PL I Standards

PL/1 Programming Standards
Document Summary:.........................................................................................................4 TABLE OF CONTENTS BREAKDOWN.........................................................................5 INTRODUCTION............................................................................10 PROJECT STANDARDS.................................................................................................11

NAMING CONVENTIONS.......................................................................................................11
DB2 NAMING CONVENTIONS..............................................................................................................11 DB2 Data Structures .............................................................................................................................11 DB2 Object Names ...............................................................................................................................12 IMS NAMING CONVENTIONS..............................................................................................................14 IMS-MFS Naming Conventions ...........................................................................................................14 Transaction Codes..................................................................................................................................16 Program Status Block Names................................................................................................................17 MVS NAMING CONVENTIONS.............................................................................................................18 Job Names..............................................................................................................................................18 Application Program Names..................................................................................................................19 Dataset Names........................................................................................................................................21 Report Names.........................................................................................................................................22
DESIGN STANDARDS..............................................................................................................23
SCREEN DESIGN STANDARDS............................................................................................................23 Screen Formats ......................................................................................................................................23 Error Processing ....................................................................................................................................25 Cursor Positioning .................................................................................................................................26 PF Key Usage ........................................................................................................................................27 REPORT LAYOUT STANDARDS..........................................................................................................28 Batch Report Layout .............................................................................................................................28
PROGRAMMING STANDARDS.............................................................................................31
PL/1 PROGRAMMING STANDARDS....................................................................................................31 Program Style ........................................................................................................................................31 Variable Names and Usage ...................................................................................................................32 Procedure and INCLUDE Members .....................................................................................................33 On-line Processing Standards ...............................................................................................................34 DB2 Considerations ..............................................................................................................................36 Program Documentation .......................................................................................................................38 Program Skeletons ................................................................................................................................39 Error Message Numbers ........................................................................................................................40
REVIEW STANDARDS............................................................................................................41
Walkthrough and Peer Reviews ............................................................................................................41 Lifecycle Reviews .................................................................................................................................42
PROCEDURES AND TECHNICAL FACILITIES........................................................43

TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT................................43
Champ ....................................................................................................................................................43 TSO/SPF ................................................................................................................................................44 DB2.............................................................................................................................................................45 DB2I ......................................................................................................................................................45 DB2/QMF ..............................................................................................................................................46 IMS.............................................................................................................................................................47 IMS - BTS .............................................................................................................................................47 IMS - DC ...............................................................................................................................................48 IMS - MFS .............................................................................................................................................49 PRODUCTIVITY TOOLS.........................................................................................................................50
Page: 2
NASTEC CASE/2000 DesignAid ........................................................................................................50 Easytrieve Plus ......................................................................................................................................51
PROJECT MANAGEMENT AND PLANNING.....................................................................52

ARTEMIS Project Tracking .................................................................................................................52
SYSTEM DESIGN METHODOLOGY....................................................................................53

STRUCTURED ANALYSIS AND DESIGN............................................................................................53 Data Flow Diagrams..............................................................................................................................53 Structure Charts......................................................................................................................................54 Pseudocode.............................................................................................................................................55 Process Specifications............................................................................................................................56 Data Modeling........................................................................................................................................58
TESTING PROCEDURES........................................................................................................59
Unit Testing Procedures.........................................................................................................................59 Change Control Request (CCR).............................................................................................................71
PRINTING..................................................................................................................................72
Print Destinations...................................................................................................................................72 1. SCROLLING -.....................................................................................................................................73 2. REQUIRED FIELDS -.........................................................................................................................75 3. SCREEN NAVIGATION -..................................................................................................................75 4. ACTION CODES -..............................................................................................................................75 5. UPDATE -............................................................................................................................................75 6. PFKEY -...............................................................................................................................................77 7. HELP -..................................................................................................................................................77 8. INQUIRY -...........................................................................................................................................77 9. PRINT -................................................................................................................................................79 10. SELECTION -....................................................................................................................................81 11. EDITING -.........................................................................................................................................81 12. DELETE -..........................................................................................................................................81 13. CHANGE -.........................................................................................................................................82 14. SCREEN CODE -..............................................................................................................................83 15. TRANSACTION DATA BASE -......................................................................................................83 16. TEST PLAN -....................................................................................................................................83 17. JCL -...................................................................................................................................................83 18. BATCH -............................................................................................................................................84 19. CHECKPOINT RESTART -.............................................................................................................85 20. MFS-...................................................................................................................................................85 21. ONLINE -...........................................................................................................................................85 22. SECURITY -......................................................................................................................................85
Page: 3
Document Summary:
Document: PDS STANDARDS & PROCEDURES MANUAL Author: Addressee: Operator: Creation Date: 09/09/1987 Modification Date: 10/05/1987 Identification key words:
Comments: Changed all 'P _D _S _ STEP' on 07/31/91 - PDSJCDB.
_S _T _E _P _' etc to 'PDS
Page: 4
TABLE OF CONTENTS BREAKDOWN

i. A. INTRODUCTION PROJECT STANDARDS 1.0 NAMING CONVENTIONS 1.1 DB2 Naming Conventions 1.1.1 DB2 Data Structures 1.1.2 DB2 Object Names 1.2 IMS Naming Conventions 1.2.1 IMS-MFS Naming Conventions 1.2.2 Transaction Codes 1.2.3 Program Status Block Names 1.3 MVS Naming Conventions 1.3.1 Job Names 1.3.2 Application Program Names 1.3.3 Data Set Names 1.3.4 Report Names 2.0 DESIGN STANDARDS 2.1 Screen Design Standards 2.1.1 Screen Formats 2.1.2 Error Processing 2.1.3 Cursor Positioning 2.1.4 PF Key Usage 2.2 Report Layout Standards 3.0 PROGRAMMING STANDARDS 3.1 PL/I Programming Standards 3.1.1 Program Style 3.1.2 Variable Names and Usage 3.1.3 Procedures and Include Members 3.1.4 On-line Processing 3.1.5 DB2 Considerations 3.1.6 Program Documentation 3.2 Program Shells 3.3 Program Error Recovery/Restart 3.4 Error Message Numbers 3.5 Common Routines
Page: 5
1 A.
TABLE OF CONTENTS (cont.) PROJECT STANDARDS (Cont.) 4.0 REVIEW STANDARDS 4.1 Walkthrough and Peer Reviews 4.2 Lifecycle Reviews 5.0 SECURITY PROCEDURES AND TECHNICAL FACILITIES 1.0 TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT 1.1 Champ 1.2 TSO/SPF 1.3 DB2 1.3.1 DB2I 1.3.2 DB2/QMF 1.3.2.1 QMF Query 1.3.2.2 QMF Proc 1.3.2.3 Printing from QMF 1.4 IMS 1.4.1 IMS-BTS 1.4.2 IMS-DC 1.4.3 IMS-MFS 1.5 MVS-JCL 1.6 Productivity Tools 1.6.1 Nastec CASE/2000 DesignAid 1.6.2 Easytrieve Plus 1.6.3 Extended File-Aid 1.6.3.1 On-line 1.6.3.2 Batch 1.6.4 Multi-Mate 1.7 Testing Facilities 1.7.1 BTS On-Line Testing 1.7.2 Test IMS Testing 1.7.3 Batch Testing 1.8 War Room 2.0 PROJECT MANAGEMENT AND PLANNING 2.1 ARTEMIS 2.2 PDS Project Tasks and Deliverables
B.
Page: 6
3.0
4.0
6.0
TABLE OF CONTENTS (cont.) SYSTEM DESIGN METHODOLOGY 3.1 Structured Analysis and Design 3.1.1 Data Flow Diagrams 3.1.2 Structure Charts 3.1.3 Pseudocode 3.1.4 Process Specifications 3.2 Data Modeling DATAMANAGER DATA DICTIONARY USE 4.1 Introduction to Data Dictionaries 4.1.1 Objectives and Purpose 4.1.2 Basic Concepts 4.1.3 Objects and Object Types 2.1.4 Class Words 4.2 Accessing Datamanager 4.2.1 Logon Sequence 4.2.2 Datamanager Functions Menu 4.3 Query Commands 4.3.1 Browse 4.3.2 Keep 4.3.3 Drop 4.3.4 Does 4.3.5 Search for 4.3.6 What 4.3.7 Which 4.3.8 Glossary 4.3.9 List 4.3.10 Report 4.3.11 Alternate Format 4.3.12 Print TESTING PROCEDURES 5.1 Unit Testing Procedures 5.2 System Testing Procedures 5.3 PDS CHAMP Procedures for Testing 5.3.1 Unit Testing in Champ 5.3.2 System Testing in Champ
Page: 7
6.0
7.0
TABLE OF CONTENTS (cont.) CONFIGURATION MANAGEMENT PROCEDURES 6.1 Change Control Request (CCR) 6.1.1 CCR Logon Procedure 6.1.2 CCR Procedure - Originator 6.1.3 CCR Procedure - SE 6.1.4 CCR Procedure - Database 6.1.5 CCR Procedure - Testing 6.1.6 CCR Procedure - Technical Documents 6.2 PDS Maintenance Procedures 6.2.1 Routine Maintenance Processing 6.2.2 Emergency Maintenance Processing 6.2.3 Enhancement Maintenance Processing 6.2.4 Release Processing 6.2.5 Maintenance Tasks 6.2.6 Maintenance Documentation Standards 6.2.7 Controlling the Maintenance PRINTING 7.1 Print Destinations 7.2 Print Fonts 7.3 3800 Laser Printing 3270 AND PC PROCEDURES 8.1 GMNET/EDSNET 8.2 Communicating with the 3270 Series 8.3 Communicating with the Host from a PC OTHER GROUPS INVOLVED WITH PDS 9.1 Account Support Group 9.2 GM Project Management Group 9.3 GM Users 9.4 Other TSD Groups 9.5 The IPC 9.6 BSM's, BSS, IPSD, DAMART, DSG
8.0
9.0
Page: 8
C.
TABLE OF CONTENTS (cont.) DOCUMENTATION GUIDELINES AND PROCEDURES 10.1 PDS End-Documents 10.1.1 Requirements Definition 10.1.2 Business Design (Logical) 10.1.3 Technical Design (Physical) 10.1.4 Testing 10.1.5 Conversion and Implementation 10.2 PDS Documents Distributed Outside of Project APPENDIX A. EDS VOLUME FIVE NAMING STANDARDS B. SELC CODING STANDARDS FOR ALL LANGUAGES SELC PL/I CODING STANDARDS 10.0
Page: 9
INTRODUCTION
The Product Description System (PDS) Standards and Procedures Manual provides the standards and procedures necessary for supporting the PDS project. PDS project standards exist to ensure that PDS is a quality product, that each PDS deliverable is understandable, readable, and maintainable. wherever EDS corporate standards exist, they have been incorporated and referenced within this manual. A copy of each of the referenced manuals can be found within the PDS library. It is the responsibility of each PDS team member to follow and enforce these standards. Additionally, it is the responsibility of each PDS manager to ensure that his team members are adhering to these standards. This manual is maintained by a committee coordinated by the Software Quality Assurance Group. The committee includes a representative from the Development Group, Step 1 Group and the Database Group. It is the responsibility of each PDS team member to help identify standards which should be added or updated in the manual.
ORGANIZATION
There are two sections contained within the PDS Standards and Procedures Manual. Section 1 Project Standards - provides the guidelines that are to be followed for naming conventions, design standards, programming standards, review standards, and security. These guidelines are meant to serve as tools for standardizing processes that work together to produce a more concise and effective PDS. Section 2 - Procedures and Technical Facilities - provides basic overviews on various procedures and technical facilities that are currently being used on the PDS project. This includes overviews on programming languages, testing standards, project management and planning, and system design methodology to list a few. These overviews are provided for both new and established PDS members to use as needed.
MANUAL APPENDICES
Appendix A contains the "EDS Volume Five Naming Standards". This document is used by EDS as a guide to follow for naming standards.
Appendix B contains the 'Coding Standards For All Languages' and 'PL/I Coding Standards' excerpts from the "Software Engineering Life Cycle (SELC)" manual. These excerpts provide guidelines to follow when in the coding phase of the development process.
A current copy of the PDS Standards and Procedures Manual and any referenced on-line files will be located in the data set 'PBHEN.PDSMA.STDS'.
Page: 10
PROJECT STANDARDS
NAMING CONVENTIONS DB2 NAMING CONVENTIONS
DATE: 8/27/87 INDEX: A.1.1.1
DB2 Data Structures

