| DIVISION OF IT |
 |
OFFICE OF IT |
|
GET CONNECTED |
|
UTS HOME |
|
||||||||||
|
 |
|
|
MAINFRAME STANDARDS MANUAL
RETURN TO INDEX Note: This member is set up with print commands for the HP Laser Jet 00000100 network printers (not with Xerox commands). This member may be printed 00000101 using STDSPRNT on CPROD.TEST.PANLIB. 00000102 CHAPTER: Operations Number: 6.1.01.01 Date: 03/26/86 SECTION: Production Control Revised: SUBJECT: General Overview of Duties Production Control responsibilities consist of Production Job Scheduling, Job Processing, and the distribution of output reports and forms. The most important tool used in this process is the CA7 Production Control System. With this system, Production Control personnel can perform the duties of monitoring production workload, making online edits and changes to existing JCL listings of production jobs, submitting production jobs to the operating system for processing, and controlling the nature of work activity of the production schedule via online commands. One important function which constitutes the job processing duties of Production Control are the implementation of restart and rerun instructions in the event of production jobs terminating due to operating system failure, abnormal ending of jobs (ABEND), Job Control Language errors, or unacceptable completion codes being encountered. Another aspect of Production Control are the maintaining of quality control standards on output reports and forms before being sent for distribution processing. Due to the demand of operating system resources during regular working hours (8:00 A.M. to 5:00 P.M. Monday thru Friday) production job processing is scheduled for the following times: Monday thru Friday - 5:00 P.M. to 11:59 P.M. CHAPTER: Operations Number: 6.1.02.01 Date: 03/26/86 SECTION: Production Control Revised: 11/02/89 SUBJECT: Production Job Scheduling There are two methods by which production jobs are scheduled for processing. They are either cyclic and have a set scheduled time of submission for processing or are scheduled for processing thru the submission of a written request. Production jobs which are processed over recurring periods or run at a certain time or date as required by data set retention and scheduling documentation have a schedule defined on the CA7 Automated Production Control system. CA7 will then automatically invoke the process of job submission when the predefined parameters of time, date, or cyclic period conditions are met. The other method of job scheduling is the use or written requests. Request sheets are normally formatted according to the application of the production job and are designed by the programming personnel who authored the job and it's documentation. The information contained on the request sheet identifies the job name and number, the date of the request, the name of the user or requestor, and any control card information or jcl modifications as well as any special handling of output reports and forms. There are four methods of submitting these requests to Production Control for processing: 1. Courier - When the distribution section of operations delivers output reports from the previous night's workload processing to the users, an arranged system of pickup of job requests to be processed that night is implemented. 2. Submission thru the I/O Window located in the operations area. 3. Submission thru the operating system to a hardcopy printer which is monitored by Production Control for these job requests. 4. Submission thru the programming staff. The production workload for the evening or weekend processing cycle is defined into a schedule and operating system resource allocated for efficient processing. Production job requests sheets should be submitted to the Production Control area by 4:00 P.M. in order for preprocess functions to be completed. CHAPTER: Operations Number: 6.1.03.01 Date: 03/26/86 SECTION: Production Control Revised: 11/02/89 SUBJECT: CA7 Automated Production Control System The scope, operation and use of the CA7 Automated Production Control System provide an online, interactive system for automatically controlling, scheduling, and initiating production jobs for processing. The following facilities provided by CA7 make it an effective Production Control tool: 1. Workload Scheduling and Sequencing - CA7 includes facilities for defining and scheduling activities associated with the production workload. These time and event driven facilities are used to schedule production jobs and certain production control tasks. Workload sequencing prevents production jobs from being executed before preprocess tasks are completed and job dependencies are satisfied. 2. Workflow Control - Although CA7 automatically schedules and invokes the workload defined to it. Occasions arise which makes it necessary to circumvent scheduled workflow in the interest of new priorities. With CA7, unscheduled interruptions are handled online so that current priorities can be addressed quickly. schedules can be moved forward or backward, and jobs can be held, rushed or cancelled without tedious time consuming rescheduling activities. JCL management facilities provide for inclusion or omission of override statements depending on current execution requirements for a job. Both scheduled and unscheduled override requirements are supported. 3. Job Restart - Under CA7, jobs that terminate abnormally are moved to the CA7 request queue to await job restart. Through online transactions, all jobs awaiting restart are listed along with job restart information. Job restart information identifies the last step successfully executed, the abend code and the restartable steps. After restart cleanup is completed, abnormally terminated jobs can be restarted online. CHAPTER: Operations Number: 6.1.04.01 Date: 03/26/86 SECTION: Production Control Revised: 11/02/89 SUBJECT: Job Restart and Rerun Whenever a production job abnormally terminates due to operating system failure, abnormal ending (ABEND), JCL errors, or unacceptable completion codes, Production Control will implement procedures for that job. If the nature of the termination requires programming staff assistance, Production Control will contact the personnel responsible for resolution of the production job. Restart and rerun instructions for each step component of production jobs are located in program run references in the Production Control area. It is at the step component level that job restart procedures are implemented. The procedure for job restart involves making an analysis of the termination by referencing job message condition codes with the IBM message manuals to determine the nature of the abend and procedures to follow for resolution. Another reference source which is utilized whenever an abend code is encountered is the ABEND-AID facility which is located on the output dump listing of the job. This facility gives information on the description of the abend code, devices and data sets utilized, and possible solutions and causes of the abend. The CA7 Production Control system provides a very efficient tool for conducting job restart procedures. The ability for Production Control personnel to enter online transactions to process job restarts results in faster response to workload processing when unscheduled interruptions occur. Production jobs can have optional parameters to implement the restart process by passing controls for data set cleanup and step restart to CA7 or be manually restarted by Production Control. SPECIAL NOTE: If a data set that has been allocated with less than 2000 total tracks causes a job to abend because the dataset requires more than 2000 tracks, the job will not be rerun until Production Control notifies the programmer/manager of the responsible area. The responsible area will then be given the choice of changing the UNIT parameter (refer to 5.1.04.02) to designate tape output (instead of disk) or of the job being held until the responsible area can make any changes in the job. Before the job can be rerun, the job, with changes, must be submitted to the Standards Department for production turnover and must be accompanied with the approval of the System Support Group to exceed the 2000 tracks limit of disk space (refer to the SPACE parameter in the Standards Manual - 5.1.04.03). The exception to this special note will be checkpoint restart output GSAM files, which will be assigned a higher allocation to complete the job. Before the job can be scheduled to run again, the GSAM file must be changed to designate tape output, or approval be obtained from Systems to keep the file on disk with an allocation greater than 2000 tracks. CHAPTER: Operations Number: 6.1.05.01 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) The following chapter is intended to describe preliminary requirements for converting and implementing hardcopy output to the Report/Data Archive and Retrieval System (R/DARS) for on-line viewing by authorized mainframe users. This is to be done to eliminate the printing, processing, and distribution of hardcopy output such as greenbar reports, special forms, or microfiche. The conversion and implementation work will normally be done by Production Control Report Administrators, but some of the tasks such as revising or creating new JCL may be done by the programming staff. The programmers, however are restricted from any of the work that requires using the R/DARS Administrators tools. Program code revisions will be done by the programming staff after the request is routed by Report Administration to the appropriate programming manager for assignment. The R/DARS Report Information form is used to gather preliminary information and initiate the process to add a report to R/DARS - see STDS 6.1.05.07. The form will be used as an information sheet as work progresses on the conversion and will be kept on file in Production Control. The form is also to be used to request updates to R/DARS such as security and search fields and user-ids. An automated R/DARS inventory system will be maintained by Report Administrators for tracking the forms and for management reports. The forms are designed to be filled out by the user departments, but may be completed by the programming staff. Interviews with the report owners and requestors will be held as needed to clarify information to insure that the reports are set up correctly. The Report Administrator will coordinate navigating a report through the various stages of the standards process, the report definition to R/DARS, the testing of the report to the satisfaction of the owner, and the turn over to production status of all appropriate CDSTORE steps and batch jobs to load the report to R/DARS. New reports produced in new production jobs will require the R/DARS Report Information form to be turned over to Standards as part of the Production Job Acceptance Report document. The new report should be written to a data set only and a test version of the report be given to the Report Administrator for definition to R/DARS. It is recommended that new reports that are being developed and loaded into R/DARS be aware of an 80 column display limitation for the initial view of a report. There are controls for scrolling left and right and logical view definitions to view data beyond column 80. CHAPTER: Operations Number: 6.1.05.02 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) The following is an outline of the steps to be taken for conversions by Production Control Report Administration: 1. Log each request as received into the R/DARS inventory software, and continue to update at the appropriate points in the set up. 2. Review each form for completeness and either return to the requestor if critical information is missing (such as RDN or owner signature), or determine additional information needed and add to the request. 3. Determine if program changes are needed. If so, request from programming managers, and record status in inventory software. 4. Prioritize reports to be converted based on greatest benefits from the requested conversions. 5. Print part of report to use for segmenting and indexing analysis, or use TSO/ISPF screen 3.4 to review the report online. 6. Create test file of report for use in testing ACT (Application Control Table on R/DARS). 7. Analyze report and make initial determination on segmenting, indexing, and display fields based on requested access and security schemes. 8. Review report and the R/DARS Report Information request with customer to verify segments, indexes, and display fields. 9. Create ACT using test storage group, management class, and directory group. 10.Create input and/or index exits, as necessary. 11.Create FCT (Forms Control Table), VCT (View Control Table), and global views in R/DARS as necessary. One global logical view will be defined for each report as appropriate. 12.Set up security scheme per customer specifications. 13.After testing all components, have customer review tested version. 14.Convert necessary DD names in source production job to write report to data set form. Set up batch production jobs for the print utility and for the CDSTORE utility to load report to R/DARS. The automatic printing of the report will be discontinued after the customer is satisfied with the conversion to on-line availability by deleting the batch print utility job. 15.Convert test definitions on R/DARS to production naming schemes once approval to do so has been given by report owner. 16.File the request form and update the inventory system. 17.Monitor production environment to gather information on frequency of access to report on R/DARS to make adjustments to retrieval schemes for faster access times and insure an efficient storage process. CHAPTER: Operations Number: 6.1.05.03 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) Current naming conventions for reports will be used to define reports to R/DARS for the production version of the report - see STDS 2.3.14.01. While in test mode, the RDN will contain a T as the 1st character to differentiate from an actual production status report. The Report Administrator will copy test RDN ACT definition to production status after approval from the departments and when R/DARS ACT definition is satisfactory to meet production standards. Reports with SYSOUT=A or SYSOUT=* should be converted to production data sets with GDG attributes with a retention level of two. The data set names should conform to Standards DSN naming conventions - see STDS.2.3.10.01. The data sets should be set up with the constant "PRINT" as the fourth level qualifier (optional ID) as shown in the following example: GROUPID.PGMID.Mnn.PRINT(+1) where M = system storage identifier (D or M for disk/ T for tape) and nn = file sequence number. Production Step numbers to be used for step names for the CDSTORE utility have been reserved for use and are the following: C66101UA R/DARS CDSTORE UTILITY These step numbers can be used in a batch job to write from one to ten or more reports to R/DARS as needed. The batch job containing these CDSTORE steps can be scheduled to run immediately after all the appropriate print data sets have been created. This will insure reports will be available as soon as possible. Each step included in the batch job will process one report definition. Job numbers will be assigned per normal procedures to set up a batch job in production status. Reports that are produced from Decision Analyzer should contain the CDSTORE steps within the same JCL listing and the CDSTORE steps should have an appropriate COND parameter to prevent running the step if a condition code 0016 (no records selected) occurs. CHAPTER: Operations Number: 6.1.05.04 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) An example of a report produced by Decision Analyzer that will be written to R/DARS is in CPROD.TEST.PANLIB(RDARSDA). To conform to current production job flowchart standards, converted DD names should have a comment (for DOCU/TEXT purposes) to 'label' the DD name as producing the RDN for the report for R/DARS. This will identify DD names and the source batch jobs that produce R/DARS reports by using the DOCU/TEXT online XREF query. An example follows: //SYSOUT DD DSN=FPROD.F40267CM.M01.PRINT(+01), RDARS:
F400168M Naming conventions for exits (input and index) will utilize the C66 number system with a CR as the last two characters to create unique R/DARS exit 'program' numbers. The source for these exits is to be turned over through the Standards system as includes, not programs, to update CPROD.PROD.PANLIB. The actual compiles will be done by Report Administrators to a special R/DARS load library, CICS410.DA RSV2M3.AUTHEXIT. A "refresh" action by Operations will be needed after a compile to make the change immediately available. Definition of exits will be as follows: *Input exit - COBOL program compiled to the R/DARS loadlib by Report Administrators which is used to convert report contents in order to provide the requested access and security. *Input exits are used for the following reasons: - Posting date on report is in a format not supported by the R/DARS batch capture process. - Using 'OR' logic during the segmentation process (R/DARS batch capture process uses 'AND' logic). - Report has inconsistent page headings. Index exit - COBOL program compiled to the R/DARS loadlib which is used to modify index values for a segment to conform to requested access and security. Index exits are used for the following reasons: - Convert codes in the report into meaningful text for use in the on-line part of R/DARS CHAPTER: Operations Number: 6.1.05.05 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) The following is a JCL sample of the CDSTORE utility job
step for loading a report to R/DARS (see
CPROD.TEST.PANLIB(CDSTORE): In this example, report F400168M would be loaded from the data set for DD name OBJINPT, FPROD.F40267CM.M01(+00). A PROC has also been set up which may be coded in the JCL
as follows: CHAPTER: Operations Number: 6.1.05.06 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: Report/Data Archive and Retrieval System (R/DARS) A print utility step, C60370CA, (MSSPRINT) will be used to continue printing the reports in the interim period before hardcopy printing of the report is stopped. The print file that is input to the MSSPRINT step is also used as input to a job that will contain program CDSTORE to do the batch capture process to load the report into R/DARS. Separate jobs will be set up for the printing of the reports and for the CDSTORE steps. Having two jobs will allow a rerun of only one job if there are problems with either the printing or the R/DARS load. The print job will be deleted and the job with the CDSTORE step will be retained when the decision is made to place the report on R/DARS without printing hardcopy output. The MSSPRINT step will be used to print reports from files having an LRECL=133. If the LRECL is other than 133, an IEBGENER step will be used to print these reports. Detailed information on the R/DARS system can be found in the following IBM documentation manuals titled: Report/Data Archive and Retrieval System Training Guide Report/Data Archive and Retrieval System Report Administrator Education CHAPTER: Operations Number: 6.1.05.07 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: R/DARS REPORT INFORMATION FORM Form STDS 7.2.34.01 is used to communicate to the Report Administration section of Production Control the needed information for RDARS system setup to allow online viewing of a computer generated report by the appropriate personnel. The form is to be used as a request sheet for the set up of jobs to move reports from printed output (paper or microfiche) to disk files with GDG (Generation Data Group) attributes for input to the RDARS CICS mainframe system for online retrieval. The form will also serve as an information sheet once finalized by Report Administration and will be filed in a RDARS Control Book. There is no requirement for application groups and user departments to keep paper copies or electronic copies (such as Jetforms files), but may optionally do so. The forms kept in Production Control will be considered the 'master copies' for audit and record keeping purposes. The forms are prepared using JETFORMS which has a 'field help' feature to indicate what information is needed in each field on the form. These fields are also summarized in STDS 6.1.05.07. The form may be originated in the user departments or by the Computer Services staff. When completed, the form should be printed, signed by the authorized user of the requesting deparment, and sent to Production Control; or,if appropriate, included with the Production Job Acceptance Report, Standards form 7.2.14.01, for production turnover through the DBA/Standards Group. As the forms are received by Production Control they will be analyzed, researched as necessary, finalized, and the appropriate actions taken to define report files to RDARS. This could include changing existing JCL hardcopy report output to disk files and/or creating a seperate new job to load the report information from a disk file into the RDARS system. Any revisions requiring programming assistance will be forwarded to the appropriate applications manager for assignment. New jobs with output for the RDARS systems should be turned over by the programming staff. JCL revisions may also be made by the programming staff rather than Production Control. Any new or revised production JCL will be turned over to DBA/Standards by both Production Control and the programming staff following existing job acceptance procedures. A summary of the processing of the form follows - for more information on the detailed processing of RDARS requests and set up, see STDS 6.1.05.1. CHAPTER: Operations Number: 6.1.05.08 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: R/DARS REPORT INFORMATION FORM RDARS JOB: The Production Control Report Administrator will add the new JOB created to load RDARS with the requested report. DATE: Date of the request. APPLICATION: Name of the applications computer system that the report is created in (example, Purchasing or Housing). RDN: Report Distribution Number (RDN) that is assigned to and printed on the report to be loaded to RDARS. RDN's should be unique for each production report. In the situation where the same report is created in multiple jobs or programs for multiple recipients with the same RDN, the last character which usually denotes frequency may be used by the Report Administrator to denote the different report versions. Any other variances in RDN usage should be discussed with the Report Administrator for resolution. See STDS 2.3.14.01 for RDN format and STDS 6.2.02.10 for turnover considerations. OWNER/CONTACT: Name of the individual who should be contacted for questions about the request, and for review and approval of the intitial reports loaded in RDARS 'test mode' to a secured, production RDARS member. PH#: Phone Number of the individual listed as the OWNER/CONTACT. REPORT TITLE: The full or abbreviated title of the report as it is to appear on RDARS. CREATION JOB: The name of the production job that produces the report. If multiple jobs, contact the Administrator - see RDN. PGM: The name of the program (job step) that prints the report. If multiple programs, contact the Administrator - see RDN. PRT-FILE DSN: The data set name (DSN) of the file that contains the report. The DSN may exist; for example, for reports currently printed using MSSPRINT or for microfiche. If the DSN does not exist, the Report Administrator will complete this field as a new data set (print file) is created to be used to load the report into RDARS. CHAPTER: Operations Number: 6.1.05.09 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: R/DARS REPORT INFORMATION FORM TYPE OUTPUT: The requestor should indicate the type of output medium that the report is currently being produced on from the following categories: -- GREEN-BAR: standard 11x14 continuous feed computer paper SUMMARY PAGE(S): Indicate whether or not a report has a page(s) of YES or NO? summary information that may affect RDARS page breaks. FREQUENCY: Indicate how often the report is produced using the Computer Services frequency codes - see STDS 2.2.05.01. A - on request S - semester SCHEDULED: Check this block if the report is scheduled by
Production Control for execution. ** ** Note, both SCHEDULED and REQUESTED may be checked if appropriate. USAGE: Indicate the frequency that will best match the expected usage of the report once loaded into the RDARS system. RARELY USED - infrequent access (generally more than a
month apart) CHAPTER: Operations Number: 6.1.05.10 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: R/DARS REPORT INFORMATION FORM REPORT ORDER: Indicate the primary data field key that is used to organize the report contents (for example, department). This field will be used for search and security access purposes as requested. OTHER KEY ITEMS TO BE USED FOR SEARCH FIELDS AND SECURITY SCHEMES: Indicate any secondary data field key(s) used to organize the report. Secondary keys will be used for search and security access purposes as requested in conjunction with the primary key field (for example, name may be a secondary key within a primary key of department). Up to three secondary key items can be used for search fields and up to two items for security. REPORT SECURITY: Indicate how the report or sections as noted above by primary and secondary key fields are to be made available to RDARS system users. -- PUBLIC: Public access will make a report available to all RDARS users. This level of security is not recommended because of the huge RDARS index it may produce for user access. -- PRIVATE: Private is the normal security scheme and is further defined by the following two methods of access for the USER-IDs and USER GROUPS as requested. 1) RPT-ID indicates to allow access to the entire contents of a report on RDARS (ie, security based on RDN only). 2) DATA indicates that access is to be determined based on specific key data fields as requested. LIST MAINFRAME USER-IDs AND USER GROUPS THAT REQUIRE ACCESS TO REPORT: List the valid USC Computer Services USER Ids and/or USER GROUPS to be given access to the report contents on RDARS as specified in the above "Security" section of the request. If security by "Data" is indicated, then the key/search/security field(s) listed above should be noted for each USER ID or Group so that access can be set up accordingly. Check the SEE ATTACHED block and include attachments as needed to fully define the security scheme desired. Note, security by USER GROUPS is encouraged to simplify maintenance when personnel changes occur. CHAPTER: Operations Number: 6.1.05.11 Date: 01/21/99 SECTION: Production Control Revised: SUBJECT: R/DARS REPORT INFORMATION FORM RETENTION: This section of the request is to be used to indicate the length of time the reports are to be kept on the RDARS system for online access. If "NO" is indicated for report "Expiration" then the report will be deleted from RDARS after 10 days. If "YES" is indicated for "Expiration", then the report will be retained for the period selected as follows: -- WEEKLY -- 18 MONTHS Note, reports cannot be restored once deleted from RDARS. AUTHORIZED SIGNATURE/DATE: The appropriate responsible person deemed responsible for the report, including the report retention, by the department head must sign and date the request approving the indicated retention period. Note: all reports migrated to RDARS will be reviewed to assure retention is in accordance with the South Carolina Public Records Act of 1973 and those authorizing RDARS retention should be aware of those requirements. RDARS USE ONLY: The following fields will be completed by the Report Administrator as indicated. Exits are further explained in STDS 6.1.05.01. EXITS(S) Input - The name of the cobol program or subroutine that performs the required input exit processing for RDARS for the report. Index - The name of the cobol program or subroutine that performs the required index exit processing for RDARS for the report. Security - The name of the cobol program or subroutine that performs the required security exit processing for RDARS for the report. |
|
|
|
| USC LINKS: | DIRECTORY | MAP | EVENTS | VIP |
| Columbia, SC 29208 • 803-777-1777 • Webmaster | © University of South Carolina Board of Trustees |