Re: Closed file system was Re: END-IF

On Mon, 13 Jun 2005 01:28:25 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxx> wrote:

>
>"Frederico Fonseca" <real-email-in-msg-spam@xxxxxxxxx> wrote in message
>news:bt1oa150q1a8jmuu7l8kirlidkpa656agl@xxxxxxxxxx
>> On Sun, 12 Jun 2005 20:14:36 +1200, "Pete Dashwood"
>> <dashwood@xxxxxxxxxxxxxx> wrote:
>>
>> >
>> >"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.
>> Yes it does.
>> iSeries (AS400) files are available to everyone with access
>> (permissions) to them.
>> Although it is possible for COBOL programs to use ONE different type
>> of files, I have never seen any AS400 shop where they did that.
>> So in fact all INDEXED/RELATIVE/SEQUENTIAL iSeries files are available
>> to everyone either directly on the system (through SQL or through
>> Query/400) or through any ODBC compliant software, some as with any
>> other RDBMS
>>
>>
>>
>> > 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.
>> This may be a company policy, as doing ad-hoc queries on the server
>> can cause undue performance issues, as many users will not be aware of
>> ways to improve query speed.
>>
>> >Neither can he export data from same, to the COBOL file system, without
>programming
>> >being required.
>> I would NEVER, NEVER allow a user to do this. It could/would really
>> screw up data consistency.
>>
>> and now with Sarbanes-Oxley it is really a NO-NO.
>>
>>
>>
>> >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...;-)
>>
>> With "normal" cobol files you can do that also as long as you have the
>> correct tools.
>>
>> As you may be aware many users out there use Crystal Reports and
>> similar products to create their reports.
>> CR can access files from at least 4 brands of COBOL that I know of.
>>
>> over 12 years ago I used another tool that would allow users to create
>> reports on the fly, character mode so it would work on Unix machines.
>> All my several customers used it to allow their users the possibility
>> of creating their own reports.
>>
>> So I fail to see how is it that COBOL files are "closed" and RDBMS are
>> open in comparison.
>>
>Yes, you do. (At least as far as I intended the term to go...)
>
>I believe you have missed the point entirely, but that is probably my fault.
>I didn't spell out what I wanted to say, very well.
>
>It really doesn't matter. I can agree that with modern tools, COBOL file
>systems are much more open than they were. Crystal reports is an excellent
>tool and I've used it in several places. Good ODBC drivers CAN access
>'COBOL' files. But all of this is 'recent' in the scheme of things COBOL.
>Had it all been available 30 years ago, I believe COBOL would be in better
>shape than it is.
>
>My point was that the closed nature of COBOL was a contributing factor to
>its continuing demise. I believe this from what I have observed in various
>places, and conversations with managers, DBAs, and Business sponsors. It
>certainly wasn't the ONLY factor, but it definitely contributed.
>
>Today I use RDBMS exclusively. And I'm not the only one...

30 years ago there was no RDBMS and online access was expensive. The
process of making information available to end users has been an
ongoing struggle complete with conflicting requirements, constraints
and technical issues. The difference between an RDBMS and the
standard COBOL file system is that to use the latter, a tool with
knowledge of the contents of the files is needed (has access to COBOL
descriptions, its own dictionary etc.) while an RDBMS provides access
to field level descriptions.

30 years ago we didn't know nearly as much about the different types
of data as we do today. COBOL has been slow to pick up on some of
this and all too often shop rules and approaches reflect constraints
that are no longer there. We also are the victims of having picked
approaches that got the job done but now constrain us when we need to
get it done better. We are victims of the treating of help and
documentation as a frill rather than a vital necessity.

On Unix, Windows and related systems I would use the RDBMS for all
online accessible data excluding true sequential files and other cases
where RDBMS doesn't work. On older mainframe environments, I would
investigate the tradeoffs in cost, access speed (both transaction and
query) between converting from indexed files / relative files / other
data base forms to an RDBMS and providing ODBC access.

One of the many advantages of an RDBMS is that the DBA can provide
many views of the same underlying table and restrict access at the
column (field) level. It turns out that a priesthood is still needed
as intermediary but that priesthood includes the DBAs and the security
folks.

As a presumably professional programmer (40 years in applications and
systems programming), I have struggled with many systems to understand
the data and interrelationships. As a systems programmer (installer
and modifier of the operating system and related components) I would
have liked to have had independent testing of the JES exits I wrote.
Thus I think that organizations need to look carefully at their
programming practices for both IT staff and non-IT staff. In this
field we have all too often done sketchy analysis and inadequate
verification. I am not claiming that only IT people can program
because I have seen very sophisticated things done in Word Perfect
macros by secretaries and there are people who can get very
sophisticated things done in spreadsheets. The problem is that all
too often we stop when the answers look right and don't test boundary
conditions. The advantage of having to use a programmer as
intermediary is that if the programmer or analyst is good, questions
will be asked to make certain the problem or request is fully
understood. The disadvantage is that it can lead to bottlenecking and
misunderstandings.

I also believe that the power of RDBMS may be dangerous unless
properly set up by the Data Base Administrators and Data
Administrators. Misleading or cryptic column names can lead people
down wrong paths. There is also the problem that various parts of an
organization can use the same term to mean different things or
different terms to mean the same thing. Try getting a consistent
definition of a sale or something that is a reduction to sales. In
the United States the Sarbanes Oxley law may force companies to
undertake the effort for having consistent terminology throughout the
corporation but I won't hold my breath. I know one company has a task
force to get standard meanings of terms and a senior vice-president
with the power to force agreement on the meaning of terms where there
are inter-departmental disputes.

Actually I think that organizations will find they need a
multidisciplinary approach to the installing, fixing and modifying of
systems. While getting the processing right is difficult, other
possibly more difficult tasks have been overlooked. First, people
have to be able to determining what the system does and the
implications of actions. That means the implementing and the
modifying staffs should have people who how to write error messages,
help screens, tutorial and manuals so that six months later some poor
soul can figure out how to use function 32. There should be adequate
testing and simulation capability. Given the far reaching effects of
legislation such as the Personal Information Protection of Electronic
Data Act in Canada, security people should be reviewing the system and
the information retention. It can be as important to make certain
users can't ask certain questions or get certain reports as making
certain they can.

Frankly I see the need for programmers diminishing because we can
afford the CPU cycles, disk space and I-O bandwidth that good
customizable generalized packages require. The benefits of getting
something that is designed to handle requirements like Sarbanes Oxley
or PIPEDA are enormous. It is difficult enough to understand internal
needs let alone the meeting of the requirements of far-reaching
legislation. This does not diminish the need for an Information
Technology department. It does mean that we have to understand that
the purpose of information technology is so that an organization knows
what is doing and can use the information it has to control what it
does. This means that human factors people are probably at least as
important as the technical people. Writers and people who understand
library science should be added to the mix. It means that someone has
to have an overall idea what the company is going to do and how. I
see not so much the elimination of the priesthood but the expansion of
it and the growing understanding that its role is to enable the
components of an organization to communicate and work together. The
priesthood exists to provide tools that promote understanding and the
ability to act within the legal and ethical constraints on the
organization.

>
>Pete.
>
>

.