ch18.bodyTEXTDmWr BuFymBIN ch18.htm

A NATURAL program, even though there are no physical sections, should contain these logical sections:

Header Block
Housekeeping Section
Processing Section

Header Block

This Header Block will vary from one shop to the next. Most systems applications require this block in one form or another. Who has worked on the program and what modifications have been applied are important pieces of data that should be included in this block along with many of the following:

Program Name

 This MUST adhere to the naming conventions detailed in the Naming Conventions Section
System Name Name of the system of which this program is a component
Author Original author of program
Analyst Original analyst
Date Written Date original program written
Description This should be a short description of what the program does
Database Files Used The names of all DDMs used and their usage, that is, Read/Search/Update/Delete and so on
Change History
A list of dates of when the program was changed, by whom and the nature of the change. If your installation uses change Control Reference Numbers or similar control data, it should also be documented her
Work Files A list of work files accessed and their use. Omit if there are no work files utilized

Report Files

 A list of print files produced by the program. Omit if there are none
Maps/Forms Used A list of maps/forms used within the program and a brief description of each
Data Areas A list of all Data Area used
Modules Invoked A list of modules invoked. Omit is there are none
Invoking Modules A list of modules which invoke this program. Omit if there are none

Note: Several techniques have been developed for inserting this block into programs. One straightforward method is generating a COPYCODE member in a using ".i" to insert the code into the program. INCLUDE is just as appropriate where "standards" have been established and, as a rule, programmers are not supposed to modify the included code.

0010 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0020 * PROGRAM NAME : XXXXXXXX     SYSTEM : SYSTEM NAME
0030 * AUTHOR : XXXXXXXXXXXXXXX    ANALYST: XXXXXXXXXXX
0040 * DATE : YY/MM/DD
0050 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0060 * DESCRIPTION : IN TWENTY FIVE WORDS OR LESS TELL US
0070 * WHAT THIS PROGRAM DOES
0080 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0090 * CHANGES : CHANGE DATE, PROGRAMMER NAME,
0100 * DESCRIPTION OF THE MODIFICATION
0110 * IF YOUR INSTALLATION USES CHANGE
0120 * CONTROL NUMBERS, ENTER HERE)
0130 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0140 * DATABASE FILES USED: FILENAMES & USAGE
0150 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0160 * WORK FILES : 1 - WORK FILE 1 NAME & USAGE
0170 * : 2 - WORK FILE 2 NAME & USAGE
0180 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0190 * REPORT FILES : 1 - REPORT FILE 1 NAME
0200 * : 2 - REPORT FILE 2 NAME
0210 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0220 * MAPS/FORMS USED : MAPS/FORMS NAMES & DESCRIPTIONS
0230 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0240 * DATA AREAS : DETAILS OF ALL DATA AREAS REFERENCED
0250 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0260 * MODULES INVOKED : MODULE NAMES & DESCRIPTIONS
0270 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
0280 * INVOKING MODULES : MODULE NAMES & DESCRIPTIONS
0290 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Figure 18.1 - Header Block Example

Housekeeping Section

This section contains all relevant information about user data elements and parameters in force for the duration of the program. This section should be coded as follows:

Data Definition

All programs in Structured Mode MUST begin with a DEFINE DATA statement. this block is used to identify all Global, Local and Parameter data areas used by the program. Each of these areas are definitions of variables and views of DDMs, which have been pre-defined.

DEFINE DATA Statement

To include the setting of initial values and redefines. Any redefinition of program variables or database fields should be defined in the appropriate data area. If Periodic groups or Multiple Value fields are referenced from databases, the view which should have been set up in the data areas will permit blocks of occurrences to be read. The program must retrieve the appropriate blocks for its processing, as the view by default will only retrieve the first block. Work Files must not be used to pass parameter data to other programs.

SET KEY Statement

If required. Standards are easily applied for PF key settings across an application through a COPYCODE member.

INPUT Statement

Only if the program is FETCHed or RUN and variables are passed. An INPUT USING MAP is used for the execution of data processing panels.

ON ERROR Block

Placed here for ease of location.

SUBROUTINEs

Placed here unless they access data base fields, in which case they should be inside the loop that acquires the data. One except, of course, would be those external subroutines common to the enterprise.

All data areas must conform with the naming conventions described in Naming Conventions Section.

Processing Section

This section contains all the logic applicable to performing the pro gram's function.