PURPOSE: creating a number WHEN UTILIZED: REFERENCES: NOTES: Ensure that all data structure names follow the PDS data dictionary assignment which will prevent of aliases for each data structure. Whenever naming a data structure within a PL/I program. IBM DB2 Application Programming Guide for TSO; Appendix A and B. All DCLGENs (an alternative to writing out DECLARE statements in COBOL or PL/I programs) must be performed by the PDS Development Support. The DCLGEN utility, Option "2" from the DB2I Primary Menu should be used to generate all program DB2 data names.
STANDARD: Option structure
Page: 11
DB2 NAMING CONVENTIONS

DATE: 8/27/87 INDEX: A.1.1.2
DB2 Object Names

PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Standardize naming conventions for PDS in order to assign each DB2 Object a unique identifier. Naming all tablespaces, tables and indexes. EDS Volume 5 Standards Manual (See Appendix A) Table names are assigned by PDS Development Support. The following are the PDS standards for naming DB2 objects: a) Step 1: Object Type Table Space Number Partition/Table Number Index Number Object Type: Pos 1 Pos 2 thru 4 Pos 5 thru 6 Pos 7
T - Tables and Tablespace X - Indexes
Table Space Number: XXX - (001 - 199) Partition/Table Num: NN - (01 - 99), Default='01' Index Number: Z - Blank = clustering index. (2 - 9), succeeding indexes.
The format for naming each object type is: Tablespace - TXXX01 Tables - TXXXNN Indexes - XXXXNNZ Examples Tablespaces: Tables: Indexes: T00101 - Tablespace 1 T00301 - Tablespace 3 T00101 - Table 1, Tablespace 1 T00102 - Table 2, Tablespace 1 X00101 - Table 1, Index 1 X001012 - Table 1, Index 2
Page: 12
DB2 NAMING CONVENTIONS

DATE: 8/27/87 INDEX: A.1.1.2
DB2 Object Names

b) Step 2: Object Type Table Space Number Partition/Table Number Index Number Object Type: Pos 1 Pos 2 thru 4 Pos 5 thru 6 Pos 7
T - Tables and Tablespace X - Indexes
Table Space Number: XXX - (200 - 999) Partition/Table Num: NN - (01 - 99), Default='01' Index Number: Z - 1 = clustering index, 2 - 9 = succeeding indexes.
The format for naming each object type is: Tablespace - T2XX01 Tables - T2XXNN Indexes - X2XXNNZ Examples Tablespaces: Tables: Indexes: T20101 - Step 2 Tablespace 1 T20201 - Step 2 Tablespace 2 T20101 - Step 2 Table 1, Tablespace 1 T20102 - Step 2 Table 2, Tablespace 1 X201011 - Step 2 Table 1, Index 1 X201012 - Step 2 Table 1, Index 2
Page: 13
NAMING CONVENTIONS IMS NAMING CONVENTIONS

DATE: 8/27/87 INDEX: A.1.2.1
IMS-MFS Naming Conventions

PURPOSE: coordinated WHEN UTILIZED: REFERENCES: NOTES: STANDARD: name. Standardize naming conventions for PDS in order to assign each MID/MOD and DIF/DOF a unique identifier which is with the application program name. Naming all MID/MODs and DIF/DOFs. See A.1.3.2 - Application Program Names The PDS Subsystem and Sequential ID# must match those assigned to the application program. The following are the PDS standards for IMS-MFS naming conventions. The MOD name is the same as the source MFS These follow the same format as those outlined in A.1.3.2 Application Program Names. MID/MOD System Name MFS Objects PDS Subsystem Sequential ID# DIF/DOF System Name PDS Subsystem Sequential ID# MID/MOD System Name: MFS Objects: PDS Subsystem: Sequential ID#: PDS for Step 1 PD2 for Step 2 I - MID U - MOD See A.1.3.2 - Application Program Names See A.1.3.2 - Application Program Names Pos 1 thru 3 Pos 4 Pos 5 Pos 6 thru 7 Pos 1 thru 3 Pos 4 Pos 5 thru 6
Page: 14
IMS NAMING CONVENTIONS

DATE: 9/25/87 INDEX: A.1.2.1
IMS-MFS Naming Conventions

DIF/DOF System Name: PDS Subsystem: Sequential ID#: PDS for Step 1 PD2 for Step 2 See A.1.3.2 - Application Program Names See A.1.3.2 - Application Program Names EXAMPLE Step 1 Member MID MOD DIF/DOF PDSUN01 PDSIN01 PDSUN01 PDSN01 Step 2 PD2UN01 PD2IN01 PD2UN01 PD2N01
Page: 15

DATE: 8/27/87 INDEX: A.1.2.2
Transaction Codes
PURPOSE: with the WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Standardize naming conventions for PDS in order to assign each Transaction Code a unique identifier which is coordinated application program name. Whenever naming or accessing a PDS Transaction. See A.1.3.2 - Application Program Names A list of current generated IMS program status block names is in dataset 'PBHEN.PDSMA.STDS(IMSGEN)'. The following are the PDS standards for naming Transaction codes. These follow the same format as those outlined in A.1.3.2 Application Program Names. System Name Transaction Type PDS Subsystem Sequential ID# System Name: Transaction Type: PDS Subsystem: Sequential ID#: Pos 1 thru 3 Pos 4 Pos 5 Pos 6 thru 7 PDS for Step 1 PD2 for Step 2 I - Inquiry U - Update See A.1.3.2 - Application Program Names See A.1.3.2 - Application Program Names
Page: 16

DATE: 9/25/87 INDEX: A.1.2.3
Program Status Block Names

PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Index for IMS Application Program Names Whenever naming or accessing a PDS program status block. See A.1.3.2 - Application Program Names A list of current generated IMS program status block names is in dataset 'PBHEN.PDSMA.STDS(IMSGEN)'. The program status block name must be identical to the program name.
Page: 17
NAMING CONVENTIONS MVS NAMING CONVENTIONS

DATE: 8/27/87 INDEX: A.1.3.1
Job Names
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: The PDS naming conventions for job names are designed to provide consistent and unique names which adhere to EDS standards. Whenever creating a PDS batch job. EDS User's Guide; Volume 5 (IPC Guide) (See Appendix A) All PDS production batch job names should begin: 'BHENDS'. All job names must conform to EDS Volume 5 Standards Manual (Chapter 3).
Page: 18
MVS NAMING CONVENTIONS

DATE: 8/27/87 INDEX: A.1.3.2
Application Program Names

PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: Support STANDARD: with EDS Standardize naming conventions for PDS in order to assign each application program a unique identifier. Naming all on-line and batch programs. EDS Volume 5 Standards Manual (See Appendix A) Do not randomly assign a sequential identifier. This should be controlled by each subsystem through the PDS Development Group. The following are the EDS Volume 5 standards for application naming conventions used in conjunction with PDS naming conventions. For further clarification, please consult Volume 5 and your EDS supervisor. System Name Type Code PDS Subsystem Sequential ID# System Name: Type Code: Pos 1 thru 3 Pos 4 Pos 5 Pos 6 thru 7 PDS for Step 1 PD2 for Step 2 C - Clists G - SPF/DMS Screen Messages I - Input Data (SYSIN DD) P - Source Program Module S - Subroutines U - Screen Layouts (SPF or MFS) Y - Include Library
Refer to page C3D.001 VOL 5 or Appendix A for additional Type Codes
Page: 19

DATE: 8/27/87 INDEX: A.1.3.2
Application Program Names

PDS Step 1: PDS Subsystem: A - Change Control Request B,C,D - On-line Distribution Programs E - Batch Distribution Programs F,G,H - On-line EWO Programs I - Batch EWO Programs J,K,L - On-line Parts Programs M - Batch Parts Programs N,O,P - On-line Usage Programs Q - Batch Usage Programs R,S,T - On-line VDS Programs U - Batch VDS Programs V - Security W - Testing X - Administrative Y - Bit Map Z - Conversion 00 - 99
Sequential ID#: indicator
For a given subsystem, use each sequential ID# within the first PDS Subsystem before continuing with the next PDS Subsystem indicator. EXAMPLE: PDS P N 00 Usage On-line Program | | | | | | | |_________Sequential ID# | | | | | |____________PDS Subsystem | | | |_______________Type Code | |___________________System Name
Page: 20

DATE: 8/27/87 INDEX: A.1.3.3
Dataset Names
PURPOSE: The PDS naming conventions for datasets are designed to provide for consistent, unique and flexible names yet adhere to EDS standards. Whenever creating a PDS global dataset. EDS Volume 5 (IPC Guide) (See Appendix A) All PDS test datasets should begin 'TBHEN.PD2xx'. All PDS production datasets should begin 'PBHEN.PD2xx'. Avoid using the default temporary pack when allocating a dataset. Temporary packs are deleted after 2 days. Use a permanent serial number. PDS permanent pack IDs are: 007086, 007089, BLD301, BLD305 STANDARD: All dataset names must conform to EDS Volume 5 Standards Manual (Chapter 3)
WHEN UTILIZED: REFERENCES: NOTES:
volume
Page: 21

