- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- System Service sys$qiow
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
тАО08-29-2007 02:39 PM
тАО08-29-2007 02:39 PM
System Service sys$qiow
I have a process which hang (or its waiting indefinitely) at the system function call SYS$QIOW.
status = SYS$QIOW(0, mbx_chan, IO$_WRITEVBLK, iosb, 0, 0,param->bg_device, strlen(param->bg_device) + 1, 0, 0, 0, 0);
At the time of hang:
Value of mbx_chan is 880
and Value of param->bg_device BG2172
I don't know much about QIOW, what I know is that QIOW will queue the I/O request and then it will wait until the write virtual block is written.
Can any one help me in telling
1) what could be the possible reason of QIOW function waiting indefinitely.
2) What QIOW is writing and where it is writing.
3) Can we have a timeout flag with QIOW system call.
Regards,
Ajaydec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 03:35 PM
тАО08-29-2007 03:35 PM
Re: System Service sys$qiow
Lots of stuff here. The answers depend on the device you're writing to. I'll assuming it's a mailbox.
If this code has ever worked before, I'd guess that whatever is supposed to be reading the mailbox isn't working properly.
1) Reasons for QIO waiting
First the "expected" reasons for hanging. A mailbox write will wait for the message to be read. If you want it return immediately after placing the message in the mailbox add the modifier IO$M_NOW.
If the mailbox is full, the write will hang in RWMBX state until there's enough space for the message. If you want to avoid that add the modifier IO$M_NORSWAIT (you'll have to check the IOSB for errors and take some sensible action if the mailbox is full).
There are a few unexpected reasons. One is a timing issue - if your EFN (0) is cleared between the time the write completes and returning control to your process you'll hang until something else sets the EFN. It's unlikely for a WRITE, but just in case, use event flag EFN$C_ENF to avoid any possibility of different threads treading on each others event flags.
2) assuming the programmer isn't deliberately trying to obscure things, I'd guess it's writing to a mailbox. It's writing the string pointed to by bg_device.
3) timeout. yes and no. Some drivers have a timeout built in. Just add modifier IO$M_TIMEOUT and set the correct parameter. The mailbox driver doesn't implement timeout, so you have to roll your own. Simplest mechanism is "crossed ASTs". Start by issuing a $SETIMR for an AST that issues a $CANCEL against your mbx_chan, then calls $WAKE. Use your buffer address as the RQIDT. Now call $QIO (now $QIO not $QIOW) specifying an AST that cancels the timer with $CANTIM on your RQIDT, and cals $WAKE. You can now do other stuff, or $HIBER. When the I/O completes, or the timer triggers you'll be woken. Check the IOSB for the $QIO to see what happened. It should be SS$_NORMAL or SS$_CANCEL. Alternatively use a $QIOW followed by the $CANTIM. Similar effect, but less flexible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 07:02 PM
тАО08-29-2007 07:02 PM
Re: System Service sys$qiow
The code is working fine for years, but now only its giving error after a load has been increased on the product.
Regards,
Ajaydec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-29-2007 09:13 PM
тАО08-29-2007 09:13 PM
Re: System Service sys$qiow
Something like "TCPIP SHOW DEVICE BG2172/FULL" will show you the socket endpoints.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 11:27 AM
тАО08-30-2007 11:27 AM
Re: System Service sys$qiow
>The code is working fine for years
If I had a dollar for every time I've heard "It's been working for years"... ;-)
One programmers motto is:
"Insunt interdum menda in eo quod est efficax"
which translates to:
"There are sometimes flaws in that which is efficacious."
In other words: "Just because it (seems to) work, doesn't mean it's right".
Increasing the load, upgrading a CPU, changing versions, or any number of other environmental changes can, and in this case probably has, revealed a hitherto unknown bug. When you're dealing with interprocess communications, there can be subtle timing windows which, if you fall through can cause deadlocks.
You need to determine exactly what the device is. I've asumed a mailbox, but you need to look for the $ASSIGN or $CREMBX that writes mbx_chan, find out what's at the other end, and see what it's doing at the time your process is hanging.
$QIO and the mailbox driver are incredibly well exercised code paths in OpenVMS. Think in terms of BILLIONS of operations per day on thousands of systems around the planet. Although they're not necessarily completely bug free, the chances of you finding a bug in $QIO is extremely slim, so your first assumption must be a bug in your code.
re: Richard,
I'm assuming that the BG string is being written to a mailbox because the channel is called mbx_chan. Some other process or thread will read it and act on it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 06:57 PM
тАО08-30-2007 06:57 PM
Re: System Service sys$qiow
* Check whether the socket is one way (write_only, in this case) or two-way (read + write). In the latter case, be sure the socket is not in a blocked state due to an unfinished read.
* Does the other side actually read the socket? It might be that the receiver's buffer is full and the message cannot be delivered.
* If the other side had died, your sending socket may still think it's connected. The previous messages will never be read and your sending program's buffer will be full.
To prevent QIO from hanging, what you could do is the following sequence:
* Set a timer for say 2 seconds, to set an event flag on expiration.
* Start QIO - not QIOW - specifying a completion AST and IOSB. The AST routine will set a flag on completion (other than the tiems flag).
* Wait for any of the two eventflags to be set.
* Check the event flag. If the timer flag is set, QIO timed out. If the QIO completion ST, sending the message succeeded.
In all cases, check the IO status block.
next, take appropiate action. (There will surely be away to take a look to the socket status - for instance "BUFFER FULL").
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 09:57 PM
тАО08-30-2007 09:57 PM
Re: System Service sys$qiow
Now I came to know that process has written something in mailbox and now it is waiting for other process to read that information from the mailbox. Can I know which process is to to read from mailbox.
Regards,
ajaydec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-30-2007 11:42 PM
тАО08-30-2007 11:42 PM
Re: System Service sys$qiow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2007 12:06 AM
тАО08-31-2007 12:06 AM
Re: System Service sys$qiow
Do a $ TCPIP SHO DEV and you'll see the BG devices, both the local and remote addresses and ports, and the related services - if any exsist.
You might find a clue. The remote address and port should be fileld and valid. Do the same command on the system that _should_ handle the messages and what's remote on one system should be local on the other, vice versa.
What you need to do is find out what other program is needed to process the data and if it active and properly working. If it has stopped for some reason, it might be needed to restart the sending program in order to re-establish the connection. It might be worthwhile to find out why that program stopped.
If there is no program to pick up the message and there is no method of signalling it went wrong, your program will wait, and wait, and wait... With mailboxes, teh sending program would enter RWMBX state.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2007 01:57 AM
тАО08-31-2007 01:57 AM
Re: System Service sys$qiow
Wim