Crazy COBOL system, need help with cob2csv

I've just been hired at a new company, and with this new job comes a
new database system for me to update.  They now have a custom built
COBOL software running their db, as I'm not the slightest bit
accustomed to COBOL, having only been born in 83 :).

I have however been reading up quite a bit on the situation I'm in, as
it seems as if there are others in very similar ones.  However I
haven't noticed one quite like mine.  This system was built in the
early 80's and was designed and written by one man who has since passed
away.  Unfortunately it doesnt seem that this gentleman designed by the
same set of rules that most did during the "COBOL Era" as I've seen
mention of copybook files and a seperate file for the db, however, the
system I'm working with is made up of lots and lots of .CBL, files that
contain a section of the code that appears to be the copybook, and then
the source.  Then there are lots and lots of these files with no
extensions, but they appear to be binary db files, as i can make out
some of the plain text as db items.

So my question is how can I use cob2csv with this system?  Do i copy
paste the copybook section into a seperate file?

Please, Please Help!!!

Starkey2600@gmail.com wrote:
> I've just been hired at a new company,

> Unfortunately it doesnt seem that this gentleman designed by the
> same set of rules that most did during the "COBOL Era" as I've seen
> mention of copybook files and a seperate file for the db, however, the
> system I'm working with is made up of lots and lots of .CBL, files that
> contain a section of the code that appears to be the copybook, and then
> the source.  Then there are lots and lots of these files with no
> extensions, but they appear to be binary db files, as i can make out
> some of the plain text as db items.
>
> So my question is how can I use cob2csv with this system?  Do i copy
> paste the copybook section into a seperate file?
>

cob2csv was written (assuming that it is the same program) by Robert
Wagner. He may (possibly) be contactable on robert@wagner.net. My
understanding of the source (after spending a whopping 5 minutes
looking at it) is that you use a cbl file copybook tagged with the cpy
suffix as an input file to the program. It will interpret the FD and
use it as a guide for the program.

Cob2csv is written in MicroFocus Cobol but should be easily converted
to any other brand of Cobol. Robert Wagner posted the following:

<QUOTE>

You'll probably have to read it with a Cobol program compiled with MF
or a MF file tooll. If you still have access to the MS compiler or a
more recent MF compiler, cob2csv I posted here some months ago will do
the job. You'll need a Cobol copybook (include file) describing the
record layout.

IDX is an index you probably don't need. IND is the data you want. Try
editing the IND with a text editor; do the records line up? In the
unlikely event they do, it's C-ISAM and you might be able to read it
as ASCII text.

</QUOTE>

Within the code he wrote:

<QUOTE 2>
*              Convert Cobol file to comma or tab delimited
*
* This program interprets a Cobol copybook describing a record layout,
* then converts the file to either csv or tsv (comma or tab delimited).

*
* This program would best be used by the organization sending the file,

* because it has a Cobol compiler and could better deal with
* ideisyncrasies in its file system. When used by the organization
* receiving the file, the program need be compiled only once. The
* executable will convert all files.
*
* This program also provides a simple demo of how to parse
* and interpret source code.
*
* Copybook file: cob2csv.cpy              **!!!!!!!****
* Input data file: cob2csv.in
* Output data file: cob2csv.out
* Environment variable: delimiter=tab (default is comma)
*   This program filters out data characters matching the delimiter.
* Supported formats: string, display numeric, binary and packed
decimal,
* simple OCCURS. REDEFINES is ignored, the first definition is used.
* Not supported: editing pictures, scaling, OCCURS at group level,
* OCCURS DEPENDING ON.
*
* If your machine is big-endian (a PC) or 32-bit, required changes
* are in comments below.

</QUOTE 2>

I tagged one line above with **!!!!!!**** (DD, could you check the
number of exclamation marks for me?) as this is where RW identifies the
copybook.

In article <1155839297.615540.192100@b28g2000cwb.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:

[snip]

>* Copybook file: cob2csv.cpy              **!!!!!!!****

[snip]

>I tagged one line above with **!!!!!!**** (DD, could you check the
>number of exclamation marks for me?) as this is where RW identifies the
>copybook.

Please do your own check-work.

DD

