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

[Atilla Akarsular]

Hello Joe,

we could succesfully migrate to MySQL by using esqlOC from Sergey.

see: http://sourceforge.net/p/open-cobol/discussion/2526793/thread/4057115f/

We migrated all programs using a sequential file, let's call it here <SEQFILE> to a version working with MySQL.

<SEQFILE> hat this structure:

<HEAD-REC>

<REC1-CASE1>

<REC2-CASE1>

<REC3-CASE1>

<REC4-CASE1>

<REC5-CASE1>

[...]

<REC1-CASEn>

<REC2-CASEn>

<REC3-CASEn>

<REC4-CASEn>

<REC5-CASEn>

<FOOT-REC>

In a first step we wrote new Load- and UnLoad-COBOL programs which coul load a <SEQFILE> into the DB and unload into a file. This was also a good test for the database interface: After load and unload steps you should get your input file.

For every record type there already was an existing copy book. Some of them had OCCURS areas which usually means that you will need more than one table to represent this record. We still use the old copy books unchanged (!) with our migrated programs.

We could hide all esql-code which has to be preprocessed by esqlOC in sub programs. E. g.: There is a sub program which uses the old copy book REC1 in the linkage section and delivers services like INSERT, UPDATE or FETCH.

The Load- and Unload-programs can be pure COBOL programs using the new sub programs. These sub programs can also be used by your programs which shall be migrated to DB functionality.

At the end we have migrated programs with minimal changes (use some new sub program in all places where was file interaction for <SEQFILE>). Only some team members have to deal with esqlOC and pre processing. All the others just use some new sub programs.

I am working on documenting esqlOC. I hope that I can also present a minimal example for such a migration project.

Best wishes,
ati

2013/11/18 Joe Robbins <address@hidden>

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.

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list