[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

2206.0. "LGICMD in SYSUAF is not updated." by KERNEL::SIMPSONR (fred) Wed Feb 03 1993 09:58

 VMS V5.5-1   ALL-IN-1 Starter V2.4

 I have a customer who sets up a template for creating accounts, like the
 following:


                                 Account Template

 Name of template:  RICH_NO_PRIVS

  ALL-IN-1 account details:        Group directory:
 ALL-IN-1 sub-directory: A1V24            Language: BRITISH
 Form libr:USER

  VMS account details:      UIC group number:    110
 Group identifier:                                    VMS accounting:  TSC_APPS
 Login Command: disk$users3:[simpson.start]fred.com
 Post-processing:
  .
  .
  .


 He then creates the account and finds that the UAF entry for the new account
 is something like:

 Username: BART1                            Owner:  Richard Simpson
 Account:  TSC_APPS                         UIC:    [110,13003] ([TSC_APPS,BART1)
 CLI:      DCL                              Tables: DCLTABLES
 Default:  DISK$USERS3:[BART1]
 LGICMD:   LOGIN
 Flags:
 Primary days:   Mon Tue Wed Thu Fri
  .
  . 
  .


 The LGICMD should have been DISK$USERS3:[SIMPSON.START]FRED.COM, instead it
 defaulted to LOGIN. When I tried the same thing here it worked fine. Admitedly
 it was on ALL-IN-1 V2.4 Classic not Starter.

 Does anyone have any ides,

 Regard,
 Richard Simpson.

T.R Title User Personal
Name Date Lines

2206.1 can't find a fix IOSG::TYLDESLEY Wed Feb 03 1993 11:52 30

T.R	Title	User	Personal Name	Date	Lines
2206.1	can't find a fix	IOSG::TYLDESLEY		`Wed Feb 03 1993 11:52`	30
	Richard, I seem to recall some problem around lgicmd in V2.4, but I can't remember what (old age is affecting the memory cells!), and I do not have a V2.4 system here at present. What is happening, if I remember V2.4 correctly, is that cli$lgicmd is being set up in the script sm_cr_user_details.scp, and passed back to mua_create.com where it is used in the creation of the VMS account e.g. $ write uafcmd "$RUN SYS$SYSTEM:AUTHORIZE" $ write uafcmd "MOD ''vms_user'/dire=''uaf_dir'/devi=''vms_device'-" $ if lgicmd .nes. "" then write uafcmd "/lgicmd=''lgicmd'-" $ write uafcmd "/bytlm=''vms_bytlm'/fillm=''vms_fillm'-" $ etc.... I assume that either the template value is "" or lgicmd is not being set up correctly, because in either case, the DEFAULT account value is being adopted in the new account. You could perhaps ask the customer to set trace on the relevant part of sm_create_user_details to find out what is being passed? This should be available for inspection in the Create Log then (oa$log:). For information, this all changed in V3.0, because the UAI$ dataset became available, and a direct write change UAI$ is now done from the script. Sorry I can't help further; maybe someone else can remember whether we fixed a problem with lgicmd in V2.4? Cheers DaveT

Richard,

I seem to recall some problem around lgicmd in V2.4, but I can't remember 
what (old age is affecting the memory cells!), and I do not have a V2.4 
system here at present. What is happening, if I remember V2.4 correctly, 
is that cli$lgicmd is being set up in the script sm_cr_user_details.scp, 
and passed back to mua_create.com where it is used in the creation of 
the VMS account e.g.

$       write uafcmd "$RUN SYS$SYSTEM:AUTHORIZE"
$       write uafcmd "MOD ''vms_user'/dire=''uaf_dir'/devi=''vms_device'-"
$       if lgicmd .nes. "" then write uafcmd "/lgicmd=''lgicmd'-"
$       write uafcmd "/bytlm=''vms_bytlm'/fillm=''vms_fillm'-"
$ etc....

I assume that either the template value is "" or lgicmd is not being set up 
correctly, because in either case, the DEFAULT account value is being 
adopted in the new account. You could perhaps ask the customer to set trace
on the relevant part of sm_create_user_details to find out what is being 
passed? This should be available for inspection in the Create Log then 
(oa$log:).

For information, this all changed in V3.0, because the UAI$ dataset became 
available, and a direct write change UAI$ is now done from the script.

Sorry I can't help further; maybe someone else can remember whether we fixed
a problem with lgicmd in V2.4?

Cheers
DaveT