From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 30-MAY-1989 13:14
To:	MRGATE::"ARISIA::EVERHART"
Subj:	VMS V5 implementation of MAXDETACH=NONE

Message-Id:  <8905301701.AA21618@crdgw1.ge.com>
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Tue, 30 MAY 89 08:09:23 PDT
Received: from CUNYVM.CUNY.EDU by KL.SRI.COM with TCP; Tue, 30 May 89 07:53:28 PDT
Received: from DGOGWDG5.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 8125; Mon, 29 May 89 13:09:47 EDT
Date:    Mon, 29 May 1989 19:07:35  +0200
From: "GWDGV1::MOELLER"  <U0012%DGOGWDG5.BITNET@CUNYVM.CUNY.EDU>
To: info-vax@kl.sri.COM
Subject: VMS V5 implementation of MAXDETACH=NONE

   I'm having troubles with DEC's idea of detached processes under VMS,
and I'm in doubt if I should write an SPR again.

Background:
   Prior to VMS V4, creating a detached process was strictly a privileged
operation (DETACH priv. required), independent of the identity (UIC) the
new process was to have.
   VMS V4 introduced a new special case of RUN/DETACH, where an
unprivileged user now can create a detached process with his/her own
UIC, now limited by the (formerly rather unnoticed) MAXDETACH quota.
   I and probably many others now complained to DEC that you could not
inhibit anyone from detaching at least one process - since the minimum value
for MAXDETACH was 1 (0 means no limit). Obviously this defeats a computer center
submit batch jobs (at low priority) for long tasks; it is very easy
to convert a batch job into a detached process (at interactive priority).
Admittedly, SPAWN/NOWAIT does almost the same, but there is at least
a responsible person logged in).

   With VMS V5, DEC was kind enough to implement a new value,
MAXDETACH=NONE (in reality, -1), which had been previously announced as a
remedy for the problem under V4. Great, I thought, but ...
.. now they have made MAXDETACH that restrictive, that absolutely no
detached processed can be created by a user with MAXDETACH=NONE, and this
makes it impossible to MOUNT a tape (MTAACP is run in a detached process)!
Since our unprivileged users need access to tapes, at least for our site
MAXDETACH=NONE can't be used.

My Question:
        How do you feel about the current state of affairs, do you think
        DEC's V5 implementation makes sense, or should one insist upon
        some option which would re-instate the behaviour of VMS V3?

-----
In case you like the old behaviour, here is the patch to get V3-style
detaching under VMS V5.0 & V5.1 (I have used a similar patch with V4):

        $ patch PROCESS_MANAGEMENT.EXE
        ! w.j.m. may 1989
        !
        ! Intention of this patch:
        !  Require DETACH privilege for any creation of a detached process,
        !  Supposedly this re-installs the behaviour of VMS V3.
        ! Note: MAXDETACH quota is still checked.
        !       ... so do NOT use MAXDETACH=NONE (with V5)
        !
        ! This patch is valid for:
        !       VMS 5.00 thru 5.02
        !
        !
        set patch PAT$A_PAGED
        !
        define syscreprc=3560
        !
        replace/ins syscreprc+1b
        'beql syscreprc+4a'
        exit
        'nop'
        exit
        !
        replace/ins syscreprc+45
        'movl w^0c4(r4),r11'
        exit
        'movl w^0c4(r4),r11'
        'brb syscreprc+01d'
        exit
        !
        update
        exit

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
Bitnet/Earn: U0012@DGOGWDG5         Phone: +49 551 201516 | No claim intended

