For Programmers: Free Programming Magazines  


Home > Archive > Cobol > November 2004 > COBOL COPYBOOK CONVERTER









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author COBOL COPYBOOK CONVERTER
FrOsTbYtE

2004-11-22, 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-22, 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.



Alistair Maclean

2004-11-23, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote in message news:<cnt179$5at$1@peabody.colorado.edu>...
> 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?


Move corresponding does not explicitly reference the subject fields
and therefore a program suite which parses the code and extracts
fields referenced by line will not explicitly pick up on the
implicitly referenced fields.
Ron

2004-11-23, 3:55 am

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)
Esmond Pitt

2004-11-23, 3:55 am

Alistair Maclean wrote:
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


That would appear to indicate a shortcoming in the program suite ...

Lueko Willms

2004-11-23, 3:55 am

.. 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
Howard Brazee

2004-11-23, 3:55 pm


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

>
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


So the move corresponding works fine. The cross-referencing fails.
Richard

2004-11-23, 8:55 pm

alistair@ld50macca.demon.co.uk (Alistair Maclean) wrote

> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


Nor would a group move.
LX-i

2004-11-24, 3:55 am

E P Chandler 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?


For this, no. For a large program, qualification can get to be a bit
tedious, but it still works. If "variable not uniquely qualified" is
not at least a minor error on your compiler, and you don't check for it
in your compiles, you can really get yourself messed up.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2004-11-24, 8:55 pm

Alistair Maclean wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message news:<cnt179$5at$1@peabody.colorado.edu>...
>
>
>
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


Wouldn't you have the same problem with other group-level items? i.e.,

01 var1.
12 var1-a pic x.
12 var1-b pic x.

01 var2 pic xx.

move var1 to var2.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Warren Simmons

2004-11-27, 3:55 am

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

Alistair Maclean

2004-11-29, 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-29, 3: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
LX-i

2004-11-29, 3:55 pm

Alistair Maclean wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message news:<cnt179$5at$1@peabody.colorado.edu>...
>
>
>
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


Wouldn't you have the same problem with other group-level items? i.e.,

01 var1.
12 var1-a pic x.
12 var1-b pic x.

01 var2 pic xx.

move var1 to var2.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Howard Brazee

2004-11-29, 3: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?
Alistair Maclean

2004-11-29, 3:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message news:<cnt179$5at$1@peabody.colorado.edu>...
> 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?


Move corresponding does not explicitly reference the subject fields
and therefore a program suite which parses the code and extracts
fields referenced by line will not explicitly pick up on the
implicitly referenced fields.
Esmond Pitt

2004-11-29, 3:55 pm

Alistair Maclean wrote:
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


That would appear to indicate a shortcoming in the program suite ...

Howard Brazee

2004-11-29, 3:55 pm


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

>
> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


So the move corresponding works fine. The cross-referencing fails.
Richard

2004-11-29, 3:55 pm

alistair@ld50macca.demon.co.uk (Alistair Maclean) wrote

> Move corresponding does not explicitly reference the subject fields
> and therefore a program suite which parses the code and extracts
> fields referenced by line will not explicitly pick up on the
> implicitly referenced fields.


Nor would a group move.
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com