Re: New job on V7.1

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.?