DATE: 8/27/87 INDEX: A.1.3.4
Report Names
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Names must be similar to the program IDs. The 10-character report names follow the same format as those outlined in A.1.3.2 - Application Program Names. System Name Type Code PDS Subsystem Sequential ID# Report Number Filler System Name: Type Code: PDS Subsystem: Sequential ID# Report Number Pos 1 thru 3 Pos 4 Pos 5 Pos 6 thru 7 Pos 8 thru 9 Pos 10 PDS for Step 1 P Refer to A.1.3.2 - Application Program Names. 00-99 Number assigned within the Subsystem. Blank if the program generates only one report; 00-99 for multiple reports. To assign report names which easily associate the reports with the programs generating them. Whenever naming a report generated in a PDS program.
Page: 22
PROJECT STANDARDS
DESIGN STANDARDS SCREEN DESIGN STANDARDS
DATE: 8/27/87 INDEX: A.2.1.1
Screen Formats
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: The screen header and footer must be constant for all screens. All Field Names will be highlighted. Data will not be highlighted unless it is in error. When there is more data to view on another screen, the screen name selection (or PF Key) will be highlighted and a message displayed. This does not apply to page forward and page back. Header-line 1 Screen Code: The screen codes will be an abbreviation for the subsystem name plus a screen number - for example, ACT01. The source member names will not change so code will need to be included to convert screen codes to MOD names. Product Description System Current date To ensure that all screens within PDS have uniform formats. When a PDS screen is being designed or altered.
System Title: Date: Header-line 2
Subsystem Title: Subsystem & screen name Time: Current time
Page: 23
SCREEN DESIGN STANDARDS

DATE: 8/27/87 INDEX: A.2.1.1
Screen Formats
Header-line 3 (Command Line - Menu Level)
Menu Selection Field: An optional field. The numeric entry corresponding to the menu selection identified on the menu screen is entered in this field. Header-line 3 (Command Line - Detail Screens) Blank line. Used as a program hidden area. Header-line 4 Select Field: The type of processing desired is entered here. For example, A=Add, C=Change, D=Delete, I=Inquiry. The possible choices will not be displayed on the screen. Menu Body-lines Each option will have the available screen titles accompanied by the corresponding screen code. Footer-line 1 (line 22) Error/Informational Message Line (highlighted). Footer-line 2 (line 23) PF Key Description. Lists subsystem function keys On menu screens, lists PF Keys to other subsystems. Footer-line 3 (line 24) PF Key Description. Defines program function keys that are valid on each screen. Screen Field: 5 position entry field which indicates the screen code desired.
Page: 24

DATE: 9/09/87 INDEX: A.2.1.2
Error Processing
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Error Processing 1. Line 22 is reserved for error and informational messages only. 2. A meaningful message will be approved by the user. 3. Error/informational messages and all data errors will be highlighted. The cursor should be positioned at the first 4. A question mark, '?', will appear in each field that is required but not entered. '?' will be processed as if the user left the Error Number Assignments 1. Assignment of error numbers will be controlled through the Error Message Coordinator. 2. Each group should submit the approved error messages to the Error Message Coordinator for number assignment. It is Message Coordinator's responsibility to ensure that there already a similar message in the table. 3. All error messages are available in dataset 'PBHEN.PDS.STDS(MESSAGES)'. These messages are available only on the Buick system. This standard ensures that all PDS screens handle errors in a uniform manner. When a PDS screen is being designed or altered.
error.
field blank.
the Error is not
Page: 25

DATE: 9/09/87 INDEX: A.2.1.3
Cursor Positioning
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Cursor Positioning 1. The cursor should be positioned on the first field requiring entry. Most of the time this will be the SELECT field. 2. For a screen in error, the cursor should be placed on the first data field on the screen which contains an error. This standard ensures that all screens position the cursor on PDS screens in a uniform manner. When a PDS screen is being designed or altered.
Page: 26

DATE: 12/02/87 INDEX: A.2.1.4
PF Key Usage
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Program Function Key Standards PF1 - Help System (Not available in step 1) PF2 - Subsystem Menu PF3 - Quit (Only valid on menus) PF4 - PDS Main Menu PF7 - Page Top PF8 - Page Forward PF12 - User Defined (e.g. Printer) PF3, PF5, PF6, PF9, PF10, PF11 are reserved for subsystem use. Non-MENU Program Funtion Key Standards Enter - Should only be used to process a transaction request or initial screen request. PF1 table PF2 PF4 PF7 PF8 A standard error message should appear whenever this key is pressed in step 1. A generic error message is in the error message T00205. This key will transfer the user to the pertinent subsystem menu. This key will transfer the user to the PDS Main Menu. This key will display the initial screen that was requested when the paging function was initiated. This key will display more available data if it exists. This standard ensures that PF Keys for all PDS screens will be processed in a uniform manner. When a PDS screen is being designed or altered.
Page: 27
PROJECT STANDARDS
DESIGN STANDARDS REPORT LAYOUT STANDARDS
DATE: 9/09/87 INDEX: A.2.2
Batch Report Layout

PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: The following standards have been designed for batch reports: Header-line 1 Report Name System Name Run Date Header-line 2 Subsystem Name Time Header-line 3 Report Title Page Number Header-line 4 Platform IDs All Platforms which are contained on the report Report sequence number Full report name Number of the page printed Subsystem name Time the report was executed Ten character report name (See A.1.3.4 - Report Names) Product Description System Date the job was executed To ensure that all batch PDS reports have a uniform format. When a PDS report is being designed or altered.
Sequence Number-
Page: 28
REPORT LAYOUT STANDARDS

DATE: 9/09/87 INDEX: A.2.2
Batch Report Layout

Footer END OF REPORT This will be printed in the middle the last line of the report to minimize any possible confusion.
NO DATA ON THIS REPORT - This will be printed after the report headers to show that the report was indeed executed, but no detail lines were generated. Example: See next page.
Page: 29
PGM NAME02 PRODUCTION DESCRIPTION SYSTEM SUBSYSTEM NAME 22:12:00 REPORT TITLE C/H PLATFORM CHASSIS
RUN DATE: 09/09/87 TIME: PAGE NUMBER:23 SEQ: 9999
END OF REPORT or NO DATA ON THIS REPORT
Page: 30
PROJECT STANDARDS
PROGRAMMING STANDARDS PL/1 PROGRAMMING STANDARDS
DATE: 12/02/87 INDEX: A.3.1.1
Program Style
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: Program Style PDS follows and enforces coding standards outlined in the SELC manual. See SELC Section 9.3 Coding Standards for All Languages and PL/I Coding Standards and Section 9.5 PL/I Coding Standards (PDS Standards & Procedures Appendix B) for more information. Additionally, 1. Only make 'CALL's to procedures that are positioned AFTER the 'CALL' statement. 2. Try to avoid negative logic. 3. Use external procedures whenever appropriate. 4. Declare external subroutine parameters in an INCLUDE with the same name as the subroutine source except for the type code. To ensure uniform and maintainable code. Whenever creating or modifying a PL/I code. Software Engineering Life Cycle (SELC) Manual
Page: 31
PL/1 PROGRAMMING STANDARDS

DATE: 9/09/87 INDEX: A.3.1.2
Variable Names and Usage

Variable Names and Usage 1. All variable names MUST adhere to the EDS naming conventions as follows (start with the indicated letter and underscore): A_ C_ S_ W_ P_ T_ accumulators constants switches, indicators work fields print lines tables and elements of tables (not DB2 type tables).
Page: 32

DATE: 9/09/87 INDEX: A.3.1.3
Procedure and INCLUDE Members

Procedures and INCLUDE Members 1. All internal program procedures should be placed in numerical order for ease of reference and use. This applies for procedures contained in ++INCLUDES (place the ++INCLUDE statement in such a fashion as to preserve the sequencing). Design your code so that the top down call structure standard is not violated. Use the pre-named procedure names to implement common sections of code. The following is a list of the known procedure names to use to implement common sections of code: General list: 1000s 3000s 4000s 5000s-8000s 9000s 9999 XXXX On-line list: #1000 INITIALIZE #1025 COPY MID TO MOD #3000 PROCESS ONE MESSAGE #3100 PROCESS PFKEY #3125 PROCESS SCREEN CHANGE #3200 PROCESS ADD #3400 PROCESS CHANGE #3600 PROCESS DELETE #3700 PROCESS INQUIRY #3800 MOVE DATA TO MOD #4000 EDIT KEY #4100 EDIT DATA #9000 SEND MESSAGE #9800 SET MESSAGE 3. - initialize each message - copy all MID fields to MOD - main logic for each message - perform action for PF Key - logic for screen jump - database add processing - database change processing - database delete processing - database inquiry processing - copy database fields to MOD - edit screen key fields - edit screen data fields - send MOD/create pgm switch - flag an error, get msg text initialization main processing functions edits programmer-defined finalization abort Checkpoint/Restart
2.
An INCLUDED member must not contain any %INCLUDE statements.
Page: 33

DATE: 9/09/87 INDEX: A.3.1.4
On-line Processing Standards

On-line Processing 1. Selection options: The following three events are mutually exclusive: PF Key selection screen change selection general selection. If any two of the three events occur at the same time, the program should issue an error message and redisplay the screen (with all the data). 2. Required Fields: The program should place a question mark in the first position of any input field which is required. 3. Update processing: o Perform edits on all fields of the screen, left to right, top to bottom. o Display the error message for the first errored field, placing the cursor on the field and highlighting it. o Continue to edit ALL fields, highlighting any errors. o Use standardized edits for each field. 4. Change and Delete Processing: The program must execute an inquiry first on the data to be updated.
Page: 34

DATE: 9/09/87 INDEX: A.3.1.4
On-line Processing Standards

5. Change Processing: If no data is actually changed, a message to that effect should be shown to the user, with the funcion C still in the select field. This means that all fields edited should be compared to the fields obtained in the inquiry to see if changes were actually made. 6. Input Edit Processing: o Errors Found - The selection field(s) should remain the way the user entered them. o No Errors - If the data base is updated successfully, then the selection field(s) should be blanked out. 7. Message Text: o The actual message displayed will be derived from the message table by supplying the correct message code in the field "W WRK MSG CODE". o The message table will be centrally maintained by the Message Code Coordinator in order to ensure that messages remain unique. o Use the appropriate message from the table. o If an appropriate message doesn't exist, contact the Error Message Coordinator to have the message table updated with a new message code and text. o An updated listing of this table will be distributed as changes are made to this table. A listing will also be made available in library 'PBHEN.PDSMA.STDS(MESSAGES)'- to browse only!
Page: 35

DATE: 9/09/87 INDEX: A.3.1.5
DB2 Considerations
DB2 Considerations 1. Use the following indented form for all DB2 queries: EXEC SQL keyword1 item1, item2, . . itemn keyword2 item1, item2, . . itemn; Example: EXEC SQL SELECT MSGCODE, MSGTEXT INTO :MSG CODE, :MSG TEXT FROM BHENPDS5.T002050 WHERE MSGCODE = :MSG CODE;
Page: 36

