IRM 2.7.6 — Systems Scheduling

# Part 2. Information Technology

Chapter 7. Information Technology (IT) Operations Section 6. Systems Scheduling 2.7.6 Systems Scheduling Manual Transmittal December 02, 2020 Purpose (1) This transmits revised Internal Revenue Manual (IRM) 2.7.6, Information Technology Services (ITS) Operations, Systems Scheduling. Material Changes (1) Added internal controls. Effect on Other Documents IRM 2.7.6, dated January 1, 2010, is superseded. Audience These guidelines are for the Information Technology Services (ITS) staff in the Enterprise Computing Centers that have system scheduling roles and responsibilities. Effective Date (12-02-2020) Nancy A Sieger Acting Chief Information Officer

# Program Scope and Objectives

2.7.6.1 (12-02-2020) Program Scope and Objectives Overview: To arrange and organize in a programmatic way the execution of daily and weekly processing for Enterprise Computing Center for both Memphis (ECC-MEM) and Martinsburg (ECC-MTB). Purpose: This IRM reinstates Internal Revenue Manual (IRM) 2.7.6, Information Technology Services (ITS) Operations, Systems Scheduling for service center tax processing. Audience: IT Application Development (AD) – Developers who coordinate with Operations Services Branch (OSB) to schedule jobs on the IBM Mainframe and UNISYS, IT OSB IBM Mainframe and UNISYS Schedulers and IT Mainframe Operations Branch (MOB) Computer Systems Analyst (CSA). Policy Owner: Chief Information Officer. Program Owner: Enterprise Computing Center, Operations Scheduling Branch (OSB). Primary Stakeholders: IT Applications Development (AD) and Operations Scheduling Branch (OSB). Program Goals: Provides detailed Scheduling processes and procedures.

# Systems Scheduling Overview

2.7.6.2 (09-01-2020) Systems Scheduling Overview This section presents the general concepts to be followed in the creation of schedules for all processing; the preparation of run set-ups; the review of these prior to, and following, the completion of the work on the system. This section on ITS Scheduling is applicable to most offices within the IRS that schedule computer equipment for processing or testing of live data and provides basic Scheduling functions. The goals of an effective scheduling system include: Timely completion of all processing; maximum utilization of all available resources; proper identification of all the processing that should be completed in the allocated time frames; specific avoidance of processing that conflict within the computer systems; careful consideration of all processing interdependencies between all computer systems and sites; current status of all ongoing processing and projected completion times for management information; protecting the information processd by ensuring proper security and privacy. It is the responsibility of the senior ITS Operations manager to ensure that all data is processed timely, completely, and within the guidelines set forth in this document and other appropriate IRS procedures and directives.

# Acronyms

2.7.6.3 (09-01-2020) Acronyms This section provides the following abbreviations/acronyms. AAF:Automatic Attribute Feature. ATR:Automated Tracking Report. BLISS:Basic Library Inquiry Sub-System. BRM:Business Reports Monthly. CADE: Customer Account Data Engine. For additional information see "Definition of Terms" below. C:D: Connect Direct. CIN:Controls Irregularity Notice. CIP Programs: Critical Infrastructure Protection programs are contained in the Main Frame Master File applications at ECC-MTB. CPE:Computer Performance Evaluation CRX:Correspondex Letter File. CSA:Computer System Analyst Cybersecurity:replaces Mission Assurance & Security Services DAV:Data Adjustment Voucher. ECC: Enterprise Computing Center - includes the three Computing Centers) Detroit, (ECC-DET), Martinsburg, (ECC-MTB), Memphis (ECC-MEM) ECL: Executive Control Language. EDT:Electronic Data Transfer. EFTU: File Transfer Protocol. IRSC:Internal Revenue Service Campus, (formerly Service Center.) IRW:Individual Reports Weekly. JCL: Job Control Language. PVS:Processing Validation Section. RDS: Retention Data Set. SA:System Administrator SACS: Security and Communications System. SCSS:Service Center Support System STAR: System for Tape Administration and Reporting. TAG:Transmittal Auto-Gen System.

# Definition of Terms

