EVENT variables

What ever happened to EVENT variables and asynchronous I/O?

I don't see them in the z/OS PL/I manual I have a link to, though I
thought I remembered them from older PL/I versions.

-- glen

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:0bednfp3b9kLhpDVnZ2dnUVZ_tzinZ2d@comcast.com. ..
> What ever happened to EVENT variables and asynchronous I/O?
>
> I don't see them in the z/OS PL/I manual I have a link to, though I
> thought I remembered them from older PL/I versions.

Have you looked at the WAIT statement?

robin wrote:

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

>>What ever happened to EVENT variables and asynchronous I/O?

>>I don't see them in the z/OS PL/I manual I have a link to, though I
>>thought I remembered them from older PL/I versions.

> Have you looked at the WAIT statement?

There is WAIT, but no EVENT option on record oriented I/O statements
to do asynchronous I/O.

-- glen

glen herrmannsfeldt wrote:

> robin wrote:
>
>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>> news:0bednfp3b9kLhpDVnZ2dnUVZ_tzinZ2d@comcast.com. ..
>
>
>>> What ever happened to EVENT variables and asynchronous I/O?
>
>
>>> I don't see them in the z/OS PL/I manual I have a link to, though I
>>> thought I remembered them from older PL/I versions.
>
>
>> Have you looked at the WAIT statement?
>
>
> There is WAIT, but no EVENT option on record oriented I/O statements
> to do asynchronous I/O.
>

Asynch I/O is an idea whose time has come and gone. Tape and DASD are
so buffered these days that it's generally pretty useless. I plan to
support it (eventually), but it will require a separate thread to do the
I/O.

Peter Flass wrote:
(snip, I wrote)

>> There is WAIT, but no EVENT option on record oriented I/O statements
>> to do asynchronous I/O.

> Asynch I/O is an idea whose time has come and gone. Tape and DASD are
> so buffered these days that it's generally pretty useless. I plan to
> support it (eventually), but it will require a separate thread to do the
> I/O.

Still, I was surprised that IBM didn't support it anymore.

Though since that post I looked it up in the PL/I (F) manual, and
it seems that it was originally only for unbuffered or direct files.
(Though I am not so sure what they mean by unbuffered.)

-- glen

glen herrmannsfeldt wrote:
> What ever happened to EVENT variables and asynchronous I/O?

Basically, it stopped being something you find in normal operating
systems. OS/2 included something of the sort, but it actually achieved
it by starting a slave thread.

> I don't see them in the z/OS PL/I manual I have a link to, though I
> thought I remembered them from older PL/I versions.

Yes, because the BxAM access methods of OS/360 all had parallel
constructs with DECBs and the WAIT macro. But by the 90s, the OS/360 I/O
model had become an eccentric backwater; modern operating systems
pattern their I/O on Unix.

The new compiler has also abandoned the original PL/I tasking model,
which had been perfectly hellish to implement even on OS/360, chiefly
because any number of original PL/I tasks can wait on a single EVENT,
whereas only one OS/360 task can wait on a single ECB.

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

glen herrmannsfeldt wrote:
> Peter Flass wrote:
> (snip, I wrote)
>
>>> There is WAIT, but no EVENT option on record oriented I/O statements
>>> to do asynchronous I/O.
>
>> Asynch I/O is an idea whose time has come and gone. Tape and DASD are
>> so buffered these days that it's generally pretty useless. I plan to
>> support it (eventually), but it will require a separate thread to do
>> the I/O.
>
> Still, I was surprised that IBM didn't support it anymore.
>
> Though since that post I looked it up in the PL/I (F) manual, and
> it seems that it was originally only for unbuffered or direct files.
> (Though I am not so sure what they mean by unbuffered.)

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.


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

John W Kennedy wrote:

> glen herrmannsfeldt wrote:

>> What ever happened to EVENT variables and asynchronous I/O?
(snip)

>> I don't see them in the z/OS PL/I manual I have a link to, though I
>> thought I remembered them from older PL/I versions.

> Yes, because the BxAM access methods of OS/360 all had parallel
> constructs with DECBs and the WAIT macro. But by the 90s, the OS/360 I/O
> model had become an eccentric backwater; modern operating systems
> pattern their I/O on Unix.

At least some versions of unix have asynchronous I/O. I was doing it
in SunOS not so many years ago.

For some reason, asynchronous I/O came up in a discussion on TOPS-10,
the original OS for the PDP-10. That would have been at the assembly
level, though.

-- glen

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.

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

> Though since that post I looked it up in the PL/I (F) manual, and
> it seems that it was originally only for unbuffered or direct files.
> (Though I am not so sure what they mean by unbuffered.)

Unbuffered I/O is just that. Unbuffered.
It means that the input is direct into the input area.

When buffered I/O is used, there are two or more input areas,
and after one has been filled, the next buffer is filled while you are
processing the data in the first.

Similarly for output.