Sometimes you can’t have all the budget you want to be prepared for every possible disaster but you can do things to prepare you for some scenarios so you can at least have your ducks in order if something should go wrong. This includes testing some assumptions.

If your organization runs multiple facilties and has the budget then looking into some sort of High Availability product is probably the best way to assure business continuity should one facility go down for whatever reason. When it comes to the i world the products to accomplish this have been around, they are stable and mature.

At a very basic level they will replicate data and objects between a primary and backup(s) systems in near real time depending on some factors including the amount of bandwidth available.

Should the primary host go down you can rollover to the backup with minimal data loss.

Now if you don’t have the budget for HA you should at least put together a preparedness plan. Obviously you don’t want to test restoring your entire system from a tape backup just to see if it works (though if you have a backup system in place that is an excellent idea) you can put together a rough outline or plan for what to do.

I prefer to use a binder that is placed in the server room that has all of the pertinent information stored in it. Support contract agreements, tech support numbers (like 1-800-IBM-SERV), passwords, checklists and data CDs with important programs.

Do you know if you can IPL off of your tape device? Have you tested that? If you can’t then you had better have at least enough of the installation CDs to get the load source back up to a point where you can restore from tape.

Multi-member files allow you to essentially create a database file with the same layout and structure but with a different “member” still a apart of the file that contains data separate from another member.

It’s as if they are two distinctly different files but have the same exact format.

Now I can see why members can be a useful feature but frankly I don’t like using multile member files because it can cause confusion and issues if you are not looking out for them when writing a program or report.

Just to be clear though, files with data have at least a single member created. And to be able to add data to a file it needs to contain a member, but just one will suffice.

The tools and programs created on the AS/400 handle multi-member files fairly easily, for instance in Query/400 when you specify the file selection you can choose a specific member if need be.  It handles everything without any more rigmarole.

But SQL is a different animal. This also applies when you are querying the database through ODBC, JDBC or something else.

Currently there isn’t a way of choosing the member you want when selecting data using an SQL statement.

There is a workaround though. And that is to create an ”alias” of the physical file and specific member like the following where JOHNA is the library, SALES is the physical file and MEMBER3 is the member:

CREATE ALIAS JOHNA/SALES3
FOR JOHNA/SALES(MEMBER3)

The alias SALES3 will be created as a non keyed logical file with only the data from the MEMBER3 member that you can then use your regular SQL statements on directly.

-John Andersen

Since relational databases, are well, relational if the data is similar or somehow related there should be a common field between the files or tables. This common field is what allows you to join the database files together.

For instance take a SALES file that has a field SLSNUM that contains the salesrep numbers would be related to a file SALESREP with the same SLSNUM field. You would join these two files based on the SLSNUM field.

But, not all joins work the same regardless if you are writing custom reports using Query/400, Query Manager or another query tool since they tend to use SQL behind the scenes to actually query the database.

You need to understand the different types of joins for bringing our sales and salesrep files together because it makes a big difference in the end result.

The first method of joins will return only records that match the join field, salesrep, in BOTH files, here is the SQL used and a print screen of the query results:

select * from sales
join salesrep
on sales.salesrep = salesrep.salesrep

The second join method will return records from the sales file and any records without a match in the salesrep file come back as nulls:

select * from sales
left join salesrep
on sales.salesrep = salesrep.salesrep

See the difference between query results? When there isn’t a match on the salesrep number field it comes back as null displayed as a – in the fields.

Now why does this matter? Well the first join could produce a report or query that is missing data or incomplete if there are missing records from your secondary file.

On well written software that checks for and enforces integrity of the data this is not always a problem (ie a sales record that has a missing salesrep number), but it can happen even in commercial programs.

Now as I mentioned previously this matters even f you use Query/400 or Query for iSeries, you specify the first join from above using “1=Matched Records” and the left join style using ”2=Matched Records With Primary File” as the join type.

-John Andersen

At some point you will want to retrieve data out of the system, and you will want (or someone else will want) to see data in a report or way that the software you are running will not provide. This is where report writing and creation comes in, every place I have worked at had a fair number of “custom” reports used day in and out that where critical to running the business.

There are many different tools for creating reports. There is a whole market of third party report software. Many advanced systems and ERP vendors sell a reporting package or module in the bundle of software and these can be a good choice since they plug right in. For instance on SAP there are so many files its hard to find what file or field you need.

The neat thing about advanced report writing tools is they abstract all of that from the person building the report by usually having the software vendor create the mappings and cross references to the underlying database tables.

