Re: LR *ON or *OFF for web apps (was Dynamic sized multipleoccurrence data structure )

Mike,

Sorry for the delay getting back to you.

In answer to your question, you want to leave LR off even when working
with non-persistent CGI for performance reasons.  From the CGIDEV2
tutorial http://www-922.ibm.com/cgidev2o/tutorial.htm#8
In order to obtain the best performance from your CGI's, you may want to
adopt the following tips:

1. use a named activation group (a different activation group for each
CGI, see FAQ number 26)
2. return without setting LR on
  Note. By returning with LR set to *off provides you with another great
performance advantage. The next time the program is called and calls
subprocedure gethtml, will not load the external html again (unless it
was changed meanwhile), because it is still in core. This feature is
responsible for the highest gain in the Version 2 performance
improvements.
3. open files just the first time through, never close them
4. each time the program runs
  * re-initialize variables
  * do not rely on files being positioned on the first record;
reposition with SETLL, or SETGT, or any other appropriate way 
5. After programs are thoroughly tested, use CALLP SetNoDebug(*ON) to
turn all debugging off.
  Note.SetNoDebug sets a global variable in the service program. If
multiple CGI programs are running in the same named activation group,
all those programs are affected in the same way by the most recent
execution of SetNoDebug.


The use of named activation groups separates the different CGI apps
within the job.  But yes, your multiple web jobs could all end up with
the same set of CGI jobs open inside.  Remember that the program code is
not duplicated, but the static storage and open files will be.  Which
may be an issue with your 1000 occurrence MOD if your using 100's of web
jobs.  On the other hand, higher performance will allow you to handle
the load with fewer web jobs.

As usual, comes down to space vs. performance.

Just remember that unlike the green screen, even though LR is off you
can't expect the same user to be using it again nor can you use any data
from the prior run.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Monday, December 18, 2006 9:23 AM
To: Wilt, Charles; RPG programming on the AS400 / iSeries; 
Web Enabling the AS400 / iSeries
Subject: RE: LR *ON or *OFF for web apps (was Dynamic sized 
multipleoccurrence data structure )

I have always been under the assumption that unless your doing
persistent sessions (and the opinion of most people I have 
talked to is
to NOT use persistence) that the last thing you should do in 
any web CGI
app is set LR to *ON before you do a RETURN. I have used the LR being
*OFF for years for a lot of green-screen apps but that was in a world
where I know user A was always user A until they signed off 
and then all
apps shutdown and all files closed. In the web world every hit to one
CGI job could be from a different person and requesting a 
different app.
If LR is left *OFF one web job could have every CGI app we 
have open by
the end of the day. 
 
Am I mistaken in this assumption?

CWilt@xxxxxxxxxxxx 12/18/2006 9:05 AM >>>

Mike,

With a web app, you're going to want to leave LR off when you finish
anyway.

So your version that does dynamic allocation multiple times is
probably
going to perform worse than a version that does that does the maximum
allocation once.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Friday, December 15, 2006 3:23 PM
To: RPG programming on the AS400 / iSeries;

rpg400-l@xxxxxxxxxxxxxxxx

Subject: Re: Dynamic sized multiple occurrence data structure

Completely agree with your "don't try to save a few cycles at the
expense of readable code". My main concern was using this in a web

app

where the app will open, fill in the structure, send the results and
then close and could be doing that a lot if it gets used as I hope.

If

it was an app that ran once or twice a day I would not even 
consider it.
If it gets a couple of hits a minute that might be a 

different story.

 
And doesn't OS/400 have to load the entire app when it is started

even

if some code pages might later get swapped out if not used? Static
storage size  is 5,206,080 and Program size  is 1,806,336 for this

app

and I was concerned about the load time.
 
And in this particular app I actually have an array and a MODS. I

load

the array because I then sort the data before loading it into 
the MODS.
Then send the MODS as the results set. I do already keep track of

the

number of elements and set the result set size to the actual number

of

elements. 

rpg400-l@xxxxxxxxxxxxxxxx 12/15/2006 2:45:41 PM >>>

Hi Mike,

Is there any trick available to create a multiple occurrence data
structure and define the size at run time?

[SNIP]

my application is used as a stored procedure that returns a result

set 

and so I can't use arrays.

The "SET RESULT SET" SQL statement can specify the number of rows to

return.  For example

      C/exec sql Set Result Sets Array :MYMODS for :COUNT Rows
      C/end-exec

Your program will have to keep track of how many elements 
you've loaded

into the MODS and set the number of rows (in the COUNT 

variable in my

example, above) appropriately.

As far as how many occurrences exist in your MODS, I strongly 
recommend

that you allocate all 1000 of them as a normal MODS.  The unusused 
occurrences won't matter.  The amount of memory they occupy won't

have

any 
significant impact on the system.

It's possible to base your MODS on a pointer, and allocate 
only as many
as 
you need -- exactly the same way you do it with an array -- 
but there's

really no value to doing so (either with a MODS or an array!) if you
only 
have 1000 elements.

You can hurt the performance of your program, and make a 
program that's

very difficult to maintain, using techniques like this.  Sure, you

may

save a few kilobytes or even megabytes of memory, but who the heck
cares 
about that?  The iSeries will store unused portions of your program

on

disk, only loading it into memory if nothing else needs the 
memory.  So

the amount of memory you use really doesn't have a 

sigificant impact.

Certainly nothing worth the cost of making your program hard to
maintain!!

Even if the memory usage is a problem, big deal.  Buy another 512mb
memory 
module for your system.  What does that cost?  $300 or 

something?  By

comparison to the extra days it'll take you to write and debug yoru 
program, and by comparison to the years of extra time maintaining

your

program, the cost of an extra memory module is extremely cheap. 

Don't

create a maintenance nightmare over a couple of kilobytes!

-- 
Scott Klement  http://www.scottklement.com

-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L)

mailing

list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


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

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


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