Re: CRTPF appears in HTTP subsystem when using CGIDEV2 -- WEB400

Although this was one of my concerns in my original post, I
guess I didn't think it would be possible, or at least hard
to do.  But, as we have found it is.

In my CGIDEV2 manual I specifically state and use the
clrhtmlbuffer subprocedure as the first piece of every
application.  This won't stop a looping program from having
the problem, but it should help.

Thanks for looking into this, Mel.

Brad
www.bvstool.com

On Thu, 09 May 2002 16:45:43 -0500
 Mel Rothman <mel@rothmanweb.com> wrote:
> I couldn't tell from the job log snippet what the problem
> was, but I suspected
> it was a problem with WrtSection's dynamic storage.  So,
> I modified a copy of
> one of my sample programs to loop and the symptoms
> appeared.  By looking at the
> second level text of the messages, I located where in
> WrtSection the failure
> occurred.  CGIDEV2's built-in debugging facilities also
> found the problem and
> dumped the PSSR into the CGIDEBUG file.
>
> I'll add to my to-do list your request for a way to find
> out how much data has
> been stored in WrtSection's buffer.  I'm thinking of
> doing it by adding a second
> *nopass parameter to the WrtSection subprocedure.  Since
> there is already one
> *nopass parameter (whether to not add a newline character
> to each line), you
> would have to code all three parameters.  For example:
> WrtSection('top main' :
> *off : byteswritten).
>
> I can't make any promises as to when I'll get to it.
>
> The ClrHtmlBUffer subprocedure already exists (was part
> of the September 2001
> update).  If you don't have it, refresh your copy of
> CGIDEV2 from the easy400
> site.
>
>
> Mel Rothman, CGIDEV2 Author
> IBM eServer Custom Technology Center (CTC), Rochester,
> Minnesota
> http://www-1.ibm.com/servers/eserver/iseries/service/ctc/
> http://www.easy400.ibm.it/en
>
>
>
> Michael Skvarenina wrote:
> >
> > Excellent!  I'm not sure how you could tell from that
> joblog snipet what we
> > probably exceeded the 16MB limit but I'd suspect you
> are correct that the
> > programmer caused an endless loop.
> >
> > I agree also that 16MB is large enough.  We've had
> situations were we
> > intentionally wanted to send more than 16MB but this
> just takes too long all
> > around to be crafting the data then sending it to the
> browser.
> >
> > What I would like however is a means to check the
> buffer size so I can
> > determine when to stop filling it.  As an example, we
> have a program where
> > the user build a query by selecting some parameters.
> It's not a SQL query
> > but basically a set of fields s/he sets on a form then
> we build the results
> > in our RPG program.  Sometimes however they select too
> much data and we end
> > up filling up the buffer or having long delays before
> the page is returned.
> > What would be great is a procedure that returns the
> current size of the
> > buffer so we could decide when we've sent enough and in
> the event that they
> > exceed our pre-determined size, we would interrupt the
> building of the data
> > and perhaps return "Too much data, the result has been
> truncated" or
> > something like that.
> >
> > And if we can determine the size, then can we also just
> clear the buffer
> > without sending?  In this scenario we may just want to
> replace the entire
> > buffer with a message that tells they they chose too
> mcuh data rather than
> > giving then a partal display with the error message at
> the end.
> >
> > Is that possible Mel?
> >
> > ----- Original Message -----
> > From: "Mel Rothman" <mel@rothmanweb.com>
> > To: <web400@midrange.com>
> > Sent: Thursday, May 09, 2002 4:54 PM
> > Subject: Re: [WEB400] CRTPF appears in HTTP subsystem
> when using CGIDEV2
> >
> > > I just replicated the problem here in Rochester.
> > >
> > > First, a little background.
> > >
> > > Each call to WrtSection adds its output to a
> dynamically allocated buffer.
> > > Storage is expanded, as required, with the realloc
> operation code.  When
> > > WrtSection receives a request to write the *fini
> section, it sends the
> > > accumulated data to the browser.
> > >
> > > The maximum amount of storage that can be allocated
> is 16 megabytes.  If
> > more
> > > than 16 MB is  accumulated before *fini is received,
> the symptoms you
> > > encountered occur.
> > >
> > > In your case, either there is an endless loop
> containing one or more calls
> > to
> > > WrtSection, or the program was intentionally written
> to output that much
> > data.
> > >
> > > When I wrote WrtSection, I didn't anticipate that
> anyone would send more
> > than 16
> > > MB intentionally, and did not check for this
> condition.
> > >
> > > Although I could add code to handle this, it is
> probably a better idea to
> > leave
> > > it as it is to force a runaway loop to fail.
> > >
> > > By the way, this is the first time this problem has
> been reported, which
> > seems
> > > to support my initial supposition that a 16 MB buffer
> is enough.
> > >
> > > Mel Rothman, CGIDEV2 Author
> > > IBM eServer Custom Technology Center (CTC),
> Rochester, Minnesota
> > > http://www-1.ibm.com/servers/eserver/iseries/service/ctc/
> > > http://www.easy400.ibm.it/en
> > >
> > >
> > >
> > > Michael Skvarenina wrote:
> > > >
> > > > Well we do have a job sitting on a CRTPF right now
> and here's what's in
> > the
> > > > job log.  We are wondering what the message about
> QZHBCGI may be about.
> > > >
> > > > Any ideas?
> > > >
> > > > The length requested for storage allocation is out
> of range.
> > > > RPG status 00425 caused procedure WRTSECTION in
> program
> > CGIBIN/CGISRVPGM2
> > > >   to stop.
> > > > Pointer not set for location referenced.
> > > > Suspected program QZHBCGI not found.
> > > > Object QZHBCGI in *LIBL type *PGM not found.
> > > > Added a symptom to the symptom string that was not
> valid.
> > > > *** QQQOPTIONS DATA AREA NO LONGER SUPPORTED.
> > > > *** USE THE NEW QUERY OPTIONS QAQQINI FILE SUPPORT.
> > > > Problem log updated.
> > > > Output queue QSCAPAROQ in QSC2857377 already
> exists.
> > > > File QAPDFCDP in library QSC2857377 already exists.
> > > > File QAPDFCDP not created in library QSC2857377.
> > > >
> > More..
> > > > ----- Original Message -----
> > > > From: "Richard B Baird"
> <rbaird@esourceconsulting.com>
> > > > To: <web400@midrange.com>
> > > > Sent: Thursday, May 09, 2002 9:38 AM
> > > > Subject: Re: [WEB400] CRTPF appears in HTTP
> subsystem when using CGIDEV2
> > > >
> > > > >
> > > > > Micheal,
> > > > >
> > > > > I've had this problem too.  I don't remember
> exactly what caused it,
> > but
> > > > > the CRTPF you are seeing is the http server doing
> it's thing with
> > ab-end
> > > > > errors.
> > > > >
> > > > > Look for job logs and dumps in wrksplf under the
> http user ids
> > (QTMHHTTP?,
> > > > > QTMHTTP1?).   you will probably find many.
> browse through them and
> > I'll
> > > > > bet you will find your problem.
> > > > >
> > > > > Rick
> > > > >
> > > > > ----original message------
> > > > > I'll admit this message is a bit vague because I
> don't have many
> > details
> > > > > but from time to time our entire CGI HTTP system
> stops meaning all our
> > > > > users get an HTTP 404 error and when we look into
> the QHTTPSVR
> > subsystem
> > > > > we'll find one of the server jobs doing a CRTPF.
> Since at this point
> > > > we've
> > > > > begun to rely on the HTTP apps working 24x7 we
> simply cancel the
> > offending
> > > > > job and all our clients can then proceed to
> connect.
> > > > >
> > > > > This usually only happens during new program
> development but we havn't
> > > > been
> > > > > able to isolate what causes it.
> > > > >
> > > > > Has anyone else seen this and if so what was your
> solution.
> > > > >
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/web400
> or email: WEB400-request@midrange.com
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
>

Bradley V. Stone
BVS.Tools
www.bvstools.com