| 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 |
Cross posted in IOSG::ALL-IN-1 & IAMOK::DTRDIG
VMS V5.4-2
DTR V5.1
CDD V4.3-2-0
ALL-IN-1 V2.4
A customer is seeing the following problem when invoking DTR from
All-in-1:
Unexpected DATATRIEVE call status from routine DTR$INIT
If I do Gold W, the error is:
%OA-W-DTRCALLFAIL, unexpected DATATRIEVE call status from routine DTR$INIT
-SYSTEM-F-NOPRIV, no privilege for attempted operation
If I then issue DTR again, I get the following:
Unexpected DATATRIEVE stall point 0
with the message
Stall point in DAB invalid
being flashed up momentarily.
They had also had problems calling DTR from dcl, where they were
getting
%SYSTEM-F-NOPRIV, No privilege for attempted operation
-SYSTEM-S-NORMAL, Normal successful completion
%SYSTEM-F-NOPRIV, No privilege for attempted operation
and ending back at the $ prompt, OPCOM was also giving the following:
%%%%%%%%%%% OPCOM 23-APR-1992 14:11:55.45 %%%%%%%%%%%
Message from user AUDIT$SERVER on PUPAE
Security alarm (SECURITY) and security audit (SECURITY) on PUPAE, system id: 420
81
Auditable event: Attempted file access
Event time: 23-APR-1992 14:11:55.42
PID: 20802D97
Username: SMITH_R
Image name: $5$DUS6:[ALLIN1.LIB_SHARE]OA$MAIN.EXE
Object name: _$5$DUS4:[CDD$DICTIONARY]CDD.DIC;12
Object type: file
Access requested: CONTROL
Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation
which is like the CDD/DTR security alarm problem, but much more
severe. We solved this by installing the DTR32.exe (& eventually
DTR32FM & DTR32TD images) image with SYSPRV. So DTR from dcl is
now ok.
I don't know anything about the ALL-IN-1 side of things, ie how
DTR is called from there, whether it's similar to calling DTR from
DCL or if it's not quite as simple than that. Also if installing
DTR32 with sysprv, does anything further have to be done so that
ALL-IN-1 sees that it's installed with SYSPRV
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 560.1 | Verify CDD$DEFAULT is valid | BUFFER::VICKERS | Perfect is the enemy of good | Thu Apr 23 1992 19:04 | 12 |
I have seen similar results when the DATATRIEVE default library
setting, CDD$DEFAULT, is not set to an existing node in the library.
You might want to verify any other DATATRIEVE specific logicals as well
as the ALL-IN-1 interface to DATATRIEVE does seem a bit less forgiving
than is the DCL interface during initialization.
Good luck,
don
P.S. Don't forget to be careful with keeping ALL-IN-1 (and DATATRIEVE)
in all caps so jerks like me don't complain about the trademark. :')
| |||||
| 560.2 | Security alert | IOSG::TALLETT | Just one more fix, then we can ship... | Thu Apr 23 1992 20:32 | 11 |
Installing Datatrieve with SYSPRV sounds like a security hole
to me. Can't I just knock up a record layout for, say, SYSUAF.DAT
and gaily write to the UAF file?
Seems like you should change the protection on the CDD file, but
then again, I don't know if that is a problem (but it doesn't
sound as big a problem as a rampant DTR image with SYSPRV).
Regards,
Paul
| |||||
| 560.3 | Logicals seem to be ok | KERNEL::WILESL | Louise Wiles, TP/IM Support | Fri Apr 24 1992 13:59 | 14 |
Re: .1
Thanks Don,
I checked CDD$DEFAULT, it's set to CDD$TOP, from ALL-IN-1 I spawned out
to DCL level, from here I checked with sho log DTR* & CDD*. Is this the
best way to get this info?
Thanks,
Louise.
PS Sorry about the ALL-IN-1 caps mistake, but I actually entered the
note prematurely in my haste ;-)
| |||||
| 560.4 | Use SET WATCH FILE to check for protected files | BUFFER::VICKERS | Perfect is the enemy of good | Fri Apr 24 1992 23:58 | 19 |
Louise,
I assume that you're still getting the 'no privilege' message.
The next step that I would take would to use
$ SET WATCH FILE/CLASS=MAJOR
to get an idea of which files are being accessed the point of the
error.
It may be that there are some other dictionary files which are in
CDD$TOP or something like that.
Showing the logicals is the only way I know to verify the settings so
you seem to be set in that regard.
Hang in there,
don
| |||||
| 560.5 | A problem with system startup | KERNEL::WILESL | Louise Wiles, TP/IM Support | Mon Apr 27 1992 10:33 | 15 |
Thanks for all the replies.
I've had a call from them to tell me that they had got a new system
startup which was starting the layered products up in batch rather than
running them sequentially. When they reverted to their original
sequential startup, things were all ok.
I've yet to have a look at their new 'improved' startup, but my feeling
is that if things are being started off in batch then one product may
not have completed its startup before another startup begins.
Thanks anyway,
Louise.
| |||||