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