Basis Manual

BASIS II
DEVELOPMENT STANDARDS
T3 Technical Guide
PTF 53.5
Coca-Cola Computer Service G.m.b.H.

Vienna, Austria
This publication could include technical inaccuracies or typographical errors. Information in this
document is subject to change without notice and does not represent a commitment on the part
of Coca-Cola Computer Service G.m.b.H. No part of this manual may be reproduced or
transmitted in any form or by any means, electronic, mechanical, or otherwise, including
photocopying and recording, for any purpose other than the user's personal use without the prior
written permission of Coca-Cola Computer Service G.m.b.H.
These materials are furnished upon the condition that the user assumes all risks and liabilities
arising out of the use, or reliance upon this documentation.
Neither The Coca-Cola Company nor Coca-Cola Computer Service G.m.b.H. warrants suitability
or favorable results, NOR SHALL THEY BE LIABLE OR RESPONSIBLE FOR ANY LOSS,
CLAIM, OR DAMAGE, DIRECT OR CONSEQUENTIAL, ARISING OUT OF THE USE, POSSESSION, OR RELIANCE UPON THE INFORMATION CONTAINED IN THIS PUBLICATION.
This document may contain examples of data used in daily business correspondence and
operations. In these examples, we use names of hypothetical businesses and persons. These
names are fictitious, and any similarity to names of actual businesses or persons is purely
coincidental.
If you have any comments about this document, complete the Documentation Feedback form
at the back of this manual and return it to Coca-Cola Computer Services.
THIS PROGRAM AND ACCOMPANYING DOCUMENTATION IS PROPRIETARY TO THE
COCA-COLA COMPANY. IT IS A VALUABLE TRADE SECRET AND IS TO BE KEPT
CONFIDENTIAL AND NOT TO BE USED WITHOUT THE PRIOR WRITTEN CONSENT OF
THE OWNER.
COPYRIGHT 1993, 1994, 1995, 1996, 2001, 2007. AN UNPUBLISHED WORK BY THE COCACOLA COMPANY. ALL RIGHTS RESERVED.
Software and Version:
T3 Development Standards Technical Guide

PTF 53.5
Contents
1 DOCUMENTATION STANDARDS
1.1
Documentation Structure 1-3

Overview 1-3
User System Manuals 1-5
User Application and System Function Manuals 1-7
Technical Manuals 1-11
Program Logic Manuals 1-14
Highlights and Workbooks 1-15
1.2
Page Numbering, Table of Contents, Standard Forms 1-17

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

Data Flow Diagrams 1-21
Control Flow Diagrams or Flowcharts 1-25
Decision Tables 1-27
Hierarchy Charts 1-28
Structograms (Nassi-Schneidermann Diagrams) 1-31
Documentation Hints 1-35
Documentation Conventions 1-37
2 DESIGN STANDARDS
2.1
Naming Conventions 2-3

Library Members 2-3
Files (Ranges, File Group, Suffix, Fieldnames) 2-7
Screen and Report Numbers 2-9
Query Members 2-9
PTF53.5 T3 DEVELOPMENT STANDARDS
ii
2.2
Program Error Messages 2-11

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

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

Report Documentation 2-73
Report Sizes 2-74
Report Layout 2-77
Field Definitions for Data Output 2-78
2.5
Disk File Standards 2-79

Disk File Layout 2-79
Common Record Structure 2-82
Multisegment Records 2-83
2.6
CL/Program Communication 2-85

Local Data Area (LDA) 2-85
2.7
Program Design 2-91
2.8
Module Design 2-93
3 COBOLPROGRAMMING STANDARDS
3.1
Objectives 3-3
3.2
Overview 3-5
General Remarks 3-5
Notation 3-5
3.3
Structured Programming 3-7

Standard Elements: 3-7
Coding the Standard Elements in COBOL 3-10
3.4
Naming Conventions for COBOL Programs 3-19

Paragraph Names 3-19
Special Names (Mnemonic Expressions) 3-23
File Description Entries (FD) 3-23
Working Storage Section 3-27
Standard Words and Prefixes 3-33
3.5
Standards for Patchable Constants 3-37

Common Constants 3-38
Program Constants 3-40
Program Error messages 3-48
3.6
Coding and Efficiency Techniques 3-51

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

Structure of Working Storage Section. 3-61
Structure of Procedure Division 3-63
COMMENTS 3-64
iii
3.8
Program Administration 3-67
3.9
Program Modules 3-69

"Dummy Parameters" 3-71
Administration Documentation and Comments 3-73
3.10 S/36 - S/38 Considerations 3-75

Programs 3-75
Screen Formats 3-79
4 LIBRARYSTANDARDS
iv
4.1
Introduction 4-3
Guidelines 4-3
Coordination and Scope 4-3
Modification Level 4-4
4.2
Menu Standards 4-7

Menu Types 4-7
Menu Design 4-10
Menu Documentation 4-13
4.3
CL Standards 4-15
CL Complexes 4-15
CL Program Procedures 4-21
CL Messages 4-23
CL-Standard Procedures 4-23
Defining of Printer Files in Procedures 4-35
4.4
Message Member 4-37

Concept 4-37
Structure of a Message Member 4-38
Maintenance 4-51
4.5
Miscellaneous 4-53
Prompt Display 4-53
5 APPLICATION DEVELOPMENT STANDARDS

5.1
Development Steps 5-3

Project Definition - Broad Design 5-3
SIGN-OFF by the Senior Management 5-3
Research - Requirement Collection 5-3
System Concept 5-4
System Concept Review 5-4
Technical Detail Design 5-5
Programming 5-6
Documentation 5-6
System Test 5-7
Pilot Installation 5-8
Acceptance Test 5-9
Distribution 5-10
Evaluation 5-10
Maintenance and Enhancements 5-11
5.2
Application Documentation (Top Down) 5-15
6 PROJECT MONITOR AND PLANNING

6.1
Project Monitor 6-3

PM Software Package 6-3
PM Procedure 6-3
PM Code Structure 6-5
List of Personnel Numbers 6-6
PM Reports and Options 6-6
6.2
Planning 6-11
Preparation of Long Range Plan 6-8
Application Development Check List 6-9
7 INTERNAL STANDARDS
7.1
File Name Prefix Assignment 7-3
8 STANDARDS FOR QUERY
This page intentionally left blank.
vi
Documentation Structure
Documentation
Standards
1.1
Documentation Structure 1-3

Overview 1-3
User System Manuals 1-5
User Application and System Function Manuals 1-7
Technical Manuals 1-11
Program Logic Manuals 1-14
Highlights and Workbooks 1-15
1.2
Page Numbering, Table of Contents, Standard Forms 1-17

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

Data Flow Diagrams 1-21
Control Flow Diagrams or Flowcharts 1-25
Decision Tables 1-27
Hierarchy Charts 1-28
Structograms (Nassi-Schneidermann Diagrams) 1-31
Documentation Hints 1-35
Documentation Conventions 1-37
1-1
DOCUMENTATION STANDARDS
1-2
1.1
1.1.1
Overview
1) "User" Manuals
a) Intended for the general user:
B2 Business & System Approaches
B3 Terms & Codes
B4 Operating Guide
aa
Application manuals: aa = SM for Settlement, OM for Outlet

Master, and so on. These manuals describe what the application does
and how to use it. They include also technical information such as how to
set up the application.
aaU Application manuals (User Guides): aaU = Order Entry User Guide,
Dispatching User Guide, and so on. These manuals describe what the
application does and how to use it. The technical information is included
in the corresponding Technical Guides.
b) Intended for the DP managers:
B6 S/36 File Layouts
B7 File Layouts for System Control file (XI01)
B8 iSeries File Layout
B9 eBASIS II Schemas
Xs 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
T4
T5
aaT
Developtment Standards
iSeries Devlopment Standards
Call Modules
Technical Guides: aaT = Order Entry Technical Guide, Dispatching
Technical Guide, and so on. These manuals describe technical information
such as how to set up the application.
1-3
Note:
Current codes for System Functions (Xs) are:

XA
Data Distribution
XC
Shareware Tools
XD
Program Distribution Control (installed applications, program

modification levels, and so on)
XF
Copy Modules File definitions (including S/38 DDS - standards)
XI
Installation Options and Parameters (data dictionary, code

interpretation, 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, business

modules, 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
1-4
Cross Application
1.1.2
User System Manuals
User system manuals include manuals which group user information related to the
BASIS 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 approaches
business issues such as pricing, promotions, taxes, advance selling, sales
organization, delivery frequencies, market segmentation, outlets and customers,
articles, empties and so on. It also includes general information on system
approaches 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 the
application 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 which
must be entered by the user in master files. It gives definitions plus type and length
if applicable, valid code values for certain codes (when assigned by BASIS
otherwise possibly a few suggested meanings). A few technical terms are also
included. 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 is
applicable:
1-5
FIELDNAME
N/5(1)
DATA STORED IN:
- - field no.
- - field no.
- - field no.
CODE DEFINED BY:
(2)
ALLOWED VALUES:
(3)
CODE LEVEL:
(4)
DESCRIPTION
= Field definition
N = 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.
= "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 field
characteristics, for example, field is N/1 but allowed are only 0 and 1.
= Only specified if "Location". The default value is 'Company'.
Common error messages (applicable for all applications)

Control language (CL) messages.
1-6
B6 - File and Data Component Layouts

Describes file structure (as required) and record layouts for application and system
function disk files (aann and Xsnn). It also includes layouts of data components
which 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 or
XS) in its key. It acts as a series of sub files. The application or system function
code (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 before
implementation. Gives an conceptual overview of major system and business
approaches.
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 to
sections of B2, B3, or other application manuals.
1.3
Hints how to begin
1-7
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 are
used.
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 are
used.
1.7
Calculation Rules
Formulars, description of complex calculation proceedings (Only if
applicable).
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
1-8
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 programs
per 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/6
manual
- Control Lists used (for example, PL05, OL03, SL08) and to which
objects they are assigned
- the maximum size allocated in the generic program for the internal
format
- the processing logic if necessary, for example, that only outlets are
processed which have an OM08 record
- overflow handling in case of multiple print lists used in a generic
program
- run options associated
- subtotal calculation by the program
- the contents of system field $$COMPLOC which are loaded by the
generic program
1-9
- the meaning of system and object conditions set by the generic program
in case the description in the external format of the control list is not
sufficient.
- 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. The
steps are furnished by a consecutive number allowing the user to skip or
repeat certain steps. For each screen only those explanations are given
which are related to the current activity. In case an activity is very similar to
another already explained step, there is no need to duplicate the whole
description.
3.5
Special Problem Situations

Problem situations, which may occur due to wrongly used fields or command
keys or other wrong performed steps are described with answers.
1 - 10
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. For
reports produced by 'Print Lists' the standard version is described. Free
space for user versions of reports should be available. All reports are
examples, reflecting real business situations. For error reports, the used error
messages from control file are listed.
3.8
Miscellaneous References
Definition of specific fields and transactions (for example, control totals, and
so on).
aa/4 SAFETY AND CONTROL

4.1
BASIS Standard Safety and Closing Procedures

Periodic and end-of-year closing options and procedures. Recommended
reorganization 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,
1 - 11
not for the user or the DP Manager. However they can be made available to these
people 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 and
programmers, covering topics such as patching, restart, and so on (that is, how to
program 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 for
maintaining 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 or
system 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
1 - 12
Taa/2 MENU SPECIFICATIONS

This section contains:
a menu reference list (name/description) in typed form
a computer print test of every display textand 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 which
functions are included. How a function is performed, however, is not
described. This is documented in the corresponding user guide. The program
description 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, done
manually.
1) Screen layouts are defined by the development group. Each screen number
aaSnn consists of one page and uses the screen layout form defined in chapter
2.3.
1 - 13
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, done
manually.
1) Report layouts can be defined by the development group. Each layout consists
of one page and uses the report layout form and conventions described in
chapter 2.4.
2) Reports can also be defined by the user by means of control lists (print list). No
special 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 form
only. The lead programmer/program analyst is responsible for updating the logic
manuals 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 intended
exclusively for development staff. All logic manuals of an application are part of the
T-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 about
modification level (for internal control), files used (organization, access mode,
records used), standard modules used, switches and LDA used, key arrays, CMDkeys used (screen programs only) formats used (screen programs only) patching
requirements (literal records used).
1 - 14
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.4
for symbols used.
3) Key modules
A narrative description of the key modules is given by the lead programmer (or
deputy) and will be more detailed in the analysis stage; a reduced version is kept
for actual documentation.
1.1.6
Highlights and Workbooks
The 'Highlights' brochures provide a short general introduction to each BASIS II

application, as well as practical examples and screens.
The 'workbooks' deal with specific topics and features of BASIS II. They provide a
detailed description, as well as many examples, making them a good tool during
daily work. The following workbooks exist:
Calling Schedules
Data Identifiers
Disk Space/Performance/Hardware/Training
Implementation Checklist
Linkage
Pricing Samples of BASIS forms
XL - Control Lists
1 - 15
1 - 16
1.2
Page Numbering, Table of Contents, Standard

Forms
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.6
2.6.1.
The number of positions in the section number has been chosen so that the
number of pages in each section is limited . This will allow easy location of a
section in a manual, or a topic or paragraph within the section in case of
references. Pages are printed front and back. This means that a section is printed
on about 4 sheets which are generally completely replaced when updated. This is
because a section represents a unit for the word processor. When paragraphs are
inserted or deleted, the word processor automatically repaginates the section and
renumbers the pages. When changes do not require repagination, single pairs of
corrected pages may be issued. This means that a minimum of two pages of a
section will always be issued, even if only one of them has been modified. Each
section starts on a new front page. Sub-sections can start within a page. Each
section 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. Subsections are not listed in the table of contents. It is identified as section 0, which
also includes the List of Pages of the manual. (See 1.2.5, Checking for
Completeness...)
1.2.3
Paragraphs
A section or sub-section may be further subdivided into paragraphs. These are

identified by a number or letter, followed by a closing bracket:
1 - 17
1) ...
a) ...
or by a heading (that is, a name) without a number. These non-numbered headings
should not be used for sections which are longer than 2 or 3 pages; otherwise it
would be too difficult to find the desired paragraph.
1.2.4
Standard Referencing
Example: see TRS, 2.6

see 2.6
see 2.6,
see 2.6,
(reference in another manual)

(reference within the same manual)
Par. 4
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 the

Documentation
Updated pages and new manuals are distributed with "Documentation

Newsletters", numbered sequentially. A complete list of pages of each modified or
new manual is included with the newsletter. This list of pages indicates the date
and newsletter number with which each page of the manual was last distributed
and can therefore be used to check whether documentation is complete and up to
date. For the pages being distributed an indication is given in the list of pages as to
whether 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 recipient
can 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 simple

structure, simple forms and so on.
Flowcharts and complex illustrations are drawn manually and inserted into
pre-programmed spaces in the text.
One level of indentation is followed. Text begins flush with the left margin and is
1 - 18
right justified. Heading levels are distinguished as in the following example:

1.
1.1
1.1.1
DOCUMENTATION
Overview
The following page format is followed for text:

margins:
tabs:
first typing line:
last typing line:
line spacing:
left 10, right 86

individually set
8
62
1
Prestige elite (12 pitch) type is used.

The heading on the standard forms begins on line 3, information being inserted in
the following positions:
Release number:
25
Date:
31
Newsletter number: 42
Manual:
48
Section:
61 (may be varied to suit length of information)
Page number:
85, flush with right margin
The 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. The
originals are then filed by the documentation department which photocopies them
and 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:
1 - 19
org.:
32
rec. length:
39
key length:
45
file and record name: 55 (approximately)
Text begins in
Field number:
Field name:
Type:
Position:
Length:
Description:
the following positions:

10
15, 19
34
40
47
53
Quarto (U.S. size) paper is used exclusively. Pages are distributed with three holes
to fit standard American binders. BASIS binders, labelled for the appropriate
manuals are distributed when necessary with the documentation.
1.2.7
Standard Forms
Examples of standard forms follow:

blank page
1 - 20
Page Numbering, Table of Contents,

Standard
Forms
Documentation
Structure
1.3
Documentation Techniques
1.3.1
Data Flow Diagrams
Data flow diagrams show how data flows from process to process. They show
where data comes from and where it goes, either to a data store (computer or
manual 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.
1 - 21
Symbols Used:
1) PROCESS
Process
Name
Computer Process
Process
Name
Clerical Process
2) FILES
File
name
or
or
File
name
or
File
Name
= Manual File
Computer File
Diskette File
or
Screen File
Report, Document
3) DATA FLOW
Data Flow
Data transport (for example diskette)
Data transmission
Name
4) INTERFACES
1 - 22
or
or
Name or Name
Name
5) OTHER
TEXT
- - - - Commentary
Example:
From:
ID
or to:
ID
(Off page) Connector
From:
ID
or to:
ID
(Same page) Connector
3
3
2
Page 1
Page 2
Controls
Data Controls (compare totals...) can also be shown on a data flow diagram. Symbol
used:
Example:
Control Chart
Date
Process x
Total
Cash
Total
Credit
..
Process y
Use
Data-flow diagrams are mainly in aa/2 (Functions) and aa/3 (Activities).
1 - 23
Example of a data flow diagram:

Warehouse
Cashier
Load/Unload
Load/Unload
Data
Salesman
Sales Slips
Cash Data
Additions on preextended invoices
Sales Data
Control Sheet
Group
per
Route
Data Entry
OM
AM
Delivery Route Data
OE
+
IN
Non-delivered invoices remain in file

Delivered
RS
1 - 24
1.3.2
Control Flow Diagrams or Flowcharts
Control flow diagrams or flowcharts show how control flows from program to program (within a
procedure). 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 Manuals
instead of program flowcharts.
Files, processing and input/output devices are shown on diagrams from left to right.
FILES
INPUT/OUTPUT
PROCESS
DEVICES
TEXT ON EXTERNAL
VARIABLES AND
DECISIONS
The text on external variables and decisions identifies the external variable and what information is
received 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.
Outlet Master
OM01
Parameter 3 - Type of List

LDA - Writes last outlet
OMP600
If the action is in CL, the text is shown in line with CL symbol.
LIST
End
Parameter 2 - List Requested
1 - 25
Program
Name or
Function
Program
or
Program Step
Example of a Procedure Flowchart
RSC015
Standard Module
or
Subroutine
RSP200
Condition
Test
NO
List
Tag
Parameter 3
- List Requested
YES
File
RSP205
File
Name(s)
Options
Screen
File
Name
Report
LDA - Writes
last outlet
RSP210
File
Name
Control Flow
From or To
RSS220
COPY
Off-Page Connector
From or To
END
On-Page Connector
FILES
Text
PROCESS
I/O DEVICES
TEXT
Commentary, for example

External Variables
Start and End
1 - 26
Documentation
Techniques
Documentation
Structure
1.3.3
Decision Tables
Decision tables show the static relationship between conditions and actions. They are sometimes
useful for investigating and documenting complex static relationships.
Table Format
Rules
1
CONDITIONS
Driver type
Note 1
Volume Total
Note 2
ACTIONS
Calculate
Commission
with rates =
Pay Overtime
Note 3
NOTE 1
D = DRIVER
A = ASSISTANT
NOTE 2
A = 0-200 CASES
B = 201-250 CASES
C = 251-300 CASES
D = OVER 300 CASES
NOTE 3
COMMISSION = VOLUME X RATE SHOWN BY 100 (RATES ARE SHOWN IN
PERCENTAGE)
1 - 27
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, system
functions, applications and programs. Following is an example of the hierarchy of an
inquiry program.
1 - 28
Documentation
Techniques
Documentation
Structure
Mainline
UNTIL CMD 7
1
Init
3
Read-WS
4
Write
Trans. File
Processing
Terminate
OFF
UPSI 0
ON
XMIO02
Read from
Job Control File
11
Load
Patch
Data
(Outl. No.)
(Roll)
(Initial Read)
(Else)
XM1O03
31
Y1
Load
Array
32
Prepare
1st Screen
Write Jobe
Control File
33
Prepare
prompt
outl.No.
ON
Error
OFF
UPSI 0
Y1
321
Load
Array
322
1 - 29
MAINLINE is the control module which delegates functions to lower levels; in

programming 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 the
hierarchy, each lower level becomes more and more detailed until no more
functions must be delegated (typically 4, 5 or 6 levels)
The level numbers uniquely identify a module's place within a program
hierarchy and are assigned serially; a new module which must be inserted
later gets the next free number (for example, 34 can be inserted between 31
and 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 from
different places; their prefixes start with a letter:
XMccnn. . .
standard COPY modules common to several programs,

cc= module class, nn= unique number for example, XMIO
2/ 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 (for
example, Y1 calls Y11, Y12 calls Y121, Y222 and so on
Znn . . .
all modules containing Input/Output Operations, with

nn=01-99 followed by the file name aann and code
operation (for example, Z0/1-OM1-READ, Z53-XI
1-WRITE)
Each module performs its own function and may delegate functions to lower
level modules. This delegation may be conditioned by one of the 3 symbols:
Repetitive execution of the lower level module(s) while or
until a condition is true; the condition test is done in the
higher level module.
(For example, 2/3/4 are performed by MAINLINE UNTIL
CMD Key 7 has been pressed).
Case structure, that is, only one of the lower level
1 - 30
modules is performed, depending on condition tests C1 ...

Cn; the condition tests are performed in the higher level
module.
(For example, one of the following: Y1/31/32/33, is
performed depending on the input received from
2-READ-WS).
Execution of the lower level module depends on a
condition C; the condition test is done in the higher level
module.
(for example, 11 is performed if
UPSI is ON or
321 is performed if
UPSI is ON-else
322 is performed).
1.3.5
Structograms (Nassi-Schneidermann Diagrams)
This documentation technique was specially designed to support "structured

programming". Structograms are preferrable to flowcharts because they offer no
symbol for "GO TO" and therefore do not permit a programmer to break the rules of
structured programming. The text below introduces structogram symbols. The
subject is discussed in more detail in 3.3, Structured Programming.
1) SEQUENCE
MOVE A TO B
Datacheck
SYNTAX CHECKING
Single step (on instruction level)
PERFORM another routine

(reference to another structogram)
1 - 31
2) IF-THEN-ELSE
AMOUNT
POSITIVE
N
Two-way branching based on
an IF-statement
Add Amount
to
Debit Total
Subtract Amount
from
Credit Total
LINE COUNTER =
PAGE SIZE
N
One-way branching. The box
under N (ELSE path) remains
empty.
Write Heading/
Advance Page
3) CASE
A
RECORD CODE
B
Address
Edit Name
& Address
for Printing
1 - 32
C
ELSE
Art.
Total
Accumulate
Article
Quantities
Calculate
Tax and
Prepare
Total Line
Multiple branching based

on the value of a
variable. (An ELSE path
should always exist to
provide for error
checking.)
Display
Error
Message
4) DOWHILE
Index
100
WHILE condition (continue if true)
Move fields from array (ind.) to print

record
Write print line from print record
Iteration body
Add amount (ind.) to total
5) DOUNTIL
Stays empty
Read WS
Read from Workstation
I1
CMD-7
Process
UNTILcondition (discontinue if true)
Process Workstation
Read
I2
Write Transaction File
I3
SEVERE ERROR
Write Trans.
Note: I1 + I2 + I3 = Iteration body
1 - 33
6) DECISION TABLES
If a route consists of a heavy load of IF's and ELSE's, it may be desirable to group the
decisions and actions into a table and put the table into a box, for example,
ACTIONS
CONDITIONS
CASE
CASH CUSTOMER
ELIGIBLE FOR PROMOTIONS
TAX EXEMPT
EXTEND ARTICLES
COMPUTE PROMOTION
COMPUTE TAX
X
X
Y = Condition TRUE
N = Condition FALSE
- = Condition may be true or fals
X = To be executed
b = 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 structograms
before coding begins. They are finalized for the Program Logic manuals only
after the system test.
One structogram exists for every performable routine. It normally combines
several elements into logical or functional unit.
Comments may be put in brackets:
TAX
(Calculate tax, tax rate
from tax table using tax
class and art. tax code as
indices.)
1 - 34
1.3.6
Documentation Hints
Good documentation is a difficult job. Each author has his own style. It should be as
short 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 to
maintain a high standard of documentation and, at the same time, support our
development procedures.
Similar manual presentation
For the user each manual should have the same structure, it should have the same
style, it should help him find information quickly.
Reduction of documentation
A major criticism of BASIS I was the volume of documentation to study. Information
should be documented in one place and not repeated. Avoid repetition of B2-3. Avoid
documenting information that is 'padding', that is, it really brings the reader no new
information and could be omitted. It is no criticism that a section is small or even not
used, 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 and
1.1.4. In addition, make your own check list of topics that require explanation and
group them together in a logical reading sequence. This will help you avoid
duplication and omission.
When standard sections are not applicable, they will appear in the Table of Contents
with their section numbersbut with the title missing and N/A. These sections do not
appear in the text itself.
The names of standard sections can be modified or extended if this helps to make
them more meaningful.
Style
Use simple language. English is not the mother tongue of many of our users.
1 - 35
Keep sentences short (newspaper approach to make reading easy).

Keep subsections to a reasonable length. If these are too long, split the topic
into two or more sub-sections.
Remember the limitations of the word processor (see 1.2.6). It may not be
able to produce your documentation as you would like.
Try to keep your explanations simple. If they get too complex, you should stop
and consider another approach (maybe the business or technical solution is
not 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, the
screen will be used to guide the user department. An advantage will be that often
information on the sample screens will not have to be repeated in written
explanations, that is, rely on sample screen and sample reports.
Development milestones
It can happen during the various development milestones (R, B and so on) that
certain analysis or technical work is done in advance of the current milestone being
worked on.
In this case, it should be included in the correct section, and not in the current
documentation section; this will avoid duplication or later reclassification of the
section.
Use of sections (sub-sections)
A section heading at the top of the page appears in the Table of Contents. Subsections within a section do not appear in the Table of Contents.
Example:
4.6
4.6.1
4.6.2
1 - 36
CL Techniques
CL Technique Number One
Text
CL Technique Number Two
Text
When the writer finds that the sub-section is becoming too lengthy and should
appear in the Table of Contents, he should consider changing all the sub-sections
to sections.
Example:
4.6.
4.6
4.6.1
(4.6.2
changed to section 4.6.1

CL Techniques
CL Techniques Number One
CL Techniques Number Two starts a new page)
Because section headings appear in the Table of Contents, section headings

should be meaningful to make this Table of Contents more useful. In the above
example, 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 when

BASIS I and BASIS II are specifically referred to or appear together (linkage
considerations).
The letter O and zero number 0 will be typed normally as in this sentence. In
handwritten text, whenever confusion is possible, the writer should use to
alert the documentation department that it is a zero and not the letter O, for
example, XMIO1.
Words will start with capital letters for:
Section Title,
Paragraphs
1.3.7, Documentation Conventions,

b) Screen Formats
Files
Abbreviations
System Control file

E.D.P., COBOL, CL, B1, T4, CMD, GA
Application,
System Function
Outlet Master, Restart
Manuals
B3, Terms and Codes
If doubt exists, the rule is to avoid capitals as far as possible, for example, it is not
necessary to use capitals for codes, for example, sales term 5, and so on.
1 - 37
Words will appear in capital letters for

Example
Main section title
For highlighting
1. DOCUMENTATION STANDARDS
Press ENTER key
Standard American spelling, vocabulary and style will be used throughout the
Documentation, the only exception being the internal date format (Year/
Month/Day) used in the headings and in sample reports and sample screens.
1 - 38
Screen Standards
Design
Standards
2.1

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

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

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

Report Documentation 2-73
Report Sizes 2-74
2-1
DESIGN STANDARDS
2-2
2.4
Report Standards, continued

Report Layout 2-77
Field Definitions for Data Output: 2-78
2.5
Disk File Standards 2-79

Disk File Layout 2-79
Common Record Structure 2-82
Multisegment Records 2-83
2.6
CL/Program Communication 2-85

Local Data Area (LDA) 2-85
2.7
Program Design 2-91
2.8
Module Design 2-93
Screen
Standards
Naming
Conventions
2.1
Naming Conventions
The naming conventions apply to applications (aa), system functions (Xs) and
cross application menus and complexes (XX). Fixed conventions appear in
capitals, for example, aaMnnn. Variable conventions appear in small letters and are
underlined if an explanation follows in the text, for example, aaMnnn. Not included
are code structures which are explained under the subject concerned, normally in
the B3 manual.
2.1.1
Library Members
An identical code structure has been applied to library members:

Menu
Complex (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
aaMnnn
Meaning
aa or Xs menus are described in the application or system
manual. Cross application menus with aa=XX are described
in 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)
2-3
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
aaCnnn
Meaning
S/34 OCL procedures or S/38 CL programs, except XU
complexes (utilities) and single program procedures
0nn
1nn
2nn
.
.
.
7nn
8nn
9nn
main complexes
level 1 complexes (or called from Onn complexes)
level 2 complexes (or called from 1nn complexes)
clean-up procedures (used for Restart)

Conversion/Linkage (for example, BASIS I - II)
local complexes
See 1.1.4 under Taa/3 for example of hierarchy diagram
with level complexes.
XUccccxx
XU complexes (utilities)
cccc
mnemonic name
xx
bb
= main complex
00-99 = sub complexes
2-4
Naming
Screen
Conventions
Standards
3) Programs (and Sorts)

