DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: GENERAL

FOR ANY OPERATIONAL SYSTEM IT IS ESSENTIAL THAT THERE BE A CENTRAL COLLECTION OF INFORMATION WHICH ACCURATELY DESCRIBES THE SYSTEM AS IT IS CURRENTLY RUNNING. TO ACCOMPLISH THIS NEED EACH SYSTEM MUST HAVE PREPARED A SYSTEMS MANUAL. THIS MANUAL WILL BE KEPT IN A CENTRAL LOCATION FOR THE USE OF THE SYSTEMS AND PROGRAMMING STAFF AND MUST BE UPDATED WITH ALL CHANGES.

NOTEBOOKS FOR THE ABOVE HAVE BEEN PREPARED WHICH WILL REQUIRE ONLY THAT YOU INSERT THE REQUIRED DOCUMENTATION. THESE MAY BE OBTAINED FROM THE STANDARDS AND PROCEDURES DEPARTMENT.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.01.01

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: CONTENT

ALL SYSTEMS MANUALS MUST INCLUDE THE BELOW LISTED ITEMS. IT IS REALIZED, HOWEVER, THAT EACH SYSTEM IS UNIQUE AND THE ANALYST SHOULD MAKE ANY ADDITIONS HE NEEDS TO FULLY DOCUMENT THE SYSTEM.
 

*THESE ITEMS WILL NOT BE REQUIRED FOR EXISTING SYSTEMS.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.02.01

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: ANALYSIS AND FEASIBILITY STUDIES

PART OF THE SYSTEM DOCUMENTATION SHOULD BE THE ANALYSIS AND FEASIBILITY STUDY. WHILE THIS IS AN AREA WHERE FLEXIBILITY IS DESIRABLE, THE FOLLOWING GUIDELINES HAVE BEEN ESTABLISHED.

1. THE PROBLEM TO BE SOLVED OR NEEDS TO BE FULFILLED SHOULD BE DEFINED FROM THE USER'S POINT OF VIEW.

2. THERE SHOULD BE A VERY GENERAL DESCRIPTION OF INPUTS AND OUTPUTS TO THE SYSTEM. INCLUDED WOULD BE INPUT FILES AND USER SUPPLIED DATA. THE END PRODUCT OF THE SYSTEM SHOULD BE DESCRIBED, AND REFERENCE SHOULD BE MADE AS TO WHAT USE IS MADE OF THE INFORMATION PRODUCED.

3. A GENERAL DESCRIPTION IN USER LANGUAGE OF THE INFORMATION FLOW WITHIN THE SYSTEM SHOULD BE PRESENT.

4. INTER-RELATIONSHIPS BETWEEN THIS SYSTEM AND OTHER MANUAL AND COMPUTER SYSTEMS SHOULD BE MENTIONED.

5. A SECTION OF SPECIAL COMMENTS SHOULD BE INCLUDED WHENEVER COMPLEX PROCESSING OR SCHEDULING CONSIDERATIONS ARISE.

6. ATTACHED TO THIS SHOULD BE A VERY GENERALIZED SYSTEMS FLOW CHART SHOWING THE ENTIRE SYSTEM WITH BOTH ITS USER DEPARTMENT AND COMPUTER CENTER ASPECTS.

7. ESTIMATES OF TIME AND COST NECESSARY TO COMPLETE THE PROJECT SHOULD APPEAR.

THE IMPORTANT POINT TO REMEMBER IS THIS PART OF THE DOCUMENTATION SHOULD BE BRIEF, CONCISE, AND ORIENTED TOWARD THE USER DEPARTMENT. IT SHOULD BE FREE OF COMPUTER TERMINOLOGY, FILE DSN'S, AND THE LIKE.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.03.01

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: FILE LAYOUTS

