RE: Activation Group Issues ?

Scott,

Thanks.  You hit the nail on the had, as I mentioned to Carel.  Turns
out I was opening and closing the file every time.  

Sorry I didn't go into enough detail about what the program was actually
doing.  Whenever I post a question here, I try to give enough info for
you guys to help, but also try to avoid writing a book and overwhelming
you with irrelevant information.  It's a difficult balance to achieve. I
only suspected activation groups because they are the bit I understand
least, and which as I mentioned, my reading to date has left me a bit
confused, but I will dig in and try some more.  Hence the question mark
in the subject line.  Perhaps a more overt subject line would have been
"could this possibly be an activation group issue?" and a signature line
"stabbing in the dark".  Given that we are in South Fla and the power
just came on from Hurricane Wilma's passing two weeks ago, the "dark"
part is literal as well as metaphorical.

Anyhow, the program is down to a barely acceptible 2 hours 20 minutes
now, whereas it would have run well over 24 with all those file openings
and closings, so I feel better, though I can't help thinking the
performance could be tweaked further.  It used to run in a half an hour
before we added these new fields.

The subproc just does a chain using the imput parms to fetch a value,
and if it doesn't find it in file1, it goes to another file to fetch the
default value.  The info is just appended demographic type info for our
customer file, like employee size or whether it's a female owned
business, or whether they can accept HTML emails, or whether they allow
us to rent their address to business partners, etc.  It's a vertical
file appended to the customer file in our third party order/entry
package, so we can add new "fields" by making up a new code to identify
the new information.  

In this case, I'm fetching all the data from our customer file to
populate our data warehouse in an SQL server.  As I do, I now have to
fetch all this demographic data from the vertical file along with each
customer.  Most report progams and such would only fetch one or two
values from this file, hence the procedure to enforce the rules about
fetching the default value if the customer doesn't have one, but in this
case, I'm sending most if not all of the values, so I just call the proc
several times, passing a different code each time.  I could change it to
pass in a DS like Carel suggested, but it seems like that would make the
code a bit burdensome for the other programs which only want one or two
values, although I suppose I could make two versions of the procedure.  

I've also thought about binding the proc by copy instead of using the
service program, but if I understand correctly, the service program only
has to be activated once at the beginning of the calling program, and
not every time the proc gets called, so I don't think that would gain me
more than a few nanoseconds.  




>-----Original Message-----
>From: 
>rpg400-l-bounces+gfleming=evergladesdirect.com@xxxxxxxxxxxx 
>[mailto:rpg400-l-bounces+gfleming=evergladesdirect.com@midrange
>.com] On Behalf Of Scott Klement
>Sent: Tuesday, November 08, 2005 6:01 PM
>To: RPG programming on the AS400 / iSeries
>Subject: Re: Activation Group Issues ?
>
>
>
>> I have an RPG program which uses a procedure in a service program to 
>> populate fields in the output file based on a key passed to the 
>> procedure.
>>
>> I may use the same procedure several times in a row to populate 
>> different flags based on various keys, like so:
>[SNIP]
>> CallFlag  = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'CAL');
>> EmailFlag = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'EML');
>> FaxFlag = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'FAX');
>> HTMLFlag = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'HTM');
>> MailFlag = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'MAI');
>> RentFlag = S_MKIUFD_getVerticalFlag(K#Comp:HLJYNB:HLFQNQ:'REN');
>
>
>What does this subprocedure do, exactly?  I know, it 
>"populates fields in 
>an output file based on a key" huh?   Does it open/close files?  What 
>is it returning?  What do you mean by "populates fields in an 
>output file" 
>even?
>
>All I've been able to pick up from your message is that you call a 
>subprocedure, and that you don't like the performance.  Okay, 
>great. What 
>does the subprocedure actually do that might affect performance?
>
>> I've done some reading on Activation groups in the ILE 
>Reference, but 
>> it's made my head go wobbly.  I'm guessing maybe I should update my 
>> service program and change the shared activation group attribute to 
>> *Yes.
>
>If you compiled the SRVPGM with ACTGRP(*CALLER), then why 
>would activation 
>groups make any difference in performance?  Why would a shared 
>activation 
>group help?  I'm missing your logic here.
>
>Since ACTGRP(*CALLER) doesn't create an activation group, how can you 
>share it?  Why would you want to?
>
>Seems to me that your subprocedure does something that's not efficient 
>enough. Maybe you're opening/closing a file each time, but 
>didn't do that 
>befre you used a subprocedure. Maybe you're using VALUE variables or 
>copying a big piece of data, and that's taking time.
>
>You need to look at the code and figure out what could be slowing you 
>down...
>-- 
>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.
>
>