Pl i Standards

PL/1 Programming

Standards

Document Summary:.......................................................................................................

TABLE OF CONTENTS BREAKDOWN.........................................................................

INTRODUCTION.............................................................................................................

PROJECT STANDARDS..................................................................................................

NAMING CONVENTIONS.......................................................................................................DB2 NAMING CONVENTIONS...........................................................................................................

DB2 Data Structures...........................................................................................................................DB2 Object Names.............................................................................................................................

IMS NAMING CONVENTIONS............................................................................................................IMS-MFS Naming Conventions..........................................................................................................Transaction Codes..............................................................................................................................Program Status Block Names..............................................................................................................

MVS NAMING CONVENTIONS..........................................................................................................Job Names..........................................................................................................................................Application Program Names...............................................................................................................Dataset Names....................................................................................................................................Report Names.....................................................................................................................................

DESIGN STANDARDS..............................................................................................................SCREEN DESIGN STANDARDS..........................................................................................................

Screen Formats...................................................................................................................................Error Processing.................................................................................................................................Cursor Positioning..............................................................................................................................PF Key Usage.....................................................................................................................................

REPORT LAYOUT STANDARDS........................................................................................................Batch Report Layout...........................................................................................................................

PROGRAMMING STANDARDS.............................................................................................PL/1 PROGRAMMING STANDARDS..................................................................................................

Program Style.....................................................................................................................................Variable Names and Usage.................................................................................................................Procedure and INCLUDE Members....................................................................................................On-line Processing Standards..............................................................................................................DB2 Considerations............................................................................................................................Program Documentation.....................................................................................................................Program Skeletons..............................................................................................................................Error Message Numbers......................................................................................................................

REVIEW STANDARDS............................................................................................................Walkthrough and Peer Reviews..........................................................................................................Lifecycle Reviews..............................................................................................................................

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

TECHNICAL FACILITIES FOR DEVELOPMENT AND SUPPORT..................................Champ................................................................................................................................................TSO/SPF............................................................................................................................................

DB2........................................................................................................................................................DB2I...................................................................................................................................................DB2/QMF...........................................................................................................................................

IMS........................................................................................................................................................IMS - BTS..........................................................................................................................................IMS - DC............................................................................................................................................

Page: 2

IMS - MFS..........................................................................................................................................PRODUCTIVITY TOOLS......................................................................................................................

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

PROJECT MANAGEMENT AND PLANNING.......................................................................ARTEMIS Project Tracking................................................................................................................

SYSTEM DESIGN METHODOLOGY.....................................................................................STRUCTURED ANALYSIS AND DESIGN..........................................................................................

Data Flow Diagrams...........................................................................................................................Structure Charts..................................................................................................................................Pseudocode.........................................................................................................................................Process Specifications.........................................................................................................................Data Modeling....................................................................................................................................

TESTING PROCEDURES........................................................................................................Unit Testing Procedures......................................................................................................................Change Control Request (CCR)..........................................................................................................

PRINTING.................................................................................................................................Print Destinations...............................................................................................................................

1. SCROLLING -...................................................................................................................................2. REQUIRED FIELDS -........................................................................................................................3. SCREEN NAVIGATION -.................................................................................................................4. ACTION CODES -.............................................................................................................................5. UPDATE -..........................................................................................................................................6. PFKEY -.............................................................................................................................................7. HELP -...............................................................................................................................................8. INQUIRY -.........................................................................................................................................9. PRINT -..............................................................................................................................................10. SELECTION -..................................................................................................................................11. EDITING -.......................................................................................................................................12. DELETE -........................................................................................................................................13. CHANGE -.......................................................................................................................................14. SCREEN CODE -.............................................................................................................................15. TRANSACTION DATA BASE -......................................................................................................16. TEST PLAN -...................................................................................................................................17. JCL -................................................................................................................................................18. BATCH -..........................................................................................................................................19. CHECKPOINT RESTART -.............................................................................................................20. MFS-................................................................................................................................................21. ONLINE -.........................................................................................................................................22. SECURITY -....................................................................................................................................

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 _ _S _T _E _P _' etc to 'PDS STEP' on 07/31/91 - PDSJCDB.

