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.

This post is password protected. To view it please enter your password below:

Password:

I think you will be pleasently surprised that the gift I am sending out this year is worth quite a bit.

Please note that if you didn’t put in a valid or complete mailing address I have no way of sending your gift to you!

-John Andersen

So be sure and watch this space because on Wednesday I will put up my Christmas sign up list so I can send you a gift. But you will have to act quick because the list will only be available for a couple of days before I take it down.

-John Andersen

So that is why I have been posting lately about things like Query/400, the DB2 database and SQL.

They are simply excellent tools for getting at the data you want and need from your AS/400 and IBM i system. And at some point you definately need data out of your system.

But now it’s coming towards the busy time of year. And before your life gets busy like mine does around the holidays, I wanted to find something out from you my reader and customer.

What Do YOU Want From Me?

I want to know what you would like to see from me. Do you want to know how to create AS/400 reports, CL programs, manage your system, something else?

Based on what you tell me, I plan on sending you a gift just to say “thank you.”

So for the next few days the floor is yours. Go ahead and post a comment to this entry letting me know what you would like.

But here is the deal: I am only accepting 10 comments to this entry, after that I will close comments for this post.

So let me know right NOW what you want before comments are closed.

-John Andersen

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

I have covered Query/400 in prior blog posts, it is simply a great reporting tool that is really more than a mere reporting tool. It also has a ton of features and many little tricks that I cover in the course.

The special runs from now until Wednesday at noon (Pacific Time, GMT-8). During the special you can pick up a copy of Query In A Flash at a special price of $30. The special is at least 70% off the final price.

But once the 48 hour special is over the price will go up, so act quick and order your copy of Query In A Flash right away by going here:
http://kunaki.com/sales.asp?PID=PX00FJ5AJ9

-John Andersen