There are other methods to get at the data like using linked tables in Access via ODBC connection and I will covers those another time. For now let’s look at the common tools available for report building directly on the system.

First up is Query Manager, not to be confused with Query/400 which I will get to in just a minute.

Query Manager essentially has two parts, the query and the form. To create a report using Query Manager you first will create a query using SQL and then create a query manager form to format and display the query data.

Using standard SQL with Query Manager has several benefits. It will also end up using the SQE optimizer which is vastly superior to the old Classic Query Engine or CQE. Although query performance rarely matters to end users when you start drilling into files with millions of records it can have a huge impact.

SQL is also fairly well known and you can proof a SQL statement and usually copy and run it in another system to access the same data with no to very minor tweaking. With SQL you also have many more functions at your disposal, like being able to convert numbers to alphanumeric whereas doing this in Query/400 is hokey and has limitations.

So although Query Manager has it’s place, I find it clunky and not as efficient in building reports. But Query Manager is SQL driven, and that alone gives it a huge benefit over Query/400.

Also many end users are not savvy enough or don’t want to learn how to write SQL. Not to mention you can make a mistake with SQL and wipe out data (so there are some additional concerns) and drag a system down with a poorly written query. There are ways to get around this but I like to avoid it altogether.

That brings us up to Query/400. Even though DB2 Web Query has been around for awhile, Query/400 is still alive and kicking. However the writing is on the wall and you should be moving your reports over to Web Query or some other tool. The good news is that owning a license to Query/400 entitles you to a couple licenses of Web Query so you can get working on now without a bunch of additional costs.

Query/400 is quick and mostly efficient when it comes to creating reports. And you don’t need to be an IT geek or understand a bunch of techno babble to start writing reports with it. Usually the hardest part of using Query, or building any reports, is knowing what files contain the data you want.

Once you know the file and field names, you simply fire up Query/400, plug in the file name specification then press F5. And presto, on the screen the data from the file will be displayed. Next up you choose the Select Records option to limit the data to exactly what you want, salesrep = 10, customer = 1095 and so forth. Pretty simply, huh?

When you are all finished with your report you can save it as a query definition (object type *QRYDFN) to re-run it later. A cool thing to do is setup commonly used queries on a menu so users can choose what they want quickly and easily. You don’t need to be a programmer to do this, the SDA tool will do the heavy lifting for you when building custom menus.

You should always be judicial in the use of the F5 key used to preview the query. The longer it takes for the preview to come up, the more you are working the system, the less you should press F5. On systems where the interactive CPW is governed, a query writing session joining large files and sets of data can really bog things down and impact system performance by being overzealous with the F5 key.

-John Andersen

Libraries are the main storage objects on the AS/400, iSeries and IBM i platform. All objects on the system like database files, programs, data areas and such are contained within libraries. But libraries do not contain other libraries so they are essentially one level in depth.

The single exception to storing libraries within libraries is the special library called QSYS which acts like the root or master library and contains all of the other libraries. You can see this by issuing the command “DSPLIB QSYS” and paging through, each of the objects will have a type of *LIB.

Just like your Windows system has a “WINDOWS” folder that contains files essential to the operating system and the AS/400, iSeries and IBM i operting system has its own set of system and program libraries. These are commonly known as system supplied libraries and they are essential to the operating system functionality.

You can quickly find these libraries since they always start with the letter Q. As a quick side note you will find this same naming consistency with other things like system supplied user profiles that start with the letter Q, like QSECOFR and QSYSOPR.

If you do a “WRKLIB *ALL” or “WRKLIB Q*” command and page down you should see all sorts of libraries on your system, nearing the bottom of that list there are libraries like QGPL  and QTEMP. For the most part you should not mess around with the objects inside of these libraries because they are core pieces of the operating system and software.

The one exception to this rule is the QTEMP library, which is a special library for housing temporary objects in the context of a single job. When the job ends the objects for it are cleared out of QTEMP. This is useful for programs that need to create and work with temporary objects, for instance I have used it to create a copy of a scratch table that a program can modify and then dispose of table without having to worry about other users running the same program at the same time conflicting with object and record locks.

-John Andersen

Well the long and the short of it is from an end user standpoint it depends. Why is that? Because the AS/400 is just a platform, just like Windows is a platform. The actual business software runs on top the platform. Does that make sense? The way you enter in data and work with the programs will be different from software package to software package that runs on the AS/400.

So ultimately there is not one good answer on how to learn the AS/400.

However there are almost always commonalities in screen layout design that all users should be familiar with. For instance F3 exits a screen whilst F5 refreshes or updates a screen. If you need help with a specific field or screen then F1 usually brings up the help info. And so on.