THIS AREA MUST CONTAIN LAYOUTS OF ALL PERMANENT DATA SETS IN THE SYSTEM. IT IS EXTREMELY IMPORTANT THAT THESE LAYOUTS BE KEPT ACCURATE AS THIS WILL BE THE MASTER FILE FOR THE SYSTEM. ANY COPIES FILED ELSEWHERE WILL BE REFERENCED ITEMS ONLY.

FOLLOWING ARE SAMPLES OF THE FORMS TO BE USED IN PREPARING ALL LAYOUTS. PLEASE NOTE THAT THE PRINTER LAYOUT FORM INCLUDES CARRIAGE CONTROL TAPE SPECIFICATIONS. THIS MUST BE COMPLETED UNLESS THE STANDARD SIX OR EIGHT LINE PER INCH CARRIAGE CONTROL TAPE IS TO BE USED.

ALL DATA SETS TO WHICH A RECORD LAYOUT APPLIES, MUST BE INDICATED BY DATA SET NAME UNDER "REMARKS"

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.04.01

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: PROGRAM NARRATIVES

THE PROGRAM NARRATIVE CAN BE VIEWED AS THE DOCUMENTATION OF A PROGRAM OR SUBROUTINE THAT HAS NOT YET BEEN CODED. THE NARRATIVE'S LENGTH IS DICTATED BY THE PROGRAM'S SIZE AND COMPLEXITY; THE LEVEL OF DETAIL SHOULD VARY ACCORDINGLY.

THE PROGRAM NARRATIVE SHOULD INCLUDE THE FOLLOWING SECTIONS:

A. PURPOSE AND SCOPE - THIS SECTION ANSWERS THE QUESTION, WHY WAS IT REQUIRED? IT SHOULD DEFINE ITS SCOPE OF CAPABILITY, AND NOT TO BE NEGLECTED - ITS LIMITATIONS.

B. DATA USED - SPECIFY THE DATA ELEMENTS THIS PROGRAM USES, AND IF IT IS AN UPDATE PROGRAM, THE EDITING TO BE PERFORMED ON EACH ITEM. SPECIFICATION SHOULD ALSO BE MADE TO THE DATA SET NAME (DSN) OR DATA BASE NAME FOR ALL INPUT AND OUTPUT FILES.

C. REPORTS PRODUCED - SPECIFY ALL REPORTS COMING FROM THIS PROGRAM AND HOW THEY WILL BE USED.

D. PROGRAM OPTIONS - DISCUSS ALL EXTERNALLY CONTROLLABLE OPTIONS, E.G., OPTIONS EXERCISED THROUGH CONTROL CARD OR ONLINE TERMINAL.

E. PROCESS - THIS SECTION IS NORMALLY THE LARGEST SECTION OF THE NARRATIVE. IT DESCRIBES HOW THE PROGRAM CONVERTS THE INPUT INTO THE DESIRED OUTPUT. IT DESCRIBES THE FUNCTIONS TO BE PERFORMED, NOT EACH DETAIL OF THE PROGRAM LOGIC. PARTICULAR EMPHASIS, HOWEVER, SHOULD BE GIVEN TO SPECIFIC CALCULATIONS AND HOW PROGRAM DECISIONS ARE MADE. THERE SHOULD ALSO BE A REFERENCE, BY JOB NUMBER, TO THE JOBS TO WHICH THIS PROGRAM RELATES. IN THE CASE OF SUBROUTINES, THE FORMAT OF THE CALL SHOULD BE GIVEN WITH A DESCRIPTION OF EACH OF ITS ARGUMENTS.

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: USER INSTRUCTIONS

THESE ARE GENERAL GUIDELINES. THE WRITER MUST BE FLEXIBLE ENOUGH TO ADAPT THEM TO THE PARTICULAR SYSTEM UNDER CONSIDERATION.

I. CONTENTS
A. OVERVIEW OF SYSTEM
    1. PURPOSE
    2. CAPABILITIES
    3. WHEN TO USE
    4. LIMITATIONS

