Cobol - COBOL COPYBOOK CONVERTER

Author

COBOL COPYBOOK CONVERTER

FrOsTbYtE

2004-11-18, 8:55 pm

OK. I have been doing this through SAS. But the maintenace has become
to great. We have flat files on mainframes that have copybooks defined
for them.

Most records have hundreds of fields. I am only interested in 20 or
so. I would like to create the output copybook layout using the same
field names as the input copybook.

Does anyone have a COBOL program that does nothing more than this?

Moreover, I would prefer to have something where I could compile the
program and pass the copybooks as PARMS in my JCL or as DD statements.
Basically something that I can reuse as long as I have an input and
output copybook layout that uses the same field names.

Any suggestions?

FYI I know JCL, SAS and SYNCSORT pretty well. Used COBOL in school
years ago so I understand just can't write from scratch.

Thanks.

William M. Klein

2004-11-18, 8:55 pm

I am not clear on exactly what you are asking for the program to do. If you
have (COBOL) copybooks that describe the input file - do you want to MANUALLY
create the output copybook (telling which files to keep) and then have a COBOL
program create the output file for you?

If so, this is a pretty simple COBOL program (and could be done quite easily).
Providing JCL to (semi-)randomly take various input/output copybooks and compile
the COBOL program and then run it would also be easy.

If, however, you want a COBOL program to CREATE the output copybook, then how
will you tell it which fields you want to keep and which you don't?

--
Bill Klein
wmklein <at> ix.netcom.com
"FrOsTbYtE" <frostbyte@arctic.net> wrote in message
news:3o2qp0dsqdn9g4tgn7u5a136q64l3b18k3@
4ax.com...
> OK. I have been doing this through SAS. But the maintenace has become
> to great. We have flat files on mainframes that have copybooks defined
> for them.
>
> Most records have hundreds of fields. I am only interested in 20 or
> so. I would like to create the output copybook layout using the same
> field names as the input copybook.
>
> Does anyone have a COBOL program that does nothing more than this?
>
> Moreover, I would prefer to have something where I could compile the
> program and pass the copybooks as PARMS in my JCL or as DD statements.
> Basically something that I can reuse as long as I have an input and
> output copybook layout that uses the same field names.
>
> Any suggestions?
>
> FYI I know JCL, SAS and SYNCSORT pretty well. Used COBOL in school
> years ago so I understand just can't write from scratch.
>
> Thanks.

Joe Zitzelberger

2004-11-19, 3:55 pm

In article <3o2qp0dsqdn9g4tgn7u5a136q64l3b18k3@4ax.com>,
FrOsTbYtE <frostbyte@arctic.net> wrote:

> OK. I have been doing this through SAS. But the maintenace has become
> to great. We have flat files on mainframes that have copybooks defined
> for them.
>
> Most records have hundreds of fields. I am only interested in 20 or
> so. I would like to create the output copybook layout using the same
> field names as the input copybook.
>
> Does anyone have a COBOL program that does nothing more than this?
>
> Moreover, I would prefer to have something where I could compile the
> program and pass the copybooks as PARMS in my JCL or as DD statements.
> Basically something that I can reuse as long as I have an input and
> output copybook layout that uses the same field names.
>
> Any suggestions?
>
> FYI I know JCL, SAS and SYNCSORT pretty well. Used COBOL in school
> years ago so I understand just can't write from scratch.
>
> Thanks.

If you are on a mainframe and have IBMs compiler there is an easy
solution.

Write out a simple template program that has nothing but the
ID-division, et al, working storage section with your COPY statement and
a procedure division with a goback.

Invoke the compiler on this simple program with the ADATA option. The
ADATA records for the program will be written to the SYSADATA dd. You
can then read them in and convert them to whatever you want. The record
layouts are described at the end of the IBM Cobol Language Reference for
the latest version, but I dont remember which appendix.

No Cobol required for this, you could use SAS or Rexx or C or whatever
you feel comfortable with.

Howard Brazee

2004-11-19, 3:55 pm

I have a program that copies a file that was FTPd to me, and reformats it to
match the tape that we have been getting.

