rmcobol and best way to re-org index files

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

Hi Bill

1. how to re-organize rmcobol index files?
RMcobol has a routine or program called recovery.exe. you can use it any time with indexed corrupted files problems mainly 98 status erros. However, if your Indexed files are version 4 you can use Atomic configuration in order to avoid many of these errors.
2. how often should this be done?
The recovery.exe can be done any time but you have to keep in mind that while the analisys and recovering process of this program set the file status to 93, you have to control and handle it in you application programs.
3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?
You can develop a routine in order to check periodically all of your indexed data and run it as windows service. I suggest you to read the user guides manual in Appendix G.

Hope you get the idea. Good Luck.

Humberto Betancur

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

Bill,

[quote]how to re-organize rmcobol index files?[/quote]

As noted above, use the recover utility.  There is extensive documentation in the RM/COBOL Users Guide.

[quote]how often should this be done?[/quote]

This all depends on the amount and nature of the activity in the file, as well as its size.  the recover utility can be used to rebuild he index trees, and in this mode it can under some circumstances reduce the tree depth.  Reduced tree depth leads to fewer accesses for random reads.

[quote]someone told me that rmcobol index files self-reorg or have some kind of self maintenance?[/quote]

Yes, this is true.  Considerable effort is made to reuse empty and partially empty disk blocks, and the trees are built in a balanced manner in order to keep tree depth under control.

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

Tom,

Thank you for your detailed response. One more question. If executed the following steps would this accomplish the same thing as when the recover utility is used:
1. create a new empty IX file called FILE_REORG with all the attributes of FILE_ORIG
2. read FILE_ORIG with a cobol pgm by the master key and write each record out to FILE_REORG
3. mv FILE_ORIG to FILE_ORIG_date as a backup
4. mv FILE_REORG to FILE_ORIG effectively re-orging the FILE_ORIG

your thoughts? And thanks again.

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

From my experience in RM / COBOL I think that the files with the cobol files do not have to do anything to regenerate them. if there are shutdown problems or process blocks then i use recover1.

If you want you can use recover1 or recovery which is the same.

When recover1 is unable to rebuild a file, I try to extract information with recover2.cob

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

[quote]would this accomplish the same thing as when the recover utility is used[/quote]

Superficially, the answer would seem to be yes.  However, there are some nuances to consider.

The first issue pertains to alternate keys with duplicates.  The COBOL standard requires that records with duplicate key values be retrieved in temporal order when being read sequentially on the alternate key.  In other words, If I write record '5' (prime/master key value) with alternate key value 'A', then record '7' with alternate key value 'A', then record '6' with alternate key value 'A', then a START on the alternate key followed by READ NEXT statements should return records '5', '7', and '6' in that order.  Your proposed technique would write the records in the order of the prime key, so the order when read on the alternate key would be '5', '6', '7'.  You will have lost the original order on the alternate key due to the loss of the original order in which the records were written.

This may be a problem.  If you are taking bids on an item in an auction, it may be important to know which record was written first.  The recover utility uses the metadata stored with the record in order to rebuild the alternate key with duplicates in the proper order.

One other nuance has to do with tree depth.  The recover utility sorts the key values prior to rebuilding the index trees.  This results in more compact index trees and typically smaller tree depth.  This pertains to all the keys.  Your proposed re-org will present the prime key in sorted order but the alternate key values will probably not be in order.  The possible result is that alternate index trees will not benefit from being more compact.

The final issue is execution time.  There would be little reason to do this re-org on a small indexed file, so the issue of execution time may be a very real concern for larger files.  Because the recover utility leaves the data records in place (it is only reconstructing the index trees) there is a considerable savings in time spent reading the data records (which can be done in a sequential pass through the file) and of course there is no time spent writing the data records.

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

as a side note to Tom's point about execution time, I always run rmdefinx first on the file to turn off the Recoverability/Performance Strategy options (re-enable on the recovered file). Best practice for us over the years in a multi-user environment is to "force write data blocks" and "force write index blocks" on critical files, at a slight cost to performance.

does anyone have any suggestions on:

1. how to re-organize rmcobol index files?

2. how often should this be done?

3. someone told me that rmcobol index files self-reorg or have some kind of self maintenance?

please advise.

and thanks for all your help.

bill

[quote]"force write data blocks" and "force write index blocks" on critical files[/quote]

As Humberto wrote in an earlier reply, the more modern alternative to this technique is to configure Atomic IO.  Atomic IO was designed to assure that any write/rewrite operation that is successful from the standpoint of the program will be completed.  If an interruption occurs in the middle of an update (such as updating a lot of alternate key index trees), atomic IO will complete the operation when the file is next opened.  Atomic IO also forces writes through the operating system cache which was the effect of the older 'force' settings.