DATE: 9/09/87 INDEX: A.3.1.5
DB2 Considerations
2. When updating a large number of rows use the 'FOR UPDATE' option of the 'SELECT' command and the 'WHERE CURRENT OF CURSOR' clause. When updating a small number of rows fetched with a CURSOR SELECT, use stand-alone updates. 3. Always examine the return code from DB2 and use the PL/I 'SELECT' statement to take one of the following appropriate courses of action: EXEC SQL some query; SELECT (SQLCODE); WHEN (0) DO; successful! END; WHEN (100) DO; not found END; WHEN (???) . . . OTHERWISE DO; some error routine END; END; 4. NEVER use the 'SELECT *' in an SQL select and NEVER use a PL/I structure variable to capture all of the columns. ALWAYS reference the data element level - each field of both the table and the PL/I structure. This allows for data independence. 5. The original binder of a newly-written program must grant the following authorization on the application so that other SE's can execute the program: GRANT EXECUTE ON PLAN PDSx____ TO PUBLIC x = P or T This permission can be granted either through QMF or SPUFI.
Page: 37

DATE: 9/09/87 INDEX: A.3.1.6
Program Documentation
PURPOSE: All programmers should use a consistent documentation scheme in order to ensure maintainability. Whenever a new code is being developed or maintained. SELC MANUAL
WHEN UTILIZED: REFERENCES: NOTES: STANDARDS:
See pages 9.12-9.27 of the SELC manual for EDS Program Documentation Standards. PDS follows and enforces the SELC standards.
Page: 38

DATE: 01/25/88 INDEX: A.3.2
Program Skeletons
PURPOSE: All programmers should use a standard shell to ensure all code deliverables are structured in the same format. Whenever a new code deliverable is being developed.
WHEN UTILIZED: REFERENCES: NOTES: STANDARD:
The following datasets should be accessed for the current shell for each type of code deliverable: Batch Programs - 'PBHEN.PDSMA.STDS(SKELBATC)'
On-line Programs - 'PBHEN.PDSMA.STDS(SKELONLN)' MFS Definitions - 'PBHEN.PDSMA.STDS(SKELMFS)'
Page: 39

DATE: 09/14/87 INDEX: A.3.4
Error Message Numbers

PURPOSE: This standard ensures that all error message numbers within PDS have a unique identifier and follow a common format. Whenever adding an error message to PDS
Common error messages are contained in the dataset: 'PBHEN.PDSMA.STDS(MESSAGES)' All error message numbers must be assigned through the Error Message Coordinator.
Page: 40
PROJECT STANDARDS
REVIEW STANDARDS
DATE: 09/10/87 INDEX: A.4.1
Walkthrough and Peer Reviews

PURPOSE: Formal and informal walkthroughs and peer reviews are conducted throughout the PDS lifecycle to identify defects in the product as early in the life cycle as possible, and to ensure that QA standards and procedures are being applied to system development and documentation. Throughout each phase of the development lifecycle SELC Manual PDS Software Quality Assurance Plan
For a minimum, the following reviews must be conducted during the development and maintenance process: o o o o o Managerial Walkthroughs Code Walkthroughs Test Readiness Review Documentation Reviews Lifecycle Reviews
Page: 41
REVIEW STANDARDS
DATE: 09/10/87 INDEX: A.4.2
Lifecycle Reviews
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: STANDARD: As a minimum, the following are conducted: o SOFTWARE REQUIREMENT REVIEW (SRR) - held to ensure the adequacy, completeness, clarity of the PDS requirements stated in the Requirements Definition Document. BUSINESS DESIGN REVIEW (BDR) - held to evaluate whether the Business Design Document meets the PDS Requirements. TECHNICAL DESIGN REVIEW (TDR) - held to determine the acceptability of the PDS detailed design in satisfying the PDS requirements. POST IMPLEMENTATION REVIEW (PIR) - held after the system has been implemented and placed into production. The purpose is to determine how well PDS is fulfilling the PDS Requirements. These reviews are checkpoints in the development of PDS. At the end of each phase of the lifecycle (for each deliverable). SELC Manual PDS Software Quality Assurance Plan
Page: 42
PROCEDURES AND TECHNICAL FACILITIES

TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT
DATE: 09/09/87 INDEX: B.1.1
Champ
PURPOSE: CHAMP (Change Management and Promotion) is designed to control the movement of source members between development and production datasets. CHAMP is designed to be used by system engineers involved in the development and maintenance of customer systems and by IPC personnel responsible for the support and maintenance of the production environment. For all PDS developed source members. Champ User's Manual. None
WHEN UTILIZED: REFERENCES: NOTES:
Page: 43
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT

DATE: 03/02/87 INDEX: B.1.2
TSO/SPF
PURPOSE: The System Productivity Facility (TSO/SPF) is a product that assists in program development by taking advantage of the characteristics of the IBM 3270 display terminals. Program development and testing PF1 - HELP System Productivity Facility for MVS Program Reference. SPF Dialog Management Services NOTES: When writing CLISTS, some TSO utility functions can not be executed under the SPF environment.
WHEN UTILIZED: REFERENCES:
Page: 44
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT DB2

DATE: 03/02/87 INDEX: B.1.3.1
DB2I
PURPOSE: DB2I is an interactive program that helps in the development of DB2 applications. It consists of seven major panels to do the following tasks: 1. SPUFI (SQL Processor Using File Input) Processes SQL statements. 2. DCLGEN - Produces SQL statements. 3. BIND/REBIND/FREE - Binds, rebinds, and frees application plans. 4. PROGRAM PREPARATION - Prepares programs that include SQL statements. 5. RUNS& Executes programs. 6. DB2 COMMANDS - Issues DB2 operator commands. 7. UTILITIES - Executes utility jobs. WHEN UTILIZED: REFERENCES: NOTES: Data Base development, program development and testing Appendix A and B of IBM DB2 Application Programming Guide for TSO The DB2 name subsystem is TDSN on system 8. Enter this via U.2.2.D subsystem identifier on the DB2 default screen.
Page: 45
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT DB2

DATE: 03/02/87 INDEX: B.1.3.2
DB2/QMF
PURPOSE: The Query Management Facility (QMF) may be used to insert, update, delete and display data in a DB2 data base. It can also format reports generated through queries. Data Base development, program development, testing and ad hoc reporting. IBM Query Management Facility: User's Guide and Reference Manual. IBM Query Management Facility: Learner's Guide NOTES: None
Page: 46
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT IMS

DATE: 03/02/87 INDEX: B.1.4.1
IMS - BTS
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: PROCEDURE: Tool used to test IMS/VS-DC programs. Program Development and Testing. IMS-BTS User's Manual. The IMS-BTS User Manual will be stored in the PDS Documentation Library. It is currently on order. Instructions for using IMS-BTS are: 1. Copy 'PBHEN.PDSMA.STDS(SKELBTSI)' into your own BTSIN dataset. 2. Off of the main panel, select: U.D.15.B2 3. Select Option: X 4. BTSIN Dataset: Your own BTSIN dataset name 5. Are all of the files allocated? <ENTER> (Not Y) **Note: If you have not logged off since your last BTS session, you can enter 'Y', since the files are still allocated to you. (This will be slightly faster) 6. /For (MODNAME) session now started 7. /* to end 8. Do you want to execute BTS again? Your call
Page: 47

DATE: 03/02/87 INDEX: B.1.4.2
IMS - DC
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: Teleprocessing Facility On-line Transaction Processing IMS-DC User's Manual.
Page: 48

DATE: 03/02/87 INDEX: B.1.4.3
IMS - MFS
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: IMS-MFS is the screen format facility used with IMS-DC. On-line Transaction Processing IMS-MFS User's Manual. A skeleton for an IMS-MFS program exists in the dataset: 'PBHEN.PDSMA.STDS(SKELMFS)'.
Page: 49
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT PRODUCTIVITY TOOLS

DATE: 03/02/87 INDEX: B.1.6.1
NASTEC CASE/2000 DesignAid

PURPOSE: DesignAid is a requirements and design tool that facilitates top-down project design by providing modeling support for the Yourdon methodology. The tool supports data flow diagrams, structure charts and entity relationship diagrams. This tool should be used to create all data flow diagrams and structure charts for the PDS project. Full documentation includes a set of three user manuals (GraphiText, Design Dictionary, and Design Analyzer). Features of this tool includes leveling of data flow diagrams as well as a fully integrated data dictionary and word processor.
NOTES:
Page: 50
TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT PRODUCTIVITY TOOLS

DATE: 03/02/87 INDEX: B.1.6.2
Easytrieve Plus
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: JCL for executing Easytrieve Plus is contained in dataset: 'PBHEN.PDSMA.STDS(EASYPLUS)'.
Page: 51

PROJECT MANAGEMENT AND PLANNING
DATE: 03/02/87 INDEX: B.2.1
ARTEMIS Project Tracking

PURPOSE: ARTEMIS is a project tracking tool which is currently accessed via the Plano IPC. ARTEMIS produces both bar and Gant charts which display each activity within a project. These status reports are submitted to the PDS management team. ARTEMIS is a project management tool to be used throughout the project life cycle. PDS Support Documentation: PDS Project Management Task Identifier None The Standard input forms are located in the PDS Support Documentation : PDS Project Management: Task Identifier. One of these must be filled out before a particular activity is added or deleted from ARTEMIS.
WHEN UTILIZED: REFERENCES: NOTES: PROCEDURE:
Page: 52

SYSTEM DESIGN METHODOLOGY STRUCTURED ANALYSIS AND DESIGN
DATE: 08/27/87 INDEX: B.3.1.1
Data Flow Diagrams

PURPOSE: The Data Flow Diagram (DFD) is a picture of how data moves through the system. It is a network of interrelated processes which transforms the data from inputs to outputs. The diagrams show the major decomposition of function into pieces which can be easily managed and implemented. They show the scope of the system and interfaces between processes. DFDs are used during structured analysis to gather requirements for the system in order to facilitate development of a structured model of the system. Software Engineering Life Cycle (SELC) Manual Sections: 2.3; 2.4; 2.6 "The Practical Guide to Structured Systems Design" Meilir Page-Jones, Yourdon Press, 1980. pgs:59-74 NOTES: PROCEDURE: The standard notation used to develop all data flow diagrams for the PDS project is outlined in the SELC Manual (Section: 2.3 The Data Flow Diagram). Samples DFDs are illustrated in Appendix A, B & C of the SELC Manual.
WHEN UTILIZED:
REFERENCES:
Page: 53
STRUCTURED ANALYSIS AND DESIGN

DATE: 09/09/87 INDEX: B.3.1.2
Structure Charts
PURPOSE: The Structure Charts show the partitioning of the system into a hierarchy of modules or black boxes based on the function each performs in the system. The Structure Charts do not indicate the sequence of module calls, only the hierarchy of modules and the interfaces between the modules. Structure Charts are to be developed during the general and detailed design phases of the life cycle. High-level structure charts are to be developed during the general design phase. Detail is added and Pseudocode developed during the detailed design. Software Engineering Life Cycle (SELC) Manual Sections: 3.2; 3.3; 3.4 "The Practical Guide to Structured Systems Design" Meilir Page-Jones, Yourdon Press, 1980. pgs:39-52 NOTES: PROCEDURE: The standard notation used to develop all Structure Charts for the PDS project is outlined in the SELC Manual (Section: 3.2.1 Structure Chart Notation). Sample Structure Charts are illustrated in Appendix A, B & C of the SELC Manual.
WHEN UTILIZED:
REFERENCES:
Page: 54

