| ALL-IN-1 V3.0 : Creating a Single ALL-IN-1 Account for Several VMS Accounts
COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.
PROBLEM/SOLUTION ARTICLE OUTLINE
-------------------------------------------------------------------------------
BRIEF PROBLEM OUTLINE:
Creating a Single ALL-IN-1 Account for Several VMS Accounts and is unable
to blank the VMS account name.
PRODUCT: VMS, Version 5.4-2
LAYERED PRODUCT: ALL-IN-1, Version 3.0
DATE: 28-MAY-1992
SYMPTOMS/PROBLEM:
A customer was trying to follow the instructions in the Management Guide to
create a single ALL-IN-1 account for several VMS accounts (4-42 to 4-43).
When he tried to delete the VMS account name it would not let him. Brought
up the message:
"Field may not be left blank - re-enter"
ANALYSIS:
The named data appeared to be too restrictive. There is a /VALID qualifier
that does not allow blank fields for the field VMSUSR.
SOLUTION:
Alter the named data on the form SM$PROFILE from:
;;VMSUSR;;
/PRE='GET #SM_VMS_INITIAL = VMSUSR'
/HARD=OA$_SM_HRD_VMS_ACCOUNT
/RECOG=UAF:.USERNAME
/VALID=UAF:.USERNAME
/POST='.IF #SM_VMS_INITIAL NES VMSUSR THEN GET #SM_VMS_CHANGE = "1"'
To:
;;VMSUSR;;
/PRE='GET #SM_VMS_INITIAL = VMSUSR'
/HARD=OA$_SM_HRD_VMS_ACCOUNT
/RECOG=UAF:.USERNAME
/VALID=UAF:.USERNAME/OPTIONAL
/POST='.IF #SM_VMS_INITIAL NES VMSUSR THEN GET #SM_VMS_CHANGE = "1"'
It is also necessary to move the whole form set live.
i.e SM$PROFILE, SM$PROFILE2, SM$PROFILE3, SM$PROFILE4, SM$PROFILE5,
SM$PROFILE6.
|
| Hi Audrey,
>> to create "a single ALL-IN-1 account for several VMS accounts".
>> We're following the instructions in the V3.0 Manager's Guide
>> (page 4-42 and 4-43) - and step #4's instructions are to delete the VMS
>> account name. ALL-IN-1 won't allow it (after all, the VMSUSR field is
>> a key field)...
----
This seems to be a carry-over from V2.4 when form SM$EDIT was used, and you
could close the form leaving the VMSUSR field blank. In V3.0 SM$PROFILE was
introduced and the validation on this field prevents its being left blank.
If no problem report exists for this, then one needs to be submitted.
For your purposes in the class situation, there are several ways to work
around this:
. as -1 suggests, you can add /OPTIONAL to the field.
. you can enter the command oa$val_set_valid after blanking the
VMSUSR field, and then close the form.
. or you can WRITE CHANGE direct to the Profile.
To help you do this, you can use the script below, and modify it as you wish.
Run it from the ALL-IN-1 Manager account, after first having selected the
account (in the context block) that you wish to share between several VMS
accounts.
!============================================================================
! VMSUSR_BLANK.SCP
!
get oa$display = sm$_gbl_working\force
get #cur_account = $sm_account
write change profil user = #cur_account, vmsusr = ""
!-
! Because the account name has changed, then we must change all
! the PARTITION records for this user.
!+
get #sm_partial_key = "[" #cur_account "]"
for partition with .unique_name = #sm_partial_key do -
get #sm_partition_key = .unique_name\\ -
write change partition unique_name = #sm_partition_key, -
owner = ""
!
get oa$display = ""
.exit
!============================================================================
The partition change after editing the VMS user name is a known problem in
V3.0 and will be fixed in a possible future release. When you have run this
script, all users on the system will be able to see this drawer from the
Index of All Drawers, but only those with privilege to open the DOCDB, DAF,
etc. will be able to use it.
Cheers,
DaveT
|
| An even better workround is to ask them why they are trying to do it at
all. Since V3.0 sharing is all controlled by ACLs, which are tied to
individual VMS accounts, it is much preferable not to share VMS
accounts at all. Actually it was never a particularly good idea, but
it's even less so now. At one time I think we were intending to ban it
in V3.0, so perhaps that's how the named data came to be there.
Graham
|