Re: Closed file system was Re: END-IF


"Clark Morris" <cfmtech@xxxxxxxx> wrote in message
news:m1cma11c73gm53o7s2sieb4kii31sp8pdj@xxxxxxxxxx
> On Sat, 11 Jun 2005 04:48:51 +1200, "Pete Dashwood"
> <dashwood@xxxxxxxxxxxxxx> wrote:
>
> >> much snipped
> >
> >Hahaha! That same nice file system was one of the major nails in COBOL's
> >coffin... It is closed. You can't get at information without writing a
> >COBOL program. In modern environments where data has to be shared easily,
> >and flies around the network getting updated, having data in repositories
> >that can't be accessed with standard tools, like spreadsheets and local
> >databases, is just unaceptable. By the time ODBC drivers became available
it
> >was too late...
>
> It depends entirely on the environment as to whether the "COBOL" file
> system is closed.

No, it doesn't. If you can't get to the data without writing a COBOL
program, it is closed. If you need a programmer to use utilities like
EasyTrieve to get it for you, it is closed. The point is that it is closed
to the Business if they need to request a report from IT. A Business user
cannot simply import data to his spread *** or local database. Neither can
he export data from same, to the COBOL file system, without programming
being required. With a RDBMS he can. Given the right permissions, data can
be easily exchanged and shared across the Business, with little or no
intervention from IT.

That is what I meant by 'closed'... The repository may well be 'open' to
people with access and programming knowledge, but it is 'closed' to everyone
else. When some managers I knew realised that they didn't need to request
reports from IT if they opted for RDBMS, it was amazing how quickly they
found the money...;-)

> In the IBM mainframe (z/OS and VSE) environments
> and I would assume the IBM i-series (was AS400), UNISYS mainframe and
> similar environments the COBOL file system is and was the file system
> provided by the operating system. The report generators, system
> utilities for file print and copy, etc. all know how to deal with any
> file that a COBOL program can create with its I-O verbs.

Yes, I agree that these physical organisations properly belong to the OS,
rather than to COBOL or other languages. Nevertheless, the COBOL language
has modules that document Access Methods and file Organizations which are
based on the use of OS file organizations that apply to the particular
environment where the compiler is running. Before 1983 there wasn't much
alternative. Now there is.

> The flavors
> of Unix and Windows are what caused the problem because they didn't
> and don't have built in record oriented sequential files and indexed
> files.

Er... what is the 'problem' exactly? If you don't use the COBOL file system
there IS no problem.

> Since sequential files really are only good for transferring
> data in a batch mode and not designed for querying they weren't as
> much of a problem. The increased CPU and memory power of the 1990's,
> especially on the UNIX and PC platforms made the inherent increased
> costs of a relational database over an indexed file irrelevant so that
> the former could be used in circumstances where all you needed was an
> indexed file.
>

Sure, now you had a choice; previously, you didn't. The difference is that
with the RDBMS choice, all of your data is freely transportable. Across
platforms and departments. It is 'open' for business.


> Having used both and having been in a Unix shop where Oracle was used
> in place of indexed files (rightly so since the alternative was adding
> a proprietary indexed file system), the RDMS offers far greater
> visibility to the file contents but has interesting testing and
> performance considerations.
>

LOL! I like your use of 'interesting'...and you are right, of course. It is
also 'interesting' that as computer literacy grows amongst (primarily) young
people, the number of people with enough knowledge of SQL to get what they
want from a Corporate database is rising. On one project I did in the UK thi
s century, there were more Computer Science graduates in the Business (which
was not directly computer related) than there were in the whole of the IT
department. It was challenging and fun to work with them. They didn't know
COBOL and would have politely refrained from laughing if you suggested they
learn it, but they showed me stuff with SQL I'd never seen before. My own IT
guys were at least equally sharp in this area, a number of them having come
originally from the Business.


> An interesting follow-on would be a discussion on code sets EBCDIC vs.
> ASCII (ISO) vs. ISO 10647 with proper subset Unicode and the long term
> effects (and costs) of moving to a "universal" encoding system. As a
> related issue, the need for semi-exact compares and handling
> culturally sensitive order rules would be useful because COBOL
> definitely is ill set up to handle these things.

You are talking about COBOL in native mode, right? NOT COBOL using ESQL?
(Obviously, the latter can do anything SQL can do...)

It would certainly be an interesting discussion to some here, and the goal
you outline is a good one.

Pete.



.

Quantcast