IBM response:
The QDFTSVR job showing the details of: QSYS/CALL PGM(QSYS/QLWISEIMPL) PARM('*QLWIENDALL')
The above call is to a program that ends all non-admin servers. If the user who calls this command has enough authority to call the program and the non-admin servers end properly then this job should end. If the QBATCH jobq is held, there's no way to eliminate this as it's part of the ENDTCPSVR command processing. I suppose you could just end the job from the jobq itself, but if there are non-admin HTTP servers that need to be ended it would appear those would have to be ended manually.
--
Sean Porterfield
________________________________________
From: midrange-l-bounces@xxxxxxxxxxxx [midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence [CRPbottle@xxxxxxxxx]
Sent: Wednesday, November 07, 2012 12:42
To: midrange-l@xxxxxxxxxxxx
Subject: 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.?
--
Regards, Chuck
On 07 Nov 2012 08:39, Porterfield, Sean wrote:
Our backup job submitted a job each day it ran this week after the
upgrade. I couldn't find anything on Bing, Google, or IBM site
search. Anyone know what this is?
Job: QDFTSVR Jobq: Qbatch
.. QSYS/CALL PGM(QSYS/QLWISEIMPL) PARM('*QLWIENDALL')
I can guess the parameter probably means End All.
Based on the log of the job submitting it, it seems to be from
ENDTCPSVR *ALL
The line before showed HTTP ending, and the line after showed IAS
ending.
For those wondering why I care, this is our backup HA system, so
most JOBQ are on hold to prevent things from accidentally running.
The QDFTSVR job gets stuck in the queue, and eventually (if we
hadn't looked) we'd get an alert that there are jobs in queue (from
Bytware MPLUS).
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
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.
midrange.com
