READ WORK FILE for varibale length records

I have a dataset with fields separated by comma and variable record length
e.g.
emp-no,first-name,last-name,address,dept

Need to read this dataset (READ WORK FILE) and separate all the fields to update records (for emp-no & address) in ADABAS file.

Please share a best possible approach. Can we achieve this using SELECT clause on READ WORK statement?

Hi Ats,
I would suggest you use the SEPARATE statement.

  • with delimiter “,”.
    Finn
    PS As I heard one of the founding “Natural Father” once say (my quote):
    “Natural should be natural”
    So of course the statement used to separate is SEPARATE :wink:

Thanks Finn! Got you!

Yep! statement used to separate is SEPARATE :wink:

Just an additional note to say, beware of quoted delimiters! SEPARATE does not have an option to ignore delimiters within quotes, so such values get split into adjacent receiving fields.

One way to handle it in Natural 6 is to define the work file as type CSV.

Unfortunately the default delimiter is semi-colon, and it can’t be changed dynamically.

Additionally, in order to change it, you first have to define the file type as CSV in the NatParm (then click the now-available browse button bext to CSV). Obviously any existing progams using the work file number with default type may have to be changed to explicitly define their type now.

The old method we have in production re-joins any split values after the SEPARATE into an array, but this is quite complex and slow (1-1.5 milliseconds per average record). But if you want the code I can post it.

Another way to handle it if you can create the data set is to use semi-colon, although this will cause confusion with CSV readers like Excel which expect, not surprisingly, Comma-Separated Values.

Or use Tab (H’09’) and SEPARATE.

Hopefully Software AG will enable a natparm-wide default delimiter to be set! Or even better, make it dynamic, so that one can handle any delimited file.

This is the Natural Basics on Mainframes, so Natural 6 and file types are not relevant.