Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 2. Information Technology

Chapter 5. Systems Development

Section 4. Document Standards (Cont. 1)

2.5.4  Document Standards (Cont. 1)

2.5.4.7 
Run Description Documentation

2.5.4.7.4 
Preparing Run Descriptions

2.5.4.7.4.2  (06-01-2002)
List of Files Accessed

  1. Prepare a list of the files which may be accessed by this run. Include both the file number and the file name. The list is divided into three parts: input files, output files, and I/O (input/output) files. Additional information may be included, such as "inquiry only " . This list is to include all files necessary to execute the run, such as print files, and runstream files.

  2. Describe briefly each output file produced by the run. Input files need only be described when they enter the system for the first time. Avoid redundancy by references to files that have already been described.

  3. Each description must contain:

    • File number;

    • Types of records contained in the file;

    • Manner in which records are batched, blocked, or grouped. Include a diagram when it is helpful; and

    • A statement about the sequence of records must be made, even when the file is in random order.

2.5.4.7.4.3  (06-01-2002)
Internal and External Controls

  1. Describe the necessary controls, including any balancing instructions for utilizing the controls:

    • Internal Controls—any balancing schemes which have been developed to verify the validity of processing within a run.

    • External Controls—the information necessary for operations personnel to perform inter-run balancing, including which output file contains the control data, what control data are output, and to what element each item of control data should balance with.

2.5.4.8  (06-01-2002)
Data Specification Documentation

  1. This specification provides the generic information, contents, and organization for data specifications.

2.5.4.8.1  (06-01-2002)
Data Specification — Standard

  1. Data Specifications are required for each data structure.

2.5.4.8.2  (06-01-2002)
Data Specification — Purpose

  1. Data Specifications are used to illustrate and define the data structures processed by the computer runs in the system.

  2. Data structures are arranged hierarchically as follows:

    • Files — the physical, external interlaces between runs, each consisting of a set of related records;

    • Records — a logical I/O (input/output) unit; e.g., the data referred to by a READ or WRITE instruction;

    • Groups — a set of related items, defined together for convenience in manipulating as a unit (such as a date defined to be a group consisting of year, month, and day); and

    • Item — an element or field; data which is not further decomposed.

2.5.4.8.3  (06-01-2002)
Data Specification — Contents and Organization

  1. The Data Specifications document will contain, in this order:

    • File descriptions/record layouts; and

    • Appendices, when necessary.

  2. Computer Specialists will sequence the file descriptions and record layouts by record reference number in ascending order. File descriptions will appear in this sequence under record reference number SSS/RR(R)/FF/000, where SSS/RR(R)/FF = file number.

  3. Data Specification headers will contain the system name, responsible organization, operational date, revision date and the file or record reference numbers (see Exhibit 2.5.4–7).

2.5.4.8.4  (06-01-2002)
Preparing Data Specifications

  1. This documentation provides the instructions for preparing the data specifications.

2.5.4.8.4.1  (06-01-2002)
Record Reference Numbers

  1. Assign a reference number to each record contained in a file shown on the Schematic Diagram. This number is developed from the file number. An example of the format is "SSS-RR(R)-FF-NNN" where:

    • SSS = System-ID;

    • RR(R) = run number;

    • FF = file number; and

    • NNN = record reference suffix.

  2. The record reference number serves as a cross-reference document. Therefore, only one record reference number will be assigned to a given record format (see Exhibit 2.5.4–8).

  3. The record reference suffix "NNN " is not the same as the optional variable indicator " VVV" , which is added to a particular file number. The record reference suffix is used to form the record reference number which identifies individual record formats. The record reference number is only used in Data Specifications to distinguish records from one another. The "VVV" suffix, referred to above, will not be necessary in this case.

2.5.4.8.4.2  (06-01-2002)
File Descriptions

  1. Describe the file briefly. Include any information about the file which is relevant, such as:

    • File name;

    • File format;

    • Manner in which records are batched, blocked or grouped;

    • Access method; or

    • Sequence of records in the file (including random).

  2. Any other information describing the file may be included.

