|
What I do with RPG xTools *SRVPGM is to hard code the signature. When a new procedure is introduced, it is added to the bottom. If a replacement procedure is introduced, it is, effectively, a new procedure so it too is added to the bottom. There is an exception to this, read on... If a procedure is to be retired, but needs to continue to be in service until all existing code that references it is recompiled, thee following is what I do. Assume the proc name is FindReplace(). I write a faster or better version and have the streamline the parameters. In my binder source I originally have this: STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('RPGXTOOLS') EXPORT SYMBOL("aesEncrypt") EXPORT SYMBOL("aesDecrypt") EXPORT SYMBOL("FindReplace_V1") EXPORT SYMBOL("CpyToCsvIFS") ...... ENDPGMEXP Now I write a new procedure to replace the old FindReplace routine. That new procedure is named FindReplace but has a different parameter list. By different, I mean perhaps I moved from a VARYING parm, to CONST OPTIONS(*VARSIZE) which would cause the compiler to pass data in a different form, but would not cause source code changes to the caller. So in my binder language I do this: STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('RPGXTOOLS') EXPORT SYMBOL("aesEncrypt") EXPORT SYMBOL("aesDecrypt") EXPORT SYMBOL("FindReplace_V1") EXPORT SYMBOL("CpyToCsvIFS") ... EXPORT SYMBOL("FindReplace") ENDPGMEXP Note that I've changed the name of the original FindReplace export to FindReplace_V1 and inserted a new EXPORT statement with FindReplace. In my source code I would change the original FindReplace procedure name to FindReplace_V1 and then create the new FindReplace routine someplace else. This leaves the old FindReplace in the service program and exported in with the same ordinal. So a program that is already compiled and is calling ordinal number 3 (my original FindReplace routine) will continue to call the original routine because it is not calling it by name, but by export ID or "ordinal". When new programs are compiled and use the FindReplace routine, they will get the new version because the name matches the new EXPORT I've added and does not match the FindReplace_V1 name in the binder source. When current programs are recompiled, they too will now use the new version of FindReplace instead of the old one. Again, as long as the parameter list is compatible, this technique works. I will say I've only done this twice and there are nearly 200 procedures in RPG xTools, so it doesn't come up too often. -Bob Cozzi www.RPGxTools.com RPG xTools - Enjoy programming again. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Francis Lapeyre Sent: Thursday, September 15, 2005 11:51 AM To: 'RPG programming on the AS400 / iSeries' Subject: RE: Service Programs and Naming Conventions Bob: That's the way I would do it, also. The whole idea is to do aa little "code cloning" as possibe; less stuff to maintain that way. Yes, I'm aware that the old versions in Marvin's model are not supposed to change, but what if one of them has a bug? You have to know where that code is everywhere on the system. I'd rather change it in just one place. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob Cozzi Sent: Thursday, September 15, 2005 11:29 AM To: 'RPG programming on the AS400 / iSeries' Subject: RE: Service Programs and Naming Conventions If you only add new parameters then adding one with OPTIONS(*NOPASS) or OPTIONS(*NOPASS : *OMIT) would make no difference in the signature. I've moved to hard coding the signature in the binder source and adding my new procedure names to the bottom. That way everything continues to work without recompiling. I also always add new parameters with OPTIONS(*NOPASS : *OMIT) -Bob Cozzi www.RPGxTools.com RPG xTools - Enjoy programming again. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Marvin Radding Sent: Thursday, September 15, 2005 10:12 AM To: RPG programming on the AS400 / iSeries Subject: RE: Service Programs and Naming Conventions 1a. Then when I see module names in upper/lower case that must mean that it was not written in RPG but probably C or C++ 1b. I was planning to use the dots in the name of the module thinking that it would be hidden inside quote marks. 2. Yes I mean service program. I understand the need to not disturb the order as this would force an update of the program, which I am trying to avoid while making improvements/enhancements to the service program. On your last statement, wouldn't adding a parameter even if it was OPTIONS(*NOPASS) change the signature forcing an update of the program? That is what I am trying to avoid. I want to make changes and enhancements without the necessity of updating all program to make sure there won't be any fatal errors when the user goes to use a program. The update could take a long time with over 2,000 programs over 6 systems. Marvin -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Francis Lapeyre Sent: Wednesday, September 14, 2005 8:00 PM To: 'RPG programming on the AS400 / iSeries' Subject: RE: Service Programs and Naming Conventions 1A. OS/400 and the RPG compiler is case-insensitive. Any source you supply is interpreted as upper case by the compiler. You can use mixed case for readability, but remember that Foo is the same as fOO and foO. 1B. You can't use dots in a variable name unless you use the QUALIFIED keyword on a data structure. I'd use an underscore instead. 2. If by "module", you really mean "service program", yes, as long as you add the new versions after everything else in the service program. Never add anything in the middle. Personally, I would modify the existing function within the service program to do things the new way, when it is passed an optional parameter (OPTIONS(*NOPASS)). -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Marvin Radding Sent: Wednesday, September 14, 2005 7:15 PM To: RPG programming on the AS400 / iSeries Subject: Service Programs and Naming Conventions I am designing a service program and considering version, revisions and naming conventions. Here's what I am proposing so far. 1. Every program has a name that consists of upper/lower case letters ending with a release.version numering. a. How do I get the upper/lower case name? The D-Spec always comes out in upper case. b. Can I append a number.number to the end of the name? I tried but the compiler rejects the dots. 2. When an enhancement/improvement is made to a module, the release.version will change and the new module will be added to the service program but the old module will not be replaced. This way no recompilations/modifications will be necessary. Is this idea feasible? Can I added different modules for basically the same program without encountering any problems as long as the external/exported names are different? Any idea if this is possible? Marvin -- 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.
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.