Name
aaPnnn
Meaning
program source and load member, CL
procedure containing // LOAD, // FILE,
// RUN (single program procedure)
001
0nn
header program
stand alone auxiliary or inquiry program (in
gaps of 5 or 10)
group 1 of programs (in gaps of 10)
group 2 of programs (in gaps of 10)
1nn
2nn
.
.
7nn
8nn
9nn
generic programs
conversion/Linkages programs (e.g. BASIS I-II)
local programs
Sorts
Name
aaSnnn
Meaning
CL-sort procedure, nnn assigned in line with program name
aaPnnn, for example, OMS14O is executed between
programs OMP130 and OMP150.
4) Format Member (and Formats)

Name
aaFnnn
Meaning
Format Member for screen programs, with aa nnn
corresponding to screen programs
Format
Name
Meaning
FMTnn or
As defined by SFGR included in the format member aaFnnn

(see above).
2-5
DESIGN STANDARDS
FMTHLPnn
FMTnn
= data format name
FMTHLPnn = 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 // PROMPT
SEE 4.5.1.
5) Modules
Name
XMccnnd
Meaning
cc = classification for example
FR =
IO =
TP =
FP =
ER =
program frames
input/output modules
table processing
field processing
error handling
nn = 01 - 99 to identify a module within its class

d = 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)
2-6
Naming
Screen
Conventions
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 are
distinguished by the library type.
2.1.2
Files (Ranges, File Group, Suffix, Fieldnames)
Files
Name
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 the
B6 manual.
01-19
20-39
Master files, Control files

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, processing
history files, log files ...)
60-79
80-99
Work files (Scratch files, for example, sort work files, print files, ...)
Data components created and used by generic programs
2-7
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 ALL
VALUES 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 multiple
alternate 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 embedded

blanks, 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.
2-8
Naming
Conventions
Screen
Standards
2.1.3
Screen and Report Numbers
1) Screen Number
Name
aaSnn
Meaning
Each main screen in its normal sequence within an application is
identified by a screen number (gaps of 5 to allow new screens to
be inserted).
Used in aa/3, Activities (Workstation User Guide)
2) Reports
Name
aaPnnnc
Meaning
As printed on a report, corresponding to the name of program that
prints the report.
c...
Suffix, if one program produces more than one report
(c = A, B, C, ...).
2.1.4
Name
aaQnnn
Query Members
Meaning
aa ...... application
Q ...... fixed
nnn ...... 001 - 499 Development query members
500 - 999 User query members no other structure
2-9
DESIGN STANDARDS
2 - 10
Program
Screen
Error Standards
Messages
2.2
Program Error Messages
2.2.1
Overview
Program Error Messages are stored in the message part of the SCF. They are
divided into:
common Error Messages (available for all Applications) documented in
chapter 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 is
identified by an error code Eaant and up to 9 message lines can be stored by error
code. Error code + line number is used as XI01 subkey:
E
aa
nnn
fixed
aa
aa = application (or Xs System Function)

XX = common error message
nnn
error number 001 - 999 (assigned by an analyst
error type
E = Error
W = Warning
line number (to identify records internally, never displayed)

1
= error message
2 - 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
2 - 11
DESIGN STANDARDS
displayed together with a terminal error via DISPLAY/STOP statement to

assist the EDP Manager.
NOTE
ORIGINALLY ONLY 4 MESSAGE LINES WERE SUPPORTED. WITH
THE NEW SCREEN STANDARDS THE NUMBER OF MESSAGE LINES
PER ERROR CODE HAS BEEN INCREASED TO 9. ALL OLD
APPLICATIONS STILL USE THE OLD DISPLAY TECHNIQUE OF
MESSAGE LINE 1 IN SCREEN LINE 24 AND MESSAGE LINES 2-4 IN
SCREEN LINES 22-24 WHEN F2 IS PRESSED.
2.2.2
Error Message Attributes
To provide standards and flexibility, a separate attribute (options) is provided per

error 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 user
can choose the attribute that best fits his local needs. No initial attribute is present
when 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 the
System Control File. Note that patching translates the error message but cannot
change the attribute. To change the attribute, an XI utility is used.
Error Type
E-Error
Error Attribute
b
Meaning
Reject (and ignore) transaction (all fields)
W-Warning
Upgrade the warning to an E-error, that is,

reject and ignore transaction.
Leave the meaning of the warning as

usual. The system displays a message if
an error has been detected. The user can
either correct the error, or by pressing
2 - 12
Program
Error Standards
Messages
Screen
function key F11, cause the system to take

any predetermined and programmed step,
depending on the individual error situation.
Which action is taken will be described in
the corresponding error message.
N
Downgrade the warning to "no error", that

is, no error message is displayed and the
value 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, the
corresponding error attribute(s) must be loaded into the TER-TABLE from the SCF
at initialization time. This can either be done with random accesses (if only one or
two 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 the
WSFILE, 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 messages
the following procedure is used:
One screen may contain one or more input fields to be checked and one or
more error messages may be displayed.
If at least one error is detected the screen is redisplayed with entered data in
the input fields and erroneous field(s) appear in reverse image
2 - 13
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 Line
23 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 same
error code. First message lines 2 and 3 are displayed in screen lines 22-24
overlaying 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 the
last message lines then message line 1 + function keys are redisplayed from
the same error code (wrap around).
With F1 the next error code + message line 1 is shown. When F1 is pressed
from the last error then the first error message is redisplayed (wrap).
The text of an error message is as follows:
line 1
lines 2-9
describes the error

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) should
explain what the program does in case of F11.
If no message text is found in the System Control File for an error code, the
program displays the error code plus a standard text 'NO MESSAGE
FOUND'.
2 - 14
Program
Error Standards
Messages
Screen
2.2.4
Print Program Procedure
In print programs that make validity checks and therefore display error messages
the following procedure is used:
Either all transactions (all = with or without error) are listed or only erroneous
transaction. 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 the
first error message but a space line is used between transactions.
One or more error messages may be printed per transaction. They should be
in sequence of input fields from left to right.
The message text should use the same terms and field names as printed in
column headings.
The error message attribute is handled similarly to the screen program
procedure.
"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 DISPLAY
and STOP statements. This means that the error appears to the user as if it were a
SYSTEM stop:
CBL 3017 (0 23)
1)
ABNORMAL SITUATION DETECTED BY PROGRAM, CONSULT EDP MANAGER 2)
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)
2 - 15
DESIGN STANDARDS
1) Displayed by the system

2) Message line 1 from error code EXX002E, translatable
3) English text hardcoded in program, not translatable
For important errors, a special error code can be used to store all 4 message lines
in 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 with
the 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, the

following coding techniques must be adhered to:
1) Each program dealing with error messages must contain the so-called 'TERTable' in the working storage area.
One element must be possible for each possible error.
Example (TER-Table)
01 TER-CODES.
05 TER-CODE01
05 TER-CODE02
05 TER-CODE03
05 TER-CODE04
05 TER-CODE05
05 TER-CODE06
PIC
PIC
PIC
PIC
PIC
PIC
X(11)
X(11)
X(11)
X(11)
X(11)
X(11)
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
'EOM001E
'EOM002E
'EOM003E
'EOM020E
'EOM021E
'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.
2 - 16
Program
Error Standards
Messages
Screen
1 = TER-CODE
Error Message code
2 = TER-FLAG
(set by program)
'Y' error is to be displayed or printed

' ' error is not valid for processing
3 = TER-ATTR1
(loaded by XMER03
from XI01)
TER-ATTR2
Error attribute (see T3/2.2.2 for details)
4 = TER-ADDINFO
reserved for future use

This field is only used when variable data is to be
shown together with the error message. (See T3/2.2.7
Variable Error Message Text). In this case the size of
this field is 10 bytes and not 1 byte as shown in the
example.
2) As soon as an error is detected by the program the corresponding TER-flag

must be set to 'Y'. At the same time a general error indicator and the Boolean
indicator for reverse image of the erroneous field are turned ON.
Example
IF W-INPUT-FLD-LENGTH GREATER XI01-ID-FIELD-LENGTH
MOVE 'Y' TO TER-FLAG (6)
SET C-ERROR
TO TRUE
SET C-IND-A-ON (14)
TO TRUE
First all input fields of a screen format (or all fields of a transaction) are checked
resulting in zero, one or more TER-FLAGS in the TER-table
3) Standard error handling modules
In a screen program the general error indicator C-ERROR determines if an error
message is to be displayed in lines 23-24 (standard bottom format FMT99).
Module XMER04 automatically gets message line 1 of the first flagged error
code in the TER-table and puts it into FMT99:
IF C-ERROR
OR F1-NXTERR
OR F2-ADDINFO
PERFORM XMER04-ERROR-MESSAGE THRU XMER04-EXIT
2 - 17
DESIGN STANDARDS
4) If F1 or F2 is pressed then the module XMER04 is also executed to read

message line 1 of the next flagged error code (F1) or to read the next 2
message 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 TERFLAGS, the gerenal error-indicator and the Boolean indicators must first be
turned 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 to
be printed right after the transaction. Module XMER04 is performed with F1
simulated 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-ERRORS
PERFORM XMER04-ERROR-MESSAGE THRU XMER04-EXIT.
IF XMER04-O-C-END-OF-TER
GO TO 315-EXIT.
MOVE XMER04-O-ERRCODE
TO RPT-ERRCODE
MOVE XMER04-O-T1-MESSAGE (1) TO RPT-MESSAGE
PERFORM Z05-RPT-WRITE THRU Z05-EXIT.
MOVE '01' TO FUNCTION-KEY.
315-EXIT
EXIT
2 - 18
Program
Error Standards
Messages
Screen
7) Modules available for standard error handling:

XMFR04
XMF999
XMER02
XMER03
XMER04
2.2.7
COBOL Screen program frame

Screen format defintions (FMT01, FMT99, window pattern, help
pattern)
Stop error handling (termial error)
Load error attributes
Supply error message
Variable Error Message Text
In order to be able to give the user as much information as possible, it may

sometimes 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 is
taken from XI01-data dictionary record.
To allow for simple and automatic processing of error messages including variable
data, the following must be foreseen in the error message text itself and in the
program displaying or printing the message:
1) Error Message Text
The last 10 positions of the error message text must be reserved for the variable
data. 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.
2 - 19
DESIGN STANDARDS
2) Program Requirements
a) TER-Table
The TER-Table must be defined as shown below:
01 TER-CODES.
05 TER-CODE01
05 TER-CODE02
05 TER-CODE03
05 TER-CODE04
05 TER-CODE05
05 TER-CODE06
PIC
PIC
PIC
PIC
PIC
PIC
X(20)
X(20)
X(20)
X(20)
X(20)
X(20)
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
'EOM001E
'EOM002E
'EOM003E
'EOM020E
'EOM021E
'EOM031E
'.
'.
'.
'.
'.
'.
1)
01 TER-TABLE
REDEFINES TER-CODES.
30 TER-ELEMENT OCCURS 06
INDEXED BY TER.
32 TER-CODE
PIC X(7).
32 TER-FLAG
PIC X.
32 TER-ATTR.
34 TER-ATTR1
PIC X.
34 TER-ATTR2
PIC X.
32 TER-ADDINFO
PIC X(10).
3)
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 the
message concerned is flagged.
Example
IF W-INPUT-FLD-LENGTH
MOVE 'Y'
MOVE XI01-FLD-LGTH
TO TER-FLAG (6)
TO TER-ADDINFO(6).
(XI01-ID-FIELD-LGTH contains the length of the field being processed).
2 - 20
Screen
Program
Error Standards
Messages
c) Error Handling XMER01 (Supply an Error Message)

Module XMER04 automatically moves the contents of the TER-Table (TERADDINFO) 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 store
the required variable data, special programming must be done to handle each
specific situation.
2.2.8
Standard Error Messages
EXX
BASIS XIP080 12
31.10.88 15:32
BA B5
TEST COMPANY --CCCS-S Y S T E M C O N T R O L F I L E - ERROR MESSAGES
APPLICATION: XX
MESSAGE CODE
EXX000
EXX000
EXX001
EXX001
EXX003
EXX004
EXX005
EXX006
EXX006
EXX006
EXX008
EXX009
EXX009
EXX009
EXX010
EXX012
EXX012
EXX013
EXX013
EXX014
EXX014
EXX014
EXX014
EXX015
E1
E2
E1
E2
E1
E1
E1
E1
E2
E3
E1
E1
E2
E3
E1
E1
E2
E1
E2
E1
E2
E3
E4
E1
EXX015 E2
EXX015 E3
EXX016 E1
RELEASE DATE: 31.10.88

MESSAGE TEXT
ERROR ATTRIBUTES
NO MESSAGE FOUND
NO FURTHER INFORMATION AVAILABLE
F1/CMD-1 PRESSED BUT NOT REQUIRED
F2/CMD-2 PRESSED BUT NOT REQUIRED
ITEM NO./LINE NO. ENTERED IS NOT ON SCREEN
DATE MISSING OR INVALID
INVALID COMMAND KEY PRESSED
ROUTE NOT DEFINED IN SYSTEM CONTROL FILE.
ENTER CORRECT ROUTE OR ADD ROUTE TO CODE INTERPRETATION PART OF
THE SYSTEM CONTROL FILE (USE MENU XIM001-03)
INVALID OUTLET NUMBER OR CHECK DIGIT ENTERED
OUTLET NOT EXISTING IN OUTLET MASTER FILE.
ENTER CORRECT OUTLET NO. OR CREATE NEW OUTLET BEFORE ENTERING
ANY TRANSACTION (USE MENU OMM000-01)
INVALID STATUS CODE ENTERED
ARTICLE NUMBER(S) NOT ON ARTICLE MASTER FILE
-OR- GENERIC ARTICLE NUMBER ENTERED
INVALID ARTICLE NUMBER ENTERED
INVALID ARTICLE NUMBER ENTERED
ARTICLE QUANTITY NOT NUMERIC OR INVALID FORMAT
NOT NUMERIC -OR- MISSING -OR- OTHER THAN DECIMAL SIGN USED FOR
SUBUNITS SEPARATOR SIGN -OR- SUBUNITS ENTERED FOR AN ARTICLE W/O
SUBUNITS -OR- INVALID MINUS SIGN
PERSONNEL NUMBER MISSING OR NOT EXISTING ON PERSONNEL MASTER
FILE
ENTER CORRECT PERSONNEL NUMBER OR STOP PROCESSING TO
UPDATE PERSONNEL MASTER FILE WITH MISSING PERSONNEL DATA
CALENDAR RECORDS MISSING IN SYSTEM CONTR.FILE FOR MONTY ##########
2 - 21
DESIGN STANDARDS
EXX016
EXX016
EXX016
EXX017
EXX017
EXX017
EXX018
EXX018
EXX019
EXX020
EXX021
EXX022
EXX023
EXX024
EXX025
EXX025
EXX026
EXX027
EXX027
EXX027
EXX028
EXX029
EXX030
EXX031
EXX031
EXX032
EXX034
EXX035
EXX035
EXX035
E2
E3
E4
E1
E2
E3
E1
E2
E1
E1
E1
E1
E1
E1
W1
W2
W1
E1
E2
E3
E1
E1
E1
W1
W2
W1
E1
E1
E2
E3
CALENDAR RECORDS ARE REQUIRED FOR DATE CALCULATION

RECOVERY = 3 - TERMINATE JOB, INSERT CALENDAR RECORD(S) ON
SYSTEM CONTROL FILE (MENU XIM001-01)
XL TABLE RECORDS ARE NOT MATCHING LOAD AND START ADDRESS
TABLE IN GENERIC PROGRAM
ONLY RECOVERY '3' ALLOWED
XL AREA OVERFLOW
ONLY RECOVERY '3' ALLOWED
LOCATION INVALID OR MISSING
FIELD NUMBER ENTERED NOT VALID FOR FILE(S) BEING MAINTAINED
FIELD NUMBER MISSING
ONLY PERCENTAGE OR VALUE ALLOWED
NEGATIVE PERCENTAGE OR VALUE NOT ALLOWED
PERCENTAGE ONLY VALID FOR FIELDS WITH FIELD TYPE 'S'....
SENDING FIELD LENGTH UNEQUAL RECEIVING FIELD LENGTH...: ##########
IF RECEIVING FIELD LENGTH IS SMALLER DATA TRUNCATION MAY OCCUR
FIELD TYPE AND FIELD FORMAT UNEQUAL...................: ##########
INVALID COMBINATION OF FIELD TYPES
A) SENDING FIELD HAS TYPE 'A'/ RECEIVING FIELD HAS 'N','S' OR 'O'
B) SENDING FIELD HAS TYPE 'S' / RECEIVING FIELD HAS 'N' OR 'D'
FIELD NUMBER OR VALUE MISSING
VALUE ENTERED AND FIELD TYPE NOT 'N' OR 'S'
LOCAL FIELD NAME ENTERED NOT EQUAL....................: ##########
NUMBER OF DECIMAL POSITIONS UNEQUAL...................: ##########
UNPREDICTABLE RESULTS MAY OCCUR
ATTENTION - ALL RECORDS WILL BE MAINTAINED !
PRICE LIST MISSING OR NOT PRESENT IN PRICE MASTER FILE AM05
INVALID ADJUSTMENT LIST NUMBER
ADJUSTMENT LIST MISSING OR
NOT PRESENT IN AM07 OR
BASIS XIP080 12
TEST COMPANY --CCCS--
31.10.88 15:32
BA B5
S Y S T E M C O N T R O L F I L E - ERROR MESSAGES
APPLICATION: XX
APPLICATION: XX
MESSAGE CODE
MESSAGE TEXT
ERROR ATTRIBUTES
EXX035
EXX037
EXX039
EXX041
EXX042
EXX043
EXX043
E4
E1
E1
E1
E1
E1
E2
EXX043 E3
EXX044 E1
2 - 22
NO VALID VERSION PRESENT IN AM07 FOR PRICING DATE

RECORD ALREADY PRESENT IN FILE..........................##########
OUTLET NUMBER MISSING
NO DATA ON FILE FOR DATA TYPE TO BE PROCESSED
OPTION VALUE INVALID OR MISSING
INVALID 'SKIP-TO' SEQUENCE NUMBER ENTERED
SEQ.NO.
A)'SKIP-TO' MUST BE IN SAME RANGE AS ADJUSTMENT SEQUENCE
NUMBER
B)'SKIP-TO' MUST BE GREATER THAN ADJUSTMENT SEQUENCE NUMBER
MESSAGE CODE IS NOT DEFINED IN MESSAGE FILE OM05
Screen
Program
Error Standards
Messages
EXX045
EXX046
EXX047
EXX048
EXX049
EXX050
EXX051
EXX052
EXX052
EXX052
EXX052
EXX053
EXX053
EXX053
EXX054
EXX055
EXX056
EXX056
EXX057
EXX057
EXX058
EXX058
EXX058
EXX059
EXX059
EXX061
EXX062
EXX063
EXX064
EXX065
EXX065
EXX065
EXX065
EXX066
EXX066
EXX066
EXX066
EXX067
EXX068
EXX068
EXX068
EXX069
EXX070
EXX070
EXX070
EXX070
EXX071
EXX072
E1
E1
E1
E1
E1
E1
E1
E1
E2
E3
E4
E1
E2
E3
E1
E1
E1
E2
E1
E2
E1
E2
E3
E1
E2
E1
W1
E1
E1
E1
E2
E3
E4
E1
E2
E3
E4
E1
E1
E2
E3
E1
E1
E2
E3
E4
E1
E1
REQUIRED RANGE RECORDS MISSING FOR FIELD

VALUE NOT WITHIN RANGE LIMITS
ENTER '/' TO DELETE FIELD.(ZEROES OR BLANKS NOT ALLOWED)
'/' IS NOT ALLOWED FOR REQUIRED FIELD
NO UPDATE ALLOWED FOR THIS FIELD (PROGRAM DEVELOPMENT GROUP)
UPDATE NOT POSSIBLE ...... (KEY FIELD FOR INDEXED FILE!!!)
DATA ENTERED EXCEEDS FIELD LENGTH.....................: ##########
INVALID NUMERIC DATA ENTERED
1) NEGATIVE VALUE ENTERED FOR FIELD TYPE 'N'
2) INVALID DEZ.SIGN OR MINUS SIGN NOT IN LAST POSITION OFFIELD
3) TOO MANY DECIMAL POSITIONS OR ALPHA DATA ENTERED
VALUE ENTERED IS NOT PRESENT IN CODE INTERPRETATION PART OF XI01
CHECK LOCATION INDICATOR IN DATA DICTIONARY RECORD FOR FIELD
IF INDICATOR EQUALS 1.CODE VALUE MUST BE RECORDED WITH LOCATION
OVERLAPPING DATES !! ATTEMPT TO UPDATE TWICE !
DATES MISSING !! DATE GAP BETWEEN LAST UPDATE RUN !
NO FIELD PROCESSING OPTION PRESENT IN XI01 FOR FILE...: ##########
PLEASE CONTACT EDP MANAGER
ERRORS DATA DICTIONARY PART OF SYSTEM CONTROL FILE XI01.
PLEASE CONTACT EDP MANAGER TO CORRECT DATA DICTIONARY
FIELD TO BE DISPLAYED NOT PRESENT IN DATA DICTIONARY..: ##########
CONTACT EDP MANAGER TO CORRECT FIELD PROCESSING OPTION
OR TO CREATE DATA DICTIONARY RECORD FOR FIELD CONCERNED
USER IS NOT AUTHORIZED TO UPDATE FIELD
CONTACT EDP MANAGER2
INVALID DATA IDENTIFIER ENTERED
CONTROL TOTAL MISSING OR NOT EQUAL COMPUTED TOTAL.....: ##########
MANUAL ADJUSTMENT DATA MUST BE PRECEDED BY VALID ARTICLE DATA
INVALID PERCENTAGE VALUE
INVALID VALUE OR AMOUNT
A) DATA MAY NOT BE NEGATIVE
B) DATA NOT NUMERIC
C) TOO MANY DECIMAL POSITIONS
INVALID FREE CASE VALUE
A) QUANTITY MUST BE NUMERIC
B) NO DECIMAL POSITIONS ALLOWED
C) QUANTITY MAY NOT BE NEGATIVE
EMPTIES EXCHANGE INDICATOR MUST EQUAL '0' OR '1'
INVALID ADJUSTMENT LIST NUMBER
ADJUSTMENT MUST BE DELIVERY BASED OR 1
ADJUSTMENT LIST IS NOT A FREE CASE ADJUSTMENT
NO ADJUSTMENTS ALLOWED FOR TRANSACTION CODE 177 OR 178
ADJUSTMENT LIST IS NOT VALID FOR THIS OUTLET
ADJ.LIST NO. FROM 9100 TO 9199 REQUIRES A VALID BILL-TO-OUTLET
ADJ.LIST NO. FROM 9200 TO 9299 REQUIRES A VALID DISCOUNT-TO-OUTLET
ADJ.LIST NO. FROM 9300 TO 9399 REQUIRES A VALID CREDIT-TOOUTLET
EMPTIES EXCHANGE DOES NOT ALLOW EMPTY ARTICLE OR NEGATIVE QUANTITY
DOCUMENT OR ORDER NOT CORRECTLY COMPLETED WITH 'ENTER' KEY
2 - 23
DESIGN STANDARDS
BASIS XIP080 12
31.10.88 15:32
BA B5
APPLICATION: XX
APPLICATION: XX
MESSAGE CODE
MESSAGE TEXT
ERROR ATTRIBUTES
EXX072
EXX072
EXX072
EXX073
EXX074
EXX075
EXX075
EXX075
EXX076
EXX077
EXX078
EXX079
EXX080
EXX081
EXX081
EXX081
E2
E3
E4
E1
E1
E1
E2
E3
W1
W1
E1
E1
E1
E1
E2
E3
EXX081
EXX082
EXX082
EXX082
EXX082
EXX083
EXX083
E4
E1
E2
E3
E4
E1
E2
EXX083
EXX084
EXX085
EXX085
EXX085
E3
E1
E1
E2
E3
EXX086
EXX086
EXX086
EXX086
EXX087
EXX088
EXX089
EXX090
EXX090
EXX090
EXX090
E1
E2
E3
E4
E1
E1
E1
W1
W2
W3
W4
2 - 24
THE PROGRAM CANNOT HANDLE 'INCOMPLETE' ORDERS OR DOCUMENTS:

A) DELETE ORDER/DOCUMENT WITH CMD-4
B) ENTER ORDER/DOCUMENT AGAIN AND PRESS ENTER FROM LAST SCREEN
UNAUTHORIZED ARTICLE ENTERED
ARTICLE NUMBER OR ARTICLE QUANTITY MISSING
FUNCTION KEY NOT ALLOWED UNTIL TRANSACTION COMPLETELY ENTERED
IF CORRECTION OF DATA IS NOT POSSIBLE AT THE MOMENT
CANCEL TRANSACTION WITH F4
SUPPRESSED OUTLET
SUPPRESSED ARTICLE
DATA IDENTIFIER ONLY ALLOWED ON FIRST SCREEN OF A TRANSACTION
INVALID STOCK LEVEL QUANTITY
INVALID OR NO ARTICLE NUMBER ENTERED
INVALID FREE PREFIX ENTERED
EITHER OXX-DOCRAN RECORD DOES NOT EXIST ON XI01 FILE FOR PREFIX
ENTERED OR FREE PREFIX IS NOT ALLOWED DUE NOT OXX-DOCPFX RECORD
ON
XI01 FILE
DUPLICATE DOCUMENT NUMBER FOUND IN FILE.FP01.........: ###########
ACTION --> USE RECOVERY 0 TO CANCEL THIS JOB AND REORGANIZE
DOCUMENT NUMBER CHECK FILE FP01 IN MENU FPM001 ITEM #1
THEN RESTART THIS JOB TO CONTINUE DOC.NUMBER ASSIGNMENT
DOCUMENT NUMBER IDENTIFICATION MISSING ON XI01 FILE
CREATE OXX-DOCID RECORD AND/OR INCLUDE DOCUMENT IDENTIFICATION
ON
OXX-DOCID OPTION ON XI01
INVALID BREAKPOINT VALUE ENTERED
DOCUMENT NO. RANGE MISSING FOR LOCATION/DOC-ID/PREFIX...##########
CREATE OXX-DOCRAN RECORD ON XI01 SYSTEM CONTROL FILE
CANCEL JOB AND CREATE OXXDOCRAN-RECORD ON XI01 FOR MISSING
RANGE
INVALID DOCUMENT NUMBER PREFIX OPTION FOUND
EITHER INDICATOR NOT 'A'. 'B'. 'C'. 'D' OR LENGTH NOT 1 - 4
OR PREFIX INDICATOR NOT IN ACCORDANCE WITH PREFIX LENGTH
OR INDICATOR IS 'C' AND PAYMENT TYPE SUBSTITUTIONS(S) NOT 1 - 9
INVALID MANUAL OVERRIDE OF TRANSACTION TYPE
INVALID MANUAL OVERRIDE OF PAYMENT TYPE
INVALID DOCUMENT NUMBER OR CHECK DIGIT ENTERED
F11 = BYPASS ERROR (USE ONLY IN RESTART SITUATION !!!)
NOTE: CHECK REPEATED IN ACTUAL UPDATE PROGRAMS
(NO RECOVERY POSSIBLE !)
Program
Error Standards
Messages
Screen
EXX091
EXX091
EXX091
EXX091
EXX092
EXX092
EXX092
EXX092
EXX093
EXX094
EXX095
EXX095
EXX095
EXX095
EXX096
EXX097
EXX098
EXX099
E1
E2
E3
E4
E1
E2
E3
E4
E1
E1
E1
E2
E3
E4
E1
E1
E1
E1
INVALID DELIVERY TRANSACTION CODE

##########
ENTRY OF .PATY. .DOTY OR .TRTY RESULTS IN AN INVALID DELIVERY
TRANS.CODE -OR- INVALID .TRCO ENTERED
---> USE .TRCO TO OVERRIDE ALL 3 CODES
PRICE LIST 910-949 REQUIRES A VALID BILL-TO/DISCOUNT-TO/CREDIT-TO
PL.910-919 --> OM01 FLD.NO 091 (BILL-TO) IS MISSING
PL.920-929 --> OM01 FLD.NO 092 (DISCOUNT-TO) IS MISSING
PL.930-939 --> OM01 FLD.NO 093 (CREDIT-TO) IS MISSING
EMPTIES ARTICLE NOT VALID FOR IDENTIFIER...............:##########
ONLY EMPTIES ARTICLE VALID FOR IDENTIFIER.............: ##########
VALUE ENTERED IS INVALID
ENTER CORRECT VALUE OR
CREATE CODE INTERPRETATION FOR SPECIFIED VALUE OR
INCLUDE SPECIFIED VALUE IN RANGE RECORD LIMITS
EMPTY SPLIT CODE MUST EQUAL '0' OR '1'
ENTERED ARTICLE MUST NOT BE AN EMPTY
ENTERED ARTICLE MUST BE AN EMPTY
INVALID EMPTY INVENTORY OVERRIDE
BASIS XIP080 12
31.10.88 15:32
BA B5
APPLICATION: XX
APPLICATION: XX
MESSAGE CODE
MESSAGE TEXT
ERROR ATTRIBUTES
EXX100
EXX101
EXX102
EXX103
EXX104
EXX104
EXX104
EXX105
EXX105
EXX105
EXX106
EXX106
EXX106
EXX107
EXX107
EXX108
EXX108
EXX109
EXX109
EXX110
EXX111
EXX112
E1
E1
E1
E1
E1
E2
E3
E1
E2
E3
E1
E2
E3
E1
E2
E1
E2
E1
E2
E1
E1
E1
SUBUNIT QUANTITY NOT ALLOWED FOR ARTICLE

