RE: CRTSRVPGM

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Mark
S. Waterbury

Hi, David:

This is because you have violated one of the "rules" of
creating export binder source.

in effect, you "lied" to the system, pretending that your
changes are "upwards compatible" between the various versions
of the *SRVPGM ...
When you use PGMLVL(*PRV), AFAIK, you must ensure that all of
the procedures previously available are still supported, with
compatible interfaces, in the same order or relative position ...

The idea is, you can add new procedures, but only at the end
... if you want to be "upward compatible" and use the
PGMLVL(*PRV) support.

This is similar to the concept used on mainframes, S/36, S/38
or AS/400, etc., of adding new fields only to the end of the
record, so that your existing programs could still access the
file with LVLCHK(*NO) ...

Thanks Mark, Bryce, Charles

By lying to the system, I think you mean that in this case I told it that the current signature used by the program was still supported but it was in fact not. The program trusted me thinking it would find PROC2 in slot2 but found PROC3. So, if I now recompile the program, it will now know that it must use slot3 for PROC2. I hope I have that right.

Still, we don't have a single srvpgm in the shop, and when a module containing exported procedures gets modified, then all programs using it get recompiled. I'm imagining that recompiling everything is a bigger issue elsewhere than it is for us.

I feel that it's a little scary though. Imagine someone made a mistake in the binder source? I suppose it's difficult to make, but it must be possible.

Finally, at this stage I still don't know which technique to prefer with the binder source.