On 25-Nov-2013 11:09 -0800, Steinmetz, Paul wrote:
Initial library list error tolerance
Starting in 7.1, the way certain errors are handled for the initial
library list when starting certain types of jobs has changed to allow
the job to start. In prior releases, they would have received an
error message and the job would have been prevented from starting.
When starting an interactive job, an autostart job, a communications
job, a prestart job, or starting a batch job that is on a job queue,
if a library is not found it now dropped from the library list. Also
for these job types, if a library is specified more than once, only
the first reference is kept in the library list. Other interfaces
affecting library lists are not changed.
I just tested a SBMJOB with initial library list (INLLIBL) *JOBD, the
Job Description contained a library that does not exist. At V7R1, I
expected this job to run, but it behaved the same as at V6R1,
CPF1153, Library .. not found, and CPF1338 Errors occurred on SBMJOB
command.
The CPP for the Submit Job command, QWTSCSBJ. is performing the
validation of the INLLIBL *prior to* the job being placed on the Job
Queue; i.e. symptom is msgCPF1153 F/QWTSCSBJ The same validation is
performed on the resolved values of the Current Library (CURLIB)
parameter and the System Library List (SYSLIBL) parameters as well.
I also tested an interactive job, JOBD contains a library that does
not exist. At V6R1, job does NOT start, posts CPF1113 Library in
initial library list not found At V7R1, job does start, posts CPI146B
Library in initial library list not found, (No one will ever see this
message)
Some CPI09## messages log similar /tolerated/ conditions, logged
prior to the CPF1124 for the start of the job; similarly obscure.
If nothing else, perhaps ask that they at least send their new
message(s) to *SYSOPR so that an operator might get annoyed enough, or
at least be able to notice the condition, and then address the issue; if
sent to QSYSOPR, then available also in DSPLOG.
I'm a bit confused to what will run and not run.
Perhaps only for the nuance of the job on-the-JOBQ versus not yet
on-the-JOBQ?
The V6R1 logic was equal across the board, a good safety check, now
it is gone.
If a library was missing or a JOBD was wrong, the job would not run.
Does anyone know why this was changed?
Perhaps because a sufficiently large number of issues that customers
have encountered, for which a service call often was the result; issues
that since would be overcome with those changes.? The most beneficial
effect, enabling interactive jobs to continue, because those are
effectively /attended/ vs unattended processing. Sometimes customer
[recovery] actions impact their ability to signon, such that a manual
IPL might be required to enable them to recover from prior actions.
Other non-usage origins, e.g. lost contexts, likely still would require
a service call, even if just to say "issue RCLSTG SELECT(*ALL)."
However I agree with the benefit in not allowing a job to start its
processing, given a missing library or even a duplicate library [per
*proper position* being indeterminate]. At least for other than
interactive job types. Hardly beneficial to have a[n unattended]
process get x% complete, only to crash and burn, because the required
library-list was not properly established according to the initial Work
Management attributes. It might be worthwhile reporting the new effect
as a defect, asking\hoping they may enable an [effective system value
as] ability to get the old behavior [at least for other than interactive
signon].
I am actually surprised the change took over a quarter century...
given they managed to resolve some similar issues ages ago. For other
missing objects like a *JOBD [with a CPI0913 to diagnose it, and
similarly, likely goes mostly unnoticed; e.g. I just recently went a
week before seeing mine], but for some reason they never addressed a
missing library. I suppose that is because with the other missing
object situations [e.g. OUTQ, CLS, JOBD] that were changed to be
/tolerant/ of the errors, they were able for each, to provide the job
with a /backup object/ to replace the missing object. Not so
straightforward with a library object.
I remember complaining in V1R2 about a missing library being a
frustrating issue for interactive sign-on, after encountering the
problem due to poorly planned recovery of systems in the lab and
eventually due to a combination of of overly-capable users and
improperly configured systems [e.g. QSYSLIBL or QUSRLIBL and QLIBLCKLVL
where the latter enables DLTLIB]. Similar problems some customers have
experienced, and thus might need to use a manual IPL to recover, just as
we did in the lab.
midrange.com
