Basis Manual

Coca-Cola Computer Service G.m.b.H.Vienna, Austria

BASIS II

T3 Technical Guide

PTF 53.5

DEVELOPMENT STANDARDS

This publication could include technical inaccuracies or typographical errors. Information in thisdocument is subject to change without notice and does not represent a commitment on the partof Coca-Cola Computer Service G.m.b.H. No part of this manual may be reproduced ortransmitted in any form or by any means, electronic, mechanical, or otherwise, includingphotocopying and recording, for any purpose other than the user's personal use without the priorwritten permission of Coca-Cola Computer Service G.m.b.H.

These materials are furnished upon the condition that the user assumes all risks and liabilitiesarising out of the use, or reliance upon this documentation.

Neither The Coca-Cola Company nor Coca-Cola Computer Service G.m.b.H. warrants suitabilityor favorable results, NOR SHALL THEY BE LIABLE OR RESPONSIBLE FOR ANY LOSS,CLAIM, OR DAMAGE, DIRECT OR CONSEQUENTIAL, ARISING OUT OF THE USE, POS-SESSION, OR RELIANCE UPON THE INFORMATION CONTAINED IN THIS PUBLICATION.

This document may contain examples of data used in daily business correspondence andoperations. In these examples, we use names of hypothetical businesses and persons. Thesenames are fictitious, and any similarity to names of actual businesses or persons is purelycoincidental.

If you have any comments about this document, complete the Documentation Feedback format the back of this manual and return it to Coca-Cola Computer Services.

THIS PROGRAM AND ACCOMPANYING DOCUMENTATION IS PROPRIETARY TO THECOCA-COLA COMPANY. IT IS A VALUABLE TRADE SECRET AND IS TO BE KEPTCONFIDENTIAL AND NOT TO BE USED WITHOUT THE PRIOR WRITTEN CONSENT OFTHE OWNER.

COPYRIGHT © 1993, 1994, 1995, 1996, 2001, 2007. AN UNPUBLISHED WORK BY THE COCA-COLA COMPANY. ALL RIGHTS RESERVED.

Software and Version: T3 Development Standards Technical GuidePTF 53.5

iPTF53.5 – T3 DEVELOPMENT STANDARDS

Contents

1 DOCUMENTATION STANDARDS

1.1 Documentation Structure 1-3Overview 1-3User System Manuals 1-5User Application and System Function Manuals 1-7Technical Manuals 1-11Program Logic Manuals 1-14Highlights and Workbooks 1-15

1.2 Page Numbering, Table of Contents, Standard Forms 1-17Page Numbering 1-17Table of Contents 1-17Paragraphs 1-17Standard Referencing 1-18Checking for Completeness While Updating the Documentation 1-18Word Processing 1-18Standard Forms 1-20

1.3 Documentation Techniques 1-21Data Flow Diagrams 1-21Control Flow Diagrams or Flowcharts 1-25Decision Tables 1-27Hierarchy Charts 1-28Structograms (Nassi-Schneidermann Diagrams) 1-31Documentation Hints 1-35Documentation Conventions 1-37

2 DESIGN STANDARDS

2.1 Naming Conventions 2-3Library Members 2-3Files (Ranges, File Group, Suffix, Fieldnames) 2-7Screen and Report Numbers 2-9Query Members 2-9

PTF53.5 – T3 DEVELOPMENT STANDARDSii

2.2 Program Error Messages 2-11Overview 2-11Error Message Attributes 2-12Screen Program Procedure 2-13Print Program Procedure 2-15Program Terminal Error 2-15Error Message Handling Technique in Programs 2-16Variable Error Message Text 2-19Standard Error Messages 2-21

2.3 Screen Standards 2-29Following SAA Standards for Common User Access 2-30Screen Documentation 2-31General Screen Layout 2-32Standard Screen Sequence to Start an Action 2-37Action Bars 2-38Action Codes 2-42Windows 2-43Overview Screens (=list panels) 2-47Entry Screens 2-49User Defined Screens and Windows (Screen Design Facility) 2-50Function Keys 2-55Commands in 'Expert Mode' 2-57Options and Selection Methods 2-60Input Fields 2-63Instructions 2-64Error Messages and Informational Messages 2-65Help Support 2-66Patchable Constants 2-69Performance Considerations 2-70

2.4 Report Standards 2-73Report Documentation 2-73Report Sizes 2-74Report Layout 2-77Field Definitions for Data Output 2-78

2.5 Disk File Standards 2-79Disk File Layout 2-79Common Record Structure 2-82Multisegment Records 2-83

2.6 CL/Program Communication 2-85 Local Data Area (LDA) 2-85

iiiPTF53.5 – T3 DEVELOPMENT STANDARDS

2.7 Program Design 2-91

2.8 Module Design 2-93

3 COBOLPROGRAMMING STANDARDS

3.1 Objectives 3-3

3.2 Overview 3-5General Remarks 3-5Notation 3-5

3.3 Structured Programming 3-7Standard Elements: 3-7Coding the Standard Elements in COBOL 3-10

3.4 Naming Conventions for COBOL Programs 3-19Paragraph Names 3-19Special Names (Mnemonic Expressions) 3-23File Description Entries (FD) 3-23Working Storage Section 3-27Standard Words and Prefixes 3-33

3.5 Standards for Patchable Constants 3-37Common Constants 3-38Program Constants 3-40Program Error messages 3-48

3.6 Coding and Efficiency Techniques 3-51General 3-51Data Division 3-51Procedure Division 3-52Printer Files 3-53VALUE and Usage Standards for Condition Names 3-55Instruction Timings in COBOL 3-56Standard Coding for I-O Operations 3-57

3.7 Program Structure 3-61Structure of Working Storage Section. 3-61Structure of Procedure Division 3-63COMMENTS 3-64

PTF53.5 – T3 DEVELOPMENT STANDARDSiv

3.8 Program Administration 3-67

3.9 Program Modules 3-69Naming Conventions 3-69"Dummy Parameters" 3-71Administration Documentation and Comments 3-73

3.10 S/36 - S/38 Considerations 3-75Programs 3-75Screen Formats 3-79

4 LIBRARYSTANDARDS

4.1 Introduction 4-3Guidelines 4-3Coordination and Scope 4-3Modification Level 4-4

4.2 Menu Standards 4-7Menu Types 4-7Menu Design 4-10Menu Documentation 4-13

4.3 CL Standards 4-15CL Complexes 4-15CL Program Procedures 4-21CL Messages 4-23CL-Standard Procedures 4-23Defining of Printer Files in Procedures 4-35

4.4 Message Member 4-37Concept 4-37Structure of a Message Member 4-38Maintenance 4-51

4.5 Miscellaneous 4-53Prompt Display 4-53

vPTF53.5 – T3 DEVELOPMENT STANDARDS

5 APPLICATION DEVELOPMENT STANDARDS

5.1 Development Steps 5-3Project Definition - Broad Design 5-3SIGN-OFF by the Senior Management 5-3Research - Requirement Collection 5-3System Concept 5-4System Concept Review 5-4Technical Detail Design 5-5Programming 5-6Documentation 5-6System Test 5-7Pilot Installation 5-8Acceptance Test 5-9Distribution 5-10Evaluation 5-10Maintenance and Enhancements 5-11

5.2 Application Documentation (Top Down) 5-15

6 PROJECT MONITOR AND PLANNING

6.1 Project Monitor 6-3PM Software Package 6-3PM Procedure 6-3PM Code Structure 6-5List of Personnel Numbers 6-6PM Reports and Options 6-6

6.2 Planning 6-11Preparation of Long Range Plan 6-8Application Development Check List 6-9

7 INTERNAL STANDARDS

7.1 File Name Prefix Assignment 7-3

8 STANDARDS FOR QUERY

PTF53.5 – T3 DEVELOPMENT STANDARDSvi

This page intentionally left blank.

Documentation Structure

PTF53.5 – T3 DEVELOPMENT STANDARDS 1 - 1

DocumentationStandards11.1 Documentation Structure 1-3

Overview 1-3User System Manuals 1-5User Application and System Function Manuals 1-7Technical Manuals 1-11Program Logic Manuals 1-14Highlights and Workbooks 1-15

1.2 Page Numbering, Table of Contents, Standard Forms 1-17Page Numbering 1-17Table of Contents 1-17Paragraphs 1-17Standard Referencing 1-18Checking for Completeness While Updating theDocumentation 1-18

Word Processing 1-18Standard Forms 1-20

1.3 Documentation Techniques 1-21Data Flow Diagrams 1-21Control Flow Diagrams or Flowcharts 1-25Decision Tables 1-27Hierarchy Charts 1-28Structograms (Nassi-Schneidermann Diagrams) 1-31Documentation Hints 1-35Documentation Conventions 1-37

DOCUMENTATION STANDARDS

PTF53.5 – T3 DEVELOPMENT STANDARDS1 - 2




1.1 Documentation Structure

1.1.1 Overview

1) "User" Manuals

a) Intended for the general user:B2 Business & System ApproachesB3 Terms & CodesB4 Operating Guide

aa Application manuals: aa = SM for Settlement, OM for OutletMaster, and so on. These manuals describe what the application doesand how to use it. They include also technical information such as how toset up the application.

aaU Application manuals (User Guides): aaU = Order Entry User Guide,Dispatching User Guide, and so on. These manuals describe what theapplication does and how to use it. The technical information is includedin the corresponding Technical Guides.

b) Intended for the DP managers:B6 S/36 File LayoutsB7 File Layouts for System Control file (XI01)B8 iSeries File LayoutB9 eBASIS II SchemasXs System Functions, with s = T for Installation Utilities, R for Restart, and

so on): see Note on next page.

2) "Technical" Manuals (intended for the development and support groups)

T3 Developtment StandardsT4 iSeries Devlopment StandardsT5 Call ModulesaaT Technical Guides: aaT = Order Entry Technical Guide, Dispatching

Technical Guide, and so on. These manuals describe technical informationsuch as how to set up the application.



Note: Current codes for System Functions (Xs) are:

XA Data Distribution

XC Shareware Tools

XD Program Distribution Control (installed applications, programmodification levels, and so on)

XF Copy Modules File definitions (including S/38 DDS - standards)

XI Installation Options and Parameters (data dictionary, codeinterpretation, installation options and tables, rounding, and so on)

XJ Job Control & Job History

XL Control Lists (selection list, grouping list, print list, sort list, and so on)

XM Modules (table processing, field processing, frames, businessmodules, for example, taxes, rounding ...)

XO Run Options

XP Patching

XQ Driver

XR Restart

XS Security

XT Installation Utilities

XU Utilities (for example, file print programs)

XW Copy Modules for Working Storage Section

XX Cross Application



1.1.2 User System Manuals

User system manuals include manuals which group user information related to theBASIS System as a whole. B1, B2, B3, B4 are intended for the general user; B5, B6,and B7, are intended for the DP Manager.

B2 - Business and System Approaches

B2 is a study manual. It gives broad information on how BASIS approachesbusiness issues such as pricing, promotions, taxes, advance selling, salesorganization, delivery frequencies, market segmentation, outlets and customers,articles, empties and so on. It also includes general information on systemapproaches such as amount editing, options and parameters, rounding, coding,and so on. Certain items may be discussed in further detail in section aa 2.1 of theapplication manuals. In such cases, reference is made in B2.

B3 - Terms and Codes

B3 is essentially a reference manual, not a study manual. It includes codes whichmust be entered by the user in master files. It gives definitions plus type and lengthif applicable, valid code values for certain codes (when assigned by BASIS—otherwise possibly a few suggested meanings). A few technical terms are alsoincluded. References to B2 and/or application manuals are made where applicable.

A standard form is used. The following information is shown on this form if it isapplicable:



FIELDNAME

N/5(1)

DATA STORED IN: - - field no.

- - field no.

- - field no.

CODE DEFINED BY: (2)

ALLOWED VALUES: (3)

CODE LEVEL: (4)

DESCRIPTION

1 = Field definitionN = numeric,A = alphanumeric. If not specified differently in (3) the valid characters

in N fields are 0 to 9, in A fields any printable characters.

2 = "the BASIS group" or "the User"

2, 4, = only specified if field is a code

3 = Only specified if not all values are allowed according to the fieldcharacteristics, for example, field is N/1 but allowed are only 0 and 1.

4 = Only specified if "Location". The default value is 'Company'.

• Common error messages (applicable for all applications)

• Control language (CL) messages.



B6 - File and Data Component Layouts

Describes file structure (as required) and record layouts for application and systemfunction disk files (aann and Xsnn). It also includes layouts of data componentswhich are created and used by generic programs.

B7 - File Layouts, System Control file

The System Control file XI01 has the application or system function code (aa orXS) in its key. It acts as a series of sub files. The application or system functioncode (aa or Xs) is used as the section name.

1.1.3 User Application and System Function Manuals

aa - Application Manuals

A standard table of contents is present in all aa and Xs manuals:

aa/1 INTRODUCTION & BUSINESS APPROACHES

Scope of Application. Intended to be read by managers or users beforeimplementation. Gives an conceptual overview of major system and businessapproaches.

1.1 Description

Short description what it is and what it does (extended version of the'Highlights').

1.2 Background Information

Basic information and required background knowledge with references tosections of B2, B3, or other application manuals.

1.3 Hints how to begin



Considerations to be done before implementation of application.

1.4 Data Flow

Functional flowchart, showing connections to other applications, and so on.

1.5 Application Files

Major files, created or mainly used in this application. Fields and how they areused.

1.6 Integration

Integration of the application in the BASIS package. Data sources like files,fields (for example, from Master files) and transactions and how they areused.

1.7 Calculation Rules

Formulars, description of complex calculation proceedings (Only ifapplicable).

1.8 Limits and Ranges

Specification of the most important limits and ranges (for example, max,number of articles, and so on).

aa/2 INSTALLATION

Contains all necessary documentation for implementation and condition settings.

2.1 Technical Implementation

• Installation time table (Implementation steps)• Organizational aspects• Education• Forms (preprinted) to be planned• Preparation of manual data for the installation



• Proposed test runs• File allocation• Error messages during implementation runs• Special problem situations during implementation time

2.2 File Sizes, Hardware Requirements

2.3 Preparing the Start Conditions• Installation options (General and by application)• Data dictionary• Data identifiers used• Code interpretation• Message member (Ranges used)• Execution control records

2.4 Preparation of Output

• Reports

• Generic programsper Generic Program the following information has to be given:- the name of the generic program (aaP7nn)- a short description (for example, 'VISIT PLAN')- the number of the complex in which the generic program runs- the number of the object(s) used (aaOBnn)- the data components the object(s) consist of (for example, OM01,

OM08). Details of the fields in the data components are in the B/6manual

- Control Lists used (for example, PL05, OL03, SL08) and to whichobjects they are assigned

- the maximum size allocated in the generic program for the internalformat

- the processing logic if necessary, for example, that only outlets areprocessed which have an OM08 record

- overflow handling in case of multiple print lists used in a genericprogram

- run options associated- subtotal calculation by the program- the contents of system field $$COMPLOC which are loaded by the

generic program



- the meaning of system and object conditions set by the generic programin case the description in the external format of the control list is notsufficient.

- a sample printout (only if print list used)- the external format of the Control Lists used as provided by the

development group. Print Lists have to agree with the sample printouts.

• Files (User interface files)

• Diskettes

aa/3 USER GUIDE

This section gives all information required for the use of this application.

3.1 Run Options

3.2 Preparation of Input Data

3.3 Menues by Item

Description by complex.

3.4 Run Book

The run book describes in detail all activities to be executed at the workstation.It defines, per activity, and in chronological order, the steps to be performed.Each step is supported by practical examples of reports and screens. Thesteps are furnished by a consecutive number allowing the user to skip orrepeat certain steps. For each screen only those explanations are givenwhich are related to the current activity. In case an activity is very similar toanother already explained step, there is no need to duplicate the wholedescription.

3.5 Special Problem Situations

Problem situations, which may occur due to wrongly used fields or commandkeys or other wrong performed steps are described with answers.



3.6 Screens

Hardcopy of a practical example with• Explanation of output fields• Input fields with their checks• Used error messages from control file

(Description if mandatory or optional)• Command key directory

3.7 Reports

Standard print list examples of all reports produced by this application. Forreports produced by 'Print Lists' the standard version is described. Freespace for user versions of reports should be available. All reports areexamples, reflecting real business situations. For error reports, the used errormessages from control file are listed.

3.8 Miscellaneous References

Definition of specific fields and transactions (for example, control totals, andso on).

aa/4 SAFETY AND CONTROL

4.1 BASIS Standard Safety and Closing Procedures

Periodic and end-of-year closing options and procedures. Recommendedreorganization of files. Additionally recommended actions for safety.

4.2 Recommended Audit and Control Procedures

4.3 Recovery and Restart Functions

1.1.4 Technical Manuals

Technical manuals describe how the applications (aa) and system functions (Xs)work internally. They are intended for use by the development and support groups,



not for the user or the DP Manager. However they can be made available to thesepeople in certain circumstances.

T3 - Development Standards

T3 covers documentation standards, design standards, programming standards,control language standards, and so on It is a "cookbook" for the designers andprogrammers, covering topics such as patching, restart, and so on (that is, how toprogram these functions; how they work is described in the TXs manuals)

Taa and TXs - Technical Manuals

A standard table of contents applies to the Taa and TXs manuals.

Depending on the importance and who is responsible for writing and formaintaining them, the Taa-sections are kept in

• typed• computer printed or• handwritten form.

Taa/1 TECHNICAL SECTION

This section is kept in typed form. Its structure depends on the application orsystem function. Typical functions to be covered are:

• general overview• interfaces with other system functions• technical description (if not included in a logic manual)

for example:- flagging philosophy (process flags, deletion flags and so on)- restart features- execution control (use of Eaa records on XI01)- file reservations- use of switches and/or LDA- work file processing due to table overflow- table processing in connection with pointer addresses and so on



Taa/2 MENU SPECIFICATIONS

This section contains:

• a menu reference list (name/description) in typed form• a computer print test of every display text—and command member.

Taa/3 COMPLEX SPECIFICATIONS


• a complex reference list (name/description) in typed form and• a computer print test of every complex.

Taa/4 PROGRAM SPECIFICATIONS


• The program reference list (name/description) in typed form• The program description, for example a condensed overview per program

enabling the reader to understand what the program does and whichfunctions are included. How a function is performed, however, is notdescribed. This is documented in the corresponding user guide. The programdescription is kept in typed form.

• A list of all call-, copy modules and frames used (typed form)• A handwritten table of all files used (for example, name, organization, access

mode, usage, and so on)• A computer print test of the corresponding program procedure.

Taa/5 SCREEN LAYOUTS

A standard preprinted form is used for screen layouts. Entries are, however, donemanually.

1) Screen layouts are defined by the development group. Each screen numberaaSnn consists of one page and uses the screen layout form defined in chapter2.3.



2) Screen layouts can be defined by the user by means of control lists (display list).No special layout is provided. A sample screen will be shown in aa/2.4.

Taa/6 REPORT LAYOUTS

A standard preprinted form is used for report layouts. Entries are, however, donemanually.

1) Report layouts can be defined by the development group. Each layout consistsof one page and uses the report layout form and conventions described inchapter 2.4.

2) Reports can also be defined by the user by means of control lists (print list). Nospecial layout is provided. A sample report will be shown in aa/2.5.

Taa/7 LOGIC MANUALS

The logic manuals are also part of the T-manuals. They are kept in manuscript formonly. The lead programmer/program analyst is responsible for updating the logicmanuals whenever a modification in the program concerned is made.

1.1.5 Program Logic Manuals

These are not published and are kept in manuscript form. They are intendedexclusively for development staff. All logic manuals of an application are part of theT-manual Taa/7. All logic manuals of the system utilities are in one binder, LXs;within the binder L-manuals ascend by program name and consist of 4 sections:

1) General

This section is written by the lead programmer and gives general information aboutmodification level (for internal control), files used (organization, access mode,records used), standard modules used, switches and LDA used, key arrays, CMD-keys used (screen programs only) formats used (screen programs only) patchingrequirements (literal records used).



2) Hierarchy

This section is drawn by the programmer in cooperation with the lead programmer(or deputy); typically it consists of 3 or 4 levels and fits onto 1 page. Refer to 1.3.4for symbols used.

3) Key modules

A narrative description of the key modules is given by the lead programmer (ordeputy) and will be more detailed in the analysis stage; a reduced version is keptfor actual documentation.

1.1.6 Highlights and Workbooks

The 'Highlights' brochures provide a short general introduction to each BASIS IIapplication, as well as practical examples and screens.

The 'workbooks' deal with specific topics and features of BASIS II. They provide adetailed description, as well as many examples, making them a good tool duringdaily work. The following workbooks exist:

Calling SchedulesData IdentifiersDisk Space/Performance/Hardware/TrainingImplementation ChecklistLinkagePricing Samples of BASIS formsXL - Control Lists






1.2 Page Numbering, Table of Contents, StandardForms

1.2.1 Page Numbering

All pages are identified by manual, section and page.

Manual = B2 - B9, T3-T5, aa, aaU, aaT

Section can have 1, 2, 3 or in some special cases, 4 numeric positions:for example 2

2.62.6.1.

The number of positions in the section number has been chosen so that thenumber of pages in each section is limited . This will allow easy location of asection in a manual, or a topic or paragraph within the section in case ofreferences. Pages are printed front and back. This means that a section is printedon about 4 sheets which are generally completely replaced when updated. This isbecause a section represents a unit for the word processor. When paragraphs areinserted or deleted, the word processor automatically repaginates the section andrenumbers the pages. When changes do not require repagination, single pairs ofcorrected pages may be issued. This means that a minimum of two pages of asection will always be issued, even if only one of them has been modified. Eachsection starts on a new front page. Sub-sections can start within a page. Eachsection has a title. This title appears on all pages of the section.

1.2.2 Table of Contents

Each section appears with its title in the Table of Contents of the manual. Sub-sections are not listed in the table of contents. It is identified as section 0, whichalso includes the List of Pages of the manual. (See 1.2.5, Checking forCompleteness...)

1.2.3 Paragraphs

A section or sub-section may be further subdivided into paragraphs. These areidentified by a number or letter, followed by a closing bracket:



1) ...a) ...

or by a heading (that is, a name) without a number. These non-numbered headingsshould not be used for sections which are longer than 2 or 3 pages; otherwise itwould be too difficult to find the desired paragraph.

1.2.4 Standard Referencing

Example: see TRS, 2.6 (reference in another manual)see 2.6 (reference within the same manual)see 2.6, Par. 4see 2.6, Taxes (Taxes is a heading within 2.6).

The manual code is only shown if another manual is being referenced.

1.2.5 Checking for Completeness While Updating theDocumentation

Updated pages and new manuals are distributed with "DocumentationNewsletters", numbered sequentially. A complete list of pages of each modified ornew manual is included with the newsletter. This list of pages indicates the dateand newsletter number with which each page of the manual was last distributedand can therefore be used to check whether documentation is complete and up todate. For the pages being distributed an indication is given in the list of pages as towhether they are new or modified, or are to be deleted from the documentation (C= changed page, N = new page, D = page to be deleted). In this way, the recipientcan check whether he has received all pages of a newsletter.

1.2.6 Word Processing

Documentation is produced on word processing equipment. This entails a simplestructure, simple forms and so on.

Flowcharts and complex illustrations are drawn manually and inserted intopre-programmed spaces in the text.

One level of indentation is followed. Text begins flush with the left margin and is



right justified. Heading levels are distinguished as in the following example:

1. DOCUMENTATION1.1 Documentation Structure1.1.1 Overview

The following page format is followed for text:

margins: left 10, right 86tabs: individually setfirst typing line: 8last typing line: 62line spacing: 1

Prestige elite (12 pitch) type is used.

The heading on the standard forms begins on line 3, information being inserted inthe following positions:Release number: 25Date: 31Newsletter number: 42Manual: 48Section: 61 (may be varied to suit length of information)Page number: 85, flush with right marginThe section title appears on line 5, flush with the right margin.

Screen and report layouts are filled in by hand by the author of documentation. Theoriginals are then filed by the documentation department which photocopies themand prints text, headings and so on on these copies.

The following standards apply for record layouts:

Single spacing is used throughout.

Heading as above, without section title is printed on line 3.

The following information is printed on line 6:



org.: 32rec. length: 39key length: 45file and record name: 55 (approximately)

Text begins in the following positions:Field number: 10Field name: 15, 19Type: 34Position: 40Length: 47Description: 53

Quarto (U.S. size) paper is used exclusively. Pages are distributed with three holesto fit standard American binders. BASIS binders, labelled for the appropriatemanuals are distributed when necessary with the documentation.

1.2.7 Standard Forms

Examples of standard forms follow:blank page



1.3 Documentation Techniques

1.3.1 Data Flow Diagrams

Data flow diagrams show how data flows from process to process. They showwhere data comes from and where it goes, either to a data store (computer ormanual file) or an interface (user department, another application...)

Data flow diagrams are mainly used in aa 1, Description (and if required in Taa 1,Technical Description) to show how data flows between and within applications.

Page Numbering, Table of Contents,Standard Forms



Symbols Used:

1) PROCESS

ProcessName

ProcessName

Computer Process

Clerical Process

2) FILES

orFilename

Filename = Manual File

FileName

Computer Fileor

or

orDiskette File

Screen File

Report, Document

3) DATA FLOW

Data Flow

Data transport (for example diskette)

Data transmission

4) INTERFACES or orName

NameName or Name



5) OTHER

TEXT - - - - Commentary

1

3

2

2

3

3

Page 1 Page 2

Example:

From: or to: (Same page) ConnectorID ID

ID IDFrom: or to: (Off page) Connector

ControlsData Controls (compare totals...) can also be shown on a data flow diagram. Symbolused:

Process x

Process y

Control Chart

TotalCash

TotalCredit …..

Date

Example:

Use

Data-flow diagrams are mainly in aa/2 (Functions) and aa/3 (Activities).



Load/Unload Sales Slips Additions on pre-extended invoices

Warehouse Cashier Salesman

Groupper

Route

Control Sheet

Data Entry

AM

OM

Load/UnloadData

Cash Data Sales Data

Delivery Route Data

Example of a data flow diagram:

Delivered

OE+IN

RS

Non-delivered invoices remain in file



1.3.2 Control Flow Diagrams or Flowcharts

Control flow diagrams or flowcharts show how control flows from program to program (within aprocedure). For each program in a procedure they show files (I, O, U), screens and reports.

Use: Control flow diagrams or flowcharts are used in section Taa/3 of the Technical Manual.

Note that in BASIS, because of structured programming, structograms are used in the Laa Manualsinstead of program flowcharts.

Files, processing and input/output devices are shown on diagrams from left to right.

FILES PROCESS INPUT/OUTPUT

DEVICES

TEXT ON EXTERNALVARIABLES AND

DECISIONS

The text on external variables and decisions identifies the external variable and what information isreceived or passed. For a decision, it identifies what is tested and what action is taken.

If the action is in the program, the text is shown in line with the program.

OMP600OM01

Outlet MasterParameter 3 - Type of ListLDA - Writes last outlet

If the action is in CL, the text is shown in line with CL symbol.

LIST End

Y

N

Parameter 2 - List Requested



ProgramName orFunction

ProgramorProgram Step

Standard ModuleorSubroutine

Test

FileFile

Name(s)

Screen

Report

Control Flow

From or To

Off-Page Connector

From or To

On-Page Connector

TextCommentary, for exampleExternal Variables

Start and End

Example of a Procedure Flowchart

RSC015

RSP200

Condition

List Tag

RSP205 Options

RSP210File

Name

FileName

RSS220COPY

END

NO

YES

FILES PROCESS I/O DEVICES TEXT

Parameter 3- List Requested

LDA - Writeslast outlet



Documentation Techniques

1.3.3 Decision Tables

Decision tables show the static relationship between conditions and actions. They are sometimesuseful for investigating and documenting complex static relationships.

Table Format

Rules

1 2 3 4 5 6 7

CONDITIONSDriver type D D D D A A A Note 1

Volume Total A B C D A B - Note 2

ACTIONSCalculate Note 3Commissionwith rates = 7 6 5 4 4 3 2

Pay Overtime - - - - Y Y Y

NOTE 1

D = DRIVERA = ASSISTANT

NOTE 2

A = 0-200 CASESB = 201-250 CASESC = 251-300 CASESD = OVER 300 CASES

NOTE 3

COMMISSION = VOLUME X RATE SHOWN BY 100 (RATES ARE SHOWN INPERCENTAGE)



1.3.4 Hierarchy Charts

Hierarchy charts show how functions are organized in a hierarchy of modules.These charts can be used at almost every level, that is, general BASIS, systemfunctions, applications and programs. Following is an example of the hierarchy of aninquiry program.




Mainline

Init

XMIO02

Read fromJob Control File

XM1O03

Write JobeControl File

Terminate

1 5

UPSI 0

11LoadPatchData

Read-WS Processing

2 3Write

Trans. File

4

UNTIL CMD 7

(Roll) (Outl. No.) (Initial Read)

(Else)

Prepare 1st Screen

Prepare prompt “outl.No.”

31 32

“Error”

33

Load Array

Y1

OFF

ON

Load Array

UPSI 0

321 322Y1

OFFON



• MAINLINE is the control module which delegates functions to lower levels; inprogramming terminology the function is PERFORMED.

1-9 are first level modules and also delegate functions to the next lower level(for example, 1 performs 11 or 32 performs 321/322); going down thehierarchy, each lower level becomes more and more detailed until no morefunctions must be delegated (typically 4, 5 or 6 levels)

• The level numbers uniquely identify a module's place within a programhierarchy and are assigned serially; a new module which must be insertedlater gets the next free number (for example, 34 can be inserted between 31and 32); if 9 was already occupied letters A, B, C, and so on may be used.

• The number of digits uniquely identifies the level (2 = level 1, 31 = level 2,321 = level 3,).

• In almost every program there are common modules which are performed fromdifferent places; their prefixes start with a letter:

XMccnn. . . standard COPY modules common to several programs,cc= module class, nn= unique number for example, XMIO2/ 3 belong to module class IO standing for Input/ Output.

Yc . . . standard modules only common to a specific program;with c = 01-99 they may have their own hierarchy (forexample, Y1 calls Y11, Y12 calls Y121, Y222 and so on

Znn . . . all modules containing Input/Output Operations, withnn=01-99 followed by the file name aann and codeoperation (for example, Z0/1-OM1-READ, Z53-XI1-WRITE)

• Each module performs its own function and may delegate functions to lowerlevel modules. This delegation may be conditioned by one of the 3 symbols:

Repetitive execution of the lower level module(s) while oruntil a condition is true; the condition test is done in thehigher level module.(For example, 2/3/4 are performed by MAINLINE UNTILCMD Key 7 has been pressed).

Case structure, that is, only one of the lower level




modules is performed, depending on condition tests C1 ...Cn; the condition tests are performed in the higher levelmodule.(For example, one of the following: Y1/31/32/33, isperformed depending on the input received from2-READ-WS).

Execution of the lower level module depends on acondition C; the condition test is done in the higher levelmodule.

(for example, 11 is performed ifUPSI is ON or

321 is performed ifUPSI is ON-else

322 is performed).

1.3.5 Structograms (Nassi-Schneidermann Diagrams)

This documentation technique was specially designed to support "structuredprogramming". Structograms are preferrable to flowcharts because they offer nosymbol for "GO TO" and therefore do not permit a programmer to break the rules ofstructured programming. The text below introduces structogram symbols. Thesubject is discussed in more detail in 3.3, Structured Programming.

1) SEQUENCE

MOVE A TO B Single step (on instruction level)

Datacheck SYNTAX CHECKINGPERFORM another routine(reference to another structogram)



2) IF-THEN-ELSE

3) CASE


Add Amountto

Debit Total

Subtract Amountfrom

Credit Total

Y N

AMOUNTPOSITIVE

Two-way branching based onan IF-statement

Write Heading/Advance Page

Y N

LINE COUNTER =PAGE SIZE

One-way branching. The boxunder N (ELSE path) remainsempty.

“A”

“B”

“C”

ELSE

Address

Art.

TotalEdit Name& Addressfor Printing Accumulate

ArticleQuantities

CalculateTax andPrepareTotal Line

DisplayErrorMessage

RECORD CODE

Multiple branching basedon the value of avariable. (An ELSE pathshould always exist toprovide for errorchecking.)



4) DOWHILE

5) DOUNTIL

WHILE condition (continue if true)1 Index 100

Move fields from array (ind.) to printrecord

Write print line from print record

Add amount (ind.) to total

Iteration body

CMD-7

SEVERE ERROR

Read from WorkstationRead WS

Process WorkstationReadProcess

Write Transaction FileWrite Trans.

I1

Stays empty

UNTILcondition (discontinue if true)

I2

I3

Note: I1 + I2 + I3 = Iteration body



6) DECISION TABLES

If a route consists of a heavy load of IF's and ELSE's, it may be desirable to group thedecisions and actions into a table and put the table into a box, for example,

CASE 1 2 3 4 5 6

CASH CUSTOMER Y Y Y Y N N

ELIGIBLE FOR PROMOTIONS Y Y N N Y N

TAX EXEMPT Y N Y N - -

EXTEND ARTICLES X X X X

COMPUTE PROMOTION X X X

COMPUTE TAX X X

CO

ND

ITIO

NS

AC

TIO

NS

Y = Condition TRUEN = Condition FALSE- = Condition may be true or falsX = To be executedb = Not to be executed

EACH COLUMN REPRESENTS A SEPARATE CASE, FOR EXAMPLE, CASE 4 READS: -

IF CASH CUSTOMER AND NOT ELIGIBLE FOR PROMORTIONS AND NOT TAX EXEMPT,PERFORM EXTENDED ARTICLES AND THEN COMPUTE TAX

Several notes on structograms follow:

• The program logic as such is set up in a hierarchy chart and structogramsbefore coding begins. They are finalized for the Program Logic manuals onlyafter the system test.

• One structogram exists for every performable routine. It normally combinesseveral elements into logical or functional unit.

• Comments may be put in brackets:

TAX

(Calculate tax, tax ratefrom tax table using taxclass and art. tax code asindices.)




1.3.6 Documentation Hints

Good documentation is a difficult job. Each author has his own style. It should be asshort as possible, but it must contain all important facts to assist implementation,questions arising at remote sites, and so on.

There are some important guidelines which will help to achieve our efforts tomaintain a high standard of documentation and, at the same time, support ourdevelopment procedures.

Similar manual presentation

For the user each manual should have the same structure, it should have the samestyle, it should help him find information quickly.

Reduction of documentation

A major criticism of BASIS I was the volume of documentation to study. Informationshould be documented in one place and not repeated. Avoid repetition of B2-3. Avoiddocumenting information that is 'padding', that is, it really brings the reader no newinformation and could be omitted. It is no criticism that a section is small or even notused, it will help keep the attention of the reader.

Standard structure reference manuals

Standard sections are to be used for structuring reference manuals. See 1.1.3 and1.1.4. In addition, make your own check list of topics that require explanation andgroup them together in a logical reading sequence. This will help you avoidduplication and omission.

When standard sections are not applicable, they will appear in the Table of Contentswith their section numbers—but with the title missing and N/A. These sections do notappear in the text itself.

The names of standard sections can be modified or extended if this helps to makethem more meaningful.

Style

• Use simple language. English is not the mother tongue of many of our users.




• Keep sentences short (newspaper approach to make reading easy).

• Keep subsections to a reasonable length. If these are too long, split the topicinto two or more sub-sections.

• Remember the limitations of the word processor (see 1.2.6). It may not beable to produce your documentation as you would like.

• Try to keep your explanations simple. If they get too complex, you should stopand consider another approach (maybe the business or technical solution isnot practical?).

Turn key

Users more and more expect a turn-key approach in software packages, that is,switch the computer on and everything functions. To achieve this objective, thescreen will be used to guide the user department. An advantage will be that ofteninformation on the sample screens will not have to be repeated in writtenexplanations, that is, rely on sample screen and sample reports.

Development milestones

It can happen during the various development milestones (R, B and so on) thatcertain analysis or technical work is done in advance of the current milestone beingworked on.

In this case, it should be included in the correct section, and not in the currentdocumentation section; this will avoid duplication or later reclassification of thesection.

Use of sections (sub-sections)

A section heading at the top of the page appears in the Table of Contents. Sub-sections within a section do not appear in the Table of Contents.

Example:4.6 CL Techniques4.6.1 CL Technique Number One

Text4.6.2 CL Technique Number Two

Text



When the writer finds that the sub-section is becoming too lengthy and shouldappear in the Table of Contents, he should consider changing all the sub-sectionsto sections.

Example: 4.6. changed to section 4.6.14.6 CL Techniques4.6.1 CL Techniques Number One(4.6.2 CL Techniques Number Two starts a new page)

Because section headings appear in the Table of Contents, section headingsshould be meaningful to make this Table of Contents more useful. In the aboveexample, a better section heading might be 4.6.1, CL Parameter Techniques.

1.3.7 Documentation Conventions

• BASIS II is always referred to as BASIS in text. The exception is whenBASIS I and BASIS II are specifically referred to or appear together (linkageconsiderations).

• The letter O and zero number 0 will be typed normally as in this sentence. Inhandwritten text, whenever confusion is possible, the writer should use toalert the documentation department that it is a zero and not the letter O, forexample, XMIO1.

• Words will start with capital letters for:

Section Title, 1.3.7, Documentation Conventions,Paragraphs b) Screen Formats

Files System Control fileAbbreviations E.D.P., COBOL, CL, B1, T4, CMD, GA

Application, Outlet Master, RestartSystem Function

Manuals B3, Terms and Codes

If doubt exists, the rule is to avoid capitals as far as possible, for example, it is notnecessary to use capitals for codes, for example, sales term 5, and so on.




• Words will appear in capital letters for

Example

Main section title 1. DOCUMENTATION STANDARDSFor highlighting Press ENTER key

• Standard American spelling, vocabulary and style will be used throughout theDocumentation, the only exception being the internal date format (Year/Month/Day) used in the headings and in sample reports and sample screens.

Screen Standards


DesignStandards22.1 Naming Conventions 2-3

Library Members 2-3Files (Ranges, File Group, Suffix, Fieldnames) 2-7Screen and Report Numbers 2-9Query Members 2-9

2.2 Program Error Messages 2-11Overview 2-11Error Message Attributes 2-12Screen Program Procedure 2-13Print Program Procedure 2-15Program Terminal Error 2-15Error Message Handling Technique in Programs 2-16Variable Error Message Text 2-19Standard Error Messages 2-21

2.3 Screen Standards 2-29Following SAA Standards for Common User Access 2-30Screen Documentation 2-31General Screen Layout 2-32Standard Screen Sequence to Start an Action 2-37Action Bars 2-38Action Codes 2-42Windows 2-43Overview Screens (=list panels) 2-47Entry Screens 2-49User Defined Screens and Windows (Screen Design Facility) 2-50Function Keys 2-55Commands in 'Expert Mode' 2-57Options and Selection Methods 2-60Input Fields 2-63Instructions 2-64Error Messages and Informational Messages 2-65Help support 2-66Patchable Constants 2-69Performance Considerations 2-70

2.4 Report Standards 2-73Report Documentation 2-73Report Sizes 2-74

DESIGN STANDARDS


2.4 Report Standards, continuedReport Layout 2-77Field Definitions for Data Output: 2-78

2.5 Disk File Standards 2-79Disk File Layout 2-79Common Record Structure 2-82Multisegment Records 2-83

2.6 CL/Program Communication 2-85Local Data Area (LDA) 2-85

2.7 Program Design 2-91

2.8 Module Design 2-93

Screen Standards


2.1 Naming Conventions

The naming conventions apply to applications (aa), system functions (Xs) andcross application menus and complexes (XX). Fixed conventions appear incapitals, for example, aaMnnn. Variable conventions appear in small letters and areunderlined if an explanation follows in the text, for example, aaMnnn. Not includedare code structures which are explained under the subject concerned, normally inthe B3 manual.

2.1.1 Library Members

An identical code structure has been applied to library members:

MenuComplex (OCL procedures on S/34 or CL programs on S/38)Program (and Sort)Format Member (and Formats)Modules.

1) Menu (and Menu Items)

Name Meaning

aaMnnnaa or Xs menus are described in the application or systemmanual. Cross application menus with aa=XX are describedin B4 Operating Guide.

aaM000 application main menu

aaM001-499 application sub menus

aaM500-999 application user menus (local)

XXM000 BASIS main menu (cross application)

XXM001-499 other cross application menus

XXM500-999 user menus (local)

Naming Conventions

DESIGN STANDARDS


ZZM000 standard start menu

ZZM0uu start menu per user (uu = user-ID)

Menu Items

aaMnnn-01 to 24 used as job identification for XJ Job Control and XR Restart

for example OMM000-01 First item of OM main menu.

2) Complexes

Name Meaning

aaCnnn S/34 OCL procedures or S/38 CL programs, except XUcomplexes (utilities) and single program procedures

0nn main complexes1nn level 1 complexes (or called from Onn complexes)2nn level 2 complexes (or called from 1nn complexes) . . .7nn clean-up procedures (used for Restart)8nn Conversion/Linkage (for example, BASIS I - II)9nn local complexes

See 1.1.4 under Taa/3 for example of hierarchy diagramwith level complexes.

XUccccxx XU complexes (utilities)

cccc mnemonic name

xx bb = main complex00-99 = sub complexes

Screen Standards


3) Programs (and Sorts)

Name Meaning

aaPnnn program source and load member, CLprocedure containing // LOAD, // FILE,// RUN (single program procedure)

001 header program0nn stand alone auxiliary or inquiry program (in

gaps of 5 or 10)1nn group 1 of programs (in gaps of 10)2nn group 2 of programs (in gaps of 10) . .7nn generic programs8nn conversion/Linkages programs (e.g. BASIS I-II)9nn local programs

Sorts

Name Meaning

aaSnnn CL-sort procedure, nnn assigned in line with program nameaaPnnn, for example, OMS14O is executed betweenprograms OMP130 and OMP150.

4) Format Member (and Formats)

Name Meaning

aaFnnn Format Member for screen programs, with aa nnncorresponding to screen programs

Format

Name Meaning

FMTnn or As defined by SFGR included in the format member aaFnnn(see above).

Naming Conventions

DESIGN STANDARDS


FMTHLPnn FMTnn = data format nameFMTHLPnn = HELP format name

nn = 01 Standard heading (line 1)02-31 Free

32 Error Format (line 22-24)33-99 Free

NOTE

FOR NAMING CONVENTIONS OF FORMATS USED IN // PROMPTSEE 4.5.1.

5) Modules

Name Meaning

XMccnnd cc = classification for example

FR = program framesIO = input/output modulesTP = table processingFP = field processingER = error handling

nn = 01 - 99 to identify a module within its classd = division identifier

D = data division specs.P = procedure division specs.b = 'cross' divisions (for example, CALL and FRAMES)

Some examples:

XMFR02 = level break

XMTP01 = binary search(consisting of XMTP01D and XMTP01P)

Screen Standards


XMFP02 = date conversion(consisting of XMFP02D and XMFP02P)

XMER01 = get error message(consisting of XMER01D and XMER01P)

Source and load members of CALL modules have the same name and aredistinguished by the library type.

2.1.2 Files (Ranges, File Group, Suffix, Fieldnames)

FilesName Meaning

aann nn 01-99, Ranges of file types, see list below

1) Ranges: The more permanent and important the file, the lower the number.The major files therefore come first (within each application) in theB6 manual.

01-19 Master files, Control files20-39 Summary files (permanent) and

Status files (semi-permanent, for example, Open Item,Invoice Suspense File, ...)

40-59 Transaction Files (volatile (for example, data entry transactions,interface files between applications or processors, processinghistory files, log files ...)

60-79 Work files (Scratch files, for example, sort work files, print files, ...)80-99 Data components created and used by generic programs

Naming Conventions

DESIGN STANDARDS


2) File Group

c.aann c a file group can be prefixed for separate files per company (A, B,

C, and so on) or for test files (T).

NOTE

FILE GROUPS ARE NO LONGER SUPPORTED BY BASIS SO ALLVALUES SHOULD BE SET TO BLANK

3) Suffix

aannc c • "X" for copied file (on line) or extract

• "A" for alternate index files, or "An" with n = 1-9 if multiplealternate indexes exist for a file (examples: SA22A, OM01A1,SI21A1, SI21A2)

• "B" for backup• "S" for sorted• "W" for work copy (e.g. during sort)• "M" for a file used in a CALL-module• "r" record format code for physical files (S/38) to be combined in

a logical file.• "mm" or "ww" for monthly or weekly files• job number (01-99) if the same file can exist for several interactive

jobs (that is, menu items) executing in parallel.• User-ID for transaction files, that is, data entry from several

workstations.• An

4) Fieldnames

Fieldnames are defined by the analyst according to the following rules:

Length of name: maximum of 10 positions, no special characters or embeddedblanks, for example, TAXCODE (TAX-CODE is wrong!)

The fieldnames within an application must be unique if data dictionary is used.When no data dictionary is present, for example, for internal work files,fieldnames do not have to be unique within the application.

Screen Standards


2.1.3 Screen and Report Numbers

1) Screen Number

Name Meaning

aaSnn Each main screen in its normal sequence within an application isidentified by a screen number (gaps of 5 to allow new screens tobe inserted).Used in aa/3, Activities (Workstation User Guide)

2) Reports

Name Meaning

aaPnnnc As printed on a report, corresponding to the name of program thatprints the report.

c . . . Suffix, if one program produces more than one report(c = A, B, C, ...).

2.1.4 Query Members

Name Meaning

aaQnnn aa ...... applicationQ ...... fixed

nnn ...... 001 - 499 Development query members500 - 999 User query members no other structure

Naming Conventions

DESIGN STANDARDS



Screen Standards


2.2 Program Error Messages

2.2.1 Overview

Program Error Messages are stored in the message part of the SCF. They aredivided into:

• common Error Messages (available for all Applications) documented inchapter 2.2.8 and identified by an application code XX

• application Error Messages.

They can be translated into local language with XP Patching. Each error isidentified by an error code Eaant and up to 9 message lines can be stored by errorcode. Error code + line number is used as XI01 subkey:

E aa nnn t l

E fixed

aa aa = application (or Xs System Function)XX = common error message

nnn error number 001 - 999 (assigned by an analyst

t error typeE = ErrorW = Warning

l line number (to identify records internally, never displayed)1 = error message2 - 9 = additional 8 lines for information on error message (optional,

see note)

Error messages can be

• displayed in screen programs for action by the workstation user

• printed on error reports for action by the user department

Program Error Messages

DESIGN STANDARDS


• displayed together with a terminal error via DISPLAY/STOP statement toassist the EDP Manager.

NOTE

ORIGINALLY ONLY 4 MESSAGE LINES WERE SUPPORTED. WITHTHE NEW SCREEN STANDARDS THE NUMBER OF MESSAGE LINESPER ERROR CODE HAS BEEN INCREASED TO 9. ALL OLDAPPLICATIONS STILL USE THE OLD DISPLAY TECHNIQUE OFMESSAGE LINE 1 IN SCREEN LINE 24 AND MESSAGE LINES 2-4 INSCREEN LINES 22-24 WHEN F2 IS PRESSED.

2.2.2 Error Message Attributes

To provide standards and flexibility, a separate attribute (options) is provided pererror code to let the user change the severity:

• Change warning into terminal error (upgrade)• Switch off warnings (downgrade)

For E-Error, the attribute is fixed and cannot be changed. For W-Warning, the usercan choose the attribute that best fits his local needs. No initial attribute is presentwhen the W-Warning is distributed to users. It can then be changed as need arises.

The attribute is stored with the error message in the first message record of theSystem Control File. Note that patching translates the error message but cannotchange the attribute. To change the attribute, an XI utility is used.

Error Type Error Attribute Meaning

E-Error b Reject (and ignore) transaction (all fields)

W-Warning C Upgrade the warning to an E-error, that is,reject and ignore transaction.

b Leave the meaning of the warning asusual. The system displays a message ifan error has been detected. The user caneither correct the error, or by pressing

Screen Standards


function key F11, cause the system to takeany predetermined and programmed step,depending on the individual error situation.Which action is taken will be described inthe corresponding error message.

N Downgrade the warning to "no error", thatis, no error message is displayed and thevalue is accepted as it is.

Handling of Warning Errors in COBOL Programs

When at least one error message warning is to be displayed in a program, thecorresponding error attribute(s) must be loaded into the TER-TABLE from the SCFat initialization time. This can either be done with random accesses (if only one ortwo warnings present) or with module XMER03 (more warnings present).

When checking a warning error condition, the following coding is recommended:

IF TER-ATTR1 (ii) (W) EQUAL 'C'OR TER-ATTR1 (ii) (W) EQUAL 'b' AND NOT F11-ACC-WITH-ERROR

PERFORM nn-CHECK-ERROR-CONDITION THRU nn-EXIT.

(ii = element no. of TER-TABLE which contains the appropriate W-error code)

When F11 (accept warning) has been pressed, the program, after having read theWSFILE, performs the same routines as for the ENTER key.

2.2.3 Screen Program Procedure

In screen programs that make validity checks and therefore display error messagesthe following procedure is used:

• One screen may contain one or more input fields to be checked and one ormore error messages may be displayed.

• If at least one error is detected the screen is redisplayed with entered data inthe input fields and erroneous field(s) appear in reverse image


DESIGN STANDARDS


• Sound alarm ('beep') alerts the operator.

• Cursor is on first erroneous field.

• Error code and message line 1 for the first erroneous field is displayed in Line23 and the F1, F2, and HELP plus the F11 description, (for warnings n=only)appear in line 24.

• With F2 it is possible to scroll through additional message lines of the sameerror code. First message lines 2 and 3 are displayed in screen lines 22-24overlaying the function key descriptions in line 24. Then message lines 4+5,then 6+7, then 8+9 are displayed, as present. When F2 is pressed from thelast message lines then message line 1 + function keys are redisplayed fromthe same error code (wrap around).

• With F1 the next error code + message line 1 is shown. When F1 is pressedfrom the last error then the first error message is redisplayed (wrap).

• The text of an error message is as follows:

line 1 describes the errorlines 2-9 explain what to do to correct the error and which function

keys can be used in this situation

The last position of a line is reserved to indicate continuation:

blank = no continuation line'+' = continuation line follows

• F11 is enabled to bypass warnings. The message text (lines 2-9) shouldexplain what the program does in case of F11.

• If no message text is found in the System Control File for an error code, theprogram displays the error code plus a standard text 'NO MESSAGEFOUND'.

Screen Standards


2.2.4 Print Program Procedure

In print programs that make validity checks and therefore display error messagesthe following procedure is used:

• Either all transactions (all = with or without error) are listed or only erroneoustransaction. They are printed left aligned on the report.

• Error messages are printed immediately following the erroneous transaction,right aligned. Usually no space line is left between the transaction and thefirst error message but a space line is used between transactions.

• One or more error messages may be printed per transaction. They should bein sequence of input fields from left to right.

• The message text should use the same terms and field names as printed incolumn headings.

• The error message attribute is handled similarly to the screen programprocedure.

"C" print a message and invalidate the record checked

"b" print a message and free record for further processing

"N" no error condition checked and no message printed.

2.2.5 Program Terminal Error

A program terminal error is an abnormal situation detected by a program, that is,invalid key, invalid record. A terminal error is shown by using the COBOL DISPLAYand STOP statements. This means that the error appears to the user as if it were aSYSTEM stop:

CBL 3017 (0 23) 1)ABNORMAL SITUATION DETECTED BY PROGRAM, CONSULT EDP MANAGER2)SIP317: Invalid record detected on file SI21, record no. 1723. 3)

0 Ignore record and continue, not selected for Invoicing 3)2,3 Cancel job. Investigate and restart job later. 3)


DESIGN STANDARDS


1) Displayed by the system2) Message line 1 from error code EXX002E, translatable3) English text hardcoded in program, not translatable

For important errors, a special error code can be used to store all 4 message linesin the System Control file, all 4 translatable. This is decided by the analyst.

In programs which have no SCF a message can be displayed in English with the"DISPLAY" statement. For those error messages the high order range is reserved(for example Eaa999E). These error messages are documented in the SCF withthe comment that the message is not translatable.

2.2.6 Error Message Handling Technique in Programs

To allow for a standard approach in error message handling by programs, thefollowing coding techniques must be adhered to:

1) Each program dealing with error messages must contain the so-called 'TER-Table' in the working storage area.

One element must be possible for each possible error.

Example (TER-Table)

01 TER-CODES.05 TER-CODE01 PIC X(11) VALUE 'EOM001E '.05 TER-CODE02 PIC X(11) VALUE 'EOM002E '.05 TER-CODE03 PIC X(11) VALUE 'EOM003E '.05 TER-CODE04 PIC X(11) VALUE 'EOM020E '.05 TER-CODE05 PIC X(11) VALUE 'EOM021E '.05 TER-CODE06 PIC X(11) VALUE 'EOM031E '.

01 TER-TABLE REDEFINES TER-CODES.30 TER-ELEMENT OCCURS 06 INDEXED BY TER.32 TER-CODE 1) PIC X(7).32 TER-FLAG 2) PIC X.32 TER-ATTR. 3)34 TER-ATTR1 PIC X.34 TER-ATTR2 PIC X.32 TER-ADDINFO 4) PIC X.

Screen Standards


1 = TER-CODE Error Message code

2 = TER-FLAG 'Y' error is to be displayed or printed(set by program) ' ' error is not valid for processing

3 = TER-ATTR1 Error attribute (see T3/2.2.2 for details)(loaded by XMER03from XI01)TER-ATTR2 reserved for future use

4 = TER-ADDINFO This field is only used when variable data is to beshown together with the error message. (See T3/2.2.7Variable Error Message Text). In this case the size ofthis field is 10 bytes and not 1 byte as shown in theexample.

2) As soon as an error is detected by the program the corresponding TER-flagmust be set to 'Y'. At the same time a general error indicator and the Booleanindicator for reverse image of the erroneous field are turned ON.

Example

IF W-INPUT-FLD-LENGTH GREATER XI01-ID-FIELD-LENGTHMOVE 'Y' TO TER-FLAG (6)SET C-ERROR TO TRUESET C-IND-A-ON (14) TO TRUE

First all input fields of a screen format (or all fields of a transaction) are checkedresulting in zero, one or more TER-FLAGS in the TER-table

3) Standard error handling modulesIn a screen program the general error indicator C-ERROR determines if an errormessage is to be displayed in lines 23-24 (standard bottom format FMT99).Module XMER04 automatically gets message line 1 of the first flagged errorcode in the TER-table and puts it into FMT99:

IF C-ERROROR F1-NXTERROR F2-ADDINFO

PERFORM XMER04-ERROR-MESSAGE THRU XMER04-EXIT


DESIGN STANDARDS


4) If F1 or F2 is pressed then the module XMER04 is also executed to readmessage line 1 of the next flagged error code (F1) or to read the next 2message lines of the same error code from SCF (F2)

5) If ENTER was pressed (or any function key other than F1 or F2) then all TER-FLAGS, the gerenal error-indicator and the Boolean indicators must first beturned off before repeating the check-routines:

SET C-NOERROR TO TRUE.SET IND-FMT99-OFF (01-04) TO TRUE.IF F1-NXTERR OR F2-ADDINFO GOTO 30-EXIT.PERFORM 301-REMOVE-ERRORFLAGS THRU 301-EXIT

VARYING TER FROM 1 BY 1 UNTIL TER > ??.PERFORM 302-REMOVE-ERRORFLAGS THRU 301-EXIT

VARYING T1-A FROM 1 BY 1 UNTIL T1-A > 99.

6) In a print program the general error indicator determines if error messages are tobe printed right after the transaction. Module XMER04 is performed with F1simulated to get the message lines 1 of all flagged error codes in the TER-table:

MOVE '00' TO FUNCTION-KEY.PERFORM 315-PRINT-ERRORS THRU 315-EXIT

VARYING TER FROM 1 BY 1 UNTIL XMER04-O-C-END-OF TER.

315-PRINT-ERRORSPERFORM XMER04-ERROR-MESSAGE THRU XMER04-EXIT.IF XMER04-O-C-END-OF-TER

GO TO 315-EXIT.MOVE XMER04-O-ERRCODE TO RPT-ERRCODEMOVE XMER04-O-T1-MESSAGE (1) TO RPT-MESSAGEPERFORM Z05-RPT-WRITE THRU Z05-EXIT.MOVE '01' TO FUNCTION-KEY.

315-EXITEXIT

Screen Standards


7) Modules available for standard error handling:

XMFR04 COBOL Screen program frameXMF999 Screen format defintions (FMT01, FMT99, window pattern, help

pattern)XMER02 Stop error handling (termial error)XMER03 Load error attributesXMER04 Supply error message

2.2.7 Variable Error Message Text

In order to be able to give the user as much information as possible, it maysometimes be necessary to extend the error message with variable data.

Example (Message as shown to the user)

EOM031E1 DATA ENTERED EXCEEDS FIELD LENGTH ......................:12.

The actual field length '12' varies depending on the field being processed. It istaken from XI01-data dictionary record.

To allow for simple and automatic processing of error messages including variabledata, the following must be foreseen in the error message text itself and in theprogram displaying or printing the message:

1) Error Message Text

The last 10 positions of the error message text must be reserved for the variabledata. This is done by filling these positions with the '#' sign.

Example

EOM031E1 DATA ENTERED EXCEEDS FIELD LENGTH ......................:##########

These positions cannot be patched by the user.


DESIGN STANDARDS


2) Program Requirements

a) TER-Table

The TER-Table must be defined as shown below:

01 TER-CODES.05 TER-CODE01 PIC X(20) VALUE 'EOM001E '. 1)05 TER-CODE02 PIC X(20) VALUE 'EOM002E '.05 TER-CODE03 PIC X(20) VALUE 'EOM003E '.05 TER-CODE04 PIC X(20) VALUE 'EOM020E '.05 TER-CODE05 PIC X(20) VALUE 'EOM021E '.05 TER-CODE06 PIC X(20) VALUE 'EOM031E '.

01 TER-TABLE REDEFINES TER-CODES.30 TER-ELEMENT OCCURS 06 INDEXED BY TER.32 TER-CODE PIC X(7). 3)32 TER-FLAG PIC X.32 TER-ATTR.

34 TER-ATTR1 PIC X.34 TER-ATTR2 PIC X.

32 TER-ADDINFO PIC X(10). 2)

1 = The size of a TER-Table element must be set to '20'.

2 = The size of the 'TER-ADDINFO' field must be set to 10.

3 = The occurs value must be 2 positions (e.g. "06" instead of "6")

b) The variable data must be moved to the TER-Table when the TER-flag of themessage concerned is flagged.

Example

IF W-INPUT-FLD-LENGTHMOVE 'Y' TO TER-FLAG (6)MOVE XI01-FLD-LGTH TO TER-ADDINFO(6).

(XI01-ID-FIELD-LGTH contains the length of the field being processed).

Screen Standards


c) Error Handling XMER01 (Supply an Error Message)

Module XMER04 automatically moves the contents of the TER-Table (TER-ADDINFO) to the last 10 positions of the error message thus erasing the '#' signs.If, for some reason, the ten positions in the error message are not sufficient to storethe required variable data, special programming must be done to handle eachspecific situation.

2.2.8 Standard Error Messages

EXXBASIS XIP080 12 31.10.88 15:32 BA B5TEST COMPANY --CCCS-- S Y S T E M C O N T R O L F I L E - ERROR MESSAGES

APPLICATION: XX RELEASE DATE: 31.10.88MESSAGE CODE MESSAGE TEXT ERROR ATTRIBUTES

EXX000 E1 NO MESSAGE FOUNDEXX000 E2 NO FURTHER INFORMATION AVAILABLEEXX001 E1 F1/CMD-1 PRESSED BUT NOT REQUIREDEXX001 E2 F2/CMD-2 PRESSED BUT NOT REQUIREDEXX003 E1 ITEM NO./LINE NO. ENTERED IS NOT ON SCREENEXX004 E1 DATE MISSING OR INVALIDEXX005 E1 INVALID COMMAND KEY PRESSEDEXX006 E1 ROUTE NOT DEFINED IN SYSTEM CONTROL FILE.EXX006 E2 ENTER CORRECT ROUTE OR ADD ROUTE TO CODE INTERPRETATION PART OFEXX006 E3 THE SYSTEM CONTROL FILE (USE MENU XIM001-03)EXX008 E1 INVALID OUTLET NUMBER OR CHECK DIGIT ENTEREDEXX009 E1 OUTLET NOT EXISTING IN OUTLET MASTER FILE.EXX009 E2 ENTER CORRECT OUTLET NO. OR CREATE NEW OUTLET BEFORE ENTERINGEXX009 E3 ANY TRANSACTION (USE MENU OMM000-01)EXX010 E1 INVALID STATUS CODE ENTEREDEXX012 E1 ARTICLE NUMBER(S) NOT ON ARTICLE MASTER FILEEXX012 E2 -OR- GENERIC ARTICLE NUMBER ENTEREDEXX013 E1 INVALID ARTICLE NUMBER ENTEREDEXX013 E2 INVALID ARTICLE NUMBER ENTEREDEXX014 E1 ARTICLE QUANTITY NOT NUMERIC OR INVALID FORMATEXX014 E2 NOT NUMERIC -OR- MISSING -OR- OTHER THAN DECIMAL SIGN USED FOREXX014 E3 SUBUNITS SEPARATOR SIGN -OR- SUBUNITS ENTERED FOR AN ARTICLE W/OEXX014 E4 SUBUNITS -OR- INVALID MINUS SIGNEXX015 E1 PERSONNEL NUMBER MISSING OR NOT EXISTING ON PERSONNEL MASTER

FILEEXX015 E2 ENTER CORRECT PERSONNEL NUMBER OR STOP PROCESSING TOEXX015 E3 UPDATE PERSONNEL MASTER FILE WITH MISSING PERSONNEL DATAEXX016 E1 CALENDAR RECORDS MISSING IN SYSTEM CONTR.FILE FOR MONTY ##########


DESIGN STANDARDS


EXX016 E2 CALENDAR RECORDS ARE REQUIRED FOR DATE CALCULATIONEXX016 E3 RECOVERY = 3 - TERMINATE JOB, INSERT CALENDAR RECORD(S) ONEXX016 E4 SYSTEM CONTROL FILE (MENU XIM001-01)EXX017 E1 XL TABLE RECORDS ARE NOT MATCHING LOAD AND START ADDRESSEXX017 E2 TABLE IN GENERIC PROGRAMEXX017 E3 ONLY RECOVERY '3' ALLOWEDEXX018 E1 XL AREA OVERFLOWEXX018 E2 ONLY RECOVERY '3' ALLOWEDEXX019 E1 LOCATION INVALID OR MISSINGEXX020 E1 FIELD NUMBER ENTERED NOT VALID FOR FILE(S) BEING MAINTAINEDEXX021 E1 FIELD NUMBER MISSINGEXX022 E1 ONLY PERCENTAGE OR VALUE ALLOWEDEXX023 E1 NEGATIVE PERCENTAGE OR VALUE NOT ALLOWEDEXX024 E1 PERCENTAGE ONLY VALID FOR FIELDS WITH FIELD TYPE 'S'....EXX025 W1 SENDING FIELD LENGTH UNEQUAL RECEIVING FIELD LENGTH...: ##########EXX025 W2 IF RECEIVING FIELD LENGTH IS SMALLER DATA TRUNCATION MAY OCCUREXX026 W1 FIELD TYPE AND FIELD FORMAT UNEQUAL...................: ##########EXX027 E1 INVALID COMBINATION OF FIELD TYPESEXX027 E2 A) SENDING FIELD HAS TYPE 'A'/ RECEIVING FIELD HAS 'N','S' OR 'O'EXX027 E3 B) SENDING FIELD HAS TYPE 'S' / RECEIVING FIELD HAS 'N' OR 'D'EXX028 E1 FIELD NUMBER OR VALUE MISSINGEXX029 E1 VALUE ENTERED AND FIELD TYPE NOT 'N' OR 'S'EXX030 E1 LOCAL FIELD NAME ENTERED NOT EQUAL....................: ##########EXX031 W1 NUMBER OF DECIMAL POSITIONS UNEQUAL...................: ##########EXX031 W2 UNPREDICTABLE RESULTS MAY OCCUREXX032 W1 ATTENTION - ALL RECORDS WILL BE MAINTAINED !EXX034 E1 PRICE LIST MISSING OR NOT PRESENT IN PRICE MASTER FILE AM05EXX035 E1 INVALID ADJUSTMENT LIST NUMBEREXX035 E2 ADJUSTMENT LIST MISSING OREXX035 E3 NOT PRESENT IN AM07 OR

BASIS XIP080 12 31.10.88 15:32 BA B5TEST COMPANY --CCCS--

S Y S T E M C O N T R O L F I L E - ERROR MESSAGESS Y S T E M C O N T R O L F I L E - ERROR MESSAGES

APPLICATION: XX RELEASE DATE: 01.07.88 APPLICATION: XX RELEASE DATE: 01.07.88MESSAGE CODE MESSAGE TEXT ERROR ATTRIBUTES

EXX035 E4 NO VALID VERSION PRESENT IN AM07 FOR PRICING DATEEXX037 E1 RECORD ALREADY PRESENT IN FILE..........................##########EXX039 E1 OUTLET NUMBER MISSINGEXX041 E1 NO DATA ON FILE FOR DATA TYPE TO BE PROCESSEDEXX042 E1 OPTION VALUE INVALID OR MISSINGEXX043 E1 INVALID 'SKIP-TO' SEQUENCE NUMBER ENTERED SEQ.NO.EXX043 E2 A)'SKIP-TO' MUST BE IN SAME RANGE AS ADJUSTMENT SEQUENCE

NUMBEREXX043 E3 B)'SKIP-TO' MUST BE GREATER THAN ADJUSTMENT SEQUENCE NUMBEREXX044 E1 MESSAGE CODE IS NOT DEFINED IN MESSAGE FILE OM05

Screen Standards


EXX045 E1 REQUIRED RANGE RECORDS MISSING FOR FIELDEXX046 E1 VALUE NOT WITHIN RANGE LIMITSEXX047 E1 ENTER '/' TO DELETE FIELD.(ZEROES OR BLANKS NOT ALLOWED)EXX048 E1 '/' IS NOT ALLOWED FOR REQUIRED FIELDEXX049 E1 NO UPDATE ALLOWED FOR THIS FIELD (PROGRAM DEVELOPMENT GROUP)EXX050 E1 UPDATE NOT POSSIBLE ...... (KEY FIELD FOR INDEXED FILE!!!)EXX051 E1 DATA ENTERED EXCEEDS FIELD LENGTH.....................: ##########EXX052 E1 INVALID NUMERIC DATA ENTEREDEXX052 E2 1) NEGATIVE VALUE ENTERED FOR FIELD TYPE 'N'EXX052 E3 2) INVALID DEZ.SIGN OR MINUS SIGN NOT IN LAST POSITION OFFIELDEXX052 E4 3) TOO MANY DECIMAL POSITIONS OR ALPHA DATA ENTEREDEXX053 E1 VALUE ENTERED IS NOT PRESENT IN CODE INTERPRETATION PART OF XI01EXX053 E2 CHECK LOCATION INDICATOR IN DATA DICTIONARY RECORD FOR FIELDEXX053 E3 IF INDICATOR EQUALS 1.CODE VALUE MUST BE RECORDED WITH LOCATIONEXX054 E1 OVERLAPPING DATES !! ATTEMPT TO UPDATE TWICE !EXX055 E1 DATES MISSING !! DATE GAP BETWEEN LAST UPDATE RUN !EXX056 E1 NO FIELD PROCESSING OPTION PRESENT IN XI01 FOR FILE...: ##########EXX056 E2 PLEASE CONTACT EDP MANAGEREXX057 E1 ERRORS DATA DICTIONARY PART OF SYSTEM CONTROL FILE XI01.EXX057 E2 PLEASE CONTACT EDP MANAGER TO CORRECT DATA DICTIONARYEXX058 E1 FIELD TO BE DISPLAYED NOT PRESENT IN DATA DICTIONARY..: ##########EXX058 E2 CONTACT EDP MANAGER TO CORRECT FIELD PROCESSING OPTIONEXX058 E3 OR TO CREATE DATA DICTIONARY RECORD FOR FIELD CONCERNEDEXX059 E1 USER IS NOT AUTHORIZED TO UPDATE FIELDEXX059 E2 CONTACT EDP MANAGER2EXX061 E1 INVALID DATA IDENTIFIER ENTEREDEXX062 W1 CONTROL TOTAL MISSING OR NOT EQUAL COMPUTED TOTAL.....: ##########EXX063 E1 MANUAL ADJUSTMENT DATA MUST BE PRECEDED BY VALID ARTICLE DATAEXX064 E1 INVALID PERCENTAGE VALUEEXX065 E1 INVALID VALUE OR AMOUNTEXX065 E2 A) DATA MAY NOT BE NEGATIVEEXX065 E3 B) DATA NOT NUMERICEXX065 E4 C) TOO MANY DECIMAL POSITIONSEXX066 E1 INVALID FREE CASE VALUEEXX066 E2 A) QUANTITY MUST BE NUMERICEXX066 E3 B) NO DECIMAL POSITIONS ALLOWEDEXX066 E4 C) QUANTITY MAY NOT BE NEGATIVEEXX067 E1 EMPTIES EXCHANGE INDICATOR MUST EQUAL '0' OR '1'EXX068 E1 INVALID ADJUSTMENT LIST NUMBEREXX068 E2 ADJUSTMENT MUST BE DELIVERY BASED OR 1EXX068 E3 ADJUSTMENT LIST IS NOT A FREE CASE ADJUSTMENTEXX069 E1 NO ADJUSTMENTS ALLOWED FOR TRANSACTION CODE 177 OR 178EXX070 E1 ADJUSTMENT LIST IS NOT VALID FOR THIS OUTLETEXX070 E2 ADJ.LIST NO. FROM 9100 TO 9199 REQUIRES A VALID BILL-TO-OUTLETEXX070 E3 ADJ.LIST NO. FROM 9200 TO 9299 REQUIRES A VALID DISCOUNT-TO-OUTLETEXX070 E4 ADJ.LIST NO. FROM 9300 TO 9399 REQUIRES A VALID CREDIT-TOOUTLETEXX071 E1 EMPTIES EXCHANGE DOES NOT ALLOW EMPTY ARTICLE OR NEGATIVE QUANTITYEXX072 E1 DOCUMENT OR ORDER NOT CORRECTLY COMPLETED WITH 'ENTER' KEY


DESIGN STANDARDS





EXX072 E2 THE PROGRAM CANNOT HANDLE 'INCOMPLETE' ORDERS OR DOCUMENTS:EXX072 E3 A) DELETE ORDER/DOCUMENT WITH CMD-4EXX072 E4 B) ENTER ORDER/DOCUMENT AGAIN AND PRESS ENTER FROM LAST SCREENEXX073 E1 UNAUTHORIZED ARTICLE ENTEREDEXX074 E1 ARTICLE NUMBER OR ARTICLE QUANTITY MISSINGEXX075 E1 FUNCTION KEY NOT ALLOWED UNTIL TRANSACTION COMPLETELY ENTEREDEXX075 E2 IF CORRECTION OF DATA IS NOT POSSIBLE AT THE MOMENTEXX075 E3 CANCEL TRANSACTION WITH F4EXX076 W1 SUPPRESSED OUTLETEXX077 W1 SUPPRESSED ARTICLEEXX078 E1 DATA IDENTIFIER ONLY ALLOWED ON FIRST SCREEN OF A TRANSACTIONEXX079 E1 INVALID STOCK LEVEL QUANTITYEXX080 E1 INVALID OR NO ARTICLE NUMBER ENTEREDEXX081 E1 INVALID FREE PREFIX ENTEREDEXX081 E2 EITHER OXX-DOCRAN RECORD DOES NOT EXIST ON XI01 FILE FOR PREFIXEXX081 E3 ENTERED OR FREE PREFIX IS NOT ALLOWED DUE NOT OXX-DOCPFX RECORD

ONEXX081 E4 XI01 FILEEXX082 E1 DUPLICATE DOCUMENT NUMBER FOUND IN FILE.FP01.........: ###########EXX082 E2 ACTION --> USE RECOVERY 0 TO CANCEL THIS JOB AND REORGANIZEEXX082 E3 DOCUMENT NUMBER CHECK FILE FP01 IN MENU FPM001 ITEM #1EXX082 E4 THEN RESTART THIS JOB TO CONTINUE DOC.NUMBER ASSIGNMENTEXX083 E1 DOCUMENT NUMBER IDENTIFICATION MISSING ON XI01 FILEEXX083 E2 CREATE OXX-DOCID RECORD AND/OR INCLUDE DOCUMENT IDENTIFICATION

ONEXX083 E3 OXX-DOCID OPTION ON XI01EXX084 E1 INVALID BREAKPOINT VALUE ENTEREDEXX085 E1 DOCUMENT NO. RANGE MISSING FOR LOCATION/DOC-ID/PREFIX...##########EXX085 E2 CREATE OXX-DOCRAN RECORD ON XI01 SYSTEM CONTROL FILEEXX085 E3 CANCEL JOB AND CREATE OXXDOCRAN-RECORD ON XI01 FOR MISSING

RANGEEXX086 E1 INVALID DOCUMENT NUMBER PREFIX OPTION FOUNDEXX086 E2 EITHER INDICATOR NOT 'A'. 'B'. 'C'. 'D' OR LENGTH NOT 1 - 4EXX086 E3 OR PREFIX INDICATOR NOT IN ACCORDANCE WITH PREFIX LENGTHEXX086 E4 OR INDICATOR IS 'C' AND PAYMENT TYPE SUBSTITUTIONS(S) NOT 1 - 9EXX087 E1 INVALID MANUAL OVERRIDE OF TRANSACTION TYPEEXX088 E1 INVALID MANUAL OVERRIDE OF PAYMENT TYPEEXX089 E1 INVALID DOCUMENT NUMBER OR CHECK DIGIT ENTEREDEXX090 W1 OVERLAPPING DATES !! ATTEMPT TO UPDATE TWICE !EXX090 W2 F11 = BYPASS ERROR (USE ONLY IN RESTART SITUATION !!!)EXX090 W3 NOTE: CHECK REPEATED IN ACTUAL UPDATE PROGRAMSEXX090 W4 (NO RECOVERY POSSIBLE !)

Screen Standards


EXX091 E1 INVALID DELIVERY TRANSACTION CODE ##########EXX091 E2 ENTRY OF .PATY. .DOTY OR .TRTY RESULTS IN AN INVALID DELIVERYEXX091 E3 TRANS.CODE -OR- INVALID .TRCO ENTEREDEXX091 E4 ---> USE .TRCO TO OVERRIDE ALL 3 CODESEXX092 E1 PRICE LIST 910-949 REQUIRES A VALID BILL-TO/DISCOUNT-TO/CREDIT-TOEXX092 E2 PL.910-919 --> OM01 FLD.NO 091 (BILL-TO) IS MISSINGEXX092 E3 PL.920-929 --> OM01 FLD.NO 092 (DISCOUNT-TO) IS MISSINGEXX092 E4 PL.930-939 --> OM01 FLD.NO 093 (CREDIT-TO) IS MISSINGEXX093 E1 EMPTIES ARTICLE NOT VALID FOR IDENTIFIER...............:##########EXX094 E1 ONLY EMPTIES ARTICLE VALID FOR IDENTIFIER.............: ##########EXX095 E1 VALUE ENTERED IS INVALIDEXX095 E2 ENTER CORRECT VALUE OREXX095 E3 CREATE CODE INTERPRETATION FOR SPECIFIED VALUE OREXX095 E4 INCLUDE SPECIFIED VALUE IN RANGE RECORD LIMITSEXX096 E1 EMPTY SPLIT CODE MUST EQUAL '0' OR '1'EXX097 E1 ENTERED ARTICLE MUST NOT BE AN EMPTYEXX098 E1 ENTERED ARTICLE MUST BE AN EMPTYEXX099 E1 INVALID EMPTY INVENTORY OVERRIDE




EXX100 E1 SUBUNIT QUANTITY NOT ALLOWED FOR ARTICLEEXX101 E1 NO DATA FOUND FOR SELECTION CRITERIAEXX102 E1 FROM - TO RANGE SELECTION INCORRECTEXX103 E1 AT LEAST ONE SELECTION FIELD MUST NOT BE BLANKEXX104 E1 INVALID BUSINESS SEGMENT ENTERED OREXX104 E2 COMBINATION MISSING IN THE SALES DATA BASE FILE,EXX104 E3 CHECK OXX-KEYCMB RECORD IN XI01EXX105 E1 INVALID BUSINESS SEGMENT VALUE ENTERED OREXX105 E2 SEGMENT MISSING IN THE SALES DATA BASE FILE,EXX105 E3 CHECK OXX-KEYCMB RECORD IN XI01EXX106 E1 THE DEFINATION OF THE KEY COMBINATION IS NOT MATCHING WITHEXX106 E2 THE FILE, REBUILD THE DATA BASE FILES FOR THE PERIOD(S) OREXX106 E3 CORRECT OXX-KEYCMB RECORD IN XI01EXX107 E1 INVALID ARTICLE GROUP OR INVALID OR NO ARTICLE(S) SELECTED OREXX107 E2 ARTICLE(S) SELECTED BUT NOT REQUIREDEXX108 E1 INVALID OR NO ARTICLE GROUPING TYPE SELECTED, CHECK OXX-GROUPEXX108 E2 RECORD IN XI01, OR ARTICLE GROUPING TYPE SELECTED BUT NOT REQUIREDEXX109 E1 SELECTION OF AN ARTICLE GROUPING TYPE IS POSSIBLE ONLY TOGETHEREXX109 E2 WITH THE SELECTION SIGN FOR ARTICLE GROUPS, USE SYMBOL '+'EXX110 E1 INVALID BUDGET TYPE ENTEREDEXX111 E1 TOO MANY FIELDS SELECTEDEXX112 E1 INVALID SELECTION SIGN ENTERED, USE THE SYMBOL DEFINED BY THE


DESIGN STANDARDS


EXX112 E2 OPTION OXX-SELECT, OR THIS SELECTION SIGN IS NOT ALLOWED NOWEXX113 E1 INVALID ARITHMETICAL SYMBOL ENTEREDEXX114 E1 INVALID ADDITIONAL CONVERSION FACTOR ENTEREDEXX115 E1 INVALID SELECTION SIGN ENTERED, VALID CODES ARE: ' ' AND '1'EXX116 E1 INVALID SELECTION SIGN ENTERED, VALID CODES ARE: '1' AND '2'EXX117 E1 INVALID NUMBER OF COLUMNS ENTEREDEXX118 E1 INVALID SYMBOL FOR PAGE SKIP ENTEREDEXX119 E1 INVALID FIELD NUMBER ENTEREDEXX120 E1 INVALID COMBINATION OF SELECTIONS, IT IS NOT ALLOWED TO COMBINEEXX120 E2 DIFFERENT KINDS OF SEGMENT TYPES ON ONE REPORT, THE FIRST SEGMENTEXX120 E3 TYPE MAY NOT BE A COMBINATION OF FIELDS, ONLY ONE LETTER ALLOWEDEXX121 E1 INVALID GROUPING LIST ENTERED, CHECK AM03EXX122 E1 INVALID COST AND/OR ADJUSTMENT CLASS ENTEREDEXX122 W1 INVALID COST AND/OR ADJUSTMENT CLASS ENTEREDEXX123 E1 INVALID TIME FRAME ENTERED, CODE MUST BE EQUAL 1EXX124 E1 ONLY AN AVAILABLE KEY COMBINATION IS ALLOWEDEXX125 E1 A DIFFERENCE FIELD MAY ONLY BE SELECTED TOGETHEREXX125 E2 WITH THE CORRESPONDING CURRENT FIELDEXX126 E1 THE SHARE TO GROWTH LEVEL MAY NOT BE BLANK WHEN A FIELDEXX126 E2 'SHARE OR PERCENT OF A VARIABLE LEVEL' WAS SELECTEDEXX127 E1 FOR SELECTED PERIOD NO SALES DATA BASES OR SALES BUDGET FILESEXX127 E2 ARE AVAILABLE OR NO EXX-SDCONT RECORD WAS FOUND IN XI01EXX128 E1 THE CONTRIBUTION LEVELS MUST BE IN ASCENDING ORDEREXX129 E1 INVALID PERIOD ENTERED, VALID CODES ARE ' ', '1' OR '7'EXX130 W1 IMMEDIATE INVOICING FOR A PREVIOUS DAY HAS NOT BEEN COMPLETEDEXX130 W2 THE MENU ITEM 'END OF DAY' FOR IMMEDIATE INVOICING,WHERE INVOICESEXX130 W3 ARE TRANSFERRED AND LOAD REPORT IS PRINTED SHOULD BE EXECUTEDEXX130 W4 BEFORE A NEW DAY IS STARTEDEXX131 E1 YOU ARE NOT AUTHORIZED TO RUN THIS COMPLEX .....EXX131 E2 ************************************************EXX131 E3 *** INFORM YOUR SECURITY OFFICER ***EXX131 E4 ************************************************EXX132 W1 ENTERED YEAR IS NOT EQUAL SYSTEM YEAR. CMD-12 --> ACCEPT.EXX133 W1 WAITING FOR A RESERVED DOCUMENT RANGE.................: ## # ####EXX133 W2 CURRENTLY OCCUPIED BY ANOTHER JOB................: ######-## ## ##




EXX133 W3 PROGRAM WILL AUTOMATICALLY CONTINUE WHEN FREE. IN SPECIAL CASESEXX133 W4 THE RESERVATION CAN BE REMOVED WITH XIM000-01 FROM ANOTHER SCREEN.EXX134 W1 JOB THROUGH WAITING FOR RESERVED DOCUMENT. PROGRAM CONTINUESEXX135 E1 INVALID OR NO OXX-PERIOD OPTION FOR TYPE/YEAR/NUMBER ##########

Screen Standards


EXX135 E2 A) CREATE OXX-PERIOD OPTION ON SCF XI01, IF NOT EXISTINGEXX135 E3 B) CHECK PERIOD FROM-TO DATES ON VALIDITYEXX135 E4 C) OXX-CALEND OPTIONS WITHIN FROM-TO DATES MUST ALSO EXISTEXX136 E1 VALUE MORE THAN ONE TIMES ENTEREDEXX137 E1 WRONG FILES USED: THE FILE GAS ALREADY BEEN CONVERTED OREXX137 E2 THE FILE HAS AN OLD LAYOUT OREXX137 E3 IS NOT CORRESPONDING WITH THE PROCESSING DATEEXX138 E1 INCORRECT OXX-FIELDS OR OXX-KEYCMD RECORD IS DEFINED IN XI01EXX139 E1 INVALID ARTICLE GROUPING TYPE OR ARTICLE GROUP ENTEREDEXX140 E1 FOR SELECTED CALCULATION SIGN, AMOUNTS MAY NOT BE ZEROEXX141 E1 LOCATION ENTERED NOT PRESENT ON CURRENT INPUT FILEEXX142 E1 INVALID COMBINATION OF SELECTION SIGN AND FUNCTION KEY OREXX142 E2 INVALID SELECTION SIGN ENTEREDEXX143 E1 INVALID COMBINATION OF SELECTIONS OR INVALID SELECTIONEXX143 E2 SIGN ENTEREDEXX144 E1 AT LEAST ONE PERCENTAGE VALUE MUST NOT BE ZEROEXX145 E1 INVALID COLUMN NUMBER SELECTEDEXX146 E1 INVALID CONSTANT VALUE ENTERED FOR CALCULATIONEXX147 E1 NO DETAIL INFORMATION AVAILABLE FOR SPECIAL COLUMN ASSIGNMENTEXX147 E2 PRESS F4 'UNDO COLUMN ASSGNMNT' AND REPEAT DETAIL SELECTIONSEXX148 E1 INVALID SELECTION SIGN OR INVALID BUDGET TYPE ENTERED OREXX148 E2 FIELD NOT VALID FOR BUDGET SELECTIONEXX149 W1 ARTICLE HAS ERROR STATUS ON AM01EXX149 W2 CHECK AM01 - MAINTANANCE MAY NOT BE FINISHED CORRECTLYEXX149 W3 F11 ACCEPT ARTICLE WITH ERROREXX150 E1 INVALID COST AND/OR ADJUSTMENT TYPE ENTEREDEXX151 W1 OVERLAPPING DATES !! ATTEMPT TO UPDATE TWICE !EXX152 E1 ARTICLE GRP OVERVIEW FOR USER CALC FIELDS NOT ALLOWED ON S36EXX153 E1 F11 PRESSED TO BYPASS WARNING, BUT TERMINAL ERROR ALSO PRESENT.EXX153 E2 PRESS F1 TO PAGE THROUGH ERROR MESSAGES.EXX153 E3 FIRST CORRECT TERMINAL ERRORS, THEN F11 WILL BE ACCEPTED.EXX153 E4EXX154 E1 INVALID JOBQ/EVOKE OPTION ENTERED, VALID CODES ARE: ' ', 'J', 'E'EXX155 W1 ENTERED YEAR IS NOT EQUAL SYSTEM YEAR. F11 --> ACCEPT.EXX156 W1 ARTICLE HAS ERROR STATUS ON AM01EXX156 W2 CHECK AM01 - MAINTENANCE MAY NOT BE FINISHED CORRECTLYEXX156 W3 F11 --> ACCEPT ARTICLE WITH ERROREXX157 E1 F11 PRESSED TO BYPASS WARNING, BUT TERMINAL ERROR ALSO PRESENTEXX157 E2 PRESS F1 TO PAGE THROUGH ERROR MESSAGES.EXX157 E3 FIRST CORRECT TERMINAL ERRORS, THEN F11 WILL BE ACCEPTED.EXX157 E4EXX158 E1 MORE THAN ONE ERROR FOUND. USE F1 TO PAGE THROUGH ERROR MESSAGES.


DESIGN STANDARDS



Screen Standards


2.3 Screen Standards

2.3.1 Following SAA Standards for Common User Access2.3.2 Screen Documentation2.3.3 General Screen Layout2.3.4 Standard Screen Sequence to Start an Action2.3.5 Action Bar2.3.6 Action Codes2.3.7 Windows2.3.8 Overview Screens (=list panels)2.3.9 Entry Screens (=entry and menu panels)2.3.10 User Defined Screens and Windows (Screen Design Facility)2.3.11 Function Keys2.3.12 Commands in 'Expert mode'2.3.13 Options and Selection Methods2.3.14 Input Fields2.3.15 Instructions2.3.16 Error Messages and Informational Messages2.3.17 Help Support2.3.18 Language Translation ('Patchable' constants)2.3.19 Performance Considerations

DESIGN STANDARDS


2.3.1 Following SAA Standards for Common User Access

Statement:

All new BASIS applications developed from 1989 onwards follow the standards asdocumented in this chapter. Most of the guidelines are taken from IBM's SAAconcept for CUA but also keeping to old BASIS standards in favour of the integretyof the package. Abbreviations SAA and CUA stand for:

SAA ... System Application ArchitectureCUA ... Common User Access

All standards specified in chapter 2.3 are based on the technical capabilities of theS/36 Screen Format Generator ($SFGR) and follow the SAA/CUA rules for:

Non-programmable terminalsCharacter applications

Refer to publications:

IBM SC26-4351-0 SAA Common User Access, Panel Design and UserInteraction

COCA-COLA Common User Access Design Specifications for use at theCoca-Cola Company

Deviations from SAA-CUA standards:

The following exceptions to SAA rules are made because of two reasons, firstbecause of the limited capabilities of the S3/X screen format generator, andsecondly to keep up the general outline of the BASIS package (= old plus newapplications!):

1) Panel id/title: Always appears in line 1 together with program name/modification levels, and so on instead in line 3 belowaction bar.

2) Action bar: Action bar choices are in reverse image insteadnormal intensity, selected emphasis is in reverseimage/high intensity instead in reverse image/nornalintensity.

Screen Standards


3) Help: HELP key is used to request help information insteadF1. Extended help (F2) and Help index (F11) are notsupported. Help can not be requested from action bar.

4) Function keys: F1 and F2 are used to roll through error messages inthe message area instead of being used to requesthelp/extended help.F11 is used to accept warnings instead of being usedfor help index.F-keys for optional SAA features (such as F4=prompt,F5=refresh, F9=retrieve) can be used for otherapplication functions instead of reserving them strictly.

5) Function key description: Long format is always displayed in lines 23-24 ofprimary window instead of providing the user option toswitch between long/short/no display of F-keys.

6) Windows: A star frame in reverse image/high intensity is used asborder instead of a double or single line. Pull-downwindows also have a panel-id instead none.

7) Message area: Lines 23-24 of the primary window are used asmessage area as well as for function key descriptionsinstead of keeping both separate. If error occurs in asecondary window the message is displayed inmessage area of primary window instead of placingthe message in secondary window or in an adjacentmessage window.

2.3.2 Screen Documentation

User Guide and Technical Guide:

1) Each guide includes a chapter (Chapter 2) which introduces the application onthe system. It shows the application's menus and gives a general explanation ofthe menu items. The Technical Guide includes menus which are more related tothe EDP department rather than an end user, such as the Housekeeping Menu.

If a screen is used in different tasks or menu items which are explained in differentchapters, Chapter 2 should contain a section describing the general layout of the

DESIGN STANDARDS


common screen, along with a sample of the screen. This prevents having to explainthe screen twice or more within the manual.

Chapter 2 should also contain a section on standard routines if they are usedthroughout an application. Standard routines include use of the action bar, on-linehelp and the shortcut facility. This section shows significant screens with examplesof the routine.

2) All sections of a guide that contain step-by-step instructions show all thecorresponding screens in the sequence as they appear on a user's workstation.

3) Important areas on menus and screens are highlighted and arrows indicate therelation between fields and screen caption text.

2.3.3 General Screen Layout

This chapter describes the layout of a full-size panel with 24 lines x 80 characters.It is referred to as primary window (SAA term) or as main screen (former BASISterm).

....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80 1| uu X--loc---X BASIS X-------title---------------------------X 00 00 aaPnnn/Snn | 1 2| N X-action-X N X-action-X N X-action-X N X-action-X N X-action-X | 2 3| A XX/XX/XX | 3 4| | | 4 5| | | 5 6| | | 6 7| | | 7 8| | | 8 9| | | 9 10| Panel body in lines 3-22 (if action bar) |10 11| or in lines 2-22 (if no action bar) |11 12| | |12 13| | |13 14| | |14 15| | |15 16| | |16 17| | |17 18| | |18 19| | |19 20| | |20 21| | |21 22| ===> A-----------------V-----command entry line (optional)----------------A |22 23| X---key1---X X---key2---X X---key3---X X---key4---X X---key5---X X---key6---X |23 24| X---key7---X X---key8---X X---key9---X X---key10--X X---key11--X X---key12--X |24 ....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80

Screen Standards


Or if error message is displayed in message area (lines 23-24):

....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80 23| Eaannnt X-----error message line 1----------------------------------------X |23 24| X----F1----X X----F2----X X---(F11)--X X---key?--X X----key?--X X---HELP---X |24 ....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80

Or if additional information for error message is displayed (F2):

....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80 23| Eaannnt X-----error message lines /2\ or /4\ or /6\ or /8\---------------X |23 24| X-------------------------\3/ \5/ \7/ \9/---------------X |24 ....:...10....:...20....:...30....:...40....:...50....:...60....:...70....:...80

A detailed description of the individual elements follows on the next pages

Line 1 always contains standard heading (FMT01):

us User-Id --loc-- Short name of Sign-on location, from XI01 OXX-LOCNAM BASIS Non-patchable constant (high intensity or white on color

screens) --title-- Application and screen title (= panel title), patchable constant

in capital letters. Examples:'OUTLET SELECTION RUN OPTIONS''O S RUN OPTIONS'

00 00 Modification levels of program and format member aaPnnn/Snn Program name and screen number, non-patchable (high

intensity or white on color screens)

Line 2 is used as action bar on screens with 2 or more actions supported. Simplescreens with only one implied action do not have an action bar.

N One-byte input field in front of every action bar element.

X--action--X User constant defined in XI01 option Aaa-SCRFCT-nnn12 bytes long (aa=application, nnn=function number).

DESIGN STANDARDS


Non-active action bar elements in reverse image/normalintensity or green background on color screens.The currently active element (selected emphasis) in reverseimage/high intensity or white background on color screens.

On AS/400 and S/36 the action bar must be combined in one format with theapplication input format, in most cases.Five choices fit into one line. If more than 5 choices are used on screen either F23can be used to roll action bar horizontally or an action bar element 'OTHERS' isused to offer the remaining choices in a pop-up window vertically.

Lines 3-22 can be used for the application, such as overview (= list) panels orentry panels, if line 2 is used as action bar.

Lines 2-22 can be used for the application, if no action bar is present in line 2.The following rules apply within the panel body:

• The system date (external,edited) must be in line 2 or 3,pos.72-79

• An instruction must appear on top (line 3/4).Example:'Select an action from action bar and select a version, pressENTER.'

• If command entry is supported then the command entry linemust be at the bottom (see line 22 described below).

• Design of the middle part is up to the analyst• For panel type overview (=list) see chapter 2.3.7.• For panel type entry see chapter 2.3.8.

Line 22 is used as command entry line, if supported (optional):

'===>' Non-patchable constant. Same sign as used on AS/400! --command-- 70-bytes input field for entry of commands and parameters.

On AS/400 and on S/36 the command entry line must be combined in oneformat with the application input format, in most cases. For standards oncommands in 'expert mode' refer to chapter 2.3.11.

Lines 23-24 are used for key descriptions and error messages (FMT99):

X---key?---X 12-bytes patchable constant for description of functionkeys.

Screen Standards


Eaannnt Error code with aa=application,nnn=error number andt=type W or E (reverse image or green background oncolor screens, in one block with error message)

--error message-- Patchable message text from XI01(reverse image orgreen background on color screens, in one block witherror code)

If no error is on the screen description for all currently active function keys aredisplayed. If less than 6 F-keys they are diplayed in screen line 24. If morethan 6 they are displayed in lines 23-24.If an error occurred or F1 is pressed the main message (stored as 'messageline 1' in XI01) is displayed in screen line 23 and key descriptions for F1/F2/F11/HELP+ others (key?) are displayed in screen line 24.If F2 is pressed further message lines of the same error are displayed inscreen lines 23-24 erasing the F-key descriptions in screen line 24.

Line 23 can also used to display information messages such as'** Calculationhas been completed, select next route.'For standards on messages refer to chapter 2.3.14.

Standards for the different screen sections are further explained in thefollowing chapters.

Frames for the formats FMT01, FMT99, and for the action bar line and commandentry line are available in format source member XMF999 in library SYSMOD.

Two examples are following:

1. CBP090/S09 Simple entry/selection screen without action bar.Application panel goes from line 2-22 with instructions in lines3-4 and one input field in line 19.

2. OSP001/S01 Overview/selection screen with an action bar in line 2Application panel goes from line 3-22. Input is allowed from theaction bar and also in the overview format to select a version.The cursor is positioned on the first action bar choice.

DESIGN STANDARDS


Example 1:

EL LOC11 CCCS BASIS CB ENTRY SETTLEMENT DATE 00 00 CBP090/S01

02/10/89 Enter settlement date under which you want to process CB deliveries, based on execution calender:

PERIOD 1---+---10----+---20----+----31

8901 | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 8902 | XXXXXXXXXXXXXXXXXXXXXXXXXXXX BLANK = no settlement 8903 | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X = days to be 8904 | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX settled 8905 | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 9 = days already closed

Last Settlement Date Was........ 09.02.89

New Settlement Date............ 010189

ROLL UP / ROLL DOWN CMD-7 End of job HELP key for information press ENTER to continue

Example 2:

MW CCCS VIENN BASIS OUTLET SELECTION - VERSION OVERVIEW 00 00 OSP002/S01 Design File/Save 890928

No Description Owner Type Status __ 001 FIRST TEST UNDER N6 SMART __ 002 SLAVES TEST SMART __ 003 SECND TEST SMART __ 004 OUTLET SELECTION SMART __ 005 BFO-VERSION SMART __ 006 BFO SECOND VERSION SMART

Bottom ROLL UP / ROLL DOWN CMD-7 End of job HELP key for information

Screen Standards


2.3.4 Standard Screen Sequence to Start an Action

The same sequence of performance steps must be followed in all BASIS screenprograms to start and perform a function from an action bar. The SAA designprinciple of Object-action' is followed but the 'Action-object' sequence is alsopossible.

STEP 1 Primary window with action bar is presented by the program. Allaction bar choices are in reverse image/normal intesity (or on greenbackground on color screens). Cursor is at first choice. An instruction isdisplayed below the action bar, like 'Select an action from action bar,select outlet from overview. Press ENTER.'

STEP 2 User selects an action and object(s), and presses the ENTER key.An action is selected by keying any character into an input field of theaction bar (using the TAB-key or FIELD EXIT to move the cursor).Object(s) are selected by keying any character into the inputfield(s) of the overview (using the TAB-key or FIELD EXIT or the New-Line key to move the cursor).If only an action is selcted but no object an error message appears ifthe action requires an object.If both action and object was selected but no object is required theselected object is kept as selected (no error message).If only object(s) were selected but no action the program shows them inhigh intensity (selected emphasis) and waits for an action to be se-lected later (no error message).

STEP 3 The selected object is shown in high intensity (or white on colorscreens) and the selected action bar element is shown in reverseimage/high intensity (or on white background on color screens).A pull-down window appears below the action bar choice, eitheraligned to the left or the right edge of the selected element in line 2.The window contains instructions and input fields for the next step.

STEP 4 User enters input fields in window (if any) and follows instructions.F3 or F12 are available to exit from the started action and to take theuser back to STEP 1.

DESIGN STANDARDS


STEP 5 If another step is necessary before the function can be performedthe program displays another window as described in steps 3 and 4.The secondary window should be placed so that it overlaps the firstwindow, if the layout permits. F12 is used to return to the first window,F3 returns to STEP 1.

STEP 6 When the user has gone through all windows the program performsthe selected action. As a result the original primary window with re-freshed data is redisplayed or a new screen is displayed. An informa-tion message should be displayed:

a) in a window if the action takes time (for example, 'Articlegroups are being loaded')

b) in line 24 in high intensity (or white on color screens) when afunction has finished and no new screen is displayed (forexample, 'Calculation has been completed, select next route').

No message is necessary if a new screen is displayed and the action doesnot last long.

2.3.5 Action Bars

Definition:

An Action bar is a group of functions that can be performed from one screen. Theyare displayed in line 2 of the screen. The functions within an action bar are referredto as 'action bar choices' or as 'action bar elements'.

Optional:

Simple screens with only one implied action do not have an action bar. As a rule ofthumb: If you attempt to use a function key (other than standard keys F1/F2/F3/F11/F12/F23/F24)) to perform a function an action bar is required (for instance donot use F4 to delete!).

Screen Standards


Layout:

The action bar line contains one to five choices with a one-byte input field in front ofeach choice. There should be 5 functions each with 1 byte input and a 12 characterconstant field. The 5 x (1+12) character layout is available in member XMF999 inlibrary SYSMOD.Non-active choices are shown in reverse image/normal intensity (or on a greenbackground on color screens), the activated function is shown in reverse image/high intensity (or on white background on color screens).

Naming of actions:

Each action bar choice is labelled with a verb or noun that best describes theaction or group of actions that it contains (examples: UPDATE, VIEW, DELIVERY,PAYMENTS).These words are specified as user defined constants in XI01 option Aaa-SCRFCT-nnn (aa=application, nnn=function number) together with its corresponding 'expertmode' command.

Selecting an action bar element:

An action is selected when any character is keyed into the input field in front of itsaction bar choice. At the same time one or more object(s) can be selected from theoverview. Then the ENTER key must be pressed. Only one action is accepted bythe program at the same time. See also T3, 2.3.4.

Selecting an action bar element with mnemonic commands ('expert mode'):

Alternately a one to three-character abbreviation of the associated action barconstant can be entered in a command line (normally in line 22). This commandalso selects an action bar function.

Because the cursor is initially positioned at the first action bar choice the user firsthas to move the cursor to the Command entry line (use Back-Tab Key). Then hecan type the command and press the ENTER key. Such mnemonic commands aredefined in the System Control File (option Aaa-SCRFCT-nnn) and can be changedby users into local languages.

Example: A Second action bar selection for 'DISPLAY' can either be selected bykeying any character into the second input field in the action bar (line 2)or by keying 'DI' in command entry line (line 22) and pressing ENTER.

DESIGN STANDARDS


Sequence of action bar choices within line:

Main functions available on a screen are arranged from left to right in the sequenceof their importance or in the sequence they have to be performed. No gaps are tobe left free.

Unavailable action bar choices:

For programming it is often preferrable to show the same sequence of choices inthe action bars on all screens of a program although not every action is availableon every screen. In this case the unavailble choices are displayed in normalintensity without reverse image (or green on color screens) and its input field is setto protected and non-diplay.

Additional functions in an action bar line (F23):

If an application has more functions than fit in one action bar line, F23 can be usedto roll functions in line 2 horizontally.

When F23 is pressed, the currently displayed functions in the action bar line arereplaced by another 1 to 5 functions. When F23 is pressed again the originalfunctions are redisplayed. F23 can also roll 3 or more action bar lines within ascreen when applicable. How functions are presented and over how many lines, isleft up to the analyst of an application.

Action bar 'OTHERS':

As an alternative to opening a second action bar line with F23, additionalsupporting functions can be collected under the last choice 'OTHERS' of the firstaction bar line.

If the "OTHERS' function is selected, a window is displayed which offers the otherfunctions. It works just like a vertical action bar: a list of action bar constants isdisplayed, each headed by an input field in which any character is keyed forselection.

An example of the action bar function 'OTHERS' follows on the next page.

Screen Standards


Example: Screen CBP100/S01 with 5th action bar choice = OTHERS

GD CCBELGIQUE BASIS CB LOCATION OVERVIEW - VERSION NUMBERS 00 00 CBP100/S10

Display Proc./Reproc. Error Corr. Calculate Others--> Type any char. left to desired function. HOME moves cursor to top.

Settlem. date: 01/31 02/15 02/28 03/15 03/31 04/15 04/30 05/15008 <-#loc--> 000 001 000 001 000 001 001 00401 SOKODRINK NIL 00702 ANVERS NIL03 LA LOUVIER 00104 MAASTRICHT05 LIEGE06 GOSSELIERS NIL NIL NIL NIL07 BRUGGE08 GANCO GENT

(*=still errors, c=already calculated, s=suspended) BottomROLL UP / ROLL DOWN CMD-7 END OF JOB HELP KEY FOR INFORMATION

When OTHERS is selected, a pull-down window presents the 'other' functions

GD CCBELGIQUE BASIS CB LOCATION OVERVIEW - VERSION NUMBERS 00 00 CBP100/S10

Display Proc./Reproc. Error Corr. Calculate 1 Others

** Sel. func.*** CBW105** * * Type any char. left to desired function. HO * Select with any char.* * *Settlem. date: 01/31 02/15 02/28 03/15 0 * Suspense *008 <-#loc--> 000 001 000 001 0 * Inquiry *01 SOKODRINK * mark NIL *02 ANVERS * *03 LA LOUVIER * CMD-3=Exit HELP*04 MAASTRICHT *************************05 LIEGE06 GROSSELIERS NIL NIL NIL NIL07 BRUGGE08 GANCO GENT

(*=still errors, c=already calculated, s=suspended) BottomROLL UP / ROLL DOWN CMD-7 END OF JOB HELP KEY FOR INFORMATION

DESIGN STANDARDS


2.3.6 Action Codes

Definition:

Action codes are one- or two-character codes which identify an action and whichcan be used to directly select object(s) for processing. They are used as alternativemethod to selecting an object and an action from the action bar separately.

Example:

EL VIENNA BASIS C B LOCATION/VERSION OVERVIEW 00 00 CBP100/S10 _ Display _ Process _ Correct _ Calculate _ Others

Select action from action bar and select one location, press ENTER. Or, select one or more location(s) with action codes, press ENTER: 1=Display 2=Process 3=Correct 4=Calculate

Locations 01/31 02/15 02/28 03/15_ 01 VIENNA 001 002 003* 004c_ 02 SALZBURG 005 006* 008*_ 03 INNSBRUCK_ 04 GRAZ_ 05 LINZ etc.

ENTER F3=exit ROLL up/dwn HELP Sel.sign=any

Aaa-SCRFCT options:

Action codes and their associated text are stored on the System Control file XI01along with the action bar functions. Both, codes and text, can be translated by theuser. If no Aaa-SCRFCT records are found on XI01 (or action code fields areblank) the program uses its own 'hardcoded' defaults (usually numbers 1-9).

Use:

Action codes can be used in addition to an action bar or without action bar. As arule: if a program has an action bar then the actions supported by action codesmust also be present in an action bar.Action codes can be used on overview screens if multiple objects can be selectedtogether and/or multiple actions can be selected from one screen.

Screen Standards


For instance, on AS/400 the Program Developement Manager (PDM) uses actioncodes to edit/copy/delete/and so on members.

2.3.7 Windows

Definition:

In SAA the term 'window' defines a screen format of any size in which the user andthe computer communicate. There are primary windows (full screen) andsecondary windows (only parts of screen). In this context a window is a secondarywindow which occupies only part of the screen and leaves all unused lines/columnsof the primary window unchanged.

Types of windows:

There are 2 types of windows: Working windows (input expected) and Informationwindows (no input).

Use:

Working windows: Pull-down windows from action bars, viewing/changing ofoptions, selection of one or more items from alist (withROLL), entry panels for parameters orlow-volume data, andso on.

Information windows: Help windows, message windows (e.g. to explain longwaiting times), and so on.

Windows should not be used for: Overview screens and high-volume data entry.

Layout for working windows:

....:...10....:...20....:...30....:...401|** X---title--------------X ** aaWnnn **|12|* X----instruction-------------------X *|23|* A *|34|* | *|45|* <---------- Panel body -----------> *|56|* | *|67|* V *|78|** X--key---X X--key---X X--key---X ****|8 ....:...10....:...20....:...30....:...40

DESIGN STANDARDS


aaWnnn: Window number (= panel-id) embedded in the star frame in theright upper corner (aa = application, nnn = 001-999).

--title--: Patchable constant as window title embedded in the star frame.For consistency it should repeat the text of the prior step (forexample, 'Select ORDER' or 'PROCESS new data file')

--instruction--: Optional patchable text over one or more lines at the top to guidethe user (in addition to title)

window format: Application data in form of input fields, output fields and text

-key descr.-: Patchable constant for key descriptions, embedded in the starframe

frame: Stars'*' non-patchable (high intensity/reverse image or whitebackground on color screens)

Layout for information windows:

....:...10....:...20....:...30....:...401| X----title----------------X X--type--X |12| A |23| | |34| | |45| <--------- Information text ---------> |56| | |67| | |78| V |89 | X---key descriptions-----------------X |9 ....:...10....:...20....:...30....:...40

--title--: Patchable constant for field name or other title (for Help format) orblank (for other message)

--type--: Patchable constant '-Help-' or '-Message-'

frame: No frame.Instead line 1 in reverse image/ high intensity (or whitebackground on color screens) and the rest in reverse image/normal intensity (or green background on color screen).Furthermore line 1 is defined as protected input field. Thisprevents from keying data on the original format on S/36.

Screen Standards


--key descriptions--: Patchable constants to describe meaningful keys:ENTER = Return, ROLL UP = more (only within field),ROLL UP = Next field, ROLL DOWN = F-Keys (fromlast field of a screen), and so on.

Shape of window and placement on main screen:

The shape always depends on the application requirements. The placement of awindow also depends on the application requirements. However, the followingguidelines are to be used:

• A pull-down window from an action bar is placed one line below the actionbar and is aligned either to the right or to the left of the selected element.

• A window should not overlap valuable information on the screen.• A window must not overlap the bottom area with function key descriptions.• A help window should be placed adjacent to the field it describes.

For general help texts any place that does not hide valuable information onthe screen is possible.

• A message window should be placed adjacent to the part of the main screento which it pertains, but should not cover it.

Overlapping windows:

Windows that immediately follow another window in order to perform one functionshould overlap (for example option entry in 2 steps). The second window is placedon top of the first window so that still the 2 top or bottom lines and the 2 left or rightcolumns are visible. In order to simulate a 3-dimensional appearance thesecondary window should be surrounded by blanks in addition to the star frame.For the AS/400 and the S/36 screen format generator that implies:

• additional output field with constant blank at top or bottom• attribute bytes automatically provide blanks to the right• additional blank in front of the left '*'

Examples for placement of overlapping windows:

************ ************ ************ ************ * 1 * * 1 * * * * ************* * * ************ ** * * * * *** 2 * * * * 2 * * * 2 * * 2 * ** * ** ** * * * ************ ************ ** * * * * 1 * * 1 ************* ************ ************ ************

DESIGN STANDARDS


User defined windows:

A window that displays data from files can be user defined through the SDF(Screen Design Facility) feature. The analyst has to decide if a window can behandled thru the SDF and corresponding Aaa-SCREEN options must be created.For each SDF defined window the user can define up to 99 different layouts, eachlayout displaying 63 selected fields from the BASIS data dictionary. For moreinformation refer to chapter T3, 2.3.9.

Instructions:

Instructions should tell the user what to do from this window, including which keymust be pressed. Instructions, if necessary, appear at the top of the window andmay extend over two or more lines if required. Information windows do not normallycontain instructions, such as Help windows.

Input fields:

A window may contain input fields to enter data/options or to make selections.Rules as documented in chapters 2.3.11 (Options and selection methods) and2.3.12 (Entry fields) must be followed.

Function-key descriptions:

Function keys that are valid for this window are displayed at the bottom of thewindow. 12-character common constants are available for the standard functionkeys (do not define as constants in format).

Standard function-keys:

ENTER: to continue, input fields are accepted, checked and processedF3: to terminate the current action (back to action bar!)F12: to return to the previous window (only one step back!)ROLL : if required

Error messages:

Any error messages for invalid input in the current window appear at the bottom ofthe main screen (FMT99). Standard error handling with F1/F2/F11 is provided.

Screen Standards


Frame XMF999:

A standard frame for both, working windows and information windows, is availablein member XMF999 in library SYSMOD.

2.3.8 Overview Screens (=list panels)

Definition:

The term 'overview screen' is equivalent to the SAA term 'list panel'.An overview screen lists a variable number of similar items. Typically one line peritem is displayed in a 'body' of, say 12 lines, that can be scrolled and from whichthe user can select one or more items.

User defined line layouts (Screen Design Facility):

The SDF (Screen Design Facility) feature should be used to display overviewscreens whenever possible. It enables the user to define the fields to be displayedper line, up to 99 different line layouts. In this way the decision what to show onoverview screens is given to the user. It is possible to alternately view the differentlayouts in a session.

The analyst has to decide if an overview is to be handled through the SDF andcorresponding Aaa-SCREEN options must be submitted together with the program.An action bar choice 'Select Layout' must be included in the application screenprogram which calls up modules to select user defined 'layouts' (layout number 01-99) and prepare output data per line. For more details see chapter 2.3.9 Userdefined screens and windows.

Instructions:

A user guide instruction line is always placed on top (or any other convenientplace) of the overview body. It may extend over 2 or more lines, if necessary.

Example:

'Select one outlet, press ENTER. If outlet is not on screen, use ROLL keys.'Refer to chapter 2.3.13 for more information on Instructions.

DESIGN STANDARDS


Signify top and bottom of overview:

The same method is used as on AS/400. The right lower corner is used to placeone of 3 patchable (common) constants in high intensity (or white color). Forexample: Overview lines go from line 9 to line 20, the patchable constant alwaysappears in line 21, pos.68-79.

'more......' if more items follow after the last displayed line '--Bottom--' if the last item is displayed on that screen, blank lines may appear

between the last data item and line 21 '--Top-- ' is shown if a ROLL-down was made to the first screen.

If the first screen is shown initially than 'more......' is displayed and n o t '--Top--'!If ROLL-DOWN is pressed from the first screen or if ROLL-UP is pressed from thelast screen an informational message is displayed in line 24 and the screenremains unchanged. Two common constants are available for the informationalmessage:

'** The Top has already been reached. ROLL-DOWN is not possible.' '** The Botttom has already been reached. ROLL-UP is not possible.'

If no data is present on the files to be displayed on an overview an empty screen ora screen with a patchable text 'No data present' is displayed.

Select object(s) from the overview for processing:

Usually the items (=objects) displayed in the panel body are selected for furtherprocessing. The analyst/programmer can use two methods:

• select object(s) from the overview and an action from the action bar• use action codes to directly select object(s) from the overview

The two methods are described in more detail in T3 chapters 2.3.5 and 2.3.6.

Screen Standards


2.3.9 Entry Screens

Definition:

The term 'entry screen' combines both SAA-terms 'entry panel' and 'menu panel'.Entry screens contain a number of input fields to enter options, low-volume data orhigh volume data.

Field prompts:

Description to the left, input filed in the middle, and permitted values, if applicable,to the right. For example:

Document type................. __ 1=settl.header 2=helper 5=outload6=inload 8=deliv.document

Article group..................... __ 01-99 or ?=Prompt

Tabular entry screen for high volume data entry:

For real data entry a tabular design should be used with column headings. Forexample:

Artno Quantity Artno Quantity Artno Quantity_____ ___________ _____ ___________ _____ ________________ ___________ _____ ___________ _____ ________________ ___________ and so on

Instructions:

An instruction line is always placed on top of the panel body (line 2 or 4) or at thebottom (line 21-22). The text may extend over 2 or more lines, if necessary.

Example:

'Key changes to print options, press ENTER. If no change, just press ENTER.'Refer to chapter 2.3.13 for more information on Instructions.

DESIGN STANDARDS


2.3.10 User Defined Screens and Windows (Screen DesignFacility)

Definition:

The BASIS II Screen Design Facility allows the user to define:

• line layout of overview screens(up to 63 fields horizontally)• block layout of consecutive lines (up to 04 lines with 2 fields each)• windows (up to 63 fields vertically)

XI01 options Aaa-SCREEN and Oaa-SCREEN:

Options Aaa-SCREEN store the file and field definitions for the line, block andwindow layouts. Screen numbers are BASIS defined, layout numbers are userdefined. Fields are defined with field numbers from the BASIS data dictionary. Thefollowing symbols are used: aa=application, nn=main screen number 01-99,B/L=fixed letters known to the program, ll=layout number 01-99, Fn=field definitionsF1-F9 for 9 possible records each 7 fields.

Aaa- SCREEN-nn Main screen header for screen aaSnn- SCREEN-nnL Line definition header for screen aaSnn- SCREEN-nnLll Layout header for aaSnn overview line- SCREEN-nnLllFn Field definitions for aaSnn overview line/layout no'll'- SCREEN-nnB Block definition header for screen aaSnn- SCREEN-nnBll Layout header for aaSnn block part- SCREEN-nnBllFn Field definitions for aaSnn block part/layout no.'ll'- SCREEN-nnn Window header for window aaWnnn- SCREEN-nnnll Layout header for window aaWnnn- SCREEN-nnnllFn Field definitions for window aaWnnn/layout no.'ll'

Separate installation options can be defined per user (uu=user-Id) toassign him/her (or restrict him/her on) up to 20 layouts...

Oaa-SCREEN-uu ... per application aaOaa-SCREEN-uuss ... per main screen aaSnnOaa-SCREEN-uussL ... per line part of main screen aaSnnOaa-SCREEN-uunnB ... per block part of main screen aaSnnOaa-SCREEN-uunnn ... per window aaWnnn (not connected to a specific

main screen aaSnn)

For example and record layouts refer to B7,Aaa-SCREEN and B7,Oaa-SCREEN.

Screen Standards


Line layout of overview screens:

The line definition ('nnL') allows to define up to 63 fields to be displayed in one linefrom left to right. Module XMFP20 prepares one line at a time and the applicationscreen program has to move lines into the screen format to compose the virtualoverview screen.

Headings are also prepared by the module once at the beginning. The short datadictionary names (5 long) are used. Signed numeric fields are edited with OXX-MASK no.01, dates are edited with separators from OXX-DATE.

For example a line layout as defined in the example in B7, Aaa-SCREEN wouldlook like this:

----------------------------------------------------------------------------In Adj Adj. Adj.list name Effect. Effect. Adj Skip Nxt.rangputseq list from-date to-date base to B D C__ 999 9999 XXXXXXXXXXXXXXXXXXXXXXXX YY/MM/DD YY/MM/DD 999 999 X X X----------------------------------------------------------------------------

The following sequence of fields within line is recommended from left to right: inputfield for selection, key field (usually ascending), other fields.

Block layout:

The block definition ('nnB') allows to define 02-08 fields to appear in 1-4consecutive lines in 2 columns:

X---fld1-----X X---fld5-----X

X---fld2-----X X---fld6-----XX---fld3-----X X---fld7-----X

X---fld4-----X X---fld8-----X

Each 'fld' element can be 38 bytes long and consists of:

hhhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxhhhhh = short data dictionary name as heading (5 long)xxxxxxxxxxx.... = field value and optional code interpretation

The module XMFP20 supplies an area of 8 x 38 bytes field elements and theapplication screen program only has to move this area to the screen format.

DESIGN STANDARDS


Window layout:

The window definition ('nnn') allows to define 1-63 fields to appear in the windowvertically:

**x---title (optional)-------x**aaWnnn**** ** hhhhh x------fld1-------------------x *

hhhhh = short data dictionary * hhhhh x------fld2-------------------x *name as 'heading' * | | *(5 long) * | | *

x--fldn----x = field value * | | *and optional * V V *code interpretation * hhhhh x------fldn-------------------X *

* ** Function key descriptions............ *

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

The window width and length is not fixed. It can vary from a width of 10 to 40 bytesand a length of 5 to 20 lines. Module XMFP20 supplies an area of 63 x 40 bytes (orsmaller) field elements. The application screen program moves as many fieldelements into the window format as possible at a time. With ROLL the applicationscreen program must be able to page thru all 63 field definitions.

NOTE

THE SDF CANNOT BE USED TO DEFINE INPUT OR SELECTIONFIELDS. IF NEEDED, THEY HAVE TO BE DEFINED SEPARATELY INTHE FORMAT.

Distribution of Aaa-SCREEN options with programs:

The analyst/programmer of an application must prepare default layouts and submitcorresponding XI01 option records to the test & quality control group. These defaultoptions are sent out with the program distribution to the users.

Connection main screen aaSnn and line resp.block part definition:

On the main screen header Aaa-SCREEN-nn it is defined whether a block part issupported on a main screen aaSnn and whether a line part is supported.

Screen Standards


These definitions are made by the analyst and cannot be changed by the user. It ispossible to have both supported on a main screen, or only a block part, or only aline part or none of both.

Connection main screen aaSnn and window(s):

On the main screen header Aaa-SCREEN-nn up to three window numbers can beconnected to a main screen aaSnn. These are windows which can be 'opened'on that main screen via action bar or via a function key. The same window numbercan be connected to multiple screens. These window connections are made by theanalyst and cannot be changed by the user.

For uniform presentation to the user the same window name must be used:

• for the action bar/F-key description (Aaa-SCRFCT or patchable constant)• for the selection of layouts (title on window header Aaa-SCREEN-nnn)• in the window itself, if a title is displayed

XIP050 Screen Design Facility program (SDF):

There is one XI program which can design any layout for any application. Thisprogram is called from the XIM030 menu item number 01. It asks for the applicationand screen number and offers layouts already available. Existing layouts can bemodified and new layouts can be created interactively similar to the IBM QUERYproduct.

The options for screen header and Block/Line/Window header must exist on XI01(created by the analyst of an application). The layout header and field definitionoptions are created/maintained by the user with program XIP050.

This SDF program also displays data dictionary to select files and fields, it checksthat only files which are defined in the corresponding screen header are selected, itdisplays draft layouts and allows rearranging fields within a line, block or window.Headings for a line layout are taken from data dictionary field names, left alignedfor alpha fields or right aligned for numeric fields.

XIP055 program to select layouts via action bar 'Selct Layout':

If an application screen program uses the SDF feature to display userdefined lines, blocks and windows it must have an action bar element for 'SelctLayout'. If this function is selected from the action bar the application screenprogram is terminated (temporarily) and the XIP055 program is called.

DESIGN STANDARDS


This program:

• displays a pull-down window with layout numbers allowed for this user (fromOaa-SCREEN option)

• lets the user select a layout number for the Line part, for the Block part and1-3 windows connected to the currenltly displayed main screen aaSnn

• returns to the calling application screen program with selected layoutnumbers in the LDA

LDA layout used between application screen program aaPnnn <--> XIP055:

Pos. aaPnnn --> XIPnnn (input): XIPnnn --> aaPnnn(output):

256-257 Application 'aa' (returned unchanged)258-259 Main screen number 'nn' (returned unchanged)260-261 Currently active layout number New selected layout number 'll'

'll' of line part (if applicable)262-263 Currently active layout number New selected layout number 'll'

'll' of block part (if applicable)264-269 Currently active layout number(s) New selcted layout number(s)

'll' of 1-3 connected windows (if 'll' applicable)271-272 User-Id 'uu' (returned unchanged)273 Position of action bar choice 1-5 (returned unchanged)

(for correct display of pull-downwindow) or blank (pull-down windowis displayed in centre of main screen)

NOTE FOR THE PROGRAMMER:

IF POS.256-273 ARE ALREADY USED BY THE APPLICATIONCOMPLEX, THAN THE CURRENT LDA PSOITIONS CAN BE SAVED INTHE CALLING PROGRAM AND RESTORED AFTER RETURN FROMXIP055.

Screen Standards


2.3.11 Function Keys

Definition:

Function keys are all programmable keys of the S/3X keyboard. These are: F1-F24keys (former command keys CMD1-24), ROLL keys, ENTER key, HELP key.

NOTE

ON PCS THERE ARE A LOT MORE KEYS THAT CAN BEPROGRAMMED SUCH AS CTRL+ANY LETTER/DIGIT OR ALT+ANYLETTER/DIGIT WHICH ARE NOT SUPPORTED IN THE S/3X SCREENFORMAT GENERATOR!

Use of function keys:

1) For standard functions such as exit or cancel on all panels (see list of standardF-keys below)

2) As fast-path keys on primary windows (=main screen) to initiate function(s)which are usually started from a pull-down window

3) For auxiliary functions (for example, select period or suspend delivery). Howeverkeep in mind that operational functions (for example, Calculate or Data Entry)require an action bar.

Standard function keys:

This is a list of standard keys which have the same meaning throughout BASIS.Common constants each 12 bytes long are available for display in primary windows(FMT99) and in secondary and pull-down windows:

DESIGN STANDARDS


CCnn key=..text.. Meaning

CC62 ENTER Accept input and continueCC63 ROLL up/down Display next or previous pageCC64 ROLL up Display next pageCC65 ROLL down Display previous pageCC66 F1=nxt.error Display next error, if anyCC67 F2=add.info Display more information on current error (wrap around)CC68 F3=exit Exit from current function (back to action bar) or exit from

job if F3 pressed from primary window (EOJ)CC69 F11=acpt.err Accept warning error (former CMD-12!)CC70 F12=cancel Cancel window, return to prev.window (back one step)CC71 F23=more fct Roll functions in action bar horizontally (wrap around)CC72 F24=more key Roll key-descriptions in bottom lines/FMT99 (wrap around)CC73 HELP Display help textCC74 HOME=act.bar Moves cursor to first input field of action bar

(Note: HOME key is system supported, not programmable!)

Common constants CC26-CC35 and CC52-CC55 with former function keydescriptions, each 25 bytes long, are still present for old programs but are not usedany longer.

Key descriptions on primary windows (= main screens):

Key descriptions appear in lines 23-24 (FMT99), each a patchable constant of 25characters in length. Sequence in which they appear: ENTER, ROLL, function keysascending, HELP, Selection sign (if applicable).

Only function keys that are really available at that moment are displayed (e.g. donot display F1/F2 if no error is active). Fast path-keys are not included. Screenlines 23 and 24 are also used for error messages. If an error occurs the messageline is shown in screen line 23 and key descriptions for F1, F2, F11 HELP plus 2additional keys that help most are shown in line 24. With F2 both screen lines 23/24 are used for additional error information. As a consequence the function keysshould be described in the error message!

Key descriptions in windows:

Key descriptions currently valid for a window, appear at the bottom of the window.Each is a patchable constant of 12 characters length and are submitted from theprogram (do not describe in the format except HELP windows!). For example 'F3 =

Screen Standards


exit ', 'ENTER ' or 'ROLL '. Refer to chapter 2.3.6 for more information onWindows.

F24 to roll function-key descriptions in FMT99:

The maximum number of key descriptions in screen lines 23-24 is 2 lines x 6 F-keys = 12 key descriptions. If this is still too few the F24 key can be used for rollingof F-key descriptions in FMT99:

On the first display: describe all important F-keys + ROLL + HELP + F24. On thesecond display: describe all less important F-keys + F24.F24 can roll over 2 or more pages of FMT99 without changing data in the panelbody. Wrap around is provided.

2.3.12 Commands in 'Expert Mode'

Definition:

Commands are mnemonic abbreviations of the functions described in action bars.Instead of selecting an action bar function from line 2, an advanced user (=expert)can also key in the mnemonic command to start an action. Additional parameterscan be entered together with the command to replace entry or selection fromwindows.

Commands, subcommands and parameters:

The BASIS Expert mode supports entry of commands in 3 levels:

Command = 1-3 character abbreviation of the functions listed in the action bar(mandatory)

Subcommand = 1-3 character abbreviation of subfunctions or selectionsoffered in the primary pull-down window (optional)

Parameter(s) = BASIS code(s) such as outlet number or document numberwhich are either typed in the window or are selected from anoverview screen if the function was selected from the action bar(optional).

Command line:

Line 22 is normally used as input field for typing commands. It is headed by thenon-patchable '===>' sign.

DESIGN STANDARDS


Entry format:

Commands and parameters separated by the slash '/' can be entered in thefollowing format:-------------------------------------------------------------------------===> ccc/sss/p1/p2/..../pn-------------------------------------------------------------------------

ccc = 1-3 character command (mandatory)sss = 1-3 character subcommand (optional)p1 = parameter 1, any BASIS code such as outlet number (optional)p2 = parameter 2, if applicable (optional) : :

: :pn = nth parameter, if applicable (optional)

Examples from AR:

===> D Select main function 'Display'===> D/AC Select main and subfunction 'Display' 'ACcount number'===> D/AC/10256 Would 'Display' the Inquiry screen for 'ACcount'

'0010256' without further intervention by the user

Entry of partial commands:

If a command is entered without a required parameter the program automaticallyopens the window in which the parameter can be entered. From there the usercontinues as if he had selected an action bar element.

Naming conventions:

A command or subcommand can be 1-3 characters long. The action bar textshould be in lower case script. The letters used as a command should be in uppercase.

For (primary) commands the first or first 2 characters of the associated action bartext should be used, for example, Display --> D or DIsplay --> DI.If two action bar choices have the same starting character than another significantletter can be used, for example, disPatch --> P or DisPatch --> DP.For subcommands the first 2 or 3 characters of the associated text should be used,for example, ACcount number --> AC or ACCount number --> ACC.

Screen Standards


XI01 option Aaa-SCRFCT:

Commands and Subcommands for an application are defined in options in XI01:Aaa-SCRFCT-nnn One option per function (aa=application, nnn=function

number). The function number is:001-099 = for commands and100-999 = for subcommands.

It contains a 12-byte action name (displayed in action bar orpull-down window), a 1-3 bytes command/subcommand (to beentered in the command line) and a 1-byte action code (toselect objects directly from the overview).

The function numbers are directly associated with certain functions in the program.Via these Aaa-SCRFCT (=Screen Function) options the same function is initiatedby the programs if either a command was keyed or an action bar element wasselected or an object was selected with an action code.

Application screen program to enter/update Aaa-SCRFCT options:

A screen program must be written for every application to allow entry andmaintainance of Screen-Function options in XI01. It is called from the applicationmenu.

This program is used by development to create Aaa-SCRFCT options and by theuser to translate into a local language. The program checks for duplicatecommands or texts within the group Commands (function number 001-099) andwithin the group Subcommands (function numbers 100-999).

Translation into local language:

The analyst/programmer of an application has to prepare a set of Aaa-SCRFCToption records with English defaults. They are submitted to the Test & Qualitycontrol group and sent to the user together with the program release.

The user can translate both action-bar-texts and commands into a local language.The original English commands and texts are preserved. The program uses thelocal commands and texts.

DESIGN STANDARDS


Error messages:

If an invalid command was entered, error message EXX... is displayed in FMT99. Ifan invalid parameter was entered (for example a non-existing outlet number) anapplication message Eaannn is displayed in FMT99 and the corresponding pull-down window in which the correct value can be entered.

Standard modules to handle command entry in 'Expert mode':

XMFR modules are available in library SYSMOD, which should be used by theprogrammer of the application screen program:

• load Aaa-SCRFCT options into tables• prepare action bar line from screen function table• check command entry and split into command, subcommand and parameters• ???? others

2.3.13 Options and Selection Methods

Conventions for options: Examples ('_' for input field!):

a) Option for a yes/no decision: - Print totals 0 = noBlank or 0 --> No 1 = yes

1 --> Yesb) Option with multiple values: - Print totals 0 = no

Blank or 0 --> for 'non-applicable' 1 = physical units1-9 --> for the actual choices 2 = converted un.

c) JOBQ/EVOKE processing option: - JOBQ/EVOKE processing:Blank --> interactive processing blank = interactive

E --> in EVOKE (S/36) E = EVOKEJ --> in Job queue J = Job queue

Letters should not be used as option values unless they can be translated by theuser into local languages.

Screen Standards


Error messages for invalid options:

The following XX error messages are available:EXX042E OPTION VALUE INVALID OR MISSINGEXX154E INVALID JOBQ/EVOKE OPTION ENTERED, VALID CODES ARE:' ','J','E'EXXxxx --> More added when required!!

It is preferred to have a more precise application message naming the field in thetext explicitly.

Selection methods:

a) Select one or more items from a list to start processing:Use the selection sign from OXX-SELECT,pos.18 (default is '*')

b) Select one or more items from a list without starting processing:Use any character (must not be used to start an action to change data)

c) Select one or more items from a list for deletion:Use the selection sign from OXX-SELECT,pos.26 (default is '/').

d) Select 2 or more items in a certain sequence:Use numbers 1,2,...,9. For example: in SD to select current period usea '1' andto select the reference period use a '2'.

NOTE ON a) AND b):

IT IS PREFERRED TO USE ANY CHARACTER FOR SELECTION.HOWEVER, FOR SECURITY, ONLY A SELECTION SIGN SHOULD BEALLOWED TO START A REAL FUNCTION IN ORDER TO PREVENTAN ARBITRARY INITIATION OF A CRITICAL PROCESS!.

Error messages for invalid selections:

The following XX error messages are available:

EXX111E TOO MANY FIELDS SELECTEDEXX112E INVALID SELECTION SIGN, USE SIGN DESCRIBED AT THE BOTTOM

DESIGN STANDARDS


It is preferred to have a more precise application message naming the field in thetext explicitly.

Prompt permitted code interpretation values for an input field:

If an input field requires one to enter an 'anonymous' code such as marketsegment', the selection sign from OXX-SELECT, pos.27 can be keyed into pos.1 ofthat input field. The default sign is a '?'.

The program shows a window listing all code values and names from the XI01code interpretation part. From this window the user may select one code by typingthe '*' selection sign in the window. On return to the main screen the programinserts the selected code value into the input field.

Screen Standards


2.3.14 Input Fields

Field formats for data input:

Sectors After

Codes

Alphanumeric A A A A A A b b bStays left adjustedPadded with blanks

Numeric 1 2 3 0 0 0 1 2 3Right adjustedLeading Zones

Amounts and quantities

Signed numeric (Normally not used) 1 2 3 b b 1 2 3Right adjustedLeading blanks (Field Exit + or Field Exit)

1 2 3 b b 1 2 3 -

(Field Exit -)

orCalculator Mode 1 2 . 3 - b 1 2 . 3 -Right adjustedLeading blanks - 1 2 . 3 b - 1 2 . 3

NOTES

1) ALL FIELDS EXCEPT SIGNED NUMERIC USE "FIELD EXIT".

2) SIGNED NUMERIC (SSS-) IS THE ONLY FIELD TYPE WHICH USES"THE 'FIELD-' KEY". WHEN USED, IT SHOULD BE INDICATED ASSUCH IN NOTES IN AA/3. NORMAL FORMAT FOR NUMERICFIELDS IS CALCULATOR MODE.

DESIGN STANDARDS


NOTES, CONTINUED

3) IN SELECTION LIST, THE FREE FIELDS REMAIN LEFT ADJUSTED(LIKE CHARACTER FIELDS).

4) IN CALCULATION MODE A "T" SUFFIX MEANS THOUSAND, A "M"SUFFIX MEANS MILLION, FOR EXAMPLE, 2.75M = 2,750,000 "T"AND "M" ARE TRANSLATABLE.

2.3.15 Instructions

Use:

BASIS uses the 'step-by-step approach' as recommended by IBM's SAA standard.Every step must be documented to the user in a way that he always knows what hehas to do.

Wording:

The text should: • Name the fields that have to be entered, selected or just sayhow many options are to be entered if they can not be namedindividually

• Say which button has to be pressedStandard terms: • Use the verb 'key' (for codes or options) or 'type' (for text) and

not 'enter'• Use the verb 'Press' for keys, not 'hit' or 'enter'• Use 'you' and the active voice, not the passive voice

Lower-case script should be used, not upper-case.

Examples:

'Key outlet number and invoice number. Press ENTER.''Key selection sign to select 1-12 outlets. Press ENTER.''Key changes to print options, press ENTER. If no changes just press ENTER.''Type reason for unproductive visit. Press ENTER.'

Placement on the primary window (= main screen):

The instructions should be placed either at the top of the panel body (line 3-5) or atthe bottom (line 20-22). More than one line can be used if required. However theplacement at the top or at the body should be consistent within a job (never mix topand bottom placement!). The analyst should always provide more space than theEnglish text to enable proper translation into local language.

Screen Standards


Placement in a window:

The instruction line(s) should also be placed at the top of a window. Refer tochapter 2.3.6 for more information on Windows.

Layout:

The text is aligned to the left of the format and appears as a 'narrative' sentence inlower case script and in normal intensity (or green on color screens).

2.3.16 Error Messages and Informational Messages

Error messages:

Error messages for invalid input or data are presented at the bottom of the screen,lines 23-24 (FMT99). One to nine lines of message texts are stored on XI01 pererror code. Message line 1 is displayed in screen line 23, and message lines 2-9are displayed in screen lines 23-24 when F2 is pressed, two at a time. Refer tochapter 2.2 for more information on Program error messages.

F1 next error message:

F1 is a BASIS standard function key to roll through error messages if more thanone error occurred on a window at a time. F1 diplays the message line 1 of the nexterroneous field in screen line 23 and leaves the function key descriptions in screenline 24 unchanged. Wrap around is done automatically when F1 is pressed fromthe last error.

F2 additional information on current error:

F2 is also a BASIS standard function key to roll through the message lines 2-9 ofone specific error. Every time F2 is pressed 2 more message lines are displayed inline 23-24, as many as are available for an error code. If at the end it automaticallywraps around to show message line 1 again.

F11 accept warning error:

F11 is the third BASIS standard key for error handling. It is used to accept warningerrors and let the program continue with the default action as described in the errormessage. F11 is only allowed if a warning error is displayed and no terminal error ispresent. For more information refer to T3,2.2.

DESIGN STANDARDS


Informational messages:

Informational messages are messages that inform the user. They usually do notrequire a response by the user and disappear when the function is complete.

Examples:

• what the program is doing if the action takes longer, for example, 'Articlegroups are being loaded'

• that an action has been successfully completed, for example, 'Payment hasbeen applied in B/F mode to number of invoices.. 25'

Information window:

Temporary messages that inform the user about a longer action are displayed inwindows. The window appears as soon as the action is started (for example,'Article groups are being loaded') and disappears when finished. Refer to chapter2.3.6 for more information on Windows.

Messages in line 23:

Messages that should not overlap the main screen can be displayed in line 23 suchas '***Payment has been applied. Select next account.'

Such messages are patchable constants. They are headed by 3 asterisks '***' andare displayed in high intensity (or white on color screens). They disappear as soonas ENTER or another function key has been pressed.

2.3.17 Help Support

HELP key:

BASIS programs utilze the HELP key, whereas IBM's SAA manual proposes eitherthe F1-key or selecting HELP from an action bar with selection possibilities (Helpindex, extended Help, Keys Help, and so on).

The HELP key on the S/36 is system supported and needs no programming inapplication programs! It is always bound to the cursor position.

Screen Standards


Use:

Help is supported:a) On menues: • to explain what each item doesb) On Prompt screens: • every input field

• a general description (first page)• function key explanations (last page)

c) On Program screens: • every input field• a general description (first page)• function key explanations (last page)• optionally also for important output fields

Help windows:

Help texts are presented in informational windows. Refer to 2.3.6 for moreinformation on Windows.

Shape of Help windows:

The size of Help windows should be kept small. It is preferred to rather spread textfor one input field over several pages (in this case ROLL UP and DOWN keys mustbe described at the window bottom accordingly!).

Placement of Help windows on the primary window (=main screen):

A help window should be placed adjacent to the field it describes. For general helptext any place that does not hide valuable information on the main screen ispossible.

Placement of Help windows for working windows:

The help window should be placed so that it overlaps the working window withoutcovering the input (or other) fields that it explains.

Examples: ************* _______________* Working* | Help |* * | |* * |_____________|*************_____________ * Working*

| Help | * *| | * *|____________| **************

DESIGN STANDARDS


Sequence of Help formats for rolling:

The ROLL keys on AS/400 and on S/36 allow you to roll thru Help formats in thesequence they occur in the format source member. Formats should always be inthe same order that input fields are on the screen.

The first Help format is a general description that can only be reached by the userthru ROLL DOWN from the Help format of the first input field or thru ROLL UP fromthe function key Help format (therefore ROLL UP and DOWN keys must bedescribed at the bottom of a window!)

The last Help format is a description of all valid function keys. It can only bereached by the user thru ROLL UP from the Help format of the last input field orthru ROLL DOWN from the general description Help format (therefore ROLL UPand DOWN keys must be also described at the bottom of a window!)

Help on output fields:

This is not recommended, because a user will usually not move the cursor to aprotected area of the screen. However, if provided for important fields, the samerules as for input fields are to be followed.

Disable input on main screen:

On the AS/400 and on the S/36 input is always possible on the last written inputformat. Therefore, if a help window has a pure output format, entry in main screeninput fields is still possible. Any input would be lost as soon as the Help format isexited. This is misleading for the user!

In order to prevent entry in input fields which are still visible on the main screen, thefirst line 1 of the help window is defined as a dummy input field (that is, protected).This makes the Help format an input format for the I/O processor!

Return to main screen:

The ENTER key is used to return control to the main screen. This deviates fromSAA standards which uses F3.

Screen Standards


2.3.18 Patchable Constants

About the translation of constants into local language:

Patchable constants are shown in English on sample screens. Local MIS Managerswill be encouraged to translate sample screens in aa/3, Workstation User Guide fortheir bottlers. They will replace samples with copies in the local language.

Small errors on sample screens are not important. Actual patching is more critical.XP Patching provides full information concerning length and position of screenconstants. Patching of programs is done first. Then the programs should beexecuted and live screens (using patched programs) should be checked.

Standards for patchable constants:

1) Format member name must be aaFnnn (nnn = same number as associatedprogram)

2) Name of each format within a format member must be:

FMTnn for application formats and windowsnn = 01-99, unique number within format member aaFnnn

2 standard formats are always present (see XMF999 in SYSMODlibrary)FMT01 = heading line 1FMT99 = bottom lines 23-24 for function key descriptions and error

messages

FMTHxxnn for help formats, old standard still supported, not used in newapplications (with xx = any alphabetic combination AA-ZZ andnn = 01-99, unique within format member also incl. FMTnn!)

FMTnnnn for help formats, latest standard (nnnn = any 4 digit number0000-9999. Structure such as sshh is recommended with ss = mainscreen number and hh = help format number within screen)

3) Formats (FMTnn) within a format member must be in ascending sequence byformat number (nn). Help formats (FMTHxxnn or FMTHnnnn) follow after thelast application format, also ascending by format number (nn without xx, ornnnn)

DESIGN STANDARDS


4) The first format wihin a format member must always be standard formatFMT01. This format is available as a source member in library SYSMOD(XMF999). Standard format FMT99 is also available in member XMF999,library SYSMOD. In addition format definitions for action bar and windows arealso included.

5) The modification level in standard format FMT01 must be incremented by twoeach time a modification is made to a format member. The fieldname in theS/36 SFGR specifications must be 'FMTLEV'.

6) A 4 or 5 digit sequence number must be present for each statement of aformat member in positions 1-5. This number must be in ascending sequence.

7) Maximum field length for a constant field is 80 bytes.

8) Field description entries for a format must be in ascending sequence by line/position.

9) Constant data is not selected for patching if an entry (Y/N) is found in position43-44 (NONDISPLAY) of a field description record.

10) As soon as the "NONDISPLAY" field is blank, or contains an indicator, anydata found in pos.57-79 of a field description record is selected for patching.

2.3.19 Performance Considerations

1) Minimum Amount of Data

Screens should be designed so as to minimize the amount of data transmitted toan to and from a screen. This is particularly important for remote screens.

2) Use of "Override" and "Erase Input Fields"

Both AS/400 and S/36 support precompiled screen formats (SFGR on S/36 andDDS on AS/400). COBOL on both machines includes special WRITE operationswhich actually imply two output operations:

Screen Standards


a) sending complete format specifications to the terminal and setting up theformat accordingly; the format is retained in the terminal until a new format issent using the same lines

b) sending the data to be displayed according to the format specifications.

The "override" and "erase input fields" indicators should be used extensively so asto avoid unnecessary transmission of format specifications:

a) "Override" • OFFif a format is written the first time or replaces another format

• ONif a format is redisplayed with new data (for example ROLL)

b) "Erase Input Fields • OFFif an input format is being written the first time or if theinput field values remain unchanged

• ONif the same input format is cleared (= erased) toreceive the following input.

3) Use of "Suppress Input"

Every format with output fields should specify this indicator in order to completelyskip the input routine when executing a WRITE operation. This results in a fasterresponse time.

NOTE

"ENABLING/DISABLING" OF FUNCTION AND COMMAND KEYS NEEDNOT BE SPECIFIED ALONG WITH "SUPPRESS INPUT"

DESIGN STANDARDS


4) Save screen image

For programs which exeed the program size of 64K it is not possible to keep allused screen formats in the WSO-definitions of the working storage. Therefore, aso-called screen memory work file should be used.

The structure of this workfile should be:Record Length = length of the largest output buffer used in the format membersKey Length = 8 bytes (use the format name defined in the format member)

Whenever a format is written to the Workstation file, the format is saved to thescreen memory work file. If the formats need to be redisplayed and previouslydisplayed data has not been changed, only one I-O is needed to read the previousformat from the screen memory workfile and redisplay it.

Screen Standards


2.4 Report Standards

2.4.1 Report Documentation

The term "reports" is applied to all computer printed output. The term "lists" isreserved for the system function XL lists.

aa, Application Manual

aa/1 Overview • section 1.3 (Overview of Processing Functions) maycontain sample major reports

aa/2 Description • section 2.3 (Processing Functions) contains samplereports for further illustration

• section 2.5 (Sample Menus and Reports), 1 page perreport

aa/3 Activities • each activity section includes sample reports with regardsto user activities

Taa, Technical Manual no documentation of reports included

Taa/6 Report Layout • report design using report layout form

• one page per report-ID aaPnnn with additional pages forexplanations

• used for development maintenance

Laa, Program LogicManuals no documentation of reports included.

Report Standards

DESIGN STANDARDS


2.4.2 Report Sizes

For standard reports, two sizes are proposed. See attached examples:

Full report 132 print positionsQuarto report 100 print Positions (10")

The Quarto report corresponds to quarto paper (8.5" wide, 11" high) and can becopied 1 to 1 on normal copying machines. It is envisaged to use this size for awide range of reports where additional copies may be made frequently. It can alsobe filed, conveniently, in normal binders as day-to-day correspondence.

Screen Standards


BA

SIS

aa

Pn

nn

c 00

CC

nn

n

YY

/MM

/DD

H

H.M

M.S

S U

S W

S

P

AG

E X

XX

XX

----

----

----

----

----

----

----

----

----

----

----

----

-XX

----

----

----

----

----

----

----

----

----

----

----

----

----

----

-X(C

OM

PA

NY

/LO

CA

TIO

N N

AM

E)

(RE

PO

RT

DIS

TR

IBU

TIO

N)

X--

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

X--

---X

(RE

PO

RT

HE

AD

ING

)

123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012

PR

INT

LA

YO

UT

0

1

2

3 4

5

6

7 8

9

10

11

12

13

1

2

3

4

5

1"

6

7

8

9

10

11

2"

12

13

14

15

16

17

3"

18

19

20

21

22

23

4"

24

25

26

27

28

29

5"

30

31

32

33

34

35

6"

36

37

38

39

40

41

7"

42

43

44

45

46

47

8"

48

Eaa

nn

n t

X--

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

X

(ER

RO

R M

ES

SA

GE

, if

app

licab

le)

EX

AM

PL

E F

UL

L R

EP

OR

T

DESIGN STANDARDS


123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012

PR

INT

LA

YO

UT

0

1

2

3 4

5

6

7 8

9

10

11

12

13

1

2

3

4

5

1"

6

7

8

9

10

11

2"

12

13

14

15

16

17

3"

18

19

20

21

22

23

4"

24

25

26

27

28

29

5"

30

31

32

33

34

35

6"

36

37

38

39

40

41

7"

42

43

44

45

46

47

8"

48

EX

AM

PL

E Q

UA

RT

O R

EP

OR

T

Eaa

nn

n t

X--

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

X

(ER

RO

R M

ES

SA

GE

)

BA

SIS

aa

Pn

nn

c 00

CC

nn

n

YY

/MM

/DD

H

H.M

M.S

S U

S W

S

P

AG

E X

XX

XX

----

----

----

----

----

----

----

----

----

----

----

----

-X

X--

----

----

----

----

----

----

----

----

----

----

----

----

----

-X(C

OM

PA

NY

/LO

CA

TIO

N N

AM

E)

(

RE

PO

RT

DIS

TR

IBU

TIO

N)

X--

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

----

--X

(RE

PO

RT

HE

AD

ING

)

Screen Standards


As many as 9 different form lengths may be defined by the user. The appropriatenumber of print lines available are defined as installation options in the SystemControl File:

For example, 1) Full report (11 inches/66 lines in U.S., 12 inches/72 lines in Germany)

2) Quarto (8 inches/48 lines)

3) Invoices (6 inches/36 lines)

NOTE

MANY REPORTS ARE SPECIFIED BY THE USER BY MEANS OF A"PRINT" LIST. THE PRINT LIST ALLOWS SPECIFICATION OF THENUMBER OF PRINT POSITIONS AND THE NUMBER OF LINES.

2.4.3 Report Layout

A standard layout will be used. See example 2.4.2.

Full Report

Line Contents Length

1 Standard HeadingBASIS 5Program Name 6Program Modification Level 2License Contract no. 5Date 8Time 8User ID 2WSID 2Page Constant 6Page Number 4

Report Standards

DESIGN STANDARDS


2 Standard HeadingCompany Name 30Report Distribution 30

4 First Header Line 132

Variable Error Message - 76 right adjusted

Quarto Report

As above, compressed.

2.4.4 Field Definitions for Data Output

These are identical to screen definitions for data output:

Unedited Field XXXX

Edited Field (American Style) XX/XX/XX

X,XXX.XX-

Patchable Constants ...AMOUNT...(.. = used to show full length, as in XP Patching)

In case of a long field, a straight line can be used between the first X and last Xsymbol.

Screen Standards


2.5 Disk File Standards

2.5.1 Disk File Layout

• Application and System Function disk file layouts (aann and Xsnn) are filedunder B6, except the System Control File XIO1 layouts which are filed under B7.

• Page identification: Manual Section PageB6 aann-x Page

Xsnn-aa x = Record format codeaa = Application Code (if

records for more thanone application exist)

File Name

B7 X-----X Page(record key, high order part)

• Guidelines for completion of disk file form. (See pages 2 and 3.)

1) File Data

Record Length - record length of file

Key Length - corresponds to total length of field names shown below withletter 'K' in field name column.

Organization - S Sequential, D Direct, I Indexed.

File Name - for example, OM01 - Outlet Master

1 10 2 4 3 XXXX X---------X X XXXX XXX field

-------------- XX* table

XXX

Disk File Standards

DESIGN STANDARDS


Explanation of Columns

FIELD NO. 1) Required only when maintenance using field number is allowedor field can be used by control lists.

FIELD NAME 2) 1) Additional field name informationfor example, K = key (also see ref. data)

G = group items (for non-elementary fields)2) Mnemonic name max. 10 positions .

See 2.1.2, Field names

TYPE A alphanumeric (code or data)N numeric codeNP numeric code packedS signed numeric (amount quantities)SP signed numeric packedSO signed numeric optionally packedB binaryI index value

Decimal fixed positions within an amount field, as a rate conversionfactor, are covered in description, that is, maximum value 99.99%.

POS. Start position in record or within table element

LGTH. XXX Length of field

XX* = number of elements in table (occurs XX times)

1) field numbers must be unique within application.2) field names must be unique within application.

Example 1: Elementary field occuring more than once

LOC A 1 10* valid locations2

Screen Standards


Example 2: Non-elementary field occuring more than once

G DATA 21 20* Distribution Option6

A (1) 2 market subsegmentN (3) 4 distribution %

relative start position withinelement (optional)

Example 3: Positions in record not used

61 4 free

2) Field Data

The field definition will be a 1:1 of COBOL Copybook modules XFaann. Onlyelementary fields are included. Group items are shown to structure fields and assistprogrammer in redefining a record in the Working Storage Section.

3) Standard field sizes

per outlet per groupship-to of outletsQ $ Q $

per year 7 (4) 11 (6) 9 (5) 13 (7) per month 7 (4) 11 (6) 9 (5) 13 (7) per day 5 (3) 9 (5)* 7 (4) 11 (6)

NOTE

(X) = PACKED FIELD LENGTH*... WITH 4 ADDITIONAL DECIMALS: THIS BECOMES 13 (7)

Prices = 7 (4) (Number of decimals dependent on currency, usually 2.Percentages = 5 (3): xxx.xx (%) = x.xxxx (fraction)

Disk File Standards

DESIGN STANDARDS


Adjustment rates: 7 (4) = a) for value per case 1 decimal more than pricesb) for % = ooxx,xxx % = oo,xxxxx (fraction) that is, one

decimal more than usual for percentages.

2.5.2 Common Record Structure

1) Status Code (position 1):

H = all header records (may not be deleted)D = ready for physical deletion from the file1-4 = different statuses of validity and completeness5 = data in record is correct and ready to be processed6-9 = different statuses for logical deletion during processing.

2) Key (for indexed files) or other "record identification" (for other files). (Theseinclude record code(s) used for identification.) When the records are organizedin continuation sets, the rightmost positions of the key or record identificationare the record number (01,02, ---)

3) For continuation sets: Last record indicator (or 'L').

4) Other status codes and/or record codes, for example, reservation status code(for record reservation in shared files)

5) Data fields

6) BASIS I linkage information when required (to be dropped later)

7) User data starting from end of record

Screen Standards


2.5.3 Multisegment Records

The first record in a continuation set has 'n' fixed length segments (usually 16bytes), right adjusted in the record following the record sections 1) through 7)described in 2.5.2.

KEY

FIXED PORTION SEGMENTS(SIMILAR STRUCTURE AS NORMAL RECORDS)

The following records in a continuation set can have a shorter fixed portion (onlysections 1) through 3) are needed) and therefore more segments.

Disk File Standards

DESIGN STANDARDS



Screen Standards


2.6 CL/Program Communication

2.6.1 Local Data Area (LDA)

The LDA is a 'temporary' work area of 512 bytes (user area) which is used to

1) pass data between programs and CL, that is, write CL options to the LDA tobe used in a program or vice versa, write program options to the LDA to befurther used in CL.

2) pass data between programs, that is, write program options to the LDA to beused in the next program

3) take a job step checkpoint (CP), that is, save all CL information to the JobControl File valid at a certain point of processing, a so-called CP

NOTE

THE LDA SHOULD NOT BE USED IN COBOL PROGRAMS WHICHREAD CL PARAMETERS ONLY. IN SUCH CASES, THE ACCEPTMETHOD IS PREFERABLE, AS DESCRIBED IN 2.6.2.

Two kinds of jobs exist in BASIS:

a) Stand-alone jobs, such as simple inquiry or list programs or system functions,for example, XP Patching.

b) Controlled jobs running under XJ (Job Control) and XR (Restart) such asupdate, data entry.

The stand-alone jobs can freely access all LDA positions, 1-512. The XJ controlledjobs can only use positions 1-100. The remaining positions, 101-256, are reservedfor XJ (Job Control) and XR (Restart). Positions 505-512 are reserved for multipleapplication jobs. All jobs which may run in multiple application processing may notuse pos. 101-256 for own positions. The standard layout of the LDA follows. Forfurther details concerning positions 101-256, refer to TXJ and TXR.

CL/Program Communication

DESIGN STANDARDS


NOTE

ON THE AS/400 THE LDA HAS A LENGTH OF 1024 BYTES. THEFIRST 512 BYTES (USER AREA) ARE DESCRIBED HERE. THESECOND 512 BYTES (SYSTEM AREA) ARE NOT DEFINED ANDSHOULD NOT BE USED. THIS AREA IS RESERVED FOR BASISDEVELOPMENT.

512 LDA - Standard Layout for XJ

G 1 100 CL/Program Options

Subdivided into fields as required

G 101 49 Job Information

RESTCOND A 101 1 Restart condition (blank = no restart,'R' = Restart, 'S' = Suspend, 'C' =Cancel)

MENUITEM A 102 8 Menu Item aaMnnnii (ii = item no.01-24)

EXTYPE A 110 1 Execution type 'b' = In-teractive

J = Submitted to JobQE = 'EVOKED'

XJ02EXIST N 111 1 XJ02 Existance Indicator1 = XJ02 is not existing

112 1 Work indicator used by programsXJP020, XJP050, XJP060

AS400EXIT 113 1 Stop run/exit switch1 = exit program

not 1 = stop run program

This position is used because it iscleared by XJ during job start-up.

USERID A 114 2 User-ID (who started the job)

WSID A 116 2 Workstation-ID (from which started)

MICNO N 118 4 Message Member Number (4nnn-6nnn)

JOBNOSUF N 122 2 Job Number Suffix

Screen Standards




CTLJOBNOSUF N 124 2 Control Job Number Suffix(see XJ01 File)(Job no. of multiple application job)

LIBRARY A 126 8 Library Name (Sign-on)

FSUFFIXA 134 2 Free File Suffix used in complex(for automatic save)

MESSAGEMBR A 136 8 Name of the Message Member in use(for example, BASISMSA)

COMPLEXNO N 144 2 Complex Number

PERYEAR N 146 1 Rightmost byte ofperiod year

PERTYPE A 147 1 Period typePERNUMB N 148 2 Period number

G 150 92 Checkpoint Information

CLPARAM A 150 36 CL Parameter (as entered on S/34;no padded blanks and separated bycommas, for example,LIST,A,,,100)

A 186 20 Reserved for BASIS use

SAVMIL A 206 4 Auto safety copy 'SAVE MEDIAMIC'

SWITCHES A 210 8 Switches 1-8

CPTAG A 218 8 CL Tag Name

CLEANUP A 226 8 CL Complex Name for 'CLEAN-UP'

CANCEL A 234 8 CL Complex name for 'CANCEL'

FILEGROUPC A 242 2 Company File Group Code (shouldbe blank)

FILEGROUPL A 244 2 Location File Group Code (forexample B)

LOCATION A 246 2 Location Code (for example 01)

for auto-matic saveof SD files

DESIGN STANDARDS



MSGSAVE1 N 248 4 Message number for first safetydefinition of complexb = no save

MSGSAVE2 N 252 4 Message number for second safetydefinition

SAVESIGN N 256 1 Savesign1 = save has to be done

(Set by automatic save creationprogram)

XO01NAME A 257 8 Option file label (for example,A.XO01), used in XLP070, XLP075

265 199 free

PGMTEMFLG A 464 1 Native program termination flagb = normal termination with

'GO BACK'1 = abnormal termination with

'END PROGRAM'

465 19 Reserved

LDAENDOPT N 484 10 Complex security options (see B7,AXX-ENDOPT), set by headerprogram aaP001

494 8 Reserved

N 502 2 Sequence no. application complexin MUAP (written by XJP950, readby XJP010)

MUAPVERS N 504 2 Version number of multipleapplication job

MUAPDATE N 506 7 Processing date of multipleapplication job (CYYMMDD)(or date for automatic save if usedin file label)

G A 601 25*10 Library names (AS/400 only)Positions 601 - 850 are updated byXXP210, in XJC001, and are usedby CL program XXP215 to updatethe library list from within MRTprocedures.

Screen Standards


LDADUM A 924 1 Reserved for dummy write to LDAA dummy write, using the S/36'LOCAL' command, to this positioncauses the following LDA read,"?L,nnn,nnn?" statement to use theLDA SYSTEM area.

LDACOMARE A 925 100 Communication area betweenDriver program and S/36environment program—layout isapplication dependent

Positions 101-256 must not be updated by CL or by programs in a restartable job.These positions are exclusively used by the XJ (Job Control) and XR (Restart)utilities and destruction may lead to unpredictable results.

The CL/Program Options Area has no standard layout. Programs can use positions1 through 100 as needed.

The utilization of the LDA is documented in:

Taa,3, Complex Specifications common LDA fields used throughout the complexLaa, aaPnnn.1, General all LDA fields used in a specific program

(common as well as program dependent)


DESIGN STANDARDS



Screen Standards


2.7 Program Design

1) Programs should be kept as small as possible. Whenever feasible, overlayswill be used, for example, for program initialization and termination as well asfor different functions in interactive programs (that is, processing differentscreens)

2) Alternatively a program can be split into separate programs (for example, onefor each interactive function) but this is much slower than using overlays (2 to4 seconds instead of 0.1 second).

3) When an interactive program is split into multiple programs the RUF (Readunder Format) technique can and should be used when applicable to overlapdata entry with the loading of the next program. RUF must not be used,however, to pass data from one program to the next via the screen; if datamust be passed, the LDA must be used (not the Job Control File that savesLDA for a restart). The program should also function without modification onsystems which do not support RUF (or which do not support the LDA but canread or write a file in control language).

NOTE:

RUF FUNCTIONS AS FOLLOWS:- PROGRAM A WRITES FORMAT XX AND GOES TO EOJ- THE OPERATOR CAN ENTER INPUT DATA (UNDER CONTROL OF

THE OPERATING SYSTEM) WHILE PROGRAM B IS LOADED- PROGRAM B READS THE SCREEN. IF RUF IS NOT SUPPORTED,

PROGRAM B MUST WRITE FORMAT XX AND THEN READ THESCREEN.

4) All programs must be SRT (single requesting terminal) programs. MRT(multiple requesting terminals) is not used.

Program Design

DESIGN STANDARDS



Screen Standards


2.8 Module Design

Two main groups of modules are present:

1) modules covering one or more functions in a general and flexible way, knownas program respectively procedure frames.

2) modules covering one or more functions in a fixed way. These modules areCALL or COPY modules.

Program/Procedure Frames

Typical functions covered by program frames are the general functions such as• merge• level break• screen processing and so on

and by procedure frames single functions such as• roll up/roll down, and so on

Frames must be provided as source members to allow the programmer to adaptthe module to his individual needs by adding and/or changing logic statements.

CALL/COPY Modules

Typical functions covered by these modules are for example

• edit amount field• compute check digit• display an error message• convert date and so on

The attribute of the modules for these functions is that the logic is fixed and cannotbe changed.

In order to decide whether a module should be a CALL module/subroutine memberor a COPY module/source member the following should be considered:

• if possible, the module should be a CALL module because of

o better utilization and more flexibility as a COPY module (use of parametersand so on)

Module Design

DESIGN STANDARDS


o faster compilation of main program

o no source code printing on main program compilation list

o programming language need not be COBOL (for example, may be CL onS/38).

• If a module has to be put into an overlay due to program size, an overlaylinkage editor run must be performed separately.

• Performance for CALL module is 5-10% below a "performed" module (COPYmodule) with the same functions (parameter transfer).

• A CALL module is bigger than a "performed" module (COPY module) with thesame functions.

• If a module has to perform I/O on disk files it should be a COPY module (dueto OPEN and so on).

• If field names, PICTURE clauses, and so on are not fixed, the module mustbe COPY module to allow REPLACING during compilation.

Standards

For programming standards, naming conventions and using standards, see T3 - T5.


Naming Conventions forCOBOL Programs

COBOLProgramming Standards33.1 Objectives 3-3

3.2 Overview 3-5General Remarks 3-5Notation 3-5

3.3 Structured Programming 3-7Standard Elements: 3-7Coding the Standard Elements in COBOL 3-10

3.4 Naming Conventions for COBOL Programs 3-19Paragraph Names 3-19Special Names (Mnemonic Expressions) 3-23File Description Entries (FD) 3-23Working Storage Section 3-27Standard Words and Prefixes 3-33

3.5 Standards for Patchable Constants 3-37Common Constants 3-38Program Constants 3-40Program Error messages 3-48

3.6 Coding and Efficiency Techniques 3-51General 3-51Data Division 3-51Procedure Division 3-52Printer Files 3-53VALUE and Usage Standards for Condition Names 3-55Instruction Timings in COBOL 3-56Standard Coding for I-O Operations 3-57

3.7 Program Structure 3-61Structure of Working Storage Section. 3-61Structure of Procedure Division 3-63COMMENTS 3-64

3.8 Program Administration 3-67



3.9 Program Modules 3-69Naming Conventions 3-69"Dummy Parameters" 3-71Administration Documentation and Comments 3-73

3.10 S/36 - S/38 Considerations 3-75Programs 3-75Screen Formats 3-79



3.1 Objectives

The use of programming standards is essential in the modern data processingenvironment. The structured programming technique forces management todevelop general programming and coding rules to ensure compatibility of programmodules written by different programmers. Maintenance of a standardized programis made easier since the structure of every program is similar. Similar problems aresolved similarly in different programs using, for example, the same filespecifications, tables, fields, as well as the same program logic.

It is obvious that the programmer will see standards as a restraint. He might not bewilling to use a predefined field name or even a full solution (done by a module) inhis program. However, the aforementioned advantages will soon enable theprogrammer to spend more time on the interesting parts of a program while apredefined code does the "routine work".

Objectives






3.2 Overview

3.2.1 General Remarks

All standards documented in this manual are mandatory for all programmers writingCOBOL programs, screen formats or a CL procedure. However, each user is freeto make suggestions for modifications or the introduction of new standards.Programs in which the BASIS standards are not used will not be administered and/or distributed by the BASIS Group.

This is because non-standardized programs:

• cannot be patched with the BASIS patching procedure• are not automatically convertible to the S/38 COBOL language• cannot be combined with other programs and/or modules developed by a

different development group (that is, Vienna, Atlanta, and so on).

3.2.2 Notation

• Reserved words (that is, standard words) are written in capital letters. Theymust be used as specified and must not be changed by the programmer. Inaddition, no other words (or abbreviations) identical to a reserved word mustbe used.

• The expression "mnemonic" indicates that the programmer may insert anydesired term.

Example:

SWITCH - mnemonicfixed free

The length of the mnemonic character string should not exceed 10-15 positions.

Overview






3.3 Structured Programming

BASIS II development follows the rules of "Structured Programming"! "StructuredProgramming" no longer is a "buzz word" and since the late 70's has become anaccepted practice; common rules and standards have been established and areinternationally accepted.

3.3.1 Standard Elements:

The five basic elements of structured programming are:

SEQUENCEIF-THEN-ELSECASEDOWHILEDOUNTIL

Comments on each element follow.

Structured Programming



1) SEQUENCE

A A One or more single stepsare executed sequentially.

B

2) IF-THEN-ELSETrue False

C

Execution depends on a condition C.A B If C is true THEN A is executed,

ELSE if C is false B is executed.

True False C

A Or A is only executed if C istrue and the ELSE-path is empty.

3) CASE

C1 Else Only one of A1 thru Anis executed at a time

C2 Cn depending on condition C1thru Cn; if, for example, C2 is

A1 A2 An B true A2 is executed and C3thru Cn are not tested further.In case that none of theconditions C1 thru Cn aretrue an ELSE path shouldbe provided (for example,error routine in B).



4) DOWHILE

Iteration of A:

False DO A WHILE a condition C is true.C Condition C is tested before the

execution of A; thus A may not beexecuted at all if C was initially false.

A

5) DOUNTIL

Iteration of A:

DO A UNTIL a condition C is true.A Condition C is only tested after the

execution of A; thus A is executed atleast once.

FalseC

True

6) COMPOUND STRUCTURES

The five basic elements may be combined by replacing a box with any other structure-element. This can be done with no problem because each element has a single entrypoint and single exit-point; a GO TO from one structure element into another is notpossible.

For example: take an IF-THEN-ELSE and replace box A by a DOWHLIE and box B by aCASE:

True




BOX A

R

S1 S2 S3 T

C1

C2 C3 C4 C5 Else

BOX B

3.3.2 Coding the Standard Elements in COBOL

Despite the common features of structure elements, there remain a number ofways to code them in COBOL, depending on the taste and habits of theprogrammer. The following standard COBOL elements are used in all BASISprograms to

• make sure that COBOL programms follow the rules of structuredprogramming

• increase the readability of COBOL programs• make future maintenance as easy as possible.

A COBOL program which deviates from these standards will not be accepted.



NOTE

STRUCTOGRAMS (SEE 1.3.5) ARE USED INSTEAD OF FLOWCHARTSYMBOLS BECAUSE ACTUAL CODING IS ALWAYS DONE FROMSTRUCTOGRAMS.

1) SEQUENCEall basic COBOL instructions such as MOVE, ADD, SET, and the simplePERFORM... THRU...

2) IF-THEN-ELSE

Overflow Y N

***** EXAMPLE IF-THEN

Yo1 IF C-OVERFLOWPRINT PERFORM Y01-PRINT-HEADINGS THRU Y01-EXITHEADINGS MOVE ZEROS TO W-LINE-COUNTER

Clear line-counter

NOTE

INDENTATION OF 3 POSITIONS IS RECOMMENDED.




***** EXAMPLE IF-THEN-ELSE

IF W-AMOUNT IS POSITIVEADD W-AMOUNT TO W-DEBIT-TOTALIF CI-CREDIT-CUSTOMER

PERFORM 52-PASTDUE-CALCULATION THRU 52-EXITELSE

NEXT SENTENCE

ELSESUBTRACT W-AMOUNT FROM W-CREDIT-TOTAL

b) IF-THEN-ELSE

Amount positive Y N

Add Amount Subtract to amount fromDebit-Total Credit Total

Credit Customer

Y N

52 -PASTDUECalculation

c) all Input-Output operations in COBOL:

READ with AT ENDREAD with INVALID KEYWRITE with INVALID KEYREWRITE with INVALID KEYSTART with INVALID KEYDELETE with INVALID KEY

The actual I/O operation is in a separate paragraph Znn-aann-cccccccccc (nn=01-99,aann=file name, cccccccccc = READ, WRITE, REWRITE, START, DELETE). The "ATEND" or "INVALID KEY" condition can be handled outside via the "File Status."

MOVE ART. NO. TO RECORD KEY *****

Z05-AM01-READ

RECORD PRESENT Y N

MOVE FROM FD- MOVE SPACES TOAREA TO WORKING WORKING-STORAGESTORAGE-AREA AREA

EXAMPLE IF-THEN-ELSE WITH "READ....INVALID KEY"

MOVE WSI-ARTNO TO KEYAM01PERFORM Z05-AM01-READ THRU Z05-EXIT.IF FS-AM01-SUCCESSFUL

MOVE AM01REC TO AM01 WORKRECELSE

MOVE SPACES TO AM01-WORKREC.

Z05- AM01-READREAD AM01 INVALID KEY GO TO Z05-EXIT.

Z05- EXIT.



d) STRING/UNSTRING with ON OVERFLOW

UNSTRING WS-LINEDELIMITED BY SPACESINTO SEL-WORDDELIMITER IN W-BLANKS

ON OVERFLOWY N

SET END-OF-LINE 4351TO CheckTRUE Sel-Word

Error Y N

Set 4351 Error-in Interpret Line to Sel-Word true

NOTE

THE "ON OVERFLOW" CLAUSE SHOULD NOT CONTAIN ANYACTUAL STATEMENT

3) CASE

a) Series of IF's and GO TO's (simulating nested IF's)

"A" RECORD-CODE

31- "B"Process-rec.-

A 32- "C"Process-Rec.-

B 33- Else Process-Rec,-

C XMER02 Stop-Error

***** EXAMPLE IF-THEN-ELSE WITH "UNSTRING"

435- UNSTRING-EXAMPLE.UNSTRING WSI-LINE DELIMITED BY SPACES

INTO W-SEL-WORDDELIMITER IN W-BLANKS

ON OVERFLOW GO TO 435-END-OF-LINE.

435- PROCESS-SEL-WORD.PERFORM 4351-CHECK-SEL-WORD THRU 4351-EXIT.IF C-ERROR-IN-WORD

SET C-ERROR-IN-LINE TO TRUEELSE

PERFORM 4352-INTERPRET-SEL-WORD THRU 4352-EXIT.GO TO 435-EXIT.

435- END-OF-LINE.SET C-END-OF-LINE TO TRUE.

435- EXIT.


***** EXAMPLE CASE WITH "NESTED IF'S"

3-PROCESS.IF RECODE EQUAL "A"

PERFORM 31-PROCESS-REC-A THRU 31-EXITGO TO 3-EXIT.

IF RECODE EQUAL "B"PERFORM 32-PROCESS-REC-B THRU 32-EXITGO TO 3-EXIT.

IF RECODE EQUAL "A"PERFORM 33-PROCESS-REC-C THRU 33-EXITGO TO 3-EXIT.

PERFORM XMER02-STOP-ERROR THRU XMER02-EXIT.3-EXIT.



b) GO TO DEPENDING ON (only if an integer is tested)

1 MARITAL STATUS2

Move 3"Married" Move Elseto "Single" MovePrint Line to "Divorced" Move

Print Line to "Undefined"Print Line to

Print Line

c) SEARCH with several WHEN's and AT-END (the AT-END clause is the ELSE path)

SEARCH ART-TABLE

Art. No. Key-Art-No. compared tofound WS-Art. No.

NextAdd greaterUnits/Subunits At

end371INSERT Art

Y03(Shift all greater Write Arrayelements by 1 &insert new Art.at T5).

ClearArt-Table

NOTE

THE "WHEN" AND THE "AT END" CLAUSESSHOULD NOT CONTAIN ANY ACTUALSTATEMENT.

***** EXAMPLE CASE WITH "GO TO DEPENDING ON"

852-CASE-EXAMPLE.GO TO 852-SINGLE, 852-DIVORCED

DEPENDING ON W-MARITAL-STATUS.852-UNDEFINED.

MOVE "UNDEFINED" TO RPT-MARITAL-STATUSGO TO 852-EXIT.

852-MARRIED.MOVE "MARRIED" TO RPT-MARITAL-STATUS.GO TO 852-EXIT.

852-SINGLE.MOVE "SINGLE" TO RPT-MARITAL-STATUS.GO TO 852-EXIT.

852-DIVORCED.MOVE "DIVORCED" TO RPT-MARITAL-STATUS.

852-EXIT.



***** EXAMPLE CASE WITH "SEARCH"

37-SEARCH-EXAMPLE.SEARCH T5-ART-TABLE VARYING T5

AT END GO TO 37-ARRAY-FULLWHEN T5-ARTNO(T5) EQUAL WSI-ARTNO GO TO 37-UPDATE-ARTWHEN T5-ARTNO(T5) GREATER WSI-ARTNO GO TO 37-INSERT-ART.

37-UPDATE-ART.ADD WSI-UNITS TO T5-UNITS(T5),ADD WSI-SUBUNITS TO T5-SUBUNITS(T5).GO TO 37-EXIT.

37-INSERT-ART.PERFORM 371-INSERT-SRT THRU 371-EXIT,GO TO 37-EXIT.

37-ARRAY-FULL.PERFORM Y03-WRITE-ARRAY THRU Y03-EXIT,MOVE SPACES TO T5-ART-TABLE.

37-EXIT.

4) DOWHILE

The PERFORM....UNTIL in COBOL is a mixture of the 2 elements DOWHILE andDOUNTIL; the condition is tested before performing the routine but if it is true it meansdiscontinuation instead of continuation (it also says UNTIL not WHILE). It becomes aWHILE condition when you negate it: (for example, UNTIL NOT LESS = WHILE LESS).

a) PERFORM with UNTIL NOT

SET T1 TO 1

T1-ART (T1) LESS WSI-ART. AND NOTEND-OF-LIST

43ProcessList-Element

(If pointer is zero end of listis reached, else move pointerto T1).


***** EXAMPLE DOWHILE WITH "PERFORM....UNTIL NOT"

SET T1 TO 1.PERFORM 421-PROCESS-LIST-ELEMENT

UNTIL T1-ARTNO(T1) NOT LESS WSI-ARTNOOR C-END-OF-LIST.



b) PERFORM ...... TIMES

START XI01 AT OXX "MASK"

16 TIMES

15-EDIT-MASK

(Read edit-mask recordsfrom System Control Fileand load into table).

c) PERFORM ...... VARYING ... FROM ... BY ... UNTIL

T2 = 1-100and ELEMENT (T2) not blank

612- Art-Line

(Extract from table andedit/print an article line).

5) DOUNTIL

There is nothing in COBOL directly supporting this iteration process. Although thePERFORM ...... UNTIL contains the correct condition test (UNTIL = discontinue when itbecomes true) the test is done before performing the routine. There are two possibilities:

***** EXAMPLE DOWHILE WITH "PERFORM....VARYING...UNTIL NOT"

PERFORM 612-ART-LINE VARYING T2 FROM 1 BY 1UNTIL T2 GREATER 100 OR T2-ELEMENT(T2) EQUAL SPACES

***** EXAMPLE DOWHILE WITH "PERFORM....TIMES"

START XO01 KEY NOT LESS "OXXMASK "PERFORM 15-EDIT-MASK THRU 15-EXIT 16 TIMES.



a) Self programmed loop in which you can put one or more UNTIL conditions anywherebetween starting and ending paragraph:

Z01WSFILE (Read inputREAD format)

CMD 1 (EOJ)

Process input3-PROCESS format receivedWRITE-WS and write new

format)

CMD 3 (Call New Prog.)

Z04 (Write recordOM60- to TransactionWRITE File.)

b) Use a PERFORM .... UNTIL and initially set the condition to false. Note that only oneUNTIL condition is possible and that it must always be put in front. Moreover combine allsteps of a loop into a procedure. (For example, PROCESS-WS is a new procedure usedto combine WSFILE-READ, PROCESS-WRITE-WS, OM60-WRITE, into a single,performable procedure).

UNTIL CMD-7OR CMD-3

3-PROCESS-WS

(Read and process input-recordfrom workstation, write newformats, and write recordTransaction File.)

***** EXAMPLE DOUNTIL WITH SELF-PROGRAMMED LOOP

READ-WS.PERFORM Z01-WSFILE-READ THRU Z01-EXOT.IF CMD-EOJ

GO TO TERMINATE.PERFORM 3-PROCESS-WRITE-WS THRU 3-EXIT.IF CMD-3

GO TO TERMINATE.PERFORM Z04-OM60-WRITE THRU Z04-EXIT.GO TO READ-WS.

TERMINATE.


***** EXAMPLE DOUNTIL WITH "PERFORM .... UNTIL"

PERFORM 3-PROCESS-WRITE-WS THRU 3-EXIT.UNTIL CMD-EOJ OR CMD-3.

3-PROCESS-WS.PERFORM Z01-WSFILE-READ THRU Z01-EXIT.IF CMD-EOJ

GO TO 3-EXITPERFORM 31-PROCESS-WRITE-WS THRU 31-EXIT.IF CMD-3

GO TO 3-EXIT.PERFORM Z04-OM60-WRITE THRU Z04-EXIT.

3-EXIT.






3.4 Naming Conventions for COBOL Programs

3.4.1 Paragraph Names

Each paragraph name has 2 parts: a module identification part and a mnemonicpart:

• the module identification part of the name consists of one or more digits,

22-CALCULATE-TAX

221-DETERMINE-RATE

22 and 221 = module identification

All paragraph names within the module start with the same module identification.

Module identifiers are assigned in a hierarchy:

MAINLINE

1-mnem 2-mnem. 3-mnem. 9- A-

21-mnem. 22-mnem.

221-mnem. 222-mnem.



The number of characters within the identification part indicates the level of thecorresponding module.

Considerations for the module identification part:

• the mainline has no identification part and is called 'MAINLINE'

• characters 0 - 9 and A - W are used. It is recommended that digits be used.Letters must be specified only if more than 10 procedures are needed in alevel.

• the letter "X" must not be used as it is reserved for standard modules.

• the letter "Y" is to be applied for modules performed in different places in theprogram. The "Y" is followed by a "c" (with C = 1-9, A-Z)

• the letter "Z" is used for I/O modules. The "Z" is followed by nn (with nn = 01-99)

22-mnem.

Ycc-mnem. 221-mnem.

2211-mnem. Ycc-mnem.

• the paragraph name for Y-common modules is Yc-mnemonic and can in turnbe structured with level numbers added to Yc (for example, Y11 called fromY1)



Yc-mnem.

Yc1-mnem. Yc2.mnem.

2211-mnem Ycc-mnem.

• EXIT paragraphcccc-EXIT, where "cccc" is the module identification part.

for example, 221-EXITZ41-EXIT Y3-EXIT

• branch points (tags)cccc- mnemonic, where "cccc" is the module identification part.

for example, 11-GETNEXT-P01

If the programmer uses any unique identification for branch points, it must beuniform within the program.

• paragraphs for I/O operations (non-workstation files). All I/O operations haveto be specified in paragraphs having standard names:

module identification part - file name - I/O operationZnn - aann (disk) - READ

- RPT (printer) WRITE (mnomonic)- LDA REWRITE- OCL START- DATE-TIME DELETE

READNEXT



Znn01-50 free51-95 reserved for system files96 DATE/TIME read97 OCL-read98-99 LDA

for example, Z51-XI01-READZ03-OM40-STARTZ07-RPT-WRITEZ19-RPT-WRITE-HEADINGS

• paragraphs for input and/or output operations to workstation files:Znn-format name(s)-WRITE, Znn-WSFILE-READ

for example, Z01-FMT04-WRITEZ04-FMT02-04-WRITEZ14-WSFILE-READ

• LDA and OCLZ97-OCL-READ (refer to 2.6.2)Z98-LDA-READZ99-LDA-WRITE

• System Date and System TimeZ96-DATE-TIME-READ

• System files (fixed Znn-number to standardize use in XM modules)Z51-XI01-READ (random by RECORD KEY)Z52-XI01-REWRITEZ53-XI01-READNEXT (sequential by RECORD-KEY)Z54-XJ02-READZ55-XJ02-REWRITE



3.4.2 Special Names (Mnemonic Expressions)

Special Name Paragraphs:

• UPSI-0 is SWITCH-1 - mnemonicON IS SW1-ON-mnemonicOFF IS SW1-OFF-mnemonic

• SYSTEM-SHUTDOWN IS SHUTDOWNON IS SHUTDOWN-ONOFF IS SHUTDOWN-OFF

• LOCAL-DATA IS LDA• ATTRIBUTE-DATA IS WS-ATTR.• SYSTEM-CONSOLE IS SYS-CONSOLE• REQUESTOR IS IBM-DSP

Select clause:

• CONTROL-AREA IS WS-CTR• FILE STATUS IS FILE-STATUS-aann

"aann" is the name of the corresponding file

I/O Control:

• APPLY CORE-INDEX TO CORE-INDEX-aann"aann" is the name of the corresponding file

3.4.3 File Description Entries (FD)

File Description

1) Disk Files

For most of the files used in BASIS programs, standard file descriptions comparableto the DDS record formats on S/38 are available.

These descriptions, stored in COPY modules, must be copied into the FD's of theCOBOL programs.



The modules are structured as follows:

• name of module:XFaannc (aann= file name, c = suffix if multiple COPY modules exist for thesame file)

• the name of the "record format" (level 01) is aannRECc (where "aann" is thename of the file concerned and "c" is the record format code (that is, recordcode if there are multiple record formats in the same file).

• all fields present are on one level (06)

• no name must exceed 10 positions

• "-" must not occur in the name (not allowed in S/38)

• the key field for index sequential files is defined with a 66 item (RENAMESthe elementary 06 fields)—see example on the following page.

66 KEYaann RENAMES field 1 (THROUGH field 2)

This name must also be specified in the RECORD KEY clause present in theSELECT clause of the file concerned.

The 66 item will be used to automatically generate key fields for the D/38DDS.

Example

FD OM40COPY XFOM40 written by programmer

01 OM4REC frame XFOM40 (copied06 COMPANY PIC into program during06 OUTLETNO . compilation06 NAME . . . . .06 PRICELIST PIC

66 KEYOM40 RENAMES COMPANY THROUGH OUTLETNO.



If the field names are not unique within the program, that is, same name used inmultiple files or records, the qualification feature of COBOL is used.

If any further structuring of predefined input and/or output fields is needed in theprogram, two possibilities exist for the programmer:

• specify these additional record formats in the FD (that is, use REDEFINES at01 level following the COPY statement)

• use separate I/O areas in the Working Storage Section which are processedvia the READ INTO/WRITE FROM or MOVE operation codes.

For the additional record formats in the FD the same standards as used in theWorking Storage Section must be applied (see 3.4.4):

01 aannc - mnemonic05 aannc-mnemonic .05 aannc-mnemonic

NOTE

THE STANDARDS FOR EXTERNAL FIELD DESCRIPTIONS (NAMELESS 11 BYTES, NO HYPHEN, AND SO ON) NEED NOT BE APPLIEDHERE.

The use of either method is up to the programmer. When these areas are specifiedin the Working Storage Section rather than in the FD area, no data in the FD is lostwhen any unsuccessful I/O operations have been performed. However, noadditional storage space is required using the "FD method". The programmershould use only one method in the program.

If the disk file is an output file created by a generic program using a file list namingconventions for SELECT and FD clause are the following:

• SELECT FLxxxx ASSIGN TO DISK-aann• FD FLxxxx....

aann standard file name (see 2.1.2)xxxx record length (0064, 0128, 0256)



2) Printer Files

FD RPT.01 RPT-LINE PIC X(132)

The actual structure must be given in the Working Storage Section

3) Workstation Files

FD WSFILE01 WSREC

The actual structure is defined in the Working Storage Section, that is, a MOVEfrom FD to the Working Storage Section must be programmed.

4) Sort Files

SD SORTn n = 1-901 SORTRECn

The actual structure may be defined in the Working Storage Section.

5) Condition Names in FD

88 Cc-mnemonic

• "c" stands for I, O or U (input, output or update), depending on the filetype, for example, 88 CI-NEW CUSTOMER VALUE '1'

• for standard use of VALUE clause refer to 3.6.5



3.4.4 Working Storage Section

• AREA FOR I/O DATA (I, U, O files)processed with the READ INTO/WRITE FROM or MOVE operation codes

1) Disk Files:

01 aann-mnomonic

05 aann-mnemonic

"aann" is the name of the file concerned.

2) Printer Files

01 RPT-mnemonic 05 RPT-mnemonic

• this structure must only be used if no patchable constant is defined in thisprint line definition. If patch constants are to be defined, the correspondingrecord must be called "PATCH-AREA-nn". See "Standards for PatchConstants" (Section 3.5) in this manual for further information.

3) Workstation Files

01 WSc-mnemonic05 WSc-mnemonic05 WSc-mnemonic

"c" stands for "I, O or U", depending on whether the record is used to storeinput data ("READ INTO"), output data ("WRITE FROM") or both (updatearea).

4) Sort Files

01 SORTn-mnemonic n = 1-9



• CONDITION NAMES

C-mnemonic VALUE...for standard use of VALUES refer to 3.6.5

• LOCAL DATA AREA

01 LDA-AREA05 LDA-mnemonic

A standard module and standard field names will be used for processing theLDA (see frames XMFR01-04).

• CONTROL AREA FOR WORKSTATION FILES

01 WS-CTR.05 FUNCTION KEYS PIC XX.

88 ENTER-KEY VALUE '00'.88 CMD-NXTERR VALUE '01'.88 CMD-ADDINFO VALUE '02'.88 CMD-DEL VALUE '04'.88 CMD-UPD VALUE '05'.88 CMD-EOJ VALUE '07'.88 ROLL-UP VALUE '90'.88 ROLL-DOWN VALUE '91'.

05 TERMINAL-ID05 RESERVED

These are standard CMD keys used throughout BASIS (see 2.3.4). AdditionalCMD keys may be added according to the program functions.

• FILE STATUS AREA01 FILE-STATUS-aann (aann = file name)

88 FS-aann-SUCCESSFUL VALUE '00'.-EOF VALUE '10'.-SEQ-ERR VALUE '21'.-DUPL-KEY VALUE '22'.-NO-REC VALUE '23'.-BOUNDARY-IND-REL VALUE '24'.-PERM-ERR VALUE '30'.-BOUNDARY-SEQU VALUE '34'.-ERROR VALUE '90' THRU '9Z'.



Normally only "SUCCESSFUL" and "EOF" is used in a program. All unused88 conditions should be removed.

• CL - PARAMETER AREA

01 CL-PARAMETERS.05 CL-mnemonic05 CL-mnemonic

01 TCL-PARAMETER TABLE REDEFINES CL PARAMETERS30 TCL-PAREMETER OCCURS nn TIMES PIC X (8) INDEXED BY TCL.

is used with the COBOL ACCEPT statement to read CL parameters into theprogram. Refer to 2.6.2. A table may be useful to load multiple CLparameters.

• DATES, TIME

Standard modules with predefined field names will be used.

• TERMINAL ATTRIBUTE AREA

01TERMINAL-ATTRIBUTES05 A-TYPE

88 A-DISPLAY VALUE 'D'88 A-PRINTER 'N'88 A-UNKNOWN '2'

05 A-SIZE88 A-1920 '1'88 A- 960 '2'

05 A-SITE88 A-LOCAL 'L'88 A-REMOTE 'R'

05 A-CONN-STATUS88 A-ON LINE '0'

05 A-ALLOCATION88 A-ALLOC-OWN 'A'88 A-ALLOC-OTHER 'E'88 A-AVAILABLE 'V'88 A-NOTAVAILABLE 'N'88 A-UNKNOWN 'U' 05 A-INPUT-STATUS88 A-INP-ALLOWED "Y"88 A-INP-NOTALLOWED "N"



05 A-DATA STATUS88 A-DATA PENDING "Y"88 A-DATA-NOTPENDING "N"

05 A-INQUIRY-STATUS88 A-INQUIRY-MODE "Y"88 A-NOTINQU - MODE VALUE "N"

value "N"

NOTE

THE TERMINAL ATTRIBUTES ARE NOT USED CURRENTLY.

• TABLES

Every table name consists of a table identifier and a mnemonic characterstring:

for example, T4-ARTICLE DATA

T4 = table identifier

The table identifier must start with the character "T", followed by 1, 2, or 3identical characters (0- 9, A - Z). This allows for a maximum of 36 tables perprogram. The number of these characters indicates the dimension of the fieldto be referenced, for example,

T4 ..... first dimensionT88 .... second dimensionTZZZ ... third dimension.

The index of each table is identical to the corresponding table identifier:

30 TB-ARTICLE-ELEMENT OCCURS nn INDEXED BY TB.

Should more indexes be needed for one table the following rule must beapplied:

..... INDEXED BY T3, T3-1, T3-2 .....

..... INDEXED BY T77, T77-1, T77-2, T77-3 .....



The level number of table elements must be within the range of 30 and 39.

Example:

01 T1-ARTICLE-DATA30 T1-ELEMENT OCCURS ..., INDEXED T1

32 T1-ARTNO32 T1-ARTNAME32 T11-ELEMENT OCCURS ..., INDEXED T11

34 T11-PRICE34 T11-REPRICE34 T111-ELEMENT OCCURS ..., INDEXED T111

36 T111-LEFT36 T111-RIGHT

If a table is to be included in an I/O area, the conventions for I/O areaprecede the table conventions, for example, T2 in a table of 10 lines in ascreen output format:

01 WSO-FMT0305 WSO-FIELD PIC (10)05 WSO-T2-ROLL-TABLE

30 WSO-T2-LINE OCCURS 10 TIMES INDEXED BY WSO-T2

32 WSO-T2-FIELDA PIC (5).32 WSO-T2-FIELDB PIC (6).32 WSO-T2-FIELDC PIC (10).

Values can be assigned to a table at compilation:

01 Tn-VALUES05 FILLER PIC (nn) VALUE "...Literals..."05 FILLER PIC (nn) VALUE "...Literals..."

. . .

01 Tn-mnemonic REDEFINES Tn-VALUES30 Tn-ELEMENT OCCURS nn TIMES INDEXED BY Tn.

32 Tn-...



• STANDARD TABLES

Standard tables are used in more than one program. They have an identicalstructure and contain the same type of data. The following standard is usedfor the table name and the table identifier.

Tcc-mnemonic INDEXED BY Tcc.

"cc" and the mnemonic name are predetermined and must not be changed bythe programmer. The following tables exist:

TER-TABLE containing the error codes (assigned at compilation), see3.5.3

TBL-TABLE containing the command key descriptions and the errormessage texts displayed by screen programs (loaded atexecution time as needed)

TCL-TABLE containing CL parameters loaded by means of the COBOLACCEPT statement at execution time)

The structure of the abovementioned tables is already defined and availablein the COBOL frames, for example, XMFR01, XMFR04...)

• SUBSCRIPTS

Due to performance problems, no subscripts should be used in COBOLprograms. Therefore no standards have been set up.

• INDEX DATA ITEMS ("USAGE IS INDEX")

I-Tccc where "Tccc" is the table identifier of the table the index of which is tobe saved.

for example, I-T44, I-T555....I-T1-1,I-T22-3....

If index data items are used to save index values of more than one index,"Tccc" can be replaced by any mnemonic text.

for example, I-SAVE-NO



• WORK FIELDS

W-mnemonic

• RELATIVE KEY

RELKEY-aann (= file name)

• BOOLEAN AREAS

01 INDICATOR-c VALUE ZERO30 INDIC-c INDICATOR 1 PIC 1 OCCURS 99 INDEXED BY TI-c

88 IND-c-ON VALUE B"1"88 IND-c-OFF VALUE B"0"

- The character "c" stands for any letter of the alphabet.- A 99 element table must always be used.

- COPY MODULES (if applied)name of the module is XWaacc (W = working storage section,aa = application, cc = mnemonic, T1 for Table 1)

3.4.5 Standard Words and Prefixes

Aside from the ANS-COBOL reserved words there are a number of 'BASISreserved' words and prefixes which have a standard meaning and must not beused in any other expression (data name, condition name, and so on) than the onethey have been set up for:

1) Standard Words

CCnn (01-99)CMD-ADDINFOCMD-AWRCMD-DELCMD-EOJCMD-NXTERRENTER-KEYFOOTING-LINEIBM-DSP



LDALDA-AREALINAGE-VALUEMODLEV-AREAMODLEVPATCH-AREA-nn (nn = 01-99)PCccccc (ccccc = mnemonic name)RPTROLL-DOWNROLL-UPSHUTDOWNSHUTDOWN-ONSHUTDOWN-OFFSKIP-VALUESORTn (n = 1-9)SYS-CONSOLESYSTEM-SHUTDOWNTBL-ERROR-FMTBL-BOTTOM-LINETBL-ERROR-LINETBL-CMD-DESCRTBL-ERRORCODETBL-ERRORMSGTCLTCL-TABLETERTER-TABLETER-CODETER-CODESTER-CODEnn (where nn = 01-99)TER-RECOVTER-FLAGTER-ATTRTER-ELEMENTW-HHMMSSW-SYSDATEW-SYSTIMEWS-CTRWSCODEWS-ATTRWSDATAWSFILE



2) Standard Prefixes Description

A- Terminal Attribute AreaCORE-INDEX-aann I- C- Control/main storage index of

file aannC-CI-CO- Condition names in FDCU-CL- OCL parametersCMD- Command keysFILE STATUS-aann Condition name in Working Storage SectionFS- File status for file aann

Condition defined for file status(for example, FS-aann-EOF)

I Index data itemINDIC-c Indicator FieldINDIC-c-ON Condition defined for indicator fieldINDIC-c-OFF (where "C" = A-Z) Condition defining status of indicator

(ON/OFF)INDICATOR-c Indicator areaKEYaann Key for index fileLDA- LDA-AreaRPT- FD for printer filesRELKEY-aann Key for relative fileSWITCH-n-SWn-ON- (where n = 1-8) Status of switchesSWn-OFF-TBL TBL = Error message handlingTCL TCL = Standard display of error messages

and command keysTER TER = OCL paralmeters

Tccc- Tables

WS- FD for workstation fileWSI-WSO- WSU- Area for workstation files in working

storage section



Apart from the rules for the use of standard words and/or prefixes, the followingsuggestions should be followed by the programmer:

• No field name in the program must start with the character "X" which is to beused in modules only.

• No field other than patchable constants should begin with characters "PC" or"CC".



3.5 Standards for Patchable Constants

Three types of patchable constants can occur in a program:

• common constants (for example, DATE, PAGE)• program constants• program error messages.

All translated constants are read from the literal part of the System Control file(SCF) "XI01". Depending on the type of constant, the following standards must beadhered to:

Common constants and program constants are read during the programinitialization (standard paragraph 11-XI01-LITERALS available in frames XMFR01-XMFR04). An XI01 record description must be coded for every record retrievedfrom the SCF:

01 XI01-CCnn (common constant, nn = pos. 5-6 of corresponding XI01record)

- or -

01 XI01-PAnnx (program constant, nnx = pos. 11-12 of corresponding XI01record, 'nn' corresponding to PATCH-AREA-nn)

'x' = pos. 13 representing A, B or C

NOTE

ANY OTHER XI01 RECORD DESCRIPTION (LEVEL 01) MUST BECODED AFTER COMMON CONSTANT AND PROGRAM CONSTANTRECORDS.

The module loads the constants in patch areas defined in the working storagesection: see the example below:

01 PATCH-AREA-nn

Standards for PatchableConstants



Program error messages are read from the SCF at execution time when needed.Only a table of error codes used in the program is defined in the working storagesection.

3.5.1 Common Constants

• Every common constant used in a program must exist in the CommonConstant file. See TXP/1.2.

• Common constants can only be specified in the patch areas of a program.

• name: CCnnCC = "common constant"nn = 01-99

• Common constants must be elementary items at 05- level.

• Their length must not exceed 66 characters.

• The length and the actual English text of the constant must be identical to theentries in the Common Constant file XP04 and the PICTURE clause in therecord description of the literal part of the SCF for that constant.

• For every constant used in a program, one entry must be present in the fileDescription of the SCF in that program.

• Module 11-XI01-LITERALS is used to transfer translated text from the SCF tothe corresponding constants in the different patch areas.

• For detailed description of placement of common constants see the examplefor program constants in this manual (paragraph 3.5.2)

SCF Record Description for Common Constants

The following standards must be adhered to:

• For every common constant in the patch areas of the programs, one entry inthe SCF record description for common constants must be present.




IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50

CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

01

XI

01 -

CC

nn

. 0

5 F

IL

LE

RP

IC

X

(17

) .

05

CC

mm

P I

C

X (

. .

) .

05

CC

nn

P I

C

X (

. .

) .

05

F I

LL

ER

05

CC

nn

P I

C

X (

. .

) .



• Record descriptions of common constants must be coded before those forprogram constants.

• For placement of PICTURE clause see paragraph 3.5.2, Program Constants

• Only records and common constants needed in a program must be describedin the FD.

• The record number (XI01-CCnn) depends on which constants are neededand where these constants are stored on the SCF.

NOTE

THESE RECORD DESCRIPTIONS ARE PRE-CODED AND AVAILABLEIN THE COBOL FRAMES (FOR EXAMPLE, XMFR01). THEY MUSTIMMEDIATELY FOLLOW THE 'COPY' STATEMENT FOR XI01.

3.5.2 Program Constants

All translatable text in a program (print constants, constants displayed via theDISPLAY operation code or a screen format) is called "program constant". Theseconstants can only be specified in so-called "patch areas" in the working storagesection of the COBOL program.

The following standards must be adhered to when defining patch areas in theworking storage section:

• The patch areas must immediately follow the modification level area or—ifpresent—the error codes area.

• name:

01 PATCH-AREA-nn

nn = patch area number 01-99

• Patch areas in the program must begin with 01 and must be in ascendingsequence.



• No other 01 or 77 areas must be defined between patch areas.

• At least one common or program constant must be present in a patch area,that is, areas where no translatable text is present must not be called "patchareas"

• A maximum of 66 bytes of translatable text of program constants is permittedin a patch area.

The following standards must be used for program constants:

• name:PCccccc.PC - 'program constant'ccccc = any mnemonic text (next 5 characters)

• The length of a constant must not exceed 66 positions.

• If single text is longer than 66 bytes, two or more constants must be defined.The mnemonic part of these constants must be in closed alphabeticalsequence, so that no other name can be defined between the constants,

for example, PCHEAD1PCHEAD2.

• The PICTURE clause must have the following structure:

PIC X(nn)for example, PIC X(1), PIC X(24)

• Patch constant names must be unique to a program, that is, a programconstant name must not occur more than once. Should the same text beneeded in more than one patch area, two possibilities exist for theprogrammer:

1) to define the text as variable in both areas, but as program constant(PCccccc) in a different area. From here it can be moved to other variablesaccordingly

2) to give the constants different names. This, however, forces the user totranslate the same text more than once.




IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50

CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

Pla

cem

ent

of

Pat

ch C

on

stan

ts i

n t

he

Wo

rkin

g S

tora

ge

Sec

tio

n

01

PA

TC

H A

RE

A-n

n 0

5 P

Ccc

ccc

P I

C

X (

nn

)V

AL

UE

'

-

'

'

. 0

5 C

Cn

nP

IC

X

(n

n)

VA

LU

E

'-

'

' .



• Patch constants must be elementary items in the program (level 05).

• "*" lines (for example, similar) should not be patchable, that is, a name otherthan "PCccccc" must be used.

The same standards apply for common and program constants:

• The patch area number must be in positions 23-24.

• The constant name must start in position 16.

• The length of the constant must be coded in positions 46 and 47.

• For technical reasons an apostrophe (') cannot be part of a patch constant.

• The word 'VALUE' can be placed anywhere.

• The actual text must start on the succeeding line at position 40 (the firstapostrophe at 39)

• If the length of the constant exceeds 32 characters a continuation line mustbe used ("-" in position 7). Here text must start at position 38 (apostropheat 37).

SCF Record Description for Program Constants

Translated constants are stored on the LP of the SCF. A frame must be used bythe programmer to

• access the SCF and

• move constants from there to the corresponding patch areas in the WorkingStorage Section

The following standards are to be used when defining SCF record descriptions:

• For every patch area defined, at least one record description must bepresent.

• The number, names, sequence and patchable positions of program constantsin a record description must be identical to the ones in the correspondingpatch area.




• The record descriptions for program constants must be coded after the onesfor common constants.

• If a patch area contains only common constants, a dummy SCF recorddescription (no fields defined) must nevertheless be defined, that is, the1 to 1 relationship between the SCF and patch areas must be kept. Seeexample 2.




IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50

CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

Exa

mp

le 1

:

01

XI 0

1 -P

A04

. 0

5 F

IL

LE

RP

IC

X

(17

) .

05

PC

OU

TL

P I

C

X (

10 )

. 0

5 P

CA

DD

RP

IC

X

(40

) .

05

PC

CIT

YP

IC

X

(10

) .

05

F I

LL

ER

P I

C

X (

09 )

.



IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50

01

PA

TC

H-A

RE

A-

01 .

05

PC

TO

WN

P IC

X (

14 )

VA

LU

E .

. . .

05

PC

AM

TP

ICX

(15

)V

AL

UE

. . .

.

01

PA

TC

H-A

RE

A-

02 .

05

CC

04P

ICX

(50

)V

AL

UE

. . .

. 0

5 W

- .

. .

P IC

X (

14 )

.

01

PA

TC

H-A

RE

A-

03 .

05

PC

NA

ME

P IC

X (

20 )

VA

LU

E .

. . .

CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

Exa

mp

le 2

In t

his

exam

ple,

pat

ch a

rea

02 d

oes

not

cont

ain

prog

ram

con

stan

ts.

The

fol

low

ing

reco

rd d

escr

iptio

ns o

f th

e S

CF

mus

t be

code

d as

fol

low

s:

* *



01

XI 0

1 -P

A01

. 0

5 s

tatu

s /

Key

fie

ld 0

5 P

CA

DD

RP

IC

X

(40

) .

05

PC

AM

TP

IC

X

(21

) .

05

FIL

LE

R

01

XI

01 -

PA

02 .

PIC

X

(96

) .

01

XI 0

1 -P

A03

. 0

5 s

tatu

s /

Key

fie

ld 0

5 P

CN

AM

EP

IC

X

(20

) .

05

FIL

LE

R


IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50

CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

The

fol

low

ing

reco

rd d

escr

iptio

ns o

f th

e S

CF

mus

t be

cod

ed a

s fo

llow

s:

* *



NOTE

THE RECORD DESCRIPTIONS AND EXAMPLES OF PATCH AREASARE ALREADY PRE-CODED IN ALL AVAILABLE COBOL FRAMES,FOR EXAMPLE, XMFR01.

3.5.3 Program Error messages

Translated error messages are accessed from the literal part of the System Controlfile ("LP of SCF"). When defining the error codes in the program, the followingstandards must be adhered to:



IBM

CO

BO

L C

od

ing

Fo

rm

SY

ST

EM

P

UN

CH

ING

IN

ST

RU

CT

ION

S

P

AG

E

O

FP

RO

GR

AM

GR

AP

HIC

CA

RD

FO

RM

#P

RO

GR

AM

ME

RD

AT

E

P

UN

CH

SE

QU

EN

CE

ID

EN

TIF

ICA

TIO

N

(PA

GE

)(S

ER

IAL)

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

0 1

0 2

0 3

0 4

0 5

0 6

0 7

0 8

0 9

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

1 8

1 9

2 0

1

3

4

6

78

1216

2024

2832

3640

4448

5256

6064

6872

7680

+ A

sta

ndar

d ca

rd f

orm

, IB

M E

lect

ro C

61 1

987,

is p

unch

ing

sour

ce s

tate

men

ts f

rom

thi

s fo

rm.

Inst

ruct

ions

for

usi

ng t

his

form

are

giv

en in

any

IB

M C

OB

OL

refe

renc

e m

anua

l. A

ddre

ss c

omm

ents

con

cern

ing

this

for

m t

o IB

M C

orpo

ratio

n, P

.O.

Box

500

20,

Pro

gram

min

g P

ublic

hing

, S

an J

ose,

CA

951

50


CO

NT.A

BC

OB

OL

ST

AT

EM

EN

T

*

01

TE

R-C

OD

ES

05

TE

R-C

OD

E01

P I

C

X (

11 )

VA

LU

E 'E

aan

nn

E/ W

'. 0

5 P

CN

AM

E

05

TE

R-C

OD

En

n

01

TE

R-T

AB

LE

RE

DE

FIN

ES

RE

R-C

OD

ES

30

TE

R-E

LE

ME

NT

OC

CU

RS

n

n IN

DE

XE

D B

Y T

ER

32

TE

R-C

OD

EP

ICX

(7

) .

32

TE

R-F

LA

GP

IC X

.3

2T

ER

-AT

TR

.3

4T

ER

-AT

TR

1P

ICX

.3

4T

ER

-AT

TR

2P

ICX

.3

2T

ER

-AD

DIN

FO

P IC

X .



• Frame XMFR04 can be used to show how to store the error codes in theprogram.

• All other TER-CODES (TER-CODEnn) and the OCCURS clause must beadded and modified by the programmer according to the needs of theprogram.

SCF Record Description for Error Messages

Translated error messages are stored on the LP of the SCF. Error handlingmodules XMER01 (XMER02) must be used to display (print) messages on screens(report).

The standard record description of the SCF (XFX101) is used by the error modulesto access the error messages and the error attributes.



3.6 Coding and Efficiency Techniques

3.6.1 General

The following clauses in the ENVIRONMENT and DATA DIVISION are not usedand will be partially replaced by BASIS routines:

CURRENCY SIGNDECIMAL-POINTSEGMENT-LIMITRERUN ONBLANK WHEN ZEROSYNCHRONIZEDVALUE OFDATA RECORDS ARECODE SETSIGN LEADING/TRAILING

3.6.2 Data Division

The contents of fields must always be compatible with their PICTURE definition, forexample, a numeric field must not contain blank. To avoid unpredictable results, allfields in the Working Storage Section must be initialized with VALUE accordingly,for example, VALUE "SPACES" for alphanumeric fields, "VALUE ZEROS" fornumeric fields.

All fields should be defined alphanumerically unless used in arithmeticaloperations.

Numeric values are always defined signed.

Arithmetical operations with packed and/or binary are slow and should therefore beavoided.

Exception: COMP-4 fields having identical length can be added or subtractedwithout converting them.

Coding and EfficiencyTechniques



3.6.3 Procedure Division

• Arithmetical expressions should be coded in parentheses.

• Negated conditions should be avoided.

• Conditional statements should be defined by specifying the most unlikelycondition first in an AND relationship and the most likely condition first in anOR relationship.

• ROUNDED Option

• ALTER Statement are not used

• ON SIZE ERROR

• INSPECT: should be replaced by a PERFORM statement whenever possible.

• The "ON OVERFLOW" clause should be used in the STRING andUNSTRING operation codes.

• PERFORM: Must always be used with the "THRU" option.

• Array elements, COMP-3 or COMP-4 fields should be moved to work fieldswhen used often in a routine.

• The COMPUTE statement is more efficient and readable than correspondingarithmetical expressions.

• Segmentation should be used whenever the impact on performance is low(less than, for example, 5% of program duration) to reduce program size.SECTION names are used only in relation to segmentation.

Programming hints (COBOL)

• Concentrate on packed operations which are executed freqentlyfor example, 10.000 times or more (10.000 x 1 ms = 10 sec!)



* Packed fields are redefined with character fields05 W-AMOUNT-PACKED COMP-305 W-AMOUNT-CHAR REDEFINES W-AMOUNT-PACKED

and05 W-ZERO-PACKED VALUE ZEROES COMP-305 W-ZERO-CHAR REDEFINES W-ZERO-PACKED

initialize with zero: MOVE W-ZERO-CHAR TO W-AMOUNT-CHARcompare with zero: IF W-AMOUNT-CHAR EQ W-ZERO-CHAR

• Test for zero before a packed add when there is a good chance that the fieldadded is zeroIF W-AMOUNT-CHAR NOT EQUAL W-ZERO-CHARADD W-AMOUNT-PACKED TO W-TOTAL-PACKED

• Instead of divide by 100 or 1000, use COMPUTE B ROUNDED = A/100where B has the correct number of decimals

• Test end of loops by comparing with an index value (which has been savedduring table load), not with a complex condition:'end of table OR initializedtable entry found'.

• For highly critical loops (executed 100.000 times or more)

- replace AND by If...IF... perform x * - replace OR by IF... perform x * (difference 0.160 ms)

GO TO EXIT-01. *IF... perform x *

GO TO EXOT-02. *

3.6.4 Printer Files

a) Definition of Page Size(s) in SC file (XI01) Installation Option Part

Key Data

OXXLINES nnn (= number of lines per page)




b) Definition of Printer file in a COBOL Program

• FD RPTLABEL RECORD OMITTED, LINAGE IS LINAGE-VALUE,

LINES AT TOP 0, LINES AT BOTTOM 6.

• WORKING STORAGE SECTION77 LINAGE-VALUE PIC 9(03) VALUE 60 (default if OXXLINES not present)77 W-LINKAGE-VALUE REDEFINES LINKAGE-VALUE PIC X(03).77 SKIP-VALUE PIC 9(03)

• INIT-ROUTINEOPEN INPUT XI01MOVE'OXXLINES' TO KEYXI1.PERFORM Z51-XI01-READ THRU Z51-EXIT.IF FS-XI01-SUCCESSFUL

MOVE XI01DATA TO W-LINKAGE-VALUESUBTRACT 6 FROM LINKAGE-VALUE.

OPEN OUTPUT REPORT.

c) Print Routine for Detail Lines

IF LINAGE COUNTER GREATER (LINAGE-VALUE - SKIP-VALUE)PERFORM Zmm-RPT-WRITE THRU Zmm-EXIT.

Znn-RPT-WRITE.WRITE RPT-LINE (FROM RPT-DETAILLINE)

AFTER/BEFORE ADVANCING SKIP-VALUE LINES.

Znn-EXIT.Zmm-RPT-WRITE.

WRITE RPT-LINE (FROM PATCH-AREA-nn)AFTER ADVANCING PAGE.

Zmm-EXIT.



3.6.5 VALUE and Usage Standards for Condition Names

If a condition is to be set on a SET statement should be used.

To indicate an "off" situation for one or more conditions, space and/or zero shouldbe used. These values are reserved for this purpose only.

77 W-ALPHA PIC X.88 C-mnemonic 1 VALUE "A".88 C-mnenonic 2 VALUE "B".88 C-OFF VALUE X.

X = SPACE(S) or " " or "0"

77 W-NUMERIC PIC 9.88 C-mnemonic 1 VALUE 1.88 C-mnemonic 2 VALUE 2.88 C-OFF VALUE Y.

Y = ZERO(S) or 0

77 W-ERROR PIC X.88 C-ERROR VALUE "1".88 C-NOERROR VALUE Z.

Z = SPACE(S) or " " or "0"

To set off one or more conditions, a MOVE statement moving space or zero maybe applied.




3.6.6 Instruction Timings in COBOL

Non critical operations:

• Normal instructions: - set up/down *- set *- go to *- short decimal arithmetic. * 0.005 ms- compare with 'X' *- compare with index value *

• Decimal arithmetic in character (11 char) *Moves of characters (11 char) * 0.020 ms

• Perform loop with varying an index, per cycle: 0.050 ms• complex logic: per AND or OR 0.160 ms

Critical operations (if executed frequently)

• Any arithmetic COBOL operation using 0.2-0.6msCOMPUTE,GIVING,SIZE ERROR or ROUNDED key word

• Any arithmetic COBOL operation using an 0.5 msoperand with a length 15 bytes

• multiply non-packed 1.0 ms• divide non-packed 1.5 ms• multiply AxB -- C (all packed) 2.4 ms• divide A/B -- C (all packed) 2.9 ms• Move unpacked to packed or vice versa 0.6 ms• Move zero to packed 0.6 ms• Add packed A+B -- A (A and B packed) 1.4 ms• Add packed A+B -- A (A unpacked, B packed) 0.6 ms• Compare A and B (both packed) 1.0 ms• Convert decimal suffix or decimal value to index 0.6 ms• change sign: COMPUTE A = -A (packed) 1.0 ms



3.6.7 Standard Coding for I-O Operations

This coding has to be applied for all disk I-O operations. Normally it forces aCOBOL-'STOP' if an I-O operation was not performed successfully (for example,WRITE-operation, but file is full and no EXTEND performed, and so on).The AT END and INVALID KEY clause is not used on the COBOL I-O statements.By using a DECLARATIVE section system stops are avoided. In the I-Oprocedures (see 3.4.1 for naming conventions) file status test and error handling isoptional and must not be coded if:

a) File status test is performed in main program outside of I-O procedure (seeprocessing of XI01, XJ02.......in program frames) or

b) procedure should not stop for a not successful I-O operation (for example,dummy READ's to unlock locked records......).

Standard coding consits of three parts:

a) FILE STATUS entries (see 3.4.4 file status area)b) DECLARATIVE section (see example)c) I-O procedures (see examples)

Declaratives:

PROCEDURE DIVISION * -------------------

DECLARATIVESI-O-ERROR SECTION

USE AFTER ERROR PROCEDURE ONXI01 , XJ02AANN , AANN . . . . . > AANN .

?-----> SUBSTITUTE FILE NAMES (AANN) FOR ALL USED DISK FILESDUMMY-PARAGRAPH.END DECLARATIVES.

* -------------------MAIN-PROGRAM SECTION.

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

MAINLINE. * *************




NOTE

THE CODING EXAMPLEX FOR THE DECLARATIVE SECTION ANDTHE I-O PROCEDURES ARE INCLUDED IN THE PROGRAM FRAMES.

I-O Procedures - System Files

Z51-XI01-READ. * *******************

READ XI01.Z51-EXIT.

EXIT.

Z51-XI01-READNEXT. * **************************

READ XI01 NEXT RECORD.IF FS- XI01-SUCCESSFUL

GO TO Z53-EXIT.IF FS- XI01-EOF

GO TO Y53-EXIT.Z53-ERROR.

DISPLAY 'ERROR FOR FILE XI01 / READ NEXT / ''FILE STATUS = ' FILE-STATUS-XI01UPON IBM-DSP

DISPLAY 'TAKE HARD COPY AND DUMP / CALL FOR SUPPORT'UPON IBM-DSP

STOP ' '

Z54-XJ02-READ. * ********************

READ XJ02.Z54-EXIT.

EXIT.

Z55-XJ02-REWRITE. * *************************

REWRITE XJ02REC.Z55-EXIT.

EXIT.

Similar procedures are available for XO01 and XO70 in program frame XMFR05.



I-O Procedures - Other Files

***************************************************************************************************** Sequential 'READ' for Disk Files *****************************************************************************************************

?-----> Substitute in whole procedure, file name for 'aann' Z??-aann-READNEXT.***************************

READ aann .IF FS-aann-SUCCESSFUL

GO TO Z??-EXIT.IF FS-aann-EOF

GO TO Z??-EXIT. Z??- ERROR.

DISPLAY 'ERROR FOR FILE aann / READ NEXT / ''FILE STATUS = ' FILE-STATUS-aannUPON IBM-DSP

DISPLAY 'TAKE HARD CPOY AND DUMP / CALL FOR SUPPORT'UPON IBM-DSP

STOP ' 'GO TO Z??-ERROR.

Z?? EXIT.EXIT.

***************************************************************************************************** Random 'READ' for Disk Files

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

?-----> Substitute in whole procedure, file name for 'aann' Z??-aann-READNEXT.***************************

READ aann . Z??- ERROR.

IF NOT FS-aann-SUCCESSFULDISPLAY 'ERROR FOR FILE aann / READ / '

'FILE STATUS = ' FILE-STATUS-aannUPON IBM-DSP

DISPLAY 'TAKE HARD CPOY AND DUMP / CALL FOR SUPPORT'UPON IBM-DSP


Z?? EXIT.EXIT.




***************************************************************************************************** 'START' or 'DELETE' for Disk Files

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

?-----> Substitute in whole procedure?-----> + file name for 'aann' and?-----> + START or DELETE for ???????

Z??-aann-??????.**********************

?????? aann . Z??- ERROR.

IF NOT FS-aann-SUCCESSFULDISPLAY 'ERROR FOR FILE aann / ?????? / '




Z?? EXIT.EXIT.

***************************************************************************************************** 'WRITE' or 'REWRITE' for Disk Files

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

?-----> Substitute in whole procedure?-----> + file name for 'aann' and?-----> + START or DELETE for ???????

Z??-aann-???????.***********************

??????? aannREC. Z??- ERROR.

IF NOT FS-aann-SUCCESSFULDISPLAY 'ERROR FOR FILE aann / ??????? / '




Z?? EXIT.EXIT.



3.7 Program Structure

3.7.1 Structure of Working Storage Section.

The different areas of the WSS must be coded in the sequence specified below:

1) Areas for modification level (MODLEV-AREA) and system identification(SYSTEM-IDENT).

2) Error code area and error code table:

01 TER-CODES

01 TER-TABLE

3) Patch areas

01 PATCH-AREA-0101 PATCH-AREA-02

For further information on patching standards see 3.4.5.

4) Areas for installation options and run options:

Only the 01 level names are standard and have to be used as specified in thefollowing examples: Both examples are also available in frames XMFR01through XMFR04.

01 XI01 - INSTALLATION-OPTIONS.

05 XI01-DATE-FORMAT PIC X(6) VALUE 'DDMMYY'.05 XI01-DATE-MASK PIC X(8) VALUE 'bb//.bb//.bb//'.05 XI01-TIME-MASK PIC X(8) VALUE 'bb//:bb//.bb//'.05 XI01-DECIMAL-SIGN PIC X VALUE ','. ' ' ' etc. (as required)

Program Structure



• The VALUE represents the default to be used by the program unless theXI01 record is present; it must be set according to the default documentedon the B7 layout.

• A subdefinition can be inserted wherever required with the VALUE-clauseremaining on the 05 level, for example,

05 XI01-DATE-MASK VALUE 'bb.bb.bb'.

10 FILLER PIC X(2).10 XI01-DATE-EDITSIGN-1 PIC X.10 FILLER PIC X(2).10 XI01-DATE-EDITSIGN-2 PIC X.10 FILLER PIC X(2).

01 XJ02-RUN-OPTIONS.

05 XJ02-CALL-DATE PIC X(6).05 XJ02-REORG-DATE PIC X(6) VALUE SPACES.05 XJ02-CALL-ROUTE PIC X(3) VALUE SPACES.

• The VALUE should be provided as default wherever necessary

5) Input, output, and update areas for file data, that is, areas processed with theREAD INTO/WRITE FROM operation codes.

6) Area for LDA data or checkpoint area, including LDA

7) Tables

8) Boolean Areas

9) Index data items

10) All other work fields (W-mnemonic)

11) Areas for the• file status• workstation control area• attribute data

12) All parameters of standard modules (COPY, CALL, INCLUDE) used in theprogram. Standard frames (for example, XMFR1) where this structure isprovided should be used by the programmer.



3.7.2 Structure of Procedure Division

• All standard modules must be copied at the end of the procedure divison.

• All paragraphs in ascending sequence by module identifier

Example:

MAINLINE1-INIT2-READWS3-PROCESS *31 *311 *312 *32 *. *. *. * Module 3-PROCESS together33 *331 *3312 *' *' *' *4-DISPLAY5-TERMINATEY1Y11'

Y2- - -'Z 1'''ZnnXM'''

Program Structure



3.7.3 COMMENTS

• EJECT should be used only after FILE SECTION AND WORKING STORAGESECTION.

• blank lines should be used for an optical separation of paragraphs.

• level numbers: 1- 5-1 ...

For table elements, the level numbers must be in the range between 30 and 39.

• PICTURE AND VALUE clauses should be in identical positions in oneprogram. For patch constants, however, certain positions are obligatory (seepatching standards in this manual).

• Indentation:

0105

10 W- FLAG88 C-INVALID ...

IF CONDITION-1MOVEADD

IF CONDITION-2ADDSUBTRACT

ELSEMULTIPLY

ELSEPERFORMDIVIDE

An extra line must be coded for the following clauses:

INVALID KEY, AT END, GIVING, VARYING WHEN, INTO, ON OVERFLOW, ONSIZE ERROR



Arithmetical expressions should be coded as follows:

ADD W-ALTW-NEW

TO W-AMTW-TAX

Every performed paragraph must be preceded by a short comment.

Program Structure






3.8 Program Administration

• IDENTIFICATION DIVISION

• AUTHOR, INSTALLATION, DATE-WRITTEN, DATE-COMPILED are notused and replaced by an identification block:

Programmer Date Mod. Level Description

Written ZADRAZIL 80/07/01 00 Mainten. PSCHISTACEK 80/08/04 02 SZTASCZIK 80/08/19 04

• PROCESS STATEMENT

All options to be used for last compilation, the source listing of which has tobe given to the program distribution department.

• All statements

Whenever a program is modified, the statements concerned (changed or newones) must be flagged with the new modification level in positions 73-74.

On positions 1-5 serial number and positions 75-80 the program name mustbe inserted. The SEU serialization feature may be used.

A B COBOL STATEMENT

010203040506

07

Program Administration

8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68

01 MODLEV-AREA .05 MODLEV PIC 99 VALUE 0005 MODLEV-FILLER PIC X (4 ) . VALUE ' ------- '05 MODLEV-IDENT PIC X (9 ) . VALUE 'MODLECBL'






3.9 Program Modules

Generally, all standards used in main programs must also be applied in modules.

3.9.1 Naming Conventions

Module Names

A common naming structure is used for all module types (COPY/CALL modules,frames):

XMccnnCXM = Standard identificationcc = Classification of the module

for example, FP - field processingTP - table processing

nn = Sequence number within the class of the modules

C = First letter of the COBOL division where the module is used: forexample, D - Data Division, P-Procedure Division

If the module goes across divisions, (program frame, CALL module),no character is present.

For further information on naming conventions see 3.4.

COPY modules and procedure frames will normally consist of two entries:

• XMccnnD - where all input/output/work fields are described• XMccnnP - where the actual statements are stored.

Paragraph and Field Names

The same hierarchical philosophy as for a program must be considered whendesigning a module.

Program Modules



Example:

XMccnn

XMccmm-1- XMccnn-2- XMccnn-3- XMccnn-4-

DIGITS SIGN DECIM ALPHA

XMccnn-31- XMccnn-32-

COMMA FULL STOP

• For COPY modules all fields-, table-, condition-, paragraph names, and so onare preceded by XMccnn-, that is, the identification prefix of the module.

for example, 01 XMFP01-AGE

88 XMFP01-C-SENILE VALUE 35 THRU 99

Note that the prefix can be omitted in all documentation of the module, forexample, structograms, procedure diagrams, and so on. The main paragraph,that is, the paragraph performed by the program, and its corresponding EXITmust be coded as follows:

Main Program:

PERFORM XMFP4-mnemonic THRU XMFP4-EXIT

Module (XMFP4P)

XMFP4-mnemonic

XMFP4-EXIT



• Since most of the fields in a module are work fields, the prefix "W" can beomitted.

• All input/update/output parameters of the module must be prefixed by:

XMccnn-I- , XMccnn-U-, XMccnn-O-,for example, XMFP4-I-INTERNAL, XMFP4-O-EXTERNALXMTP8-O-C-OVERFLOW condition name as output parameter

In this way, all parameters which link the module with the main program caneasily be distinguished from internal work fields.

3.9.2 "Dummy Parameters"

When he is writing a COPY module and for example the length of fields,parameters, number of elements for a table, and so on. are different from programto program, the programmer must define "dummy parameters" instead of theseentries. These parameters will be replaced by actual values at the time the moduleis copied into the program.

As shown in the following examples the following standards must be adhered to,when defining dummy parameters.

• dummy parameter for substitution of PICTURE clause

Module:

XMccnn-I-AMOUNT PIC ?10? .XMccnn-I-TAX PIC ?04? .

COPY Statement:

COPY XMccnn REPLACING ==?10?== BY ==9(2)====?04?== BY ==9(4)==

• if two or more identical attributes occur in a module, the same dummyparameter name can be assigned to them.

Program Modules



Module:

XMccnn - FIELD1 PIC ?02? .XMccnn - FIELD2 PIC ?02? .

Copy Statement:

COPY XMccnnD REPLACING ==?02?== BY ==X(24)==

• as specified in the COBOL manual, the pseudo text- replacing option can beused only to replace complete text words, that is, expressions delimited byblank characters:

for example, PIC b ?07? b .?07? can be replaced by, for example, "X(5)"

PIC b X(?07?) .(?07?)- cannot be replaced by, for example, '5' because not

delimited by blanks.

• as shown in the example, the full stop must not be coded immediately afterthe parameter's name ?07?. This is to ensure:- that the parameter is followed by a blank character -and-- that enough space is reserved for the replacing text:

for example,

1) PICb?08?bbbb.

2) COPY XMccnnD REPLACING==?08?== BY XXXXXXXthat is, "?08?bbb" will be replaced.

The space to be reserved for the replacing text must at least be equal to thenumber of positions in that text plus one blank position, for example,

a parameter must be replaced by the character string XXBBXXBBXX, (i.e.10 positions). The parameter must be coded as follows:

PIC ?01?bbbbbbb.11 positions (10 for the text +1)

• for OCCURS and/or VALUE clauses, and so on, the aformentioned standardshave to be applied accordingly.



3.9.3 Administration Documentation and Comments

a) COPY Modules and Frames

The standards to be applied in a module are the following:

1) Insert date of last change, module version no., module name and serialnumber in the source statements as shown in the following table.

POSITIONS IN SOURCE STATEMENTS FOR

MODULE DATE OF a) MODULE b) MODULE SERIAL NO.

TYPE LAST CHANGE VERSION NO. NAME

COPY

MODULE

(D AND P) 60-67 c) 70-73 c) 75-80 d) 91-95 d)

FRAME 60-67 c) 70-73 c) 75-80 d) 91-95 d)

NOTES

A) FORMAT OF DATE IS YY/MM/DD

B) FORMAT OF VERSION NO. IS XX.Y

XX = NUMBER BEING INCREASED BY 2 WITH EACH CHANGE (00//,2 ...). IF A CHANGE APPEARS IN A COPY MODULE OF TYPE'D', AND NOT IN TYPE 'P', OR VICE VERSA, THE NUMBER ISINCREASED IN BOTH TYPES.

Y = FOR INTERNAL USAGE IN DEVELOPMENT GROUP.

C) ONLY IN THE FIRST STATEMENT OF THE MODULE

D) IN ALL STATEMENTS OF THE MODULE.

Program Modules



2) For COPY modules and procedure frames, comment statements are used inthe beginning, defining the function.

3) Description of parameters, fields, subroutines, and so on, are put into the T5module manual.

Example of 1), 2), and 3):

XMER02D

*** XMER02 STOP ERROR HANDLING ********************* 81/03/12 02.0 XMER02 0001 01 XMER02-1-INDICATOR PIC X. XMER02 0002

88 XMER02-1-C-REC.-O-ALLOWED VALUE IS "Y." XMER02 000388 XMER02-1-C-REC.-O-NOT-ALLOWED VALUE IS "N." XMER02 0004

***************************************************************************************************** XMER02 0005

Position 60-67 Position 70-73

XMER02P

*** XMER02 STOP ERROR HANDLING ********************* 81/03/12 02.0 XMER02 0001 ******************************** XMER02 0002 XMER02-STOP-ERROR. XMER02 0003 ******************************** XMER02 0004

DISPLAY XMER01-O-ERRCODE XMER01-O-T1-MESSAGE(01) UPON IBM-DSP XMER02 0005 PERFORM XMER02-DISPLAY THRU XMER02-DISPLAY-EXIT XMER02 0006

VARYING XMER01-T1 FROM 02 BY 01 XMER02 0007UNTIL XMER01-T1 IS EQUAL TO 05 XMER02 0008

IF XMER02-I-C-REC-O-ALLOWED XMER02 0009 STOP "RECOVERY ''0'' ID ALLOWED" XMER02 0010

ELSE XMER02 0011 PERFORM XMER02-STOP THRU XMER02-STOP-EXIT XMER02 0012

100 TIMES. XMER02 0013 SET XMER02-I-C-REC-O-NOT-ALLOWED TO TRUE. XMER02 0014

Position 75-80

Position 91-95

b) CALL Modules (COBOL subprograms)

The standards to be applied are the same as for a main program. See 3.7, 3.8.



3.10 S/36 - S/38 Considerations

3.10.1 Programs

With the development of BASIS II we decided to use COBOL as our programminglanguage. COBOL may be a common, business oriented language, but whenprograms are being developed for S/34, S/36 and S/38, the differing COBOLversions for each machine make development difficult. It is our objective to developBASIS II programs in such a manner that they can be executed on all machines,while maintaining only one source program.

To achieve this we must• apply programming standards and• run a conversion utility.

a) Programming Standards

To simplify application of these standards most of them are considered in thestandard COBOL frames and copy modules located in library 'SYSMOD'.

1) Hardware indicator (S/34, S/36, S/38)

A hardware indicator is used to distinguish between S/34, S/36 and S/38during the execution of programs if necessary. Source statements for thisindicator (module XWXXSI) are copied from the 'SYSMOD' library into thesource program during the compilation. They have the following format:

S/36 - S/38 Considerations



25 WORKING-STORAGE SECTION. XUP002 0060XUP002 0061

************************************************************************ XUP002 0062XUP002 0063

26 01 MODLEV-AREA XUP002 006427 05 MODLEV PIC 99 VALUE 00. XUP002 006528 05 MODLEV-FILLER PIC XXXX VALUE '----', XUP002 006629 05 MODLEV-IDENT PIC X(9) VALUE 'MODLEVCBL', XUP002 0067

XUP002 0068************************************************************************ XUP002 0069

XUP002 0070COPY XWXXSI. XUP002 0071

* 83/06/07 00.0 XWXXSI30 01 SYSTEM-IDENT PIC X(6) VALUE 'S/34'. XWXXSU31 88 C-S34 VALUE 'S/34'. XWXXSI32 88 C-S36 VALUE 'S/36'. XWXXSI33 88 C-S38 VALUE 'S/38'. XWXXSI * XWXXSI

The value of field 'SYSTEM-IDENT' depends on the location of the modulewhich can be in the 'SYSMOD' of S/34, S/36 or S/38.

Use: IF C-S34WRITE ....

IF C-S36WRITE ....

IF C-S38WRITE ....

2) Numeric Fields (S/38)

The field contents have to be numeric, otherwise the system stops duringexecution. To avoid this, these fields must be, for example,

• initialized with a numeric value, or

• tested and value changed to numeric if necessary, and so on.



3) COBOL Sort (S/38)

Although there is no problem on S/34 and S/36, a compiler error will appearon S/38 if control is passed outside of sort input and/or sort output procedure.For details see COBOL reference manual SC21-7741, chapter 6.

4) TRANSACTION File (S/38)

An initial READ (READ before first WRITE) is not supported on S/38 andmust be avoided.

b) Conversion Utilities

1) XXP001 (menu SYS2) S/34 to S/38 Source

This utility performs changes in the following statements, clauses andparagraphs:

• PROCESS statement (APOST, FLAG...)• SOURCE-COMPUTER clause (IBM-S38)• OBJECT-COMPUTER clause (IBM-S38)• SELECT clause for printer files (...-QSYSPRT)• SELECT clause for TRANSACTION files (...-SI)• SPECIAL-NAMES Paragraph (LOCAL and ATTRIBUTE deactivated)• APPLY CORE-INDEX clause (deactivated)• COPY statement (... OF QCBLSRC-SYSMOD)• Z98-LDA-READ/Z99-LDA-WRITE

(COPY... included / ACCEPT ... and DISPLAY ... deactivated)

For further details of changes, see the logic manual of XXP001.

After conversion, the source code can be compiled on S/38 without anyfurther changes.

2) XUP004 - S/36 to S/XX source conversion (menu SYS2)

This utility activates or deactivates source statements in COBOL programs.This allows maintenance of only one source meember for S/36, S/34 andother systems. Activation and deactivation is controlled by control statementsfollowed by the source statements to be applied.




Control Statement

Pos. 7 '*'Pos. 8 - 11 name of system for which the source statements are valid(S/34, S/36 or S/38).Pos. 12 blankPos. 13 - 14 n n = number of source statements following the controlstatement, if not used default = 01

Example

*S/34 01*PROCESS SOURCE LIST*S/36 PROCESS SOURCE OFFSET*S/38*PROCESS

Conversion Example (S/36 to S/34)

a) Before conversion:

CONFIGURATION SECTION*S/34 02*SOURCE-COMPUTER. IBM-S34.*OBJECT-COMPUTER. IBM-S34*S/36 02SOURCE-COMPUTER. IBM-S36.OBJECT-COMPUTER. IBM-S36

*S/38 02*SOURCE-COMPUTER. IBM-S38.*OBJECT-COMPUTER. IBM-S38*S/36 01

MEMORY 21504 CHARACTERS.*S/34* MEMORY 23004 CHARACTERS.SPECIAL-NAMES.

*S/34 03* UPSI-0 IS SWITCH-1-MNEMONIC* ON IS SWI-ON-MNEMONIC* OFF IS SWI-OFF-MNEMONIC.

position 7



b) After conversion

CONFIGURATION SECTION*S/34 02SOURCE-COMPUTER. IBM-S34.OBJECT-COMPUTER. IBM-S34

*S/36 02*SOURCE-COMPUTER. IBM-S36.*OBJECT-COMPUTER. IBM-S36*S/38 02*SOURCE-COMPUTER. IBM-S38.*OBJECT-COMPUTER. IBM-S38*S/36 01* MEMORY 21504 CHARACTERS.*S/34

MEMORY 23004 CHARACTERS.SPECIAL-NAMES.

*S/34 03UPSI-0 IS SWITCH-1-MNEMONIC

ON IS SWI-ON-MNEMONICOFF IS SWI-OFF-MNEMONIC.

position 7

3.10.2 Screen Formats

Similarly to programs our objective is to develop screen formats which can be usedon S/34, S/36 and S/38 while maintaining only one screen format source member.

To achieve this we must• apply standards in designing screen formats, and• run a conversion aid (S/38 only).

a) Design Standards

Although there is no difference between S/34 and S/36 screen formats, for S/38some standards must be observed as described in 2.3.3.

b) Conversion Aid (S/38 only)

This is a set of modified IBM utilities which converts S/34-DSF to S/38-DDS(menu SYS2). For conversion details see SB30-0447. During the conversion




process the following S/34 screen format functions are ignored as not orincorrectly supported on S/38:

• return input• suppress input• override fields• indicator for output/input fields.

CL Standards

PTF 53.5 – T3 DEVELOPMENT STANDARDS 4 - 1

LibraryStandards4

PTF 53.5 – T3 DEVELOPMENT STANDARDS

4.1 Introduction 4-3Guidelines 4-3Coordination and Scope 4-3Modification Level 4-4

4.2 Menu Standards 4-7Menu Types 4-7Menu Design 4-10Menu Documentation 4-13

4.3 CL Standards 4-15CL Complexes 4-15CL Program Procedures 4-21CL Messages 4-23CL-Standard Procedures 4-23Defining of Printer Files in Procedures 4-35

4.4 Message Member 4-37Concept 4-37Structure of a Message Member 4-38Maintenance 4-51

4.5 Miscellaneous 4-53Prompt Display 4-53

LIBRARY STANDARDS

PTF 53.5 – T3 DEVELOPMENT STANDARDS4 - 2


CL Standards


4.1 Introduction

4.1.1 Guidelines

Generally, library members such as menus and control language will not be fullycompatible between machines. Although conversion aids are often provided, inpractice a great deal of manual interaction is normally required for such conversion.

For these reasons,the BASIS policy is to keep these functions as simple aspossible. In addition, documentation is left as generalized as possible.Documentation of particular features of a machine should be avoided. Forexample, explanations such as '?1? on S/34' should be avoided. 'Parameter 1means...' is superior.

Section 4 is restricted to standards. For example, cross-application CL proceduresand messages are documented in B4, Operating guide, and are available to theuser.

4.1.2 Coordination and Scope

Procedures will be established to coordinate, identify (modification level) andadminister the library members.

MESSAGE MEMBER:• CL MESSAGES (common and application dependent)• FILE DEFINITIONS (size, back-up onto diskette)• MENU ITEM DEFINITIONS (CL complex-name and parameters)

MENUS• APPLICATION, SYSTEM FUNCTIONS• CROSS APPLICATION

CL COMPLEXES• APPLICATION, SYSTEM FUNCTIONS• STANDARD CL COMPLEXES (for example, COPY, DELETE)

Introduction

LIBRARY STANDARDS


PROGRAM SOURCE• COBOL PROGRAMS• SCREEN FORMATS• MODULES

PROGRAM OBJECT• COBOL PROGRAMS• SCREEN FORMATS• CALL MODULES

Each topic is discussed individually.

The Development Manager is responsible for controlling the assignment of

Subject Documented in

Menu names (aaMnnn) aa/1+2, Taa/2 (application menus)B4 (cross application menus 'XX', startmenu 'ZZ')

CL complex names (aaCnnn) Taa/3 (application complexes)B5 (standard complexes)

Program/format/ (aaPnnn/ Taa/4 (application programs and sorts)sort names aaFnnn/

aaSnnn)

MIC numbers (BASISMSG) B5 (CL messages, file definitions, menuitems)

4.1.3 Modification Level

Modification levels are structured in such a way that utilities (such as UTLB inBASIS) can find them in SOURCE as well as LOAD members. The modificationlevel is placed as close as possible to the beginning of the members in order toallow fast search (especially in LOAD members, the member must be searchedbyte by byte).

CL Standards


Structure of the modification level (ML):

nnbbbbMODLEVcccnn = modification level 00-99

(increased by 2 in case of program modification)

bbbb = '----' for COBOL programs, spaces for all other members

'MODLEV' = constant used to allocate the version no. in a LOAD member

ccc = member type ... CBL (COBOL program)RPG (RPG linkage programs)FMT (Screen formats)MSG (Message member)(MEN (Menus) - standard structure not

applied, see 5 )CL (CL complexes)XL (Source members for print lists,

selection lists, order lists, file lists)ASM (Assembler routine)

The member type is stored in the ML. If this were not the case it would be verydifficult to determine the type of a utility. This is especially important for localmembers.

1) COBOL ML is stored as the first 01-item in the Working StorageSection.

2) RPG: ML is stored as a constant in the first element of the firstcompile time array.

3) SCREEN FORMATS: ML is stored in the first format FMT01 which is standardfor all screens. The constant 'MODLEVFMT' mustappear in the format as 'non-display' so that it can befound in the 'format load member'.

Introduction

LIBRARY STANDARDS


Example of Screen Heading Line

BASIS OMP100 2 00 MODLEVFMT CCnnn XX.XX.XX XX XX

2 = modification level of the program00 = modification level of the formatMODLEVFMT = non-displayCCnnn = license contract numberXX = user-IDXX = workstation-ID

In the load member, IBM generates 4 bytes in front of each field. These positionsare not checked by the utility which looks for the ML. But in order to have a uniqueML in all load members these 4 positions are left blank in all member types.

4) MESSAGE MEMBER: ML is stored in the second message record.

5) MENU: ML is stored in the following way:

a) Using SDA: Insert the 2 digits of ML in line 3 (heading line) pos. 3-4.

b) Using SEU/BILDMENU: • Update MIC 0003/pos. 7-8 of "display text" sourcemember-aaMnnnDT, with the 2 digits of ML.

• Execute BLDMENU with aaMnnn

6) CL COMPLEXES: ML is stored in the first comment line, right adjusted,for example, 'nnbbbbMODLEVCL' in positions 60-73.

7) XL SOURCE MEMBERS:ML is stored in the first comment line, right adjusted,for example, 'nnbbbbMODLEVXL' in positions 82-95.

Each BASIS program running under a Job Control File stores its ML in the JobControl File at execution time. At the end of a job, this information is transferred tothe Job History File. From there it is possible to see which program versions havebeen used. This is important for the user as well as the development group, as itfacilitates tracing of errors.

CL Standards


4.2 Menu Standards

4.2.1 Menu Types

Three menu types exist:

1) BASIS menus aaM000 application main menuaaM001-499 application sub menusXXM000 BASIS main menu (cross application)XXM001-499 other cross application main and sub menus

2) User menus aaM500 application main menuaaM501-999 application sub menusXXM500 user main menu (cross application)XXM501-999 other user menus

3) Start menus ZZM000 standard start menuZZM0uu start menu for every user (uu = user-ID)

BASIS menus are designed and maintained by the development group. Theyappear in the BASIS Documentation and must therefore not be changed by theuser. Normally the main menu has a sufficient number of menu items. If too manymenu items exist (selection possibilities, and so on), sub menus can be created forsimilar activities. The BASIS cross application menus XXM000-499 provide aproposal for organizing departmental activities such as daily and month-endprocessing, and so on and are documented in B4, Operating Guide.

Generally, the user is free to build his own menus, so-called user menus, and torearrange items in BASIS menus according to local needs. Numbers 500-999 areavailable to the user. User menus are created and maintained locally with SDA (orby the MIS-group). Automatic linkage to the user main menu is provided by itemno. 23 of all BASIS menus (for example, OMM000-23 calls menu OMM500 andXXM005-23 calls menu XXM500).

To make use of the IBM menu security system, so-called start menus are used tochannel the activities of every workstation user entitled to work on the computer.Start menus must be created and maintained locally with SDA. A standard startmenu, ZZM000, which is supplied by Vienna can be used as a pattern. Theindividual start menu automatically appears to the workstation user after sign-on.

Menu Standards

LIBRARY STANDARDS


Automatic return to 'his' start menu is provided by item number 24 of all BASISmain menus. A typical start menu contains item number 1 to assign messagemember ('start-up') and items 2-24 to call permissable menus.

No hierarchical relationship exists between main and sub menu numbers.Assignment of numbers 001-499 is left to the analyst designing an application. Itemnumber 24 of a main menu is always used return to the start menu, whereas itemnumber 24 of a sub-menu is used to return to the main menu. See the example onthe next page.

CL Standards


SIGN-ON (USER-ID "AB")

MENU ZZMOAB

S T A R T M E N U

--Sales Department (AB)--

1. START-UP

5. ORDER ENTRY

6. DAILY INV. (local)

7. DAILY CLOSING

22. SIGN OFF

MENU OEM000 MENU INM500 MENU XXM001

O R D E R E N T R Y D A I L Y I N V O I C I N G D A I L Y C L O S I N G

--MAIN MENU-- --USER MAIN MENU-- --MAIN MENU--

1. TEL-SELL 1. CHAIN STORE INVOICING 1. FINAL ROUTE SETTLEMENT

2. ADVANCE SALESMAN 2. SINGLE INVOICES 2. DAILY REPORTS (SA & DS)

5. REPORTS MENU 3. COMMISSION (del. Personnel)

22. SIGN-OFF 23. USER MENU 10. LOCAL REPORTS MENU 4. (Sales Staff)

24. Start MENU 22. SIGN-OFF 23. USER MENU

24. Start MENU

MENU OEM003 MENU INM502 MENU XXM500 (if existing)

O R D E R E N T R Y D A I L Y I N V O I C I N G

--REPORTS MENU-- --LOCAL REPORTS MENU--

1. ORDER SUMMARY 1. -

2. NON-BUYING OUTLETS 2. -

3. EXCEPTION REPORT 3. -

22. SIGN-OFF 23. USER MENU

24. MAIN MENU

MENU OEM500

O R D E R E N T R Y

--USER MAIN MENU--

1. TEL-SELL (Northern Area)

2. (Southern Area)

.

.

.

Menu Standards

LIBRARY STANDARDS


4.2.2 Menu Design

Standards for menu design:

• The free field format is used.

• Each line has 75 positions. Menus can be translated into local language (XPPatching).

• Standard layout of menus:

Line 1 not available2 menu name (also not available)3 modification level (see 4.1.3),

name of application, resp. system function or cross applicationtitle, for example, 'DAILY CLOSING', with 1 space between letters

4 main menu constant, or title of constant 'MAIN MENU' orsubmenu title (for example, 'REPORTS MENU'), delimited by '--'

5 blank line6-19 menu items

20 standard menu items21-24 not available.

• The sub-menu title is identical to the title of the main menu item.

• Space is available for 13 menu items (lines 7-19).

• Standard menu items presented in line 20: 22. SIGN-OFF 23. USER MENU 24. START MENU (for main menu) 24. MAIN MENU (for sub-menu)

- The OCL behind the standard menu items are:

22. XRC003 INTERACT,,?WS? 23. // MENU aaM500,?SLIB?

24. // MENU ZZM0?USER?

• Comments are to be shown right-adjusted next to the menu item. Commentsdo not appear between menu items.

• Menu items are listed in a straight line down the page (except standard menuitems which appear on one line). If space is needed for comments, left adjustmenu items.

CL Standards


Menu Standards

2

• Leave a space between menu items to group similar menu items.

• Leave one or two item numbers free between groups of similar menu itemsso that an additional menu item can easily be added (or created via a sub-menu).

• Avoid special characters such as '*'. Menu layout is kept simple.

• The start menu is the menu which is presented to the workstation user atsign-on. It automatically restricts him to certain activities or menus (IBM menusecurity).

• User menus are those in the range of 500-999 for which the user is fullyresponsible. Standard item number 23 provides linkage to aaM500.

• Examples appear on the following pages.

Sample Menus - Main and Sub Menu

COMMAND W5MENU : OEM000

02 O R D E R E N T R Y A N D I N V O I C I N G--MAIN MENU--

1. PROCESSING MENU2. INQUIRY MENU3. REPORTS MENU4. MONTHLY CLOSE MENU5. FILE MAINTENANCE MENU

22. SIGN OFF 23. USER MENU 24. START MENU

ENTER NUMBER, COMMAND, OR OCL.<- READY

1 Menu name 4 "Main Menu" constant2 Modification Level 5 Menu item, number, and title3 Application title 6 Standard menu items

1

34

5

6

LIBRARY STANDARDS


COMMAND W5MENU : OEM001

04 O R D E R E N T R Y A N D I N V O I C I N G --ORDER PROCESSING MENU--

1. ORDER ENTRY2. ORDER ENTRY-IMMEDIATE RELEASE3. ORDER MAINTENANCE4. ODER RELEASE5. DISKETTE ORDER ENTRY6. BATCH UPDATE7. PICK LISTS8. INVOICES



7 Sub menu name8 Sub menu title ( = title of main menu item)

Sample Menus - Main and Sub Menu

COMMAND W5 MENU : XPM000

00 P A T C H I N G --MAIN MENU--

1. EXTRACT CONSTANTS MENU2. DISTRIBUTION MENU3. FILE MENU4. TRANSLATION MENU



3

7

2

8

5

6

CL Standards


COMMAND W5MENU : XPM001 06 P A T C H I N G--EXTRACT CONSTANTS MENU--

1. COBOL PROGRAMS EXTRACT PROGR. & COMMON CONSTANTS

2. MENU MEMBERS EXTRACT CONSTANTS FROM MENU

3. MESSAGE MEMBER EXTRACT CONSTANTS FROM MESS.MEMB.

4. SCREEN FORMATS EXTRACT CONSTANTS FROM SCR. FORMATS

5. ALL MENBERS EXTRACT FROM ALL MEMBERS TYPES



4.2.3 Menu Documentation

User oriented menu documentation is included in the user manual (aa):aa, 2.4 Sample Menus and Xreens (overview)

See 1.1.3, User Application Manual.

Technical oriented menu documentation is included under Taa2, MenuSpecifications:

2.1 aaMnnn Menu Name (details by menu item number).

See 1.1.4, Technical Manual.

Menu Standards

LIBRARY STANDARDS



CL Standards


4.3 CL Standards

4.3.1 CL Complexes

CL Complexes do not contain CL statements to 'load' a program (that is, LOAD,FILE and RUN on S/34.) But they provide much CL-logic outside the program(IF-ELSE, GO TO - TAG). BASIS includes two types of complexes:

1) aaCnnn - application complexes (execute application programs)

2) XXcccccc - standard complexes (call IBM-utility programs) with 'cccccc'signifying any descriptive name such as CPYFIL, DELFIL.For details see chapter 4.3.4

The following general rules apply to CL-complexes:

• Record length is 96, but use only 1-70 to facilitate filing of hardcopies.

• CL-messages are displayed from the message member only; informationalCL-messages must be suppressed for batch jobs (that is, on S/34 IF JOBQ-NO IF EVOKED-NO * MIC-no.).

• The first statement is always a comment line with complex-name, title andmodification level.

• CL complexes have to be generated without history logging

The following rules apply to aaCnnn application complexes:

• All external parameters used (except standard parameters like complex,version, company, location, and so on) must be described in front of thecomplex, that is, parameters, switches, LDA, Message Member. See theexample at the end of this section.

• Comments must be included together with the 'structured' approach: pos.1-3*** pos.4-70 comment. (Except standard parameters such as complex,version, company, location, and so on)

• The program names and short description are displayed as informational CL-messages for interactive jobs (see 4.3.2 CL Program Procedures).

LIBRARY STANDARDS


• Standard procedures XXTSTFIL or XXTSTFLS are used when necessary totest for presence of files before the first program starts (with message tosystem operator).

• Deletion of files should be done as much as possible with the RETAIN-Sparameter (performance). If not possible use XXDELFIL or XXDELFLSprocedures.

• If running under XJ Job Control the complex must be subdivided intocheckpoint steps (refer to TXJ/1).

• Tag names: checkpoint-tag = aaPnnn, others = TAGnn (nn=01-99).

Use of CL Parameters (supported by SSP on S/34 and CPF on S/38):

• CL parameters should not be confused with run options (applicationprograms)

• However, CL-parameters can be used in Xs or stand alone programs to pass'Run Options' to a program (via // PROMPT and ACCEPT LDA)

• Mnemonic names should be used as far as possible, for example, DRAFT,FINAL, and so on.

• '1' and '' should be used for YES/NO decisions, for example, print updatereport 1 - yes, 0 - no

• A value of blank should not be allowed for important (mandatory) parameters.With less important (optional) parameters blank defaults to the most frequentcase.

• Assignment of parameters to the main complex should always begin withnumber 1. If parameters are passed 'down' to sub complexes they should bepassed with the same parameter number (for example, main complexARC001 A,B,C,D subcomplex ARC101 ,,C).

• Screen formats (// PROMPT on S/34) may be used for Xs or stand aloneprograms to enter missing CL-parameters and/or display errors. Refer to4.5.1.

• CL-parameters are documented before all CL-complexes to understand theCL logic flow. See the example at the end of this section.

CL Standards


User Complexes

If it is necessary to run user applications together with BASIS complexes in MultipleApplication Processing (MUAP), the user complexes have to be coded according toBASIS standards, including job control. To allow this, message member entrieshave been reserved in the job control area records (4460-4469) and CL messages(1970-1979). (See 4.4.2.) If the above is provided for, the complex can be includedin MUAP processing as can any BASIS complex.

For a description of MUAP complexes, see manual XJ.

LIBRARY STANDARDS


Documentation in CL procedures:

1234567890123456789012345678901234567890123456789012345678901234567890123456789

******************************************************************************************** xxxxxx DESCRIPTION NN MODLEVCL ********************************************************************************************

****PARAMETERS* NUMBER, VALUE

* 1 'XXXXXX' DESCRIPTION* 2 X(8) DESCRIPTION* 3 'A' DESCRIPTION

* 'B' DESCRIPTION****SWITCHES

* NUMBER STATUS* 1 0 DESCRIPTION* 1 DESCRIPTION

* 2 1 DESCRIPTION* 3 X DESCRIPTION*

***LOCAL DATA AREA* POS. LENGTH* 1 8 DESCRIPTION

* 9 1 DESCRIPTION* 10 2 DESCRIPTION*

***MESSAGE MEMBER* MIC POS/LENGTH* XXXX XX XX DESCRIPTION

* XX XX DEXCRIPTION* XXXX XX XX DESCRIPTION* XX XX DESCRIPTION

****MAINTENANCE COMPLEXaaC001

1-10 11-20 21-30 31-40 41-50 51-60 61-70 71-80

CL Standards


The following CL-variables are standard and do not have to be documented inprocedures:

MIC NO. POS. LENGTH TEXT

0003 1 2 Company file group (should be blank)3 2 Location file group5 2 Location code

3nnn 31 5 Number of BLOCKS36 4 Number of BLOCKS for EXTEND40 1 On line indicator56 5 Slot of diskette station

4nnn- 1 8 Menu item6nnn 9 1 Execution type

10 2 Complex number12 2 Version number14 1 MUAP processing code

X = job not allowed in MUAP16 6 CL-procedure name

LDA POS. LENGTH

101 156 Standard LDA information

PARAMETERS NO.

10* Company file group code11* Location file group code

* not compulsory; if used for other purpose, it has to be documented.

REL45 – T3 DEVELOPMENT STANDARDS

LIBRARY STANDARDS


Example of a Tel-Sell complex

************************************************************************** *O E C 0 0 3 ORDER ENTRY TEL-SELL COMPLEX 02 MODLEVCL*******************************************************************************PARAMETERS* NUMVER VALUE* NONE****SWITCHES* NUMBER STATUS* 1 1 ALWAYS SET ON FOR COMPLEX (USED ONLY I OEP230)****LOCAL DATA AREA* POS. LENGTH* 1 2 USER-ID* 3 2 WORKSTATION-ID*** 05 14 OUTLET NAME AND ADDRESS SEARCH FIELD (INPUT TO OMP072)* 05 7 OUTLET NUMBER (FROM OMP072 OR SELECTED FROM REVIEW SCREEN* 20 6 PROGRAM AFTER OMP072 (UPD.: OEP200.USED ONLY IN OMP072)* 35 6 NEXT PROGRAM NAME TO BE EXECUTED* 41 1 ERROR INDICATOR* 42 1 PROCESSING TYPE* 71 6 OE20 ADDRESS (OF OUTLET SELECTED FROM REVIEW SCREEN)* 77 5 FP03 ADDRESS (OF OUTLET SELECTED FROM REVIEW SCREEN)****MESSAGE MEMBER* MIC POS/LENGTH* NONE****INITIALZE LDAXXDELLDA// LOCAL OFFSET-001,DATA-'?USER?'// LOCAL OFFSET-003,DATA-'?WS?'// LOCAL OFFSET-035,DATA-'OEP200'// LOCAL OFFSET-102,DATA-'?1'OEM00105'?'// LOCAL OFFSET-114,DATA-'?USER?'// LOCAL OFFSET-116,DATA-'?WS?'// LOCAL OFFSET-122,DATA-'?USER?'// LOCAL OFFSET-245,DATA-'?M'0003.5.2'?'****ACCESS COMPANY & LOCATION FILE GROUP CODES.FORCE AS PARMETER 10 & 11// IF ?10F'?M'0003,1,2'?'?/DUMMY// IF ?11F'?M'0003,3,2'?'?/DUMMY****BUILD FILE OE20?USER? IF NOT EXISTING// IF DATAF1-?11?OE20?USER? GOTO START// BLDFILE ?11?OE20?,D,BLOCKS.?M'3000.31.5'?.512*// TAG START****SET ON SWITH-1// SWITCH 10000000****SUBSTITUTE NEXT PROGRAM TO BE EXECUTED AS A TAG NAME// TAG RETURN// IF ?L'35,6'?/ GOTO END// GOTO ?L'35,6'?

// TAG OEP200OEP200 ,,,,,,,,,?10?,?11?// GOTO RETURN

CL Standards


****TEL-SELL ORDER ENTRY// TAG OEP210OEP210 ,,,,,,,,,?10?,?11?// GOTO RETURN****TEL-SELL UPDATE ORDER// TAG OEP220OEP220 ,,,,,,,,,?10?,?11?// GOTO RETURN****TEL-SELL DISPLAZ CALLING STATUS// TAG OEP230OEP230 ,,,,,,,,,?10?,?11?// GOTO RETURN****OMP072 NAME ADDRESS SEARCH// TAG OMP071OMP072 ,,,,,,,,,?10?.?11?// GOTO RETURN****END COMPLEX// TAG END

4.3.2 CL Program Procedures

A CL program procedure exists to "load" each program, i.e. a program on S/34must contain // LOAD, // FILE and // RUN. The following rules apply:

• A CL program procedure must not contain CL logic, that is, IF and GOTO.

• File size (in blocks) for output files is substituted from the Message Member.An automatic EXTEND may be use for output/add-to files (appropriateEXTEND value in BLOCKS is also substituted from the Message Member ifpresent).

• File location is not used (dynamic allocation of disk space is preferable).

• File group (that is, company code, location code) is substituted from themessage member (MIC number 3, pos. 1-2 and 3-4). If an interactiveprocedure has many FILE-statements (more than 6) the company or locationcode should be forced into parameter 10 and 11 respectively (?10F'?'M0003,1,2'?'? for company files, ?11F'?'M0003,3,2'?'? for location files) when usedthe first time and used as a prefix for all file lables thereafter (for example,?10?OM01). This improves substitution by about 25%.


LIBRARY STANDARDS


NOTE

THE COMPANY FILE GROUP CODE SHOULD BE SET TO BLANK INTHE BASIS MESSAGE MEMBER.

• The program name and title is taken from the Message Member anddisplayed to the workstation calling the program (before actual LOAD), forexaemple, O M P 0 3 0 UPDATE OM-FILE (suppress for batch jobs, that is,on S/34 // IF JOBQ-NO IF EVOKED-NO MIC-no.).

• Output files are deleted (before actual LOAD) to avoid SYS-stop. Usestandard complex XXDELFIL.

• CL parameters are passed to the program from the CL program procedure,either using the COBOL ACCEPT method (as described in 2.6.2) or via theLDA (using the // LOCAL statement on S/34. See 2.6.1.

• If the program was cancelled with recovery 2, cancel the entire job, that is, onS/34 test Return Code ?CD? after the // RUN statement and CANCEL theprocedure with a message to the workstation.

• CL program complexes have to be generated without history logging.

N -LOG THE PROCEDURE STATEMENTSN -MULTIPLE REQUESTOR TERMINAL PROCEDUREN -PROGRAM DATA IN INCLUDE STATEMENTS

Example of a CL Program Procedure

*************************************************************************** F P P L 0 0 OUTLET SELECTION 00MODLEVCL ****************************************************************************// IF JOBQ-NO IF EVOKED-NO * 1010// XXDELFIL ?M'0003,3,2'?FP02?L'122,2'?// LOAD FPP100// FILE NAME-XI01,LABEL-?M'0003,1,2'?XI01,DISP-SHR// FILE NAME-XJ02,LABEL-?M'0003,1,2'?XJ02?L'122,2'?,DISP-SHR// FILE NAME-FP02,LABEL-?M'0003,1,2'?FP02?L'122,2'?,BLOCKS-?M'3011,31,5'?// IFF ?M'3011,36,4'?/ EXTEND-?M'3011,36,4'?// FILE NAME-OM06,LABEL-?M'0003,1,2'?OM06,DISP-SHR,IFILE-YES// FILE NAME-OM01,LABEL-?M'0003,1,2'?OM01,DISP-SHR// RUN// IF ?CD?/3721 CANCEL


CL Standards


4.3.3 CL Messages

• The only way to display a message is from the message member (that is, use// * MIC no.).

• CL messages can be translated into local language with menu XIM000/// (viaSEU and screen formats).

• CL messages are documented in B5, Implementation Guide (commonmessages) and Taa (application related messages).

• MIC Numbers 1-2999 are reserved for CL messages:MIC no. 1-100 BASIS I messages

101-999 BASIS II common messages1000-2999 BASIS II application related messages.

• Application related CL messages are assigned in ranges (for example, 1080-1099 OM, 1100-1119 AM, ...) with vacant records for future additions.

4.3.4 CL-Standard Procedures

A series of standard procedures is available for general purpose use e.g. deletionof file(s), existence test on files etc.

The descriptive name for those procedures is:XXcccccc where cccccc is split into 2 times 3 characters with the first 3 ccc's

equalling the function name (such as CPY, DEL, TST) and thenext 3 'ccc' equalling the object name (such as FIL, FLS).

The following standard procedures exist and are documented in the following:XXCPYFIL copy file disk to diskXXDELFIL delete a single disk fileXXDELFLS delete up to 11 disk filesXXORGFIL organize an indexed disk fileXXRNMFIL rename a disk fileXXTSTFIL test presence of a disk file and restore from diskette if not presentXXTSTFLS same for up to 11 filesXXCOPFLS copy up to 5 files disk to diskXXP050 check for valid security code/user-ID combinationXXP100 transfer records from file to LDA


LIBRARY STANDARDS


LIBRARY - SYS.JOB

DATE 20/12/88

TIME 10.51

PAGE

1 SUB REF REL MRT PROGRAM RECORD NUM TOTAL

NAME TYPE TYPE DATE TIME NUMBER

ATTRIBUTES

LEV MAX SIZE/K BYTES LENGTH STMTS

SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXP050 P 20/01/88 10.45 000013 NOLOG

5.0

120 30

5

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

* X X P 0 5 0

PROCESS

AXX-JOBSEC

RECORDS

00 MODLEVCL *

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

***PARAMETER(S)

* PARAMETER NUMBER

* 01: SECURITY CODE BEING USED FOR CHECKS IN XI01

* FOR DETAILS SEE :

B2, JOB SECURITY (SECURITY CODE METHOD)

*B7,

AXX-JOBSEC

OPTIONS

* 02: TO SAVE/RESTORE LDA POS. 114-117

(USER-ID)

* 03: TO SAVE/RESTORE LDA POS. 484-489

(SECURITY

CODE)

* ***LOCAL DATA AREA (LDA)

* POS.

LENGTH

* 114

4

USER-ID (ONLY TWO POSITIONS ARE USED)

* 484

6

SECURITY CODE

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

// IF JOBQ-NO IF EVOKED-NO * 1129

//

EVALUATE

P2='?L'114,4'?'

//

EVALUATE

P3='?L'484,6'?'

//

LOCAL

OFFSET-484,DATA-'?1?',BLANK-6

//

LOCAL

OFFSET-114,DATA-'?USER?',BLANK-4

* // LOAD XXP050

//

FILE

NAME-XI01,LABEL-?M'0003,1,2'?XI01,DISP-SHR

// RUN

*RESTORE

LDA

//

LOCAL

OFFSET-114,DATA-'?2?'

//

LOCAL

OFFSET-484,DATA-'?3?'

*

CL Standards


LIBRARY - XDI

DATE 11/12/87

TIME 10.22

PAGE 1

SUB REF REL MRT PROGRAM RECORD NUM TOTAL


ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXP100 P 11/01/87 08.42 000013 NOLOG

5.0

120 51

7

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

* X X P 1 0 0

TRANSFER RECORDS FROM FILE TO LDA

00 MODLEVCL *

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

***PARAMETER

DESCRIPTION

* PAR-1 FILE NAME ------------->

NAME OF INPUT FILE (RECL=132).

* * -2 SEARCH KEY ------------>

**** ONLY USED ID ?4? = 'L' ****

*DEFINES -ALL- OR A GROUP OF RECORDS

*VALUES MAY BE :

*-NAME- ,

*-NAME.- (=GROUP SELECTION) OR

*-ALL- (=DEFAULT FOR BLANK)

* -3 PROCESSING INDIC. ------>

'START' =

PROGRAM PROVIDES DATA OF

*1. RECORD IN FILE OR IF

*DEFINED IN ?2?+?4?

*1. RECORD OF A GROUP

*BLANK =PROGRAM PROVIDES DATA OF

*'NEXT' RECORD IN PHYSICAL

*SEQUENCE OF IF DEFINED

*IN ?2?+?4? , -NEXT- RECORD

*OF A GROUP

* -4 FILE TYPE -------------->

'L' =

FILE TO BE PROCESSED IS A

*'LISTLIBR' DISK FILE. ?2? IS

*USED FOR RECORD SELECTION.

*BLANK =FILE TO BE PROCESSED IS A

*NORMAL DISK FILE AND ?2? IS

*IGNORED.-ALL-

RECORDS

WILL

*BE

SELECTED.

* ***LDA-DESCRIOPTON

* POSITION

LENGTH

* 301 G

132

RECORD-AREA FROM FILE

* 301

8

PAR-2 / SEARCH KEY

* 433

7,0 REL. REC # OF LAST TRANSFERRED RECORD

* -----> '9999998' = 'EOF' OR 'END OF GROUP'

* 440

8

PAR-3 / PROCESSING INDICATOR

* 448

1

PAR-4 / FILE TYPE

* // * '?M1129?'

//

LOACL

OFFSET-301,DATA-'?2'ALL'?',BLANK-8

PAR-2 / SEARCH KEY

//

LOCAL


PAR-3 / PROCESSING INDIC.

//

LOCAL


PAR-4 / FILE TYPE

* // LOAD XXP100

//

FILE

NAME-XX40,LABEL-?1?,DBLOCK-20

// RUN

*

LIBRARY STANDARDS


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXBLDMSG P 12/03/84 12.38 000001 NOLOG

1.0

120 11

2

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

* X X B L D M S G

UPDATE MESSGAE MEMBER - BASISMS(x)

02 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1

X(1) MESSAGE MEMBER SUFFIX

* // IF ?1?/ * 0100

SEU

BASISMS?1R?,S,XXF000,80,?SLIB?

CREATE

BASISMS?1?,REPLACE,?SLIB?

LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXCOPFLS P 05/06/84 09.33 000002 NOLOG

1.0

120 22

4

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

* X X C O P F L S

COPY FILES DISK TO DISK

02 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF INPUT FILE 1

* 2

X(8) FILE LABEL OF OUTPUT FILE 1

* 3


* 4


* 5


* 6


* 7


* 8


* 9


* 10


* // IFF ?01?/ IFF ?02?/ XXCPYFIL ?01?,?02?

// IFF ?03?/ IFF ?04?/ XXCPYFIL ?03?,?04?

// IFF ?05?/ IFF ?06?/ XXCPYFIL ?05?,?06?

// IFF ?07?/ IFF ?08?/ XXCPYFIL ?07?,?08?

// IFF ?09?/ IFF ?10?/ XXCPYFIL ?09?,?10?

CL Standards


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXCPYFIL P 04/03/87 09.33 000002 NOLOG

4.0

120 37

5

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

* X X C P Y F I L

COPY FILE DISK TO DISK

06 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF FILE TO BE COPIED

* 2

X(8) FILE LABEL OF OUTPUT FILE

* 3

'D

OPTIONAL, DELETE INPUT FILE (DEFAULT=NO DELETE)

* 4

N(4) OPTIONAL, NO.OF BLOCKS FOR OUTPUT FILE (DEFAULT=BLOCKS

* FROM INPUT FILE)

* 5

X(3) 'YES' OR 'NO' FOR DFILE-KEYWORD , BLANK = NO CHANGE

* 6

X(3) 'YES' OR 'NO' FOR IFILE-KEYWORD , BLANK = NO CHANGE

* // IF ?1?=?2?

* '- TRYING TO COPY TO SAME FILE-LABEL : ?1?'

// IF ?1?=?2?

* '- JOB IS IN TERMINATION...'

// IF ?1?=?2?

PAUSE

// IF ?1?=?2?

CANCEL

* // IFF DATAF1-?1?

RETURN

XXDELFIL ?2?

* // IF JOBQ-NO IF EVOKED-NO * '?M1120?'

// LOAD $COPY

//

FILE

NAME-COPYIN,LABEL-?1?,

// IF ?3?/D

RETAIN-S,

//

UNIT-F1,

// IF ?M'0002,36,1'?/

DISP-SHRRM

//

IFF

?M'0002,36,1'?/

DISP-SHR

//

FILE

NAME-COPYO,LABEL-?2?,

//

UNIT-F1

// IFF ?5?/

DFILE

-?5?,

// IFF ?6?/

IFILE-?6?,

//

BLOCKS-?4'?F'S,?1?'?'?

// RUN

//

COPYFILE

OUTPUT-DISK

// END

LIBRARY STANDARDS


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXDELFIL P

NOLOG

8.0

96

15 2

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

* X X D E L F I L

DELETE A SINGLE DISK FILE (IF PRESENT)

00 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF FILE TO BE DELETED

* // IFF DATAF1-?1?

RETURN

* // IF JOBQ-NO IF EVOKED-NO * ?M11217'

// LOAD $DELET

// RUN

//

SCRATCH

LABEL-?1?,UNIT-F1

// END

CL Standards


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXDELFLS P 31/10/84 31.35 000007 NOLOG

2.0

96 36

5

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

* X X C P Y F I L

DELETE UP TO 11 DISK FILES(IF PRESENT)

02 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1-11

X(8) FILE LABEL(S) OF FILE(S) TO BE DELETED

*BLANK TERMINATES THE PARAMETER LIST

* // IF JOBQ-NO IF EVOKED-NO * 1122

// LOAD $DELT

// RUN

// IF ?01?/

GOTO ENDO

// IF DATAF1-?1? SCRATCH UNIT-F1,LABEL-?1?

// IF ?02?/

GOTO ENDO


// IF ?03?/

GOTO ENDO


// IF ?04?/

GOTO ENDO


// IF ?05?/

GOTO ENDO


// IF ?06?/

GOTO ENDO


// IF ?07?/

GOTO ENDO


// IF ?08?/

GOTO ENDO


// IF ?09?/

GOTO ENDO


// IF ?10?/

GOTO ENDO

// IF DATAF1-?10?

SCRATCH UNIT-F1,LABEL-?10?

// IF ?11?/

GOTO ENDO

// IF DATAF1-?11?

SCRATCH UNIT-F1,LABEL-?11?

// TAG ENDO

// END

LIBRARY STANDARDS


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXDELLDA P 27/09/85 12.45 000001 NOLOG

3.0

96 5

1

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

* X X D E L L D A

DELETE LDA (SET POS.1-256 TO BLANK)

02 MODLEVCL *

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

* // LOCAL BLANK-256

CL Standards


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXORGFIL P 08/11/83 14.51 000003 NOLOG

1.0

96 32

5

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

* X X O R G F I L

ORGANIZE AN INDEXED DISK FILE

02 MODLEVCL *

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

* ***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF FILE TO BE ORGANIZED

* 2

X(8) FILE LABEL OF OUTPUT FILE

* 3

'D

OPTIONAL, DELETE INPUT FILE (DEFAULT=NO DELETE)

* 4

N(4) OPTIONAL, NO.OF BLOCKS FOR OUTPUT FILE (DEFAULT=BLOCKS

* FROM INPUT FILE)

* 5

N(3) OPTIONAL, POS.OF DELETION CHARACTER

*'SYSDEL'

REMOVE DELETED RECS. FROM DELETE-CAPABLE FILE

* 6

X(2) OPTIONAL, DELETION CHARACTER(S)

* // IFF DATAF1-?1?

RETURN

XXDELFIL ?2?


// LOAD $COPY

//

FILE

NAME-COPYIN,LABEL-?1?,

// IF ?3?/D

RETAIN-S,

//

UNIT-F1,

//

FILE

NAME-COPYO,LABEL-?2?,BLOCKS-?4'?F'S,?1?'?'?,

// IF ?5?/SYSDEL DFILE-YES,

// UNIT-F1

// RUN

//

COPYFILE

OUTPUT-DISK,

// IF ?5?/SYSDEL

DELETE-SYSDEL,

// ELSE

IFF ?5?/ IFF ?6?/

DELETE-'?5?,?6?,

//

REORG-YES

// END

LIBRARY STANDARDS


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXRNMFIL P

NOLOG

8.0

120

17 2

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

* X X R N M F I L

RENAME FILE,DELETE NEW LABEL IF PRES.

00 MODLEVCL *

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

* ***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF FILE TO BE RENAMED

* 2

X(8) NEW FILE LABEL

* // IF JOBQ-NO IF EVOKED-NO * '?M11237'

// LOAD $RENAM

// RUN

//

RENAME

LABEL-?1?,NEWLABEL-?2?

// END

CL Standards


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE



ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXTSTFIL P

NOLOG

8.0

96

20 3

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

* X X T S T F I L

TEST PRESENCE OF FILE,RESTORE FROM DSKT00 MODLEVCL *

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

* ***PARAMETERS

* NUMBER

VALUE

* 1

X(8) FILE LABEL OF FILE TO BE TESTED AND RESTORED

* 2

X(5) OPTIONAL, DISKETTE LOCATION (DEFAULT=S1)

* // IF DATAF1-?1? RETURN


// ** '?M1127?'

// IF JOBQ-NO IF EVOKED-NO * '?M1125?'

// LOAD $COPY

//

FILE

NAME-COPYIN,LABEL-?1?,UNIT-F1,LOCATION-?2'S1'?

//

FILE

NAME-COPYO,LABEL-?1?,UNIT-F1

// RUN

//

COPYFILE

OUTPUT-DISK,REORG-NO

// END

LIBRARY STANDARDS


LIBRARY - #LIBRARY

DATE 26/11/87

TIME 09.47

PAGE

10

SUB REF REL MRT PROGRAM RECORD NUM TOTAL


ATTRIBUTES


SECTORS

------- ---- ---- ------- ---- ------ --------------------- --- --- ------------ ------ ----- -----

--

XXTSTFLS P

NOLOG

8.0

96

32 4

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

* X X T S T F I L

TEST PRES.OF AND RESTORE UP TO 11 FILES00 MODLEVCL *

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

***PARAMETERS

* NUMBER

VALUE

* 1-11

X(8) FILE LABEL(S) OF FILE(S) TO BE TESTED AND RESTORED

*BLANK TERMINATES THE PARAMETER LIST

* // IF JOBQ-NO IF EVOKED-NO * 1128

// IF ?01?/

XXTSTFIL ?1?,S1

// ELSE

RETURN

// IF ?02?/

XXTSTFIL ?2?,S1

// ELSE

RETURN

// IF ?03?/

XXTSTFIL ?3?,S1

// ELSE

RETURN

// IF ?04?/

XXTSTFIL ?4?,S1

// ELSE

RETURN

// IF ?05?/

XXTSTFIL ?5?,S1

// ELSE

RETURN

// IF ?06?/

XXTSTFIL ?6?,S1

// ELSE

RETURN

// IF ?07?/

XXTSTFIL ?7?,S1

// ELSE

RETURN

// IF ?08?/

XXTSTFIL ?8?,S1

// ELSE

RETURN

// IF ?09?/

XXTSTFIL ?9?,S1

// ELSE

RETURN

// IF ?10?/

XXTSTFIL ?10?,S1

// ELSE

RETURN

// IF ?11?/

XXTSTFIL ?11?,S1

// ELSE

RETURN

CL Standards


4.3.5 Defining of Printer Files in Procedures

Printer Statement / Connection COBOL Program - OCL - MIC

COBOL Program:

Select RPT assign to printer-aaPnnnc

NORMAL PRINT PROGRAM: MIC

// LOAD aaPnnn// PRINTER NAME-aaPnnn?M7020? 7020 , FORMS-5501, ALIGN-YES,......// FILE// FILE . . .// RUN

7030 , COPIES-3,......7031 , COPIES-2,......7032 , FORMS-5502,......

No special PRINTER parameters 7040PRINTER parameters at execution time 7050 , PRIORITY-0,....

GENERIC PRINT PROGRAM USED IN VARIOUS COMPLEXES:

COMPLEX 01// LOAD aaP7nn// IF ?L'142,2'?/01 PRINTER NAME-aaP7nnA? m7030? (132 PRINT

POSITIONS)// IF ?L'144,2'?/01 PRINTER NAME-aaP7nnB? m7030? CPI-15 (198 PRINT

POSITIONS)

// IF ?L'144,2'?/02 PRINTER NAME-aaP7nnA? m7031?// IF ?L'144,2'?/02 PRINTER NAME-aaP7nnB? m7031? CPI-15

// IF ?L'144,2'?/04 PRINTER NAME-aaP7nnA? m7032?// IF ?L'144,2'?/04 PRINTER NAME-aaP7nnB? m7032? CPI-15

// FILE// FILE . . .

// RUN

}

}

}

LIBRARY STANDARDS



Message Member


4.4 Message Member

The message member is used in BASIS as a central place to store and maintaininformation to be used in CL-procedures.

4.4.1 Concept

BASIS uses its own message member, BASISMSx. (x = corresponds to thelocation's file group. The same message member can be used to allow BASIS Iand BASIS II to run in parallel,

• within one computer each location has its own message member.

• If 2 or more companies share one computer, a separate message member isneeded per company (company 1 = BASISMSA, 2 = BASISMSK,3 = BASISMSP,..).

• The third message record (MIC no. 3, pos. 1-2) contains the company filegroup 'c.' to keep separate files per company (for example, c = A. K. P.) and(in pos. 3-4) the location file group code 'l'. (for example, l = B. C. D. L. M.).

NOTE

THE COMPANY GROUPING CODE IS NO LONGER SUPPORTED BYBASIS. THE VALUE IN THE BASIS MESSAGE MEMBER SHOULD BESET TO SPACES.

• The message member must be manually activated from the user's start menuZZMuu (with uu = user ID). Refer to 4.2, Menu Standards.

LIBRARY STANDARDS


4.4.2 Structure of a Message Member

A message member consists of 9999 records, each of which is addressableindividually in OCL/CL by means of a so-called MIC (message identification code)number. The following MIC number ranges are reserved for development:

MIC number0001 BASIS I / BASIS II title0002 Modification level (BASIS I as well as BASIS II)0003 Company and location file groups and libraries.0004 SD Preparation0005 MUAP Library0006 SAVDAT (internal BASIS save data parameters)0007 BASIS Data Dictionay (IDDU) and Query Library0008 BASIS to ROSS Linkage0009 BASIS to ROSS Linkage

0nnn Common OCL Messages(10-100 for BASIS I, 101-999 for BASIS II)

1nnn- Application related OCL-messages2nnn (application ranges assigned in development sequence)

3nnn File definitions (size, EXTEND-value, BACKUP information)(assigned in development sequence)

4nnn- Menu item definitions (application ranges6nnn assigned in development sequence)

7nnn Report definitions (per report or per complex/report)

8nnn Available for BASIS user

9000- BASIS I file definitions and other BASIS II options9499

9500- Save media and definitions for XJ automatic safety copies9998

9999 Reserved for XJ automatic safety copies (must be blank)

Message Member


Assigned MIC Number Ranges

1) APPLICATION RELATED OCL-MESSAGES (1nnn-2nnn)

1000 - 1029 FP (1)1030 - 1059 OE (1)1060 - 1069 XO1070 - 1079 XJ & XR (1)1080 - 1099 OM (1)1100 - 1119 AM (1)1120 - 1139 XX1140 - 1159 XL (1)1160 - 1179 OM (2)1180 - 1199 XL (2)1200 - 1249 OM (3)1250 - 1269 XP1270 - 1289 XI1290 - 1339 AM (2)1340 - 1399 FP (2)1400 - 1449 SI (1)1450 - 1474 OE (2)1475 - 1549 RS (1)1550 - 1579 IN (1)1580 - 1584 XJ & XR (2)1585 - 1629 SA (1)1630 - 1649 IN (2)1650 - 1699 DS1700 - 1729 FI (1)1730 - 1779 AR (1)1780 - 1809 SD (1)1810 - 1819 MA1820 - 1829 KA1830 - 1849 CA1850 - 1879 WH1880 - 1899 CF (1)1900 - 1949 RS (2)1950 - 1969 SI (2)1970 - 1979 USER JOBS1980 - 1989 XA (1)1990 - 1999 AR (2)2000 - 2099 CB2100 - 2129 SI (3)2130 - 2139 SB (2)2140 - 2159 FI (2)2160 - 2179 XA (2)2180 - 2219 CS (1)2220 - 2239 AR (3)

2240 - 2249 SD (2)2250 - 2269 SA (2)2270 - 2274 SB (2)2275 - 2279 AR (4)2280 - 2289 CF (2)2290 - 2299 CS (2)2300 - 2399 OS & PA2400 - 2424 EC2425 - 2449 ED2850 - 2879 SD (3)2880 - 2899 XJ & XR (3)

2) FILE DEFINITIONS (3nnn)3000 - 3009 OE (1)3010 - 3019 FP3020 - 3024 XO3025 - 3029 XJ3030 - 3049 OM3050 - 3069 XI3070 - 3079 AM (1)3080 - 3099 XL3100 - 3109 XP3110 - 3129 AM (2)3130 - 3149 SI3150 - 3159 OE (2)3160 - 3179 RS3180 - 3199 IN3200 - 3219 SA3220 - 3229 FI (1)3230 - 3249 AR (1)3250 - 3269 SD3270 - 3274 MA3275 - 3279 KA3280 - 3289 CA3290 - 3299 FI (2)3300 - 3319 WH3320 - 3329 DS3330 - 3339 XA3340 - 3359 CB3360 - 3369 SB3370 - 3374 CF3375 - 3379 XX3380 - 3409 CS

LIBRARY STANDARDS


3410 - 3429 MM3430 - 3439 AR (2)3440 - 3449 SD3500 - 3519 OS3520 - 3529 EC3530 - 3539 PA

3) MENU ITEM DEFINITIONS (4nnn 6nnn)

4000 - 4024 FP4025 - 4049 OE (1)4050 - 4074 OM (1)4075 - 4099 AM4100 - 4109 XL (reserved)4110 - 4139 OM (2)4140 - 4154 CF4155 - 4159 XJ (1)4160 - 4169 AM (2)4170 - 4219 SI4220 - 4234 OE (2)4235 - 4249 RS (1)4250 - 4269 SA4270 - 4279 RS (2)4280 - 4299 DS4300 - 4329 IN4330 - 4344 FI (1)4345 - 4364 AR (1)4365 - 4374 FI (2)4375 - 4394 SD (1)4395 - 4409 CA4410 - 4439 WH4440 - 4459 XA4460 - 4469 USER JOBS4470 - 4499 CB4500 - 4509 SB (1)4510 - 4529 CS4530 - 4549 MM4550 - 4559 AR (2)4560 - 4565 SD (2)4566 - 4569 SB (2)4600 - 4619 OS4620 - 4639 EC4640 - 4649 PA6380 - 6399 XJ (2)6900 - 6909 RS (3)6910 - 6919 OC

4) REPORT DEFINITIONS (7nnn)7000 - 7009 RS (1)7010 - 7022 FP7023 XI (1)7024 XO7025 - 7029 OE (1)7030 - 7049 OM7050 - 7069 AM7070 - 7089 IN7090 - 7099 SI7120 - 7129 SA7130 - 7139 RS (2)7140 - 7149 FI7150 - 7169 AR (1)7170 - 7179 OE (2)7180 - 7184 MA7185 - 7189 KA7190 - 7199 CA7200 - 7209 WH7210 - 7219 DS7220 - 7229 XA7230 - 7249 CB7250 - 7259 SB7260 - 7269 CF7270 - 7289 CS7290 - 7299 MM7300 - 7319 OS7320 - 7329 EC7351 - 7359 XI (2)7360 - 7369 XP7370 - 7389 AR (2)7390 - 7399 XJ & XR


Message Member


Message Member - MIC No. 0002

G 1 12 BASIS I Modification Level

IDENT1 A 1 10 Identifier '++BASISMSG' (= nameof message member)

MODLEVEL1 N 11 2 Modification level (00,02,...)

13 8 free

G 21 15 BASIS II Modification Level

MODLEVEL2 N 21 2 Modification level (00,02,...)

23 4 free

IDENT2 A 27 9 Identifier 'MODLEVMSG'

System Identification

SYSIDENT A 36 1 'b' = S/36'1' = S/34'2' = AS/400

HISTORY A 37 1 'b' = History file (XJ03) is updated

'1' = History file is not updated

38 3 free

TEXT A 41 35 User text - optional Standard English text is: *** BASIS MESSAGE MEMBER ***

LIBRARY STANDARDS


Message Member - Mic No.0003

G 1 6 Company/location File Group/Location Code

COMPANYFG A 1 2 Company File GroupContents should be blank.Company file group is no longersupported and should not be used.

LOCATIONFG A 3 2 Location File GroupGroup characters can consist ofany characters allowed in filesnames (the first character shouldnot be a special character or anumber)

LOCATIONCD A 5 2 Location Code (e.g.: 01, AB, etc.)

G 7 50 AS/400 - as of Release 40

FILLIB 7 10 File library for native data base files(BASDB)- used in FP and OM (S/36) modeto access native data base files

LIBDDS 17 10 Library for DDS sources and forField Reference File (BASDDS)

FILLIB36 27 10 File library for S/36 files and XI01(QS36F)

LANGLIB 37 10 Language library for BASIS Mes-sage file (BASLANG)

MSGF 47 10 BASIS Message File Name(BASMSG)

TEXT A 57 20 User text - optional(e.g.: location decription)


Message Member



G 1 2 Administration / Distribution

ADMGRPLBL A 1 2 Used in complex SDC080 toprepare SD files for RS42

A 3 74 User text - optional


G 1 8 Multiple Application

MUAPLIB A 1 8 MUAP library

A 9 68 User text - optional

NOTEThis library is also used by otherBASIS applications to store proce-dures that are created during runtime, for example, CF and XJ(automatic safety copies).


G 1 18 SAVDAT (Internal BASIS DataParameters)

SAVLIB A 1 8 SAVDAT Library

SAVGRP A 9 2 SAVDAT Group (01 - 99)

SAVUSR A 11 8 SAVDAT User (for CL messages)

SAVAST A 19 8 SAVDAT assistant (used for CLmessages)

SAVDAYINC A 27 1 libraries to use for daily incrementalsaves (libraries only)b = use normal SAVE library1 = use incremental library


LIBRARY STANDARDS


*SAVHST A 28 1 Save changed object historyparameterb = objects are saved every day to

an incremental library1 = objects are saved to an

incremental library only on theday they were changed


G 1 16 BASIS Data Dictionary & QueryLibrary

BASDATDIC 1 8 Data Dictionary Name

BASQRYLIB 9 18 Query Library Name

17 60 User Text

NOTE:The Release 40 BASIS DataDictinary is called 'BASNDIC'. Thisname can be changed by the user.

The Release 40 BASIS QueryLibrary is called 'BASNQRY'. Thisname can be changed by the user.

The BASIS Data Dictionary andQuery Library prior to Release 40are called 'BASISDIC' and'BASISQRY'. These names shouldnot be changed.

Message Member



G 1 76 BASIS to ROSS Linkage

ENTRY A 1 8 File label for FI link to ROSSInventory

MARSC A 9 8 File label for FI link to ROSSInventory (physical count)

OECOM A 17 8 File label for SA link to ROSSInventory


G 1 76 BASIS to ROSS Linkage

A 1 8 File label for SA-finance link

A 9 8 File label for SA-statistical link

A 17 8 File label for SA-operational link

A 25 8 File label for SA-gallon conversion

Note:Do not use c.GL99X or GL99TR asfile labels. These file labels arealready used by BASIS (as internalworkfile) and by ROSS/GL.

Message Member - Mic No.0101 - 2999

CLMESSAGE 1 75 Message Text(Standard English texts provided byVienna, can be translated into locallanguage via SEU.)

LIBRARY STANDARDS


Message Member - Mic No. 3nnn

G 1 30 File Description

FILENAME A 1 6 File name aann

7 1 free

FILETEXT A 8 22 Descriptive textFILLER2 30 1

G 31 10 File attributes used in CL

SIZE A 31 5 Number of BLOCKS to be substi-tuted in OCL for output file ( man-datory left adjusted, e.g. '20')

EXTEND N 36 4 BLOCKS value substituted in OCLfor automatic EXTEND of updatefiles (mandatory, left adjusted)

ONLINE A 40 1 ON-line indicatorblank = file is on-line permanently'1' = file must be restored fromdiskette (BEFORE USING IT)

41 15 free

56 20 Back-up information (optional)

SLOTNO A 56 5 Slot number of the diskette to holdthe safety copy e.g. M1.05 means5th diskette in magazine 1 (blank =operator must insert requireddiskette in S1).

VOLUMEID A 61 6 Volume-ID of the diskette

GENERATION N 67 2 Number of generations

69 6 free

FILETYPE A 75 1 File TypeC ... Company FileL ... Location File

Message Member


Message Member - Mic no. 4nnn-6nnn

G 1 15 Job Identification

MENUITEM A 1 8 Menu item aaMnnnii (ii = item no.1-24)

EXTYPE A 9 1 Execution Type'J' = Job queue'j' = Always runs in job queue'E'= Evoked'e' = Always runs evoked'B'= Interactive'0' = Always runs interactiveThe execution type values applymainly to pre-native applications.Users cannot override the code fora job defined to "always" execute acertain way.

COMPLEXNO N 10 2 Complex number (01-99) used forVERSIONNO A 12 2 Version number (01-99, blank)XOPRIORITY 14 1 Priority Code

(1 = high, = normal), can only beused if Execution Type is "Interac-tive''.

A 15 1 MUAP processing code(X = job is not allowed in MUAP)

G OCL Specifications

CLPROC A 16 6 OCL procedure name aaCnnn tobe executed

A 22 1 Reserved—do not use

CLPARAM A 23 38 OCL parameters(as entered in S/36 mode. Nopadded blanks between parametersand separated by commas (,), e.g.LIST,A,,,100

JOBQSUF A 61 2 BASIS jobqueue suffix

TEXTMIC N 63 4 MIC no. of related complex descrip-tion (0101 - 2999)

LIBRARY STANDARDS


SAVEMIC1 N 67 4 MIC no. of safety copy beforecomplex

SAVEMIC2 N 71 4 MIC no. of safety copy after com-plex

1 75 Contains the parameters to besubstituted into the PRINTERstatement assigned to print pro-grams.

All the OCL statements contain thefollowing:

PRINTERNAME- aaPnnn?M7nnn?

In the MIC the additonal param-eters for controling the SPOOL aregiven, e.g., FORMSNO-nnn,ALIGN-YES,... (for details see theSSP manual).

In case no special parameters arerequired, the corresponding MICnumber has to be allocated, butcan be left blank.

Message Member - Mic No.9500 - 9998

G MEDMSGREC A 1 75 Media Message Record(MIC 9500 and specially definedMedia Records, see MEDMICbelow)

VOLID A 1 6 Media Volume ID

A 7 2 free

SAVMEDSGL A 9 5 Save Media for Single Complex

SAVMEDMUAP A 14 5 Save Media for MUAP Complex

MSGCOB A 19 1 'C' Save message is sent to Con-sole' ' No message is sent

Message Member


Message Member - Mic No.9500 - 9998(Cont.)

MSG A 20 40 Message to be displayed beforesave

ENDTAP A 60 6 End of TAPE Option'LEAVE ''REWIND''UNLOAD'

A 66 6 free

MEDMIC A 72 4 Media MIC NumberThe presence of a MIC number inthis position indicates that thisrecord is a Media Message Record- the number in this position mustmatch the record's MIC number.

G SAVCPYDEF A 1 75 Safety Copy Definitions

RETDAY A 1 3 Retention days(000 - 999)

FLELBL A 4 2 File label for online safety copies

SUFLBL A 6 1 Suffix for online safety copies

SAVDEF A 7 4*16 Safety Copy DefinitionsFile Type (Label):'L.' Location file'C.' Company file

Suffix Type:'DD' Day'MM' Month'YY' Year'JJ' Job number'US' User ID'WS' Workstation ID'FF' Currently not supported by

BASIS applications'NN' Currently not supported by

BASIS applications

Sales Data Base (YPNN):'Y' Period year'P' Period type'NN' Period number

LIBRARY STANDARDS


Message Member - Mic No.9500 - 9998(Cont.)

Job Execution Type:'00' Normal jobs'--' All MUAP jobs'01-99' Specific MUAP job

Save Type:'1' Direct to media'2' Online save'3' Online and save file group'4' Save at end of MUAP job

Saved File Deletion'' No files are deleted'1' Files are deleted when saved'E' Files are deleted at end of

MUAP job

NXTREC A 71 4 Next(continuation) Safety CopyDefinition record

A 75 1 free

NOTE:The 16th element of the SafetyCopy Definitions field can alsocontain a pointer to a Media Mes-sage Records definition. The MICnumber stored in this elementoverwrites the default record 9500.Only the first Safety Copy Definitionrecord of a group is accessed forthis override. If the 16th element ofanother record also contains a MICnumber the element is ignored.


G A 1 75 Reserved for XJ, used by Auto-matic Safety Copies Complex,must be present and blank.

Message Member


4.4.3 Maintenance

The BASISMSG message file is used as a central place to store all CL optionsrequired to run the system. This simplifies maintenance, especially when the BASISsystem is being installed. An XIMnnn menu offers all the maintenance and printfacilities needed by the responsible person (for example, EDP manager or systemoperator).

The development group will supply a 'standard' message member on diskette atthe time of initial implementation. The user should update or translate this messagemember carefully, paying heed, for example, to file sizes. Aternatively, themessage member can be copied from a neighboring bottler.

When a new application is implemented, the appropirate 'standard' messagerecords are also supplied on diskette from Vienna. The user has a special utility tomerge them into the existing BASISMSG member and update or translate themaccordingly.

Any updates to existing message records will be reported to the users on specialforms (included in the program distribution). The actual update must be donerecord by record by the user (via SEU). This is preferrable to an automatic replacebecause this would destroy previous updates which the user has made.

CL messages in the message member are not translatable with XP Patching.

LIBRARY STANDARDS



Message Member


Miscellaneous

4.5 Miscellaneous

4.5.1 Prompt Display

Use:

• For system functions, the prompt display can be useful to enter parameters.

• For applications, the XO run options will normally be preferred.

• The prompt display is generally used interactive jobs and is not allowed in the jobqueue.

Name:

• aaF000 for member except aa = XU (one member for all PROMPT formats ofan application), FMTnn (01-99) for individual formats.

• XUccccPR for member used in a utility, where cccc is taken from the maincomplex name (see 2.1.1)

Standards for Patching

• Standard format FMT01 with modification level is needed but is neverdisplayed.

• Patchable text must not exceed 80 characters.

• Text which is not to be translated must be furnished with 'Y' or 'N' in Non-Display column pos. 43-44 (for example default values)

Layout:

• Input fields on the left side down the screen (starting in position 4)

• Input fields with column separator at exact length (for example, only 2 slotsfor a 2 byte field).

• Headings in line 3 (application name and appropriate text, screen numberand processing mode) and line 4 (if needed)

LIBRARY STANDARDS


• Explanatory text on the right side down the screen (starting in position 14).

• CMD key description in line 22 (if applicable)

• Error message in line 24.

Error Message:

A standard SWITCH 8 is used to control display of an error message "INVALIDOR MISSING PARAMETER". Switch 8 is converted to indicator 98 to be usedinternally for displays of error message.

Screen Number (aaSnn)

The range between 80 and 99 is used. It is displayed in line 3, pos. 64-68.

Command and Function Keys

• Return code ?CD? can be used to test for command or function keys

• Command-7 is used to return to the menu

• The roll up/down key may be useful if several screens are necessary.

Message Member


1

2

4

3

1) HEADINGS WITH SCREEN NUMBER2) PARAMETERS PLUS EXPLANATION3) COMMAND OR FUNCTION KEY DESCRIPTION4) ERROR MESSAGE (one general message for all input fields)

Miscellaneous


BASIS

P A T C H I N G

TRANSFER TRANSLATED BACK TO SOURCE MEMBER XPS80

|p| ENTER MEMBER TYPE C ....MESSAGE MEMBER

F ....SCREEN FORMAT

M ....MENU

|x|p|p|0|2|4|| ENTER MEMEBER NAME

INVALID OR NO PARAMETERS ENTERED

CMD 7 - CANCEL JOB

LIBRARY STANDARDS



Development Steps


Application DevelopmentStandards55.1 Development Steps 5-3

Project Definition - Broad Design 5-3SIGN-OFF by the Senior Management 5-3Research - Requirement Collection 5-3System Concept 5-4System Concept Review 5-4Technical Detail Design 5-5Programming 5-6Documentation 5-6System Test 5-7Pilot Installation 5-8Acceptance Test 5-9Distribution 5-10Evaluation 5-10Maintenance and Enhancements 5-11

5.2 Application Documentation (Top Down) 5-15


APPLICATION DEVELOPMENTSTANDARDS


Development Steps


5.1 Development Steps

5.1.1 Project Definition - Broad Design

The project definition is prepared under the supervision of the DevelopmentManager.

It contains:

• brief description including:the purpose of the application,the benefits for the users,the benefits for the Coca-Cola Company andthe definition of the intended audience

• list of functions divided into:business functions supported andtechnical functions and highlights

• integration of the application to the business practices and to thealready existing BASIS applications

• expected utilization and given priority(if necessary by country)

• estimated development budget including:the estimated hours by development step,required human resources by qualification,required and earliest possible deadlines

5.1.2 SIGN-OFF by the Senior Management

(Sign-off step 1)

5.1.3 Research - Requirement Collection

The Project Manager and his senior manager are responsible for this developmentstep.



The step starts with the actualization of the Field Requirements based on the latestprintout of the Requirements Data Base.

The analysis and evaluation of the requirements is accomplished according to thecurrent and future business situations. The evaluation is supported by surveys thruMIS channels and on-site evaluations.

5.1.4 System Concept

The system concept is prepared by the Project Manager with assistance of othermembers of the development team.

It consists of:

• Revision and itemization of the brief description of the Broad Design,• Description of functions supported including:

- functions covered and how they are supported- special problems and solutions- special end-user features

• Data flow also showing the integration and interfaces• Description of complexes and menu items• Major functions by program• Prototypes and sequence of screens and reports with correct and realistic

data (in English language—no live data from users)• Definition and description of system and user options• Concept of major files - data bases• Definition of support utilities• Description of access security concept• Concepts for restart, reruns and safety copies• Hardware considerations• List of Field Change Requests included as an attachment

5.1.5 System Concept Review

Before distribution the system concept is internally reviewed by the CCCSmanagement.

(Sign-off step 2)

Development Steps


The system concept is distributed to the MIS Managers of the Coca-Cola Companyand to the selected key users. The review and feedback is requested from the fieldwithin a specified period of time, which has to be considered in the projectplanning.

The answers from the field are discussed and reviewed with the responsiblecustomer services manager and senior development management. Changes to thesystem concept are considered, if necessary and useful.

The Final System Concept is created after review and sign-off by CCCSManagement.

The Project Plan is completed with

• Task details• Dependencies• Assignment of resources

The final System Concept is distributed to the field.

(Sign-off step 3)

5.1.6 Technical Detail Design

Implemented by the Project Manager and the assigned senior programmer.Detailed design of data flow and program complexes is completed underconsideration of:

• Menu items• Complexes• Restart and repetition runs• Safety copy concept• Use of BASIS tools (XL...)• Procedures (OCL, CL)• Design of queries and SQL• Use of existing modules and frames• Consideration of BASIS standards

Single program descriptions including test instructions are created according tostandards described in the T3 - logic manuals.



Following items have to be considered:

• Detailed description of functions and technical solutions• Creation of file layouts (B6, B7)• Description of terms and codes (B3, B2)• Auditing considerations

- audit trails- cross check totals

• Creation of internal documentation

The basic documentation material has to be created, discussed and passed over tothe documentation department. A report 'Deviations from System Concept'including reasons and explanations has to be prepared. Review (Sign off) of detaildesign and deviations from system concept by senior development management.

(Sign-off step 4)

5.1.7 Programming

Programs are created according to description and consideration of standards asdescribed in BASIS T3 (Programming Standards).

1. Creation of program concept (including hierarchy chart of main functions)2. Sign off by Project Manager (Sign-off step 5)3. Creation of all related members like formats with help texts, Data Dictionary,

message member, copy modules of file descriptions4. Programming of single modules and tests5. Creation and test of procedures, complexes and menus6. Documentation according to T3 - internal technical documentation7. Final single program test including patching8. Creation of submission forms

5.1.8 Documentation

All external documentation (B manuals and Application Manuals) are produced andedited by the Documentation department according to standards described in T3.Documentation starts in parallel to Step 6 (Technical Detail Design) and has to be

Development Steps


completed (draft version) for system test. The final version has to be submittedtogether with all application members to the acceptance test. Documentation isdistributed to the field in coordination with program/release distribution.

The Project Manager is responsible for:

• coordination of deadlines• submission of necessary information to the Documentation Department• providing ongoing support and documentation enhancements according to

development status• contents and accuracy• approval of final application manuals

The application manuals are a substantial part of the final product and thereforeimportant aspect of system test and acceptance test.

5.1.9 System Test

System test is conducted by Project Manager and executed by the whole projectteam.

Following items have to be considered while preparing test data:

• selection of representative data from bottling plants• completion of a small data base containing single transactions to be

especially tested• creation of system test check lists

The execution of the System Test requires following:

• test according to BASIS Standard Check List (T3...)• test of special technical cases (file handling, filed or table sizes)• test of business functions according to application specific check lists• test of each single menu item under consideration of the user documentation• test of all restart, clean-up and cancel procedures• test of safety, security and audit features• test of installation procedures according to installation guide• test multiuser-terminal environment• test of multiple location data• test of performance



• test of integration to BASIS (relationship to other applications)• test of interfaces• check and recalculate all output (screens, reports, files - correctness and

completeness)• check results and supported functions against system concept• reconciliation of results on all supported hardware systems.

Final system test and sign-off by senior development management.

(Sign-off steps 6 and 7)

5.1.10 Pilot Installation

The pilot plant should be selected under consideration of

• Hardware requirements• Availabilities to run live and compare with old system

Data preparation for pilot installation involves:

• submission of a list containing the prerequisites• check for completion and CCCS management approval (Sign-off step 8)

The pilot installation is executed by the Project Manager and the programmer incharge of the application.

It includes:

• physical implementation of programs and other members• setting up together with local EDP Manager according to the Technical

Installation guide• parallel test runs with live data• education of local EDP staff and 'end users'• decision by local management to go 'live'. If live run must be postponed,

management in Vienna must be informed.• supervision of work of the local staff, explanation and reconciliation of results,

correction of errors, if necessary• check of all output (screens, reports, and files) for completeness and

correctness• correction of misleading or wrong documentation parts

Development Steps


After completion of all implementation work a final meeting with local responsiblemanagement and staff involved must be arranged. Open or remaining points haveto be discussed. Agreement has to be reached about further steps ofimplementation and organizational or programming work still to be done. Localmanagement should approve quality and agree continuing live run. Animplementation report has to be prepared by the responsible Project Manager.

(Sign-off step 9)

All members except objects are submitted to Quality Control and Distributiondepartment according to described standards.

5.1.11 Acceptance Test

The Acceptance Test is performed under consideration of the overall project planand the BASIS release planning. Before the start of the first phase of testing, thetest files and the list of functional and business test cases are actualized.

The execution of the Acceptance Test requires attention of:

• test according to list of BASIS standards (T3...)• test of special technical cases (file handling, filed or table sizes)• test of business functions according to application specific check lists• test of the correctness and usefullness of the documentation• test of each single menu item under consideration of the user documentation• test of all restart, clean-up and cancel procedures• test of safety, security and audit features• test of installation procedures according to installation guide• test multiuser-terminal environment• test of multiple location data• test of performance• test of integration to BASIS (relationship to other applications)• test of interfaces• check and recalculate all output (screens, reports, files - correctness and

completeness)• check results and supported functions against documentation• reconciliation of results on all supported hardware systems.

The list of test cases including the findings is discussed with the project managerafter the first phase of acceptance test.



(Sign-off step 10)

After correction of programs, a second Acceptance Test phase proves that thefindings where corrections were agreed have been corrected.

After completion of acceptance test, a final test report including all test casesperformed, the findings list and correction history is provided to seniormanagement. The project manager communicates any necessary changes to thedocumentation department.

(Sign-off step 11)

5.1.12 Distribution

Customer Services Managers and CCCS Senior Management approve thereadiness for general distribution under consideration of Quality Control results andresults from Pilot Implementation.

(Sign-off step 12)

General distribution is performed according to distribution list.

5.1.13 Evaluation

During the evaluation phase (approximately 3 to 6 months after generaldistribution) the Project Manager who did the development is still responsible forenhancements and corrections.

If desired by Senior Management, the Development Team may perform andsupport several additional pilot implementations. The application is handed over tothe designated maintenance person or group after approval by the DevelopmentManager.

Development Steps


5.1.14 Maintenance and Enhancements

Major enhancement projects are managed like new development projects andrequire all development steps from 1 to 13.

Maintenance, enhancements and major revisions of applications are handled inreleases. A release is defined as one project and may consist of several tasks.Which field change requests (FCR's) have to be considered within a release isdecided by Customer Service Managers and the responsible managers ofApplication Services and New Development.

For urgent requests the Customer Service Manager can decide to arrange aspecial program distribution. All special program distributions are to be included inthe next release.

Sequence for normal FCR's

Duties of Customer Service Managers:

1. Evaluation of FCR's• checking of attachments for completeness• rejection of the request, if

- attachments are insufficient- error cannot be verified- request has already been completed

• reconstruction of the error situation• assignment of a priority• commenting on the request

- which program, complex and application involved- description of the situation- related requests

• entry of the request to the FCR data base with special attention to- priority- type of requirement (for example, error, business requirement)- comments

2. Submission of the FCR to the Maintenance Group• copy of the FCR• original attachments• additional attachments from the reconstruction tests



• discussion with the responsible Project Manager about- priorities- desired completion dates- planned release

Duties of the Maintenance Group

1. Evaluation of FCR's• checking of attachments for completeness• resubmissionof request to customer service, if

- attachments are insufficient- error cannot be verified- request has already been completed

2. Scheduling of the request• 'filing' of less urgent requests• estimation of required man hours• assigning of accepted requests to tasks

3. Completion of request is performed within the task

Sequence for urgent FCR's

Duties of Customer Service Managers:

1. Hot-line support• evaluation of the situation• finding solutions to overcome the problem temporarily• getting information on

- which complex, program- special situations (restart, period-end processing, new programs, and so on)- contents of files- sequence of events leading to the error

2. Alerting of the Maintenance Group

3. Permanent customer information about the status of the correction

Development Steps


Duties of the Maintenance Group:

1. Immediate correction of the request (non-task related)2. Individual system test after completion3. Informing of the Customer Service Manager upon completion4. Submission / special distribution of the program (if necessary and justifiable to all

MIS departments)5. Integration of the member to the next release

5.1.15 Administration of Program Library

According to the corresponding chapter in T3.



SIGN-OFF CHART FOR MAJOR BASIS II PROJECTS

Project: Project Manager:

Planned completion date: Supervising Mgr.:

SIGN-OFF STEP Supervising Manager Senior Manager RemarksDate Signature Date Signature

1. Project Definition

2. System Concept Internal Review (Ahead of Distribution)

3. System Concept Review Final Version (after field review)

4. Technical Detail Design - All program descript. - Deviations Reports

5. Program Concept (of all programs incl.)

Project. Mgr.

6. Final System Test

7. Documentation Completness of internal and external Manuals

8. Pilot Implementation (Preparation of Data and personell) Project Mgr.

9. Completion of Pilot Implementation and Submission of programs

10. Acceptance Test Phase 1 ( List of findings )

Mgr. Quality Control

11. Acceptance Test Final test and approval (Applic.incl.Document.) Mgr. Quality Control

12. Ready for General Distribution

All steps habe to be completed according to standards described in BASIS II Documentation T3.Additional remarks or reports (Deviation Reports) are attached

Development Steps


5.2 Application Documentation (Top Down)

MILESTONES

REQUIRE- BROAD DETAILED TECH. PRO SYSTEM ACCEPT

MANUAL/CHAPTER MENTS DESIGN DESIGN SPECS. GRAMMING TEST TEST

B2 BUSINESS APPROACHES X

B3 TERMS AND CODES X

aa REFERENCE MANUAL

aa/ 1. Description X2. Activities X3. Workstation User Guide X4. Implementation X5. Error Messages X

B6 FILE LAYOUTS X

Taa TECHNICAL MANUAL

Taa/1. Technical Description X2. Menu Specifications X3. Complex Specifications X4. Program Specifications X5. Screen Layouts Samples in X6. Report Layouts aa/1, aa/2 X

LaaPROGRAM LOGIC MANUAL

Laa/1. General X2. Hierarchy X3. Key Modules X4. Structograms

PROGRAM LISTING X

SYSTEM TEST CHECK-LIST X

ACCEPTANCE TEST CHECK-LIST X

ANALYST

PROGRAMMING

MANAGER/LEAD

PROGRAMMER

TEST

GROUP

Application Documentation(Top Down)




Project Monitor


Project Monitorand Planning66.1 Project Monitor 6-3

PM Software Package 6-3PM Procedure 6-3PM Code Structure 6-5List of Personnel Numbers 6-6PM Reports and Options 6-6

6.2 Planning 6-8Preparation of Long Range Plan 6-8Application Development Check List 6-9


PROJECT MONITORAND PLANNING


Project Monitor


6.1 Project Monitor

6.1.1 PM Software Package

The planning and control fo BASIS is centered on Project Monitor. Project Monitor(PM) is a software package developed by EDP Design Consultants Inc. St. Louisand marketed by Program Products Inc.

There are approximately 100 installations of Project Monitor, mainly on largerequipment; the package was converted to IBM System/34 in 1979 and is written inCOBOL.

The purchase price includes source programs and documentation comprising:

Introduction GuideUser Reference GuideInstallation and Operations GuideSystem Documentation Guide.

Menu and DFU data entry programs are provided.

In case of further interest, please contact Corporate Information Services, Atlantawho have negotiated a central contract at favorable terms. The price isapproximately 8,300.

6.1.2 PM Procedure

Project Monitor is administered by the Coordinator. The weekly running of thesystem is handled by the Librarian. Managers are responsible for keeping theCoordinator informed of additions and revisions needed to keep the planningreports accurate and up-to-date. The operation of PM is documented in the UserReference Manual; each Manager has a copy available for reference. Tosummarize, there are two groups of input:



Use as needed: Defines

System Form Installation options (also see com pile options inInstal. Guide)

Report Form Selection of Reports, and their options

Employee Form Addition of employees, revisions and deletions

Weekly Usage:

Project Form Addition of Project Tasks, revisions and deletions

Assignment Assignment of employees to planned Project Tasks

Turnaround Time Document

The initial input to PM is the Long Range Plan. (For preparation, see 6.2.1). Majorrevisions to the Long Range Plan will normally coincide with the end of eachquarter, and preparation of the Quarterly Report.

A major revision is:

• a material change to the planned hours needed for completion• a material change in the completion of a Phase (group of related System

Functions and Applications) and must be authorized by the Project Manager.

An important system option is the number of man-hours available weekly which isused for scheduling employees' time against planned work. The normal number ofworking hours per week is 40, but other activities such as training, legal holidaysand vacation must be deducted. Therefore a net figure of 32 hours per week isused, averaging these other activities over the year.

Two important reconciliations must be made weekly.

1. The total planned hours in PM agree with the current Long Range Plan

2. The total actual hours reported in PM agree with the manual control system (lasttotal + total hours this week = new total)

Project Monitor


6.1.3 PM Code Structure

A feature of PM is that detailed project tasks can be summarized in higher levels asdefined by the user. There are 8 levels available; certain reports can be obtained ateach level.

BASIS currently uses levels 1-4, i.e.

Levels 1 2 3 4

Development Application Milestone Specific Task

B,T Manuals Specific Specific TaskManual

SystemFunctions Function Specific Task

Other Year Group Specific TaskActivities

Project tasks are planned and reported at level 4. Levels 1-3 are used tosummarize the information.

Because project ID's are created for specific tasks as they occur, the reader shouldobtain a copy of the Project Master List for a full list of current codes. At the planningstage, the specific tasks may not be known, for example, programming. In this case,a Project Task for Programming is included and time transferred from this reserve tospecific tasks as they become known, that is,

OMP Programming EST 1000 HOURSREV 840 HOURS

OMP100 Header Program EST 160 HOURSTOTAL 1000 HOURS

In this way, the total Long Range Plan remains unchanged.



6.1.4 List of Personnel Numbers

(Not applicable).

6.1.5 PM Reports and Options

See next page for a list of project monitor reports and options.

Project Monitor


PR

OJE

CT

MO

NIT

OR

RE

PO

RT

S A

ND

OP

TIO

NS

OP

TIO

NS

AV

AIL

AB

LE

FO

R R

EF

ER

EN

CE

No

.D

ES

CR

IPT

ION

Fre

q.

Tim

eP

rin

tP

rin

t

Ne

wN

o.

Ma

ste

r H

S,

JHG

AG

rou

p

Em

plo

yee

Un

its

As

sig

n-

Le

ve

ls

Pa

ge

Co

pie

sL

ea

de

rm

en

tsL

ev

els

WE

EK

LY Man

ual

Con

trol

She

et H

ours

W

-

--

-1

1C

ontr

ol o

f H

ours

Edi

t Li

st o

f In

put

W

11

Aud

it T

rail

01

Em

ploy

ee M

aste

r Li

st

WN

AN

AN

AN

A1

1C

F A

dmin

istr

atio

n0

3E

mp.

Tur

n A

roun

d T

ime

Doc

.

WN

AN

AN

AN

A1

1S

peci

al R

un0

8P

roje

ct D

etai

l Rep

ort

Con

trol

of

Hou

rs/

Leve

l 4

W H

OU

RS

NO

YE

S1

11

Ad

min

.3

2P

roje

ct D

ue in

1 W

eek

W

HO

UR

SN

AN

A0

11

EV

ER

Y 2

WE

EK

S

02

Em

ploy

ee T

ime

Ana

lysi

s

2W H

OU

RS

NA

NA

NA

31

1X

1O

ne S

heet

per

08

Pro

j. D

et.

Rep

. Le

v. 4

2W

HO

UR

SN

AY

ES

11

11

Pe

rso

n3

9E

mpl

oyee

Sch

edul

e

2WN

AY

ES

NA

14

11

1X

1O

ne S

heet

per

Pe

rso

n4

3P

roje

ct S

ched

ule

2W

HO

UR

SY

ES

NA

16

11

13

ON

RE

QU

ES

T

04

Pro

ject

Mas

ter

List

13

Pro

ject

Sum

mar

y Li

st2

4P

roje

ct W

ork

Rem

aini

ng3

7E

mpl

oyee

Loa

ding

38

Pro

ject

Loa

ding

SU

MM

AR

Y

Eac

h E

mpl

oyee

Rec

eive

sW

eekl

y T

urn-

Aro

und

Tim

e S

heet

2 W

eekl

y E

mpl

oyee

Tim

e A

naly

sis

Em

ploy

ee S

ched

ule

Gro

up L

eade

r R

ecei

ves

2 W

eekl

y R

evie

w o

f A

bove

Rep

orts

Pro

ject

Sch

edul

e -

Leve

l 4

All

Rep

orts

Ava

ilabl

e on

Mas

ter

File


PROJECT MONITORAND PLANNING Planning

6.2 Planning

6.2.1 Preparation of Long Range Plan

1) Introduction

The total BASIS development is divided into phases. Each phase consists ofproject tasks classified either as System Functions or Business Applications. A longrange plan is prepared for each Phase. Progress is monitored against the LongRange Plan and reported to management quarterly. Minor revisions are madeweekly, depending on progress and do not materially affect the Long Range Plan.Normally quarterly, a review of the Long Range Plan (and minor revisons) versusprogress will be carried out to assess whether a major revison is required. Systemfunctions support technical procedures which apply throughout the entiredevelopment (the tools to build the car). Examples are language patching, optionhandling, programming modules that are generalized features serving all businessapplications.

2) Long Range Plan

The Long Range Plan is prepared for each phase of the project. For each projecttask, estimates are prepared for:

• sub-project tasks which are recognizable milestones against which progresscan be monitored

• the starting and ending dates for each sub-project task (milestone)

• the number of man-hours budgeted, based on planning standards. SeeParagraph 3.

The assignment of sub-project tasks can then be made to key staff andprogramming groups.

Development manpower hours available are calculated (development group) andreduced by other activities (training, vacation) to arrive at the total net man hoursavailable for development. The total net man-hours available are compared to the

Project Monitor


total planned hours of Project Tasks. This information is further broken down by keystaff and programming groups. This provides a first overview of the Long RangePlan: whether the plan is realistic, what safety margin is available and whether keypeople are overloaded. As a result, certain revisions may be needed. The plan isentered in PM to reveal scheduling problems. Further revisions may then berequired.

3) Planning Standards

As a rule, the lapsed time from start date to completion date is spread as far aspossible in the planning. The main reason for this decision is to provide sufficienttime for users to study the detailed design and provide their input beforeprogramming takes place. Another reason is that it provides more time for walk-throughs within the development group and with outside experts. The typicallapsed time is 15 months. A consequence is that two applications will be developedin parallel by an analyst and a programming group. Experience with BASIS Ishowed an average development time, per application, of 24 man months, typically6 people for 4 months. The time was divided as follows: 1/3 for analysis, 1/3 forprogramming and 1/3 for testing and implementation. Estimates in the Long RangePlan currently use these figures. An average application development check-listfollows under 6.2.2. It shows planned man-months, lapsed time and work to becompleted for each milestone. It also shows the planned work distribution toemployees included in the Long Range Plan.

6.2.2 Application Development Check List

(Not applicable).




File Name Prefix Assignment


InternalStandards77.1 File Name Prefix Assignment 7-3

INTERNAL STANDARDS



File Name Prefix Assignment


7.1 File Name Prefix Assignment

To avoid file conflicts while testing BASIS II programs on the S/36 the following filename prefixes have been assigned.

Function/Group Prefix

AS B, E, M, K(W. Maresch)

CS1 S(F. Sack)

CS2 F(M. Felsmann)

DS C(S. Messner)

D1 R(E. Lackermayer)

D2 G(T. Linnahovi)

EID A; W,X,Y,Z(E. Mullner) (for training)

IS1, IS2, IS3 U,V(R. EgermannP. KarasF. Hank)

M2 Q(H. Letz)

M3 P(H. Possl)

QC D,L(R. Friedl)

SS I,J(P. Jerabek)

INTERNAL STANDARDS



Standards for Query


Standardsfor Query8

STANDARDS FOR QUERY



Standards for Query


The file, format and field definitions for some AR and RS files are stored in theBASNDIC folder. For distribution of new or changed definitions a second folder,DISTrrDIC (rr=release level), is used. This contains ALL standard BASISdefinitions. The contents of this folder are copied into the BASNDIC folder, byhand, when the user receives the updates.

AR and RS expect to find IDDU definitions in BASNDIC folder or the folderspecified in the BASIS Message Member MIC No. 0007, positions 1-8. Linking toIDDU is done by the calling application procedure.

Query members are stored in a separate library called BASNQRY. For distributionof new or changed members a second library, DISTrrQRY (rr=release level), isused. This contains only new or changed members. The contents of this library arecopied into the BASNQRY library, by hand, when the user receives the updates.

BASIS applications expect the Queries to be in session's Library List, members donot have to be in BASNQRY. The Query library specified in the BASIS MessageMember MIC No. 0007, position 9-18, is no longer used.

NOTE

AT DISTRIBUTION TIME, THE USER IS FULLY RESPONSIBLE FORUPDATING THE:

• BASNDIC FOLDER• BASNQRY LIBRARY


STANDARDS FOR QUERY



Basis Manual

Documents

screen documentation

documentation conventions

accompanying documentation

documentation techniques

documentation structure

documentation hints

program error messages

program terminal error