Skip to main content

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

Comments

  1. valencemacdonough4 March 2022 at 07:50

    Slots Cafe - Best Casino in St. Louis
    The Slots Cafe has 구미 출장마사지 a restaurant 목포 출장마사지 located inside 경기도 출장샵 the hotel on Main Street near St. Louis. The place has 도레미시디 출장샵 everything you'd expect 부천 출장안마 from a  Rating: 3.6 · ‎24 reviews

    ReplyDelete

Post a Comment

Popular posts from this blog

Restarting a abended job in CA7

To restart the job, type xQ command to get into the CA7 Queue Maintenance. Tab down to the job you want to restart, type an 'F' beside it, and hit the Enter key. You will get into restart panel. Options for restarting the job: Resubmit for production: Resubmits the job with no changes.  Force complete: Indicates whether to flag the job as normally completed. If force complete is selected, the previous abnormal status of the job is ignored, and normal job completion processing is performed instead of a restart. CA-11 restart/rerun :Complete the following fields for a CA-11 restart/rerun: Pseudo(Optional) Indicates whether this job uses the CA WA Restart Option pseudo processing feature. Usage(Optional) Indicates an optional CA WA Restart Option usage code, the character to use in the restart/rerun. For values, see the CA WA Restart Option documentation. This option is honored only when CA WA Restart Option is in use and CA Workload Automation CA 7 Ed
Post a Comment
Read more

Control M: Zoom Screen

This section breaks down the various fields you see within a job using the Zoom command.    Many of the fields within the zoom     screen can be altered.   There a few (they will show a different color) that cannot.   To make any changes, a job must be in a HELD     state before zooming, then when in the zoom screen make the changes and type SAVE at the command line.   Remember to FREE     the job when you are satisfied with your change.   Type CANCEL instead of SAVE if you don’t want your changes to be saved. MEMNAME – schedule member name, should be same as jobname. MEMLIB – denotes where CTM will scan for jcl, standard is GENERAL, which will default to the                     predefined concatenation.   An entry of DUMMY indicates a dummy job, or one that will not execute jcl.   These                    are used as schedule placeholders.   OWNER – owner id of job. TASKTYPE – JOB – batch job, STC – started task, GRP – group entry, CYC – cyclical job o
1 comment
Read more

Control M : Commands entered against a job or task

  ? (WHY) Displays what a job is waiting on.    This shows only what a job is currently waiting on at that          time.    It will not show conditions that have already been met, and, certain requirements may change.   ex – you may check a job and it is waiting on a certain job/in-condition one minute.   you check 5 minutes          later and the in/condition may have been met, but it now is waiting on an INIT.       Also, within this screen, you can add an IN-CONDITION.   USE CAUTION when doing this.   It should     only be used when you are ABSOLUTELY SURE that you want to add this condition as it will add it for     any job on the schedule looking for it- and any other job looking for it on that day. L   (log) Displays IOA log entries for that job.   H (hold) Puts job in held status.   A job held will not change states until it is freed.   For example, if a job         is executing is held, even though the job ends, Control M will not change it’s sta
Post a Comment
Read more