CleS/VS Data Ease Design 179

A dependent segment relies on some higher level segment for its full meaning or identification. Since the number of account name segments may vary from one savings account to the next, logical data base records will vary in length according to the number of segments occurring in the hierarchy of the data structure.

The root segment in Figure 5-33 ccntains the specific account details for account number 61321. There are multiple account name segments for perscns using this account: John Smith and Mary Smith.

Also, for this account, there are t~o withdrawal and three deposit segments,. The data base has four segment types, and this particular data baSE record consists of eight segments because of the multiple occurrences of the account name, deposit, and withdrawal segments.

The sf~gments immediately above and below a given segment are called the "parent" and "child" ^seqment~ respectively. In Figure 5-33, the account detail segment fer account 61321 is a parent of the two name

segments~ Each account name segment is a child of the account detail segment. The deposit and ~ithdrawal segments sutordinate to the account name segments are their children. All occurrences of a particular

segment type dependent on a particular parent segment are called "twin"

segments.. The account name segments fer John smith and Mary Smith are twins of each other.

Refer to the ~1§!§~~jERli~ti~~ ~~§ign Qyi~§ for the relevant DL/I product for further discussion of logical structures.

DATA BASE ACCESS CALLS

A com loon symbelic program linkage and data base description allow batch ana online applicaticn programs to request DL/I to:

• Betrieve a unique segment (GET UNIQUE)

• Retrieve the next sequential segment (GET NEXT)

• Beplace the contents of an existing segment (REPLACE)

• Delete the data in an Existing segment (DELETE)

• Insert a new segment (INSERT)

Additional data tase access calls are pro~ided to enable all

dependent segments based on a particular parent segment to be retrieved seguentially. The retrieval access calls may also specify that a record being retrieved is to be held, because it will suhseguently be updated, replaced, or deleted.

Application pregrams written in American National Standard (ANS) COBOL, PI,II, and Assembler Language utilize the CALL statement facility in these languages te perform the input/output functions listed above.

The external data base descriptions (DEDs) and program specification block (PSB) descrihe the ~hysical data organization and logical data structure of the data base to DL/I. Because of this ap~roach to data referencE:, input/output cFerations and associated system control blocks are not compiled into the apFlication ^~rogram. This avoids program dependence upon currently availatle access methods and physical storage

organizati~ns. other apFlication data can be added to this data base without necessitating changes to application programs that use the data.

180 CleS/VS System/Application Design Guide

DATA BASE ORGANIZATION AND ACCESS ^~E~HODS

DL/I supports two basic physical storage organizations as discussed briefly above. 7he first crganizaticn, Hierarchical Sequential,

provides the base for both tbe Hierarchical Sequential Access Method (HSAM) and the Hierarchical Inde~ed Sequential Access Method (HISAM).

The second organization, Hierarchical Direct, prcvides the base for two more accessing techniques, the Hierarchical Direct Access Method

(HDAM) and the Hierarchical Indexed Direct Access ~ethod (HIDA~). HDAM uses an addressing algorithm for direct access ^sup~ort of the

hierarchical direct organization. Standard addressing algorithms are provided by DL/I, or may be supplied by the user installation for each HDAM data base. HIDAM is an indexed access suppcrt of this hierarchical direct organization.

~ach DL/I access method and data tase organization will now be briefly introduced. Refer tc the ~~§!~L!RR1~~!lsD ~~§ign ~ide for the relevant DL/I product for a aore detailed description of each data base access method.

The primary differences between hierarchical direct and hierarchical sequential organizations are the manner in which segments are related, and the techniques of data storage and access. Segments in the

hierarchical sequential organization that represent one data base record (that is, a physical hierarchical tree structure) are related by

physical adjacency. This requires that segments which represent one data base record be contained in a variable number of segment blocks unique to that data base record.

HSAM is used for sequential storage and access on tape or direct access storage. The DOS/VS and CS/VS sequential access methods (SAM and ESAM respectively) provide the data management services for HSAM.

Physical blocks (a variable numter) required to contain a particular data base record are accessed by physical adjacency (H5AM).

HISAM is used for indexed sequential access to the hierarchical sequential organization. data base record may be directly accessed through an index. Segments within a data base record are related by physical adjacency. All physical blocks used to store the segments of a single data base are related by direct address pointers. The virtual storage access method (VSAM) provides data management services for DL/I ENTRY, DL/I DOS/VS, and IMS/VS DI/I. IM5/VS can optionally use BISAM and a EDAM-like access method called OSAM for data management services.

(However, DL/I facilities such as variable-length segments, or secondary indexing (see later in this chapter) are only available to data bases which utilize VSAM.) Generally, a HISAM data base is comFrised of one VSAM key-sequenced data set and cne entry-sequenced data set.

Note: DI/I ENTRY only uses one VSAM key-sequenced data set to support a HISAM data base.

Chapter 5. CICS/VS Data Base Design 181