NO DATA FOUND FOR SELECTION CRITERIA
FROM - TO RANGE SELECTION INCORRECT
AT LEAST ONE SELECTION FIELD MUST NOT BE BLANK
INVALID BUSINESS SEGMENT ENTERED OR
COMBINATION MISSING IN THE SALES DATA BASE FILE,
CHECK OXX-KEYCMB RECORD IN XI01
INVALID BUSINESS SEGMENT VALUE ENTERED OR
SEGMENT MISSING IN THE SALES DATA BASE FILE,
CHECK OXX-KEYCMB RECORD IN XI01
THE DEFINATION OF THE KEY COMBINATION IS NOT MATCHING WITH
THE FILE, REBUILD THE DATA BASE FILES FOR THE PERIOD(S) OR
CORRECT OXX-KEYCMB RECORD IN XI01
INVALID ARTICLE GROUP OR INVALID OR NO ARTICLE(S) SELECTED OR
ARTICLE(S) SELECTED BUT NOT REQUIRED
INVALID OR NO ARTICLE GROUPING TYPE SELECTED, CHECK OXX-GROUP
RECORD IN XI01, OR ARTICLE GROUPING TYPE SELECTED BUT NOT REQUIRED
SELECTION OF AN ARTICLE GROUPING TYPE IS POSSIBLE ONLY TOGETHER
WITH THE SELECTION SIGN FOR ARTICLE GROUPS, USE SYMBOL '+'
INVALID BUDGET TYPE ENTERED
TOO MANY FIELDS SELECTED
INVALID SELECTION SIGN ENTERED, USE THE SYMBOL DEFINED BY THE
2 - 25
DESIGN STANDARDS
EXX112
EXX113
EXX114
EXX115
EXX116
EXX117
EXX118
EXX119
EXX120
EXX120
EXX120
EXX121
EXX122
EXX122
EXX123
EXX124
EXX125
EXX125
EXX126
EXX126
EXX127
EXX127
EXX128
EXX129
EXX130
EXX130
EXX130
EXX130
EXX131
EXX131
EXX131
EXX131
EXX132
EXX133
EXX133
E2
E1
E1
E1
E1
E1
E1
E1
E1
E2
E3
E1
E1
W1
E1
E1
E1
E2
E1
E2
E1
E2
E1
E1
W1
W2
W3
W4
E1
E2
E3
E4
W1
W1
W2
OPTION OXX-SELECT, OR THIS SELECTION SIGN IS NOT ALLOWED NOW

INVALID ARITHMETICAL SYMBOL ENTERED
INVALID ADDITIONAL CONVERSION FACTOR ENTERED
INVALID SELECTION SIGN ENTERED, VALID CODES ARE: ' ' AND '1'
INVALID SELECTION SIGN ENTERED, VALID CODES ARE: '1' AND '2'
INVALID NUMBER OF COLUMNS ENTERED
INVALID SYMBOL FOR PAGE SKIP ENTERED
INVALID FIELD NUMBER ENTERED
INVALID COMBINATION OF SELECTIONS, IT IS NOT ALLOWED TO COMBINE
DIFFERENT KINDS OF SEGMENT TYPES ON ONE REPORT, THE FIRST SEGMENT
TYPE MAY NOT BE A COMBINATION OF FIELDS, ONLY ONE LETTER ALLOWED
INVALID GROUPING LIST ENTERED, CHECK AM03
INVALID COST AND/OR ADJUSTMENT CLASS ENTERED
INVALID COST AND/OR ADJUSTMENT CLASS ENTERED
INVALID TIME FRAME ENTERED, CODE MUST BE EQUAL 1
ONLY AN AVAILABLE KEY COMBINATION IS ALLOWED
A DIFFERENCE FIELD MAY ONLY BE SELECTED TOGETHER
WITH THE CORRESPONDING CURRENT FIELD
THE SHARE TO GROWTH LEVEL MAY NOT BE BLANK WHEN A FIELD
'SHARE OR PERCENT OF A VARIABLE LEVEL' WAS SELECTED
FOR SELECTED PERIOD NO SALES DATA BASES OR SALES BUDGET FILES
ARE AVAILABLE OR NO EXX-SDCONT RECORD WAS FOUND IN XI01
THE CONTRIBUTION LEVELS MUST BE IN ASCENDING ORDER
INVALID PERIOD ENTERED, VALID CODES ARE ' ', '1' OR '7'
IMMEDIATE INVOICING FOR A PREVIOUS DAY HAS NOT BEEN COMPLETED
THE MENU ITEM 'END OF DAY' FOR IMMEDIATE INVOICING,WHERE INVOICES
ARE TRANSFERRED AND LOAD REPORT IS PRINTED SHOULD BE EXECUTED
BEFORE A NEW DAY IS STARTED
YOU ARE NOT AUTHORIZED TO RUN THIS COMPLEX .....
************************************************
***
INFORM YOUR SECURITY OFFICER
***
************************************************
ENTERED YEAR IS NOT EQUAL SYSTEM YEAR. CMD-12 --> ACCEPT.
WAITING FOR A RESERVED DOCUMENT RANGE.................: ## # ####
CURRENTLY OCCUPIED BY ANOTHER JOB................: ######-## ## ##
BASIS XIP080 12
31.10.88 15:32
BA B5
APPLICATION: XX
APPLICATION: XX
MESSAGE CODE
MESSAGE TEXT
ERROR ATTRIBUTES
EXX133
EXX133
EXX134
EXX135
2 - 26
W3
W4
W1
E1
PROGRAM WILL AUTOMATICALLY CONTINUE WHEN FREE. IN SPECIAL CASES

THE RESERVATION CAN BE REMOVED WITH XIM000-01 FROM ANOTHER SCREEN.
JOB THROUGH WAITING FOR RESERVED DOCUMENT. PROGRAM CONTINUES
INVALID OR NO OXX-PERIOD OPTION FOR TYPE/YEAR/NUMBER ##########
Screen
Program
Error Standards
Messages
EXX135
EXX135
EXX135
EXX136
EXX137
EXX137
EXX137
EXX138
EXX139
EXX140
EXX141
EXX142
EXX142
EXX143
EXX143
EXX144
EXX145
EXX146
EXX147
EXX147
EXX148
EXX148
EXX149
EXX149
EXX149
EXX150
EXX151
EXX152
EXX153
EXX153
EXX153
EXX153
EXX154
EXX155
EXX156
EXX156
EXX156
EXX157
EXX157
EXX157
EXX157
EXX158
E2
E3
E4
E1
E1
E2
E3
E1
E1
E1
E1
E1
E2
E1
E2
E1
E1
E1
E1
E2
E1
E2
W1
W2
W3
E1
W1
E1
E1
E2
E3
E4
E1
W1
W1
W2
W3
E1
E2
E3
E4
E1
A) CREATE OXX-PERIOD OPTION ON SCF XI01, IF NOT EXISTING

B) CHECK PERIOD FROM-TO DATES ON VALIDITY
C) OXX-CALEND OPTIONS WITHIN FROM-TO DATES MUST ALSO EXIST
VALUE MORE THAN ONE TIMES ENTERED
WRONG FILES USED: THE FILE GAS ALREADY BEEN CONVERTED OR
THE FILE HAS AN OLD LAYOUT OR
IS NOT CORRESPONDING WITH THE PROCESSING DATE
INCORRECT OXX-FIELDS OR OXX-KEYCMD RECORD IS DEFINED IN XI01
INVALID ARTICLE GROUPING TYPE OR ARTICLE GROUP ENTERED
FOR SELECTED CALCULATION SIGN, AMOUNTS MAY NOT BE ZERO
LOCATION ENTERED NOT PRESENT ON CURRENT INPUT FILE
INVALID COMBINATION OF SELECTION SIGN AND FUNCTION KEY OR
INVALID SELECTION SIGN ENTERED
INVALID COMBINATION OF SELECTIONS OR INVALID SELECTION
SIGN ENTERED
AT LEAST ONE PERCENTAGE VALUE MUST NOT BE ZERO
INVALID COLUMN NUMBER SELECTED
INVALID CONSTANT VALUE ENTERED FOR CALCULATION
NO DETAIL INFORMATION AVAILABLE FOR SPECIAL COLUMN ASSIGNMENT
PRESS F4 'UNDO COLUMN ASSGNMNT' AND REPEAT DETAIL SELECTIONS
INVALID SELECTION SIGN OR INVALID BUDGET TYPE ENTERED OR
FIELD NOT VALID FOR BUDGET SELECTION
ARTICLE HAS ERROR STATUS ON AM01
CHECK AM01 - MAINTANANCE MAY NOT BE FINISHED CORRECTLY
F11 ACCEPT ARTICLE WITH ERROR
INVALID COST AND/OR ADJUSTMENT TYPE ENTERED
ARTICLE GRP OVERVIEW FOR USER CALC FIELDS NOT ALLOWED ON S36
F11 PRESSED TO BYPASS WARNING, BUT TERMINAL ERROR ALSO PRESENT.
PRESS F1 TO PAGE THROUGH ERROR MESSAGES.
FIRST CORRECT TERMINAL ERRORS, THEN F11 WILL BE ACCEPTED.
INVALID JOBQ/EVOKE OPTION ENTERED, VALID CODES ARE: ' ', 'J', 'E'
ENTERED YEAR IS NOT EQUAL SYSTEM YEAR. F11 --> ACCEPT.
ARTICLE HAS ERROR STATUS ON AM01
CHECK AM01 - MAINTENANCE MAY NOT BE FINISHED CORRECTLY
F11 --> ACCEPT ARTICLE WITH ERROR
F11 PRESSED TO BYPASS WARNING, BUT TERMINAL ERROR ALSO PRESENT
PRESS F1 TO PAGE THROUGH ERROR MESSAGES.
FIRST CORRECT TERMINAL ERRORS, THEN F11 WILL BE ACCEPTED.
MORE THAN ONE ERROR FOUND. USE F1 TO PAGE THROUGH ERROR MESSAGES.
2 - 27
DESIGN STANDARDS
2 - 28
Screen Standards
2.3
Screen Standards
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
2.3.8
2.3.9
2.3.10
2.3.11
2.3.12
2.3.13
2.3.14
2.3.15
2.3.16
2.3.17
2.3.18
2.3.19
Following SAA Standards for Common User Access

Screen Documentation
General Screen Layout
Standard Screen Sequence to Start an Action
Action Bar
Action Codes
Windows
Overview Screens (=list panels)
Entry Screens (=entry and menu panels)
User Defined Screens and Windows (Screen Design Facility)
Function Keys
Commands in 'Expert mode'
Options and Selection Methods
Input Fields
Instructions
Error Messages and Informational Messages
Help Support
Language Translation ('Patchable' constants)
Performance Considerations
2 - 29
DESIGN STANDARDS
2.3.1
Following SAA Standards for Common User Access
Statement:
All new BASIS applications developed from 1989 onwards follow the standards as
documented in this chapter. Most of the guidelines are taken from IBM's SAA
concept for CUA but also keeping to old BASIS standards in favour of the integrety
of the package. Abbreviations SAA and CUA stand for:
SAA ... System Application Architecture
CUA ... Common User Access
All standards specified in chapter 2.3 are based on the technical capabilities of the
S/36 Screen Format Generator ($SFGR) and follow the SAA/CUA rules for:
Non-programmable terminals
Character applications
Refer to publications:
IBM SC26-4351-0
COCA-COLA
SAA Common User Access, Panel Design and User

Interaction
Common User Access Design Specifications for use at the
Coca-Cola Company
Deviations from SAA-CUA standards:

The following exceptions to SAA rules are made because of two reasons, first
because of the limited capabilities of the S3/X screen format generator, and
secondly to keep up the general outline of the BASIS package (= old plus new
applications!):
1) Panel id/title:
Always appears in line 1 together with program name/

modification levels, and so on instead in line 3 below
action bar.
2) Action bar:
Action bar choices are in reverse image instead

normal intensity, selected emphasis is in reverse
image/high intensity instead in reverse image/nornal
intensity.
2 - 30
Screen Standards
3) Help:
HELP key is used to request help information instead

F1. Extended help (F2) and Help index (F11) are not
supported. Help can not be requested from action bar.
4) Function keys:
F1 and F2 are used to roll through error messages in

the message area instead of being used to request
help/extended help.
F11 is used to accept warnings instead of being used
for help index.
F-keys for optional SAA features (such as F4=prompt,
F5=refresh, F9=retrieve) can be used for other
application functions instead of reserving them strictly.
5) Function key description: Long format is always displayed in lines 23-24 of

primary window instead of providing the user option to
switch between long/short/no display of F-keys.
6) Windows:
A star frame in reverse image/high intensity is used as

border instead of a double or single line. Pull-down
windows also have a panel-id instead none.
7) Message area:
Lines 23-24 of the primary window are used as

message area as well as for function key descriptions
instead of keeping both separate. If error occurs in a
secondary window the message is displayed in
message area of primary window instead of placing
the message in secondary window or in an adjacent
message window.
2.3.2
Screen Documentation
User Guide and Technical Guide:

1) Each guide includes a chapter (Chapter 2) which introduces the application on
the system. It shows the application's menus and gives a general explanation of
the menu items. The Technical Guide includes menus which are more related to
the 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 different
chapters, Chapter 2 should contain a section describing the general layout of the
2 - 31
DESIGN STANDARDS
common screen, along with a sample of the screen. This prevents having to explain
the screen twice or more within the manual.
Chapter 2 should also contain a section on standard routines if they are used
throughout an application. Standard routines include use of the action bar, on-line
help and the shortcut facility. This section shows significant screens with examples
of the routine.
2) All sections of a guide that contain step-by-step instructions show all the
corresponding screens in the sequence as they appear on a user's workstation.
3) Important areas on menus and screens are highlighted and arrows indicate the
relation 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 BASIS
term).
....:...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
2 - 32
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
--loc-BASIS
User-Id
Short name of Sign-on location, from XI01 OXX-LOCNAM
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. Simple
screens 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-nnn

12 bytes long (aa=application, nnn=function number).
2 - 33
DESIGN STANDARDS
Non-active action bar elements in reverse image/normal

intensity or green background on color screens.
The currently active element (selected emphasis) in reverse
image/high intensity or white background on color screens.
On AS/400 and S/36 the action bar must be combined in one format with the
application input format, in most cases.
Five choices fit into one line. If more than 5 choices are used on screen either F23
can be used to roll action bar horizontally or an action bar element 'OTHERS' is
used 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 or

entry 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, press
ENTER.'
If command entry is supported then the command entry line
must 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):

'===>'
--command--
Non-patchable constant. Same sign as used on AS/400!

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 one
format with the application input format, in most cases. For standards on
commands in 'expert mode' refer to chapter 2.3.11.
Lines 23-24 are used for key descriptions and error messages (FMT99):
X---key?---X
2 - 34
12-bytes patchable constant for description of function

keys.
Screen Standards
Eaannnt
Error code with aa=application,nnn=error number and

t=type W or E (reverse image or green background on
color screens, in one block with error message)
--error message-- Patchable message text from XI01(reverse image or
green background on color screens, in one block with
error code)
If no error is on the screen description for all currently active function keys are
displayed. If less than 6 F-keys they are diplayed in screen line 24. If more
than 6 they are displayed in lines 23-24.
If an error occurred or F1 is pressed the main message (stored as 'message
line 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 in
screen lines 23-24 erasing the F-key descriptions in screen line 24.
Line 23
can also used to display information messages such as'** Calculation

has 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 the
following chapters.
Frames for the formats FMT01, FMT99, and for the action bar line and command
entry 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 lines
3-4 and one input field in line 19.
2. OSP001/S01
Overview/selection screen with an action bar in line 2

Application panel goes from line 3-22. Input is allowed from the
action bar and also in the overview format to select a version.
The cursor is positioned on the first action bar choice.
2 - 35
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
8902
8903
8904
8905
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
|
|
|
Last Settlement Date Was........
09.02.89
New
010189
Settlement Date............
ROLL UP / ROLL DOWN

press ENTER to continue
CMD-7 End of job
BLANK = no settlement
X = days to be
settled
9 = days already
closed
HELP key for information
Example 2:
MW CCCS VIENN BASIS OUTLET SELECTION - VERSION OVERVIEW

Design
File/Save
00 00
OSP002/S01
890928
__
__
__
__
__
__
No
001
002
003
004
005
006
Description
FIRST TEST UNDER N6
SLAVES TEST
SECND TEST
OUTLET SELECTION
BFO-VERSION
BFO SECOND VERSION
ROLL UP / ROLL DOWN
2 - 36
Owner
CMD-7 End of job
Type
SMART
SMART
SMART
SMART
SMART
SMART
Status
Bottom
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 screen
programs to start and perform a function from an action bar. The SAA design
principle of Object-action' is followed but the 'Action-object' sequence is also
possible.
STEP 1
Primary window with action bar is presented by the program. All

action bar choices are in reverse image/normal intesity (or on green
background on color screens). Cursor is at first choice. An instruction is
displayed 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 the
action bar (using the TAB-key or FIELD EXIT to move the cursor).
Object(s) are selected by keying any character into the
input
field(s) of the overview (using the TAB-key or FIELD EXIT or the NewLine key to move the cursor).
If only an action is selcted but no object an error message appears if
the action requires an object.
If both action and object was selected but no object is required the
selected object is kept as selected (no error message).
If only object(s) were selected but no action the program shows them in
high intensity (selected emphasis) and waits for an action to be selected later (no error message).
STEP 3
The selected object is shown in high intensity (or white on color

screens) and the selected action bar element is shown in reverse
image/high intensity (or on white background on color screens).
A pull-down window appears below the action bar choice, either
aligned 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 the
user back to STEP 1.
2 - 37
DESIGN STANDARDS
STEP 5
If another step is necessary before the function can be performed

the program displays another window as described in steps 3 and 4.
The secondary window should be placed so that it overlaps the first
window, 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 performs
the selected action. As a result the original primary window with refreshed data is redisplayed or a new screen is displayed. An information message should be displayed:
a)
in a window if the action takes time

groups are being loaded')
(for example, 'Article
b)
in line 24 in high intensity (or white on color screens) when a

function has finished and no new screen is displayed (for
example, 'Calculation has been completed, select next route').
No message is necessary if a new screen is displayed and the action does

