in reply to COBOL Layout parsing
...write a generic layout parser which includes data conversion.
There is a awful lot of data out there in files stored with COBOL-FD/WS layouts waiting to be extracted and reported, an awful lot of pathological rubbish waiting to be eclectically listed.
In other words: this sounds like a Perl problem of the first hour. There are little languages that deal with such data efficiently but they are quite expensive (Easytrieve plus for instance). Somehow the efforts put into perl dealing with them are either non-existant, non-succesfull or not widely accepted (and thus on CPAN) upto now. These days even Linux is swimming into the pool of z-Series mainframes, so now might be a good time to get this going.
I for one would be very interested.
What modules would be necessary in a good COBOL-data toolkit?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Modules?
by broomberg (Initiate) on Mar 29, 2002 at 14:12 UTC | |
I guess I'd start the discussion by showing a COBOL layout, and then pointing to the pieces that would need to be dealt with. We'd need an object that took the layout as a create arg. It would parse out all the fields, setting up a array of field objects. Each field object would have enough info to read/understand that field type. I'd have a higher level structure that would take into account the physical read/unpack of the data, which would then be mapped back to the individual fields. In the case of 'redefines', I'd need a higher level parent object, then children that refer back to it, into pieces of it. We can't just chunk out the data since either object modifying it should be modifying the same data. In the case of 'occurs', we'd need arrays of objects. If the data has no 'comp' fields, I can do an EBCDIC to ASCII conversion of front to the entire record. If not, we've got to deal with it against ranges of bytes split by comp fields. | [reply] |
by mAsterdam (Sexton) on Mar 30, 2002 at 19:37 UTC | |
Is this what usage could look like?
DISCLAIMER
So here is the preliminary list of questions:
The example leaves a lot of questions unanswered:
HTH, Danny | [reply] [d/l] |
by Anonymous Monk on Nov 06, 2002 at 21:05 UTC | |
Q3: Omygod, I'm not ready for Perl6 Other: Why not just add subscripts to the (target) data variables for an OCCURS statement? 88 levels are just Static symbols. I would assume that all data has already been translated to ASCII encoding in order to use this. Are you working on something? I can work on it if you don't have anything yet (although I've never written a CPAN module before). ... HH | [reply] [d/l] |
|
Re: Re: COBOL Layout parsing
by torsore (Initiate) on Mar 29, 2002 at 21:42 UTC | |
My needs are generally not (data|data layout) conversion oriented, but I could certainly use a module that parsed COBOL data layouts and plopped them into Perl data structures. I would like to see a way to deal with the myriad of different COBOL dialects out there. It seems I am continuously reworking my scripts in order to deal with yet another COBOL dialect that my benevolent and sage employers have seen fit to jump right in to. Different dialects of COBOL (Unisys, Microfocus, IBM, Tandem, VAX, Wang, etc.) often handle data in different ways. The differences are usually subtle, but very important. Especially when dealing with comp fields. Would it make sense to have a base module implemented under ASCII COBOL (or some other standard) guidelines with other dialect specific modules available that would override the appropriate portions of the base? I know we are discussing a COBOL-data toolkit, but how about parsing COBOL code in general? I am just now starting to really research what is already out there so please be gentle on a newbie to the monastery! The same concerns over dialect apply here as well. | [reply] |
by Curunir_wolf (Initiate) on Dec 04, 2002 at 13:55 UTC | |
It doesn't address all your needs (I only have IBM COBOL II to work with), but it's a start. What more would you like to see? Thx... HH | [reply] |
by mAsterdam (Sexton) on Mar 30, 2002 at 19:45 UTC | |
My needs are generally not (data|data layout) conversion oriented, ... Could you state more specifically what functionality you would like to see available? Thx, Danny | [reply] |