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
 

 

COPY BOOK with FILLER

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Chetan Kumar

New User


Joined: 03 Dec 2012
Posts: 35
Location: India

PostPosted: Sat May 31, 2014 7:58 pm    Post subject: COPY BOOK with FILLER
Reply with quote

Hi,

I have a copy book OUTREC with below details.

01 OUT-REC.
05 DATA-A PIC X(10).
05 DATA-B PIC X(15).
05 DATA-C PIC X(20).
05 FILLER PIC X(25).

This copy book has been used by 80+ programs. For a new requirement I need to add a variable DATA-D with PIC X(10). So how do I use the existing FILLER size, I mean only X(10) and remaining should be FILLER X(15).
This change is applicable for only 10 programs.

So for 10 programs, the copy book should act as below.

01 OUT-REC.
05 DATA-A PIC X(10).
05 DATA-B PIC X(15).
05 DATA-C PIC X(20).
05 DATA-D PIC X(10).
05 FILLER PIC X(15).


Suggestions please.
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat May 31, 2014 9:42 pm    Post subject:
Reply with quote

since no one is referencing the FILLER
you can redefine as you have
and no one will have a problem.

yes, you only need to recompile/link/bind(if db2) the 10 programs which will address the new DATA-D field.
Back to top
View user's profile Send private message
Chetan Kumar

New User


Joined: 03 Dec 2012
Posts: 35
Location: India

PostPosted: Sun Jun 01, 2014 8:44 pm    Post subject:
Reply with quote

Thanks for the reply.

Is the below redefinition in BOLD fine?

01 OUT-REC.
05 DATA-A PIC X(10).
05 DATA-B PIC X(15).
05 DATA-C PIC X(20).
05 FILLER PIC X(25).
05 FILLER REDEFINES FILLER.
10 DATA-D PIC X(10).
10 FILLER PIC X(15).


But in this case, all the 10+ programs needs to be recompiled or all the programs which uses this copy book (but not the new field) needs to be compiled and link edited?

In case, if we need to re-compile only 10 programs which uses the new DATA-D Field definition then how other programs which use this copy book will refer to it from the library after change.

i.e. If we say rest of the programs are not recompiled with the copy book after change, then it will refer to the old version fo the copy book. So if we delete the copy book member from the copy library, can we execute the programs which doesn't refer to the new change but uses the copy book??

If not, then how can other programs refer to the older version of the copy book, although each time during program execution it refers to copy book library?

Suggestions Please.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Mon Jun 02, 2014 2:02 am    Post subject:
Reply with quote

I think you are DRASTICALLY misinformed about copy books. They are used during COMPILE time -- and only during the compile -- to include source from an external source. The copy book is not used -- EVER -- during EXECUTION. Hence your statement
Quote:
although each time during program execution it refers to copy book library
is completely and totally wrong.

Second, why not simply use
Code:
01 OUT-REC.
    05   DATA-A PIC X(10).
    05   DATA-B PIC X(15).
    05   DATA-C PIC X(20).
    05   DATA-D PIC X(10).
    05   FILLER PIC X(15).
since this is the simplest, easiest way to make the change?

Third, only those programs using DATA-D need to be recompiled -- all other programs will not be aware of DATA-D and that is fine since that won't matter.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Mon Jun 02, 2014 3:50 am    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

Just as a note, you cannot REDEFINES a FILLER.

You can use FILLER to REDEFINES something else.

You need to be careful not to change the length of the 01 by mistake. Assuming you don't do that, the other programs which don't use the new field definition will operate correctly. They will continue, as previously compiled, to not know anything about the FILLER except the effect it has on group items it is subordinate to.

When it becomes necessary to recompile one or more of them anyway, they will pick up the new copybook, but, since they are not referencing the new field, they will be unaffected by the content of the new copybook.

Some sites dictate that when a copybook is changed, all programs using it must be re-compiled. Your site is not one of those, else you'd not have asked us.

If a data previously defined by a FILLER (of a particular length) is later defined in a different way, as long as the length of the data defined is not changed, then there will certainly not be a problem, and no actual need to recompile.

Sometime it will not be strictly necessary to recompile after a change in length, but it is probably a bad idea to try to get away with that, as someone will get confused (and it will usually happen at the worst possible time).

