Customizing Special CA Automation Point Files › Customizing Script Files › Specifying Scripts to Use › Using Session State Scripts

Using Session State Scripts

A session state script configures a session so that CA Automation Point can control it. For example, for CA Automation Point to work properly with an MCS console, the console must be in nondelete mode, must have no display area, and its messages must have time stamps and job numbers. A session state script automatically issues the appropriate commands to put the MCS console in non-delete mode.

CA Automation Point checks the screen continuously to make sure that the session has not changed states. For example, suppose that console session S008 is currently in an MCS console and you defined this session to CA Automation Point, and the ConsoleType/State list includes IPL, MCS, PAUSE, and INIT.

The session definition causes CA Automation Point to manage this session as an MCS console. If z/OS initializes and session S008 receives the first IPL message, CA Automation Point determines that session S008 is now an IPL console and immediately begins processing messages from the session using the rules file. When the IPL progresses to the point where the session changes to an MCS console, CA Automation Point processes the script named MCS.scr. Next, it resumes processing messages from session S008 using rules defined in the rules file.

Note this additional information about session state scripts:

• The VSE state script always executes when the host console changes to the VSE state from any other state.
• The MCS state script always executes when CA Automation Point determines that an MCS console is in any mode other than non-delete mode.