Page: 4

TABLE OF CONTENTS BREAKDOWNi. INTRODUCTIONA. 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 TABLE OF CONTENTS (cont.)A. PROJECT STANDARDS (Cont.) 4.0 REVIEW STANDARDS 4.1 Walkthrough and Peer Reviews 4.2 Lifecycle Reviews 5.0 SECURITY B. 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

Page: 6

TABLE OF CONTENTS (cont.) 3.0 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 4.0 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 6.0 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

TABLE OF CONTENTS (cont.) 6.0 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 7.0 PRINTING

7.1 Print Destinations 7.2 Print Fonts 7.3 3800 Laser Printing 8.0 3270 AND PC PROCEDURES 8.1 GMNET/EDSNET 8.2 Communicating with the 3270 Series 8.3 Communicating with the Host from a PC 9.0 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

Page: 8

TABLE OF CONTENTS (cont.) 10.0 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 ProjectC. APPENDIX A. EDS VOLUME FIVE NAMING STANDARDS B. SELC CODING STANDARDS FOR ALL LANGUAGES SELC PL/I CODING STANDARDS

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 manualscan 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 toserve 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 systemdesign 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: Ensure that all data structure names follow the PDS data dictionary assignment which will prevent

creating a number of aliases for each data structure.

WHEN UTILIZED: Whenever naming a data structure within a PL/I program. REFERENCES: IBM DB2 Application Programming Guide for TSO; Appendix A and B.

NOTES: All DCLGENs (an alternative to writing out DECLARE statements in COBOL or PL/I programs) must be performed by

the PDS Development Support.

STANDARD: The DCLGEN utility, Option "2" from the DB2I Primary Option Menu should be used to generate all program DB2 data

structure names.

Page: 11


DATE: 8/27/87 INDEX: A.1.1.2

DB2 Object Names

PURPOSE: Standardize naming conventions for PDS in order to assign each DB2 Object a unique identifier.

WHEN UTILIZED: Naming all tablespaces, tables and indexes. REFERENCES: EDS Volume 5 Standards Manual (See Appendix A) NOTES: Table names are assigned by PDS Development Support. STANDARD: The following are the PDS standards for naming DB2 objects:

a) Step 1:

Object Type Pos 1 Table Space Number Pos 2 thru 4 Partition/Table Number Pos 5 thru 6 Index Number Pos 7

Object Type: 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: T00101 - Tablespace 1 T00301 - Tablespace 3

Tables: T00101 - Table 1, Tablespace 1 T00102 - Table 2, Tablespace 1

Indexes: X00101 - Table 1, Index 1 X001012 - Table 1, Index 2

Page: 12


DATE: 8/27/87 INDEX: A.1.1.2

DB2 Object Names

b) Step 2:

Object Type Pos 1 Table Space Number Pos 2 thru 4 Partition/Table Number Pos 5 thru 6 Index Number Pos 7

Object Type: 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: T20101 - Step 2 Tablespace 1 T20201 - Step 2 Tablespace 2

Tables: T20101 - Step 2 Table 1, Tablespace 1 T20102 - Step 2 Table 2, Tablespace 1

Indexes: 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: Standardize naming conventions for PDS in order to assign each MID/MOD and DIF/DOF a unique identifier which is

coordinated with the application program name.

WHEN UTILIZED: Naming all MID/MODs and DIF/DOFs.

REFERENCES: See A.1.3.2 - Application Program Names

NOTES: The PDS Subsystem and Sequential ID# must match those assigned to the application program.

STANDARD: The following are the PDS standards for IMS-MFS naming conventions. The MOD name is the same as the source MFS

name. These follow the same format as those outlined in A.1.3.2 - Application Program Names.

MID/MOD System Name Pos 1 thru 3 MFS Objects Pos 4 PDS Subsystem Pos 5 Sequential ID# Pos 6 thru 7

