On 2020-03-08 22:28, Thomas DeBellis wrote:
We always thought that the VMS asynchronous $QIO
interface was a real
winner.? Except for special JSYI (DUMPI%/DUMPO%) for magnetic tape I/O
and certain cases of disk transfers, _all_ I/O in Tops-20 is synchronous
(blocking).? You get put to sleep and you don't come back until the data
is in your address space (unless you take an interrupt).
The QIO$ system call of RSX and VMS is one of the best bits, for sure.
But most everything is asynchronous. It really allows you to do a lot of
stuff rather easily, if you write in assembler. It's a bit hard to make
use of in high level languages, though. But it's easy to do something
synchronous on top of the asynchronous basic services. Much harder the
other way around.
Johnny
The way you handle asynchronicity is to have a separate fork for data
transfers.? It can be a challenge to orchestrate data done; we don't
have P() and V(), but rather something of a queuing paradigm.? The
Extended Mode FTP server on Tops-20 has this model; a top-level fork for
the control channel and a lower for for the data channel.? Tops-10 has
more flexibility in that regard; all I/O is asynchronous (it has to be,
given the job structure).
On 3/8/20 10:25 AM, Keith Halewood wrote:
> I looked back at CMUTEK TCP/IP and discovered the multithreaded NNTP server I wrote
for ANU-NEWS under VAX/VMS... over 30 years ago. The DCL archive file is still there and
still extracts. Despite it being written in C, the interface to CMU's TCP/IP is
wonderfully $QIO-based. It still pleasantly surprises me how easy it is/was to fire off a
whole load of $QIOs with an AST routine reference and parameter, or a mailbox and just
wait around for things to happen. Someone subsequently modified it (and added better error
handling from what I remember) to work with UCX.
>
> Keith
>
> -----Original Message-----
> From:owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Timothy Stark
> Sent: 08 March 2020 00:19
> To:hecnet at Update.UU.SE
> Subject: RE: [HECnet] HPE OpenVMS Hobbyist license program is closing
>
> Yeah. I was able find CMUIP066 and CMUIP063 on ALDUR::
>
> Thanks for information.
>
> -----Original Message-----
> From:owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf Of
Dave McGuire
> Sent: Saturday, March 7, 2020 1:22 PM
> To:hecnet at Update.UU.SE
> Subject: Re: [HECnet] HPE OpenVMS Hobbyist license program is closing
>
> On 3/7/20 1:16 PM, Supratim Sanyal wrote:
>>> I see ALDUR:: but I don't see that distribution, could you point me
>>> to it?
>> CMUIP066 is at ALDUR::DISK$OLD_USERS:[DECUS.VMSLT98B.CMU.VMS-V5]
> Great. Thanks!
>
>> Looks like I dumped my install session at
>>
https://supratim-sanyal.blogspot.com/2019/03/cmu-tcpip-vax-vms-4.7.htm
>> l
> Yes I did find that. Thank you for posting it.
>
>> BTW is it a fair assumption Process Software's MULTINET hobbyist
>> licenses will also dry up?
> I don't see why they would..?
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol