Introduction

This chapter contains the following topics:

• INCONTROL Products and IOA

  • IOA

  • INCONTROL

• Control-V Overview

  • A Schematic View of Control-V Operation

• Control-V Capabilities

• Integration with Other INCONTROL Products

• Control-V Components

  • Control-D Monitor

  • Printers Control Monitor

  • IOA Core and Control-V Repository

  • Online Facility

  • Recipient Tree

  • New Day Procedure

  • Compressed Dataset Access Method (CDAM)

  • IOA Archive Server

  • Introduction

  • Control-D/Delivery Server

  • Control-D Application Server

  • Reporting Facility

  • Shout Facility

  • Utilities

• Report Decollating Mission Parameters

  • Report Decollating Mission Definition Screen

  • Decollating Workflow

  • Balancing Pages Under Control-M/Analyzer

• Migration, Printing, Backup and Restore Mission Parameters

  • Migration Workflow

  • Printing Workflow

  • Backup Workflow

  • Restore Workflow

• Online Viewing

• Report Indexes

  • Index Hierarchies

  • Index Values and Masks

  • Multi-value Indexes

  • Indexes, Reports and CDAM Files

  • Index Design

  • Index Migration

  • Index Size

  • Using Indexes for Retrieval

  • Retrieval Methods

• Prerequisite Condition Concept

• IOA Calendar Facility

• Date Definition Concepts

  • System Date

  • Working Date

  • Original Scheduling Date

  • Date Standards and Date Field Formats

INCONTROL Products and IOA

The Control-V Quick Access Archive Viewing System is a component member of the INCONTROL by BMC family of products, a fully integrated suite designed to automate, manage and streamline operations on the z/OS mainframe. The INCONTROL family also includes client and server products that facilitate the automation of other platforms.

IOA

The Integrated Operations Architecture (IOA) is at the heart of the INCONTROL family of products. IOA has a common core of shared code as the foundation of its architecture design. The INCONTROL IOA environment has several inherent design advantages, including a common user interface and a shared data repository. A key feature of the IOA environment is its integrated application design, which includes:

• Integrated User Notification

• Management by Exception

• Integrated Scheduling

• Interdependency and Interrelationship Handling

• Common Help Facility

• Integrated Management Reporting

• Common Method for Sharing Information

• Unified Installation and Maintenance

• Unified Security Implementation

• Open Interface Design

INCONTROL

The INCONTROL family of products includes:

Table 1 List of INCONTROL Products

Control-V Overview

Control-V is an automated operations product that provides indexing, controlled migration to various storage media, selective retrieval by index values, and online viewing of computer generated reports. Control-V replaces the usage of Computer Output Microfiche (COM) and facilitates productive online report viewing while efficiently using the most cost effective media for report storage.

A Schematic View of Control-V Operation

Figure 1 Control-V Operations Schematic

Reports in conventional and compressed formats are automatically indexed by decollating missions that assign report pages or sections to appropriate users and other recipients. The reports and generated indexes can be viewed online before and after optional transfer to various storage media by migration missions. The indexes are utilized to quickly select and retrieve relevant report pages and sections.

Control-V Capabilities

Control-V increases the value and decreases the cost of computer generated information that must be retained for relatively long periods of time by:

• Assigning index values to report pages or sections.

• Generating alphabetical indexes that can be used to efficiently retrieve report pages or sections from all popular storage media.

• Automatically migrating reports and indexes from DASD to more cost–effective long term storage media.

• Providing powerful online viewing capabilities that include report editing and a mechanism for adding notes and comments.

• Using the Compressed Dataset Access Method (CDAM) to minimize the space required for storing reports on any supported media.

• Maintaining files that can be easily viewed online to obtain information about reports, users and Control-V activities.

• Enhancing the security and integrity of stored data.

• Integrating efficiently with all other INCONTROL products.

All Control-D features are also available. Control-D:

• Simultaneously automates the distribution and access control of Control-V indexed reports, through a hierarchical Recipient Tree.

• Enhances Control-V’s printing capabilities with a Print Bundling facility.

• Provides additional protection against the loss of essential data with automated backup and restore facilities.

• Transfers reports to PCs using Control-D/WebAccess Server.

• Enables reports to be viewed or printed by Control-D/WebAccess Server, through Control-D/Page On Demand.

• Supports predefined indexes of AFP reports that are used through Control-D/WebAccess Server Page On Demand.

Integration with Other INCONTROL Products

The functions of Control-V can be completely integrated with those of other INCONTROL automated operations products. The value of all installed INCONTROL products is enhanced as a result of this integration. Techniques and procedures learned for one INCONTROL product are easily transferred to the others. Some specific benefits of INCONTROL product integration for the Control-V user are:

• The Control-V indexing process is performed as part of the Control-D decollation process, saving both time and computer resources.

• The Control-D Recipient Tree can be used to automate the distribution and the access control (security) of Control-V indexed reports.

• Control-D report editing rulers and notepad facilities can be used when viewing Control-V’s reports.

• Control-D backup and restore missions are coordinated with Control-V migration missions to ensure timely backups and eliminate unnecessary data transfer operations.

• Control-M/Analyzer balancing operations can be performed automatically on Control-V pages.

• Reports can be downloaded to PCs by Control-D/WebAccess Server.

• The same powerful, user-friendly online facility is used for all electronic report monitoring, control and viewing.