B. GENERAL PROCEDURES
1. RESPONSIBILITIES AND ACTIONS OF THE USER DEPARTMENT
    A. WHAT MACHINES, SUCH AS CRT'S, WILL BE USED, IF ANY.
    B. JOB REQUESTS TO BE MADE TO COMPUTER SERVICES, IF NEEDED.
    C. NATURE OF INPUT DOCUMENTS TO BE CODED, IF ANY.
2. RESPONSIBILITIES AND ACTIONS OF COMPUTER SERVICES
    A. FILES MAINTAINED
    B. TRANSACTIONS PROCESSED
    C. REPORTS PRINTED AND DISTRIBUTED

C. PROCEDURE DETAILS - FOR EACH TYPE OF PROCESSING IN SYSTEM
1. DETAILED DESCRIPTION OF MACHINES USED, IF APPLICABLE
2. INITIATING PROCESSING
    A. SIGNING ON MACHINES AND OBTAINING FORMATS IF APPLICABLE.
    B. CODING JOB REQUEST FORMS, IF APPLICABLE, WITH SAMPLE FORMS.
3. OPTIONS OF PROGRAMS INVOLVED
    A. PURPOSE OF OPTION
    B. WHEN TO USE OPTION
    C. HOW TO SPECIFY OPTION
4. HOW TO ACCESS RECORDS
    A. TERMINAL RETRIEVAL PROCEDURES, IF APPLICABLE, WITH SCREEN OR TYPED
    FORMATS DRAWN OUT.
    B. CODING REQUEST FORMS IF APPLICABLE, WITH SAMPLE FORMS.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.05.02

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: USER INSTRUCTIONS

5. FILE UPDATE PROCEDURES - ADDING, CHANGING, OR DELETING RECORDS
    A. CODING MACHINE FORMATS, IF APPLICABLE, WITH SAMPLE FORMATS.
    B. CODING INPUT FORMS, IF APPLICABLE, WITH SAMPLE FORMS.
6. RESPONSE IF ALL GOES WELL
    A. RESPONSE IN CONVERSATIONAL SYSTEMS.
    B. TRANSACTION CODES ON PRINTED REPORTS RETURNED TO USER, IF ANY.

D. ERROR MESSAGES
1. WHAT A MESSAGE REALLY MEANS
2. POSSIBLE CAUSES OF ERROR
3. HOW TO CORRECT ERROR - IMMEDIATELY OR BY RESUBMITTING JOB.

E. MACHINE MALFUNCTIONS
1. WHAT IS AFFECTED IF COMPUTER GOES DOWN.
2. RECOGNIZING TERMINAL MALFUNCTIONS, IF APPLICABLE.
3. WHEN TO CONTACT COMPUTER SERVICES

F. ERRORS THE COMPUTER WILL NOT CATCH
1. TYPES AND LIMITATIONS OF INPUT EDITING
2. HOW TO CHECK DATA TO CATCH ERRORS.
3. HOW TO CORRECT ERRONEOUS DATA.

II. PRESENTATION

A. TONE - MOST USERS AWED BY THE COMPUTER ALREADY
1. INCLUDE ONLY WHAT CONCERNS USER - LEAVE THE COMPUTER A BLACK BOX.
2. DON'T TRY TO IMPRESS USER - WILL ONLY INTIMIDATE USER INSTEAD.

B. ORGANIZATION
1. DETERMINE WHAT TYPES OF USERS INVOLVED AND ON WHAT LEVELS.
2. USE 'MANUAL WITHIN MANUAL CONSTRUCTION.
    A. ORGANIZE BY LEVEL OF FUNCTION, AS IN I., A., B., AND C. ABOVE.
    B. PROVIDE COOKBOOK FOR DAY-TO-DAY USE.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.2.05.03

DATE: 11/06/85

SECTION: SYSTEMS MANUAL REVISED:

SUBJECT: USER INSTRUCTIONS

