Has anyone run into an error in the installation of MySQL where the tar
cannot be extracted because of a lack of space?

I've tried the straight installation of MySQL and updating to the newest
version of ZEND that has it bundled. In both cases I receive the
following:

tar: 0511-197 mysql -5.0.51a--i5os-power-64bit/bin/mysqld-debug: Cannot
write data extracted with the tar command: There is not enough space on
the server.

I'm at 11% DASD utilitzation out of a total of 1199G. I can't figure what
could be causing the problem.



web400-bounces@xxxxxxxxxxxx wrote on 02/06/2008 12:27:17 PM:

Send WEB400 mailing list submissions to
web400@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/web400
or, via email, send a message with subject or body 'help' to
web400-request@xxxxxxxxxxxx

You can reach the person managing the list at
web400-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of WEB400 digest..."


*** NOTE: When replying to this digest message, PLEASE remove all
text unrelated to your reply and change the subject line so it is
meaningful.

Today's Topics:

1. Re: Question about QZSRCGI. (Peter Connell)
2. QzhbCgiParse: Error: Can't read CONTENT_LENGTH bytes from
stdin. Using CGIDEV2 (mike@xxxxxx)
3. Slow Page Load Using CGIDEV2. (Terry Anderson)
4. Re: Slow Page Load Using CGIDEV2. (Richard ECUYER)
5. Re: Slow Page Load Using CGIDEV2. (Haas, Matt (CL Tech Sv))
6. Re: Slow Page Load Using CGIDEV2. (Mike Cunningham)
7. Re: Slow Page Load Using CGIDEV2. (Larry Kleinman)
8. Re: Slow Page Load Using CGIDEV2. (Crispin Bates)
9. Re: Slow Page Load Using CGIDEV2. (Haas, Matt (CL Tech Sv))


----------------------------------------------------------------------

message: 1
date: Tue, 5 Feb 2008 15:55:28 +1100
from: "Peter Connell" <Peter.Connell@xxxxxxxxxxxxxxxxx>
subject: Re: [WEB400] Question about QZSRCGI.

Bent Ronne,

I've just subscribed so this email is related to but probably not
attached to the relevant thread.

With Apache, the HTTP server will indeed reserve a job just for you to
service your requests, but only if you configure the server do that your
log in authenticates against the OS/400 system password file, (the one
used for green screen sign-on).
Similarly, other users will be assigned jobs of their own, which means
that there is an analogy with regular green screen jobs.
However, the communication still remains stateless, it is just the job
that is persistent.
But it does not pay to rely on accessing anything left in QTEMP from a
previous request since Apache may fire up more than one job for you if
it is attempting to service another of your requests before the previous
one has completed.

Since allowing web users to use OS/400 user profiles may raise security
issues, I would recommend that a server configured this way is
restricted to be accessible only on your internal network (intranet).
Having a large number of such users would pose performance issues
similar to having many green screen users.

Of course, you should know that CGIDEV2 is not the only method.
IBM provided Net.data as a CCI language long before then which lets you
call your native iSeries programs and run CL commands right from your
web page script, as well as many other goodies. It has never failed us
yet as a simple and rapid way to develop web pages, without having to
resort to compilng RPG etc unless necessary.

Cheers, Peter



#####################################################################################
This correspondence is for the named person's use only. It may
contain confidential or legally privileged information, or both. No
confidentiality or privilege is waived or lost by any
mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You
must not disclose, copy or rely on any part of this correspondence
if you are not the intended recipient. Any views expressed in this
message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of Veda
Advantage. If you need assistance, please contact Veda Advantage on
either :- Australia 133124 or New Zealand +64 9 367 6200


------------------------------

message: 2
date: Tue, 5 Feb 2008 14:35:14 -0500
from: <mike@xxxxxx>
subject: [WEB400] QzhbCgiParse: Error: Can't read CONTENT_LENGTH bytes
from stdin. Using CGIDEV2

Has anyone come to a resolution on this issue? We are on V5R3M00 and see
the
same messages logged;

The requested heap space operation is invalid.
The pointer parameter passed to free or realloc is not valid.
QzhbCgiParse: Error: Can't read CONTENT_LENGTH bytes from stdin..


_____________________________________
Mike Scherer
e2e Logistics Consulting Inc.




------------------------------

message: 3
date: Wed, 6 Feb 2008 10:31:13 -0600
from: "Terry Anderson" <terrya@xxxxxxxxxxxx>
subject: [WEB400] Slow Page Load Using CGIDEV2.

Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a
web page. The first time the user takes the option, the page takes
about 60 seconds to load. After that, the page loads in 2 - 3
seconds. Has anyone seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975




------------------------------

message: 4
date: Wed, 06 Feb 2008 17:53:17 +0100
from: Richard ECUYER <recuyer@xxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a
web page. The first time the user takes the option, the page takes
about 60 seconds to load. After that, the page loads in 2 - 3
seconds. Has anyone seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975





------------------------------

message: 5
date: Wed, 6 Feb 2008 11:56:03 -0500
from: "Haas, Matt (CL Tech Sv)" <matt.haas@xxxxxxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

