EVENT variables

glen herrmannsfeldt wrote:
> John W Kennedy wrote:
> (snip)
>
>> BxAM access methods, in practice, which actually construct channel
>> programs with the read and write CCWs addressing the space addressed
>> by the READ and WRITE macros. In the QxAM access methods (and in
>> VSAM), the I/O is done elsewhere.
>
> Last I knew, STREAM I/O was done with QSAM, RECORD I/O with BSAM or
> BDAM. DIRECT files were one that had EVENT for the (F) compiler.

No.

STREAM is QSAM.

RECORD SEQUENTIAL BUFFERED is QSAM, QISAM, or VSAM.

RECORD SEQUENTIAL UNBUFFERED and RECORD DIRECT are BSAM, BDAM, BISAM, or
VSAM.

RECORD TRANSIENT was QTAM on the F compiler and TCAM on the newer ones.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

Peter Flass wrote:
> glen herrmannsfeldt wrote:
>> John W Kennedy wrote:
>> (snip)
>>
>>> BxAM access methods, in practice, which actually construct channel
>>> programs with the read and write CCWs addressing the space addressed
>>> by the READ and WRITE macros. In the QxAM access methods (and in
>>> VSAM), the I/O is done elsewhere.
>>
>>
>> Last I knew, STREAM I/O was done with QSAM, RECORD I/O with BSAM or
>> BDAM. DIRECT files were one that had EVENT for the (F) compiler.
>>
>
> I recall coding it in the Optimizer for tape files. I wazs trying to
> speed a process up, but it still benchmarked poorly compared to
> assembler, so I wound up with that.

The only time that EVENT was really practical, was when accessing
multiple DIRECT files on multiple disk drives. You could issue multiple
READ, WRITE, or REWRITE statements with EVENT and then WAIT for all of them.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:480fc6b1$0$20176$4c368faf@roadrunner.com...
> glen herrmannsfeldt wrote:
> > John W Kennedy wrote:
> > (snip)
> >
> >> BxAM access methods, in practice, which actually construct channel
> >> programs with the read and write CCWs addressing the space addressed
> >> by the READ and WRITE macros. In the QxAM access methods (and in
> >> VSAM), the I/O is done elsewhere.
>
> > Last I knew, STREAM I/O was done with QSAM, RECORD I/O with BSAM or
> > BDAM. DIRECT files were one that had EVENT for the (F) compiler.
>
> I recall coding it in the Optimizer for tape files. I wazs trying to
> speed a process up, but it still benchmarked poorly compared to
> assembler, so I wound up with that.

It was probably necessary to specify BUFFNO=10 or 20 or something
for tape files. That was definitely so for SYSIN and SYSPRINT.

In <480eb6c2$0$15161$607ed4bc@cv.net>, on 04/23/2008
at 12:10 AM, John W Kennedy <jwkenne@attglobal.net> said:

>Basically, it stopped being something you find in normal operating
>systems.

No. But it did stop being something that normal applications used.

--
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

In <j5qdnZCGN7Gi35LVnZ2dnUVZ_gydnZ2d@comcast.com>, on 04/23/2008
at 06:11 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>John W Kennedy wrote:
>(snip)

>> BxAM access methods, in practice, which actually construct channel
>> programs with the read and write CCWs addressing the space addressed by
>> the READ and WRITE macros. In the QxAM access methods (and in VSAM), the
>> I/O is done elsewhere.

>Last I knew, STREAM I/O was done with QSAM, RECORD I/O with BSAM or
>BDAM.

That doesn't conflict with what you quoted.

>DIRECT files were one that had EVENT for the (F) compiler.

Also sequential.

--
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 <j5qdnZCGN7Gi35LVnZ2dnUVZ_gydnZ2d@comcast.com>, on 04/23/2008
> at 06:11 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>
>> John W Kennedy wrote:
>> (snip)
>
>>> BxAM access methods, in practice, which actually construct channel
>>> programs with the read and write CCWs addressing the space addressed by
>>> the READ and WRITE macros. In the QxAM access methods (and in VSAM), the
>>> I/O is done elsewhere.
>
>> Last I knew, STREAM I/O was done with QSAM, RECORD I/O with BSAM or
>> BDAM.
>
> That doesn't conflict with what you quoted.
>
>> DIRECT files were one that had EVENT for the (F) compiler.
>
> Also sequential.

UNBUFFERED SEQUENTIAL ONLY.

--
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see
why it was her."
-- "Alias"

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,
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, though
you could have a buffer length of one.

DCB=(RECFM=F,LRECL=1,BLKSIZE=1)

QSAM does have one more buffer stage than BSAM.
There is also locate mode I/O.

-- glen

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.

--
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

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.

--
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 <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.

As previously noted, not for the OS/360 definition of buffered.

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

For unix, disk I/O (well, file system I/O or block I/O) is buffered
inside the OS, where other devices (character I/O) is not.

In unix/C terms, unbuffered sets the buffer length to 1.

Also in unix/C terms, one can use the C library routines
fread/fwrite, or the unix system calls read/write, the latter
avoids any buffering in the C library.

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

-- glen