C. ACTUAL WRITING
1. AVOID COMPUTER TERMS AS COMPLETELY AS POSSIBLE.
    A. IF SUCH A TERM IS UNAVOIDABLE, MAKE SURE IT IS CLEARLY EXPLAINED.
    B. CHECK WHAT YOU WRITE - ANY FREQUENTLY RECURRING WORD IS SUSPECT.
2. AVOID TENDENCY TO ABBREVIATE.
    A. EXPLAIN ANY ABBREVIATIONS ON FORMS OR FORMATS.
    B. GIVE SUGGESTIONS TO USER WHERE ABBREVI ATION MAY BE NECESSARY.
3. INDICATE WHEN AND HOW MACHINES ARE USED, BUTTON BY BUTTON, IF APPLICABLE.
4. FIELDS - A SPECIAL INTRODUCTION TO THIS CONCEPT IS ESSENTIAL.
    A. EXPLAIN HOW FIELDS ARE DEFINED TO COMPUTER BY LENGTH AND PERMISSIBLE
    CONTENTS.
    B. INDICATE WHERE PADDING WITH BLANKS OR ZEROES NECESSARY.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.01.01

DATE: 11/06/85

SECTION: DATA MANAGEMENT SYSTEMS REVISED:

SUBJECT: GENERAL

THE COMPUTER SERVICES DIVISION IS CURRENTLY USING IBM'S INFORMATION MANAGEMENT SYSTEM (IMS) AS ITS DATA BASE MANAGEMENT SYSTEM. THE SYSTEM ALLOWS GREATLY IMPROVED STORAGE EFFICIENCY AND PROGRAMMING EASE. HOWEVER, TO REALIZE ALL OF THE BENEFITS, IT IS NECESSARY THAT PROGRAMMERS AND ANALYSTS STRICTLY ADHERE TO STANDARD PROCEDURES.

INFORMATION CONCERNING SPECIFIC USES OF IMS CAN BE OBTAINED FROM THE APPROPRIATE IBM MANUALS.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.02.01

DATE: 11/06/85

SECTION: DATA MANAGEMENT SYSTEMS REVISED: 02/22/96

SUBJECT: DATA BASE DOCUMENTATION

ALL NON-GSAM DATA BASES MUST HAVE A PANVALET "INCLUDE" FOR EACH SEGMENT. EACH "INCLUDE" MUST DESCRIBE THE SEGMENT AND ALL FIELDS WITHIN THE SEGMENT. PLEASE SEE THE NEXT CHAPTER FOR AN EXPLANATION OF WHAT IS CONTAINED IN A PANVALET "INCLUDE". GSAM DATABASES MUST HAVE A RECORD LAYOUT WORKSHEET AND/OR A PRINTER SPACING CHART.

A DATA BASE THAT IS BEING SUBMITTED TO THE STANDARDS AND PROCEDURES AREA FOR THE FIRST TIME MUST BE IDENTIFIED AS SUCH BY USING FORM STDS 7.2.11.01. THIS FORM MUST BE FILLED OUT FOR THE PRODUCTION DATA BASE ONLY. A HIERARCHICAL DIAGRAM MUST BE SUPPLIED AT THIS TIME. ALL PANVALET "INCLUDES" FOR THE DATA BASE MUST BE PRESENTED AT THIS TIME ALSO. THE DATA BASE ADMINISTRATION GROUP WILL USE THIS INFORMATION TO ISSUE THE SYSTEM GENERATION COMMANDS TO DEFINE BOTH TEST AND PRODUCTION DATA BASES TO IMS.

WITH THESE ITEMS COMPLETE, THE REQUIRED DBD WILL BE CODED AND PLACED ON IMSVS.DBDLIB AND THE REQUESTOR WILL RECEIVE NOTIFICATION WHEN THE WORK IS COMPLETE.

