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

Mel,

Did you consider using a UserSpace object (wich is also limited to
16Meg) for the HTML buffer?
I'm wondering what the performance difference would be once the space
was created.---Just wondering.

Bob Cozzi

> -----Original Message-----
> From: web400-admin@midrange.com
> [mailto:web400-admin@midrange.com] On Behalf Of Mel Rothman
> Sent: Thursday, May 09, 2002 6:19 PM
> To: web400@midrange.com
> Subject: Re: [WEB400] 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.
> _______________________________________________
> 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.
>
>