Follow site standards. If nothing there: length-change, recompile all programs using the copybook; only definition change, recompile those programs actually using the definition (which you'd need to compile anyway, to have the new code...).
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 460
Location: The Universe

PostPosted: Mon Jun 02, 2014 7:01 am    Post subject:
Reply with quote

The potential issue you have here - regardless of how you redefine your data definition - is you have data prepared using the old data definition. What is in the data constructed using the original data definition? And How is your program going to differentiate between data prepared using the original definition, and data prepared using the revised definition? Mr. Woodger and Mr. Sample ignored that issue, but, believe me, before you put this revised data definition into production you have to think about this issue.

I also believe you are going to have to touch programs that prepare data using the original definition to make sure they insert null data into the new area. Only programs that only read data using the original definition do not have to be modified.
Back to top
View user's profile Send private message
Chetan Kumar

New User


Joined: 03 Dec 2012
Posts: 35
Location: India

PostPosted: Mon Jun 02, 2014 2:46 pm    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

Thank you all.

I was just thinking about below statement made by Steve-Myers. Definitely it is very good point to look for.
(How is your program going to differentiate between data prepared using the original definition, and data prepared using the revised definition?)


Considering all the points, I believe it's always better to re-compile all the programs which use the changed copy book irrespective of whether it is a redefinition or change in length and whether the program only reads or change the contents of the modified fields.

Suggestions please.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Mon Jun 02, 2014 5:20 pm    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

Someone has either done the the analysis correctly, or they haven't. If only 10 programs require changing, then only 10 programs require compiling.

If the analysis has been done incorrectly, you may have more programs to change (even all of them, who knows?).

If you have programs using that copybook which do not have to be changed (and assuming as you have shown there are no VALUE clauses in the the copybook) then those programs do not need to be compiled. You can of course compile them anyway. It will make no difference.

So, the analysis is either correct or it is not. We could say that about any question, but it seems to have become important on this one. Whether or not correct, you only need to compile any programs which change.

I believe it is always a pointless waste of time and effor to re-compile programs which don't need to be recomplied. Some sites insist. It will not fix any problem, in the case of changing an existing FILLER to some other defintions.

If the analysis is incorrect, just recompiling the programs will not affect the outcome in any remote way. Just wasted time.
Back to top
View user's profile Send private message
chandan.inst

Active User


Joined: 03 Nov 2005
Posts: 269
Location: Mumbai

PostPosted: Mon Jun 02, 2014 5:25 pm    Post subject:
Reply with quote

Hi Ckumar,

I have a question with point highlighted by you and Steve-Myres

If you are changing a layout for one of the program out of all the programs which are using this copybook then are you expecting the data as input in Original as well as revised definition?

If you are populating DATA-D for 10 no of programs and this new definition used by other 10 programs then you would need to change and re-compile these 20 programs.

I do not see need to change or recompile other programs which are using Old definition copybook and not using DATA-D

steve-myers wrote:

I also believe you are going to have to touch programs that prepare data using the original definition to make sure they insert null data into the new area. Only programs that only read data using the original definition do not have to be modified.


Also here Already you are populating Nulls to new area as its Filler in old definition..

Instead changing all programs I would say you need to have correct impact analysis and list down the impacted programs and change accordingly

Regards,
Chandan
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Mon Jun 02, 2014 7:01 pm    Post subject:
Reply with quote

The impact depends, partly, upon what the copy book code is used for -- hence the need to do impact analysis. In a CICS program, for example, where the copy book is defining the layout of the COMMAREA, there would be no problem with old and new definitions being used simultaneously as long as the new data occurred at the end of the 01 variable, which is the case posted.

One thing to consider, too, is that if any programs already have a variable named DATA-D, error messages will occur the next time that program is compiled using the new copy book. The specific error message will depend upon whether the program DATA-D is an 01 / 77 level, a group variable other than 01, or an elementary variable and may indicate a duplicate variable is being defined or that qualification is required to access the variable.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Mon Jun 02, 2014 7:35 pm    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

it should also be considered that
if a source control package is used ( sclm,endeavor,changeman )

most probably an assembly will be forced of all the <users> of the copy book

I do not know about the others, but under SCLM
You <build> a <copybook> which implies that SCLM will compile all the sources using it.
Back to top
View user's profile Send private message
Chetan Kumar

New User


Joined: 03 Dec 2012
Posts: 35
Location: India

PostPosted: Wed Jun 04, 2014 1:04 pm    Post subject:
Reply with quote

Hi Chandan,

What I see is, if the changed field being used in the program, obviously those programs needs to be re-compiled.

But when it comes to a tool as said by Enrico, all the source programs which uses the copy book will be re-compiled.


I agree that it's a waste of time to re-compile all the programs irrespective of whether it is using the new updated field or not.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Jun 04, 2014 1:10 pm    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

If you are using a tool which requires that all programs are compiled when a copybook changes, why did you ask, in your second post on the topic, if all programs needed to be re-compiiled?
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Jun 04, 2014 5:53 pm    Post subject:
Reply with quote

I would never leave a program with the old copybook. I would compile them all.

Even if a program doesn't reference the new fields, it will have control over that record area. If it's writing a record, it will treat that area with indifference, which may be bad news for the programs that need that area to be correct.

But...here's the main reason: The next time that 'not using the field' program needs updated, it will pick up a new copybook that needs tested. My work ethic sees that as lazy and inconsiderate. It's been given to you to updated that record, so just do it and quit trying to weasel out of it.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Jun 04, 2014 8:04 pm    Post subject: Reply to: COPY BOOK with FILLER
Reply with quote

Two main schools of thought:

Re-compile everything.

Re-compile only what is needed.

For the first, you obviously need to test every program.

For the second, you obviously need to test the changed programs, and sufficient of the other programs to verify that they do not require changing (which may mean all of them).

Note that for any programs which do not require re-compiling, there is no further work for "the next person along".

The first gives you listings/object/loads that are "in-step".

The second avoids the investigation of fifteen programs which were compiled for the same release (subsequent bug reported) only to find that nothing changed in them. When ignoring programs compiled-with-no-changes, it is too easy to miss a one-liner in a program, which turns out to be involved with the actual problem.

The second can of course raise questions of "why wasn't this program compiled when the copybook was changed?".

The first can hide the fact that someone thinks recompiling something which doesn't need recompiling actually has a positive benefit for the executing system.

If tools or local standards dictate otherwise, the question is moot. If not, it is more manageable to compile only what needs compiling, and do all the testing necessary.
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 syncsort: copy lines after the keyword shreya19 SYNCSORT 1 Fri Dec 02, 2016 9:47 am
No new posts Single COPY CICS TS datasets and when... Kyle Carroll CICS 2 Tue Oct 11, 2016 9:47 pm
No new posts dataset copy question - REPRO or some... atulxp TSO/ISPF 2 Wed Aug 03, 2016 10:56 pm
No new posts How to copy Tape dataset to unix main... chaky All Other Mainframe Topics 4 Fri Jul 08, 2016 2:52 am
No new posts Using Field names in FILEAID Batch CO... Atul Banke Compuware & Other Tools 2 Wed Jun 29, 2016 9:54 pm


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