DIF/DOF System Name Pos 1 thru 3 PDS Subsystem Pos 4 Sequential ID# Pos 5 thru 6

MID/MOD

System Name: PDS for Step 1 PD2 for Step 2

MFS Objects: I - MID U - MOD

PDS Subsystem: See A.1.3.2 - ApplicationProgram Names

Sequential ID#: See A.1.3.2 - ApplicationProgram Names

Page: 14


DATE: 9/25/87 INDEX: A.1.2.1

IMS-MFS Naming Conventions

DIF/DOF


PDS Subsystem: See A.1.3.2 - Application Program Names

Sequential ID#: See A.1.3.2 - Application Program Names

EXAMPLE

Step 1 Step 2

Member - PDSUN01 PD2UN01 MID - PDSIN01 PD2IN01 MOD - PDSUN01 PD2UN01 DIF/DOF - PDSN01 PD2N01

Page: 15


DATE: 8/27/87 INDEX: A.1.2.2

Transaction Codes

PURPOSE: Standardize naming conventions for PDS in order to assign each Transaction Code a unique identifier which is coordinated

with the application program name.

WHEN UTILIZED: Whenever naming or accessing a PDS Transaction.


NOTES: A list of current generated IMS program status block names is in dataset 'PBHEN.PDSMA.STDS(IMSGEN)'.

STANDARD: 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 Pos 1 thru 3 Transaction Type Pos 4 PDS Subsystem Pos 5 Sequential ID# Pos 6 thru 7


Transaction Type: I - Inquiry U - Update

PDS Subsystem: See A.1.3.2 - Application Program Names

Sequential ID#: See A.1.3.2 - Application Program Names

Page: 16


DATE: 9/25/87 INDEX: A.1.2.3

Program Status Block Names

PURPOSE: Index for IMS Application Program Names

WHEN UTILIZED: Whenever naming or accessing a PDS program status block.


NOTES: A list of current generated IMS program status block names is in dataset 'PBHEN.PDSMA.STDS(IMSGEN)'.

STANDARD: 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: The PDS naming conventions for job names are designed to provide consistent and unique names which adhere to EDS standards.

WHEN UTILIZED: Whenever creating a PDS batch job.

REFERENCES: EDS User's Guide; Volume 5 (IPC Guide) (See Appendix A)

NOTES: All PDS production batch job names should begin: 'BHENDS'.

STANDARD: All job names must conform to EDS Volume 5 Standards Manual (Chapter 3).

Page: 18


DATE: 8/27/87 INDEX: A.1.3.2

Application Program Names

PURPOSE: Standardize naming conventions for PDS in order to assign each application program a unique identifier.

WHEN UTILIZED: Naming all on-line and batch programs.

REFERENCES: EDS Volume 5 Standards Manual (See Appendix A)

NOTES: Do not randomly assign a sequential identifier. This should be controlled by each subsystem through the PDS Development

Support Group.

STANDARD: The following are the EDS Volume 5 standards for application naming conventions used in conjunction with PDS naming

conventions. For further clarification, please consult with EDS Volume 5 and your EDS supervisor.

System Name Pos 1 thru 3 Type Code Pos 4 PDS Subsystem Pos 5 Sequential ID# Pos 6 thru 7


Type Code: 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

Sequential ID#: 00 - 99

For a given subsystem, use each sequential ID# within the first PDS Subsystem indicator before continuing with the next PDS Subsystem indicator.

EXAMPLE: P D S P N 0 0 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.

WHEN UTILIZED: Whenever creating a PDS global dataset.

REFERENCES: EDS Volume 5 (IPC Guide) (See Appendix A)

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

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

Page: 21


DATE: 8/27/87 INDEX: A.1.3.4

Report Names

PURPOSE: To assign report names which easily associate the reports with the programs generating them.

