From: Chris Ringer
To: All
How does the AS/400 determine where a report should go? I read somewhere that there are rules the system uses to determine where a spool file should go.
From: Matt Sargent
To: Chris Ringer
Call it the the Hierarchy of the Damned. The base level is whatever output queue is specified on the print file being used. If an output queue is explicitly specified, the only thing that can change where the spooled files goes is an Override Printer File (OVRPRTF) command. However, instead of explicitly specifying an output queue, the values *DEV or *JOB can be used. You can also use these two special values in the OVRPRTF command.
The value *JOB points to the OUTQ value specified in the current job. This may or may not be an explicitly specified output queue. It might be special value *USRPRF, *DEV, or *WRKSTN.
If the value is *USRPRF, then the output queue can be explicitly defined in the current user profile, or it can be *DEV or *WRKSTN.
If the value is *WRKSTN, then the output queue can be explicitly defined in the workstation device description, or it can be the special value *DEV.
If the value is *DEV, the value refers to the device (DEV) entry of the printer file or the DEV entry of the OVRPRTF command, if one is in effect. The DEV entry can specify either a printer device name (not an output queue) or special value *JOB or *SYSVAL. Here, *JOB has a completely different meaning than it does in the *JOB mentioned above. In this case, it refers to the PRTDEV entry of the current job, not the output queue. *SYSVAL points to the QPRTDEV system value.
The PRTDEV entry for the job can specify either a printer device name or one of the special values *USRPRF, *WRKSTN, or *SYSVAL. Again, *USRPRF and *WRKSTN refer to the PRTDEV entries, not to the output queue for the user profile or workstation. *SYSVAL refers to the system value QPRTDEV.
The best thing to do is to start at the printer file definition and follow the trail up from there. Whenever *JOB is specified, you'll need to check out what job description was used when the job was initiated.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online