IN THE CASE OF A LOGICAL DBD WHERE THE LOGICAL DATA BASE WILL BE COMPOSED OF EXISTING DATA BASE SEGMENTS, THE PROGRAMMER NEED ONLY SUBMIT A HIERARCHICAL DIAGRAM WHICH IDENTIFIES THE DESIRED SEGMENTS. THE LOGICAL DATA BASE MUST HAVE A UNIQUE DATA BASE NAME AND SEGMENT NAMES;

THESE LOGICAL SEGMENT NAMES SHOULD BE SHOWN ON THE HIERARCHICAL DIAGRAM ALONG WITH THE PHYSICAL SOURCE SEGMENT NAMES COMPOSING THEM. HOWEVER, THE FIELDS MAY KEEP THE SAME NAMES THEY CARRY IN THE PHYSICAL DATA BASE.

A DATA BASE THAT IS BEING SUBMITTED TO THE STANDARDS AND PROCEDURES AREA FOR ALTERATION MUST BE IDENTIFIED AS SUCH BY USING FORM STDS 7.2.11.01. IF A SEGMENT IS BEING ADDED, PROVIDE A PRE-EXISTING HIERARCHICAL DIAGRAM WITH THE NEW SEGMENT SKETCHED IN AT THE PROPER LOCATION. A PANVALET "INCLUDE" FOR THE NEW OR ALTERED SEGMENT MUST ALSO BE PROVIDED. THIS PROCEDURE MUST BE PERFORMED FIRST FOR THE TEST DATABASE, AND THEN AFTER TESTING, FOR THE PRODUCTION DATABASE.

ALL DOCUMENTATION SUBMITTED TO THE DBA GROUP FOR PURPOSES OF ADDING OR CHANGING A DATABASE IS PLACED IN THE RECYCLING BIN. NOTHING IS RETURNED TO THE PROGRAMMING STAFF.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.02.02

DATE: 05/15/74

SECTION: DATA MANAGEMENT SYSTEMS REVISED: 02/22/96

SUBJECT: DATA BASE DOCUMENTATION

THE DATA ELEMENT DICTIONARY IS NO LONGER REQUIRED. THE FOLLOWING FORMS ARE NOW OBSOLETE, STDS 7.2.07.01, STDS 7.2.26.01, AND STDS 7.2.27.01.

WITH THE ELIMINATION OF THE DATA ELEMENT DICTIONARY THE FOLLOWING INFORMATION MUST APPEAR IN THE SEGMENT "INCLUDE":

1. SEGMENT NAME. REFER TO STDS 2.3.08.01

2. DESCRIPTION OF THE SEGMENT.

3. ACCESS METHOD (USUALLY HIDAM OR HDAM). ROOT SEGMENT ONLY.

4. ACCOUNT NUMBER TO BE BILLED. ROOT SEGMENT ONLY.

5. SEGMENT'S PARENT NAME OR THE WORDS 'ROOT SEGMENT'.

6. LENGTH IN BYTES OF THE SEGMENT.

7. STARTING POSITION OF THE KEY, KEY LENGTH, AND WHETHER IT IS UNIQUE OR MULTIPLE. IF A KEY DOES NOT EXIST OR THE KEY IS MULTIPLE, STATE WHETHER THE SEGMENT SHOULD BE INSERTED FIRST, LAST, OR HERE.

8. FREQUENCY - FOR THE ROOT SEGMENT, SHOW THE MAXIMUM NUMBER OF ROOTS THAT MAY EXIST IN THE FIRST CALENDAR YEAR. FOR CHILD SEGMENTS, THIS WOULD BE THE AVERAGE NUMBER OF OCCURENCES UNDER ONE PHYSICAL PARENT.

9. LOGICAL RELATIONSHIPS (IF THEY EXIST) - INDICATE WHETHER THE SEGMENT IS A LOGICAL CHILD OR LOGICAL PARENT, THE NAME OF THE SEGMENT IT IS RELATED TO AND THE DATABASE THE RELATED SEGMENT BELONGS TO. INDICATE RULES FOR INSERTING, DELETEING, AND REPLACING LOGICAL SEGMENTS. LOGICAL RELATIONSHIPS WILL BE DERIVED WITH THE HELP FROM DBA.