2.5.4.8.4.3  (06-01-2002)
Record Layouts

  1. Each record layout will be prepared in a format similar to that shown in Exhibit 2.5.4–9. A record layout describes the structure of a record, showing its component groups and elements (items). The format may be developed manually, or tools such as a word processor or an automated Data Dictionary may be used.

  2. Record layouts will be prepared for all records contained in files identified in the Schematic Diagrams. (If screen displays and printer layouts are developed in Analysis, do not repeat their definition in the record layouts.)

  3. All layouts must contain the following fields, regardless of the developmental method used:

    • Record name — as heading for the layout;

    • Element numbers for the elements;

    • Name — elements may be indented under a group name;

    • Starting position — relative to the first position of the record;

    • Length;

    • Type (group, numeric item, alpha); and

    • Remarks, including editing rules, valid ranges, etc., and separate or imbedded signs.

  4. If the Automated Data Dictionary is used as a tool to aid in the definition of record structures, refer to the Data Dictionary section of this manual.

2.5.4.8.4.4  (06-01-2002)
IBM Core Record Layout

  1. An IBM core record layout and IBM layout reference shall conform to the formats depicted in Exhibits 2.5.4–10 and 2.5.4–12 respectively, and must be developed using computer aided tools, e.g., electronic media, automated data dictionaries, spreadsheet programs, or other technologies.

  2. An IBM core record layout comprises a layout and, if required, a layout reference. The layout describes the structure, groups, and fields that constitute a record. Instructions for completing the IBM core record layout can be found in Exhibit 2.5.4–11.

2.5.4.8.4.5  (06-01-2002)
Detailed Definitions

  1. The requirements mentioned for the System Description, System Schematic, Run Description, Data Specifications, and Computer Operations Handbooks are needed to define the physical data. This data must be documented in the Servicewide Data Dictionary.

  2. However, what the data actually is needs to be defined somewhere. A suggested means for detailed definition is a local data dictionary that is either manual or automated. Although the local data dictionary is used to further describe the data, the requirement to update the Servicewide Data Dictionary still exists.

  3. Consistency is important; do not introduce redundancy by repeating in the local data dictionary information that is already contained in the Servicewide Data Dictionary.

2.5.4.9  (06-01-2002)
Computer Operations Handbooks (COH)

  1. This documentation provides details on the various components of the COH.

2.5.4.9.1  (06-01-2002)
COH — Standard

  1. A Computer Operations Handbook (COH) is required, which contains a complete set of operating instructions for each computer run in the system.

2.5.4.9.2  (06-01-2002)
COH — Purpose

  1. It provides detailed instructions to a computer operator for the proper execution of a run.

  2. The Computer Operations Handbook is a required deliverable for the Programming stage of development. However, Computer Operator Messages should be considered first in the Design stage of development. Updating of the COH should be throughout the program development life cycle. Among the items described in the operating instructions are set-up instructions, messages between the program and the operator, the input/output devices used and each file’s name and number.

2.5.4.9.3  (06-01-2002)
COH — Organization

  1. Arrange instructions in System—ID/run number sequence.

  2. Document the computer operating instructions in accordance with the following standards and the instructions specified in Exhibits 2.5.4–13 through 2.5.4–18.

    1. Assemble the operating instructions for each run as a complete set.

    2. Place operating steps in the proper sequence and cross-reference steps when applicable.

    3. When a run contains options, document with separate operating instructions for each option.

    4. Only one set of operating instructions are to be provided for programs which only differ by their file contents.

