[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: result from recv() missing imbedded blank (occasionally)



Unless I'm missing something obvious, this question isn't related to 
HTTPAPI or FTPAPI?

How do you know how much data to receive??  Or to put it another way, 
how do you know you've received all of the data for a particular "return 
string"?    You should have logic in your program that's calling recv() 
in a loop until you've got the whole message...   And, most likely, if 
there's a problem with a character being stripped, it's in that routine 
that concatenates the data from the multiple recv() calls.

The notion that this is occurring in the recv() API itself seems a 
little absurd to me.  If recv() were randomly dropping bytes, you'd be 
having problems all over the place.   Telnet/Tn5250 wouldn't work.  HTTP 
wouldn't work.  FTP wouldn't work... you'd have major problems all over 
the place if the core network routines in the operating system weren't 
working.

The problem is almost certainly in your code.  (Though it could be in my 
routines if you're using them -- but you don't seem to be??  and I 
haven't had this problem with HTTPAPI or FTPAPI...)


On 8/10/2011 5:34 PM, Koester, Michael wrote:
> I've been using the sockets routines from the LIBHTTP set to send commands to telephone switch equipment, and it has been serving our needs nicely.  One little quirk appears on occasion that messes me up, though.  To verify that the switch has properly updated a subscriber's phone service, I send it a "QUE STN" command, and then parse the reply for the expected features.  These features are expected to appear with spaces between them, just as what would display in a telnet session used by the service center techs.  In a return string containing "... CND PRS2 6745 CNAM ACR ...", I can easily know that the CND, CNAM, and PRS2 features are on the line.  Every once in a while, a space is missing, which makes it difficult to find SUPR and CNAM in the string "... UAR 1 CND SUPRCNAM ACR ...".
>
> The string comes back from recv() and is translated to EBCDIC before writing it to the "text" column (3000A Varying) in my Switchlog table.  And if it helps, when the space is missing, it appears to consistently be absent from either position 134 or 136 of the "text" column.  (Hmmmm...)
> My program has the following:
>       D RecBuf          S           3000A
>       D RecLen          S             10I 0
> ...
>
>         recbuf = *blanks;
>         rc = recv(sock: %addr(recbuf):3000:0);
>         reclen = rc;
>
>         // translate the line of text into EBCDIC to make it readable
>         if rc>  0;
>            Translate(reclen: recbuf: 'QTCPEBC');
>            LogSwitchActivity(FromSwitch : recbuf);
>         endif;
> ...
>
>       P*--------------------------------------------------
>       P LogSwitchActivity...
>       P                 B
>       D LogSwitchActivity...
>       D                 PI
>       D  FromWhere                    12A
>       D  LogText                    3000A   OPTIONS(*VARSIZE)
>       D                                     const
>
>        /free
>         exec sql
>          insert into SwitchLog
>                   (Order,
>                    Direction,
>                    TFStime,
>                    Text)
>             VALUES(:ServiceOrder,
>                    :FromWhere,
>                    NOW(),
>                    trim(:LogText))
>             with nc;
>
>         return;
>        /end-free
>       P LogSwitchActivity...
>       P                 E
>
> I could add some complexity to my %scan statements in my parsing routine, but if there's a better fix to the root cause, I'd rather not hack it up.  Running at OS version 6.1.
> Any ideas as to what is causing this?
>
> Many thanks.
>    Michael Koester
>
>

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------