FUNDAMENTALS OF NATURAL PROGRAMMING

Objective of the Session

The objective of this course is to understand the basic programming concepts of Natural Prerequisites : Mainframe background (TSO/ISPF, JCL)

TOPICS OF INTEREST
INTRODUCTION NATURAL PROGRAMMING MODES NATURAL OBJECTS DATA AREAS DEFINING DATA STATEMENTS & OPERATORS & FUNCTIONS

USER DEFINED CONSTANTS

ARRAYS CONDITIONAL & LOOPING STATEMENTS PROGRAM & ROUTINE INVOKING STATEMENTS SEQUENTIAL FILE HANDLING SYSTEM VARIABLES & EDIT MASK

INTRODUCTION

ABOUT NATURAL
Natural is a complete application development environment for designing, developing and employing business-critical applications It supports all popular platforms, including mainframes, Windows, Unix, and Linux Programming Language Developed by Software AG It has been used by enterprises around the world since it was introduced in 1979 Fourth Generation Language Has both Online and Batch features Can access Sequential files ADABAS DB2 Programming modes Structured Reporting

ADVANTAGES Natural can be used to open up key information to clients and partners without major redevelopment Simple and efficient Natural requires fewer lines of code for a given task than other development languages The language is easy to learn; developers new to Natural can be trained and made productive in a matter of weeks

NATURAL PROGRAMMING MODES

Natural offers two ways of programming: Reporting mode Reporting mode is only useful for the creation of adhoc reports and small programs which do not involve complex data and/or programming constructs Structured mode Structured mode is intended for the implementation of complex applications with a clear and well-defined program structure

Setting the Programming Mode The default programming mode is set by the Natural administrator with the profile parameter SM. You can change the mode by using the Natural system command GLOBALS and the session parameter SM:

Structured Mode: Reporting Mode:

GLOBALS SM=ON GLOBALS SM=OFF

Functional Differences The following major functional differences exist between reporting mode and structured mode: Syntax Related to Closing Loops and Functional Blocks Closing a Processing Loop in Reporting Mode Closing a Processing Loop in Structured Mode Location of Data Elements in a Program Database Reference

Syntax Related to Closing Loops and Functional Blocks

Reporting Mode: (CLOSE) LOOP and DO ... DOEND statements are used for this purpose. END-... statements (except END-DEFINE, END-DECIDE and ENDSUBROUTINE) cannot be used.

Structured Mode:

Every loop or logical construct must be explicitly closed with a corresponding END-...statement. Thus, it becomes immediately clear, which loop/logical constructs ends where. LOOP and DO/DOEND statements cannot be used.

Closing a Processing Loop in Reporting Mode The statements END, LOOP (or CLOSE LOOP) or SORT may be used to close a processing loop The LOOP statement can be used to close more than one loop, and the END statement can be used to close all active loops A SORT statement closes all processing loops and initiates another processing loop

Closing a Processing Loop in Structured Mode Structured mode uses a specific loop-closing statement for each processing loop. Also, the END statement does not close any processing loop The SORT statement must be preceded by an END-ALL statement and the SORT loop must be closed with an END-SORT statement

Location of Data Elements in a Program

In reporting mode, you can use database fields without having to define
them in a DEFINE DATA statement Also, you can define user-defined variables anywhere in a program, which means that they can be scattered all over the program

In structured mode, all data elements to be used have to be defined in

one central location (either in the DEFINE DATA statement at the beginning of the program, or in a data area outside the program)

Database Reference
In reporting mode, database fields and DDMs may be referenced without having been defined in a data area In structured mode, each database field to be used must be specified in a DEFINE DATA statement (as described in Defining Names and Fields and Accessing Data in an Adabas Database)

NATURAL OBJECTS

OBJECTS OF NATURAL
Objects are used to achieve efficient application structure Types of objects :

Program Subprogram Subroutine Copycode Map Local data area Global Data Area Parameter Data Area

Creating and Maintaining Objects

To create and maintain all these objects, you use the Natural editors
Local data areas, global data areas and parameter data areas are created/maintained with the data area editor

Maps are created/maintained with the map editor

All other types of objects listed are created/maintained with the program editor

DATA AREAS

Natural supports three types of data area: Local Data Area Global Data Area Parameter Data Area

Local Data Area Variables defined as local are used only within a single Natural programming object There are two options for defining local data: You can define local data within a program You can define local data outside a program in a separate Natural programming object

Example 1 - Fields Defined Directly within a DEFINE DATA Statement: DEFINE DATA LOCAL 1 VIEWEMP VIEW OF EMPLOYEES 2 NAME 2 FIRST-NAME 2 PERSONNEL-ID 1 #VARI-A (A20) 1 #VARI-B (N3.2) 1 #VARI-C (I4) END-DEFINE ...