2.5.4.9.4  (06-01-2002)
COH — Forms

  1. Operating instructions forms are published as a full page in the Computer Operations Handbook.

  2. Examples of forms, which are to be used in compiling the Computer Operations Handbook, are shown in Exhibits 2.5.4–13, 2.5.4–15 and 2.5.4–17. These examples include the following forms:

    Form
    Number     		Form
    Title
       
    3864 I/O UNITS
    3864–A SET-UP INSTRUCTIONS
    3864–D MESSAGE LIST

  3. Comparable documents which convey similar information may be used if those listed do not satisfy requirements or are unavailable. Refer to the corresponding system-specific manuals for instructions when preparing those forms unique to particular systems. Instructions for completing the listed forms are in Exhibits 2.5.4–14, 2.5.4–16, and 2.5.4–18 at the end of this document.

  4. Include only those forms that are necessary in the Computer Operations Handbook.

2.5.4.9.5  (06-01-2002)
COH — Language Considerations

  1. Use language that is clear and concise.

  2. Be consistent in the use of abbreviations, formats, names and terminology, both within the Computer Operations Handbook and between the COH and other related documentation.

  3. Avoid excessive abbreviations to insure readability.

  4. Write the instructions to be implemented by the operator in simple imperative sentences.

2.5.4.9.6  (06-01-2002)
COH — Paging

  1. Assign page numbers in unbroken sequence from 1 through "n" for each run, regardless of the number of run options involved.

  2. Enter the page number on each page.

  3. When run options are not involved, place the required pages in the following sequence:

    • I/O Units

    • Set-Up Instructions

    • Message List

  4. When options are involved, document each option on separate pages. Place all the pages for each option together and place one option behind the other.

  5. When inserting a new page between existing pages, use a decimal page number, e.g., 5.1.

2.5.4.9.7  (06-01-2002)
Operator Messages

  1. Keep operator queries or messages to a minimum.

  2. Console messages should require operator intervention or affect the continued operation of the runstream.

  3. Information messages should appear on the printed listing only.

  4. Console messages should have clear, concise explanations that the operator can follow easily.

  5. If a computer run does not go to EOJ, include a console message to the operator that the contact point designated by the "User-Service Agreement" should be notified.

2.5.4.9.8  (06-01-2002)
IBM COH Guide

  1. An IBM Computer Operations Handbook (COH) Guide shall conform to the format depicted in Exhibit 2.5.4–20. This guide is applicable to the IBM Tier 1 mainframe (except for the Automated Collection System), and applies to all computer specialists developing IBM or IBM-compatible programs.

  2. The IBM COH Guide consolidates the COH, run descriptions, and file specifications into one unified and standard document. Instructions for completing the IBM COH Guide are found in Exhibit 2.5.4–19.

Exhibit 2.5.4-1  (06-01-2002)
Project Library Contents Development Phase

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-2  (06-01-2002)
Sample System Description Outline

SYSTEM NAME:      
SYSTEM ID:     OPERATIONAL DATE:
RESPONSIBLE ORG:     REVISION DATE:
       
  SYSTEM DESCRIPTION  
       
  A. General Description  
       
  1. Scope  
  2. Background  
  3. External Interfaces  
       
  B. Operating Environment  
       
  1. Equipment  
  2. Controls  
  3. Security/Privacy Requirements
  4. Failure Contingencies
       
  C. Runs/Programs  
       
  1. Number and Type  
  2. Optional Run Streams
  3. Data Base Characteristics
       
  D. Miscellaneous  

Exhibit 2.5.4-3  (06-01-2002)
Schematic Diagram—Title Block

The title block will appear on every page of the Schematic Diagram. The following instructions are keyed to the illustration below:
Key Item Instructions
A Title The words "Schematic Diagram" must appear on each page, followed by a descriptive title, such as "SC Daily Processing" .
B Issued by The organizational symbols of the originating office will appear here.
C Date Enter the operational date of the system.
D Revisions No. — The number of the revision, beginning with one ("1" ).
    By  — Enter the transmittal number assigned to the revision.
    Date — Date of the transmittal.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-4  (06-01-2002)
File Media Symbols

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-5  (06-01-2002)
Processing and Control Symbols

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-6  (06-01-2002)
Sample Schematic Diagram

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-7  (06-01-2002)
Sample Data Specifications

