Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

simple code fails on open vms 8.2 while the same works on 7.3

 
jeet_2
Occasional Visitor

simple code fails on open vms 8.2 while the same works on 7.3

status = sys$qio( TERM_EFN, term, IO$_READVBLK, &iosb, NULL, NULL,
&accmsg, sizeof( ACCDEF2 ), 0, 0, 0, 0 );

fails while closing the mailbox with the termination messg. term here is a short int type.
2 REPLIES
Uwe Zessin
Honored Contributor

Re: simple code fails on open vms 8.2 while the same works on 7.3

The code is not that simple and including the error code would give us additional information to help you.

Unfortunately it is not clear how experienced your are with QIOs (no offense intended), but you do realize that this is an asynchronous QIO which very likely completes after the return to your main program.

With such little information I'd guess you have found a race condition.

.
Hein van den Heuvel
Honored Contributor

Re: simple code fails on open vms 8.2 while the same works on 7.3

>> simple code fails on open vms 8.2 while the same works on 7.3

How does it fail? R0 return status? IOSB return status? What does the sync code after the async QIO look like? $WAITFR? $WTFLOR? $SYNC?. Is the EFN checked as well as the iosb to make sure the call is finished?
Where does it fail? This call or a future $deasgn?

>> term here is a short int type

Doe it work again when you use an int?

Like Uwe says, your report is a little short to make useful comments on.

It is good to have the report. Great, thank you.
It is good to know that a change in 8.2 seems to create a problem for a program that seemed to work before.

It may have worked, but it may have been broken all along anyway, and you were just unlucky it happened to work while being developed.

For example: the IO channel argument is documented (7.30 to be an unsigned longword. With the side note that only the lower 16 bits are used. Now if you pass it a short it, it will be sign extended which for certain channel values will set the upper bits. I would call such program broken, even though the upper bits were, at one point, supposed to be ignored. Why risk it?

Hope this helps some,
Hein.