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

The following guidelines are provided for preparing a Systems Notification:

Use the website to prepare a Systems Notification at: http://mountaineer.mcc.irs.gov.. When completed send an email to address,*ccmccb@irs.gov..

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:

The Enterprise Computing Center will:

Upon balancing the TEP, Data Control Function will:

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.

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:

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.

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:

SCIPAS reports are divided into four sections:

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.

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 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.

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 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.

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.

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.

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.

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:

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:

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:

Monitoring of runs by accessing Control-M.

Monitoring of runs by accessing the input queue:

IRSC media that cause problems at ECCs fall into two general categories:

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.

Replacement files can be any of the following:

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.

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.

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

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.

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:

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.

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:

ESD will update the ticket with the actions taken to ensure the replacement is sent.

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.

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:

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.

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:

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.

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.

The receipt of input to a consolidated site may be received via the following methods:

The MEM Scheduler will logon to the IAP system under the appropriate Logical Partition (LPAR) as shown below:

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.

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.

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.

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.

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.

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:

On the "Initiate A File Transfer Screen," enter the following:

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.

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.

After the file has been transmitted successfully, MTB Scheduler will verify good completion via Connect Direct Panel.

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:

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:

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.

#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.

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.)

#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.

(4) #The IBM Scheduling Section (MFSS) OPOG MAIN MENU will appear:

Select Option 1 — EDIT OPOG DATA BASE FILES — The panel will be displayed, select one of the following options:

Selecting Option 2 — CREATE INITIAL OPOG REPORT (OPOGS002) — The panel will be displayed, enter the following information:

Select Option 3 — PRINT FINAL OPOG REPORT — The MFSS panel will be displayed, enter the following information:

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

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.

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:

If a retention cannot be determined using the traditional sources above, the following may be contacted:

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.

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:

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:

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.

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.

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.

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.

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.

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:

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.

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.

The PCI main menu is invoked by keying in @PCI.

If a user has the proper security profile, the following options will be listed.

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.

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:

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:

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):

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:

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" .

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.

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.

A RUNPROFILE Record must exist for every production run that MREX starts. It will use the record to:

The SETC value from the RUNPROFILE record must be put into the STR screen for the associated Opcon/xps jobs to be effective.

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.