The difference between the two files is that the tape has some packed decimal
fields, and the FTP file obviously doesn't.

This is the applicable part of the code:

- - - - - - - - - - - - - - - - 67 Line(s) not Displayed
COPY LAMMASTP REPLACING ==EDUSERV-RECORD==
BY ==TAPEOUT-REC==.
/
COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.
- - - - - - - - - - - - - - - - 70 Line(s) not Displayed
MOVE CORRESPONDING EDUSERV-RECORD TO TAPEOUT-REC
- - - - - - - - - - - - - - - - 21 Line(s) not Displayed

The copy member starts off like this:

01 EDUSERV-RECORD.
05 LN-DETAIL-RECORD.
10 LN-BORROWER-NAME PIC X(30).
10 LN-SOC-SEC-NUMBER PIC S9(09) COMP-3.
10 LN-P-ADDR-LINE-1 PIC X(25).
10 LN-P-ADDR-LINE-2 PIC X(25).
10 LN-P-ADDR-LINE-3 PIC X(25).

Ron

2004-11-19, 3:55 pm

FrOsTbYtE <frostbyte@arctic.net> wrote:
>Thanks to all that have responded thus far. Actually what I am looking
>for is quite simple. I want an example of COBOL code that would:
>
>Read in a dataset (name provided in JCL)
>Read in a copybook (name provided in JCL)
>Write the dataset (name provided in JCL)
>Using a different copybook (name provided in JCL)
--snip--
>The output dataset will only contain the fields specified in the
>output copybook layout.

Is there a reason you want to use COBOL? You're
definitely doing it the hard way. You say:

>FYI I know JCL, SAS and SYNCSORT pretty well

This whole thing can be done in Syncsort
via the OUTREC control card. You could also
do this via IEBGENER, though it's a little more
awkward, or it's a natural for Easytrieve, if
you have that.

--
Ron
(user ron
in domain spamblocked.com)

E P Chandler

2004-11-19, 3:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<nBend.3235102$yk.501138@news.easynews.com>...[color=darkred]
> From your references to "DSN, JCL, SAS" - I am assuming that you are on an IBM
> mainframe.
>
> With the COBOL there, there is no EASY way to "dynamically" read in a copybook
> (at run-time) and determine what fields to copy to an output file.
>
> ***
>
> The way that I would (probably) solve your problem would be to set up a JCL
> stream.
>
> 1) Step 1
> Copy input and output copybooks from "individual" names to some common name
> (in a PDS) such as
> INPCPY
> OUTPCPY
>
> 2) Step 2
> Compile (probably also Step2a - link) a simple program (using these standard
> copybook names) for the input and output files
>
> 3) Step 3
> Run the job specified above (with the designated input and output files)
>
> ***
>
> Creating such JCL is a "piece of cake" - Creating the COBOL program for Step 2
> is ALMOST as easy but does require someone knowing COBOL.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "FrOsTbYtE" <frostbyte@arctic.net> wrote in message
> news:o8rqp0lmeol119orc7evo6g5io8ptcid9d@
4ax.com...

1. Why can't you use existing system utilities to extract fields from
one dataset to create another? Read both copybooks, parse them, match
fields, calculate character positions and write a file containing the
needed JCL?

2. Or, read both copybooks as data files, parse them, match fields,
then write a COBOL program to be compiled as output?

3. Why supply an output copybook at all? How about (for example)
prefixing each line in the input copybook with an extra column. If the
character in that column is blank, then do nothing, otherwise append
that line to the output copybook and add a MOVE statement. Again, let
one COBOL program write another.

(Sorry if these suggestions do not make sense in a mainframe
environment. I do all of my work on PCs these days.)

Howard Brazee

2004-11-19, 8:55 pm

What's the advantage of having one program handle a bunch of copybooks pulled in
at run time?

Why not have a bunch of programs? Either have the JCL select the program, or
have one program call the sub-program that matches the parms?

FrOsTbYtE

2004-11-20, 3:55 am

