Any work arounds for this?

[Johnson, Harold A EDUC:EX]

lol (good one)   Our quick in batch processes work just great (and quickly
too) and are simpler to debug/create than doing it in QTP.  (QTP and QUIZ
definately have their place)  (I might have to replace these with Visual
Foxpro)



-----Original Message-----
From: Curt Morgan [mailto:ccmorgan@austin.rr.com]
Sent: Monday, November 25, 2002 12:37 PM
To: Johnson, Harold A EDUC:EX; powerh-l@lists.swau.edu
Subject: Re: Any work arounds for this?


Harold
Take heart from this:  I once replaced a Quick-in-batch process that took 24
hours (...!) to run, with simple Quiz and QTP code that took all of 3 hours.
Broke my arm from patting myself on the back, too.
Curt

----- Original Message -----
From: "Johnson, Harold A EDUC:EX" <Harold.A.Johnson@gems1.gov.bc.ca>
To: <powerh-l@lists.swau.edu>
Sent: Monday, November 25, 2002 2:23 PM
Subject: Any work arounds for this?


> Hi all.  We have a fairly complicated process which has grown over the
years
> and includes several quick-in-batch and C code external calls.  We have
> noticed that it seems to "run out of steam" (out of memory or environment
> space?) after processing a number of records and issues the following
error:
>
> *Fatal Error* *635* Notify Cognos Customer Support
>
> The actual number of records that the process has been able to work
through
> has been steadily decreasing over the years and we are now looking at
> ripping it apart in order to allow it to finish properly without crashing.
> Information that we have received in the past always contain the warning
the
> "quick was never intended to be run in batch", even though technical
> articles have been produced on how to run quick in batch.  We know that it
> really has nothing to do with the C calls, as this crashing behavious has
> been duplicated on other processes with no C calls.
>
> We *have* noticed that the number of records our quick-in-batch processes
> can go through is dependent on the type, complexity and amount of work
that
> is done and is related to how many times a screen is called from another.
> (the simpler, the better - no called screens means no crashing at all,
> whereas a single called screen will crash after about 30 - 32,000 calls)
>
> We have MANY quick-in-batch routines, which greatly enhance our systems
> productivity and flexibility.   Are there any known work-arounds to this
> problem? (aside from actually changing the code)
>
> OpenVMS on Alpha server.
>
> thnx
>
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.