HP OpenVMS Systems

Ask the Wizard

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

What is the proper definition for sys$crembx?

The Question is:

Dear Wizard:

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.

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?

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:

           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.