Jazz™ LRM: Section      2.     DEFINE and ATTRIBUTE

Rich data definitions are key to the power of Jazz™, so you should read at least the first part of this Section before reading further.

DEFINE – Introduction. 1

record-name. 1

Type Option. 1

DATA (data-list) 2

Extension xxx. 2

Record-Validity Option. 3

Trigger Option. 3

Record-Title. 3

DEFINE – Introduction

The Define statement defines the data that you work with in your Jazz™ programs, screens, and reports. You use Define to define working storage, file and database records, parameters, communication areas, and anything else that your program needs to deal with. Here are a couple of very basic Define statements: -

Define PreviousCustomer Data(

                Name Char(30),

                Address1 Char(30),

                Address2 Char(30),

                AccountID Integer,

                Balance Money(7.2));

Define Orders Type (SQL Database(OrderDB)) Data(

                OrderNbr  Integer  NotNull Title'Order Number',

                CustomerID Integer  NotNull Title 'Customer ID'

                                      Exists Customer.CustomerID,

                DateOrdered Date Title 'Date' 'Ordered');


The DEFINE statement has this form: -

DEFINE record-name

                [Type option]

                DATA (data-list)

                [record-validity option]....

                [trigger option]....

                [record-title option]



A Jazz™ “record” might be a relational database table, a screen message, a record on a physical file, or a collection of fields in working data. Depending on the TYPE option a record name might follow the restrictions of external names, or it might be valid to have longer names and to use hyphens.

Type Option

The Type Option describes the way in which the data is stored and accessed; for example, the type of file or database handler. Examples are: -

Type (SQL Database(OrderDB))

Type (VSAM)

Type (WorkingData)


If present, the Type option must precede DATA and other options. This is because different rules might be applied to different types of data. For example data in a relational database (e.g. DB2) cannot be grouped and cannot have dimension, but both groups and dimensions are permitted if the data has type VSAM.  TYPE(SYSTEM) is used to define special names like ZERO and $LEN: it has some special rules.


A full description of TYPE is included here.


If there is no TYPE option then TYPE(WorkingData) is assumed.

DATA (data-list)

The data-list describes each field or group of fields in the record. The description must include the field’s format – for example Char, Integer, and so on, but it also include validation criteria, display formats, initial values, and the error messages that validation checks are to issue. A full description is included here.

Extension xxx

This only applies when COBOL is the target language: the use of this option makes no difference to the meaning of your program, but alters the form of the generated COBOL slightly. xxx is a string of 2 to 4 characters in length that will be prefixed to the field names in the generated COBOL.


Field names may have been reused within your record definitions. Indeed, you are encouraged to do this. For example: -


    AccountNbr INTEGER KEY,

    NAME CHAR(30),

    ADDRESS1 CHAR(30),

    ADDRESS2 CHAR(30));


    AccountNbr INTEGER KEY,

    NAME CHAR(30),

    ADDRESS1 CHAR(30),

    ADDRESS2 CHAR(30));

This will have generated data structures: -

01  Record1.

      03 AccountNbr  PIC S9999 COMP.

      03 NAME PIC X(30).


01  Record2.

      03 AccountNbr  PIC S9999 COMP.

      03 NAME PIC X(30).



Also, Jazz™ may have created structures to save data, for example the last record read. So within your Jazz™ program names are automatically qualified to resolve ambiguity: you write

Name = “Robert Barnes”;

and Jazz™ will make this

Record1.Name = “Robert Barnes”;

and within the COBOL program generate

MOVE ‘Robert Barnes’ TO Name OF Record1.


Extension supports the common practice of COBOL programmers of using a naming convention to distinguish the different records, so that they do not have to write qualified references. If the DEFINE statements above had been written: -


    AccountNbr INTEGER KEY,

    NAME CHAR(30),

    ADDRESS1 CHAR(30),

    ADDRESS2 CHAR(30));


    AccountNbr INTEGER KEY,

    NAME CHAR(30),

    ADDRESS1 CHAR(30),

    ADDRESS2 CHAR(30));

Then the generated COBOL record layouts would have been

01  Record1.

      03 Rec1AccountNbr  PIC S9999 COMP.

      03 Rec1NAME PIC X(30).


01  Record2.

      03 Rec2AccountNbr  PIC S9999 COMP.

      03 Rec2NAME PIC X(30).


And the assignment statement can be generated as

MOVE ‘Robert Barnes’ to Rec1Name.

Record-Validity Option

Like a field-validity option this is a condition that must be valid for the record to be accepted, but whereas a field-validity option is written as an attribute of a particular field record-validity options are written outside the data list, and are checked after field-validity options. Refer to Validation in section 4 for more information.

Trigger Option

To be written


To be written