Re: ILE Concepts

"If they retrieve the binder source and always use the company name as the signature what comes to my mind is the order of the exports. How does export all order the exports? Is it ordered by appearance in the source code? What if that changed? You would need to always compile everything else a wrong procedure might get called and that might lead to some unwanted side effects."

When EXPORT *ALL is used the signature is based on the _alphabetized_ procedure names. Adding a new procedure is almost guaranteed to impact the slot order and that will cause the wrong procedure to be called in the event that a program (or service program) is accidentally omitted from the re-build.

Because procedure calls are designed for speed not safety (unlike PGM calls) it is quite possible for the resulting call to "work" and not show any immediate error. I have encountered situations where major damage was done to the company's database before such an error was discovered.

Personally I would never use *ALL at any time other than during initial development. IBM tried it during the early days of ILE and it was a disaster.


Jon P

On Nov 1, 2022, at 6:29 AM, Mihael <mihael@xxxxxxxxxxxxxx> wrote:

Hi Birgitta,

some thoughts:

This 1-to-1 concept for module-to-service program is very common and fits most of the time. It eases most of the building tasks because you can give everything the same name (module, service program and binder source). But you are forfeiting some of the great concepts of ILE : multi-module and polyglot.

Of course you can mash up everything in one module but from time to time this can become very dirty (and the statement from Dilbert comes to my mind: "I am unclean." , https://dilbert.com/strip/2003-08-01 :) ). So for a clean design you split things up into multiple modules and bound it together into one program/service program.

And here comes the part where some things in the new design doesn't work. These modules export procedures and/or ds/vars. But these exports are not always to be exported by the service program. Some are only for the other modules in the program/service program. You want control over what will be exported and thus you use binder source. Export all won't work for this scenario.

This approach one module per service program and we export all is a bad idea. You wouldn't want to limit yourself in other languages so why in RPG?! In Java you would never limit yourself to one class per file with no nested class or non public classes. You just wouldn't do that. And it is ridiculous.

Keeping ALWAYS the same name as a signature ... that is bad too IMO. This only works if you will recompile EVERY program/service program which uses the changed service program on a service program change ... ALWAYS ... without ANY exception. In the first moment this doesn't sound to bad. Compiling everything. But as system evolves and you get more service programs and have more generic service program which do common stuff you need in "every" program you end up compiling your whole system if you change that one service program. You need a way to work around compiling everything but still be sure that things fail fast if you don't compile everything. There comes the service program signature into play. Don't use a static signature. Use semantic versioning and put the major version into the signature. If something is not compatible with the previous version then the signature gets changed. MYSRVPGMv1 to MYSRVPGMv2. Thus if you miss to compile some program on the change from v1 to v2 then it fails on the start. You don't get that with a static signature.

About this new strategy:

If they retrieve the binder source and always use the company name as the signature what comes to my mind is the order of the exports. How does export all order the exports? Is it ordered by appearance in the source code? What if that changed? You would need to always compile everything else a wrong procedure might get called and that might lead to some unwanted side effects.

Java development and RPG development (at least inhouse RPG development) differs very much in their build approach. Java always does a full build, compiling everything. With RPG and a CMS you mostly do incremental builds. You (probably) never build everything. This is fundamentally different.

IMHO this cannot work ... at least not without recompiling everything.

I think you are totally correct.

These are my 2 cents. Yours might differ.

HTH

Mihael


On 01.11.22 07:54, Birgitta Hauser wrote:

Hi everybody,

I need some comments/strategies about ILE Concepts.
A company worked since years as follows:
- One Source one Object (Service-Program or Program)
- a Service-Program could include 1 to n (exported and a few internal)
procedures
- Binder Language was used in the way, it was maintained before creating or
updating the service program. (They even had a tool which generated the
binder language automatically by scanning the source)
- The signature was kept static, i.e. Signature Name = Service-Program name
- Even though the signature was static, the previous export blocks are
stored in the binder source just to see what procedures were added.

With this method they could easily add new procedures to service programs
and transfer single service programs from the development system to the
productive system.
In the case of the company they had to implement the application and fixes
on different customer machines. Because the tool was a development tool, the
customers had to call the exported procedures.
... and until now it worked without problems.

Now a new (java) guy/leader (who knows everything better) came and told them
everything they did were bullshit.
He wants the following:
- Service-Programs are compiled/bound without binder language (i.e. EXPORT
*ALL)
- After the binder language is retrieved (and the signature get modified,
i.e. ALL SERVICE PROGRAMS will get the SAME NAME, i.e. Company name =
SIGNATURE).
- Then an UPDSRVPGM is performed to include the new Signature in the
Service-Program

- if new procedures are added, again the Service-Program is again created
with EXPORT *ALL, and the binder source retrieved.
- the binder language is retrieved again, and only the signature has to be
changed.

IMHO this cannot work ... at least not without recompiling everything.

Someone can tell me what happens if ALL Service-Programs get the same
signature?
Are the right service-Programs still found or are just ALL service-programs
activated at the same time?
Are the right procedures still called if all Service-Programs have the right
signature?

What do you think about this new strategy ...and was the old one so silly?

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i


"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
„Train people well enough so they can leave, treat them well enough so they
don't want to.“ (Richard Branson)

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