Re: Monitoring for a change in a jobs library list

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