What does the return status of 20 mean from a SYS$QIOW?

[Eric Boyer]

J_STATUS = SYS$ASSIGN('_NTY109:', I_CHANNEL,,)I_FUNCTION = IO$_TTY_PORT .OR. IO$M_LT_CONNECT
J_STATUS = SYS$QIOW(,
1 %VAL(I_CHANNEL),
2 %VAL(I_FUNCTION),
3 I_IOSB,
4 ,,,,,,,)

I get a 20 from the SYS$QIOW call and I am wondering what that means?

[Craig A Berry · Accepted solution]

$ write sys$output f$message(20)
%SYSTEM-F-BADPARAM, bad parameter value

It doesn't like one of your parameters. You might start by checking the return status from SYS$ASSIGN to see if you really got a channel assigned. Examining all the parameters in the debugger immediately before the call is the best way to see whether you're really giving it what you think you're giving it.

[Ken Robinson]

Is the a decimal 20 or a HEX 20. If it was a Hex 20, then the error is

%SYSTEM-W-NOPRIV, insufficient privilege or object protection violation

Check that you have the proper privileges to do what you want.

Ken

[Hoff]

Do consider verifying j_status (as an odd -- the $assign worked -- or as even -- it failed) value, before continuing; check the low bit of the $assign return. Failure to check return values can derail subsequent processing in strange and interesting ways.

Here's an example of calling $qio from Fortran:

http://h71000.www7.hp.com/wizard/wiz_6642.html

Here's an example of the LAT connection from Fortran:

http://vmsone.com/~decuslib/vmssig/vms94a/dsj/comm.vax

That file is a Fortran source file; ignore the .vax extension and open it as text.

Stephen Hoffman
HoffmanLabs LLC

[Dean McGorrill]

hi Eric,
hoff's example is a good one, careful of
the placeholder commas. As suggested, compile and link with the debugger and examine
the parameters just before stepping into the
qio call (or assign for that matter) good luck -Dean

[Eric Boyer]

The assign seems to work fine. I get a one return from the assign. When an bogus device is enter, I get a zero. So, i think it is not my problem.

Is there any special compile or linking that needs to be done.

Currently I just use fortran and link.

Any suggest on what I can try to verify assign works beside looking at return status.

[Jim_McKinney]

Migrating from LAT to IP?

Looks like your using a LAT modifier on the QIO to a telnet device - don't think that's permissible. My recollection (which could be off) is that the LAT modifiers were only valid on LAT devices. If that's the case then it's likely the cause of your "bad parameter" return status from the QIO.

[Richard Brodie_1]

If you have the TELNET device already mapped to a remote port, you might find that omitting the $QIOW is the correct fix.

[Hein van den Heuvel]

>> The assign seems to work fine. I get a one return from the assign. When an bogus device is enter, I get a zero.

fwiw, Zero is NOT a valid return status for a system service on OpenVMS. Low-bit zero is, but there has to be something in those other bits to indicate, notably 316 = IVCHAN

btw... was that 20 hex or decimal?
I suspect decimal for: %SYSTEM-F-BADPARAM, bad parameter value
The parameter being the function code.

Hein.

[Richard Brodie_1]

If you get a zero return status, you probably are implicitly typing SYS$ASSIGN as a float, and using a junk status from F0.

[Jur van der Burg]

As noted before, you're using a LAT function code on an NTY (= tcpip) device. No wonder you get a badparam error in return. It's a decimal number (20), since SS$_BADPARAM has a -F- severity and not -W-.

Jur.

[Eric Boyer]

For your comments, this line is my problem

I_FUNCTION = IO$_TTY_PORT .OR. IO$M_LT_CONNECT

What should be it for an NTY Device?

Thanks for everyone help. As you can see, I never work with OpenVms before.

Eric

[Volker Halle]

Eric,


What should be it for an NTY Device?


This depends on what you want this code sniplet to achieve !

Volker.

[Eric Boyer]

I would like to connect to it?

[Jim_McKinney]

As Richard Brodie previously suggested, just try removing the two lines of code that assign the function codes and perform the QIOW - depending upon what you're trying to do that's likely all it'll take.

[Hoff]

Y'all might want to ring up Process software.

NTY is a Multinet control device. Here are the programming details:

http://www.process.com/tcpip/mndocs52/PROGRAMMERS_REFERENCE/httoc.htm

The $qio functions are here:

http://www.process.com/tcpip/mndocs52/PROGRAMMERS_REFERENCE/Ch03.htm#E29E4

Here's the set-up command for NTY device:

http://www.process.com/techsupport/multinet/788/17.html

Based on what I see on a quick read of the MultiNet documentation, the NTY device is probably already connected to the telnet device.

One of the Process folks may be reading here, or you might want to see if there's a preferred sequence for replacing LAT with Multinet over at the Process site. NTYCP is apparently deliberately set up to mimic LATCP.

What I don't know is if there's a $qio that allows you to establish the telnet connection to the printer under program control, if you're looking to do that. Otherwise, you can use a static NTY mapping.

Stephen Hoffman
HoffmanLabs LLC

[Eric Boyer]

The solution is you do not have to connect to an NTY device unlike an LAT device, which I bet everyone knew except for me.

The only step is to assign the channel before the read.

Thanks for the help.

Eric