[Info-vax] Looking into C-include files on VMS

[Bill Gunshannon]

In article <34047980-dd87-4012-8520-7491d61d2ad2 at m13g2000vbf.googlegroups.com>,
	John Wallace <johnwallace4 at yahoo.co.uk> writes:
> On Nov 5, 10:15 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <baOjfZKhG... at eisner.encompasserve.org>,
>>         koeh... at eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>
>> > In article <7ld3naF3d1ka... at mid.individual.net>, billg... at cs.uofs.edu (Bill Gunshannon) writes:
>> >> In article <hcrfk0$bt... at naig.caltech.edu>,
>> >>        glen herrmannsfeldt <g... at ugcs.caltech.edu> writes:
>>
>> >>> I presume VMS has some way to share data when needed, though.
>>
>> >> None that I have ever seen.
>>
>> >    You haven't seen mmap()?  Or $CRMPSC?  Or an installed, writable
>> >    section?
>>
>> The discussion was about fork(), not mmap().  The sharing done between
>> forked processes is, as far as I know, not possible under VMS.  That
>> is, there is no way for two processes to both have the ability to
>> read/write the exact same variables and devices.  Unix fork() does
>> this precisely.  For an easy to understand example, just take a look
>> at the source to the connect portion of  UXKermit.  The program opens
>> a serial device, forks and then one process handles input from the
>> serial port while another process handles output thru that same serial
>> port.  Can two totally separate processes under VMS both access a single
>> serial port simultaneously?
>>
>> bill
>>
>> --
>> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
>> billg... at cs.scranton.edu |  and a sheep voting on what's for dinner.
>> University of Scranton   |
>> Scranton, Pennsylvania   |         #include <std.disclaimer.h>  
> "The sharing done between forked processes is, as far as I know, not
> possible under VMS"
> You haven't been paying attention have you Bill. Just because your
> VMSworld never saw the capability doesn't mean that it didn't exist in
> the broader world of VMS. The rest you will have to sort out for
> yourself.

No. Bob, I don't have to.  Because both my employers (The University and
the DoD), like so many others, have dumped VMS. These discussions are
purely academic as VMS really has no place in the industry any more.
And one of the saddest parts of this is that its remaining advocates
still can't see that and certainly can't see all the important reasons
why it happened.  Trust me, the lack of marketing may have contributed
but it is not the primary reason for the demise of VMS.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>