Re: I need help!!

Pete Dashwood wrote:
<Starkey2600@xxxxxxxxx> wrote in message
news:1181933898.182569.271260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hey everyone, I'm having issues trying to pull data from a fixed
length binary file from a COBOL program that was written a long, long
time ago. I have the source file, I have the data file, I found which
actual "program" writes to the binary file, I opened the source for
that program and found what appears to be copybook data. I've been
trying to use the java based record editor program on sourceforge to
extract the data, but as of now I'm so lost. Could someone please
help me out?

Here is a piece of the source file containing what I think is copybook
info.

000010 IDENTIFICATION DIVISION.
000040 PROGRAM-ID. PRD009SR.


You are trying to edit an indexed sequential file directly. Even WITHOUT
packed fields, this is not something you want to do for fun...

000310 SOURCE-COMPUTER. RMC.
000340 OBJECT-COMPUTER. RMC.

What is this, exactly? Is it a PC, mid-range, mainframe, can you give us the
make and model? Do you know what particalur Indexed Sequential software has
been used to create your file? (Is it PC ISAM, Mainframe VSAM/KSDS, what?)

Most COBOL environments have utilities available to create standard
sequential datasets from Indexed Sequential files. Do you have anything like
this?

Try and get the file into a more amenable format. The indexed file will
contain free space, space management fields, all kinds of stuff that just
muddies the water. Editing (even in "read only" mode) the actual dataset is
a last resort.

If you can get it into a simpler sequential format, you may have more
success editing it, but you will still have to deal with the packed fields.
(This can be done with Java or COBOL, see below.)

If you really can't convert it to a simpler format with a utility, do you
have a COBOL compiler available?

If you have:

1. Write a small COBOL program to convert all the packed fields to display.

It's very easy. Just copy the source you have at the moment, and add a
sequential dataset that is the same as the definition above, but with all
the COMP-3 clauses removed. In the procedure division, open the existing
file for input, and the new one for output, then read sequentially through
the Indexed file, moving each record read, FIELD BY FIELD to the output
record area and writing it. The end result will be a copy of your indexed
file that has all the packed fields converted to display.

2. Edit the new sequential "unpacked" version.

(Another possibility you could consider, if you have COBOL available, is to
amend the program which creates the Indexed file so that it simultaneously
creates an "unpacked" version which can be edited with normal tools.)

Really, it is time this system was converted to a database... The data can
then be easily passed and extracted by standard tools. Given it was written
in 1984, it should be a prime candidate for replacement. While it's all very
well saying "If it ain't broke, don't fix it..." the fact is that data from
it is required elsewhere, otherwise you wouldn't be undertaking this
exercise... to this extent, it IS broke...

If you DON'T have a COBOL compiler available you should still try and get
the file into a sequential version (with a Utility, as mentioned above). You
can then read it as a stream in Java and use one of the Java packages
available to deal with the packed fields. Have a look at:
http://benjaminjwhite.name/zdecimal/doc/name/benjaminjwhite/zdecimal/PackDec.html

BOTTOM LINE:

1. If you have a COBOL compiler that can compile the existing source, you
should create an unpacked version. I would also look at converting the
master file to RDB and converting the Indexed file access to SQL (even to
<shudder> embedded SQL in the COBOL...) I know that's easy for me to say, I
have tools to do it... (I'm happy to make them available to others, or do
the conversion for them, for a reasonable price...). The use of indexed
files is simply locking the data resource into COBOL and sooner or later the
bullet will have to be bitten. Conversion to RDB extends the useful life of
the existing system without requiring a rewrite or replacement, and keeping
the current logic. It simply opens up the data resource.

2. If you have to extract data from it in Java, you are in for a very hard
time. The cost of doing this now and in the future should be weighed against
the cost of replacing it with something more amenable.
(Personally, I would make a case to Management that they either obtain a
COBOL compiler for it, or replace the system, given that the data in it is
required elsewhere. Even if they go for replacement, the existing master
file is problematic. The data on it has to be extracted and converted to the
new system (hopefully) database.)

Frankly, if you don't have a COBOL compiler for this, you are pretty
screwed. Under those circumstances, I would be looking at a ONE TIME extract
from the master file, and I can't see people forming a line to do it...:-)

Pete.







Was searching the internet for my domain name and found your reference
to my Java Decimal package. I was surprised when IBM made a point to
give us a week long presentation about using Java on Z/Series and the
Red Book about Java on the mainframe asked us to write our own routines
to handle packed and zoned decimal in Java.

Do you think my Java decimal package will help more people use Java on
the mainframe or help convert old packed decimal data and systems off
the mainframe to non-IBM platforms?
.

Relevant Pages

  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol is far from OO. ... many printers and page format as need at any time. ...
    (comp.lang.cobol)
  • Re: I need help!!
    ... trying to use the java based record editor program on sourceforge to ... Most COBOL environments have utilities available to create standard ... Write a small COBOL program to convert all the packed fields to ... Do you think my Java decimal package will help more people use Java on ...
    (comp.lang.cobol)
  • Re: I need help!!
    ... Most COBOL environments have utilities available to create standard ... but you will still have to deal with the packed fields. ... If you DON'T have a COBOL compiler available you should still try and get ... I would also look at converting the ...
    (comp.lang.cobol)
  • Re: Believe me, you WANT to read this!
    ... This is a success story - but it is still PROMOTING Microsoft as the sloution:- ... for them to have gone in the first place, sraight from mainframe thinking into, shhh..., OO-techniques via Java. ... COBOL for the .Net ".. ... As for finding the link and wading through umpteen screens, with very discernible pauses, said "Done", the progress bar at the bottom is ...
    (comp.lang.cobol)
  • Re: Differences in data description in programming languages
    ... COBOL programs designed to create either COBOL, ... converter, JAVA. ... > longer than the languages which implement the procedural paradigm. ... > I have to be honest here: the main reason I am still using COBOL is because ...
    (comp.lang.cobol)