There's a setting you can specify in the httpd.conf to prestart the CGI
jobs.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@midrange.
com] On Behalf Of Richard ECUYER
Sent: Wednesday, February 06, 2008 11:53 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a
web page. The first time the user takes the option, the page takes
about 60 seconds to load. After that, the page loads in 2 - 3
seconds. Has anyone seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.




------------------------------

message: 6
date: Wed, 6 Feb 2008 12:01:30 -0500
from: Mike Cunningham <mcunning@xxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

How does the CGI app get its' data? Traditional SETLL/READE or SQL?
SQL might be reusing a index that gets build on the first call or it
could just be that the system has all the data in RAM on the second
call and makes the process faster. I have some batch jobs which I
run that might take 2-3 minutes on the first run and only 1 on any
subsequent runs done shortly after. I have always attributed this to
the data being in RAM. It is also that the problem is on the client
end. The first call will need to launch the browser and all of its
dll's (if your windows) the second one will be faster if windows has
all that loaded. You could try an experiment from two different PCs.
Have one run the CGI app and then a few seconds later have the
second do the same. If the first time speed is the same for both it
would make me think it's a client side issue. If the first is slow
and the second fast it is a server side issue

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@midrange.
com] On Behalf Of Richard ECUYER
Sent: Wednesday, February 06, 2008 11:53 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a
web page. The first time the user takes the option, the page takes
about 60 seconds to load. After that, the page loads in 2 - 3
seconds. Has anyone seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.



------------------------------

message: 7
date: Wed, 6 Feb 2008 12:01:06 -0500
from: Larry Kleinman <larry@xxxxxxxxxxxxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.


I see a similar delay going from green screen to a Net.Data macro. Takes
about 20 seconds the first time, less than 5 seconds the second. The
cgi
job is already running when I do the first open. I've always assumed
that
this had something to do with the browser cache - but maybe there's
something else going on. If anyone knows how to speed this up, I'd also
like to hear about it


Larry Kleinman
Kleinman Associates, Inc.
212-949-6469
203-255-4100



Richard ECUYER
<recuyer@xxxxxxx>
Sent by: To
web400-bounces@mi Web Enabling the AS400 / iSeries

drange.com <web400@xxxxxxxxxxxx>
cc

02/06/2008 11:53 Subject
AM Re: [WEB400] Slow Page Load Using

CGIDEV2.

Please respond to
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>






Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a web
page. The first time the user takes the option, the page takes about 60
seconds to load. After that, the page loads in 2 - 3 seconds. Has anyone
seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.


------------------------------

message: 8
date: Wed, 6 Feb 2008 12:04:06 -0500
from: "Crispin Bates" <cbates@xxxxxxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

StartThreadedCGI

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?
topic=/rzaie/rzaiemod_cgi.htm


----- Original Message -----
From: "Haas, Matt (CL Tech Sv)" <matt.haas@xxxxxxxxxxx>
To: "Web Enabling the AS400 / iSeries" <web400@xxxxxxxxxxxx>
Sent: Wednesday, February 06, 2008 11:56 AM
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.


There's a setting you can specify in the httpd.conf to prestart the CGI
jobs.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On
Behalf Of Richard ECUYER
Sent: Wednesday, February 06, 2008 11:53 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a web
page. The first time the user takes the option, the page takes about
60
seconds to load. After that, the page loads in 2 - 3 seconds. Has
anyone
seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





------------------------------

message: 9
date: Wed, 6 Feb 2008 12:27:24 -0500
from: "Haas, Matt (CL Tech Sv)" <matt.haas@xxxxxxxxxxx>
subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

That only works for multi-threaded CGI. It will not do anything for
Net.Data or RPG CGI programs.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@midrange.
com] On Behalf Of Crispin Bates
Sent: Wednesday, February 06, 2008 12:04 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

StartThreadedCGI

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?
topic=/rzaie/rzaiemod_cgi.htm


----- Original Message -----
From: "Haas, Matt (CL Tech Sv)" <matt.haas@xxxxxxxxxxx>
To: "Web Enabling the AS400 / iSeries" <web400@xxxxxxxxxxxx>
Sent: Wednesday, February 06, 2008 11:56 AM
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.


There's a setting you can specify in the httpd.conf to prestart the CGI
jobs.

Matt

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On
Behalf Of Richard ECUYER
Sent: Wednesday, February 06, 2008 11:53 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Page Load Using CGIDEV2.

Hi,
the only time i a saw a difference like that between first load an
others, was when the first one had to start the cgijob.

Terry Anderson a ?crit :
Greetings,
OK, here is what's happening.

The user takes an option from a green screen menu that launches a web
page. The first time the user takes the option, the page takes about
60
seconds to load. After that, the page loads in 2 - 3 seconds. Has
anyone
seen anything like this before?

I am using the apache server on a 525 at V5R4.



Terry Anderson
Programming Manager
Citation Corporation
Switchboard 1.251.867.5481 ext 212
Direct Line 1.251.809.2312
Fax 251.867.0525
Cell 1.251.363.4975



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
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@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
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) digest list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.



End of WEB400 Digest, Vol 6, Issue 27
*************************************

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.