- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: problem porting macro-32 code
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-03-2004 07:08 AM
тАО05-03-2004 07:08 AM
problem porting macro-32 code
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?
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-03-2004 09:41 AM
тАО05-03-2004 09:41 AM
Re: problem porting macro-32 code
> "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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-03-2004 07:00 PM
тАО05-03-2004 07:00 PM
Re: problem porting macro-32 code
HP Macro porting guide can help you
http://h71000.www7.hp.com/doc/73final/5601/5601pro_contents.html
Regards
@Antoniov
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2004 04:31 AM
тАО05-04-2004 04:31 AM
Re: problem porting macro-32 code
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2004 09:29 AM
тАО05-04-2004 09:29 AM
Re: problem porting macro-32 code
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?
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2004 01:03 PM
тАО05-04-2004 01:03 PM
Re: problem porting macro-32 code
It is possible to get a listing of Alpha instructions generated by using MACRO/MIGRATION/MACHINE/LIST.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2004 03:14 PM
тАО05-04-2004 03:14 PM
Re: problem porting macro-32 code
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-04-2004 08:54 PM
тАО05-04-2004 08:54 PM
Re: problem porting macro-32 code
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2004 02:10 AM
тАО05-05-2004 02:10 AM
Re: problem porting macro-32 code
> "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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-05-2004 02:12 AM
тАО05-05-2004 02:12 AM
Re: problem porting macro-32 code
Very nice!