Exits

This exit controls the use of the IOA Online facility.

IOAX006 and IOAX009 are twin exits. IOAX006 is invoked by the Online facility before the entry panel is displayed. When signing on to the Online facility through the online monitor, Exit IOAX009 is invoked first, followed by Exit IOAX006). When the Online facility is used without the online monitor, only Exit IOAX006 is invoked). These exits can be used to display a sign‑on window for users to enter their user ID and password or password phrase.

These sign-on modules determine and build the user’s identity for all subsequent actions. They both have similar structure, parameters, return codes and functionality. However, they work in different address spaces. The home address space is the primary address space requesting and receiving services from the online monitor address space using the cross‑memory facilities. Exit IOAX006 is invoked in the online monitor address space (when signing on through the online monitor). Exit IOAX009 is invoked in the home address space for the VTAM monitor, CICS, IMS, CA‑ROSCOE, and so on The control block that represents the user’s identity accompanies the user during the entire session with the IOA Online services facility.

In the online monitor environment, the ACEE control block is stored in the user’s TCB (Task Control Block) and the OCT (Online Control Table). MVS recognizes the ACEE as a standard control block to be used for authorization checks, so that task level security feature is achieved. If the ACEE is not stored in the TCB, either because module IOASE06 is not implemented or because the security package does not build an ACEE (for example, ACF2 in native mode), then all authorization checks for file access are performed using the identity of the online monitor address space. All authorization checks are performed using the correct user’s ACEE. If the ACEE is not built, it is quite likely that the security interface does not perform the authorization checks correctly.

MVS checks authorization for actions such as opening files by first checking if there is an ACEE in the current TCB. If it is found, authorization checks are performed using the TCB’s ACEE. If it is not found, MVS continues to search for the appropriate TCB until the ACEE associated with the address space is found.

In an environment where security is not implemented, Exits IOAX006 and IOAX009 can set the OCTUSER parameter, which is the reference parameter for all programs used as the identity of the current working user ID.

User Exit IOAX006T must be called when all IOA functions are performed under native CA‑ROSCOE address space.

This exit can be used to control update of the IOA Conditions file and the Control‑M Resources file. For further details, see the INCONTROL for z/OS Security Guide.

This exit controls entry to the IOA Online facility when working with the Online monitor (under CICS, VTAM, IMS/DC, TSO/ROSCOE cross memory options, COM‑PLETE and IDMS/DC).

User Exit IOAX009T must be called when CA‑ROSCOE communicates with IOA through cross‑memory services. All IOA functions are performed in the separate address space, which is the IOA Online monitor address space (OMON1).

In an environment where security is not implemented, Exits IOAX006 and IOAX009 can set a value for parameter OCTUSER, which is used by all programs as the identity of the current user ID.

For details, see the exit source for Exit IOAX009 and Exit IOAX006, and the description of Exit IOAX006 above.

This exit can be used to control or modify operator commands issued by utilities CTMOPR, CTDOPR and IOAOPR, by Control‑O and by the Control‑M and Control‑D and Control‑V New Day procedures.

Mainframe application server exit. This exit is called when a logon request is made by Control‑D/Page On Demand. The mainframe logon user ID and password from the Control‑D/WebAccess Server Communication Setup menu are passed to the exit. This exit is provided as a dummy load module. The associated security module is IOASE016.

IOA definition screen exit. This exit is invoked each time the user presses the Enter or PF03/PF15 key to exit an IOA definition screen. This exit is relevant for all IOA definition screens (Screens 2, 3.Z, 8, R, M, TR, TV, TP, BM, BR, OR, and C).

IOA Online Sysout or Report Viewing exit. This exit is activated as part of the Online viewing facility invoked for each sysout or report line that is to be displayed on the user terminal. For example, this exit allows translation of unprintable characters. This exit also provides additional features (for example, making special data invisible on the report).

This exit can be used to modify email attributes (such as To, CC, or From) before sending the email text as a sysout to the JES spool.

IOA Log exit. This exit is invoked before a message is written to the IOA Log file. The exit can be used to write the message on other files (SMF, and so on) or to accumulate message statistics.

