RE: New job on V7.1

["Porterfield, Sean" <SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx>]

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