Learn the “F” keys and learn them well.

The plus (+) key on the numeric keypad is generally mapped as a field exit key which slides your numbers over to the right in a field. This is handy when entering in numeric data.

Now this is an overly simplistic view of how things work on the AS400, but at least its a starting point for most total beginners. But there really is no good answer to learning an AS/400 from an end user perspective because you will need to learn the software that is being used. Hopefully the place you get hired at will at least train you on the software and it’s nuances.

Now there are some things that are good for you to know and can certainly give you a leg up or make you a power user. Like Operations Navigator, iSeries Navigator or i Navigator. Whatever IBM decides on renaming it does not matter, its what it can do for you that matters.

For instance almost every user would like to download spool files (aka reports) to there PC so they can send them electronically, email or import the data into another program like MS Excel. This is an area where i Navigator shines, you can simply track down your spool files within Navigator and then literally drag and drop it on your desktop where it is then instantly converted to a format compatible with your workstation. Pretty simple stuff that can save you hours of work.

There is alot more to be said for Navigator and I am just barely scratching the surface but most of the other tools built into it are for system administration and configuration tasks, not for end users unless you have someone that is really a power user or sophisticated enough not to screw something up. Fortunately when installing Navigator you can pick and choose which modules a user will have installed and can access.

End users should be familiar with the printing systems and how to control printable output in the form of spool files. Everything that is printable is called a spool file. Spool files spool in output queues which are then prints the document on a physical printer. So you should become familiar with the Work With Spooled Files command WRKSPLF.

WRKSPLF will show you all of your current spool files or the spool files of another user, where they are and what the status is. If you need to know why that report you just created isn’t printing this should be your first stop. There could be a message waiting.

If a printer has a bunch of documents printing on it you can use WRKSPLF to move the spooled file to another printer that may be idle.

Another frequently asked question is where the heck is that job I just submitted? So users should familiarize themselves with the Work With Submitted Jobs command WRKSBMJOB.

WRKSBMJOB displays all of the jobs you have submitted and where they are currently residing. Most importantly there is the “— status—” column that displays the current status of that job. This is important because if the job is waiting for it’s turn to actually run it the WRKSBMJOB display will show that it is waiting in the job queue so you know that it hasn’t run yet.

If the job shows the status of ”ACTIVE” then it is still processing and hasn’t finished running yet.

If the job shows a status of “OUTQ” then it has finished running and the spool file is waiting on an output queue so you can go and print it.

See how easy that is? To make your life even easier the WRKSBMJOB screen allows you to take an option to look at a message that may be waiting on the job or to go directly to the spooled files it created so you can release them or move to another outq.

-John Andersen

Check it out here:
http://www.midrangejumpstart.com/

-John Andersen

AS400 Programming Development Manager Menu

Let’s first take a look at Work With Libraries function of PDM. At a basic level this option allows you to reivew and change libraries on your system, sort of like the Work With Libraries (WRKLIB) command but using a little bit better (depending on your preference) interface with some different capabilities.

 

PDM Work With Libraries

By taking option 12 for work with from the Work With Libraries screen takes you into the second PDM option we will cover which is Work With Objects. Once again in work with objects you have all the familiar options to change, copy, delete, rename objects and so on. So similiar options is a recurring theme throughout the utility.

PDM Work With Objects

A nice feature built right into the PDM tool in the work objects screen is the ability to Position to a file name or object type which comes in really handy when you have to wade through libraries with hundreds and even thousands of objects. I am really only touching the surface of what can be done with the PDM utility.

Like the name implies it really is a tool to make programmers jobs easier.

PDM User Defined Options

For instance Programming Development Manager comes with the ability to create user definable options. These options are essentially shortcut keys you enter on the option line to perform some sort of action. Many of the more popular commands are pre-programmed options for you, for example Work With Spool Files (command WRKSPLF) is setup as option SP. So if you simply enter SP on the option line it calls up your spooled files.

The option WA calls the Work With Active Jobs (WRKACTJOB) command. Another handy option that has been pre-configured is the Call command which has been defined as option C. In this instance the option for Call is setup to pass parameters to the command for you. So if you are working with source members and wanted to call a program you just compiled (or any program for that matter) simply put the cursor in the option field next the source file you compiled, enter ‘C’ in that option field and then press the enter key and that exact program will be called.

I use the C option in PDM quite frequently when compiling and testing out programs that don’t require additional user entered parameters to be passed. Another technique to get around this is to create a small “wrapper” CL or CLLE program to pass the parameters for you.

