[HECnet] HPE OpenVMS Hobbyist license program is closing

Johnny Billquist bqt at softjar.se
Sun Mar 8 14:41:49 PDT 2020


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


More information about the Hecnet-list mailing list