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



If the *SRVPGM is in a binding directory, then you should be able to create
your new *SRVPGM, delete the old entry and re-enter the new one.  I think
your programs should never miss a beat because the Activation Group should
still have the "correct" version of the modules until it ends.

Joel R. Cochran
Director of Internet Services
VamaNet.com
800-480-8810 (va toll free)
540-885-8050 (phone)
540-886-1589 (fax)
www.vamanet.com
mailto:custservice@vamanet.com


>-----Original Message-----
>From: Smith, Nelson [mailto:NSmith@lincare.com]
>Sent: Monday, November 19, 2001 12:21 PM
>To: MIDRANGE-L@midrange.com
>Subject: Replacing *SRVPGM in production
>
>
>Has anyone come up with a way to replace an "active" service program in
>production (with a new version) without getting pointer errors in the
>programs that are currently using it?
>
>I'm looking for some method kinda like how the OS moves
>existing programs to
>QRPLOBJ and other programs calling them can still find them.
>That doesn't
>seem to work with service programs.  Replacing a service
>program that is
>currently "in-use" always seems to cause the calling programs
>to lose their
>way. I assume that is because the pointers are resolved when
>the calling
>program starts up and the replacing service program goes to a
>new location.
>Is there some way to make calling programs continue to point to the old
>service program until they end?
>
>Nelson Smith, CDP, CCP
>IBM Certified Specialist
>AS400 RPG IV Programmer
>(727) 431-8243
>(800) 284-2006
>
>
>
>***************************************************************
>***************************************************************
>***************************************************************
>***************
>This message originates from Lincare Holdings Inc. It contains
>information which maybe confidential or privileged and is
>intended only for the individual or entity named above.
>It is prohibited for anyone else to disclose, copy, distribute
>or use the contents of this message.
>All personal messages express views solely of the sender,
>which are not to be attributed to Lincare Holdings Inc., and
>may not be copied or distributed without this disclaimer.
>If you received this message in error, please notify us
>immediately at MailAdmin@lincare.com or (800) 284-2006.
>***************************************************************
>***************************************************************
>***************************************************************
>***************
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L)
>mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>


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.