The extension on indexed data files may become an issue especially when coming from other legacy COBOL brands.
Here we will analyze the different alternatives isCOBOL provides to handle the extension and how it affects several areas of the application during migration, maintenance and deployment time.
First: Migrating indexed data files that already contain an extension (.dat for example).
Whether the indexed data file comes in a single .dat file or on a dual form of .dat and .index (the .index extension may vary from COBOL to brand to brand) the main case is when the SELECT statement explicitly and static or dynamically defines the physical name with the .dat extension.
select myfile assign to random "myfile.dat" ...
select myfile assign to ws-filename ...
Move "myfile.dat" to ws-filename
Open input myfile
On this case the physical file migrated to Jisam or C-Tree, ends up having what looks like a double extension: myfile.dat.dat and myfile.dat.idx
This could be avoided by running the ISMIGRATE utility with the following option enabled:
If ISMIGRATE is used in background (called from a cobol program), the following runtime property should be set:
And, to avoid having to change the select statement on the copybooks and/or programs, the following runtime property should be used to run the programs:
Second: Create an indexed data file from scratch using Jisam or C-tree directly.
In this case it's better to avoid the .dat extension in the physical filename on the select, so Jisam or C-Tree will by default generate the .dat extension for the data file part and the .idx on the index file.
For example this Select:
select myfile assign to "myfile" ...
will create: myfile.dat and myfile.idx
There are 2 runtime properties that allow to customize these extensions for the indexed data files. For example using:
the same Select will create: myfile and myfile.fil