Re: [open-cobol-list] Are keys for COBOL INDEXED files by definition PIC X (implicitly)?

[Joe Robbins]

Hello Ron

 

Thanks for your helpful reply. I can test what happens if the key field contains COMP fields on an ancient Micro Focus compiler we have here. I "get" the principle of VBISAM and BDB treating the key simply as an ordered set of bytes. I am just unsure whether the COBOL standards state that the bytes must be ASCII (EBCDIC) characters. Embedding COMP (binary) fields may make no sense in getting an ordered KEY: I am thinking byte-ordering, signing, etc.

 

If some (one?) experienced COBOL users reply "our programs used non-alphanumeric fields in KEYs all the time ...". then I will have to re-think. Otherwise, I will assume it doesn't happen and leave the code as it stands.

 

Just to clarify my earlier email (so expectations are not raised too high): I am specifically talking about the KEYs of an INDEXED file.

 

Mapping the COBOL file record - field by field - into a database table, so that each field is a column in the table, is a project for another day.

 

Currently all we are doing is creating a table with rows like:

        ID, key-0, key-1 ... key-n, [rsz], data

 

The field "data" is the COBOL file record (BINARY) which passes between program and database.  

 

Why would we want to do this? Because many installations are organised around databases and have tools to manage the databases. It's quite "cute" viewing COBOL files using MS SQL Server Management Studio for example. It makes viewing data, deleting records, and even updating them fairly easy. It also makes network distribution of files more transparent to the end-user.

 

Regards: Joe Robbins
 
Bawtry Computer Services
 www.bawtry.net

 

---

From: Ron Norman <address@hidden>
Sent: 17 November 2013 21:53
To: Joe Robbins
Subject: Re: [open-cobol-list] Are keys for COBOL INDEXED files by definition PIC X (implicitly)?

 

For VBISAM, CISAM, DISAM, the keys are just treated as a sequence of bytes and the ISAM code does not care if those bytes represent ASCII characters for COMP-3 data.

But for a database using ODBC or something else, I would expect the database to be a lot more picky and require you to have valid data for the column type in the database.

If you want to replace simple ISAM files with an SQL table, you will need something that knows the SQL database structure and can do the mapping (data conversion) from the COBOL PICs into the SQL columns. Or if you ISAM files have all USAGE DISPLAY data then you could make a smoother transition.

For my normal job, my business has a software package that will do the data conversion from COBOL PICs to SQL columns on the fly but it takes a fair bit of setup and this is commercial software so there is cost for it.