osam – the healthy alternative to vsam - ims ug october 2012 san ramon

IBM Software Group | IMS Information Management Software

San Ramon User’s Group - Oct. 18 © Copyright IBM Corporation 2012 San Ramon User's Group - October 18

© Copyright IBM Corporation 2012

IBM Software Group IMS Information Management Software

OSAM – “The Healthy

Alternative to VSAM”

Charles Jones

IMS Database Support

Silicon Valley Laboratory [email protected]

October 18, 2012


San Ramon User’s Group - Oct. 18 © Copyright IBM Corporation 2012

Topics Covered

Operating System Access Methods

Origins of OSAM

Sequential Buffering

OSAM Caching in CF (Coupling Facility)

OSAM and HALDB

VSAM to OSAM Conversion Considerations



Operating System Access Methods

Virtual Storage Access Method (VSAM)

IBM uses two available VSAM access methods:

1) Key-Sequenced Data Sets (KSDS) are used for index and HISAM databases

2) Entry-Sequenced Data Sets (ESDS) are used for the primary data sets for

HDAM, HIDAM, PHDAM, and PHIDAM databases.

VSAM data sets are defined using the VSAM Access Method Services (AMS)

Utility program.

Overflow Sequential Access method (OSAM)

OSAM is unique to IMS, is delivered as part of the IMS product, and consists

of a series of channel programs that IMS executes to perform I/O.

OSAM data sets are defined using JCL statements.



VSAM Versus OSAM for Data Set Groups

The choice between OSAM and VSAM ESDS for the primary database

data sets depends on:

- whether your site already uses VSAM

- whether you need to use the features of OSAM

The reasons you might want to use OSAM include:

- The availability of Sequential Buffering

- The structural limit on the amount of data that IMS can store in a

VSAM ESDS (4 GB) versus OSAM (8 GB)

- OSAM reduced CPU cost (shorter instruction path)

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.



Implementing OSAM CF Caching

You can implement OSAM caching by means of the CO (Cache Option)

parameter in IOBF control statement on DFSVSMxx of IMS.PROCLIB.

Different caching options may be defined for each OSAM subpool.

Omitted - No data caching. Caching is not active for the subpool.

N - No data caching. Caching is not active for the subpool.

A - Cache all data. Write all data read from DASD and all changed

data to the CF.

C - Cache only changed data. Write all changed data written to

DASD to the CF.

If you specify any value other than A, C, or N, no data caching for the

subpool occurs. The default is N.





OSAM and HALDB

A Dynamic Duo



HALDB (High Availability Large Database)

High Availability Database

Partition independence

• Allocation, authorization, reorganization, recovery by partition

Self healing pointers

Reorganization of partition does not require changes to secondary indexes or logically related databases

Large Database

Databases are partitioned

• Up to 1001 partitions per database

• Partitions have up to 10 data set groups



HALDB Highlights

OSAM and VSAM (ESDS and KSDS) supported

Partition selection is done by key range or user exit

Logical relationships and secondary indexes supported

Secondary indexes may be partitioned

DBRC is required

Databases must be registered

Dynamic allocation uses DBRC information

DFSMDA is not used



HALDB Database Data Sets

Each HALDB database has up to 1001 partitions

PHIDAM has index, ILDS, up to 10 data set groups per partition

3 to 12 data sets per partition

3 to 12,012 data sets per database

PHDAM has ILDS and up to 10 data set groups per partition

2 to 11 data sets per partition

2 to 11,011 data sets per database

PSINDEX has no ILDS or data set groups

1 data set per partition

1 to 1001 data sets per secondary index



HALDB Overview

Database candidates for HALDB

Very large databases

Approaching 4GB limitation

Theoretical limit is now over 40 terabytes per database

Medium and large databases

Parallel processing to meet time deadlines

Less frequent reorganizations due to more free space

Any database

More frequent reorganizations

Making only parts of the data unavailable for database maintenance





