Preface

This Standard Operating Procedures Manual contains many of the procedures that are the responsibility of the Production Support Group. It contains many of the tools frequently used by PSG Members to solve Production problems, to maintain current Production Jobs, and to improve existing Production Job performance.

The nature of the Production Support Group requires constantly changing applications of these tools. As a result, there are numerous tasks that are not repeated often enough to warrant being placed in a Standard Operating Procedure manual.

Production Support Group General areas of responsibility:

1. Technical Support For Production Jobs
2. Technical Support For Scheduling
3. Technical Support For Data Entry
4. Technical Support For Application Programming

1. Evaluate and implement major software conversions
2. Perform some daily Scheduling tasks/trouble shooting
3. Evaluate and implement hardware and software packages
4. Program in-house utilities and reports
5. Maintain and document technical information for the production areas
6. Maintain and upgrade Autodoc System
7. Create and maintain Production Support Standards Manual (S.O.P.)
8. Assist with DASD management
9. Review and evaluate Production Runbooks
10. Create and manage OGL applications
11. Evaluate Pre-Production Jobs
12. Perform research and consulting tasks

Table of Contents

AUTODOC
   OVERVIEW
      Autodoc Exec
      Other Execs
      Autodoc Diagram
      Cobol Programs
      Focus Databases
      Focus Modules
      Focus Synchronous User Machine - FOCADM4
      Jobsdbc, Jobsdbm, Panels, Display, And SBCOBRA
      Libraries For JCL And Msglib
      Passid Data File
      Vsam Table File
      Vsamtest Focexec
   BRINGING SYNC MACHINE UP OR DOWN
      Checking For AUTODOC Users
      Bringing The Sync Machine Down
      Bringing The Sync Machine Up
   PRO1
   DBDELETE
   UPDATING THE VSAM TABLE FILE
   CHANGING AUTODOC COBOL PROGRAMS AND FOCUS MODULES
   UPDATING JOBSDBC COPY MEMBER
   CHANGING THE ORDER OF STEPS IN AN EXISTING AUTODOC JOB
   PRODOWN and DEVCOPY
      PRODOWN
      DEVCOPY
   UPDATING AUTODOC FOR A NEW AUTODOC USER
   ADDING A NEW PROC TO JCL GENERATOR AND VSAM TABLE
   RESTORING A LOST JOB TO THE PRODUCTION OR DEVELOPMENT FOCUS DATABASE
      RESTORING A LOST JOB TO THE PRODUCTION FOCUS DATABASE
      RESTORING A LOST JOB TO THE DEVELOPMENT FOCUS DATABASE
   REBUILDING THE TEST DATABASE ON DOCUTEST
Restoring DEV or PRO Library Members Using FDR
Restoring MVS Datasets Using FDRABR
Restoring VM Datasets
Adding New DEV or PRO Libraries to PROCOPY Procedure
   Adding New Libraries
   SCHEDDEV Libraries
EXECs and Commands
Scanning PRO.JOBLIB and DEV.JOBLIB.
   SCANLIB
Overlay Generation Language and Page Segments.
   Creating Overlays, Form and Page Definitions
      Creating an Overlay
      Creating a FORMDEF
      Creating a PAGEDEF
      Using Overlays, Form and Page definitions.
   Creating a Page Segment from an Overlay
      Creating the Overlay
      Modifying the Compiled Pattern to Create a Page Segment
      Updating the Page Segment Library
       Using Page Segments
       Library Procedures
Glossary

AUTODOC

This section describes AUTODOC. This section is not a user's guide. It describes tasks that the Production Support Group must know how to do to maintain and upgrade AUTODOC.

OVERVIEW

AUTODOC is the automated JCL generator that must be used by the programming staff to produce new JCL. AUTODOC consists of:

     1  AUTODOC EXEC E
     1  SBCOBRA EXEC
     8  COBOL FOCUS Modules
     8  COBOL Programs
     3  Development Libraries
        Execs called by the AUTODOC EXEC
     2  Execs for use through the Sync Machine by the Programmers
     2  Execs for use in batch mode by PDUC1
     2  FOCUS Synchronous User CMS Machines (FOCADM4 & FOCADM31)
     4  FOCUS Databases:  Test (DEV) and production
                          Y2K Test (YR2) and production
     1  JOBSDBC COPY Member
     1  PANELS COPY Member
     1  JOBSDBC COPY File
     1  PANELS COPY File
     1  PASSID DATA E
     6  Synchronous (simultaneous user) FOCUS Modules
     1  VSAM Table File
     1  VSAMTEST FOCEXEC E

AUTODOC Exec

The AUTODOC Exec is stored on the E disk. It drives the entire AUTODOC system. It contains execs that call the FOCUS modules which generate screens, JCL, msglibs, runbooks, etc.

Other Execs

There are two more execs frequently used in AUTODOC:

• PRO1 is used by the Production Support Group to move a job from the AUTODOC Test Focus Database to the AUTODOC Production Focus Database. This is a move: The job is erased from the Test Database and the version in the Production Database written over.
• DBDELETE is used by the Information Systems Support Group (or the Production Support Group in their absence) to remove a job from the AUTODOC Test Focus Database or the AUTODOC Production Focus Database.

Autodoc Diagram

The following is a diagram that illustrates how all of the components of AUTODOC are related. Locations are boxed and in upper case. Procedures and Execs are in lower case. Arrows indicate data flow.

 --------------------------                                       ------------
| PROGRAMMER'S CMS MACHINE |--------PUTPDS ADD/REPL------------->| DEV JOBLIB |
 --------------------------     (for non-AUTODOC jobs)           | DEV MSGLIB |
       |         /|\                                              ------------
       |          |                                                    |
       |          |                                                 PROCOPY
    AUTODOC    AUTODOC                                                 |
     Entry       JCL                                                  \|/
       |       Runbook                  -------------             ------------
       |        MSGLIB             --->| DEV AUTOJOB |--PROCOPY->| PRO JOBLIB |
       |          |               |    | DEV AUTOMSG |     |     | PRO MSGLIB |
      \|/         |               |     -------------   Copy to   ------------
  ---------------------           |                     UAPCTLM?
 |   <--DEVCOPY-->     |          |                        |
 | Test FOCUS Database |--------PRO1                       | Y    ------------
 | Y2K  FOCUS Database |          |                         ---->| UAPCTLM.   |
 |  D2230F00/D2230T00  |          |                              | PROD.JCLLIB|
  ---------------------           |                               ------------
       |         /|\              |
       |          |               |      ---------------------------
       |          |                ---->| Production FOCUS Database |
    DBDELETE      |                     |        D2230F01           |
       |          |                      ---------------------------
       |          |                           |           |
       |           ------PRODOWN--------------         DBDELETE
      \|/                                                 |
                                                         \|/

Cobol Programs

AUTODOC uses 8 COBOL programs:

     ADCOPYSU     - Copies PRO to DEV, and DEV to DEV
     ADECTLSU     - Editor
     ADESU        - AUTODOC screen generator and entry system
     ADJCTLSU     - JCL Generator
     ADMCTLSU     - MSGLIB Generator
     ADRCTLSU     - Runbook Generator
     DBDELETD     - Database Deletes DEV
     PROCOPI      - Copies DEV to PRO

Focus Databases

There are two FOCUS Databases used by AUTODOC: D2230F00 is the Test (DEV) Database and it is located on the FOC308 disk. D2230F01 is the Production (PRO) Database and it is located on the FOC309 disk. When the programming staff uses AUTODOC they are working with the Test Database. The only jobs in the Production Database are jobs that have been Turned Over into production.

Focus Modules

In order for AUTODOC to use the COBOL programs, they must have FOCUS Modules generated from them. AUTODOC uses two types of FOCUS Modules:

• Cobol FOCUS Modules are used by PDUC1 to make changes to the databases without using the Sync Machine.
• Synchronous (simultaneous user) FOCUS Modules are used by the programming staff to make changes to the DEV database, and to retrieve copies of jobs from the PRO database.

     ADCOPY       - Copies PRO to DEV, and DEV to DEV
     ADECTL       - Editor
     ADJCTL       - JCL Generator
     ADMCTL       - MSGLIB Generator
     ADRCTL       - Runbook Generator
     DBDELETD     - Database Deletes DEV
     DELETD       - Database deletes PRO
     PROCOPI      - Copies DEV to PRO

There are 6 Synchronous (simultaneous user) FOCUS Modules:

     ADCOPYSU     - Copies PRO to DEV, and DEV to DEV
     ADECTLSU     - Editor
     ADESU        - AUTODOC screen generator and entry system
     ADJCTLSU     - JCL Generator
     ADMCTLSU     - MSGLIB Generator
     ADRCTLSU     - Runbook Generator

Focus Synchronous User Machine - FOCADM4

The FOCUS Synchronous User Machine FOCADM4 is the machine the programming staff links to when in AUTODOC. It is this machine that updates the Test and Production Databases. FOCADM4 is AUTODOC as far as the programming staff is concerned. It is the Sync Machine. This is the machine that is logged on or off to bring the Sync Machine up or down.

Jobsdbc, Jobsdbm, Panels, Display, And SBCOBRA

The JOBSDBC COPY Member, PANELS COPY Member, and COPY members stored in Source Bank are all related. The COPY members are stored in Source Bank and are also stored in PRO.COPYLIB. They contain working storage information that is copied into the COBOL Programs when they are compiled. AUTODOC Cobol programs must be compiled on DOCUTEST using the SBCOBRA EXEC.

Libraries For JCL And Msglib

AUTODOC uses 3 DEV Libraries:

• The DEV AUTOJOB is where JCL that is generated during the turnover (PRO1) process is stored (Procopied to the PRO JOBLIB by Scheduling).
• The DEV AUTOMSG is where the MSGLIB that is generated during the turnover (PRO1) process is stored (Procopied to the PRO MSGLIB by Scheduling).
• The DEV AUTOFLAG contains Production jobs that are generated using AUTODOC.

Passid Data File

The Passid Data File is located on the E disk. It contains the names of the CMS Machines that are authorized to use AUTODOC. A CMS Machine must be included in the Passid Data File on the E disk in order to use AUTODOC.

Vsam Table File

AUTODOC uses a VSAM Table File to perform edits on information entered by the programming staff and to insert code into generated JCL. The VSAM Table File T2230X00 is on the PDUC1 Machine. The values are stored in a VSAM Table File so they can be updated, added to, or deleted quickly and in one place.

