EVENT variables

Shmuel (Seymour J.) Metz wrote:

> In <XeKdnYnbzY3Y8orVnZ2dnUVZ_sWdnZ2d@comcast.com>, on 04/29/2008
> at 11:01 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>
>>The term seems strange, but I suppose it is right.
>
>
>>In unix, unbuffered means no buffer at all.
>
>
> Yes; it's common for a language or operating system to have nomenclature
> that does not match the nomenclature of other languages and operating
> systems, just as you wouldn't expect terms of art used by a doctor to
> match terms of art used by a lawyer.
>
>
>>For S/360 there is no character at a time I/O,
>
>
> Actually, there is, although AFAIK it was only used by 65MP and TSS/360.
> The term Direct Control comes to mind, but IAC it was an optional feature.
>

RDD and WDD (read direct/write direct).

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:E5adnddWA8PKaYTVnZ2dnUVZ_umdnZ2d@comcast.com. ..

> It is, then, not so obvious how to apply the PL/I terms
> BUFFERED and UNBUFFERED on a unix/PL/I system.

Read the manual.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:XeKdnYnbzY3Y8orVnZ2dnUVZ_sWdnZ2d@comcast.com. ..
> John W Kennedy wrote:
>
> > Shmuel (Seymour J.) Metz wrote:
> (snip)
>
> >> Also sequential.
>
> > UNBUFFERED SEQUENTIAL ONLY.
>
> The term seems strange, but I suppose it is right.
>
> In unix, unbuffered means no buffer at all. Every
> character is written directly to the output device,

direct from storage.

> usually a terminal. It could even be passed in a
> register all the way.
>
> For S/360 there is no character at a time I/O,

The S/360 disappeared by the 1970s.

But when it existed, I/O proceeded upon execution of a
Channel Command Word, which specified the address
of the data and the number of bytes to be transferred.
The number of bytes transferred could be 1.

> though
> you could have a buffer length of one.

Byte multiplexor channel did one character at a time.

Shmuel (Seymour J.) Metz wrote:
> In <XeKdnYnbzY3Y8orVnZ2dnUVZ_sWdnZ2d@comcast.com>, on 04/29/2008
> at 11:01 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>> The term seems strange, but I suppose it is right.
>
>> In unix, unbuffered means no buffer at all.
>
> Yes; it's common for a language or operating system to have nomenclature
> that does not match the nomenclature of other languages and operating
> systems, just as you wouldn't expect terms of art used by a doctor to
> match terms of art used by a lawyer.
>
>> For S/360 there is no character at a time I/O,
>
> Actually, there is, although AFAIK it was only used by 65MP and TSS/360.
> The term Direct Control comes to mind, but IAC it was an optional feature.

It was optional on everything but the 75 (which, being all hard-wired,
had no options). The 44 had an optional alternate version that was 32
bits wide instead of eight. It was used on MP versions of the 65 and 67
for functions that were later handled by the SIGP instructions, but it
had other applications. The most common, I believe, was a secondary data
path to MICR devices under DOS/360, which needed such a second path to
do pocket selection while the main channel connection was busy reading
data. (OS/360 instead used two channel connections.) The general idea
was to give the 360 a high-speed, low-latency data path for real-time
work, but 360s didn't get much use that way.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly; the rich
have always objected to being governed at all."
-- G. K. Chesterton. "The Man Who Was Thursday"

Shmuel (Seymour J.) Metz wrote:
> In <4816a332$0$25052$607ed4bc@cv.net>, on 04/29/2008
> at 12:25 AM, John W Kennedy <jwkenne@attglobal.net> said:
>
>> UNBUFFERED SEQUENTIAL ONLY.
>
> Il va sans dire. EVENT wouldn't make much sense in conjunction with
> BUFFERED.

Not in the days of OS/360, but VSAM introduced new complications.

--
John W. Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"

In <E5adnddWA8PKaYTVnZ2dnUVZ_umdnZ2d@comcast.com>, on 05/01/2008
at 08:53 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>On a unix system I would expect EVENT to make sense for
>buffered I/O, according to the unix definition of buffered.

Why would you expect the nomenclature of a programming language to
correlate to the nomenclature of an unrelated operating system?

>It is, then, not so obvious how to apply the PL/I terms
>BUFFERED and UNBUFFERED on a unix/PL/I system.

Only if you don't care about preserving PL/I semantics. If you care then
it's obvious.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

Shmuel (Seymour J.) Metz wrote:

> In <E5adnddWA8PKaYTVnZ2dnUVZ_umdnZ2d@comcast.com>, on 05/01/2008
> at 08:53 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>>On a unix system I would expect EVENT to make sense for
>>buffered I/O, according to the unix definition of buffered.

> Why would you expect the nomenclature of a programming language to
> correlate to the nomenclature of an unrelated operating system?

I would say that IBM did the best they could with what they
knew at the time. Certainly they didn't know about unix when
PL/I was being defined. They chose some keywords that were
generally applicable to the way systems worked. The more
system dependent stuff is in ENVIRONMENT, though.

>>It is, then, not so obvious how to apply the PL/I terms
>>BUFFERED and UNBUFFERED on a unix/PL/I system.

> Only if you don't care about preserving PL/I semantics.
> If you care then it's obvious.

Well, things have changed over the years. Unix tape I/O
isn't so different from S/360, though. In most cases,
a buffer supplied by the user is written directly to the
I/O device (which may have an internal buffer). This is
fairly similar to BSAM. (Especially in that the user is
responsible for blocking.)

Unix disk (file system) I/O is always internally buffered
by the system. That seems more QSAM like than BSAM like,
but uses the same system calls on unix and unix-like systems.

-- glen

Shmuel (Seymour J.) Metz wrote:
> In <E5adnddWA8PKaYTVnZ2dnUVZ_umdnZ2d@comcast.com>, on 05/01/2008
> at 08:53 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>> On a unix system I would expect EVENT to make sense for
>> buffered I/O, according to the unix definition of buffered.
>
> Why would you expect the nomenclature of a programming language to
> correlate to the nomenclature of an unrelated operating system?
>
>> It is, then, not so obvious how to apply the PL/I terms
>> BUFFERED and UNBUFFERED on a unix/PL/I system.
>
> Only if you don't care about preserving PL/I semantics. If you care then
> it's obvious.

And the solution chosen by IBM, over ten years ago, was to delete this
entire aspect of the language, because it has become effectively
obsolete, which is what I said over a week ago. Current programming
practice is to use threads if buffering is not satisfactory, operating
systems reflect that, and so does current PL/I.


--
John W. Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

John W Kennedy wrote:
(snip)

> And the solution chosen by IBM, over ten years ago, was to delete this
> entire aspect of the language, because it has become effectively
> obsolete, which is what I said over a week ago. Current programming
> practice is to use threads if buffering is not satisfactory, operating
> systems reflect that, and so does current PL/I.

http://www.kegel.com/c10k.html

-- glen

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
>
>> And the solution chosen by IBM, over ten years ago, was to delete this
>> entire aspect of the language, because it has become effectively
>> obsolete, which is what I said over a week ago. Current programming
>> practice is to use threads if buffering is not satisfactory, operating
>> systems reflect that, and so does current PL/I.
>
> http://www.kegel.com/c10k.html

True, the old methods comparable to PL/I's UNBUFFERED see some degree of
use in real-time and superserver applications, but, as that article
indicates, there are significant portability problems and a number of
competing strategies, not to mention that none of them help with SQL
databases.
--
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a
Marcus Aurelius is as naïve as the fear that ultimate power inevitably
corrupts."
-- James D. Barber (1930-2004)