NOTICE: Our Community is moving. Get more information.
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.
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.