2.7.6.4 (09-01-2020) Definition of Terms This section uses the following definitions. Agency Outside IRS: Any agency that may receive magnetic media from IRS, and is not a part of any IRS function, e.g., banks, state employment commissions, etc. CADE:Through a number of incremental releases, CADE will ultimately replace the IMF and enable the replacement of the IDRS components. Taxpayer records will be moved from the legacy master file to the modernized system, using a released based approach starting with the simplest taxpayer accounts. CONTROL-D: The electronic distribution of computer generated reports. CIP Programs Critical Infrastructure Protection programs are contained in the Main Frame Master File applications at ECC-MTB. CONNECT:Direct: An electronic method of transferring files. Control-M: An online, scheduling, tracking, and control facility used by Master File Scheduling Section to manage production processing. DIET: Display Information for EDT, (a software tool developed by ECC-MTB that runs on IBM Master File processing systems and tracks the disposition of client/server jobs, ELFCK and GMFCK. ECS: Enterprise Control Station (software that allows the manipulation of multiple Control-M installations from a single workstation using GUI. It executes production processing, performs JCL corrections, and restarts jobs.) EFT: Electronic File Transfer (a generic term for CONNECT:Direct or NDM, etc.). ELFCK: A fraud detection system that checks electronically filed returns for duplicate entries and runs validity checks. Function Code: Indicates the entity that is responsible for causing the rerun. The function code is always to be used in conjunction with a reason code and when combined with a reason code makes up a descriptive rerun code. The function code represents an activity within a center's information systems organization except for function codes: J = National Headquarters/Site Support, K = Outside Activities, and L = Other Centers. GMFCK: A fraud detection system that checks paper returns for duplicate entries and runs validity checks. GUI: Graphical User Interface. IRSC:Internal Revenue Service Campus (formerly known as Service Centers). LARS: Log Analysis and Reporting Services (balances input-output records). MREX: Modified Run Executive. Opcon/xps is an enterprise-wide scheduling software used on the UNISYS system. OPOG: Operations Processing Objectives Guide identifies ECC-MTB computer workload for the upcoming two-week period (current and subsequent week). Output Shipment Tapes: Media to be shipped to another agency, after the file is created. Outside Activities: All non-information technology services operations personnel, either inside or outside the center. Print Priority List: (Determine locally.) Listing, kept on the print systems, consisting of all print file run IDs. This allows the print media to be forwarded to the in house print systems without an accompanying Form 3220. Reason Code: The condition that caused the rerun. Recirculating Tapes: Media that must be input into future runs. SACS: Security and Communication System. SCIPAS: Service Center Inputs Processing Automation System (the automated scheduling of input to production). ITOCC: Information Technology Operations Command Center

# Scheduling Requirements

2.7.6.5 (09-01-2020) Scheduling Requirements When necessary, scheduling section will prepare work flow charts, or other means that will assist the site in forecasting and monitoring systems performance by: detecting and correcting scheduling conflicts; working with SAs and CSAs on the potential problem situations; identifying job interrelationships, providing for dependencies, and priorities; ensuring that all jobs are scheduled at the proper time with the correct variables to process the runs; working closely with the CPEs to develop the most efficient means to schedule runs, resulting in the most effective mix, sequence and linkage of runs; planning of computer processing and predicting processing time, completion time; providing historical data for use in projecting run times, to assist in preparing schedules; maintaining scheduling software and calendars. Forecasting tools also provide an overall time frame for: coordinating between customer areas and the responsible branches, as required; reviewing output, as required, to ensure quality.

# Building and Modifying UNISYS Schedules

2.7.6.6 (09-01-2020) Building and Modifying UNISYS Schedules This segment describes procedures for building and modifying schedules on the UNISYS Dorado 280 System. The software package known as Opcon is used on the UNISYS ClearPath Mainframe Systems, and its function is the scheduling and processing of jobs. The daily schedule is built by Opcon and runs on a 24 hour cycle. The daily schedule must be maintained and can be modified to adapt to daily requests by users.

# Building Schedules

2.7.6.6.1 (09-01-2020) Building Schedules Daily schedules are built through the Opcon at 1300 hours, Monday through Thursday, by the program PRODBLD-M-T. This builds the daily schedule for the following day. On Friday, the program PRODBLD-FRI runs to build daily schedules for Saturday, Sunday and Monday. The status of daily schedules can be obtained by clicking the Daily Schedule Maintenance button on the Opcon/xps screen. Use menu path:File>Check Daily Schedules. Click on the desired date or schedule in the schedules section. Click Display Informational Messages check box. Click Check Schedules. View the Results, If a daily schedule needs to be manually build: Click the Daily Schedule Maintenance button Use menu path: File>Build Daily Schedules Click on the desired schedule in the Schedules section Enter a date in the Start box, Enter a date in the Stop box Select 'Always Warnfrom the Existing Schedules frame Click 'Build Schedule' If a daily schedule was built incorrectly and needs to be deleted Click Daily Schedule Maintenance Use menu path: File>delete daily schedules Click on the desired schedule date or individual schedule in the schedules section Click 'delete schedule' Click 'OK' to proceed with the delete Note: An error message will be displayed if any of the schedules being deleted are in process. Opcon/xps does not allow processing schedules to be deleted.

# Master File Systems Notification

2.7.6.7 (09-01-2020) Master File Systems Notification This segment is to provide standard operating procedures for the preparation and distribution of the Systems Notification. The appropriate Section or Branch prepares a Systems Notification on an as needed basis to inform and instruct the personnel of scheduling changes in computer processing operations.

# Preparing the Systems Notification or Other Form of Notification

2.7.6.7.1 (09-01-2020) Preparing the Systems Notification or Other Form of Notification The following guidelines are provided for preparing a Systems Notification: Obtain a number from the Change Management Team. Prepare a free form word processing document detailing scheduling changes in computer processing operations (e.g., holidays, power outages, extended IRSC cutoff, expedited processing, changes in hours of computer operations at ECC, changes in distribution of output files or unit destinations, extended or date changes for real-time, rerouting of command codes, etc.). Use the website to prepare a Systems Notification at: http://mountaineer.mcc.irs.gov.. When completed send an email to address,*ccmccb@irs.gov.. After approval of the Systems Notification, it will be disseminated via E-mail to managers of all responsible and impacted areas. NUMBER: WMB-99-039 DATE: 03/29/1999 Systems Notification SUBJECT: Balancing Workload Due to the current system problems, we are recommending close monitoring and scheduling actions to ensure that workload is balanced between the MBH1 and the MEH2 Systems. Please ensure that CFOL remains on the MBH1. If SOC4's are encountered, please restart at checkpoint or BOJ and validate the SOC4 prior to opening a problem resolution ticket. Any questions or concerns can be directed to Janet Doe, Master File Scheduling Section, telephone number XXX-XXX-XXXX.

# Manually Transmitting IRSC Data to the ECC

2.7.6.8 (09-01-2020) Manually Transmitting IRSC Data to the ECC There will be numerous instances when the IRSC customer will request that an ad hoc job or special instructions be included in the Enterprise Computing Center production schedule. Note: This segment does not address Enterprise Computing Center processing where the customer has demand terminal access or when the IRSC customer has the need to provide the IRSC with the authority to continue a job/run after a system halt i.e., TEP, RPS, etc. See the following segment for this information. Special instructions and any processing information provided to the Enterprise Computing Center will be automated to the extent that they will be transmitted to the ECC via a customer service request via KISAM. Until that time or when KISAM is not available, these interim or backup procedures will remain in effect.

# Selected Processing Procedures

2.7.6.9 (09-01-2020) Selected Processing Procedures Critical Enterprise Computing Center/campus processing must meet strict processing time frames and ultimately strict delivery schedules for ITS customers. The Service has devised Service Level Agreements (SLA) that list time frames and delivery schedules to ensure the on-time delivery to the customer. The site will refer to their local SLA for detailed information.

# SCCF/TEP Processing Procedures

2.7.6.9.1 (09-01-2020) SCCF/TEP Processing Procedures The time frames for the completion of the processes are in each site's Service Level Agreement. To request the TEP File Creation upon balancing the SCCF reports and coding the SCFDL File, Data Control Function at the IRSC will: complete the Job Request/Release and fax or email the request to run GMF15 to the Enterprise Computing Center; follow up via telephone contact to ensure receipt, if necessary. The Enterprise Computing Center will: generate GMF15 TEP; transmit back to the IRSC the associated PRINT files. Upon balancing the TEP, Data Control Function will: fax the Job Request/Release releasing the NDM of GMF15 to the Enterprise Computing Center; follow up via telephone contact; request, via fax, daily/weekly/monthly SCF 13 date cards, when necessary. If a request is denied the ECC will advise the IRSC Liaison Staff with the reason for denial and update the KISAM service request with this information.

# SCCF Out-Of-Balance Condition

2.7.6.9.1.1 (09-01-2020) SCCF Out-Of-Balance Condition When an SCCF out-of-balance condition occurs, the IRSC Liaison Staff will: Contact the IRSC Help Desk and provide information to open an KISAM ticket. The IRSC Liaison Staff will be notified of the out-of-balance condition either by an KISAM ticket or a phone call from the ECC.

# ECC IBM Scheduling Software and References

2.7.6.10 (09-01-2020) ECC IBM Scheduling Software and References The following are widely used software packages with limited information and references: Control-D— The electronic distribution of computer generated reports. A method of transferring reports similar to EONS. Connect:Direct — A method of transferring files electronically. Control-M/GUI — An online scheduling, tracking, and control facility used by Scheduling, Service Operations Command Center, and Master File Scheduling Section to manage production processing. DIET — Display Information for EDT is a software developed by ECC-MTB that runs on IBM Master File processing systems for tracking the disposition of client/server jobs ELFCK and GMFCK fraud detection systems that runs validity checks and checks for duplications of electronic and paper returns respectively. ECS — Enterprise Control Station (Control-M/Enterprise Manager) is a software that allows the manipulation of multiple Control-M installations from a single workstation, using a Graphical User Interface (GUI). It allows the OIRSC staff to execute production processing, perform JCL corrections, and restart jobs. LARS — Log Analysis and Reporting Services is a job log summary of processing statistics. It balances input and output records, etc. OPOG — Operations Processing Objectives Guide identifies ECC-MTB computer workload for the upcoming two-week period (current and subsequent week). SCIPAS: Service Center Inputs Processing Automation System. SCIPAS is a scheduling automation tool used in conjunction with Control-M to handle the unpredictable nature of scheduling IRSC inputs. In addition to automating the scheduling of input files, SCIPAS also supports problem management and reporting. The first phase of SCIPAS automated the processing of IRSC input to the router run, substantially reducing the need for human intervention for job setup. Subsequent phases of SCIPAS have automated scheduling and processing up through the pre-posting runs. SCIPAS also provides a basic duplicate file check prior to processing IRSC input.

# Service Center Inputs Processing Automation System (SCIPAS)

2.7.6.11 (09-01-2020) Service Center Inputs Processing Automation System (SCIPAS) The cataloging of inputs received electronically has allowed the development of a series of programs to automate the scheduling of Service Center Campus Transactions files. This series of programs is known as SCIPAS. The following input files are received via Electronic Data Transfer (EDT) from the Service Center Campuses or from Bureau of the Fiscal Service (BFS) (formerly Financial Management Services (FMS). BUR5311, CTR4901, CTR4902, CTR4903, CTR4904, EFD0101, EFT1501, EFT1601, EFT1701, ELF6120, EOD2901, EOD2902, EOD2903, ERA0327, ERS0105, ERS0507, ERS0801, FRD0101, GMF1501, GMF2501, GUF5118, MEF1503, MEF6803, RDO7401, RDO7402, and UND5311. The first phase of SCIPAS automated the scheduling of Service Center Campus input to the Router run (J793-01), substantially reducing the need for human intervention in Master File Scheduling (MFS) for job setup. Subsequent phases of SCIPAS have automated the processing for various other Master File projects such as IMF, BMF, EPMF, TRDB, DDB, and TETR. SCIPAS-J (Master File Routers) schedules the following jobs: J79301, J79302, J79304, J79311, JDDB01, RRPA14, RRPA17, RRPA18, RRPA25, RRPA28, RRPA29, RRPA38, RRPA41, RRPA43, and RRPA44. SCIPAS-I (IMF Pre-posting) schedules the following jobs: I46002, I46003, I46005, I4602A, I4602B, I4602C, I75767, and I75768. SCIPAS-B (BMF Pre-posting) schedules the following jobs: B16002, B16003, B16004, B16005, B16007, B16008, B1602A, B1602B, B1602C, B1602D, B4020A, B7B767, B7B769, J7B768, J79312, RRPA22, RRPA26, RRPA34, and RRPA42.. SCIPAS-E (EPMF Pre-posting) schedules the following jobs: J7P768, P13001, P13002, P13017, P7P767, P7P769, and RRPA24. SCIPAS-T (TRDB) schedules the following jobs: JRDBA0, JRDBCA, JRDBC3, JRDBGD, JRDBGM, JRDBK0, JRDBK1, J793BA, J793BD, J793CA, J793DA, J793DD, J793FA, J793FD, J793GA, J793GD, J7936A, J7936D, J7937A, J7937D, RRPA19, RRPA21, RRPA30, RRPA40, RRPA47, and RRPA48. SCIPAS-D (TETR) schedules the following job: JTEB01 SCIPAS-V (JPD voucher/dup-check) schedules the following jobs: J7931C, J7931D, and J7932G.

# Scheduling Procedures

2.7.6.11.1 (09-01-2020) Scheduling Procedures SCIPAS has two methods of determining when electronically transmitted files have been received and are available for scheduling. The first way is via the use of the Automated Tracking Report (ATR). The ATR automatically updates each hour on the half-hour and uses the CONNECT:Direct (C:D) statistics to determine which files have been successfully received. ATR also updates each hour on the three-quarter hour for files that are received via Enterprise File Transfer Utility (EFTU). The second way is via the use of SCIPAS program RRPA56. RRPA56 uses Control-O rules to detect the receipt of electronically transmitted files and then immediately posts that information to the SCIPAS Scheduling file (RunBase). Each time SCIPAS schedules JCL, it automatically retrieves the JCL from Endevor, edits the JCL to make it production-ready, and places the JCL into Control-M for processing. The following jobs are SCIPAS setup jobs. Please note that the jobs are listed alphabetically and are not necessarily processed in that order: RRPABKPD automatically runs Monday through Saturday at 0600 hours. RRPABKPD is the daily backup job and it creates backup copies of many critical SCIPAS files. RPABKPW automatically runs on Friday after the successful completion of RRPAJCL. RRPABKPW is the weekly backup job and it creates backup copies of many of the critical SCIPAS files. RRPACOA1 processes after all of the cycle setup jobs have successfully completed. RRPACOA1 adds Control-M static condition RPA-SCIPAS-CYC-READY. RRPACOD1 automatically runs on Friday at 0545 hours. RRPACOD1 deletes Control-M static condition RPA-SCIPAS-CYC-READY. RRPACYCS automatically runs on Friday at 0546 hours if the following Control-M In-Conditions are present: RRPAWBMF-ENDED-OK; RRPAWEMF-ENDED-OK; RRPAWIMF-ENDED-OK; RRPAWJPD-ENDED-OK; and RRPAWTDB-ENDED-OK. RRPACYCS builds the JCL for RRPAPLUG via a simple copy from Endevor. RRPADJCL automatically runs on Friday after the successful completion of RRPAJCL. RRPADJCL retrieves a copy of various SCIPAS JCL elements from Endevor (for scheduling TRDB jobs) and prepares them for current cycle processing. JCL elements: RRPA09, RRPA10, and RRPA90. RRPAINIW automatically runs on Friday after the successful completion of RRPABKPW. RRPAINIW performs weekly initialization (reset) of various SCIPAS history files. RRPAJCL automatically runs on Friday after the successful completion of RRPAPLUG. RRPAJCL retrieves a copy of various SCIPAS JCL elements from Endevor (for scheduling Master File jobs) and prepares them for current cycle processing. JCL elements: RRPA00, RRPA01, RRPA03, RRPA05, RRPA07, RRPA08, RRPA09, RRPA10, RRPA32, RRPA55, and RRPA90. RRPAPLUG runs on Friday morning. RRPAPLUG retrieves a copy of the various SCIPAS jobs from Endevor and prepares them for current cycle processing RRPA00 automatically runs on Friday after the successful completion of RRPABKPW. RRPA00 updates the SCIPAS SYMLIB which sets the weekly (numeric) portion of the SCIPAS cycle. RRPA00PM automatically runs on weekdays at 0610 hours if job I460V1has been successfully processed. RRPA00PM sets the day-of-week portion of the SCIPAS cycle. It should be noted that job I460V1 passes the day-of-week to SCIPAS via auto-edit variables. RRPA01 automatically runs on Friday after the successful completion of RRPABKPW. RRPA01 archives old records from the SCIPAS Scheduling file (RunBase) to the SCIPAS Archive file. Listed below are SCIPAS jobs that are used to schedule the files and jobs that are under SCIPAS control. Please note that the jobs are listed alphabetically and are not necessarily processed in that order. RRPA03PB processes on Thursday evening after the Master File Schedulers have verified that all BMF processing has been successfully processed. RRPA03PB places holds on the following BMF/BMF-related jobs: B16002, B16003, B16004, B16005, B16006, B16007, B16008, B1602A, B1602B, B1602C, B1602D, B4020A, B7B767, B7B769, B701JB, JTEB01, J7B768, J79312, RRPA22, RRPA26, RRPA34, and RRPA42. RRPA03PE processes on Thursday evening after the Master File Schedulers have verified that all EPMF processing has been successfully processed. RRPA03PE places holds on the following EPMF/EPMF-related jobs: J7P768, P13001, P13002, P13017, P7P767, P7P769, and RRPA24. RRPA03PH processes on Thursday evening after the Master File Schedulers have verified that all weekly non-pass IMF/IMF-related processing has been successfully processed. RRPA03PH places a hold on the following IMF/IMF-related job: I75768. RRPA03PI processes on Thursday evening after the Master File Schedulers have verified that all weekly pass-oriented IMF/IMF-related processing has been successfully processed. RRPA03PI places holds on the following IMF/IMF-related jobs: I46002, I46003, I46005, I4602A, I4602B, I4602C, and I75767. RRPA03PJ processes on weekday evenings if job I460V1 has been successfully processed. Before releasing RRPA03PJ, the Master File Schedulers must verify that all daily JPD router processing has been successfully processed. RRPA03PJ places holds on the following jobs: J79301, J79302, I79304, and I79311. RRPA03PR processes on Thursday evening after the Master File Schedulers have verified that all JPD router and JPD dup-check-voucher processing has been successfully processed. RRPA03PR places holds on the following jobs: J79301, J79302, J79304, J79311, and J7931C. RRPA03PS processes on Thursday evening after the Master File Schedulers have verified that all SCIPAS-J processing has been successfully processed. RRPA03PS places holds on the following jobs: JDDB01, J7931D, J7932G, J7932H, RRPA14, RRPA17, RRPA18, RRPA25, RRPA28, RRPA29, RRPA36, RRPA37, RRPA38, RRPA41, RRPA43, and RRPA46. RRPA03PT processes on Thursday evening after the Master File Schedulers have verified that all TRDB/TRDB-related processing has been successfully processed. RRPA03PT places holds on the following jobs: JRDBA0, JRDBCA, JRDBC3, JREBGD, JRDBGM, JRDBK0, JRDBK1, RRPA19, RRPA21, RRPA30, RRPA31, RRPA40, RRPA47, and RRPA48. RRPA03PV processes on Thursday evening after the Master File Schedulers have verified that all TRDB voucher processing has been successfully processed. RRPA03PV places holds on the following jobs: J793BA, J793BD, J793CA, J793DA, J793DD, J793FA, J793FD, J793GA, J793GD, J7936A, J7936D, J7937A, and J7937D. RRPA05P1 automatically runs at 0700 hours on the weekdays if job I460V1 has been successfully processed. RRPA05p1 is the entry point to the early morning SCIPAS-J daily processing. SCIPAS-I daily processing automatically begins when SCIPAS-J completes. RRPA05P2 automatically runs at 1100 hours on the weekdays if job I460V1 has been successfully processed. RRPA05P2 is the entry point to the mid-morning SCIPAS-J daily processing. SCIPAS-I daily processing automatically begins when SCIPAS-J completes. RRPA05P3 automatically runs at 1500 hours on the weekdays if job I460V1 has been successfully processed. RRPA05P3 is the entry point to the afternoon SCIPAS-J daily processing. SCIPAS-I daily processing automatically begins when SCIPAS-J completes. RRPA05P4 runs at 1700 hours on the weekdays if job I460V1 has been successfully processed and after the Master File Schedulers have verified that all inputs have been received. RRPA05P4 is the entry point to the evening SCIPAS-J daily processing. SCIPAS-I daily processing automatically begins when SCIPAS-J completes. RRPA07B4 automatically runs on Tuesday at 0610 hours if job B160V0 has been successfully processed. RRPA07B4 releases the following BMF jobs, thus making them available for SCIPAS scheduling: B16002, B16003, B16008, and B7B767. RRPA07B5 automatically runs on the Thursday at 0610 hours. RRPA07B5 releases the following BMF jobs, thus making them available for SCIPAS scheduling: B16004, B16005, B16006, B16007, B1602A, B1602B, B1602C, B1602D, B7B769 and J7B768. RRPA07B6 automatically runs on Thursday at 1650 hours. RRPA07B6 releases the following BMF/BMF-related jobs, thus making them available for SCIPAS scheduling: B4020A and J79312. RRPA07D2 automatically runs on Friday at 0610 hours. RRPA07D2 releases the following jobs, thus making them available for SCIPAS scheduling: JDDB01 and JTEB01. RRPA07E5 automatically runs on Thursday at 0610 hours. RRPA07E5 releases the following EPMF jobs, thus making them available for SCIPAS scheduling: P7P767 and P7P769. RRPA07E6 automatically runs on Thursday at 1650 hours. RRPA07E6 releases the following EPMF jobs, thus making them available for SCIPAS scheduling: J7P768, P13001, P13002, and P13017. RRPA07I1 automatically runs on the weekdays at 0610 hours. RRPA07I1 releases the following IMF jobs, thus making them available for SCIPAS scheduling: I46002, I46005, and I75767. RRPA07I3 automatically runs on the weekdays at 1645 hours if job I460V1 and either I460V7 or I460V9 have been successfully processed. RRPA07I3 releases the following IMF jobs, thus making them available for SCIPAS scheduling: I46003, I4602A, I4602B, and I4602C. RRPA07I6 automatically runs on Thursday at 1650 hours. RRPA07I6 releases the following IMF jobs, thus making them available for SCIPAS scheduling: I75768 RRPA07J1 automatically runs on the weekdays at 1645 hours if job I460V1 and either I460V7 or I460V9 have been successfully processed. RRPA07J1 releases the following JPD Router jobs, thus making them available for SCIPAS scheduling: J79301, J79302, J79304, and J79311. RRPA07K2 automatically runs on Friday at 0610 hours. RRPA07K2 releases the following RPA dup-check jobs, thus making them available for SCIPAS scheduling: RRPA14, RRPA17, RRPA18, RRPA19, RRPA21, RRPA22, RRPA24, RRPA25, RRPA26, RRPA28, RRPA29, RRPA30, RRPA31, RRPA34, RRPA36, RRPA37, RRPA38, RRPA40, RRPA41, RRPA42, RRPA43, RRPA46, RRPA47, and RRPA48. RRPA07T2 automatically runs on Friday at 0610 hours. RRPA07T2 releases the following daily TRDB/TRDB-related jobs, thus making them available for SCIPAS scheduling: JRDBA0, JRDBC3, JRDBGD, JRDBGM, JRDBK0, JRDBK1, J793BD, J793DD, J793FD, J793GD, J7936D, and J7937D. RRPA07T6 automatically runs on Thursday at 1650 hours. RRPA07T6 releases the following weekly TRDB/TRDB-related jobs, thus making them available for SCIPAS scheduling: JRDBCA, J793BA, J793CA, J793DA, J793FA, J793GA, J7936A, and J7937A. RRPA07V3 automatically runs on weekdays at 1650 hours. RRPA07V3 releases the following daily JPD voucher job, thus making them available for SCIPAS scheduling: J7931C. RRPA07V6 automatically runs on Thursday at 1650 hours. RRPA07V6 releases the following weekly JPD vouchers jobs, thus making them available for SCIPAS scheduling: J7931D and J7932G. RRPA08FB processes on Thursday evening after the Master File Schedulers have reviewed the Scipas-B reports and verified that the BMF SCIPAS processing has been completed for the week. RRPA08FB is the entry point to the Final SCIPAS-B processing. Final SCIPAS-B schedules BMF application jobs if inputs are available. RRPA08FE processes on Thursday evening after the Master File Schedulers have reviewed the SCIPAS-E reports and verified that the EMPF SCIPAS processing has been completed for the week. RRPA08FE is the entry point to the Final SCIPAS-E processing. Final SCIPAS-E schedules EPMF application jobs if inputs are available. RRPA08FI processes on Thursday evening if job I460V1 has been successfully processed. Before releasing RRPA08FI, the Master File Schedulers must review the SCIPAS-I reports and verify that the IMF SCIPAS processing has been completed for the week. RRPA08FI is the entry point to the Final SCIPAS-I processing. Final SCIPAS-I schedules IMF application jobs if inputs are available. RRPA08PB is an ad-hoc job that is processed on an "as needed" basis. RRPA08PB is the entry point to the SCIPAS-B processing. SCIPAS-B schedules BMF/BMF-related jobs if inputs are available. RRPA08PE is an ad-hoc job that is processed on an "as needed" basis. RRPA08PE is the entry point to the SCIPAS-E processing. SCIPAS-E schedules EPMF/EPMF-related jobs if inputs are available. RRPA08PI is an ad-hoc job that is processed on an "as needed" basis as long as job I460V1 has been successfully processed. RRPA08PI is the entry point to the SCIPAS-I processing. SCIPAS-I schedules IMF/IMF-related jobs if inputs are available. RRPA08PM automatically runs on the weekdays after the SCIPAS-J processing has completed and if job I460V1 has been successfully processed. RRPA08PM is the entry point to the daily SCIPAS-I processing. SCIPAS-I schedules IMF/IMF-related jobs if inputs are available. RRPA08PV processes in the evening on weekdays if job I460V1 has been successfully processed. Before releasing RRPA08PV, the Master File Schedulers must review the SCIPAS reports and verify that the SCIPAS-J and SCIPAS-B processing has been completed. RRPA08PV is the entry point to the SCIPAS-V processing. SCIPAS-V schedules JPD dup-check-voucher jobs if inputs are available. RRPA09PC automatically runs Monday through Saturday at 1900 hours. RRPA09PC is the entry point to the evening SCIPAS-T processing. SCIPAS-T schedules TRDB/TRDB-related jobs if inputs are available. RRPA09PD automatically runs on the weekdays at 1800 hours. RRPA09PD is the entry point to the SCIPAS-D processing. SCIPAS-D schedules the TETR job if inputs are available. RRPA09PE automatically runs Monday through Saturday at 0615 hours. RRPA09PE is the entry point to the morning SCIPAS-T processing. SCIPAS-T schedules TRDB/TRDB-related jobs if inputs are available. RRPA09P1 automatically runs on the weekdays at 0800 hours. RRPA09P1 is the entry point to the morning SCIPAS-B and SCIPAS-E processing. If inputs are available, SCIPAS-B schedules BMF/BMF-related jobs and SCIPAS-E schedules EPMF/EPMF-related jobs. RRPA09P2 automatically runs on the weekdays at 1900 hours. RRPA09P2 is the entry point to the evening SCIPAS-B and SCIPAS-E processing. If inputs are available, SCIPAS-B schedules BMF/BMF-related jobs and SCIPAS-E schedules EPMF/EPMF-related jobs. RRPA10 processes multiple times with different 'Leg-IDs' while SCIPAS is running. Leg-IDs are similar to passes and allow SCIPAS to use the same basic RRPA10 JCL to schedule multiple files. RRPA10 schedules unprocessed files that are on the SCIPAS Scheduling file (RunBase). When unscheduled files are found, RRPA10 updates the SCIPAS RunBase to indicate the scheduling of the file and also builds the RRPA15 JCL. RRPA15 processes whenever RRPA10 schedules unprocessed files. RRPA15 retrieves a copy of the application JCL from Endevor, makes it 'production-ready' by adding input files, passes, cycles, etc. and then subIT the job to Control-M for processing. RRPA32 processes on an 'as needed' basis. It processes the SCIPAS "PRI" cards that are needed when a file has been transmitted, but doesn't appear on the ATR. PRI cards give the MFS schedulers the ability to post older 'user-identified' files to the SCIPAS Scheduling file (RunBase). RRPA55DB automatically processes after JDDB03 has been successfully processed. RRPA55DB adds the newly created DDB-03-803 file to the SCIPAS Scheduling file (RunBase) where it awaits scheduling into SCIPAS-I. RRPA55SA automatically processes on Thursday evening after JDDB11 has been successfully processed. RRPA55SA adds the newly created DDB-11-11 file to the SCIPAS Scheduling file (RunBase) where it awaits scheduling into SCIPAS-I. RRPA55SI automatically processes on the weekdays at 0615 hours if job I460V1 has been successfully processed. RRPA55SI adds the newly created 460-63-11 file to the SCIPAS Scheduling file (RunBase) where it awaits scheduling into SCIPAS-I. RRPA55SI is also the entry point into the special morning SCIPAS-I. Note: If it becomes necessary to expedite the processing of SCIPAS to resolve problems, the Master File Schedules have the authority and capability to process additional SCIPAS runs.

# SCIPAS Reports

2.7.6.11.2 (09-01-2020) SCIPAS Reports Upon completion of each SCIPAS, a SCIPAS Processing Summary Report is generated. The reports are automatically sent to Control-D and can be accessed on-line under the following report names / job names: MASTER FILE PROJECT REPORT NAME JOB NAME SCIPAS-J: Routers & DDB SCIPASJ RRPA90PA SCIPAS-I: IMF SCIPASI RRPA90PC / RRPA90PD / RRPA90PI SCIPAS-B: BMF SCIPASB RRPA90PB SCIPAS-E: EPMF SCIPASE RRPA90PE SCIPAS-T: TRDB SCIPAST RRPA90PF / RRPA90PH SCIPAS-D: TETR SCIPASD RRPA90PG SCIPAS reports are divided into four sections: The "NDM Receipts" section is a cumulative list of all files that were scheduled by SCIPAS and processed into the current cycle. This section includes record counts for the files and also identifies the job that processed the files. The "Application Program" section lists the jobs that processed the various input files that are scheduled by SCIPAS. This section includes projected and actual counts for the jobs, a list of inputs for each job, record counts/money amounts from LARS if available, and subsequent jobs that processed the output files from these jobs. The "DUP Check" section lists the SCIPAS duplicate file check jobs that processed the various service center files. The "Cards And Messages" section contains several sub-sections. The "Holds And Releases" section lists the SCIPAS 'action cards' that were built by the Master File Schedulers. Action cards aid in the control and resolution of potential problems that were identified (flagged) on the SCIPAS reports. The "Missing File" section lists control files that were received without a corresponding data file. Files listed in this section must be researched by the Master File Schedulers to ensure that the missing files are received. The "Retransmitted Files" section lists files that have been transmitted more than once. Files listed in this section must be researched by the Master File Schedulers to ensure that the proper files were received and processed. The "Outside Of Expected Cycle" section lists files that were received outside of the expected cycle. Files in this section must be researched by the Master File Schedulers to determine why the files were received. The SCIPAS reports identify (flag) many potential error conditions. When certain conditions are met, SCIPAS will hold the file or job and mark it with a series of asterisks (********). Any file or job marked with asterisks must be investigated and corrective action must be taken in order for the file or job to be processed. Listed below are examples of the error conditions that SCIPAS identifies. ****FAILED DUP CHECK message: generated when the duplicate data job detects a possible duplicate condition. ****DUPLICATE DOCUMENT NUMBER message: generated when the duplicate data job finds a duplicate document number. ****DUPLICATE SCHEDULE NUMBER message: generated when the duplicate data job finds a duplicate schedule number on the RDO files. ****CONTROL FILE IS CORRUPT message: generated when the duplicate data job cannot read the control file. ****WORK GROUP IS OUT OF SEQUENCE message: generated when the work groups aren't received in order. ****DATA FILE CNT = ??? CONTROL CNT = ??? message: generated when the data file and the control file counts do not match. (Note: ??? represents numeric counts) ****THE FORMAT OF THE WORK GROUP IS INCORRECT message: generated when the work group format is incorrect. ****PROBLEM FOUND, CHECK LARS LOG message: generated when an out-of-balance occurs in the B16002 job. ****THERE IS NO ORIGINAL TO REPLACE message: generated when a replacement file is received before the original file. ****PROJECTED = ??? ACTUAL = ??? message: generated when the projected count does not equal the actual count. (Note: ??? represents numeric counts) ****BAD DATA IN CTRL, SEE COH message: generated when the SCIPAS duplicate data job (RRPA41 or RRPA42) detects invalid data on the RDO control file. ****NON-SCIPAS JOB HAS A HIGH RC message: generated when an application job ends with a high return code. ****RUN ENDED WITH HIGH RC message: generated when a SCIPAS job ends with a high return code. ****NON-SCIPAS JOB HAS ABENDED message: generated when an application job terminates abnormally. ****RUN ABENDED message: generated when a SCIPAS job terminates abnormally. ****J7931C IDENTIFIED DUP DATA message: generated when the 7931C step of job J79301 identifies potential duplicate data. ****"R" FILES ARE NOT ACCEPTED message: generated when an "R" replacement file is received for files that are not permitted to have an "R" in the work group. ****MISSING RDO SCHEDULE NUMBER message: generated when the RRPA41 or RRPA42 job detects a missing RDO schedule number. ****REPLACEMENT RECEIVED, ORIGINAL ALREADY PROCESSED message: generated when a replacement file is received for a file that is not permitted to be replaced after is has been successfully process

# SCIPAS Panel Interface

2.7.6.11.3 (09-01-2020) SCIPAS Panel Interface The SCIPAS panel interface is accessed via a TSO session on the IBM mainframe and provides a quick, easy way to display processing information for files and jobs that have been scheduled by SCIPAS. In addition to providing information about the processing, the panels are also used to build the SCIPAS Action Cards. The SCIPAS panel interface is divided into four categories and displays the information described in IRM 2.7.6.12.3.1.

# SCIPAS Panel Interface

2.7.6.11.3.1 (09-01-2020) SCIPAS Panel Interface LISTCAT FILE INFORMATION for files that were created during Master File processing on the mainframe. The date and time the file was added to the SCIPAS scheduling file (RunBase). If applicable, indicates the reason the file is held or dropped. Identifies if the hold on a file was released. Displays a message if/when a file was rescheduled into processing. Displays the cycle/day, job name, pass, and status for jobs that processed the file. SCIPAS JOB for jobs that have been scheduled by SCIPAS. Displays the date and time that the job was completed. If applicable, displays the total record count (projected count) for all files scheduled into the job. Displays the total records (actual count) that were processed by the job. If applicable, indicates the reason the job is held or dropped. Identifies if the job or specific inputs were rescheduled. Identifies the processing status of the job. Indicates if reruns are permitted for the job. If applicable, indicates the status of a rerun. Displays the total number of inputs for the job. Selecting this field will display a list of the input files. Displays the cycle/day, job name, pass, and status for jobs that processed outputs of this job. EDT INPUT FILE for electronically transmitted files that have been scheduled by SCIPAS. Displays the date and time the file was added to the SCIPAS scheduling file (RunBase). Displays the date and time that the file transfer was successfully completed. If a file has been retransmitted, the label 'RETRANS' is displayed. Displays the record count extracted from the Controls file. If there is a mismatch between the data file count and the control file count, a message will be displayed along with the counts. Indicates if replacements are permitted for the file. Identifies whether the sequence of the work group is checked for the file. If applicable, identifies the reason the file is held or dropped. Indicates if the hold on the file has been released. Displays messages to indicate the status of the dup check processing. Indicates if a duplicate flag was accepted by the Master File Schedulers. If applicable, a message is displayed if/when a file was rescheduled. PACKET RELEASE INFORMATION for jobs that are scheduled by SCIPAS Displays whether the job has been released for processing.

# Building SCIPAS Action Cards

2.7.6.11.4 (09-01-2020) Building SCIPAS Action Cards SCIPAS Action Cards are built by the Master File Schedulers (MFS). The cards provide a way for MFS to take corrective actions on errors and also gives them some control over the processing. MFS must thoroughly investigate the situations to ensure that the proper cards are being built. This is especially important because the cards are immediately processed and recorded on the SCIPAS Scheduling file (RunBase). It is very difficult, if not impossible, to reverse cards that are erroneously built. Listed below is an alphabetical list of the SCIPAS Action Cards. Action Card Purpose Description ACC Accept High Return Code or Abend Condition Accepts an abend or a condition code that has been flagged as unacceptable. The job is marked as successfully completed and its associated output will then be scheduled into subsequent processing. COM Add Processing Comment Records information about a particular situation for a file or job. The comments will appear on the SCIPAS reports. DRP Drop a File or Job Drops specific files or jobs that have been processed and automatically reruns subsequent ("downstream") jobs. HLD Hold a File or Job Places a hold on a file or job so that it will not be scheduled until it is released by the Master File Schedulers. It should be noted that files can be held before they are received or created. ISO Isolate a File Isolates a Service Center file so that it is processed as a single input. RDP Release Duplicate File Releases files which have been identified as potential duplicates and allows them to process. REL Release Hold Releases files/ jobs previously held by MFS or jobs that have been flagged by SCIPAS due to various error conditions. RER Rerun a Job Schedules the rerun of a job. All subsequent ("downstream") jobs will automatically rerun. RSF Reschedule a File Reschedules an input file that was not successfully processed or was dropped. RSI Reschedule Inputs to a Job Reschedules all inputs from a prior cycle job into a new cycle. If the original job was successfully processed, the RSI card cannot be used. RSR Reschedule a Run Reschedules a job that is not pass oriented and adds additional inputs for processing. All subsequent ("downstream") jobs will automatically rerun. PKH Packet Hold Prevents a job from being scheduled. Packet Holds are typically used when waiting for the transmission of new JCL. PKR Packet Release Releases a job and perIT scheduling.

# Replacement Files

2.7.6.11.5 (09-01-2020) Replacement Files In most cases, when a replacement is needed for a file that has been successfully transmitted, the Service Center Campus MUST transmit the replacement with the letter "R" in the workgroup. The letter "R" should NOT be used in the DSN of control files. If a control file replacement is needed, the original control file will need to be uncatalogededued and the replacement should be sent with the same DSN as the original control file. Additionally, the letter "R" should NOT be used in the DSN of replacement files for TRDB or data from BFS (TRACS and RDO files). TRDB jobs require special recovery processing before a file can be rerun. If a replacement is needed, the original file will need to be uncatalogedued and the replacement file should be sent with the same DSN as the original file. If an "R" replacement file is received and the original file is still awaiting scheduling on the SCIPAS Scheduling file (RunBase), SCIPAS will ignore the original file and automatically schedule the replacement file. If MFS is aware that an "R" replacement is forthcoming and the original file has not yet been processed, a hold (HLD) card should be built to place a hold on the original file. When the "R" replacement file is received, SCIPAS will automatically schedule the replacement file. If the original file has already been processed and an "R" replacement file is received, the original file will be dropped and the original pass of the job will be processed without that file. The replacement file will be scheduled as the only input into a new pass of the job. The receipt of the "R" replacement file automatically initiates this process. When the message "***** Control File Is Corrupt" is displayed in the SCIPAS report, the control file must be replaced according to established procedures. After the newly transmitted control file is received, the pass of the Dup Check job associated with the original corrupted file must be rerun. Note: If the Dup Check job is current cycle, a RER (rerun) card can be built. If the Dup Check job is from a prior cycle, MFS must manually rerun the Dup Check job WITHOUT the SCIPAS Kick steps. If an abend occurs during the SCIPAS processing, the string of SCIPAS will stop. If MFS wants to resume SCIPAS processing, they must rerun the appropriate leg of job RRPA10. The SCIPAS Leg-ID document can be used to determine which RRPA10 leg was processing when the abend occurred.

# SCIPAS Processing, MFS Responsibiliyies and Miscellaneous Notes

2.7.6.11.6 (09-01-2020) SCIPAS Processing, MFS Responsibiliyies and Miscellaneous Notes Setup jobs for SCIPAS automatically process on Friday beginning at 0545 hours. Early morning special SCIPAS-I automatically processes weekdays at 0610 hours. A SCIPAS report is not generated at the end of this processing. The morning SCIPAS-T automatically processes Monday through Saturday at 0615 hours. After SCIPAS-T completes, a SCIPAS-T report (RRPA90PH) is generated. MFS is required to review the report and address any issues that have been identified. The 1st SCIPAS-J / SCIPAS-I automatically processes each weekday at 0700 hours. After SCIPAS-J completes, SCIPAS-I automatically starts and a SCIPAS-J report (RRPA90PA) is generated. At the completion of SCIPAS-I, a SCIPAS-I report (RRPA90PD) is generated. MFS is required to review both reports and address any issues that have been identified. The morning SCIPAS-B automatically processes each weekday at 0800 hours. After SCIPAS-B completes, a SCIPAS-B report (RRPA90PB) is generated. MFS is required to review the report and address any issues that have been identified. (Please Note: SCIPAS-B only schedules BMF application jobs Tuesday through Thursday.) The morning SCIPAS-E automatically processes each weekday at 0800 hours. After SCIPAS-E completes, a SCIPAS-E report (RRPA90PE) is generated. MFS is required to review the report and address any issues that have been identified. (Please note: SCIPAS-E only schedules EPMF application jobs on Thursday.) The 2nd SCIPAS-J / SCIPAS-I automatically processes each weekday at 1100 hours. After SCIPAS-J completes, SCIPAS-I automatically starts and a SCIPAS-J report (RRPA90PA) is generated. At the completion of SCIPAS-I, a SCIPAS-I report (RRPA90PD) is generated. MFS is required to review both reports and address any issues that have been identified. The 3rd SCIPAS-J / SCIPAS-I automatically processes each weekday at 1500 hours. After SCIPAS-J completes, SCIPAS-I automatically starts and a SCIPAS-J report (RRPA90PA) is generated. At the completion of SCIPAS-I, a SCIPAS-I report (RRPA90PD) is generated. MFS is required to review both reports and address any issues that have been identified. The 4th SCIPAS-J / SCIPAS-I processes each weekday at 1700 hours after MFS verifies that all critical input files have been received. In order to start the SCIPAS-J processing, MFS must manually satisfy a Control-M In-Condition. After SCIPAS-J completes, SCIPAS-I automatically starts and a SCIPAS-J report (RRPA90PA) is generated. At the completion of SCIPAS-I, a SCIPAS-I report (RRPA90PD) is generated. MFS is required to review both reports and address any issues that have been identified. SCIPAS-D automatically processes each weekday at 1800 hours. After SCIPAS-D completes, a SCIPAS-D report (RRPA90PG) is generated. MFS is required to review the report and address any issues that have been identified. (Please note: MFS manually releases this processing early, typically between 1515 and 1530 hours.) The evening SCIPAS-B automatically processes weekdays at 1900 hours. After SCIPAS-B completes, a SCIPAS-B report (RRPA90PB) is generated. MFS is required to review the report and address any issues that have been identified. (Please Note: SCIPAS-B only schedules BMF application jobs Tuesday through Thursday.) The evening SCIPAS-E automatically processes weekdays at 1900 hours. After SCIPAS-E completes, a SCIPAS-E report (RRPA90PG) is generated. MFS is Required to review the report and address any issues that have been identified. (Please Note: SCIPAS-E only schedules EPMF jobs on Thursday.) The evening SCIPAS-T automatically processes Monday through Saturday at 1900 hours. After SCIPAS-T completes, a SCIPAS-T report (RRPA90PH) is generated. MFS is required to review the report and address any issues that have been identified. SCIPAS-V (JPD dup-check/vouchers) is manually released by MFS each evening. A report is not generated for this processing. Final SCIPAS-I processes on a daily schedule and runs each weekday. Before Final SCIPAS-I processing is released, MFS MUST verify that all expected input files have been processed. The ATR, Processing Notes, and any other information that was received via Info-Notes and/or email are used during this verification process. Final SCIPAS-B and Final SCIPAS-E are processed on a weekly schedule. Before Final SCIPAS-B and Final SCIPAS-E are released, MFS MUST verify that all input files have been processed. The ATR, Processing Notes, and any other information that was received via Info-Notes and/or email are used during this verification process. After the processing of Final SCIPAS, various RRPAW jobs will be manually released by MFS after they have verified that All Final SCIPAS runs were processed and have ensured that there are no outstanding flags on the reports. MFS is responsible for: 1) monitoring SCIPAS processing; 2) reviewing SCIPAS reports to ensure that all inputs were scheduled and processed; 3) resolving or reporting processing issues that were detected by SCIPAS and flagged on the SCIPAS reports; 4) building SCIPAS action cards to resolve issues and control SCIPAS processing. Please note that all inputs and outputs for SCIPAS processing must be on non-intervention media.