SYSTEM NAME:     OPERATIONAL DATE:
SYSTEM I.D.:     REVISION DATE:
RESPONSIBLE ORG.:      
  DATA SPECIFICATIONS
    FILE NAME:
    FILE NUMBER:
    FILE FORMAT:
    MEDIA:
    ORGANIZATION:
    ACCESS METHOD:
    BLOCKING FACTOR:
    NUMBER OF RECORD TYPES:
    LABELS:
NOTES:

Exhibit 2.5.4-8  (06-01-2002)
File and Record Index (Instructions)

(Instructions)

List the file numbers of all the files related to a given system. These files will be listed in ascending sequence based on file number.

Within the above list, list the records contained in each file, in ascending sequence by record reference number. The record reference number serves as a cross-reference to the record layouts in this document; therefore, only one record reference number will be assigned to a given record format. For example:

File Number Record Reference Number
7600101 7600101–001
7600101–002
(repeat until all records for file 7600101 are listed)
7770101 7770101–001

Enter the record name for each record reference number listed.

Enter the file name for each file number listed.

Enter the block size established for each file.

Enter the maximum record length for each record.

Enter the file format as follows:

F—Fixed
FB—Fixed Blocked
V—Variable
VB—Variable Blocked

For tape files, enter the tape density (e.g., compressed files of 18 and 36 tracks).

If the file is a disk file, enter the word "DISK" . For tape files, enter the tape characteristic; e.g., "9" for 9 track tapes.

Enter the number of days a file must be retained.

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-9  (06-01-2002)
Record Layout

EMPLOYEE-MASTER-RECORD
Element Number Name Start Pos Length Type Remarks
1 EMPLOYEE-CODE l 4 Num  
  EMPLOYEE-IDENTIFICATION 5 111 Group  
2 SOCIAL-SECURITY-CODE 5 9 Num SSN
3 EMPLOYEE-NAME 14 30 Char Last name first
4 STREET-ADDRESS 44 30 Char  
5 CITY 74 25 Char  
6 STATE 99 2 Alpha Standard abbreviation
7 ZIP-CODE 101 5 Num  
8 TELEPHONE-NUMBER 106 10 Num Include area code

Exhibit 2.5.4-10  (06-01-2002)
IBM Core Record Layout

This image is too large to be displayed in the current screen. Please click the link to view the image.
This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-11  (06-01-2002)
Instructions for Completing the IBM Core Record Layout

The IBM core record layout specifies the following fields:
  a) Element Name — The name of the elements that constitute a record layout. Elements may be indented under a group name ( begin group element names with a hyphen).
  b) Dec — The displacement in decimal. If this field does not apply, then it may be left blank.
  c) Hex — The displacement in hexadecimal. If this field does not apply, then it may be left blank. (The hexadecimal displacement does not show decimal points.)
  d) Length — The length of the field (designate 1/2 byte fields as 0.5).
  e) Type — This item indicates the data format of the element (e.g., packed decimal, zoned decimal, funny packed, character) and the number of decimal positions and sign.
  f) Ref — This item indicates the reference number (number sequentially beginning with 1) or whether a reference entry exists for the field (indicate with a " Y" ). Use a reference for lengthy remarks, otherwise leave this item blank. The references should be on a separate page at the end of the layout.
  g) Remarks — This item identifies additional information regarding the element such as editing rules and valid ranges. It may also be used for short remarks (one to a few lines).
   

Note:

It is not necessary to specify in the remarks YYYYMMDD for date fields, YYYYMM for tax periods or YYYYCC for posting cycle since these are the IRS standards. However if a date element is in month-day year format, then MMDDYYYY should be entered in the remarks since this is nonstandard.

  h) * — This item identifies elements that have been updated. Possible values are "I" (Insert — new field, record expands), " R" (Replace — field replaced or renamed), "M" (Move — field repositioned within record), and "C" (Change — field size changes, record expands/contracts).
The file name, record name (title) and date constitute the heading and must be displayed on each page.
Each record must end with the element "Total Record Length. " On variable records indicate a minimum and maximum length (if available).
If additional space is required for remarks regarding fields specified in the layout, then use an IBM Layout Reference.

