Re: I need help!!


"Benjamin White" <bjwhite66212@xxxxxxxxxxxxxxx> wrote in message
news:21ebb$467c5d2c$4088cc92$6090@xxxxxxxxxxxxxxxx
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.



Hi Benjamin,

thanks for dropping in to CLC :-)


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?

I think your Java Decimal package is a very useful piece of software. We get
many cries for help here from people encountering Packed and other formats
for the first time. Michael Mattias has a very good tutorial on it, that
many have found interesting: http:///www.talsystems.com

But some people can relate to it better from Java.

To answer your question:

I think your package will do both.

But you are not responsibile for the choices people make.

Whether people move off IBM platforms is subject to much more than the
openness (or otherwise)of decimal arithmetic. IBM are doing what they need
to in order to retain their current base (promoting SOA, Websphere, Java...
all good steps towards making a transition to the new paradigm. Java (on
the mainframe) certainly needs to have classes available for dealing with
the decimal formats and if IBM can get you guys to write it for them, who
can blame them :-)

It really doesn't matter what platforms people choose; there will be many
factors contributing to that particular choice.

Your package is useful because it can save people time and help them to
understand something that they may be unfamiliar with. (Some of us prefer
not to re-invent the wheel and use components for our solutions. Your Java
Package is such a component... :-))

Besides, you enjoyed writing it, right? :-)

Pete.



.

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 ... but you will still have to deal with the packed fields. ... I would also look at converting the ...
    (comp.lang.cobol)
  • Re: COBOL and Java Relative Perceived Power
    ... What does COBOL ... 003 classes for Java Support ... is referred to as implementation inheritance. ... I don't think inheritance breaks encapsulation, ...
    (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: COBOL and Java Relative Perceived Power
    ... What does COBOL have to offer that is equivalent to that, that would make me want to use COBOL instead of ... 003 classes for Java Support ... Certainly hierarchical classes were central to Smalltalk, ... Now as to my own usage I can achieve all I want from the M/F set of OO classes, bearing in mind I've never looked at Webbing etc., promising myself I would get around to it some day. ...
    (comp.lang.cobol)