Control M: IOA Log

The IOA log details activity within Control-M, Control-D, and Control-O (if it is interacting with M & D).

Fields 

DATE/TIME – Denotes system date/time event occurred.

ODATE – Denotes ODAT of job,mission,condition, etc that event was affiliated with.

USERID – Denotes owner/userid that event originated from.  Could be tso user, Control-M,D,or O, owner id of job/mission, etc.

CODE – IOA system code of event.  Can be looked up in quickref for detailed information.

MESSAGE – text of message/event.

The IOA log can be used in a very basic way – find out who/what took action on a job, such a hold, change, rerun, force ok, etc.

It can be used to see when or by who certain conditions were added.  Conditions added by jobs or missions will not show here, but those added by Control-O, a user, or other outside resource.

For jobs that fail with a NOT SUBMITTED reason, the IOA log will be where you will find the reason/error why if failed.

Similarly, when Control-D missions fail, here is where you will find the reason.

The IOA log is also a place to investigate what a job was ultimately waiting on before submitting.  While most of the time, if it was

simply waiting on a predecessor job, it can be easily determined using the NETWORK option on the AJF and checking the end time

of the pred job.  But if a job was waiting on a CONTROL (wouldn’t run against another), some type of RESOURCE, or an external condition like a dsn trigger, here’s where you can determine that.

Simply do a find on the jobname until you see the message where it says it is ELIGIBLE FOR RUN.  Then scan the messages preceeding that event.

 It will take some deduction, as there may  be unrelated messages if there is heavy activity at that time.  You will need to cautious

not to jump to the wrong conclusion, but with a little investigation, the answer will present itself.

(Take note of the time a job is ‘eligible for run’ and compare it with the time it actually submitted.  If there is a large gap between that time and the time the job is actually submitted to JES, it indicates the job was WAIT EXECUTION or waiting on something external to Control-M.   If you are investigating why a job ran later than normal, this could be the reason and you need to look for what was happening within the system (JES init shortage, system problems, etc.)