Re: ILE Concepts

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