10. POINTERS - NO TWIN. THIS WILL INDICATE THAT A SEGMENT CAN ONLY OCCUR ONCE FOR A PARTICULAR PARENT SEGMENT.

- CHILD POINTERS, TWIN POINTERS, AND LOGICAL POINTERS DEEMED SIGNIFICANT TO MENTION. (THESE POINTERS WILL BE DERIVED WITH THE HELP FROM DBA).

11. SECONDARY INDEXES (IF THEY EXIST) - ALL SECONDARY INDEX INFORMATION MUST APPEAR IN THE ROOT SEGMENT. INFORMATION WOULD BE THE SOURCE SEGMENT, TARGET SEGMENT, SEARCH FIELDS, SUBSEQUENCE FIELDS AND ANY OTHER FIELDS THAT WOULD MAKE UP A SECONDARY INDEX.

12. MAINTENANCE PERFORMED. KEEP A RECORD OF THE CHANGES THAT WERE MADE TO THE SEGMENT.

13. FIELD NAME. REFER TO STDS 2.3.09.01.

14. STARTING POSITION OF THE FIELD.

15. ENDING POSITION OF THE FIELD.

16. DESCRIPTION OF THE FIELD.

17. INDICATION IF THE FIELD IS A SEGMENT SEARCH ARGUMENT (SSA).

18. CODES/EDITING AND RECORDING INSTRUCTIONS.

AN EXAMPLE OF A SEGMENT "INCLUDE" IS ON PAGE STDS 4.3.02.03

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.02.03

DATE: 02/22/96

SECTION: DATA MANAGEMENT SYSTEMS REVISED:

SUBJECT: DATA BASE DOCUMENTATION

HERE IS AN EXAMPLE OF A PANVALET "INCLUDE" DESCRIBING A DATA BASE SEGMENT (NOTICE THAT THE ACCOUNT START DATE (NEXT PAGE) DOES NOT HAVE DATA BASE FIELDS NAMES FOR ITS ELEMENTARY ITEMS):

*****************************************************************
 

** F7500000 **

** COMMUNICATIONS SERVICES BILLING **

** HIDAM **

** ACCOUNT NUMBER - F7500010 **

** ROOT SEGMENT **

** LENGTH - 89 BYTES **

** KEY LENGTH - 8 BYTES **

** KEY STARTS IN POSITION 1 **

** KEY IS UNIQUE **

** FREQUENCY = 19000 **

** NO LOGICAL RELATIONSHIPS **

** SECONDARY INDEX: **

** SOURCE = F7500000 **

** TARGET = F7500000 **

** SEARCH = F7500020 **

** SUBSEQ = F7500SEQ **

** MAINTENANCE PERFORMED: **

** DATE: 02/02/96 PERFORMED BY: NATURE OF THE MAINTENANCE EXPANDED BY ALL DATES FOR Y2K **
*****************************************************************

05 F7500000.

DB NAME BEG END

F7500SEQ 001 008 SSA

* AUTHORIZATION CODE F7500010 001 007 SSA

15 F7500-ACODE PIC 9(07).

* RECORD TYPE F7500015 008 008 SSA

* 'S' = STUDENT 'B' = BELL CREDIT CARD

* 'A' = ADMIN 'D' = DIRM CREDIT CARD

* ' ' = DUMMY ROOT 'V' = MCI/VNET OFF CAMPUS LD

* 'M' = MCI/VNET CALLING CARD

15 F7500-REC-TYPE PIC X(01).

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.02.04

DATE: 02/22/96

SECTION: DATA MANAGEMENT SYSTEMS REVISED:

SUBJECT: DATA BASE DOCUMENTATION

 * SSN FOR STUDENTS F7500020 009 017 SSA

* DEPT-FUND FOR ADMIN

10 F7500-SSN PIC X(09).

10 F7500-DEPT-FUND REDEFINES F7500-SSN.

15 F7500-DEPT PIC X(05).

15 F7500-FUND PIC X(04).

* ACCOUNT START DATE F7500025 018 025

10 F7500-START-DATE-CCYYMMDD.

15 F7500-START-CC PIC 9(02).

15 F7500-START-DATE.

20 F7500-START-YY PIC 9(02).

20 F7500-START-MM PIC 9(02).

20 F7500-START-DD PIC 9(02).

DATE: 11/06/85

SECTION: DATA MANAGEMENT SYSTEMS REVISED: 02/22/96

SUBJECT: DATA BASE DOCUMENTATION

EACH IMS APPLICATION PROGRAM USES A PROGRAM SPECIFICATION BLOCK (PSB) WHICH DESCRIBED HOW THE PROGRAM USES ONE OR MORE DATA BASES OR LOGICAL TERMINALS.

PROGRAMMERS NEEDING PSB'S SHOULD FILL OUT A PSB REQUEST FORM AND AN IMS GEN FORM. TEST PSB AND ALL IMSGEN FORMS ARE PROCESSED BY THE IMS AREA COORDINATORS. PRODUCTION PSB AND IMSGEN REQUESTS ARE SUBMITTED TO THE STANDARDS DEPARTMENT AS THE JOB IS BEING TURNED OVER. ONLINE TEST APPLICATIONS WILL HAVE PSB NUMBERS IDENTICAL TO THE PROGRAM IDENTIFICATION WITH THE EXCEPTION OF A 'C' IN THE 8TH POSITION DESIGNATING TEST. BMP AND BATCH JOBS WILL HAVE PSB NAMES ASSIGNED BY THE IMS AREA COORDINATORS FROM THEIR POOL OF TEST PSB NAMES. WHEN TESTING IS COMPLETE BATCH, BMP, AND ONLINE APPLICATIONS WILL USE PRODUCTION PSB NAMES, AND SUCH NAMES WILL BE IDENTICAL TO THE PROGRAM IDENTIFICATION. ALL PSB'S WILL BE PLACED ON IMSVS.PSBLIB.

THE NECESSARY REQUEST FORMS FOR DBD'S, PSB'S AND IMSGEN'S ARE AVAILABLE FROM THE STANDARDS DEPARTMENT.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.3.03.01

DATE: 05/15/74

SECTION: DATA MANAGEMENT SYSTEMS REVISED: 07/10/90

SUBJECT: HIERARCHICAL DIAGRAMS

HIERARCHICAL DIAGRAMS WILL BE CONSTRUCTED AS PER THE IMS/VS APPLICATION PROGRAMMING MANUAL. COMPUTER SERVICES DIVISION REQUIRES THAT THE FOLLOWING INFORMATION BE CONTAINED IN EACH SEGMENT BLOCK OF THE HIERARCHICAL DIAGRAM.

- SEGMENT NAME (REFER TO STDS 2.3.08.01)
- NUMBER OF BYTES IN SEGMENT
- KEY LENGTH
- FREQUENCY OF OCCURRENCE UNDER ONE PHYSICAL PARENT. THIS FIGURE SHOULD BE THE AVERAGE NUMBER OF OCCURRENCES OF A SEGMENT UNDER ITS PARENT AND NOT A MINIMUM OR MAXIMUM NUMBER OF OCCURRENCES.
- LOGICAL RELATIONSHIP (IF PRESENT)
THE PHYSICAL PARENT, LOGICAL PARENT AND/OR LOGICAL CHILD SHOULD BE INDICATED ON THE HIERARCHICAL DIAGRAM FOR ANY ACTIVE LOGICAL RELATIONSHIPS. ANY POINTERS REQUESTED OTHER THAN THE ONES NORMALLY REQUIRED TO DEFINE THE LOGICAL RELATIONSHIPS SHOULD BE INDICATED IN THE SEGMENT BLOCK OF THE HEIRARCHICAL DIAGRAM.
- RULES
ABBREVIATION THAT DENOTES THE RULES FOR INSERTION, DELETION AND REPLACEMENT FOR ANY SEGMENTS THAT ARE DEFINED AS A LOGICAL CHILD, LOGICAL PARENT OR PHYSICAL PARENT.

