On 02 Aug 2012 15:38, Charles Sallee wrote:
I appreciate everyone's comments on this and, 'best practices' aside;
I went with the spool file option for several reasons:
1. I have lots of experience using this method (we always done it
that way! :-) :-)).
Ugh. Apparently not yet either having encountered or having noticed
any of the multiple issues that are likely to be seen eventually using
that method.? Changed layouts for the printer file data are just one of
many issues that may cause difficulties. Too many spools, too large
spool, overrides [SPLFNAME, PRTTXT, PAGESIZE or others might impact copy
or reading\selecting], performance issues, spool file owner, authority
to the spooled file, non-spool\printed\deleted spools, and many other
issues are likely [if only eventually] when using SPLF. There is a huge
amount of [even redundant] work that occurs for spooling, copying,
opening, and reading, and thus implicitly many more chances for
difficulties to be encountered.
2. I can not get the operations staff to load the QSYSINC copy
library.
The original post stated that the work was to be done "in a CL"; i.e.
a CLP or CLLE. So what value QSYSINC could provide, seems illusory,
since there had never been [and presumably still are not] any
declarations for CL made available by that option's installation.
3. I don't have much experience with APIs and they can also change
with a release.
I know #3 is not likely but a possibility.
IMO this is a poor rationalization; i.e. more just an excuse for
continuing with option 1. Why not gain some experience using an API?
This scenario provides a simple introduction for which obvious benefits
should be obvious.
Any "change" to an API in almost all cases will be moot, with regard
to a caller, given the coding to that API was done appropriately. On
the other hand, [disruptive] changes to data sent to a printer file are
probable. A call to the Retrieve Job Information (QUSRJOBI) to do the
desired work is extremely simple, and will work in every release since
the API [format JOBI0300] was introduced. Extremely doubtful any
release would ever experience any disruptive change in the effect.
Aside from forming the qualified job name, here is a snippet of CL
code that retrieves the job date from a named job, and then converts
that value into an ISO formatted date-string [optional; if that might be
more desirable than CYYMMDD as documented by WMAttrDesc for the
retrieved Job Date value]:
<code>
dcl &jobnam *char 26
dcl &rcvvar *char 200
dcl &rcvlen *int 4 (200) /* Size of &rcvvar */
dcl &fmtnam *char 10 (JOBI0300)
dcl &intjid *char 16 (' ')
dcl &jobdat *char 7
dcl &isodat *char 10
call qusrjobi parm( &rcvvar &rcvlen &fmtnam &jobnam &intjid )
chgvar &jobdat %sst(&rcvvar 181 07)
cvtdat date(&jobdat) tovar(&isodat) fromfmt(*cymd) tofmt(*iso)
</code>
Jeff, thanks for your note. I had looked at the DSPJOB printout and
overlooked the job date. So, you helped me finish the task the way I
had started.
At least, still, until v5r3, the printer file QPDSPJOB could be
overridden to a database file for use of a request to use WRKJOB
OUTPUT(*PRINT) OPTION(*DFNA) which eliminates some of the spool-specific
potential difficulties, placing the spooled results including "job date"
directly into a database file member thus also eliminating any CPYSPLF work.
All of this brings me back to the reason for writing this code. Has
anyone else experienced a problem with Client Access when the user
turns off their PC before shutting down Client Access? About once a
week someone will do so (or the PC crashes) and I get a runaway job
that is eating up a lot of the CPU.
The job log has the following messages in it:
Session stopped by a request from device SG8BWCP1A1.
Input or Output request failed. See message CPF5140.
The "Device Recovery Action" for the job can be adjusted to change
the effect for the loss of contact with the [emulated] display device.
See QDEVRCYACN system value and the DEVRCYACN job attribute, and the
help text for the supported values. The "runaway" may be a coding issue
with an application; perhaps incorrectly coded to properly handle the
chosen device recovery action, and possibly resolved\circumvented by
simply choosing an alternate effect such as *ENDJOB.
For my procedure, after checking the WRTACTJOB printout, I wanted a
way to check the job date before any further logic. <<SNIP>>
Hmmm. The "job date" seems an odd value to review.? I wonder if
either of the "Date and time job became active" or "Date and time job
entered system" might instead be what is of interest to review.?
Regards, Chuck
midrange.com
