IMS and OSAM datasets



IBM's hierarchical database management system with a Database Manager (IMS DB) and a Transaction Manager(IMS DC)

IMS and OSAM datasets

Postby Don Scott » Wed Aug 26, 2009 3:32 am

Hello, all!

I have been involved with IMS DB/DC since V1.3, mostly as a DBA, and for the first time ever, I am working in a DBCTL shop. (For the tyros, that’s IMS/DB with CICS as the transaction manager.) All DBs use VSAM as their access method, and none are registered to DBRC. I have one (HIDAM,VSAM) DB that is rapidly approaching the 4 Gb VSAM addressability limit.

I wish to convert this DB to use OSAM, which will give me an 8 Gb limit. I know how to set up the reorg to do this, but my problem is this: Since 1982, the entire backup/restore approach here has consisted of stopping all transactions that access a DB, then copying or archiving the underlying VSAM datasets (currently using CA-BrightStor/CA-Disk (DMS). They restore using the same product and procedure. Operations and the application folk are incredibly nervous about any changes to ‘the way we’ve always done it’. I know I should alter the process and introduce these folks to ‘real IMS’ and ImageCopy/Recovery, not to mention DBRC and the rest…. However, I have seen MVS Fast Dump Restore used for IMS DB recovery, but only on a pack by pack basis, restoring the whole data center for a DR test. For my particular situation, does anyone know if I could use DMS to archive the OSAM datasets underlying the DB?

Thanks and best regards.
Don Scott
 
Posts: 1
Joined: Wed Aug 26, 2009 3:15 am
Has thanked: 0 time
Been thanked: 0 time

Re: IMS and OSAM datasets

Postby dick scherrer » Wed Aug 26, 2009 6:34 am

Hello Don and welcome to the forum,

Please check your PM inbox,

d
User avatar
dick scherrer
Global moderator
 
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: IMS and OSAM datasets

Postby melina386 » Tue Dec 15, 2009 2:08 am

Observe the following restrictions when you preallocate with any of the accepted methods:

* DCB parameters should not be specified.
* Secondary allocation must be specified for all volumes if the data set will be extended beyond the primary allocation.
* Secondary allocation must be specified for all volumes in order to write to volumes pre-allocated but not written to by initial load or reload processing.
* Secondary allocation is not allowed for queue data sets because queue data sets are not extended beyond their initial or pre-allocated space quantity. However, queue data sets can have multivolume allocation.
* The secondary allocation size defined on the first volume will be used for all secondary allocations on all volumes regardless of the secondary allocation size specified on the other volumes. All volumes should be defined with the same secondary allocation size to avoid confusion.
* If the OSAM data set will be cataloged, use IEHPROGM or Access Method Services to ensure that all volumes are included in the catalog entry.
Data Entry India
melina386
 
Posts: 1
Joined: Tue Dec 15, 2009 2:04 am
Has thanked: 0 time
Been thanked: 0 time


Return to IMS DB/DC

 


  • Related topics
    Replies
    Views
    Last post