PDM Work With

You can also setup your own PDM defined options by pressing the F6 key on the Work With User-defined Options screen and following the prompts. Lastly PDM makes working with any kind of source member easy by calling up the Source Entry Utility (also known as SEU) by using option 2.

-John Andersen

Understanding how to enter DDS specifications into a source file and compile them into physical and logical files is really as far as you need to go for 90% of the tasks involved in running a 400. Yes, nowadays you see alot about using DDL (essentially SQL) to create tables but I am still a fan of DDS and do create views using SQL statements when it makes sense to do so.

Recently I have been working on a tier three ERP system from one of those conglomerated software consolidation companies. Chances are you have heard of them if you have been around ERP systems in the last few years. 

The one thing I really hate about this system (which uses a mainstream database on the backend running on a Win32 platform) is how clunky the report writing process is. It’s not elegent, and it’s not tightly integrated into the system itself. In short I think it sucks.

This is precisely an area where the AS/400, iSeries and System i shines. You have so many native tools and applications to work with the underlying database. You have tools like Query/400, Query Manager, direct SQL and so much more that simply plugs right in and goes. You don’t have to learn a bunch of complicated syntax to use programs like Query/400 either because its entirely menu driven.

Many people these days are frowning on “green-screen” based programs.

My take is always to use the right tool for the job and sometimes that is a query report or interactive lookup screen using runqry or query definition. The command line and perhaps a small CL program allows this to be transparent to the user, so who cares if the resulting data is displayed on an old fashioned green-screen.

So to get started writing reports check out the following short list of commands/programs:

WRKQRY
STRQMQRY
RUNQRY
Operations Navigator (allows you to execute and thoroughly examine SQL statements)

One area that used to be lacking on the AS400 was report manipulation or report mining tools. People used to print out thousands of pages of reports (and many still do) just to pull out a couple pages with the pertinent details and then throw the rest away.

But nowadays there are so many third party tools that will take your spool files and convert them into plain text for your PCs. Even Operations Navigator has had this capability for many years. It even allows you to search through files and outqs. End users can even do this with a little bit of training on Operations Navigator, it’s not that difficult and they will love you for it.

There really aren’t many excuses for getting the most out of your systems today. We aren’t living in the stone age where data extraction and reporting writing for the AS/400 is complicated thanks to the myraid of tools that have been available for many years now.

There is a large misconception running about the user community these days that the AS/400 and iSeries platform are old antiquated machine as scarce as the dinosaurs and just as hard to use with its crummy looking text only interface commonly known as the green screen.

This is a major sticking point for business looking to buy an AS/400 and especially for some system administrators that have been groomed on a Windows based environment with point and click ease of use and a built in wizard to do just about everything.

But there is really good news for those people who absolutely hate the old fashioned green-screens that the AS/400 and iSeries platform is known for… there has been a tool available to make maintenance and administration tasks easier. That cool graphical user interface tool is called Operations Navigator, it comes along with your regular licenses so it doesn’t cost any additional money and it has been available now for many years.

That’s right I said that the operations navigator utility is a GUI you can use with your AS/400 and iSeries systems. With it you can maintain users, catalogue system patches and program temporary fixes, watch jobs, administer printer output queues and more.

You want to run an SQL query to delete some data sets or run a quick and dirty report and export the results into Excel? Operations navigator has you covered. Want to copy files from your computer over to the integrated file system on the AS/400? Operations navigator can do that too.

If you are into keeping a watchful eye on the health and performance data of your system, once configured, operations navigator will spit out great looking charts and graphs of important performance metrics.

Did you know that you can also download your reports as text or pdf files from your AS/400 or iSeries with operations navigator, this very feature alone can replace you dependency for expensive third party software packages you may currently be using.

One of the greatest features not otherwise available until operations navigator came around is the ability to diagnose SQL statements and present them in a graphical diagram with each of the steps the system used to execute it in very thorough detail.

There is also a whole feature set available that will collect performance data on your programs and files and record how often temporary indexes are built, you then simply go back and review this data after running a collection and it will recommend indexes to build that will improve the performance of your reports and queries dramatically.

Eventually you may find yourself having to perform some tasks in the command line environment, but as time moves on more and more of features are being built natively into operations navigator with each new release slowly removing the dependency on the green-screen. Who knows though, you may even become a convert like some of us old 400 folks and start to use the command line interface instead of the GUI.

Nonetheless oprations navigator has such a rich set of tools and its ease of use make it an excellent tool to administering your AS/400 and iSeries systems so it is definitely here to stay.