- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: LAT port cannot work on IA64
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
тАО11-21-2008 01:12 AM
тАО11-21-2008 01:12 AM
Re: LAT port cannot work on IA64
Make sure you check that status and print it if the low bit is clear, it may give a clue.
Jur.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2008 03:25 AM
тАО11-21-2008 03:25 AM
Re: LAT port cannot work on IA64
I am starting back at the beginning.
There are TWO status returns that must be checked when doing ANY of the QIO and related functions (e.g., QIO, ENQ, GETJPI, etc.). The first, returned as a function return from the call itself is whether or not the directive was processed successfully.
Getting a successful result in the function return implies nothing about the eventual result of the request. The only result that matters is the contents of the IOSB status value. Buffer contents (and the remainder of the IOSB) are only valid in the context of the IOSB status.
I have seen many cases where the code erroneously confuses the two status values. When something does not work, usually the IOSB has not been checked correctly.
In years past, I have seen many of these and slightly similar cases. Way back (RSX-11M Version 3-3.1), I found a problem in a piece of code that had done a QIO (without a wait) and worked. It turned out that the Version 3.0 terminal driver forced a wait during terminal IO, the Version 3.1 driver relaxed that provision, causing the code to fail. It was the code, not the underlying OS. Wait was always documented as obligatory.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2008 07:00 AM
тАО11-21-2008 07:00 AM
Re: LAT port cannot work on IA64
This:
if (($status & 1) != SS$_NORMAL) { failure code }
is an odd construct. It creates correct code, but I don't think it was what was expected, and it is unlikely to work for any condition other than SS$_NORMAL. The following is a more typical approach:
if ( !$VMS_STATUS_SUCCESS( $status )) { failure code }
dviread() treats one successful condition as success, and all other successful conditions and all errors as failure.
As I had guessed in my first reply, iosb is not handled correctly here which means the code is unstable at best. Others have commented on this. This is a central problem with this code; it's just not known if this code is stable.
The UpdLog function is not logging the interesting part of the iosb, either. For failures, the contents of iosb[0] is far more interesting than iosb[1].
Some of that code would be better in a state machine, whether using lib$table_parse or otherwise. Large if-then-else-if-else-then-if sequences just never work out.
Depending on what you are doing here, connections out and even modem dial-out is possible with the SET HOST /DTE command that is available at DCL. (Though I don't know what goes in the "{tailored code}" section.)
Volume 4B? That's a documentation reference I haven't seen in a while. This code was probably ported across from OpenVMS VAX, and most VAX boxes are typically uniprocessors and are generally much less asynchronous than are Alpha or Itanium boxes.
The code has a memory leak in GetJParm().
Continuing after a malloc failure in GetJParm() -- attempting to continue after any malloc() failure in any code anywhere -- is generally a bad idea.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-21-2008 12:53 PM
тАО11-21-2008 12:53 PM
Re: LAT port cannot work on IA64
code was ported from old VAX to AXP in nineties and now I wanto to port on IA64.
Now I change code and test iosb[0] as most of you said to me.
I'll report you the result.
Thanks.
Antoniov
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2008 02:51 AM
тАО11-22-2008 02:51 AM
Re: LAT port cannot work on IA64
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2008 06:47 PM
тАО11-22-2008 06:47 PM
Re: LAT port cannot work on IA64
QIOW (and the xxxW variants of may other system services) calls an implicit sys$synch to wait for completion. I think, but am not certain, that sys$synch spins on the IOSB, so if something else sets the event flag, sys$synch won't get fooled. Perhaps something else put something into the IOSB, then set the event flag, and then *cleared* the IOSB again. (Do you have any async I/O or sys$getxxx calls running in the background?)
So what I would look for is 1) a typo (specifying the wrong IOSB in the call or accidentally sharing it with some other call), 2) a typo where you are actually calling sys$qio instead of sys$qiow, 3) creating the IOSB on the stack and then returning before it is used or examined (this is a common bug in asynchronous code, IMHO, but is unlikely here, since Antoniov is using QIOW and appears to be creating and using the IOSB locally), 4) sharing an event flag (though I think $synch defends against that), or 5) accidently using the asynchronous version of some other system service elsewhere in the program (e.g. sys$getjpi, sys$getdvi, etc. instead of sys$getjpiw or sys$getdviw.)
It's most likely a bug that has always been there, but was rarely or never seen on VAXes or Alphas because the timing was different. I always enjoy smashing a long-standing bug, so you have this pleasure to look forward to! :-)
HTH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2008 05:09 AM
тАО11-23-2008 05:09 AM
Re: LAT port cannot work on IA64
Fwiw,
Jur.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2008 09:55 AM
тАО11-23-2008 09:55 AM
Re: LAT port cannot work on IA64
I changed in source code the check for iosb[0] instead of $status. Now the return status is 0x22C that's mean time-out.
So the return code is true but I don't yet solve.
I carefully watched this old code (from VAX); I didn't remember that code set DSR flow control. Now I try with standard XON/XOFF control and I'll report you the result.
TIA
Antoniov
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-23-2008 05:26 PM
тАО11-23-2008 05:26 PM
Re: LAT port cannot work on IA64
>John, you have been exposed to OpenVMS
>Engineering folks too long. It has poluted
>your thinking. I'm sure you are techinally
>correct, but if you are, then IMHO OpenVMS
>is all wrong.
Normally I'd agree with you. I/O should be device independent, so you don't need to care about the physical device. However, LAT is different because there LAT device exists even when there is no connection to the physical device.
So, consider the serial port out on the terminal server. There may be many LTA devices pointing at it, from any number of nodes. Numerous processes may have issued READ $QIOs against one or more of those LTA devices. Suppose a character appears at the port, where should it be sent?
Some event must initiate a connection between the LTA device and the terminals server. Perhaps posting a READ should create the connection, but it doesn't. A design decision we're stuck with. A WRITE operation will create the connection, so this type of application will work (but unsupported) if the initial operation on the LTA device is a WRITE.
That's why in the general case you need the IO$M_LT_CONNECT.
- « Previous
-
- 1
- 2
- Next »