 |
» |
|
|
|
Ask the Wizard Questions
FORTRAN Language: System service
The Question is:
Hello.
This particular problem has been driving me crazy for the
last couple of days. I have been using the following call
to sys$crembx for the last few weeks to communicate
istatus = sys$crembx(,ichan,,,mask,,'ftp$mailbox')
between two programs. The call was working well until a
few days ago, when it suddenly stopped working! I was
working on another section of the code, and I assumed I
modified something that caused the failure. However, I
have tried everything I can think of to fix it, with no
success. I went back to the "concept" program I wrote before
deciding on this particular method, and it no longer works
either!
The variables are declared as follows:
ichan and mask are integer*4. Mask is initialized to 65294
in a data statement. I tried setting mask to various
values, but they do not impact the mailbox protection
values. What does impact the mailbox protection values
are the sizes of the variables actually specified in the
variable list. When mask is a longword,and only ichan,
mask, and the logical name are specified the following
device information is obtained with
show device /full ftp$mailbox
by spawning from the debugger after the mailbox has been
created.
show device ftp$mailbox/full
Device MBA2446: is online, record-oriented device, shareable, mailbox device.
Error count 0 Operations completed 0
Owner process "" Owner UIC [GEMSDEV,AMO]
Owner process ID 00000000 Dev Prot S:RWLP,O:WP,G:LP,W:WL
Reference count 1 Default buffer size 256
The size of the buffer is also impacted by which arguments
are included in the system call.
I *must* not have the correct call definition for
sys$crembx. But, I *cannot* explain why it worked until a
few days ago and suddenly stopped. As far as I know there
have been no system modifications. I have tried specifying
all the arguments in the list, but sys$signal gives an
error when I try to include them all. Something about an
invalid status flag. There is no status flag in the
definition I have.
sys$crembx(prmflg byte u, chan word, maxmsg longword u,
bufquo longword u, promask longword u, acmode longword u,
lognam character-coded text string, flags longword u)
If I leave mask out of the argument call list, the program
does not fail until the part I am actually working on.
However, show device/full indicates that my mailboxes
all have world and group RWLP.
The questions are: What is the proper definition for
sys$crembx? Has it been changed over the last few
releases? I think the version on the machine I am on
(VAXTM1 Research Triangle Park, North Carolina) is 5.5.
But I only think so because I found an upgrade script
that suggested 5.5 was the current version in sys$system.
Can the system operator prevent me from assigning a
non-default mailbox protection by changing my account?
Thank you for your help,
The Answer is:
I assume you're code is in FORTRAN.
From $ HELP SYSTEM $CREMBX, the arguments are:
SYS$CREMBX [prmflg] ,chan ,[maxmsg] ,[bufquo] ,[promsk]
,[acmode] ,[lognam] ,[flags]
So, strictly speaking, you require another trailing comma for the
flags argument. The protection mask argument that you're having
trouble with is defined as:
promsk
VMS Usage: file_protection
type: longword (unsigned)
access: read only
mechanism: by value <*****
...
Now, since FORTRAN passes arguments by REFERENCE, your apparent mask
value is NOT being passed, rather it's *address* is being interpreted
as the protection mask. This may explain the "sudden" change in
behaviour. If the address of "mask" in a particular incarnation of your
program just happened to look like a protection mask which includes
your desired accesses, then the program would appear to work. Any
modification to the program (including changes in compile and/or link
qualifiers) might move the mask variable, thus changing the resultant
protection mask. If you wanted, you could figure out the address
from the protecction fields you're getting on your mailbox.
Try changing your code to:
istatus = sys$crembx(,ichan,,,%VAL(mask),,'ftp$mailbox',)
Most of the programming errors I see occur at routine interfaces. You
should ensure that arguments match in position, data type and passing
mechanism.
|
