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



Pascal,

I'd be willing to be that's it's normal behavior.

You'd pay a huge performance penalty if the system resolved the service program's location for every
call to a procedure in the service program.

Heck, the system doesn't re-resolve the location of a *PGM on a dynamic call. I know from
conversations with Barbara that that behavior is as designed. So if you have

CALL QCMDEXEC('ADDLIBLE MYLIB *FIRST')
CALL MYPGM
CALL QCMDEXEC('ADDLIBLE MYNEWLIB *FIRST')
CALL MYPGM

If MYPGM is in both MYLIB and MYNEWLIB, both calls to MYPGM will run MYLIB/MYPGM.

HTH,
Charles

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Pascal Bellerose
Sent: Thursday, October 11, 2007 3:58 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: [SPAM] RE: Rép. : [SPAM] Re: Service program not using LIBL

For example: You want to load another version of the program
that is in another library... That'S exactly my case and I
think this thread has gone way too far...

Could we just get back to the subject?

Is it a normal behavior? (please read my first post) If not
is there a PTF tha twould solve the problem? Or do we have
to start using activations groups?

Thanks

Pascal Bellerose
pascal_bellerose@xxxxxxxxxxxx
Cascades Canada inc.
Analyst-Programmer-Helpdesk
Telephone: 819-363-6114 (2114)
Fax: 819-363-6155 (6155)
Do you really need to print this e-mail? Change your environmentality!

Le 11 Octobre, 2007 à 14:14, "Christen, Duane J."
<dchristen@xxxxxxxxxxxxx> a écrit :
Scott;

Why would you need to unload service programs from memory?

I can't think of a reason to reclaim an activation group. I'm
not saying that there isn't a reason, and that using
RCLACTGRP is always wrong, but if it is being used all the
time then I would beleave that something is wrong with the
process which requires the cleanup.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Thursday, October 11, 2007 11:48 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Rép. : [SPAM] Re: Service program not using LIBL


Why do you say that requiring a RCLACTGRP means there's something
wrong with your coding?

Granted, there are other ways to accomplish the same things
-- but the
fact that you choose to use activation groups instead of other
alternatives shouldn't mean that something is WRONG. It's just a
choice.

In my opinion, if you always use the SAME value for the ACTGRP
parameter, rather than using the right one for the purpose at hand,
that's a symptom that indicates that something is wrong with your
coding. But using RCLACTGRP? That doesn't mean anything
-- unless of
course you're using it incorrectly.

If you have an application that consists of 10 programs/srvpgms, and

these programs need to all be loaded into memory at once, and all
calling back & forth between each other rapidly, but you need to
unload
them all from memory at certain times of the day... why not use
RCLACTGRP to accomplish that? Assuming you're not doing something
that's potentially harmful (such as loading programs in the default
activation group, or reclaiming QILE, or reclaiming
*ELIGIBLE) then why
is it bad coding to use RCLACTGRP?


Christen, Duane J. wrote:
This is just my opinion, but if you regularly require a RCLRSC or
RCLACTGRP then there is something wrong with your coding.
Personally
I have never needed to do either in a production process. I
could see
where a program/process may execute once everytime a user
signs on or
enters an application for the first time. In this case I would use
a
*NEW activation group, thus the activation group is reclaimed
automatically.
--
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 email has been scanned by the MessageLabs Email Security
System.
For more information please visit http://www.messagelabs.com/email

______________________________________________________________________




NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use,
copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via
e-mail.



--
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 e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.


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.