not last long.
2.3.5
Action Bars
Definition:
An Action bar is a group of functions that can be performed from one screen. They
are displayed in line 2 of the screen. The functions within an action bar are referred
to 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 of
thumb: 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 do
not use F4 to delete!).
2 - 38
Screen Standards
Layout:
The action bar line contains one to five choices with a one-byte input field in front of
each choice. There should be 5 functions each with 1 byte input and a 12 character
constant field. The 5 x (1+12) character layout is available in member XMF999 in
library SYSMOD.
Non-active choices are shown in reverse image/normal intensity (or on a green
background 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 the
action or group of actions that it contains (examples: UPDATE, VIEW, DELIVERY,
PAYMENTS).
These words are specified as user defined constants in XI01 option Aaa-SCRFCTnnn (aa=application, nnn=function number) together with its corresponding 'expert
mode' command.
Selecting an action bar element:
An action is selected when any character is keyed into the input field in front of its
action bar choice. At the same time one or more object(s) can be selected from the
overview. Then the ENTER key must be pressed. Only one action is accepted by
the 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 bar
constant can be entered in a command line (normally in line 22). This command
also selects an action bar function.
Because the cursor is initially positioned at the first action bar choice the user first
has to move the cursor to the Command entry line (use Back-Tab Key). Then he
can type the command and press the ENTER key. Such mnemonic commands are
defined in the System Control File (option Aaa-SCRFCT-nnn) and can be changed
by users into local languages.
Example: A Second action bar selection for 'DISPLAY' can either be selected by
keying 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.
2 - 39
DESIGN STANDARDS
Sequence of action bar choices within line:

Main functions available on a screen are arranged from left to right in the sequence
of their importance or in the sequence they have to be performed. No gaps are to
be left free.
Unavailable action bar choices:
For programming it is often preferrable to show the same sequence of choices in
the action bars on all screens of a program although not every action is available
on every screen. In this case the unavailble choices are displayed in normal
intensity without reverse image (or green on color screens) and its input field is set
to 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 used
to roll functions in line 2 horizontally.
When F23 is pressed, the currently displayed functions in the action bar line are
replaced by another 1 to 5 functions. When F23 is pressed again the original
functions are redisplayed. F23 can also roll 3 or more action bar lines within a
screen when applicable. How functions are presented and over how many lines, is
left up to the analyst of an application.
Action bar 'OTHERS':
As an alternative to opening a second action bar line with F23, additional
supporting functions can be collected under the last choice 'OTHERS' of the first
action bar line.
If the "OTHERS' function is selected, a window is displayed which offers the other
functions. It works just like a vertical action bar: a list of action bar constants is
displayed, each headed by an input field in which any character is keyed for
selection.
An example of the action bar function 'OTHERS' follows on the next page.
2 - 40
Screen Standards
Example: Screen CBP100/S01 with 5th action bar choice = OTHERS
GD CCBELGIQUE BASIS
Display
CB LOCATION OVERVIEW - VERSION NUMBERS

Proc./Reproc.
Error Corr.
00 00
CBP100/S10
Calculate
Others
-->
Type any char. left to desired function.
Settlem. date: 01/31
008 <-#loc--> 000
01 SOKODRINK
02 ANVERS
03 LA LOUVIER
04 MAASTRICHT
05 LIEGE
06 GOSSELIERS
07 BRUGGE
08 GANCO GENT
02/15
001
02/28
000
HOME moves cursor to top.
03/15
001
NIL
03/31
000
04/15
001
NIL
04/30
001
NIL
05/15
004
007
NIL
001
NIL
(*=still errors, c=already calculated, s=suspended)

ROLL UP / ROLL DOWN
CMD-7 END OF JOB
NIL
Bottom
HELP KEY FOR INFORMATION
When OTHERS is selected, a pull-down window presents the 'other' functions
GD CCBELGIQUE
S10
Display
BASIS
CB LOCATION OVERVIEW - VERSION NUMBERS
Proc./Reproc.
Error Corr.
Type any char. left to desired function.

Settlem. date: 01/31
008 <-#loc-->
000
01 SOKODRINK
02 ANVERS
03 LA LOUVIER
04 MAASTRICHT
05 LIEGE
06 GROSSELIERS
07 BRUGGE
08 GANCO GENT
02/15
001
02/28
000
NIL
03/15
001
Calculate
HO
0
0
NIL
(*=still errors, c=already calculated, s=suspended)

ROLL UP / ROLL DOWN
CMD-7 END OF JOB
00 00 CBP100/
1
Others
** Sel. func.*** CBW105**

*
*
* Select with any char.*
*
*
*
Suspense
*
*
Inquiry
*
*
mark NIL
*
*
*
* CMD-3=Exit
HELP*
*************************
NIL
NIL
Bottom
HELP KEY FOR INFORMATION
2 - 41
DESIGN STANDARDS
2.3.6
Action Codes
Definition:
Action codes are one- or two-character codes which identify an action and which
can be used to directly select object(s) for processing. They are used as alternative
method to selecting an object and an action from the action bar separately.
Example:
EL VIENNA
_ Display
BASIS C B LOCATION/VERSION OVERVIEW

00 00 CBP100/S10
_ 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 VIENNA
02 SALZBURG
03 INNSBRUCK
04 GRAZ
05 LINZ
etc.
ENTER
01/31
001
005
F3=exit
02/15 02/28 03/15

002
003*
004c
006*
008*
ROLL up/dwn
HELP
Sel.sign=any
Aaa-SCRFCT options:
Action codes and their associated text are stored on the System Control file XI01
along with the action bar functions. Both, codes and text, can be translated by the
user. If no Aaa-SCRFCT records are found on XI01 (or action code fields are
blank) 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 a
rule: if a program has an action bar then the actions supported by action codes
must also be present in an action bar.
Action codes can be used on overview screens if multiple objects can be selected
together and/or multiple actions can be selected from one screen.
2 - 42
Screen Standards
For instance, on AS/400 the Program Developement Manager (PDM) uses action
codes 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 and
the computer communicate. There are primary windows (full screen) and
secondary windows (only parts of screen). In this context a window is a secondary
window which occupies only part of the screen and leaves all unused lines/columns
of the primary window unchanged.
Types of windows:
There are 2 types of windows: Working windows (input expected) and Information
windows (no input).
Use:
Working windows:
Pull-down windows from action bars, viewing/changing of

options, selection of one or more items from alist (with
ROLL), entry panels for parameters orlow-volume data, and
so on.
Information windows: Help windows, message windows (e.g. to explain long
waiting times), and so on.
Windows should not be used for: Overview screens and high-volume data entry.
Layout for working windows:
....:...10....:...20....:...30....:...40
1|** X---title--------------X ** aaWnnn **|1
2|* X----instruction-------------------X *|2
3|*
A
*|3
4|*
|
*|4
5|* <---------- Panel body -----------> *|5
6|*
|
*|6
7|*
V
*|7
8|** X--key---X X--key---X X--key---X ****|8
....:...10....:...20....:...30....:...40
2 - 43
DESIGN STANDARDS
aaWnnn:
Window number (= panel-id) embedded in the star frame in the

right 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 (for
example, 'Select ORDER' or 'PROCESS new data file')
--instruction--:
Optional patchable text over one or more lines at the top to guide
the 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 star

frame
frame:
Stars'*' non-patchable (high intensity/reverse image or white

background on color screens)
Layout for information windows:
....:...10....:...20....:...30....:...40
1| X----title----------------X X--type--X |1
2|
A
|2
3|
|
|3
4|
|
|4
5| <--------- Information text ---------> |5
6|
|
|6
7|
|
|7
8|
V
|8
9 | X---key descriptions-----------------X |9
....:...10....:...20....:...30....:...40
--title--:
Patchable constant for field name or other title (for Help format) or
blank (for other message)
--type--:
Patchable constant '-Help-' or '-Message-'
frame:
No frame.
Instead line 1 in reverse image/ high intensity (or white
background 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. This
prevents from keying data on the original format on S/36.
2 - 44
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 (from
last 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 a
window also depends on the application requirements. However, the following
guidelines are to be used:
A pull-down window from an action bar is placed one line below the action
bar 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 on
the screen is possible.
A message window should be placed adjacent to the part of the main screen
to which it pertains, but should not cover it.
Overlapping windows:
Windows that immediately follow another window in order to perform one function
should overlap (for example option entry in 2 steps). The second window is placed
on top of the first window so that still the 2 top or bottom lines and the 2 left or right
columns are visible. In order to simulate a 3-dimensional appearance the
secondary 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 *
************ *
*
2 * *
*
* **
*
*
************
************
*
1 *
* ************
* *
2 *
** *
*
*
*
************
************
*
*
** *
*
* *
2 *
* ************
*
1 *
************
************
*
*
*
* **
*
2 * *
************ *
*
1 *
************
2 - 45
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 be
handled 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, each
layout displaying 63 selected fields from the BASIS data dictionary. For more
information refer to chapter T3, 2.3.9.
Instructions:
Instructions should tell the user what to do from this window, including which key
must be pressed. Instructions, if necessary, appear at the top of the window and
may extend over two or more lines if required. Information windows do not normally
contain 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) and
2.3.12 (Entry fields) must be followed.
Function-key descriptions:
Function keys that are valid for this window are displayed at the bottom of the
window. 12-character common constants are available for the standard function
keys (do not define as constants in format).
Standard function-keys:
ENTER:
F3:
F12:
ROLL :
to continue, input fields are accepted, checked and processed

to terminate the current action (back to action bar!)
to return to the previous window (only one step back!)
if required
Error messages:
Any error messages for invalid input in the current window appear at the bottom of
the main screen (FMT99). Standard error handling with F1/F2/F11 is provided.
2 - 46
Screen Standards
Frame XMF999:
A standard frame for both, working windows and information windows, is available
in 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 per
item is displayed in a 'body' of, say 12 lines, that can be scrolled and from which
the 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 overview
screens whenever possible. It enables the user to define the fields to be displayed
per line, up to 99 different line layouts. In this way the decision what to show on
overview screens is given to the user. It is possible to alternately view the different
layouts in a session.
The analyst has to decide if an overview is to be handled through the SDF and
corresponding Aaa-SCREEN options must be submitted together with the program.
An action bar choice 'Select Layout' must be included in the application screen
program which calls up modules to select user defined 'layouts' (layout number 0199) and prepare output data per line. For more details see chapter 2.3.9 User
defined screens and windows.
Instructions:
A user guide instruction line is always placed on top (or any other convenient
place) 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.
2 - 47
DESIGN STANDARDS
Signify top and bottom of overview:

The same method is used as on AS/400. The right lower corner is used to place
one of 3 patchable (common) constants in high intensity (or white color). For
example: Overview lines go from line 9 to line 20, the patchable constant always
appears in line 21, pos.68-79.
'more......'
'--Bottom--'
'--Top-- '
if more items follow after the last displayed line

if the last item is displayed on that screen, blank lines may appear
between the last data item and line 21
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 the
last screen an informational message is displayed in line 24 and the screen
remains unchanged. Two common constants are available for the informational
message:
'** 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 or
a 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 further
processing. 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.
2 - 48
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 or
high 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=outload
6=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. For
example:
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 the
bottom (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.
2 - 49
DESIGN STANDARDS
2.3.10
User Defined Screens and Windows (Screen Design

Facility)
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 and
window layouts. Screen numbers are BASIS defined, layout numbers are user
defined. Fields are defined with field numbers from the BASIS data dictionary. The
following 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 definitions
F1-F9 for 9 possible records each 7 fields.
Aaa- SCREEN-nn
- SCREEN-nnL
- SCREEN-nnLll
- SCREEN-nnLllFn
- SCREEN-nnB
- SCREEN-nnBll
- SCREEN-nnBllFn
- SCREEN-nnn
- SCREEN-nnnll
- SCREEN-nnnllFn
Main screen header for screen aaSnn

Line definition header for screen aaSnn
Layout header for aaSnn overview line
Field definitions for aaSnn overview line/layout no'll'
Block definition header for screen aaSnn
Layout header for aaSnn block part
Field definitions for aaSnn block part/layout no.'ll'
Window header for window aaWnnn
Layout header for window aaWnnn
Field definitions for window aaWnnn/layout no.'ll'
Separate installation options can be defined per user (uu=user-Id) to

assign him/her (or restrict him/her on) up to 20 layouts...
Oaa-SCREEN-uu
Oaa-SCREEN-uuss
Oaa-SCREEN-uussL
Oaa-SCREEN-uunnB
Oaa-SCREEN-uunnn
... per application aa

... per main screen aaSnn
... per line part of main screen aaSnn
... per block part of main screen aaSnn
... 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.
2 - 50
Screen Standards
Line layout of overview screens:

The line definition ('nnL') allows to define up to 63 fields to be displayed in one line
from left to right. Module XMFP20 prepares one line at a time and the application
screen program has to move lines into the screen format to compose the virtual
overview screen.
Headings are also prepared by the module once at the beginning. The short data
dictionary names (5 long) are used. Signed numeric fields are edited with OXXMASK no.01, dates are edited with separators from OXX-DATE.
For example a line layout as defined in the example in B7, Aaa-SCREEN would
look like this:
---------------------------------------------------------------------------In Adj Adj. Adj.list name

Effect.
Effect. Adj Skip Nxt.rang
putseq 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: input
field for selection, key field (usually ascending), other fields.
Block layout:
The block definition ('nnB') allows to define 02-08 fields to appear in 1-4
consecutive lines in 2 columns:
X---fld1-----X
X---fld2-----X
X---fld3-----X
X---fld4-----X
X---fld5-----X
X---fld6-----X
X---fld7-----X
X---fld8-----X
Each 'fld' element can be 38 bytes long and consists of:

hhhhh xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hhhhh = 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 the
application screen program only has to move this area to the screen format.
2 - 51
DESIGN STANDARDS
Window layout:
The window definition ('nnn') allows to define 1-63 fields to appear in the window
vertically:
hhhhh =
short data dictionary

name as 'heading'
(5 long)
x--fldn----x = field value
and optional
code interpretation
**x---title (optional)-------x**aaWnnn***
*
*
* hhhhh x------fld1-------------------x *
* hhhhh x------fld2-------------------x *
*
|
|
*
*
|
|
*
*
|
|
*
*
V
V
*
* 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 bytes
and a length of 5 to 20 lines. Module XMFP20 supplies an area of 63 x 40 bytes (or
smaller) field elements. The application screen program moves as many field
elements into the window format as possible at a time. With ROLL the application
screen program must be able to page thru all 63 field definitions.
NOTE
THE SDF CANNOT BE USED TO DEFINE INPUT OR SELECTION
FIELDS. IF NEEDED, THEY HAVE TO BE DEFINED SEPARATELY IN
THE FORMAT.
Distribution of Aaa-SCREEN options with programs:

The analyst/programmer of an application must prepare default layouts and submit
corresponding XI01 option records to the test & quality control group. These default
options 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 is
supported on a main screen aaSnn and whether a line part is supported.
2 - 52
Screen Standards
These definitions are made by the analyst and cannot be changed by the user. It is
possible to have both supported on a main screen, or only a block part, or only a
line 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 be
connected 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 number
can be connected to multiple screens. These window connections are made by the
analyst 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. This
program is called from the XIM030 menu item number 01. It asks for the application
and screen number and offers layouts already available. Existing layouts can be
modified and new layouts can be created interactively similar to the IBM QUERY
product.
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 definition
options are created/maintained by the user with program XIP050.
This SDF program also displays data dictionary to select files and fields, it checks
that only files which are defined in the corresponding screen header are selected, it
displays 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 aligned
for 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 user
defined lines, blocks and windows it must have an action bar element for 'Selct
Layout'. If this function is selected from the action bar the application screen
program is terminated (temporarily) and the XIP055 program is called.
2 - 53
DESIGN STANDARDS
This program:
displays a pull-down window with layout numbers allowed for this user (from
Oaa-SCREEN option)
lets the user select a layout number for the Line part, for the Block part and
1-3 windows connected to the currenltly displayed main screen aaSnn
returns to the calling application screen program with selected layout
numbers in the LDA
LDA layout used between application screen program aaPnnn <--> XIP055:
Pos.
aaPnnn --> XIPnnn (input):
XIPnnn --> aaPnnn(output):
256-257 Application 'aa'

258-259 Main screen number 'nn'
260-261 Currently active layout number
'll' of line part (if applicable)
262-263 Currently active layout number
'll' of block part (if applicable)
264-269 Currently active layout number(s)
'll' of 1-3 connected windows
271-272 User-Id 'uu'
273
Position of action bar choice 1-5
(for correct display of pull-down
window) or blank (pull-down window
is displayed in centre of main screen)
(returned unchanged)
New selected layout number 'll'
New selected layout number 'll'
New selcted layout number(s)
(if 'll' applicable)
NOTE FOR THE PROGRAMMER:

IF POS.256-273 ARE ALREADY USED BY THE APPLICATION
COMPLEX, THAN THE CURRENT LDA PSOITIONS CAN BE SAVED IN
THE CALLING PROGRAM AND RESTORED AFTER RETURN FROM
XIP055.
2 - 54
Screen Standards
2.3.11
Function Keys
Definition:
Function keys are all programmable keys of the S/3X keyboard. These are: F1-F24
keys (former command keys CMD1-24), ROLL keys, ENTER key, HELP key.
NOTE
ON PCS THERE ARE A LOT MORE KEYS THAT CAN BE
PROGRAMMED SUCH AS CTRL+ANY LETTER/DIGIT OR ALT+ANY
LETTER/DIGIT WHICH ARE NOT SUPPORTED IN THE S/3X SCREEN
FORMAT GENERATOR!
Use of function keys:

1) For standard functions such as exit or cancel on all panels (see list of standard
F-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). However
keep 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:
2 - 55
DESIGN STANDARDS
CCnn
key=..text..
CC62
CC63
CC64
CC65
CC66
CC67
CC68
ENTER
ROLL up/down
ROLL up
ROLL down
F1=nxt.error
F2=add.info
F3=exit
CC69
CC70
CC71
CC72
CC73
CC74
Meaning
Accept input and continue

Display next or previous page
Display next page
Display previous page
Display next error, if any
Display more information on current error (wrap around)
Exit from current function (back to action bar) or exit from
job if F3 pressed from primary window (EOJ)
F11=acpt.err
Accept warning error (former CMD-12!)
F12=cancel
Cancel window, return to prev.window (back one step)
F23=more fct
Roll functions in action bar horizontally (wrap around)
F24=more key Roll key-descriptions in bottom lines/FMT99 (wrap around)
HELP
Display help text
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 key

descriptions, each 25 bytes long, are still present for old programs but are not used
any longer.
Key descriptions on primary windows (= main screens):
Key descriptions appear in lines 23-24 (FMT99), each a patchable constant of 25
characters in length. Sequence in which they appear: ENTER, ROLL, function keys
ascending, HELP, Selection sign (if applicable).
Only function keys that are really available at that moment are displayed (e.g. do
not display F1/F2 if no error is active). Fast path-keys are not included. Screen
lines 23 and 24 are also used for error messages. If an error occurs the message
line is shown in screen line 23 and key descriptions for F1, F2, F11 HELP plus 2
additional 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 keys
should 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 the
program (do not describe in the format except HELP windows!). For example 'F3 =
2 - 56
Screen Standards
exit ', 'ENTER

Windows.
' or 'ROLL
'. Refer to chapter 2.3.6 for more information on
F24 to roll function-key descriptions in FMT99:

The maximum number of key descriptions in screen lines 23-24 is 2 lines x 6 Fkeys = 12 key descriptions. If this is still too few the F24 key can be used for rolling
of F-key descriptions in FMT99:
On the first display: describe all important F-keys + ROLL + HELP + F24. On the
second display: describe all less important F-keys + F24.
F24 can roll over 2 or more pages of FMT99 without changing data in the panel
body. 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 parameters
can be entered together with the command to replace entry or selection from
windows.
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 selections
offered in the primary pull-down window (optional)
Parameter(s) = BASIS code(s) such as outlet number or document number
which are either typed in the window or are selected from an
overview 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 the
non-patchable '===>' sign.
2 - 57
DESIGN STANDARDS
Entry format:
Commands and parameters separated by the slash '/' can be entered in the
following 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
===> D/AC
===> D/AC/10256
Select main function 'Display'

Select main and subfunction 'Display' 'ACcount number'
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 automatically
opens the window in which the parameter can be entered. From there the user
continues as if he had selected an action bar element.
Naming conventions:
A command or subcommand can be 1-3 characters long. The action bar text
should be in lower case script. The letters used as a command should be in upper
case.
For (primary) commands the first or first 2 characters of the associated action bar
text should be used, for example, Display --> D or DIsplay --> DI.
If two action bar choices have the same starting character than another significant
letter 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.
2 - 58
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 and
100-999 = for subcommands.
It contains a 12-byte action name (displayed in action bar or
pull-down window), a 1-3 bytes command/subcommand (to be
entered in the command line) and a 1-byte action code (to
select 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 initiated
by the programs if either a command was keyed or an action bar element was
selected 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 and
maintainance of Screen-Function options in XI01. It is called from the application
menu.
This program is used by development to create Aaa-SCRFCT options and by the
user to translate into a local language. The program checks for duplicate
commands or texts within the group Commands (function number 001-099) and
within the group Subcommands (function numbers 100-999).
Translation into local language:
The analyst/programmer of an application has to prepare a set of Aaa-SCRFCT
option records with English defaults. They are submitted to the Test & Quality
control 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 the
local commands and texts.
2 - 59
DESIGN STANDARDS
Error messages:
If an invalid command was entered, error message EXX... is displayed in FMT99. If
an invalid parameter was entered (for example a non-existing outlet number) an
application message Eaannn is displayed in FMT99 and the corresponding pulldown 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 the
programmer 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:

Blank or 0 --> No
1 --> Yes
b) Option with multiple values:
Blank or 0 --> for 'non-applicable'
1-9 --> for the actual choices
c) JOBQ/EVOKE processing option:
Blank --> interactive processing
E --> in EVOKE (S/36)
J --> in Job queue
- Print totals 0 = no
1 = yes
- Print totals 0 = no
1 = physical units
2 = converted un.
- JOBQ/EVOKE processing:
blank = interactive
E = EVOKE
J = Job queue
Letters should not be used as option values unless they can be translated by the
user into local languages.
2 - 60
Screen Standards
Error messages for invalid options:

The following XX error messages are available:
EXX042E OPTION VALUE INVALID OR MISSING
EXX154E 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 the
text 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' and
to 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 BE
ALLOWED TO START A REAL FUNCTION IN ORDER TO PREVENT
AN ARBITRARY INITIATION OF A CRITICAL PROCESS!.
Error messages for invalid selections:

The following XX error messages are available:
EXX111E TOO MANY FIELDS SELECTED
EXX112E INVALID SELECTION SIGN, USE SIGN DESCRIBED AT THE BOTTOM
2 - 61
DESIGN STANDARDS
It is preferred to have a more precise application message naming the field in the
text explicitly.
Prompt permitted code interpretation values for an input field:
If an input field requires one to enter an 'anonymous' code such as market
segment', the selection sign from OXX-SELECT, pos.27 can be keyed into pos.1 of
that input field. The default sign is a '?'.
The program shows a window listing all code values and names from the XI01
code interpretation part. From this window the user may select one code by typing
the '*' selection sign in the window. On return to the main screen the program
inserts the selected code value into the input field.
2 - 62
Screen Standards
2.3.14
Input Fields
Field formats for data input:

Sectors
After
Alphanumeric
Stays left adjusted
Padded with blanks
A A A
A A A b b b
Numeric
Right adjusted
Leading Zones
1 2 3
0 0 0 1 2 3
1 2 3
b b 1 2 3
Codes
Amounts and quantities

Signed numeric (Normally not used)
Right adjusted
Leading blanks
(Field Exit + or Field Exit)

1 2 3
b b 1 2 3 -
(Field Exit -)
or
Calculator Mode
Right adjusted
Leading blanks
1 2
. 3 -
- 1 2
. 3
b 1 2
b
. 3 -
- 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 AS
SUCH IN NOTES IN AA/3. NORMAL FORMAT FOR NUMERIC
FIELDS IS CALCULATOR MODE.
2 - 63
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 he
has to do.
Wording:
The text should: Name the fields that have to be entered, selected or just say
how many options are to be entered if they can not be named
individually
Say which button has to be pressed
Standard 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 at
the bottom (line 20-22). More than one line can be used if required. However the
placement at the top or at the body should be consistent within a job (never mix top
and bottom placement!). The analyst should always provide more space than the
English text to enable proper translation into local language.
2 - 64
Screen Standards
Placement in a window:
The instruction line(s) should also be placed at the top of a window. Refer to
chapter 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 in
lower 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 per
error code. Message line 1 is displayed in screen line 23, and message lines 2-9
are displayed in screen lines 23-24 when F2 is pressed, two at a time. Refer to
chapter 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 than
one error occurred on a window at a time. F1 diplays the message line 1 of the next
erroneous field in screen line 23 and leaves the function key descriptions in screen
line 24 unchanged. Wrap around is done automatically when F1 is pressed from
the last error.
F2 additional information on current error:
F2 is also a BASIS standard function key to roll through the message lines 2-9 of
one specific error. Every time F2 is pressed 2 more message lines are displayed in
line 23-24, as many as are available for an error code. If at the end it automatically
wraps 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 warning
errors and let the program continue with the default action as described in the error
message. F11 is only allowed if a warning error is displayed and no terminal error is
present. For more information refer to T3,2.2.
2 - 65
DESIGN STANDARDS
Informational messages:
Informational messages are messages that inform the user. They usually do not
require 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, 'Article
groups are being loaded'
that an action has been successfully completed, for example, 'Payment has
been applied in B/F mode to number of invoices.. 25'
Information window:
Temporary messages that inform the user about a longer action are displayed in
windows. The window appears as soon as the action is started (for example,
'Article groups are being loaded') and disappears when finished. Refer to chapter
2.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 such
as '***Payment has been applied. Select next account.'
Such messages are patchable constants. They are headed by 3 asterisks '***' and
are displayed in high intensity (or white on color screens). They disappear as soon
as 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 either
the F1-key or selecting HELP from an action bar with selection possibilities (Help
index, extended Help, Keys Help, and so on).
The HELP key on the S/36 is system supported and needs no programming in
application programs! It is always bound to the cursor position.
2 - 66
Screen Standards
Use:
Help is supported:
a) On menues:
to explain what each item does
b) 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 more
information on Windows.
Shape of Help windows:
The size of Help windows should be kept small. It is preferred to rather spread text
for one input field over several pages (in this case ROLL UP and DOWN keys must
be 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 help
text any place that does not hide valuable information on the main screen is
possible.
Placement of Help windows for working windows:
The help window should be placed so that it overlaps the working window without
covering the input (or other) fields that it explains.
Examples:
*************
*
Working*
*
*
*
*
*******_____________
|
Help |
|
|
|____________|
_______________
|
Help
|
|
|
|_____________|******
*
Working*
*
*
*
*
**************
2 - 67
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 the
sequence they occur in the format source member. Formats should always be in
the same order that input fields are on the screen.
The first Help format is a general description that can only be reached by the user
thru ROLL DOWN from the Help format of the first input field or thru ROLL UP from
the function key Help format (therefore ROLL UP and DOWN keys must be
described at the bottom of a window!)
The last Help format is a description of all valid function keys. It can only be
reached by the user thru ROLL UP from the Help format of the last input field or
thru ROLL DOWN from the general description Help format (therefore ROLL UP
and 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 a
protected area of the screen. However, if provided for important fields, the same
rules 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 input
format. Therefore, if a help window has a pure output format, entry in main screen
input fields is still possible. Any input would be lost as soon as the Help format is
exited. This is misleading for the user!
In order to prevent entry in input fields which are still visible on the main screen, the
first 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 from
SAA standards which uses F3.
2 - 68
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 Managers
will be encouraged to translate sample screens in aa/3, Workstation User Guide for
their 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 screen
constants. Patching of programs is done first. Then the programs should be
executed and live screens (using patched programs) should be checked.
Standards for patchable constants:
1) Format member name must be aaFnnn (nnn = same number as associated
program)
2) Name of each format within a format member must be:
FMTnn
for application formats and windows

nn = 01-99, unique number within format member aaFnnn
2 standard formats are always present (see XMF999 in SYSMOD
library)
FMT01 = heading line 1
FMT99 = bottom lines 23-24 for function key descriptions and error
messages
FMTHxxnn
for help formats, old standard still supported, not used in new
applications (with xx = any alphabetic combination AA-ZZ and
nn = 01-99, unique within format member also incl. FMTnn!)
FMTnnnn
for help formats, latest standard (nnnn = any 4 digit number

0000-9999. Structure such as sshh is recommended with ss = main
screen number and hh = help format number within screen)
3)
Formats (FMTnn) within a format member must be in ascending sequence by

format number (nn). Help formats (FMTHxxnn or FMTHnnnn) follow after the
last application format, also ascending by format number (nn without xx, or
nnnn)
2 - 69
DESIGN STANDARDS
4)
The first format wihin a format member must always be standard format
FMT01. 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 are
also included.
5)
The modification level in standard format FMT01 must be incremented by two

each time a modification is made to a format member. The fieldname in the
S/36 SFGR specifications must be 'FMTLEV'.
6)
A 4 or 5 digit sequence number must be present for each statement of a

format 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 position
43-44 (NONDISPLAY) of a field description record.
10) As soon as the "NONDISPLAY" field is blank, or contains an indicator, any

data found in pos.57-79 of a field description record is selected for patching.
2.3.19
1)
Performance Considerations
Minimum Amount of Data
Screens should be designed so as to minimize the amount of data transmitted to

an 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 and
DDS on AS/400). COBOL on both machines includes special WRITE operations
which actually imply two output operations:
2 - 70
Screen Standards
a)
sending complete format specifications to the terminal and setting up the

format accordingly; the format is retained in the terminal until a new format is
sent 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 as
to avoid unnecessary transmission of format specifications:
a)
"Override"
OFF
if a format is written the first time or replaces another format
ON
if a format is redisplayed with new data (for example ROLL)
b) "Erase Input Fields
OFF
if an input format is being written the first time or if the
input field values remain unchanged
ON
if the same input format is cleared (= erased) to
receive the following input.
3)
Use of "Suppress Input"
Every format with output fields should specify this indicator in order to completely
skip the input routine when executing a WRITE operation. This results in a faster
response time.
NOTE
"ENABLING/DISABLING" OF FUNCTION AND COMMAND KEYS NEED
NOT BE SPECIFIED ALONG WITH "SUPPRESS INPUT"
2 - 71
DESIGN STANDARDS
4)
Save screen image
For programs which exeed the program size of 64K it is not possible to keep all
used screen formats in the WSO-definitions of the working storage. Therefore, a
so-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 members
Key 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 the
screen memory work file. If the formats need to be redisplayed and previously
displayed data has not been changed, only one I-O is needed to read the previous
format from the screen memory workfile and redisplay it.
2 - 72
Report Standards
Screen
2.4
Report Standards
2.4.1
Report Documentation
The term "reports" is applied to all computer printed output. The term "lists" is
reserved for the system function XL lists.
aa, Application Manual
aa/1 Overview
section 1.3 (Overview of Processing Functions) may

contain sample major reports
aa/2 Description
section 2.3 (Processing Functions) contains sample

reports for further illustration
section 2.5 (Sample Menus and Reports), 1 page per
report
aa/3 Activities
each activity section includes sample reports with regards

to 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 for
explanations
used for development maintenance
Laa, Program Logic

Manuals
no documentation of reports included.
2 - 73
DESIGN STANDARDS
2.4.2
Report Sizes
For standard reports, two sizes are proposed. See attached examples:
Full report
Quarto report
132 print positions

100 print Positions (10")
The Quarto report corresponds to quarto paper (8.5" wide, 11" high) and can be
copied 1 to 1 on normal copying machines. It is envisaged to use this size for a
wide range of reports where additional copies may be made frequently. It can also
be filed, conveniently, in normal binders as day-to-day correspondence.
2 - 74
8"
7"
6"
5"
4"
3"
2"
1"
1 BASIS aaPnnnc 00
CCnnn YY/MM/DD HH.MM.SS US WS
PAGE XXXX
2 X-------------------------------------------------X
X---------------------------------------------------------X
3
(COMPANY/LOCATION NAME)
(REPORT DISTRIBUTION)
4 X----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------X-----X
5
(REPORT HEADING)
6
7
8
9
10
11
Eaannn t X------------------------------------------------------------------------------------------------------------------X
12
(ERROR MESSAGE, if applicable)
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
EXAMPLE FULL REPORT
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
0
1
2
3
4
5
6
7
8
9
10
11
12
13
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
PRINT LAYOUT
Screen Standards
2 - 75
2 - 76
8"
7"
6"
5"
4"
3"
2"
1"
1 BASIS aaPnnnc 00
CCnnn YY/MM/DD HH.MM.SS US WS
PAGE XXXX
2 X-------------------------------------------------X
X-------------------------------------------------------X
3
(COMPANY/LOCATION NAME)
(REPORT DISTRIBUTION)
4 X----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------X
5
(REPORT HEADING)
6
7
8
9
10
11
12 Eaannn t X------------------------------------------------------------------------------------------------------------------X
(ERROR MESSAGE)
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
EXAMPLE QUARTO REPORT
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
0
1
2
3
4
5
6
7
8
9
10
11
12
13
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
PRINT LAYOUT
DESIGN STANDARDS
Screen
Report Standards
As many as 9 different form lengths may be defined by the user. The appropriate
number of print lines available are defined as installation options in the System
Control 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 THE
NUMBER 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
Standard Heading
BASIS
Program Name
Program Modification Level
License Contract no.
Date
Time
User ID
WSID
Page Constant
Page Number
Length
5
6
2
5
8
8
2
2
6
4
2 - 77
DESIGN STANDARDS
Standard Heading
Company Name
Report Distribution
First Header Line
Variable
30
30
132
Error Message right adjusted
76
Quarto Report
As above, compressed.
2.4.4
Field Definitions for Data Output
These are identical to screen definitions for data output:

Unedited Field
Edited Field
(American Style)
Patchable Constants
XXXX
XX/XX/XX
X,XXX.XX...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 X
symbol.
2 - 78
Disk
File Standards
Screen
Standards
2.5
Disk File Standards
2.5.1
Disk File Layout
Application and System Function disk file layouts (aann and Xsnn) are filed
under B6, except the System Control File XIO1 layouts which are filed under B7.
Page identification: Manual
B6
Section
aann-x
Xsnn-aa
Page
Page
x = Record format code
aa = Application Code (if
records for more than
one application exist)
File Name
B7
X-----X
(record key, high order part)
Page
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 with

letter 'K' in field name column.
Organization
- S Sequential, D Direct, I Indexed.
File Name
- for example, OM01 - Outlet Master
1
XXXX
10
X---------X
2
X
4
3
XXXX XXX field
-------------XX*
table
XXX
2 - 79
DESIGN STANDARDS
Explanation of Columns
FIELD NO.
1)
FIELD NAME
Required only when maintenance using field number is allowed

or field can be used by control lists.
2)
TYPE
1) Additional field name information

for 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
A
N
NP
S
SP
SO
B
I
alphanumeric (code or data)

numeric code
numeric code packed
signed numeric (amount quantities)
signed numeric packed
signed numeric optionally packed
binary
index value
Decimal fixed positions within an amount field, as a rate conversion

factor, 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
2 - 80
10*
2
valid locations
Screen
Disk
File Standards
Example 2:
G
Non-elementary field occuring more than once

DATA
A
N
21
20*
6
(1)
(3)
2
4
Distribution Option
market subsegment
distribution %
relative start position within
element (optional)
Example 3:
Positions in record not used

61
free
2) Field Data
The field definition will be a 1:1 of COBOL Copybook modules XFaann. Only
elementary fields are included. Group items are shown to structure fields and assist
programmer in redefining a record in the Working Storage Section.
3) Standard field sizes
per outlet
ship-to
Q
$
7 (4)
11 (6)
7 (4)
11 (6)
5 (3)
9 (5)*
per year
per month
per day
per group
of outlets
Q
$
9 (5)
13 (7)
9 (5)
13 (7)
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)
2 - 81
DESIGN STANDARDS
Adjustment rates: 7 (4) = a) for value per case 1 decimal more than prices
b) 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
D
1-4
5
6-9
=
=
=
=
=
all header records (may not be deleted)

ready for physical deletion from the file
different statuses of validity and completeness
data in record is correct and ready to be processed
different statuses for logical deletion during processing.
2) Key (for indexed files) or other "record identification" (for other files). (These
include record code(s) used for identification.) When the records are organized
in continuation sets, the rightmost positions of the key or record identification
are 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
2 - 82
Screen
Disk
File Standards
2.5.3
Multisegment Records
The first record in a continuation set has 'n' fixed length segments (usually 16
bytes), right adjusted in the record following the record sections 1) through 7)
described in 2.5.2.
KEY
FIXED PORTION
(SIMILAR STRUCTURE AS NORMAL RECORDS)
SEGMENTS
The following records in a continuation set can have a shorter fixed portion (only
sections 1) through 3) are needed) and therefore more segments.
2 - 83
DESIGN STANDARDS
2 - 84
Standards
CL/ProgramScreen
Communication
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 to
be used in a program or vice versa, write program options to the LDA to be
further used in CL.
2)
pass data between programs, that is, write program options to the LDA to be
used in the next program
3)
take a job step checkpoint (CP), that is, save all CL information to the Job
Control File valid at a certain point of processing, a so-called CP
NOTE
THE LDA SHOULD NOT BE USED IN COBOL PROGRAMS WHICH
READ CL PARAMETERS ONLY. IN SUCH CASES, THE ACCEPT
METHOD 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 as

update, data entry.
The stand-alone jobs can freely access all LDA positions, 1-512. The XJ controlled
jobs can only use positions 1-100. The remaining positions, 101-256, are reserved
for XJ (Job Control) and XR (Restart). Positions 505-512 are reserved for multiple
application jobs. All jobs which may run in multiple application processing may not
use pos. 101-256 for own positions. The standard layout of the LDA follows. For
further details concerning positions 101-256, refer to TXJ and TXR.
2 - 85
DESIGN STANDARDS
NOTE
ON THE AS/400 THE LDA HAS A LENGTH OF 1024 BYTES. THE
FIRST 512 BYTES (USER AREA) ARE DESCRIBED HERE. THE
SECOND 512 BYTES (SYSTEM AREA) ARE NOT DEFINED AND
SHOULD NOT BE USED. THIS AREA IS RESERVED FOR BASIS
DEVELOPMENT.
512
G
LDA - Standard Layout for XJ

100
CL/Program Options
Subdivided into fields as required
101
49
Job Information
RESTCOND
101
Restart condition (blank = no restart,

'R' = Restart, 'S' = Suspend, 'C' =
Cancel)
MENUITEM
102
Menu Item aaMnnnii (ii = item no.

01-24)
110
Execution type 'b'

=
Interactive
J = Submitted to JobQ
E = 'EVOKED'
111
XJ02 Existance Indicator

1 = XJ02 is not existing
112
Work indicator used by programs

XJP020, XJP050, XJP060
113
Stop run/exit switch

1 = exit program
not 1 = stop run program
EXTYPE A
XJ02EXIST
AS400EXIT
This position is used because it is

cleared by XJ during job start-up.
2 - 86
USERID
114
User-ID (who started the job)
WSID
116
Workstation-ID (from which started)
MICNO
118
Message Member Number (4nnn6nnn)
JOBNOSUF
122
Job Number Suffix
CL/ProgramScreen
Communication
Standards
512
CTLJOBNOSUF
124
Control Job Number Suffix

(see XJ01 File)
(Job no. of multiple application job)
LIBRARY
126
Library Name (Sign-on)
134
Free File Suffix used in complex

(for automatic save)
FSUFFIXA
MESSAGEMBR
136
Name of the Message Member in use

(for example, BASISMSA)
COMPLEXNO
144
Complex Number
PERYEAR
146
PERTYPE
PERNUMB
A
N
147
148
1
2
Rightmost byte of
period year
Period type
Period number
150
92
Checkpoint Information
150
36
CL Parameter (as entered on S/34;

no padded blanks and separated by
commas, for example,
LIST,A,,,100)
186
20
Reserved for BASIS use
SAVMIL
206
Auto safety copy 'SAVE MEDIA

