| Clark F Morris 2007-01-11, 6:55 pm |
| On Sun, 7 Jan 2007 15:02:44 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:ra6tp2d4j8j7udbg1sdehncvn5clcub98l@
4ax.com...
>
>Not if you buy a COBOL compiler. COBOL standards require support for the
>"COBOL file system" (Not my words... check the COBOL manual :-))
Here is an interesting situation. For the mainframes I mentioned, the
COBOL file system was mapped to the standard file facilities and thus
was not viewed as a COBOL file system. For PCs and UNIX based
systems, the COBOL file system became an add-on. For the mainframe,
the basic FORTRAN and C style files were the oddballs (delimiter
terminated strings and arrays). The reverse is true for the PC and
UNIX systems.
>
>
>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".
The VSAM Entry Sequenced Data Set is accessible if the SELECT
statement is coded properly. There are heretics like myself who
believe that it should have been enhanced over time so that it could
supplant the QSAM (queued sequential access method) data sets, that
you should be able to concatenate ESDS and QSAM data sets and that you
shouldn't need a special SELECT statement to use them.
>
>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.
On a PC, the RDBMS is a better choice than adding a proprietary
indexed file system. However, there are interesting drawbacks. I was
surprised when testing something in DB2 on the mainframe to find that
I couldn't mix accessing production (or common test) tables in a read
only manner with the test tables I was interested in within the same
program. It seems that all of the tables have to be accessed by the
same instance of the data base subsystem. This becomes less of a
problem as DASD becomes cheaper but it still can add up if an
application requires a large number of tables. I am used to just
changing the file that the DD (data set definition?) statement points
to when I want my own copy of a file. While a RDBMS makes a number of
complex situations easier and probably is better for 99.9 percent of
the customer files, it makes simple table files where there is a key
and one or two data fields much more of a pain to handle. I suspect
that in many cases, the RDBMS has become the 40 ton truck used where a
wheelbarrow would be perfectly adequate. An RDBMS will have greater
overhead because access is not at the row level but at the column
level based on the generated call statements that I have seen. This
allows for interesting compression and other techniques to minimize
disk and in storage buffer space at the cost of long access pat
lengths. The cost can be more than justified if the suite of
applications using the data base is taking advantage of the RDBMS
capabilities as opposed to treating it is a tricky indexed file.
>
>
> :-) (I like that...)
>
>
>yeah, I know... :-) How crazy is that? (I think it is OK if you deal with
>cataloged sequential datasets... and GDSes... not sure now...)
I think that ISPF without tweaking can handle UNIX file systems if the
user has UNIX access allowed in their security system definition. VSAM
still is primarily through third party products. Of course, IBM needs
to understand that just because its first attempts at providing full
GUI workstation access received underwhelming acceptance in the field,
it is no reason to retreat from the idea of providing a good modern
IDE.
>
>Pete.
>
|