This exit is invoked in all IOA panels each time an IOA user attempts to perform an operation on a PDS library or member in a PDS library. This exit can deny operations such as accessing a library, listing its directory and browsing, editing or saving a member. The exit is invoked when a user requests to edit JCL members or documentation data through Control‑M/Enterprise Manager. The exit checks authorization and either grants or denies the Edit (or Save) request prior to the performance of these operations by the Control‑M Application Server (CTMAS).

This exit can also be used to enable ‘Forced Browse’ of an IOA PDS member by denying the user Edit authority, but granting the user View (Browse) authority for the requested library or member.

Receives control for every message issued by the IOA Shout facility. This exit can modify the message text, change its destination, or suppress it. This exit can be activated by the Control‑O monitor, the Control‑M monitor or an IOA Functional monitor (used with Control‑M/Tape).

IOA Account Information Extraction exit. This exit is invoked by an INCONTROL product whenever account field information is required. Exit IOAX035 can extract the requested information from different parts of the account field depending on site customization. The exit can be invoked by CDAM when writing directly to a CDAM file, by Control‑D when decollating from a spooler, by Control‑M/Tape when a job’s account field is copied to the Media Database, and so on

IOA Access Method (IOAAM) exit. This exit is invoked whenever program IOADBF is executed, both as an independent utility program and when called internally by IOA Access Method I/O routines. This exit can check for which function it is being called and either grant or deny the request.

IOA translation exit. This exit contains four 256‑byte translation tables for the IOA online routines. This exit can be used to translate IOA screens to any language supported at the site. In addition, it can implement upper casing, special characters sets and other capabilities.

IOA Functional monitor exit. This exit is invoked before writing a request to the Functional monitor queue. The return code of the exit determines whether the request is or is not written. For performance reasons, Exit IOAX038 in the IOA LOAD library is a dummy exit.

IOA Page Separating exit. This exit is invoked during the creation of a CDAM file by a Control‑D decollating mission or during direct writing to a CDAM file by a job. The exit can control page separation in a CDAM file being created.

This exit is invoked for every job order that must be placed in the Active Jobs file. The exit is usually used to modify job production parameters. This exit has an associated security module CTMSE01. For further details, see the INCONTROL for z/OS Security Guide.

This exit is called a roof exit or driver exit because it can be used to activate as many as nine other Control‑M sample exits. Each sample exit activates a different function. The driver exit calls each sample exit in turn.

This roof exit is invoked during the Job Ordering process and receives the scheduling definition records. This roof exit enables the customer to combine several samples of Control‑M exits prefixed by CTMX001, each exit performing a specific processing function on job scheduling definitions.

Control‑M submission exit. Every line of the job stream submitted by Control‑M can be modified or deleted or replaced, and so on This exit has an associated security module CTMSE02. For further details, see the INCONTROL for z/OS Security Guide.

This exit is called a roof exit or driver exit because it can be used to activate as many as nine other Control‑M sample exits. Each sample exit activates a different function. The driver exit calls each sample exit in turn.

This roof exit is invoked during the job submission process and receives JCL cards for a submitted job. This roof exit enables the customer to combine several samples of Control‑M exits prefixed by CTMX002, each exit performing a specific processing function on job JCL records.

Control‑M SYSOUT scan exit. After the job finishes executing, every line of the job’s SYSDATA is passed to the exit. The main use of this exit is to detect user generated constants in the SYSOUT (such as program DISPLAY messages) and to affect the execution results of the current job accordingly.

SYSDATA is an IOA term used to designate the data in the following three job SYSOUT datasets: job log (console messages), expanded JCL, and system output messages.

This exit allows the user to change the defaults of the Control‑M scheduling algorithm by assigning weights to quantitative resources. In this way, Control‑M can be fine-tuned to achieve maximum throughput.

Exit CTMX005 is an integral part of the statistical data accumulation process. It is invoked by utility CTMJSA, which accumulates job statistical data from the IOA Log file. The exit can be used for the following purposes:

By default the machine ID (one-character) is automatically derived from the SYSID (four-character) and from information contained in CTMPARM, before Exit CTMX005 is invoked. Exit CTMX005 can override the machine ID.

Exit CTMX005 enables the user to incorporate additional statistical data from sources other than the IOA Log (for example, performance monitors) into the job execution statistics.

