Operating System Access Methods


IMS uses two operating system access methods to physically store the data on disk storage and move the data between the disk storage and the buffers in the IMS address space:

  • Virtual Storage Access Method (VSAM): IMS uses two of the available VSAM access methods:

    - Key-sequenced data sets (KSDSs) are used for index and HISAM databases.

    - Entry-sequenced data sets (ESDSs) are used for the primary data sets for HDAM, HIDAM, PHDAM, and PHIDAM databases.

    The data sets are defined using the VSAM Access Method Services (AMS) utility program.

  • Overflow Sequential Access Method (OSAM): The OSAM access method is unique to IMS, is delivered as part of the IMS product, and consists of a series of channel programs that IMS executes to use the standard operating system channel I/O interface. The OSAM data sets are defined using JCL statements. To the operating system, an OSAM data set is described as a physical sequential data set (DSORG=PS).

For more information about these operating system access methods, see "VSAM Versus OSAM for Data Set Groups" on page 111.

The VSAM and OSAM access methods define two types of data sets:

  • Indexed sequential data sets: Defined and accessed as VSAM KSDSs, are used to implement primary and secondary index databases. The index databases are processed using the standard record level instructions of VSAM. A catalog listing (VSAM LISTCAT) shows all current details of the files. VSAM KSDSs are susceptible to the normal performance degradation from CI or CA splits caused by insert and delete activity. VSAM KSDSs can, if necessary, be processed using AMS utilities such as REPRO.

  • Sequential data sets: Defined and accessed either as VSAM ESDSs or using OSAM. While these data sets appear as sequential data sets to the operating system, IMS accesses them randomly, therefore the data sets do not contain records. IMS always processes them at the CI (VSAM) or block (OSAM) level. The internal structure within each CI or block is arranged as described in "IMS Hierarchical Access Methods" on page 87. Interpreting catalog listings of these files as if they were sequential files can, therefore, be misleading.

In addition to using VSAM or OSAM, most IMS data sets can be managed by Data Facility Storage Management Subsystem (DFSMS). The exception is the data sets that IMS uses for logging. For more information, see "IMS Log Data Sets and Data Facility Storage Management Subsystem (DFSMS)" on page 373.

Data Set Groups

While most physical databases are implemented over a single VSAM ESDS or OSAM data set, IMS allows you to create data set groups to spread an HDAM or HIDAM physical database over up to nine additional data sets.

One of the restrictions associated with data share groups is that the first (primary) data set group that is defined must contain the root segments, and can optionally contain any dependent segment type. The other (or secondary) data set groups can each contain any dependent (non-root) segment type. However, each dependent segment type can be defined in only one data set group. These restrictions, aside from performance implications, are transparent to applications. If the database must be reorganized, then all data sets that make up the physical database must be reorganized at the same time.

You might want to use secondary data set groups for the following reasons:

  • To separate little used segments from the main data set and leave more space for frequently used segments. Doing so increases the chance that all regularly accessed segments are in the same block with the root segment, thus enhancing performance. For example, you might have a segment type that has a new occurrence inserted each month, say month-end audit totals. The audit total segment is only rarely accessed after insertion. Placing this segment type in a secondary data set group, while imposing an overhead on the program that inserts it, might improve the performance of all other programs because doing so increases the chance that the segments they access are in the same block as the root segment, and more database records can be packed into one CI or block.

  • A database with one very large segment type and a number of other small segment types can result in unusable space because IMS space management regards only a CI or block within a data set as having free space if the CI or block can accommodate the largest segment type stored in that data set. If you put this large segment type in a secondary data set group, the other data set groups are regarded as full only if they cannot contain the second largest segment type.

  • Because you can specify different free space parameters on the different data set groups, you can place nonvolatile segment types in a data set group with little free space, to increase packing in a CI or block, and consequently increase the chances of having several segments that a program is retrieving located in the same block. Volatile segment types (that is, segments with frequent insert or delete operations) could be placed in a data set group with a large free space specification, which allows segments to be inserted near related segments.

  • For very large databases, you might be approaching the structural limit of the data set access method (4 GB of data for VSAM and 8 GB for OSAM). If you have one or two segment types that occur very frequently, each of these segment types could be placedin one or more secondary data set groups to provide more space. In this case, OSAM, DEDBs, or HALDBs might work well because the database can be spread over many more data sets.

When you perform space calculations, be aware that, in addition to the overhead for IMS control information (pointers, for example), VSAM data sets also contain a suffix area at the end of the CI that contains VSAM control information. This makes the space available in the CI for IMS data slightly less than the VSAM CI size.

VSAM Versus OSAM for Data Set Groups

The choice between OSAM and VSAM ESDSs for the primary database data sets depends, to some extent, on whether your site already uses VSAM and whether you need to make use of the additional features of OSAM. The choice between VSAM ESDSs and OSAM is not final because you can change a database from one access method to the other by unloading the database, changing and regenerating the DBD, then reloading the database.

Because the OSAM access method is specific to IMS, it is optimized for use by IMS. The reasons you might want to use OSAM include:

  • The availability of sequential buffering (SB). With sequential buffering, IMS detects when an application is physically processing data sequentially or consecutively and fetches in advance any blocks it expects the application to request from DASD, so that the blocks are already in the buffers in the IMS address space when the application requests segments in the blocks. Sequential buffering is manually activated for specific IMS databases and programs and can appreciably increase performance for applications that physically process databases sequentially or consecutively. Sequential buffering is similar to the sequential prefetch that is available with some DASD controllers, but has the advantage that the data is fetched into the address space buffer in main memory rather than the DASD controller cache at the other end of the channel.

  • The structural limit on the amount of data that IMS can store in a VSAM ESDS is 4 GB of data. OSAM can process a data set up to 8 GB in size.

  • Overall, OSAM is regarded as more efficient than VSAM ESDSs because OSAM has a shorter instruction path.

Related Reading: For details about sequential buffering, see the chapter "Designing Full-Function Databases" in IMS Version 9: Administration Guide: Database Manager.



Introduction to IMS. Your Complete Guide to IBM's Information Management System
An Introduction to IMS: Your Complete Guide to IBMs Information Management System
ISBN: 0131856715
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net