HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Behavior of the System Services in a VMS Alpha multiprocessor system

 
RajaSamy
Occasional Visitor

Behavior of the System Services in a VMS Alpha multiprocessor system

In our product, each module communicates with the Data Server module for requesting certain services.

In this regard, we need some info on the System Services in OpenVMS.

The System Service “SYS$ASSIGN” ends up giving an error “-SYSTEM-F-IVDEVNAM, invalid device name” (but the device name is valid).

The system call is as given below...
status = SYS$ASSIGN( &mbx_log_name, channel, 0, 0 );

And the error given is...
-SYSTEM-F-IVDEVNAM, invalid device name

By our analysis, the situation occurs only in a multi processor system.

Is there a difference in behavior of the System Services for a single processor & a multiprocessor system?

There is no consistence on the occurrence of this error, also not specific to any module which communicates to DS module.

Need details, on what scenario does the system could thorough this error (IVDEVNAM)?

4 REPLIES
Hoff
Honored Contributor

Re: Behavior of the System Services in a VMS Alpha multiprocessor system

Hello and Welcome to ITRC.

What OpenVMS Alpha version?

The $assign system service call is used all over the place within OpenVMS and within a gazillion customer applications; Occam's Razor points straight at this application code. There are more than a few calls to $assign in existence after all, and a systemic problem should have been seen many times at many sites.

As for the trigger for the error, the device name is not valid. I'd look at the device name argument, and I'd look at where the logical name is defined, and whether the application has access to it.

Add some debugging code here, displaying the contents of the logical name; the logical name translation, and a call to $getdviw to get the device characteristics, etc. If the error is transient, then capture the error if/when it arises and dump out the data.

Have you tried reproducing the error with a cut-down and standalone version of the sys$assign code? Simplify the problem, and divide the problem space up.

Symmetric Multiprocessing (SMP) does tend to bring latent application bugs out of hiding and into the open. These can be timing conditions. Race conditions. Failures to interlock. Different completion timings. Etc. See the old OpenVMS Ask The Wizard area topic (1661) for a list of common coding bugs. http://www.hp.com/go/openvms/wizard

And you posted just one line of C code. There's no information on the set-up to the $assign call, and no indication of the argument definitions, nor what's stored in the arguments. Without some details, it's tough to tell what happened here.

FWIW, according to the current documentation, I see five arguments to $assign, but only four are shown in your code. (Are you on an older version of OpenVMS Alpha here?)

And as a suggestion and though the call will default to PSL$C_USER if you're in user-mode, I'd still tend to specify that.
John Gillings
Honored Contributor

Re: Behavior of the System Services in a VMS Alpha multiprocessor system

Raja,

$ASSIGN works. There is no difference between single and multi processor systems. Serveral billion invocations per day around the planet can't be wrong!

You haven't shown the definition for mbx_log_name. It should be a string descriptor with the correct length. Remember that system services will use the string EXACTLY as you send it. They don't do anything "nice" like trimming or ignoring whitespace. Be aware that the length of a mailbox name can vary, depending on the unit number. Your code must deal with that correctly and send $ASSIGN the correct string, no more, no less.

To see what $ASSIGN sees, try this. Run your program under DEBUG. Set a break point, or step to the $ASSIGN. Then STEP/INTO. You should see a message like this:

stepped to SHARE$SYS$SSISHR+117B0
%DEBUG-I-SOURCESCOPE, source lines not available for %PC in scope number 0

(if you don't see this, keep issuing STEP/INTO commands until you step into the service itself).

Now examine the argument - this is best done in HEX
DBG> SET RADIX HEX

Now check the descriptor

DBG> ex/quad @r16
0000000000020004: 0002000C010E0008

Now the fields. Length first

DBG> EXAMINE/WORD @R16
0000000000020004: 0008

Now the class and type fields:

DBG> EXAMINE/WORD
0000000000020006: 010E

This should probably be 010E, meaning class scalar, type text.

Now use the length determined above to see the exact string:

DBG> EXAMINE/ASCII:8 @(@r16+4<0,20,0>)
000000000002000C: 'MBA1234:'

If you have any excess or missing characters, then $ASSIGN will CORRECTLY return IVDEVNAM.

If you can't work out what's wrong, please post the declaration of mbx_log_name, the code that gives it a value, and a transcript of the above DEBUG commands.
A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Behavior of the System Services in a VMS Alpha multiprocessor system

RajaSamy,

I concur with both Hoff and John, the problem almost certainly lies in the application code (99.99999999999999999999999999% certain, I will allow for the possibility of a bug, but it is extraordinarily unlikely).

I would be more suspicious of the values in the call to SYS$ASSIGN, particularly, as has already been noted, in the descriptors.

- Bob Gezelter, http://www.rlgsc.com
David Jones_21
Trusted Contributor

Re: Behavior of the System Services in a VMS Alpha multiprocessor system

You haven't shown the definition for mbx_log_name. It should be a string descriptor with the correct length. Remember that system services will use the string EXACTLY as you send it. They don't do anything "nice" like trimming or ignoring whitespace.

That's not exactly true, $ASSIGN will usually ignore stuff after the first colon.

If it is happening when multi-threaded, I'd look you have a synchronization error or possible false sharing (word tearing corrupting your descriptor).
I'm looking for marbles all day long.