On Fri, 24 Aug 2007 08:22:48 -0700, Paul Raulerson
wrote:

>>> Boy, you can say *that* again! It is also one of the reasons that
>>> COBOL is so darn expensive on UNIX or non-VMS/non-Mainframe platforms.
>>>
>>
>> By "UNIX or non-VMS/non-Mainframe" i assume you mean that they don't
>> have indexed key access data files built into the system.
>
> Pretty much. UNIX filesystems have no idea about record oriented files,
> or rather, all the files on a UNIX file size have a record size of 1
> byte.
>
> COBOL (and I assume PL/I running under UNIX has to supply a record
> oriented file system layered over the UNIX filesystem. Or they can use a
> empty DASD partition and roll their own filesystem, still has the same
> problem. Or they can use a RDMS, which internally has to solve exactly
> the same problem.

Yes, basically it is an ISAM package. On Ultrix PL/I it was sold as a
separate
product that could be bundled with applications.

>
> System that normally deal with record based file systems have a great
> advantage in terms of support for COBOL (and PL/I).
>
> -Paul
>
>
>



--
PL/I for OpenVMS
www.kednos.com

In article , "Paul Raulerson" writes:

> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
> ented file system layered over the UNIX filesystem.

As do Ada implementations.

There is a distinct problem with an operating system written by folks
who think the lowest common denominator programming language is the
only one.

In article ,
Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article , "Paul Raulerson" writes:
>
>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
>> ented file system layered over the UNIX filesystem.
>
> As do Ada implementations.
>
> There is a distinct problem with an operating system written by folks
> who think the lowest common denominator programming language is the
> only one.

Once again, don't assume your worldview is the only one. The entire
paradigm underlying Unix was "The Software Tools" paradigm in which
things are reduced to their simplest form and complexity is created
by adding layers. Thus the "pipe" concept as used by things like
troff which required other utilities like col, eqn, greek and tbl
in order to create more complex documents.

C-ISAM was around and available for Unix since at least the early to
mid 80's. I first used a database and COBOL on Unix in the mid 80's.
One advantage to the Unix paradigm is you don't end out paying for
features you neither need nor want. I have never used RMS on VMS.
explicitly. I can't think of anything I have done that actually
needed it. And don't say "you don't pay for it because it is
bundled in" because you pay for everything that comes with the system
wether it is listed on the invoice or not.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
> In article ,
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> In article , "Paul Raulerson" writes:
>>
>>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
>>> ented file system layered over the UNIX filesystem.
>>
>> As do Ada implementations.
>>
>> There is a distinct problem with an operating system written by folks
>> who think the lowest common denominator programming language is the
>> only one.

> C-ISAM was around and available for Unix since at least the early to
> mid 80's.

But never something one could always count on being there ?

> One advantage to the Unix paradigm is you don't end out paying for
> features you neither need nor want. I have never used RMS on VMS.
> explicitly. I can't think of anything I have done that actually
> needed it.

If you write all your programs with a "stream of bytes" language,
that may be the case. In my experience programs written with a
"stream of bytes" mentality are a major source of lousy software.

In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>
> I have never used RMS on VMS.
> explicitly. I can't think of anything I have done that actually
> needed it.

You only program in C,C++,Java and you never view your files on a
terminal (type or edit) or printer? You never perused a directory?

Yes, those can be done without RMS, UNIX and DOS are examples. As
long as someone provided the missing component somewhere. Your
terminal and printer didn't come out of the box thinking LF implied
CR, although some hardware is settable to provide that.

On Fri, 24 Aug 2007 11:05:48 -0700, Bill Gunshannon
wrote:

> In article ,
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> In article , "Paul Raulerson"
>> writes:
>>
>>> COBOL (and I assume PL/I running under UNIX has to supply a record
>>> ori=
>>> ented file system layered over the UNIX filesystem.
>>
>> As do Ada implementations.
>>
>> There is a distinct problem with an operating system written by folks
>> who think the lowest common denominator programming language is the
>> only one.
>
> Once again, don't assume your worldview is the only one. The entire
> paradigm underlying Unix was "The Software Tools" paradigm in which
> things are reduced to their simplest form and complexity is created
> by adding layers. Thus the "pipe" concept as used by things like
> troff which required other utilities like col, eqn, greek and tbl
> in order to create more complex documents.
>
> C-ISAM was around and available for Unix since at least the early to
> mid 80's. I first used a database and COBOL on Unix in the mid 80's.
> One advantage to the Unix paradigm is you don't end out paying for
> features you neither need nor want. I have never used RMS on VMS.
> explicitly. I can't think of anything I have done that actually
> needed it. And don't say "you don't pay for it because it is
> bundled in" because you pay for everything that comes with the system
> wether it is listed on the invoice or not.
>
C-ISAM which was written by Roger Sippl, was a pretty limited implentation
without secondary keys, for example, and this later morphed into Informix
IIRC.

> bill
>



--
PL/I for OpenVMS
www.kednos.com

Bob Koehler wrote:
> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>
>>I have never used RMS on VMS.
>>explicitly. I can't think of anything I have done that actually
>>needed it.
>
>
> You only program in C,C++,Java and you never view your files on a
> terminal (type or edit) or printer? You never perused a directory?
>
> Yes, those can be done without RMS, UNIX and DOS are examples. As
> long as someone provided the missing component somewhere. Your
> terminal and printer didn't come out of the box thinking LF implied
> CR, although some hardware is settable to provide that.
>

Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

On 08/24/07 14:41, Larry Kilgallen wrote:
[snip]
>
> If you write all your programs with a "stream of bytes" language,
> that may be the case. In my experience programs written with a
> "stream of bytes" mentality are a major source of lousy software.

More importantly, the data that is needed to generate my paycheck
isn't is "stream of bytes" format.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On 08/24/07 16:11, John Santos wrote:
[snip]
>
> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)

I was delighted the first time I opened SYSUAF in EDT, and learned
the interesting lesson (*not* on SYSUAF!) that saving an indexed
file converts it into a flat file...

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

In article ,
Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>> In article ,
>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>> In article , "Paul Raulerson" writes:
>>>
>>>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
>>>> ented file system layered over the UNIX filesystem.
>>>
>>> As do Ada implementations.
>>>
>>> There is a distinct problem with an operating system written by folks
>>> who think the lowest common denominator programming language is the
>>> only one.
>
>> C-ISAM was around and available for Unix since at least the early to
>> mid 80's.
>
> But never something one could always count on being there ?

Because the majority of users didn't need or want it. So, why should
they have to pay for it?

>
>> One advantage to the Unix paradigm is you don't end out paying for
>> features you neither need nor want. I have never used RMS on VMS.
>> explicitly. I can't think of anything I have done that actually
>> needed it.
>
> If you write all your programs with a "stream of bytes" language,
> that may be the case. In my experience programs written with a
> "stream of bytes" mentality are a major source of lousy software.

I have written programs on Unix systems in COBOL, Fortran, Pascal, Ada,
Algol, PL/I, BASIC, Modula2, various assemblers and I am sure a few
languages I have forgotten. Just because the underlying systems doesn't
have your favorite file type on it doesn't mean all programs are written
with a "stream of bytes" mentality. Part of real Software Engineering
is picking the right tools for the job. It's nice to know that some
tool is not being forced down my throat when I know it is the wrong
answer to a problem.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article ,
Ron Johnson writes:
> On 08/24/07 14:41, Larry Kilgallen wrote:
> [snip]
>>
>> If you write all your programs with a "stream of bytes" language,
>> that may be the case. In my experience programs written with a
>> "stream of bytes" mentality are a major source of lousy software.
>
> More importantly, the data that is needed to generate my paycheck
> isn't is "stream of bytes" format.

Only because the machine doing the work has imposed a format on the
raw data, wethere it is necessary or not. What exactly is needed
to generate a paycheck that can not be done with data stored as a
stream of bytes? (Hint: at the lowest level all data is stored as
a stream of bytes even on VMS!!)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article ,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>>
>> I have never used RMS on VMS.
>> explicitly. I can't think of anything I have done that actually
>> needed it.
>
> You only program in C,C++,Java and you never view your files on a
> terminal (type or edit) or printer? You never perused a directory?

I didn't say that. I know VMS is using RMS for all that. But I do the
same taskes quite well on machines without it so I guess it really isn't
necessary. It is just forced on me. Kind of like the common rant, "Bill
Gates knows what's best for you." Apparently DEC/Compaq/HP have pretty
much the same attitude.

>
> Yes, those can be done without RMS, UNIX and DOS are examples. As
> long as someone provided the missing component somewhere. Your
> terminal and printer didn't come out of the box thinking LF implied
> CR, although some hardware is settable to provide that.

At one time, almost every printer I had ever seen knew that. Today, they
all do postscript which means without a "missing component somewhere" you
couldn't print any of your RMS based files either. And don't even try
saying that you can view raw RMS files on a terminal or edit them without
a "missing component somewhere" to convert them from RMS format to juat
another pile of bytes.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article ,
John Santos writes:
> Bob Koehler wrote:
>> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>>
>>>I have never used RMS on VMS.
>>>explicitly. I can't think of anything I have done that actually
>>>needed it.
>>
>>
>> You only program in C,C++,Java and you never view your files on a
>> terminal (type or edit) or printer? You never perused a directory?
>>
>> Yes, those can be done without RMS, UNIX and DOS are examples. As
>> long as someone provided the missing component somewhere. Your
>> terminal and printer didn't come out of the box thinking LF implied
>> CR, although some hardware is settable to provide that.
>>
>
> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)

