RecordEditor / Discussion / Help: Unable to read Mutliple Record Copybook: String index out of range: 0

Amer Safdar - 2022-12-19

Hi,

I am trying to read a single copybook that represents multiple records in a ASCII file output. I am new to cobol and have been trying to parse the copybook in RecordEditor to generate the Java code. I can successfully load the copybook under Utilities -> Cobol Copybook Anaylsis. When I try import the copybook using "Load Cobol Record Layout" I get String index out of range: 0 error.

I need some guidance if the format and structure of copybook is valid and also if the file structure is correct to read/parse the data file.

Below is the actual data file definition and structure documentation:

https://www.rrc.texas.gov/media/zgccdjpi/drillingpermitmasterpluslatitudeslongitudes_oga049m_july1.pdf

I have attached the data file, extracted copybook from PDF and the error message I am receiving in record edit.

Thank you.

daf420_data_file.dat

error.JPG

test4.cbl

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bruce Martin - 2022-12-22

The problem is with field RAILROAD-COMMISSION-TAPE-REC, it has no picture clause:

02 RRC-TAPE-RECORD-ID PIC X(02). 02 RAILROAD-COMMISSION-TAPE-REC. 02 RRC-TAPE-RECORD-ID PIC X(02).

Just comment it out, I will update RecordEditor to report/ignore this type of issue.

Also a separate issue is DA-CONVERTED-DATE is a comp field. This create 2 problems:

It will be corrupted by Mainframe EBCIDIC to ascii conversion

It could be treated as Line field - corrupting the record (splitting the record in to 2 records).

Last edit: Bruce Martin 2022-12-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amer Safdar - 2022-12-22

Bruce. Thanks for your prompt reply. Commenting that line out worked. However when you open the data file the encoding seems to be ASCII. So will there still be corruption with the comp field ? What is your recommendation to handle the comp field in the ASCII data file to avoid such corruption or incorrect parsing of the file.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bruce Martin - 2022-12-23

You can certainly view/edit the file with file with the RecordEditor but remember

If the file was converted from the Mainframe this field could be corrupt

Lines could be split in 2 if a \n happens to be in this field

From the Mainframe

When transferring a binary file from the Mainframe

Use the binary transfer option (keep the file as EBCDIC)

For VB files also use the RDW option is used to ensure the RDW is transferred

Note: RDW: record Descriptor word basically record length

Note: VB Files are a type of file on the mainframe. Each Record has a RDW (basically record length) preceding it.
It is important that this RDW is also transferred

Problems with doing a EBCDIC to ASCII translation of a binary file

The translation program will treat binary fields as text fields as text fielk. So if
a boinary field has x'40' (64 decimal) the EBCDIC space character it will be converted to
the ASCII space character x'20' (Decimal 32). So your 64 is now 32

COBOL on the PC / linux / unix

If you are using COBOL on a PC / Linux etc you can use ASCII but for binary files
Do not use Standard Text files (LINE SEQUENTIAL in COBOL) use either Fixed length or variable length.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I have managed to generate Java code to read and extract the records. I have an issue with following section:

   01 DAW999A1.
       05 DA-SURF-LOC-LONGITUDE PIC 9(5)V9(7) VALUE SPACES.
       05 DA-SURF-LOC-LATITUDE PIC 9(5)V9(7) VALUE SPACES.
   01 DAW999B1.
       05 DA-BOTTOM-HOLE-LONGITUDE PIC 9(5)V9(7) VALUE SPACES.
       05 DA-BOTTOM-HOLE-LATITUDE PIC 9(5)V9(7) VALUE SPACES.

Record number 14 and 15 have latitude and longitude values that represent in the data file like this:

14 -94.3251710 31.4884060
15 -94.3185210 31.4729580

But when i extract the values, using Java code, they are coming out like this:

DA-SURF-LOC-LONGITUDE	DA-BOTTOM-HOLE-LATITUDE
14-94.32517	10 31.48840

DA-BOTTOM-HOLE-LONGITUDE	DA-BOTTOM-HOLE-LOC-LATITUDE
15-94.31852	10 31.47295

This is my code:

if ("14".equals(line.getFieldValue(rDaw999a1.rrcTapeRecordId).asString())) {
                        JSONObject daw999a1 = new JSONObject();

                        daw999a1.put("rrcTapeRecordId",line.getFieldValue(rDaw999a1.rrcTapeRecordId).asString());

                        daw999a1.put("daSurfLocLongitude",line.getFieldValue(rDaw999a1.daSurfLocLongitude).asString());

                        daw999a1.put("daSurfLocLatitude",line.getFieldValue(rDaw999a1.daSurfLocLatitude).asString());

                        //daw999a1.put("daCountyCode",line.getFieldValue(rDaw999a1.daCountyCode).asString());
                        //daw999a1.put("daConvertedDate",line.getFieldValue(rDaw999a1.daConvertedDate).asString());


                        daw999a1Array.put(daw999a1);
                    }

                    if ("15".equals(line.getFieldValue(rDaw999b1.rrcTapeRecordId).asString())) {
                        JSONObject daw999b1 = new JSONObject();

                        daw999b1.put("rrcTapeRecordId",line.getFieldValue(rDaw999b1.rrcTapeRecordId).asString());
                        daw999b1.put("daBottomHoleLongitude",line.getFieldValue(rDaw999b1.daBottomHoleLongitude).asString());
                        daw999b1.put("daBottomHoleLatitude",line.getFieldValue(rDaw999b1.daBottomHoleLatitude).asString());

                        daw999b1Array.put(daw999b1);
                    }

