IOA Utilities

Some utilities prefixed by IOA replace corresponding utilities prefixed by CTM in previous versions. In such cases, the old utilities are supported for your convenience; however, you should use the IOA utilities.

IOABLCAL – Build Calendars

The scheduling of jobs, missions and rules in the IOA environment is frequently based on calendars. A data center can use different calendars for different scheduling requirements.

Table 15 Scheduling Calendars

In many cases, a calendar is related to, or derived from, another calendar or a combination of two other calendars. For example, in the calendars listed above, calendar NOTEOFMN can be derived from a combination of the WORKDAYS and ENDOFMON calendars.

When calendars are related, a change to one calendar frequently affects other calendars. This can make manual maintenance of calendars time consuming and error prone. The IOABLCAL utility simplifies and automates calendar maintenance.

Through parameters supplied to the utility, the user specifies two existing calendars and the operation (or formula) that determines how the calendars are combined to build a new calendar.

The new calendar created by the utility is a regular calendar. It can be viewed using Option 8 (Calendars) of the IOA Primary Option menu and it can be used as an input calendar in subsequent runs of the utility. Thus, using several basic calendars, numerous other calendars can be created.

It is recommended that all steps that calculate calendars be collected into one job, and that the job be run once a day. This refreshes the calendars in the event that changes are made to the basic calendars.

IOABLCAL Parameters

Parameters are supplied to the utility either using DD statement DABCLIN (or SYSIN) or using PARM. You can specify any number of parameter statements. The parameter statement syntax is

calendar1 operator calendar2=calendar3

where

Table 16 IOABLCAL parameters

If the operation is +, calendar3 contains all days scheduled in calendar1 and additionally all days scheduled in calendar2.

If the operation is –, calendar3 contains all days scheduled in calendar1 excluding those days scheduled in calendar2.

If the operation is *, calendar3 contains all days scheduled in calendar1 that are also scheduled in calendar2. The day has to be marked for execution in both calendars in order to be marked for execution in calendar3.

If calendar2 is a relative calendar, additional logic is required to handle the * operation mentioned above. (A relative calendar is a calendar that contains days marked + or - instead of, or in addition to, days scheduled or not scheduled.) Each day in calendar2 that contains a + or – sign is checked against the same day in calendar1. If the day is marked for execution in calendar1, it is marked for execution in calendar3. However, if the day is not marked for execution in calendar1, the result depends on how the day was marked in calendar2:

• If the day was marked + in calendar2, the closest next day marked for execution in calendar1 is marked for execution in calendar3.

• If the day was marked – in calendar2, the closest previous day marked for execution in calendar1 is marked for execution in calendar3.

Operations <W nn and >W nn create a new calendar (calendar3) by shifting the days in an old calendar (calendar1) a specified number of working days according to the specified workdays calendar (calendar2):

• Symbol < indicates that days are shifted to the left (meaning, to preceding days).

• Symbol > indicates that days are shifted to the right (meaning, to subsequent days).

• The number of working days to shift is nn.

The logic for operations <W nn and >W nn is as follows:

• Each day marked for execution in calendar1 is checked against calendar2.

  • If the same day is a working day in calendar2, nn working days in calendar2 are counted in the direction of the shift and the resulting day is marked as a working day in calendar3.

  • If the same day is not a working day in calendar2, the closest working day in the direction of the shift is identified in calendar2. From that working day, nn working days in calendar2 are counted in the direction of the shift and the resulting day is marked as a working day in calendar3.

• If operation <>W or ><W is specified, then for each working day (meaning, day marked for execution) in calendar1

  • If the same day is a working day in calendar2, it is marked as a working day in calendar3.

  • If the same day is not a working day in calendar2, the closest working day (in either direction) is marked as a working day in calendar3.

  • If two working days are equally close (meaning, the same number of days before and after), the day selected depends on the parameter specified:

    • If <>W was specified, the earlier working day is selected as the working day for calendar3.

    • If ><W was specified, the later working day is selected as the working day for calendar3.

Activating the IOABLCAL Utility

// EXEC IOABLCAL
calendar1 operator calendar2 = calendar3

where operator is +, –, *, <W nn, >W nn, <>W or ><W

IOABLCAL Return Codes

Table 17 IOABLCAL Return Codes

Examples for IOABLCAL

calendar1 * calendar2 = calendar3

 S ----------- S ----------- S -------
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9         calendar1
 Y Y Y Y Y   Y Y Y Y Y Y           Y
 S ----------- S ----------- S -------

 S ----------- S ----------- S -------
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9         calendar2
 Y Y + -   +             +   -
 S ----------- S ----------- S -------

 S ----------- S ----------- S -------
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9         calendar3
 Y Y Y Y     Y         Y           Y
 S ----------- S ----------- S -------

OLDCAL <W 2 WORKDAYS = NEWCAL

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
         Y         Y Y Y     Y               OLDCAL
 S - - - - - - S - - - - - - S - - - -

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
     Y Y Y Y Y     Y Y Y Y     Y Y               WORKDAYS
 S - - - - - - S - - - - - - S - - - -

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
     Y     Y Y     Y Y                           NEWCAL
 S - - - - - - S - - - - - - S - - - -

OLDCAL ><W   WORKDAYS = NEWCAL

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
         Y     Y Y     Y     Y               OLDCAL
 S - - - - - - S - - - - - - S - - - -

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
 Y Y Y Y Y   Y     Y Y Y Y       Y               WORKDAYS
 S - - - - - - S - - - - - - S - - - -

 S - - - - - - S - - - - - - S - - - -
 1 2 3 4 5 6 7 8 9 + 1 2 3 4 5 6 7 8 9
         Y   Y     Y   Y         Y           NEWCAL
 S - - - - - - S - - - - - - S - - - -

IOACABPR – Emergency CAB Control Block Disconnect

The IOACABPR utility forces a disconnect of the CAB control block, a cross-product control block used to anchor information. The CAB control block is anchored indirectly from the MVS CVT, at offset x’AC’ of the customer table.

The utility can be activated using job IOACABJ located in the IOAprefix.INSTALL library. The IOACABPR utility procedure is located in the IOAprefix.PROCLIB library.

Activating the IOACABPR Utility (and Example)

//CABSTEP EXEC IOACABPR,FUNC=DISC

IOACABPR Return Codes

Table 18 IOACABPR Return Codes

IOACCDSL – Data Set Listing tool

• The Data Set Listing tool (IOACCDSL) can be used to perform the following tasks on an IOA environment:

  Cloning an environment (For more information about the cloning process, see the INCONTROL for z/OS Installation Guide: Installing.)

• Backing up an environment

For both these tasks, the Data Sets Listing tool produces a complete list of all data sets of the specified IOA environment in a plain-text format.

Activating the IOACCDSL utility

The Data Sets Listing tool is activated from ICE, using the Cloning, Change Deployment, and Maintenance options. These are accessible by appropriately selecting either the Clone, Deploy IOA Environment or the Maintain your Environment option from the main ICE screen.

IOACCDSL Return Codes

Table 19 IOACCDSL Return Codes

IOACCND – Copy or Resize IOA Conditions File

This utility copies the contents of the IOA Conditions file to another file that may or may not be the same size or version.

To change the size of the IOA Conditions perform the following steps:

1. Enter ICE and select Customization.

2. Select Environment for Processing.

3. In the Customization screen, set Product ID to IOA and select Product Customization.

4. Select major step 2 "Customize IOA Dataset Parameters."

5. Select minor step 3 "Conditions File(s) Parameters."

6. Change the parameter values.

7. Perform step "Save Parameters into Product Libraries."

8. Perform step "Format IOA Conditions File."

9. Run the IOACCND utility. The utility copies the current IOA Conditions to the new file.

IOACCND Parameters and DDNAMEs

Table 20 IOACCND Parameters

For details, see sample job IOACCND in the IOA JCL library.

Activating the IOACCND Utility (Example)

Figure 1 IOACCND – Example

// EXEC PGM=IOACPC,PARM=’MODE=COPY’
// OLDCND=’IOA.old.CND’, OLD CONDITIONS FILE
// NEWCND=’IOA.new.CND’, NEW CONDITIONS FILE

IOACCND Return Codes

Table 21 IOACCND Return Codes

Resizing ALTCND

The copy function of the IOACCND utility can be used to resize ALTCND, the IOA mirror condition file.

IOACCRNM – Renaming tool

The Renaming tool (IOACCRNM) can be used to perform the following tasks in the cloned environment:

• adjustment of an IOA environment to new values of parameters

• optional allocation of missing user data sets

Activating the IOACCRNM utility

You can run IOACCRNM in either of the following ways:

• From the TSO command line:

  Copy

  EXEC 'basepref.INSTALL(IOACCRNM)' 'ENVID(ENVID1) MODE(FULL)'

• By submitting the IOARNM job from the IOA JCL library.

The messages of the utility are sent to the ilprefa.ICELOG data set and, when the utility is invoked from a job, to a data set allocated to the DD SYSTSPRT.

The preferred way for running the Renaming tool is by using the IOARNM sample job located in the ilprefa.JCL.

IOACCRNM Input

The Renaming tool processes the internal ICE data of the specified IOA environment. The IOA environment is specified with the ENVID parameter. In addition, the tool requires the following inputs:

• the basepref.RNM sequential file with the renaming definitions - The user can copy the content of the IOACDRNM member produced by the Data Set Listing tool (see IOACCDSL – Data Set Listing tool) to basepref.RNM and rename the prefixes and parameters appropriately. For a list of the prefixes, see Table 23 List of the prefixes in basepref.RNM that are handled both by the DFDSS utility and by the Renaming tool. For a list of the parameters, see Table 22 IOACCRNM Parameters. When entering the parameters in the basepref.RNM member, the dash, "-", must be in column 71.

• the IOACDDSL member with the list of the data sets in the cloned IOA environment - Running the Data Sets Listing tool generates IOACDDSL. If the Renaming tool is invoked in the standalone mode (without running Data Sets Listing tool), the user can create the IOACDDSL member.

IOACCRNM Parameters

Table 22 IOACCRNM Parameters

When the tool is invoked from the ilprefa.JCL(IOARNM) sample job, the value of IOA installation libraries prefix must be specified in the job with the ILPREFA parameter.

Table 23 List of the prefixes in basepref.RNM that are handled both by the DFDSS utility and by the Renaming tool

Table 24 List of the parameters in basepref.RNM that are handled by the Renaming tool

IOACCRNM Output

The Renaming tool adjusts all copied libraries and information saved in these libraries to the new file names and parameters values. In addition, it allocates the files required for the products using the new names.

In addition, it produces a list of all post-cloning activities that the user should perform manually.

IOACCRNM Return Codes

Table 25 IOACCRNM Return Codes

IOACLB – Produce XML Calendar Files

