Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

DELETE FILE ‘filename’ statement not removing both .dat and .idx files in native code

DELETE FILE ‘filename’ statement not removing both .dat and .idx files in native code

Problem:

A problem was encountered opening indexed files after an application was upgraded from Net Express to Visual COBOL running native code.

The SELECT statement was as follows: SELECT ‘filename’ (i.e. no extension specified).

Also, INDEXNAMETYPE=2 was set in the file handler configuration file. As a result when opening a new version of a file in Net Express the file handler created an indexed file with the naming convention filename.dat and filename.idx.

When testing Visual COBOL it seemed the Visual COBOL Native Runtime was ignoring this directive and was creating just the one file - filename.dat.

Some files were temporary transaction files and these were to be removed using the DELETE FILE statement each time the program was run.

But in Visual COBOL the .idx file was not deleted when the DELETE FILE statement was executed, and this caused a problem when opening the file later on.

 

Resolution:

The reason this happened was because in Net Express the default IDXFORMAT is “3” – which means 2 physical files (eg filename.dat & filename.idx) are created.

But with Visual COBOL the default IDXFORMAT is “8” – meaning both data and index are concatenated into one physical file – filename.dat

So the file was being generated correctly, it’s just that it was using a different IDXFORMAT.

All files were copied over from the Net Express environment, including the redundant transaction .dat and .idx files. Therefore, when either the CALL “CBL_DELETE_FILE” or the DELETE FILE <identifier> statement was executed it would only delete filename.dat and wouldn’t delete the .idx. This was simply because the file handler determined it was an IDXFORMAT”8” file and wouldn’t have an associated .idx to delete.

So there are a couple of options -:

1)      In Visual COBOL set IDXFORMAT=4 (much better than 3) in your extfh.cfg file (or directly in the program using the $SET statement) to override the default IDXFORMAT”8”.

This could be set as the ‘DEFAULT’ for all files or the transaction files only. When the file is  recreated it will create both a .dat & .idx – and subsequently delete both as well. The only downside to this is if the size of the transaction file gets greater than 4gb, which is why IDXFORMAT”8” files were developed. But as these are transaction files it’s unlikely they would, but that has to be a consideration.         

 2)      Or - simply delete any existing .idx file of the same name as the transaction file(s). That way, the transaction file will always be generated as IDXFORMAT”8”. Once the .idx has been deleted it won’t be re-regenerated and so won’t be a problem to the file handler. This is probably the best option.

So it really comes down to the fact that Visual COBOL generates IDXFORMAT”8” files when creating a new version of the file instead of IDXFORMAT”3” as in Net Express. This makes it appear as if IDXNAMETYPE is being ignored, but it isn’t.

 

 

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-03-08 06:52
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.