WHEN UTILIZED: Whenever naming a report generated in a PDS program.

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 Pos 1 thru 3 Type Code Pos 4 PDS Subsystem Pos 5 Sequential ID# Pos 6 thru 7 Report Number Pos 8 thru 9 Filler Pos 10

System Name: PDS for Step 1

Type Code: P

PDS Subsystem: Refer to A.1.3.2 - Application Program Names.

Sequential ID# 00-99 Number assigned within the Subsystem.

Report Number Blank if the program generates only one report; 00-99 for multiple reports.

Page: 22

PROJECT STANDARDS

DESIGN STANDARDS

SCREEN DESIGN STANDARDS

DATE: 8/27/87 INDEX: A.2.1.1

Screen Formats

PURPOSE: To ensure that all screens within PDS have uniform formats.

WHEN UTILIZED: When a PDS screen is being designed or altered.

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.

System Title: Product Description System

Date: Current 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).


PF Key Description. Lists subsystem function keys On menu screens, lists PF Keys to other subsystems.


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

DESIGN STANDARDSSCREEN DESIGN STANDARDS

DATE: 9/09/87 INDEX: A.2.1.2

Error Processing

PURPOSE: This standard ensures that all PDS screens handle errors in a uniform manner.


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

error.

4. A question mark, '?', will appear in each field that is required but not entered. '?' will be processed as if the user left the

field blank.

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

the Error Message Coordinator's responsibility to ensure that there is not 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.

Page: 25


DATE: 9/09/87 INDEX: A.2.1.3

Cursor Positioning

PURPOSE: This standard ensures that all screens position the cursor on PDS screens in a uniform manner.


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.

Page: 26


DATE: 12/02/87 INDEX: A.2.1.4

PF Key Usage

PURPOSE: This standard ensures that PF Keys for all PDS screens will be processed in a uniform manner.


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 - A standard error message should appear whenever this key is pressed in step 1. A generic error message is in the error message

table - T00205.

PF2 - This key will transfer the user to the pertinent subsystem menu.

PF4 - This key will transfer the user to the PDS Main Menu.

PF7 - This key will display the initial screen that was requested when the paging function was initiated.

PF8 - This key will display more available data if it exists.

Page: 27

PROJECT STANDARDSDESIGN STANDARDS

REPORT LAYOUT STANDARDS

DATE: 9/09/87 INDEX: A.2.2

Batch Report Layout

PURPOSE: To ensure that all batch PDS reports have a uniform format.

WHEN UTILIZED: When a PDS report is being designed or altered.

REFERENCES:

NOTES:

STANDARD: The following standards have been designed for batch reports:

Header-line 1

Report Name - Ten character report name (See A.1.3.4 - Report Names) System Name - Product Description System Run Date - Date the job was executed

Header-line 2

Subsystem Name - Subsystem name Time - Time the report was executed

Header-line 3

Report Title - Full report name Page Number - Number of the page printed

Header-line 4

Platform IDs - All Platforms which are contained on the report

Sequence Number- Report 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 RUN DATE: 09/09/87 SUBSYSTEM NAME TIME: 22:12:00 REPORT TITLE PAGE NUMBER:23 C/H PLATFORM CHASSIS SEQ: 9999

END OF REPORTor

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: To ensure uniform and maintainable code.

WHEN UTILIZED: Whenever creating or modifying a PL/I code.

REFERENCES: Software Engineering Life Cycle (SELC) Manual

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.

Page: 31


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_ accumulators

C_ constants

S_ switches, indicators

W_ work fields

P_ print lines

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

2. 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 - initialization 3000s - main processing functions 4000s - edits 5000s-8000s - programmer-defined 9000s - finalization 9999 - abort XXXX - Checkpoint/Restart

On-line list:

