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


  • Subject: Re: Call in ILERPG response time slow
  • From: "Steven Easton" <seaston@xxxxxxxxx>
  • Date: Sat, 24 Oct 1998 00:47:25 -0500

Thanks every one for your help

The machine is a model 600, with 40m of memory.  Test machine, No other
users signed on.  Was:
DFTACTGRP(*YES)
ACTGRP(QILE)
DBGVIEW(*ALL)
OPTIMIZE(*NONE)

I changed to:
DFTACTGRP(*no)
ACTGRP(QILE)
DBGVIEW(*source)
OPTIMIZE(*basic)

This dropped the response time to 9 seconds on the first call, and 7 second
on subsequent calls.

The extra overhead is in submitting compiles and making sure all programs
that use a module are recompiled when the module changes, and lastly
education.
----------
> From: Pete Hall <peteh@inwave.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: Call in ILERPG response time slow
> Date: Thursday, October 22, 1998 8:40 PM
> 
> At 07:26 10/22/1998 , Steven Easton wrote:
> >My question is, how can I improve response time without converting to
> >CALLB.  I write many small programs instead of 1 large program.  The
CALLB
> >adds extra programming overhead that I would like to avoid.
> 
> Try compiling with DFTACTGRP(*NO) ACTGRP(*CALLER). That will at least
remove the added overhead of creating an activation group each time you
call the subprogram. A word of warning though: Don't use ACTGRP(*CALLER) if
you're executing the program by calling it from an OPM program and using
bound calls. Results will be "unpredictable". If you need activation
groups, specify a named activation group. Do NOT use the default, which
creates a new activation group each time you call the program, and can
leave the old ones lying about. You could also look at the debug
information you're keeping in the program (DBGVIEW - check the docs). I'd
recommend using *SOURCE or *COPY, since that does not store the complete
source member in the program object. Also, OPTIMIZE(*BASIC) may help some,
with minimal risk of dysfunction.
> 
> What extra overhead are you speaking of with CALLB? All you really need
to do is add the 'B'. If you build a binding directory and have a naming
convention, compiles are every bit as easy as PDM option 14 (I named mine
CP for compile).
> 
> 
> Pete Hall

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.