# IRSC Job Setup and Monitoring

2.7.6.12 (09-01-2020) IRSC Job Setup and Monitoring This segment establishes procedures for job setup, processing and monitoring of IRSC runs within a consolidated site on the UNISYS ClearPath Mainframe Systems and IBM z/900 production systems. Job setup and monitoring is the responsibility of the MEM Schedulers assigned to the UNISYS Scheduling Section of the Operations Scheduling Branch (OSB). The actual processing of the computer runs is the responsibility of the MEM Schedulers to the UNISYS Scheduling Section (USS) within Operations Scheduling Branch (OSB).

# Job Setup on UNISYS and IBM

2.7.6.12.1 (09-01-2020) Job Setup on UNISYS and IBM MTB/MEM Schedulers need to verify the input files for each run that does not come from a predecessor run. When a computer run is initially being implemented, the input file information is obtained from Computer Operator Handbooks (COHs). These documents are available online through Docit except for SACS. On the UNISYS ClearPath Mainframe Systems (out of cons mode), a Tape Librarian can check for received inputs by entering the command @QTM. At the main menu, enter 2 for received files and press ENTER. Tab to LOCATE and type in the file ID of the input you are trying to locate and press ENTER to bring up the latest files that were received. The last file received is the most current on the system. To get out of this screen, tab over to EXIT and press ENTER. To exit the QTM menu, type 3 and press ENTER. Another method that can be used to check for received inputs on the UNISYS ClearPath Mainframe Systems (in or out of cons), is by printing the file. As an example, enter the command, @prt,f 19BSC*filename (where 19BSC = the SC Access Location Number [ALN] and SC code of the file). This command will list the directory information. When you have verified that all of the inputs have been received for your run, you will need to access the Production Control Interface (PCI) for all runs that have a dependency on a PCI job. To access PCI, you need to be out of the cons mode. At the ready prompt, or Start of Entry (SOE), enter the command @PCI. This will bring up the UNISYS Utility Menu. To access PCI, tab to PCI and press ENTER. This will bring up the PCI Main Menu. From this menu tab to " Display Preview of Run" and press ENTER. The next screen displayed will be the preview of files set to go into a run. At the Run ID prompt, enter the file ID of the run and press ENTER. All of the eligible inputs that have been received will be displayed. This means if you were to process the run at this time, these are the files that PCI would schedule as inputs for your run. Information and instructions for use of PCI can be found in the PCI Handbook. On the IBM z/900 IAP System, job setup is controlled by the National Headquarters. The scheduling package used on this system is Control-M. The MEM Schedulers will logon to the IAP system under the appropriate LPAR (Logical Partition) as shown below: LPAR IRSC Location SYSD 19BIRSC Brookhaven ECC-MTB SYSA 08ANIRSC Andover ECC-MTB SYSC 18AUIRSC Austin ECC-MTB SYSI 29OIRSC Ogden ECC-MTB SYSJ 28PIRSC Philadelphia ECC-MTB SYSB 07ATIRSC Atlanta ECC-MEM SYSG 09KCIRSC Kansas City ECC-MEM SYSE 17CIRSC Cincinnati ECC-MEM SYSF 89FIRSC Fresno ECC-MEM SYSG KIRSC Kansas City ECC-MEM SYSH 49MIRSC Memphis ECC-MEM SYSL ICS Production Jobs are scheduled and processed according to predetermined calendars. Modifications can be made to the schedule that will affect when a job will be scheduled to process. Modifications need to be verified by a CSA or the programmer that is responsible for that run, even the simplest of changes can affect other runs. An example of a modification may be to change the day of the week that the job will be scheduled and processed. Instructions on how to modify schedules can be found in the Control-M Handbook. There are also some jobs that need the input media (cartridge/tape) numbers placed in the Job Control Language (JCL). An example would be run ACJDS100. The input file comes from the UNISYS run DTR09. NOTE: On the UNISYS ClearPath Mainframe Systems, the command @PRT,F 19BSC*DTR0911 (where 19 = the SC ALN and BSC is the SC code of the file) should be used to locate the input number. To place the input number in the JCL of the run on the IAP System: At the ISPF Primary Option Menu, type IOA and press ENTER. This will take you to the IOA Primary Option Menu. On the option line, type 3 for the Job Status Screen. This screen will list all of the scheduled jobs on the IAP system. On the command line, type L JOBNAME (for example, L ACJDS100).At the far left of the job name, place a J (for JCL) and press ENTER. Scroll down through the job to the input DD and type in the number of the media (cartridge/reel) that you received when you typed in the @prt,f command on the UNISYS ClearPath Mainframe Systems. Press the F3 key to exit the JCL.