Exhibit 2.5.4-12  (06-01-2002)
IBM Layout Reference

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-13  (06-01-2002)
Form 3864

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-14  (06-01-2002)
Instructions for Completing Form 3864—I/O Units

The I/O Units page must contain all data files necessary to execute the run being documented (e.g. catalogued, temporary special print processor files, etc.). For each file the device file type, number and name used by the program being documented must be specified. Any specific conditions concerning the file translation or special device options must also be indicated. Program run options that include or exclude certain files must be mentioned under the conditions portion of the I/O Units page.
Space Title Instructions
1. SYSTEM-ID/RUN NUMBER (1) Identify the program by System-ID and run number in the format SSS-RR(R).
(2) When there are options involved in a single run and each option is documented on a separate page, identify the option by SSS-RR(R).n (where n = option number).
2. FILE ASSN. System-specific
3. DEVICE System-specific
4. FILE NUMBER (1) Enter the file number in the acceptable standard format. File numbers must be consistent with the ANSI File Header Label and any End-of-File Label for tape. (

Note:

This must also correspond to the file numbers on the Schematic Diagrams.)


(2) Input files are to be listed first in ascending file number sequence. These will be followed by output files also listed in ascending file number sequence. (

Note:

Files that serve as both input and output should be integrated in the list of input files according to the specified sequence and not repeated in the list of output files).


(3) Make no entry here if a tape is used as a work tape; such as a checkpoint file. This type of information is contained in CONDITIONS.
5. FILE NAME Enter the name of the file identified by the file number in space 4. This identifier must be consistent with the Schematic Diagrams.
6. I/O Identify: I = Input Unit I/O = Input and Output (in the same run).
O = Output Unit
List all Input Units first, Input/Output Units second and Output Units last.
7. CONDITIONS Note any special restrictions on the file or unit. When the space provided is not adequate, cross reference the appropriate step in the Set-Up Instructions. All run options affecting file assignments must be listed under CONDITIONS, and cross referenced in the Set-Up Instructions.
8. EFFECTIVE DATE/CYCLE Identifies when the current information contained on this page becomes operational. (TRANSMITTAL NUMBER AND DATE may be substituted for the EFFECTIVE DATE/CYCLE.)
9. PAGE NUMBER Enter the page number of the pages for this run.
10. COMPUTER AND SIZE Identify the computer by name and number.
11. RUN TITLE Enter a brief title for run identification that is consistent with the Run Description and Schematic Diagrams.
12. SYSTEM-ID/RUN NUMBER Identify the System-ID and run number as entered in space 1.

Exhibit 2.5.4-15  (06-01-2002)
Form 3864–A

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-16  (06-01-2002)
Instructions for Completing Form 3864A—Set Up