Example 2 - Fields Defined in a Separate Data Area: Program: DEFINE DATA LOCAL USING LDA39 END-DEFINE ... Local Data Area "LDA39": I T L Name F Length Miscellaneous All -- -------------------------------- - ---------- -------------------------> V 1 VIEWEMP EMPLOYEES 2 PERSONNEL-ID A 8 2 FIRST-NAME A 20 2 NAME A 20 1 #VARI-A A 20 1 #VARI-B N 3.2 1 #VARI-C I 4

Global Data Area

A global data area (GDA) is a Natural programming object that allows programs and external subroutines to share data elements

The data elements shared can be read or modified

In a GDA, you define the characteristics and the sequence of data elements that determine the layout of a GDA instance

A GDA instance is a piece of storage containing data element values that can be shared by Natural programming objects
Any modification of a data element value in a GDA affects all Natural programming objects that reference the same instance of this GDA

Parameter Data Area A Natural programming object of the type parameter data area (PDA) is used to define the data elements that are passed as parameters to a subprogram or external subroutine. A PDA allows subprograms and external subroutines to use the same data element definitions. Subprogram is invoked with a CALLNAT statement. With the CALLNAT statement, parameters can be passed from the invoking object to the subprogram. These parameters must be defined with a DEFINE DATA PARAMETER statement in the subprogram

They can be defined in the PARAMETER clause of the DEFINE DATA statement itself; or They can be defined in a separate parameter data area, with the DEFINE DATA PARAMETER statement referencing that PDA.

Parameters Defined within DEFINE DATA PARAMETER Statement

Parameters Defined in Parameter Data Area

DEFINING DATA

DEFINING USER VARIABLES

User-defined variable can be defined by specifying the following in the DEFINE DATA statement

DEFINE DATA LOCAL level-number variable-name level-number variable-name level-number variable-name END-DEFINE

(format/length) (format/length) (format/length)

LEVEL-NUMBER => 1 or 2 digit numbers of range 01 to 99 (leading 0 optional) VARIABLE-NAME => Should be alphanumeric format with length of 32 characters Note: Working variables usually have # as first char

Level Numbers The level numbering in view definitions, redefinitions and groups must be sequential; no level numbers may be skipped If you define a view, the specification of the view name must be on Level 1 and the fields the view is comprised of must be on Level 2 Example of Level Numbers in View Definition: DEFINE DATA LOCAL 1 VIEWEMP VIEW OF EMPLOYEES 2 NAME 2 FIRST-NAME 2 BIRTH ... END-DEFINE

While redefining a field, the REDEFINE option must be on the same level as the original field and the fields resulting from the redefinition must be one level lower

Example of Level Numbers in Redefinition: DEFINE DATA LOCAL 1 VIEWEMP VIEW OF STAFFDDM 2 BIRTH 2 REDEFINE BIRTH 3 #YEAR-OF-BIRTH (N4) 3 #MONTH-OF-BIRTH (N2) 3 #DAY-OF-BIRTH (N2) 1 #FIELDA (A20) 1 REDEFINE #FIELDA 2 #SUBFIELD1 (N5) 2 #SUBFIELD2 (A10) 2 #SUBFIELD3 (N5) ... END-DEFINE

Format/length of VARIABLE TYPES

Alphanumeric (Annn) Numeric (Nnn.m) Integer (In) Date (D) Time (T) Logical (L) PACKED NUMERIC (P) EXAMPLE : 1 to 253 characters 1 to 29 digits 1,2 or 4 bytes 4 bytes 7 bytes 1 byte (TRUE/FALSE) 1 TO 29 DIGITS

DEFINE DATA LOCAL

01 #ENDOFFILE 01 #DATEOFJOIN 01 #EMPL-NAME 01 #EMP-SAL 01 #WS-COUNTER (L) (D) (A20) (N9.2) (I2)

END-DEFINE

INIT AT DEFINING
Initial value can be set while defining a variable Example : DEFINE DATA LOCAL 01 #FIELD1 01 #FIELD2 01 #FIELD3 END-DEFINE

(N3) INIT <100> (A10) INIT <USTR> (L) INIT <FALSE>

REDEFINE
The redefinition must be specified immediately after the definition of the original field In the following example #VAR2 is redefined as #VAR3 DEFINE DATA LOCAL 01 #VAR1 (A15) 01 #VAR2 02 #VAR22 (N4) 01 REDEFINE #VAR2 02 #VAR3 (A4) END-DEFINE

FILLER
FILLER can be used as in COBOL 1 #OUT-DETAIL-LINE (A100) INIT <' '> 1 REDEFINE #OUT-DETAIL-LINE 2 #OUT-MAILB-ID (A8) 2 FILLER 2X 2 #OUT-USER-IDEN (A25) 2 FILLER 2X 2 #OUT-DATE-ADDED (A10) 2 FILLER 2X 2 #OUT-TIME-ADDED (A8) 2 FILLER 2X 2 #OUT-STATUS (A10) 2 FILLER 4X 2 #OUT-BTCH-NUM (N7)

Thank You