Vsamtest Focexec

The VSAMTEST FOCEXEC is a Focus Exec that is on the E disk. It can only be changed by the Focus Administrator. This exec controls an AUTODOC user's access to the VSAM Table File. All AUTODOC users are allowed access to the VSAM Table File through an ACF2 rule.

BRINGING SYNC MACHINE UP OR DOWN

Checking For AUTODOC Users

Before bringing the Sync machine down, make sure there are no programmers working in AUTODOC. You can do this by running the CHKAD EXEC. Run this EXEC by entering the following at the command line. enter:

     CHKAD

     USER ID      FILEID QUEUE
 
     HARLAND      D2230F00FOCUS M1
 
     USER ID      FILEID QUEUE
 
     CMS machine  D2230T00FOCUS M1
 
     THE VSAMTEST (1AA) DISK HAS BEEN LINKED FOR YOUR USE AS DISK 'P'
    DOCUTEST 01AA, HARLAND  01AA R/O
    DASD 01AA DETACHED

Note: Your user ID will always be listed under VSAMTEST (1AA) DISK.

If no one is using the Sync machine, you'll receive the following message:

 
     NO SIMULTANEOUS USERS ARE ACTIVE ON FOCADM4
 
     NO SIMULTANEOUS USERS ARE ACTIVE ON FOCADM31
 
     THE VSAMTEST (1AA) DISK HAS BEEN LINKED FOR YOUR USE AS DISK 'P'
    HARLAND  01AA R/O
    DASD 01AA DETACHED

Bringing The Sync Machine Down

To bring the Sync Machine down, log on to FOCADM4. The machine will reconnect. Do not enter B or IPL CMS. Simply type in STOP and hit enter. Then logoff. If the system will not accept STOP, type in #CP LOG and hit enter. This will stop the Sync Machine and log FOCADM4 off. The Sync Machine is now "Down".

Bringing The Sync Machine Up

To bring the Sync Machine up, log onto FOCADM4. When the machine connects itself, it immediately disconnects itself and prompts you with HIT ENTER OR CLEAR KEY TO CONTINUE. Do so, then logon to your machine and Q FOCADM4. It must be disconnected. If it isn't, bring it up again.

PRO1

A PRO1 is used to move a job from the AUTODOC Test FOCUS Database to the AUTODOC Production Focus Database and to generate JCL and MSGLIB which is placed in the DEV AUTOJOB and DEV AUTOMSG (respectively). This is done as part of the PROCOPY process. PRO1s are the responsibility of the Data Administration Group. PRO1s are normally done first thing in the morning, just after lunch, and then again at the end of the day. Before doing a PRO1 you should check to see that the Turnover Form has a new copy of JCL attached to it. If the Turnover Form is part of a Runbook, check to make sure that the Runbook has been signed off by Scheduling. There should be two copies of the Turnover Form.

To do a PRO1:

• Logon to PDUC1
• Enter: CHKAD
  This EXEC checks if anyone is using AUTODOC.
• Bring the SYNC MACHINE down
• Enter: PRO1
• This screen will be displayed.

   
                                                        PRO SCREEN 1
                              AUTODOC PRO EXEC
   
   
      PLEASE ENTER JOB NUMBER AND AN A TO ADD OR A C TO CHANGE A JOB
   
                 JOB NUMBER                       "A" OR "C"
                    (1)                               (2)
   
      ENTER TO PROCESS                                   PF3 TO QUIT
   
  

  1. Type in the Job Number (from Turnover Form)
  2. Type in an A for Add (N or New on the Turnover Form) or C for Change (R or REV on the Turnover Form)
• Press ENTER and you will see the following screen:

   
                                                       PRO SCREEN 2
   
                            AUTODOC PRO EXEC
   
      THE JOB NUMBER      (1)      WILL BE       (2)        THE
      AUTODOC PRODUCTION LIBRARY AND DELETED FROM THE TEST LIBRARY.
      IF YOU WANT TO CONTINUE PRESS THE    ENTER KEY TO PROCESS
      ELSE PRESS   PF3 TO QUIT.
   
      ENTER TO PROCESS                                 PF3 TO QUIT
   
  

  1. Job Number
  2. ADDED TO / CHANGED IN (Depending on A or C entered in PRO SCREEN 1)
• Press ENTER if the information is correct, PF3 if it is not.
• Enter new information or press PF3 to exit
• Three files will be spooled to PDUC1's reader:
  1. DEVAUTOF: Check the condition code. A 0000 or 0004 is okay. This is the update to the DEV AUTOFLAG.
  2. DEVAUTO: Check the condition code. A 0000 is okay. A 0004 means the member was already in the DEV AUTOMSG (if an A was selected), or the member wasn't in the DEV AUTOMSG (if a C was selected). Talk to the programmer requesting the PRO1 to make sure they are aware that a revised job isn't there or a new job is there. Rerun PRO1 with correct code, if necessary.
  3. DEVAUTO: Check the condition code. A 0000 is okay. A 0004 means the member was already in the DEV AUTOJOB (if an A was selected), or the member wasn't in the DEV AUTOJOB (if a C was selected). Talk to the programmer requesting the PRO1 to make sure they are aware that a revised job isn't there or a new job is there. Rerun PRO1 with correct code, if necessary.
• If all three condition codes are okay, bring the SYNC MACHINE up.
• Initial and date both copies of the Turnover Form to the left of the "Chk" column for the DEV AUTOJOB and DEV AUTOMSG (the form MUST have both). Bring the Turnover Forms (with the rest of the paper) down to the basket in Scheduling

DBDELETE

DBDELETE is used to delete a job from the AUTODOC Test Focus Database or the AUTODOC Production Focus Database. This is done at the request of a member of the programming staff. There is a sign up sheet for "SCRATCHES" that the programming staff fills out. DBDELETEs are the responsibility of the Data Administration Group. DBDELETEs are normally done first thing in the morning, just after lunch, and then again at the end of the day. To do a DBDELETE:

• Bring the Sync Machine down
• Logon to PDUC1
• Enter: INFOCUS
• Once in FOCUS, enter: EX WRITEACC D2230F00 (This gives you read/write access to the Test Focus AUTODOC Database)
• Enter: EX ACC309 (This gives you read/write access to the Production Focus AUTODOC Database)
• Enter: FIN (To exit Focus)
• In CMS, Enter: DBDELETE
• The system responds with:

       EXECUTING DBDELETE OF THE JOB FROM DATABASE
       ENTER JOB NUMBER YOU WISH TO DELETE
  

• Enter the job number to be deleted
• The system responds with:

       ENTER "P" IF YOU WISH TO DELETE THE JOB FROM THE PRODUCTION
       DATABASE OR ENTER "T" TO DELETE THE JOB FROM THE TEST DATABASE
  

• Enter a P or a T (the programmer will specify test or production on scratch request form). The system responds with:

       JOB NUMBER   (1)   WILL BE DELETED FROM THE    (2)    DATABASE
       IF THE INFORMATION IS CORRECT ENTER "Y" ELSE ENTER "END"
  

  1. Job Number
  2. TEST / PRODUCTION (depending on T or P entered)
• If the information is correct enter a Y, if not enter END
• The system will return you to CMS
• Bring the Sync Machine back up

UPDATING THE VSAM TABLE FILE

AUTODOC uses a VSAM Table File to perform edits on information entered by the programming staff and to insert code into generated JCL. The VSAM Table File T2230X00 is on the PDUC1 Machine. The values are stored in a VSAM Table File so they can be updated, added to, or deleted quickly and in one place. To change the VSAM Table File:

• Bring the Sync Machine down.
• Logon to PDUC1
• Enter: COPY T2230X00 TABLE A T2230X00 TABOLD A
• Squeeze or archive T2230X00 TABOLD A. Enter: ARC T2230X00 TABOLD A
• XEDIT: T2230X00 TABLE A
• Locate the section of values you wish to add. For example, if you wish to add a model: L/MODEL
• Go to the bottom of the section and find the last value
• Duplicate the line, increase the sequence number, key the new value
• FILE T2230X00 TABLE A
• Enter: VSAM21
• The VSAM21 Exec places a SYSOUT DATA file on the A disk. Check this file to make sure RECORDS IN matches RECORDS OUT. If they don't match, see the FOCUS Administrator. Also check D2230M01 LISTING A for condition code zero. If all condition codes are not equal to zero, see the FOCUS Administrator.
• The VSAM21 Exec places a RPTFL DATA file on the D disk. Send this file to the PSGFORMS id, 'SF RPTFL DATA D TO PSGFORMS'
• Logoff PDUC1
• Bring the Sync Machine back up
• Logon to PSGFORMS
• Read in the RPTFL DATA file to the A disk
• XEDIT RPTFL DATA A
• Run the VTBL XEDIT macro to create and HTML listing of the VSAM table.
• Logoff PSGFORMS

CHANGING AUTODOC COBOL PROGRAMS AND FOCUS MODULES

• Logon to DOCUTEST.
• Check Out the COBOL program to be updated from Source Bank using Option 1 of the SBANK EXEC. The program source will be placed on the 'Z' disk.
• XEDIT the program source on the Z disk and make necessary changes.
• Enter: SBCOB370 programname

  This calls the SBCOBRA EXEC to compile the program and creates programname LISTING Z and programname TEXT Z CMS files.