Space Title Instructions
1. SYSTEM-ID/RUN NUMBER (1) Identify the System-ID and run number in the format SSS-RR(R).
(2) When there are options involved in a single run and each option is documented on a separate page, identify the option by SSSRR(R).n (where n = option number).
2. STEP NO. Number each step in unbroken sequence beginning with 1.
3. INSTRUCTIONS Provide the necessary instruction, using imperative sentences, needed by the operator to set up the run as follows:
(1) Include set-up steps for the job control language/executive control language (JCL/ECL — program, data, and control), the printer, disk unit, etc.
(2) When JCL/ECL statements, data cards or other special data cards are necessary in the job set up, provide a list of the statements or cards.
(3) Include complete, precise instructions and illustrations regarding the set-up of Checkpoint/Restart packets. It is recommended that this be a separate and unique set-up page.
(4) Rerun and restart procedures must be addressed for each run. If there are no special restart procedures this should be stated. A separate page containing rerun instructions must be included for each run. Precise information concerning file manipulation (delete, reload, or recatalog), and other pertinent instructions for the operator must be included on this page. If an alternate runstream is necessary to rerun a job, this must be listed and documented in the same fashion as all other runstreams. If no special instructions are required for a particular run, this should be stated with a reference to the appropriate first-time run instructions. Programs that access a data base must have rerun and restart instructions. Include information such as whether a data base area must be reloaded to eliminate updated records prior to rerun.
(5) When a controlling device is required for any I/O unit; e.g., printer carriage control tape, be sure to identify it by name and, when available, identification number. Include all application specifications.
(6) When there are options involved in one run, separate them into sets of loading steps accordingly. Begin each set on a new page. State the option number followed by option name on one line; e.g., OPTION 2. Monthly Tables. When necessary, include a two or three sentence synopsis of option. List the steps of the option sequentially beginning with 1.
4. EFFECTIVE DATE/CYCLE Identifies when the current information contained on this page becomes operational. (TRANSMITTAL NUMBER AND DATE may be substituted for the EFFECTIVE DATE/CYCLE.)
5. PAGE NUMBER Enter the page number of the pages for this run.
6. COMPUTER AND SIZE Identify the computer by name and number.
7. RUN TITLE Enter a brief title for run identification that is consistent with the Run Description and Schematic Diagrams.
8. SYSTEM-ID/RUN NUMBER Identify the System-ID and run number as entered in space 1.

Exhibit 2.5.4-17  (06-01-2002)
Form 3864–D

This image is too large to be displayed in the current screen. Please click the link to view the image.

Exhibit 2.5.4-18  (06-01-2002)
Instructions for Completing Form 3864D—Message List

Space Title Instructions
1. SYSTEM-ID/RUN NUMBER Identify the System-ID and run number in the format SSS-RR(R).
2. NUMBER Number each message in an unbroken sequence beginning with 1. List all messages whether computer processing continues or not.
3. MESSAGE (1) All program generated messages must be listed on the Message List Operating Instructions. All messages must be documented, and those that are not self-explanatory must have clear, concise instructions. If the message is informational only, this should be stated under the EXPLANATION column. It is recommended that messages be separated Into two categories: CONSOLE MESSAGES and INFORMATION MESSAGES (those appearing on the printed listing only). Discretion must be used in deciding which messages go where. Only those messages which require operator intervention or affect the continued operation of a runstream should appear on the console. All other messages should be routed to the run control print log (if available). If a computer run does not go to EOJ, include a CONSOLE MESSAGE to the operator that the contact point designated by the " USER SERVICE AGREEMENT" should be notified.
(2) Enter any fixed message by writing it in capital letters; e.g., "EOJ" . In a variable message, indicate the variable part with lower case letters; e.g., mm-dd-yyyy for a date or nnnn for a displayed number.
4. EXPLANATION AND OPERATOR ACTION If the message requires any operator action, explain in detail what the operator is to do. If there is no required action, state "No operator action" . Give any explanation or clarification of the message which will aid the operator.
5. EFFECTIVE DATE/CYCLE Identifies when the current information contained on this page becomes operational. (TRANSMITTAL NUMBER AND DATE my be substituted for the EFFECTIVE DATE/CYCLE.)
6. PAGE NUMBER Enter the page number of the page for this run.
7. COMPUTER AND SIZE Identify the computer by name and number.
8. RUN TITLE Enter a title for the run identification that is consistent with the Run Description and Schematic Diagrams.
9. SYSTEM-ID/RUN NUMBER Identify the System-ID and run number as entered in space 1.

Exhibit 2.5.4-19  (06-01-2002)
Instructions for Completing the IBM COH Guide