• Prerequisite conditions in the IOA Conditions file and in the IOA Manual Conditions file can be applied to Control-V operations.

• The Compressed Dataset Access Method (CDAM) reduces the space required for Control-V files wherever they reside.

• The IOA Log file keeps a complete audit trail of important messages generated by all INCONTROL products.

• The IOA Reporting facility, including the KeyStroke Language (KSL), can generate reports about Control-V operations based on data in the IOA Log file and other sources.

• The same accurate, flexible Calendar facility is used by all INCONTROL products.

Control-V Components

The main components of Control-V and their interrelationships are discussed in the following paragraphs. The components described are:

• Control-D Monitor

• Printers Control Monitor

• IOA Core and Control-V Repository

• Online Facility

• Recipient Tree

• New Day Procedure

• Compressed Dataset Access Method (CDAM)

• IOA Archive Server

• Introduction

• Control-D/Delivery Server

• Control-D Application Server

• Reporting Facility

• Shout Facility

• Utilities

Control-D Monitor

Control-V and Control-D share the same monitor when both are installed. However, this monitor is referred to as the Control-D monitor in this guide.

The Control-D monitor executes mission (task) instructions defined by the users. The monitor is active in one computer at the site, usually 24 hours a day. It is normally activated as a started task.

The monitor’s primary functions are:

• Scheduling missions for execution based on the existence of prerequisite conditions, scheduling time limits, priorities, and so on.

• Decollating reports

• Indexing reports during decollation

• Preparing printing plans for the Printers Control monitor

• Migrating reports

• Backing up reports

• Restoring reports

• Notifying users (for example, TSO users, computer operator) of report events

• Adding and deleting prerequisite conditions

• Transferring reports to PCs (for users of Control-D/WebAccess Server)

Printers Control Monitor

The Printers Control monitor is active as an independent started task. It is initiated, controlled and terminated by the Control-D monitor. Its purpose is to actually perform the printing process.

The Printers Control monitor receives from the Control-D monitor a printing plan and the name of the printer assigned to the printing mission (printing mission = a bundle). The Printers Control monitor writes the bundled reports to spool in controlled "chunks" (the size of which is specified in the printing mission or in the Printer Definition in member CTDPARM). It tracks printing speed and makes sure the printer always has something to print, but not too much. This prevents overloading the spool with SYSOUTs that cannot be printed until much later.

The Printers Control monitor switches to a new chunk of lines when the printing characteristics in the user bundle change. It is possible to print sysouts with different printing characteristics in the same bundle.

IOA Core and Control-V Repository

Files that are shared by INCONTROL products are collectively referred to as the IOA Core. Files used only by Control-V are collectively called the Control-V Repository. The Control-V Repository consists of the following files:

• Active Missions File

• User Report List Files

The IOA Core consists of the following files:

• IOA Conditions File

• IOA Manual Conditions File

• IOA Log File

• IOA Calendar tables

• Dynamic Destination Table

Active Missions File

The Active Missions file contains report decollating missions (including indexing instructions) for all jobs that need to be decollated in the near future, are currently decollating. or have recently finished being decollated. It also contains migration, printing, backup and restore missions. It is a control file used by operations personnel to query and update the status of report processing tasks (missions).

User Report List Files

The User Report List files contain information on all reports a user can receive at any time or has received already. They act as a smart "index" for the user’s reports, providing a means for selecting reports, online viewing, and so on.

IOA Conditions File

The IOA Conditions file contains a list of prerequisite conditions under the control of Control-V.

IOA Manual Conditions File

The IOA Manual Conditions file contains a list of all prerequisite conditions that are expected to be added manually by the Control-V user (for example, START-MIGRATE, AR-BALANCED).

IOA Log File

All messages issued by INCONTROL products are written to the IOA Log file. The IOA Log file contains a complete audit trail of every event under the Control-V environment. Control-V logs every item of meaningful information about its operation, including statistics. The IOA Log screen displays the IOA Log file. The user can filter IOA Log file contents displayed in the IOA Log screen.

Mission Definition Libraries

Missions are defined as regular members in libraries (partitioned datasets). Usually a different library is allocated to:

• Decollating missions (including indexing instructions)

• Migration missions

• Printing missions

• Backup missions

• Restore missions

An unlimited number of libraries can be used (for example, due to security considerations). More information about defining missions is provided later in this chapter.

Online Facility

Users of Control-V communicate with the system via the Online facility, a set of integrated, interactive fill-in-the-blanks screens that provide access to Control-V information. Its operation is characterized by:

• Uniform ISPF-like screen handling conventions

• Menu-driven functions

• Dynamic PFKey assignment

• "All information on the screen" approach

• Concurrent management of many screens (including TSO applications)

The Online facility allows access to the Repository, to the IOA Core, and to indexes and compressed reports. It enables the user to see and update the following:

• Mission definition parameters

• Index definitions

• Report copy count, print destination, and so on.

• Sections of reports that belong to the user

• Status of active missions

• Status of prerequisite conditions under the supervision of Control-V

• IOA Log file

• Calendars

The Online facility can be activated under the following environments, regardless of whether the Control-D monitor is active:

• TSO (native)

• TSO/ISPF

• IMS/DC

• VTAM

• ROSCOE/ETSO

• IDMS/DC

• CICS

• COM-PLETE