Thanks, that is a start. So what your saying is that i could just
rename the files that i have ( the ones with the copybook info) to have
a .cpy extension and then use them as the input files?
Alistair wrote:
> Starkey2600@gmail.com wrote: 
> 
>
> cob2csv was written (assuming that it is the same program) by Robert
> Wagner. He may (possibly) be contactable on robert@wagner.net. My
> understanding of the source (after spending a whopping 5 minutes
> looking at it) is that you use a cbl file copybook tagged with the cpy
> suffix as an input file to the program. It will interpret the FD and
> use it as a guide for the program.
>
> Cob2csv is written in MicroFocus Cobol but should be easily converted
> to any other brand of Cobol. Robert Wagner posted the following:
>
> <QUOTE>
>
> You'll probably have to read it with a Cobol program compiled with MF
> or a MF file tooll. If you still have access to the MS compiler or a
> more recent MF compiler, cob2csv I posted here some months ago will do
> the job. You'll need a Cobol copybook (include file) describing the
> record layout.
>
> IDX is an index you probably don't need. IND is the data you want. Try
> editing the IND with a text editor; do the records line up? In the
> unlikely event they do, it's C-ISAM and you might be able to read it
> as ASCII text.
>
> </QUOTE>
>
> Within the code he wrote:
>
> <QUOTE 2>
> *              Convert Cobol file to comma or tab delimited
> *
> * This program interprets a Cobol copybook describing a record layout,
> * then converts the file to either csv or tsv (comma or tab delimited).
>
> *
> * This program would best be used by the organization sending the file,
>
> * because it has a Cobol compiler and could better deal with
> * ideisyncrasies in its file system. When used by the organization
> * receiving the file, the program need be compiled only once. The
> * executable will convert all files.
> *
> * This program also provides a simple demo of how to parse
> * and interpret source code.
> *
> * Copybook file: cob2csv.cpy              **!!!!!!!****
> * Input data file: cob2csv.in
> * Output data file: cob2csv.out
> * Environment variable: delimiter=tab (default is comma)
> *   This program filters out data characters matching the delimiter.
> * Supported formats: string, display numeric, binary and packed
> decimal,
> * simple OCCURS. REDEFINES is ignored, the first definition is used.
> * Not supported: editing pictures, scaling, OCCURS at group level,
> * OCCURS DEPENDING ON.
> *
> * If your machine is big-endian (a PC) or 32-bit, required changes
> * are in comments below.
>
> </QUOTE 2>
>
> I tagged one line above with **!!!!!!**** (DD, could you check the
> number of exclamation marks for me?) as this is where RW identifies the
> copybook.

Starkey2600@gmail.com wrote:
> Thanks, that is a start. So what your saying is that i could just
> rename the files that i have ( the ones with the copybook info) to have
> a .cpy extension and then use them as the input files?

Errm, at the risk of commiting myself, I would guess that what you need
to do (after carefully reading the source comments and the emails in
this newsgroup written by RW himself - searchable under Google groups)
is:

1.  Rename the source code FD copybook as a .cpy member.
2.  Compile the source code that is called cob2csv.
3.  Execute the compiled code using the cpy copybook as an input file.
4.  Start worrying about that niggling doubt that sits in the back of
my mind about the
cob2csv program being the first of two steps (see the emails in
this group by RW).
5.  Wonder why the code doesn't work. I may be maligning RW but I think
there may
have been some discussion about errors in the code. Check the
emails by RW.


> Alistair wrote: 

I forgot to add this bit:

I am based in the UK but would love an all expenses paid holiday in the
US to fix it for you.

Hehe, thanks a lot for your input.  If i had the finances to do so, at
this point i'd make it happen ;)  This system is driving me crazy.
Alistair wrote:
> I forgot to add this bit:
>
> I am based in the UK but would love an all expenses paid holiday in the
> US to fix it for you.

Guys and Gals, if there is anyone out there that can help me out a bit,
i would so appreciate it.  I have the source, i have the binary
datafiles, but i don't have copybooks, please, please help.
Starkey2600@gmail.com wrote:
> Hehe, thanks a lot for your input.  If i had the finances to do so, at
> this point i'd make it happen ;)  This system is driving me crazy.
> Alistair wrote: 

Starkey2600@gmail.com wrote:

> Guys and Gals, if there is anyone out there that can help me out a bit,
> i would so appreciate it.  I have the source, i have the binary
> datafiles, but i don't have copybooks, please, please help.

I suspect that the problem is that you don't know what a 'copybook' is
or should be.

A 'copybook' is simply a text file that contains a fragment of source
code. Any program that needs to use that code simply has to put '
COPY filename.' into the program source and it is copied in at that
point.  In modern copilers (last quarter century) this can be done
almost anywhere for any code.  In ancient compilers it was limited as
to what may be COPYed.

Typically copybooks are used where the same code is used in several
programs, such as file record layouts which are commonly accessed.
This means that if a file is changed it is usually only necessary to
change the code once and then recompile all that use it.

If your programs are coded as:

FD  somefile.
COPY somerecord

then you already have the necessary copybooks, 'somerecord' is one of
them.

If your programs are written as:

FD  somefile.
01   somerecord.
03  somekey ...
..

Then is is only necessary to edit the souce to make the record layout
(everything until the next FD or end of section) to a separate file and
replace it with COPY filename so that it is copied back by the
compiler.

