Question - was RE: Problem with QtmhCvtDb API -- MIDRANGE-L

Hi Richard.

Again, thanks for the informative info.  I got these APIs working with
CONTENT_LENGTH as you described and as show in the Web Programmers Guide.

Anyhow, I am working on an RPG as CGI article for Midrange Computing.  Their
records have shown this problem to be a bug.  In my article, I wish to
include a small sidebar, or dedicate a paragraph or two to this
"misconception".  I would like to credit you as a source for this
information.  If this is ok, could you let me know how you want your name
and title to be shown in the article?

Thanks again.

Bradley V. Stone
Taylor Corporation - OASIS Programmer/Analyst   
bvstone@taylorcorp.com


> -----Original Message-----
> From: rgh@us.ibm.com [SMTP:rgh@us.ibm.com]
> Sent: Thursday, January 21, 1999 3:26 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Problem with QtmhCvtDb API
> 
> To set the record straight.  This is NOT a bug in the QtmhCvtDb API.   The
> solution you describe may make your symptom of the 0D25 causing the -4 for
> invalid data go away by pushing it into a dummy variable.
> 
> Any program that reads a fixed number of bytes from standard input will be
> a problematic CGI program.  The V3 and V4 HTTP servers use two different
> systems for standard input and output.  The V3 server uses the AS/400
> library file system.  The V4 server uses stream files.   Attempts to read
> more than CONTENT_LENGTH will pick up these newlines that are part of the
> stream file but not in your data since the newlines are beyond the
> CONTENT_LENGTH.
> 
> Every HTTP server tells a CGI program the length of the data in standard
> input using CONTENT_LENGTH.   On a UNIX web server, attempts to read more
> than CONTENT_LENGTH will cause the CGI to loop forever waiting for input
> since the server pipes standard input directly to the stream.  There is no
> end of file on a stream.
> 
> Every CGI program should first check that the method is POST and then
> check
> the CONTENT_LENGTH.  Only data with the POST method has data in standard
> input.  The content length has how much data to read from standard input.
> There is a sample C and RPG program on AS/400 technical studio and in the
> web master guide that has correct CGI programs.   These program have
> worked
> correctly since V3R2 without modification.
> 
> AS/400 Telnet Server/Client, WSG, LPD Server development
>  Richard G. Hartmann       AS/400 TCP/IP & Server Development
>   IBM T/L: 852-6731          IBM Mail: Richard Hartmann/Endicott/IBM
>   Phone:   607-752-6731  Internet e-mail: rgh@us.ibm.com
> 
> ------------------------------
> 
> Date: Wed, 20 Jan 1999 08:50:50 -0600
> From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> Subject: RE: Problem with QtmhCvtDb API
> 
> Ted Holt from Midrange Computing brought to my attention a Tech Talk item
> concerning this, and it answered my question.  Apparently in V4R1 and up
> there is a bug on this API when reading standard input.  The fix is to put
> one more "dummy" variable at the end.
> 
> Bradley V. Stone
> Taylor Corporation - OASIS Programmer/Analyst
> bvstone@taylorcorp.com
> 
> 
> > -----Original Message-----
> > From:   rgh@us.ibm.com [SMTP:rgh@us.ibm.com]
> > Sent:   Tuesday, January 19, 1999 8:04 PM
> > To:     MIDRANGE-L@midrange.com
> > Subject:     RE: Problem with QtmhCvtDb API
> >
> > It is important to remember CGI programs that read data from the
> standard
> > input stream, only CONTENT_LENGTH bytes should be read from standard
> > input.
> > Attempts to read more than CONTENT_LENGTH bytes produces unpredictable
> > results.   In this case, you have 0D25.
> >
> > In the technical studio on the AS/400 web page there are some RPG
> snippets
> > that will convert the character CONTENT_LENGTH to decimal to be used as
> > the
> > number of bytes to read parameter for QtmhRdStIn.
> >
> > When the last field is numeric and you read more bytes than
> > CONTENT_LENGTH,
> > you will get a -4 RC from QtmhCvtDb.   Your other application is working
> > because the last field is character and the CRLF are just characters and
> > not invalid for character data.    Although they would probably be
> invalid
> > if you used the data as a search parameter.
> >
> >  AS/400 Telnet Server/Client, WSG, LPD Server development
> >  Richard G. Hartmann       AS/400 TCP/IP & Server Development
> >   IBM T/L: 852-6731          IBM Mail: Richard Hartmann/Endicott/IBM
> >   Phone:   607-752-6731  Internet e-mail: rgh@us.ibm.com
> >
> --------------------------------------------------------------------------
> > -
> > ------
> >
> > Date: Tue, 19 Jan 1999 10:53:31 -0600
> > From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com>
> > Subject: RE: Problem with QtmhCvtDb API
> >
> > I just found another peculiarity.
> >
> > It's throwing a hex '0D25' at the end of my data (I'm guessing CRLF).
> > Should it be doing this?  Could this be causing a problem or are these
> the
> > delimiter characters that it uses to signal the end of the data stream?
> >
> >
> >
> > Bradley V. Stone
> > Taylor Corporation - OASIS Programmer/Analyst
> > bvstone@taylorcorp.com
> >
> >
> > > -----Original Message-----
> > > From:   Stone, Brad V (TC) [SMTP:bvstone@Taylorcorp.com]
> > > Sent:   Tuesday, January 19, 1999 8:28 AM
> > > To:     'MIDRANGE-L@midrange.com'
> > > Subject:     RE: Problem with QtmhCvtDb API
> > >
> > > Hi Stan.
> > >
> > > Yes.. trust me, this is the first thing I checked... and then checked
> > > again... and again.. and again...
> > >
> > > I have since changed it for now, but it still doesn't work.  I am
> having
> > > the
> > > user simply input one catalog number to run the report on.  It is now
> > > skipping this field and still returning a -4.
> > >
> > > I know it's got to be something simple, because I have another
> > application
> > > that works just fine.
> > >
> > >
> > > Bradley V. Stone
> > > Taylor Corporation - OASIS Programmer/Analyst
> > > bvstone@taylorcorp.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: Staffan Lofberg [SMTP:staffan.lofberg@netorom.se]
> > > > Sent: Tuesday, January 19, 1999 3:46 AM
> > > > To:   MIDRANGE-L@midrange.com
> > > > Subject:   Re: Problem with QtmhCvtDb API
> > > >
> > > > Brad
> > > >
> > > > Are you sure that you have the field CPTITM correctly spelled in the
> > > > HTML-input?
> > > >
> > > > Staffan Lofberg
> > > >
> > > > "Stone, Brad V (TC)" wrote:
> > > >
> > > > > Hi Folks.
> > > > >
> > > > > Doing a little RPG/CGI programming and am having a problem.  I am
> > > trying
> > > > to
> > > > > convert variables, but it is having problems on the last field and
> > > > returning
> > > > > a status code of -4 (means: An error occurred while converting the
> > CGI
> > > > input
> > > > > string to the DDS defined data types. The data may or may not be
> > > > usable).
> > > > >
> > > > > I can't find any other errors anywhere else.  The data structure
> > gets
> > > > filled
> > > > > with the info needed except for the last one.  The DS looks like
> > > this...
> > > > >
> > > > > CPDIV           3,0     Division Number
> > > > > CPSUBDIV        3,0     Subdivision Number
> > > > > CPFCAT          3,0     From Catalog
> > > > > CPTCAT  3,0     To Catalog
> > > > > CPFITM          14      From Item
> > > > > CPTITM          14      To Item
> > > > >
> > > > > The user inputs a from and to catalog, and a from and to item
> > number.
> > > > These
> > > > > are read in with the QtmhRdStin API.  The variable string looks
> > good,
> > > > and
> > > > > everything is filled but the To Item number field on the Convert
> to
> > > DB.
> > > > >
> > > > > Any ideas?  Return code of -4 doesn't tell me much.
> > > > >
> > > > > Bradley V. Stone
> > > > > Taylor Corporation - OASIS Programmer/Analyst
> > > > > bvstone@taylorcorp.com
> > > > >
> > > > > +---
> > > >
> > > > ------------------------------------------------------------------
> > > > Netorom AB              Phone +46 40 6712272
> > > > P.O. Box 9160           Fax   +46 40 940128
> > > > S-200 39  Malm�         http://risc.netorom.se
> > > > Sweden                  mailto:staffan.lofberg@netorom.se
> > > >
> >
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---