segments in the hierarchical direct organization that represent one data baSE record (that is, a physical hierarchical tree structure) are stored in one or more physical blocks. However, all segments in that data baSE record, rather than the physical blocks containing the data base record, are related by direct addresses. Each segment in a data base record refers to segments of the same type, as well as to adjacent segment types, through direct addressing. Physical blocks that contain segments of the data base record are not related by direct addressing.

In the hierarchical direct organization, the sFace requirement for each segment is increased frc. that required in the hierarchical

sequenticll organization. This sFace is required to accommodate direct addresses. However, the following advantages are gained:

• More rapid direct access to segments within a data base record.

• The ability to share sFace in a direct access storage block across multiple data base reccrds. One physical blcck may contain segments from different data tase reccrds. This may result in a considerable saving of data base stcrage space.

• The ability to reuse sFace occupied by deleted segments through the laintenance of free sFace addresses.

!Ul!!1 !1§£Q~gl~~.!!.2!

HDAM is used for direct algorithmic randomized access to records in the hierarchical direct organization. Direct access is available to each data base record. VSAM Frovides the data management services for HDAM. OSAM provides optional data management services for IMS/VS DL/I, but (as discussed previcusly for HIS AM) facilities such as

variable-length segments or secondary indexing cannot be utilized with OSAM. 01/1 ENTRY does not support HCAM.

!!!12!~ Re.£_Q~g IQ~u!

HIDAM is used for indexed access to the hierarchical direct

organization. Indexed access is available to each data base record.

VSAM provides the data managellent services for HIDAM for Dt/I DOS/VS and IMS/VS DL/I. BISAM and eSAM Frovide optional data management serv ices in HIDAM for IMS/VS DL/I. (See reference to EISAM and OSAM limi tations above for HISAM and BDAM.) DL/I EN'IEY does not support HIDAM.

Refer -to the ~~§!nLJ~.Eli.£JU.Qll 12!§isul §.g!g§ for the aFpropriate DL/I product for further infcrllaticn c~ncerning data base organization and access methods.

lOGICAL STRUCTURE tESIGN

The preceding discussion has estatlished the concept and organization of DL/I data bases. As discussed previously, the smallest data element which can be accessed by an application Frogram is a segment. The design of segments is a key factcr in the design of DL/I data bases.

Following this segment design, the design of logical data base structures should be considered.

182 CICS/VS System/Application Design Guide

Logical structure design depends upon the application. However, some of the factcrs which shculd be considered in the design of logical structures are:

• The utilization of deFendent segments

A program may wish tc access the information in the root segment of a data base record. In the savings account example in Figure 5-33, the account details will be contained in the root segment.

Follcwing the accessing of this root segment, the application requirements may dictate that segments dependent on this root must te accessed. In the savings account example in Figure 5-33, the account name segments, then the deposit segments and the withdrawal segments may be accessed either individually or in their order of occurrence.

• The sensitivity of programs to segments

An account inquiry pregram, fer example, may wish to access only the account detail (root segment) and the acceunt name segments.

In this case, the program would te defined as teing sensitive only to these segments.

Similarly, an account process1ng program may need to access only the account detail (roet segment) and the depesit and withdrawal segments, withcut reguiring reference to the account name segments.

This enables deposit and withdrawal transactions to be retrieved, updated to reflect possitle correction, cr added as new deFosit or withdrawal transactions are received against an account. In this case, the account processing program would be defined as being sensitive only te the account detail root segment, and the

withdrawal and deposit segments, but not sensitive to the account name segment.

• Application factors

In a savings account example, once an account is opened, information such as the name segment may not be changed or added to

significantly. In fact, if there is only one name for each account, it may be logical to Flace the name within the root segment itself.

However, because there may be more than cne ~ame associated with an account, the Fossible multi FIe cccurrence of names may dictate that these be separate segments which are deFendent upon the account detail root segment and furtheI describe that account. The deposit and withdrawal segments reflect activity of transactions against the account. Because there may be multiFle deposit and withdrawal transactions, it is logical to make them separate segments which are also dependent (legical children) upon the account detail root segment.

Similarly, in an insurance pelicy information system, a policy data tase may contain policy details in the root segment, policy

beneficiaries in name segments dependent upon the root segment, and Folicy claims and renewals transactions dependent upon the name segments (see Figure 11-19).

In a manufacturing werk crder system, the manufacturing werk order data base may contain all of the manufacturing work erder

information in a root segment, with multiple status information recorded at different stages of manufacture in status segments dependent upon the root segment (see Figure 11-5).

Chapter 5. CICS/VS Data Ease nesigD 183

In a medical patient information system, the patient's na.e, birth

date~ and ctber details vould be contained in the root segment, with his address in seFarate address line seg_ents dEpendent upon the root seg.ent. De~endent upon these address segments would then be visit segments, diagnosis segaents, and treatment segments of which tbere way be aultiFle cccurrences for a patient (see Figure 11-23) •

~§gg§~! E~!§~~~~s ~§§igD 1!£12~!

In a Folice inforaaticn s}stea, the logi~al structure aay te designed for a criminal data base by placing the personal characteristics of the criminal in a root seg.ent tcgether with his true na.e. This is illustrated in Figure 5-34 for reference during the discussion in the follcwing paragraphs.

