|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.