Re: CRTPF appears in HTTP subsystem when using CGIDEV2

Brad, there is no need to use ClrHtmlBuffer as the first piece of every
application.

WrtSection logically clears the buffer whenever *fini is written or
WrtHtmlToStmf is used.

ClrHtmlBuffer was only recently added to CGIDEV2 specifically to allow the
programmer to discard the buffered output in order to start over again.  It's
kind of like a rollback and WrtSection('*fini') is like a commit.


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

Brad Stone wrote:
>
> 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
> _______________________________________________
> 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.