# Job Monitoring

2.7.6.12.2 (09-01-2020) Job Monitoring By monitoring the systems you will be able to see jobs start, end or error. Any problems can be quickly addressed. On the UNISYS ClearPath Mainframe Systems, monitoring of jobs that are in process, can be done by entering the command @@cons. On the IBM z/900 IAP System, monitoring of jobs that are in process, can be accomplished by accessing the system log, Control-M, and/or queues. Monitoring of jobs by accessing the system log: At the ISPF Primary Option Menu, type S on the option line to access the System Display and Search Facility (SDSF), and press ENTER. On the command line, type LOG and press ENTER. The system log will be displayed. The log does not automatically scroll. To scroll up the log, press the F7 key. To scroll down the log, press the F8 key. Monitoring of runs by accessing Control-M. At the ISPF Primary Option Menu, type M. At the IOA Primary Option Menu, type 3 for the job status. At the command line, type L JOBNAME, then press ENTER. On the status line, you can see if the job ended OK, or is listed as Wait Schedule (on the right of the screen). To scroll up the log, press the F7 key. To scroll down the log, press the F8 key. Monitoring of runs by accessing the input queue: At the ISPF Primary Option Menu, enter S for SDSF. Enter I for Display Jobs in the JES2 input queue. Tab beside the job you want to monitor and enter S to view the job. To scroll up the log, press the F7 key. To scroll down the log, press the F8 key.

# Reporting IRSC Processing Problems

2.7.6.13 (09-01-2020) Reporting IRSC Processing Problems Using the site's local intershift status report, the Input Posting book, and KISAM for the current cycle, identify all IRSC and Enterprise Computing Center problems. Report these problems to KISAM in the usual manner.

# Other IRSC Processing Problems

2.7.6.13.1 (09-01-2020) Other IRSC Processing Problems IRSC media that cause problems at ECCs fall into two general categories: Problem media includes any incoming data from the IRSCs, transmitted via C:D, FTP, RICOPY or courier, that cause problems during processing even if all of the data is successfully input. Dropped media is problem media from where no data was input or media that contains mixed data.

# Problem Resolution

2.7.6.13.1.1 (09-01-2020) Problem Resolution For files received via C:D, FTP, and RICOPY, the UNISYS Schedulers will: Determine the type of problem (bad transmission, incorrect data from the sending site, media is physically damaged, etc.). Request a retransmission, if necessary. Contact an ICS/ACS/Print (IAP) Computer Systems Analyst (CSA) if further investigation is required (if the problem still exists after retransmission). Note: See Processing File Tracking/Input Verification or File Transfer Process for the Receipt of Electronically Transferred Data, for file verification procedures for in this IRM for additional information. For files received via courier, the UNISYS Schedulers will: Determine if the file has been delivered to the Library. If the media is still at the ECC-MTB main building, follow the procedures contained in IRSC Processing Receipt of Shipment Procedures, to have the media shipped to the Annex. If the media is not at the ECC-MTB main building, contact Scheduling to verify if the media was shipped to ECC-MTB. If ECC-MTB has not received the media, request a replacement. Refer to Coordinating Requests For Replacement Files. Place the job on HOLD and document the problem (e.g. Operations Info Note).

# Procedures for Reporting Printing Problems

2.7.6.13.2 (09-01-2020) Procedures for Reporting Printing Problems When the customer contacts the IRSC liaison to report printing problems, the liaison will contact the ECC in the usual manner and request the print job be rerun.

# Coordinating Requests for Replacement Files

2.7.6.14 (09-01-2020) Coordinating Requests for Replacement Files This segment describes the actions required to request a replacement file and to fulfill a request for such a file in the IRS Centers. A replacement file is defined as any file that must be replaced to allow continued processing in the IRS Centers.

# Replacement Files

2.7.6.14.1 (09-01-2020) Replacement Files Replacement files can be any of the following: Any file that must be replaced when an original shipment is not received. Any file that must be replaced when a previously received file, contained on magnetic media, is unprocessable for any reason. Any file that must be replaced after the shipping site determines processing problems have corrupted the data in an original shipment. EDT/NDM incoming files that abended via CONNECT:Direct. Incorrect data received (bad data) and replacement is required at the request of the sending site and/or via SCIPAS determination. The only exception to this definition are those files which are originally received via RI-COPY/Network Data Mover (NDM) and, after receipt, require only a retransmission due to RI-COPY/NDM related problems.

# Replacement Responsibilities