Introduction
1. Purpose — The IBM Computer Operations Handbook (COH) Guide is required before processing and provides detailed instructions to a computer operator for the proper execution and validation of a run or program. It also provides the conventions and standards applicable to all IRS developers, and is a required deliverable for the programming stage of development. This guide is applicable to the IBM Tier 1 mainframe (except the Automated Collection System), and applies to all developers engaged in the development of IBM or IBM-compatible programs.
2. Scope — The information presented in this manual covers the IBM COH Guide, and is composed of information from the previously used IBM Computer Operations Handbooks (such as the I/O Units), run description, schematics, and file specifications as described in this guideline. The instructions in this exhibit offer guidance in completing Exhibit 2.5.4–20, IBM COH Guide.
Standard Information
Purpose — The standard information contains the basic facts about the run in question. This data must appear at the top of every physical page (a standard 8 1/2 by 11 inch sheet of paper) or its electronic equivalent.
Data Fields:
  1. Run/Command Code: The actual command code or run in PPP-RR format where PPP equals the project and RR equals the run. The Integrated Collection System (ICS) format may vary from six to eight alphanumeric characters.
  2. Title: A one line description of the run or command code.
  3. Page Number: The physical page number as if the document was printed on a 8 1/2 by 11 inch sheet of paper.
  4. Section-ID: The first two digits of your user ID.
Section I — Run Description and Nature of Changes
Purpose: The Run Description and Nature of Changes section gives the immediate information concerning the run or command code. It tells how often it is run, how many resources it is going to require, and what was changed in this transmittal.
  1. Run Description: A short paragraph describing what this run or command code accomplishes.
  2. Frequency: The number of times this project is executed in a given year. Valid responses are: daily, weekly, monthly, biweekly, bimonthly, annually, biannually, onetime, etc.
  3. System Resource Requirements: The number and type of input drives, output drives, Disk Requirements, or DB2/CICS/Teradata needed. Valid media types are: Bosch, STK, Optical, DASD, CART8, CART36, Tape9, Memorex ATL, etc. Indicate if the job updates or has exclusive access to a database (or is read only).
  4. Sort/Merge Fields: A list containing the order of the output. Ignore this field if the program is not a sort or merge and the files are already in order.
  5. Changes Included : Explanations for the changes should be specific, relevant, and easy to understand. When changes do occur, transmit a completely new IBM COH Guide to replace all prior transmittals.
Section II — Schematic
Purpose: The project schematic is important for processing validation; it informs the Processing Validation staff what files must be input and where the output is to go. The project schematic diagram must include output file destinations for audit purposes. The schematics can be on multiple pages as long as they include on each page the project title, the cycle designation, and page numbers (1 of x, 2 of x, etc.).
  1. Schematic Location: Provides the schematic location in PCDOCS. This would be a single run or the first run in a series of runs.
  2. MCC Cycle Designation: The cycle designation received from MCC schedulers. Valid responses are: BEW-, BEM-B, IPW-P, IEX-A, etc. For MCC purposes, put the cycle designation in the reference field on the schematic document profile.
Section III — I/O Page
Purpose: The I/O page will contain the information from the JCL. It must be in step order, first input then output. Also indicate if the job is multi-step.
  1. Job Step: This indicates a job step's association with the system resource requirements and I/O elements (ICS).
  2. DDNAME: The DDNAME from the JCL that is associated with this file.
  3. File Name & DSN: The complete data set name and a short description of the file.
  4. Unit: From the Unit parameter of the JCL.
  5. Label: From the Label parameter of the JCL. Not applicable for disk datasets.
  6. Ret: The retention in days required to keep this file. This is not applicable for input files.
  7. CRL: The Core Record Layout Reference Number; in order to access the CRL, go into PCDOCS and enter the run.
  8. TO: The major run or final destination to receive this file, if appropriate. This is not applicable for input files.
  9. BLKSIZE: Block size concerns how the records are transmitted and stored on an I/O device. Include block size, if appropriate.
  10. PRINT OPTION: Furnish the appropriate information, including the logical record length (LRECL) if necessary.
