Cobol Copybook with variable length ID fields

dataservices job design
1

We’re stuck on how exactly to parse a copybook formatted file with the following example layout:

HDR04232014006
P04232014DAVID    SMITH     5555555555
P04232014BOB       SMITH     5555555556
P04232014GREG     SMITH     5555555557
A04232014DAVID   SMITH     123 ABC ST
A04232014BOB      SMITH      321 MAIN ST
TRL04232014006

Each record has the same number of chars.

"HDR" records are the headers records
{HDR}{MMDDYYYY}{NumRecords}{Filler}

"P" records are the phone number records
{"P"}{MMDDYYYY}{NAME}{PHONE}{Filler}

"A" records are the address details
{"A"}{MMDDYYYY}{NAME}{Address}{Filler}

"TRL" records are the trailer records
{"TRL"}{MMDDYYYY}{NumRecords}{Filler}

We’ve tried a few different approaches to the CPY file layout, but i’m unsure how exactly to get it to parse correctly. Would this file be set up as Variable or Fixed? Each line has the same number of chars incl. fillers.

I’ve tried a format similar to :

01 Header.
  02 HeaderIndicator PIC X(3).
  02 ImportDate PIC X(8).
  02 NumRecords PIC 9(3).
  02 Filler PIC X(80).
  
01 Phone.
  02 PhoneIndicator PIC X(1).
  02 ImportDate PIC X(8).
  02 PhoneName PIC X(30).
  02 PhoneNum PIC X(13).
  02 Filler PIC X(50?)

01 Address 
  02 AddressIndicator PIC X(1).
  02 ImportDate PIC X(8).
  02 AddressName PIC X(30).
  02 AddressLong PIC X(18).
  02 Filler PIC X(40?)

I’ve set the Field ID on each to be the indicator columns. It returns the Address “A” and Phone “P” numbers correctly, but returns nothing when trying to the header or trailer as “HDR” or “TRL” – when changing these to “H” or “T” then they do work. This will become an issue with a few of our other files that have “HDR” and “HOME” as the ID record fields. It seems like its only trying to capture the PIC X(1) field for all of the schemas.

Helppppppppppppppp :hb: :hb: :hb:

@Data services 4.1 SP3 p1

ww55d (BOB member since 2011-06-14)

2

Here’s what SAP have to sat about copybooks:-
http://wiki.scn.sap.com/wiki/display/EIM/Multirecord+Files

I’ve used them in the past and, quite frankly, they are a pain in the arse to get working. You might be better off reading the flat file into something like a staging table that consists of a single varchar 1024 (or whatever the length of your records are) column and then use a case transform followed by a query transform with many substr function calls to split the records into their various types and columns.

Nemesis :australia: (BOB member since 2004-06-09)