I login to lots of systems everyday without the help of RMS. Tell me again
why it is "needed" for this task?

RMS may be great at what it does but for a very large number of tasks
it is just overhead.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article , Ron Johnson writes:
> On 08/24/07 14:41, Larry Kilgallen wrote:
> [snip]
>>
>> If you write all your programs with a "stream of bytes" language,
>> that may be the case. In my experience programs written with a
>> "stream of bytes" mentality are a major source of lousy software.
>
> More importantly, the data that is needed to generate my paycheck
> isn't is "stream of bytes" format.

Banks are slow to cash checks made out in an amount of \/.

In article , Ron Johnson writes:
> On 08/24/07 16:11, John Santos wrote:
> [snip]
>>
>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed file. :-)
>
> I was delighted the first time I opened SYSUAF in EDT, and learned
> the interesting lesson (*not* on SYSUAF!) that saving an indexed
> file converts it into a flat file...

I know of at least six sites where privileged users did that to
SYSALF.DAT and then exited, meaning even their existing entries
no longer worked.

One of the best security measures a site can institute is mandatory
competency testing for those who want privileges on their username.

In article <5j93nfF3sloleU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
> In article ,
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>> In article <5j8kvsF3sj2ffU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
>>> In article ,
>>> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>>>> In article , "Paul Raulerson" writes:
>>>>
>>>>> COBOL (and I assume PL/I running under UNIX has to supply a record ori=
>>>>> ented file system layered over the UNIX filesystem.
>>>>
>>>> As do Ada implementations.
>>>>
>>>> There is a distinct problem with an operating system written by folks
>>>> who think the lowest common denominator programming language is the
>>>> only one.
>>
>>> C-ISAM was around and available for Unix since at least the early to
>>> mid 80's.
>>
>> But never something one could always count on being there ?
>
> Because the majority of users didn't need or want it. So, why should
> they have to pay for it?

Good idea. Can you help me get HP to remove the "stream of bytes"
support from VMS ?

In article <5j93skF3sloleU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
> In article ,
> Ron Johnson writes:
>> On 08/24/07 14:41, Larry Kilgallen wrote:
>> [snip]
>>>
>>> If you write all your programs with a "stream of bytes" language,
>>> that may be the case. In my experience programs written with a
>>> "stream of bytes" mentality are a major source of lousy software.
>>
>> More importantly, the data that is needed to generate my paycheck
>> isn't is "stream of bytes" format.
>
> Only because the machine doing the work has imposed a format on the
> raw data, wethere it is necessary or not. What exactly is needed
> to generate a paycheck that can not be done with data stored as a
> stream of bytes? (Hint: at the lowest level all data is stored as
> a stream of bytes even on VMS!!)

No, it is organized as a series of extents containing blocks containing
records. Implicit in that for most file formats is some implicit
carriage control format specified in the file header.

Larry Kilgallen wrote:
> In article , Ron Johnson
> writes:
>> On 08/24/07 16:11, John Santos wrote:
>> [snip]
>>>
>>> Not to mention never logging in.... SYSUAF.DAT is an RMS indexed
>>> file. :-)
>>
>> I was delighted the first time I opened SYSUAF in EDT, and learned
>> the interesting lesson (*not* on SYSUAF!) that saving an indexed
>> file converts it into a flat file...
>
> I know of at least six sites where privileged users did that to
> SYSALF.DAT and then exited, meaning even their existing entries
> no longer worked.
>

File versioning to the rescue ?

> One of the best security measures a site can institute is mandatory
> competency testing for those who want privileges on their username.

Bill Gunshannon wrote:
> RMS may be great at what it does but for a very large number of tasks
> it is just overhead.

Before you declare RMS "overhead", you would need to look into the code
that allows you to read "lines" of text in Unix (fgets for instance).

VMS doesn't need to scan the data for cr/lfs, it looks at the 2 byte
record header and knows exactly how many bytes of data are in that record.


And when you look at the many Unix/windows applications that work only
on sequential files, many end up reading the whole file in memory and
the scanning in memory (but that in the end results in a lot of paging
to the pagefile). Also, whenever you change a preference, it has to
rewrite the whole config file instead of just changing one record. And
this has interesting consequences in a multi-user system due to file
locking and other processes that may have the cofig file already in
memory when when they update their configs, they will overwrite
previously modified files without the changes that had been made by
other processes.