Alan Shore wrote:
A job is manually started 4 out of 5 days a week
The other time, the first business day of the week, it is on a
WRKJOBSCDE job. In this instance the job runs for 2 to 2 1/2
hours and then I get: Error message CPF4101 appeared during OPEN
for file FILENAME (C S D F).
Does "manually started" mean SBMJOB with its various parameters
defaulting to *CURRENT like SYSLIBL(*CURRENT) CURLIB(*CURRENT)
USRLIBL(*CURRENT)? The ADDJOBSCDE as I recall, depends on a library
list established either by the CMD() processing itself, or what it
would establish from the JOBD(). In either case, the job /routing/
[by JOB() & routing data] may also effect changes to the library
list via the routing program.
When I look at the system, the file is DEFINITELY there, but in
a library that is no longer in the WRKJOBSCDE original library
list. I've looked at the programs involved in the WRKJOBSCDE but
I cannot find ANYTHING to do with a change to the library
(granted - I may have just missed it)
Perhaps instead of the source, the joblog could be reviewed.
Even there, the change is easily missed if not coded either to leave
the CL request logged or to leave a\the message about the change to
the library list logged; i.e. LOGCLPGM(*YES) & LOG(4 0 *SECLVL) may
assist to see a library list modification logged in the joblog.
Now the WRKJOBSCDE (as with the manual start) just loops around
from when it is started to when it is manually ended.
Is this is a job that services requests from other jobs, or just
loops doing the same thing over? If the former, perhaps something
specific that is requested invokes a library list change feature.
This last time, I saw that the library list DEFINITELY had this
particular library in it at the start, but the error happened.
To verify for sure... Possibly worth changing the application to
perform WRKJOB OUTPUT(*PRINT) or DSPLIBL OUTPUT(*PRINT) at the
beginning of processing to confirm the *LIBL is as desired upon
entry? At the start of each iteration?
This process of WRKJOBSCDE is fairly new, and has been run only
twice, but in both cases the problem happened, and in both cases
not long after ANOTHER job ended.
Something not so obvious like an object existing at timeN but
then no longer existing by the timeN+X when the Open transpires
could be an issue; i.e. no adjustment to *LIBL made because an
object was expected to remain, but the processing in the other job
deleted the object that was expected to remain available for the
current job.
Could be a coincidence. Is there anyway of changing a job's
library list (running in batch) from another job also running in
batch?
Inter-process communication can be used to ask another job to
modify its own library list, but there is no manner I am aware of
where one job can directly manipulate the library list of another
[without requiring access to system domain storage; e.g. as might be
effected running QSECURITY<=30].
Is there a way to monitor for a change in a jobs library list?
Reactively with auditing of the various CL commands and\or each
CPP which implements the various requests such as: CHGSYSLIBL,
CHGLIBL, RMVLIBLE, ADDLIBLE [EDTLIBL is interactive only].
As OPM each of the CPP can be actively caught in debug using
ADDBKP. The breakpoints can even have a BKPPGM in the batch to
notify of the invocation [to run unattended], optionally to even
await response to an inquiry so the stack could be viewed versus
just spooling WRKJOB OPTION(*PGMSTK) and DSPLIBL details just before
the request [and debug\bkp of return from the CL invocation could
even effect post-invocation DSPLIBL or WRKJOB output for whichever
library list change interface was invoked].
As always any and all responses are welcome
Regards, Chuck
midrange.com