This exit is used to control access to the Active Jobs file, such as user authorization line commands (hold, delete, and so on). This exit has an associated security module CTMSE08. For further details, see the INCONTROL for z/OS Security Guide.

Exit CTMX008 and security module CTMSE08 are also invoked by the Control‑M Application Server (CTMAS) and the Control‑M Application Server Interface (CTMAPI).

CTMX008 may be invoked from the Active Environment screen (Screen 3) by using option X. For further details, see the Control-M for z/OS User Guide.

This exit is used to control job submission using the Quick Submit facility. For example, it can force the use of Control‑M for production job submissions under TSO.

This exit is invoked each time a line is displayed by the Control‑M Online facility in the Job Statistics screen (Screen 3.S). The exit can modify the line to be displayed.

This exit is invoked when a request is made to edit a JCL member under Screen 2 and Screen 3 of the Online facility.

This exit is invoked when a job has finished executing and has been assigned a Control‑M termination status.

This exit is called a roof exit or driver exit because it can be used to activate as many as nine other Control‑M sample exits. Each sample exit activates a different function. The driver exit calls each sample exit in turn.

This roof exit is invoked during job post-processing (that is, when a job finished its run and Control‑M assigns status ENDED OK or ENDED NOTOK to a job). This roof exit enables the customer to combine several samples of Control‑M exits that are prefixed by CTMX015, each exit performing a specific function on the post processing of a job.

The exit receives control each time the Tape Pull list utility (CTMTAPUL) attempts to resolve volumes for each DD statement of the job.

This exit receives control during the process of determining the anticipated elapse time of a job.

This exit receives control during the Control‑M external writer initialization phase.

This exit is called when a specific job starts and when it is still found running after its DUE-OUT time. The exit may be used to change the service class setting that the Control-M monitor, based on its search and matching algorithm, is about to reset the job to. For further details, see Workload management service class support.

Receives control under the Online interface whenever rule ORDER/FORCE is performed.

This exit is activated by Control‑M/Restart. It allows better control of Control‑M/Restart execution and can be used to interface with other products (for example, for checking non-standard datasets).

BMC provides several samples of CTRX001 exits in the IOA SAMPEXIT library to interface with various tape management products to extend the processing capabilities of Control‑M/Restart. For example, when used as an interface with Control-M/Tape, sample exit CTRX001T receives dataset DELETE requests and changes the Control‑M/Tape controlled dataset status to Immediate-Scratch (the default) or Deferred‑Scratch (if specified). Datasets with a status of Deferred-Scratch are expired by the next run of the CTTRTM Control‑M/Tape Retention Management utility. By default, this exit causes Control‑M/Tape controlled datasets to be scratched immediately (that is, without running the CTTRTM utility).

For more information see the chapter about operation considerations in the Control‑M/Restart User Guide.

This exit is called a roof exit or driver exit because it can be used to activate as many as nine other Control‑M/Restart sample exits. Each sample exit activates a different function. The driver exit calls each sample exit in turn.

For example, Exit CTRX001G can be used to activate two tape management products: CA-1 and Control‑M/Tape. The instructions below can be expanded to create a driver exit for more than two functions.

When Control‑M/Restart restarts a job containing Control‑M/Analyzer steps, Exit CTRX001Q calls the Control‑M/Analyzer Rollback facility to roll back those database variables that had been created by Control‑M/Analyzer steps that are to be restarted. The rolled back values are physically deleted from the Control‑M/Analyzer database and the space they occupied becomes available for new variable generations.

For information about how to invoke the Control‑M/Analyzer Rollback Facility using procedure CONTROLR, see Control-M/Analyzer.

The return codes are

0—normal termination

4—security violation

8—error opening database

12—internal error reading database record

16—error during CTBDBV call

Receives control for every mission that must be placed on the Active Missions file. This exit is usually used to modify mission production parameters. For details, review the INCONTROL for z/OS Security Guide.

Printer command exit. This exit receives control at the end of any chunk of lines that is sent by Control‑D to the spool. This exit can issue operator commands to set the printer for the coming chunk. (Contact BMC Customer Support before using this exit.)

Control‑D banner exit. This exit receives control at the beginning and end of every print mission or the beginning of a user in the bundle or for every report in the bundle or for every chunk in the bundle.

