Difference between how Fujitsu creates Btrieve files

[jglathar]

We are migrating from MBP to Fujitsu COBOL and I have encountered a difference in how Fujitsu is interfacing and creating Btrieve files.

Thusly, Fujitsu is unable to read our existing Btrieve files.

Has anyone else been through this process.

OR

Can anyone help explain how Fujitsu determinces how to create Btreive files with certain attributes such as varaiable lengths and modifiable keys?

Fujitsu's response was that they "just hand it off" to the Btrieve file handler", but there has to be more than that.

Thank you,

Jason

 

[fredericofonseca]

How are you defining your files?
Most specifically the SELECT and FD of a two of those that don't work.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[jglathar]

I use the same select and FD statments for both.

The select statement:
SELECT OPTIONAL DTCODE-FILE ASSIGN DTCODE-FILE-NAME
ACCESS MODE IS DYNAMIC
ORGANIZATION IS INDEXED
LOCK MODE IS AUTOMATIC
RECORD KEY IS DTCODE-KEY-1
ALTERNATE RECORD KEY IS DTCODE-KEY-2 WITH DUPLICATES
FILE STATUS IS DTFILE-FSTATUS.

And the FD:
FD DTCODE-FILE.
01 DTCODE-RECORD-ALL PIC X(066).
01 DTCODE-RECORD.
03 DTCODE-KEY-1.
05 DTCODE-CO-NO PIC 9(002).
05 DTCODE-PROG-ID.
07 DTCODE-MOD PIC X(002).
07 DTCODE-PROG PIC X(006).
05 DTCODE-FUNCTION PIC 9(002).
03 DTCODE-KEY-2.
05 DTCODE-CO-NO-2 PIC 9(002).
05 DTCODE-MOD-ID PIC X(002).
05 DTCODE-MENU-NO PIC 9(002).
05 DTCODE-OPTION PIC 9(002).
05 DTCODE-FUNCTION-2 PIC 9(002).
03 DTCODE-PROG-NAME PIC X(030).
03 DTCODE-SECURITY-LEVEL PIC 9(001).
03 DTCODE-PARM-TYPE PIC X(002).
03 DTCODE-EXE-NAME PIC X(008).
03 FILLER PIC X(003).

 

[fredericofonseca]

ASSIGN DTCODE-FILE-NAME

How do you define DTCODE-FILE-NAME.
both internal and external names.

And which version of Btrieve do you have? and which one created the files?

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[jglathar]

Internal File name for MBP is just "DTCTRLFL.ISM" AND for Fujitsu it is "DTCTRLFL.ISM,BTRV". We string the path on the front as well in each instance. The PIC clause is PIC X(42).

Using the "BUTIL" utility, the btrieve file version is 6.00.

And the version of Pervasive is 7. (Pervasive.SQL 7)

 

[kellyhpdx]

The response from Fujitsu is correct, as the only interface that the NetCOBOL runtime has to Btrieve is through the BTRCALL functions exposed by the Btrieve API. You mention that the BUTIL utility is showing a Btrieve file version of 6.0, but you are using Pervasive 7. While most times the Btrieve API is backwards compatible, I wouldn't rely on it. The NetCOBOL runtime looks for the dll 'wbtrv32.dll' on the system using the folders specified in the PATH environment variable.

You want to make sure that the wbtrv32.dll that it finds matches the version of Pervasive that you have installed. That is, it should find the one that ships with version 7.

You should convert the Btrieve file in question to the same version of the Pervasive engine that you have installed and try again.

 

[jglathar]

After further analysis I had 2 engines on my workstation. I have now cleaned up my computer and only have the "Pervasive.SQL 2000" on my workstation. This is obviously a "client/server" type of engine.

But, since removing the local btrieve engine I have not been able to get my sample program to create a Btrieve file. My guess is that the program is not recognizing that the btrieve requester.

Any ideas?