• Aucun résultat trouvé

DBDGEN 7 FINISH

Dans le document Information Management System/360 for the (Page 117-123)

Simulation is accomplished by appending two modules to the message processing program in addition to the language interface (Simulator

CHAPTER 7. SYSTEMS OPERATION INTERFACE

6 DBDGEN 7 FINISH

its DBD and i t is from this pool of information that other internal Data Language/I control blocks are built at execution time.

I t is not the responsibility of the application programmer to

generate the DBD's that affect the data bases he uses. However, i t is imperative that he be able to understand the contents of a DBD in order to utilize the data bases that already exist and are available to him.

Before Data Language/I can be used to process data base information, or even before the data base can be created, the data base must be described to Data Language/I. The organizat'ion of the data within the data base must be completely described so that i t can properly set up the tables and control blocks that determine how the data is to be stored.

The result of the procedures described here is the creation of a Data Language/I data base description (DBD) table that is required when the data for the data base is actually loaded into the system and when i t is retrieved and manipulated during execution of any application program.

Each DBD is stored as a member of a load module library generically titled the DBD library.

This procedure must precede any processing that will in any way reference the data base i t describes. The data base cannot exist until the Data Base Description is completed.

In general, the control statements for DBD generation appear as follows:

r---,

1 [PRINT NOGEN]

2 DBD NAME=". ACCESS=

3 OMAN DD1=,DEV1=, [002=], [DLIOF=]

4 SEGM NAME=" PARENT=, BYTES= ,FREQ=

5 FLDK NAME=,TYPE=,BYTES=,START=

[FLO NAME=,TYPE=,BYTES=,START=]

6 DBDGEN 7 FINISH 8 END

_________________________________________________________ J

Note: At least one OMAN, SEGM and FLDK card must exist within the Data Base Description. Following each OMAN card there may be one or more SEGM and FLDK cards. For each SEGM card there must be one and only one FLDK card.

] denotes optional statement or parameter

ThE! following are the generalized rules for the DBD generation job step:

A - Number of OMAN cards determines whether the data base is composed of a single or multiple data set groups. One OMAN card per data set group.

is:

B - ACCESS - (INDX) - Hierarchical indexed sequential organization (SEQ) - Hierarchical sequential organization

C - Only one PRINT NOGEN card. - eliminates object listing from DBD generation

One DBD card One DBDGEN card One FINISH card One END card

D - if INDX - only DD1. DLIOF. omit DD2=

if SEQ - both DD1, DD2. omit DLIOF=

E - follow the rules in the paragraph titled "DBD Control Card .Requirements"

An example of a hierarchical description of control cards 3. 4, and 5

1-DMAN (DATA SET GROUP 1) 2-SEGM (ROOT SEGMENT)

3-FLDK 3-FLD 3-FLD 2-SEGM (LEVEL 2)

3-FLDK 3-FLD 2- SEGM (LEVEL 2)

3-FLDK

1-DMAN (DATA SET GROUP 2) 2-SEGM (LEVEL 2)

3-FLDK 3-FLD

2-SEGM (LEVEL 2 or 3)

The job step itself consists of eight types of Data Language/I control cards arranged in a specific order. Each control card is described individually in detail in the following section.

DBD CONTROL CARD REQUIREMENTS

The description of the data base is presented to Data Language/Ion eight types of control cards.

108

1. Each control card must be identified by a name, called a

"card-type code". which comprises three to six characters:

PRINT. DBD, DMAN, SEGM, FLD, DBDGEN, FINISH, or END.

/

(

)

I

/

2. In the generalized example shown in the following descriptions of the control cards, these conventions apply:

a. Words written in all capital letters must appear exactly as written.

b. Words written in lowercase letters are to be replaced by a user-specified value.

c. The control cards are free form but must begin after column 1.