MIC'
SWITCHES
210
Switches 1-8
CPTAG
218
CL Tag Name
CLEANUP
226
CL Complex Name for 'CLEAN-UP'
CANCEL
234
CL Complex name for 'CANCEL'
FILEGROUPC
242
Company File Group Code (should

be blank)
FILEGROUPL
244
Location File Group Code (for

example B)
LOCATION
246
Location Code (for example 01)
G
CLPARAM
for automatic save

of SD files
2 - 87
DESIGN STANDARDS
512
MSGSAVE1
248
Message number for first safety

definition of complex
b = no save
MSGSAVE2
252
Message number for second safety

definition
SAVESIGN
256
Savesign
1 = save has to be done
(Set by automatic save creation
program)
XO01NAME
257
Option file label (for example,

A.XO01), used in XLP070, XLP075
265
199
464
465
19
Reserved
484
10
Complex security options (see B7,

AXX-ENDOPT), set by header
program aaP001
494
Reserved
502
Sequence no. application complex

in MUAP (written by XJP950, read
by XJP010)
PGMTEMFLG
LDAENDOPT
2 - 88
free
Native program termination flag
b = normal termination with
'GO BACK'
1 = abnormal termination with
'END PROGRAM'
MUAPVERS
504
Version number of multiple

application job
MUAPDATE
506
Processing date of multiple

application job (CYYMMDD)
(or date for automatic save if used
in file label)
601 25*10
Library names (AS/400 only)

Positions 601 - 850 are updated by
XXP210, in XJC001, and are used
by CL program XXP215 to update
the library list from within MRT
procedures.
CL/Program
Communication
Screen
Standards
LDADUM
924
LDACOMARE
925
100
Reserved for dummy write to LDA

A dummy write, using the S/36
'LOCAL' command, to this position
causes the following LDA read,
"?L,nnn,nnn?" statement to use the
LDA SYSTEM area.
Communication area between
Driver program and S/36
environment programlayout is
application 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 positions
1 through 100 as needed.
The utilization of the LDA is documented in:
Taa,3, Complex Specifications common LDA fields used throughout the complex
Laa, aaPnnn.1, General
all LDA fields used in a specific program
(common as well as program dependent)
2 - 89
DESIGN STANDARDS
2 - 90
Screen
Program
Standards
Design
2.7
Program Design
1)
Programs should be kept as small as possible. Whenever feasible, overlays

will be used, for example, for program initialization and termination as well as
for different functions in interactive programs (that is, processing different
screens)
2)
Alternatively a program can be split into separate programs (for example, one
for each interactive function) but this is much slower than using overlays (2 to
4 seconds instead of 0.1 second).
3)
When an interactive program is split into multiple programs the RUF (Read
under Format) technique can and should be used when applicable to overlap
data 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 data
must be passed, the LDA must be used (not the Job Control File that saves
LDA for a restart). The program should also function without modification on
systems which do not support RUF (or which do not support the LDA but can
read 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 THE
SCREEN.
4)
All programs must be SRT (single requesting terminal) programs. MRT

(multiple requesting terminals) is not used.
2 - 91
DESIGN STANDARDS
2 - 92
Screen
Standards
Module
Design
2.8
Module Design
Two main groups of modules are present:

1)
modules covering one or more functions in a general and flexible way, known
as program respectively procedure frames.
2)
modules covering one or more functions in a fixed way. These modules are
CALL 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 adapt
the 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 cannot
be changed.
In order to decide whether a module should be a CALL module/subroutine member
or 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 parameters
and so on)
2 - 93
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 on
S/38).
If a module has to be put into an overlay due to program size, an overlay
linkage editor run must be performed separately.
Performance for CALL module is 5-10% below a "performed" module (COPY
module) with the same functions (parameter transfer).
A CALL module is bigger than a "performed" module (COPY module) with the
same functions.
If a module has to perform I/O on disk files it should be a COPY module (due
to OPEN and so on).
If field names, PICTURE clauses, and so on are not fixed, the module must
be COPY module to allow REPLACING during compilation.
Standards
For programming standards, naming conventions and using standards, see T3 - T5.
2 - 94
Naming Conventions for

COBOL Programs
COBOL
Programming Standards
3.1
Objectives 3-3
3.2
Overview 3-5
General Remarks 3-5
Notation 3-5
3.3
Structured Programming 3-7

Standard Elements: 3-7
Coding the Standard Elements in COBOL 3-10
3.4
Naming Conventions for COBOL Programs 3-19

Paragraph Names 3-19
Special Names (Mnemonic Expressions) 3-23
File Description Entries (FD) 3-23
Working Storage Section 3-27
Standard Words and Prefixes 3-33
3.5
Standards for Patchable Constants 3-37

Common Constants 3-38
Program Constants 3-40
Program Error messages 3-48
3.6
Coding and Efficiency Techniques 3-51

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

Structure of Working Storage Section. 3-61
Structure of Procedure Division 3-63
COMMENTS 3-64
3.8
Program Administration 3-67
3-1
3.9
Program Modules 3-69

"Dummy Parameters" 3-71
Administration Documentation and Comments 3-73
3.10 S/36 - S/38 Considerations 3-75

Programs 3-75
Screen Formats 3-79
3-2

COBOLObjectives
Programs
3.1
Objectives
The use of programming standards is essential in the modern data processing

environment. The structured programming technique forces management to
develop general programming and coding rules to ensure compatibility of program
modules written by different programmers. Maintenance of a standardized program
is made easier since the structure of every program is similar. Similar problems are
solved similarly in different programs using, for example, the same file
specifications, tables, fields, as well as the same program logic.
It is obvious that the programmer will see standards as a restraint. He might not be
willing to use a predefined field name or even a full solution (done by a module) in
his program. However, the aforementioned advantages will soon enable the
programmer to spend more time on the interesting parts of a program while a
predefined code does the "routine work".
3-3
3-4

Overview
COBOL Programs
3.2
Overview
3.2.1
General Remarks
All standards documented in this manual are mandatory for all programmers writing
COBOL programs, screen formats or a CL procedure. However, each user is free
to 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. They
must be used as specified and must not be changed by the programmer. In
addition, no other words (or abbreviations) identical to a reserved word must
be used.
The expression "mnemonic" indicates that the programmer may insert any
desired term.
Example:
SWITCH - mnemonic
fixed
free
The length of the mnemonic character string should not exceed 10-15 positions.
3-5
3-6

Structured
Programming
COBOL
Programs
3.3
Structured Programming
BASIS II development follows the rules of "Structured Programming"! "Structured

Programming" no longer is a "buzz word" and since the late 70's has become an
accepted practice; common rules and standards have been established and are
internationally accepted.
3.3.1
Standard Elements:
The five basic elements of structured programming are:

SEQUENCE
IF-THEN-ELSE
CASE
DOWHILE
DOUNTIL
Comments on each element follow.
3-7
1) SEQUENCE
One or more single steps

are executed sequentially.
2) IF-THEN-ELSE
True
False
C
Execution depends on a condition C.

If C is true THEN A is executed,
ELSE if C is false B is executed.
True
False
C
Or A is only executed if C is
true and the ELSE-path is empty.
3) CASE
C1
Else
C2
A1
3-8
A2
Cn
An
Only one of A1 thru An

is executed at a time
depending on condition C1
thru Cn; if, for example, C2 is
true A2 is executed and C3
thru Cn are not tested further.
In case that none of the
conditions C1 thru Cn are
true an ELSE path should
be provided (for example,
error routine in B).

Structured
Programming
COBOL
Programs
4) DOWHILE
Iteration of A:
False
C
True
DO A WHILE a condition C is true.

Condition C is tested before the
execution of A; thus A may not be
executed at all if C was initially false.
5) DOUNTIL
Iteration of A:
DO A UNTIL a condition C is true.
Condition C is only tested after the
execution of A; thus A is executed at
least once.
False
C
True
6) COMPOUND STRUCTURES
The five basic elements may be combined by replacing a box with any other structureelement. This can be done with no problem because each element has a single entry
point and single exit-point; a GO TO from one structure element into another is not
possible.
For example: take an IF-THEN-ELSE and replace box A by a DOWHLIE and box B by a
CASE:
3-9
C1
BOX A
BOX B
C3
C2
S1
C4
S2
C5
Else
S3
3.3.2
Coding the Standard Elements in COBOL
Despite the common features of structure elements, there remain a number of

ways to code them in COBOL, depending on the taste and habits of the
programmer. The following standard COBOL elements are used in all BASIS
programs to
make sure that COBOL programms follow the rules of structured
programming
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.
3 - 10

Structured
Programming
COBOL
Programs
NOTE
STRUCTOGRAMS (SEE 1.3.5) ARE USED INSTEAD OF FLOWCHART
SYMBOLS BECAUSE ACTUAL CODING IS ALWAYS DONE FROM
STRUCTOGRAMS.
1)
SEQUENCE
all basic COBOL instructions such as MOVE, ADD, SET, and the simple
PERFORM... THRU...
2)
IF-THEN-ELSE
Overflow
Y
N
***** EXAMPLE IF-THEN
Yo1
PRINT
HEADINGS
IF C-OVERFLOW
PERFORM Y01-PRINT-HEADINGS THRU Y01-EXIT
MOVE ZEROS TO W-LINE-COUNTER
Clear linecounter
NOTE
INDENTATION OF 3 POSITIONS IS RECOMMENDED.
3 - 11
b) IF-THEN-ELSE
***** EXAMPLE IF-THEN-ELSE
Amount positive
Y
Add Amount
to
Debit-Total
IF W-AMOUNT IS POSITIVE
ADD W-AMOUNT TO W-DEBIT-TOTAL
IF CI-CREDIT-CUSTOMER
PERFORM 52-PASTDUE-CALCULATION THRU 52-EXIT
ELSE
NEXT SENTENCE
Subtract
amount from
Credit Total
Credit
Customer
Y
ELSE
SUBTRACT W-AMOUNT FROM W-CREDIT-TOTAL
52 PASTDUE
Calculation
c) all Input-Output operations in COBOL:

READ
READ
WRITE
REWRITE
START
DELETE
with
with
with
with
with
with
AT END
INVALID
INVALID
INVALID
INVALID
INVALID
KEY
KEY
KEY
KEY
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 "AT
END" or "INVALID KEY" condition can be handled outside via the "File Status."
MOVE ART. NO. TO RECORD KEY
***** EXAMPLE IF-THEN-ELSE WITH "READ....INVALID KEY"
Z05-AM01-READ
RECORD PRESENT
Y
MOVE FROM FDMOVE SPACES TO

AREA TO WORKING WORKING-STORAGE
STORAGE-AREA
AREA
3 - 12
MOVE WSI-ARTNO TO KEYAM01

PERFORM Z05-AM01-READ THRU Z05-EXIT.
IF FS-AM01-SUCCESSFUL
MOVE AM01REC TO AM01 WORKREC
ELSE
MOVE SPACES TO AM01-WORKREC.
Z05- AM01-READ
READ AM01 INVALID KEY GO TO Z05-EXIT.
Z05- EXIT.

Structured
Programming
COBOL
Programs
d) STRING/UNSTRING with ON OVERFLOW

***** EXAMPLE IF-THEN-ELSE WITH "UNSTRING"
UNSTRING WS-LINE
DELIMITED BY SPACES
INTO SEL-WORD
DELIMITER IN W-BLANKS
ON OVERFLOW
Y
SET END-OF-LINE
TO
TRUE
4351
Check
Sel-Word
Error
Y
Set 4351
Error-in
Line to
true
N
Interpret
Sel-Word
435- UNSTRING-EXAMPLE.
UNSTRING WSI-LINE DELIMITED BY SPACES
INTO W-SEL-WORD
DELIMITER 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 TRUE
ELSE
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.
NOTE
THE "ON OVERFLOW" CLAUSE SHOULD NOT CONTAIN ANY
ACTUAL STATEMENT
3) CASE
a) Series of IF's and GO TO's (simulating nested IF's)
"A"
***** EXAMPLE CASE WITH "NESTED IF'S"
RECORD-CODE
31Process-rec.A
"B"
32Process-Rec.B
"C"
33Process-Rec,C
Else
XMER02
Stop-Error
3-PROCESS.
IF RECODE EQUAL "A"
PERFORM 31-PROCESS-REC-A THRU 31-EXIT
GO TO 3-EXIT.
IF RECODE EQUAL "B"
PERFORM 32-PROCESS-REC-B THRU 32-EXIT
GO TO 3-EXIT.
IF RECODE EQUAL "A"
PERFORM 33-PROCESS-REC-C THRU 33-EXIT
GO TO 3-EXIT.
PERFORM XMER02-STOP-ERROR THRU XMER02-EXIT.
3-EXIT.
3 - 13
b) GO TO DEPENDING ON (only if an integer is tested)
***** EXAMPLE CASE WITH "GO TO DEPENDING ON"
MARITAL STATUS
2
Move
"Married"
to
Print Line
3
Move
"Single"
to
Print Line
Else
Move
"Divorced"
to
Print Line
Move
"Undefined"
to
Print Line
852-CASE-EXAMPLE.
GO TO
852-SINGLE, 852-DIVORCED
DEPENDING ON W-MARITAL-STATUS.
852-UNDEFINED.
MOVE "UNDEFINED" TO RPT-MARITAL-STATUS
GO 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.
c) SEARCH with several WHEN's and AT-END (the AT-END clause is the ELSE path)
SEARCH ART-TABLE
Art. No.
found
Add
Units/Subunits
Key-Art-No. compared to
WS-Art. No.
Next
greater
At
end
371
INSERT Art
(Shift all greater
elements by 1 &
insert new Art.
at T5).
Y03
Write Array
NOTE
THE "WHEN" AND THE "AT END" CLAUSES
SHOULD NOT CONTAIN ANY ACTUAL
STATEMENT.
Clear
Art-Table
3 - 14

Structured
Programming
COBOL
Programs
***** EXAMPLE CASE WITH "SEARCH"

37-SEARCH-EXAMPLE.
SEARCH T5-ART-TABLE VARYING T5
AT END
WHEN T5-ARTNO(T5) EQUAL
WSI-ARTNO
WHEN T5-ARTNO(T5) GREATER
WSI-ARTNO
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.
GO TO 37-ARRAY-FULL
GO TO 37-UPDATE-ART
GO TO 37-INSERT-ART.
4) DOWHILE
The PERFORM....UNTIL in COBOL is a mixture of the 2 elements DOWHILE and
DOUNTIL; the condition is tested before performing the routine but if it is true it means
discontinuation instead of continuation (it also says UNTIL not WHILE). It becomes a
WHILE 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 NOT
END-OF-LIST
43
Process
List-Element
(If pointer is zero end of list
is reached, else move pointer
to T1).
***** EXAMPLE DOWHILE WITH "PERFORM....UNTIL NOT"

SET T1 TO 1.
PERFORM 421-PROCESS-LIST-ELEMENT
UNTIL T1-ARTNO(T1) NOT LESS WSI-ARTNO
OR C-END-OF-LIST.
3 - 15
b) PERFORM ...... TIMES
START XI01 AT OXX "MASK"
16 TIMES
15-EDITMASK
***** EXAMPLE DOWHILE WITH "PERFORM....TIMES"

START XO01 KEY NOT LESS "OXXMASK
"
PERFORM 15-EDIT-MASK THRU 15-EXIT 16 TIMES.
(Read edit-mask records

from System Control File
and load into table).
c) PERFORM ...... VARYING ... FROM ... BY ... UNTIL
T2 = 1-100
and ELEMENT (T2) not blank
612Art-Line
***** EXAMPLE DOWHILE WITH "PERFORM....VARYING...UNTIL NOT"

PERFORM 612-ART-LINE
VARYING T2 FROM 1 BY 1
UNTIL T2 GREATER 100
OR T2-ELEMENT(T2) EQUAL SPACES
(Extract from table and

edit/print an article line).
5) DOUNTIL
There is nothing in COBOL directly supporting this iteration process. Although the
PERFORM ...... UNTIL contains the correct condition test (UNTIL = discontinue when it
becomes true) the test is done before performing the routine. There are two possibilities:
3 - 16

Structured
Programming
COBOL
Programs
a) Self programmed loop in which you can put one or more UNTIL conditions anywhere
between starting and ending paragraph:
Z01
WSFILE
READ
(Read input
format)
CMD 1 (EOJ)
3-PROCESS
WRITE-WS
Process input
format received
and write new
format)
***** 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.
CMD 3 (Call New Prog.)
Z04
OM60WRITE
(Write record
to Transaction
File.)
b) Use a PERFORM .... UNTIL and initially set the condition to false. Note that only one
UNTIL condition is possible and that it must always be put in front. Moreover combine all
steps of a loop into a procedure. (For example, PROCESS-WS is a new procedure used
to combine WSFILE-READ, PROCESS-WRITE-WS, OM60-WRITE, into a single,
performable procedure).
UNTIL CMD-7
OR
CMD-3
3-PROCESSWS
(Read and process input-record
from workstation, write new
formats, and write record
Transaction File.)
***** EXAMPLE DOUNTIL WITH "PERFORM .... UNTIL"

UNTIL CMD-EOJ
OR CMD-3.
3-PROCESS-WS.
PERFORM Z01-WSFILE-READ THRU Z01-EXIT.
IF CMD-EOJ
GO TO 3-EXIT
IF CMD-3
GO TO 3-EXIT.
PERFORM Z04-OM60-WRITE THRU Z04-EXIT.
3-EXIT.
3 - 17
3 - 18

COBOL Programs
3.4
Naming Conventions for COBOL Programs
3.4.1
Paragraph Names
Each paragraph name has 2 parts: a module identification part and a mnemonic
part:
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.
21-mnem.
3-mnem.
9-
A-
22-mnem.
221-mnem.
222-mnem.
3 - 19
The number of characters within the identification part indicates the level of the
corresponding 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 a
level.
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 the
program. 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 = 0199)
22-mnem.
Ycc-mnem.
221-mnem.
2211-mnem.
Ycc-mnem.
the paragraph name for Y-common modules is Yc-mnemonic and can in turn
be structured with level numbers added to Yc (for example, Y11 called from
Y1)
3 - 20

COBOL Programs
Yc-mnem.
Yc1-mnem.
Yc2.mnem.
2211-mnem
Ycc-mnem.
EXIT paragraph
cccc-EXIT, where "cccc" is the module identification part.
for example, 221-EXIT
Z41-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 be
uniform within the program.
paragraphs for I/O operations (non-workstation files). All I/O operations have
to be specified in paragraphs having standard names:
module identification part
Znn
file name
aann (disk)
RPT (printer)
LDA
OCL
DATE-TIME
- I/O operation
- READ
WRITE (mnomonic)
REWRITE
START
DELETE
READNEXT
3 - 21
Znn
01-50
51-95
96
97
98-99
free
reserved for system files
DATE/TIME read
OCL-read
LDA
for example, Z51-XI01-READ

Z03-OM40-START
Z07-RPT-WRITE
Z19-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-WRITE
Z04-FMT02-04-WRITE
Z14-WSFILE-READ
LDA and OCL
Z97-OCL-READ (refer to 2.6.2)
Z98-LDA-READ
Z99-LDA-WRITE
System Date and System Time
Z96-DATE-TIME-READ
System files (fixed Znn-number to standardize use in XM modules)
Z51-XI01-READ (random by RECORD KEY)
Z52-XI01-REWRITE
Z53-XI01-READNEXT (sequential by RECORD-KEY)
Z54-XJ02-READ
Z55-XJ02-REWRITE
3 - 22

COBOL Programs
3.4.2
Special Names (Mnemonic Expressions)
Special Name Paragraphs:

UPSI-0 is SWITCH-1 - mnemonic
ON IS SW1-ON-mnemonic
OFF IS SW1-OFF-mnemonic
SYSTEM-SHUTDOWN IS SHUTDOWN
ON IS SHUTDOWN-ON
OFF 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 comparable
to the DDS record formats on S/38 are available.
These descriptions, stored in COPY modules, must be copied into the FD's of the
COBOL programs.
3 - 23
The modules are structured as follows:

name of module:
XFaannc (aann= file name, c = suffix if multiple COPY modules exist for the
same file)
the name of the "record format" (level 01) is aannRECc (where "aann" is the
name of the file concerned and "c" is the record format code (that is, record
code 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 (RENAMES
the 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 the
SELECT clause of the file concerned.
The 66 item will be used to automatically generate key fields for the D/38
DDS.
Example
FD OM40
COPY XFOM40
written by programmer
01 OM4REC
frame XFOM40 (copied
06 COMPANY
PIC
into program during
06 OUTLETNO
.
compilation
06 NAME
.
.
.
.
.
06 PRICELIST
PIC
66 KEYOM40 RENAMES COMPANY THROUGH OUTLETNO.
3 - 24

COBOL Programs
If the field names are not unique within the program, that is, same name used in
multiple files or records, the qualification feature of COBOL is used.
If any further structuring of predefined input and/or output fields is needed in the
program, two possibilities exist for the programmer:
specify these additional record formats in the FD (that is, use REDEFINES at
01 level following the COPY statement)
use separate I/O areas in the Working Storage Section which are processed
via the READ INTO/WRITE FROM or MOVE operation codes.
For the additional record formats in the FD the same standards as used in the
Working Storage Section must be applied (see 3.4.4):
01 aannc - mnemonic
05
aannc-mnemonic
.
05
aannc-mnemonic
NOTE
THE STANDARDS FOR EXTERNAL FIELD DESCRIPTIONS (NAME
LESS 11 BYTES, NO HYPHEN, AND SO ON) NEED NOT BE APPLIED
HERE.
The use of either method is up to the programmer. When these areas are specified
in the Working Storage Section rather than in the FD area, no data in the FD is lost
when any unsuccessful I/O operations have been performed. However, no
additional storage space is required using the "FD method". The programmer
should use only one method in the program.
If the disk file is an output file created by a generic program using a file list naming
conventions 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)
3 - 25
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 WSFILE
01 WSREC
The actual structure is defined in the Working Storage Section, that is, a MOVE
from FD to the Working Storage Section must be programmed.
4) Sort Files
SD SORTn
n = 1-9
01 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 file
type, for example, 88 CI-NEW CUSTOMER VALUE '1'
for standard use of VALUE clause refer to 3.6.5
3 - 26

COBOL Programs
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 this
print line definition. If patch constants are to be defined, the corresponding
record must be called "PATCH-AREA-nn". See "Standards for Patch
Constants" (Section 3.5) in this manual for further information.
3) Workstation Files
01 WSc-mnemonic
05
WSc-mnemonic
05
WSc-mnemonic
"c" stands for "I, O or U", depending on whether the record is used to store
input data ("READ INTO"), output data ("WRITE FROM") or both (update
area).
4) Sort Files
01 SORTn-mnemonic
n = 1-9
3 - 27
CONDITION NAMES
C-mnemonic VALUE...
for standard use of VALUES refer to 3.6.5
LOCAL DATA AREA
01 LDA-AREA
05 LDA-mnemonic
A standard module and standard field names will be used for processing the
LDA (see frames XMFR01-04).
CONTROL AREA FOR WORKSTATION FILES
01 WS-CTR.
05 FUNCTION KEYS
88
ENTER-KEY
88
CMD-NXTERR
88
CMD-ADDINFO
88
CMD-DEL
88
CMD-UPD
88
CMD-EOJ
88
ROLL-UP
88
ROLL-DOWN
05 TERMINAL-ID
05 RESERVED
PIC XX.
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
'00'.
'01'.
'02'.
'04'.
'05'.
'07'.
'90'.
'91'.
These are standard CMD keys used throughout BASIS (see 2.3.4). Additional
CMD keys may be added according to the program functions.
FILE STATUS AREA
01 FILE-STATUS-aann (aann = file name)
88 FS-aann-SUCCESSFUL
-EOF
-SEQ-ERR
-DUPL-KEY
-NO-REC
-BOUNDARY-IND-REL
-PERM-ERR
-BOUNDARY-SEQU
-ERROR
3 - 28
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
VALUE
'00'.
'10'.
'21'.
'22'.
'23'.
'24'.
'30'.
'34'.
'90' THRU '9Z'.

COBOL Programs
Normally only "SUCCESSFUL" and "EOF" is used in a program. All unused

88 conditions should be removed.
CL - PARAMETER AREA
01 CL-PARAMETERS.
05 CL-mnemonic
05 CL-mnemonic
01 TCL-PARAMETER TABLE REDEFINES CL PARAMETERS
30 TCL-PAREMETER OCCURS nn TIMES PIC X (8) INDEXED BY TCL.
is used with the COBOL ACCEPT statement to read CL parameters into the
program. Refer to 2.6.2. A table may be useful to load multiple CL
parameters.
DATES, TIME
Standard modules with predefined field names will be used.
TERMINAL ATTRIBUTE AREA
01 TERMINAL-ATTRIBUTES
05 A-TYPE
88 A-DISPLAY
VALUE 'D'
88 A-PRINTER
'N'
88 A-UNKNOWN
'2'
05 A-SIZE
88 A-1920
'1'
88 A- 960
'2'
05 A-SITE
88 A-LOCAL
'L'
88 A-REMOTE
'R'
05 A-CONN-STATUS
88 A-ON LINE
'0'
05 A-ALLOCATION
88 A-ALLOC-OWN
'A'
88 A-ALLOC-OTHER
'E'
88 A-AVAILABLE
'V'
88 A-NOTAVAILABLE
'N'
88 A-UNKNOWN
'U'
88 A-INP-ALLOWED
"Y"
88 A-INP-NOTALLOWED
"N"
05 A-INPUT-STATUS
3 - 29
05 A-DATA STATUS
88 A-DATA PENDING
88 A-DATA-NOTPENDING
05 A-INQUIRY-STATUS
88 A-INQUIRY-MODE
88 A-NOTINQU - MODE
"Y"
"N"
"Y"
VALUE "N"
value "N"
NOTE
THE TERMINAL ATTRIBUTES ARE NOT USED CURRENTLY.
TABLES
Every table name consists of a table identifier and a mnemonic character
string:
for example, T4-ARTICLE DATA
T4 = table identifier
The table identifier must start with the character "T", followed by 1, 2, or 3
identical characters (0- 9, A - Z). This allows for a maximum of 36 tables per
program. The number of these characters indicates the dimension of the field
to be referenced, for example,
T4 ..... first dimension
T88 .... second dimension
TZZZ ... 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 be
applied:
..... INDEXED BY T3, T3-1, T3-2 .....
..... INDEXED BY T77, T77-1, T77-2, T77-3 .....
3 - 30

COBOL Programs
The level number of table elements must be within the range of 30 and 39.
Example:
01 T1-ARTICLE-DATA
30 T1-ELEMENT OCCURS ..., INDEXED T1
32 T1-ARTNO
32 T1-ARTNAME
34 T11-PRICE
34 T11-REPRICE
36
T111-LEFT
36
T111-RIGHT
If a table is to be included in an I/O area, the conventions for I/O area

precede the table conventions, for example, T2 in a table of 10 lines in a
screen output format:
01 WSO-FMT03
05 WSO-FIELD
05 WSO-T2-ROLL-TABLE
30 WSO-T2-LINE
T2
32 WSO-T2-FIELDA
32 WSO-T2-FIELDB
32 WSO-T2-FIELDC
PIC (10)
OCCURS 10 TIMES INDEXED BY WSOPIC (5).
PIC (6).
PIC (10).
Values can be assigned to a table at compilation:

01 Tn-VALUES
05 FILLER
PIC (nn) VALUE "...Literals..."
05 FILLER
PIC (nn) VALUE "...Literals..."
.
.
.
01 Tn-mnemonic REDEFINES Tn-VALUES
30 Tn-ELEMENT OCCURS nn TIMES INDEXED BY Tn.
32 Tn-...
3 - 31
STANDARD TABLES
Standard tables are used in more than one program. They have an identical
structure and contain the same type of data. The following standard is used
for the table name and the table identifier.
Tcc-mnemonic INDEXED BY Tcc.
"cc" and the mnemonic name are predetermined and must not be changed by
the programmer. The following tables exist:
TER-TABLE
containing the error codes (assigned at compilation), see

3.5.3
TBL-TABLE
containing the command key descriptions and the error

message texts displayed by screen programs (loaded at
execution time as needed)
TCL-TABLE
containing CL parameters loaded by means of the COBOL

ACCEPT statement at execution time)
The structure of the abovementioned tables is already defined and available

in the COBOL frames, for example, XMFR01, XMFR04...)
SUBSCRIPTS
Due to performance problems, no subscripts should be used in COBOL
programs. 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 to
be 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
3 - 32