If you have neither of these.  ie the programs have COPY file but there
is nothing that relates to 'file' then you are screwed.  The programs
won't recompile and you will never know how the files are layed out.

If you think that this is the case yet the programs do compile OK then
you just haven't found where the copybooks are.  There may be a
compiler option to specify that the copybooks may be found in a
different directory, or may be in a 'library', or may have a file
extension added by the compiler.  So '   COPYmsrec.' or '   COPY
"msrec".' may in fact be reading 'include/msrec.cpy'.

Starkey2600@gmail.com wrote:
> Guys and Gals, if there is anyone out there that can help me out a bit,
> i would so appreciate it.  I have the source, i have the binary
> datafiles, but i don't have copybooks, please, please help.
> Starkey2600@gmail.com wrote:
> 
>
>
I haven't been following this thread, but you are in BIG TROUBLE - you
need those copybooks. New to COBOL, and so that you are quite clear, if
copybooks have been used then the deceased programmer's programs should
look somewhat similar to the the following example.

Copybook1.
*>------------------------------------------
FILE-CONTROL.

Select               Customer-File
assign               ws-Customer-Filename (or hard coded)
organization         indexed
access               dynamic
record key           Cus-PrimeKey
file status          ws-FileStatus.
*>-----------------------------------------------


Copybook2.
*>--------------------------------------------
01 CUS-Record.
05 Cus-PrimeKey			pic x(06).
05 Cus-Details.
10 Cus-Name			pic x(40).
10 Cus-AddressLine1		pic x(30).
10 Cus-AddressLine2		pic x(30).
10 Cus-City			pic
10 Cus-State			pic
10 Cus-Zipcode			pic
05 Cus-LastTransactionDate		pic 9(08).  *> ccyymmdd
05 Cus-CurrentBalance		pic s9(06)v9(02) comp-3.

*>-------------------------------------------------------------

Depending upon your compiler you should see :-

FILE-CONTROL.

copy "copybook1.cpy".

FD.

copy "copybook2.cpy".

------------------------------------------------------------------------

1. DATA CONVERTERS :

Now first port 'o call. There used to be a couple of COBOLers here who
advertised data file conversions. So firstly check Bill Klein's COBOL
FAQ to see if he references the topic. If not Bill maybe able to recall
who they were. Obviously it will cost you, but if it works, will save a
lot of aggravation.

2. SHERLOCK HOLMES.

#1 is unsuccessful SO you have to go at it 'brute force and ignorance' -
change that to 'brute force and accumulated intelligence' :-).

You have the source - you don't know how lucky you are ! Most folks in
your situation have neither copybooks nor source. Take a look at any
programs that print reports or display screen information, or even
update files - you should see fields being moved prior to
printing/displaying.

so if you see : MOVE CUS-CurrentBalance TO WS-BALANCE and in Working
storage you see :-

01 ws-BALANCE  -9,999,999.99

- this gives you an indicator that CUS-CurrentBalnace fits into nine
characters - but that doesn't mean it is 'nine' but the 'signed eight
characters' I show above. Nor is it telling you that the field is
comp-3. Unlikely, rather than packing he (the deceased), could have
specified the field as :-

05 Cus-CurrentBalance		pic s9(06)v9(02).

which allows for -999,999.99. (one penny shy of a million)

Are you already  ?

Given that you have a tool that can display files in 'raw format', where
any fields which are packed/binary will show up as Egyptian
hieroglyphics, take consolation in the fact that alphabetics pic x(???)
will be readable - you may be able to figure where the 'numerics' are
but not exactly their formats.

Above is arduous to say the least and is still hit and miss to find any
quirks.

3. BIG BANG APPROACH :

Nothing else works BUT you must have the info from the files. Print out
EVERY report to get the latest information plus monetary control totals.
Get ready for it - now write fresh programs where you input the printed
data into file records designed by yourself.

#3 doesn't look the least bit enticing does it ? Sometimes it has to be
that way. Prior to getting into Systems Analysis back in '63 I worked
for a UK dairy company where three companies were merged locating
Accounts Receivable in one location. Thank God I wasn't involved - and
I'm talking a MANUAL Sales Ledger. The merge of the three A/Rs was a
complete cock-up and we were owed £32 million. Lots of wacky suggestions
as to how to overcome the problem. The trouble-shooter put in charge of
the problem noted them all, and with a grim look on his face said, "We
will strike fresh balances for each customer starting at '63 June 01.
Meanwhile a team of six will concentrate on the backlog owed to us
working their way forward". Took about six months but the £32 million
was whittled down to less than £0.5 million.

++++ Go googling and keep plugging away at tools that will convert files
for you, if available - when asking don't confuse with the term 'DB'
(makes people think of SQL, (R)DBMS), tell them they are COBOL files
ISAM, Relative, Sequential or Line Sequential, as appropriate.

Jimmy