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

http://imho.midrange.com/2011/09/07/the-green-screen-sucks-and-other-heresy/

-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

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

-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.

This is where report mining comes in.

You may not have heard the term “report mining” before but essentially report mining is just taking your printable reports from your AS40 or iSeries and bringing them over to your PC into a program like Excel, then scrubbing them up a bit.

Maybee you need to calculate some additional fields or condense the data into an easy to read format. This is where report mining can really come through.

Getting data off of your AS400 to a PC used to be a major hassle back in the dark ages… in fatc people hated it so much that software vendors sprung up all over to accomplish this now routine task.

If you have the luxury of having a programmer on staff that can write reports all day long then your in luck. But some places can’t and hiring an outside consultant to write reports at $175 dollars an hour adds up quickly.

Another option is using the excellent tool you might have is Query/400. This allows you to write simple reports joining together data from one or more files. 

Unfortunatley Query has limited logic capabilities that are handled better by regular programmed reports, but for probably 80% of the reporting needed it will suffice.

Anyhow, back to report mining. If the data you want to get at is already a part of an existing report then you are in luck. No need to write a query since you can just mine that report to get what you want.

The process is really simple and takes only a few mouse clicks.

Using Operations Navigator you can simply browse the printer data on the system then drag and drop any report on your As400 or iSeries onto your desktop. The software then automatically converts it into a text file.

Now this works with reports that are still in an outq on the system. The best way to handle this is to have your spool files go to your own output queue that is not attached to a writer.

After copying the file over to your PC, simply open up that text file with the Excel data import wizard, add the column breaks, clean up the report headings and you are off to the races.

This really is a poor mans way to generate reports, but its really simple and you should already have all the tools to do it installed on your computer.

All you need is Operations Navigator (aka iSeries Navigator) and Excel.

If you need something more complex then look into the other options out there like writing reports using Query or the Excel Add-in.

The operating system that runs on an AS/400, iSeries, i5 is known as OS/400 or i5/OS and it is command and menu driven. At its heart everything tends to be a command and even the menus that you see use commands behind the scenes. All of these commands are known as control language

 AS400 commands tend to be three letter abbreviations of two or more words put together. For example the word “work” is commonly used in several commands and is abbreviated as wrk. Printable output on an AS/400 is known as spool files and commands to work with those are abreviated as splf— ok so thats four letters but it is a rare exception.

So if we put together Work and Spool Files we ge the command “wrksplf” Work with Spool Files and it allows you to maintain your printable output that is still residing on the system. And by the way commands are entered on the command line at the bottom of menus and denoted with the “===>” symbol.

 To see a list of AS400 commands that have been catagorized into groups type in “go verb” on the command line. As you will see there are *alot* of commands. Ultimately you will probably only ever use 20% of them, and realistically even for day to day system administration less than that.

You can also prompt any command by typing it in and pressing the F4 key on the keyboard. This prompting will display more detail about the command and provide all of the available parameters that go along with it.

Everything that runs on the AS400 is called a job. And all of the jobs run within their own areas known as subsystems. To see a list of all the jobs currently running on the system you will use the command wrkactjob which stands for Work with Active Jobs.

Without getting into a bunch of techno jargon, subsystems are a way to run jobs that jobs can be allocated system resources like memory and CPU processing time. For example printers run in there very own subsystem called QSPL, which tends to have its own pool of memory allocated to it. That way others jobs in the system don’t use that allocated memory and vice versa. The memory can be reallocated easily if need be but that will be covered in another topic.

Out of the box an AS400 will have adequate subsystems configured to get you up and going… as time goes on your can create more subsystems or change the pre-configured ones if need be.

Lastly let’s take a look at how to shutdown or restart an AS400. Starting up an AS400 or restarting is know as an Initial Program Load or IPL for short. This is a rather straight forward process but can take quite a bit of time to complete.

In a very brief nutshell upon startup the system checks everything out and loads up the operating system and related systems to make the system opertational. During an IPL is most often when you will experience a hardware failure… not to worry though because most hardware failures that occur on an AS400 can be replaced while the machine is running. This includes hard disks, redundant power supplies and even memory.

So to shutdown or IPL a system you will use the Power menu which you access by typing in “go power” on the command line or alternatively using the Power Down System or pwrdwnsys command. Most people opt for using pwrdwnsys.

-John Andersen

Sometimes when people transfer data from an AS/400 to Excel or another program they run into a some data that looks a bit like guacamole, this tends to happen when transferring numerical data.

Without getting into a lot of boring technical details “packed data fields” are the default standard for storing numerical data on AS/400s in a format known as EBCDIC. PC based computers use ASCII and so they don’t always translate across when transferred in there native formats.

The problem is when you bring that data over to the PC world it doesn’t always translate correctly to ASCII… now this only tends to occur when using the data transfer program built into Client Access and not when using an ODBC connection or other program which does the data translation for you behind the scenes.

The symptom is that when you download the data you will see letters in fields where there should be numbers from 0 through 9. To correct you simply translate these letters or characters over to the corresponding number as follows:

0 = ‘}’
1 = ‘J’
2 = ‘K’
3 = ‘L’
4 = ‘M’
5 = ‘N’
6 = ‘O’
7 = ‘P’
8 = ‘Q’
9 = ‘R’

Now thats about as easy as duck soup… but it sure can be a pain. Ultimately to “cure” this issue you will want to get at the data another way and not use the AS/400 Data Transfer portion of Client Access for this specific table, instead use ODBC and SQL query, import it as part of a printable report, etc.