The IOACLB utility provides a method of converting Control-M for z/OS calendar definitions to Control-M calendar definitions. The IOACLB utility exports one or more Control-M for z/OS calendar libraries, or selected members in the libraries, to an XML file. The XML file is used as a mass input to the defcal Control-M utility for importing the calendar definitions to a specified Control-M/Server.

IOACLB Parameters

The IOACLB utility accepts the following input control statements (as 80-byte card images) in the DAINCLB file:

Figure 2 DAINCLB file - input control statements for IOACB

* comment
DATACENTER=data-center-name-1
CALENDAR-LIB=library-name1
CAL=calendar-n*m?1
CAL=calendar-nam?2
DATACENTER=data-center-name-2
CALENDAR-LIB=library-name2
CAL=calendar-name3

Pass-through parameter

DATACENTER is the name of the Control-M/Server and is a mandatory pass-through parameter to the defcal utility that can be specified for a particular calendar. For more information, see the section about the defcal Control-M utility in the Control-M Utility Guide.

Action parameters

• Multiple sets of CALENDAR-LIB and CAL statements are permitted.

• CALENDAR-LIB and CAL statements refer to the library and member names of the Control-M for z/OS calendar or Rule-Based calendar library that the IOACLB utility is converting. At least one CAL statement for each CALENDAR-LIB statement is required.

• Masking, using ? and * wildcards, in the CAL parameter is permitted.

• Comment statements begin with an asterisk (*) in the first column of the line.

Calendar types

IOACLB supports the following calendar types:

• Regular (days marked with Y, N or blank)

• Periodic (days marked with a period indicator)

• Relative (days marked with Y, N, +, - or blank)

  For more information, see IOABLCAL – Build Calendars.

• RBC - Rule-Based calendars (For more information, see the Control-M User Guide). The Control-M CTMTLB utility is invoked to create the XML file for RBCs.

OUTPUT file

The IOACLB utility produces the CALXML output file. The CALXML file contains statements in XML format that are suitable as input to the defcal Control-M utility. The file must have the following attributes: RECFM=FB, LRECL=4095. These statements are in standard EBCDIC format, which must be transformed to ASCII format before being used as input to the defcal utility. When transforming the file from EBCDIC to ASCII, do not specify the CRLF (Carriage Return and Line Feed) file option.

Activating the IOACLB Utility

A sample job to activate the utility can be found in the IOACLB member in the IOA JCL library. The DD statements used by the CTMTLB utility are also required when processing Rule-Based calendar libraries.

IOACLB Return Codes

Table 26 IOACLCND Return Codes

Example for IOACLB

