Re: Issue with running HLDJOBSCDE from CL Prog

On 2/15/11 4:04 PM, O'Callaghan, Barry wrote:

I just wrote a piece of CL that basically takes a copy of the default
job scheduler (QUSRSYS/QDFTJOBSCD) to save file from source, ftps the
save file to target and then restores the jobscd object to QUSRSYS on
target. The save/restore part is working fine for me, though I am
having a slight issue.

At the end of the script, I have:
HLDJOBSCDE JOB(*ALL) ENTRYNBR(*ALL)

This is too prevent any jobs that are only supposed to run on source
from running on target once the default Job scheduler has been
restored.

Every time my gets to this part it fails with the following CPF?
CPF1640 - Job schedule &1 in library &2 does not exist

Has anyone come across this CPF before?. It sounds like it is failing
trying to hold a job scheduled entry that doesn't exist, however how
is this possible with a HLDJOBSCDE *ALL *ALL??. Would be grateful for
any insight, cheers guys.

Restoring the object is, to the Job Scheduling feature, the equivalent of having performed the first part of an "upgrade" install scenario. Thus the message alludes to completing the install by performing the install of QUSRSYS. The recovery could be as simple as calling the "install exit program" that exists for the "upgrade" of the *JOBSCD object; that assumes some user-domain means of effecting the CALL to that exit-pgm; I am not sure if UPDSYSINF, INZSYS, or some direct CALL might perform that processing instead of only as part of the QUSRSYS install itself.

FWiW searching the message in the symptom keyword form msgCPF1640 or the message identifier itself might lead to some documentation of the means to perform the required "upgrade" processing to enable the utility to function without that error after having performed the restore. Combining the search keywords for restore, upgrade, RSTOBJ, install exit, exit program, or others might better limit the results.

I did not read\research any of the many documents on the web using the above searches [some on the archives of midrange.com]... There is another possibility along the same thoughts above, and that is the prior RSTOBJ in the job causes the utility to be unavailable but only in that routing step; e.g. due to a pointer in static storage to the old *JOBSCD object. In that case perhaps just signoff\signon would verify that the request would then function; a RRTJOB or SBMJOB could effect the hold.? However since the "upgrade" is required for any case where the object might have been restored from a down-level release, thee utility may be adamant that the installation-exit-program gets called before. In such cases, the utility may integrate that feature into one or more of its interfaces; so apparently not HLDJOBSCDE, but perhaps ADDJOBSCDE, CHGJOBSCDE, or RMVJOBSCDE might implicitly effect the "upgrade" path by first calling the install-exit to ensure the object appears "installed" before failing the request with the CPF1640.

Regards, Chuck