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 Dragos?
• 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.

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