[Info-vax] Looking for other IDEAS for Small/Medium OVMS appliance server????

[VAXman- at SendSpamHere.ORG]

In article <qScTL+cyZ9Ag at eisner.encompasserve.org>, cornelius at eisner.decus.org (George Cornelius) writes:
>In article <00AAA713.659B4968 at SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> PRECISELY!!!  The "problem" that they are apparently trying to fix isn't
>> a problem at all.  They're trying to thwart "$ STOP/ID" from being issued
>> to stop a process running Crashe'.  Apparently, to maintain ACID access.
>> I can think of several ways to keep "$ STOP/ID"'s ($DELPRC) hands off of
>> the processes in question without having to resort to using the draconian
>> PCB$V_NODELET!!!  As far as I know too, when this has occurred, patching
>> away the PCB$V_NODELET and a "$ STOP/ID" doesn't see to hurt anything, so
>> why cause an undue pain in the first place???????
>
>I don't recall having too many problems in the past with $ STOP/ID applied
>to Cache (strong_accent) or its predecessor ISM.  [DSM is another ancestor,
>but from what I can tell a minor one.  Intersystems bought out a number of
>Mumps implementations as the demand for them began to wane.  I believe
>acquiring DSM allowed them to add some compatibility features, and maybe
>even a bit of the cluster cache capability that DSM had that Intersystems,
>which seemed allergic to clusters, did not.]
>
>If a computer operator ever got sloppy and issued a $ STOP/ID on
>an ISM process, he received a lecture about it and did not try it again.
>
>Since Mumps started out as its own O/S, when it was placed on top of
>a guest operating system without such niceties as VM or other
>virtualizations, vendors tried various ways to allow job control
>within the pseudo O/S to continue to function as before.  Primarily,
>what was needed was for VMS to make a kernel (or exec?) level call
>to ISM or Cache' before actually running down the process, and, since,
>unlike DSM, they had no clout with VMS designers, they resorted to
>essentially a desperation move to retain control.  At least if they
>couldn't keep you from using $ STOP/ID they would make it so painful
>you might not try a second time.
>
>Our remaining Cache' systems seem to have the DCL tables patched to
>run their version of $ STOP/ID so their environment can have even
>more control over the issue.

Wow, more kludge!  I didn't know that.



>Oh, and DSM did not have PCB$V_NODELET set and would from time to
>time hang when a process disappeared out from under it, but this
>got better over time, to the point where I had not seen it in recent
>years (one DSM environment left, and it's mostly just spinning its
>wheels idly).

There are other ways to keep someone from shooting themselves or some
other process in the foot.  That PCB$V_NODELET shooting oneself in the
foot and then, for fix the problem, shooting oneself in the foot yet
again!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.