This exit produces banner pages at any level and in any desired format. It can also, optionally, produce an index of the reports in a bundle. For a detailed explanation of how to tailor and use the banner exit, see Tailoring Control-D Banner Exits.

This exit authorizes access to User Reports List files. When a user displays a list of reports, which can be refined by specifying report selection criteria, the list is based on the authorization assigned to that user. The user can then perform operations on these reports. However, the user can only view the decollated portions.

When Control‑D is installed, a default dummy exit is active. To facilitate installation and product testing, this exit does not enforce any security standards. When security standards are not enforced, all of the users can view all reports using option U. When Control‑D becomes operational and access to its Online facility is given to many users, BMC recommends that you use either security module CTDSE04 or sample User Exit CTDX004A.

Sample Exit CTDX004A retrieves security definitions from the Recipient Tree. The administrator can identify one or more recipients in the Recipient Tree with a TSO logon (or logon, CICS, VTAM, and so on) user ID. These authorizations enable users to see reports under Option U. The user IDs to be authorized must be specified in the AUTHORIZE field in the definition of each recipient that is authorized to view that ID’s reports. For more information, see the Recipient Definition screen in the online facilities chapter of the Control‑D and Control‑V User Guide. When a user is authorized in the Recipient Tree, it means that the TSO (or CICS, IMS, DC, and so on) user can view all the reports of that recipient and the reports of that recipient’s descendants in the Recipient Tree. The same TSO user ID (or other environment’s sign‑on ID) can be defined for more than one recipient in the Recipient Tree.

User ID identification in the AUTHORIZE field is performed according to the following rules:

The specified user ID can contain a number of ? characters. This wildcard character indicates any single character.

This exit receives every line to be printed by the Control‑D Printers Control monitor before actual printing takes place. The exit can prevent the line from being printed, change its contents or add more lines to the printed output. Examples of its use are Print page sequence numbers from the beginning of the printing mission (these numbers can be printed in the bundle index as well).

The actual printing is suppressed and the bundle is saved to a sequential file (for file transfer to RJE stations, and so on). For more information, see Control-D and Control-V

SMF exit. This exit receives control before each Control‑D SMF record is written to the SMF datasets. It can suppress the record or change it. The SMF record written by Control‑D is created for each combination of User or Report or Job name. Therefore, it allows accounting on each level – including accounting by report recipient. The number of pages is accurate (unlike SMF type 6 records that use approximate numbers).

This exit handles the problem of decollating reports that cannot be shown on the screen. Many sites use special character sets in reports that cannot be displayed on a screen but can be printed. It is possible under Control‑D to decollate such reports by specifying the name of a translation table before the string in the WHEN statement. Under this method, the user types what the user can see, and decollation takes place using the actual nonstandard spool representation.

This exit is used to control the update of the Active Missions file. For details, review the INCONTROL for z/OS Security Guide.

Print job tailoring exit. This exit can modify the contents of the print job prepared by the Control‑D print mission. For a description of printing mission workflow, see Control-D and Control-V

Backup job tailoring exit. This exit can modify the contents of the backup job prepared by the Control‑D backup mission. For a description of backup mission workflow, see Control-D and Control-V

Restore job tailoring exit. This exit can modify the contents of the restore job prepared by the Control‑D restore mission. For a description of restore mission workflow, see see Control-D and Control-V

Activated by utility CTDCA2P. This exit allows the user to change the contents of the records that are copied from the Active User Report List file to the Permanent User Report List file. The exit can also suppress the copying of any record.

Activated by utility CTDCP2A. This exit allows the user to change the contents of the records that are copied from the Permanent User Report List file to the Active User Report List file. The exit can also suppress the copying of any record.

