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

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.