Conference iosg::all-in-1_v30

    At a guess you don't have the XOWN priviledge in your ALL-IN-1 profile.
    
    ALL-IN-1 privileges:
      DCL  CMD  UDPDCL UDPFNC  XOWN  VIEW  SUBSCR  SUP  ERR  SRC  CPHD  LOG APP
       Y    Y     Y      Y      Y     Y      Y      N    N    N    N     N   N
     
    For XOWN:
    Y in this field allows the user to execute scripts and docuemnt
    templates in the user area, and open form libraries in the user area.
    The user area is any file specification which does not include a
    logical name defined in Executive mode.
    
    If you enter N in this filed and the form library filed contains the
    name of a library in the user area the user will recieve an error
    message when they log into ALL-IN-1.
    
    Richard

    Hi there!
    
    >    The user area is any file specification which does not include a
    >    logical name defined in Executive mode.
    
    	This really true? SYS$LOGIN is defined in executive mode. /JOB/EXEC
    
    Regards,
    Paul

When I defined my logical name with the /exec qualifier, my problem noted in
.0 went away.

RAM

    
>    For XOWN:
>    Y in this field allows the user to execute scripts and docuemnt
>    templates in the user area, and open form libraries in the user area.
>    The user area is any file specification which does not include a
>    logical name defined in Executive mode.
    
    Thought I'd just give the complete answer to the XOWN situation.
    
    If you do not have the XOWN ALL-IN-1 privilege.
    
    You may not run any scripts, or templates, or open any form libraries
    which:
    
    	o	Contain a directory specification 
    		(e.g. DO user1:[hacker]hack.scp or DO user1:<hacker>hack.scp)
    	
    	o	Pointed to by a non exec mode logical 
    		(e.g. DO mylog:hack.scp)
    
    	o	Whole name is a non exec mode logical 
    		(e.g. DO loghack)
    
    	o	Pointed to by a SYS$ exec mode logical.  That is an exec
    		mode logical starting with the string "SYS$" 
    		(e.g. DO sys$login:hack.scp)
    
    	All the above examples will fail with the not privileged message.
    
    	So all you are allowed to do is to invoke a script, template, form
    	library with a 'simple' filename.  That is, just the name and
    	extension, and version if you so wish!. (e.g. DO WPPRINT.SCP works!)
    
    	The one exception to this rule is for UDPs.  That is a SCRIPT
    	script invoked with the (new) UDP function.
    
    	A UDP can be (and must be) run from the user's [.UDP] directory.
    
    	Hope this clears this little confusion up.
    
    	Cheers,
    
    	Steve

    
    This is causing me a major headache as I have some batch and remote
    jobs that do...
    
    $ALLIN1/NOINIT
    DO OAX$BLA:MY_SCRIPT
    EXIT
    $
    
    Nothing unusual about this except it don't work under V3.0! I get the
    "no priv mumble mumble own elements" message. I guess what is happening
    is that ALL-IN-1 is attempting to check the XOWN field but as, because
    of the /NOINIT, it can't (no current user) it gives up and gives the
    error message.
    
    So. Do I have to create a profile for the user I rin this under just so
    I can run the script? Or can I define OAX$BLA as an executive mode
    logical?
    
    I do NOT want to put the script in the TXL, or OA$LIB. If I put it in
    the sys$login of the account I'm running from, in absence of a [.a1]
    sub-dir (there's no profile remember), will ALL-IN-1 pick it up from
    there if I change the call to "DO MY_SCRIPT"? Maybe I need a
    SET_DEFAULT before it?
    
    Discuss.
    
    BTW. When I run this under SYSTEM it appears to work. Does the XOWN
    check get overriden if the VMS account has enough muscle? If so, what
    specifically it it check for?
    
    I hate to think how many customer applications etc. this new feature has 
    broken - still it's more consultancy for us I guess :-)
    
    
    Andy

    Surely if you are doing this /NOINIT it hasn't read the profile (as you
    point out when discussing the Directory field) so therefore it can't
    have read the XOWN field to know it's not set? Maybe it defaults to
    being set off until it's read the profile. Perhaps the fact that the
    SYSTEM account doesn't have a profile record is significant?
    
    Perhaps someone else here will read the code and give us the real
    answer!
    
    Graham

    
    RE .-1
    
  >  Surely if you are doing this /NOINIT it hasn't read the profile (as you
  >  point out when discussing the Directory field) so therefore it can't
  >  have read the XOWN field to know it's not set? Maybe it defaults to
  >  being set off until it's read the profile. Perhaps the fact that the
  >  SYSTEM account doesn't have a profile record is significant?
    
    Erm. I thought that's what I said...
    
    And. The account I running ALL-IN-1 from does not have a profile record
    either (didn't use to need one).
    
    Andy

As of BL123 anyway, if the account running ALLIN1/NOINIT has SYSPRV, then XOWN
is assumed to be "on".  That is why your privileged account worked.

I won't know if this same "default" of "off" is also true in the SSB shipping
version (BL123A).

/Marty

    Thanks. I'll give the account SYSPRV then (thud - sound of security
    concious system manager hitting floor...)
    
    Andy

    
    
    Just a little background.
    
    The reason the value of the XOWN priv is zero before reading the
    profile is to stop Joe Hacker, who notices with V3.0 he can no longer
    run his nasty little scripts!
    
    Ahah he thinks, if that don't work, then I'll just run ALLIN1/NOINIT,
    therefore ALL-IN-1 wont know who I am, so I can still do it!
    
    We decided that this scenario was probably less than best!!
    
    So whats your solution.
    
    If your batch job does 'systemy' type things then run it under system,
    or manager, or any account which has SYSPRV.
    
    If your batch job does user type things, then pressumably, you would
    want ALL-IN-1 accounts, or at least profile records for them ....
    wouldn't you (he asked naively)?  If so, then modify your batch job to
    do :
    
    	OA$INI_PROFIL
    	OA$INI_GLOBALS
    
    and as long as the account has XOWN then no problem.
    
    By the way, why cant your script be in OA$LIB or the TXL or any area
    pointed to by an exec mode logical?
    
    Perhaps this is where a change should be made??
    
    That's the official story anyway.
    
    Hope this helps,
    
    Steve

    If you define OAX$BLA as an exec mode logical (as you guessed in .5),
    you can run it without XOWN (or SYSPRV).
    
    Dave.

    Re .4
    Both myself and a customer are getting access problems when the XOWN
    flag in profile is set to "N".  I'll give you the info about my system.
    	
    ALL-IN-1 V3.0 (UNPATCHED)
    VMS V5.5-1   (not got around to doing -2 yet)
    
    The libraries defined in profile are pointed to by logicals
    FAX$OPER  and FAX$USER.
    
    If we look at FAX$USER, the original way this was defined in systartup
    was: 
    $ define/system fax$user sys$ofx_lng:fax$user_forms
    
    and sys$ofx_lng was defined in it's own startup as:
    
    $ DEFINE/SYSTEM/TRANS=CONCEAL SYS$OFX SYS$SYSDEVICE:[VICFAX.]
    $ DEFINE/SYSTEM SYS$OFX_LNG SYS$OFX:[ENGLISH]
    $
    
    Anyway as expected this errored because none were /exec and the user
    didn't have XOWN priv.
    So first thing - make FAX$USER /EXEC - no joy yet  !!
    Next thing - make SYS$OFX and SYS$OFX_LNG both /EXEC - still no joy !!
    As a final clutch at straws make FAX$USER point to a PHYSICAL DEVICE (sharp
    intake of breath) - still no flippin' joy.
    Next thing - bang head against wall.
    
    So the final situation is the logicals set up as here:
    
    (LNM$SYSTEM_TABLE)      [kernel]  [shareable,system]
                            [Protection=(RWE,RWE,R,R)]  [Owner=[SYSTEM]]
    
     "FAX$OPER" [exec] = "$1$DKA0:[VICFAX.ENGLISH]FAX$OPER_FORMS"
     "FAX$USER" [exec] = "$1$DKA0:[VICFAX.ENGLISH]FAX$USER_FORMS"
    
    where the files pointed to are actual .flb and $1$DKA0: is a real disk.
    
    Help.
    Go on, please, point out the obvious thing I'm missing, 'cos I can't
    see it.
      
    	.Steve.  (my head hurts)
    
    PS just for completeness here is the error message - isn't windows
    cut/paste wonderful :-)
    
    %OA-W-NOPRV_XOWN_FORM, Not privileged to open form library FAX$OPER
    %OA-W-NOPRV_XOWN_FORM, Not privileged to open form library FAX$USER
    

    I guess it must just be some mismatch between my understanding of the
    way prvxown works and the way it actually works.  Looks like no-one in
    here has noticed the same behaviour - Oh well.......
    
    Steve.

    Are the logicals literally what you put in .12?
    
    I'm asking because there's a "feature" of XOWN (added as a bug fix)
    which means that any logicals used not only must be defined in /exec
    mode but also MUST NOT BEGIN WITH THE CHARACTERS "SYS$".
    
    This might be your problem, perhaps?
    
    D.

    Thanks for your interest Dave,
    The customer is quite happy with the "restriction" that PRVXOWN seems
    to be needed even with logicals/exec mode so the heat is off.
    
    Yes I have tried it with the logicals exactly as in .12,   ie.
    
         "FAX$OPER" [exec] = "$1$DKA0:[VICFAX.ENGLISH]FAX$OPER_FORMS"
         "FAX$USER" [exec] = "$1$DKA0:[VICFAX.ENGLISH]FAX$USER_FORMS"
    
    and it still fails, don't spend any more time on this as it isn't a big
    issue.
    
    .Stevie.