TSO users can activate other online application programs (including ISPF) concurrently with the Online facility under the multiplication environment created by Control-V.

Control-V provides full color support when activated from a screen with extended seven-color support.

The Online facility is explained in depth in Online Facilities.

Recipient Tree

The list of all possible report recipients is organized as a tree. The Recipient Tree allows the users (recipients) to be grouped in a hierarchical structure correlating to the organizational chart of the recipients in the organization.

The Recipient Tree is defined and maintained by authorized users via the Online facility. It contains the user name, synonyms, a free text description, and so on. For sites using Control-D/WebAccess Server, it also contains fields relating to the downloading of reports to PCs.

It is possible to minimize the size of the Recipient Tree by listing only recipients whose entries include special information (for example, recipient's address, synonyms, Control-D/WebAccess Server authorization, $SYSDATA access, special default destination). For more information about this topic, see Decollation Without the Recipient Tree.

New Day Procedure

The New Day procedure is the primary mechanism used to issue (activate) new missions for the Control-D monitor. The New Day procedure is activated to determine which missions may potentially be activated on a specific date. A mission is not necessarily executed by the monitor. For example, a mission is not executed if it has prerequisite conditions that have not been satisfied.

The New Day procedure places the potential missions in the Active Missions file. The monitor reads the new missions from the Active Missions file and merges their data with the rest of the workload information under its supervision. The monitor executes the mission while taking into account the entire report distribution environment.

The New Day procedure is usually activated automatically by the monitor at a predefined time each day. The New Day procedure can also be activated manually by a job, TSO CLIST, ROSCOE RPF, or through the Online facility.

Figure 2 New Day Procedure

Compressed Dataset Access Method (CDAM)

Control-V stores SYSOUTs in compressed format using the Compressed Dataset Access Method (CDAM). This access method allows both Control-V and regular jobs to write or read reports to/from compressed datasets. The compressed datasets are regular sequential datasets containing reports in compressed format. They are automatically managed by the various Control-V components. For more information about CDAM, see Compressed Dataset Access Method (CDAM).

IOA Archive Server

The IOA Archive server provides services for viewing and printing reports migrated to storage media other than DASD.

Control-V migrates reports in compressed format from DASD to various storage media, including DASD. Reports migrated to DASD can be viewed without activating and using the IOA Archive server. Reports and indexes migrated to other storage media use the IOA Archive server for online viewing and Immediate Printing.

The IOA Archive server:

• Supports various media types based on user definitions.

• Responds to operator commands that modify media definitions during server operation to increase or decrease the service level or free resources for other jobs.

• Permits stopping and starting a media defined to the server without affecting ongoing work on other media.

• Supports concurrent requests to the same or a different media type.

• Implements queuing and synchronization mechanisms to optimize service level, improve media utilization, and reduce volume switch requests.

• Provides an internal caching mechanism to reduce media accesses and improve response time.

• Uses cross memory services to communicate with address spaces requesting its services.

Control-D/Delivery Server

Control-D/Delivery Server is a separately licensed product for report distribution to a Unix or Windows environment. If Control-D/Delivery Server is installed at your site, you can use its features to specify an external "logical destination" for Control-V reports. For more information about this product, see Control-D/Delivery Server.

Control-D Application Server

The Control-D Application Server provides access to Control-V User Report files by Control-D/WebAccess Server users of Control-D/Page On Demand. It is activated by the IOAGATE monitor.

Control-D/Page On Demand is a separately licensed add-on feature that is available in addition to the batch download method.

Control-D/Page On Demand enables Control-D/WebAccess Server users to view reports that reside on mainframe storage in real time. There is no need to replicate and send large production reports over the network to all potential online viewing users. At sites where Control-D/Page On Demand is active, reports are centrally stored and users retrieve only the pages they require.

For more information about Control-D/Page On Demand, see the Control-D and Control-V chapter of the INCONTROL for z/OS Administrator Guide.

Reporting Facility

Two types of reports are available:

• Reports that can be produced with the Online facility can also be generated in batch mode using IOA KeyStroke Language (KSL). For more information about the KeyStroke Language, refer to the KeyStroke Language (KSL) User Guide.

• A paper usage report that cannot readily be produced using the Online facility or KSL is provided by a special utility.

Some Control-V reports are produced from the information in the IOA Log file. Other reports are produced from the Active Missions file or User Report List files. Statistical information is gathered from the IOA Log file to produce statistical reports.

The Reporting facility can be activated at any time.

Shout Facility

When a problem or delay occurs, Control-V can notify appropriate personnel through the "Shout" facility, which can send messages to a variety of destinations including the operator console, a TSO user, and the IOA Log file.

Control-V can issue a Shout message if an exception occurs when a mission is submitted or executed (for example, a mission completes much before or long after its anticipated execution time).

Utilities

Utilities provided with Control-V are used to perform a variety of management functions and generate reports that assist in the efficient use of Control-V.

For information about batch utilities, see the INCONTROL for z/OS Utilities Guide. For information about online utilities, see Utilities under ISPF.

Functions that can be performed by utilities include:

• Adding, checking, or deleting prerequisite conditions.

• Loading (building) the IOA Manual Conditions file.

• Cleaning unneeded reports from User Report List files.

• Formatting Control-V files.

• Performing operator commands.

• Scheduling any type of Control-V mission.

Report Decollating Mission Parameters

Report decollating mission parameters (including indexing instructions) are defined using the Online facility. Formatted screens guide the user through the definition process. For details about how to define these parameters online, see Report Decollating Mission Definition Facility.

Report decollating mission parameters are stored in libraries (partitioned datasets). For each job, one member is kept containing one or more report decollating missions for that job. A job can be decollated differently depending on when it is run. The report decollating mission contains indexing, migration, printing and backup instructions in addition to decollating instructions for each of the job’s reports.

Any number of libraries can be defined. For example, each group of users can have its own library. This allows users to define report decollating mission parameters for their jobs without any breach of security.

Although each report decollating mission is defined once, it can be updated by authorized users at any time.

Report Decollating Mission Definition Screen

  ----- CONTROL-D/V CATEGORY DAILY                JOB  PLRPT010 ----------- (R.S)  
  COMMAND ===>                                                    SCROLL===> CRSR
  +-----------------------------------------------------------------------------+
    CATEGORY DAILY                  JOBNAME PLRPT010  GENERIC    MONITOR
    ===========================================================================
    DEF COPIES 01 LVL    USER UNIDENT              DEST          MAX COPIES
    ===========================================================================
    ON CLASS      = D         EXTWTR               DEST          FORM
    PRT COPIES 01 LVL 20 USER MGT                  DEST          MAX COPIES
        PRINT/CDAM PARMS =
    WHEN LINE 001 - 001 COL 014 - 046 PRINT Y REF NEXT PAGE N CONTID N AND/OR
         STRING = E M P L O Y E E S     R E P O R T
      DO NAME     = EMPLOYEES REPORT             LINE     COL     -
      DO USER     = *                     LVL    LINE     COL 064 - 074 S A T
                                          SYNONYM =       CONCAT =
      DO MIGRATE  = MIG003Y
      DO INDEX    = EMP_NUM                     LINE +000 COL 001 - 006 R Y G
             MASK = ######               LINE   003 - 060 COL 001 - 006 RC Y
      02 SUBINDX = EMP_NAME              LVL 02 LINE +000 COL 008 - 029
             MASK = *                    LINE   003 - 060 COL 008 - 029 RC Y
      02 SUBINDX = EMP_DEPT              LVL 02 LINE +000 COL 031 - 034
             MASK = ####                 LINE   003 - 060 COL 031 - 034 RC Y
         SUBINDX =                       LVL    LINE      COL     -
             MASK =                      LINE       -     COL     -     RC
    ===========================================================================
                              INDEX LEVEL DISPLAY
      EMP_NUM / EMP_NAME
      EMP_NUM / EMP_DEPT
    ===========================================================================
      DO BACKUP   = EMPBKUP
      DO PRINT    = EMP_PRT                               COL     -
  FILL IN REPORT DEFINITION. CMDS: EDIT, SCHED, SHPF, PATH               11.58.37

Decollating Workflow

A decollating mission allocates (parts of) reports to users authorized to receive them. A decollating mission also builds one or more predefined indexes for reports so that pages or sections of a report can be selectively retrieved for online viewing, printing, and so on.

The workflow of a decollating mission consists of the following stages:

1. The New Day procedure analyzes the scheduling parameters of the report decollating mission definitions and decides which decollating missions should be executed on that day. The selected missions are placed in the Active Missions file.

2. The Control-D monitor analyzes the mission’s runtime scheduling criteria (prerequisite conditions, time constraints, availability of the job on the output queue, and so on). If all scheduling criteria are met, the decollating mission executes.

3. Generic jobs that appear on a specific output class are automatically decollated. The generic job name can contain mask characters (for example, all jobs starting with NDX).

4. The monitor reads reports from the spool and writes them to Compressed Dataset Access Method (CDAM) files. Alternatively, reports can be written directly to CDAM files without using the spool.

5. The indexing process assigns pointers to each page, section or line of a report and identifies beginning and ending pages for each index value. For detailed information about index design and usage, see Report Indexes.

6. Decollating parameters assign report names and specify migration, printing and backup instructions.

7. When reports are decollated, prerequisite conditions can be added and/or deleted (thereby triggering other events or missions in the production environment) and messages can be sent to specified destinations via the Shout facility.

8. Decollation results are stored in the Active User Report List file.

9. After decollation, reports are available for printing, migration, online viewing, and so on.

Balancing Pages Under Control-M/Analyzer

At sites using Control-M/Analyzer, balancing operations can be performed automatically on Control-V pages. The Control-M/Analyzer Runtime environment is invoked by inserting a DO CTBRULE statement in the report decollating mission definition. Arguments may be passed to Control-M/Analyzer. For more information, see the discussion of Control-M/Analyzer interfaces in the Control-M/Analyzer User Guide.

Migration, Printing, Backup and Restore Mission Parameters

These parameters are defined using the Online facility. Formatted screens guide the user through the definition process. For details about how to define these parameters online, see Migration, Printing, Backup and Restore Mission Parameters.

The parameters are stored in libraries (partitioned datasets). For each mission, one member is kept containing one or more categories of the mission.

Any number of libraries can be defined. Usually, only one library is used for each type of mission because these missions are usually managed by one unit within the organization.

Although the missions are defined once, they can be updated by authorized users at any time.

Figure 3 Printing Mission Definition Screen

  ---- CONTROL-D CATEGORY DAILY                PRT MISSION STD      --------(M.S) 
  COMMAND ===>                                                    SCROLL===> CRSR
  +-----------------------------------------------------------------------------+
    CATEGORY DAILY                             MISSION STD        MONITOR
    OWNER    M22     TASKTYPE PRT              GROUP
    BATCH            SKELETON                  FREE               TIMEOUT
    OVERRIDE CLASS   DEST                      EXTWTR             FORM
    WRITER OPTION
    DESC     PRINTING MISSION FOR ALL STANDARD FORM REPORTS
    DESC
    ===========================================================================
    INCLUDE USER
    EXCLUDE USER
    INCLUDE ODATE
    EXCLUDE ODATE
    SORT PARAMETERS: 1-USER  2-JOB   3-REPORT NAME 4-CATEGORY  5-LEVEL 6-TREE
                     7-FORMS 8-CHARS 9-MODIFY T-TIME/DATE E-USER DEFINED
    ENTER SORT SEQ :
    ===========================================================================
    DAYS    ALL                                                   DCAL
                                                                       AND/OR
    WDAYS                                                         WCAL
    MONTHS  1- Y 2- Y 3- Y 4- Y 5- Y 6- Y 7- Y 8- Y 9- Y 10- Y 11- Y 12- Y
    DATES
    CONFCAL          SHIFT   RETRO N MAXWAIT 00
    MINIMUM          PDS
  PLEASE FILL IN MISSION PARAMETERS. USE "SHPF" TO SEE PFK DEFINITION    08.49.41

Migration Workflow

A migration mission moves one or more reports from one storage device (usually DASD) to another (usually tape, cartridge, silo or optical disk). The workflow of a migration mission consists of the following stages:

The Control-V New Day procedure analyzes the basic scheduling criteria of the migration missions and decides which migration missions should be executed on that day. The selected missions are placed in the Active Missions file.

The monitor analyzes the migration mission’s runtime scheduling criteria. If all scheduling criteria are met, the migration mission executes.

The migration mission scans the Active User Report List file for reports that should be migrated by the specified migration mission, but have not yet migrated. The name of the migration mission is specified in the Report Decollating parameters.

The migration mission prepares a list of CDAM datasets and index files to be migrated.

Control is passed to a job submitted from the Control-D monitor, a job under the Control-M Production Control System, or a job submitted by another production control system.

The migration job transfers all the files in the migration list to the target media, updates the report status in the Active User Report List file, and indicates the location to which each CDAM file migrated.

The monitor then uses the Shout facility to add and/or delete requested prerequisite conditions, and to notify appropriate personnel.

Figure 4 Migration Workflow

Printing Workflow

A printing mission is actually a bundle. It can contain reports for one or many users. The workflow of a printing mission consists of the following stages:

• The Control-V New Day procedure analyzes the basic scheduling criteria of the printing missions and decides which printing missions should be executed on the given day. A different printing or report delivery plan can be structured for every day – regular working day, end of the month, weekend, and so on. The missions are placed in the Active Missions file.

• The monitor analyzes the mission’s runtime scheduling criteria (prerequisite conditions, time constraints, priority, and so on). If all scheduling criteria are met, the printing mission starts executing.

• Control-V initiates a printing mission only if a printer is available to the Control-D monitor. The printing mission parameters contain the list of printers on which the bundle can be printed (for example, it is impossible to print a carbon paper report on a laser printer). Control-V selects one of the available printers. The printer is selected taking into account the printing priorities and speed of each printer. Control-V performs workload balancing between the printers to select the fastest printing order to achieve printing priorities.

• After a printer has been selected for the printing mission, a printing plan is prepared:

  • The printing parameters specify the users who should receive the reports. The Active User Report List file is scanned for all scheduled by as yet unprinted reports of the selected user (and that user’s descendants in the Recipient Tree). The copy count and printing destination are taken from the user records in the Active User Report List file.

  • The specific pages of reports to be printed are sorted according to the specified printing mission sort parameters.

• The printing plan is saved on a file (to allow for recovery and checkpointing) and can be viewed and controlled online.

• Control is passed to the Printers Control monitor to execute the printing plan. The Printers Control monitor sends to the spool a calculated amount of lines (for example, 10,000 at a time). The monitor periodically checks the status of the printing lines. When the printer is about to finish printing the lines, additional lines are placed on the spool. With this method, the spool contains the minimum number of lines required to keep the printer busy.

  • If new printing characteristics need to be used, the Printers Control monitor closes the currently printing "chunk" of lines and opens a new one with the new characteristics. Therefore, it is possible to mix different printing characteristics in the same bundle.

  • If the user has specified a special printing ruler for a report, the report is edited accordingly.

  The Printers Control monitor passes control to various exits which can change the printed lines, edit banner pages, print the bundle report index, and so on. Sample exits are supplied in the IOA SAMPEXIT library.

  When printing in LINE MODE or PAGE MODE on IBM AFP laser printers, special parameters and special Control-V supplied user exits are invoked to support the IBM PSF. These exits can be tailored for local use.

  When printing on a Xerox 8700/9700 printer, special Control-V supplied user exits are invoked to support DJDE parameters.

  The printing process can create System Management Facility (SMF) records which allow billing and charge back at the job level or at the report recipient level.

• When printing is finished, control is passed to the Control-D monitor. The monitor then adds and/or deletes requested prerequisite conditions and uses the Shout facility to notify appropriate personnel.

A printing mission can be scheduled and processed as a batch job, similar to a backup mission or restore mission. Batch printing jobs are executed via skeleton JCL kept as a library member. Batch printing can utilize or ignore the regular chunking mechanism. A time-out mechanism can be used to terminate the printing mission if it does not begin on time.

Backup Workflow

A backup mission backs up a group of reports for a specified number of days or generations. The workflow of a backup mission consists of the following stages:

• The Control-V New Day procedure analyzes the basic scheduling criteria of the backup missions and decides which missions should be executed on the given day (for example, different backup procedures can be employed for end-of-month processing versus the regular working day). The missions are placed in the Active Missions file.

• The monitor analyzes the mission’s runtime scheduling criteria (prerequisite conditions, time constraints, priority, and so on). If all scheduling criteria are met, the backup mission executes.

• The backup mission scans the Active User Report List file for reports which should be backed up by the specified backup mission and have not been backed up yet. The name of the backup mission is specified in the report decollating parameters.

• The backup mission prepares a list of datasets to be backed up. The list can be in one of the following formats:

  • DF/DSS

  • DF/HSM

  • FDR

  • DMS/OS

  • ASM2

  • ARCS

  • Site controlled format

  Control is passed to either:

  • A job under the Control-M Production Control System

  • A job submitted by another production control system

  • A job submitted from the Control-D monitor

• The job backs up all the files in the list in a fast and reliable manner since it employs the standard backup procedures used by the site.

• After the job finishes executing, it notifies the Control-D monitor that the backup has successfully completed, and lists the tape numbers used in the backup process.

Optionally, the monitor adds and/or deletes requested prerequisite conditions and uses the Shout facility to notify appropriate personnel.

Restore Workflow

A restore mission restores reports from tape or cartridge back to disk. The workflow of the restore mission consists of the following stages:

• The Control-V New Day procedure analyzes the basic scheduling criteria of the restore missions and decides which restore missions should be executed on the given day (for example, different restore procedures can be employed for end-of-month processing versus the regular working day). The missions are placed in the Active Missions file.

• The user can request a restore by selecting option R on the History User Report list screen. The user is prompted with a list of possible restore missions. After selecting the desired restore mission, the restore request is recorded in the "input queue" of the specified restore mission. In addition, a prerequisite condition is (usually) added to the IOA Conditions file. Each restore mission has at least one prerequisite condition that indicates to the restore mission that a restore is needed.

• The monitor analyzes the mission’s runtime scheduling criteria (prerequisite conditions, time constraints, priority, and so on). If all scheduling criteria are met, the restore mission executes. Restore missions are usually triggered by the associated prerequisite condition together with a time interval (for example, two hours between each restore mission).

• The restore mission prepares restore parameters for all files in its queue (that is, for all restore requests that have accumulated since the last executed restore).

• The restore mission prepares a list of datasets to be restored (and their tape numbers). The list can be in one of the following formats:

  • DF/DSS

  • DF/HSM

  • FDR

  Site-controlled format

  • DMS/OS

  • ASM2

  • ARCS

  Control is passed to either:

  • A job under the Control-M Production Control System

  • A job submitted by another production control system

  • A job submitted from the Control-D monitor

• The job restores all the files in the list in a fast and reliable manner since it employs the standard restore procedures used by the site.

• The restored User Report entries are copied from the History User Report List file to the Active User Report List file, making them available for online viewing.

• After the job finishes, it notifies the Control-D monitor that the restore has been successfully completed, and lists the tape numbers used in the restore process.

Optionally, the monitor adds and/or deletes requested prerequisite conditions and uses the Shout facility to notify appropriate personnel.

Online Viewing

The User Reports Entry Panel enables end users (that is, report recipients) and operations personnel to access Control-V report information. Users can retrieve a list of user reports based on the following selection criteria:

• Report name

• User

• Date From and To

• Jobname

• Report status

• Show Migrated

• Index

• Value

• Display Type

• Bypass Panel

Many operations can be made on the list. The most significant of these operations is the online viewing function that enables the user to select report pages by hierarchical index values and view these pages online. Hard copy can always be requested by the online viewer at any time.

For more information, see Report Indexes and Using Indexes for Retrieval.

Figure 5 Online Viewing Operations

Report Indexes

Indexes are defined using the DO INDEX statement in the Report Decollating Mission Definition screen (option R in the IOA Primary Option menu).

An index definition is in one of the following formats:

• LINE

• VAR

A LINE format index definition consists of the following:

• A specified line.

• A column specification, which must be one of the following:

  • A specified column range.

  • A column relative to the column identified by the mandatory MASK value.

• An index type.

A VAR format index definition consists of the following:

• A specified variable.

• An index type.

There are three index types

• Page Level: Every page of the report can be indexed by one value. Page Level is mandatory in a VAR format index definition.

• Record Level: Every line of every page in the report can be indexed by one value.

• Continuous Record Level: Identical to record level except records without an index value are indexed by the last previous value found for this index.

During the report decollation process, values for each index are extracted as a text string, either from the lines on the report page or from a specified variable. These index values enable users to determine if desired information is available, and to retrieve only the desired information for online viewing or printing.

Index Hierarchies

Main indexes and a hierarchy (tree structure) of subindexes can be defined for each report. Each unique sequence of indexes in a hierarchy constitutes an index path. An index path can have both page level and record level indexes. For more information about index specification, see DO INDEX: Decollating Parameter (Decollating Mission).

Index Values and Masks

An optional index mask can be defined for each page level index and subindex. An index mask must be defined for each record level index and subindex. If a relative column is specified, an index mask must be defined for each index and subindex.

If the index value for a report is not all contained in one range, or is not contained in the report at all, use a variable in defining the index.

When pages in a report have more than one format, a specified line or column range may contain values for a particular index on some report pages, but may not contain index values (or may contain values for a different index) on other report pages. Therefore, when defining indexes for reports with multiple page formats, it is necessary to ensure that the text strings in a specified line or column range are in fact appropriate index values. This can be done by defining an index mask.

An index mask definition specifies a mask value and a column range in a line range. If the content of the mask line or column range in the report matches the specified mask value, the content of the index line or column range of the report is validated as a genuine index value. The line or column ranges for the index value and its mask value may be identical, may overlap, or may have no overlap.

Usage of mask definitions is not limited to reports in which pages have various formats. Mask definitions can be useful in other situations. For example, each page may have the same format, but the report page may only be of interest when the contents of a specified location matches a mask. In this case, extraction of index values can be limited to those situations in which the mask criteria are satisfied.

Multi-value Indexes

You can define a multi-value index that contains multiple values for more than one index value in an index within:

• The same page in a page level index.

• The same line in a record level index.

It is possible to access the indexed page or line or a report using any multi-value. There are three ways to create a multi-value index:

• From a range according to a mask.

• From the multiple value ranges.

• With separate sub-index values.

For more information, refer to Multi-value Indexes.

Indexes, Reports and CDAM Files

Index values for each index are extracted from the report by the decollating mission.

Each index value points to all report pages that contain that index value in the defined index location. Each logical report page or section is pointed to by only one value in a given index. Any page without an value that can be indexed is treated as a continuation of the previous pages in that report section. For this reason, a request to view a report based on index values may retrieve one or more consecutive or nonconsecutive report pages.

Each index value points to relevant report pages or sections in a single CDAM file. Therefore, WHEN statements that contain DO INDEX statements should select report pages that are in the extents of a single CDAM file. For information about WHEN statements, see WHEN Statements. For information about CDAM files, see Compressed Dataset Access Method (CDAM).

Index Design

Well designed indexes can enable users to retrieve important information without viewing the report itself. For example, if a bond portfolio report with one bond per page contains a redemption date field, indexing that field produces a sorted list of all bond redemption dates which can be displayed in the Values of Index panel, without retrieving the report.

Page Level Indexes

Page level indexing should be used whenever a report page can be adequately indexed by one value per index per report page. The bond portfolio report described above may have separate indexes for bond name, redemption date, and the responsible securities analyst. Page level indexing is appropriate for each of these indexes.

Record Level Indexes

By contrast, an inventory report sorted by part number may have 20 to 30 different part records listed on each report page. Indexes for part name and part number require multiple values per report page. Record level indexing is appropriate for each of these indexes.

Continuous Record Level Indexes

Another version of the same inventory report may be sorted by a storage area identifier which (later) occurs only in a single record that precedes the records of all parts that are stored in that area. Continuous record level indexing is appropriate for the storage area index so that the applicable storage area value points to the records of the parts that are stored in that area.

Index Paths

Control-V enables users to retrieve parts of reports based on any predefined index path. Separate index paths should be defined for each meaningful way to retrieve a report page or section.

It is recommended that every index be given a unique name. For more information about report and index design, see Report Design and Index Design.

Index Migration

A maximum of three main indexes per report can remain in DASD when a report migrates. A main index and its subindexes remain DASD resident or migrate as a unit. For more information about report and index migration, see the Control-D and Control-V chapter of the INCONTROL for z/OS Administrator Guide.

Index Size

Index size is a function of index field width, the number of different index values that occur in the report, and how the report is sorted. Sorting affects index size because each index entry contains a separate pair of pointers to the beginning and ending pages of each nonconsecutive occurrence of the index value in the report.

Using Indexes for Retrieval

Report pages can be retrieved for viewing or immediate printing regardless of where the report is stored. When index values are included in report selection criteria, only those pages or sections of the report that are pointed to by the specified index values are retrieved.

• Online screens in the User Reports facility enable the user to:

• Identify the report from which pages should be retrieved.

• Identify the indexes whose values should be specified as selection criteria.

• Specify a value for the selected indexes.

• Specify viewing or immediate printing for the selected report pages.

Retrieval Methods

There are two basic methods of specifying index values for report retrieval:

Table 2 Index Value Specification Methods

In both methods, available index values are displayed alphabetically in a Values of Index panel. Values in the panel can be specified for use in retrieval.

For detailed information about these methods, Using Indexes for Report Retrieval.

Prerequisite Condition Concept

The prerequisite condition concept is one of the fundamentals of the INCONTROL production environment. A prerequisite condition is a user-defined descriptive name given to a situation, event, or condition.

Prerequisite conditions are either created by previous jobs, created by Control-V missions, or created manually via the Online facility. A job’s reports is decollated or migrated only when all prerequisite conditions defined as necessary for the execution of the mission exist.

The following are examples of prerequisite conditions:

Table 3 Prerequisite Condition Examples

A list of prerequisite conditions can be specified in the mission definition parameters. Control-V allows mission execution only if all the prerequisite conditions exist. For example, a printing mission executes only when all prerequisite decollating jobs have run successfully.

Figure 6 Decollating Jobs Prerequisite Conditions Example

Prerequisite conditions can be used to create any kind of dependency (for example, mission to mission, mission to job, manual operations, creation of a dataset).

Prerequisite conditions can be added or deleted in many ways:

• By using the Online facility.

• By specifications in the mission’s definition parameters.

• By an application program or a job step using a supplied routine or utility.

• By the Control-M Production Control System.

The Online facility is used to add conditions like AR-BALANCED. These prerequisite conditions represent manual operations. They can be added by any authorized user.

The most common way of adding or deleting a condition is by defining it in the mission definition parameters. A list of prerequisite conditions to be added or deleted when the mission finishes OK can be specified by the user. For example, it can be a simple condition like EJ18FOR-DECOLLATED, or it can represent a more complex situation like SALARY-FINISHED.

Prerequisite conditions can also be used as a trigger for messages; for example, the user can tell Control-V to send a highlighted, un-rollable message to the operator console whenever the condition CHECK-NOT-BALANCED exists.

Prerequisite conditions are strictly under the user’s control. Any number of conditions, and therefore any number of dependencies, can be created. Prerequisite conditions can be used for any purpose.

IOA Calendar Facility

Specification of scheduling criteria for missions can be simplified by using calendars. A calendar is a defined schedule (for example, every day except Saturdays and Sundays of each month) that can be applied to missions.

Calendars are defined in the IOA Calendar facility. Each calendar is given a unique name that can be specified in mission definitions. A particular calendar (that is, a unique set of dates) only needs to be defined once.

Specifying a calendar’s name in a mission definition enables that mission to be scheduled on the dates specified in that calendar.

Two types of calendars can be defined: regular and periodic.

• Regular calendars consist of scheduling dates or days (of the week) that can be defined according to monthly patterns.

  Table 4 Regular Calendar Example

  Parameter	Description
  WEEKDAYS	Schedules missions on every weekday (Monday through Friday) in each month.
  WEEKENDS	Schedules missions on every Saturday and Sunday each month.
  QUARTERLY	Schedules missions on the last date in each quarter: March 31, June 30, September 30, and December 31.

  Regular calendars are especially useful when many missions have the same schedule. Defining that schedule once in a calendar, and specifying that calendar’s name in the mission definition of those missions, makes it unnecessary to individually define that schedule in the mission definition of those missions.

• Periodic calendars are especially useful when scheduling dates do not conform to fixed date/day of the week/month patterns.

  PAYCAL – Schedules missions (for example,payroll) every other Wednesday. Scheduling occurs on the first, third, and (if there is one) fifth Wednesday of some months. Scheduling occurs on the second and fourth Wednesday of other months.

The IOA Calendar facility is described in IOA Calendar Facility.

Date Definition Concepts

IOA uses the following types of date definitions:

• System date

• Working date

• Original scheduling date

System Date

This date is supplied by the operating system. It should be the actual calendar date starting and ending at midnight.

Working Date

Many sites do not use midnight as the formal time for changing to a new date. A site, for example, may decide that transactions between 13:00 and 24:00 belong to the next day’s transactions. In this case, the working date changes at 13:00 and not at midnight.

The working date (that is, the time at which a date changes at the site) is defined in the Control-D installation parameters. New Day processing generally begins at the start of the new working date.

Original Scheduling Date

The original scheduling date (ODATE) is the working date that Control-V assigns to a mission, a message or a condition.

Every "item" under Control-V is assigned an original scheduling date. For missions, it is the date on which the mission should be scheduled for execution. For messages, it is the original scheduling date of the mission that generated the message.

The importance of the ODATE can be illustrated by the following example:

The computer is down for two days. When it is brought up on the third day, there is a two day backlog of jobs to be run, in addition to the jobs of the current day. It is desired that the jobs in the backlog have a run date matching their intended (original) scheduling date, not the working date when the computer was brought up. This is achieved by specifying the ODATE as the run date. The jobs are then executed as if they had run on their originally scheduled working dates.

Date Standards and Date Field Formats

Date standards and date field formats use either Gregorian or Julian dates.

Gregorian Dates

Gregorian dates are indicated in the guide by the following symbols:

Table 5 Gregorian Date Formats

Whether a field holds a 4-character date (month and day), a 6-character date (month, day and 2-digit year) or an 8-character date (month, day and 4-digit year) depends on the field. However, the format of the 4-character, 6-character or 8-character date depends on the installation defined date standard.

INCONTROL products support three date standards for Gregorian dates. Each standard has an 8-character format, a 6-character format and a 4-character format. Only one Gregorian date standard is defined at any site.

These supported Gregorian date standards are described in the chart below.

Table 6 Gregorian Date Standards

Julian Dates

Julian dates are indicated in the guide by the following symbols:

Table 7 Julian Date Formats

Julian date fields have either three, five, or seven characters. Whether a Julian date field holds a 3-character date (day of year only), 5-character date (day of year and 2-digit year) or a 7-character date (day of year and 4-digit year) depends on the field definition. However, the format of the date depends on the installation defined date standard.

For example, the Julian date for the calendar date of 28 February 2000 would be represented in jjj or ddd format as 059, in yyjjj or yyddd format as 00059, and in yyyyjjj or yyyyddd format as 2000059.