Alias names may be dependent segments of the root segment. The particular mode of operaticn for various criaes lay be each stored in a separate 1!.2g'y§ 2RillDgi seg_ent. ~hese G~ll§ .9~!Ey,gi segments lIay be dependent upon the alias segments (see (A) in Figure 5-34), but more logically are furtber descriFticns of the cri.inal who is descrited by the root segment. Thus, tbe alias segments and ~dus 2~iI!Dg! segments are regarded as twins if both are children of the root segment (see

(B) in Figure 5-34).

Following the J!~JL§ .2.E!.!!!S! segments may be various convictions recorded against this cri.inal (e). Bach conviction is contained within a conviction segment, and typically idEntifies the crime to which the conviction is related, the particular punishment carried out, and the extent to which that punisbment has teen carried out. Alternatively, the conviction seg.ents aa} te children of the root segment and twins of the .I~.g'y§ 2R!I!Dgi and alias segments (see (D) in Figure 5-34).

The decision whether tc define the logical structure in such a manner that these dependent segaents are twins, or children, depends upon the information which will be availatle for subsequent accessing of this data baSE record. Tc access a child segment efficiently requires identification of the parent.

184 CICS/VS Syste./ApFlication Design Guide

Personal convicticns were children cf JRgJ§ 2R~IAn~i (E), to. retrieve information relating to particular convictions for a cri.inal would require

knowledge possibly of his true naDe, his alias name, and various aggg§

~R~ • .iD.9i ^(see (E) 'in figure 5-34). Bowever, in this aFplica tion, that idEntification aay not be availatle to access information relating to convictions. In this case, it wculd bEtter to define convictions as

additional DL/I features, such as logical relationships, or secondary indexing, which are descrited below.

Alternatively, instead cf using sEcondary indexing, a separate data base may be organized based cn alias names, which Frovides a

cross-reference to the original criminal names, and another data base lIay be organized based u~cn !2GY§ 2R~I!ngi which again identifies the Chapter 5. CIeS/1S Data Base Design 185

criminal's true name. Thus, by accessing the separate data bases first, the criminal may be identifiEd and then further information related to that criminal may be ottained frcm the criminal data base.

Obviously, the factors which may te considered in the design of logical structurES are cften very de~endent upon application. Refer to the ~l~§!!:!!!!L.lJ2.Eli5:gti~1! ~§ign 2.Yi,g§ for the relevant DL/I product for further discussion af logical structure design.

UPDA!ES, ADDITIOtiS, AND tEIEilONS

In order to update (REFtACE) segments in DL/I data bases, it is necessary to indicate when the original record is retrieved that there is a possibility that the record aay bE updated. ihis is indicated by placing a "hold" cn that segDent with a GET call, such as GET HOLD UNIQUE, GET HOLD NEXT, or GET HOLD NEXT WITHIN PAR~NT. The segment presented on a GET HOLD call is then updated by the application program and written back with a EEFLACE call. Alternatively, if the segment is not tc be updated, this is indicated by the next GET call, without an intervening REPLACE or DELETE. In effect, the HOLD used with the GET call implies that "exclusive centrol" is to te placed on that segment to prevent the same segment from being concurrently updated by another task. Only when the REPlACE or DELETE call (or the next GET) is issued is the exclusive control released.

When DL/l DOS/VS or I!S/VS DL/I is used with CICS/VS, concurrent updating "ill be prevented at the segment-type level with the

scheduling-by-intent feature. The DL/I task will not be scheduled if it has conflicting intent with another active DL/I task on the same segment type. This may have performance implications, depending upon the frequency cf reference tc the saDe segment type by concurrently executing tasks. However, it provides the ability to back out ^p~ograms independently in the event of an unccntrolled shutdown. VANDL-1 and DL/I ENTEI, used with CICS/DCS/VS, does not perfcra checks at scheduling time and does not previde specific backout support following an

unccntrolled shutdown.

To illustrate the significance of segment intent scheduling on data base design and performance using ut/I DOS/VS or 18S/VS Dt/I, consider the follewing order entry and inventory control application in the distribution industry.

Each store carries its cwn inventory and enters orders from a terminal located in the stcre. These orders update the inventory maintained in a central data base for all stores. If the inventory data base is designed with oLly cne segment type for inventory details across all stores, only one task (that is, store transaction) would be scheduled to update that segment type at a time. This may have

significant performance implications if several stores were concurrently entering orders, and may result in single thread access to the data base.

However, as each store carries its own inventory, a separate

inventory details segment type may bE defined for each store (subject to the maximum of 255 differEnt segment types, imposed by DL/I). In this way, each store transaction would bE scheduled on its own inventory details segment type, with nc conflict with other stores inventory

segment types. This will permit multithread access to each stores inventory details, with conseguent iuprovement in performance without any loss in data integrity. However, it will be dcne at the expense of additional HDA! data base pointers, control block storage, and application program logic.

186 CICS/VS System/Application Design Guide