2.7.6.14.2 (09-01-2020) Replacement Responsibilities The MTB Schedulers and/or the MEM Sehedulers in the UNISYS Scheduling Section (USS) are responsible for contacting the Enterprise Service Desk (ESD) when a replacement is required. ESD will open an Information Technology Asset Management System KISAM ticket when a replacement is required. The MTB Schedulers and/or the MEM Schedulers will prepare an ACTION Info Note or CCITS & Tunnover Book to document the action taken and will monitor and update, as appropriate. Additionally, they will resolve KISAM tickets and close the info note after the replacement has been received and successfully processed. The ESD is responsible for monitoring all requests for media replacements which are required within IRS domains. The MTB Schedulers and/or the MEM Schedulers are responsible for ensuring the file received/sent is the file that was requested. The MTB Schedulers and/or the MEM Schedulers are responsible for verifying and acknowledging shipments. The USS MEM Schedulers will be responsible for updating and resolving KISAM tickets and info notes when replacement media has been successfully processed for Mainframe Consolidation processing.

# ECC-MTB Initiating Requests for Replacement Files

2.7.6.14.3 (09-01-2020) ECC-MTB Initiating Requests for Replacement Files When it is determined a replacement file is required, a MTB Schedulers and/or MEM Schedulers will contact the ESD via the ITS toll free number (1-866-743-5748), or send an email (with all pertinent information included) to the *IT-EUES ESD (a follow-up phone call is required for all Priority 1 or 2 problems), requesting an KISAM ticket be opened. An ACTION info note must also be prepared to document the action taken. The MTB Schedulers and/or MEM Schedulers will provide the ESD with the following information required to open the KISAM ticket File ID Program Name Batch (if applicable) Cycle or Subcycle (if applicable) Reel Number Work Control Number Creation Date/Time Replacement Type Sending Site Method Sent. : The ESD will assign the ticket to the appropriate service provider determined by the information provided by the requesting customer. The MTB Schedulers and/or MEM Schedulers will query the active KISAM tickets every 30 minutes via the "Assignment" field, and print the tickets assigned to their area but have not yet been assigned to a team. These tickets will be provided to the appropriate team. The MTB Schedulers and/or MEM Schedulers Sections must update the "Assignee" field within 30 minutes of the ticket being assigned. Note: The ESD will contact a MEM Scheduler via common phone lines (extensions 7818 [0730-1630] or 7797 [1630-0730]) if not assigned within the 30 minute timeframe. The Scheduling team or MEM Scheduler assigned the ticket will update the ticket with all actions taken to follow-up on the replacement through Problem Resolution. The site preparing the replacement will resolve the KISAM ticket by completing the "Update/Resolution" window, " Update Actions" field, "Cause Code" field, and "Resolution Code" field once the replacement is sent. A courtesy call will be made to the receiving site informing them of the date/time the replacement was sent. Once received at ECC-MTB, the Scheduling team and/or MEM Scheduler assigned the ticket will also resolve the ticket with the received date/time and update the info note with this information. If the sending site has not yet provided the "Resolution Code" or "Update Actions," complete the following fields: Resolution Code--for example, RQST COMP or NFT. Update Actions--enter Received. If the replacement file still cannot be processed, or if a partial shipment has been received and another replacement is being requested, Scheduling and/or the MEM Schedulers must contact the ESD and request them to reopen the KISAM ticket. Scheduling and/or the MEM Schedulers will update the info note. The "Assignment" group will close the ticket and send an e-mail to all appropriate areas. Note: When a file needs to be uncataloged, Scheduling and/or USS will need to contact the ESD and request an KISAM ticket be opened to have the file uncataloged and cross reference the main FT ticket. If at any time there is a critical timeframe involved for a file replacement request, and the sending site is not responding to the request in a timely manner, the ticket should be escalated/upgraded by contacting the ESD, as follows: Dial the IT toll free number (1-866-743-5748) Press 2 for IT Call Center Press 2 for an Escalation Assistor In the "Update/Resolution" field of the KISAM ticket enter, "This ticket needs to be upgraded by ESD to a Priority 2 due to no response from the Sending Site." ESD will update the ticket with the actions taken to ensure the replacement is sent.

# Requests for Replacement Files from ECC-MTB

2.7.6.14.4 (09-01-2020) Requests for Replacement Files from ECC-MTB When it is determined by an IRS Center that a replacement file is required, the requesting site will open an KISAM ticket requesting a replacement from ECC-MTB, along with the reason for the replacement. ESD will assign the ticket to ECC-MTB. The ECC Help Desk will assign the ticket and send an e-mail to the appropriate "Assignment" group for action. The assigned group will then open a info note to document the request. Note: The ECC Help Desk will contact USS/OSB common line (extension 7818 [0730-1630] and 7797 [1630-0730]), if not assigned within 30 minutes. The "Assignment" group must update the " Share Assign" field with the team responsible for updating the ticket. The MTB Schedulers or MEM Schedulers will determine exactly what is required to fulfill the replacement request (i.e., individual magnetic media, multiple magnetic media, or an entire file). The ECC Scheduling team or MEM Schedulers assigned the ticket will be required to update the "Update" field with the status of replacement preparation. The following updates are required once these actions are taken: Recreates Retransmissions File put in active job file. Prepared transmittal Pull sheets created for job on floor--awaiting priority (if applicable). Transmittal on floor awaiting transmission Job completed transmittal to be prepared Transmission complete Transmittal prepared Shipped Note: Form 9255 should be annotated that this file is a replacement/retransmission for further clarification for MEM Scheduling . Form 9255 should also be annotated with the KISAM ticket number. The Scheduling team (MTB/MEM) assigned the ticket must update the KISAM ticket within eight hours of the replacement request. A report prepared by the ECC Help Desk is forwarded to designated contacts if updates are not timely. The recreated replacement file will be prepared for shipment and shipped as appropriate. For reference purposes, a MTB/MEM Scheduler will include the replacement file KISAM ticket number in the remarks section of the associated Form 9255, Tape Shipment Control Document. Note: The MTB/MEM Scheduler will be responsible for verification of acknowledgement of shipments as appropriate. Once the replacement media is shipped/EDT'd, the MTB/MEM Schedulers assigned the ticket will resolve the ticket by completing the "Problem Details" field with the date/time sent. The "Resolution Code" and "Update/Resolution" fields should be completed as follows: Resolution Code--for example, RQST COMP or NFT Resolution Description--enter Sent. MTB/MEM Scheduling/OSB will make a courtesy call to the receiving site informing them of the date/time the replacement was sent. The point of contact at the receiving site will be the customer that reported the problem Once the replacement is received, the receiving site will also resolve the ticket and enter the received date/time. The problem ticket will stay open until the file has been successfully replaced and the data is either input or printed. The receiving site will then close the ticket and send an e-mail to notify the appropriate areas. Note: One hour before the end of the shift, the KISAM Service Desk will need to print a list of the active tickets to be used for turnover at the Status Meeting.

# Cancelling Requests for Replacement Files

2.7.6.14.5 (09-01-2020) Cancelling Requests for Replacement Files If, after a request for a replacement file has been made, it is determined it is not needed, a MTB Scheduler or MEM Schedulers will contact the IRS Center, reference the ticket number, and inform them the file is no longer required. The MTB Scheduler and/or MEM Scheduler will resolve the ticket. A complete description of why the ticket is being cancelled should be entered in the "Update/Resolution" field, including the name of the person at the sending site notified of the cancellation. The ECC Help Desk will then close the KISAM ticket, and an e-mail will be sent notifying the appropriate areas.

# IRSC Processing File Tracking/Input Verification

2.7.6.15 (09-01-2020) IRSC Processing File Tracking/Input Verification This segment provides the requirements to establish procedures for the IRSC file tracking and input verification of incoming data from an outside source, i.e., ECC-MTB, ECC-DET, ECC-MEM, or other government agency, to a consolidated IRSC. The data should be received and processed in accordance with the Service Level Agreement (SLA). IRSC file tracking and input verification is the responsibility of the UNISYS Scheduling Section (USS) of the Operations Scheduling Branch (OSB).

# Receiving IRSC Input

2.7.6.15.1 (09-01-2020) Receiving IRSC Input The receipt of input to a consolidated site may be received via the following methods: RICOPY--The process of channel extension of an input file from IRSC mini systems to the ECCs ICS/ACS/Print (IAP) System. CONNECT:Direct (C:D)--The software product used to transfer data between International Business Machines (IBM) systems. Electronic File Transfer Utility (EFTU)--The software product used to transfer data from one system to another system. Shipment of magnetic media from IRSCs or other government agencies via ECC. QTM - A set of tools that is used for file verification.

# IRSC Input Received via RICOPY

2.7.6.15.2 (09-01-2020) IRSC Input Received via RICOPY The MEM Scheduler will logon to the IAP system under the appropriate Logical Partition (LPAR) as shown below: LPAR IRSC Location SYSD 19BIRSC Brookhaven ECC-MTB SYSA 08ANIRSC Andover ECC-MTB SYSC 18AUIRSC Austin ECC-MTB SYSI 29OIRSC Ogden ECC-MTB SYSJ 28PIRSC Philadelphia ECC-MTB SYSB 07ATIRSC Atlanta ECC-MEM SYSG 09KCIRSC Kansas City ECC-MEM SYSE 17CIRSC Cincinnati ECC-MEM SYSF 89FIRSC Fresno ECC-MEM SYSH 49MIRSC Memphis ECC-MEM SYSL ICS Production At the ISPF Primary Option Menu, Type IOA and press ENTER. This will provide access to the IOA Primary Option Menu. On the option line, type 3 for the Job Status Screen. This will show the status of all the scheduled jobs on the IAP System. At the ISPF Primary Option Menu, type IOA and press ENTER. Tab down to the job that has the same name as the input you are searching for. Once the job says "Job Ended OK," place a V (View) to the far left of the job and press ENTER. Tab again to the far left of the job and place an S (Select) to pull up the JES2 job log. Browse the job log until you find the mount message for the input file from the incoming site containing the cartridge number. Continue to browse the log until you find the output cartridge number. The output cartridge will be a ECC designated cartridge number. Near the end of the job log, you will find the record count of the file. This count will be listed in the statement, "Records In and Records Out." For files RICOPied to the ECC, the IRSC should verify the input and output media and record counts. These media numbers and records should be compared to the numbers and records that were found in the job log. If applicable, the media numbers and record counts should be recorded in a designated notebook or log sheet. If there are any discrepancies, a phone call should be placed to the outside source (ECC-MTB, ECC-DET, ECC-MEM, IRSC, etc.) for file verification. When verification is completed and recorded in the notebook or log sheet, the file tracking and verification is complete.

# Input Received via C:D

2.7.6.15.3 (09-01-2020) Input Received via C:D The MTB Scheduler will logon to the ECC's IBM TSOB System through TN3270. At the ready prompt, type PDF. This will access the ISPF Primary Option Menu. On the option line, type T (Transmit). This will access the IRS Transmittal System Main Menu. On the command line, type 10 for Incoming/Outgoing Automated Tracking Report (ATR), and press ENTER. On the option line, type in the number that corresponds to the IRSC you are tracking/verifying (i.e., 2 for the BIRSC ATR). At the Selection Panel, type 2 to browse the incoming files. Type the cycle number, fill in the appropriate IRSC and press ENTER. The ATR has now been accessed and all files that have been received will be displayed. The time and date the file was received, along with the input and output numbers, will be listed. If the file you are looking for is not there, then it has not been received. If the file has not been received timely, within the guidelines of the appropriate SLA, a call should be placed to the outside source (ECC-MTB, ECC-DET, ECC-MEM, IRSC, etc.). Once the file has appeared on the ATR and the information has been recorded in a notebook or log sheet, if applicable, the file tracking and input verification is complete.

# Input Received via EFTU

2.7.6.15.4 (09-01-2020) Input Received via EFTU The MEM Scheduler will logon to the UNISYS Clearpath Mainframe Systems. At the ready prompt or Start Of Entry (SOE), enter the command, as an example @prt,f 19BSC*filename (where 19BSC = the SC Access Locator Number [ALN] and IRSC code of the file). The file you are tracking/verifying should be listed along with the date and time the file was cataloged. If you receive the message that your file has not been cataloged or assigned, the file has not yet been received. If the file has not been received timely, within the guidelines of the appropriate SLA, a call should be placed to the outside source (ECC-MTB, ECC-DET, ECC-MEM, IRSC, etc.). Once the file has been cataloged and appears on the screen (after entering the above command) and the information has been recorded in a notebook or log sheet, if applicable, the file tracking and input verification is complete.

# File Transfer Process (FTP) for Sending Files

2.7.6.16 (09-01-2020) File Transfer Process (FTP) for Sending Files This segment describes procedures and requirements to be used when transmitting a file and corresponding controls electronically to the IRSCs or the ECCs using a compatible production system at the ECC, or IRSC. ECC-MTB also transIT to the Social Security Administration (SSA) and the Office of Child Support Enforcement (OCSE). In order to ensure the timely receipt of live data, procedures were established to electronically transmit requested data from ECC-MTB to our customers (i.e., IRSCs, ECC-DET). The primary mode of transmission will be a compatible production system at ECC-MTB and the HYPERchannel/T-1 circuits using CONNECT:Direct (C:D) software.

# Sending Files — General Responsibilities

2.7.6.16.1 (09-01-2020) Sending Files — General Responsibilities It is the responsibility of ECC-MTB management to ensure all balancing requirements have been satisfied before the data is released for transmission. Every effort will be made to transmit the data using the primary Electronic Data Transfer (EDT) system. If ECC-MTB is unable to transfer data timely, due to transmission problems, the file should be copied to " round" magnetic media for shipment. It is the responsibility of ECC-MTB (the transmitting site) to initiate corrective actions necessary for a successful transmission.

# Setting Up the Transfer, Using C:D Panels

