IDMS

We have a big database with the page range almost exhausted. I have been dealing with this problem since I expect it will be happen some day. The CA option is doing segmentation with page group but a lot of changes in programming will be required. In the past I ask to CA to create an option to define areas or something like db2 partitioned table spaces to solve this problem, but CA said it wasn't in the path of improvements.  Now there is still not an easy solution, I was thinking in doing something like database procedures or something like that, trying to not to requires a lot of changes in programming. Anybody in the group have  dealing with this problem and get any solution without a lot of changes on programming ?? We are really looking for a solution that has not a lot of impact in our business. Thanks.

Javier Sotela 

Depending on the makeup of your records – you MIGHT consider changing the radix – this would ore pages but fewer records per/page (might be an option if you have larger lengths –

Or set up a “partitioning” table – associate a field range for multiple segments/page groups – unl/rel to match those ranges – then have every operation read the partitioning table to determine the segment, and then make the original code a SUB-PROGRAM ad call the subprogram with the appropriate DBNAME

Or split the rows into subtables – same key – then across page groups – each transaction would only need to access the subtable(s) it is interested in

Chris Hoelscher

Technology Architect, Database Infrastructure Services

Technology Solution Services

Humana Inc.

123 East Main Street

Louisville, KY 40202

Humana.com

(502) 476-2538 or 407-7266

Hello Javier,

what is the current page size using in the database. we have the maximum available page size is 32744 in IDMS.

if you can run print space on the impacted area to know the page size which is currently allocated in the database. 

then, please...try... you can do the Xpage (database expansion to the impacted areas). if already exceed the page size of 32744.  (3390 DASD).

then, the another option to work on unload/reload utility. will fix the insufficient space on the impacted area make sure,,, you should test this activity in your test environment and before move to prod implementation.

1. Big database --- >

    a. create a new segment 

    b. try to attach existing areas to the new segment

    c. you need to decide what are the impact application areas which can attach to the new segment. In this case you will have the multiple segment.

    d. even this also have more time to complete and work on Global DMCL and so on. 

Thanks,

Sushil Joseph

Is there a reason you can't use mixed page groups and/or VLDB support?

There is a lot of sets that cross area communication, then this is not an option. Anything that CA offer requires a lot of changes at database level and programming, thats exactly what we have to skip, we need a database option that provides the horizontal growing. Thanks.

Okay – here is something silly <?>

Move the non-key fields off the record in question to “shadow” record types (in their own areas/groups)

Then …

Use LRF or stored procedures to do the retrieval/manipulation behind the scenes

(yes I said LRF)

Chris Hoelscher

Technology Architect, Database Infrastructure Services

Technology Solution Services

Humana Inc.

123 East Main Street

Louisville, KY 40202

Humana.com

(502) 476-2538 or 407-7266

Hi Everybody and thanks for answers. There is not option to do a expand page. We have one segment with cross-area crossing thru areas. In that segment almost without page range available we have 3 o 4 big areas that need more space. There is a lot of programs online and batch using the records on that areas. Then trying to do programming changes will be a lot of work and risk.  Segmentation could be the option but with that we have to change programming and database changes. We are looking something like a database procedure or something that we can change at the database level but not at programming level. Any option that anybody commented here requires a lot of programming and we don't have the time either the programmers to do that. I really need a "magical idea" or a "genius idea"  that can help us without involving a lot of programming changes.

Thanks. 

Javier Sotela

We implemented Mixed Page Group Solution in Nov 2015. See the attachment for more detail.

The answer is Mixed Page Group Support was introduced in IDMS release 14.1.

It allows a single rununit to access data residing in areas defined to different page groups.

The main restriction is that there can be no sets or indexes that cross page group boundaries.

However, a new feature Mixed Page Group Index (MPGI) was introduced in IDMS release 18.5 which allows the owner and member records within an index set relationship to reside in different page groups. See the details here:

https://support.ca.com/cadocs/7/CA%20IDMS%2018%205-ENU/Bookshelf_Files/HTML/IDMS_v18.5_ReleaseNotes_ENU/1975369.html

Since page group information is not kept in database record, using mixed page group does not require any change to existing subschema or user application. That is the case with us.

The good news is all these changes are transparent to the schema, SCCOURT and its subschema which means application programs and dialogs do not need to be rec-compiled to use mixed page groups.

However, if your application program retrieves a record by dbkey, the following consideration is observed:

• Specify on the DML command the name of the record that it is trying to retrieve
• Specify on the DML command the page group and maximum records per page of the   record that it is trying to retrieve

Ensure that the current page group and maximum records per page are correct for the record that it is trying to retrieve. The current page group and record maximum are those associated with the dbkey that is current of run unit.

You are so lucky. We have a lot of sets that connect records in multiples areas. Anything that you saids works if you don't have this problem. Hey this is a network database, the cross area communication in a network database its a standard. Thanks.

If you have any areas whose only cross-area set connection is an index set, you can make use of mixed page groups.

Do you have any areas that only contain a system-owned index?

If so, those areas can be defined in a separate page-group segment and you simply add the new segment to the DBNAME you currently set when accessing this database.

Hi Brian!!!

The answer is no, part of my problem is that this database its defined a lot of time ago. Because this is a network database, there was a lot of design criteria s that suggest multiple area connected thru sets . This was a really standard database on that time. Then I have a lot of sets not indexed that connects records in different s areas.  If I try to split it there is a lot of connections and its impossible to split it. By the other hand, doing any separation according to suggestion will be a nightmare in terms of the magnitude of programming changes. If mixed page group works with standard set not indexed will be my solution, if not, there is not my option. I suggested a lot of time ago that IDMS develop an option like db2 partitioned table spaces, that will be my solution, but this requirement has been discarded. 

Thanks.

ONE MORE SUGGESTION

CONVERT THE linked sets to system indexed sets  by prepending the symbolic key of the owner record into the new indexed sets – then – assuming you already know the key of the owner record, you could walk the indexed set as if it was a linked set

But now you have area independence – and can move areas to new page groups

Chris Hoelscher

Technology Architect, Database Infrastructure Services

Technology Solution Services

Humana Inc.

123 East Main Street

Louisville, KY 40202

Humana.com

(502) 476-2538 or 407-7266

Or … purge / Archive unwanted data

Chris Hoelscher

Technology Architect, Database Infrastructure Services

Technology Solution Services

Humana Inc.

123 East Main Street

Louisville, KY 40202

Humana.com

(502) 476-2538 or 407-7266

I'm not sure how many areas you have defined in this database. I wonder if your problem is that you are filling specific areas and have no room to expand those areas. There is a good possibility that you have other areas that are over-allocated with respect to page range. You might look at reallocating page range for those areas to free up page range overall in the database. This, alone, will leave a bunch of gaps in your page range, so you would have to unload-reload  pretty much your entire database to realign the areas and open up a large page range for the area(s) that need more page range.

I understand you have a lot of complex relationships. Maybe there are areas in the database that are not involved in those complex relationships that you can move to a different database and free up page range for just those areas that need to remain together. Again that will require a large unload-reload to consolidate page range for those areas that remain.

Also, there may be areas that can take advantage of much larger page sizes (and still not exceed the maximum records per page limit). You could review your entire database to identify areas that can be resized to larger pages and reduce the number of pages needed for the area. Then you would have to unload-reload to get the areas into the larger page sizes and remove any gaps so that you have a large open page range for the areas that are in need of more page range. (Note: changing page sizes in an area may impact your performance and locking situation since there will be more records per page. This may be a good thing since I/Os are at the page level. It may be a bad thing it you have a lot of update activity targeting specific pages, though.

Thanks, the problem is that with the option to xpan page size its not valid now, if we don't have the maximum page size its because maybe we are close to maximun number of records or we are in there now, and xpan its not working on this case. Sometimes xpan its not the option and in our case we are in there. Because this is a system that has been working fore more than 20 years, there is not areas with free space wasted, there is not "hole ranges" then its not an option too. Thanks.