utility to read cobol data files?

Hello,
does it egzist?
I need to read some data from files generated by program in Cobol.
I don't know structure of data files.
Pleas, it's urgent.
Tnx.

"John Smith" <hard.ware@gmx.net> wrote in message
news:cpp5fu$om4$1@fegnews.vip.hr...
> Hello,
> does it egzist?
> I need to read some data from files generated by program in Cobol.
> I don't know structure of data files.
> Pleas, it's urgent.

If you do not  know the structure of the data files, the answer is, no, no
such utility exists. And that's not only true if the files are created by a
COBOL program, it's true all the time.

Best you can do is dig out a hex editor/viewer and try to figure out what
the data mean.

MCM

thank you

"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:btYvd.5851$%s7.1335@newssvr31.news.prodigy.com...
> "John Smith" <hard.ware@gmx.net> wrote in message
> news:cpp5fu$om4$1@fegnews.vip.hr... 
>
> If you do not  know the structure of the data files, the answer is, no, no
> such utility exists. And that's not only true if the files are created by
a
> COBOL program, it's true all the time.
>
> Best you can do is dig out a hex editor/viewer and try to figure out what
> the data mean.
>
> MCM
>
>
>
>

"Michael Mattias" <michael.mattias@gte.net> wrote in message
news:btYvd.5851$%s7.1335@newssvr31.news.prodigy.com...
> "John Smith" <hard.ware@gmx.net> wrote in message
> news:cpp5fu$om4$1@fegnews.vip.hr... 
>
> If you do not  know the structure of the data files, the answer is, no, no
> such utility exists. And that's not only true if the files are created by
> a
> COBOL program, it's true all the time.

Actually, have a look at this:
http://www.siber.com/sct/datafile/data-viewer.html

It has a "guess the layout" feature.

Tom Morrison wrote:

>Actually, have a look at this:
>http://www.siber.com/sct/datafile/data-viewer.html
>
>It has a "guess the layout" feature.
>
>
>
Looks interesting Tom. But as we all now recognize the different formats
have been a pain in the butt. Just out of curiosity, history, although
you may only have been young, bright-eyed and bushy-tailed at the time.

As you indicated quite some while back RM was into a whole bunch of
compilers. I think about the same time Micro Focus was also active,
although I was unaware of the name. From reading Pete appears there was
a very simple sub-set for file handling in say 1960-ish, so possibly
what we now know as ISAM, Relative and Sequential were firmed up in
COBOL '74. Then the dreaded phrase 'implementer defined' was introduced
- each to his own - "This is how my internal file structures and
indexing work, (but I ain't gonna tell you exactly)".

Way back when, RM was very much involved in the Standards process. To
your knowledge, was there ever an attempt to go beyond the broad
definition of COBOL file handling, i.e., the access VERBS and come up
with a common format, or was it a case of, "No way !  We want to retain
our customers, thank you very much". If the latter was even considered,
did our friends at Big Blue screw it up - wouldn't be the first time,
from what has been related to me.

Jimmy

"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:MZ3wd.526767$%k.136426@pd7tw2no...
[snip]
> Way back when, RM was very much involved in the Standards process. To your
> knowledge, was there ever an attempt to go beyond the broad definition of
> COBOL file handling, i.e., the access VERBS and come up with a common
> format, or was it a case of, "No way !  We want to retain our customers,
> thank you very much". If the latter was even considered, did our friends
> at Big Blue screw it up - wouldn't be the first time, from what has been
> related to me.

Jimmy,

I personally was never on the COBOL committee except as an alternate that
never attended a meeting (I did serve on X3S34, though).

I don't think that there could have been too much progress on common
formats, etc.  This would have been considered 'specification' which was not
the business of the committee.  The work product was 'standardization' and
not 'specification.'  And, true enough, anything beyond that would most
likely have been too contrary to the corporate goals of the committee
members' employers.

So...that being the case, the behavior of the file system was described (and
it has served us very well) and the vendors are left to there own devices.
Some chose to license existing technology (C-ISAM, e.g.) and some chose to
build their own.  Most of the work in the mid-1980s used B+ trees as
described in Knuth, since it was (relatively) easy to do garbage collection
on unused space.  RM completely reimplemented its file system to improve
performance and meet the emerging demands of the mircoprocessor-based
revolution.  We provided conversion utilities for our customers (to assist
the upgrade), but there was really no tremendous proprietary advantage.
Liant has adaptors for several of the popular file systems that provide
'properly behaved' COBOL I/O, and we of course publish Relativity which
provides SQL (ODBC) access to these files (thereby opening up the data, as
it were) for RM files and for those of a large competitor.

And, of course, Siber and others (Data Junction) have reverse engineered or
licensed mechanisms to gain access to the data as well.

Best regards,
Tom Morrison
Liant Software Corporation

Tom Morrison wrote:

>"James J. Gavan" <
>
Top Post : Again Tom, many thanks.

Jimmy

>jjgavan@shaw.ca> wrote in message
>news:MZ3wd.526767$%k.136426@pd7tw2no...
>[snip]
>
> 
>
>Jimmy,
>
>I personally was never on the COBOL committee except as an alternate that
>never attended a meeting (I did serve on X3S34, though).
>
>I don't think that there could have been too much progress on common
>formats, etc.  This would have been considered 'specification' which was no
t
>the business of the committee.  The work product was 'standardization' and
>not 'specification.'  And, true enough, anything beyond that would most
>likely have been too contrary to the corporate goals of the committee
>members' employers.
>
>So...that being the case, the behavior of the file system was described (an
d
>it has served us very well) and the vendors are left to there own devices.
>Some chose to license existing technology (C-ISAM, e.g.) and some chose to
>build their own.  Most of the work in the mid-1980s used B+ trees as
>described in Knuth, since it was (relatively) easy to do garbage collection
>on unused space.  RM completely reimplemented its file system to improve
>performance and meet the emerging demands of the mircoprocessor-based
>revolution.  We provided conversion utilities for our customers (to assist
>the upgrade), but there was really no tremendous proprietary advantage.
>Liant has adaptors for several of the popular file systems that provide
>'properly behaved' COBOL I/O, and we of course publish Relativity which
>provides SQL (ODBC) access to these files (thereby opening up the data, as
>it were) for RM files and for those of a large competitor.
>
>And, of course, Siber and others (Data Junction) have reverse engineered or
>licensed mechanisms to gain access to the data as well.
>
>Best regards,
>Tom Morrison
>Liant Software Corporation
>
>
>
>