2.7.6.16.2 (09-01-2020) Setting Up the Transfer, Using C:D Panels Logon to the TSOB (MBH1) system and enter CD on the command line of the ISPDF/PDF Primary Menu. At the command line, enter one of the following: IP--Submit IPW process to IRSCs. BP--Submit BPW process to IRSCs. O--Submit other weekly process to IRSCs. N--Submit non-weekly process to IRSCs. ECC-DET--Submit process to ECC-DET. SSA--Submit process to SSA. OCSE--Submit process to OCSE. On the "Initiate A File Transfer Screen," enter the following: Cycle--Enter the two digit cycle plus optional subcycle (e.g., 37E). For retransmissions, enter the letter "R" after the subcycle (e.g., 37ER). For IRSCs type "S" in front of the valid IRSC location. Data Set Name--Type "S" in front of the data set name to be transmitted. Press enter and the next Submit Process screen will appear. Enter the volume serial number(s) of the media to be transmitted (if applicable). For multi-reel files, the volume serial numbers must be separated by a comma. For disk-to-disk transfers or cataloged media files, no entries are required. If the file to be transmitted is a test file, the word " TEST" should be added to the "to" data set name (e.g., 1606011.test). Changes can be made to entries on the Submit Process screen by simply typing over what appears on the screen. Note: Any changes to the Submit Process Screen must be approved by management. If the Network Command Center (NCC) requests a file be transmitted in order to resolve a telecommunications problem, from the O (other IRSC files) screen, select 'NDMTEST'. NDMTEST will submit a process to transmit a test file from the ECC-MTB STK Silo to round media at the selected IRSCs. Press the enter key. If there were no problems, you will see the message "SUBMIT PROCESS SUCCESSFUL" appear under the command line and the process number will be displayed in the upper right hand corner of the screen. Fill-in the process number on the Form 3220 in the start statement located under the corresponding file name being sent (e.g., F NDM,RLSE X where X = the process number). Sign and date the Form 3220 on the "PROCESS SUBMITTED" line. The MTB Scheduler will enter their branch, initial and date the Shout Message to indicate the file transfer process has been submitted. To send additional files, repeat instructions described above. When the job is staged, the job setup must be forwarded to the EDT Console/Tape Library. Jobs requiring stand alone media must be forwarded to the MTB Schedulers. All other jobs will be sent directly to the EDT area (transmissions from disk or ATL). After the file has been transmitted successfully, MTB Scheduler will verify good completion via Connect Direct Panel.

# Accessing the Outgoing ATR

2.7.6.16.3 (09-01-2020) Accessing the Outgoing ATR The MTB Scheduler must access the outgoing ATR to verify there was a successful transmission. The following are procedures for updating and browsing the outgoing ATR: Note: Before browsing the outgoing ATR, it should be updated. Enter "6" on the command line of the ISPF/PDF primary menu (you must be logged on to the MBH1 System--TSOB). Enter "ATR" for the command. At the Main Automated Tracking Report Panel Option type 1 and hit enter. To create/update the ATR, enter "5" on the selection line, then enter the current cycle on the cycle line. Enter Sunday's date of the current cycle and press enter. To browse only, enter 6 on the selection line, then enter the cycle you wish to browse on the cycle line and press enter. Using the PF8 key, scroll to the corresponding file you wish to verify (you can also perform a "find" on the file by typing a " F" on the command line, followed by the file and pressing enter). The MTB Scheduler will then compare the data set on the outgoing ATR with the file-id listed on Form 3220 to ensure the information matches. The following fields must be verified for accuracy: ECC-MTB reel numbers. Batch and Cycle. Destination Code (07, 08, etc.). Date and Time of transmission. Process Number. Once the above information has been verified for accuracy, the MTB Scheduler will annotate the outgoing ATR. If any errors are identified, the MTB Scheduler will inform his/her supervisor so the problem can be further investigated and corrective action initiated. If the file appears on the ATR as not being transmitted, the MTB Scheduler will access the NDM statistics to determine the status of the transmission. A final review of the ATR for the current cycle will be started on Swing Shift, Saturday each week, to ensure all files to be electronically transferred have been sent. The MTB Scheduler will also ensure the outgoing ATR has been annotated to indicate each transmission has been verified for completion. The MTB Scheduler performing the review will bring discrepancies to the attention of the Scheduling Chief, on-duty, for resolution. (A info note is prepared indicating all files were transmitted successfully or problems were detected and follow-up is necessary.) The review will be conducted by the MTB Schedulers on succeeding shifts until all files are transmitted.

# Operational Processing Objectives Guide (OPOG)

2.7.6.17 (12-02-2020) Operational Processing Objectives Guide (OPOG) #This segment provides procedures for preparing the computerized Operational Processing Objectives Guide. #A MTB Scheduler in the ECC-MTB IBM Scheduling Section is responsible for updating the OPOG. #Computer processing at the Enterprise Computing Center (ECC) produces numerous types of output at various frequencies. Master Files (IMF/CADE, BMF, IRAMF, EPMF, PMF and IRMF), Combined Annual Wage Reporting (CAWR) and Information Returns Processing (IRP) are updated weekly and periodic extractions are made from them. This guide, arranged in alphanumeric sequence by project symbol, identifies the computer workload for the upcoming two-week period (current and subsequent week). #A working knowledge of the Time Sharing Option (TSO) terminal and a basic understanding of the Statistical Analysis System (SAS) is assumed when implementing procedures.

# OPOG, Source of Information

2.7.6.17.1 (12-02-2020) OPOG, Source of Information #IRM 2.7.9, ECC-MTB Processing Timeliness, is the basic source of information. Request for Information Services (RIS) issuances, memoranda and other communications within ECC-MTB and National Headquarters provide updated information on new projects. #The MTB Schedulers in IBM Scheduling Section maintain a tickler file containing pertinent information on projects. This file contains documentation designated for each week of the year. Notations are made as changes occur for the appropriate week.

# OPOG Organization

2.7.6.17.2 (12-02-2020) OPOG Organization Projects are identified by a ten character project symbol along with a brief description of the project. The symbol is used to list the project in alphanumeric ascending sequence. (For example, project IEW-2007A.) The major sort identifies the tax year comprised of the sixth and seventh characters that are numeric. (Using the above example, this would be 2007.) The secondary sort identifies the project comprised of the first three alpha characters. (Using the above example, this would be IEW.) The final sort identifies the week and a subcycle, if any, comprised of the eighth, ninth and tenth positions. This is a combination of alphanumeric characters. (Using the above example, this would be 43A.)

# Building the OPOG

2.7.6.17.3 (12-02-2020) Building the OPOG #LOGON to the IBM mainframe systems. ) #From the ISPF/PDF primary option menu, enter number 6 at the option line. #On the TSO command processor, enter the command MFSS. The MAIN MENU will be displayed. Select 1) OPOG bulletlist li • ## li bulletlist # para para (4) #The IBM Scheduling Section (MFSS) OPOG MAIN MENU will appear: 1 EDIT OPOG DATA BASE FILES 2 CREATE INITIAL OPOG REPORT (OPOGS002) 3 PRINT FINAL OPOG REPORT 4 Z Exit Select Option 1 — EDIT OPOG DATA BASE FILES — The panel will be displayed, select one of the following options: 1 EDIT OPOG NEW PROJECTS FILES 2 EDIT OPOG DELETES FILE 3 EDIT OPOG NOTES FILE 4 EDIT OPOG TAX YEAR PROJECTS FILE 5 EDIT OPOG PROJECT CYCLES FILE 6 EDIT OPOG INITIAL REPORT LIST FILE 7 Z EXIT Any of the above options will put the user into the ISPF EDIT mode. Edit the database Press the PF3 key to exit Selecting Option 2 — CREATE INITIAL OPOG REPORT (OPOGS002) — The panel will be displayed, enter the following information: SELECT ENTER BEGIN PROCESS CYCLE The year is already displayed, you can type over, otherwise, enter the BEGIN process cycle. END PROCESS CYCLE The year is already displayed, you can type over, otherwise enter the END process cycle. EXTRACT DUE DATE Enter the extract due date as MMDDYYYY. Note: if there is no NOTE INFORMATION, depress the ENTER key and the "INITIAL REPORT JOB (OPOGS002) " Report will be submitted. Otherwise, enter the "NOTE INFORMATION" as shown below. Note Number Title Action to Implement Note 1 – Project Type Enter IPW or BPW Note 1 – Beg Cycle Ind Leave blank or enter X if note is for the beginning cycle. Note 1 – End Cycle Ind Leave blank or enter X if note is for the beginning cycle. Note 2 – Project Type .Enter IPW or BPW Note 2 – Beg Cycle Ind Leave blank or enter X if note is for the ending cycle. Note 2 – End Cycle Ind Leave blank or enter X if note is for the ending cycle. Note 3 — Project Type Enter IPW or BPW Note 3 — Beg Cycle Ind Leave blank or enter X if note is for the ending cycle. Note 3 — End Cycle Ind Leave blank or enter X if note is for the ending cycle. Note 4 — Project Type Enter IPW or BPW Note 4 — Beg Cycle Ind Leave blank or enter X if note is for the ending cycle. Note 4 — End Cycle Ind Leave blank or enter X if note is for the ending cycle. When all NOTE information has been keyed in, press the ENTER key, and the INITIAL (OPOGS002) Report job will be submitted. When the report has ended the user may select Option number 4, EDIT OPOG DATA BASE FILES and then select EDIT THE INITIAL OPOG REPORT (LIST1) File, for editing. To exit from these options press the PF3 key. Select Option 3 — PRINT FINAL OPOG REPORT — The MFSS panel will be displayed, enter the following information: SELECT ENTER BEGIN PROCESS CYCLE The year is already displayed, you may type over, or enter the BEGIN process cycle. END PROCESS CYCLE The year is already displayed, you may type over, or enter the END process cycle. Press the Enter key and the final report will be submitted. When the job, Final OPOG Report is completed it will be available on CADISPATCH.

# OPOG Error Messages

2.7.6.17.3.1 (12-02-2020) OPOG Error Messages (1) #When certain errors occur, a short error message will appear in the upper right corner of the panel. If the error is not descriptive enough, press the HELP PF1 key and a brief description will appear.The following are error messages that can be produced by the OPOG Project: ERROR MESSAGE DESCRIPTION Invalid Cycle Cycle must be 01 thru 53 End Process Cycle Error End process cycle must be greater than BEGIN process cycle. Invalid Month Month must be 01 thru 12 Invalid Day Day must be 01 thru 31 Invalid BEG Cycle IND Cannot select more than Two Beginning cycles. Invalid END Cycle IND Cannot select more than Two Ending cycles. BEG/END Cycle IND ERR 1 BEG and END cycle indicators cannot both be blank Project Type Error Previous project type cannot be blank BEG/END Cycle IND ERR 2 Cannot select both BEG and END cycle indicators

# Comparison Report

2.7.6.17.4 (12-02-2020) Comparison Report 1) #Every Friday evening, Control-M will automatically copy the data set 'RA.OPOG.LIST1' to 'RA.OPOG.LIST2.' This will protect the data submitted the following week. Logon to a terminal and select 'RA.OPOG.CRTL,' then select member COMPOPOG. Change the cycles you want to compare and submit. (If comparing current week, it should be done towards the end of the week.) The run will pull off projects from 'RA.OPOG.LIST2' that have estimated hours completed; i.e., no dashes or blanks.# para para (3) #The output will be a comparison report of the OPOG estimated times and the actual processing times from the SOO database. The output will go to CA-Dispatch (report name OOSBCOMP). The comparison report is used to provide estimated times and actual times on an as needed basics

# Rerun Function Codes

2.7.6.18 (09-01-2020) Rerun Function Codes National Headquarters may require written rerun reports. Use the following data in preparing rerun reports and mail them to the requesting office: date of rerun (mm/dd/yyyy), run-ID, time lost, rerun code, system, appropriate remarks (e.g. reason for rerun, corrective action). See the Exhibit 2.7.6–1 in this IRM for Functions Codes and Exhibit 2.7.6–2 for Reason Codes.

# Master File Processing Status Report

2.7.6.19 (12-02-2020) Master File Processing Status Report To facilitate the flow of operational information between shifts, the centers have developed Master File Processing Status Reports. This report furnishes the current status of all computer projects scheduled for the site's current projects. ECC Master File Scheduling Section, Operations Scheduling Branch, has developed consolidated status reports that encompass all phases of IT processing to identify information needed by oncoming shift to continue Scheduling activities along with an Intershift status reports for Scheduling to identify information needed by the oncoming shift to continue Scheduling activities in a seamless fashion.

# Requesting Changes to File Retentions

2.7.6.20 (09-01-2020) Requesting Changes to File Retentions Prior to the IRSC Mainframe Consolidation Project, the IRSCs adjusted file retentions at the local level. The motivation to change these retentions varied from site to site but most often involved extending retentions to avoid reruns or recreates. Oversight and security entities are another source of these file extensions. These offices would request that local management extend retentions on selected files for use at a later date. These files were generally used for research, investigations, etc. The inconsistency of retentions on identical files processed at each IRSC has had a negative impact on the system scheduling and the disaster recovery segments of the consolidation effort. File extensions have expanded the equipment resources needed for processing at the computing centers, and required Programmers/CSAs to change ECL and reimpose local extensions with the receipt of each new updated program transmittal. This segment provides for a central, locally administered database of consistent standardized file retentions, and processes on how the computing centers inform one another of changes, updates to file retentions. Additionally, these procedures require a mirror image of the retention database, and what actions are to take place for verification. The AAF database will be administered by the AAF Administrator (AAFA) appointed at each Enterprise Computing Center. Research to determine a retention and the primary contact for National Headquarters programmers and Program Offices will be the Magnetic Media Specialist (MMS). The MMS is currently located at ECC-MTB. The Enterprise Computing Center AAF will compare their respective AAF retention database bi-monthly. The action is necessary to ensure a mirror image. The results of this compare will be documented and changes made to the AAF so that the database are identical. The National Headquarters, Director of Operational Readiness, will conduct periodic audits or Standardization Assessments to ensure compliance. When the computing centers do not agree on a file retention, each Enterprise Computing Center will document their respective justification for their proposed file retention and forward it to National Headquarters Scheduling Section for review.

# Administration of the Retention Database

2.7.6.20.1 (09-01-2020) Administration of the Retention Database The database containing standardized file retentions in the UNISYS environment for the Internal Revenue Service is the Automatic Attribute Feature (AAF). The AAF is a feature of the UNISYS STAR system. The Enterprise Computing Centers will maintain a synchronized AAF database. The AAF database will be administered by the AAF Administrator (AAFA) appointed at each Enterprise Computing Center. Research to determine a retention and the primary contact for National Headquarters programmers and Program Offices will be the Magnetic Media Specialist (MMS). The MMS is currently located at ECC-MTB. Information on accessing the AAF database and changing file retentions can be found in the UNISYS STAR Operations Guide. All retention recommendations determined by the research of the MMS will be provided to the Enterprise Computing Center AAFA for their information.

# Determining File Retentions

2.7.6.20.2 (09-01-2020) Determining File Retentions A number of sources exist that will assist the AAFA/MMS to determine the correct file retention. The following are examples of the sources most often used: New program file retentions will be extracted from the accompanying Computer Operators Handbook (COH) when received at the computing centers, or The program ECL or other similar resource will be used to establish the retention, or The MMS will contact the programmer and request a retention. If a retention cannot be determined using the traditional sources above, the following may be contacted: Program Developer or Program Office, Prime Programmers as provided by KISAM, ITS customers receiving processed data as listed in the Service Level Agreements (SLA). When an email from the programmer or other viable source is received providing or approving a new proposed retention, that email will be shared between the computing centers. When the AAFA at both computing centers approve a new or proposed retention, the site's administrator will pass this information on to the MMS who will update the AAF database within 24 hours. When the computing centers do not agree on a file retention, the retention research data from each Enterprise Computing Center will be forwarded to National Headquarters Scheduling Section for review. A discussion on the disputed retention with all interested parties will be held and a decision will be made.