Section IV — Setup Cards/Sysin Cards
Purpose: This section will describe any sysin cards that are required by your job, and any necessary instructions needed by the operator to set up the run. Also incorporate other documentation related to the execution of the program, including the ENDEVOR memo, for any special instructions or input.
  1. Special Cards: The layout of any special cards, in the order that is required by the program, which also includes a short explanation. The CP23 or CP2000 cards should be included if needed. State if the program utilizes the CP23 or CP2000 macros if that is true. The DD name should be included if it is other than SYSIN.
  2. Rerun/Restart Requirements: Any rerun or restart requirements. Indicate any disk file that needs to be set back, e.g., to a previous time period or with a generation data group.
  3. Special Considerations: Any additional information that would help Scheduling, Production Control, or Operations run your job correctly the first time or how to restart it smoothly. Include any date considerations, e.g., on setup cards. Explain the PARM values on the EXEC card, if appropriate.
Section V — Halts/Messages/User Abends
Purpose: This section is needed to assist Operations and the Resident Programmer Analysts (RPAs)/ Computer Systems Analysts (CSAs) understand, answer, and restart a job after it has abnormally ended.
  1. Job Step: This indicates which job step created the message (ICS).
  2. Number: This must be the halt or abend codes so that the operators can research the abend code. When it is a message for information only, not requiring a reply, it can be just a sequential number of messages relative to the order of appearance.
  3. Message Text: The actual text in the message.
  4. Explanation: A short explanation as to why the message was sent.
  5. Action/No Action: Any expected action by Scheduling, Production Control, Operations, or RPA/CSA personnel. "No Action" is also a valid response.
  6. Restart Instructions: This must include any special instructions for Production Control, Operations or RPA/CSA personnel.
Section VI — Balancing
Purpose: This section is used to help Processing Validation and the RPAs/CSAs if there is a LARS out of Balance (LOOB) condition. Even though not enumerated below, it should be noted that ‘run-to-run’ balancing (i.e., LARS counters from previous runs need an audit trail) is required as well as "internal run" balancing.
  1. LARS Balancing Equations: The LARS formula as it will appear.
  2. Explanations: A paragraph explaining what the balancing instruction is trying to accomplish and how to manually balance if a LOOB is received.
  3. Counters: All single record counts, record count arrays, single money amounts, money amount arrays and explanations should be listed. LARS CNTL001 messages are needed in the balancing instructions along with the file number associated with each LARS counter. Also, a TOTAL line is required when more than one (1) pass is involved.
  4. Manual Balancing: If the program does not contain any LARS Balancing instructions it will be necessary to explain how the Processing Validation personnel will be able to verify the record counts or money amounts received.
  5. External Counters: If the records received are from an outside agency, one should include the number of records on the input and which counter it is equal to in the program, if appropriate.
  6. Auto Control Records (from external to center): If control records are included with the data records they should be described here, if appropriate.

Exhibit 2.5.4-20  (06-01-2002)
IBM COH Guide

Standard Information — To be included on each printable page.
1. Run/Command Code 2. Title 3. Page Number
PPP-RR (except ICS)
4. Section-ID
Section I — Run Description and Nature of Changes
Run Description:
Frequency:
System Resource Requirements Input Drives:
  Output Drives:
  Disk Requirements:
  DB2/CICS/Teradata:
Sort/Merge Fields:
Changes Included:
Section II — Schematic
1. Schematic Location:
2. MCC Cycle Designation:
Section III — I/O Page
DDNAME FILE NAME & DSN UNIT LABEL RET CRL TO
JOB STEP (ICS) BLKSIZE: PRINT OPTION:
Standard Information — To be included on each printable page.
1. Run/Command Code 2. Title 3. Page Number
PPP-RR (except ICS)
4. Section-ID
Section IV — Setup Cards/Sysin Cards
Special Cards (explanation & sequence):  
  DD Statement (Sysin or other):
  Cards formatted (in required order):
  CP23/CP2000 card or
  CP23/CP2000 macro utilized or other options
Rerun/Restart Requirements:
Special Considerations:
Section V — Halts/Messages/User Abends
Job Step Number Message Text Explanation Action/ Restart Instructions
(ICS)       No Action  
Section VI — Balancing
LARS Balancing Equations:
Explanations:
Counters:
Manual Balancing:
External Counters:
Auto Control Records (from external to center):

More Internal Revenue Manual