The following standards should be adhered to when coding statements within the Processing Section.

Indentation

Indent coding to improve the readability of source code. Basic indentation of source code can be achieved using the STRUCT command. (We suggest setting a Program Function key in the PROFILE to STRUCT for ease of use; see PROFILE Section).

The following formats of indentation should be used:

Similarly, keywords or statements should be aligned under each other.

Comments

All comments should be short and to the point. If supported by your installation, comments may be entered in lower case for readability.

Since many NATURAL programs are relatively small, be careful not to hide the actual program code with numerous screens of documentation.

Comments are denoted using one of the following formats in columns 1 and 2 of source lines:

'* ' '**' '/*' '*/'

0000 * COMMENTS
0000 ** COMMENTS
0000 /* COMMENTS

The '* ' (asterisk-space) should be used except where comments start in columns other than 1 in which case, '/*' must be used.

0000 * COMMENTS
0000 * COMMENTS
0000 *
0000 statement
0000 statement /* COMMENT

Note: A blank line can be included instead of using the '*' at the beginning of a spacer line. See the PROFILE section, Additional Options, for blank line support.

It is not necessary to "box" comments, however, to maintain readability, blocks of comments should be bordered by a blank line beginning with an asterisk or turn on the blank line save feature in the PROFILE:

:
0000 statements
0000 *
0000 * comments
0000 *
0000 statements
:

instead of

:
0000 statements
0000 * * * * * * * * * * * * * * * * * * * * * * * *
0000 * comments
0000 * * * * * * * * * * * * * * * * * * * * * * * *
0000 statements
:

Note that the use of '*/' will cause a new page (an eject) to be started at this source comment line when using the NATURAL LIST command.

Use comments prior to each major processing blocks within a program to explain complex coding.

Use a '/*' type comment after every END-type statement to document which loop or block is being closed. NATURAL will automatically renumber these comments provided a valid line number of four numeric digits enclosed in parentheses with no embedded spaces is used.

:
0180 *
0190 * Read Employees File
0200 *
0210 READ EMPLOYEES
:
0300 END-READ /* (0210)
:
:
0180 *
0190 * Read Employees File
0200 *
0210 REMPL01. READ EMPLOYEES
:
0300 END-READ /* (REMPL01.)
:

Each internal subroutine should be preceded by a '*/' so that each one appears on a separate page, when the full program is LISTed.

NATURAL Statements

General Guidelines

Each NATURAL statement should start on a new line. If the whole of a statement cannot be concluded on one line, subsequent lines must be indented to leave the statement keyword clearly visible and all keywords should be aligned accordingly.

For example:

FIND VEHICLES WITH MAKE = 'PORSCHE'
  AND COLOR = 'RED' OR = 'BLACK'
READ EMPLOYEES IN LOGICAL SEQUENCE BY PERSONNEL-ID
  STARTING FROM '20000000
  ENDING AT '29999999'

When coding an IF statement, the following rules apply:

Nested IF statements, illustrated below, should be avoided since they are somewhat difficult to maintain and impair readability in general:

0200 IF VEHICLES.LEASE-PUR = 'B'
0210   IF VEHICLES.CLASS = 'P'
0220     MOVE

The IF statement could have been combined to read as:

0200 IF VEHICLES.LEASE-PUR = 'B'
0210     AND VEHICLES.CLASS = 'P'
0220   MOVE

Or, depending on the number of combinations needed, a DECIDE FOR statement could add significantly to the readability entirely:

0200 DECIDE FOR EVERY CONDITION
0210   WHEN VEHICLES.LEASE-PUR    = 'B'
0220     AND VEHICLES.CLASS    = 'P'
0230     MOVE
0240   WHEN VEHICLES.LEASE-PUR    = 'B'
0250     AND VEHICLES.CLASS    = 'L'
0260     MOVE
0270   WHEN NONE IGNORE
0280 END-DECIDE

Program Termination

Always use END, avoiding the period. Coding STOP in a program should be avoided (to return to any calling module, use the ESCAPE ROUTINE statement). TERMINATE should be used with caution.

Conditional Processing

Always place AT BREAK statements towards the end of the block within the loop to which they apply. AT END OF PAGE and AT TOP OF PAGE should be coded at the end of the program or loop generating the report which they reference. All other conditional blocks should be coded at the end of the loop. See Figure 18.2.