CHAPTER: SYSTEMS ANALYSIS NUMBER: 4.4.01.01

DATE: 11/06/85

SECTION: FLOWCHARTING REVISED: 07/10/96

SUBJECT: GENERAL

HAND DRAWN FLOWCHARTS ARE NO LONGER REQUIRED AS PART OF THE JOB TURNOVER PROCESS. YOU NOW HAVE THE ABILITY TO PRODUCE A FLOWCHART DIRECTLY FROM THE JCL. THIS HAS BEEN MADE POSSIBLE WITH A NEW PRODUCT CALLED DOCU/TEXT.

TO MAKE THE FLOWCHART AS COMPREHENSIVE AS POSSIBLE THE JCL MUST BE PROCESSED BY DOCU/TEXT. DOCU/TEXT PROVIDES A WAY FOR YOU TO STORE DESCRIPTIVE INFORMATION FOR EACH JOB, PROGRAM, AND FILE.

REPORT DISTRIBUTION NUMBERS (RDN FOR SHORT) MUST NOW BE ENTERED AS A COMMENT IN THE JCL (ON THE DD STATEMENT THAT IDENTIFIES THE REPORT). DOCU/TEXT WILL PLACE THE RDN BELOW THE REPORT SYMBOL IN THE FLOWCHART. DESCRIPTIONS OF IMS PROGRAMS MUST ALSO BE ENTERED IN THE JCL (AS A COMMENT ON THE EXEC STATEMENT). DOCU/TEXT WILL PLACE THIS DESCRIPTION TO THE LEFT OF THE STEP BEING EXECUTED.

TO RECAP, HERE IS A LIST OF HOW EACH ITEM IN A JOB SHOULD BE HANDLED BY OCU/TEXT:

JOBS - USE THE DOCU/TEXT SHORT DESCRIPTION FACILITY.

IMS PROGRAMS - PLACE THE DESCRIPTION ON THE EXEC STATEMENT IN THE JCL, AND OPTIONALLY AS A SHORT DESCRIPTION IN DOCU/TEXT.

NON-IMS PGMS - USE THE DOCU/TEXT SHORT DESCRIPTION FACILITY.

FILES - USE THE DOCU/TEXT SHORT DESCRIPTION FACILITY.

NOTE: IF A DATASET IS A GDG DO NOT USE THE PROMPTER, INSTEAD, USE THE INDIVIDUAL ENTRIES PANEL WITHOUT THE '+' DESIGNATION.

REPORTS - PLACE THE REPORT DISTRIBUTION NUMBER ON THE APPROPRIATE DD STATEMENT IN THE JCL.

ONCE A JOB, PROGRAM, OR FILE HAS BEEN PROCESSED BY DOCU/TEXT YOU WILL NEVER HAVE TO ENTER THE DESCRIPTION AGAIN, UNLESS YOU WANT TO CHANGE IT. AS FAR AS DELETIONS ARE CONCERNED, IF A JOB IS UPDATED (PROGRAMS AND/OR FILES REMOVED) OR DELETED DOCU/TEXT WILL TAKE THE APPROPRIATE ACTION TO KEEP THE SDF/OLX FILE MAINTAINED PROPERLY.

AT YOUR DISCRETION YOU MAY PRINT A FLOWCHART USING THE DOCU/TEXT CREATE ANALYSIS DOCUMENTS PANEL.