| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1401.1 | Things to check | SCOTTC::MARSHALL | Do you feel lucky? | Mon Sep 14 1992 11:00 | 16 |
| First, do the accounts in question have a file FILECAB.DAT in their ALL-IN-1
directories?
Secondly, do these files contain anything? They should contain a list of
drawers in that account's file cabinet.
Thirdly, do those drawers have entries in the PARTITION? Are all the details
in the partition record correct?
Fourthly, do the directories specified by the PARTITION entries exist?
Fifthly, do these directories contain DOCDB.DAT, DAF.DAT, DOCn.DIR, etc?
Sixthly, ... err, can't think of anything else!
Scott
|
| 1401.2 | Check protections! | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Mon Sep 14 1992 11:53 | 28 |
|
Hi Gil,
Just a couple of other things to look for.
You say that V3.0 is on two of your test machines, so are you
attempting local or remote shared filing - this could effect the
possible reasons for your troubles.
Also, to share a drawer it is essential that the intended sharers can
access the drawer directory. In particular they must have execute
access to all the directory levels down to the drawer itself.
If you read (or print) the drawer details from the owners account
then you would see a warning if the required access is not there at
any of the levels.
The warning is included if
a) the drawer is shared and
b) at least one of the directories does not have w:e
HTH,
Kevin.
|
| 1401.3 | Don't think you are getting that far | CHRLIE::HUSTON | | Mon Sep 14 1992 14:35 | 20 |
|
re all
While all good suggestions mentioned in .1 and .2, from the looks of
the error message, you are not getting far enough to have file
protection problems. The error message is invalid file cabinet, this
is almost always generated by a call to OafcOpenCabinetW and passing
a file cabinet name that we (FCS) cannot find. My suggestion would
be to have server tracing turned on, try again, then turn tracing on.
You will need to turn tracing on for all users to pick up the trace
of an open cabinet attempt, so make sure you have a clean trace file
to start with. When you have this, run it through the trace formatter
(sys$system:oafc$print_trace_log.exe, not sure if the SM interface
gives an easy way for this), then post the output here, or send
me a pointer to the trace file and I will run it through my
formatter (don't post an unformatted trace file, it will look like
complete garbage and is very large).
--Bob
|
| 1401.4 | Server trace output | MASALA::GMURRAY | Have Mercy I Cry City ! | Mon Sep 14 1992 18:03 | 98 |
|
Hi all,
Well, everything in .1 checked out OK. I also checked
directory protections as per .2, and these were fine. BTW we're talking
local shared filing, not remote.
Here is the output for .3 - any use ?
Thanks,
Gil
OIS Manager > run sys$system:oafc$print_trace_log
SESSION ID: 3654992
OAFC FUNCTION: OafcSetServer
TRACE EVENT: Task Complete
EVENT TIME: 14-SEP-1992 16:44:09.49
STATUS: 55803913
STRING1 IS: ALLIN1
SESSION ID: 3654992
OAFC FUNCTION: OafcShowServer
TRACE EVENT: Task Start
EVENT TIME: 14-SEP-1992 16:44:10.34
STRING1 IS: ALLIN1
SESSION ID: 3654992
OAFC FUNCTION: OafcShowServer
TRACE EVENT: Task Complete
EVENT TIME: 14-SEP-1992 16:44:10.43
STATUS: 55803913
STRING1 IS: ALLIN1
SESSION ID: 3655248
OAFC FUNCTION: OafcOpenCabinetW
TRACE EVENT: Task Start
EVENT TIME: 14-SEP-1992 16:47:48.97
SESSION ID: 3655248
OAFC FUNCTION: OafcOpenCabinetW
TRACE EVENT: Connection Rcv'd
EVENT TIME: 14-SEP-1992 16:47:49.11
FILE CABINET NAME: OISDEV.SARKIS.CATRIONA
STRING1 IS: OISDEV
STRING2 IS: CSARKIS
SESSION ID: 3655248
OAFC FUNCTION: OafcOpenCabinetW
TRACE EVENT: Connection Rejected
EVENT TIME: 14-SEP-1992 16:47:49.31
FILE CABINET NAME: OISDEV.SARKIS.CATRIONA
STRING1 IS: CSARKIS
SESSION ID: 3655248
OAFC FUNCTION: OafcOpenCabinetW
TRACE EVENT: Task Complete
EVENT TIME: 14-SEP-1992 16:47:49.58
FILE CABINET NAME: OISDEV.SARKIS.CATRIONA
STATUS: 55803994
STRING1 IS: CSARKIS
SESSION ID: 3655248
TRACE EVENT: Disconnect Done
EVENT TIME: 14-SEP-1992 16:47:49.78
FILE CABINET NAME: OISDEV.SARKIS.CATRIONA
SESSION ID: 3654992
OAFC FUNCTION: OafcShowServer
TRACE EVENT: Task Start
EVENT TIME: 14-SEP-1992 16:48:18.98
STRING1 IS: ALLIN1
SESSION ID: 3654992
OAFC FUNCTION: OafcShowServer
TRACE EVENT: Task Complete
EVENT TIME: 14-SEP-1992 16:48:19.04
STATUS: 55803913
STRING1 IS: ALLIN1
SESSION ID: 3654992
OAFC FUNCTION: OafcSetServer
TRACE EVENT: Task Start
EVENT TIME: 14-SEP-1992 16:48:20.01
STRING1 IS: ALLIN1
|
| 1401.5 | couple things to check | CHRLIE::HUSTON | | Mon Sep 14 1992 19:22 | 27 |
|
re .4
doesn't tell me much, about what I thought :-(
>SESSION ID: 3655248
>OAFC FUNCTION: OafcOpenCabinetW
>TRACE EVENT: Connection Rcv'd
>EVENT TIME: 14-SEP-1992 16:47:49.11
>FILE CABINET NAME: OISDEV.SARKIS.CATRIONA
>STRING1 IS: OISDEV
>STRING2 IS: CSARKIS
This is the relevant one. According to this your A1 username contains
a '.' in it. We had a bug a long time ago, which this would not work.
What version of ALL-IN-1 are you using??
Also could you do an anal/image on sys$system:oafc$server.exe and
sys$share:oafc$client_shr.exe and get the versions from them.
Can you also verify that there is a record in the profile for
SARKIS.CATRIONA.
--Bob
|
| 1401.6 | Spooky | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Tue Sep 15 1992 11:24 | 7 |
|
Further to what Bob said, the does the VMS account have numerous
ALL-IN-1 accounts, one of which is the account you're having the
problems with ??
Kevin.
|
| 1401.7 | answers | PAKORA::GMURRAY | Have Mercy I Cry City ! | Wed Sep 16 1992 11:10 | 35 |
|
Hi folks,
Sorry for the delay ...
We were using ALL-IN-1 v2.4, but have now upgraded to v3.0
The anal/image on the two executables looks like this :
1. sys$system:oafc$server.exe
image name: "OAFC$SERVER"
image file identification: "OAFC V1.0"
link date/time: 3-SEP-1992 10:57:53.97
linker identification: "05-09"
2. sys$share:oafc$client_shr.exe
image name: "ALL-IN-1 FCS"
image file identification: "OAFC V1.0"
link date/time: 4-MAR-1992 00:38:46.12
linker identification: "05-05"
Yes, there is a record for SARKIS.CATRIONA, in the profile. All our
A1 usernames are in the format lastname.firstname.
Lastly, no, the VMS account in question has only one ALL-IN-1
account - the problematic one.
Thanks,
Gil
|
| 1401.8 | either we missed something or its not easy | CHRLIE::HUSTON | | Wed Sep 16 1992 15:23 | 28 |
|
Gil,
does anything show up in the server log files??
There are several reasons for invalid file cabinet to be returned,
we have covered the most obvious, now its time to get into the dirty
stuff :-)
Did anything show up in the server log files? If so, can you post the
message.
Does the VMS user in question have READ access to the filecab.dat?
Look at the VMS users record in the UAF file. Does the default login
directory specified in the UAF file actually exist?
Look at the A1 users profile. Does the A1 directory exist?
Did this account work before moving to V3.0?
Do the other accounts with '.' in it work?
Is this a DEC system (like can I get on it with a debuggable server if
all else fails)?
--Bob
|
| 1401.9 | Server log errors etc | PAKORA::GMURRAY | Have Mercy I Cry City ! | Wed Sep 16 1992 16:07 | 39 |
|
Bob,
1. Yes - the log file sys$manager:OAFC$SERVER.log contains loads of
RMS-E-RNF errors such as :
10-SEP-1992 16:17:41.90 Server: OISDEV::"73=" Error: %RMS-E-RNF, record
not found Message: CsiOpenRmsFileCab; error getting
record:SARKIS.CATRIONA
SARKIS.CATRIONA gets the majority of these, but me (MURRAY.GIL),
CHICK.KEN, and even MANAGER get one or two, all the same error.
Nothing in the sys$manager:oafc$server_errors.log file though.
2. Yes, CSARKIS (her VMS account) has access to her FILECAB.DAT
3. Yes, the UAF default login directory exists.
4. Yes, her A1 directory exists too.
5. The old 2.4 ALL-IN-1 account for this user was somehow lost, so
I created a brand new one after the upgrade, locating it into the old
VMS account directory.
6. Yes. Strangely enough, at first the account CHICK.KEN had
exactly the same problem, but now everything works as expected for
him, no apparent reason why. My own account has always worked normally.
7. Yup, I'll contact you on this if you want
Cheers,
Gil
|
| 1401.10 | ? | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Wed Sep 16 1992 16:58 | 26 |
|
>> 5. The old 2.4 ALL-IN-1 account for this user was somehow lost, so
>>I created a brand new one after the upgrade, locating it into the old
>>VMS account directory.
This is only a guess, but perhaps something's gone wrong in the process
of creating this new account from the old 2.4 files. Are all
these problems isolated to situations involving accounts of the
above scenario ? Can the user with the new V3.0 account + old 2.4
files create in their filecabinet successfully ??
I'll try to reproduce the problem from here.
Kevin.
|
| 1401.11 | Are you sure its in the profile?? | CHRLIE::HUSTON | | Wed Sep 16 1992 17:22 | 25 |
|
re .9
> 1. Yes - the log file sys$manager:OAFC$SERVER.log contains loads of
>RMS-E-RNF errors such as :
>
>10-SEP-1992 16:17:41.90 Server: OISDEV::"73=" Error: %RMS-E-RNF, record
>not found Message: CsiOpenRmsFileCab; error getting
>record:SARKIS.CATRIONA
this is caused by the FCS not being able to find the record
SARKIS.CATRIOINA in the A1 profile. Are you sure it is there?
We do a get by key and use that user name, this is saying that that
username does not exist in the profile.
Can you double check that the profile record exists for
SARKIS.CATRIONA, if it does I will need either the profile file to put
on my system or need to put a debug server on yours.
It sounds like the account creation messed up somehow.
--Bob
|
| 1401.12 | more answers | PAKORA::GMURRAY | Have Mercy I Cry City ! | Wed Sep 16 1992 18:06 | 34 |
|
Kevin,
An angle worth checking...
The problems are NOW limited to these "2.4/3.0" accounts, though it
WAS the case that a user with an ordinary "upgraded" account had
an identical problem. He is OK now. As a test, we've just created a
brand new account which is able to create into a shared drawer no
problem.
All the current accounts have been "upgraded", so it's difficult to
test the problem without restoring the old v2.4 files from tape.
And yes, the user with the problem can do everything including
create in her own filecabinet.
Bob,
Sorry, but SARKIS.CATRIONA is definitely in the PROFILE. I can see
her from SM MUA, and also if I do a
<get profil.user["sarkis.catriona"] from the Manager account.
I'll try copying PROFILE.DAT to CHRLIE::
Thanks,
Gil
|
| 1401.13 | Getting somewhere... | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Wed Sep 16 1992 18:17 | 25 |
|
Gil,
>>The problems are NOW limited to these "2.4/3.0" accounts, though it
>>WAS the case that a user with an ordinary "upgraded" account had
>>an identical problem. He is OK now.
OK - so there was a problem with the upgraded accounts but now
they're fine? Any chance you know the reasons as to how these
accounts resolved themselves ?
OK, so it's definitely isolated to users who were on 2.4, had
their profile removed, upgraded to 3.0 and then had their profile
added again.
Armed with this I'll take a look and a few things...
Kevin.
|
| 1401.14 | still searching | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Wed Sep 16 1992 18:36 | 10 |
|
Gil,
Also, when you created the V3.0 accounts using the V2.4 files - did
you achieve this via User Profile Addition (SM MUA C UP) ??
Kevin.
|
| 1401.15 | its there | CHRLIE::HUSTON | | Wed Sep 16 1992 19:31 | 12 |
|
Gil,
I copied the profile over and ran it on my system, you are right,
the profile record is there, and my server handled it just fine.
It read the record and pulled out all the info it needed.
I will contact you off line on the next step, unless Kevin comes
up with something first.
--Bob
|
| 1401.16 | Reboot appears to have cured :^} | KIRKTN::GMURRAY | Have Mercy I Cry City ! | Thu Sep 17 1992 12:10 | 35 |
|
Kevin, Bob,
I've looked back at the account (re-)creation logs to jog my memory.
The first job (SM MUA C CU) failed on "creating the ALL-IN-1
subdirectory ...", so I actually deleted the A1 subdir contents and
tried again. The second job completed OK, so perhaps the account angle
is a red herring ?
How the earlier troublesome account resolved itself I don't know, but
I do have some new news.
I spent some time tuning the test system yesterday, and after the
reboot and restart of ALL-IN-1, the user with the shared drawer problem
reported that the problem has gone away ! Sure enough, this is the case -
she can now create into any of the test shared drawers.
We've restarted ALL-IN-1 several times since the upgrade, so could
the problem have anything to do with the state of the system ? In
particular Global Sections/Pages had almost been exhausted.
Bob, if you still want to check out the system I'd be happy to
arrange access. We're in Scotland, so are probably 5 hours ahead in
time ?
I appreciate all the work on this problem,
Cheers,
Gil
|
| 1401.17 | ?? | IOSG::STANDAGE | Oink...Oink...Mooooooooooooooooooooooooooooooooo | Thu Sep 17 1992 14:10 | 20 |
|
Gil,
Now that the system is cured it's going to be difficult to speculate.
Global Sections/Pages (or lack of) might be a cause, but I'm not
convinced. As the errors were along the lines of "file not found" etc
I'm wondering if an ALL-IN-1 logical somewhere had been defined
incorrectly and the V3.0 startup has now rectified the problem.
Another possibility is that the server got itself into some kind of
state and stopping/restarting it fixed things up - but this again
is unlikely as the problem was user specific.
Well, all I can say is that if it ever happens again contact me and Bob
and we'll log in and take a closer look...
Kevin.
|
| 1401.18 | Must be that self-correcting FCS code :-) | CHRLIE::HUSTON | | Thu Sep 17 1992 14:48 | 26 |
|
Gil,
glad to hear it is cleared up, and as Kevin says, checking into it
now would be next to futile since we could only specualate and there
are to many variables.
Possible things a reboot could fix are:
logicals (as Kevin said)
server problem (but it didn't sound like it)
VMS account problems, like the directory stuff. This is all read in
when the user logs in, so if a change was made the user would need
to log out and back in to pick up any changes.
There are also some cached info, like drawer security, that is cached
in the FCS, it is timed out periodically. You should probably check
the time outs that the server has (SM manage servers menu will show
you this) they will be listed in seconds, make sure they all look
reasonable.
If it ever shows up then please let us know as soon as possible.
--Bob
|