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

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

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.