× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I see some hits on prestart jobs in qusrwrk that use qdftsvr jobd.

On Fri, Nov 9, 2012 at 12:56 PM, Jack Kingsley <iseriesflorida@xxxxxxxxx>wrote:

Sean, these aren't jobs related to IP servers that are being ended then
restarted as a part of end tcipip possibly in your backup, jobs that might
be running in qsyswrk or qusrwrk subsystems.


On Fri, Nov 9, 2012 at 12:47 PM, Porterfield, Sean <
SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

From: CRPence

What the submitted job requested, the CALL, had already been shown.
What had not been included about that job was the CPF1124 and CPI1125,
which
in a spooled joblog, appear before the request message that showed the
CALL.
Somewhat moot now

I thought I mentioned somewhere but do not see it in this email that the
only things in the spooled joblog related to me moving the job to another
queue to run. CPF1124 was logged because I changed the jobq to QSYSNOMAX.

CPC1129 Completion 00 11/07/12 12:15:19.669542
QWTCHGJB QSYS 0B58 *EXT
From user . . . . . . . . . :
SPORTER
Message . . . . : Job
206319/BACKUP/QDFTSVR changed by SPORTER.
CPF1124 Information 00 11/07/12 12:15:19.672121
QWTPIIPP QSYS 04C0 *EXT
Message . . . . : Job
206319/BACKUP/QDFTSVR started on 11/07/12 at 12:15:19
in subsystem QSYSWRK in QSYS. Job
entered system on 11/07/12 at 01:00:08.
CPI1125 Information 00 11/07/12 12:15:19.691856
QWTPCRJA QSYS 0110 *EXT
Message . . . . : Job
206319/BACKUP/QDFTSVR submitted.
Cause . . . . . : Job
206319/BACKUP/QDFTSVR submitted to job queue QSYSNOMAX
in QSYS from job
203459/BACKUP/DSP03. Job 206319/BACKUP/QDFTSVR was started
using the Submit Job (SBMJOB)
command with the following job attributes:
JOBPTY(5) OUTPTY(5) PRTTXT()
RTGDTA(QCMDB) SYSLIBL(QSYS QSYS2
QHLPSYS QUSRSYS)
CURLIB(*CRTDFT) INLLIBL(OMS400 QGPL HD1100GP
QTEMP SQLPRO41 DBU90)
INLASPGRP(*NONE) LOG(4 00 *SECLVL)
LOGCLPGM(*YES) LOGOUTPUT(*PND)
OUTQ(/*DEV) PRTDEV(DUMMY) INQMSGRPY(*RQD)
HOLD(*NO) DATE(*SYSVAL)
SWS(00000000) MSGQ(/*NONE) CCSID(65535)
SRTSEQ(*N/*HEX) LANGID(ENU)
CNTRYID(US) JOBMSGQMX(4) JOBMSGQFL(*WRAP)
ALWMLTTHD(*YES) SPLFACN(*KEEP)
ACGCDE().
*NONE Request 11/07/12 12:15:19.693190
QWTSCSBJ *N QCMD QSYS 0195
Message . . . . : -QSYS/CALL
PGM(QSYS/QLWISEIMPL) PARM('*QLWIENDALL')
CPF1164 Completion 00 11/07/12 12:15:21.522502
QWTMCEOJ QSYS 014A *EXT *N
Message . . . . : Job
206319/BACKUP/QDFTSVR ended on 11/07/12 at 12:15:21;
.101 seconds used; end code 0 .


As you saw or inferred, JOBD(QDFTSVR) does show JOBQ(QBATCH) on it.

FWiW the context of the message CPC1221 from details provided by a
spooled
joblog including that message [a copy\paste of the first level text
from an
active joblog does not include those details], is what would be used to
provide the conclusive proof. That spooled joblog would show which
program
[named with the prefix QTOC] had issued the [effective] SBMJOB request.

CPC1221 Completion 00 11/09/12 01:00:06.715280
QWTCCSBJ QSYS 01C4 QC2SYS QSYS *STMT
To module . . . . . . . . . :
QC2SYS
To procedure . . . . . . . :
_C_NEU_system
Statement . . . . . . . . . : 35
Message . . . . : Job
210148/BACKUP/QDFTSVR submitted to job queue QBATCH in
library QGPL.

If these delays still exist as recommendations from IBM

The only worthwhile and IMO acceptable resolutions would come from
things
like notification by an [effective] event, retrieval of or sending of a
notified status enabling polling [e.g. "not done yet" messages

FWiW, ENDTCP does seem to do ENDTCPSVR *ALL, but I don't know if the
timing issues still exist that might cause a failure if not processed
separately.

I think but have no evidence other than poor memory that ENDTCP (or
possibly one of the other ENDTCP* commands?) used to issue a message like
"ENDTCP was requested but the system was unable to determine if it
completed"

Such a message is not displayed in the joblog of my job. In fact, I have
the opposite (similar on V5R4, below from V7.1):

TCP1A01 Completion 00 11/09/12 01:01:27.672786
QTOCNETCP QSYS *STMT BACKUPDLY QGPL 0082
From module . . . . . . . . :
QTOCNETCP
From procedure . . . . . . :
sendToJobLog__FPcT1iT1
Statement . . . . . . . . . : 10
Message . . . . : ENDTCP completed
successfully.
--
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.
--
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.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.