× 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.



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.
> >
>
> _______________________________________________
> 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.