COBOL COPYBOOK CONVERTER

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.

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 MANUALL
Y
create the output copybook (telling which files to keep) and then have a COB
OL
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 com
pile
the COBOL program and then run it would also be easy.

If, however, you want a COBOL program to CREATE the output copybook, then  h
ow
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.

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.

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 decima
l
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).

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)

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:<nBend.3235102$yk.5011
38@news.easynews.com>...
> 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 copy
book
> (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 JC
L
> stream.
>
> 1) Step 1
>   Copy input and output copybooks from "individual" names to some common n
ame
> (in a PDS) such as
>     INPCPY
>     OUTPCPY
>
> 2) Step 2
>   Compile (probably also Step2a - link)  a simple program (using these sta
ndard
> 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 S
tep 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.)

What's the advantage of having one program handle a bunch of copybooks pulle
d 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?

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 copyb
ook
>(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 na
me
>(in a PDS) such as
>    INPCPY
>    OUTPCPY
>
>2) Step 2
>  Compile (probably also Step2a - link)  a simple program (using these stan
dard
>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 St
ep 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.

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?

..    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 Gegentei
l nachahmen. -G.C.Lichtenberg