COBOL Programs
WORK FIELDS
W-mnemonic
RELATIVE KEY
RELKEY-aann (= file name)
BOOLEAN AREAS
01 INDICATOR-c VALUE ZERO
30 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 'BASIS
reserved' words and prefixes which have a standard meaning and must not be
used in any other expression (data name, condition name, and so on) than the one
they have been set up for:
1) Standard Words
CCnn (01-99)
CMD-ADDINFO
CMD-AWR
CMD-DEL
CMD-EOJ
CMD-NXTERR
ENTER-KEY
FOOTING-LINE
IBM-DSP
3 - 33
LDA
LDA-AREA
LINAGE-VALUE
MODLEV-AREA
MODLEV
PATCH-AREA-nn (nn = 01-99)
PCccccc
(ccccc = mnemonic name)
RPT
ROLL-DOWN
ROLL-UP
SHUTDOWN
SHUTDOWN-ON
SHUTDOWN-OFF
SKIP-VALUE
SORTn (n = 1-9)
SYS-CONSOLE
SYSTEM-SHUTDOWN
TBL-ERROR-FM
TBL-BOTTOM-LINE
TBL-ERROR-LINE
TBL-CMD-DESCR
TBL-ERRORCODE
TBL-ERRORMSG
TCL
TCL-TABLE
TER
TER-TABLE
TER-CODE
TER-CODES
TER-CODEnn (where nn = 01-99)
TER-RECOV
TER-FLAG
TER-ATTR
TER-ELEMENT
W-HHMMSS
W-SYSDATE
W-SYSTIME
WS-CTR
WSCODE
WS-ATTR
WSDATA
WSFILE
3 - 34

COBOL Programs
2) Standard Prefixes
ACORE-INDEX-aann
CCICOCUCLCMDFILE STATUS-aann
FS-
I
INDIC-c
INDIC-c-ON
INDIC-c-OFF (where "C" = A-Z)
INDICATOR-c
KEYaann
LDARPTRELKEY-aann
SWITCH-nSWn-ON- (where n = 1-8)
SWn-OFFTBL
TCL
Description
Terminal Attribute Area
I- C- Control/main storage index of
file aann
Condition names in FD
OCL parameters
Command keys
Condition name in Working Storage Section
File status for file aann
Condition defined for file status
(for example, FS-aann-EOF)
Index data item
Indicator Field
Condition defined for indicator field
Condition defining status of indicator
(ON/OFF)
Indicator area
Key for index file
LDA-Area
FD for printer files
Key for relative file
Status of switches
TER
TBL = Error message handling

TCL = Standard display of error messages
and command keys
TER = OCL paralmeters
Tccc-
Tables
WSWSIWSO- WSU-
FD for workstation file
Area for workstation files in working

storage section
3 - 35
Apart from the rules for the use of standard words and/or prefixes, the following
suggestions should be followed by the programmer:
No field name in the program must start with the character "X" which is to be
used in modules only.
No field other than patchable constants should begin with characters "PC" or
"CC".
3 - 36
Naming
Conventions
for
Standards
for Patchable
COBOL Constants
Programs
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 be
adhered to:
Common constants and program constants are read during the program
initialization (standard paragraph 11-XI01-LITERALS available in frames XMFR01XMFR04). An XI01 record description must be coded for every record retrieved
from the SCF:
01 XI01-CCnn
(common constant, nn = pos. 5-6 of corresponding XI01

record)
- or 01 XI01-PAnnx (program constant, nnx = pos. 11-12 of corresponding XI01

record, 'nn' corresponding to PATCH-AREA-nn)
'x' = pos. 13 representing A, B or C
NOTE
ANY OTHER XI01 RECORD DESCRIPTION (LEVEL 01) MUST BE
CODED AFTER COMMON CONSTANT AND PROGRAM CONSTANT
RECORDS.
The module loads the constants in patch areas defined in the working storage
section: see the example below:
01 PATCH-AREA-nn
3 - 37
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 storage
section.
3.5.1
Common Constants
Every common constant used in a program must exist in the Common

Constant file. See TXP/1.2.
Common constants can only be specified in the patch areas of a program.
name: CCnn
CC = "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 the
entries in the Common Constant file XP04 and the PICTURE clause in the
record 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 file
Description of the SCF in that program.
Module 11-XI01-LITERALS is used to transfer translated text from the SCF to
the corresponding constants in the different patch areas.
For detailed description of placement of common constants see the example
for 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 in
the SCF record description for common constants must be present.
3 - 38
3 - 39
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
28
12
16
20
CCnn
24
28
32
32
36
36
40
40
44
44
48
48
P IC X ( . . ) .
24
05
20
P IC X (17 ) .
P IC X ( . . ) .
P IC X ( . . ) .
16
XI 01 -CCnn .
05 F ILLER
05 CCmm
05 CCnn
05 F ILLER
COBOL STATEMENT
12
52
52
56
56
60
60
PUNCHING INSTRUCTIONS
01
CONT.
DATE
GRAPHIC
PUNCH
COBOL Coding Form
+ A standard card form, IBM Electro C61 1987, is punching source statements from this form. Instructions for using this form are given in any
IBM COBOL reference manual. Address comments concerning this form to IBM Corporation, P.O. Box 50020, Programming Publiching, San Jose, CA 95150
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
64
64
68
68
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
Naming
Standards
Conventions
for Patchable
for
COBOLConstants
Programs
Record descriptions of common constants must be coded before those for

program constants.
For placement of PICTURE clause see paragraph 3.5.2, Program Constants
Only records and common constants needed in a program must be described
in the FD.
The record number (XI01-CCnn) depends on which constants are needed
and where these constants are stored on the SCF.
NOTE
THESE RECORD DESCRIPTIONS ARE PRE-CODED AND AVAILABLE
IN THE COBOL FRAMES (FOR EXAMPLE, XMFR01). THEY MUST
IMMEDIATELY FOLLOW THE 'COPY' STATEMENT FOR XI01.
3.5.2
Program Constants
All translatable text in a program (print constants, constants displayed via the
DISPLAY operation code or a screen format) is called "program constant". These
constants can only be specified in so-called "patch areas" in the working storage
section of the COBOL program.
The following standards must be adhered to when defining patch areas in the
working storage section:
The patch areas must immediately follow the modification level area orif
presentthe 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 ascending
sequence.
3 - 40
Naming
Conventions
for
Standards
for Patchable
COBOLConstants
Programs
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 "patch
areas"
A maximum of 66 bytes of translatable text of program constants is permitted
in 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 alphabetical
sequence, so that no other name can be defined between the constants,
for example, PCHEAD1
PCHEAD2.
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 program
constant name must not occur more than once. Should the same text be
needed in more than one patch area, two possibilities exist for the
programmer:
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 variables
accordingly
2) to give the constants different names. This, however, forces the user to
translate the same text more than once.
3 - 41
3 - 42
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
20
24
12
05
16
20
CCnn
24
PATCH AREA-nn
05 PCccccc
16
12
01
CONT.
28
28
DATE
32
32
36
36
'
'
'
'
44
40
44
48
P IC X (nn)
P IC X (nn)
40
48
52
52
60
56
60
VALUE
VALUE
56
COBOL STATEMENT
GRAPHIC
PUNCH
COBOL Coding Form
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
Placement of Patch Constants in the Working Storage Section
64
64
68
68
'.
'.
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
Naming
Conventions
for
Standards
for Patchable
COBOL Constants
Programs
Patch constants must be elementary items in the program (level 05).

"*" lines (for example, similar) should not be patchable, that is, a name other
than "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 first
apostrophe at 39)
If the length of the constant exceeds 32 characters a continuation line must
be used ("-" in position 7). Here text must start at position 38 (apostrophe
at 37).
SCF Record Description for Program Constants

Translated constants are stored on the LP of the SCF. A frame must be used by
the programmer to
access the SCF and
move constants from there to the corresponding patch areas in the Working
Storage Section
The following standards are to be used when defining SCF record descriptions:
For every patch area defined, at least one record description must be
present.
The number, names, sequence and patchable positions of program constants
in a record description must be identical to the ones in the corresponding
patch area.
3 - 43
The record descriptions for program constants must be coded after the ones
for common constants.
If a patch area contains only common constants, a dummy SCF record
description (no fields defined) must nevertheless be defined, that is, the
1 to 1 relationship between the SCF and patch areas must be kept. See
example 2.
3 - 44
3 - 45
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
20
12
16
20
XI 01 -PA04.
05 F ILLER
05 PCOUTL
05 PCADDR
05 PCCITY
05 F ILLER
16
01
12
CONT.
24
24
28
28
DATE
32
32
36
36
40
P IC
P IC
P IC
P IC
P IC
40
44
48
X (17 ) .
X (10 ) .
X (40 ) .
X (10 ) .
X (09 ) .
44
48
52
52
56
56
60
60
COBOL STATEMENT
GRAPHIC
PUNCH
COBOL Coding Form
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
Example 1:
64
64
68
68
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
Naming
Conventions
for
Standards
for Patchable
COBOLConstants
Programs
3 - 46
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
01
01
01
CONT.
16
20
24
PCAMT
05
12
05
16
20
PCNAME
24
PATCH-AREA- 03 .
PATCH-AREA- 02 .
05 CC04
05 W- . . .
PCTOWN
05
PATCH-AREA- 01 .
12
28
28
DATE
32
32
36
36
44
40
44
48
P IC X (20 )
P IC X (50 )
P IC X (14 ) .
P IC X (15 )
P IC X (14 )
40
48
56
60
52
56
60
VALUE . . . .
VALUE . . . .
VALUE . . . .
VALUE . . . .
52
COBOL STATEMENT
GRAPHIC
PUNCH
COBOL Coding Form
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
64
64
68
68
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
In this example, patch area 02 does not contain program constants. The following record descriptions of the SCF must be
coded as follows:
Example 2
3 - 47
20
24
28
01
01
12
16
20
24
28
XI 01 -PA03 .
05 status / Key field
05 PCNAME
05 FILLER
XI 01 -PA02 .
XI 01 -PA01 .
05 status / Key field
05 PCADDR
05 PCAMT
05 FILLER
16
12
01
DATE
32
32
36
36
44
40
44
48
P IC X (20 ) .
PIC X (96 ) .
P IC X (40 ) .
P IC X (21 ) .
40
48
52
52
56
56
60
60
COBOL STATEMENT
GRAPHIC
PUNCH
COBOL Coding Form
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
CONT.
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
The following record descriptions of the SCF must be coded as follows:
64
64
68
68
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
Naming
Standards
Conventions
for Patchable
for
COBOLConstants
Programs
NOTE
THE RECORD DESCRIPTIONS AND EXAMPLES OF PATCH AREAS
ARE 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 Control
file ("LP of SCF"). When defining the error codes in the program, the following
standards must be adhered to:
3 - 48
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
20
24
01
TER-CODEnn
28
32
36
44
48
P IC X (11 )
40
COBOL STATEMENT
12
16
20
24
28
32
36
40
44
48
56
60
64
52
56
60
64
68
68
'.
OF
72
72
76
76
80
80
IDENTIFICATION
PAGE
CARD FORM #
VALUE 'Eaannn E/W
52
TER-TABLE REDEFINES RER-CODES

30 TER-ELEMENT OCCURS nn INDEXED BY TER
32 TER-CODE
P IC X (7 ) .
32 TER-FLAG
P IC X .
32 TER-ATTR.
34 TER-ATTR1
P IC X .
34 TER-ATTR2
P IC X .
32 TER-ADDINFO
P IC X .
05
TER-CODES
05 TER-CODE01
05 PCNAME
16
12
01
DATE
GRAPHIC
PUNCH
COBOL Coding Form
3 4
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
2
3 4
CONT.
(PAGE) (SERIAL)
SEQUENCE
SYSTEM
PROGRAM
PROGRAMMER
IBM
Naming
Conventions
for
Standards
for Patchable
COBOL Constants
Programs
3 - 49
Frame XMFR04 can be used to show how to store the error codes in the
program.
All other TER-CODES (TER-CODEnn) and the OCCURS clause must be
added and modified by the programmer according to the needs of the
program.
SCF Record Description for Error Messages

Translated error messages are stored on the LP of the SCF. Error handling
modules 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 modules
to access the error messages and the error attributes.
3 - 50
Naming
for
CodingConventions
and Efficiency
COBOL
Programs
Techniques
3.6
Coding and Efficiency Techniques
3.6.1
General
The following clauses in the ENVIRONMENT and DATA DIVISION are not used
and will be partially replaced by BASIS routines:
CURRENCY SIGN
DECIMAL-POINT
SEGMENT-LIMIT
RERUN ON
BLANK WHEN ZERO
SYNCHRONIZED
VALUE OF
DATA RECORDS ARE
CODE SET
SIGN LEADING/TRAILING
3.6.2
Data Division
The contents of fields must always be compatible with their PICTURE definition, for
example, a numeric field must not contain blank. To avoid unpredictable results, all
fields in the Working Storage Section must be initialized with VALUE accordingly,
for example, VALUE "SPACES" for alphanumeric fields, "VALUE ZEROS" for
numeric fields.
All fields should be defined alphanumerically unless used in arithmetical
operations.
Numeric values are always defined signed.
Arithmetical operations with packed and/or binary are slow and should therefore be
avoided.
Exception: COMP-4 fields having identical length can be added or subtracted
without converting them.
3 - 51
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 unlikely
condition first in an AND relationship and the most likely condition first in an
OR 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 and
UNSTRING operation codes.
PERFORM: Must always be used with the "THRU" option.
Array elements, COMP-3 or COMP-4 fields should be moved to work fields
when used often in a routine.
The COMPUTE statement is more efficient and readable than corresponding
arithmetical 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 freqently
for example, 10.000 times or more (10.000 x 1 ms = 10 sec!)
3 - 52
Naming
for
CodingConventions
and Efficiency
COBOL
Programs
Techniques
* Packed fields are redefined with character fields

05 W-AMOUNT-PACKED
COMP-3
05 W-AMOUNT-CHAR REDEFINES W-AMOUNT-PACKED
and
05 W-ZERO-PACKED VALUE ZEROES
COMP-3
05 W-ZERO-CHAR REDEFINES W-ZERO-PACKED
initialize with zero: MOVE W-ZERO-CHAR TO W-AMOUNT-CHAR
compare 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 field
added is zero
IF W-AMOUNT-CHAR NOT EQUAL W-ZERO-CHAR
ADD W-AMOUNT-PACKED TO W-TOTAL-PACKED
Instead of divide by 100 or 1000, use COMPUTE B ROUNDED = A/100
where B has the correct number of decimals
Test end of loops by comparing with an index value (which has been saved
during table load), not with a complex condition:'end of table OR initialized
table entry found'.
For highly critical loops (executed 100.000 times or more)
- replace AND by
- replace OR by
3.6.4
If...IF... perform x
IF... perform x
GO TO EXIT-01.
IF... perform x
GO TO EXOT-02.
*
* (difference 0.160 ms)
*
*
*
Printer Files
a) Definition of Page Size(s) in SC file (XI01) Installation Option Part

Key
Data
OXXLINES
nnn (= number of lines per page)
3 - 53
b) Definition of Printer file in a COBOL Program

FD RPT
LABEL RECORD OMITTED, LINAGE IS LINAGE-VALUE,
LINES AT TOP 0, LINES AT BOTTOM 6.
WORKING STORAGE SECTION
77 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-ROUTINE
OPEN INPUT XI01
MOVE'OXXLINES' TO KEYXI1.
PERFORM Z51-XI01-READ THRU Z51-EXIT.
IF FS-XI01-SUCCESSFUL
MOVE XI01DATA TO W-LINKAGE-VALUE
SUBTRACT 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 - 54
CodingConventions
and Efficiency
Naming
for
Techniques
COBOL Programs
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 should
be used. These values are reserved for this purpose only.
77 W-ALPHA
88 C-mnemonic 1
88 C-mnenonic 2
88 C-OFF
PIC X.
VALUE "A".
VALUE "B".
VALUE X.
X = SPACE(S) or " " or "0"

77 W-NUMERIC
88 C-mnemonic 1
88 C-mnemonic 2
88 C-OFF
PIC 9.
VALUE 1.
VALUE 2.
VALUE Y.
Y = ZERO(S) or 0
77 W-ERROR
88 C-ERROR
88 C-NOERROR
PIC X.
VALUE "1".
VALUE Z.
Z = SPACE(S) or " " or "0"

To set off one or more conditions, a MOVE statement moving space or zero may
be applied.
3 - 55
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
COMPUTE,GIVING,SIZE ERROR or ROUNDED key word
Any arithmetic COBOL operation using an
operand with a length 15 bytes
multiply non-packed
divide non-packed
multiply AxB -- C (all packed)
divide
A/B -- C (all packed)
Move unpacked to packed or vice versa
Move zero to packed
Add packed A+B -- A (A and B packed)
Add packed A+B -- A (A unpacked, B packed)
Compare A and B (both packed)
Convert decimal suffix or decimal value to index
change sign: COMPUTE A = -A (packed)
3 - 56
0.2-0.6ms
0.5 ms
1.0
1.5
2.4
2.9
0.6
0.6
1.4
0.6
1.0
0.6
1.0
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Naming
for
CodingConventions
and Efficiency
COBOL
Programs
Techniques
3.6.7
Standard Coding for I-O Operations
This coding has to be applied for all disk I-O operations. Normally it forces a
COBOL-'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-O
procedures (see 3.4.1 for naming conventions) file status test and error handling is
optional and must not be coded if:
a) File status test is performed in main program outside of I-O procedure (see
processing 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
* ------------------DECLARATIVES
I-O-ERROR SECTION
USE AFTER ERROR PROCEDURE ON
XI01 , XJ02
AANN , AANN . . . . . > AANN .
?-----> SUBSTITUTE FILE NAMES (AANN) FOR ALL USED DISK FILES
DUMMY-PARAGRAPH.
END DECLARATIVES.
* ------------------MAIN-PROGRAM SECTION.
* **********************************
MAINLINE.
* *************
3 - 57
NOTE
THE CODING EXAMPLEX FOR THE DECLARATIVE SECTION AND
THE 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-XI01
UPON 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.
3 - 58
Naming
CodingConventions
and Efficiency
for
Techniques
COBOL
Programs
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-aann
UPON 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-SUCCESSFUL
DISPLAY 'ERROR FOR FILE aann / READ / '
UPON IBM-DSP
DISPLAY 'TAKE HARD CPOY AND DUMP / CALL FOR SUPPORT'
UPON IBM-DSP
STOP ' '
GO TO Z??-ERROR.
Z?? EXIT.
EXIT.
3 - 59
*
***************************************************************************************************
* 'START' or 'DELETE' for Disk Files
*
***************************************************************************************************
*
?-----> Substitute in whole procedure
?----->
+ file name for 'aann' and
?----->
+ START or DELETE for ???????
Z??-aann-??????.
**********************
?????? aann .
Z??- ERROR.
DISPLAY 'ERROR FOR FILE aann / ?????? / '
UPON IBM-DSP
UPON IBM-DSP
STOP ' '
GO TO Z??-ERROR.
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.
DISPLAY 'ERROR FOR FILE aann / ??????? / '
UPON IBM-DSP
UPON IBM-DSP
STOP ' '
GO TO Z??-ERROR.
Z?? EXIT.
EXIT.
3 - 60

Program
Structure
COBOL Programs
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-01
01 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 the
following examples: Both examples are also available in frames XMFR01
through XMFR04.
01 XI01 - INSTALLATION-OPTIONS.
05
05
05
05
XI01-DATE-FORMAT
XI01-DATE-MASK
XI01-TIME-MASK
XI01-DECIMAL-SIGN
'
'
' etc. (as required)
PIC
PIC
PIC
PIC
X(6)
X(8)
X(8)
X
VALUE
VALUE
VALUE
VALUE
'DDMMYY'.
'bb//.bb//.bb//'.
'bb//:bb//.bb//'.
','.
3 - 61
The VALUE represents the default to be used by the program unless the
XI01 record is present; it must be set according to the default documented
on the B7 layout.
A subdefinition can be inserted wherever required with the VALUE-clause
remaining on the 05 level, for example,
05 XI01-DATE-MASK
10
10
10
10
10
VALUE 'bb.bb.bb'.
FILLER
XI01-DATE-EDITSIGN-1
FILLER
XI01-DATE-EDITSIGN-2
FILLER
PIC
PIC
PIC
PIC
PIC
X(2).
X.
X(2).
X.
X(2).
01 XJ02-RUN-OPTIONS.
05 XJ02-CALL-DATE
05 XJ02-REORG-DATE
05 XJ02-CALL-ROUTE
PIC X(6).
PIC X(6)
PIC X(3)
VALUE SPACES.
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 the
READ 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 the
program. Standard frames (for example, XMFR1) where this structure is
provided should be used by the programmer.
3 - 62

Program
Structure
COBOL Programs
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:
MAINLINE
1-INIT
2-READWS
3-PROCESS *
31
*
311
*
312
*
32
*
.
*
.
*
.
* Module 3-PROCESS together
33
*
331
*
3312
*
'
*
'
*
'
*
4-DISPLAY
5-TERMINATE
Y1
Y11
'
Y2- - '
Z1
'
'
'
Znn
XM
'
'
'
3 - 63
3.7.3
COMMENTS
EJECT should be used only after FILE SECTION AND WORKING STORAGE
SECTION.
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 one
program. For patch constants, however, certain positions are obligatory (see
patching standards in this manual).
Indentation:
01
05
10 W- FLAG
88 C-INVALID ...
IF CONDITION-1
MOVE
ADD
IF CONDITION-2
ADD
SUBTRACT
ELSE
MULTIPLY
ELSE
PERFORM
DIVIDE
An extra line must be coded for the following clauses:
INVALID KEY, AT END, GIVING, VARYING WHEN, INTO, ON OVERFLOW, ON
SIZE ERROR
3 - 64

Program
Structure
COBOL Programs
Arithmetical expressions should be coded as follows:

ADD W-ALT
W-NEW
TO W-AMT
W-TAX
Every performed paragraph must be preceded by a short comment.
3 - 65
3 - 66

Program
Administration
COBOL
Programs
3.8
Program Administration
IDENTIFICATION DIVISION
AUTHOR, INSTALLATION, DATE-WRITTEN, DATE-COMPILED are not
used 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 to
be given to the program distribution department.
All statements
Whenever a program is modified, the statements concerned (changed or new
ones) 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 must
be inserted. The SEU serialization feature may be used.
A
8
01 01
02
03
04
05
06
07
B
12
COBOL STATEMENT
16
20
24
28
32
MODLEV-AREA .
05 MODLEV
05 MODLEV-FILLER
05 MODLEV-IDENT
36
40
44
PIC 99
PIC X (4 ) .
PIC X (9 ) .
48
52
56
VALUE
VALUE
VALUE
60
64
00
' ------- '
'MODLECBL'
3 - 67
68
3 - 68

ProgramPrograms
Modules
COBOL
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):
XMccnnC
XM = Standard identification
cc = Classification of the module
for example,
FP - field processing
TP - table processing
nn = Sequence number within the class of the modules
C
= First letter of the COBOL division where the module is used: for
example, 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 when
designing a module.
3 - 69
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 on
are 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, for
example, structograms, procedure diagrams, and so on. The main paragraph,
that is, the paragraph performed by the program, and its corresponding EXIT
must be coded as follows:
Main Program:
PERFORM
XMFP4-mnemonic THRU XMFP4-EXIT
Module (XMFP4P)
XMFP4-mnemonic
XMFP4-EXIT
3 - 70

ProgramPrograms
Modules
COBOL
Since most of the fields in a module are work fields, the prefix "W" can be
omitted.
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-EXTERNAL
XMTP8-O-C-OVERFLOW condition name as output parameter
In this way, all parameters which link the module with the main program can
easily 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 program
to program, the programmer must define "dummy parameters" instead of these
entries. These parameters will be replaced by actual values at the time the module
is 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
XMccnn-I-TAX
PIC ?10? .
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 dummy
parameter name can be assigned to them.
3 - 71
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 be
used only to replace complete text words, that is, expressions delimited by
blank 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 after
the 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 XXXXXXX
that is, "?08?bbb" will be replaced.
The space to be reserved for the replacing text must at least be equal to the
number 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 standards
have to be applied accordingly.
3 - 72

Program
Modules
COBOL Programs
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 serial
number in the source statements as shown in the following table.
POSITIONS IN SOURCE STATEMENTS FOR

a)
MODULE
DATE OF
TYPE
LAST CHANGE
b)
MODULE
VERSION NO.
MODULE
SERIAL 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 IS
INCREASED 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.
3 - 73
2) For COPY modules and procedure frames, comment statements are used in
the beginning, defining the function.
3) Description of parameters, fields, subroutines, and so on, are put into the T5
module manual.
Example of 1), 2), and 3):
XMER02D
***
01
XMER02 STOP ERROR HANDLING

********************* 81/03/12 02.0 XMER02
XMER02-1-INDICATOR
PIC X.
XMER02
88
XMER02-1-C-REC.-O-ALLOWED
VALUE IS "Y."
XMER02
88
XMER02-1-C-REC.-O-NOT-ALLOWED
VALUE IS "N."
XMER02
*****************************************************************************************************
XMER02
Position 60-67
0001
0002
0003
0004
0005
Position 70-73
XMER02P
***
XMER02 STOP ERROR HANDLING
********************* 81/03/12 02.0
********************************
XMER02-STOP-ERROR.
********************************
DISPLAY XMER01-O-ERRCODE XMER01-O-T1-MESSAGE(01) UPON IBM-DSP
PERFORM XMER02-DISPLAY THRU XMER02-DISPLAY-EXIT
VARYING XMER01-T1 FROM 02 BY 01
UNTIL XMER01-T1 IS EQUAL TO 05
IF XMER02-I-C-REC-O-ALLOWED
STOP "RECOVERY ''0'' ID ALLOWED"
ELSE
PERFORM XMER02-STOP THRU XMER02-STOP-EXIT
100 TIMES.
SET XMER02-I-C-REC-O-NOT-ALLOWED TO TRUE.
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
XMER02
0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
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 - 74

S/36 - S/38
Considerations
COBOL
Programs
3.10
S/36 - S/38 Considerations
3.10.1
Programs
With the development of BASIS II we decided to use COBOL as our programming

language. COBOL may be a common, business oriented language, but when
programs are being developed for S/34, S/36 and S/38, the differing COBOL
versions for each machine make development difficult. It is our objective to develop
BASIS 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 the
standard 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/38
during the execution of programs if necessary. Source statements for this
indicator (module XWXXSI) are copied from the 'SYSMOD' library into the
source program during the compilation. They have the following format:
3 - 75
25
WORKING-STORAGE SECTION. XUP002 0060
XUP002 0061
XUP002 0062
XUP002 0063
26
01 MODLEV-AREA
XUP002 0064
27
05 MODLEV
PIC 99
VALUE 00.
XUP002 0065
28
05 MODLEV-FILLER
PIC XXXX VALUE '----',
XUP002 0066
29
05 MODLEV-IDENT
PIC X(9)
VALUE 'MODLEVCBL', XUP002 0067
XUP002 0068
************************************************************************
XUP002 0069
XUP002 0070
COPY XWXXSI.
XUP002 0071
*
83/06/07 00.0 XWXXSI
30
01 SYSTEM-IDENT
PIC X(6)
VALUE 'S/34'.
XWXXSU
31
88 C-S34
VALUE 'S/34'.
XWXXSI
32
88 C-S36
VALUE 'S/36'.
XWXXSI
33
88 C-S38
VALUE 'S/38'.
XWXXSI
*
XWXXSI
************************************************************************
The value of field 'SYSTEM-IDENT' depends on the location of the module

which can be in the 'SYSMOD' of S/34, S/36 or S/38.
Use:
IF C-S34
WRITE ....
IF C-S36
WRITE ....
IF C-S38
WRITE ....
2) Numeric Fields (S/38)

The field contents have to be numeric, otherwise the system stops during
execution. 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 - 76

S/36 - S/38
Considerations
COBOL
Programs
3) COBOL Sort (S/38)

Although there is no problem on S/34 and S/36, a compiler error will appear
on 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 and
must be avoided.
b) Conversion Utilities
1) XXP001 (menu SYS2) S/34 to S/38 Source
This utility performs changes in the following statements, clauses and
paragraphs:
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 any
further 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 and
other systems. Activation and deactivation is controlled by control statements
followed by the source statements to be applied.
3 - 77
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
blank
Pos. 13 - 14
n n = number of source statements following the control
statement, 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 02
SOURCE-COMPUTER. IBM-S36.
OBJECT-COMPUTER. IBM-S36
*S/38 02
*S/36 01
MEMORY 21504 CHARACTERS.
*S/34
*
SPECIAL-NAMES.
*S/34 03
*
UPSI-0 IS SWITCH-1-MNEMONIC
*
ON IS SWI-ON-MNEMONIC
*
OFF IS SWI-OFF-MNEMONIC.
position 7
3 - 78

COBOL
Programs
S/36 - S/38
Considerations
b) After conversion
CONFIGURATION SECTION
*S/34 02
SOURCE-COMPUTER. IBM-S34.
OBJECT-COMPUTER. IBM-S34
*S/36 02
*S/38 02
*S/36 01
*
*S/34
SPECIAL-NAMES.
*S/34 03
UPSI-0 IS SWITCH-1-MNEMONIC
ON IS SWI-ON-MNEMONIC
OFF IS SWI-OFF-MNEMONIC.
position 7
3.10.2
Screen Formats
Similarly to programs our objective is to develop screen formats which can be used
on 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/38
some 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
3 - 79
process the following S/34 screen format functions are ignored as not or
incorrectly supported on S/38:
3 - 80
return input
suppress input
override fields
indicator for output/input fields.
CL Standards
Library
Standards
4.1
Introduction 4-3
Guidelines 4-3
Coordination and Scope 4-3
Modification Level 4-4
4.2
Menu Standards 4-7

Menu Types 4-7
Menu Design 4-10
Menu Documentation 4-13
4.3
CL Standards 4-15
CL Complexes 4-15
CL Program Procedures 4-21
CL Messages 4-23
CL-Standard Procedures 4-23
Defining of Printer Files in Procedures 4-35
4.4
Message Member 4-37

