|
The example code posted in .0 is only a very small fraction of the
code involved in an RMS open call, and far less than would be required
to determine the cause of the problem. (The really interesting part
of the open call is the contents of the FAB and any associated data
structures.)
And given that a variant logical name table is in use, make certain
the logical name table is visible to the searchlist used for this RMS
call -- please provide the (full) output of a SHOW LOGICAL command
on the logical name(s) in this table, showing the translations of the
logical names, and the table attributes.
Have the customer do some basic debugging in the program -- try a
call to something like sys$trnlnm. Use the debugger on the program
to see if what is being passed via the FAB/NAM/XAB/etc. is valid --
it's quite easy to misprogram an RMS call, and there are a variety of
ways it can be misprogrammed. Also, see if the customer has this image
installed with privileges or as a protected image or with a subsystem
identifier -- if so, this will change the behaviour of the logical name
translations. (...Only privileged logical names and entries will be
translated, and all logical names and all logical name tables "on the
way" to the translation must be trusted.) Also use the esa and rsa
structures in the FAB to determine the target file name built from
the RMS sys$open call. And -- obviously -- look for any differences
between the VAX and the Alpha code. (Be aware that DEC C for OpenVMS
Alpha pads data structures to a natural alignment, where DEC C for
OpenVMS VAX and VAX C do not generally pad structure members -- this
can cause structures to appear correct, but to fail to operate as
expected -- see the member alignment qualifier and #pragma, and see
the DEC C conference for some previous discussions.)
The RMS notes conference is located at VMSZOO::RMS_OPENVMS.
|
| re .1
>Also, see if the customer has this image installed with privileges or as a
>protected image or with a subsystem identifier
As far as I know this would by default affect only logical names used in
image activations. However it is the case that software written for any
of those three environments may have to specify LNM_MODE in the FAB
in order to guarantee integrity.
re .0
Consequently you would want to verify whether the FAB for the $OPEN call
sets this field and if so verify what acmodes are applicable to *all*
logical names needed for the translation (starting with LNM$FILE_DEV in
either the process or system directory).
Failing that, more good old fashioned debugging is needed, starting
with a small standalone program that just does the $TRNLNM.
WAG: typo in logical name or name table search list?
|
| re .0
>When he tries to open a file by using a logical name, that is defined in a
>private logical name table, which is placed, (in the order of the logical name
>table search list),
Which logical name table search list? Logical name table search lists
are defined by logical names. Different parts of the system use
different ones. You might look for differences between the 2 systems in
those logical names.
(As far as I know, there are no significant differences between the
logical name system services on VAX and Alpha or between V6.1 and
V6.2, so I first would look for differences in the way the two
customer environments are set up.)
Check from the process environment in which the customer is trying to
run the program. Use
SHO LOG/FULL/TABLE=LNM$PROCESS_DIRECTORY [/ACCESS_MODE=exec]
to see any process-specific definitions and
SHO LOG/FULL/TABLE=LNM$SYSTEM_DIRECTORY [/ACCESS_MODE=exec]
for systemwide ones.
In particular, I'd check LNM$FILE_DEV (both supervisor and exec mode
definitions) and maybe LNM$DCL_LOGICALS as well. (I'm not sure whether
DIR and COPY translate before trying to open or rely on RMS, which I
believe uses LNM$FILE_DEV). If you see no differences there, also check
the names at the next level down - LNM$PROCESS, LNM$JOB, LNM$GROUP,
LNM$SYSTEM.
hope this helps,
ruth
|