#1000 INITIALIZE - initialize each message #1025 COPY MID TO MOD - copy all MID fields to MOD #3000 PROCESS ONE MESSAGE - main logic for each message #3100 PROCESS PFKEY - perform action for PF Key #3125 PROCESS SCREEN CHANGE - logic for screen jump #3200 PROCESS ADD - database add processing #3400 PROCESS CHANGE - database change processing #3600 PROCESS DELETE - database delete processing #3700 PROCESS INQUIRY - database inquiry processing #3800 MOVE DATA TO MOD - copy database fields to MOD #4000 EDIT KEY - edit screen key fields #4100 EDIT DATA - edit screen data fields #9000 SEND MESSAGE - send MOD/create pgm switch #9800 SET MESSAGE - flag an error, get msg text

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

WHEN UTILIZED: Whenever a new code is being developed or maintained.

REFERENCES: SELC MANUAL

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.

WHEN UTILIZED: Whenever a new code deliverable is being developed.

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.

WHEN UTILIZED: Whenever adding an error message to PDS

REFERENCES:

NOTES: Common error messages are contained in the dataset: 'PBHEN.PDSMA.STDS(MESSAGES)'

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

WHEN UTILIZED: Throughout each phase of the development lifecycle

REFERENCES: SELC Manual PDS Software Quality Assurance Plan

NOTES:

STANDARD: For a minimum, the following reviews must be conducted during the development and maintenance process:

o Managerial Walkthroughs o Code Walkthroughs o Test Readiness Review o Documentation Reviews o Lifecycle Reviews

Page: 41

REVIEW STANDARDS

DATE: 09/10/87 INDEX: A.4.2

Lifecycle Reviews

PURPOSE: These reviews are checkpoints in the development of PDS.

WHEN UTILIZED: At the end of each phase of the lifecycle (for each deliverable).

REFERENCES: SELC Manual PDS Software Quality Assurance Plan

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.

o BUSINESS DESIGN REVIEW (BDR) - held to evaluate whether the Business Design Document meets the PDS Requirements.

o TECHNICAL DESIGN REVIEW (TDR) - held to determine the acceptability of the PDS detailed design in satisfying the PDS requirements.

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

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.

WHEN UTILIZED: For all PDS developed source members.

REFERENCES: Champ User's Manual.

NOTES: None

Page: 43


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.

WHEN UTILIZED: Program development and testing

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

Page: 44


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: Data Base development, program development and testing

REFERENCES: Appendix A and B of IBM DB2 Application Programming Guide for TSO

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


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.

WHEN UTILIZED: Data Base development, program development, testing and ad hoc reporting.

REFERENCES: IBM Query Management Facility: User's Guide and Reference Manual.

IBM Query Management Facility: Learner's Guide

NOTES: None

Page: 46


IMS

DATE: 03/02/87 INDEX: B.1.4.1

IMS - BTS

PURPOSE: Tool used to test IMS/VS-DC programs.

WHEN UTILIZED: Program Development and Testing.

REFERENCES: IMS-BTS User's Manual.

NOTES: The IMS-BTS User Manual will be stored in the PDS Documentation Library. It is currently on order.

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


IMS

DATE: 03/02/87 INDEX: B.1.4.2

IMS - DC

PURPOSE: Teleprocessing Facility

WHEN UTILIZED: On-line Transaction Processing

REFERENCES: IMS-DC User's Manual.

NOTES:

Page: 48


IMS

DATE: 03/02/87 INDEX: B.1.4.3

IMS - MFS

PURPOSE: IMS-MFS is the screen format facility used with IMS-DC.

WHEN UTILIZED: On-line Transaction Processing

REFERENCES: IMS-MFS User's Manual.

NOTES: A skeleton for an IMS-MFS program exists in the dataset: 'PBHEN.PDSMA.STDS(SKELMFS)'.

Page: 49


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.

WHEN UTILIZED: This tool should be used to create all data flow diagrams and structure charts for the PDS project.

REFERENCES: Full documentation includes a set of three user manuals (GraphiText, Design Dictionary, and Design Analyzer).

NOTES: Features of this tool includes leveling of data flow diagrams as well as a fully integrated data dictionary and word processor.

Page: 50


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.

WHEN UTILIZED: ARTEMIS is a project management tool to be used throughout the project life cycle.

