View previous topic :: View next topic
|
Author |
Message |
Debasis Misra Warnings : 1 New User
Joined: 16 Sep 2008 Posts: 72 Location: Bangalore
|
|
|
|
The Schenario is like :
PGMA is calling PGMB
PGMB is calling PGMC
If all are static call and PGMB is changed.
Then which is correct?
a) Needs to compile all 3 programs
b) Needs to compile PGMB and PGMA?
Please help me out. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
All three need to be re-compiled and linked.
Is this CICS or Batch?
Bill |
|
Back to top |
|
|
Debasis Misra Warnings : 1 New User
Joined: 16 Sep 2008 Posts: 72 Location: Bangalore
|
|
|
|
Thanks a lot Bill!!
Its Batch programs. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
Interview question? |
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
No. Niether one is correct.
If PGMB changes, only PGMB needs to be recompiled unless the thing that changed was how it got information from PGMA or how it passed information to PGMC.
In any case, you need to relink the resulting load module, using either object stored from previous compilations of PGMA and PGMC or the old load module.
Why would you have to pass PGMA or PGMC through a compiler if only PGMB changed? |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
I agree with Bill. B needs to be recompiled and relinked because it changed. A needs to be recompiled and relinked because B was a part of A's load module before B changed. C needs to be recompiled and relinked because it was a part of B's load module before B changed. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
MBabu wrote: |
Why would you have to pass PGMA or PGMC through a compiler if only PGMB changed? |
If these were dynamic calls, then only "B" would need to be re-compiled and linked.
But, these are static calls.
Also, if "B" had been changed and the parmlist passed to "C" had been modified, then "C" would need to be re-compiled/linked (using the updated parmlist), regardless whether this was a static or dynamic call sequence.
Bill |
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
It doesn't really matter how many load modules there are or if this is static or dynamic (unless I'm misunderstanding the terminology). As long as program B creates its own CSECT(s) you only have to compile program B. You have to relink whatever load modules program B is in and those load modules may contain A and/or C but only B needs to be recompiled. You can use existing object decks for A & C or you can relink each load module using the old load module as input to the binder by adding it to a SYSLIB library and mentioning it in SYSIN INCLUDE control statements (as is commonly done when applying system maintenance). That will to replace only the new CSECTs. The question was about compiling, not linking. Had it been about linking, the answer would be that you have to at least consider including modules other than B. Reusing previous compiler output of unchanged modules is standard in build/generate processes implemented by software configuration managers. If you are familiar with MAKE in Dos or Unix, this is the same idea. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
We are not aware of possible changes to the parmlist from "A" to "B" and if it changed, then a re-compile/link is necessary.
Same holds true for any modifications to the parmlist from "B" to "C". It might be the same as "A" to "B", but this is an unknown.
A re-compile and link of all three programs, beginning with "C", then "B" and finishing with "A", significantly reduces the possibility of raising the ever popular "opportunities".
Bill |
|
Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008 Posts: 400 Location: Mumbai
|
|
|
|
Bill O'Boyle wrote: |
We are not aware of possible changes to the parmlist from "A" to "B" and if it changed, then a re-compile/link is necessary.
Same holds true for any modifications to the parmlist from "B" to "C". |
But if the call changed, then program A changed. If program A didn't physically change, then the object code generated by a new compile will be the same as that generated by the previous compile.
The other thing is, that if A calls B with 2 parameters and B is expecting 3 parameters, the compiler will not catch that. A more cognizant environment that does live parsing, compiles and intermodule compatibility checking on the fly like Eclipse does with Java would catch that, but running a COBOL program through a compiler won't catch parameter inconsistencies since it has no knowledge of the other module (and even with entry declarations in PL/I, that would require a change to both modules or a common include, which is effectively the same as changing both modules).
I know I'm just being picky and it is sometimes convenient to recompile everything (or even needed to assure matchnig compilers/options/etc), the original question is what do I need to send through the compiler, and the answer (save for times when you change compilers or options also) is just program B.
Now, as mentioned above, if a copybook changes that is included by A and B, that is a 'nother kettle of fish. |
|
Back to top |
|
|
|