//DAINCLB DD *
DATACENTER=CTM-DS-Local
CALENDAR-LIB=IOA.CALENDAR.LIB
CAL=CALDEF
DATACENTER=CTM-DS-Unix
CALENDAR-LIB=IOA.CALENDAR.LIB
CAL=CALDEF
/*

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE DEFCAL SYSTEM "DEFCAL.DTD">
<DEFCAL>
<CALENDAR
DATACENTER="CTM-DS-Local "
NAME="CALDEF"
TYPE="Regular">
<YEAR
NAME="2010"
DAYS="YYYYYYYYYYYYYYYYYYNYYYYYYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYNNNYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
YYYYNNYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYNYYYYYYYYYYYYYY
YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYNNNY
YYYYYYYYYYYYYYYYYYYY"
DESCRIPTION="Calendar for 2010."/>
</CALENDAR>
</DEFCAL>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE DEFCAL SYSTEM "DEFCAL.DTD">
<DEFCAL>
<RULE_BASED_CALENDAR
DATACENTER="CTM-DS-Local "
NAME="RULECAL"
DAYS="1"
DAYS_AND_OR="AND"
WEEKDAYS="5"
DAYSCAL="CALDEF"
MAXWAIT="05"
JAN="1" />
</DEFCAL>

IOACLCND – Clean the IOA Conditions File

This utility cleans the IOA Conditions file of conditions that are no longer required. It is recommended that this utility be activated as part of IOA maintenance.

IOACLCND Parameters

Unless the utility is instructed otherwise using parameters, it deletes all prerequisite conditions (except those whose date reference is STAT) in the IOA Conditions file.

The utility outputs a list of all the deleted prerequisite conditions.

Prerequisite conditions that must not be deleted (for example, prerequisite conditions needed throughout the year) are specified by means of control statements, that are specified using DD statement DACRSIN or SYSIN. The formats of these statements are displayed below, followed by explanations:

IGNORE statements instruct the utility not to delete the indicated prerequisite conditions, as follows:

• An IGNORE COND statement instructs the utility not to delete the indicated prerequisite condition under any circumstances.

• An IGNORE CONDIN statement instructs the utility not to delete the indicated prerequisite conditions if the utility determines that the prerequisite conditions are referenced conditions. A referenced condition is a prerequisite condition appearing in the IOA Conditions file at the same time that it appears as an IN condition in an active job, mission or rule (for example, one that is currently present in the Active Jobs file or Active Missions file).

Conversely, SELECT {COND|CONDIN} statements instruct the utility to delete the prerequisite conditions specified. A customer who wants to delete only those statements specified in the SELECT COND statement should specify IGNORE COND * as the last statement.

IGNORE and SELECT statements can contain the following values:

• cond-prefix specifies the prefix of prerequisite conditions. An asterisk indicates all prerequisite conditions.

• If a FROM or TO combination is supplied, the specified condition is processed by the SELECT/IGNORE statement only if its date is in the date range.

• date can be either a specific date in the site defined standard (mmddyy, ddmmyy or yymmdd) or a relative date. A relative date is specified in the format -n, where n is the number of days before the current date (for example, -5 means five days before the current date). Relative and specific dates can be mixed (for example, a specific FROM date and a relative TO date).

When a FROM and/or TO date is not specified, the current date is the default for the unspecified date. The TO date (regardless of whether specific, relative or assumed) cannot precede the FROM date.

CONTROLM and CONTROLD statements indicate whether the utility checks prerequisite conditions in the Active Jobs file and/or the Active Missions file, respectively, if a CONDIN-type condition statement is specified. By default, each of these files is checked if its respective product is installed (according to IOA installation options). These statements can be used to override the default. You can specify either, both or neither of these statements.

These statements can impact the result of a CONDIN-type condition statement because the utility cannot determine that a prerequisite condition is referenced unless it can check the Active Jobs or Missions file for the job or mission containing the IN prerequisite condition.

Valid values for these statements are described below:

Table 27 Control-M and Control-D Statements

The utility can be run simultaneously with the Control-M and the Control-D monitors.

If the job is submitted under Control-M, AutoEdit variables are supported.

Activating the IOACLCND Utility

// EXEC IOACLCND

Specifying AutoEdit Variables and Functions

AutoEdit variables can be specified for any of the above parameters. These variables are especially useful for specifying relative date ranges in the FROM and TO parameters.

AutoEdit functions can be used to set variables and these variables can then be used in the parameters of the utility. The lines in which the variables are set must have an asterisk (*) in the first column of the line. Such lines are resolved by the AutoEdit facility and are interpreted as comments by the utility. Regular comments can also be specified in lines with an asterisk in the first column.

IOACLCND Return Codes

Table 28 IOACLCND Return Codes

Examples for IOACLCND

// EXEC   IOACLCND
 IGNORE COND * FROM -10 TO %%RMONTH.%%RDAY.%%RYEAR
 IGNORE COND CICS
 IGNORE COND DB-

// EXEC   IOACLCND
 IGNORE CONDIN * CONTROLD NO
 IGNORE COND CICS

IOACLVL – Compare Levels

This service compares the level of modules in two IOA load libraries allocated to the DD name STEPLIB. The level information is retrieved using the IDL facility. For more information about the identity level facility, see the INCONTROL for z/OS Administrator Guide. The IOACLVL utility consists of the IOACLVLG and IOACLVLC jobs.

Activating the IOACLVL utility

The IOACLVLG job collects the level information on two compared systems and must be executed twice, once on the production system and once on the test system. The reports produced by the IOACLVLG job on the compared systems are used as the input by the IOACLVLC job, which compares the level information of the two systems and produces the final report. The report includes detailed information about the differences between the compared systems, as shown in the example on IOACLVLC job. The IOACLVLG and IOACLVLC jobs must be customized before they are used, using the variables described in Table 29 and Table 30:

Table 29 IOACLVLG variables

Table 30 IOACLVLC variables

IOACLVL Return Codes

Table 31 IOACLVL return codes

Examples for IOACLVL

//IOACLVLG JOB IOA700,&SYSUID,NOTIFY=&SYSUID//*
//*
//*********************************************************************
//*                                                                    
//* THE JOB COLLECTS THE LEVEL INFORMATION OF ALL LOAD MODULES LOCATED 
//* IN THE STEPLIB DEFINED BY THE INSTALLATION (IN THE MEMBER 'IOASET').
//* THE JOB MUST BE SUBMITTED ON TWO COMPARED SYSTEMS IN ORDER TO GENE-
//* RATE TWO REPORTS - ONE PER SYSTEM.                                 
//* THE RESULTING REPORT WILL BE USED AS ONE OF TWO INPUT REPORTS BY   
//* THE JOB 'IOACLVLC' IN ORDER TO COMPARE THE LEVEL INFORMATION OF TWO
//* INSTALLATIONS.                                                     
//*                                                                    
//* THE CUSTOMIZATION AREA VARIABLES MUST BE CUSTOMIZED AS FOLLOWS:    
//*     'RESDSN' -   DEFINES THE NAME OF THE DATA SET THAT STORES THE  
//*                  RESULTING REPORT                                  
//*     'INSTID'   - DEFINES UP TO 8 CHARACTER IDENTIFICATOR OF THE    
//*                  INSTALLATION - USED TO DISTINGUISH BETWEEN THE    
//*                  REPORTS GENERATED BY THIS JOB ON DIFFERENT SYSTEMS
//*                  (FOR EXAMPLE 'TEST' OR 'PROD')                    
//*                                                                    
//*======  START OF THE CUSTOMIZATION AREA  ===========================
//*                                                                    
//         SET INSTID=TEST                   ID OF THE INSTALLATION -  
//*                                          UP TO 8 CHARACTERS        
//*                                          (TEST OR PROD)            
//         SET RESDSN=&SYSUID..IOACLVL.RES1  RESULTS DATA SET NAME     
//*                                                                    
//*======  END OF THE CUSTOMIZATION AREA    ===========================
//*                                                                    
//         JCLLIB  ORDER=IOAP.V700.PROCLIB                             
//         INCLUDE MEMBER=IOASET                                       
//*                                                                    
//*--------------------------------------------------------------------
//*        GET THE LEVEL INFORMATION OF THE TEST LOAD DATA SET         
//IOAGLVL  EXEC PROC=IOACLVLG,SETID=&INSTID,OUTDSN=&RESDSN             
//                                                                      

//IOACLVLC JOB IOA700,&SYSUID,NOTIFY=&SYSUID
//*
//*
//*********************************************************************
//*                                                                    
//* THE JOB COMPARES BETWEEN TWO REPORTS GENERATED BY THE JOB 'IOACLVLG'
//* IN ORDER TO FIND THE DIFFERENCES BETWEEN TWO INSTALLATIONS OF IOA. 
//*                                                                    
//* THE CUSTOMIZATION AREA VARIABLES MUST BE CUSTOMIZED AS FOLLOWS:    
//*                                                                    
//*        'RESDSN' - THE VARIABLE DEFINES THE DSNAME OF THE RESULTING 
//*                   REPORT                                           
//*        'INDSN1' - THE VARIABLE DEFINES THE DSNAME OF THE REPORT THAT
//*                   GENERATED BY THE JOB 'IOACLVLG' ON THE FIRST     
//*                   INSTALLATION TO BE COMPARED                      
//*        'INDSN2' - THE VARIABLE DEFINES THE DSNAME OF THE REPORT THAT
//*                   GENERATED BY THE JOB 'IOACLVLG' ON THE SECOND    
//*                   INSTALLATION TO BE COMPARED                      
//*                                                                    
//*********************************************************************
//*                                                                    
//*======  START OF THE CUSTOMIZATION AREA  ===========================
//*                                                                    
//         SET RESDSN=&SYSUID..IOACLVL.RES   RESULTS DATA SET NAME     
//         SET INDSN1=&SYSUID..IOACLVL.RES1  LEVEL INFO OF 1ST DATA SET
//         SET INDSN2=&SYSUID..IOACLVL.RES2  LEVEL INFO OF 2ND DATA SET
//*                                                                    
//*======  END OF THE CUSTOMIZATION AREA    ===========================
//*                                                                    
//         JCLLIB  ORDER=IOAP.V700.PROCLIB                             
//         INCLUDE MEMBER=IOASET                                       
//*                                                                    
//*--------------------------------------------------------------------
//*        COMPARE THE LEVEL INFORMATION OF THE LOAD DATA SETS         
//IOACMPRL EXEC PROC=IOACLVLC,OUTDSN=&RESDSN,IN1=&INDSN1,IN2=&INDSN2   
//

CLIENT   ECANCMP$ 6.1.00 II0959 IOAR630  PROD
CTBABF#  CTBABF#  6.1.07 BB0873 IOAR630  PROD
CTBABF#  CTBABF#  6.3.00 IOA700 IOAR700  TEST
CTBABF#  CTMXAGR  6.3.00 IOA700 IOAR700  TEST
CTBABI   CTMXAGR  6.3.00 IOA700 IOAR700  TEST
CTBBAO   CTBINP   6.3.00 IOA700 IOAR700  TEST
CTBBAO   CTBSE01  6.3.00        IOAR700  TEST
CTBBAO   CTMCMPXA 6.2.00 IM0971 IOAR630  PROD
CTBBAO   CTMCMPXA 6.3.00 IOA700 IOAR700  TEST
CTBBAO   CTMDSS   6.2.00 BM5699 IOAR630  PROD
CTBBAO   CTMDSS   6.3.00 IOA700 IOAR700  TEST
CTBBAO   CTMDTM   6.2.00 BM5401 IOAR630  PROD
CTBBAO   CTMDTM   6.3.00 IOA700 IOAR700  TEST
CTBBAO   CTMRSV   6.3.00 IOA700 IOAR700  TEST
. . .

IOACMPP – Compare IOA Parameter Files at Different Installations

The purpose of the IOACMPP utility is to compare the parameters of two different members that are in different IOA or INCONTROL libraries.

To avoid executing the utility multiple times for different members, the IOACMPP utility supports comparison of two entire libraries when names of the members are identical.

Structure of the parameter’s member

Each record in the parameter member contains the following information:

Label        Parameter name=Parameter value        Note

Table 32 Parameter's member structure and description

*        Monitor Parameters:                       *             
MONITOR  INTERVLM=0300,        CTM Monitor Interval (0010-9999). 
         NONSWAPM=Y,           Run Monitor as Non-Swappable (Y/N).

Activating the IOACMPP utility

You can run the IOACMPP utility in either of the following ways:

• From command line.

  Results are displayed in the ISPF panel.

• By submitting a job.

  A sample job can be found in the IOACMPPJ member in the IOA.V700.SAMPLE library.

IOACMPP Usage

The IOACMPP utility examines the following items in sequence to compare the two parameter’s members:

• Label – whether the label exists in both members

• Parameter name—if the label is the same, the utility compares the names of the parameters

• Parameter value – if the parameter name is the same, the utility compares the values of the parameters

Notes that begin with an asterisk and notes at the end of the record are ignored during the comparison of the parameters.

The order of the parameters in the label and the order of the labels in the member are not significant.

IOACMPP Components

The IOACMPP utility contains the following parts:

IOACMPP Input

The order of the input information is significant.

Table 33 IOACMPP input

IOACMPP Return codes

Table 34 IOACMPP return codes

Results of IOACMPP

Depending on how the utility ran, one of the following occurs:

• ISPF panel in TSO is displayed, through a temporary table. (Press PF1 in the output panel to display explanations of the messages).

• A report is printed in the DD SYSTSPRT job.

In both cases, the following information is displayed:

• static information

  • name of the first library

  • name of the second library

  • number of members found

  • name of the displayed member

• dynamic information (in the same row)

  • label name

  • parameter name

  • parameter value

  • messages

IOACMPP output analysis

The output of the IOACMPP utility with each record in the parameter member containing the following information:

Label        Parameter name=Parameter value        message

Table 35 IOACMPP output messages when ISPF panel in TSO is displayed

Table 36 IOACMPP output messages when report is printed in DD SYSTSPRT

Examples for IOACMPP

EXEC 'IOA.V700.CLIST(IOACMPP)' 'IOAP.V700.PARM * IOAP.V630.PARM’

==>                                                           Row 351 of 2345
                                                                              
     THIS IS THE RESULT OF THE COMPARISON OF THE MEMBERS
                    Press PF1 for description of the Messages
 The First  Library is: IOAP.V700.PARM
 The Second Library is: IOAP.V630.PARM                                        
                                               Number of Members found: 21    
 Label   Parameter                                        Message 
==>CTMPARM at Different Libraries:   
----------------------------------- 
MONITOR  INTERVLM=300  
         NONSWAPM=Y             
         CTMPLEX=Y                     
         HLDCLAS=X,                                       ParmNotInc 
         PRTCLAS=X         
         AUTOTAPE=Y,                                      ParmNotInc 
         CMEMREQ#=20 
         FORCE#RT=6,                                      ParmNotInc 
         FORCE#WI=0                                       DiffValues1
                 =1                                       DiffValues2 
         MAXJBHLD=0                                       DiffValues1
                 =10                                      DiffValues2
CKP      AJFSIZE=10000  
         AJFTHRSH=90     
         HIST=Y           
         JRNL=Y             
         REUSTIME=1              
         REUSAPPL=K27                                     DiffValues1  
                 =NOA                                     DiffValues2
NEWDAY   PROCNAMM=M63TDAY                                 DiffValues1
                 =M62TDAY                                 DiffValues2         
         DAYTIMEM=+1430                                   DiffValues1         
                 =+1200                                   DiffValues2         
         REPDELJ=Y                                        DiffValues1         
                =N                                        DiffValues2         
         NEWDAY#W=30                                      DiffValues1         
                 =35                                      DiffValues2         
ORDER    CALNFND=N                                                            
         CNTERCRD=Y                                                           
         CNTERCMP=N                                                           
         FREESPAC=150                                     DiffValues1         
                 =50                                      DiffValues2         

//IOACMPPJ JOB ,COMPARE,NOTIFY=K68
//S1 EXEC PGM=IKJEFT01
//SYSEXEC DD DISP=SHR,DSN=SCM.WORK.R700.IOA.CLIST
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
IOACMPP IOAP.V700.PARM CTMPARM IOAP.V630.PARM
/*

READY                                                                          
IOACMPP IOAP.V700.PARM * IOAP.V630.PARM                                        
The First  Library is:IOAP.V700.PARM                                           
The Second Library is:IOAP.V630.PARM                                           
                                                                               
==>CTBPARM at Different Libraries:                                             
-----------------------------------------                                      
DAYTIME        DAYTIMEB=+0900                                                        
CODES           DEFSTAT=OK                                                            
                        DEFCODE=0000                                                          
RTE                 RTEBUF=099                                                            
DATABASE     VARCRET=Y                                                             
                        VARGENS=0005                                                          
PRODUCTS   CTBINM=Y                                                              
                        CTBIND=Y                                                              
                        CTMSTSTA=CTBFIRST                                                     
                        CTMSTEND=CTBLAST                                                      
PROCS           CTBPROC=B63TROLB                                  Different Values 1st
                       =B62TROLB                                  Different Values 2nd
PRINT             DECCHAR=DOT                                                           
DEFAULT       STATB=N                                                               
                       SEARCHB=R                                                             
                       NOTFND=N                                                              

IOACND – Perform IOA Condition File or Control-M Resources File Adjustments

This utility adds, verifies the existence of, deletes, or modifies prerequisite conditions in the IOA Conditions file and/or resources in the Control-M Resources file. It can be activated by the operator as a started task (STC), from TSO, or from within a user program.

The addition, deletion, modification or verification is recorded three ways: in the job sysout, as a message on the operator console and as an event in the IOA Log file.

Parameters can be received by the utility in two ways: using DD statement DACNDIN (or SYSIN), or using PARM. The parameters required depend on whether prerequisite conditions, control resources or quantitative resources are being processed. If an input parameter file is specified, its block size must not exceed 8000.

If it is necessary to add, delete, verify or modify prerequisite conditions or resources during a job step, IOACND can be called as a procedure from within the application program. For more information, see Activating the IOACCND Utility (Example).

The IOACND utility deletes control resources only when those resources were added manually, either by the IOACND utility itself or through screen 4. If you need to delete a resource that is allocated to a specific job, you can use the CTMRELRS utility, but only from within the job.

Parameters for Processing Prerequisite Conditions (IOACND)

operation COND condition condition_date

where

• operation is the action to be performed by the utility. Valid values are:

  • ADD – Add the specified prerequisite condition.

  • DELETE – Delete the specified prerequisite condition.

  • CHECK – Verify the existence of the specified prerequisite condition.

• condition is the name of the prerequisite condition.

• condition_date is the date associated with the prerequisite condition. Valid values are:

  • mmdd, ddmm – Any specific date (in format mmdd or ddmm, depending on the site standard defined by the DATETYP parameter in IOAPARM)

  • DATE – Current Gregorian date

  • WDATE – IOA working date

  • STAT – Static. Indicates that the condition (for example, IMS-ACTIVE) is not date-dependent.

Date character masking for DELETE and CHECK functions is supported as follows:

• * represents any value in the corresponding position of the date (format mmdd or ddmm depending on the site standard). Up to four asterisks can be specified. For example

• **** represents any date

Parameters for Processing Control Resources (IOACND)

operation CONTROL resource control

where

• operation is the action to be performed by the utility. Valid values are:

  • ADD – Add the specified Control resource under the specified type of control.

  • DELETE – Delete the specified resource that is under the specified type of control.

• resource is the name of the resource.

• control is the type of control. Valid values are:

  • E – Exclusive control

  • S – Shared control

Parameters for Processing Quantitative Resources (IOACND)

operation RESOURCE resource quantity

where

• operation is the action to be performed by the utility. Valid actions are:

  • ADD – Add the specified Quantitative resource with the quantity specified. quantity is mandatory.

  • DELETE – Delete the resource (and the entire existing quantity). quantity must not be specified.

  • CHANGE – Adjust the existing quantity of the Quantitative resource to or by the value specified in quantity. quantity is mandatory.

• resource is the quantitative resource name.

• quantity is the quantity of the Quantitative resource.

  For CHANGE operations, valid values can have the format n, +n, or –n where n is an integer. When n is specified, the quantity of the Quantitative resource is set to n. When +n or –n is specified, the quantity is increased or decreased by n.

  For ADD actions, valid values can only have the format n, where n is the quantity of the Quantitative resource to be added.

Activating the IOACND Utility (and Examples)

The IOACND utility can be activated as a step in a job or from an application program (as illustrated in the following examples). In these cases, proper protocol is ensured. However, if you use a different method to invoke the IOACND utility, follow the rules below to ensure that the proper protocol is maintained:

• When the IOACND utility receives control, register 1 must contain the address of a full word.

• To indicate this is the last, and only, parameter, the high-order byte must contain X'80'.

• The three low order bytes of the fullword must contain the address of a halfword field.

• The halfword field must be the count of the number of bytes of information contained in the parameter list.

• The parameters must immediately follow the halfword field.

  • As a job step

    Copy

    //CND1 EXEC IOACND
      ADD COND JOB-A-ENDED-OL 0505
      DELETE COND JOB-A-DID-NOT-RUN 0505
      CHANGE RESOURCE TAPE -1
      ADD RESOURCE INIT-CPUA 3
      DELETE RESOURCE INIT-CPUB
      ADD CONTROL PROD-DATA-BASE E

  • As a job containing AutoEdit variables, submitted through the Control-M monitor

    Copy

    //CND1 EXEC IOACND
      ADD COND     AR-FILE-009-CREATED  %%OMONTH.%%ODAY

  • As an operator command

    Copy

    S IOACND,PARM='ADD COND END-CICS 0102'

  • As a called procedure in an application program

    Copy

             CALL CTMCND,(PARMCOND),VL
             LTR  R15,R15
             BNZ  ERROR
             ...
    PARMCOND DC   AL2(80)
    DC   CL80'ADD COND CICS-FILE-CLOSED 0102'

  • As invoked from a REXX exec

    Copy

    parm = ’ADD COND cond_name odat’
    address linkmvs ’ioacnd parm’

IOACND Return Codes

Table 37 IOACND Return Codes

The EXEC statement for the IOAVCND utility utilizes standard IOACND input and sends a job to the MVS node to set the conditions.

EXEC  IOAVCND   'ADD COND VM-READY   STAT'

IOACPLOG – Copy the IOA Log File

The IOACPLOG utility copies the contents of the IOA Log file. The contents can be copied to a sequential file or to another Log file. Usage of the utility depends on the type of target file.

Copying to a Sequential File

The IOA Log file is generally copied to a sequential file for archiving. The sequential file can be restored for access under ISPF (for example, browsing) and for use by report generators.

A date range for the log records to be copied can be specified. If a date range is not specified, the entire Log file is copied.

The target sequential file is referenced by DD statement DALOGSEQ. The existing Log file is referenced by DD statement DALOGCUR.

You should use the utility daily to copy the contents of the IOA Log file to a sequential file. Use of AutoEdit parameters can simplify the process.

Parameters for IOACPLOG Copy to Sequential File

Parameters are supplied using DD statement DALCPPRM (or SYSIN).

Table 38 IOACPLOG Copy to Sequential File Parameters

Activating the Utility (and Example) for IOACPLOG Copy to Sequential File

//* %%SET %%D = %%CALCDATE %%ODATE -1
//   EXEC IOACPLOG
//DALOGSEQ DD DSN=prefix.seqfile,DISP=... Target sequential file
//DALCPPRM DD *
 COPYTOSEQ
 FROMDATE %%D
 TODATE %%D
//

Return Codes for IOACPLOG Copy to Sequential File

Table 39 IOACPLOG Copy to Sequential File Return Codes

Copying to a Log File

This function is generally used to copy one Log file to another. The target Log file size can be different from the source Log file size. However, if the target Log file is smaller, the oldest records in the source Log file may be deleted.

The target Log file is referenced by DD statement DALOG.

Parameters for IOACPLOG Copy to Log File

One parameter is supplied using DD statement DALCPPRM (or SYSIN). The existing Log file is referenced by DD statement DALOGCUR.

Table 40 IOACPLOG Copy to Log File Parameters

Activating the Utility (and Example) for IOACPLOG Copy to Log File

// EXEC IOACPLOG
//DALOG DD DSN=prefix.logfile,DISP=...Target Log file
//DALCPPRM DD *
 COPYTOLOG
//

Return Codes for IOACPLOG Copy to Log File

Table 41 IOACPLOG Copy to Log File Return Codes

IOADBF – Allocate or Format an IOA Access Method File

The IOADBF utility is used to allocate and format the data and index components of an IOA Access Method file. This utility uses database definition statements stored in specified members to perform a requested operation. These members are created by ICE during product installation, and can be managed through ICE Customization.

IOADBF Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADBF JCL procedure:

Table 42 IOADBF Parameters

DD Statement DAFILE for IOADBF

When executing the IOADBF utility with parameter FUNC set to EXTEND or CHANGE, a DAFILE DD statement, specifying the name of the IOA Access Method file component’s primary data set extent, must be included in the JCL step executing the utility.

IOA Access Method File Definition Parameters

The following IOA Access Method file definition parameters can be specified as input to the IOADBF utility in the IOA library and member referred to above by EXEC statement parameters D and M:

Table 43 IOADBF Access Method Parameters

Examples for IOADBF

//INIT    EXEC    IOADBF,FUNC=INIT,D=INSTWORK,M=DEFACT

TYPE=V
DSN=CTD.V600.ACT
BLKSIZE=27998
LRECL=27974
SPACE=(1000,200)
BUFL=100
UNIT=3390
VOL=(PRD021,PRD022,PRD023,PRD024,PRD025,PRD026)
COMPRS=CTDUFCM
COMPTB=CTDUFCMA

//CHANGE  EXEC    IOADBF,FUNC=CHANGE,D=INSTWORK,M=DEFHSTI
//DAFILE  DD      DISP=SHR,DSN=CTD.V600.HSTI.E000

//*** RESET QNAME OF CTB.V600.GRPD.E000 TO
//*** DEFAULT ENV. QNAME
//GRP EXEC IOADBF,FUNC=CHANGE,D=INSTWORK,
//      M=DEFGRPD,ILPREFA='IOA.V600'
//DAFILE DD DISP=SHR,DSN=CTB.V600.GRPD.E000(BYPASS)

Multiple Extents

IOA Access Method files can contain multiple extents. Each extent is a separate sequential file that contains a maximum of 65535 blocks and is allocated without a secondary space allocation.

If an IOA Access Method file has more than 65535 blocks, specify a space parameter, by an expression such as SPACE=(65535,30000). In this case, the IOA Access Method allocates a first extent of 65535 blocks and a second extent of 30000 blocks as separate OS/2390 or z/OS sequential files. However, the IOA Access Method treats the two files as one file with two extents. The new extent is allocated when records are written to the file if the first extent does not have sufficient free space for the new records.

The maximum size for secondary extents is also 65535 blocks. The IOA Access Method supports a maximum of 256 extents.

Using the IOADPT Utility for Space Management

To display information about the space remaining in an IOA Access Method file, run the IOADPT utility with the FUNC parameter set to DB0, as follows.

//AMSPACE EXEC IOADPT,FUNC=DB0,DBFILE=ACT

This information enables you to manage space allocations and provide extra extents before they are created. For details and examples, see IOADPT – Print IOA Access Method File Content.

IOADBF Control-D Samples

For information about using Control-D to allocate and format IOA Access Method files, see "Customize Control-D User Files" in ICE Customization.

IOADBF Control-M/Tape Samples

For information about using Control-M/Tape to allocate and format IOA Access Method files, see "Customize Control-M/Tape Datasets" in ICE Customization.

IOADBF Control-M/Analyzer Samples

The following jobs in the Control-M/Analyzer JCL library can be used as samples for formatting existing data and index files:

Table 44 IOADBF Control-M/Analyzer Sample Formatting Jobs

The following jobs in the Control-M/Analyzer JCL library can be used as samples for formatting and rebuilding the index file for an existing data file:

Table 45 IOADBF Control-M/Analyzer Sample Formatting and Rebuilding Jobs

For example, if the index file of the Rule Activity file was damaged by a disk crash but the data file was not damaged (meaning, the actual information about invocations, and so on, is accurate), use member JOBBJAF to reformat the index file and rebuild the index entries.

IOADBF IOA Samples

The IOADBF utility is used by the following jobs in the IOA JCL library:

Table 46 IOADBF IOA Sample Jobs

IOADBIB – Rebuild Index File

The IOADBIB utility rebuilds index files for various IOA Variable Database data files. The new index files correspond to information contained in the data files.

This utility rebuilds the indexes of a specific data file. Previous contents of the index file are erased.

This utility is used:

• When the space remaining for the existing index file is insufficient, or the relevant data file was reloaded. In this case:

  • Delete the index file.

  • Redefine the index file with the required amount of space.

  • Format the index file with the IOADBF utility.

  • Rebuild the index file with the IOADBIB utility.

• In case of index file integrity problems that can be detected using the IOADII utility. For details, see IOADII – Verify Integrity of IOA Access Method File Index Component.

• In case of data file integrity problems. In this case, correct the data file and re-index it with the IOADBIB utility to reproduce the corresponding index file.

IOADBIB Parameter

The following parameter can be specified in the EXEC statement that invokes the IOADBIB JCL procedure:

Table 47 IOADBIB Parameter

Activating the IOADBIB Utility

// EXEC IOADBIB

IOADBIB Return Codes

Table 48 IOADBIB Return Codes

Example for IOADBIB

//        EXEC IOADBIB,DBFILE=GRPD
//SYSIN   DD   DSN=IOA.PROD.PARM(KEYGRP),DISP=SHR
//DAGRP   DD   DSN=IOA.PROD.COLI,DISP=SHR

The IOADBIB utility is used by the following jobs in the IOA JCL library. For additional examples, refer to these jobs:

Table 49 IOADBIB Jobs

IOADBSR – Sort Records in IOA Access Method Data Component

The IOADBSR utility sorts the records in an IOA Access Method file’s data component in the same logical order as the records in the associated IOA Access Method file’s index component.

Sorting an IOA Access Method file’s data component improves I/O performance.

WARNING: This utility does not support Control-M/Tape databases.

IOADBSR Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADBSR JCL procedure:

Table 50 IOADBSR Parameters

IOADBSR Sort Control Parameters

The following Sort Control parameters can be specified for dynamic sorting. Parameters that are not applicable to batch sorting with the IOADBSR utility are indicated as such.

Table 51 IOADBSR Sort Control Parameters

Example for IOADBSR

//   EXEC IOADBSR,DBPREFA=CTD,
//            DBFILE=ACT,
//            PARMLIB='CTD.PROD.PARM',
//            M=DBSRTPRM

For an example of how to sort the data component of the Control-D History User Report list, refer to sample job CTDUFSR in the Control-D JCL library.

IOADCPY – Recover an IOA Access Method File

The IOADCPY utility is used to recover an IOA Access Method file from the dual mirror image copy.

If an IOA Access Method file is used with dual file support, and either the working copy or the dual mirror image copy is corrupted or becomes unavailable, the damaged or missing file must be recovered. The IOADCPY utility restores the damaged or missing copy of the file from the copy that is still intact and available (including all file extents). If the dual copy is corrupted, the utility also resets the parameter in the control block of the IOA Access Method file that indicated a corrupted dual mirror image file (DUALBAD).

Activating the IOADCPY Utility

//COPY    EXEC    IOADCPY,DBFILE=ACT,SUFFIX=E000

When executing this utility, the DAIN DD statement must be included in the JCL stream and must specify the full name of the uncorrupted (valid, intact) IOA Access Method file.

The IOADCPY utility cannot be used for IOA Variable Database files.

Examples for IOADCPY

//DAIN DD DISP=SHR,DSN=CTD.PROD.ACT.E000

//DAIN DD DISP=SHR,DSN=CTD.PROD.ACT.D000

IOADCPY Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADCPY JCL procedure:

Table 52 IOADCPY Parameters

The above parameters are optional and are used only when it is necessary to override the UNIT and VOL (or UNITD and VOLD) parameters specified in the IOA Access Method file definition member when the IOA Access Method file was first created (member DEFxxx in the IOA INSTWORK library). After running the utility with these parameters, run the IOADBF utility with FUNC set to CHANGE to update the new values for these parameters in the IOA Access Method file control block.

IOADCPY Return Codes

Table 53 IOADCPY Return Codes

For more information about how to use this utility, see the CTDUFCPY sample member in the Control-D JCL library.

IOADIG – Verify Integrity of IOA Access Method File Data Component

The IOADIG utility is used to verify the integrity of the data component structure an IOA Access Method file by scanning the active and free record chain lists in the file, and reporting any detected errors. Optionally, this utility can correct the detected errors.

Activating the IOADIG Utility

//CHECK EXEC IOADIG,DBFILE=logical_filename,
//      FUNC=R|W[,DBPREFA=prefix_filename]

IOADIG Return codes

Table 54 IOADIG return codes

IOADIG Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADIG JCL procedure:

Table 55 IOADIG Parameters

Example for IOADIG

//CHECK EXEC IOADIG,DBFILE=HST,FUNC=R,DBPREFA=&DBPREFD

IOADIG IOA Samples

The IOADIG utility is used by the following jobs in the IOA JCL library:

Table 56 IOADIG Jobs

IOADIG Control-D Samples

For an example of how to check the structural integrity of a Control-D IOA Access Method file data component, see the CTDUFCHK sample job in the Control-D JCL library.

IOADIG Control-M/Tape Samples

The IOADIG utility is used by the CTTDIG job in the Control-M/Tape JCL library.

IOADII – Verify Integrity of IOA Access Method File Index Component

The IOADII utility is used to verify the integrity of the index component structure of an IOA Access Method file. If errors are detected, format the index file component using the IOADBF utility, and then rebuild the index using the appropriate index rebuilding utility. For information about index rebuilding utilities for IOA Access Method in the IOA administration chapter of the INCONTROL for z/OS Administrator Guide.

This utility also indicates the number of records in the file.

Activating the IOADII Utility

//CHECK EXEC IOADII,DBFILE=logical_filename[,
//      DBPREFA=prefix_filename]

IOADII Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADII JCL procedure:

Table 57 IOADII Parameters

Example for IOADII

//CHECK    EXEC    IOADII,DBFILE=MDBI,DBPREFA=&DBPREFT

IOADII Control-D Samples

For an example of how to check the structural integrity of a Control-D IOA Access Method file data component, see the CTDUFCHK sample job in the Control-D JCL library.

IOADII Control-M/Tape Samples

The IOADII utility is used by the CTTDII job in the Control-M/Tape JCL library.

IOADLD – Load IOA Access Method File Contents

The IOADLD utility is used to load the contents of an IOA Access Method file from a sequential file previously created by the IOADUL utility.

This utility is typically used to migrate an IOA Access Method file to another DASD volume. In this case, perform the following steps:

1. Run the IOADUL utility to unload the IOA Access Method file data component’s records to a sequential data set.

2. Allocate and format a new IOA Access Method file on a new DASD volume using the IOADBF utility.

3. Run the IOADLD utility to reload the IOA Access Method file data component records from the sequential data set previously produced by the IOADUL utility.

4. Run the appropriate index rebuilding utility to rebuild the IOA Access Method file index component, based on the contents of the data component:

   • For IOA databases, use the IOADBIB utility.

   • For Control-D, use the CTDDIB utility.

   • For the Control-V global index file, use the CTDGBIB utility.

   • For the Control-M/Tape media database, use the CTTBIX utility.

   • For the Control-M/Tape stacking database, use the CTTDBIB utility.

Activating the IOADLD Utility

//LOAD    EXEC    IOADLD

IOADLD Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADLD JCL procedure:

Table 58 IOADLD Parameters

Example for IOADLD

//LOAD EXEC IOADLD,SQFILE=ACTSEQ,DBFILE=ACT, DBPREFA=&DBPREFD

IOADLD Control-D Samples

For an example of how to load Control-D IOA Access Method file data component records from a sequential data set and then rebuild the IOA Access Method file’s index component, see the CTDUFRST sample job in the Control-D JCL library.

IOADLD Control-M/Tape Samples

The IOADLD utility is used by the CTTDBDLD job in the Control-M/Tape JCL library.

IOADLD IOA Samples

The IOADLD utility is used by the following jobs in the IOA JCL library:

Table 59 IOADLD Jobs

IOADPT – Print IOA Access Method File Content

The IOADPT utility prints IOA Access Method file data and index records in SNAP dump format.

Activating the IOADPT Utility

//PRINT EXEC IOADPTE

IOADPT Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADPT JCL procedure:

Table 60 IOADPT Parameters

This utility processes both the data and index components of a IOA Access Method file.

If KEYFROM and KEYTO parameters are not specified or are specified as blank, all records are printed.

Example for IOADPT

//PRINT EXEC IOADPT,FUNC=0,DBFILE=HST,DBPREFA=&DBPREFD

IOADPT Control-D Samples

For an example of how to print Control-D IOA Access Method file record contents, see the CTDUFDPT sample job in the Control-D JCL library.

IOADPT Control-M/Tape Samples

The IOADPT utility is used by the CTTDPT job in the Control-M/Tape JCL library.

IOADPT IOA Samples

The IOADPT utility is used by the following jobs in the IOA JCL library:

Table 61 IOADPT Jobs

IOADUL – Unload IOA Access Method File Contents

The IOADUL utility is used to unload the record contents of an IOA Access Method file data component a sequential file.

This utility is typically run to migrate an IOA Access Method file to another DASD volume. In this case, perform the following steps:

1. Run the IOADUL utility to unload the IOA Access Method file data component’s records to a sequential data set.

2. Allocate and format a new IOA Access Method file on a DASD volume using the IOADBF utility.

3. Run the IOADLD utility to reload the IOA Access Method file data component records from the sequential data set previously produced by the IOADUL utility.

4. Run the appropriate index rebuilding utility to rebuild the IOA Access Method file index component, based on the contents of the data component:

   • For IOA databases, use the IOADBIB utility.

   • For Control-D, use the CTDDIB utility.

   • or the Control-V global index file, use the CTDGBIB utility.

   • For the Control-M/Tape media database, use the CTTBIX utility.

   • For the Control-M/Tape stacking database, use the CTTDBIB utility.

Activating the IOADUL Utility

//UNLOAD EXEC IOADUL,
//   DBFILE=logical_data_filename,SQFILE=seqfilename0[,
//   RBAOFF=offset][,FROMKEY=fkey][,TOKEY=tkey][,
//   DBPREFA=prefix_filename][,
//   DBINDEX=logical_index_filename]
//   DISPO=jcl_disp_val

IOADUL Parameters

The following parameters can be specified to the utility in the EXEC statement that invokes the IOADUL JCL procedure:

Table 62 IOADUL Parameters

If FROMKEY and TOKEY parameters are not specified or are specified as blank, all records are copied.

Example for IOADUL

//UNLOAD EXEC IOADUL,DBFILE=PRM,SQFILE=PRMSEQ,
         DBPREFA=&DBPREFB

IOADUL Control-D Samples

For an example of how to print Control-D IOA Access Method file record contents, see the CTDUFDUL sample job in the Control-D JCL library.

IOADUL Control-M/Tape Samples

The IOADUL utility is used by the CTTDBDUL job in the Control-M/Tape JCL library.

IOADUL IOA Samples

The IOADUL utility is used by the following jobs in the IOA JCL library:

Table 63 IOADUL Jobs

IOAFRLOG – Allocate and Format the IOA Log File

IOAFRNRS – Allocate and Format the IOA Manual Conditions File

IOAGLV – Utility for managing IOA Global Variables

The IOAGLV utility runs as a batch job and enables the users to manage IOA Global variables.

IOA Global variables are kept in the IOAVAR database and are loaded to a memory pool during the starting of the Control-O or CMEM monitor. This utility handles IOA Global variables in the IOAVAR memory pool.

The IOA Global variable has the name and the value. The layout of complete variable name is path\varname, where path can contain several levels started from \M or \O and separated by ‘\’. The following paths can be specified in the IOA Global variables used in Control-M:

• \M

• \M\application

• \M\application\group

• \M\application\group\job

• \M\POOLS\poolname

The utility can perform the following actions:

• list paths matching the path prefix specified in the input parameter

• view the variable names and values related to the path or path prefix specified in the input parameter

• load variables from a dataset with the path specified in the input parameter

• delete variables from the specified path or delete one specified variable

• add new variables (name and value) or update existing variable values

The utility with the functions updating IOA Global variables cannot be submitted in parallel with the online IV screen, which enables the users to update the IOAVAR database.

IOAGLV Parameters

The utility parameters are specified in the SYSIN DD input stream. They must be specified in the following order:

1. General parameters

2. Command statements

The general parameters define the working mode of the utility and are described in the following table:

Table 64 IOAGLV general parameters

The command statements contain a command, which determines the action that the utility will perform, followed by one or more keyword parameters, which qualify the action. In general, only one command statement can be specified in one utility run, with the exception of the SETVAR command.

The following commands can be specified for the utility:

Table 65 IOAGLV command statements

The keyword parameters specified for the commands are described in the following table:

Table 66 IOAGLV command parameters

IOAGLV Output

The IOAGLV utility generates the output reports and messages to the file referred to by the DAPRINT DD statement. The messages are described in the INCONTROL for z/OS Messages Manual. Different output reports are issued for different commands, as shown in the examples below.

Activating the IOAGLV Utility

//IOAGLV EXEC IOAGLV
//SYSIN DD *
[ MODE= PROD|TEST ]
 LIST PATH=path  |
 VIEW  PATH=path  |
 LOAD  PATH=path  FROM=dsn |
 DELETE PATH=path | VARNAME=path\varname  |
 SETVAR VARNAME=path\varname  VALUE=value
.......
[SETVAR VARNAME=path\varname  VALUE=value ]

IOAGLV Return codes

Table 67 IOAGLV Return Codes

Examples for IOAGLV

The following examples illustrate the use of the utility:

//IOAGLV EXEC IOAGLV
//SYSIN DD *
[ MODE= PROD|TEST ]
 LIST PATH=path  |
 VIEW  PATH=path  |
 LOAD  PATH=path  FROM=dsn |
 DELETE PATH=path | VARNAME=path\varname  |
 SETVAR VARNAME=path\varname  VALUE=value
.......
[SETVAR VARNAME=path\varname  VALUE=value ]

\M\APPL1\GR1\JOB1\VAR1
\M\APPL1\GR1\JOB1\VAR2
\M\APPL1\GR2\JOB2\VAR1
\M\APPL1\GR3\VAR1
\M\APPL1\GR3\VAR2

*** LIST OF GLOBAL VARIABLES PATHS ***
\M\APPL1\GR1\JOB1        002 VARIABLES
\M\APPL1\GR2\JOB2        001 VARIABLES
\M\APPL1\GR3             002 VARIABLES

IOAGLV EXEC IOAGLV
//SYSIN DD *
 VIEW PATH=\M\POOLS\MYPOOL
/*

      *** LIST OF VARIABLES ***
   
\M\POOLS\MYPOOL\VAR1      value_1
………………………………………………
\M\POOLS\MYPOOL\VARn      value_n

IOAGLV EXEC IOAGLV
//SYSIN DD *
 LOAD PATH=\M\POOLS\MYPOOL  FROM=IOAGLV.VARS
/*

VAR1=val1
VAR11=val11
VAR2=val2

\M\POOLS\MYPOOL\VAR1      val1
\M\POOLS\MYPOOL\VAR11    val11
\M\POOLS\MYPOOL\VAR2      val2

IOAGLV EXEC IOAGLV
//SYSIN DD *
 MODE=TEST
 DELETE PATH=\M\POOLS\MYPOOL
/*

IOAGLV EXEC IOAGLV//SYSIN DD *
 MODE=PROD
 SETVAR VARNAME=\M\POOLS\MYPOOL\VAR1
                VALUE=val1
 SETVAR VARNAME=\M\APP\GR\JOB1\LONG_VALUE
                 VALUE=’My very long value including embedded blanks’
                               ‘ and specified in two lines’
/*

IOALDNRS – Load IOA manual conditions file

This utility creates and loads the IOA Manual Conditions file that can be viewed using the IOA Manual Conditions screen described in the online facilities chapter of the INCONTROL product-specific user guides. The utility is usually run every day after the New Day procedure finishes executing.

To identify conditions that are placed in the IOA Manual Conditions file, the utility first performs a search for all prerequisite IN conditions required for the submission of jobs, missions, or reports on the particular day. The search for prerequisite IN conditions is performed by checking the job scheduling definitions of all jobs in the Active Jobs file and by checking the mission definitions of missions in the Active Missions file.

Once the prerequisite IN conditions have been identified, the utility eliminates non-manual conditions from the list to arrive at the list of manual conditions that need loading. A prerequisite IN condition is not included in the IOA Manual Conditions file if it satisfies either of the following criteria:

• The prerequisite condition is added to the IOA Conditions file by an OUT or DOCOND statement in a job, mission, or report that is active that day.

• The prerequisite condition already exists in the IOA Conditions file.

All prerequisite IN conditions that do not meet the above criteria are assumed manual conditions and are placed in the IOA Manual Conditions list.

Through parameters passed to the utility, it is possible to exclude the Active Jobs file and/or the Active Missions file from the search for manual conditions. Of course, if both files are excluded, no manual conditions are found, even if they exist.

Every time the utility is activated, the IOA Manual Conditions file is recreated and all previous conditions are automatically deleted from the file. It is possible to override this default by using parameter ADDMODE.

This utility can be used in conjunction with ADDMNCND KeyStroke Language utility, which is referred to in the Keystroke Language (KSL) User Guide.

The conditions to be included in the file can be limited by control statements supplied using the DALNRIN DD statement (or SYSIN).

IOALDNRS Parameters

Table 68 IOALDNRS Parameters

When Control-M, and Control-D or Control-V, are active, you should use a shared control parameters member.

Activating the IOALDNRS Utility (and Example)

Figure 11 IOALDNRS – Example

// EXEC IOALDNRS//DALNRIN DD *
IGNORE IN CICS
IGNORE IN IMS
IGNORE OUT DB-FILE
IGNORE CODES DB-FILE
CONTROLM YES

IOALDNRS Return Codes

Table 69 IOALDNRS Return Codes

IOALOGI – Build and rebuild Index file for the IOA Log file

The IOALOGI utility builds, rebuilds, or updates the IOA Log Index file. The new Index file corresponds to information contained in the IOA Log file.

This utility is used in two cases:

• When a new Index file is first created. In this case:

  • Format the Index file using the IOADBF utility

  • Create the Index file using the IOALOGI utility

• When the current Index file does not correspond to information contained in the IOA Log file. In this case:

  • Do not format the old Index file

  • Execute the IOALOGI utility

IOALOGI Parameters

The parameters listed in Table 70 should be specified for the IOALOGI utility in the EXEC statement that invokes the IOALOGIB JCL procedure.

Table 70 IOALOGI Parameters

DD statement DAFRM

When the IOALOGI utility updates an old IOA LOG Index file, the DD statement DAFRM specifies the name of the IOA library containing the IOA Access Method file definition statements member. This member is used to format the IOA LOG Index file. The formatting is executed when the old IOA LOG Index file is not valid and updating the old IOA Log Index file is not possible. After the formatting, the utility rebuilds the IOA LOG Index file.

Activating the IOALOGI utility (example)

//IOALOGI  EXEC IOALOGI,KEYIN=KEYLOGI,M=IOADLOGI,D=INSTWORK
//DALOGI   DD DISP=SHR,DSN=&DBPREFA..LOGI.E000             
//DALOG    DD DISP=SHR,DSN=&DBPREFA..LOG                   

The IOALOGI utility is used by the IOALOGIB job in the IOA JCL library.

IOALOGI Return codes

Table 71 IOALOGI return codes

IOALOGXC – Activate or deactivate use of the IOA LOG Index file

The IOALOGXC utility is used to activate or deactivate use of the IOA Log Index file by setting or resetting the index indication in the IOA Log file Control record (Record 0).

The IOA Log Index file improves the viewing process of IOA Log messages with the ORDERID (OID) parameter because it provides direct access to specific records in the IOA Log file.

IOALOGXC Parameters

Table 72 IOALOGXC parameter

Activating the IOALOGXC utility (example)

//IOALOGXC EXEC IOALOGXC,FUNC=ACT     

The IOALOGXC utility is used by the IOALOGXC job in the IOA JCL library.

IOALOGXC Return codes

Table 73 IOALOGI return codes

IOALOGXP – Print the IOA Log Index file

The IOALOGXP utility prints the IOA LOG Index file records in SNAP dump format.

IOALOGXP Parameters

The parameters listed in Table 74 can be specified for the IOALOGXP utility in the EXEC statement that invokes the IOALOGXD JCL procedure

Table 74 IOALOGXP parameters

If the KEYFROM and KEYTO parameters are not specified or are blank, all records are printed.

Activating the IOALOGXP utility (example)

//IOALOGXP EXEC IOALOGXP,                 
//         DALOGI=&DBPREFA..LOGI.E000,    
//         KEYFROM=,                       
//         KEYTO=

The IOALOGXP utility is used by the IOALOGXD job in the IOA JCL library.

IOALOGXP Return codes

Table 75 IOALOGXP Return Codes

IOANOTE – Write a Message to the IOA Log File

This utility writes a message to the IOA Log file. It can be invoked as a started task (STC), as a job step, or from another program. On terminals supporting color, messages written by the IOANOTE utility appear on the Log screen in a different color than other messages, making them more readily identifiable.

IOANOTE Parameter

The message to be written to the Log file is specified using the following parameter:

Table 76 IOANOTE Parameter

Activating the IOANOTE Utility

As a job step

// EXEC IOANOTE,PARM=’text’

As a started task

S IOANOTE,PARM='text'

From another program

 CALL CTMNOTE,(NOTELENG)
 ...
NOTELENG DC H’80’
 DC CL80’any customer message text’

Before executing the call to CTMNOTE, you must place the program into AMODE 24. The message generated by the IOANOTE utility is written to the IOA log under message ID MSG999I.

IOANOTE Return Codes

Table 77 IOANOTE Return Codes

Example for IOANOTE

// EXEC IOANOTE,PARM='PAYROLL APPLICATION MESSAGES BEGIN HERE'

IOAOPR – Issue Operator Commands Using a Job or STC

The IOAOPR utility can be used to issue operator commands (MVS, JES2, JES3, VTAM, and so on). It can be activated as a job step or as a started task, and allows full control over when a command is issued and what to do afterwards. If Control-M is installed, it is also possible to send the command to any computer (because Control-M can schedule a started task in any computer).

Each command issued by the utility is recorded in the IOA Log file.

The utility can execute commands from a list supplied in the DA34F DD statement. To activate the utility (for example, as a job step)

//   EXEC IOAOPR,CMDMEM=mem_name

where mem_name is the name of a member containing a list of operator commands to be executed.

To activate the utility for one command, use the PARM parameter, as follows:

//   EXEC IOAOPR,PARM=`command'

If Control-M is installed, it is possible to activate the utility using Control-M facilities. The following is an example of a schedule definition for a single command in a specified computer:

MEMNAME IOAOPR  MEMLIB  M3,PARM='$PIA'
 TASKTYPE STC

The utility can also issue JES3 commands (under a JES3 environment). A JES3 command is identified as such only if it begins with the IOA JESCHAR. Under JES3 it is possible to specify commands starting with more than one type of character. A command that starts with a valid JES3 command prefix and not with the IOA JESCHAR is sent for execution but cannot be executed by JES (without any indication from the IOAOPR utility).

IOAPFSTC – Printing performance statistics reports

The IOAPFSTC utility is used for printing IOA Application Server (IOAAS) performance statistics reports. The statistics records are collected in the Permanent User file while the IOAAS is running and can be printed out any time afterwards. The reports can be printed for specific periods of time, LPARs, and IOAAS address spaces as specified by the utility parameters. The utility can also remove statistics records that are older than one year, which were not overridden by new data.

Performance statistics reports can be printed for the following purposes:

• Provide tables for easy transformation into Microsoft EXCEL worksheets. These tables allow easier analysis of performance problems. The tables are printed out to the DAPFSXL DD-statement.

• Provide tables for viewing and analysis by the customers or support staff. These tables allow customers and support to follow up IOAAS workload changes. The tables are printed out to the DAPFS DD-statement.

Activating the IOAPFSTC Utility

Submit an IOAPFSTC utility job as follows:

//IOAPFSTC   EXEC IOAPFSTC
//IOAPFSTC.SYSIN DD *;
[FUNCTION=PRINT|CLEAN]
[REPORT=TOTAL|DETAIL|ALL]
[SYSNAME=LPAR_name]
[STCNAME=IOAAS_address_space_name]
DATEFROM=dd/mm/yy | mm/dd/yy | yy/mm/dd
DATETO=dd/mm/yy | mm/dd/yy | yy/mm/dd
[TIMEFROM=hh:mm]
[TIMETO=hh:mm]
[MODE = TEST|PROD]
[DAYS = N]
/*

IOAPFSTC Parameters

The parameters listed in Table 78 can be specified in the SYSIN DD input stream as keyword statements.

Table 78 IOAPFSTC parameters

IOAPSCK – Check password validation for INCONTROL products

The purpose of the IOAPSCK utility is to check the validation of passwords for INCONTROL products. The utility indicates whether:

• the password is valid

• the password has expired

• the password is about to expire

If JCL PARM is set to ALL, then the IOAPSCK utility checks the validity of passwords for all INCONTROL products; otherwise, you can specify a particular product. For a list of valid parameters, see IOAPSCK Input.

IOAPSCK Components

The IOAPSCK utility contains the following part:

Activating the IOAPSCK utility

A sample job can be found in the IOAPSCK member in the IOA.*.SAMPLE library.

IOAPSCK Input

Table 79 IOAPSCK input

IOAPSCK Return codes

Table 80 IOAPSCK return codes

Results for IOAPSCK

A message that describes the status of the selected product’s password is displayed. The list of messages is found in the PASF9 member.

Example for IOAPSCK

//IOAPSCK JOB ,IOAPSCK,NOTIFY=&SYSUID,MSGCLASS=X,CLASS=A
//*                                                    
//*                                                    
//         JCLLIB  ORDER=IOA.V700.PROCLIB              
//         INCLUDE MEMBER=IOASET                       
//*                                                    
//PASSCHCK EXEC PGM=IOAPSCK,PARM='ALL'                 
//         INCLUDE MEMBER=&IOAENV                      
//*                                                    

IOASDISC – Emergency Subsystem Disconnect

The IOASDISC utility forces the Subsystem Vector Table (SSVT) to disconnect from the Subsystem Control Table (SSCT) control block of the IOA subsystem.

The IOASDISC utility procedure is located in the IOA.PROCLIB library.

Activating the IOASDISC Utility (and Example)

S IOASDISC,SSNAME=xxxx

IOASDISC Return Codes

Table 81 IOASDISC Return Codes

IOATEST – Simulate Production Environment Events

This utility simulates various events in the production environment. For example, it can simulate step termination codes or cause a step to "wait" a specified interval.

IOATEST Parameters

Table 82 IOATEST Parameters

WTOM= major
      Minor 1
      Minor 2
      minor n
      +++

WTO, ROUT, DESC, CONID, CMD, WAIT and TERM can also be specified in the PARM keyword of the EXEC job step. If this method is used, only the PARM parameters are executed in the following order: WTO, WAIT, TERM. When using PARM, DEFDELAY is always 0.

Example for IOATEST

WTOM= major
      Minor 1
      Minor 2
      minor n
      +++

// EXEC IOATEST
//SYSIN DD *
CMD=D T
TERM=C0004
//

IOAVERFY – Verify IOA File Installation and Status

The IOAVERFY utility can be used to perform the following tasks:

• Verify INCONTROL product installation.

• Produce reports on the utilization of various IOA files.

• Produce a report describing invalid records in the IOA Conditions file, the Control-M Resources file, the Control-M Active Jobs file, or the Control-M History Jobs file. (Invalid records can be automatically corrected during the same run.)

• Verify and replace specified data in records of the Control-M Active Jobs file.

• Verify the locking (ENQ) mechanism of the IOA and Control-M files from a multi-systems environment.

At least one of the following parameters must be specified to produce utility output:

• DISPLAY

• VERIFY

• LIST

• DIAGNOSE

• VER/REP

IOAVERFY Parameters

Table 83 IOAVERFY Parameters

ZAP FILE file_id

VER rba type offset ver_format ver_data

VER 00   X   3F X '0003E8'
REP 00   X   3F X '00045D'

VER 00   X 0103 X '000000'
REP 00   X 0103 C 'JB1'

VER 1A95 D   20 C 'N28'
REP 1A95 D   20 C 'M04'

IOAVERFY Sample reports

The following section shows different kinds of sample reports:

Sample report using the VERIFY FILE CND parameter

=======================       IOA CONDITIONS FILE      =====================
              DATA SET NAME:  BMCC.IOA6AC1.CND
              DDNAME:         DACNDF
   
                  GENERAL DATA
                     VOLUME SERIAL:        CACVD1
                     DEVICE TYPE:            3390
                     ORGANIZATION:             PS
                     RECORD FORMAT:             F
                     RECORD LENGTH:        32,760
                     BLOCK SIZE:           32,760
   
                  CURRENT ALLOCATION
                     ALLOCATED RECDS:          65
                     DEFINED RECDS:            65
   
                        UTILIZATION OF CONDITION ENTRIES
   
         +--------------+--------------+--------------+--------------+
         |    DAY OF    |     USED     |    PERCENT   |     FREE     |
         |    MONTH     |    ENTRIES   |     USED     |    ENTRIES   |
         +--------------+--------------+--------------+--------------+
         |       1      |        0     |       0      |    2,728     |
         |       2      |        0     |       0      |    2,728     |
         |       3      |        0     |       0      |    2,728     |
         |       4      |        0     |       0      |    2,728     |
         |       5      |        0     |       0      |    2,728     |
         |       6      |        0     |       0      |    2,728     |
         |       7      |        0     |       0      |    2,728     |
         |       8      |        0     |       0      |    2,728     |
         |       9      |        0     |       0      |    2,728     |
         |      10      |        0     |       0      |    2,728     |
         |      11      |        0     |       0      |    2,728     |
         |      12      |        0     |       0      |    2,728     |
         |      13      |        0     |       0      |    2,728     |
         |      14      |        0     |       0      |    2,728     |
         |      15      |    2,098     |      77      |      700     |
         |      16      |      150     |       5      |    2,578     |
         |      17      |       11     |       1      |    2,717     |
         |      18      |       58     |       2      |    2,670     |
         |      19      |       36     |       1      |    2,692     |
         |      20      |       10     |       1      |    2,718     |
         |      21      |        0     |       0      |    2,728     |
         |      22      |        0     |       0      |    2,728     |
         |      23      |        0     |       0      |    2,728     |
         |      24      |        0     |       0      |    2,728     |
         |      25      |        0     |       0      |    2,728     |
         |      26      |        0     |       0      |    2,728     |
         |      27      |        0     |       0      |    2,728     |
         |      28      |        0     |       0      |    2,728     |
         |      29      |        0     |       0      |    2,728     |
         |      30      |        0     |       0      |    2,728     |
         |      31      |        0     |       0      |    2,728     |
         |     STAT     |        0     |       0      |    2,728     |
         +--------------+--------------+--------------+--------------+

Prerequisite conditions in the IOA Conditions file are held in 32 slots. The first 31 slots contain only conditions that have a date reference to a specific day-of-the-month.

The 32nd slot is used for prerequisite conditions that contain the STAT attribute instead of a date.

The sample report shows that, for example, on day 15, 77 percent (2098/2728) of the entries are being used.

Each Long condition takes up 2 slots.

Sample report using the VERIFY FILE AJF parameter

==============        ACTIVE JOBS FILE        =================
                                                                               
            DATA SET NAME:  PFVN.CTMD618.AJF                                  
             DDNAME:         DAAJFT                                            
                                                                               
                 GENERAL DATA                                                  
                  VOLUME SERIAL:        SYST09                 
                  DEVICE TYPE:            3390                 
                  ORGANIZATION:             PS                 
                  RECORD FORMAT:             F                 
                  RECORD LENGTH:         1,024                 
                  BLOCK SIZE:            1,024                 
                                                               
               CURRENT ALLOCATION                              
                  ALLOCATED RECDS:     100,023                 
                  DEFINED RECDS:       100,000                 
                                                               
               CURRENT UTILIZATION                             
                  INDEX RECDS:           6,138                 
                  USED RECDS:           84,051                 
                  FREE RECDS:            9,811                 
                  AVG # RECDS/JOB:        2.00                 
                  FREE SPACE-NEW JBS:    4,905                 
                  # RECDS REUSABLE:        719
                  AJF SPACE REUSE:      ACTIVE

'AVG # RECDS/JOB: 2' means that, on average, two records on the AJF file are required to hold the information for one job.   Since the AJF file can hold a maximum of 100,000 records (DEFINED RECDS), it can hold approximately a maximum of 50,000 jobs. 'USED RECDS:' is 84,051, which means that there are approximately 42,025 jobs on the AJF file. In percentage terms, approximately 84% of the AJF file is used to hold jobs. Another six percent (6,138/100,000) of the AJF is used to hold index records. Therefore, a total of approximately 90% of the AJF is used for both jobs and indexes.

FREE SPACE-NEW JBS is calculated by dividing 9,811 (FREE RECDS) by 2.00. The result is 4,905. This means that, in theory, 4,905 jobs can be added to the AJF file.   Note that when jobs are added to the AJF, index records are also created. Since approximately six percent (6,138/100,000) of the file is used to hold index records, this means that six percent must be subtracted from the 4,905 jobs that can be added to the AJF. Therefore, approximately 4,611 jobs can be added to the AJF.

If the Active Jobs File Space Reuse Facility is active (AJF SPACE REUSE: ACTIVE),
'# RECDS REUSABLE' specifies how many records on the AJF can be reused for new jobs. For more information about the Space Reuse Facility, see the INCONTROL Administrator Guide.

Sample report using the VERIFY FILE RES parameter

=======================    CONTROL-M RESOURCES FILE    =======================
                                                                                
             DATA SET NAME:  CTMP.V700.RES                                     
             DDNAME:         DARESF                                            
                                                                               
                 GENERAL DATA                                                  
                    VOLUME SERIAL:        IOAT25                               
                    DEVICE TYPE:            3390                               
                    ORGANIZATION:             PS                               
                    RECORD FORMAT:             F                               
                    RECORD LENGTH:        32,760                               
                    BLOCK SIZE:           32,760                               
                                                                               
                 CURRENT ALLOCATION                                            
                    ALLOCATED RECDS:          11                               
                    DEFINED RECDS:            11                               
   
  
                UTILIZATION OF RESOURCE ENTRIES                         
                                                                        
 +--------------+--------------+--------------+--------------+          
 |   TYPE OF    |     USED     |    PERCENT   |     FREE     |          
 |   RESOURCE   |    ENTRIES   |     USED     |    ENTRIES   |          
 +--------------+--------------+--------------+--------------+          
 | CONTROL      |        1     |       1      |    6,294     |          
 | QUANTITATIVE |        1     |       1      |    5,544     |          
 | QUANT. BASE  |        7     |       2      |      293     |          
 +--------------+--------------+--------------+--------------+          

This report shows that 6,294 Control resources can be added, and 293 new Quantitative resources can be added.

Another 5,544 Used slots are available at any one time. For example, if every job has at most one Quantitative resource, a maximum of 5545 can run (get a Used slot). For more information about the RESQNT# parameter and quantitative base slots and used slots, see the INCONTROL for z/OS Installation Guide.

Sample report using the VERIFY FILE NRS parameter

=======================   IOA MANUAL CONDITIONS FILE   ======================= 
                                                                               
             DATA SET NAME:  IOAP.V700.NRS                                     
             DDNAME:         DANRES                                            
                                                                               
                 GENERAL DATA                                                  
                    VOLUME SERIAL:        IOAT25                               
                    DEVICE TYPE:            3390                               
                    ORGANIZATION:             PS                               
                    RECORD FORMAT:             F                               
                    RECORD LENGTH:        32,760                               
                    BLOCK SIZE:           32,760                               
                                                                               
                 CURRENT ALLOCATION                                            
                    ALLOCATED RECDS:          33                               
                    DEFINED RECDS:            33                               
   
            UTILIZATION OF MANUAL CONDITION ENTRIES                    
                                                                       
+--------------------+----------------------+----------------------+----------------+
|    DAY OF          |     USED             |    PERCENT           |   FREE          |
|    MONTH           |    ENTRIES           |     USED             |   ENTRIES       |
+--------------------+----------------------+----------------------+-----------------+
|       1            |        0             |       0              |    5,240        |
|       2            |        6             |       1              |    5,234        |
|       3            |        6             |       1              |    5,234        |
|       4            |        7             |       1              |    5,233        |
|       5            |        6             |       1              |    5,234        |
|       6            |        6             |       1              |    5,234        |
|       7            |        6             |       1              |    5,234        |
|       8            |        6             |       1              |    5,234        |
|       9            |        6             |       1              |    5,234        |
|      10            |        5             |       1              |    5,235        |
|      11            |        6             |       1              |    5,234        |
|      12            |        6             |       1              |    5,234        |
|      13            |        5             |       1              |    5,235        |
|      14            |        6             |       1              |    5,234        |
|      15            |        6             |       1              |    5,234        |
|      16            |        6             |       1              |    5,234        |
|      18            |        0             |       0              |    5,240        |
|      19            |        0             |       0              |    5,240        |
|      20            |        0             |       0              |    5,240        |
|      21            |        0             |       0              |    5,240        |
|      22            |        0             |       0              |    5,240        |
|      23            |        0             |       0              |    5,240        |
|      24            |        0             |       0              |    5,240        |
|      25            |        0             |       0              |    5,240        |
|      26            |        0             |       0              |    5,240        |
|      27            |        0             |       0              |    5,240        |
|      28            |        0             |       0              |    5,240        |
|      29            |        5             |       1              |    5,235        |
|      30            |        1             |       1              |    5,239        |
|      31            |    2,508             |      48              |    2,732        |
|     STAT           |       26             |       1              |    5,214        |
+--------------------+----------------------+----------------------+----------------+

Prerequisite conditions in the IOA Manual Conditions file are held in 32 slots. The first 31 slots contain only conditions that have a date reference to a specific day-of-the-month.

The 32nd slot is used for prerequisite conditions that contain the STAT attribute, instead of a date.

The sample report shows that, for example, on day 31, 48 percent (2508/5240) of the entries are used.

Each Long condition takes up 2 slots.

Sample report using the VERIFY FILE HST parameter

=======================       HISTORY JOBS FILE        =======================
                                                                               
            DATA SET NAME:  PFVN.CTMD618.HST                                  
             DDNAME:         DAHIST                                            
                                                                               
                 GENERAL DATA                                                  
                  VOLUME SERIAL:        SYST09                 
                  DEVICE TYPE:            3390                 
                  ORGANIZATION:             PS                 
                  RECORD FORMAT:             F                 
                  RECORD LENGTH:         1,024                 
                  BLOCK SIZE:            1,024                 
                                                               
               CURRENT ALLOCATION                              
                  ALLOCATED RECDS:     100,023                 
                  DEFINED RECDS:       100,000                 
                                                               
               CURRENT UTILIZATION                             
                  INDEX RECDS:           6,138                 
                  USED RECDS:           84,051                 
                  FREE RECDS:            9,811                 
                  AVG # RECDS/JOB:        2.00                 
                  FREE SPACE-NEW JBS:    4,905                 

The 'AVG # RECDS/JOB: 2' means that, on average, two records on the History file are required to hold the information for one job.   Since the History file can hold a maximum of 100,000 records (DEFINED RECDS), it can hold approximately a maximum of 50,000 jobs. 'USED RECDS:' is 84,051, which means that there are approximately 42,025 jobs on the AJF file. In percentage terms, approximately 84% of the History file is used to hold jobs. Another six percent (6,138/100,000) of the History is used to hold index records. Therefore, a total of approximately 90% of the History is used for both jobs and indexes.

FREE SPACE-NEW JBS is calculated by dividing 9,811 (FREE RECDS) by 2.00. The result is 4,905. This means that theoretically 4,905 jobs can be added to the History file.   When jobs are copied from the AJF to the History file, index records are also created. Since approximately six percent (6,138/100,000) of the file is used to hold index records, this means that six percent must be subtracted from the 4,905 jobs that can be added to the History. This means that approximately 4,611 jobs can be added to the History file.

Sample report using the VERIFY FILE LOG parameter

=======================          IOA LOG FILE          =======================   
              DATA SET NAME:  BMCC.IOA6AC1.LOG
              DDNAME:         DALOG
   
                  GENERAL DATA
                     VOLUME SERIAL:        CACVD1
                     DEVICE TYPE:            3390
                     ORGANIZATION:             PS
                     RECORD FORMAT:             F
                     RECORD LENGTH:         6,200
                     BLOCK SIZE:            6,200
   
                  CURRENT ALLOCATION
                     ALLOCATED RECDS:      19,360

'ALLOCATED RECDS' is the number of records that were allocated for the Log file. For more information on IOA Log File Space Calculation, see the INCONTROL for z/OS Installation Guide.

Activating the IOAVERFY utility

A sample job can be found in the IOAVERFY member in the IOA JCL library.

IOAVERFY may also be activated by specifying any of its commands in the PARM field of the JCL EXEC statement. In that case, only a single command may be specified and the utility's SYSIN file is ignored. IOAVERFY may also be invoked from another program by passing it a command that conforms to the format of a PARM passed via the JCL EXEC statement. For example

          CALL CTMVRF10,(PARM)          ....
          DS     0H
PARM      DC     AL2(PARMLEN) 
PARMTXT   DC     C'DIAGNOSE AJF FORMAT'
PARMLEN   EQU   *-PARMTXT                    

The VERIFY ENQ function verifies the locking of IOA and Control-M files from a multi-systems environment.

To verify the locking (ENQ) mechanism

1. Submit the IOAVERFY job in all systems that share the same IOA and Control-M files. Ensure that the job names of the jobs are all different since they must all run concurrently.

2. Wait for the following question, prompting whether to start the test:

   VRFJ43I VERIFY ENQ: START CONTROL-M ENQ TEST? L(IST), Q(UIT)

   This question is issued by the jobs for each of the systems. You must wait for this message to be issued in all the LPARS participating in the test.

3. Once the above message is issued in all the LPARS participating in the test, reply L (List LPARs) to each one, to determine whether the utility is able to detect all the other systems on which IOAVERFY ENQ test jobs were submitted. When an LPAR is missing from the list, the operator must check that the job is actually running during the test. When the LPAR list received in response indicates that all the requested LPARs are participating, reply Q to terminate (but the Q reply must only be used after the list was successfully produced in all the LPARS participating in the test).

4. Verify that the list produced from each and every system has entries for all the others systems. A system that is not in the list, and the job with IOAVERFY was running on it, has a problem with the ENQ related definition.

IOAVERFY Return Codes

Table 84 IOAVERFY Return Codes

Trace Facility for IOAVERFY

If you encounter errors when running the IOAVERFY utility, you may be requested to run the utility with the TRACE optional parameter.

This parameter activates the trace facility of the IOAVERFY utility. If TRACE is specified, information about internal data areas is printed when the utility is run.

The TRACE parameter is specified in the EXEC statement of the utility in the following format:

//VERIFY EXEC IOAVERFY,TRACE=level

where level is the trace level to be activated. Valid value: 121.