Concept 4-37
Structure of a Message Member 4-38
Maintenance 4-51
4.5
Miscellaneous 4-53
Prompt Display 4-53
PTF 53.5 T3 DEVELOPMENT STANDARDS
4-1
LIBRARY STANDARDS
4-2
CL
Standards
Introduction
4.1
Introduction
4.1.1
Guidelines
Generally, library members such as menus and control language will not be fully
compatible between machines. Although conversion aids are often provided, in
practice 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 as
possible. In addition, documentation is left as generalized as possible.
Documentation of particular features of a machine should be avoided. For
example, explanations such as '?1? on S/34' should be avoided. 'Parameter 1
means...' is superior.
Section 4 is restricted to standards. For example, cross-application CL procedures
and messages are documented in B4, Operating guide, and are available to the
user.
4.1.2
Coordination and Scope
Procedures will be established to coordinate, identify (modification level) and

administer 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)
4-3
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
Menu names
Documented in
(aaMnnn)
aa/1+2, Taa/2 (application menus)

B4 (cross application menus 'XX', start
menu 'ZZ')
CL complex names (aaCnnn)
Taa/3 (application complexes)

B5 (standard complexes)
Program/format/
sort names
(aaPnnn/
aaFnnn/
aaSnnn)
Taa/4 (application programs and sorts)
MIC numbers
(BASISMSG)
B5 (CL messages, file definitions, menu

items)
4.1.3
Modification Level
Modification levels are structured in such a way that utilities (such as UTLB in
BASIS) can find them in SOURCE as well as LOAD members. The modification
level is placed as close as possible to the beginning of the members in order to
allow fast search (especially in LOAD members, the member must be searched
byte by byte).
4-4
CL
Introduction
Standards
Structure of the modification level (ML):

nnbbbbMODLEVccc
nn
= 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

RPG
FMT
MSG
(MEN
CL
XL
ASM
(COBOL program)
(RPG linkage programs)
(Screen formats)
(Message member)
(Menus) - standard structure not
applied, see 5 )
(CL complexes)
(Source members for print lists,
selection lists, order lists, file lists)
(Assembler routine)
The member type is stored in the ML. If this were not the case it would be very
difficult to determine the type of a utility. This is especially important for local
members.
1) COBOL
ML is stored as the first 01-item in the Working Storage

Section.
2) RPG:
ML is stored as a constant in the first element of the first

compile time array.
3) SCREEN FORMATS: ML is stored in the first format FMT01 which is standard

for all screens. The constant 'MODLEVFMT' must
appear in the format as 'non-display' so that it can be
found in the 'format load member'.
4-5
LIBRARY STANDARDS
Example of Screen Heading Line

BASIS OMP100 2 00 MODLEVFMT
2
=
00
=
MODLEVFMT =
CCnnn
=
XX
=
XX
=
CCnnn XX.XX.XX XX XX
modification level of the program

modification level of the format
non-display
license contract number
user-ID
workstation-ID
In the load member, IBM generates 4 bytes in front of each field. These positions
are not checked by the utility which looks for the ML. But in order to have a unique
ML 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" source
member-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 Job
Control File at execution time. At the end of a job, this information is transferred to
the Job History File. From there it is possible to see which program versions have
been used. This is important for the user as well as the development group, as it
facilitates tracing of errors.
4-6
Menu
CL Standards
4.2
Menu Standards
4.2.1
Menu Types
Three menu types exist:

1) BASIS menus
aaM000
aaM001-499
XXM000
XXM001-499

BASIS main menu (cross application)
other cross application main and sub menus
2) User menus
aaM500
aaM501-999
XXM500
XXM501-999

user main menu (cross application)
other user menus
3) Start menus
ZZM000
ZZM0uu
standard start menu

start menu for every user (uu = user-ID)
BASIS menus are designed and maintained by the development group. They
appear in the BASIS Documentation and must therefore not be changed by the
user. Normally the main menu has a sufficient number of menu items. If too many
menu items exist (selection possibilities, and so on), sub menus can be created for
similar activities. The BASIS cross application menus XXM000-499 provide a
proposal for organizing departmental activities such as daily and month-end
processing, 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 to
rearrange items in BASIS menus according to local needs. Numbers 500-999 are
available to the user. User menus are created and maintained locally with SDA (or
by the MIS-group). Automatic linkage to the user main menu is provided by item
no. 23 of all BASIS menus (for example, OMM000-23 calls menu OMM500 and
XXM005-23 calls menu XXM500).
To make use of the IBM menu security system, so-called start menus are used to
channel the activities of every workstation user entitled to work on the computer.
Start menus must be created and maintained locally with SDA. A standard start
menu, ZZM000, which is supplied by Vienna can be used as a pattern. The
individual start menu automatically appears to the workstation user after sign-on.
4-7
LIBRARY STANDARDS
Automatic return to 'his' start menu is provided by item number 24 of all BASIS
main menus. A typical start menu contains item number 1 to assign message
member ('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. Item
number 24 of a main menu is always used return to the start menu, whereas item
number 24 of a sub-menu is used to return to the main menu. See the example on
the next page.
4-8
Menu
CL Standards
SIGN-ON (USER-ID "AB")
MENU ZZMOAB
START MENU
--Sales Department (AB)-1.
5.
6.
7.
22.
MENU OEM000
ORDER ENTRY
--MAIN MENU-1.
2.
5.
22.
TEL-SELL
ADVANCE SALESMAN
REPORTS MENU
SIGN-OFF
23. USER MENU
24. Start MENU
MENU INM500
DAILY INVOICING
--USER MAIN MENU-1.
2.
ORDER SUMMARY
NON-BUYING OUTLETS
EXCEPTIONREPORT
SIGN-OFF 23. USER MENU
24. MAIN MENU
CHAIN STORE INVOICING

SINGLE INVOICES
10. LOCAL REPORTS MENU
MENU OEM003
ORDER ENTRY
--REPORTS MENU-1.
2.
3.
22.
START-UP
ORDER ENTRY
DAILY INV. (local)
DAILY CLOSING
SIGN OFF
MENU INM502
DAILY INVOICING
--LOCAL REPORTS MENU-1.
2.
3.
MENU XXM001
DAILY CLOSING
--MAIN MENU-1. FINAL ROUTE SETTLEMENT
2. DAILY REPORTS (SA & DS)
3. COMMISSION (del. Personnel)
4.
(Sales Staff)
22. SIGN-OFF 23. USER MENU
24. Start MENU
MENU XXM500 (if existing)
MENU OEM500
ORDER ENTRY
--USER MAIN MENU-1.
2.
TEL-SELL (Northern Area)

(Southern Area)
.
.
.
4-9
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 (XP
Patching).
Standard layout of menus:
Line 1
2
3
4
5
6-19
20
21-24
not available
menu name (also not available)
modification level (see 4.1.3),
name of application, resp. system function or cross application
title, for example, 'DAILY CLOSING', with 1 space between letters
main menu constant, or title of constant 'MAIN MENU' or
submenu title (for example, 'REPORTS MENU'), delimited by '--'
blank line
menu items
standard menu items
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. Comments
do not appear between menu items.
Menu items are listed in a straight line down the page (except standard menu
items which appear on one line). If space is needed for comments, left adjust
menu items.
4 - 10
CL Standards
Menu
Leave a space between menu items to group similar menu items.

Leave one or two item numbers free between groups of similar menu items
so that an additional menu item can easily be added (or created via a submenu).
Avoid special characters such as '*'. Menu layout is kept simple.
The start menu is the menu which is presented to the workstation user at
sign-on. It automatically restricts him to certain activities or menus (IBM menu
security).
User menus are those in the range of 500-999 for which the user is fully
responsible. Standard item number 23 provides linkage to aaM500.
Examples appear on the following pages.
Sample Menus - Main and Sub Menu
COMMAND
02 2
O R D E R
W5
MENU : OEM000
E N T R Y
A N D
I N V O I C I N G
--MAIN MENU--
1.
2.
3.
4.
5.
22.
ENTER
SIGN OFF
PROCESSING MENU
5
INQUIRY MENU
REPORTS MENU
MONTHLY CLOSE MENU
FILE MAINTENANCE MENU
23.
USER MENU
24.
START MENU 6
NUMBER, COMMAND, OR OCL.

<-
1
2
3
Menu name
Modification Level
Application title
4
5
6
READY
"Main Menu" constant

Menu item, number, and title
Standard menu items
4 - 11
LIBRARY STANDARDS
COMMAND
04 2
O R D E R
W5
MENU : OEM001
E N T R Y
A N D
I N V O I C I N G
--ORDER PROCESSING MENU--
22.
ENTER
SIGN OFF
1.
2.
3.
4.
5.
6.
7.
8.
ORDER ENTRY
ORDER ENTRY-IMMEDIATE
ORDER MAINTENANCE
ODER RELEASE
DISKETTE ORDER ENTRY
BATCH UPDATE
PICK LISTS
INVOICES
23.
USER MENU
24.
RELEASE 5
START MENU

<-
7
8
READY
Sub menu name

Sub menu title ( = title of main menu item)
Sample Menus - Main and Sub Menu
COMMAND
W5
MENU : XPM000
P A T C H I N G
--MAIN MENU--
00
22.
ENTER
SIGN OFF
1.
2.
3.
4.
EXTRACT CONSTANTS MENU

DISTRIBUTION MENU
FILE MENU
TRANSLATION MENU
23.
USER MENU
24.
START MENU

<-
4 - 12
READY
Menu
CL Standards
COMMAND
MENU : XPM001
06
--EXTRACT CONSTANTS
22.
ENTER
W5
P A T C H I N G
MENU--
1.
COBOL
2.
MENU
3.
MESSAGE
4.
SCREEN
5.
ALL
SIGN OFF
PROGRAMS
EXTRACT
PROGR.
EXTRACT
CONSTANTS
FROM
MEMBER
EXTRACT
CONSTANTS
FROM
FORMATS
EXTRACT
CONSTANTS
FROM
EXTRACT
FROM
MEMBERS
MENBERS
23.
USER MENU
&
ALL
24.
COMMON
CONSTANTS
MENU
MESS.MEMB.
SCR.
MEMBERS
FORMATS
TYPES
START MENU

<-
4.2.3
READY
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, Menu
Specifications:
2.1 aaMnnn Menu Name (details by menu item number).
See 1.1.4, Technical Manual.
4 - 13
LIBRARY STANDARDS
4 - 14
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; informational
CL-messages must be suppressed for batch jobs (that is, on S/34 IF JOBQNO IF EVOKED-NO * MIC-no.).
The first statement is always a comment line with complex-name, title and
modification 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 the
complex, that is, parameters, switches, LDA, Message Member. See the
example 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 CLmessages for interactive jobs (see 4.3.2 CL Program Procedures).
4 - 15
LIBRARY STANDARDS
Standard procedures XXTSTFIL or XXTSTFLS are used when necessary to

test for presence of files before the first program starts (with message to
system operator).
Deletion of files should be done as much as possible with the RETAIN-S
parameter (performance). If not possible use XXDELFIL or XXDELFLS
procedures.
If running under XJ Job Control the complex must be subdivided into
checkpoint 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 (application
programs)
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 update
report 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 frequent
case.
Assignment of parameters to the main complex should always begin with
number 1. If parameters are passed 'down' to sub complexes they should be
passed with the same parameter number (for example, main complex
ARC001 A,B,C,D subcomplex ARC101 ,,C).
Screen formats (// PROMPT on S/34) may be used for Xs or stand alone
programs to enter missing CL-parameters and/or display errors. Refer to
4.5.1.
CL-parameters are documented before all CL-complexes to understand the
CL logic flow. See the example at the end of this section.
4 - 16
CL Standards
User Complexes
If it is necessary to run user applications together with BASIS complexes in Multiple
Application Processing (MUAP), the user complexes have to be coded according to
BASIS standards, including job control. To allow this, message member entries
have 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 included
in MUAP processing as can any BASIS complex.
For a description of MUAP complexes, see manual XJ.
4 - 17
LIBRARY STANDARDS
Documentation in CL procedures:
1-10
11-20
21-30
31-40
41-50
51-60
61-70
71-80
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 COMPLEX
aaC001
4 - 18
CL Standards
The following CL-variables are standard and do not have to be documented in

procedures:
MIC NO.
POS.
LENGTH
0003
1
3
5
2
2
2
Company file group (should be blank)

Location file group
Location code
3nnn
31
36
40
56
5
4
1
5
Number of BLOCKS
Number of BLOCKS for EXTEND
On line indicator
Slot of diskette station
4nnn6nnn
1
9
10
12
14
8
1
2
2
1
16
Menu item
Execution type
Complex number
Version number
MUAP processing code
X = job not allowed in MUAP
CL-procedure name
LDA
POS.
LENGTH
101
156
PARAMETERS
TEXT
Standard LDA information
NO.
10*
11*
Company file group code

Location file group code
* not compulsory; if used for other purpose, it has to be documented.
PTF 53.5
REL45
T3
T3
DEVELOPMENT
DEVELOPMENT
STANDARDS
STANDARDS
4 - 19
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 LDA
XXDELLDA
// LOCAL OFFSET-001,DATA-'?USER?'
// LOCAL OFFSET-003,DATA-'?WS?'
// LOCAL OFFSET-035,DATA-'OEP200'
// LOCAL OFFSET-102,DATA-'?1'OEM00105'?'
// LOCAL OFFSET-116,DATA-'?WS?'
// 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 OEP200
OEP200 ,,,,,,,,,?10?,?11?
// GOTO RETURN
4 - 20
CL Standards
*
***TEL-SELL ORDER ENTRY
// TAG OEP210
OEP210 ,,,,,,,,,?10?,?11?
// GOTO RETURN
*
***TEL-SELL UPDATE ORDER
// TAG OEP220
OEP220 ,,,,,,,,,?10?,?11?
// GOTO RETURN
*
***TEL-SELL DISPLAZ CALLING STATUS
// TAG OEP230
OEP230 ,,,,,,,,,?10?,?11?
// GOTO RETURN
*
***OMP072 NAME ADDRESS SEARCH
// TAG OMP071
OMP072 ,,,,,,,,,?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/34

must 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 (appropriate
EXTEND value in BLOCKS is also substituted from the Message Member if
present).
File location is not used (dynamic allocation of disk space is preferable).
File group (that is, company code, location code) is substituted from the
message member (MIC number 3, pos. 1-2 and 3-4). If an interactive
procedure has many FILE-statements (more than 6) the company or location
code should be forced into parameter 10 and 11 respectively (?10F'?'M0003,
1,2'?'? for company files, ?11F'?'M0003,3,2'?'? for location files) when used
the first time and used as a prefix for all file lables thereafter (for example,
?10?OM01). This improves substitution by about 25%.
PTF 53.5
REL45
T3
T3
DEVELOPMENT
DEVELOPMENT
STANDARDS
STANDARDS
4 - 21
LIBRARY STANDARDS
NOTE
THE COMPANY FILE GROUP CODE SHOULD BE SET TO BLANK IN
THE BASIS MESSAGE MEMBER.
The program name and title is taken from the Message Member and
displayed to the workstation calling the program (before actual LOAD), for
exaemple, 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. Use
standard 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 the
LDA (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, on
S/34 test Return Code ?CD? after the // RUN statement and CANCEL the
procedure with a message to the workstation.
CL program complexes have to be generated without history logging.
N
N
N
-LOG THE PROCEDURE STATEMENTS

-MULTIPLE REQUESTOR TERMINAL PROCEDURE
-PROGRAM DATA IN INCLUDE STATEMENTS
Example of a CL Program Procedure

**************************************************************************
* F P P L 0 0
OUTLET SELECTION
00
MODLEVCL
*
**************************************************************************
*
// 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
4 - 22
PTF
REL45
53.5 T3 DEVELOPMENT STANDARDS
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/// (via
SEU and screen formats).
CL messages are documented in B5, Implementation Guide (common
messages) and Taa (application related messages).
MIC Numbers 1-2999
MIC no. 1-100
101-999
1000-2999
are reserved for CL messages:

BASIS I messages
BASIS II common messages
BASIS II application related messages.
Application related CL messages are assigned in ranges (for example, 10801099 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. deletion
of 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 the
next 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 disk
XXDELFIL
delete a single disk file
XXDELFLS
delete up to 11 disk files
XXORGFIL
organize an indexed disk file
XXRNMFIL
rename a disk file
XXTSTFIL
test presence of a disk file and restore from diskette if not present
XXTSTFLS
same for up to 11 files
XXCOPFLS
copy up to 5 files disk to disk
XXP050
check for valid security code/user-ID combination
XXP100
transfer records from file to LDA
PTF 53.5
REL45
T3
T3
DEVELOPMENT
DEVELOPMENT
STANDARDS
STANDARDS
4 - 23
4 - 24
SYS.JOB
ATTRIBUTES
TIME
10.51
PAGE
--5.0
---
------------
-----120
----30
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
LEV MAX SIZE/K BYTES LENGTH STMTS
************************************************************************
* 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?'
*
NOLOG
---------------------
DATE 20/12/88
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXP050
P
20/01/88 10.45 000013
5
LIBRARY
1
LIBRARY STANDARDS
DATE 11/12/87
10.22
NOLOG
---------------------
ATTRIBUTES
TIME
PAGE 1
--5.0
---
------------
-----120
----51
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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
PAR-3 / PROCESSING INDIC.
PAR-4 / FILE TYPE
*
// LOAD XXP100
// FILE NAME-XX40,LABEL-?1?,DBLOCK-20
// RUN
*
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXP100
P
11/01/87 08.42 000013
7
LIBRARY - XDI
CL Standards
4 - 25
#LIBRARY
4 - 26
ATTRIBUTES
TIME
09.47
#LIBRARY
ATTRIBUTES
TIME
09.47
--1.0
---
------------
-----120
-----
PAGE
11
-----
---
1.0
---
------------
------
120
-----
22
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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
X(8)
FILE LABEL OF INPUT
FILE
2
*
4
X(8)
2
*
5
X(8)
FILE LABEL OF INPUT
FILE
3
*
6
X(8)
3
*
7
X(8)
FILE LABEL OF INPUT
FILE
4
*
8
X(8)
4
*
9
X(8)
FILE LABEL OF INPUT
FILE
5
*
10
X(8)
5
*
// 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?
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXCOPFLS
P
05/06/84 09.33 000002
4
LIBRARY
2
PAGE
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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?
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXBLDMSG
P
12/03/84 12.38 000001
2
LIBRARY
1
LIBRARY STANDARDS
#LIBRARY
ATTRIBUTES
TIME
09.47
PAGE
--4.0
---
------------
-----120
----37
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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)
*
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
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXCPYFIL
P
04/03/87 09.33 000002
5
LIBRARY
3
CL Standards
4 - 27
4 - 28
#LIBRARY
TIME
----
DATE
-------
------
REF
NUMBER
ATTRIBUTES
TIME
09.47
NOLOG
---------------------
DATE 26/11/87
PAGE
---
--8.0
------------
------
----96
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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
SUB
NAME
TYPE TYPE
SECTORS
------- ---- ----XXDELFIL
P
15
2
LIBRARY
4
LIBRARY STANDARDS
#LIBRARY
ATTRIBUTES
TIME
09.47
PAGE
--2.0
---
------------
-----96
----36
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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 DATAF1-?2?
// IF ?03?/
GOTO ENDO
// IF DATAF1-?3?
// IF ?04?/
GOTO ENDO
// IF DATAF1-?4?
// IF ?05?/
GOTO ENDO
// IF DATAF1-?5?
// IF ?06?/
GOTO ENDO
// IF DATAF1-?6?
// IF ?07?/
GOTO ENDO
// IF DATAF1-?7?
// IF ?08?/
GOTO ENDO
// IF DATAF1-?8?
// IF ?09?/
GOTO ENDO
// IF DATAF1-?9?
// IF ?10?/
GOTO ENDO
// IF DATAF1-?10?
// IF ?11?/
GOTO ENDO
// IF DATAF1-?11?
// TAG ENDO
// END
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXDELFLS
P
31/10/84 31.35 000007
5
LIBRARY
5
CL Standards
4 - 29
4 - 30
#LIBRARY
ATTRIBUTES
TIME
09.47
PAGE
--3.0
---
------------
-----96
----5
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* X X D E L L D A
DELETE LDA (SET POS.1-256 TO BLANK)
02 MODLEVCL *
************************************************************************
*
// LOCAL BLANK-256
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXDELLDA
P
27/09/85 12.45 000001
1
LIBRARY
6
LIBRARY STANDARDS
#LIBRARY
ATTRIBUTES
TIME
09.47
PAGE
--1.0
---
------------
-----96
----32
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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)
*
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?
*
// IF
JOBQ-NO
IF EVOKED-NO
* '?M1124?'
// 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
NOLOG
---------------------
DATE 26/11/87
SUB
REF
NAME
TYPE TYPE
DATE
TIME
NUMBER
SECTORS
------- ---- ---- ------- ---------XXORGFIL
P
08/11/83 14.51 000003
5
LIBRARY
7
CL Standards
4 - 31
4 - 32
#LIBRARY
TIME
----
DATE
-------
------
REF
NUMBER
ATTRIBUTES
TIME
09.47
NOLOG
---------------------
DATE 26/11/87
PAGE
---
--8.0
------------
------
----120
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* 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
SUB
NAME
TYPE TYPE
SECTORS
------- ---- ----XXRNMFIL
P
17
2
LIBRARY
8
LIBRARY STANDARDS
#LIBRARY
TIME
----
DATE
-------
------
REF
NUMBER
ATTRIBUTES
TIME
09.47
NOLOG
---------------------
DATE 26/11/87
PAGE
---
--8.0
------------
------
----96
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* X X T S T F I L
TEST PRESENCE OF FILE,RESTORE FROM DSKT 00 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
*
// IF JOBQ-NO
IF EVOKED-NO
* '?M1126?'
// ** '?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
SUB
NAME
TYPE TYPE
SECTORS
------- ---- ----XXTSTFIL
P
20
3
LIBRARY
9
CL Standards
4 - 33
4 - 34
#LIBRARY
TIME
----
DATE
-------
------
REF
NUMBER
ATTRIBUTES
TIME
09.47
NOLOG
---------------------
DATE 26/11/87
PAGE
---
--8.0
------------
------
----96
-----
REL MRT
PROGRAM
RECORD NUM TOTAL
************************************************************************
* X X T S T F I L
TEST PRES.OF AND RESTORE UP TO 11 FILES 00 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
SUB
NAME
TYPE TYPE
SECTORS
------- ---- ----XXTSTFLS
P
32
4
LIBRARY
10
LIBRARY STANDARDS
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?
// FILE
// FILE
.
.
.
// RUN
No special PRINTER parameters

PRINTER parameters at execution time
7020
, FORMS-5501, ALIGN-YES,......
7030
7031
7032
, COPIES-3,......
, COPIES-2,......
, FORMS-5502,......
7040
7050
, PRIORITY-0,....
GENERIC PRINT PROGRAM USED IN VARIOUS COMPLEXES:

COMPLEX 01
// LOAD aaP7nn
// IF ?L'142,2'?/01
PRINTER NAME-aaP7nnA? m7030?
// IF ?L'144,2'?/01
PRINTER NAME-aaP7nnB? m7030?
// IF ?L'144,2'?/02
// IF ?L'144,2'?/02

CPI-15
// IF ?L'144,2'?/04
// IF ?L'144,2'?/04

CPI-15
POSITIONS)
(132 PRINT
CPI-15
(198 PRINT
POSITIONS)
// FILE
// FILE
.
.
.
// RUN
4 - 35
LIBRARY STANDARDS
4 - 36
Message Member
4.4
Message Member
The message member is used in BASIS as a central place to store and maintain
information to be used in CL-procedures.
4.4.1
Concept
BASIS uses its own message member, BASISMSx. (x = corresponds to the

location's file group. The same message member can be used to allow BASIS I
and 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 is
needed per company (company 1 = BASISMSA, 2 = BASISMSK,
3 = BASISMSP,..).
The third message record (MIC no. 3, pos. 1-2) contains the company file
group '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 BY
BASIS. THE VALUE IN THE BASIS MESSAGE MEMBER SHOULD BE
SET TO SPACES.
The message member must be manually activated from the user's start menu
ZZMuu (with uu = user ID). Refer to 4.2, Menu Standards.
4 - 37
LIBRARY STANDARDS
4.4.2
Structure of a Message Member
A message member consists of 9999 records, each of which is addressable

individually in OCL/CL by means of a so-called MIC (message identification code)
number. The following MIC number ranges are reserved for development:
MIC number
0001
BASIS I / BASIS II title
0002
Modification level (BASIS I as well as BASIS II)
0003
Company and location file groups and libraries.
0004
SD Preparation
0005
MUAP Library
0006
SAVDAT (internal BASIS save data parameters)
0007
BASIS Data Dictionay (IDDU) and Query Library
0008
BASIS to ROSS Linkage
0009
4 - 38
0nnn
Common OCL Messages

(10-100 for BASIS I, 101-999 for BASIS II)
1nnn2nnn
Application related OCL-messages

(application ranges assigned in development sequence)
3nnn
File definitions (size, EXTEND-value, BACKUP information)

(assigned in development sequence)
4nnn6nnn
Menu item definitions (application ranges

assigned in development sequence)
7nnn
Report definitions (per report or per complex/report)
8nnn
Available for BASIS user
90009499
BASIS I file definitions and other BASIS II options
95009998
Save media and definitions for XJ automatic safety copies
9999
Reserved for XJ automatic safety copies (must be blank)
Message Member
Assigned MIC Number Ranges

1) APPLICATION RELATED OCL-MESSAGES (1nnn-2nnn)
1000
1030
1060
1070
1080
1100
1120
1140
1160
1180
1200
1250
1270
1290
1340
1400
1450
1475
1550
1580
1585
1630
1650
1700
1730
1780
1810
1820
1830
1850
1880
1900
1950
1970
1980
1990
2000
2100
2130
2140
2160
2180
2220
1029
1059
1069
1079
1099
1119
1139
1159
1179
1199
1249
1269
1289
1339
1399
1449
1474
1549
1579
1584
1629
1649
1699
1729
1779
1809
1819
1829
1849
1879
1899
1949
1969
1979
1989
1999
2099
2129
2139
2159
2179
2219
2239
FP (1)
OE (1)
XO
XJ & XR (1)
OM (1)
AM (1)
XX
XL (1)
OM (2)
XL (2)
OM (3)
XP
XI
AM (2)
FP (2)
SI (1)
OE (2)
RS (1)
IN (1)
XJ & XR (2)
SA (1)
IN (2)
DS
FI (1)
AR (1)
SD (1)
MA
KA
CA
WH
CF (1)
RS (2)
SI (2)
USER JOBS
XA (1)
AR (2)
CB
SI (3)
SB (2)
FI (2)
XA (2)
CS (1)
AR (3)
2240
2250
2270
2275
2280
2290
2300
2400
2425
2850
2880
2249
2269
2274
2279
2289
2299
2399
2424
2449
2879
2899
SD (2)
SA (2)
SB (2)
AR (4)
CF (2)
CS (2)
OS & PA
EC
ED
SD (3)
XJ & XR (3)
2) FILE DEFINITIONS (3nnn)

3000 - 3009
OE (1)
3010 - 3019
FP
3020 - 3024
XO
3025 - 3029
XJ
3030 - 3049
OM
3050 - 3069
XI
3070 - 3079
AM (1)
3080 - 3099
XL
3100 - 3109
XP
3110 - 3129
AM (2)
3130 - 3149
SI
3150 - 3159
OE (2)
3160 - 3179
RS
3180 - 3199
IN
3200 - 3219
SA
3220 - 3229
FI (1)
3230 - 3249
AR (1)
3250 - 3269
SD
3270 - 3274
MA
3275 - 3279
KA
3280 - 3289
CA
3290 - 3299
FI (2)
3300 - 3319
WH
3320 - 3329
DS
3330 - 3339
XA
3340 - 3359
CB
3360 - 3369
SB
3370 - 3374
CF
3375 - 3379
XX
3380 - 3409
CS
4 - 39
LIBRARY STANDARDS
3410
3430
3440
3500
3520
3530
3429
3439
3449
3519
3529
3539
MM
AR (2)
SD
OS
EC
PA
3) MENU ITEM DEFINITIONS (4nnn 6nnn)

4000
4025
4050
4075
4100
4110
4140
4155
4160
4170
4220
4235
4250
4270
4280
4300
4330
4345
4365
4375
4395
4410
4440
4460
4470
4500
4510
4530
4550
4560
4566
4600
4620
4640
6380
6900
6910
4 - 40
4024
4049
4074
4099
4109
4139
4154
4159
4169
4219
4234
4249
4269
4279
4299
4329
4344
4364
4374
4394
4409
4439
4459
4469
4499
4509
4529
4549
4559
4565
4569
4619
4639
4649
6399
6909
6919
FP
OE (1)
OM (1)
AM
XL (reserved)
OM (2)
CF
XJ (1)
AM (2)
SI
OE (2)
RS (1)
SA
RS (2)
DS
IN
FI (1)
AR (1)
FI (2)
SD (1)
CA
WH
XA
USER JOBS
CB
SB (1)
CS
MM
AR (2)
SD (2)
SB (2)
OS
EC
PA
XJ (2)
RS (3)
OC
4) REPORT DEFINITIONS (7nnn)