On Fri, 19 Nov 2004 04:25:55 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>From your references to "DSN, JCL, SAS" - I am assuming that you are on an IBM
>mainframe.
>
>With the COBOL there, there is no EASY way to "dynamically" read in a copybook
>(at run-time) and determine what fields to copy to an output file.
>
> ***
>
>The way that I would (probably) solve your problem would be to set up a JCL
>stream.
>
>1) Step 1
> Copy input and output copybooks from "individual" names to some common name
>(in a PDS) such as
> INPCPY
> OUTPCPY
>
>2) Step 2
> Compile (probably also Step2a - link) a simple program (using these standard
>copybook names) for the input and output files
>
>3) Step 3
> Run the job specified above (with the designated input and output files)
>
>***
>
>Creating such JCL is a "piece of cake" - Creating the COBOL program for Step 2
>is ALMOST as easy but does require someone knowing COBOL.

Bill K:

That is so simple it is almost eloquent. You are a genius.

The reason for this program is:

1) I do not own the input copybook and cannot make changes to it.
2) The copybooks change in position too frequently to use SYNCSORT
3) Fields get added and reformatted all the time but seldom renamed or
deleted.
4) Reusability of code.

I may have to compile and link. But it should work in theory.

Thanks to all for the help.

E P Chandler

2004-11-20, 3:55 pm

FrOsTbYtE <frostbyte@arctic.net> wrote:

> Bill K:
>
> That is so simple it is almost eloquent. You are a genius.
>

He certainly is! For some reason I did not think about using MOVE
CORRESPONDING inrec TO outrec. Other than stupidity, is there some
reason that I should avoid this construct?

docdwarf@panix.com

2004-11-20, 3:55 pm

In article <7f64e2ff.0411200747.4b192897@posting.google.com>,
E P Chandler <epc8@juno.com> wrote:
>FrOsTbYtE <frostbyte@arctic.net> wrote:
>
>
>He certainly is! For some reason I did not think about using MOVE
>CORRESPONDING inrec TO outrec. Other than stupidity, is there some
>reason that I should avoid this construct?

Other than the fact that some folks seem to be religiously opposed to
it... maybe.

DD

Lueko Willms

2004-11-20, 3:55 pm

.. On 20.11.04
wrote epc8@juno.com (E P Chandler)
on /COMP/LANG/COBOL
in 7f64e2ff.0411200747.4b192897@posting.google.com
about Re: COBOL COPYBOOK CONVERTER

EPC> He certainly is! For some reason I did not think about using MOVE
EPC> CORRESPONDING inrec TO outrec. Other than stupidity, is there some
EPC> reason that I should avoid this construct?

No.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Gerade das Gegenteil tun heißt auch nachahmen, es heißt nämlich das Gegenteil nachahmen. -G.C.Lichtenberg

Robert Wagner

2004-11-21, 3:55 am

On Thu, 18 Nov 2004 22:59:13 -0500, FrOsTbYtE <frostbyte@arctic.net>
wrote:

>Thanks to all that have responded thus far. Actually what I am looking
>for is quite simple. I want an example of COBOL code that would:
>
>Read in a dataset (name provided in JCL)
>Read in a copybook (name provided in JCL)
>Write the dataset (name provided in JCL)
>Using a different copybook (name provided in JCL)
>
>Usually reading in just one DSN per instance of the job. If more than
>one dataset is specified, I could concatenate them on DD statement in
>the JCL as they will always use the same copybook and be the same
>format.
>
>The output will always be just one dataset.
>
>The output dataset will only contain the fields specified in the
>output copybook layout. Most of the time, just character or numeric
>data.
>
>The idea is if the input copybook changes (i.e. a new field gets
>added). No modification would need to be made unless the field is
>going to be newly added to the output copybook. In short, no having to
>recalculate field positions for the output.
>
>That's it. Nothing fancy.

I posted here a program that does half of what you want. It reads and
interprets an input copybook, reads the data file and writes a CSV.
Look for COB2CSV. Logic to parse an output copybook would be the same
as input. Flagging matching fields would be easy.

Alistair Maclean

2004-11-21, 3:55 pm

