× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Problem with QtmhCvtDb API
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Thu, 21 Jan 1999 16:55:29 -0600

I played with this idea in debug.  Before the call to the Read Standard
input API, I myself changed the input length before the call and still had
the same results.

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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.