Need sanity check on return from EZASOKET call

I've got a simple TCP/IP app running on OS/390 (not sure of the compiler
version details) that leverages EZASOKET calls to do it's work.

Under some circumstances a READ will have a RETCODE of "000000000J"
(according to a debug DISPLAY line I use to p at this record.)
RETCODE is a Pic S9(8) Binary.

I read this as binary 11010001 (assuming big-endian EBCDIC) or decimal
209.  The logic in the code sees this as a negative number (I'm assuming
that first "1" in the binary agrees with this.)  Since this indicates an
error condition, when I check ERRNO it contains ECONNNRESET.

I expect some of these assumptions may be incorrect.

I'm trying to figure out who or what is resetting this connection during
a READ that otherwise works just fine, but want to make sure that my
understanding above makes some sort of sense.

Comments?

> Under some circumstances a READ will have a RETCODE of "000000000J"
> (according to a debug DISPLAY line I use to p at this record.)
RETCODE is a Pic S9(8) Binary.

An 'S9(8) BINARY' is likely to be a 4 byte integer (though it could be
anything).  You have shown 10 characters.  Which of the 10 is the 4
bytes ?

> I read this as binary 11010001 (assuming big-endian EBCDIC) or
> decimal 209.

EBCDIC 'J' is hex 'D1' or decimal 209.

> The logic in the code sees this as a negative number (I'm assuming
> that first "1" in the binary agrees with this.)

The first '1' bit does no such thing.  If it is BINARY then the first
bit of _4_ bytes is the sign bit while you are looking at the 25th bit,
the first 24 bits being off.

It is much more likely that the field is S9(8) DISPLAY and the value is
-1 in eight bytes.  'J' is an 'overpunched' 1 making the value
negative.

I am not a TCP/IP coder, but according to:

[url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1e110/2.5.9.2.2[/url
]

when RETCODE is not zero, you are supposed to check ERRNO for problem
determination.


--
Bill Klein
wmklein <at> ix.netcom.com
"clvrmnky" <clvrmnky-uunet@coldmail.com.invalid> wrote in message
news:sS4ie.6174$5u4.21124@nnrp1.uunet.ca...
> I've got a simple TCP/IP app running on OS/390 (not sure of the compiler
> version details) that leverages EZASOKET calls to do it's work.
>
> Under some circumstances a READ will have a RETCODE of "000000000J"
> (according to a debug DISPLAY line I use to p at this record.)
> RETCODE is a Pic S9(8) Binary.
>
> I read this as binary 11010001 (assuming big-endian EBCDIC) or decimal
> 209.  The logic in the code sees this as a negative number (I'm assuming
> that first "1" in the binary agrees with this.)  Since this indicates an
> error condition, when I check ERRNO it contains ECONNNRESET.
>
> I expect some of these assumptions may be incorrect.
>
> I'm trying to figure out who or what is resetting this connection during
> a READ that otherwise works just fine, but want to make sure that my
> understanding above makes some sort of sense.
>
> Comments?

On 16/05/2005 3:11 PM, William M. Klein wrote:
> I am not a TCP/IP coder, but according to:
>
>  [url]http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1e110/2.5.9.2.2[/
url]
>
> when RETCODE is not zero, you are supposed to check ERRNO for problem
> determination.
>
Not quite.  When RETCODE is negative (really, -1) you check the ERRNO.
I have the ERRNO.  I'm just trying to wrap my head around overpunched
negative values.

Positive values are the number of bytes you got.  0 means you got
everything and can move on.

On 16/05/2005 3:01 PM, Richard wrote: 
>
> RETCODE is a Pic S9(8) Binary.
>
> An 'S9(8) BINARY' is likely to be a 4 byte integer (though it could be
> anything).  You have shown 10 characters.  Which of the 10 is the 4
> bytes ?
>
This PIC is the IBM recommended way right out of the TCP/IP programming
redbook to get the number of bytes a READ gets (or an indication
something went pear-shaped.)

As for why I get 10 chars back on Display RETCODE -- I'll leave that to
the COBOL gods.  There are a number of hands this value passes through
before I see it.  My guess is that the Display line needs to be properly
formatted (or formatted at all), or the output from the job does
something to the value.

It really doesn't matter, as it looks like it is zero-padded on the
left-hand side.  Actually displaying this value is for debugging only.

> 
>
>
> EBCDIC 'J' is hex 'D1' or decimal 209.
>
> 
>
>
> The first '1' bit does no such thing.  If it is BINARY then the first
> bit of _4_ bytes is the sign bit while you are looking at the 25th bit,
> the first 24 bits being off.
>
I'm used to the 1- and 2s-complement way of doing things.  I was
approaching this from the known to the unknown.

> It is much more likely that the field is S9(8) DISPLAY and the value is
> -1 in eight bytes.  'J' is an 'overpunched' 1 making the value
> negative.
>
I have verified this is the case.  I've never had to care about the
representation of a negative number in this program before.  This field
is not "used" for anything except debugging and testing against "< 0".
A little reading of "overpunched" values clears this up a bit.

If taking a S9(8) Binary field and using this as an identifier for a
Display implies S9(8) DISPLAY, then I accept.  It is certainly not
specified that way in the code.

Ok, so now I know for sure that EZASOKET READ is returning -1,
indicating an error, and that my code is correctly catching this case.

Thanks.

On 16/05/2005 3:01 PM, Richard wrote: 
>
> RETCODE is a Pic S9(8) Binary.
>
> An 'S9(8) BINARY' is likely to be a 4 byte integer (though it could be
> anything).  You have shown 10 characters.  Which of the 10 is the 4
> bytes ?
>
This PIC is the IBM recommended way right out of the TCP/IP programming
redbook to get the number of bytes a READ gets (or an indication
something went pear-shaped.)

As for why I get 10 chars back on Display RETCODE -- I'll leave that to
the COBOL gods.  There are a number of hands this value passes through
before I see it.  My guess is that the Display line needs to be properly
formatted (or formatted at all), or the output from the job does
something to the value.

It really doesn't matter, as it looks like it is zero-padded on the
left-hand side.  Actually displaying this value is for debugging only.

> 
>
>
> EBCDIC 'J' is hex 'D1' or decimal 209.
>
> 
>
>
> The first '1' bit does no such thing.  If it is BINARY then the first
> bit of _4_ bytes is the sign bit while you are looking at the 25th bit,
> the first 24 bits being off.
>
I'm used to the 1- and 2s-complement way of doing things.  I was
approaching this from the known to the unknown.

> It is much more likely that the field is S9(8) DISPLAY and the value is
> -1 in eight bytes.  'J' is an 'overpunched' 1 making the value
> negative.
>
I have verified this is the case.  I've never had to care about the
representation of a negative number in this program before.  This field
is not "used" for anything except debugging and testing against "< 0".
A little reading of "overpunched" values clears this up a bit.

If taking a S9(8) Binary field and using this as an identifier for a
Display implies S9(8) DISPLAY, then I accept.  It is certainly not
specified that way in the code.

Ok, so now I know for sure that EZASOKET READ is returning -1,
indicating an error, and that my code is correctly catching this case.

Thanks.