DATE: 09/09/87 INDEX: B.3.1.3
Pseudocode
PURPOSE: Pseudocode is an informal and very flexible structured language that is not intended to be executed on a machine, but is used to describe the process each module on the structure chart performs in order to complete its function. Pseudocode should be used in the detailed design phase to describe in detail the process each module will perform. Software Engineering Life Cycle (SELC) Manual Sections: 3.5 "The Practical Guide to Structured Systems Design" Meilir Page-Jones, Yourdon Press, 1980. pgs:94-96 NOTES: Pseudocode is reviewed at the design walkthrough which ensures that the requirements gathered during analysis will be reflected in the design which will then be coded by the programmer. All Pseudocode written for PDS will have the characteristics and style outlined in the SELC Manual (Section: 3.5 Pseudocode). An example of Pseudocode is included in Appendix A of the SELC Manual.
WHEN UTILIZED:
REFERENCES:
PROCEDURE:
Page: 55

DATE: 03/02/87 INDEX: B.3.1.4
Process Specifications
PURPOSE: The major purpose of the process specification is to communicate the requirements to both the customer and the designer in a format which both understands and can verify. Whenever developing textual requirement specifications. PDS Support Documentation: "Use of Structured English for Process Specification" Software Engineering Life Cycle (SELC) Manual
NOTES: PROCEDURE: The following guidelines have been established for writing PDS process specifications: 1. There must be one process specification for each functional primitive (essential activity, lowest-level bubble) in the DFD set. 2. The process spec must state the way in which the data flows entering the essential activity are transformed into the data flows leaving it. 3. The process spec should say what is to be done and not a method of implementing how it should be done. 4. The process spec should not restate something already stated in the DFD or in the data dictionary.
Page: 56

DATE: 03/02/87 INDEX: B.3.1.4
Process Specifications
5. The set of constructs used to build the process specs should be small and simple. Structured English, which minimizes the set of ways to specify processes, is a subset of English and its vocabulary comprises VERBS, OBJECTS, and CONJUNCTIONS. Its syntax includes simple sentences, closed-end decisions, closed-end repetitions and combinations of the above three. 6. The process spec is also the primary tool for modeling the access capabilities required by an essential activity (lowest-level bubble and corresponding process spec), with support from the data dictionary. 7. It is important to describe the relationships between data elements as precisely as possible so that the true requirements of the system are expressed through the process specs.
Page: 57
SYSTEM DESIGN METHODOLOGY

DATE: 03/02/87 INDEX: B.3.2
Data Modeling
PURPOSE: WHEN UTILIZED: Data Modeling is used to design a Logical Data Model. Data Modeling should be utilized during requirements analysis and design in order to develop a logical model of the data. Application Modeling Guide published by the System Development Support Group
REFERENCES: NOTES: PROCEDURE:
The Standard notation used to develop Entity-Relationship diagrams is contained in the Application Modeling Guide.
Page: 58

TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1
Unit Testing Procedures

PURPOSE: The objectives for unit testing are to determine if a unit's logic works properly and performs all the specified functions. A unit is defined as logical pieces or units of work which may consist of one or more modules, subroutines or programs. In order to achieve these objectives, unit testing must begin as soon as the unit requirements are finalized and include both functional as well as structural points of view. Unit testing should begin as early in the life cycle as possible. Functional tests can be designed as soon as the requirements are finalized. Structural test design should begin as soon as the pseudocode is available. Designing test cases before you write the code should improve the quality of the unit. PDS Support Documentation : Unit Testing Example "Structured Testing : A Software Testing Methodology Using the Cyclomatic Complexity Metric"; Thomas J. McCabe; December, 1982 NOTES: An example of a unit test scenario is available in "PDS Support Documentation : Unit Testing Example" which is located in the PDS library. UNIT TESTING IS THE RESPONSIBILITY OF THE CODER! PROCEDURE: Developing good unit test cases requires that they be designed and tested. A set of expected outputs for each set of inputs must be developed and verified for each test case. After all tests have been run, the actual outputs are compared with the expected outputs to determine the pass/fail status for each test. Unit testing is considered complete when all software functions and logic base paths have been tested. After errors are corrected, all test cases must be executed again in order to ensure that the unit will still pass all tests. Be sure that any outside units you executing have been unit tested. Otherwise, it may be build a stub (a procedure consisting of PROC and simulate correct execution of the called unit.
WHEN UTILIZED:
REFERENCES:
may be necessary to End) which will
Page: 59
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

Functional Testing (Black Box) In functional testing, the unit is treated as a black box and tests that the functions specified in the unit requirements are met. Designing functional tests should begin as soon as the unit requirements are complete. The following steps should be followed when designing functional test cases: 1. Identify and assign a unique identifier to each function described in the unit requirements. When necessary, request clarification of the requirements. Identify and assign a unique identifier to requirements other than functions (e.g. performance, capacity, security, design constraints, etc.) which can be effectively tested at the unit level. Identify the input and output data structures of the unit to be tested. For each structure, identify characteristics such as formats, value ranges, relationships between fields, etc. Assign a unique identifier to each characteristic and specify its valid ranges. Select the features to be tested and begin designing test cases to cover each. Decompose any compound or multiple condition cases into single condition cases. For each test case, determine which functions, requirements and characteristics are covered. Through the use of a test matrix, one can determine which set of test cases will best test the unit from a functional point of view. Identify and make provisions for any special resources which will be required to execute the test cases.
2.
3.
4.
5.
Page: 60
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

Structural Testing (White Box)
In structural testing, the logic of the unit is being tested which will test all features or functions that are not defined in the requirements. Complete structural test coverage is defined as exercising every statement and every decision at least once. There are several methodologies which will ensure complete structural testing. The two methods outlined in this standard will yield the same results, but follow different processes. Pick whichever method you are more comfortable with. An example utilizing both methods is included. Cyclomatic Complexity Metric A flowgraph graphically depicts flow of control for a program and aids in determining the minimum set of test cases which will provide complete structural coverage. addition, flowgraphs help identify overly complex logic which should be isolated in a separate routine. The following steps should be followed this methodology to determine structural unit test cases: 1. Draw a flowgraph of the unit by: a. Proceeding statement by statement through the program (numbering each statement may facilitate drawing the flowgraph). b. Sequential statements may be ignored or treated as a single node. c. Add a node and assign a node number to it for any branching or decision statement. Each node should be connected with an edge to indicate the flow of control based upon the logic of the node (it helps to label edges coming out of a decision according to the conditions they represent).
In simplified or when utilizing
O / \ O O \ / O
O |\ | O |/ O
IF
O |\ | O O
GOTO
IF THEN ELSE
Page: 61
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

2. Determine the minimum number of test cases (Complexity) necessary to provide complete structural coverage by counting the number of nodes and edges and substituting these counts into the following formula: C = # Edges - # Nodes + 2 3. Design test cases which ensures that every edge is exercised. This may be accomplished by picking a functional "baseline" path through the program which represents a legitimate function and not just an error. Flip each decision on the baseline while simultaneously holding the maximum number of baseline decisions the same. Use the program specifications to determine what the program should do for each test case that has been designed.
4.
Page: 62
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

Conditional Logic Methodology Testing all paths through the conditional logic and loops will ensure that a unit is structurally covered. The conditional logic method maps the logic into a binary tree structure which shows the dependency of the conditional logic within the program. One can then easily develop a set of test cases which will test this logic. The following steps should be followed when using this method: 1. Identify all conditions, loops, and actions that the program logic is performing. Assign each logic condition a level which indicates the dependencies it possesses. Draw a binary tree which shows the dependencies for both the true and false condition for each logic condition. Generate test conditions which will ensure each leg of the binary tree is traversed. Explode the test conditions to satisfactorily boundary test each condition. Develop inputs and expected outputs for each test case. A matrix will facilitate this effort. Add tests which will execute each loop for its minimum and maximum repetitions.
2.
3. 4. 5. 6.
Page: 63
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

Overall Testing Considerations The structural and functional test cases should be combined to form a set of overall test cases for the unit. Redundant tests should be eliminated and any additional tests you feel may be needed should be added. There is nothing wrong with doing too much unit testing. Testing must not be confused with debugging. Execution of tests should not begin until debugging is finished. Debugging may be necessary to determine why a test has failed, but never replaces testing. Debugging involves ad hoc tests which cannot replace tests which have been carefully designed and verified. All test results and test cases should be documented so that they can be referenced whenever necessary.
Page: 64
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

The following example contains a process spec and demonstrates how a unit test plan would be developed using the Cyclomatic Complexity Method and then the Conditional Logic Method. Example PROCEDURE SPECIFICATION PROCEDURE NAME: PROCEDURE OBJECTIVE: XXXX RETRIEVE PART NOTE DATA TO OBTAIN FROM THE PART NOTE TABLE THE LATEST YEAR/LATEST SEQUENCE NUMBER PART NOTES.
SPECIFICATIONS OF PROCEDURE: 1 CALL XXX_SELECT_PART_NOTES; (RETURNS AN ARRAY OF ROWS AND COLUMNS THAT MEET THE PARTIAL KEY SPECIFIED) 2 IF PART_NOTES_FOUND 3 4 5 6 7 8 9 10 11 12 13 14 15 END; END; THEN CALL XXXX_FETCH_PART_NOTES; ELSE DO; CALL XXXX_SELECT_DWG_SHEET_ONE_ NOTES; IF DWG_SHEET_NOTES_FOUND THEN CALL XXXX_FETCH_DWG_SHEET_ONE_NOTES; ELSE DO; S_PART_NOTE_CODE = ' '; S_PART_NOTE_NUMBER = (4)' '; IF SYSTEM_LOAD_INDICATOR = 'B' THEN S_PART_NOTE = 'THIS IS A BODY PART'; IF SYSTEM_LOAD_INDICATOR = 'C' THEN S_PART_NOTE = 'THIS IS A CHASSIS PART';
Page: 65
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

CYCLOMATIC COMPLEXITY METHOD: Flowgraph
1 | 2 / \ PART NOTES FOUND 5 3 | \ 6 \ / \DWG SHEET NOTES FOUND 9 7 \ | \ \ 10 \ | | \ = 'B' \ | | 11 | | | / | | 10a | | | | | 12 | | | \ = 'C' | | | 13 | | | / | | 12a | | \ | | \ / | \ / | 6a / \ / \ / 2a | 15
Complexity = #Edges - #Nodes + 2 C = 19 16 + 2 = 5
T1 (baseline) T2 (flip 2) T3 (flip 6) T4 (flip 10) T5 (flip 12)
= = = = =
1, 2, 5, 6, 9, 10, 10a, 12, 12a, 6a, 2a, 15 1, 2, 3, 2a, 15 1, 2, 5, 6, 7, 6a, 2a, 15 1, 2, 5, 6, 9, 10, 11, 12a, 6a, 2a, 15 1, 2, 5, 6, 9, 10, 10a, 12, 13, 12a, 6a, 2a, 15
Page: 66
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