VSAM to OSAM

Conversion Considerations




Planning:

1. Buffer sizes – you are not limited to multiples of 4k.

2. Pool definitions within the IMS control regions

3. Sequential buffering for BMPs




Conversion: 1. IC the whole DB or HALDB

2. Backup ACBLIB, DBDLIB, PSBLIB

3. Run a GENJCL.RECOV for the HALDB with the JCLOUT DD pointing to a PDS to hold this JCL until needed (optional)

4. Export the HALDB definitions using the PDU (optional but recommended)

a. This is for fall back so you can use the ICs if required

5. Unload database

a. HALDB

i. All partitions but can be concurrent unloads with one or more partitions per unload

b. FF

i. Single step unload




Conversion (cont.): 6. Change the DBD and run a DBDGEN

7. Change partition information in the RECON

a. CHANGE.PART …….DISABLE the current partitions i. You can use a DBRC GENJCL.USER command to accomplish this

b. INIT.PART new partitions with the IMS DD using the update DBDLIB which is now OSAM

c. If you ensure that the key ranges will not be altered during this process, you can delete the MASTER DB RECON record and INIT.DB and INIT.PART using the previous partition names.

i. This will allow you to continue to use the same data set names

ii. If the key ranges are not the same you run the risk of corrupting the ILKs and thus the self healing pointers would be broken




Conversion (cont.): 8. Create data sets definitions

a. You can use a DBRC GENJCL.USER command to create the DEFINE

CLUSTER/NON VSAM data set definitions for every partition in the

HALDB

9. Reload the database

a. If you need to, run DFSUPNT0 to INIT the partitions

b. Run the reload with the same concurrency used to unload them

10. Run ACBGEN

a. BUILD DBD=masterdb must be used

11. IC the whole HALDB

12. Remove old partitions

a. If you used the DISABLE function, now you can DELETE.PART those

old partitions




System changes: 1. Modify buffer pools

a. Modify DFSVSAMP member for all utilities/ DLI jobs

b. Modify PROCLIB DFSVSMxx to allocate OSAM buffers

c. Create subpools where required

2. Modify PSBs for sequential buffering

a. Add SB=COND to PROCOPT where required

3. Modify CF Structures

a. Create OSAM CF Structures

b. Modify DFSVAMP member to name CF Structures

i. CFNAMES,CFIRLM=DPRALOCK,CFVSAM=DPRAVSAM,

CFOSAM=DPRAOSAM



Example of Allocating an OSAM Data Set

//OSAMALLO JOB A,OSAMEXAMPLE

//S1 EXEC PGM=IEFBR14

//SYSPRINT DD SYSOUT=A

//EXTENT1 DD VOL=SER=AAAAAA,SPACE=(CYL,(20,5)),UNIT=3390,

// DSN=OSAM.SPACE,DISP=(,KEEP)

//S2 EXEC PGM=IEFBR14


//EXTENT2 DD VOL=SER=BBBBBB,SPACE=(CYL,(30,5)),UNIT=3390,


.

.

.

//LAST EXEC PGM=IEFBR14


//EXTENTL DD VOL=SER=LLLLLL,SPACE=(CYL,(30,5)),UNIT=3390,





OSAM – “The Healthy

Alternative to VSAM” (720) 396-8545

[email protected]

October 18, 2012

Sources

Redbooks: IMS Version 7 Performance Monitoring and Tuning Update – SG24-6404-00

The Complete IMS HALDB Guide All You Need to Know to Manage HALDBs - SG24-6945-00

“OSAM – the Healthy Alternative to VSAM” – Alan Cooper, Manchester, UK

“VSAM to OSAM Conversion considerations” – Rick Long

osam – the healthy alternative to vsam - ims ug october 2012 san ramon

Technology

data caching

dfsvsmxx of ims

ims product

osam data sets

vsam data sets

changed data

osam subpool

gb osam