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



I agree - but it doesn't have to be "live" - I just copy the old procedure list to the end and comment it out to document it. This gives me the ability to document what was done _without_ implying to anyone who comes later and who doesn't fully understand things that the order of the names doesn't matter.


Jon P.

On Nov 2, 2022, at 1:17 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

Jon, but isn't that extra bit of work worth it for that documentation that
you have for the *Prev procedure? It shows me when procedures were added to
the service program.

I believe in my question above I said modules. I meant to say procedures. I
always place new procedures at the end.

On Wed, Nov 2, 2022 at 10:08 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

"When you have multiple modules bound together to make one service
program, do you have to be careful to insert the new procedures into the
binder source in the correct position, and always bind the modules on the
CRTSRVPGM in the same sequence, and always have separate signatures in the
binder source so you don't have to re-bind the callers?"

The bind sequence doesn't matter. When the service program is created the
"numbers" (I usually use the term slots) are assigned based on the the
sequence in the binder source. ONLY the sequence in the *CURRENT set is
used. You can have *PRV with a different signature but the slots are not
affected. In other words if ProcX is in slot 5 for *CURRENT it is in slot 5
period - even if it is listed as the third entry in a *PRV set. This is why
I don't personally think having multiple signatures is worth the effort.


Jon P.

On Nov 2, 2022, at 6:20 AM, Henderson, Liam via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

Hi,
We based our service programs on Scott's ILE concepts presentation.
We have multiple service programs split by business area, one source
member to one service program, each has a static signature, new procedures
get added to the end.
One binding directory holds all the *SRVPGMs.

In the presentation it says "A program calls subprocedures in a service
program by number" and "Always add new procedures to the end so that the
existing numbers won't change"

When you have multiple modules bound together to make one service
program, do you have to be careful to insert the new procedures into the
binder source in the correct position, and always bind the modules on the
CRTSRVPGM in the same sequence, and always have separate signatures in the
binder source so you don't have to re-bind the callers?

I've got another question regarding service program deployment into a
production environment.
For *PGM changes we use QLIRNMO, so it moves the existing version of the
program into QRPLOBJ, so we can install fixes without the user's needing to
log off.
We don't hold any source on production machines, just wondered how other
people install service programs?

Regards.
Liam.
--



Liam Henderson | Application Consultant | Getronics

T. +441908992044 | M. +447985875181 | E. Liam.Henderson@xxxxxxxxxxxxx
| W. www.getronics.com




Getronics Services UK Limited - Registered in England and Wales with No:
07966594. VAT No: GB 130 6848 20.
Registered Office - Getronics, Level 30, The Leadenhall Building, 122
Leadenhall Street, London, EC3V 4AB, UK

The information transmitted is intended only for use by the addressee
and may contain confidential and/or privileged material. Any review,
re-transmission, dissemination or other use of it, or the taking of any
action in reliance upon this information by persons and/or entities other
than the intended recipient is prohibited. If you received this in error,
please inform the sender and/or addressee immediately and delete the
material. Thank you.

Legal disclaimer: http://www.getronics.com/legal/ and further details
of how we treat your personal data can be found in our privacy policy <
www.getronics.com/policy-pages/corporate-policy-legal-disclaimer>
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.