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

Hi, Bob.

No, I didn't think a user space object made sense since I didn't need to 
preserve any of the output HTML from one execution to the next.  I realize it 
could save some memory, but in most cases it would be less than 50K bytes.

I use user spaces in CGI programs that need to save and restore state and they 
work extremely well.  I generally use a based data structure whose subfields 
represent all the state I need to save and restore.  Then, I create the space 
using a randomly generated name, and retrieve the space's pointer, which I use 
for the data structure.  I write the user space's name into a hidden HTML form 
field which I use upon input to retrieve the pointer again.  This way, a single 
instance of a CGI program can process requests from multiple users.

Mel

Bob Cozzi wrote:
>
> 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.
> >
> >
>
> _______________________________________________
> 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.