• Check the programname LISTING Z for errors. Also check to make sure the changes you made are there. The TEXT file is the compiled CMS version of the program.
• If the program ends in SU, it requires an SU module. Five of the programs require an SU FOCUS module (ADCOPYSU, ADECTLSU, ADESU, ADJCTLSU, ADMCTLSU, and ADRCTLSU). To create an SU module

  Enter: FOCUS GENHLI programnamesu (SU If programnamesu COBOL is not on an accessed disk, FOCUS GENHLI will display this message:

  The source code for "programnamesu TEXT" could not be determined.
  Please re-run GENHLI specifying the language from which the TEXT was
  produced.'
   
    FOCUS GENHLI txt1 txt2..... (PLI/FORTRAN/COBOL/ASSEMBLE
  

  To create an SU module in this case:

  Enter: FOCUS GENHLI programnamesu (SU COBOL

  This creates a FOCUS simultaneous user module from the programnamesu TEXT Z file called programnamesu MODULE A. If the module is not created enter: MAC - This will access FOCUS libraries that may have been disconnected from DOCUTEST. Then enter: FOCUS GENHLI programnamesu (SU again.

• Once the FOCUS Module is created, copy programnamesu FOCUS A to the D disk.

  Enter: COPYFILE programnamesu MODULE A = = D If you are just testing, you only need to create the SU module before going into Autodoc to test your changes. As long as the test modules are on the A or D disks, you'll see their effects once in Autodoc on Docutest.

• Erase the programname MODULE from the A disk.

  Enter: ERASE programname MODULE A

• If the program ended in SU, rename the programnamesu TEXT Z file to programname TEXT Z (drop the "SU" from the end).

  Enter: RENAME programnamesu TEXT Z programname TEXT Z.

• Enter: FOCUS GENHLI programname (COBOL

  This creates a COBOL SU module from the programname TEXT Z file called programname MODULE A. All of the programs EXCEPT ADESU require COBOL modules.

• Test the updated modules by entering AUTODOC on DOCUTEST and trying out your changes.
• Once the changes have been thoroughly tested, copy the programname MODULE A and the programnamesu MODULE D to the F disk. To get write access to the F disk,

  Enter: CONNECT F W

  then copy the two modules to the F disk.

  Enter: COPYFILE programname MODULE A = = F Enter: COPYFILE programnamesu MODULE D = = F

• After the modules are copied,

  Enter: CONNECT F

  to release the write access from the F disk.

• Check In the COBOL program to be updated into Source Bank using Option 3 of the SBANK EXEC. This puts the changed source back in the Source Bank library at control level TEST.
• Promote the COBOL program to level PREP using the SBCOPY EXEC. Specify 'N' at the COMPILE? option.
• If COPY members have been changed, specify 'Y' at the COPY CODE? option, or promote them individually with the SBCOPY EXEC.
• Fill out a Turnover Form for Source Bank (SBCOPY) for: programname COBOL with Compile? (Y/N): N
• If copy members were changed, fill out a Turnover Form for Source Bank (SBCOPY) for: copycodename COPY with Copy Code? (Y/N): Y
• Fill out a Turnover Form under "CMS LIBRARY UPDATES" for: programname MODULE F and programnamesu MODULE F

UPDATING JOBSDBC COPY MEMBER

The JOBSDBC Copy member is copied into all AUTODOC COBOL programs when they are recompiled. It contains Working Storage definitions that are common to (and required by) all programs. Rarely are these definitions changed, but this section describes how to change them. The JOBSDBC Copy member that is used during the compile is stored in Source Bank. To change the JOBSDBC Copy member:

• Logon to DOCUTEST
• Check Out the JOBSDBC COPY member from Source Bank using Option 1 of the SBANK EXEC. The copy member will be placed on the 'Z' disk.
• XEDIT JOBSDBC COPY Z and make necessary changes.
• Check In the JOBSDBC COPY member on Source Bank using Option 3 of the SBANK EXEC. This puts the changed copy member in the Source Bank library at control level TEST.
• You may now recompile AUTODOC COBOL programs, since the SBCOBRA EXEC uses copy members from Source Bank when compiling programs.
• Check Out the programs using the SBANK EXEC and compile them from the 'Z' disk.
• Create FOCUS SU and COBOL Modules with the new programs.
• Enter: AUTODOC and test the Modules.
• Enter: AUTODOC and test the Modules.
• Once the Modules have been thoroughly tested:
  • Get write access to F Disk: CONNECT F W
  • Copy all new Focus Modules to F Disk.
  • Release write access to F Disk: CONNECT F
  • Fill out a Turnover Form for Source Bank (SBCOPY) for: JOBSDBC COPY with Copy Code? (Y/N): Y
  • Fill out a turnover form for:
    1. JOBSDBC DEV COPYLIB
    2. All FOCUS SU And COBOL Modules
  • It isn't necessary to SBCOPY the programs, since they were not changed, they were recompiled using a new copy member.
  • Check In the programs using the SBANK EXEC.

CHANGING THE ORDER OF STEPS IN AN EXISTING AUTODOC JOB

If a programmer wants to add a step at the beginning of an AUTODOC job, the programmer must add the new step as STEP02 after the old STEP01. The Production Support Group must then rename STEP01 and STEP02 so they are in the proper sequence. For example, if a job J0000M01 has three steps:

                    STEP01   PROGRAMA
                    STEP02   PROGRAMB
                    STEP03   PROGRAMC

and  the  programmer wishes to add a new step at the beginning of the
job that uses PROGRAMD, the programmer would add the new step after the
old STEP01 as STEP02, and you would do the following:

Take the Sync Machine down
Logon to PDUC1
Enter: INFOCUS
Once in FOCUS, enter:
          EX WRITEACC D2230F00
          TABLE FILE D2230F00
          PRINT JOBNUM STEP PROGRAM
          IF JOBNUM IS J0000M01
          END

This will produce a table file report of what the Test AUTODOC
Database looks like for J0000M01.  The report will look like this:
          J0000M01  STEP01   PROGRAMA
          J0000M01  STEP02   PROGRAMD
          J0000M01  STEP03   PROGRAMB
          J0000M01  STEP04   PROGRAMC

To rename the old STEP02 to the new first step and rename the old
first step to the new STEP02, stay in FOCUS:
          Enter:
            SCAN FILE D2230F00
          System Responds:
            SCAN:
          Enter:
            SHOW JOBNUM STEP PROGRAM
          Enter:
            TOP
          System Responds:
            TOF:
          Enter:
            LOCATE JOBNUM=J0000M01,STEP=STEP02,PROGRAM=PROGRAMD
          System Responds:
            JOBNUM=J0000M01 STEP=STEP02 PROGRAM=PROGRAMD
          Enter:
            REPLACE KEY STEP=STEP01,$
          System Responds:
            JOBNUM=J0000M01 STEP=STEP01 PROGRAM=PROGRAMD
            KEY VALUE RESEQUENCED

The old J0000M01 STEP02 PROGRAMD is now changed to the new J0000M01
STEP01 PROGRAMD.  Now repeat the process for the old STEP01 PROGRAMA:
          Enter:
            TOP
            LOCATE JOBNUM=J0000M01,STEP=STEP01,PROGRAM=PROGRAMA
            REPLACE KEY STEP=STEP02,$
            FILE

The old STEP02 has become the new STEP01 and the old STEP01 has
become the new STEP02.  You MUST follow the specified procedure when
renumbering job steps:   Change the old STEP02 to the new STEP01 and then
change the old STEP01 into the new STEP02.  This ensures that you are
renumbering the correct old step.  The reason for this may not be clear
in the previous example, but if the job uses the same program in STEP01
and STEP02, working "backwards" in the file is a must.
Run another table file report to make sure the database is properly
renumbered.  Still in FOCUS, Enter:
          TABLE FILE D2230F00
          PRINT JOBNUM STEP PROGRAM
          IF JOBNUM IS J0000M01
          END

This will show you a table file report of what the new Test AUTODOC
Database looks like for J0000M01.  The report will look like this:
          J0000M01  STEP01   PROGRAMD
          J0000M01  STEP02   PROGRAMA
          J0000M01  STEP03   PROGRAMB
          J0000M01  STEP04   PROGRAMC

Enter: FIN
Logoff PDUC1
Bring the Sync Machine back up.

 PRODOWN and DEVCOPY 
PROPOWN and DEVCOPY are currently the responsibility of the
Programming Staff.  PRODOWN and DEVCOPY are accessed from the AUTODOC
Main Menu.
 PRODOWN 
See the "AUTODOC Main Menu" section in the AUTODOC Instruction Manual for
detailed information.
 DEVCOPY 
See the "AUTODOC Main Menu" section in the AUTODOC Instruction Manual for
detailed information.
 UPDATING AUTODOC FOR A NEW AUTODOC USER 
When a new programmer joins the staff, or a staff member gets a new
CMS Machine, or a staff member has their CMS Machine renamed, it is the
Production Support Group's responsibility to add the new (or renamed) CMS
Machine to AUTODOC.  To add a new user to AUTODOC:

On PSGUTIL (or your CMS Machine) copy the PASSID DATA E file
from the E Disk to your disk.
Add the new CMS Machine name alphabetically to the file in columns
1-8.  Be sure to code PDUC1 in columns 10-14.
Copy the PASSID DATA file from your disk to the F disk.
Fill out a Turnover form for PASSID DATA F with your name and CMS
Machine at the top.  Make two copies of this form, and give all three to
the FOCUS Administrator.
User names no longer need to be added  to  VSAMTEST  FOCEXEC  E.
Access is allowed by ACF2.
Fill out a Dataset/Resource Access Request Form (available from the
ACF2 Administrator) for Read/Write access to D2230F00 - the Test Focus
Database, and read access to D2230F01 - the Production Focus Database.
When you fill out the form, the Requestor is you, the Resource is
D2230F00 and D2230F01, Access Required is R/O, the Owner is the
Production Support Group Manager (who must sign the form), and the Term
Date is Perm.
Return the completed form to the ACF2 Administrator.
Once the PASSID DATA F Turnover Form is submitted to  Scheduling
the new CMS Machine is ready to use AUTODOC.

 ADDING A NEW PROC TO JCL GENERATOR AND VSAM TABLE 
Currently, AUTODOC allows  46  executable Procs:
         BACKUP               FILESAVE
         BLDINDEX             FLEETCK1
         BLDINDX2             FOCCAT
         BLDINDX3             FOCUS
         BLDINDX4             FOCUSSRT
         CATRPTS              FRSPROD
         DADSA330             GENSPROD
         DADSBTCH             GENSTEST
         DADSPREP             MIC6COM
         DADSP330             MVSFTP
         DADSP410             PROCARD
         DADSR330             P8528PRT
         DADSS330             P8628OFT
         DADSS410             P8628PRO
         DSNUPROC             P8628PRT
         EZTPCG               RESTORE
         EZTPCG2K             SARSJRN1
         EZTSCG2K             SARSJRN2
         EZTSQLCG             SARSJRN3
         FDRCPK               SARSJRN4
         FDRDSF               SAS
         FDRFULL              SORT
         FDRTCOPY             UCCQYS

To add a new Proc to AUTODOC:

Logon to PDUC1

Add the Proc name to the VSAM table (see "Updating The VSAM File").
Locate the section in the VSAM table that Begins:   PRCLB

You do NOT need to update the Editor (ADECTLSU).
Bring the JCL Generator (ADJCTLSU) down from SBANK for update.  For
information on how to bring a Cobol program down, change it, and generate
Focus SU Modules, see the section "Changing Autodoc Cobol Programs and
Focus Modules".

Go to the Proc area of ADJCTLSU.  There are two of them:
Q1050-SAVE-EXEC-RTN and B3050-NEXT-STEPS-EDIT-RTN
Duplicate an existing Proc (don't forget to duplicate the "ELSE"
that separates Procs), and change the name of the Proc in the duplicate
to the new Proc.

Recompile the program and create Focus SU Modules.
Test, Test, Test, Test, Test.
Once testing is successful, fill out a turnover form for the Focus SU
Modules, and replace the ADJCTLSU program in the archive with the new
version you have created.

 RESTORING A LOST JOB TO THE PRODUCTION OR DEVELOPMENT FOCUS DATABASE 
Occasionally a job in the Production or Development Focus Database must
be restored from information stored on a backup tape.  This can happen in
the Production Database when a programmer inadvertently Procopies
incorrect JCL (replacing the good JCL in the Production Database with bad
JCL).  Or it can happen in the Production or Development Database if a
DBDELETE is accidently executed on the wrong job (it happens).
The process of restoring a job to the Production or Development Focus
Database is accomplished in cooperation with the Focus Administrator.
 RESTORING A LOST JOB TO THE PRODUCTION FOCUS DATABASE 
To restore a job to the Production Database:

Determine when the correct information was in the Production Database
by speaking with the programmer who lost the job.  There are 5
generations of backups for the previous 5 production schedules.
Speak with the Focus Data Administrator and ask her if the D2230F01
backup is available for the day indicated by the programmer.  The tape
may be off-site and will need to be returned to the Computer Center, so
the restore process may have to be planned in advance.
Plan the restore for first thing in the morning, and make sure no
Procopies or Prodowns are done on the morning of the restore.  The
purpose for this will be clear later.
The morning that the Focus Administrator is restoring the Production
Database, send a note to all programmers asking them not to do any
Prodowns or request any Procopies.  Since the SINC machine can stay up
for this process, the programmers can continue to work in the AUTODOC
Development Database.
The Focus Administrator will write over the current version of the
Production Database with the backup from tape.
Do a Prodown for the job that was lost.  This will copy the correct
version of the job from the backup Production Database to the current
Development Database.
Ask the programmer who requested the restore to check the job in
AUTODOC to make sure it's the version they wanted.
If the job checks out in AUTODOC, ask Connie to restore the
Production Database from the most recent backup.  (Usually the previous
night's).  This is why you want to do a restore right after a backup of
the current version of the Production Database.  This is also why you
don't want programmers doing Prodowns during a restore.  They may
inadvertently Prodown an old version off the backup tape, and lose recent
changes.  It is also why you don't want programmers doing Procopies:  The
data will be moved from the Development Database and into the Temporary
Production Database and lost forever when the most recent Production
Database is restored from the previous backup.
If the Programmer needs to make changes to the job, you are finished.
When he/she is done with changes, they will have ISS do a PRO1, and the
correct version of the job will be added back into the Production
Database.
If there were no changes to be made to the job, do a PRO1 on the job
as soon as the programmer says it's the correct version of the job.
 At this point, you have:
 

Determined which version of the Production Database contains the
job that was lost.
Ensured that the Current Production Database is backed up to tape.
Frozen activity on the Current Production Database.
Replaced the Current Production Database with an Old Production
Database that contained a lost job.
Prodowned (copied) the lost job from the Old Production Database into
the Current Development Database.
Replaced the Old Production Database with the Current Production
Database that was backed up on tape.
PRO1ed the job from the Development Database into the Production
Database. (Executed either by you or the ISS).

Send a note to the programmers and let them know that the Production
Database is open, and they are free to do Prodowns and Procopies again.

 RESTORING A LOST JOB TO THE DEVELOPMENT FOCUS DATABASE 
The following procedure is for jobs that are not yet in Production, and
the copy of the job that was in the Development Database was lost.  It
could be altered to accomodate a job that is in Production, where a 
major update (change) that was in the Development Database was lost.
Remember:  If a job is erased from the Development Database, and
there is a copy in the Production Database, you need only do a Prodown to
restore the job to the Development Database (provided the copy in the
Production Database is fairly close to what was lost from the
Developement Database).
 To restore a Non-Production job to the Development Database:

Determine when the correct information was in the Development
Database by speaking with the programmer who lost the job.  There are
5 generations of backups from the previous 5 production schedules.
Speak with the Focus Data Administrator and ask her if the D2230F00
backup is available for the day indicated by the programmer. The tape may
be off-site and will need to be returned to the Computer Center, so the
restore process may have to be planned in advance.
Plan the restore for first thing in the morning, and make sure no
Procopies or Prodowns are done on the morning of the restore.  This way
if there is any problem with the restore, you can always go back to the
original databases (before you began the restore process).
The morning that the Focus Administrator is restoring the Development
Database, send a note to all programmers informing them that Autodoc will
be down for the morning.
Bring the Sync Machine down.
The Focus Administrator will save a copy of the current Development
Database and write over it with the backup Development Database from
tape.
Do a Pro1 for the job that was lost.  This will copy the job from the
backup Development Database to the current Production Database.
Have the Focus Administrator restore the original current Development
Database from the copy she made earlier.
Bring the Sync Machine back up.
Do a Prodown for the job to be restored.  This will copy the job from
the current Production Database into the current Development Database.
Ask the programmer who requested the restore to check the job in
AUTODOC to make sure it's what they wanted.
If the job checks out in AUTODOC, bring the Sync Machine down and do
a Dbdelete of the job from the Production Database.
Bring the Sync Machine back up.
Submit a turnover form requesting that the jobname DEV.AUTOJOB
and jobname DEV.AUTOMSG be scratched (the jobname
DEV.AUTOFLAG is scratched during the Dbdelete).
At this point, you have:

Determined which version of the Development Database contains the job
that was lost.
Ensured that the Current Production Database is backed up to tape.
Frozen activity on the Current Production and Development Databases.
Replaced the Current Development Database with an Old Development
Database that contained a lost job.
Pro1ed (copied) the lost job from the Old Development Database into
the Current Production Database.
Replaced the Old Development Database with the Current Development
Database that was saved.
Prodowned (copied) the lost job from the Current Production Database
into the Current Development Database.
Dbdeleted (erased) the lost job from the Current Production Database.

Send a note to the programmers and let them know that Autodoc is back
up.

 REBUILDING THE TEST DATABASE ON DOCUTEST 
When a field is to be added to the the Development and Production Autodoc
Focus Databases, it is first added to the database on DOCUTEST for
testing.  To add the field and rebuild the database:

Have the Focus Administrator send a decripted copy of the Production
D2230F00 MASTER File to DOCUTEST (with DBA information as well as any CMS
Machine IDs imbedded in it).
Logon to DOCUTEST
Receive the D2230F00 MASTER File on the A disk (use the REPLace
option).
Get at least 20 cylinders of Zspace.
Copy the current D2230F00 FOCUS database from the D disk to the Z
disk as a backup.  (Give it a file type other than FOCUS).
Copy the current  D2230F00 MASTER from the A disk to the Z disk as a
backup.  (Give it a file type other than MASTER).
Enter:  INFOCUS
Enter: SET TEMP = Z    If, for any reason, you exit Focus during the
rebuild process, you must re-enter this command when you get back
into Focus.
You must now "Dump" the existing D2230F00 FOCUS database on the D
disk to a REBUILD FOCTEMP work file on the Z disk using the current
Master file on the A disk:

Enter:  REBUILD   Focus will give you a series of choices to make.
The answers to these choices are (in order):

Enter:  REORG
Enter:  DUMP
Enter:  D2230F00 FOCUS D
Enter:  NO

Example:
>
rebuild
ENTER OPTION (REBUILD,REORG,INDEX OR CHECK)=
reorg
ENTER THE REORG PHASE (DUMP OR LOAD)=
dump
ENTER NAME OF FOCUS FILE (FN FT FM)=
d2230f00 focus d
ANY RECORD SELECTION TESTS? (YES/NO)=
no
STARTING..
 
FILEDEF REBUILD DISK REBUILD FOCTEMP Z4 (LRECL 00952 BLKSIZE 29516 RECFM VB)
REFERENCE..AT SEGMENT    1000
REFERENCE..AT SEGMENT    2000
REFERENCE..AT SEGMENT    3000
NUMBER OF SEGMENTS RETRIEVED=    3380
>


Enter:  CMS XEDIT D2230F00 MASTER A  and add the field to the
D2230F00 MASTER on the A disk at the bottom of the segment  where
you want to field to be (after the filler, if there is one).
You must now "Load" the REBUILD FOCTEMP Z work file to the D2230F00
FOCUS Database on the D disk using the D2230F00 MASTER A with the new
field at the bottom of the segment:

Enter:  CMS ERASE D2230F00 FOCUS D  to erase the D2230F00 FOCUS
database from the D disk.  The database is stored in the REBUILD FOCTEMP
Z work file.
Enter:  REBUILD  Focus will give you a series of choices to make.
The answers to these choices are (in order):

Enter:  REORG
Enter:  LOAD
Enter:  D2230F00 FOCUS D

Example:
>
rebuild
ENTER OPTION (REBUILD,REORG,INDEX OR CHECK)=
reorg
ENTER THE REORG PHASE (DUMP OR LOAD)=
load
ENTER NAME OF FOCUS FILE (FN FT FM)=
d2230f00 focus d
STARTING..
 
 NEW FILE D2230F00FOCUS   D  ON 05/21/91 AT 12.51.32
REFERENCE..AT SEGMENT    1000
REFERENCE..AT SEGMENT    2000
REFERENCE..AT SEGMENT    3000
NUMBER OF SEGMENTS INPUT=    3380
>


 If you are adding a new segment to the database you
have completed the rebuild.
The D2230F00 FOCUS database has been rebuilt on the D disk with the
new field added at the bottom of the segment.  You now want to move the
new field to its proper location in the segment.  To do this, you must
first "Dump" the newly rebuilt database on the D disk to a REBUILD
FOCTEMP work file on the Z disk using the Master with the field at the
bottom of the segment (the master you just used to "Load" the database):

Enter:  REBUILD   Focus will give you a series of choices to make.
The answers to these choices are (in order):

Enter:  REORG
Enter:  DUMP
Enter:  D2230F00 FOCUS D
Enter:  NO

Example:
>
rebuild
ENTER OPTION (REBUILD,REORG,INDEX OR CHECK)=
reorg
ENTER THE REORG PHASE (DUMP OR LOAD)=
dump
ENTER NAME OF FOCUS FILE (FN FT FM)=
d2230f00 focus d
ANY RECORD SELECTION TESTS? (YES/NO)=
no
STARTING..
 
FILEDEF REBUILD DISK REBUILD FOCTEMP Z4 (LRECL 00956 BLKSIZE 29640 RECFM VB)
REFERENCE..AT SEGMENT    1000
REFERENCE..AT SEGMENT    2000
REFERENCE..AT SEGMENT    3000
NUMBER OF SEGMENTS RETRIEVED=    3380
>


Enter:   CMS XEDIT D2230F00 MASTER A  and move the field in the
D2230F00 MASTER on the A disk from the bottom of the segment to where
you want to field located in the segment.
You must now "Load" the REBUILD FOCTEMP work file to the D2230F00
FOCUS Database on the D disk using the D2230F00 MASTER with the new field
in its proper location in the segment:

Enter:  CMS ERASE D2230F00 FOCUS D  to erase the D2230F00 FOCUS
database from the  D  disk.  The database is stored in the REBUILD
FOCTEMP Z work file.
Enter:  REBUILD   Focus will give you a series of choices to make.
The answers to these choices are (in order):

Enter:  REORG
Enter:  LOAD
Enter:  D2230F00 FOCUS D

Example:
>
rebuild
ENTER OPTION (REBUILD,REORG,INDEX OR CHECK)=
reorg
ENTER THE REORG PHASE (DUMP OR LOAD)=
load
ENTER NAME OF FOCUS FILE (FN FT FM)=
d2230f00 focus d
STARTING..
 
 NEW FILE D2230F00FOCUS   D  ON 05/21/91 AT 12.54.22
REFERENCE..AT SEGMENT    1000
REFERENCE..AT SEGMENT    2000
REFERENCE..AT SEGMENT    3000
NUMBER OF SEGMENTS INPUT=    3380
>


The D2230F00 FOCUS database has been rebuilt on the D disk with the
new field in its proper location.
Exit Focus:   FIN

 Restoring DEV or PRO Library Members Using FDR 
If a programmer scratches a member from a library  (Dev  Srclib,  Dev
Eztlib,  Pro  Eztlib,  Pro  Joblib,  etc),  and  needs to recover the
member, there is a procedure that must be  followed  to  restore  the
member  from backup tapes.  There are five generations of the backups
kept from the past five days that  a  production  schedule  was  run.
Consequently, if the member was scratched more than five days ago, it
can  not  be  recovered.    To restore a member to a library that was
scratched within five days:
 

You must determine the pack that contained the library.  There are
three backup jobs that backup the three packs that contain libraries:

J8112BU1 - USR004 - All PRO libraries
J8112BU2 - USR011 - All DEV libraries
J8112BU3 - USR026 - Development Tables and Test Datasets
Look at the job that you think is backing up the library.  Contained
in the JCL will be a listing of all libraries backed up by the job, or a
reference to a PRO CCDLIB member that contains the list.  This will tell
you without a doubt which pack contained the library and which job backed
it up.
Once you have determined the job that backs up the library, look in
the JCL to find the dataset name assigned to the backup tape.
 DSNs with an  M  in the sixth character are backups
that stay on site.   DSNs with a  B  in the sixth character are backups
stored off site.  Use the DSN that is on site.
Run LISTCTLG (an IEHLIST utility) on the DSN to find the generations
that contain the backups.  A partial sample of a LISTCTLG listing:
                              SYSTEMS SUPPORT UTILITIES---IEHLIST      PAGE    1
DATE: 1990.338  TIME: 12.54.14
 GENERAL INFORMATION FOR CATALOG ON VOL USR011
 DS OR INDEX NAME         ENTRY TYPE    VOL.ID.   SEQ.NO.   DEV.TYPE  ALIAS OF
   LISTING OF CATALOG BELOW NODE POINT PRO.ADMSYS.F8112M00
PRO.ADMSYS.F8112M00.G1379V00            001016    000001    32008003
PRO.ADMSYS.F8112M00.G1378V00            001002    000001    32008003
PRO.ADMSYS.F8112M00.G1377V00            000993    000001    32008003
PRO.ADMSYS.F8112M00.G1376V00            000982    000001    32008003
PRO.ADMSYS.F8112M00.G1375V00            001020    000001    32008003
PRO.ADMSYS.F8112M00.G1374V00            001016    000001    32008003

In a LISTCTLG listing the most recent backup (the 0 generation) is at the
top, and the oldest backup is second from the bottom (the dummy
generation is the last dataset listed).  Determine which generation you
need based on when the member was created and scratched.

The JCL to recover the member follows.  The JCL in the example is set
up to recover a member from the DEV SRCLIB:
//TRECOVER JOB (9700,0004,2,99),'*PROG-MMOSTOWY',
//        CLASS=D,TIME=2,MSGCLASS=A
/*ROUTE PRINT UCONNVM.MMOSTOWY
//JOBLIB  DD DSN=FDRABR.LOADLIB,DISP=SHR
//STEP1 EXEC PGM=FDRDSF,REGION=500K
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK1    DD UNIT=3380,VOL=SER=SCR002,DISP=SHR
//TAPE1    DD UNIT=TAPE,LABEL=1,
//         DSN=PRO.ADMSYS.F8112M00.G1375V00,DISP=(OLD,KEEP)
//SYSIN    DD *
      RESTORE TYPE=DSF
      RESTORE DSN=DEV.SRCLIB,NEWNAME=BKDEV.SRCLIB
/*
//**  RESTORE DSN=DEV.SRCLIB,NEWNAME=BKDEV.SRCLIB,NOCAT
//**  RESTORE DSN=DEV.SRCLIB,NEWNAME=BKDEV.SRCLIB,RECAT
//**  RESTORE DSN=DEV.SRCLIB,NEWNAME=BKDEV.SRCLIB
//**      WITH RECAT EITHER AN ALIAS MUST EXIST (PRO) OR
//**      MUST SPECIFY A STEPCAT SOMEWHERE IN JCL
//**  JOB WILL ABEND WITH U0888 IF IT ATTEMPTS TO RECATALOG
//**      A DATASET WITHOUT AN ALIAS OR STEPCAT.
//**      (BUT THE DATASET WILL STILL HAVE BEEN RESTORED)

 
In the TAPE1 DD Name, replace PRO.ADMSYS.F8112M00.G1375V00 with the DSN
you wish to restore (remember to use the correct generation).

When you run the JCL, the DEV SRCLIB from the tape is restored to
SCR002 and given the name BKDEV.SRCLIB.  The Job may abend and issue a
return code of U0888 because the system is trying to catalog to
BKDEV.SRCLIB.  Since you don't need the library cataloged, this is no
problem, and the library will still be restored.  Look for the message at
the bottom of the listing:
FDR998**  RESTORE COMPLETED WITH ERRORS VOL=SCR002

 
A partial sample listing of a TRECOVER job:

IEF375I  JOB /TRECOVER  / START 90334.1440
IEF376I  JOB /TRECOVER  / STOP  90334.1453 CPU 0MIN 50.63SEC SRB 0MIN 01.31SEC
FDR101 FAST DUMP RESTORE DATA SET FUNCTIONS - VER. 5.0C- INNOVATION DATA PROC
FDR303  CARD IMAGE --       RESTORE TYPE=DSF
FDR303  CARD IMAGE --       RESTORE DSN=DEV.SRCLIB,NEWNAME=BKDEV.SRCLIB
FDR101 FAST DUMP RESTORE DATA SET FUNCTIONS - VER. 5.0C- INNOVATION DATA PROC
FDR007 STARTING TIME OF DATA SET RESTORE 14.40.30 UNIT=3380,IN=TAPE1,OUTPUT=DISK1
FDR334** FDR FAILED TO CATALOG COMP=X'000800380000' DSN=BKDEV.SRCLIB
FDR311   FDR RESTORED DSN=DEV.SRCLIB                                   ALLOCATED
FDR311                TO NEWN=BKDEV.SRCLIB
FDR007  ENDING  TIME OF DATA SET RESTORE 14.52.27 UNIT=3380,IN=TAPE1,OUTPUT=DISK1
FDR122      BYTES DSK TRK  T BLKS  RESTART  STIMERS ERRS ACT DSK  LOW HGH
FDR122N 0241230501         006261                    000  002814
FDR998**  RESTORE COMPLETED WITH ERRORS VOL=SCR002


The LOOKPDS EXEC on PSG member's CMS machines has been altered
slightly to allow you to look at members in the BKDEV.SRCLIB on SCR002.
If you do not have the modified LOOKPDS EXEC, add the following line to
the LOOKPDS EXEC on the E disk and file it on your A disk:
&IF &2 EQ BKDEV &DISK = *

To link to SCR002, issue the following command:
         USE OSD 2

 
Do a LOOKPDS on the member the programmer wants recovered in the
BKDEV.SRCLIB.  When the member appears on the screen, look for the
message "FOUND IN BKDEV.SRCLIB", just to make sure you are looking at the
correct member.
File a copy of the member on your  Z  disk and send a copy to the
programmer who requested the restore.  It is a good idea to send a copy
to your own reader and keep it for a couple of days.  You will frequently
get a request to restore the member again the next day, because the
programmer placed it on his/her  Z  disk and lost it again.
Because the BKDEV.SRCLIB was created on SCR002, it will be scratched
automatically.

 Restoring MVS Datasets Using FDRABR 
All general user packs (USRnnn) are being backed up by FDRABR as of
January 1, 1994.  These backups are being retained for 5 weeks.  MVS
backups are run at midnight on Friday.  The 2 most recent MVS backups are
kept offsite.  The remaining backups are stored in the data center.  Hard
copy lists of each backup are kept in Operations.  These can be used to
find information about the backups.
 If a non-catalogued dataset whose dataset name is
greater then 43 characters is deleted the backup information is not
stored in the FDRABR catalog.  If you don't know the dataset name and
volser for this dataset, you will need to use the hard copy lists in
Operations.
This procedure must be followed to restore a dataset from these backup
tapes.
First find the FDRABR tapes you will need to restore the dataset.

Run the FDRPRINT EXEC.
Select '1' for datasets that still exist, or  '2'  for  datasets
that have  been  scratched.    Select  '3' for a history of all tape
activity in the ABR catalog.
Enter the dataset name when prompted.
Enter a volser when prompted, if it's required.
The EXEC looks at USR004, USR011, and USR026 by default.  If you need
to look on another pack, enter it now.  Press Enter to continue.
Check the BDATE(nn) field  of  the  report  for  the  generation
number, 'nn' in parenthesis.  The '00' generation is the most current
and  '04'  is  the oldest.   This number is used for the 'OLDBACKUP='
field in the restore job.
            ****** BACKUP  INFORMATION ******
  BDATE(00)-94.127 SFX-C1003000 FN-010 VOLS-006093,006239,006277
  BDATE(01)-94.120 SFX-C1002900 FN-010 VOLS-004119,004206
  BDATE(02)-94.113 SFX-C1002800 FN-011 VOLS-007623,007707
  BDATE(03)-94.106 SFX-C1002700 FN-012 VOLS-008194,008265
  BDATE(04)-94.099 SFX-C1002600 FN-010 VOLS-005187,005332,005368

FDRPRINT will submit three types of FDR print jobs to MVS.    A
sample of each type is listed below.
 

JCL to list FDRABR tape activity for a dataset.
//FDRPBKUP JOB (9600,0004,1,99),'*PROG-HARLAND',
//        CLASS=D,MSGCLASS=I,TIME=(,20),REGION=1024K
/*ROUTE PRINT UCONNVM.HARLAND
//STEP01   EXEC PGM=FDRABRP
//STEPLIB  DD DSN=FDRABR.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//ABRMAP   DD SYSOUT=*
//ABRSUM   DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK0001 DD UNIT=SYSDA,VOL=SER=USR004,DISP=SHR
//DISK0002 DD UNIT=SYSDA,VOL=SER=USR011,DISP=SHR
//DISK0003 DD UNIT=SYSDA,VOL=SER=USR026,DISP=SHR
//* DISK0099 DD UNIT=SYSDA,VOL=SER=VOLSER,DISP=SHR
//SYSIN    DD *
 PRINT BACKUP,DSN=PRO.JOBLIB,SELTERR=NO,
       OLDBACKUP=ALL,COMBINE,FORMAT=CRT
/*
//

 
JCL to list FDRABR tape activity for a scratched dataset.
//FDRPSCR  JOB (9600,0004,1,99),'*PROG-HARLAND',
//        CLASS=D,MSGCLASS=I,TIME=(,20),REGION=1024K
/*ROUTE PRINT UCONNVM.HARLAND
//STEP01   EXEC PGM=FDRABRP
//STEPLIB  DD DSN=FDRABR.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//ABRMAP   DD SYSOUT=*
//ABRSUM   DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK0001 DD UNIT=SYSDA,VOL=SER=USR004,DISP=SHR
//DISK0002 DD UNIT=SYSDA,VOL=SER=USR011,DISP=SHR
//DISK0003 DD UNIT=SYSDA,VOL=SER=USR026,DISP=SHR
//* DISK0099 DD UNIT=SYSDA,VOL=SER=VOLSER,DISP=SHR
//SYSIN    DD *
 PRINT SCRATCH,DSN=DEV.JOBLIB,SELTERR=NO,VOLG=USR,
       OLDBACKUP=ALL,FORMAT=CRT,XREF
/*
//

 
JCL to list FDRABR Catalog tape activity.
//FDRPCATL JOB (9600,0004,1,99),'*PROG-HARLAND',
//        CLASS=D,MSGCLASS=I,TIME=(,20),REGION=1024K
/*ROUTE PRINT UCONNVM.HARLAND
//STEP01   EXEC PGM=FDRABRP
//STEPLIB  DD DSN=FDRABR.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//ABRMAP   DD SYSOUT=*
//ABRSUM   DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK0001 DD UNIT=SYSDA,VOL=SER=USR004,DISP=SHR
//DISK0002 DD UNIT=SYSDA,VOL=SER=USR011,DISP=SHR
//DISK0003 DD UNIT=SYSDA,VOL=SER=USR026,DISP=SHR
//* DISK0099 DD UNIT=SYSDA,VOL=SER=VOLSER,DISP=SHR
//SYSIN    DD *
 PRINT CATLG,
       FORMAT=CRT
/*
//

 
Now setup and run the restore job.  The following is an example
of the restore JCL.  The job simulates the restore of PRO.JOBLIB from
backup  '00'  (BDATE(00)  from the FDR print job) to a new dataset on
SCR002 named BKPRO.JOBLIB.
//FDRABRR JOB (9601,0004,2,99),'*PROG-LH',
//        CLASS=D,TIME=2,MSGCLASS=A,REGION=4M
/*ROUTE PRINT UCONNVM.HARLAND
//STEP1 EXEC PGM=FDRABR
//STEPLIB  DD DSN=FDRABR.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//DISK1    DD UNIT=3380,VOL=SER=SCR002,DISP=SHR
//TAPE1    DD DSN=FDR,VOL=SER=FDR,
//            UNIT=T38K,
//            DISP=(OLD,KEEP)
//SYSIN    DD *
      SIMREST TYPE=ABR,DATA=ALL
      SELECT  DSN=PRO.JOBLIB,VOL=USR004,OLDBACKUP=00,NOCAT,
              NEWNAME=BKPRO.JOBLIB,NVOL=SCR002
/*
//

 
The restore should be simulated first.  FDRABR will restore  over  an
existing  non-VSAM  dataset  by  default,  if it exists on the target
volume.
 
 When you are ready  to  restore  the  file,  change  the  SIMREST
command to RESTORE and run the job.
      RESTORE TYPE=ABR,DATA=ALL
      SELECT  DSN=PRO.JOBLIB,VOL=USR004,OLDBACKUP=00,NOCAT,
              NEWNAME=BKPRO.JOBLIB,NVOL=SCR002

A restore  has two control statements, RESTORE statement and at least
one SELECT statement.  Any number of datasets can be restored.  Some
keywords can go on either the RESTORE statement where the affect is
global, or individually on each SELECT statement.  These keywords are
NOCAT, RECAT, COPY, DSNENQ(not used the same way on RESTORE and SELECT),
PRESTAGE, RLSE, %FREE, and VRECAT.
Following is a brief summary of suggested RESTORE statement
specifications.

Specify TYPE=ABR.
Use DSNENQ=USE to enqueue datasets during the restore.
Use COPY=2 if restoring from offsite copies.
Use SELTERR=NO.
FDRABR will catalog non-VSAM datasets unless they are  cataloged
to  another  volume.    Use  NOCAT  if  you  DO  NOT want the dataset
cataloged.  Use RECAT if you DO want the dataset cataloged even if it
is already cataloged on another volume.
VSAM clusters must always be cataloged.  By default, FDRABR will
not  allocate  clusters  if  the  cluster names already appear in the
catalog.   Use VRECAT to have FDRABR  attempt  to  DELETE  or  DELETE
NOSCRATCH  the  existing  cluster before allocating the cluster to be
restored.  VRECAT will delete all componenets of a cluster  including
alternate indexes and paths.
The  ICFCAT  keyword  determines the source of the catalog naem
FDRABR uses when restoring a VSAM cluster.  Options are:

ICFCAT=ORIGINAL          Use the dataset's original catalog.
                              Default on a restore to same name.
ICFCAT=ALIAS             Catalog dataset using the alias in  the
master catalog.
ICFCAT=STEPCAT           Use   the   catalog  specified  on  the
STEPCAT statement.

Following is a brief  summary  of  suggested  SELECT  statement
specifications.
 

Select the datasets to be restored using DSN=, CATDSN=, DD=, or
ALLDSN.  Filters for generic dataset selection can be used  with  DSN
and CATDSN.
By  default,  FDRABR  will restore from the most recent backup.
Use OLDBACKUP= to specify the  relative  backup  number  to  be  used
(BDATE field from the FDR print job).
NEWNAME=, NEWGROUP=, NEWINDEX=, or NEWDD= can be used to restore
a dataset to a new name.
NVOL=  can  be  used  to specify a new target output volume, or
group of volumes.
Refer to the FDR manual for complete command syntax.
 Restoring VM Datasets 
All permanent disk space on VM accounts (CMS user ids) is  backed  up
on a regular basis.  The backup include files on all permanent disks
including filemode 0 (e.g. A0) files.  The 2 most current backups are
stored  offsite,  all  others  are  stored  at the data center.   The
schedule of disk backups is as follows:
FULL DISK BACKUP:
     Backup starts on Sunday morning and runs for several hours.  All
     files are backed up.  Backups are stored offsite for 14 days and
     are retained for 35 days.
 
INCREMENTAL BACKUP:
     All files changed since the last full (base) backup  are  backed
     up.   This is called a cumulative incremental backup.  Backup is
     retained for 35 days.   Backup starts every  day  shortly  after
     midnight and runs for a few hours.
 
END-OF-SEMESTER BACKUP:
     Run  at  the  end  of  each  semester  (Fall,  Spring,  Summer).
     Identical to a full (base) backup except it is  retained  for  5
     semesters.
 
To  restore  a  VM/CMS  file,  you  must fill out a C M S - DISK
RESTORE FORM and submit it to Operations.
 Adding New DEV or PRO Libraries to PROCOPY Procedure 
 Adding New Libraries 
When a library is added that the programming staff must procopy  from
or to, there is a certain procedure that must be followed to add the
library to Computer Scheduling's Procopy Procedure.   Normally,  this
will involve  two  libraries:  A  Development  Library  (Dev)  and a
Production Library (Pro).   To  add  the  libraries  to  the  Procopy
Procedure:
 

First, the libraries must be allocated by the Data Administrator.
After the libraries have been allocated, logon to the SCHEDDEV CMS
Machine.
Enter:  ACC 220 H  to get write access to the panel library.  This
library contains all of the panels generated by Scheduling Execs.
FL ISPPCONT MACLIB H  - You will see all of the Panel Files.
In FL, Enter:  ML/N
Xedit the CONT211 - This Macro does the editing for the Procopy
panel.  Adding the libraries here allows the Scheduler to enter the new
libraries on the Procopy Screen.
**IMPORTANT**  When you enter the Xedit environment, Immediately
Enter: SERIAL OFF - If you do not, you will create a massive problem.  If
this does happen, do the following:

Get out of FL
Enter:  MACLIB DEL ISPPCONT CONT211
Enter:  MACLIB COMP ISPPCONT
Enter:  MACLIB ADD ISPPCONT
This will replace the version that was ruined, with the previous
unchanged version, and you can start again.
Assuming you entered SERIAL OFF, you may then make the additions
to CONT211:  Locate the current libraries, and add the new ones.   DO
NOT  go  past  column  71,  or  you  will  create the same problem as
forgetting to set SERIAL OFF.
Now follow the same procedure with CONT214 - This Macro is  used
by  the exec that does the Procopy.  Adding the libraries here allows
the Procopy Exec to use the new libraries.  When you  Xedit  CONT214,
the same  rules apply:  Immediately enter  SERIAL OFF, and do not go
past column 71.

 SCHEDDEV Libraries 
SCHEDDEV Panel Libraries (ISPPCONT MACLIB):
CONT600
CONT100
CONT130
CONTMSTR
CONT200
CONT210   Procopy
CONT212
CONT250   Compress
CONT260   Scratch Exec
CONT221
CONT610
CONT211   Procopy Panel Editor (Index)
CONT230
CONT110
CONT120
CONT214   Procopy (Exec)

SCHEDDEV Skeleton Libraries (ISPSCONT MACLIB):
CONT260
CONT210
CONT610
CONT110
CONT120
CONT130
CONT250

SCHEDDEV Message Libraries (ISPMCONT MACLIB):
CONT01
CONT02

 EXECs and Commands 
The EXECs and commands in this chapter are not exclusive to the
Production Support Group, but are commonly used by the Production Support
Group.


EXEC
FUNCTION 
ARCHLIB1
The ARCHLIB1 EXEC takes a member from DEV.SRCLIB and moves it to
DEV.ARCHLIB.
CMSSCAN
This CMSSCAN EXEC will search for a word, several words, or a
string in selected CMS files
GETPDS
The GETPDS EXEC retrieves a member from a PDS and saves it as  a
file in CMS.
LISTDSN
Use  the LISTDSN command to list, at your terminal, information
about the data sets or files residing on accessed OS  or  DOS  disks.
In addition, use LISTDSN to display extent or free space information
when you want to allocate space for VSAM files.
LOOKPDS
The LOOKPDS EXEC finds a member in an MVS PDS and put  you  into
an XEDIT  session  with it. From there you can browse it, change it,
file it on one of your read/write disks, or simply QUIT it.
MACLIB MAP
Lists certain information about the members in a macro  library.
Available  information  includes  member  name,  size,  and  location
relative to the beginning of the library.
MVS
The MVS EXEC sends a job to MVS for execution.
OBJLIB
This EXEC creates an MVS job to compile a member  of  DEV.SRCLIB
and copy the object code to DEV.OBJLIB.'
PDSSCAN
This  PDSSCAN  EXEC will search for a word, several words, or a
string in members of a PDS that is accessed by your ID.
PUTPDS
The PUTPDS EXEC sends a job to MVS to ADD or REPLace a member in
an existing PDS library. It is a replacement for OSUPDATE  exec,  and
any similar exec's created for special libraries.
RENCBL
The RENCBL EXEC renumbers COBOL programs.
SBCOBRA
This EXEC compiles COBOL programs from Source Bank source code.
The modules compiled by this EXEC,  including  all  copy  code,  must
reside on a Source Bank controlled library.
SBSCAN
The  SBSCAN  EXEC  will  search for a word, several words, or a
string in members of Source Bank.
SUBMIT
The SUBMIT EXEC is used to insert standard JOBPARM, JOBLIB, and
JOBCAT statements in JCL and then submit the job to MVS.

 Scanning PRO.JOBLIB and DEV.JOBLIB. 
 SCANLIB 
This procedure is used by the Production Support Group to search  for
character  strings  in  JCL  on the PRO and DEV JOBLIB. There are two
steps to the SCANLIB procedure:
 Step 1 
PRO.JOBLIB and DEV.JOBLIB are dumped to  tape  by  job  J2218M01.
This  job runs on the first Friday of each month and dumps PRO.JOBLIB
to the first file on the tape and  DEV.JOBLIB  to  the  second  file.
This  is used to create the FOCUS files use by the CROSSREF EXEC.  It
can also be used to scan PRO.JOBLIB and DEV.JOBLIB.
 
Job J2218M01 can be scheduled at  anytime  during  the  month  to
update the tape with new jobs.
 
 Step 2 
XEDIT  SCANPRO  JCL  for  PRO.JOBLIB  or SCANDEV for DEV.JOBLIB.
Locate the line that begins with:
   IF INDEX(JCL,'

Change whatever is between the single quotes to the character  string
you  wish  to  select  from  the PRO or DEV JOBLIB.  If the character
string is located in comments, they will not appear on your list.  If
you want to include comments too, delete the line:
   IF SUBSTR(JCL,1,3) = '//*' THEN DELETE;

 
You should also change the title line (enclosed in single quotes):
   TITLE 'LOOKING FOR JOBS THAT USE LOADER PROC ON PRO.JOBLIB';

 
to a meaningful title  for  your  scan  listing.    You  should  also
indicate  DEV or PRO JOBLIB, since the title is the only place on the
report you can see which library was on the tape input.
 
If you need to scan for more than one character string, copy  the
entire  STEP01  in  SCANLIB,  rename it STEP02, and change the string
between the quotes in the line that begins:
   IF INDEX(JCL,'

SCANPRO JCL, SCANDEV JCL, and T2218M01 (to update the  tape)  are
located on PSGUTIL.
 
CAUTION:  SCANPRO and SCANDEV use a SAS program that does a literal
search of the JCL.  Consider carefully the string for which you search.
 Overlay Generation Language and Page Segments. 
 Creating Overlays, Form and Page Definitions 
Overlays are images that can be printed on a page over the printed
output.  Examples are letterhead, special forms, signatures, and/or
anything that needs to be printed that is somewhat constant throughout
the printed output.  This is done with Print Services Facility software
installed on the mainframe.  Information about PSF is in Book Manager.
Enter:
 

USE BOOKS
USE BOOKSADM
BOOKS EZ2VMBWA (SHELF

 
There are several PDS libraries used for OGL.  They are:
 
DEV.OVERLIB           DEV.FDEFLIB           DEV.PDEFLIB
PRO.OVERLIB           PRO.FDEFLIB           PRO.PDEFLIB
DEV.P3829.OVERLIB     DEV.P3829.FDEFLIB     DEV.P3829.PDEFLIB
PRO.P3829.OVERLIB     PRO.P3829.FDEFLIB     PRO.P3829.PDEFLIB
DEV.PSEGLIB           PRO.PSEGLIB
DEV.P3829.PSEGLIB     PRO.P3829.PSEGLIB
DEV.SIGLIB            PRO.SIGLIB

 
The P3829 libraries are for the 3829  Page  Printer,  the  others
were  used  for the 3800 printer.  The PSEG and SIG libraries are for
page segments and electronic signatures used in overlays.  All source
code for OGL is stored in library RDSL08 of Source Bank.
 
All new overlay development is done on the 3829 printer.
 Creating an Overlay 
Some of the OGL statements required to  create  an  overlay  are:
CONTROL, OVERLAY, ORIENT, POSITION and PLACE.  Overlay source code is
stored  in Source Bank.  Use the SBANK EXEC to look at the source for
these overlays.
 
   Use these commands to create the overlay:
   CONTROL STORE SUMMARY;

The CONTROL Statement specifies the storage of  the  overlay  in  the
libraries.  STORE must be changed to REPLACE after the first time the
overlay is stored in the library.  You can use NOSTORE to compile and
get a sample of the overlay without storing it in a library.
   OVERLAY ADM001 SIZE 208 PELS 192 PELS OFFSET 0 IN 0 IN;
   OVERLAY ADM002 SIZE 8.5 IN 11 IN OFFSET 0 IN 0 IN;

 
The OVERLAY command names the overlay and specifies its size and
placement.
   ORIENT 0;

 
The ORIENT command specifies the orientation of the overlay  relative
to  the paper.  In most cases it will be 0 degrees.  This will create
a portrait oriented overlay.
   POSITION 0.5 IN 0.5 IN;

The POSITION command specifies the coordinates of a point relative to
the overlay.  This is used as a starting point to insert text, draw a
line or a box, include a page segment, or some similar operation.
See  the  PSF/MVS, PPFA/370, and OGL/370 manuals in Book Manager
for additional commands and information.
Follow these steps to compile an overlay and optionally store  it
in the DEV.P3829.OVERLIB.

Use  the  SBOGL  EXEC  to  compile  and  store  the  overlay in
DEV.P3829.OVERLIB.  This will print a sample of the overlay as well.

 Creating a FORMDEF 
FORMDEFS define the form used for output.  FORMDEF statements position
the form on the paper using OFFSET, PRESENT, and DIRECTION statements.
They can include overlays, control paper bin assignments, and set duplex
modes.  Several overlays can be used in each FORMDEF.  An example could
be to print output on a header page and then finish the output on a
continuation page.
See  the  PSF/MVS, PPFA/370, and OGL/370 manuals in Book Manager
for commands and information.
Follow these steps to compile a  FORMDEF  and  store  it  in  the
FORMDEF library.

Use  the  SBOGL  EXEC  to  compile  and  store  the  FORMDEF in
DEV.P3829.FDEFLIB.

 Creating a PAGEDEF 
PAGEDEFS define the page used for output.   PAGEDEFs are  printed
on FORMDEFs.  PAGEDEFs can define channel skips, fonts available for
use, and can be used to print text in  addition  to  the  report  and
overlay.
See  the  PSF/MVS, PPFA/370, and OGL/370 manuals in Book Manager
for commands and information.
Follow these steps to compile a  PAGEDEF  and  store  it  in  the
PAGEDEF library.

Use  the  SBOGL  EXEC  to  compile  and  store  the  PAGEDEF in
DEV.P3829.PDEFLIB.

 Using Overlays, Form and Page definitions. 
An OUTPUT statement in the JCL is needed to identify the FORMDEF and
PAGEDEF required for the printed output.  This is input before the first
EXEC card in the JCL.  The OUTPUT statement can also define the output
class, type of forms, destination, character set, burst and TRC options,
print mode, and the number of copies.  An OUTPUT= parameter is coded on
the DD statement for the report to refer back to the required OUTPUT
statement at the beginning of the job.
Here is a sample of the OUTPUT statement.
    //LASER1   OUTPUT CLASS=*,
    //             FORMS=0161,
    //             DEST=UCONNMVS,
    //             CHARS=(GT12),
    //             FCB=(8H08),
    //             BURST=NO,
    //             PRMODE=LINE,
    //             COPIES=001

And a sample of a DD statement with the OUTPUT= parameter.
    //SYSUT2   DD  SYSOUT=(,),
    //             OUTPUT=(*.LASER1)

Multiple references to OUTPUT statements are also allowed.
    //SYSUT2   DD  SYSOUT=(,),
    //             OUTPUT=(*.LASER1,*.LASER2,*.LASER3)

 
 Creating a Page Segment from an Overlay 
 Due to the sensitive nature of the State Seal and UCONN Tower that
appear on letter heads and special forms, it was decided to remove the
coding that defines these patterns and create page segments for them.
Page segments can then be "Called in" where the pattern is neccessary.
This prevents any alteration of the coding and also allows ease of update
for these  patterns.  The PSG runs these procedures from OGLSIG, which is
a group logon.  Some programmers may also have access to this account.
Other accounts may also be able to run these procedures as well.
 Creating the Overlay 
The first step in creating a Page Segment is to use OGL to define
the pattern.   The OGL statements  required  are:  CONTROL,  OVERLAY,
ORIENT, the pattern definition, POSITION and PLACE.
 
Use these commands to create the overlay:
   CONTROL STORE SUMMARY;

 
The CONTROL  Statement  specifies  the storage of the overlay in the
libraries.  STORE must be changed to REPLACE after the first time the
overlay is stored in the library.
   OVERLAY UCSEAL SIZE 208 PELS 192 PELS OFFSET 0 IN 0 IN;

 
The OVERLAY command names the overlay  and  specifies  its  size  and
placement.  The size for the Seal and Tower were taken from a compile
of an overlay that had the Seal and Tower pattern defined within.
   ORIENT 90;

 
The ORIENT command specifies the orientation of the overlay relative
to the paper.  In this case it is always 90 degrees.
 
The pattern definition for the seal or tower follows  the  ORIENT
command, followed by the POSITION and PLACE commands.
   POSITION 0 IN 0 IN;
   PLACE PATTERN SSEAL SHADE XDARK;

 
The POSITION command specifies the coordinates of a point relative to
the  overlay,  in  the  page segment it will always be 0,0.  When the
PLACE command is issued, the  printer  draws  the  graphic  with  the
pattern modifications.
 Modifying the Compiled Pattern to Create a Page Segment 
To get an understanding of what you will have to do, you can look
at the PSF Data Stream Reference manual.  Figure 40 on
page 51 shows the components of the page seqment.  Figure 41  
on  page  53  shows  a  diagram  of  the  components of an electronic
overlay.  You will have to modify the overlay changing the  Begin/End
Medium Overlay Structured fields to Begin/End Page Segment Structured
fields.    You  must  also remove any structured fields that might be
present in the overlay such as Begin/End Active Environment Group and
Page Descriptors.
 
After the  overlay  has  been  compiled  successfully,  you  must
retrieve the overlay object code from DEV.P3829.OVERLIB.  The overlay
is always prefixed by "O1".
   GETPDS O1UCSEAL DEV OVERLIB O1UCSEAL OGL A

 
XEDIT  the overlay.  Before you begin altering the overlay, enter the
following statements.   They will prevent  any  changes  in  the  Hex
values.
   SET IMAGE OFF
   SET CASE M

 
Change  the  Overlay  name  on  the  first and last lines to the Page
Segment Name.
  The  Segment  name  must  be  eight   characters
including the prefix of "S1").  To change the State Seal overlay name
to a Page Segment name
change:  "UCSEAL  "
    to:  "S1UCSEAL".

 
You  must  work in HEX to alter the command statements.  Follow these
steps to change the command statements.
 

 Enter: V H 1 30  on the XEDIT command line to set  verify
to HEX and view columns 1 through 30.
   Change   the   First   line   from   "5A0016D3A8DF"  to
"5A0016D3A85F".
The first 10 hex characters may be different  in  your  overlay,  the
"DF" is changed to "5F".
   Change   the   Last   line   from   "5A0016D3A8DF"   to
"5A0016D3A85F".
The first 10 hex characters may be different  in  your  overlay,  the
"DF" is changed to "5F".
 Delete all the lines EXCEPT:
   5A0016D38A5F.......
   5A0016D3A87B.......
   5A0020D3A77B.......
   5A002CD3A67B.......
   5A0900D3EE7B.......
   5A0010D3A97B.......
   5A0010D3A95F.......

 
 The Page Segment code is now complete.
  The  Tower Page Segment was small enough so when
you did a GETPDS you got the entire file.  The Seal however was a bit
of a problem.   In order to work with the  Seal,  you  had  to  do  a
LOOKPDS  and  FILE  the  overlay from there.   This created a problem
though, the overlay has variable length records so when you FILED  it
you  got  an  extra  four  bytes at the beginning of each record (the
record length).  So I worked with the file the way it was, then  used
the COPY command with the SPECS option to copy the overlay to another
file  taking the file from the fifth position.  This removed the four
byte record length.  The command used is a follows.
   COPY O1UCSEAL OGL Z = = A (SPECS
   at the SPECS prompt, enter:  5-5005 1

 
 Updating the Page Segment Library 
 Updating the Page Segment Library (DEV.PSEGLIB) requires breaking
down the coding into 80 character records so it can be sent to MVS.
 

 Run the PRT38XX EXEC from FILELIST or FLIST on the Page  Segment
code  you  just  created.   This will place "psegname PRT38XX" in the
reader.
 RECEIVE "psegname PRT38XX" onto your disk.
 XEDIT "psegname PRT38XX" file and delete  all  the  JCL  at  the
beginning and end of the data and file it.
  XEDIT the PSEG PRT38XX file and GET the "psegname PRT38XX" file
and place it after the //IN DD DATA statement.   Change  the  OUT  DD
statement to DEV.P3829.PSEGLIB("psegname") and file it.
 Send the PSEG PRT38XX file to MVS with the MVS EXEC.
  The page segment is now in DEV.P3829.PSEGLIB and ready to used
as a page segment.
  Using Page Segments 
 Using the Page Segments is quite  simple.    You  must  tell  the
printer  about  a  segment  in the same way you tell it what fonts to
use.  Write a separate SEGMENT command for each Seqment to  be  used.
The  Segment  commands can be grouped with your font definitions, and
need be defined only once.  The Segment command is as follows:
   SEGMENT SSEAL UCSEAL DDNAME SEGDD;
   SEGMENT TOWER UTOWER DDNAME SEGDD;

 
Placing the Segment on the overlay is the same as placing a  pattern.
You  must  have  the  POSITION  command, and the PLACE command.  When
positioning the segment a little adjustment may be needed for correct
placement, we found we had to move the segments down  .8  IN  or  190
pels.    The  PLACE command is a little different because now you are
placing a segment not a pattern.  The PLACE command looks like this:
   PLACE SEGID SSEAL;

 
For  additional  information  on  Page  Segment  use,  refer  to  the
Overlay  Generation  Language User's Guide and Reference pages
67-90, "Adding Graphics".
  Library Procedures 
A new library has been  established  to  store  all  the  OGL  source
statments  in  one central place, that is accessible by all.  We were
hesitant about putting the source code with the UCONN Tower and State
Seal out into the libraries for all to see, but with the  development
of the page seqments this can now be accomplished.
 When moving your overlay into production, use the SBCOPY EXEC and
select  the  compile option to compile and store it in the production
libraries.
 Glossary 

AUTODOC
Automatic JCL generator system.
DEV.ARCHOLD
Development library where programs are placed by J8888B when they are
retrieved from archive tape.
DEV.AUTOFLAG
Development library where a flag is stored that keeps track of job
updates.
DEV.AUTOJOB
Development library where generated JCL is stored before being moved
into production.
DEV.AUTOMSG
Development library where generated MSGLIB is stored before being
moved into production.
D2230F00
D2230F00 is the Focus Database that contains jobs that are being
created or revised.  When you the Programmers are working in AUTODOC,
they are accessing this Database.
D2230F01
D2230F01 is the Focus Database that contains jobs that are in
Production.
FDR
Short for Fast Dump Restore.  A software package used to backup
and restore data.
FOCADM4 CMS Machine
The Focus Synchronous user CMS machine that allows multiple users to
enter information to AUTODOC databases at the same time.
PASSID DATA
This is a CMS File on the E disk that controls an AUTODOC user's
access to AUTODOC.  All AUTODOC user's CMS Machine names must be included
in this file.
PDUC1 CMS Machine
CMS machine with batch update capability to AUTODOC Focus databases.
PRO1
An EXEC on PDUC1 that generates JCL and a MSGLIB that is placed in
development libraries to be moved into production.  Also moves jobs
information from Test AUTODOC FOCUS Database to Production AUTODOC FOCUS
Database.
PROCOPY
An EXEC by Scheduling that moves generated JCL and MSGLIB from
development libraries to production libraries.
Runbook
Used by Scheduling to supply information about the execution of a
production job. Includes step restart instructions.
SBCOPY
An EXEC that promotes Source Bank code and compiles and stores object
code in the DEV. or PRO. libraries.
SCHEDULING
Office at the Computer Center that schedules production jobs.
Sync Machine
Any Focus synchronous user CMS machine that allows multiple users to
enter information to a FOCUS database at the same time.
Turnover Form
Form filled out by a programmer that requests a job be moved into
production.
VSAM Table File
Used by AUTODOC to perform edits on information entered by the
programming staff and to insert code into generated JCL.
VSAMTEST FOCEXEC
This is Focus Exec that is on the E disk.  It can only be changed by
the Focus Administrator.  This exec control's an AUTODOC user's access to
the VSAM Table File.








UConn Web

UCC

Data Administration

UCC Index