CYCLOMATIC COMPLEXITY METHOD (cont.) +---------------------------------------------------------------+ | (Conditions) | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | 10 SYSTEM_LOAD_INDICATOR = 'B' | +--------------------------------------------+---+---+---+---+--+ | 12 SYSTEM_LOAD_INDICATOR = 'C' | +--------------------------------------------+---+---+---+---+--+ | (Actions) | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | | +--------------------------------------------+---+---+---+---+--+ | | | | +--------------------------------------------+---+---+---+---+--+ S PART_NOTE_NUMBER = (4)' ' | X | | | X | X 9 S PART_NOTE_CODE = ' ' | X | | | X | X 7 CALL XXXX_FETCH_DWG_SHEET_ONE_NOTES | | | X | | 5 CALL XXXX_SELECT_DWG_SHEET_ONE_NOTES | X | | X | X | X 3 CALL XXXX_FETCH_PART_NOTES | | X | | | 1 CALL XXXX_SELECT_PART_NOTES | X | X | X | X | X | F | - | - | F | T | F | - | - | T | F 6 DWG_SHEET_NOTES_FOUND | F | - | T | F | F 2 PART_NOTES_FOUND | F | T | F | F | F |T1 |T2 |T3 |T4 |T5
Page: 67
| 11 THE S_PART_NOTE = 'THIS IS A BODY PART' | |
| X |
+--------------------------------------------+---+---+---+---+--+ | 13 THE S_PART_NOTE = 'THIS IS A CHASS PART'| | ----------------------------------------------------------------| | | | X
Page: 68
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

