RE: New job on V7.1

PTF SI48786 was released to address this.
--
Sean Porterfield


-----Original Message-----
From: CRPence
Sent: Wednesday, November 07, 2012 12:43

<snip>

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