REFERENCES: PDS Support Documentation: PDS Project Management Task Identifier

NOTES: None

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

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.

WHEN UTILIZED: DFDs are used during structured analysis to gather requirements for the system in order to facilitate development of a structured model of the system.

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

Page: 53


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.

WHEN UTILIZED: 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.

REFERENCES: Software Engineering Life Cycle (SELC) Manual Sections: 3.2; 3.3; 3.4


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.

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.

WHEN UTILIZED: Pseudocode should be used in the detailed design phase to describe in detail the process each module will perform.

REFERENCES: Software Engineering Life Cycle (SELC) Manual Sections: 3.5


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.

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

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.

WHEN UTILIZED: Whenever developing textual requirement specifications.

REFERENCES: 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: Data Modeling is used to design a Logical Data Model.

WHEN UTILIZED: Data Modeling should be utilized during requirements analysis and design in order to develop a logical model of the data.

REFERENCES: Application Modeling Guide published by the System Development Support Group

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.

WHEN UTILIZED: 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.

REFERENCES: 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 may be executing have been unit tested. Otherwise, it may be necessary to build a stub (a procedure consisting of PROC and End) which will simulate correct execution of the called unit.

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.

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

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

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

5. Identify and make provisions for any special resources which will be required to execute the test cases.

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.

In addition, flowgraphs help identify overly complex logic which should be simplified or isolated in a separate routine. The following steps should be followed when utilizing 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).

O O O / \ |\ |\ O O | O | O \ / |/ O O O

IF THEN IF GOTO 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.

4. Use the program specifications to determine what the program should do for each test case that has been designed.

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.

2. Draw a binary tree which shows the dependencies for both the true and false condition for each logic condition.

3. Generate test conditions which will ensure each leg of the binary tree is traversed.

4. Explode the test conditions to satisfactorily boundary test each condition.

5. Develop inputs and expected outputs for each test case. A matrix will facilitate this effort.

6. Add tests which will execute each loop for its minimum and maximum repetitions.

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: XXXX RETRIEVE PART NOTE DATA

PROCEDURE OBJECTIVE: 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 THEN CALL XXXX_FETCH_PART_NOTES;

4 ELSE DO; 5 CALL XXXX_SELECT_DWG_SHEET_ONE_ NOTES;

6 IF DWG_SHEET_NOTES_FOUND

7 THEN CALL XXXX_FETCH_DWG_SHEET_ONE_NOTES;

8 ELSE DO;

9 S_PART_NOTE_CODE = ' '; S_PART_NOTE_NUMBER = (4)' ';

10 IF SYSTEM_LOAD_INDICATOR = 'B'

11 THEN S_PART_NOTE = 'THIS IS A BODY PART';

12 IF SYSTEM_LOAD_INDICATOR = 'C'

13 THEN S_PART_NOTE = 'THIS IS A CHASSIS PART';

14 END;

15 END;

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 | | \ | | \ / | \ / | Complexity = #Edges - #Nodes + 2 6a / \ / C = 19 - 16 + 2 = 5 \ / 2a | 15

