Where is my report?

When we have lots of users with lots of reports for lots of printers, this can be a problem.

Understand Queues

One of the biggest issues for new users coming from an environment of stand-alone PCs, is a failure to recognize the implications of network queues.

A new user, unaccustomed to a multi-user system, is accustomed to doing SOMETHING, then IMMEDIATELY expecting to find the results on the printer. But

• Their task might still be in JOBQ.
• Some software, when selection criteria would create an empty report, generates nothing.
• Depending on the software structure, the output might not be going to end up as a report on spool file, but get transmitted to a shared PC folder in a format to go to e-mail or spread sheet, or be going to some kind of work file.
• Their report might not print until someone else's report has finished printing.
• Their reports might be going to an OUTQ that does not have an attached printer writer.
• If they slow to get to printer, relative to when report prints, someone else may have torn it off and set it aside, or accidentally when tear off reports, a user goes off with THEIR report(s) with someone else's attached.

Where 400 places report

• Did you ever play Dungeons and Dragons?
• Do you remember "levels" going down into the adventures?
• Each level more challenging than the last?
• You learn the rules for a level, then go down to next level and find there are more rules to learn if you have any hope of proceeding into deeper layers.
• Well IBM Printer management also has "levels" but fortunately some levels are simpler than the last. It is possible to navigate with only a superficial understanding of the rules at some levels.
• And guess what? When I am going to mess with the rules that govern how printers behave, I prefer to do so at a level that is simple.

When I say "the next level is" by that I mean that this next level can override stuff that was in the earlier level. If different levels have different rules, it is the last level that wins the arguement, but many levels do not bother to exert their authority, so it usually does no good to look at the last level ... you have to know the hierarchy, and how to look at the rules for each level.

These rules work like a library list ... a program needs to access a bunch of objects, and it goes down the library list "path" until it hits the first discovery of each piece of the puzzle, but different pieces might be found at different levels. Same basic story for all the rules pertaining to 400 reports talking to a printer.

In this navigation exploration, we will go from the bottom level up the hierarchy to see how to navigate each thing then see what its boss is, recognizing that most bosses on the 400 tend to let their subordinates do their own thing except in very special cases.

Level 1 - System Printer Value

1. The first level is very basic.
   1. DSPSYSVAL QPRTDEV is how we check it
   2. this is the system value that says to send 100% of print-outs to the system printer PRT02 unless something over-rides that.
   3. This system value is pretty simple, you are not going to see it cause different behavior for different people printers.
      1. it is not anyone or any work station specific
      2. it is not getting into fonts or other printer variables

Level 2 Hardware *DEV

1. The second level is the hardware DEVICE
   1. WRKCFGSTS *DEV is one way to access info. When looking at other IBM screens, the object type for this is *DEV meaning DEVICE.
   2. Here are rules about what the printer is capable of doing, like font, lines to the inch ... this area is extremely complex, and best left just for making sure equipment is hooked up Ok.
      1. In theory you can use this place to say that a particular display station's output is to go to a particular printer.
      2. However, we often have enough of a hassle just getting equipment connected, working, identified.
   3. The ACTUAL device attached might be other than what it is emulating on the 400.
      1. This can cause different behavior for different people printers because it has to do with what KIND of printer is being emulated. We have in the past found it convenient to tell the 400 that every printer that is attached is just like our existing printers. This way we can send any report to any printer. Now some printers might not be able to handle very narrow reports, or 15 characters to the inch horizontally, or 8 lines to the inch vertically, or some special symbols, but then we will find that out when we try to print something there that is invalid for that printer, and the user of the printer will then know that we have invested in a printer that cannot do certain AS/400 things.
         1. A useful standard for report programs when trying to output a character unprintable on a particular printer is just to substitute a blank space.
      2. But that reality is astronomically superior to coding the printer so that when someone tries to transfer a report to its attached spool file, the user gets some error message they do not understand. This way any user can transfer any report to any spool file, and they get no error messages in their way.
      3. Al Mac considers it very dangerous to get into the game of saying that this printer will do this font, point size, page size, and so forth, because then we get stuff messed up and have no idea where or how to fix it. Each printer should be setup such that the HOST, which is to say the 400, will dictate the printing rules, and this printer is to emulate one of the other printer devices that all the other printers are emulating, so as to tell the 400 that it has access to all the same capabilities as our other printers, whether that is true or not. We should not be telling the 400 anything different about some connected printer unless we know exactly what we are doing here.
   4. Troubleshooting a printer whose font or whatever is messed up.
      1. Find some other printer that is Ok, then carefully copy its rules to the printer that is messed up. By Ok, we have done a variety of different reports there to be sure. If you have report X and you send it to one printer, then reprint it at another printer, and one is messed up, and the other is fine, you have eliminated the settings in the same report as being a suspect.
      2. How do find in WRKCFGSTS where these printer rules are that I am saying you are better off not tinkering with? Well let's walk thru the following steps from command line:
         1. WRKCFGSTS *DEV PRT02
            1. substitute for PRT02 whatever is the System Printer at your site
         2. enter
         3. Notice F23 and F24 ... you might want to do them a few times to toggle through the full range of stuff available
         4. F23 applies to the numbers at the top of the screen that are the Option numbers for the left side
         5. F24 applies to the command keys available, that are listed at the bottom of the screen
         6. Then fly off with my favorite F14

Notice that PRT02 says type 5225 ... a surprise to some people perhaps ... I vaguely remember 6400 but what is important here is not what the hardware number is, but what hardware we want it to emulate ... before we got the 6400, we had a 5225 there. Hey if it works, why change it? If it aint broke, don't fix it.

1. 1. 1. 1. When you first do option 5 and enter, you might want to also toggle F11 because some of those value designations will show up other places
         2. Do option 5 and print every screen
         3. You might also want to do option 6 and compare what info is printed relative to what is on screen when you scrolling thru all the stuff
         4. You will notice that printers have a heck of a lot of possibilities, compared to those we are actually using. I not want to mess with that extra stuff unless absolutely neccessary ... much of it is what printer type 5225 defaults to, and some can be overrides.