When is message IRR010I USERID .... ASSIGNED ... written?

[Tom Wasik]

The message is a RACF message that is written to the job log when the job is "verified" and RACF does userid propagation. In almost all normal modern situations that occurs during the input phase of the job. And the message ONLY occurs if the userid is propagated to the job. If you code a user and password on the job card, then there is no userid propagation and no message is issued at all.

Yes, JES2 parses the JOB card and a number of other cards during input phase processing. They are needed to not only do the validation of the job itself, but to extract things like the job class, that is used to set default for the conversion phase. This is also where it processes all JECL statements.

For the internal reader, most of the input phase processing happens in the address space submitting the job, so the IRR010I is actually being generated in the TSO users address space after the job has been submitted (the verification happens after the job is submitted).

The only odd processing for that message is code that exists to support an installation first installing a security product. If you have no security product installed (probably no longer real world) and start installing it one system at a time, then the message is issued the first phase when the job hits a system with a security product. That could be in INPUT, CONVERSION, or EXECUTION phase.

Important thing to note, not ALL jobs get a IRR010I message, so you should not depend on it always being there.

Tom Wasik
JES2 Development

[Peter Hunkeler]

Thanks a lot, Tom

So I conclude that the very first message (the one without a message id showing the date) is also written during the input phase. This message will be written even when no IRR010I is being written because of USER= to be present on the JOB statement.


Finally, and this was the main reason for asking, I conclude it is safe to say the time between the timestamp of this (these) message(s) and the timestamp of the $HASP373 was the queueing time, i.e. the time the job was waiting for an initiator to select it for execution. (Hereby neglecting the time required to do input processing, which normally should be tiny).

--
Peter Hunkeler

[Tom Wasik]

The message with the date stamp is created as part of the process of placing a message into the data set. If the prior message was written on a different day than the current message, a date record is placed into the data set before the new message. So if there is no IRR010I message, then there will be no date message.

So if there is a USER= on the JOB card, then these 3 messages are added during input phase processing:
J E S 2 J O B L O G -- S Y S T E M I B M 1 -- N O D E P O K
11.04.55 JOB00013 ---- WEDNESDAY, 09 MAR 2016 ----
11.04.55 JOB00013 IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.

If you add USER= to the job card, then this is what the data set looks like at each phase:

End of INPUT phase:
Data set does not exist

End of conversion phase:
J E S 2 J O B L O G -- S Y S T E M I B M 1 -- N O D E P O K

End of execution phase:
J E S 2 J O B L O G -- S Y S T E M I B M 1 -- N O D E P O K
11.11.16 JOB00015 ---- WEDNESDAY, 09 MAR 2016 ----
11.11.16 JOB00015 ICH70001I IBMUSER LAST ACCESS AT 11:11:15 ON WEDNESDAY, MARCH 9, 2016
11.11.16 JOB00015 $HASP373 WASIKDG STARTED - INIT 1 - CLASS A - SYS IBM1
11.11.17 JOB00015 $HASP395 WASIKDG ENDED

The ICH70001I message was added when the job went into execution.

You can play with this using TYPRUN=JCLHOLD and TYPRUN=HOLD to hold the jobs at various phases.

Tom Wasik
JES2 Development

[Peter Hunkeler]

Great! Thanks a lot, Tom


--
Peter Hunkeler