l.willms@jpberlin.de (Lueko Willms) wrote in message news:<9LCvZiquflB@jpberlin-l.willms.jpberlin.de>...
> . On 20.11.04
> wrote epc8@juno.com (E P Chandler)
> on /COMP/LANG/COBOL
> in 7f64e2ff.0411200747.4b192897@posting.google.com
> about Re: COBOL COPYBOOK CONVERTER
>
>
> EPC> He certainly is! For some reason I did not think about using MOVE
> EPC> CORRESPONDING inrec TO outrec. Other than stupidity, is there some
> EPC> reason that I should avoid this construct?
>
> No.
>
Actually, YES. I worked at First Data Europe, in Basildon, England,
where we used an in-house developed cross-reference facility which
x-refed all data items. A move corresponding would miss a vital move.

Lueko Willms

2004-11-21, 8:55 pm

.. On 21.11.04
wrote alistair@ld50macca.demon.co.uk (Alistair Maclean)
on /COMP/LANG/COBOL
in d487f04c.0411211127.5beb9c7e@posting.google.com
about Re: COBOL COPYBOOK CONVERTER

on the CORRESPONDING clause in MOVE, ADD and SUBTRACT:

AM> where we used an in-house developed cross-reference facility which
AM> x-refed all data items. A move corresponding would miss a vital move.

in other words, because this cross-reference tool could not cope
with the COBOL syntax, the COBOL programs had to be crippled?

BTW, it is the compiler which should provide the cross-reference
listing.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Das Buch muß erst ausgedroschen werden. -G.C.Lichtenberg

Warren Simmons

2004-11-21, 8:55 pm

In reply to the question at the end,
does the compiler have all the information?

Warren simmons

Lueko Willms wrote:
> . On 21.11.04
> wrote alistair@ld50macca.demon.co.uk (Alistair Maclean)
> on /COMP/LANG/COBOL
> in d487f04c.0411211127.5beb9c7e@posting.google.com
> about Re: COBOL COPYBOOK CONVERTER
>
>
> on the CORRESPONDING clause in MOVE, ADD and SUBTRACT:
>
>
> AM> where we used an in-house developed cross-reference facility which
> AM> x-refed all data items. A move corresponding would miss a vital move.
>
> in other words, because this cross-reference tool could not cope
> with the COBOL syntax, the COBOL programs had to be crippled?
>
> BTW, it is the compiler which should provide the cross-reference
> listing.
>
>
>
> Yours,
> Lüko Willms http://www.willms-edv.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> Das Buch muß erst ausgedroschen werden. -G.C.Lichtenberg

Lueko Willms

2004-11-22, 3:55 am

.. On 18.11.04
wrote frostbyte@arctic.net (FrOsTbYtE)
on /COMP/LANG/COBOL
in 3o2qp0dsqdn9g4tgn7u5a136q64l3b18k3@4ax.com
about COBOL COPYBOOK CONVERTER

f> Most records have hundreds of fields. I am only interested in 20 or
f> so. I would like to create the output copybook layout using the same
f> field names as the input copybook.
f>
f> Does anyone have a COBOL program that does nothing more than this?

You mean using the same COPY element for two files? Sure, why not?
You can use MOVE CORRESPONDING, or qualify the fields with the file
names.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Es gibt manche Leute die nicht eher hören bis man ihnen die Ohren abschneidet. -G.C.Lichtenberg

Howard Brazee

2004-11-22, 8:55 pm

On 21-Nov-2004, alistair@ld50macca.demon.co.uk (Alistair Maclean) wrote:

> Actually, YES. I worked at First Data Europe, in Basildon, England,
> where we used an in-house developed cross-reference facility which
> x-refed all data items. A move corresponding would miss a vital move.

I don't understand. Why would a move corresponding miss any move because of a
cross-reference facility?

Donald Tees

2004-11-22, 8:55 pm

Howard Brazee wrote:
> On 21-Nov-2004, alistair@ld50macca.demon.co.uk (Alistair Maclean) wrote:
>
>
>
>
> I don't understand. Why would a move corresponding miss any move because of a
> cross-reference facility?

Exactly. A move of record to record uses data names the same as any other.

Donald

Sponsored Links