COPY BOOK with FILLER

Chetan Kumar · New User Joined: 03 Dec 2012 Posts: 46 Location: India

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.

dbzTHEdinosauer · Posted: Sat May 31, 2014 9:42 pm

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.

Chetan Kumar · New User Joined: 03 Dec 2012 Posts: 46 Location: India

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.

Robert Sample · Posted: Mon Jun 02, 2014 2:02 am

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

Bill Woodger · Posted: Mon Jun 02, 2014 3:50 am

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...).

steve-myers · Posted: Mon Jun 02, 2014 7:01 am

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.

Chetan Kumar · New User Joined: 03 Dec 2012 Posts: 46 Location: India

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.

Bill Woodger · Posted: Mon Jun 02, 2014 5:20 pm

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.

chandan.inst · Posted: Mon Jun 02, 2014 5:25 pm

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

Robert Sample · Posted: Mon Jun 02, 2014 7:01 pm

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.

enrico-sorichetti · Posted: Mon Jun 02, 2014 7:35 pm

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.

Chetan Kumar · New User Joined: 03 Dec 2012 Posts: 46 Location: India

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.

Bill Woodger · Posted: Wed Jun 04, 2014 1:10 pm

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?

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

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.

Bill Woodger · Posted: Wed Jun 04, 2014 8:04 pm

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.