Immediate print request banner exit. Used to print banners on immediate print requests from the Online viewing facility. The exit is similar in function to Exit CTDX003 (for more details, see Tailoring Control-D Banner Exits.

This exit receives every line to be printed by an immediate print request under the Online viewing facility. The exit can suppress the line, change its contents, and so on It is similar in function to Exit CTDX005.

This exit receives control during report decollation when a search is made in the Recipient Tree for a synonym that is identical to the recipient name found in the report (that is, when trying to identify the recipient of the page). The exit can determine whether they are equal or not. It is mainly used to define synonym ranges. For example: User BR129 must receive all postal codes from 10200 to 10399. For an example of the use of this exit, see the implementation hints chapter in the Control‑D and Control‑V User Guide.

Exit is obsolete. Use exit IOAX034 instead. See IOA Exits.

This exit is activated when CDAM parameter EXIT=YES is specified. The exit, which should be in a LINKLIST concatenation, receives control for every line written to the CDAM file. For a description of the exit, see the CDAM chapter in the Control‑D and Control‑V User Guide.

This exit is invoked when the Print Plan file is built. It can modify the contents of print plan records before they are written to the print plan file.

This exit is activated before the Recipient Tree is displayed (Screen T). Based on the library name and Recipient Tree member name, the exit determines if the Recipient Tree is to be edited or browsed.

This exit is invoked during decollation. It can be used to access default records in the Active or Permanent User files, to create user and SYSDATA records in the Active User file, to access each page of a report that is being decollated, or to access index values before they are added to the index file. When this exit is called, function INXMASK can be used to modify a mask value and function INXVAL can be used to "unify" index values by (for example) changing index values from mixed case to uppercase.

This exit is invoked by the Application server when a Control‑D/Page On Demand (POD) request is processed. It can be called to control access to the Control‑D Active User file and the Control‑V Migrated User file from Control‑D/Page On Demand. The mainframe logon user ID specified in the Control‑D/WebAccess Server Communication Setup menu is passed to this exit.

Security module CTDSE24 retrieves security definitions from the Recipient Tree. The administrator can authorize Control‑D/Page On Demand users to view mainframe reports by adding the appropriate mainframe logon ID to the AUTHORIZE field in the recipient definitions in the Recipient Tree. For more information about this topic, see the documentation for Security Module CTDSE24.

This exit is invoked by the Control‑D/Decollation Server Online environment under the T, M, A.Z and U.P screens.

Install the Control‑D File Transfer option.

Enables you to change attributes stored in a .cfg file before sending the file to Control-D/Delivery Server.

Sample User Exit CTDX030A replaces invalid special characters in the .cfg filename with the # character.

This exit is invoked during online processing of index files. It enables the user to retrieve index values from non-Control‑V index files.

The deferred print (printing mission) banner exit.

Bundle Open banner

Bundle Close banner

Beginning of a User (Recipient) Reports banner

End of a User (Recipient) Reports banner

Start of Report banner

End of Report banner

Start of Index Report banner

End of Index Report banner

Start of Subscribed Report banner

End of Subscribed Report banner

Header of Reports index

Format of each index line

Start Banner of immediate print requests

$$

$$

$1

$2

$3

Valid ASA codes include 1, +, ‑, and so on.

AFP (Advanced Function Printing).

Printing mission name.

This variable applies to deferred print banners only.

User (recipient) name.

Father of the recipient in the tree.

Report name.

Extended report name.

Printing Mission category.

Name of the job that produced the report.

Job ID (in JES) that created the report.

Current date (at printing time).

Current time.

Original scheduling date of the report.

Number of pages (for each type of banner and for the index).

Number of lines (for each type of banner and for the index).

Printing (JES) destination.

Last user (used in END banners).

Number of copies to be printed (for report banner and for the index).

Current printing copy (of the copies) (for report banner only).

From page printed.

Until page printed.

Name of the user who requested the print.

Name of the recipient from whom the report is received. The variable is applied to report banners only.

Decollation remark (in Active User List file).

Continuation of decollation remark (in Active User List file).

Continuation of decollation remark (in Active User List file).

Name of the ruler being used to print the report. (If no ruler is being used, no RULER is printed.)

Printing GROUP (from the printing mission definition).

The nth line of member $$GLOBAL (where n is an integer from 1 to 10).

The Control‑D Banners library contains member $$GLOBAL. This member can contain from 1 to 10 lines of data. When parameter %GLOBALn% is specified in the banner page, the nth line from this member is placed in the banner page.

This parameter can be used to distribute NEWS to all report recipients.

The nth line of a member whose name is identical to one of the following, depending on the value of the DATA parameter:

• the user name (not the synonym) in the Recipient Tree or the online UserID depending on the value of the ADDR parameter

• the first eight characters of the report’s name

• the first eight characters of the report’s REMARK field

Valid values for n are: 1 to 10.

The Control‑D Banners library can contain a member for each report, report recipient, or online user. This member can contain from 1 to 10 lines of data. When the %DATAn% variable is specified, the nth line from the corresponding member is placed in the banner page. Control‑D does not expect to find such a member for every user or report.

This parameter can be used for special distribution instructions for a user or a report. For more information see sample members BMIAMI and UNIDENT in the BANNER library.

The nth address line of the current user (recipient) in the tree. Valid values for n: 1 to 10.

The Control‑D Recipient Tree can contain address lines that can be inserted in the banner page of this user. Any text can be entered in these address lines. A maximum of ten address lines can be specified per user. Control‑D does not expect to find such lines for each user.

A common use of this parameter is for the user address, to which the bundle must be delivered.

Specifies whether an index bundle contents (global index) must be printed at the beginning of a printing mission (after the bundle banner page). Valid values are:

• ON - The global index is printed.

• OFF - The global index is not printed.

Optionally, it is possible to create a separate index for each user in the bundle. A bundle can contain reports for more than one user. Valid values are:

• ON - Each user receives an index at the beginning of each user bundle. However, if parameter INDEX in the Recipient Tree is equal to N (No), an index is not printed for this user.

• OFF - An index is not produced for each user. However, if parameter INDEX in the Recipient Tree is equal to Y (Yes), an index is printed for this user.

Specifies the maximum number of index records to be printed on a page. If LINECT=0 is specified there is no limit (that is, any number of records can be printed on a page).

Specifies whether an End User Index must be printed. An End User Index is an index printed at the end of a specific user’s report bundle that indicates which reports were actually printed (that is, it does not include reports that were not printed) for that user. Valid values are:

• Y (Yes) - End User Indexes are printed. However, if the INDEX parameter in the Recipient Tree is equal to N (No) or blank, an index is not printed for this user.

• N (No or blank) - End User Indexes are not printed.

Specifies where bundle banners must be printed.

Valid values are:

• Y (Yes) - The bundle start banner, bundle index, and bundle end banner are printed to the destination specified in the print mission.

• All other banners, indexes and reports are printed to the destination specified in the User Reports screen.

• For more information, see the DEST parameter in the online facilities chapter of the ControlD and ControlV User Guide.

• N (No) - All banners, indexes and reports are printed to the destination specified in the User Reports screen. For more information, see the DEST parameter in the online facilities chapter of the ControlD and ControlV User Guide.

Specifies whether Control‑D must print banners when printing to a sequential file instead of the JES SPOOL.

Valid values are:

• Y (Yes) - Print banners when printing to a sequential file.

• N (No) - Do not print banners when printing to a sequential file.

Specifies whether to implement PAGEDEF, FORMDEF and OUTPUT statements when printing banners for the report. These statements can be included either with the PRINT and CDAM parameters for this report, or in the OUTPARMS library. For a description of the OUTPARMS library, see Control-D and Control-V. Valid values are:

• Y (Yes) - Implement these statements when printing banners for the relevant report.

• N (No or blank) - Do not implement these statements when printing banners for the relevant report. Default.

Specifies whether the %ADDRN% and %DATAN% values of the on-line user that requested the report to be printed, or the %ADDRN% and %DATAN% values of the Recipient Tree recipient to which the report is sent, are printed in the report banners.

%DATAN% values are retrieved using the DATA parameter.

Valid values are:

• USER - The %ADDRN% and %DATAN% values of the recipient from the Recipient Tree are printed.

• OUSER - The %ADDRN% and %DATAN% values of the on-line user that requested the report to print are printed.

The first subparameter, m, specifies whether all the members in the Control‑D OUTPARMS library refer to job names, user IDs, print missions' names, or to reports' destinations. Valid values are:

• JOB – The members in the OUTPARMS library refer to job names.

• USER – The members in the OUTPARMS library refer to user names.

• PMIS – The members in the OUTPARMS library refer to print mission names.

• DEST – The members in the OUTPARMS library refer to report destinations.

The second subparameter, n, specifies whether search patterns on the identification lines refer to reports' names or to external writers' names. Valid values are:

• REPORT – The search patterns refer to report names.

• WRITER – The search patterns refer to external writer names.

Receives control for every mission order that must be placed in the Active Balancing file. For further details, see the INCONTROL for z/OS Security Guide.

Control‑M/Analyzer database exit. Controls all access (for read, write, or update) to Control‑M/Analyzer database files (group file, basic variable definitions files and variable generation files).

Control‑M/Analyzer Rule Activity file selection exit. This exit controls which users can see Control‑M/Analyzer invocations on the Rule Activity screen.

This exit is used to control access to the Active Balancing file. For example, the exit checks if a user is authorized to delete a mission using the Active Balancing Environment screen. For further details, see the INCONTROL for z/OS Security Guide.

This exit receives control for every message issued by the Control‑M/Analyzer Shout facility. It can modify the message text, change its destination or suppress it. It can also be used for special purposes, such as an interface to InfoMan or to Electronic Mail Systems.

Extract user-defined processing exit. This exit is used to process extracted information according to user-defined specifications during processing of a DO EXTRACT statement. For more information on extract processing, see the DO EXTRACT statement in the rule definitions chapter of the Control‑M/Analyzer User Guide, and member CTBX010 in the IOA SAMPEXIT library.

This exit processes each line outputted by the Control‑M/Analyzer DO PRINT statement before its contents are actually written as output.

Receives control for every Control‑M/Tape rule that is loaded during initialization. This exit can be used to modify rule parameters. Security module CTTSE01 is associated with this exit. For more information on this security module, see the INCONTROL for z/OS Security Guide.

Dynamic stacking exit. Receives control when the CTTSTK utility is executed, when dynamic stacking for a dataset must be performed, and when a new dataset is added to the Media Database.

SVC operation decision. Receives control at dataset open and can determine the process of this open request. The exit has an associated security module CTTSE03.

Dynamic definition exit. Receives control when a dataset or volume is to be dynamically defined to the Media Database. The exit has an associated security module CTTSE04.

Abend exit. When Control‑M/Tape is about to abend a job, this exit receives control and determines whether to allow the job to abend or to bypass Control‑M/Tape.

If you decide to implement this exit, do so with extreme caution. If you bypass Control‑M/Tape, tape protection is disabled for this job.

Media Database update validation. Receives control when a request to update the Media Database is received. Security Module CTTSE06 is associated with this exit.

Cycle processing exit. Receives control whenever the CTTRTM utility or CTTVTM processes a cyclic dataset. The exit can determine the processing parameters.

Robotic Tape library interface confirmation exit. Receives control before a request is made to the Robotic Library routine and before a retry is initiated for a request after a failure. The exit can allow or reject the request and can modify the maximum number of retries allowed for a request.

External label printing. Receives control either from the Control‑M/Tape SVC (using statement DO LABEL) during dataset creation, or from the Online environment (Screen TI or TC) by specific request. It can be used to format label structure and contents and/or specify whether to print labels. Security module CTTSE09 is associated with this exit.

Receives control when the Dynamic Dataset Stacking facility scans the Media Database for a stackable volume. This exit can be used to change search decisions (that is, to Reject or Accept a volume) or to supply a new volume to be used for stacking.

Enhances the functionality of the CTTSBD utility by allowing placement of output files to be dependent on stacking criteria that cannot be specified using utility parameters (for example, security constants). Information passed to this exit describes the input dataset name, the candidate output volume, and the datasets already residing on the output volume chain being considered as a location for the output dataset.

This exit examines the information provided and allows placement of the output dataset on the candidate output volume, rejects placement of the output dataset on the candidate output volume, forces placement of the output dataset on a scratch volume, grants the candidate output volume preferred status, or passes (that is, the exit does not influence CTTSBD processing).

Receives control under the Online interface whenever rule ORDER/FORCE is performed.

Receives control for every rule before it is loaded to the active environment. This exit can be used to modify rule parameters prior to rule loading.

Receives control before execution of each DO KSL/TSO/SHELL statement. This exit can be used to modify specific requests.

Receives control each time a user enters an Automation Options screen or attempts to perform an action in an Automation Options screen.

Receives control each time a user enters the Rule Status screen or attempts to perform operations in the Rule Status screen.