| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3399.1 | It thinks it is | AIMTEC::WICKS_A | U.S.A 2 England 0 - I was there! | Fri Oct 15 1993 16:44 | 7 |
| Ann
Check that OA$DDS_PRIME really is defined to 0 /SYS/EXEC
Regards,
Andrew.D.wicks
|
| 3399.2 | been there, done that | ANGLIN::HARRISA | hooked on DAVE | Fri Oct 15 1993 17:04 | 13 |
| Done that. "OA$DDS_PRIME" [exec] = "0" (LNM$SYSTEM_TABLE)
user is using ALL-IN-1 now, so I'll just keep trying thruout the day.
the funny thing is i've been able to rename other accounts since the
upgrade. and I JUST renamed another account on this system with NO
PROBLEM at all. maybe there is something in the particular account i'm
trying to rename.
are there any fields in teh profil (other than MDFLAG) that might cause
a problem in renaming?
ann
|
| 3399.3 | go figure... | ANGLIN::HARRISA | hooked on DAVE | Thu Oct 21 1993 16:58 | 4 |
| ok, i waited a few days and tried renaming this account a few minutes
ago - of course NOW it worked.
|
| 3399.4 | sometimes it works, soemtimes it doesn't | ANGLIN::HARRISA | lost in the jungle of doubt | Fri Nov 05 1993 16:27 | 26 |
|
well, this saga continues, i've been getting the error in .0 on 2
different systems now. both have OA$DDS_PRIME set to:
"OA$DDS_PRIME" [exec] = "0" (LNM$SYSTEM_TABLE)
both have ALL-IN-1 v3.0-1, VMS 5.5-2
1 system the administrator was trying to do the rename, and got this
error. I tried it as the ALL-IN-1 manager and got it also. this rename
was to an existing account.
on the other system (jsut a few minutes ago) the account was newly
created.i also went in /NOCUST and renamed my account. then went in
normally and renamed my account back. both with no problems.
in either case, neither account had an autoforward set.
in both cases, a new profile was created for the new name, but with the
MAIDES field set to NO MAIL. to make the accounts usable, i just set
the MAIDES to ALL-IN-1 and deleted the wrong name profile.
when on the SM$RENAME form, i only enter a new ALL-IN-1 name and then
hit RETURN.
the RENAME forms/scripts/com files have NOT been customized
ann
|
| 3399.5 | This could be related to GBL* sysgen parameters | GIDDAY::SETHI | Holland 2-England 0,Andrew wasn't there | Sun Nov 07 1993 05:54 | 33 |
| Hi Ann,
I have come across the same problem and at times the users NETWORK.DAT
record got updated other time it didn't. What we found was the the
GBLPAGFIL quota was too low, we used autogen with feedback to get a
report than tuned the system. It's a rather obsecure problem because
no error messages were reported apart from the one in your base note.
There is a good article in Stars that maybe of some help to explain why
and how this and other parameters relate to RMS Global Buffering. The
article is called "SYSGEN Parameters Related To RMS Global Buffers".
For your interest the following parameters are important:
There are eight SYSGEN parameters that are directly related to RMS
global buffers. They are the following:
1. RMS_GBLBUFQUO 5. VIRTUALPAGECNT
2. GBLSECTIONS 6. SYSMWCNT
3. GBLPAGES 7. LOCKIDTBL
4. GBLPAGFIL 8. RESHASHTBL
There is yet again another article called "Command Procedure To
Estimate SYSGEN Units for RMS Global Buffers". I found them to be very
useful and interesting. I too checked the autoforward stuff but it
didn't help as in your case my customer didn't have autoforward set.
Regards,
Sunil
PS - I see you are no longer "hooked on DAVE" !!!!! I am just being my
cheeky self :-).
|
| 3399.6 | The results of tuning at the customer site | GIDDAY::SETHI | Holland 2-England 0,Andrew wasn't there | Mon Nov 08 1993 01:25 | 13 |
| Hi All,
I just thought that I would reply with the results. The customer tuned
3 out of 4 nodes in the cluster renames worked on the tuned system but
on the untuned system they failed.
I hope that this is of some help to you. I cannot say with certainity
if you have the same problem but from my experience on this site the
GBL* stuff in the previous reply helped to solve the problem.
Regards,
Sunil
|