d. The symbols [ 1, { }, and , . . . are used as an aid in

defining the instructions. THESE SYMBOLS ARE NOT CODED; they act only to indicate how an instruction may be written.

[ 1 indicates optional operands. The operand enclosed in the brackets (for example, [VL]) may be coded or not,

depending on whether the associated option is desired.

If more than one item is enclosed in

brackets (for example, [REREAD1), one or more may LEAVE

J

be coded.

{ } indicates that a choice must be made. One of the operands from the vertt"Cal stack within braces

(for example,

1

input ) must be coded" depending on output

which of the associatea services is desired.

e. All DBDGEN control card parameters except for the print card are keyword parameters and therefore may appear in any sequence on the associated control card.

, •••• indicates that more than one set of operands may be designated in the same instruction.

PRINT Control Card

r---,

I I I I

I I

[PRINT

I

NOGEN]

I

I

L _________________________________________________________

I I

J

I

The PRINT NOGEN card is an Operating System/360 macro generator control card used to eliminate a printout of the object listing

resulting from a DBD generation. With the PRINT card present, a source statement summary is provided for each DBD defined.

DBD Control Card

This must be the first Data Language/I control card in the job step after the PRINT NOGEN. This card names the data base to be described and provides Data Language/I with preliminary information concerning its organization. There can be only one DBD control card in the control card deck. The parameters must be contained on one card.

r---,

1 1 1 I

.1 lOBO I NAME=naIlle. I

I 1 1 I

I 1 I

I SAM

I

I I I

ACCESS= INOX

I

I 1 I

SAM

I

I 1 1

SEQ

I

1 1 1 I

L _____________________________ ~ ___________________________ J

where:

DBD=

identifies this control card as the DBD control card. This is the card-type code.

NAME=name

ACCESS=

is the name of the OBO for the data base being described.

This name may be from one to eight alphameric characters, must be left-justified, and must not have trailing blanks since i t is not the last parameter. Normally, this name would be the same as that specified in the OD1 parameter of the OMAN control card, although this is not required.

specifies the Data Language/I access method to be used in conjunction with this set and must be one of the following values:

ISAM or' INDX -- Hierarchical indexed sequential organization SAM or SEQ -- Hierarchical sequential organization

DMAN Control Card

A DMAN control card must immediately follow the DBO,card. Each OMAN control card describes one data set group that is to be set up by Data Language/I as part of the data base being described. There are one primary data set group and zero to eight dependent data set groups in a single data base for the hierarchical indexed sequential organization.

There is only one data set group for a hierarchical sequential data base.

since the DMAN card parameters may appear on more than one card;, provision has been made to accommodate the overflow of parameters to more cards. When this occurs:

110

1.. Enter a nonblank character in Column 72 of each continued card~

2. A particular parameter or operand may not span two cards. If there is not space for the entire parameter on the current card, place the whole parameter on the next card. When continuation cards are required, a comma must follow each parameter except the last on the last continuation card.

3. continue statement in Column 16 of next card.

4. The continued condition may occur in OMAN, SEGM, and FLO cards.

/

(

\.

(

J

)

/

)

The number and arrangement of DMAN control cards allowed in a job step are greatly dependent upon the data base organization specified.

For instance, for a SINGLE DATA SET GROUP - DATA BASE, only one DMAN control card and its associated overflow cards (if any) are allowed; for a MULTIPLE DATA SET GROUP - DATA BASE, up to ten OMAN cards are

allowable. For hierarchical sequential data bases, only one DMAN card is allowed. The format of theDMAN control card where the DBD card has ACCESS=INDX or ISAM is:

r---,

I I I I

I I

DMAN

I

DD1=name,

I

I I I I

I I I

[DLIOF=name,J

I

I I I I

I I I

DEV1=device

I

I

L _________________________________________________________

I I

J

I

The format of the OMAN control card where the DBD card has ACCESS=SEQ or SAM is:

r---~---,

I I I I

I I

DMAN

I

DD1=name,

I

I I I I

I I I

DEV1=device

I

I I I I

I I I [,

DD2=nameJ

I

I I I I

I I I I

I

L _________________________________________________________ J

I I I

where:

DMAN

identifies this Data Language/I control card as a DMAN control card. (See the setup examples at the end of this section.) DD1=name

is a one- to eight-character alphameric name that is the ddname of the DD card for an ISAM data set, or an input data set under SEQ organization. This parameter must be specified regardless of the data base organization.

DEV1=device

designates the physical storage device type on which the prime area for this data set is to be stored. A list of the possible

p~ysical devices follows:

Device Name DRUM

DISK FILE DISK PACK DISK FACILITY DATA CELL TAPE

DEVI=

(only when DBD ACCESS=SEQ) (The underlined value may be used for DEV1=.)

DLIOF=name

a one- to eight-character alphameric name that is the ddname of the DO card. I t is required only if INDX was specified in the DBD card ACCESS parameter. This8-character name becomes the ddname on the OD card for the OSAM data set. Omit this parameter if the OBD card ACCESS parameter equals SEQ or SAM.

DD2=name

a one- to eight-character alphameric name that is the ddname of the 00 card for the output data set under SEQ. This parameter must be omitted if the DBO card ACCESS card equals INOX or ISAM.

The D02 parameter should be specified only if the data base organization is hierarchical sequential.

The following table summarizes the parameters required on the OMAN control card for each of the Data Language/I access methods.

Access Method Parameters Required SEQ or SAM 001, DEV1, D02 INDX or ISAM 001, DEV1, DLIOF

SEGM Control Card

At least one SEGM control card must immediately follow a DMAN set.

The SEGM control card defines a segment to be contained in the data set group defined by a preceding OMAN control card. There may be a maximum of 255 segments defined. SEGM control cards must be entered in

hierarchical order. The segments are physically stored in the data base record in the same order in which these cards are entered.

Provision has been made to accommodate the overflow of parameters on a SEGM control card to more cards. When this occurs, follow the rules stated above for overflow on the DMAN card.

The format of the SEGM control card is:

r---,

, " I

, I

SEGM , NAME=name,

I

, 1 I I

, I I

PARENT=parent,

I

I I I I

, I I

BYTES=bytes,

I

, I ' I

, 1

'FREQ=frequency

I

1 I I I

l _________________________________________________________ J

where:

SEGM

is the card-type code which identifies this as the SEGM control card.

NAME=name

112

is a one- to eight-character alphameric name of the segment.

within one DBD, duplicate segment names are not allowed .•

(

)

)

PARENT=parent

a one- to eight-character alphameric name of the parent segment

Dans le document Information Management System/360 for the (Page 117-123)