Cobol -> Btrieve: Index problem

[Patten]

Hey,

I'm trying to migrate a Cobol application to a Pervasive environment. It works quite well for simple files.

However I have following Cobol file:

FD File
FD-KEY
FD-FIELD1 PIC X(04)
FD-FIELD2 PIC X(09)

The File control section looks like this

SELECT ...
RECORD KEY IS FD-KEY

The problem is that my Cobol file has 1 key consisting of 1 segment taking byte 1 till 13

While migrating to a Btrieve/Pervasive file I have to create two columns being Field1 and Field 2 and I have to create an index on it.
This index is seen (using butil - stat) as 1 key consisting of 2 segments, the first taking byte 1 till 4, the second taking 5 till 13.

Which results in my application not working properly off course.

How to solve such a problem?

 

[TomKane]

Why do you have to split your key in Pervasive? Are you using BUTIL -CREATE to create your file?

record=2048 variable=no key=1 page=2560
position=1 length=13 duplicates=no modifiable=no type=string alternate=no
null=no segment=no

 

[Patten]

I have to split the key because in the application FD-FIELD1 and FD-FIELD2 are used sometimes as seperate fields, so I have to be able to use these fields seperately.

BTW: no I am not using BUTIL -CREATE to create my file, I use a create table statement in SQL.

 

[TomKane]

But if you split the key then surely you will have to change some of the code in the program to account for this? Can't you use some kind of substring or something to get around the problem?

What does your create table statement look like?

Regards,
Tom

 

[Patten]

I don't have to change some of the code in the original program, since it uses already the splitted key. I'l give the exact example so you can follow my problem better.

Original Cobol application looks like this:

FD looks like this:

FD LOON-WKN.
01 WKN-REC.
03 WKN-KEY.
05 WKN-NR-WKG PIC 9(04).
05 WKN-NR-WKN PIC 9(10).
03 WKN-DATA.
05 WKN-NAAM PIC X(70).
05 WKN-FAMILIENAAM PIC X(35).
...

File control looks like this:

SELECT LOON-WKN ASSIGN TO RANDOM WS-FILENAAM-WKN
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS WKN-KEY

Consequence: since the primary key is a group field it is in cobol format only 1 segment taking position 1 till 14.
I don't know how to translate this in Btrieve/Pervasive.
I have to create a table like this:

create table LOON_WKN
(
NR_WKG CHAR(4) NOT NULL
,NR_WKN CHAR(10) NOT NULL
,NAAM CHAR(70) NOT NULL
,FAMILIENAAM CHAR(35) NOT NULL
...

And then I create an index (primary) on fields NR_WKG and NR_WKN. Which means the primary index consists of 2 segments taking up position 1 till 4 and position 5 till 14.

So my application is not working properly anymore: I do get RM/Cobol error 3950 indicating my definition of keys does not fit the way it is described in my application, which is true. My problem is: how to solve this?

Your feedback is highly appreciated.

 

[TomKane]

Hi,

I hope you don't take it the wrong way but the way I see it is that you have two options:

Merge the two fields into one and see if that gets around your problem. If it does then you'll have to do something like the following in your select statements

SELECT substr(FIELDNAME,1,4) AS NR_WKG, substr(FIELDNAME,5,14) AS NR_WKN
....

The other option is that you'll have to examine the way your program works and make sure that the program takes into account that the key has changed

Best of luck,
Tom

 

[infounit]

I suppose you will have already solved that problem since that is an old thread, however:
Yes, you must rewrite yous SELECT:
RECORD KEY IS WKN-KEY = WKN-NR-WKG, WKN-NR-WKN
And in the FD you will choose another name for
WKN-KEY, like WKN-KEY-FIELDS (which results in having to do some source code changes as well).
In practice, I used a switch which I stored in an INI file which is read when the main menue of my app starts and if that switch is still zero, then a conversion subroutine starts that renames the old file, opens a new with correct index definitions and transfers the records (and sets the switch to 1). Thus, at the users installations, things are done automatically after my update is installed.

Dieter L. Stangl