OK, OK so I've never used a service program before and nor has anyone else in our shop.
I've done a little more reading and come up with this, please someone correct me if I'm wrong.
A program containing only modules is bound by copy and all the code from all the modules is duplicated in one executable object.
When a service program is added, a reference is bound to the program. The code is therefore not duplicated. The adress of this code will be established at the first call of the procedure in the service program.
Some questions :
Are our programmes being created from modules bound by copy are much heavier than if they were bound by copy?
Will this have a noticeable effect on performance? I notice we have programmes of 100 MB.
What happens if a program is called and the procedure in a service program has changed or if the service program was deleted?
Why bind by copy instead of by reference?
Thanks.
-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Wilt, Charles
Envoyé : mercredi 27 février 2008 16:16
À : Midrange Systems Technical Discussion
Objet : RE: Service programs suck
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: Wednesday, February 27, 2008 9:08 AM
To: Midrange Systems Technical Discussion
Subject: Service programs suck
<snip>
I am reminded that we do not use service programs as they use dynamic
calls and that would mean the same as going back to RPGIII.
NO, NO, NO, NO, service program are a far, far cry from RPGIII dynamic calls. If a procedure is intended for reuse, then 99.9999% of the time they belong in a service program.
Perforance wise, it doesn't matter if the procedure is in a service program or bound into the program object, in both cases you are making a bound call that performs at the same speed. The only difference is a one time hit for the service program activation. But that is ilrelivant against the total time spent calling the procedures.
Hi everyone,
We have this problem with 1 procedure that calls another that calls
another :
Module 1 Procedure 1 calls Module 2 Procedure 1.
Module 2 Procedure 2 calls Module 3 Procedure 1.
Module 3 Procedure 1 gets the following modification : a parameter
M3P1Parm that is a DS declared LIKE another DS in the same module.
Module
2 Procedure 2 is modified accordingly.
Module 3 is recompiled, no problem.
Module 2 is recompiled, the compiler imports the protoypes of all the
exported procedures of Module 3 with the definition of M3P1Parm, again
no problem.
Module 1 is recompiled, the compiler imports the protoypes of all the
exported procedures of Module 2 : Procedure 1 that is uses, and
Procedure
2 that it doesn't - PROBLEM, it doesn't know what is M3P1Parm.
Bigger problem : the policy is to systematically compile ALL the
modules that use the module modified. I realise that probably raises a
few eyebrows but that's the way things are!
Now, I am asked what I think of this way round the problem :
If an exported procedure contains a DS as a parameter then that
procedure must have its own module.
I suggest that Module 2 should be a service program and that Module 1
would not have to be recompiled.
No, you'd still have an issue if you ever needed to change anything in Module 1.
But I don't really understand the issue you are having, Module 1 shouldn't even see any references to M3P1Parm as the only places M3P1Parm should be referenced from your description are:
Module 3 prototypes
Module 2 code
Module 3 code
Instead, it sounds as if you also changed the Module 2 prototypes.
You've got a couple of options, if the same DS is being used by procedure in multiple modules, perhaps they really shouldn't be separate modules.
Other option is to place the DS template into it's own /COPY member. Use the /IF DEFINED compiler options to make sure that a given protype is only copied once. Like so:
//-----Module 2 Prototypes----------//
/if defined (MODULE2_COPIED)
/eof
/else
/define MODULE2_COPIED
/endif
/copy QProtoSrc,MyDSDef
//-----Module 3 Prototypes----------//
/if defined (MODULE3_COPIED)
/eof
/else
/define MODULE3_COPIED
/endif
/copy QProtoSrc,MyDSDef
//-----MyDSDef Prototypes----------//
/if defined (MYDSDEF_COPIED)
/eof
/else
/define MYDSDEF_COPIED
/endif
D MyDsDef ds
D fld1 10a
D fld2 20a
HTH,
Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx
This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
