| Pete Dashwood 2007-01-06, 9:55 pm |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:ra6tp2d4j8j7udbg1sdehncvn5clcub98l@
4ax.com...
> On Tue, 2 Jan 2007 11:31:10 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> On PC and UNIX systems, indexed files and record sequential files are
> add-ons.
Not if you buy a COBOL compiler. COBOL standards require support for the
"COBOL file system" (Not my words... check the COBOL manual :-))
> On IBM mainframes and I would assume those from other
> manufacturers, what you refer to as the COBOL file system is actually
> a native file system open and available to all tools on the box in
> question.
Yes, inasmuch as VSAM is provided and many of the standard tools can take
advantage of it. COBOL just happens to use VSAM/KSDS for indexed sequential
support and VSAM/RRDS for relative addressing support. (I dont think
VSAM/ESDS is used by the COBOL file system, but I could be wrong and ESDS is
certainly accessible form COBOL if you use extensions. This may have
changed; it is around 20 years since I worked in that environment.) The
relative byte addressing provided by ESDS remains a mystery to most COBOL
programmers BECAUSE it is NOT part of the "COBOL file system".
No, inasmuch as there is no standard import and export of VSAM datasets into
formats acceptable to applications not written in COBOL, PL-1, or Assembler,
or in cross platform formats like XML or .CSV. (Again, this may have changed
and perhaps some of these things may be availabe now; if so it was really
too late... we needed it 20 years ago...:-))
Because RDBMS contain details of the structure of their data they have
ALWAYS been able to import and export structure and data into formats
accessible by virtually any application. (at the lowest level they can
export SQL information as text; MySQL does this for both structure and
content and can therefore easily be imported into any other RDBMS that
supports standard SQL. (I don't know of any that don't... :-))
The closest approximation I can think of is using IDCAMS to export the data
on a KSDS to a sequential file, but that is a long way from "open" access.
It is probably being a bit unfair to the mainframe environment to say the
file formats are not open, because there is little requirement for
"openness" on a central platform. It is only as the need for networking and
remote computing capability across different platforms becomes more
important that "exchangeability" of data becomes a consideration. My
argument was (and is...) that RDBMS supports this better than the COBOL file
system. When I first proposed this it was heresy and I was castigated in
this forum (I still remember it... :-)... I couldn't beleive the venom in
some of the posts...), since then the world has voted with its feet and few
applications DON'T use RDBMS (or Hierarchical or Network DBMS) on both
manframes and PCs.
> Indeed, on the IBM MVS / z/OS systems, COBOL doesn't take
> full advantage of the capabilities of the underlying file system and
> in some cases, assembler sub-routines are needed. Utilities
> (sometimes I called them futilities)
:-) (I like that...)
> such as sort and various copy
> programs, virtually all of the third party products such as DYL280 and
> Easytrieve, and virtually all of the languages had native access. The
> one major brain dead exception was that the interactive tool -
> TSO/ISPF steadfastly refused to recognize VSAM.
yeah, I know... :-) How crazy is that? (I think it is OK if you deal with
cataloged sequential datasets... and GDSes... not sure now...)
Pete.
|