problem porting macro-32 code

[Ian Miller.]

attached is some macro32 code I wrote a while ago which I'm now trying to port alpha. The system crashes runnung the getbuf_k routine with an exception above astdel bugcheck.

Two questions
1. is it now possible to get the initial and current mailbox message quota of a mailbox without going into kernel mode code. If so part of this code is no longer needed.
2. Any pointers to what I'm doing wrong?

[John Eerenberg]

ian

> "1. is it now possible to get the initial and current mailbox message quota of a mailbox without going into kernel mode code. If so part of this code is no longer needed."

No. The way I read the code is that in order to get information from the ucb *and* guarantee its integrity, you have to raise ipl (i.e., the devicelock marco), read the data, then lower ipl (deviceunlock). Another reason is that ucb data structures are located in nonpagedpool which under normal considtions requires kernel mode to read the data (while in kernel mode, you can accidentally change the ucb data and that would have an interesting effect).

> "2. Any pointers to what I'm doing wrong?"
One thing is that you are calling $lock_page while in kernel mode. This is the wrong place to do this. You have to lock the code pages for getbuf_k *before* going executing the chmk. I am assuming you are calling getbuf_k from getmbx. This applies to both vax and alpha.

An exception above astdel could mean several things. You'll need to post wrapper code for calling your routines that duplicates the problem. When I can duplicate your error, then I help further.

john

[Antoniov.]

Ian,
HP Macro porting guide can help you
http://h71000.www7.hp.com/doc/73final/5601/5601pro_contents.html

Regards
@Antoniov

[Keith Parris]

I see where you lock the code down, but the code doesn't seem to also lock down the data area. And on Alpha, something new is that you also need to lock down Linkage Sections.

[Ian Miller.]

First to explain my question 1 further - I was wondering if there was a GETDVI item code or similar suppported way to obtain the values that my getmbx routine is reading.

Secondly I think the lock/unlock macros also lock the linkage sections however you may be on to something about locking the data. My understanding of these macros is that they need to be called before raising IPL but could be called from kernel or user mode - is this correct?

I think I would get a page fault with IPL to high bugcheck if the locking was wrong.

What I don't understand is the handling of the argument list and wonder if that's where the problem is (the movw instructions). Is it possible to get the MACRO-32 compiler to show the alpha instructions for each VAX instruction so when I'm looking at the crash dump I can see what's going on?

[Keith Parris]

I don't see any $GETDVI item codes that correspond to what you're getting. There is an item code which returns the message count in the mailbox -- perhaps that might be of some use. From the OpenVMS I/O User's Reference Manual at http://h71000.www7.hp.com/DOC/731FINAL/6136/6136pro_013.html we see "VI$_DEVDEPEND returns a longword field in which the two low-order bytes contain the number of messages in the mailbox. (The two high-order bytes are not used and should be ignored.)"

It is possible to get a listing of Alpha instructions generated by using MACRO/MIGRATION/MACHINE/LIST.

[John Gillings]

Ian,

Trying to solve the underlying problem...

I'm not sure why you need to know about the initial and current quotas.

I guess one possibility is to work out if you will block if a message is written? There are theoretical issues to do with timing windows which will beat you either way. Consider:

IF (enough space to write) THEN

Write mailbox
ELSE

Wait
ENDIF

You can avoid these using the IO$M_NOW and IO$M_NORSWAIT modifiers. If the mailbox is full, the I/O will fail with SS$_MBFULL instead of waiting in RWMBX state. You can then react to the condition appropriately.

As a general rule with potential allocation failures of any sort, it's always better to try, fail and react then to attempt to predict a failure.

Another general principle I'd recommend is abstraction. Rather than coding things like mailbox I/Os directly in the application, define an application API that implements whatever message passing you application needs. You may then implement it at a lower level with mailboxes, but you also have the freedom to use any another, better/cheaper/faster/more general mechanism should it become available, without changing the application.

[Ian Miller.]

this code is part of a utility to manipulate mailboxes from DCL. The MACRO32 getmbx is part of the SHOW MAILBOX command and obtains mailbox buffer quota data which does not appear to be obtainable anyother way. The setmbx code is part of the SET MAILBOX command which allows changes to mailboxes after they have been created. The utility also has commands to create, delete, read and write mailboxes. I wrote it orginally sometime before 1994. Now that I have an alphavms system at home I thought it would be fun and educational to get it to work again. When it works I intend to make it freely available. I also intend to add other things lifted from Niel Clift's MBOX utility such as the ability to look at messages in mailboxes without removing them. I discussed this with Niel a long time ago. It's just taken me a while to get around to it :-)

[John Eerenberg]

Ian,

> "My understanding of these macros is that they need to be called before raising IPL but could be called from kernel or user mode - is this correct?"

Yes. They could be. However, sooner or later your process could terminate too (page faulting in kernel mode is not tolerated by VMS); the rules say you should do the lock pages before calling a routine in kernel mode. The page locks should be for both all data and code that can be touched while in kernel mode.

Could you make the crash dump available?

john

[John Eerenberg]

> "When it works I intend to make it freely available."

Very nice!

[Hein van den Heuvel]

"1. is it now possible to get the initial and current mailbox message quota of a mailbox without going into kernel mode code"

Check out the comp.os.vms newsgroup
Rob Brooks (VMS Engineering) just requested suggestions for new getdvi item codes.

At this time the item is not yet visibile through google groups, but in an hour or so try:

http://www.google.com/groups?as_q=getdvi&as_ugroup=comp.os.vms&as_drrb=q&as_qdr=d&lr


hth,
Hein.

[Ian Miller.]

I will move the lock/unlock macros and see. I've emailed Rob Brooks.

[Ian Miller.]

after a quick play last night I've found that if I use a stack based argument list to sys$cmkrnl then things behave better - no crash and meaningful data!
So the invalid exception bugcheck was something to do with accessing the statically allocated arglist.

Can somebody explain what homing arguments is about. I get a informational message about
@8(ap)in getbuf_k that this requires homed arguments in the calling routing. It appears to work but I wondered what the informational message is trying to tell me.

[John Gillings]

Ian,

On Alpha the emphasis was on speed, so the calling standard defined argument passing to be done in registers, rather than the memory based mechanism used on VAX. So, the first 6 arguments are found in R16 through R21 (or, if floating point by immediate value, F16 through F21). If there are more than 6 arguments, the extras are passed on the stack.

However, there are some things you may want to do with an argument that won't work on registers. Your case "@8(AP)" is one example because you're taking an offset from the argument pointer. Another is passing an entire argument list to another routine:

CALLG (AP),G^AnoterRoutine

To achieve this, you need to "home" your argument list. It's really just copying the arguments to a stack based structure. It's easy to do, just add the clause "HOME_ARGS=TRUE" to your .CALL_ENTRY definition. This isn't done automatically because it's overhead that won't be necessary for the common cases (Alpha philosophy, don't do *anything* unnecessary).

Another option is to replace @8(AP) with (R17), but that will make your code Alpha dependent (it's possible the compiler is already doing what you mean - you're getting the informational to warn you to check the generated machine code to ensure it's really is doing what you want).

John Gillings

[Ian Miller.]

John - thanks for the explaination. I am using the home_args=TRUE. getmbx appears to work fine so I've updated for VMS V7.3-1 change (mailbox quota can be in a different longword location) and am now working on setmbx.