Problems with i/o to console using $BRKTHRU

[Scot Newton]

We have a FORTRAN application that has used $BRKTHRU to write text based notices to a VT type application console for a number of years. Recently upgraded to OpenVMS 8.2 (on an Alpha DS25). We then noticed that if there are a series of event notices written to the console, we have to hit the carriage return to get the notices displayed. Almost as though i/o is locked up. Is this a known issue, or anyone else experienced this?

[John Gillings]

Scot,

Lots of questions...

Do you mean the terminal is the system console, or some other type terminal? What is it physically connected to (serial port, terminal server, ...?) What other activity is occuring on the target terminal?

What are the terminal characteristics (SHOW TERM). Who owns it and what privileges are used to access it?

What does the $BRKTHRU call specify for flags? What is are status and IOSB? Are you using $BRKTHRUW or $BRKTHRU? If $BRKTHRU how are you synchronizing?

[Scot Newton]

Hello John,
Thanks for offering to help, here is some more info. The term "console" I used was understandably misleading. This is not the OVMS system console. In fact, it is any session that we run our application from that we refer to as the "application console". So, it could be any session. We have run the application for years, and never experienced this until we upgraded to 8.2. Here is a code snip of the FORTRAN call that we believe to be the culprit:

! broadcast message without wait

BRDCST = SYS$BRKTHRU (
1 , ! efn
1 HEADERS(1:STRENDL(HEADERS))//
1 MSGS(1:STRENDL(MSGS)), ! msgbuf
1 TERMS, ! sendto
1 %VAL (brk$c_device), ! sndtyp
1 , ! iosb
1 %VAL (BLANKB), ! carcon
1 , ! flags,
1 , ! reqid
1 , ! timeout
1 , ! astadr
1 ) ! astprm

[Robert Brooks_1]

A couple of quick suggestions . . .

1) specify efn$c_enf as the event flag if you don't care about using an event flag.

2) use an IOSB and check its status (iosb$w_status), along with the status of the call itself.

3) review why you are using the asynch form of the service; I suspect that using the wait form (sys$brkthruw) is a better choice.


-- Rob