RE: New job on V7.1 -- MIDRANGE-L

From: CRPence

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.

OK, so it sounds like it's related to the message after that: TCP1A17 IAS server ended.

A spooled joblog showing the "job submitted" message would identify
the program that did that;

The "CPC1221 Job 206319/BACKUP/QDFTSVR submitted to job queue QBATCH in library QGPL." message is what I used to determine the sequence of events.

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.

You lost me on the QTOCxxxx part.

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

We started years ago with a retrieval of the GO SAVE 21 program and modified it for our purposes. In 2002, we added ENDTCPSVR, ENDHOSTSVR, and ENDTCP per IBM recommendations. I saw at least part of that recommended last month, though I'm pretty sure at least one of those commands now includes one of the previous ones (as listed in sequence here). It probably goes back to telnet server issues.

I have no idea why a submitted job would be the implementation for the ENTTCPSVR command to effect part of its work;

...

However at some point the OS established both the QSYSNOMAX Job Queue
and the QSYSWRK Subsystem Description

...

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

I take that as a suggestion to open a PMR to get an official answer possibly explaining why it was done this way and hopefully an appropriate solution to prevent the jobs from sitting around daily.

Thanks!
--
Sean Porterfield

This email is confidential, intended only for the named recipient(s) above and may contain information that is privileged. If you have received this message in error or are not the named recipient(s), please notify the sender immediately and delete this email message from your computer as any and all unauthorized distribution or use of this message is strictly prohibited. Thank you.