7000 - 7009
RS (1)
7010 - 7022
FP
7023
XI (1)
7024
XO
7025 - 7029
OE (1)
7030 - 7049
OM
7050 - 7069
AM
7070 - 7089
IN
7090 - 7099
SI
7120 - 7129
SA
7130 - 7139
RS (2)
7140 - 7149
FI
7150 - 7169
AR (1)
7170 - 7179
OE (2)
7180 - 7184
MA
7185 - 7189
KA
7190 - 7199
CA
7200 - 7209
WH
7210 - 7219
DS
7220 - 7229
XA
7230 - 7249
CB
7250 - 7259
SB
7260 - 7269
CF
7270 - 7289
CS
7290 - 7299
MM
7300 - 7319
OS
7320 - 7329
EC
7351 - 7359
XI (2)
7360 - 7369
XP
7370 - 7389
AR (2)
7390 - 7399
XJ & XR
Message Member
Message Member - MIC No. 0002
12
BASIS I Modification Level

Identifier '++BASISMSG' (= name
of message member)
IDENT1
10
MODLEVEL1
11
Modification level (00,02,...)
13
free
21
15
21
Modification level (00,02,...)
23
free
27
Identifier 'MODLEVMSG'
G
MODLEVEL2
IDENT2
BASIS II Modification Level
System Identification
SYSIDENT
36
'b' = S/36
'1' = S/34
'2' = AS/400
HISTORY
37
'b' = History file (XJ03) is updated

'1' = History file is not updated
TEXT
38
free
41
35
User text - optional

Standard English text is:
*** BASIS MESSAGE MEMBER ***
4 - 41
LIBRARY STANDARDS
Message Member - Mic No.0003
Company/location File Group/

Location Code
COMPANYFG
Company File Group

Contents should be blank.
Company file group is no longer
supported and should not be used.
LOCATIONFG
Location File Group

Group characters can consist of
any characters allowed in files
names (the first character should
not be a special character or a
number)
LOCATIONCD
Location Code (e.g.: 01, AB, etc.)
50
AS/400 - as of Release 40
10
File library for native data base files

(BASDB)
- used in FP and OM (S/36) mode
to access native data base files
LIBDDS
17
10
Library for DDS sources and for

Field Reference File (BASDDS)
FILLIB36
27
10
File library for S/36 files and XI01

(QS36F)
LANGLIB
37
10
Language library for BASIS Message file (BASLANG)
MSGF
47
10
BASIS Message File Name

(BASMSG)
57
20

(e.g.: location decription)
G
FILLIB
TEXT
4 - 42
PTF
PTF53.5
53.5 T3
T3 DEVELOPMENT
DEVELOPMENT STANDARDS
Message Member
G
ADMGRPLBL
Administration / Distribution
Used in complex SDC080 to

prepare SD files for RS42
74
G
MUAPLIB
Multiple Application
MUAP library
68

NOTE
This library is also used by other
BASIS applications to store procedures that are created during run
time, for example, CF and XJ
(automatic safety copies).
18
SAVDAT (Internal BASIS Data

Parameters)
SAVLIB
SAVDAT Library
SAVGRP
SAVDAT Group (01 - 99)
SAVUSR
11
SAVDAT User (for CL messages)
SAVAST
19
SAVDAT assistant (used for CL

messages)
SAVDAYINC
27
libraries to use for daily incremental

saves (libraries only)
b = use normal SAVE library
1 = use incremental library
4 - 43
LIBRARY STANDARDS
*SAVHST
28
Save changed object history

parameter
b = objects are saved every day to
an incremental library
1 = objects are saved to an
incremental library only on the
day they were changed
16
BASIS Data Dictionary & Query

Library
BASDATDIC
BASQRYLIB
18
Query Library Name
17
60
User Text
Data Dictionary Name
NOTE:
The Release 40 BASIS Data
Dictinary is called 'BASNDIC'. This
name can be changed by the user.
The Release 40 BASIS Query
Library is called 'BASNQRY'. This
name can be changed by the user.
The BASIS Data Dictionary and
Query Library prior to Release 40
are called 'BASISDIC' and
'BASISQRY'. These names should
not be changed.
4 - 44
Message Member
76
ENTRY
File label for FI link to ROSS

Inventory
MARSC
File label for FI link to ROSS

Inventory (physical count)
OECOM
17
File label for SA link to ROSS

Inventory
76
File label for SA-finance link
File label for SA-statistical link
17
File label for SA-operational link
25
File label for SA-gallon conversion
Note:
Do not use c.GL99X or GL99TR as
file labels. These file labels are
already used by BASIS (as internal
workfile) and by ROSS/GL.
Message Member - Mic No.0101 - 2999
CLMESSAGE
75
Message Text
(Standard English texts provided by
Vienna, can be translated into local
language via SEU.)
4 - 45
LIBRARY STANDARDS
Message Member - Mic No. 3nnn
G
FILENAME
FILETEXT
FILLER2
30
File Description
File name aann
free
8
30
22
1
Descriptive text
31
10
File attributes used in CL
SIZE
31
Number of BLOCKS to be substituted in OCL for output file ( mandatory left adjusted, e.g. '20')
EXTEND
36
BLOCKS value substituted in OCL

for automatic EXTEND of update
files (mandatory, left adjusted)
ONLINE
40
ON-line indicator
blank = file is on-line permanently
'1' = file must be restored from
diskette (BEFORE USING IT)
41
15
free
56
20
Back-up information (optional)
SLOTNO
56
Slot number of the diskette to hold

the safety copy e.g. M1.05 means
5th diskette in magazine 1 (blank =
operator must insert required
diskette in S1).
VOLUMEID
61
Volume-ID of the diskette
GENERATION
67
Number of generations
69
free
75
File Type
C ... Company File
L ... Location File
FILETYPE
4 - 46
Message Member
Message Member - Mic no. 4nnn-6nnn

G
15
Job Identification
MENUITEM
Menu item aaMnnnii (ii = item no.

1-24)
EXTYPE
Execution Type
'J' = Job queue
'j' = Always runs in job queue
'E'= Evoked
'e' = Always runs evoked
'B'= Interactive
'0' = Always runs interactive
The execution type values apply
mainly to pre-native applications.
Users cannot override the code for
a job defined to "always" execute a
certain way.
COMPLEXNO
VERSIONNO
PRIORITY
N
A
10
12
14
2
2
1
Complex number (01-99) used for

Version number (01-99, blank)XO
Priority Code
(1 = high, = normal), can only be
used if Execution Type is "Interactive''.
15
MUAP processing code

(X = job is not allowed in MUAP)
OCL Specifications
CLPROC
16
OCL procedure name aaCnnn to

be executed
22
Reserveddo not use
CLPARAM
23
38
JOBQSUF
61
BASIS jobqueue suffix
TEXTMIC
63
MIC no. of related complex description (0101 - 2999)
OCL parameters
(as entered in S/36 mode. No
padded blanks between parameters
and separated by commas (,), e.g.
LIST,A,,,100
4 - 47
LIBRARY STANDARDS
SAVEMIC1
67
MIC no. of safety copy before

complex
SAVEMIC2
71
MIC no. of safety copy after complex
75
Contains the parameters to be

substituted into the PRINTER
statement assigned to print programs.
All the OCL statements contain the
following:
PRINTERNAME- aaPnnn?M7nnn?
In the MIC the additonal parameters for controling the SPOOL are
given, e.g., FORMSNO-nnn,
ALIGN-YES,... (for details see the
SSP manual).
In case no special parameters are
required, the corresponding MIC
number has to be allocated, but
can be left blank.

G
4 - 48
MEDMSGREC
75
VOLID
Media Volume ID
free
SAVMEDSGL
Save Media for Single Complex
SAVMEDMUAP
14
Save Media for MUAP Complex
MSGCOB
19
'C' Save message is sent to Console

' ' No message is sent
Media Message Record

(MIC 9500 and specially defined
Media Records, see MEDMIC
below)
Message Member

(Cont.)
MSG
20
40
Message to be displayed before

save
ENDTAP
60
End of TAPE Option

'LEAVE '
'REWIND'
'UNLOAD'
66
free
MEDMIC
72
Media MIC Number

The presence of a MIC number in
this position indicates that this
record is a Media Message Record
- the number in this position must
match the record's MIC number.
G SAVCPYDEF
75
RETDAY
Retention days
(000 - 999)
FLELBL
File label for online safety copies
SUFLBL
Suffix for online safety copies
SAVDEF
4*16
Safety Copy Definitions
Safety Copy Definitions

File 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
4 - 49
LIBRARY STANDARDS

(Cont.)
Job Execution Type:
'00' Normal jobs
'--' All MUAP jobs
'01-99' Specific MUAP job
Save
'1'
'2'
'3'
'4'
Type:
Direct to media
Online save
Online and save file group
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
71
Next(continuation) Safety Copy

Definition record
75
free
NOTE:
The 16th element of the Safety
Copy Definitions field can also
contain a pointer to a Media Message Records definition. The MIC
number stored in this element
overwrites the default record 9500.
Only the first Safety Copy Definition
record of a group is accessed for
this override. If the 16th element of
another record also contains a MIC
number the element is ignored.
4 - 50
75
Reserved for XJ, used by Automatic 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 options
required to run the system. This simplifies maintenance, especially when the BASIS
system is being installed. An XIMnnn menu offers all the maintenance and print
facilities needed by the responsible person (for example, EDP manager or system
operator).
The development group will supply a 'standard' message member on diskette at
the time of initial implementation. The user should update or translate this message
member carefully, paying heed, for example, to file sizes. Aternatively, the
message member can be copied from a neighboring bottler.
When a new application is implemented, the appropirate 'standard' message
records are also supplied on diskette from Vienna. The user has a special utility to
merge them into the existing BASISMSG member and update or translate them
accordingly.
Any updates to existing message records will be reported to the users on special
forms (included in the program distribution). The actual update must be done
record by record by the user (via SEU). This is preferrable to an automatic replace
because this would destroy previous updates which the user has made.
CL messages in the message member are not translatable with XP Patching.
4 - 51
LIBRARY STANDARDS
4 - 52
Miscellaneous
Message
Member
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 job
queue.
Name:
aaF000 for member except aa = XU (one member for all PROMPT formats of
an application), FMTnn (01-99) for individual formats.
XUccccPR for member used in a utility, where cccc is taken from the main
complex name (see 2.1.1)
Standards for Patching
Standard format FMT01 with modification level is needed but is never
displayed.
Patchable text must not exceed 80 characters.
Text which is not to be translated must be furnished with 'Y' or 'N' in NonDisplay 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 slots
for a 2 byte field).
Headings in line 3 (application name and appropriate text, screen number
and processing mode) and line 4 (if needed)
4 - 53
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 "INVALID
OR MISSING PARAMETER". Switch 8 is converted to indicator 98 to be used
internally 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.
4 - 54
Message
Member
Miscellaneous
BASIS
TRANSFER
P A T C H I N G
TRANSLATED BACK TO SOURCE
|p|
ENTER
MEMBER
|x|p|p|0|2|4||
ENTER
MEMEBER
TYPE
INVALID
OR
NO
PARAMETERS
XPS80
....MESSAGE MEMBER
F ....SCREEN FORMAT
M ....MENU
NAME
ENTERED
CMD 7 - CANCEL JOB
1)
2)
3)
4)
MEMBER
HEADINGS WITH SCREEN NUMBER

PARAMETERS PLUS EXPLANATION
COMMAND OR FUNCTION KEY DESCRIPTION
ERROR MESSAGE (one general message for all input fields)
4 - 55
LIBRARY STANDARDS
4 - 56
Development Steps
Application Development
Standards
5.1
Development Steps 5-3

Project Definition - Broad Design 5-3
SIGN-OFF by the Senior Management 5-3
Research - Requirement Collection 5-3
System Concept 5-4
System Concept Review 5-4
Technical Detail Design 5-5
Programming 5-6
Documentation 5-6
System Test 5-7
Pilot Installation 5-8
Acceptance Test 5-9
Distribution 5-10
Evaluation 5-10
Maintenance and Enhancements 5-11
5.2
Application Documentation (Top Down) 5-15
5-1
APPLICATION DEVELOPMENT
STANDARDS
5-2
Development Steps
5.1
Development Steps
5.1.1
Project Definition - Broad Design
The project definition is prepared under the supervision of the Development

Manager.
It contains:
brief description including:
the purpose of the application,
the benefits for the users,
the benefits for the Coca-Cola Company and
the definition of the intended audience
list of functions divided into:
business functions supported and
technical functions and highlights
integration of the application to the business practices and to the
already 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 development
step.
5-3
STANDARDS
The step starts with the actualization of the Field Requirements based on the latest
printout of the Requirements Data Base.
The analysis and evaluation of the requirements is accomplished according to the
current and future business situations. The evaluation is supported by surveys thru
MIS channels and on-site evaluations.
5.1.4
System Concept
The system concept is prepared by the Project Manager with assistance of other
members 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 languageno 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 CCCS

management.
(Sign-off step 2)
5-4
Development Steps
The system concept is distributed to the MIS Managers of the Coca-Cola Company
and to the selected key users. The review and feedback is requested from the field
within a specified period of time, which has to be considered in the project
planning.
The answers from the field are discussed and reviewed with the responsible
customer services manager and senior development management. Changes to the
system concept are considered, if necessary and useful.
The Final System Concept is created after review and sign-off by CCCS
Management.
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 under
consideration 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 to

standards described in the T3 - logic manuals.
5-5
STANDARDS
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 to
the documentation department. A report 'Deviations from System Concept'
including reasons and explanations has to be prepared. Review (Sign off) of detail
design 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 as

described 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 descriptions
4. Programming of single modules and tests
5. Creation and test of procedures, complexes and menus
6. Documentation according to T3 - internal technical documentation
7. Final single program test including patching
8. Creation of submission forms
5.1.8
Documentation
All external documentation (B manuals and Application Manuals) are produced and
edited by the Documentation department according to standards described in T3.
Documentation starts in parallel to Step 6 (Technical Detail Design) and has to be
5-6
Development Steps
completed (draft version) for system test. The final version has to be submitted
together with all application members to the acceptance test. Documentation is
distributed 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 therefore
important aspect of system test and acceptance test.
5.1.9
System Test
System test is conducted by Project Manager and executed by the whole project
team.
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
test
test
test
test
test
test
test
test
test
according to BASIS Standard Check List (T3...)

of special technical cases (file handling, filed or table sizes)
of business functions according to application specific check lists
of each single menu item under consideration of the user documentation
of all restart, clean-up and cancel procedures
of safety, security and audit features
of installation procedures according to installation guide
multiuser-terminal environment
of multiple location data
of performance
5-7
STANDARDS
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 in
charge 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
5-8
Development Steps
After completion of all implementation work a final meeting with local responsible
management and staff involved must be arranged. Open or remaining points have
to be discussed. Agreement has to be reached about further steps of
implementation and organizational or programming work still to be done. Local
management should approve quality and agree continuing live run. An
implementation report has to be prepared by the responsible Project Manager.
(Sign-off step 9)
All members except objects are submitted to Quality Control and Distribution
department according to described standards.
5.1.11
Acceptance Test
The Acceptance Test is performed under consideration of the overall project plan
and the BASIS release planning. Before the start of the first phase of testing, the
test 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 manager
after the first phase of acceptance test.
5-9
STANDARDS
(Sign-off step 10)

After correction of programs, a second Acceptance Test phase proves that the
findings where corrections were agreed have been corrected.
After completion of acceptance test, a final test report including all test cases
performed, the findings list and correction history is provided to senior
management. The project manager communicates any necessary changes to the
documentation department.
(Sign-off step 11)
5.1.12
Distribution
Customer Services Managers and CCCS Senior Management approve the

readiness for general distribution under consideration of Quality Control results and
results 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 general

distribution) the Project Manager who did the development is still responsible for
enhancements and corrections.
If desired by Senior Management, the Development Team may perform and
support several additional pilot implementations. The application is handed over to
the designated maintenance person or group after approval by the Development
Manager.
5 - 10
Development Steps
5.1.14
Maintenance and Enhancements
Major enhancement projects are managed like new development projects and
require all development steps from 1 to 13.
Maintenance, enhancements and major revisions of applications are handled in
releases. 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 is
decided by Customer Service Managers and the responsible managers of
Application Services and New Development.
For urgent requests the Customer Service Manager can decide to arrange a
special program distribution. All special program distributions are to be included in
the 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
5 - 11
STANDARDS
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
5 - 12
Development Steps
Duties of the Maintenance Group:

1.
2.
3.
4.
Immediate correction of the request (non-task related)

Individual system test after completion
Informing of the Customer Service Manager upon completion
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.
5 - 13
STANDARDS
SIGN-OFF CHART FOR MAJOR BASIS II PROJECTS
Project:
Planned completion date:
SIGN-OFF STEP
Project Manager:
Supervising Mgr.:
Supervising Manager
Date
Signature
Senior Manager
Date
Signature
Remarks
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
5 - 14
Application Documentation
(Top Down)
Development
Steps
5.2
Application Documentation (Top Down)

MILESTONES
MANUAL/CHAPTER
A
N
A
L
Y
S
T
P
R
O
G
R
A
M
M
I
N
G
M
A
N
A
G
E
R
/
L
E
A
D
P
R
O
G
R
A
M
M
E
R
T
E
S
T
G
R
O
U
P
REQUIRE-
BROAD
DETAILED
TECH.
MENTS
DESIGN
DESIGN
SPECS. GRAMMING
B2
BUSINESS APPROACHES
B3
TERMS AND CODES
aa
REFERENCE MANUAL
aa/ 1.
2.
3.
4.
5.
Description
Activities
Workstation User Guide
Implementation
Error Messages
B6
FILE LAYOUTS
Taa
TECHNICAL MANUAL
Taa/1.
2.
3.
4.
5.
6.
Technical Description
Menu Specifications
Complex Specifications
Program Specifications
Screen Layouts
Report Layouts
PRO
SYSTEM
TEST
ACCEPT
TEST
X
X
X
X
X
X
X
X
Samples in
aa/1, aa/2
X
X
X
X
LaaPROGRAM LOGIC MANUAL

Laa/1.
2.
3.
4.
General
Hierarchy
Key Modules
Structograms
PROGRAM LISTING
SYSTEM TEST CHECK-LIST
X
X
X
X
X
ACCEPTANCE TEST CHECK-LIST
5 - 15
STANDARDS
5 - 16
Project Monitor
Project Monitor
and Planning
6.1
Project Monitor 6-3

PM Software Package 6-3
PM Procedure 6-3
PM Code Structure 6-5
List of Personnel Numbers 6-6
PM Reports and Options 6-6
6.2
Planning 6-8
Preparation of Long Range Plan 6-8
Application Development Check List 6-9
6-1
PROJECT MONITOR
AND PLANNING
6-2
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. Louis
and marketed by Program Products Inc.
There are approximately 100 installations of Project Monitor, mainly on larger
equipment; the package was converted to IBM System/34 in 1979 and is written in
COBOL.
The purchase price includes source programs and documentation comprising:
Introduction Guide
User Reference Guide
Installation and Operations Guide
System Documentation Guide.
Menu and DFU data entry programs are provided.
In case of further interest, please contact Corporate Information Services, Atlanta
who have negotiated a central contract at favorable terms. The price is
approximately 8,300.
6.1.2
PM Procedure
Project Monitor is administered by the Coordinator. The weekly running of the

system is handled by the Librarian. Managers are responsible for keeping the
Coordinator informed of additions and revisions needed to keep the planning
reports accurate and up-to-date. The operation of PM is documented in the User
Reference Manual; each Manager has a copy available for reference. To
summarize, there are two groups of input:
6-3
PROJECT MONITOR
AND PLANNING
Use as needed:
Defines
System Form
Installation options (also see com pile options in

Instal. 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). Major
revisions to the Long Range Plan will normally coincide with the end of each
quarter, 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 is
used for scheduling employees' time against planned work. The normal number of
working hours per week is 40, but other activities such as training, legal holidays
and vacation must be deducted. Therefore a net figure of 32 hours per week is
used, 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 (last
total + total hours this week = new total)
6-4
Project Monitor
6.1.3
PM Code Structure
A feature of PM is that detailed project tasks can be summarized in higher levels as

defined by the user. There are 8 levels available; certain reports can be obtained at
each level.
BASIS currently uses levels 1-4, i.e.
Levels
Development
Other
Activities
Application
Milestone
Specific Task
B,T Manuals
Specific
Manual
Specific Task
System
Functions
Function
Specific Task
Year
Group
Specific Task
Project tasks are planned and reported at level 4. Levels 1-3 are used to
summarize the information.
Because project ID's are created for specific tasks as they occur, the reader should
obtain a copy of the Project Master List for a full list of current codes. At the planning
stage, 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 to
specific tasks as they become known, that is,
OMP
Programming
OMP100
Header Program
TOTAL
EST
REV
EST
1000 HOURS
840 HOURS
160 HOURS
1000 HOURS
In this way, the total Long Range Plan remains unchanged.
6-5
PROJECT MONITOR
AND PLANNING
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.
6-6
Project Schedule
43
04
13
24
37
38
Project Master List

Project Summary List
Project Work Remaining
Employee Loading
Project Loading
ON REQUEST
Employee Time Analysis

Proj. Det. Rep. Lev. 4
Employee Schedule
02
08
39
EVERY 2 WEEKS
32
01
03
08
DESCRIPTION
Manual Control Sheet Hours

Edit List of Input
Employee Master List
Emp. Turn Around Time Doc.
Project Detail Report
Level 4
Project Due in 1 Week
WEEKLY
No.
2W
2W
2W
2W
HOURS NO
HOURS NA
W
W
HOURS
YES
HOURS NA
HOURS NA
NA
YES
NA
NA
NA
NA
NA
NA
YES
NA
YES
NA
NA
NA
Print
Print
Assign- Levels
ments
W
W
W
W
Freq. Time
Units
OPTIONS
NA
1
1
1
0
NA
NA
3
1
4
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Group Employee
Leader
One Sheet per

Person
One Sheet per
Person
Control of Hours
Audit Trail
CF Administration
Special Run
Control of Hours/
Admin.
6-7
All Reports Available on Master File
Group Leader Receives

2 Weekly Review of Above Reports
Project Schedule - Level 4
Each Employee Receives

Weekly Turn-Around Time Sheet
2 Weekly Employee Time Analysis
Employee Schedule
SUMMARY
1
1
1
New No.
Master HS, JH GA
Page Copies
Levels
AVAILABLE FOR REFERENCE
PROJECT MONITOR REPORTS AND OPTIONS
Project Monitor
PROJECT MONITOR
AND 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 of
project tasks classified either as System Functions or Business Applications. A long
range plan is prepared for each Phase. Progress is monitored against the Long
Range Plan and reported to management quarterly. Minor revisions are made
weekly, depending on progress and do not materially affect the Long Range Plan.
Normally quarterly, a review of the Long Range Plan (and minor revisons) versus
progress will be carried out to assess whether a major revison is required. System
functions support technical procedures which apply throughout the entire
development (the tools to build the car). Examples are language patching, option
handling, programming modules that are generalized features serving all business
applications.
2) Long Range Plan

The Long Range Plan is prepared for each phase of the project. For each project
task, estimates are prepared for:
sub-project tasks which are recognizable milestones against which progress
can be monitored
the starting and ending dates for each sub-project task (milestone)
the number of man-hours budgeted, based on planning standards. See
Paragraph 3.
The assignment of sub-project tasks can then be made to key staff and
programming groups.
Development manpower hours available are calculated (development group) and
reduced by other activities (training, vacation) to arrive at the total net man hours
available for development. The total net man-hours available are compared to the
6-8
Project Monitor
total planned hours of Project Tasks. This information is further broken down by key
staff and programming groups. This provides a first overview of the Long Range
Plan: whether the plan is realistic, what safety margin is available and whether key
people are overloaded. As a result, certain revisions may be needed. The plan is
entered in PM to reveal scheduling problems. Further revisions may then be
required.
3) Planning Standards
As a rule, the lapsed time from start date to completion date is spread as far as
possible in the planning. The main reason for this decision is to provide sufficient
time for users to study the detailed design and provide their input before
programming takes place. Another reason is that it provides more time for walkthroughs within the development group and with outside experts. The typical
lapsed time is 15 months. A consequence is that two applications will be developed
in parallel by an analyst and a programming group. Experience with BASIS I
showed an average development time, per application, of 24 man months, typically
6 people for 4 months. The time was divided as follows: 1/3 for analysis, 1/3 for
programming and 1/3 for testing and implementation. Estimates in the Long Range
Plan currently use these figures. An average application development check-list
follows under 6.2.2. It shows planned man-months, lapsed time and work to be
completed for each milestone. It also shows the planned work distribution to
employees included in the Long Range Plan.
6.2.2
Application Development Check List
(Not applicable).
6-9
PROJECT MONITOR
AND PLANNING
6 - 10
File Name Prefix Assignment
Internal
Standards
7.1
File Name Prefix Assignment 7-3
7-1
INTERNAL STANDARDS
7-2
7.1
To avoid file conflicts while testing BASIS II programs on the S/36 the following file
name prefixes have been assigned.
Function/Group
Prefix
AS
(W. Maresch)
B, E, M, K
CS1
(F. Sack)
CS2
(M. Felsmann)
DS
(S. Messner)
D1
(E. Lackermayer)
D2
(T. Linnahovi)
EID
(E. Mullner)
A; W,X,Y,Z
(for training)
IS1, IS2, IS3

(R. Egermann
P. Karas
F. Hank)
U,V
M2
(H. Letz)
M3
(H. Possl)
QC
(R. Friedl)
D,L
SS
(P. Jerabek)
I,J
7-3
INTERNAL STANDARDS
7-4
Standards for Query
Standards
for Query
8-1
STANDARDS FOR QUERY
8-2
Standards for Query
The file, format and field definitions for some AR and RS files are stored in the
BASNDIC folder. For distribution of new or changed definitions a second folder,
DISTrrDIC (rr=release level), is used. This contains ALL standard BASIS
definitions. The contents of this folder are copied into the BASNDIC folder, by
hand, when the user receives the updates.
AR and RS expect to find IDDU definitions in BASNDIC folder or the folder
specified in the BASIS Message Member MIC No. 0007, positions 1-8. Linking to
IDDU is done by the calling application procedure.
Query members are stored in a separate library called BASNQRY. For distribution
of new or changed members a second library, DISTrrQRY (rr=release level), is
used. This contains only new or changed members. The contents of this library are
copied 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 do
not have to be in BASNQRY. The Query library specified in the BASIS Message
Member MIC No. 0007, position 9-18, is no longer used.
NOTE
AT DISTRIBUTION TIME, THE USER IS FULLY RESPONSIBLE FOR
UPDATING THE:
BASNDIC FOLDER
BASNQRY LIBRARY
8-3
STANDARDS FOR QUERY
8-4

Basis Manual

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Basis Manual

Diunggah oleh

Hak Cipta:

Format Tersedia

BASIS II

Coca-Cola Computer Service G.m.b.H.

Software and Version:

T3 Development Standards Technical Guide

Documentation Structure 1-3

Page Numbering, Table of Contents, Standard Forms 1-17

Documentation Techniques 1-21

Naming Conventions 2-3

PTF53.5 T3 DEVELOPMENT STANDARDS

Program Error Messages 2-11

Screen Standards 2-29

Report Standards 2-73

Disk File Standards 2-79

CL/Program Communication 2-85

PTF53.5 T3 DEVELOPMENT STANDARDS

Program Design 2-91

Module Design 2-93

Structured Programming 3-7

Naming Conventions for COBOL Programs 3-19

Standards for Patchable Constants 3-37

Coding and Efficiency Techniques 3-51

Program Structure 3-61

PTF53.5 T3 DEVELOPMENT STANDARDS

Program Administration 3-67

Program Modules 3-69

3.10 S/36 - S/38 Considerations 3-75

Menu Standards 4-7

Message Member 4-37

PTF53.5 T3 DEVELOPMENT STANDARDS

5 APPLICATION DEVELOPMENT STANDARDS

Development Steps 5-3

Application Documentation (Top Down) 5-15

6 PROJECT MONITOR AND PLANNING

Project Monitor 6-3

File Name Prefix Assignment 7-3

8 STANDARDS FOR QUERY

PTF53.5 T3 DEVELOPMENT STANDARDS

This page intentionally left blank.

PTF53.5 T3 DEVELOPMENT STANDARDS

Documentation Structure 1-3

Page Numbering, Table of Contents, Standard Forms 1-17

Documentation Techniques 1-21

PTF53.5 T3 DEVELOPMENT STANDARDS

This page intentionally left blank.

PTF53.5 T3 DEVELOPMENT STANDARDS

Application manuals: aa = SM for Settlement, OM for Outlet

PTF53.5 T3 DEVELOPMENT STANDARDS

Current codes for System Functions (Xs) are:

Program Distribution Control (installed applications, program

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

Installation Options and Parameters (data dictionary, code

Job Control & Job History

Modules (table processing, field processing, frames, business

Utilities (for example, file print programs)

XW Copy Modules for Working Storage Section

PTF53.5 T3 DEVELOPMENT STANDARDS

User System Manuals

B2 - Business and System Approaches

B3 - Terms and Codes

PTF53.5 T3 DEVELOPMENT STANDARDS

CODE DEFINED BY:

= "the BASIS group" or "the User"

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

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