|
View previous topic :: View next topic
|
| Author |
Message |
rashmi123
New User
Joined: 04 Jun 2007
Posts: 25
Location: Pune
|
|
|
|
All,
I have a COBOL copybook which changes almost every month. Many COBOL programs are using this copybook, as a result of which I have to recompile all the programs every month. Is there a way to eliminate the need for recompilation every month.
Thanks |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
Sure -- change the system so the copybook is not updated every month.
Realistically, a copybook is normally used for code that is reasonably static -- using it for source that changes "almost every month" is going to require recompiling the programs that use the copybook. You might be able to set up a mass compile, depending upon your source management system, so you need to contact your site support group for assistance. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
no, if you change the copybook, then you should recompile, regardless.
why is the copybook changing so often?????????that is the solution to your problem.
not a shortcut. |
|
| Back to top |
|
|
rashmi123
New User
Joined: 04 Jun 2007
Posts: 25
Location: Pune
|
|
|
|
Thanks to both of you for replying!
The copybook is changing since new fields are expected everytime which are added towards the end.
How do I do a mass compile? I have Changeman in my shop. |
|
| Back to top |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006
Posts: 771
Location: Germany
|
|
|
|
Morning Sir !
On the fly, i'm thinkink of a little Rexx-Proc. This one reads a Tso-Member wich includes the Program-Names you have to compile. One line for one name. Then for ervery line extracts the Program-Name and does File-Tayloring to build a Compile-Jcl and submits this Jcl via Internal-Reader. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
you could add a filler x(100) at the end of the copybook.
| Code: |
01 REcord1.
03 existing-field1 pic x(7).
03 existing-field2 pic x(13).
03 filler pic x(100). |
use beginning of filler for new fields.
| Code: |
01 REcord1.
03 existing-field1 pic x(7).
03 existing-field2 pic x(13).
03 new-field pic x(10).
03 filler pic x(90). |
Programs which are not using new-field don't need to be recompiled.
programs which are using new-field have to be modified anyway.
Only when you run out of filler, you need to change and recompile all.
Of course moving of all fields is now different from moving the record. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| This one reads a Tso-Member wich includes the Program-Names you have to compile. |
I beg to differ a bit... UmeySan 
a better way would be to use the ISPF member parts list with the output directed to a dataset,
after that a simple rexx could build the jcl to compile the <objects> with a given dependency
the rexx could be made smart enough to accept parameters so to build based on dependencies specified at tool run time !
*edited to correct a speeling error |
|
| Back to top |
|
|
UmeySan
Active Member
Joined: 22 Aug 2006
Posts: 771
Location: Germany
|
|
|
|
Hi Enrico !
Superb idea.
Also the list of programms which use the books could be investigated by a utility if the sources are poorly managed via Endevor or Panvalet. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
I'm all for standards, but they must be reasonable.
If you have enought FILLER to withstand many field additions for a while, and if the copybook changes involve adding new fields into the FILLER area, then programs which do not use the new fields need not be recompiled for technical reasons.
You certainly will need to manage which programs use which fields, but until the record length changes, non-affected programs are fine.
Given the vast number of programs and high frequency of field additions, I suggest you follow a policy other than "recompile everything no matter how trivial the copybook change." Any professionally run organization should be able to formulate and follow "standards" that meed their needs, as opposed to what everyone else does by rote. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
i understand what you mean about doing things by rote, but:
some of the more expensive repository tools (endevor)
make it difficult to promote a copybook without also recompiling the programs that use it.
the cheaper tools (changeman) make it difficult to easily recompile everything, and still make it difficult to promote a new copybook without the recompilation.
now, we all know that using a filler and not changing the length technically is not a reason to recompile the world.
and before these nifty repository tools, that's what we did.
i agree that this should be left up to the organization,
as they know their least common denominator - programmers skill sets.
but on a forum like this, that is populated with people with little or no background in mainframe skills,
refuse to read documentation and try to understand concepts,
i think it is better to tell them the safe way - recompile the world.
why, because they will see one time where someone said something about
unnecessary compiles and from then on, that is what they do and end up in a world of hurt,
and lay the fault at one of our posts. |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| dbzTHEdinosauer wrote: |
some of the more expensive repository tools (endevor)
make it difficult to promote a copybook without also recompiling the programs that use it. |
Actually, Endevor doesn't even warn you if you promote an updated COPYBOOK without promoting all of the COBOL code that references it, but it will do its darndest to prevent you from promoting COBOL code with a retrograde COPYBOOK (that is, one that is either not being promoted simultaneously, or does not already exist at a higher stage) - and that, regardless of whether or not the code references any newly defined elements that used to be filler.
When promoting an element in Endevor, subordinate elements, like copybooks, MUST exist at a higher stage than the element being promoted. That's why the Endevor SCL is "sorted" (according to the Type Processing Sequence established by the Endevor Administrator) before being invoked. The "usual" sequence is that copybooks get promoted before cobol code, macros get promoted before assembler code, procs get promoted before runjcl, etc. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| rashmi123 wrote: |
| ...The copybook is changing since new fields are expected everytime... |
I would say only a poorly designed system work like this...  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Design. . . We don' need no steenkin' design. . .
Why plan when it can simply spread. . . Like Kudzu . . .
 |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Marso wrote: |
| I would say only a poorly designed system work like this... |
Ah! I knew that there must be a term to describe our systems! |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| Where others see a poorly designed system, I see the Phrzby Phil Full Employment Act. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| ... I see the Phrzby Phil Full Employment Act. |
but most probably in a very unpleasant environment
poor design is most often a direct descendent of a poor ( in all senses ) organization
in my experience I have never seen a good organization produce bad designs |
|
| Back to top |
|
|
|
|
