RE: CRTSRVPGM

Either solution is code it once use it in multiple places. Much better
than copying the same code into multiple programs. Basically you have
bind by copy and bind by reference. Bind by copy is to include the
module into each program. If you change the module you have to bind all
the programs that use the module. Here is where you MUST know every
where the module is used. Good documentation helps. But when you find
the module is used in hundreds of programs, gets to be very time
consuming.

Then there is bind by reference. That is the module exists in one
service program. Any programs that need the module create a reference
to the entry point within the service program at compilation.

Fist time a Job access the module, it first looks up the service
programs and finds the address of the service program. That is added to
the entry point derived at compilation to calculate the address of the
modules entry point.

So you can see if you create a new copy of the service program, a job
can find it upon first use. If you move the module entry point, you
will incorrectly calculate the entry point and your results will be
unpredictable. If you update the service program correctly, no module
entry points changed, all will work. But if the job has used the old
service programs, it has a pointer to the old object that has been
re-indexed to QRPLOBJ.
Note it is not physically moved on disk so the old resolved address is
pointing to the old object. The new object, while in the same library
with the same name, is physically in a different disk location.

I like service programs because they do not require you to recompile a
bunch of programs. But you must understand them, how they are
referenced, and how to control signatures.

I also believe that service programs are for the tried and true modules
that will not change often. They are great for date routines, string
manipulation, TCP functions, and such stuff. I would not put code into
a service program that is used in only a couple of programs and changes
often. Modules are great for that.

JMHO


Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Wednesday, January 12, 2011 9:24 AM
To: Midrange Systems Technical Discussion
Subject: RE: CRTSRVPGM


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, and 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.