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

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
>
>
>
>

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
>
>
>
>

James J. Gavan wrote:

> Tom Morrison wrote:
> 
> 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.

On the mainframes where an indexed file was a part of the operating
environment, provision of a COBOL-specific indexed file would have been
counter-productive.  VSAM KSDS (key sequenced data sets) are available
to all of the languages and a host of utilities.  I am fairly certain
the same is true of Unisys and its predecessors.  I have no idea as to
what the situation is for the various contingents (DEC, Tandem, etc.) of
HP.  If Microfocus or other vendors had developed a compiler for the
environments I mentioned they would have used the existing file system
just as Dylakor and Easytrieve did with their 4th generation (report
writing) languages.
>
> Jimmy

> If Microfocus or other vendors had developed a compiler for the
> environments I mentioned they would have used the existing file
system

When MicroFocus CIS Cobol was developed for the ICL DRS20 system they
did indeed using the existing DRX File System for Indexed and Relative
(DSAM) files.  These could then be shared with the other languages on
that system.
For Unix MF adopted C-ISAM which was defined in the X-Open standard.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1104718419.834884.115440@c13g2000cwb.googlegroups.com...
> For Unix MF adopted C-ISAM which was defined in the X-Open standard.

Actually, it would be more accurate to say, "which was adopted by X-Open."