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

[VAXman- at SendSpamHere.ORG]

In article <plrX$YW7+ZE4 at eisner.encompasserve.org>, koehler at eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00AAA645.76C1CBCC at SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> 
>> Well, I've long contended that the bit is improperly named.  It should
>> be called PCB$V_IMMORTAL.  When this bit is set, it is telling OpenVMS
>> that this process must exist.  If an exception should occur and it is
>> not fielded by the software, it is going to cause image rundown.  When
>> the rundown get to the final stages in SYS$EXIT, it sees that this is
>> an IMMORTAL process.  It sets process scheduling priority to 0 and then
>> does what it can to insure that the process is retained; it loops on:
>> 20$: BRB 20$.
>
>   Essentially causing multiple null prcesses.  I recall killing NETACP
>   before that bit was invented would cause fat Al to show up, I guess

Not this fat Al: http://biomania.yolasite.com/resources/fat-albert.jpg


>   this is better than nothing.  But there is absolutely no reason an
>   application should use it.  Whatever problem they were trying to fix,
>   there must be a better design.

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???????

-- 
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.