T1 (baseline) = 1, 2, 5, 6, 9, 10, 10a, 12, 12a, 6a, 2a, 15 T2 (flip 2) = 1, 2, 3, 2a, 15 T3 (flip 6) = 1, 2, 5, 6, 7, 6a, 2a, 15 T4 (flip 10) = 1, 2, 5, 6, 9, 10, 11, 12a, 6a, 2a, 15 T5 (flip 12) = 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) |T1 |T2 |T3 |T4 |T5 | +--------------------------------------------+---+---+---+---+---+ | 2 PART_NOTES_FOUND | F | T | F | F | F | +--------------------------------------------+---+---+---+---+---+ | 6 DWG_SHEET_NOTES_FOUND | F | - | T | F | F | +--------------------------------------------+---+---+---+---+---+ | 10 SYSTEM_LOAD_INDICATOR = 'B' | F | - | - | T | F | +--------------------------------------------+---+---+---+---+---+ | 12 SYSTEM_LOAD_INDICATOR = 'C' | F | - | - | F | T | +--------------------------------------------+---+---+---+---+---+ | (Actions) | +--------------------------------------------+---+---+---+---+---+ | 1 CALL XXXX_SELECT_PART_NOTES | X | X | X | X | X | +--------------------------------------------+---+---+---+---+---+ | 3 CALL XXXX_FETCH_PART_NOTES | | X | | | | +--------------------------------------------+---+---+---+---+---+ | 5 CALL XXXX_SELECT_DWG_SHEET_ONE_NOTES | X | | X | X | X | +--------------------------------------------+---+---+---+---+---+ | 7 CALL XXXX_FETCH_DWG_SHEET_ONE_NOTES | | | X | | | +--------------------------------------------+---+---+---+---+---+ | 9 S PART_NOTE_CODE = ' ' | X | | | X | X | | S PART_NOTE_NUMBER = (4)' ' | X | | | X | X | +--------------------------------------------+---+---+---+---+---+ | 11 THE S_PART_NOTE = 'THIS IS A BODY PART' | | | | X | | +--------------------------------------------+---+---+---+---+---+ | 13 THE S_PART_NOTE = 'THIS IS A CHASS PART'| | | | | X | ------------------------------------------------------------------

Page: 67

TESTING PROCEDURES

DATE: 03/02/87 INDEX: B.5.1


CONDITIONAL LOGIC METHOD

STEP 1 (Identify conditions)

CODE LEVEL PATH CONDITION A 0 2 PART NOTES FOUND B 1 F 6 DWG SHEET NOTES FOUND C 2 F 10 SYSTEM LOAD INDICATOR = 'B' D 3 F 12 SYSTEM LOAD INDICATOR = 'C'

STEP 2 ([Draw binary tree)

A

B / A C \ / B D \ / C \ D Level: 0 1 2 3

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

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


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.

WHEN UTILIZED: 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.

REFERENCES: Change Control Reference Manual

NOTES: None

STANDARD: None

Page: 70


PRINTING

DATE: 03/02/87 INDEX: B.7.1

Print Destinations

PURPOSE: Route printouts from TSO sessions and batch jobs.

WHEN UTILIZED: Whenever you need to route a print to a remote.

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

Page: 71

***********************************************************************N E W S T A N D A R D S * * * 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

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

Page: 72

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

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 WHEN GOING TO A SUBSYSTEM-MENU FROM A SCREEN IN A SUBSYSTEM AND THEN FROM THE MENU BACK TO A SCREEN WITHIN THE SUBSYSTEM, COMMON KEY DATA SHOULD BE PASSED THRU THE MENU IN THE SUBSYSTEM 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. - THE NOTE SCREENS WILL USE THIS STANDARD. - EXCEPTIONS TO THIS STANDARD ARE SCREENS WHICH HAVE DATA THAT

Page: 74

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

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 FIELD ON A BLANK LINE. 9/6/88

Page: 76

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

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. THIS IS FOR THE PRINT CENTER AND AN IMS PRINT. 8/8/88

G. THE VALID PRINT FIELDS ARE 'C', 'L', AND '?'. 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 THE REQUEST IS MADE A CHECK SHOULD BE DONE TO MAKE SURE THERE

Page: 78

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

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

B. WHEN PERFORMING A DELETE ON A SCREEN WITH MULTIPLE ACTION CODES, THE LINE OF DATA VEING DELETED SHOULD BE BLANKED OUT AND

Page: 80

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

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 DATE- TIME 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. 9/6/88

B. THE STANDARD NAME FOR A JOB IS BHEND2XY. 9/6/88

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

18. BATCH - A. NEW BATCH PROGRAMS SHOULD DISPLAY ANY COUNTS AND SOFT ERROR

Page: 82

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

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 INTER- VENTION IS REQUIRED AN THE JOB FINISHES SUCCESSFULLY. UNNECES- SARY 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. MFS- A. 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: 84