| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1083.1 | Old startup file?? | CHRLIE::HUSTON | | Tue Jul 21 1992 16:00 | 93 |
|
Bryan,
>When I first upgraded to v3.0 the file cabinet server started up without any
>problems. Recently that stopped happening. The file cabinet server is not
>available. After trying to start it, the server process is still in the stopped
>state.
What changed between then and now, anything??
> When I try to do any management functions from the MS menu after
>trying to start the server, I get this error message displayed on line 24:
>
>"Invalid authentication information received by the File Cabinet Server"
>
>The rights identifier oafc$sysman is granted to the ALLIN1 account.
>
This indicates to me that the server is running, you will not get the
invalid authentication error unless the server is running. I would say
to double check that the oafc$sysman rights ID is still on the
correct account.
>There is nothing in sys$manager:OAFC$SERVER_ERROR.LOG. The file is empty.
There would be nothing if the above is correct
>Example 2: After ALL-IN-1 restarts every morning when backups are complete.
>
>
>$SYLOGIN:
>This job is running on COUPON, a VAX 6000-510 running VMS V5.4-3.
>
>
>************************************************************************
>
>
>%RUN-S-PROC_ID, identification of created process is 2040293A
>Error writing to server process mailbox - %RMS-E-FNF, file not found
>%DCL-W-UNDFIL, file has not been opened by DCL - check logical name
>%DCL-W-UNDFIL, file has not been opened by DCL - check logical name
>%NONAME-W-NOMSG, Message number 00000000
>Server is being started:
> configuration_file: OA$DATA_SHARE:COUPON$SERVER73.DAT
> process_name: COUPON$SRV73
>
>
this looks suspiciously like an old startup file for the server.
Whenever th problem is mailboxes it is usually that somehow you
are using an old startup file.
>Example 3: After ALL-IN-1 restarts when backups are complete
>
>
>$SYLOGIN:
>This job is running on COUPON, a VAX 6000-510 running VMS V5.4-3.
>
>
>************************************************************************
>
>
>A server process already exists with the specified name
>%NONAME-W-NOMSG, Message number 00000000
>Server is being started:
> configuration_file: DISK$ALLIN1:[ALLIN1.DATA_SHARE]COUPON$SERVER
>73.DAT;1
> process_name: COUPON$SRV73
>
>
>************************************************************************
>
>
> ALLIN1 job terminated at 20-JUL-1992 12:03:00.52
>
> Accounting information:
> Buffered I/O count: 86 Peak working set size: 712
> Direct I/O count: 61 Peak page file size: 5117
> Page faults: 708 Mounted volumes: 0
> Charged CPU time: 0 00:00:01.62 Elapsed time: 0 00:00:07.37
>
>
>In this last one, it appears that the server is not stopped when ALL-IN-1 is
>shutdown nightly for backups.
Agree.
--Bob
|
| 1083.2 | | MSBCS::KING | VSS BXB/LTN System Management Group DTN:293-5677 | Tue Jul 21 1992 20:23 | 26 |
| What has changed recently with this installation is, I installed SYSTIDY.
I checked the rights identifier oafc$sysman again and it is granted to myself
and the allin1 account
UAF> show/ident/full oafc$sysman
Name Value Attributes
OAFC$SYSMAN %X800100F3 RESOURCE
Holder Attributes
KING RESOURCE
ALLIN1 RESOURCE
> this looks suspiciously like an old startup file for the server.
> Whenever th problem is mailboxes it is usually that somehow you
> are using an old startup file.
What should I be looking for here? I checked the dates on all of the
oafc*serv*.com files and they're all dated 12-Mar-1992.
Thanks,
Bryan
|
| 1083.5 | Problem solved | MSBCS::KING | VSS BXB/LTN System Management Group DTN:293-5677 | Wed Jul 22 1992 19:35 | 20 |
| The solution to the problem has been found and we've dealt with this before
on this cluster and that is why it previously worked. The logical SYSUAF, if it
exists, needs to have the full file specification defined. For example the
logical sysuaf is now defined to be this
SYSUAF = HOTFILES:SYSUAF.DAT
We had left the .DAT off before.
Thanks for your assistance,
Bryan
|
| 1083.6 | FCS bug | CHRLIE::HUSTON | | Wed Jul 22 1992 19:39 | 13 |
|
re .5
You mean that by having the sysuaf logical incorrectly defined, hence
causing the FCS to not be able to open it, that the FCS will not start
and will not tell you why??
I agree it should not start, and won't. If you are saying that it
just dies without any message why then this is a bug in the FCS
startup.
--Bob
|
| 1083.8 | The process was still present | MSBCS::KING | VSS BXB/LTN System Management Group DTN:293-5677 | Wed Jul 22 1992 20:35 | 6 |
| The process COUPON$SERV73 was still present and didn't die. However attempting
any management functions from the MS screen were not successful and the
error message "invalid authentication...." displayed on line 24.
/Bryan
|
| 1083.9 | Want to fix the right thing | CHRLIE::HUSTON | | Wed Jul 22 1992 21:58 | 6 |
| Ok, so it sounds if the server started but was basically useless. IF
the sysuaf file could not be opened it should not have started.
You say the process was there but useless. Did it all clear up
once the SYSUAF logical was fixed??
--Bob
|
| 1083.10 | Depends of existence of SYS$SYSTEM:SYSUAF.DAT | XLII::FDONOHUE | | Thu Oct 15 1992 16:40 | 27 |
|
Some customers have reported that the start up of the FCS does in
fact fail if the SYSUAF logical is defined and does not include
a file extension (.DAT) in the definition.
I have been told that if the FCS cannot find the file pointed to
by the logical then it will try to find the default file
SYS$SYSTEM:SYSUAF.DAT. It seems like affect on the FCS in this
case may depend on whether this (possibly and likely) is outdated
or not.
It may be that if this default file does not exist then the FCS will
not start, but if it exists it will use it even though it is not the
same one being used by VMS. And the authentication (of passwords)
possible or identifiers is failing sine the information in the
file is outdated and not what you see when you run Authorize.
Can someone who can verify this please confirm or deny this
hypothesis???
I am trying to write a complete and accurate article for STARS on this
situation and need this verified if possible.
Thanks in advance,
Faith Donohue
|
| 1083.11 | Response sent to DECUS folks | SIOG::T_REDMOND | Thoughts of an Idle Mind | Thu Oct 15 1992 18:41 | 67 |
| There has been a far amount of messages coming in from the moderators
of the DECUServe (US) ALL-IN-1 conference, one of whom is Don Vickers
(remember him). Here's the response that went to them this afternoon.
Tony
Date: 15-Oct-1992 05:43pm BST
From: Tony Redmond - European Office
REDMOND@AM@DUBSWS@SIOG@DBO
Dept:
Tel No: DTN 827-2264
TO: Bruce Bowler ( "[email protected]"@VBORMC@MRGATE )
TO: Don Vickers ( "[email protected]"@VBORMC@MRGATE )
CC: Kevin Standage@REO
CC: Graham Pye ( PYE@A1@IOSG@REO )
Subject: RE: SYSUAF and FCS
Hi Don, Bruce,
I asked the installation team in ALL-IN-1 Engineering to check things out
regarding the FCS and SYSUAF. Here is their response. Can you please post
this in the DECUServe conference?
Tony
------------------------------------------------------------------------------
Rules of interaction between the ALL-IN-1 File Cabinet Server and SYSUAF.
1) If SYSUAF.DAT is located in SYS$SYSTEM and the logical is
CORRECTLY defined then the server starts OK.
2) If SYSUAF.DAT is located in SYS$SYSTEM and the logical is
INCORRECTLY defined, then the server will still start correctly.
3) If SYSUAF.DAT is located in SYS$SYSTEM and the logical is NOT
DEFINED at all, then the server starts OK.
4) If SYSUAF.DAT is NOT located in SYS$SYSTEM, but the logical is
CORRECTLY defined, then the server starts correctly.
Finally,
5) If the server is NOT located in SYS$SYSTEM, and there is no SYSUAF
logical, then the server will (as you'd imagine) fail to start,
and the error logged is:
15-OCT-1992 12:44:50.04 Server: SHU::"73="
Error: %RMS-E-FNF, file not found
Message:Server startup has failed. Check file:sys$system:sysuaf.dat
So, the rule is:
If SYSUAF exists and correctly points to the .DAT then start server
If SYSUAF exists but doesn't point to the .DAT then check in
sys$system
if the .DAT's there then start server.
else exit
If SYSUAF doesn't exist then look in sys$system
- if the .DAT's there then start server.
else exit
|
| 1083.12 | .DAT or not .DAT | SCOTTC::MARSHALL | Do you feel lucky? | Thu Oct 15 1992 19:27 | 15 |
| re .11:
What do you mean by the logical being "correctly" defined in this context?
From VMS's point of view, the logical does not need to have the extension .DAT,
so "MYDISK:[MYDIR]MYSYSUAF" is a valid value for the logical, for example. The
application using the logical should assume a filetype of .DAT if there is no
filetype in the logical name.
However, .10 suggests that the FCS requires the .DAT extension on the logical.
Thus a "correct" definition of the logical from the FCS's point of view differs
from the VMS definition.
So which version of "correct" is being used in .11 please?
Scott
|
| 1083.14 | One issue, but fully specify SYSUAF and FCS is :-) | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Fri Oct 16 1992 00:06 | 28 |
|
I'm afraid the statements in .11 were my doing ! I did all my testing
with the logical including the .DAT extension.
However, if SYSUAF.DAT is in, say, DISK:[MYDIR] then the logical
definition has to include the .DAT extension, otherwise the FCS will
not start up.
Now, if the logical definition doesn't include the .DAT extension,
but the SYSUAF resides in SYS$SYSTEM, then there's no problem. This is
because the server fails to find the data file with the logical, so
takes a look in SYS$SYSTEM anyway.
But there is one small problem with all this. Say I copied SYSUAF from
SYS$SYSTEM to DISK:[MYDIR], but defined the logical without the .DAT
extension. This will result in the server not finding the true SYSUAF
which VMS is using, and instead it will start up on the SYSUAF in
SYS$SYSTEM (which might be out of date).
Now, did that make any sense at all ?? :-)
Kevin.
|
| 1083.16 | Hope this helps... | CHRLIE::HUSTON | | Fri Oct 16 1992 14:25 | 46 |
|
scott,
don't bother with the ipr, it is a well known bug (by us at least),
and we already have bug in the database about it. THR-16625 is the
number.
All the answers that are needed are in teh last few replies, for
simplicity let me summarize what everyone has said, all from a
FCS point of view.
When the server starts up, it looks to open the system authentication
file, which is USUALLY called SYS$SYSTEM:SYSUAF.DAT.
What we do is first try by the logical SYSUAF, if this logical is
completely defined (or correctly from the point of view of a previous
note) then we will find the file and open it. Note if the logical does
not completely specify the file, like leaving off the .DAT. A bug in
our code keeps us from finding the file. If we can't open the file
by the logical, we attempt to open SYS$SYSTEM:SYSUAF.DAT.
As suggested by some in here there are potential problems with this:
1) An old version of sysuaf.dat could be found by FCS, thereby we use
a different uaf file than VMS, hence bad things happen.
2) If you happen to have a file called sysuaf.dat in sys$system
that is not the corect file, we will use it.
So basically:
If the logical exists and completely specifies the file, we will find
the file and the server will start and work properly.
If the logical does not exist, or does not completely specify the file
we will use SYS$SYSTEM:SYSUAF.DAT.
If neither of the above work, we will not start.
Its a bug and we know of it, the short term solution, which should not
bother any systems, is to insure that SYSUAF completely specifies
the uaf file.
--Bob
|