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



bob@xxxxxxxxxxxx wrote on 06/05/2007 20:15:29:

If you don't like having to update dozens or hundreds of programs or
you
want the ability to add to a parameter list of a subprocedure, then
service programs are you only choice.

I (partly) disagree. It depends on the nature of the change to a *MODULE
object whether or not you need to "update dozens or hundreds of programs".
If need to make a bug fix to the operation of a subprocedure in a
*MODULE, and every program using that *MODULE needs to access the fix, you
need to recompile everything. I don't have a good idea of what percentage
of changes typically fall into this category, but I suspect it is fairly
large (> 50%)?

However, I can think of a couple of scenarios where making a change to a
*MODULE is as simple or even simpler than changing a *SRVPGM.

1. Adding a new procedure. Only the *PGM objects that need to use the new
procedure need to be updated. You are probably rebuilding these objects
due to other changes anyway if a new procedure is required.

2. Adding a parameter to a procedure. Again, only the *PGM objects that
need to use the new parameter need to be updated. You are probably
rebuilding these objects due to other changes anyway if a new procedure is
required. It is even a bit simpler than adding a parameter when using a
*SRVPGM, as you could get away with not using *NOPASS (though it is
probably not advisable to do so).

That said, having a bunch of *PGM objects which each contain a different
version of a particular *MODULE might be more of a pain than doing an
UPDPGM on all of them each time you change the *MODULE, so while you _can_
do it, it may not be wise depending on your environment.

HTH,
Adam

Attention:

The information contained in this message and or attachments is
intended only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited. If you received this message in error, please contact the sender
and
delete the material from any system and destroy any copies. Thank you for your
time and consideration.

Attention:

Le contenu de ce message et(ou) les fichiers ci-joints s?adressent
exclusivement à la personne ou -entité à laquelle ils sont destinés. Ils
peuvent
contenir de l?information confidentielle, protégée et(ou) classifiée. Il est
strictement interdit à toute personne ou entité autre que le(la) destinataire
prévu(e) de ce message d?examiner, de réviser, de retransmettre ou de diffuser
cette information, de prendre une quelconque action en fonction ou sur la base
de celle-ci, ou d?en faire tout autre usage. Si vous avez reçu ce message par
erreur, veuillez communiquer avec l?expéditeur(trice), supprimer ce message et
les fichiers ci-inclus de tout système, et en détruire toutes copies, qu?elles
soient électroniques ou imprimées. Nous vous remercions de votre entière
collaboration.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.