# Non-Response to Retention Requests

2.7.6.20.3 (09-01-2020) Non-Response to Retention Requests At times a response from a particular programmer for a retention change requested by the AAFA/MMS may not be timely. When that happens, take the following action: The AAFA/MMS will contact the programmer's team leader for assistance. The AAF/MMS will provide the information surrounding the contact with the program to the AAFA/MMS supervisor for follow-up action. The AAF/MMS will contact the National Headquarters Standards Compliance Section for assistance.

# Updating the AAF

2.7.6.20.4 (09-01-2020) Updating the AAF When the AAFA/MMS has determined that the database may be updated and the change has been posted to the AAF an AAF update will be prepared and forwarded via email to the AAFA of the other Enterprise Computing Center. The AAF update email informing the Enterprise Computing Center AAFA of a new or changed file retention will contain the following information: File name/job name, current retention, new retention, duration of retention (if necessary), justification, comments (optional). Upon receipt of an Enterprise Computing Center AAF update, the AAF database will be updated accordingly within 24 hours. Some files will not necessarily be processed at both computing centers. However, the files and respective retentions will be entered at both sites as a precaution in the event of a business interruption or disaster recovery effort.

# Temporary Retention Changes

2.7.6.20.5 (09-01-2020) Temporary Retention Changes The Enterprise Computing Center AAFA/MMS may independently authorize a change of retention due to an extraordinary or emergency situation. This approval may be authorized during non-prime hours by phone from the AAFA/MMS. However, the documentation supporting this request must be provided in writing by the requestor to the site's AAFA/MMS within 72 hours of the initial authorization. The change will then be forwarded, as specified above, via email to the other Enterprise Computing Center.

# AAF Database Compares

2.7.6.20.6 (09-01-2020) AAF Database Compares The Enterprise Computing Center AAFA will compare their respective AAF retention databases bi-monthly. This action is necessary to ensure a mirror image. The results of this compare will be documented and changes made to the AAF so that the databases are identical. The National Headquarters, Director Operational Readiness, will conduct periodic audits or Standardization Assessments to ensure compliance. Then the computing centers do not agree on a file retention, each Enterprise Computing Center will document their respective justification for their proposed file retention and forward it to National Headquarters Scheduling Section for review. The National Headquarters, Director of Operational Readiness, business stakeholders, the Scheduling Section will arbitrate difference in retentions after each compare, if the respective Enterprise Computing Center AAFA/MMS cannot agree. Documentation for each file retention found in dispute during the bi-monthly compare will be available for one year. The compare data will be available for review by oversight offices and similar organizations even if the disagreement has been resolved.

# Correspondence Transmittals

2.7.6.21 (09-01-2020) Correspondence Transmittals The monthly correspondex transmittal consists of a hard copy Document 6548, magnetic media templates of the letter files, and soft copies of the Correspondex Expert System (CES) letter files. ECC-MEM staff personnel prepare camera copies of the Document 6548 and mail them to National Headquarters Publishing Services. This package must have a completed Form 1767 signed by pre-authorized official, to comply with the agreement between National Headquarters (Publishing Services) and ECC-MEM staff personnel. Each major letter change must include a completed Form 1767, that a Notice Clarity employee has reviewed, stamped and signed. Note: Publishing Services will not accept the change without the form. Return the blue copy of the Form 1767 to the ECC-MEM staff when the camera copy has been processed and is on its way to the field site. Magnetic Media Tape: The ECC-MEM staff will, monthly, place the update letters and notices on a master letter file, and send them to the Enterprise Computing Center. FTP or use overnight mail to send the tape, a Form 3220, and supporting documentation to the affected destination. Soft copy, CES files: Use email to send the executable, letter data and knowledge base files directly to the letter technicians at each IRSC and Austin Development Center. The letter technicians disseminate the data to the UNIX and Windows XP system administrators. All field site operatives must adhere to the prescribed time frames. The CES specialist at ECC-MEM updates this table annually.

# Incoming Correspondex Information

2.7.6.21.1 (09-01-2020) Incoming Correspondex Information Information to update the master letter file arrives from various sources of the Internal Revenue Service: National Headquarters, regional, area, and IRSC personnel. Minor changes: Typographical errors or letter appearances do not require a Form 1767. The customer can E-Mail, fax, or telephone the ECC-MEM staff with a request for this type of change. Each transmittal has a cut off date for inclusion. Send IDRS Correspondex quarterly update volume control listings to ECC-MEM via magnetic media. The Scheduling Section in the IRSCs gathers this data. The tape retention is 180 calendar days.

# Job Balancing

2.7.6.22 (09-01-2020) Job Balancing IRSC balancing is a process that verifies records transferred, merged, processed, added or deleted before, during, or after processing. For the purpose of this segment, balancing can be broken down into two categories: Automated run-to-run balancing and manual balancing. Because of delays in automating some run-to-run balancing tasks, and delays in the development of an automated system, a manual process will serve in the interim. Unfortunately, the manual process will be labor and paper intensive. Later in this document, we describe these new procedures. There are multiple aspects of balancing: run-to-run balancing, manual balancing, balancing external files, balancing with Production Control Interface (PCI).

# Run-to-Run (R2R) Balancing

2.7.6.22.1 (09-01-2020) Run-to-Run (R2R) Balancing This is an automated balancing process that is internal to the application or job-run stream. This function verifies that the appropriate record counts are carried throughout the application, or the record counts are carried forward from one application to another as in a multiple application job-run stream. As a rule, that process is transparent to the operator unless an out-of-balance condition is identified. If an out-of-balance condition occurs, the operator will contact the balancing clerk or MTB Schedulers. Many times, depending on the application, the out-of-balance condition may be corrected at that point. If an out-of-balance condition cannot be corrected locally, notify the KISAM coordinator and prepare a trouble ticket in the usual manner.

# Manual Balancing

2.7.6.22.2 (09-01-2020) Manual Balancing This segment provides information needed for manual balancing. In the future, it is expected that many of the runs requiring manual balancing will be automated for the "mainline processing" runs. Some manual balancing for Tier 2 and other "unique" runs, however, will require a concentrated effort to automate. Document 7076, Run-To-Run Balancing, (1/98) provides basic information for manual balancing. The computing centers require two supporting systems software packages to assist in the balancing process. These systems speed the balancing process and are not considered automation tools. They are: Electronic Online Notification System (EONS), and Computer Balancing Application (CBA), Version 3.0. EONS is a database containing an electronic version of the centers' output. Using the simple EONS tools the user can view the individual stored documents that include summary and statistical information needed for input into the balancing process. An alternative to EONS is under development and future updates to this document will address that. The Computer Balancing Application provides an outline of the step-by-step process and states what figures are required, the sequence, and the subsequent totals to determine if the run is balanced. In some instances, the outline does not provide all the detailed requirements the user should know.

# Balancing External Files from the IRSC

2.7.6.22.3 (09-01-2020) Balancing External Files from the IRSC It is critically important that the data transmitted between the IRSCs and the computing centers (known as external files) be verified by balancing. This is accomplished by comparing the record count or financial count known to be on the tape prior to channel extension to that received at the Enterprise Computing Center. The external user or Tier 2 Systems Administrator will provide the IRSC liaison with the tape files and record counts, if available, for transmission. This includes files that may be sent through the mail or other courier services. When a file is ready to be channel-extended from the IRSC to the Enterprise Computing Center and the record count or financial information is provided with the tape, forward this count via F3220 to the Enterprise Computing Center, Service Center Scheduling. (The Enterprise Computing Center will provide the fax number.) This fax will also serve as a paper audit trail on data traffic between the IRSC and Enterprise Computing Center. Save these paper documents until an automated process is in place. Complete the form Tape Transmission, of a IRSC Job Request/Release fax sheet. When the liaison receives a file from an external user or Tier 2 Systems Administrator, and the record count information is not provided with the tape, use the count provided at the completion of the copy process through the channel-extender. Prepare a fax in the same manner as discussed in (3) above. Remember to indicate with an N/A that the counts were not available prior to the transmission of the media.

# Balancing With Production Control Interface (PCI)

2.7.6.23 (09-01-2020) Balancing With Production Control Interface (PCI) PCI is divided into a number of components and is run on the UNISYS system . There is a batch component that runs before the application program. There is the user interface component, and there is the component that kicks in automatically whenever ICI/ATIS gets a message. The PCI batch component generates and executes PRT,F statements that search the system catalog for specific files. This updates the PCI databases information about files. It tracks the information of a newly created file and old deleted files. PCI then scans its databases looking for eligible unprocessed files. If it finds such files, PCI stages the file into the target application and issues messages to the console telling AMS how to answer the upcoming prompts. The PCI user interface program is a series of screens that allow people to interact with the PCI databases. From the main menu, a person can: display information about runs and files; back out runs; preview inputs; look at past AMS parameter files; place on hold, files that haven't been processed; release files that are on hold. PCI routes predetermined files into awaiting inventory to ensure they are verified before they are committed to processing. When a file is channel extended to the ATL, a message routes from the IBM machine to the UNISYS ICI/ATIS interface. There the file is catalogued on the UNISYS system. Then PCI counts the number of records on the file and adds the information to the PCI databases. To add information about new files to PCI use PCI batch preview and F query. The catalogue search in PCI batch will post new files. The PCI preview option finds new files as well as the PCI display waiting inventory option. Channel extended files are captured and placed in the PCI databases via ICI/ATIS control. Files are also found via file tracking report. Note: It is important to remember if you are using PCI to see if a file has been catalogued. (A file may have been catalogued but not be in the PCI inventory unless a preview or a waiting inventory option is invoked.) Display file information only provides information that is in the PCI database because of earlier activity.

# Using the PCI Menus

2.7.6.23.1 (09-01-2020) Using the PCI Menus The PCI main menu is invoked by keying in @PCI. If a user has the proper security profile, the following options will be listed. [ ] Display Run Information [ ] Display File Information [ ] Back Out a Processed Run [ ] Display "Preview" Of Run [ ] Display a Past AMS Parameter File [ ] Display Waiting Inventory [ ] Display File Statistics [ ] Display Processed Run List [ ] Update or Add Run Comments The user can tab to the desired option and press the enter key to bring up the next screen. There is also an option at the bottom of the menu screen to exit the PCI main menu. Note: Make sure you are not in CONS mode when entering the PCI screens. It could be tough to get out without losing your session. Also note that PCI does an internal @qual statement and sets the qualifier back to the user's qualifier when PCI is left. This means that if you have a qualifier of 49MSC when PCI is invoked, that qualifier will no longer be active when PCI is left.

# Run Information Under PCI Control

2.7.6.23.1.1 (09-01-2020) Run Information Under PCI Control To see information about runs, select either Display Processed Run List or Display Run Information. The "list" option will display applications under PCI control. Scroll the list forward by pressing F1 and backwards by pressing F2. An example of how the screen might look is: Action RunID PCI Run Seq Num Date Time [ ] AMS01 PCI81 00003 1998 08/20 18:42:39 [ ] CCA01A PCI01 00003 1998 08/20 18:08:05 The run id field is the name of the application that was staged. The PCI Run is the run scheduled prior to the application and responsible for the staging of the application. The Seq Num is the number of application records under PCI control. The Date and Time reflect when the PCI job did the staging. Selecting one of the items by tabbing to the Action field of the line and pressing Enter will produce the Display Run Information display. If the user selects Display Run Information from the main menu, the prompt asks for the run ID. Inputting the run ID would produce the following information: Action RunID Seq Num Scheduled [ ] CCA01A 00003 XXXX MM/DD 18:08:05 [ ] CCA01A 00002 XXXX MM/DD 21:49:36 [ ] CCA01A 00001 XXXX MM/DD 19:12:22 It is important to note the sequence number. At a later point if it is necessary to back a run out, the run ID and the sequence number must be input. The sequence number identifies the run to a single running. The above list is also scrollable with the most recent activity showing at the top of the list. Selecting a line from the list would result in the following type of information being displayed. RunID Seq Num Scheduled CCA01A 00003 XXXX MM/DD 18:08:05 [ ] CCA0130 XXXX MM/DD 18:03:47 Now the files input into the CCA01A run are displayed in a scrollable list.

# File Information Under PCI Control

2.7.6.23.2 (09-01-2020) File Information Under PCI Control To see information about files, select either Display File Statistics or Display File Information. The statistics option will display a scrollable list of all the files under PCI control. Below is an example of such a list: Action Filename Count Total Files: 001764 [ ] CAF037501 00008 [ ] CAF037501 00003 [ ] CCA0130 00002 The count indicates the number of CAF037501 files under PCI control. Selecting one of these lines would give the user the same information that Display File Information does, but Display File Information prompts the user for the file name. Below is an example: Filename: CCA0330: Action Cycle VolSer Date Time Held Ind Run Date Seq Num Multi Runs Com [ ] 1 C 1998/08/20 18:03 — CCA01A 8/20 00003 — [ ] 1 D 1998/08/13 18:09 — CCA01A 08/13 00001 — Information for the file includes the absolute cycle, volume serial number, if the file is current cycle or has been deleted, the catalog time stamps, if the file is held, and information about the run that the file has been scheduled into. To the right is room for comments and an indicator letting the user know that more runs may be involved. Selecting one of the lines would produce the following information: Filename: 49MSC*CCA0130 (1): Current Cycle: Disk/Tape: Yes Disk Run Date Time Seq Num Date Cataloged: 1998/08/20 1. CCA01A 1998/08/20 18:03 00003 Time Cataloged: 08:03:47 2. Record Count: 00000000 3. Number of Volumes: 4. 5. [ ] Release File [ ] Hold File [ ] Enter Comment

# Controlling Inputs Under PCI

