Retrieving date a job(clp) entered subsystem

[Guest.Visitor]

Have you tried RTVJOBA ? It has a time variable, and the description states the date the job was assigned when it started. Keith

[Guest.Visitor]

Yes , I tried RTVJOBA , but it will give uou the date the job actually started running / executing. I set up several tests to check this and it always gave me the date the job was running , which could be - and was different in the tests that I did. I did (3) tests 1). Submit the job during the day (before midnight) do the RTVJOBA then DLYJOB till after Midnight , so that the next test wont start running until after midnight 2). Have a seconf job "stacked" after 1st test (in the same job queue) and give it an additional 5 min delay to be a few minutes after midnight when it starts running. 3). Submit a job on HOLD then release it after midnight In all but case 1. - which I expected to have todays date , the others both had the following days date - EVEN though job log shows that they all entered subsystem QBATCH on the same date , and thats the date I'm trying to get a hold of. When they went out to the subsystem (even though they didn't / hadn't ) started running yet.

[Guest.Visitor]

Yes you are correct. I forgot about that. I guess you could read the Help Systems Robot file that keeps track of submissions, completions, etc. I know we use the RBTDEP file to check reactive jobs. I don't know the name of the file you would use, but I know help systems could tell you. Keith

[B.Morris]

Try API QUSRJOBI (http://publib.boulder.ibm.com/pubs/html/as400/v5r1/ic2924/info/apis/qusrjobi.htm). It has a few dates: - Date and time job became active. When the job began to run on the system. This is blank if the job did not become active. It is in the format CYYMMDDHHMMSS - Date and time job entered system. When the job was placed on the system, in the CYYMMDDHHMMSS format - Date and time job is scheduled to run. Date and time the job is scheduled to become active. This field is returned as hexadecimal zeroes if the job is not a scheduled job. The format for this field is the system time-stamp format. - Date and time job was put on this job queue. This is the date and time this job was put on this job queue. It is in system timestamp format. This field will contain blanks if the job was not on a job queue. Maybe one of these will be what you want. By the way, for the "system timestamp format" dates, I think you can use QWCCVTDT to convert them to CYYMMDDHHMMSS, saying that the input format is *DTS.

[nycsusan@hotmail.com]

One technique to trigger special processing would be to submit the job with a parm. For example, we had an abbreviated batch on Saturday nights, and that run would be submitted with a "Y" parm to indicate a mini-batch. The other 6 days an "N" was sent. The CL did or did not do certain steps based on that flag. That's probably not the answer you were looking for, but it's an alternative that's really quite easy to implement. Plus, if for some reason you need to re-run that "special" processing (for production support purposes or for testing), it's quite straightforward. P.S. I am surprised that RTVJOBA didn't work!

[Guest.Visitor]

Thanks for pointing me to the web page with all of the API info. I"ve been in this business almost 15 years - and never used them !!!!!. Anyway , the (small) problem that I have is that when I used QUSRJOBI API in an ILE/RPG program where after returning from the call , the only thing that I do is manipulate the date entered system from CYYMMDDHHMMSS format to ISO YYYYMMDD and move it to a field that is part of the *LDA defined as UDS in the pgm so it will be brought in at the beginning.written out at the end after I manipulate the value returned from the API. When the program ends ( I set on LR) and running the pgm interactively the LDA has NO value in the field that I moved it into !!!!!! even though just before the stmt that turns on LR the value shows correctly(in de-bug) I have checked in de-bug and also have PSSR coded as well as the error paramater (various versions tried - 0 bytes, 16 bytes, xxx bytes to try to retieve any errors - and everything comes up clean . NO ERRORS found - but yet the LDA positions have not been changed. I changed the pgm to pass in/out an 8 digit *char variable using *ENTRY plist , and let the pgm move factor2 (the field I manipulated) to the result field - which is the value being passed in/out, and this works fine. This has me even more confused because if LR is on , and the pgm can "resolve" move factor 2 to the result field - why did the LDA N O T get updated correctly at LR time . I"m stumped !!! and even though I have a workable solution I want to know why the original update to the LDA never worked correctly, or what possibly I can check on my end. We are at release lvl V4R4M0. Thanks, for any suggestions, and remember I am new to API's.

[Guest.Visitor]

Try calling the API in your CL program. Example: PGM DCL VAR(&RCV) TYPE(*CHAR) LEN(75) DCL VAR(&RCVLEN) TYPE(*CHAR) LEN(4) DCL VAR(&SBMDATE) TYPE(*CHAR) LEN(13) CHGVAR VAR(%BIN(&RCVLEN)) VALUE(75) CALL PGM(QUSRJOBI) PARM(&RCV &RCVLEN 'JOBI0400' + '*' ' ') CHGVAR VAR(&SBMDATE) VALUE(%SST(&RCV 63 13)) ENDPGM

[B.Morris]

Are you sure your UDS is defined as the *LDA? Try doing a DSPPGMREF on your program and see what data area it's using (there should be a star in front of LDA). Maybe you coded LDA instead of *LDA. In that case, RPG would use any existing LDA data area, or if it didn't exist already, it would create a data area QTEMP/LDA. (It sounds like you're using the API just fine.)

[Guest.Visitor]

Thanks, guys for the input - still cant seem to get results out of the LDA, and still don't know why !! ?? !!. Anyway , the clp thing also worked , so now I have even another possible solution but I still wish that I knew why the RPGLE pgm isn't working(unless like I said I pass parms in and out). If interested , below is the pgm - the PSSR was just coded to see if any weird errors were occuring while calling the pgm interactively. When using the API call it would be inside a submitted job and I would modify the below sample pgm accordingly.Also I retrive *date so I have date of execution(outside of API return values) AND date actually entered subsystem - if I need to compare the two. 0017.00 DLOCAL UDS DTAARA(*LDA) 0018.00 D STAR_DATE 1001 1008 0019.00 D ENT8LDA 1010 1017 0020.00 * 0021.00 D PSDS SDS 0022.00 DSTATUS *STATUS 0023.00 DPGMNAM 1 10 0024.00 DMSGID 40 46 0025.00 DMSGTXT 91 170 0026.00 DJOBNAM 244 253 0027.00 DUSRPRF 254 263 0028.00 DJOBNBR 264 269 0 0029.00 * 0030.00 D REC S 88 0031.00 D RECLEN S 4B 0 INZ(88) 0032.00 D FORMAT S 8 INZ('JOBI0400') 0033.00 D QUAL_JOB S 26 DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++ D INT_JOB S 16 * DRECOUT DS D BYTES_RET 4B 0 OVERLAY(RECOUT:1) D BYTES_AVAIL 4B 0 OVERLAY(RECOUT:5) D JOB_NAME 10 OVERLAY(RECOUT:9) D USER_NAME 10 OVERLAY(RECOUT:19) D JOB_NBR 6 OVERLAY(RECOUT:29) D INT_JOBID 16 OVERLAY(RECOUT:35) D JOB_STATUS 10 OVERLAY(RECOUT:51) D JOB_TYPE 1 OVERLAY(RECOUT:61) D JOB_SUBTYP 1 OVERLAY(RECOUT:62) D ENT_SYS 13 OVERLAY(RECOUT:63) D ENT_DATE 6 OVERLAY(RECOUT:64) D BECAME_ACT 13 OVERLAY(RECOUT:76) * DWRK_ISO S D DATFMT(*ISO) * C EVAL QUAL_JOB = '*' * C CALL 'QUSRJOBI' C PARM REC C PARM RECLEN C PARM FORMAT C PARM QUAL_JOB C PARM INT_JOB * C MOVEL REC RECOUT * C MOVEL ENT_DATE DATEYMD 6 0 C *YMD MOVE DATEYMD WRK_ISO C *ISO MOVE WRK_ISO DATEYYMD 8 0 C MOVEL DATEYYMD ENT8LDA * C EVAL *INLR = *ON * ************ * PSSR - EXCEPTION HANDLER ************ CSR *PSSR BEGSR * C IF STATUS <> 0 C STATUS DSPLY C ENDIF * C ENDSR * ************ * INZSR - INITIALIZATION ************ CSR *INZSR BEGSR t F4=Prompt F5=Refresh F9=Retrieve F10=C * C TIME TIM 6 0 * C MOVE *DATE DATE80 8 0 C MOVEL DATE80 STAR_DATE * CSR ENDSR At the end , when pgm completes LDA pos 1001-1008 and 1010-1017 are blank. Just thought that I would re-state the problem at the end. Also in debug if I do an EVAL of LOCAL structure both STAR_DATE and ENT8LDA have values just prior to turning on LR- stumped , but at least now I have some possible work arounds.Also I am not using any binding directory and am using the default activation group. Thanks all for helping - and sorry I didn't respond sooner.

[B.Morris]

The only thing I can think of that would cause this behaviour is that your program is called by another program that also has a *LDA data area coded. When that program ends, it overwrites whatever the called program did. Hmm, there are some errors in your program that could cause storage to get corrupted. The problem is that you've defined your API BINARY(4) fields and subfields as 4B. You should define them as 9B, or better 10i. Your 4B fields are 2-byte binary fields (BINARY(2)). The API assumes they are 4 bytes long, so if you set say your RECLEN field to 88, it will have the value X'0058'. The next 2 bytes are who-knows-where. Let's say they have a value of x'0000'. The API thinks the reclen is x'00580000', which is way way more than 88 (5767168); the API is free to change that much data, starting from the beginning of your structure. Ah, I think I've figured out why the data area is not getting written out. The call to the API will likely corrupt "some" data somewhere in your program. What's probably getting corrupted is the internal structures that control the data areas. I think changing your 4B's to 10i's will fix everything up.

[Guest.Visitor]

Cool , thanks for the help Barbara , and all - I can"t believe that I got sloppy with the binary definitions. Oh well I don't work with binary results or calcs too often (no excuse) but once I made the change the pgm worked correctly. Thanks , again - now I know that when I work with API's in the future I"ll know a little bit more about how they work. I still have to play with the list API's cuss I haven"t used user spaces at all yet.

[Guest.Visitor]

I have a job running off a 3rd part software scheduler (ROBOT) , where inside of the clp I need to know when the job was submitted - not when it is running. For example if you look at the job log it will tell you Job XXX entered subsystem QBATCH on date/time , Job started on date/time. I need to know that a job entered subsystem QBATCH on friday to do special end of week processing. The job is scheduled to run at 10 PM , but recently another job in the queue (single threaded) got stuck , so my job didn't start running until SATURDAY. So when I retieved the sys value day of week (*FRI,*SAT, etc) it correctly told me that it was *SAT and all of the special week end processing that should only run on FRIDAY was skipped. Any suggestions ???? Don't think it would matter if the IBM Scheduler , or ROBOT is scheduling the job. The problem is that the job did not / does not become active until after midnight even though it entered the subsytem correctly (which the job log shows you as Friday at 10 PM)

[Guest.Visitor]

Glad that you got that to work. For some API examples, you might check out the iSeries-tookit (http://iseries-toolkit.sourceforge.net). There is a retreive jobq date procedure in a module (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/iseries-toolkit/CVSROOT/src/qrpglesrc/rtvjobinf.irp?rev=HEAD&content-type=text/vnd.viewcvs-markup) that I added last week. It is still not part of the download though. There is also a lot of support for user spaces (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/iseries-toolkit/CVSROOT/src/qrpglesrc/usrspc.irp?rev=HEAD&content-type=text/vnd.viewcvs-markup) and other APIs, with more added every week. David Morris