AT END OF DATA statements should be coded after the last AT BREAK in programs where automatic break processing is in effect (this statement signals all breaks to be processed prior to its execution thus this puts the statement block in its logical flow).

AT START OF DATA should be coded towards the end of the block within the loop, again, for clarity.

Maps

The NATURAL Mapping Facility should be used for development of maps since it provides a robust environment for map, forms and help definitions. Maps coded in the Map Editor are invoked from within the NATURAL module:

0020 INPUT USING MAP 'map-name'

Avoid using the .I(map-name) Line Command since this also generates the accompanying field list increasing the source size, which is not really necessary. However, this is a good technique to use as a temporary debugging tool to verify the fields in the map are also defined in the program (remember to delete the lines after you have evaluated their validity).

DEFINE DATA
GLOBAL USING ...
LOCAL USING ...
LOCAL
END-DEFINE
** HOUSEKEEPING STATEMENTS: FORMAT, SET KEY, ETC.
READ ... /* ACCESS THE DATA
  : /* MANIPULATE THE DATA
  DISPLAY /* DETAIL DISPLAY
  :
  WRITE TITLE /* TITLE THE REPORT
  :
  AT TOP OF PAGE /* THIS CONDITION IS AVAILABLE
    : /* AFTER THE TITLE IS OUTPUT
  END-TOPPAGE /* AND BEFORE ANY HEADERS
  AT START OF DATA /* THIS CONDITION AVAILABLE
    : /* ONE TIME PER PROCESSING
  END-START /* LOOP
  AT BREAK OF #1 /* CONTROL BREAK ON LOW
    : /* ORDER CONTROL FIELD
  END-BREAK
  AT BREAK OF #2 /* CONTROL BREAK ON HIGH
    : /* ORDER CONTROL FIELD
  END-BREAK
  AT END OF DATA /* THIS CONDITION AVAILABLE
    : /* ONE TIME FOR PROCESSING
  END-ENDDATA /* LOOP
  AT END OF PAGE /* THIS CONDITION IS AVAILABLE
    : /* AFTER THE PAGE SIZE PARAMETER
  END-ENDPAGE /* HAS BEEN EXCEEDED
END-READ
END
Figure 18.2a - AT Condition Positioning Guidelines
DEFINE DATA
GLOBAL USING ...
LOCAL USING ...
LOCAL
END-DEFINE
** HOUSEKEEPING STATEMENTS: FORMAT, SET KEY, ETC.
READ ...                /* ACCESS THE DATA
  :                     /* MANIPULATE THE DATA
  DISPLAY               /* DETAIL DISPLAY
  :
  WRITE TITLE           /* TITLE THE REPORT
  :
  AT TOP OF PAGE        /* THIS CONDITION IS AVAILABLE
    :                   /* AFTER THE TITLE IS OUTPUT
  END-TOPPAGE           /* AND BEFORE ANY HEADERS
  AT START OF DATA      /* THIS CONDITION AVAILABLE
    :                   /* ONE TIME PER PROCESSING
  END-START             /* LOOP
  AT BREAK OF #1        /* CONTROL BREAK ON LOW
    :                   /* ORDER CONTROL FIELD
  END-BREAK
  AT BREAK OF #2        /* CONTROL BREAK ON HIGH
    :                   /* ORDER CONTROL FIELD
  END-BREAK
  AT END OF DATA        /* THIS CONDITION AVAILABLE
    :                   /* ONE TIME FOR PROCESSING
  END-ENDDATA           /* LOOP
  AT END OF PAGE        /* THIS CONDITION IS AVAILABLE
    :                   /* AFTER THE PAGE SIZE PARAMETER
  END-ENDPAGE           /* HAS BEEN EXCEEDED
END-READ
END
Figure 18.2b - Many Programmers Prefer Comment Alignment for Neatness

Sorting

For on-line applications, use of the READ LOGICAL is strongly recommended. No actual sort is performed, since the index is already in the correct order, so the response should be better.

SORT is available in both batch and on-line in NATURAL. When using SORT in on-line programs, only use it where necessary, that is, where a READ IN LOGICAL SEQUENCE would not be effective. In both programming modes, SORT MUST always be coded with the USING clause even if only KEYS is selected. This gives the SORT a much better performance edge for a function that is already detrimental to response time.

NEVER use the FINDSORTED BY statement combination. At least twice the normal overhead in ADABAS is required to order the data when SORTED BY is coded. Use the alternatives of READ LOGICAL or SORT BY instead, always evaluating and using READ LOGICAL whenever possible.

SORT Program Phases

SORT programs are always processed in three phases:

The first phase is directly concerned in selecting the data to be sorted and is always terminated with an END-ALL statement. Access loops opened in this phase should not be terminated if data from the file accessed is to be release to the SORT.

Phase two is the SORT itself. The SORT statement is followed by a field list of not more than ten variables. These fields are the sorted order of the data after the SORT is complete. The first field specified is the major sort, the next the first intermediate sort, etc. and the last is the minor field of the sorted group. Additional fields to be included as part of the sort record but are not ordering fields must be listed with a USING clause. If only the fields coded in the field list following the SORT are to be used in phase three, USING KEYS must be specified. 

0010 *** *** *** P H A S E 1 *** *** ***
0020 *
0030 * EXAMPLE OF A SORT PROGRAM
0040 * ONLY ONE SORT PER PROGRAM MAY BE CODED
0050 *
0060 DEFINE DATA LOCAL USING CLASSLDA
0070 END-DEFINE
0080 FIND EMPLOYEES WITH COUNTRY = 'UK'
0090 WHERE CITY = 'WELLESLEY' OR = 'KINGSTON-UPON-THAMES'
0100 IF CITY = 'WELLESLEY'
0110 MOVE 'MA' TO COUNTRY
0120 END-IF
0130 END-ALL
0140 *** *** *** P H A S E 2 *** *** ***
0150 SORT COUNTRY CITY NAME
0160 USING FIRST-NAME JOB-TITLE SALARY(1) CURR-CODE(1)
0170 *** *** *** P H A S E 3 *** *** ***
0180 AT START OF DATA
0190 WRITE CITY
0200 END-START
0210 IF BREAK OF CITY
0220 WRITE / CITY
0230 END-IF
0240 DISPLAY NAME FIRST-NAME JOB-TITLE SALARY(1) CURR-CODE(1)
0250 AT BREAK OF CITY
0260 PRINT 'TOTAL RESIDENTS' COUNT(NAME)
0270 END-BREAK
0280 AT BREAK OF COUNTRY
0290 PRINT 'TOTAL RESIDENTS OF' OLD(COUNTRY) COUNT(NAME)
0300 END-BREAK
0310 END-SORT
0320 END
Figure 18.3 - Program Example Illustrating the Three Phases of a NATURAL Program Containing a SORT Statement.

The third phase contains all the logic coded to process the sorted data. This block of code MUST be terminated with END-SORT. See illustration on the previous page.

Only one SORT statement per NATURAL program is allowed.

See the Performance Considerations Section for more on SORT.

Programming Modes

The are three programming modes supported in NATURAL 2:

Structured Mode
Structured Data Mode (often called "mixed mode")
Reporting Mode

All NATURAL object should be coded in Structured Mode.

Reporting Mode should only be used for utility and/or ad hoc programming to assist in the development process and testing, that is, test data generation, verification of program testing, and so forth. Where possible, consider the use of SUPER NATURAL in place of using Reporting Mode to generate the appropriate routines quickly. ESPERANT is fast becoming a standard in many shops for ad hoc access to many data bases, not just ADABAS.

Reporting Mode should only be available in support and maintenance of existing systems and applications written in NATURAL Version 1.x and ad hoc reporting.

Structured Data Mode requires the DEFINE DATA statement to define all database views and user defined variables and maintains the general constructs of Reporting Mode in the procedural statements. For example, LOOP is used to terminate FINDs and READs instead of END-FIND and END-READ respectively; dynamic definition of variables is disallowed, that is, they must be defined in the DEFINE DATA statement; statements like MOVE INDEXED are still supported but should be replaced with array processing whenever possible.

Structured Data Mode is optional and only represents a medium for moving (converting) from Reporting Mode to Structured Mode. It is recommended to proceed with a full conversion rather than pass through this intermediate step when converting from Version 1.x to the current release of NATURAL.

Structured Mode Restrictions

Please note the following restrictions for Structured Mode, that is to say, supported in Report Mode but unavailable to Structured Mode programming:

Error Message Handling

A set of Error Messages should be defined and set up for each application for use by all programs to insure consistency across the system. REINPUT with a text line should not be allowed. If a new error message is required, then it must be added to the central application list. The messages must be defined to NATURAL via the SYSERR, the Error Messages Utility. This is invoked by the command SYSERR from any application library. [Note: this editor disagrees with the approach the author has taken here preferring REINPUT and its variations for error messages]

A SHORT text must be defined by the Analyst or Data Administrator for each message; this will then be allocated a number and added to the message library for that application by the Data Administrator.

Message numbers must then be used by all application programs as:

0000 REINPUT *nnnn

Where nnnn is the Error Message Code defined within the application utilizing the SYSERR Utility.

HELP Facilities

Each application should provide some degree of help. How much help should be determined between the end-users and the project team. There are three main areas concerned with providing help:

- General help about a transaction. Usually it is instructional and doesn't require entering or typing data, or pressing Program Function keys to continue processing, for example,

+--------------------------------------------------------------+ 
| THIS TRANSACTION ALLOWS YOU TO ENTER VARIOUS SEARCH CRITERIA |
| FOR A VEHICLE AND WILL THEN DISPLAY A LIST OF POSSIBLE       |
| MATCHES DETAILING MAKE, MODEL, COLOR, BODY TYPE AND YEAR.    |
|                                                              |
+--------------------------------------------------------------+

- Listing valid command or menu options. This is usually more of an informational nature and again, pressing the ENTER key is all that is need to continue processing:

+----------------------------+
| AVAILABLE OPTIONS ARE:     |
| ADD A NEW RECORD.........A |
| DELETE A SINGLE RECORD...D |
| CHANGE A RECORD..........C |
|                            |
+----------------------------+

- Listing valid values for an input field. No other action is required except pressing the ENTER key:

+----------------------------+
| RECORDS AVAILABLE FOR:     |
| CHRYSLER, FORD, GENERAL    |
| MOTORS, AMERICAN MOTORS,   |
| FIAT, VOLVO, MERCEDES,     |
| SAAB, VOLKSWAGEN, JAGUAR   |
| AND ROLLS ROYCE.           |
|                            |
+----------------------------+

Where possible, type the information in mixed case. It is more easily read when typed in upper/lower case.

+--------------------------------------------------------------+ 
| This transaction allows you to enter various search criteria |
| for a vehicle and will then display a list of possible       |
| matches detailing Make, Model, Color, Body Type and Year     |
|                                                              |
+--------------------------------------------------------------+

While these three types of windows may be executed using HELPROUTINEs or HELPTEXT, it is suggested that these information/instructional functions be accomplished through the HELPTEXT facility.

HELPTEXT modules are coded in the Map Editor (Select Code: H) with the dimensions established within the Delimiter Setting Menu. HELPTEXT, when attached to a field and called upon, will automatically position the base of the window (it's upper left hand corner) one line down and directly under the first column of the field for which help is being provided.

If the window is too large to be displayed at that position, NATURAL will automatically reposition the window elsewhere on the screen. Unless it is too close to the bottom right hand corner or the screen, the window will be placed in the same column and above the field. If there isn't any room with fields in the lower right hand portion of the screen, the full dimension of the window will be positioned in the right hand corner.

HELPTEXT should also be used to establish a generic help window for the original screen of data. Attaching this help member to the INPUT statement will then give informational data to the user in the case where help is not specifically provided.

HELPTEXT should generally only be used as a help facility and not for validation or addition processing. If list of options are provided and a selection is to be made, then a HELPROUTINE should be used for this function.

HELPROUTINEs should be used as help where one or more data values must be passed between the field(s) on screen and the HELPROUTINE. For every input field that is defined on a MAP, a HELPROUTINE may be defined. When the individual input fields are edited, a HELPROUTINE name may be specified in the HE= parameter field. The specified HELPROUTINE is then automatically executed if:

Note: these conditions invoke help attached to the field, whether it is HELPTEXT or a HELPROUTINE.

Example of a REINPUT invoking a HELPROUTINE: 

0200 INPUT (HE='HELP0')
0210   #FLD1(HE='HELP1') #FLD2 #FLD3(HE='HELP3')
0220 IF NOT (#FLD1 = 'A' OR = 'D' OR = 'C' OR = 'X')
0230   REINPUT USING HELP MARK *#FLD1
0240 END-IF

Produces:

+----------------------------+
| PLEASE ENTER A CORRECT     |
| VALUE IN THIS FIELD        |
| ..........                 |
|                            |
+----------------------------+

Global help for a MAP can be specified when a MAP is initialized or when the MAP profile is maintained or on the INPUT statement if coded in the program directly, as in the example above. It is recommended that if generic or general help is to be provided, do it in the Map Editor. The help member is then applied to all fields and individual field help may be handled on a one-to-one basis. As in the case of #FLD2, no help has been attached directly to the field but because of the HE parameter setting on the INPUT statement, HELP0 will be invoked when help is requested on #FLD2.

The field value is automatically available to the HELPROUTINE and transferred between the main program and the HELPROUTINE through the DEFINE DATA PARAMETER statement coded in the HELPROUTINE.

0010 *
0020 * HELP1A
0030 *
0040 DEFINE DATA PARAMETER
0050 1 #FIELD1-VALUE(A10)
0060 END-DEFINE
0070 DEFINE WINDOW CHK-FLD
0080 * SIZE 5 * 30 WHEN OMITTED THE DEFAULT IS "AUTO"
0090 * BASE 10 / 10 WHEN OMITTED THE DEFAULT IS "CURSOR'
0100 TITLE ' Field1-Value Help'
0110 CONTROL SCREEN
0120 FRAMED ON
0130 INPUT WINDOW='CHK-FLD' 'Please enter a correct'
0140 / 'value in this field'
0150 / '>' #FIELD1-VALUE    (AD=M'.')
0160 END

Produces:

+---Field1-Value Help----+
| Please enter a correct |
| value in this field    |
| > ..........           |
+------------------------+

If help is requested for #FIELD1, the HELPROUTINE, HELP1, is invoked and will not only display a pop-up window but will display the current value of #FIELD in the window. Because the Attribute Definition is set to M, the value may be changed in the window and will be transferred back into the field in the main screen when the ENTER key is depressed.

Use of the DEFINE WINDOW statement provide more flexible windows the use of the %W Terminal Command.

Terminal Commands

Terminal Commands can be executed from within the application program by using the SET CONTROL statement. Only the following Terminal Commands are permitted for modification:

%L Lower case translation. When upper and lower case support is specified, this Terminal Command will be needed to insure translation takes place. Please insure the TP monitor also translates in the same mode.
%N Non-conversational write. Used more commonly with windowing, this allows the system to pass through the main screen back to the controlling program without having to press the ENTER key a second time. Usually data that has been typed into a window will be returned to the original screen at which time the user must press the (ENTER key again to cause control to return to the program.
%R Rebuild screen. Returns the original screen of values when executed, usually through a PA key. Effective only if the ENTER key has not been depressed.
%T Position cursor. This is an alternative to the MARK FIELD option used in INPUT and REINPUT statements which also supports a POSITION option for more discreet cursor placement. By default, the cursor positions itself in the first position of the first modifiable field on a screen unless MARK FIELD is specified. If another position is required, this Terminal Command (usually executed with a SET CONTROL from within the program) will effect the placement. It syntax is %Tlll/ccc where lll is the line and ccc the column in which the cursor is to be place on the next execution of INPUT.
%U Upper case translation. When upper case support only is specified, this Terminal Command will be needed to insure translation takes place. Please insure the TP monitor also translates in the same mode.
%W Paging and windowing. Utilized for page movement and window definition. See section on Windowing. See also the DEFINE WINDOW statement which is a better alternative.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Optionally, the following may be allowed where applicable:

%YL Display (last twelve) PF keys 13 - 24. Support of 24 Program Function key is allowed. To display these keys, %YL is executed from with the program via a SET CONTROL statement. Usually %YL is set to a PF key which must be properly labeled as to its function (in effect, removing two keys from the active list since they will have to toggle this display. See %YX.)
%YF Display (first twelve) PF keys 1 - 12. The default.
%YX Toggle between the display of PF keys 1 - 12 and PF keys 13 - 24.
%C Copy screen into current source. Very optional. More for those whose task is documentation and it is limited. By typing %C on the Command Line, the current screen will be copied into the source work area giving the documentation person or technical writer an opportunity to capture data without having to type it into the member being used for documenting the system or transferring it in from some other media.
%Caaa Copy data from the current screen into the NATURAL System Variable *COM (or NATURAL STACK). This function defines a Cursor Sensitive function allowing the user to position the cursor at the "selected" value and when the enter key is pressed, the data is transferred into either *COM or NATURAL's STACK.

 

 

 

 

 

 

 

 

 

 

 

DECIDE ON and DECIDE FOR

These statements are for use in deciding on an action depending on a single variable or multiple conditions. A typical Case Statement.

Only simple condition statements should be used, that is, those not leading to further loop processing, in these statements. The DECIDE FOR statement is used to decide for one or more actions depending on multiple conditions.

0200 *
0210 * SELECT SETTING FOR    MAINTENANCE COST CALCULATION
0220 *
0230 DECIDE FOR FIRST CONDITION
0240   WHEN VEHICLES.CLASS = 'P'
0250     AND VEHICLES.LEASE-PUR = 'B'
0260     MOVE '1' TO #SWITCH
0270   WHEN VEHICLES.CLASS = 'P'
0280     AND VEHICLES.LEASE-PUR = 'L'
0290     MOVE '2' TO #SWITCH
0300   WHEN VEHICLES.CLASS = 'C'
0310     AND VEHICLES.LEASE-PUR = 'B'
0320     MOVE '3' TO #SWITCH
0330   WHEN VEHICLES.CLASS = 'C'
0340     AND VEHICLES.LEASE-PUR = 'B'
0350     MOVE '4' TO #SWITCH
0360   WHEN ANY
0370     PERFORM CALC-MAINT-COSTS
0380   WHEN NONE
0390     IGNORE
0400 END-DECIDE
0410 :


0600 DECIDE ON FIRST CONDITION
0610   WHEN *PF-KEY = 'PF1'
0620     OR #SELECT-CODE = '?'
0630     OR #COMMAND = 'HELP'
0640     PERFORM HELP-ROUTINE
0650   WHEN *PF-KEY = 'PF2'
0660     OR #SELECT-CODE = 'L'
0670     OR #COMMAND = 'LIST'
0680     PERFORM LIST-ROUTINE
0690   WHEN *PF-KEY = 'PF12'
0700     OR #SELECT-CODE = '.'
0710     0R #COMMAND = 'QUIT'
0720 :

DECIDE ON is used to specify multiple actions to be performed depending on the value or values in a specific variable.

0180 :
0190 *
0200 * CONVERT TO US DOLLARS
0210 *
0220 DECIDE ON FIRST VALUE OF EMPLOYEES.CURR-CODE(1)
0230   VALUE 'FRA', 'PTA'
0240     DIVIDE 6 INTO EMPLOYEES.SALARY(1)
0250   VALUE 'DM'
0260     DIVIDE 1.5 INTO EMPLOYEES.SALARY(1)
0270   VALUE 'UKL'
0280     MULTIPLE EMPLOYEES.SALARY(1) BY 1.5
0290   VALUE 'DKK'
0300     DIVIDE 4 INTO EMPLOYEES.SALARY(1)
0310   NONE
0320     IGNORE
0330 END-DECIDE
0340 :

Copycode

Use of an INCLUDE statement in a program allows the source code to be included from an external COPYCODE source member at compile time. On each subsequent compile, the latest version of the COPYCODE will be inserted into the object version of the program. The actual source code lines do not appear in the program as a replacement for the INCLUDE statement.

Good for "enforcing" standards, for example, PF key settings can be stored as COPYCODE insuring each program uses the same settings.

The Header Block mentioned earlier is a candidate for COPYCODE in that a simple ".i(header-block-name)" is all that is needed to insert the source code directly into the program for change.

RESET

The RESET statement should always be used to set any field to null values. This is highly recommended over MOVE 0 or MOVE ' ' or ASSIGN field = 0. It may be coded with multiple fields of various types to reset each to null values.

Optionally, the INITIAL clause should be used when resetting variables to their initialized values, i.e., DEFINE DATAINIT. It is not specifically recommended that RESET INITIAL be used all the time even though it effects both types of RESET options in a single statement. Some applications would prefer a RESET after initial startup for the work they are going to put the variable through.

View Definition

For each program, there will be a number of LDAs as follows:

Note HISTOGRAM may be executed for a descriptor-type even if it isn't mentioned in a file view instead of having to code a separate view specific to the HISTOGRAM.

The convention for the view names within an LDA must be as follows:

Database File Updating

All database file update processes should be designed to make the most efficient use of the END TRANSACTION and BACKOUT TRANSACTION statements.

Batch programs should be designed in such a way as to be re-startable by using GET TRANSACTION DATA without any special intervention like database file restores.

See the Transaction Processing Section for further details.

2 Dreamweaver28A2STR <