CONDITIONAL LOGIC METHOD STEP 1 (Identify conditions) CODE A B C D LEVEL 0 1 2 3 PATH F F F CONDITION 2 PART NOTES FOUND 6 DWG SHEET NOTES FOUND 10 SYSTEM LOAD INDICATOR = 'B' 12 SYSTEM LOAD INDICATOR = 'C'
STEP 2 ([Draw binary tree) A B / A \ B \ C \ Level: 0 1 2 D 3 / D / C
STEP 3 (Generate test conditions) 1. A 2. A B 3. A B C 4. A B C D 5. A B C D
Page: 69
TESTING PROCEDURES
DATE: 03/02/87 INDEX: B.5.1

CONDITIONAL LOGIC METHOD (cont.): STEP 4 (Explode test conditions) Test Condition 1: PART NOTES FOUND Test Condition 2: PART NOTES NOT FOUND DWG SHEET NOTES FOUND Test Condition 3: PART NOTES NOT FOUND DWG SHEET NOTES FOUND SYSTEM LOAD INDICATOR = 'B' Test Condition 4: PART NOTES NOT FOUND DWG SHEET NOTES FOUND SYSTEM LOAD INDICATOR = 'C' Test Condition 5: PART NOTES NOT FOUND DWG SHEET NOTES FOUND SYSTEM LOAD INDICATOR not = 'B' SYSTEM LOAD INDICATOR not = 'C'
Page: 70

DATE: 03/02/87 INDEX: B.6.1
Change Control Request (CCR)

PURPOSE: The Change Control Request (CCR) system is a mainframe based DB2 system which will aid the PDS project to track all changes made to the official baseline project design. Each change to the document (coding or documentation) will be submitted to a PDS subsystem team leader. The team leader will enter the change into the system for tracking capabilities. Management reports are generated on an ad-hoc basis. The CCR system is to be utilized anytime a change to the baseline document is needed. The system will also provide historical data to be used in calculating any extra charges which may result if changes occur in PDS. Change Control Reference Manual None None
WHEN UTILIZED:
REFERENCES: NOTES: STANDARD:
Page: 71

PRINTING
DATE: 03/02/87 INDEX: B.7.1
Print Destinations
PURPOSE: WHEN UTILIZED: REFERENCES: NOTES: The most current JCL to print datasets at the Troy print center and at ADAMS Woods will be stored in the 'PBHEN.PDSMA.STDS' datasets in the members (TROYPRNT) and (ADAMPRNT). Route printouts from TSO sessions and batch jobs. Whenever you need to route a print to a remote.
Page: 72
********************************************************************** * NEW STANDARDS * * * A STANDARDS COMMITTEE HAS BEEN PUT TOGETHER TO TRY TO MAKE PDS * * CONSISTENT ACCROSS ALL SUBSYSTEMS. TO ACCOMPLISH THIS THE FOLLOWING* * IS A LIST OF STANDARDS THAT HAVE BEEN DECIDED. IF FOR ANY REASON * * YOUR PROGRAM CAN NOT FOLLOW THE STANDARDS, CHECK WITH YOUR TEAM * * LEADER TO GET THEIR APPROVAL. IF YOU FIND INCONSISTENCIES IN * * PROGRAMS PLEASE NOTIFY YOUR TEAM LEADER. * * * ********************************************************************** *
1. SCROLLING A. IF A DISPLAY HAS NOT BEEN DONE AND PFKEY 7 IS PRESSED, OR KEY DATA IS CHANGED AND PFKEY 7 IS PRESSED, THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 7/19/88 0025 MUST INQUIRE (PRESS ENTER) BEFORE PF7 CAN BE USED B. IF A DISPLAY HAS NOT BEEN DONE AND PFKEY 8 IS PRESSED, OR KEY DATA IS CHANGED AND PFKEY 8 IS PRESSED, THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 7/19/88 0026 MUST INQUIRE (PRESS ENTER) BEFORE PF8 CAN BE USED C. IF PAGING DOWN (PRESSING PFKEY 8) WHEN THE LAST PAGE OF DATA IS DISPLAYED THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 0009 INQUIRY COMPLETE 7/19/88 ** MESSAGES 0043 LAST PAGE - NO MORE DATA TO DISPLAY AND 0010 NO MORE DATA IS AVAILABLE WILL BE DELETED FROM THE MESSAGE TABLE. D. IF PAGING DOWN (PRESSING PFKEY 8) AND THERE IS MORE DATA TO BE DISPLAYED THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 0024 MORE DATA TO DISPLAY, PRESS PF8 TO CONTINUE 7/19/88 E. IF DISPLAY IS ON THE FIRST PAGE OF DATA AND PFKEY 7 IS PRESSED THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 7/19/88 0436 PF7 INVALID - ALREADY AT BEGINNING OF LIST F. IF DISPLAY IS ON THE LAST PAGE OF DATA AND PFKEY 8 IS PRESSED THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 7/19/88 0623 PF8 INVALID - ALREADY ON THE LAST PAGE OF REQUEST G. WHEN THE TOP OF THE DATA IS REACHED BY PRESSING PFKEY 7 THE FOLLOWING MESSAGE SHOULD BE DISPLAYED: 7/21/88 0024 MORE DATA TO DISPLAY, PRESS PF8 TO CONTINUE
Page: 73
** MESSAGE 2037 TOP OF DISPLAY HAS BEEN REACHED WILL BE DELETED. H. WHEN PF8 IS PRESSED THE DATA DISPLAYED ON THE FIRST LINE OF THE NEXT PAGE SHOULD BE THE NEXT LINE OF DATA. DO NOT DISPLAY THE LINE OF DATA FROM THE PREVIOUS PAGE. 7/26/88 I. ON A SCROLLABLE SCREEN WHERE AN 'I' ACTION CODE CAN BE USED ON THE FIRST LINE OF DATA TO START THE INQUIRY ON A SPECIFIC KEY, IF AN ADD IS DONE ON THE FIRST LINE IT SHOULD NOT AFFECT YOUR TOP OR PREVIOUS KEY. 8/8/88
Page: 74
J. ON A SCROLLABLE SCREEN WHERE AN 'I' ACTION CODE CAN BE USED ON THE FIRST LINE OF DATA TO START THE INQUIRY ON A SPECIFIC KEY, IF THE KEY ENTERED IS NOT FOUND THE DATA DISPLAYED SHOULD START WITH THE NEXT KEY GREATER THAN THE KEY ENTERED. THE MESSAGE DISPLAYED SHOULD BE ONE OF THE FOLLOWING: 8/8/88 0009 INQUIRY COMPLETE 0024 MORE DATA TO DISPLAY, PRESS PF8 TO CONTINUE
2. REQUIRED FIELDS A. WHEN A REQUIRED FIELD(S) WAS NOT ENTERED DISPLAY THE FOLLOWING MESSAGE: 0011 FIELD IS REQUIRED 7/19/88 ** MESSAGE 0050 PLEASE ENTER REQUIRED FIELD(S) WILL BE DELETED. *NOTE - THE VERBIAGE IN MESSAGE 0011 MAY BE CHANGED TO MATCH MESSAGE 0050. B. WHEN A '?' IS PLACED IN A REQUIRED FIELD BY A PROGRAM, AND ENTER IS PRESSED, THE PROGRAM SHOULD TREAT BOTH '?' AND SPACE FOR REQUIRED FIELDS AS AN ERROR AND DISPLAY ERROR MESSAGE 0011. 7/19/88
3. SCREEN NAVIGATION A. FROM MEMO DATED 2-26-88 - ISSUE DECISIONS FROM GM AND EDS TEAM MEMBERS: WHEN A SCREEN IS INITIALLY DISPLAYED, ALL FIELDS WILL BE BLANK. IF THE USER PRESSES 'ENTER' WITHOUT PUTTING DATA IN THE REQUIRED FIELDS, THE SCREEN WILL BE RETURNED WITH A '?' IN THEM. 7/19/88 B. WITHIN EACH SUBSYSTEM SCREEN IN A SUBSYSTEM WITHIN THE SUBSYSTEM, MENU IN THE SUBSYSTEM WHEN GOING TO A SUBSYSTEM-MENU FROM A AND THEN FROM THE MENU BACK TO A SCREEN COMMON KEY DATA SHOULD BE PASSED THRU THE PASS AREA. 8/8/88
4. ACTION CODES A. WHEN MULTIPLE ACTION CODES ARE IN ERROR, ALL THE ACTION CODES IN ERROR WILL BE HIGHLIGHTED. 7/19/88 (I.E. MORE THAN 1 'S' ACTION CODE IS ENTERED ON A SCREEN WHERE ONLY 1 IS ALLOWED, ALL THE 'S' ACTION CODES ARE HIGHLIGHTED, CURSOR SET TO THE FIRST 'S' ACTION CODE, AND THE APPROPRIATE ERROR MESSAGE IS DISPLAYED.)
5. UPDATE A. WHEN DOING UPDATES ON A SCREEN WITH MULTIPLE ACTION CODES EACH LINE SHOULD BE PROCESSED INDIVIDUALLY. IF A LINE DOES NOT PASS THE EDITS IT SHOULD BE HIGHLIGHTED, AND THEN CONTINUE TO PROCESS THOSE LINES NOT IN ERROR.
Page: 75
- THE NOTE SCREENS WILL USE THIS STANDARD. - EXCEPTIONS TO THIS STANDARD ARE SCREENS WHICH HAVE DATA THAT NEED INTEGRITY BETWEEN THE LINES, AND SCREENS GOING TO BIT MAP. 7/19/88 B. ON A SCREEN WITH MULTIPLE ACTION FIELDS, IF A LINE HAS AN ERROR THE FIELD IN ERROR AND THE ACTION CODE SHOULD BE HIGHLIGHTED. PUT THE CURSOR ON THE FIELD IN ERROR OR THE ACTION FIELD DEPENDING ING ON THE CONTEXT OF THE ERROR. 7/21/88 7/26/88
Page: 76
6. PFKEY A. ANY PFKEYS THAT GO TO SCREENS THAT ARE NOT YET AVAILABLE SHOULD GIVE THE FOLLOWING MESSAGE WHEN PRESSED: 7/21/88 0430 SELECTED FUNCTION NOT YET AVAILABLE ** MESSAGE 0087 FUNCTION NOT AVAILABLE IN THIS PDS RELEASE WILL BE DELETED. B. WHEN A PFKEY IS PRESSED, KEY FIELDS, WHETHER CHANGED OR NOT, ARE CARRIED TO A NEW TRANSACTION. (EXCEPT PFKEY 7 & 8) 7/21/88
7. HELP A. WHEN RETURNING FROM HELP THE SCREEN SHOULD BE BROUGHT BACK EXACTLY LIKE IT WAS BEFORE GOING TO HELP. - THE ONLY TIME THE MESSAGE SHOULD BE ANY DIFFERENT FROM WHEN YOU LEFT FOR HELP IS FI IT IS MESSAGE: 1601 SCREEN CODE NOT FOUND IN HELP SYSTEM 7/21/88 ** MESSAGE 1600 RETURN FROM HELP SUCCESSFUL WILL BE DELETED B. SCROLLABLE INQUIRY SCRRENS GOING TO HELP AND NOT USING THE SPA MUST STORE THE TOP KEY, CURRENT KEY, AND PREVIOUS KEY IN THEIR SUBSYSTEM SAVE AREA. REINQUIRE ON THE CURRENT KEY. THIS IS NEEDED IN CASE A USER HAS SCROLLED FORWARD AND THEN HAS GONE TO HELP. WHEN RETURNING FROM HELP THE USER SHOULD BE ABLE TO PRESS PFKEY 7 AND SCROLL BACK.
7/21/88
8. INQUIRY A. IF ENTER IS PRESSED ON NON SCROLLABLE SCREENS WITHOUT CHANGING THE KEY FIELDS, ANOTHER INQUIRY SHOULD BE DONE. 7/21/88 **** NOTE **** 9/15/88 THE FOLLOWING STANDARDS HAS BEEN CANCELLED * B. ON A SCROLLABLE SCREEN IF ENTER IS PRESSED WITHOUT CHANGING THE * KEY FIELDS, THEN THE INQUIRY SHOULD START ON THE SAME PAGE THE * USER WAS ON. 7/21/88 * (I.E. IF A USER SCROLLED DOWN TO THE 3RD PAGE AND TRIED TO * UPDATE, AN RECEIVED A MESSAGE THAT AN INTERVENING UPDATE * TOOK PLACE, WHEN HE PRESSES ENTER TO REINQUIRE HE SHOULD * STILL BE ON THE 3RD PAGE.) **************** C. WHEN THE KEY FIELDS ON ALL SCREENS ARE CHANGED AND ENTER IS PRESSED AN INQUIRY IS DONE. IF THERE IS NO DATA FOUND, THE PREVIOUS INQUIRY'S DATA SHOULD BE BLANKED OUT AND AN ERROR MESSAGE DISPLAYED THAT NO DATA WAS FOUND. 7/21/88 D. ON A MULTI-ACTION SCREEN THAT DOES NOT HAVE FIELDS REQUIRED FOR AN INQUIRY, AN 'I' ACTION CODE CAN BE PLACED IN THE ACTION
Page: 77
FIELD ON A BLANK LINE. 9/6/88 E. ON A MULTI-ACTION SCREEN THAT DOES HAVE REQUIRED FIELDS, AN 'I' CANNOT BE PLACED IN THE ACTION FIELD ON A BLANK LINE. ONE OF THE FOLLOWING MESSAGES SHOULD BE DISPLAYED: 9/6/88 IF REQUIRED FIELDS WERE ENTERED: 0001 CONFLICTING ACTION - ONLY SELECTION, PFKEY, OR SCREEN CHANGE ALLOWED IF REQUIRED FIELDS WERE NOT ENTERED: 0011 FIELD IS REQUIRED
Page: 78
F. ON AN UPDATE SCREEN WITH ONLY ONE ACTION CODE, YOU MUST DO AN INQUIRY BEFORE EVERY CHANGE OR BEFORE A DELETE. 10/20/88
9. PRINT A. DATA DOES NOT HAVE TO BE DISPLAYED ON THE SCREEN BEFORE USING THE PRINT FUNCTION. 7/21/88 ** MESSAGE 2031 INQUIRY REQUIRED BEFORE PRINT WILL BE DELETED. B. WHEN A REPORT IS SUBMITTED TO PRINT ONE OF THE FOLLOWING MESSAGES SHOULD BE DISPLAYED: 7/21/88 2004 REPORT SENT TO IMS PRINTER, CHECK STATUS SCREEN FOR RESULTS 2005 REPORT SENT TO PRINT CENTER, CHECK STATUS SCREEN FOR RESULTS ** MESSAGES 2039 BACKGROUND PRINT INITIATED 0830 REPORT REQUEST SUBMITTED WILL BE DELETED C. NOT EVERY SCREEN THAT SCROLLS WILL PRINT. 7/21/88
D. AFTER ENTERING THE PRINT INDICATOR, ENTER MUST BE PRESSED. PRESSING A PFKEY OR ENTERING A SCREEN CODE WILL BE AN ERROR. 7/21/88 E. IF KEY DATA IS CHANGED, CLEAR ANY DISPLAYED NON KEY DATA AND ISSUE APPROPRIATE PRINT MESSAGE. IF KEY DATA IS NOT CHANGED, SIMPLY REDISPLAY DATA AND ISSUE APPROPRIATE PRINT MESSAGE. 7/21/88 F. THE MAXIMUM LINES PER PAGE FOR A REPORT IS 60. PRINT CENTER AND AN IMS PRINT. 8/8/88 G. THE VALID PRINT FIELDS ARE 'C', 'L', AND '?'. THIS IS FOR THE
8/15/88
H. WHEN YOU GO TO THE PRINTER SELECTION SCREEN AND DO NOT PICK A PRINTER, AND PF3=PREV SCRN BACK, ONE OF THE FOLLOWING MESSAGES SHOULD BE DISPLAYED: 8/15/88 0073 NO LOCAL IMS PRINTER SELECTED 0074 NO PRINT CENTER/DISTRIBUTION POINT SELECTED I. SELECTING A TEMPORARY PRINTER FROM THE PRINTER SELECTION SCREEN IS ONLY GOOD FOR THE DURATION OF THE ONE PRINT REQUEST. 8/15/88 J. EDIT AN VALIDATE KEY FIELDS BEFORE DOING AN IMS PRINT OR PUTTING OUT A PRINT REQUEST. 8/15/88 K. AN IMS PRINT HAS A 25 PAGE LIMIT. THIS MEANS 25 PAGES OF DATA SHOULD BE PRINTED AND THE 26TH PAGE SHOULD HAVE THE FOLLOWING MESSAGE DISPLAYED: 9/6/88 'REPORT TOO LONG' L. WHEN A USER REQUESTS A REPORT THAT WILL BE RUN THAT NIGHT, WHEN
Page: 79
THE REQUEST IS MADE A CHECK SHOULD BE DONE TO MAKE SURE THERE IS DATA FOUND FOR THE REPORT. IF THE DATA IS DELETED AFTER THE REQUEST WAS MADE THE REPORT RUNNING AT NIGHT SHOULD NOT ABEND, THE REPORT SHOULD STATE THAT NO DATA WAS FOUND. THE STATUS IN THE JOB STATUS LOG SHOULD SAY 'COMPLETED'. 9/6/88 M. AFTER PAGING FORWARD ON A SCREEN AND THEN USING THE PRINT FUNCTION, THE PRINT WILL START FROM THE ORIGINAL INQUIRY, ON THE FIRST PAGE. 9/15/88
Page: 80
10. SELECTION A. IF PF3=PREV SCRN IS PRESSED WHEN PASSING DATA FROM A SCREEN USING AN 'S' ACTION CODE, THE DATA SHOULD BE PASSED THROUGH THE SPA DATABASE. 7/21/88 B. USING AN 'S' ACTION CODE WITH AN INVALID PFKEY SHOULD RETURN THE FOLLOWING MESSAGE: 7/26/88 2048 ILLEGAL PFKEY TO USE WITH AN 'S' ACTION CODE C. WHEN DATA IS SELECTED (WITH AN 'S' ACTION) IF THE DATA BEING SELECTED HAS BEEN TYPED OVER WITH NEW DATA, THE NEW DATA IS CARRIED WHEN GOING TO THE NEXT SCREEN. 9/15/88 D. ON AN INQUIRY SCREEN, LINES THAT CANNOT BE SELECTED WITH AN 'S' ACTION CODE SHOULD HAVE THE ACTION CODE PROTECTED. 9/29/88
NOTE - EACH TIME YOU GO FROM THE SCREEN TO YOUR PROGRAM THE ATTRIBUTES DEFAULT TO HOW THE MFS HAS THEM DECLARED AND THE ACTION CODES HAVE TO BE PROTECTED AGAIN.
11. EDITING A. PERFORM ALL SYNTAX EDITS AND THEN GO DO VALIDATIONS ON A FIELD TO FIELD BASIS. DO EDITING FROM LEFT TO RIGHT, TOP TO BOTTOM. 7/26/88 REWORDED 9/14/88 B. WHEN ENTERING MODEL YEAR, IF A SINGLE DIGIT YEAR IS ENTERED, IT SHOULD BE RIGHT JUSTIFIED AND ZERO FILLED. THE YEAR SHOULD BE RETURNED TO THE SCREEN RIGHT JUSTIFIED AND ZERO FILLED, I.E. IF THE YEAR '5' IS ENTERED, IT SHOULD NOT MATTER WHICH OF THE 2 POSITIONS IT IS ENTERED IN. IT SHOULD BE RETURNED TO THE SCREEN AS '05'. 8/8/88 C. DO NOT DIM DATA WHEN AN ERROR MESSAGE IS DISPLAYED BUT THERE IS NO DATA IN ERROR. 8/15/88 I.E. ON A SCROLLABLE SCREEN, IF THE LAST PAGE OF DATA IS DISPLAYED AND PF8 IS PRESSED AGAIN, THE DATA ON THE SCREEN SHOULD NOT BE DIMMED WHEN MESSAGE 0623 IS DISPLAYED. D. FIELDS ON THE SCREEN SHOULD BE (LEFT/RIGHT) JUSTIFIED AND FILLED BEFORE COMPARING TO SEE IF THE FIELDS HAVE CHANGED (COMPARING AGAINST HIDDEN FIELDS). 9/15/88
12. DELETE A. WHEN PERFORMING A DELETE ON A SCREEN WITH A SINGLE ACTION CODE, THE FIELDS BEING DELETED SHOULD NOT BE BLANKED OUT AND THE SCREEN SHOULD RETURN WITH THE FOLLOWING MESSAGE: 7/26/88 0098 DELETE PROCESSING HAS BEEN COMPLETED
Page: 81
B. WHEN PERFORMING A DELETE ON A SCREEN WITH MULTIPLE ACTION CODES, THE LINE OF DATA VEING DELETED SHOULD BE BLANKED OUT AND THE SCREEN SHOULD RETURN WITH THE FOLLOWING MESSAGE: 7/26/88 0002 PROCESSING COMPLETE
13. CHANGE A. WHEN A 'C' ACTION CODE IS ENTERED AND NO CHANGE HAS BEEN MADE DISPLAY THE FOLLOWING MESSAGE: 7/26/88 0037 NO DATA HAS BEEN CHANGED
Page: 82
14. SCREEN CODE A. WHEN 'STATUS' IS ENTERED INTO THE SCREEN CODE FIELD TO GO TO THE JOB STATUS LOG SCREEN, CALL #9100_PGM_TO_PGM_SWITCH INSTEAD OF #9000_SEND_MESSAGE_TO_TERMINAL. THE USERS JOB STATUS LOG WILL THEN BE DISPLAYED WHEN THE SCREEN IS DISPLAYED INSTEAD OF THE USER HAVING TO PRESS ENTER. 8/8/88 B. WHEN USING THE DISTRIBUTION SCREEN CODE 'NOFIFY' AND CANNOT RETURN, DISPLAY THE FOLLOWING MESSAGE: 8/15/88 0112 CANNOT RETURN TO PDS DISPLAY NOTIFICATIONS ** DELETING THE FOLLOWING MESSAGE 2014 UNABLE TO RETURN TO DISTRIBUTION NOTIFICATION
15. TRANSACTION DATA BASE A. WHEN STORING OLD AND NEW DATA ON THE TRANSACTION DATA BASE, IF A DELETE IS DONE PUT THE DATA & TIME, PROGRAM ID, AND USERID OF THE DELETE IN THE OLD DATA. NEW DATA IS NOT NEEDED. 8/15/88
B. WHEN WRITING TO THE TRANSACTION DATA BASE AND YOU NEED TO WRITE OUT MORE THAN ONE TABLE, THEY SHOULD ALL HAVE THE SAME DATETIME STAMP. 10/20/88
16. TEST PLAN A. THE FOLLOWING TEST PLANS SHOULD BE USED: 'TBHEN.PDSOT.STDS(OLTSTPLN)' - ONLINE PROGRAM 'TBHEN.PDSOT.STDS(BTTSTPLN)' - BATCH PROGRAM 8/15/88
B. A CHECK LIST OF STANDARDS AND EDITS HAS BEEN CREATED TO ADD TO YOUR TEST PLAN. IT IS IN 'TBHEN.PDSOT.STDS(STTSTPLN)'. 10/7/88
17. JCL A. THE STANDARD NAME FOR A PROC IS BHEAD2XY. B. THE STANDARD NAME FOR A JOB IS BHEND2XY. NOTE - X = SYSTEM BATCH CODE Y = SEQUENCE NUMBER/LETTER C. BEFORE EVERY JOB AND PROC STEP THERE SHOULD BE A FLOWER BOX WITH A DESCRIPTION OF WHAT THE STEP DOES AND RESTART INSTRUCTIONS IF AN ABEND OCCURS IN THAT STEP. 10/7/88 D. KEEP TEST JCL IN CHAMP UNDER A SIMILAR PRODUCTION NAME, CHANGE THE D2 TO T2. FOR EXAMPLE PRODUCTION JCL BHEND2RH WOULD HAVE TEST JCL IN CHAMP UNDER BHENT2RH. 10/20/88 9/6/88 9/6/88
Page: 83
18. BATCH A. NEW BATCH PROGRAMS SHOULD DISPLAY ANY COUNTS AND SOFT ERROR MESSAGES IN THE SYSOUT OF THE PROGRAM AND NOT IN AN ERROR FILE. 9/15/88 B. IN NEW BATCH PROGRAMS INSTEAD OF MOVING THE PROC NAME TO A WORKING STORAGE FIELD AT THE BEFINING OF EACH PROC, USE THE BUILTIN FUNCTION 'ONLOC'. THE ONLOC FUNCTION WILL RETURN A CHARACTER STRING WHICH WILL CONTAIN THE NAME OF THE PROCEDURE IN WHICH THE ON CONDITION AROSE. IT CAN BE USED TO CREATE AN ERROR MESSAGE IN THE ON ERROR BLOCK. 9/15/88 IE. W_MSG_AREA = '-ERROR IN PROCEDURE ' ]] ONLOC; PUT SKIP DATA (W_MSG_AREA);
Page: 84
C. IN A BATCH STREAM IF A PROGRAM HAS NO INPUT, SET A RETURN CODE (COND CODE) OF 02 IN THE PROGRAM. SUBSEQUENT JOB STEP OR PROCS WHICH ARE DEPENDENT ON OUTPUT FROM THE PROGRAM SHOULD BE BYPASSED BY USING COND PARAMETERS. THIS WAY NO OPERATOR INTERVENTION IS REQUIRED AN THE JOB FINISHES SUCCESSFULLY. UNNECESSARY JOB STEPS ARE NOT PROCESSED. 9/29/88
19. CHECKPOINT RESTART A. ANY BATCH PROGRAM THAT DOES UPDATES OR A PROGRAM THAT RUNS OVER 1 HOUR SHOULD HAVE CHECKPOINT RESTART. 9/29/88
20. MFSA. DO NOT USE THE MFS TO DO NUMERIC EDITING; PERFORM ALL EDITS IN THE PROGRAM. MFS ATTRIBUTES ARE HIGHLY TERMINAL SPECIFIC AND COULD CAUSE SOME TERMINALS TO LOCK UP. I.E. DON'T SET AN MFS FIELD FOR 'MODEL YEAR' TO ATTR=NUM; LEAVE IT AS CHARACTER AND EDIT FOR NUMERICS IN THE PROGRAM. 9/29/88
21. ONLINE A. THE 'ONLOC' BUILTIN FUNCTION THAT WAS DESCROBED IN A PREVIOUS STANDARD TO USE FOR BATCH PROGRAMS SHOULD ALSO BE USED IN ANY NEW ONLINE PROGRAMS. BY USING 'ONLOC' YOU DON'T HAVE TO SET W_SYS_ERR_PROC_NAME IN EVERY PROC. THE ONLINE SKELETON PROGRAM WILL BE CHANGED TO DO THIS. 10/7/88 B. IF YOU ARE HIGHLIGHTING THE NOTES PFKEY WHEN THERE ARE NOTES TO DISPLAY, ONLY HIGHLIGHT THE PFKEY FOR PERMANENT AND TEMPORARY NOTES. DO NOT HIGHLIGHT IF THERE ARE ONLY GENERATED NOTES. 10/20/88
22. SECURITY A. WHEN RETURNING FROM THE SECURITY SCREEN, IF A USER WAS NOT FOUND IN THE SECURITY DATA BASE GIVE THE MESSAGE 'USER DOES NOT HAVE UPDATE AUTHORITY' CONCATENATED WITH THE FIELDS YOUR SCREEN PASSED TO THE SECURITY ROUTINE. THE FOLLOWING IS AN EXAMPLE: 'USER DOES NOT HAVE UPDATE AUTHORITY DIV = 4 MY = 90 PROD = H' DO NOT GIVE THE MESSAGE 'USER NOT FOUND'. THIS IS FROM A MEMO ON SECURITY MESSAGES FROM JACK PATTON DATED JUNE 17, 1988. 10/20/88
Page: 85

