Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Static call : Compilation

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Debasis Misra
Warnings : 1

New User


Joined: 16 Sep 2008
Posts: 72
Location: Bangalore

PostPosted: Sun Sep 20, 2009 6:55 pm    Post subject: Static call : Compilation
Reply with quote

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
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sun Sep 20, 2009 7:04 pm    Post subject: Reply to: Static call : Compilation
Reply with quote

All three need to be re-compiled and linked.

Is this CICS or Batch?

Bill
Back to top
View user's profile Send private message
Debasis Misra
Warnings : 1

New User


Joined: 16 Sep 2008
Posts: 72
Location: Bangalore

PostPosted: Sun Sep 20, 2009 7:08 pm    Post subject:
Reply with quote

Thanks a lot Bill!!

Its Batch programs.
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Sun Sep 20, 2009 8:42 pm    Post subject:
Reply with quote

Interview question?
Back to top
View user's profile Send private message
MBabu

Active User


Joined: 03 Aug 2008
Posts: 401
Location: Mumbai

PostPosted: Mon Sep 21, 2009 2:48 am    Post subject:
Reply with quote

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
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1239
Location: Richfield, MN, USA

PostPosted: Mon Sep 21, 2009 2:56 am    Post subject:
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Sep 21, 2009 5:47 am    Post subject:
Reply with quote

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
View user's profile Send private message
MBabu

Active User


Joined: 03 Aug 2008
Posts: 401
Location: Mumbai

PostPosted: Mon Sep 21, 2009 9:15 am    Post subject: Reply to: Static call : Compilation
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Sep 21, 2009 4:26 pm    Post subject: Reply to: Static call : Compilation
Reply with quote

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
View user's profile Send private message
MBabu

Active User


Joined: 03 Aug 2008
Posts: 401
Location: Mumbai

PostPosted: Tue Sep 22, 2009 12:19 am    Post subject: Re: Reply to: Static call : Compilation
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Cobol EZASOKET call to SETSOCKOPT fails Andi1982 COBOL Programming 6 Thu Oct 06, 2016 7:12 pm
No new posts Strange EXEC function call in z/VM Willy Jensen CLIST & REXX 3 Wed Oct 05, 2016 2:07 pm
No new posts COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am
No new posts Is possible to call subprogram from c... cmsmoon COBOL Programming 3 Fri Aug 05, 2016 6:46 pm
No new posts PCOMM macro to call another PCOMM macro boyti ko All Other Mainframe Topics 4 Tue Jul 12, 2016 4:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us