Re: New job on V7.1

[CRPence <CRPbottle@xxxxxxxxx>]

  IIRC the "LWI" [component; ¿either LightWeight Infrastructure or 
Lightweight Web Infrastructure?] naming was the original moniker for 
what became known as IAS [¿Integrated Application Server?]; web search 
results support my recollection.  FWiW: the component naming does not 
change, simply to match an eventual [or new] "external" naming for the 
feature it implements.

  I expect the inferences are correct, for both an "End All" parameter 
meaning for the QLWISEIMPL program-call and that the origin of the 
SBMJOB was from within the request to End the TCP Servers.  A spooled 
joblog showing the "job submitted" message would identify the program 
that did that; e.g. the completion message sent to QTOCxxxx.  The 
spooled joblog for the submitted job would show details about the WM 
that defined\started the batch job.

  Presumably the "backup job" is a utility that issues the ENDTCPSVR, 
as a defaulted action of that utility, perhaps limited to what type of 
SAV activity was requested to be performed, or perhaps instead as a 
user-configured\requested action, and then that backup feature performs 
some SAVxxx activities.?

  I have no idea why a submitted job would be the implementation for 
the ENTTCPSVR command to effect part of its work; at least if the WM is 
not configurable and conspicuous.  However I believe there was a change 
of direction from original design intentions which would have avoided 
using standard Submit Job WM from within OS features without providing 
good user-configurable capability; most typically, naming the JOBD to be 
used which defines the routing data and job queue.  However at some 
point the OS established both the QSYSNOMAX Job Queue and the QSYSWRK 
Subsystem Description which together were intended, I presume, to 
provide some standard\typical WM that the OS features could depend on 
being always-available; i.e. no limit to the number of jobs, and safely 
presumed never to be held, being unavailable only in restricted state 
for which a System Job would be the only alternative.  Thus if those 
object names describe the starting\routing for the work in the noted 
scenario, I would not be surprised that a response from IBM would 
suggest that this specific WM path should not be inhibited; i.e. holding 
the work within that path\routing is considered a usage issue.  However 
one might wonder it that were the intention, then why would HLDJOBQ even 
be allowed against that JOBQ object name.?