PL I Standards

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PL I Standards

Transféré par

Droits d'auteur :

Formats disponibles

PL/1 Programming Standards

PROCEDURES AND TECHNICAL FACILITIES........................................................43

NASTEC CASE/2000 DesignAid ........................................................................................................50 Easytrieve Plus ......................................................................................................................................51

PROJECT MANAGEMENT AND PLANNING.....................................................................52

SYSTEM DESIGN METHODOLOGY....................................................................................53

Comments: Changed all 'P _D _S _ STEP' on 07/31/91 - PDSJCDB.

_S _T _E _P _' etc to 'PDS

TABLE OF CONTENTS BREAKDOWN

DB2 Data Structures

STANDARD: Option structure

DB2 NAMING CONVENTIONS

DB2 Object Names

T - Tables and Tablespace X - Indexes

DB2 NAMING CONVENTIONS

DB2 Object Names

T - Tables and Tablespace X - Indexes

NAMING CONVENTIONS IMS NAMING CONVENTIONS

IMS-MFS Naming Conventions

IMS NAMING CONVENTIONS

IMS-MFS Naming Conventions

IMS NAMING CONVENTIONS

IMS NAMING CONVENTIONS

Program Status Block Names

NAMING CONVENTIONS MVS NAMING CONVENTIONS

MVS NAMING CONVENTIONS

Application Program Names

Refer to page C3D.001 VOL 5 or Appendix A for additional Type Codes

MVS NAMING CONVENTIONS

Application Program Names

Sequential ID#: indicator

MVS NAMING CONVENTIONS

WHEN UTILIZED: REFERENCES: NOTES:

MVS NAMING CONVENTIONS

System Title: Date: Header-line 2

Subsystem Title: Subsystem & screen name Time: Current time

SCREEN DESIGN STANDARDS

DESIGN STANDARDS SCREEN DESIGN STANDARDS

the Error is not

DESIGN STANDARDS SCREEN DESIGN STANDARDS

DESIGN STANDARDS SCREEN DESIGN STANDARDS

Batch Report Layout

REPORT LAYOUT STANDARDS

Batch Report Layout

RUN DATE: 09/09/87 TIME: PAGE NUMBER:23 SEQ: 9999

END OF REPORT or NO DATA ON THIS REPORT

PL/1 PROGRAMMING STANDARDS

Variable Names and Usage

PL/1 PROGRAMMING STANDARDS

Procedure and INCLUDE Members

An INCLUDED member must not contain any %INCLUDE statements.

PL/1 PROGRAMMING STANDARDS

On-line Processing Standards

PL/1 PROGRAMMING STANDARDS

On-line Processing Standards

PL/1 PROGRAMMING STANDARDS

PL/1 PROGRAMMING STANDARDS

PL/1 PROGRAMMING STANDARDS

WHEN UTILIZED: REFERENCES: NOTES: STANDARDS:

PROGRAMMING STANDARDS PL/1 PROGRAMMING STANDARDS

WHEN UTILIZED: REFERENCES: NOTES: STANDARD:

On-line Programs - 'PBHEN.PDSMA.STDS(SKELONLN)' MFS Definitions - 'PBHEN.PDSMA.STDS(SKELMFS)'

PROGRAMMING STANDARDS PL/1 PROGRAMMING STANDARDS

Error Message Numbers