2.7.6.23.2.1 (09-01-2020) Controlling Inputs Under PCI From the 'File' screen it is possible to place a hold on a file. A held file is not considered an eligible input and will not be staged into a run. A held file may be released, and when released it becomes an eligible input. Once a file has been staged into a run, it won't be staged into that run again. For this reason it is sometimes necessary to use the Back Out a Processed Run option. If a run must be restaged, or the inputs into it changed, back the run out. When backing out a run, the user will provide the run name and the run sequence number. The inputs that were staged into the run will then be marked as not having been staged into that run and will be considered eligible for the next PCI Run. Use the Display "Preview" of Run option to verify what PCI would do if the PCI batch jobs ran at that moment. The files that PCI would stage are listed under the run selected for preview. It is possible to have the default status of a file be set to "not eligible" . For example, files that are channel extended can be set to a "waiting" status. Such files show up under the Display Waiting Inventory option. Using that option would list all the files that are in waiting status. Such files will not be staged until they are verified. See below: Action Status Filename Date Time Record Count 1st Volser [ ] — DED0101 1998 08/19 09:35 000623 J85326 [ ] W DED0101 1998 08/19 09:35 001291 J46549 [ ] W DED0101 1998 08/19 09:35 001291 J54232 By tabbing to a line and selecting it, the user can Verify File or Ignore File. In the example above, the first DED0101 has been verified. Since the record counts on the second and third files are the same, it is possible that the same file was channel extended twice. After research it was determined that the second file is the one desired to be input. The user would verify the second file and ignore the third file. Ignored files will no longer show on the waiting inventory. Files that have been staged into processing will also no longer show on waiting inventory.

# Examples of PCI Use

2.7.6.23.2.2 (09-01-2020) Examples of PCI Use The following examples are intended to help clarify how PCI works from a user's perspective. Remember that the preview option finds inputs and sees what PCI would do if it ran, but the preview does not schedule the files. Example One of implementing PCI for the first time to support a run: Do a preview and see inputs staged that have already been processed. Place holds on the files that need to be skipped. Do a preview and see only the correct inputs staged. When PCI runs, the correct inputs get staged. Example Two of implementing PCI for the first time to support a run. Do a preview and see inputs staged that have already been processed. Place holds on the files that are to be input. Run the PCI job. The undesired inputs are now staged. Release the holds on the files that were held in step b. Do a preview and see only the correct inputs staged. When PCI runs, the correct files get staged. Example Three of a rerun of an application because a file was left out. Make sure the missing input is cataloged. Prepare the application for a rerun. Use the PCI back out option to make the original inputs eligible. Do a preview to ensure the correct files are picked up. When PCI runs, the correct files get staged. Example Four of a rerun of an application because an incorrect file was processed. Prepare the application for a rerun. Use the PCI back out option to make the original inputs eligible for the next running. Place a hold on the file that is to be held out. Do a preview to ensure the correct files are picked up. When PCI runs, the correct files get staged.

# Additional PCI Information

2.7.6.23.2.3 (09-01-2020) Additional PCI Information PCI will not stage a file that has been deleted. PCI will still track it for audit trail purposes. PCI will not stage a tape file that does not have a volume serial number. Such a file will still appear in the inventories for audit trail purposes. Adding the volume to the catalog will not change things. It still won't be input. Deleting such a file and then re-cataloging it with the volume serial number will work. PCI uses the catalog name and time stamp information as the key in the file database. PCI uses the run name and sequence number as the key in the run database. The PCI files are reorganized each morning at 08:00 hours. Don't leave the PCI screens up. Exit out of the screens when the work is finished. If you time out, you may need to start your session over due to protected fields on the screen.

# Modified Run Executive (MREX) Level 8R1

2.7.6.24 (09-01-2020) Modified Run Executive (MREX) Level 8R1 Enterprise Computing Centers (ECCs) use Opcon/xps, a software package from SMA, to perform many functions being done by REX in the IRSCs on the UNISYS system. Opcon/xps will automate job scheduling and take over the portion of REX involved starting and linking runs, however, it will not build the runstreams. MREX, a modified version of REX, will perform that function. MREX will run as a batch job and will build runstreams into the file *MREXPRODYYYY. SMA provides a program, SAMREX, to interface with their Daily Schedule File. This program extracts the runids of the runstreams to be build and then passes them to MREX.

# MREX Processing

2.7.6.24.1 (09-01-2020) MREX Processing Opcon builds the Daily Schedule for a specific date as part of the previous day's schedule. SAMREX runs at the beginning of each schedule day, and as needed, when jobs are added to the Daily Schedule. It should be set to run through Opcon and to use the ECL provided by SMA (SCHEDULER*SKDPRG. SAMREXECL). SAMREX extracts, from the Daily Schedule file, the RUNIDs for all jobs whose ECL is found in the file *MREXPROD and places them in a file scab*SAMREX-FILE in a format similar to the original REX prompt that is: field1, field2, field3 where: field1 = RUNID, field2 = not used at this time, field3 = Date (YYYYMMDD format). Example: EOD01, 20071031 or EOD01. Field2 in the REX prompt is a SETC value. MREX ignores this value. Opcon/xps uses the SETC or Condition Word value from the STR screen when it starts the job. If a SETC value is needed for a run, it should be entered on the STR screen for the job in either the master or daily schedule. SAMREX will automatically start the correct MREX runs. The MREX runs must be set up in the Opcon/xps with a dependency on SAMREX. The userid should be PROD, the account should be PROD (or ALN+PROD in the ALN environment), and the project should be "scab" .

# MREX Theory of Operation

2.7.6.24.1.1 (09-01-2020) MREX Theory of Operation MREX is a batch program and does not have any outstanding console messages. MREX reads the SAMREX-FILE that contains a list of one or more RUNIDs. MREX: locates the correct ECL based on the search sequence REX uses; rebuilds the ECL using the same resources as REX; places the updated ECL in a file *MREXPRODYYYY. places all add elements in the *runid-ADD file. Each production run to be built by MREX must be defined in the Opcon/xps with an ECL location of *MREXPRODYYYY.

# MREX Search Files

2.7.6.24.1.2 (09-01-2020) MREX Search Files MREX attempts to locate the main runstream by searching the following files in sequence: scab*TECL, scab*RUNECL, SOFT*LIB, STAR*LIB, IRSTIP*SETUP, DMS*DBRUNS, DMS*DMURUNS, DMS*DMRMT, CPE*CPE, SYS$*RUN$. In addition to these files, the CSA staff may specify additional files to be searched after this standard search sequence. They do so by creating an element in the *ADD file with the name of REXADD. The files must be fully specified beginning in column 1 on each line. Supply all qualifiers and, as necessary, F cycles and read keys (e.g., FSC*RPAECL(5)/RDKEY). Note: If duplicate runstreams (or addstreams with different versions) exist on the production libraries, the first element MREX comes to will be the one it will use.

# MREX and the Runstream

2.7.6.24.1.3 (09-01-2020) MREX and the Runstream Once MREX finds the runstream, it will perform the following: builds a runstream element in the file *MREXPRODYYYY(jdd), where (jdd) is the Julian date based on the current Schedule Date; (The runstrearn will be identified by the RUNID as the element name.) delete @RUN statements contained in the runstreams, and generates its own. Note: the default project-id for any run is the MREX project-id. replaces the @ADD *RUNSETUP statement in the main runstream with @USE statements for various run libraries (e.g., *ECL., MAINREL., SUBREL., INCLUDE., *ADD., *IRSDB that are qualified by the MREX project-id used to start MREX); replaces the DIAG$ file and TPF$ with permanent files *DIAG$runid and *TPF$$runid qualified by the MREX project-id; (Delete these files if the run fins without an error.) inserts an @LOG statement with required accounting information that has been extracted from the RUNPROFILE record; generates an @SYM,F PRINT$ with the number of copies and print site specified on the RUNPROFILE Record; (Default is one copy.) Note: SRTASG options F, G, and T will be changed to R (production) only in the main runstream. modifies the @MAP or SOFT*LIB>.MAP options in the runstream to reflect the MAP Listing Options in the RUNPROFILE record (if they exist); (If no Map Listing options are entered in the RUNPROFILE record, the MREX default will be to suppress the listing.) generates an @XQT, D for every production absolute that uses the following format; (@xqt abselt or @xqt.abselt) Note: Absolutes executed in specific files will not be changed, i.e., @xqt soft*lib.modpdate or @xqt tpf$.abselt.) insert several statements at the end of each run to test for runidTERM elements and ADD them, if present. MREX places addstreams used by the run in a separate file. MREX catalogs an addstream file *runid-ADD for each run and copies all addstreams referenced by the "ADD" , "ECL " , or file names into the *runid-ADD file. MREX often builds the runstream hours before SAM starts the actual job. If there are later changes made to the Runprofile record, runstream, or addstreams, MREX must rebuild the runstream.

# PDate Switch-Over

2.7.6.24.1.4 (09-01-2020) PDate Switch-Over The computing centers will use local time as the system clock time. This means the systems at ECC-MEM will have a different time than the systems at ECC-MTB, but the difference should not pose a technical difficulty. Each day, the centers switch-over the pdate at 0900 (Enterprise Computing Center local time) for all sites supported at that Enterprise Computing Center. With the pdate switch-over at 0900 at ECC-MTB, the IRSCs cutover will be: Local Time IRSC 0900 ANIRSC, BIRSC, PIRSC, 0830 AUIRSC 0730 OIRSC With the pdate switch-over at 0900 at ECC-MEM, the IRSCs cutover will be: Local Time IRSC 0900 ATIRSC, CIRSC 0800 MIRSC, KCIRSC 0600 FIRSC

# MREX Output

2.7.6.24.1.5 (09-01-2020) MREX Output File Name: All runstreams created by MREX are placed into a file named scab* MREXPRODYYYY(jdd) where (jdd) is the julian date and MREX cycles up to the new julian-date (fcycle) transparently. Note: The current version of MREX does not use a holdrun file like REX. If MREX is unable to access these primary output files at the beginning of the year, or any other time, it will abort and will issue a message to have the MREXPROD file recycled. Element Name: MREX uses only the RUNID as the element name. There is no version.

# MREX Creates a SCAB*runid-ADD File

2.7.6.24.1.6 (09-01-2020) MREX Creates a SCAB*runid-ADD File For MREX to access all the addstream files MREX: catalogs the addstream file sc*runid-ADD for each run; copies all addstreams referenced by the "ADD" , or"ECL" , file names into this one single file; routes all addstreams to this addstream file. Note: MREX may be run hours before the actual job is started by SAM. These are several jobs that require a CSA to update the jobs' addstreams. These jobs will require special procedures. If at all possible, update the add element prior to running MREX. If the add element is updated after MREX is run, you must update the add element in the "runid-ADD" file; or perform the following: @ERS scab*SAMREX-FILE; using an editor, place the RUNID of the job in scab*SAMREX-FILE; @@CONS SAM RERUN MREX; check NREXERR file; @@CONS SAM RERUN "RUNID of the job" .

# Rebuilding a Runstream with MREX

2.7.6.24.2 (09-01-2020) Rebuilding a Runstream with MREX SAMREX changes the MREXPROD start file name in the Daily Schedule file to MREXPRODYYYY and appends a file cycle value (based on the Julian date of the Opcon/xps day) for each run it writes to the SAMREX FILE. This serves as a flag to SAMREX— that it has processed the file. There are situations when one must rebuild a runstrearn built by MREX, such as when a new ECL runstrearn is implemented after the run is built. In these cases, go into the Daily Schedule file for the job in question and, using the CHG command, remove the cycle value and the year (yyyy) from the MREXPRODYYYY file name in the STR screen. Then rerun SAMREX (SAM RERUN xxSAMREX). SAMREX will pick up all runs started from MREXPROD that do not have cycle values in the start-file filed and will start MREX to build these runstreams.

# MREX and REX Documentation

2.7.6.24.3 (09-01-2020) MREX and REX Documentation For more information on MREX's manipulation of job ECL, refer to the REX documentation found in either chapter 7 of the CSA Handbook or the IRS*DOCFILE.REX.

# RUNPROFILE Report

2.7.6.24.4 (09-01-2020) RUNPROFILE Report A RUNPROFILE Record must exist for every production run that MREX starts. It will use the record to: determine the number of copies of the primary print file " PRINT$" ; (This may be changed during the run by changing the @SYM statement.) determine if a value (L, S, or N) is placed in the Map Listing Option of the RUNPROFILE record, if so, MREX will override the @MAP options used by any run that uses SOFT*LIB.MAP or the @MAP as the collection process; Note: MREX will change MAP options contained in addstreams to reflect the value in the RUNPROFILE Report. The default will be " N" (No Listing). The SETC value from the RUNPROFILE record must be put into the STR screen for the associated Opcon/xps jobs to be effective.

# MREX Messages

2.7.6.24.5 (09-01-2020) MREX Messages MREX uses most of the REX error messages and most of these messages are self-explanatory. The main difference is REX messages display on the console and MREX messages are found either in the MREX listing (*MREX$PRT) or the new error file *MREXERR. Both the run listing and the MREXERR file should be checked after MREX is run. These errors could indicate a problem with a job on the daily schedule. The MREXERR file is only produced if there are errors and a console message will indicate there are errors.

# Automated Opcon/xps

2.7.6.25 (09-01-2020) Automated Opcon/xps This issuance draws heavily from The Opcon/xps IRS Quick Reference Guide, Release 6R2 (3/25/98), and provides minimum instructions and guidelines for setting up and maintaining Opcon/xps. See the Opcon/xps IRS Quick Reference Guide, for detailed instructions. Initially, the Scheduling Section will set up Opcon/xps. Each site will determine who will maintain the system. Opcon/xps is a complete job scheduling and workload management system for the UNISYS ClearPath Mainframe Systems. Once a job is defined to Opcon/xps, all future runs are automatically scheduled, with no further input. It accounts for every job scheduled on any given day. The system will schedule jobs randomly, or for any periodic frequency, per user specification. Opcon/xps automatically considers leap years, weekends, and holidays and produces documentation for reports. See the Opcon/xps IRS Quick Reference Guide, for more information.

# Function Codes

Exhibit 2.7.6-1 Function Codes A Scheduling H Media (available) B Tape Library (specify shift) I DASD C Computer Operator (specify shift) J NO Analyst/Programmer/DBA D ECC Analyst/Programmer/CSA/DBA K Outside Agencies (States, RDOs, etc.) E Automation (PCI, AMS, BAL, AFT, etc.) L Service Delivery Command Center (specify shift) F Hardware M ECC-MTB — IRB G Media (damaged) N Scheduling (specify shift) O Service Center Campuses/QSE staff

# Reason Codes

Exhibit 2.7.6-2 Reason Codes 01 Schedule in error 02 Incorrect media pulled 03 Media scratched in error 04 Media lost or misplaced 05 Failure to follow schedule or special instructions 06 Incorrect console entry or response 07 Balancing error/out of balance 08 FTP/File Transfer error 09 Output media misdirected, lost or damaged 10 Failure to provide adequate instructions 11 ECL/JCL/SQL error 12 Programming error/request 13 Systems Software error 14 IRU error 15 Insufficient space 16 DMR abort/Database error 17 Nap not available 18 Media drives and controllers 19 Schedule Rerun 20 Input/Read error 21 Output/Write error 22 Media damage 23 Power/facilities interruption 24 Vendor error (CE, etc.) 25 System hang 26 Posting Log in error 27 Input file in error (incomplete or late) 28 Control/Date card in error