It seems the get fieldValue is including the RRC-TAPE-RECORD-ID value and concatenating it with Lat/Long fields. Can you please advise why this might be happening.

Last edit: Amer Safdar 2023-04-14

Bruce Martin - 2023-04-14

The problem is the Copybook does not match the data. So either it is the wrong file or the wrong copybook.

I reliase this not something you can influence, one of the things I have always advacate is including the copybook name in the file name at specified position (start or end). It makes life easy for everybody !!! e.g. if the copybook is PZR1000, the file name might be (ptpz.PZR1000.price.extract or ptpz.price.extract.PZR1000)

In this case, the Copybook should look like:

01 DAW999A1. 05 Record-Type pic XX. 05 DA-SURF-LOC-LONGITUDE PIC --9.9(7) VALUE SPACES. 05 DA-SURF-LOC-LATITUDE PIC --9.9(7) VALUE SPACES.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I updated the CopyBook file section to below and it worked. Thanks:

   01 DAW999A1.
       05 RRC-TAPE-RECORD-ID PIC X(02).
       05 DA-SURF-LOC-LONGITUDE PIC 9(5)V9(9) VALUE SPACES.
       05 DA-SURF-LOC-LATITUDE PIC 9(5)V9(9) VALUE SPACES.
   01 DAW999B1.
       05 RRC-TAPE-RECORD-ID PIC X(02).
       05 DA-BOTTOM-HOLE-LONGITUDE PIC 9(5)V9(9) VALUE SPACES.
       05 DA-BOTTOM-HOLE-LATITUDE PIC 9(5)V9(9) VALUE SPACE

Hi @bruce_a_martin in the copybook file I have lots filler entries like below

   01 DAREMARK.
      02 RRC-TAPE-RECORD-ID PIC X(02). 
      02 DA-REMARKS-SEGMENT.
         03 DA-REMARK-SEQUENCE-NUMBER PIC 9(03) VALUE ZEROS. 
         03 DA-REMARK-FILE-DATE.
            05 DA-REMARK-FILE-CENTURY PIC 9(02) VALUE ZEROS. 
            05 DA-REMARK-FILE-YEAR PIC 9(02) VALUE ZEROS.
            05 DA-REMARK-FILE-MONTH PIC 9(02) VALUE ZEROS. 
            05 DA-REMARK-FILE-DAY PIC 9(02) VALUE ZEROS.
         03 DA-REMARK-LINE PIC X(70) VALUE SPACES. 
         03 FILLER PIC X(10) VALUE ZEROS.
      02 RRC-TAPE-FILLER PIC X(0417) VALUE SPACES.

I noticed the DA-REMARK-LINE field is getting cutoff. its a long string but separated by new line.

Example:

080129THIS WELL MUST COMPLY TO THE NEW SWR 3.13 REQUIREMENTS CONCERNING THE P0000000000
080229ISOLATION OF ANY POTENTIAL FLOW ZONES AND ZONES WITH CORROSIVE FORMATIP0000000000
080329ON FLUIDS.  SEE APPROVED PERMIT FOR THOSE FORMATIONS THAT HAVE BEEN IDP0000000000
080429ENTIFIED FOR THE COUNTY IN WHICH YOU ARE DRILLING THE WELL IN.        P0000000000

How can I get whole string ?

Thanks.

Bruce Martin - 2023-04-28

There is no way to do this in JRecord. It would have to be handled in program logic.
It is not something Cobol does, it would be handled in the cobol Code.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amer Safdar - 2023-04-28

Thanks @bruce_a_martin are you able to share what the code might look like ? How will I determine the end of the string here ? Can P0000000000 be treated as newline character ?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amer Safdar - 2023-04-29

I noticed the SEQUENCE-NUMBER defines if there is a records continuation from previous number

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bruce Martin - 2023-04-29

The SEQUENCE-NUMBER is quite possibly the answer. I was going to say I need to see more of the file. Cobol copybooks do not tell you things like this, it is held in the Cobol Code, but you can generally work it out provided you can see enough of the file to see any patterns

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Unable to read Mutliple Record Copybook: String index out of range: 0

Editor for Fixed Width, Csv and Existing Xml files.

Forums

Help

Unable to read Mutliple Record Copybook: String index out of range: 0

From the Mainframe

Problems with doing a EBCDIC to ASCII translation of a binary file

COBOL on the PC / linux / unix

Unable to read Mutliple Record Copybook: String index out of range: 0

Editor for Fixed Width, Csv and Existing Xml files.

Forums

Help

Unable to read Mutliple Record Copybook: String index out of range: 0 document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

From the Mainframe

Problems with doing a EBCDIC to ASCII translation of a binary file

COBOL on the PC / linux / unix

Unable to read Mutliple Record Copybook: String index out of range: 0