Copybook is being used by 10 different programs.

[Jagjeet Dayal]

Hello All,

I was being interviewed and in it received a question as:

" suppose if a same copybook is being used by 10 different programs and if I change some fields / added new field of the copybook for one program then will it get impacted on the other set of programs. And if yes then what will be the impact and how can we correct it??"

[Robert Sample]

It depends upon the changes. Assuming the copy book has some filler, and assuming that the filler is at the end of the copy book, then you can change it with little impact. If the copy book has no filler, or if the filler is not at the end, then every program using that copy book will need to be recompiled to pick up the new length and offsets.

The general rule of thumb is that it is best to recompile every program that uses a copy book every time the copy book is changed in any way. This ensures that the changes did not create duplicate variable names in a program using the copy book. However, if the copy book length and variable offsets don't change then you could get away without recompiling all the programs (at least for a while).

[DanteMut]

Are there filler fields in the copybook, and are they located at the end, or is there no filler or it's not at the end, which could impact every program using the copybook and require recompilation?

[CuonMam]

If the copybook undergoes changes, how does the presence or absence of filler fields, and their location within the copybook, influence the impact on programs using it and the necessity for recompilation?

[Jagjeet Dayal]

It depends upon the changes. Assuming the copy book has some filler, and assuming that the filler is at the end of the copy book, then you can change it with little impact. If the copy book has no filler, or if the filler is not at the end, then every program using that copy book will need to be recompiled to pick up the new length and offsets.

The general rule of thumb is that it is best to recompile every program that uses a copy book every time the copy book is changed in any way. This ensures that the changes did not create duplicate variable names in a program using the copy book. However, if the copy book length and variable offsets don't change then you could get away without recompiling all the programs (at least for a while).

Thanks. This is helpful Robert.

Why it is only for a while? Is there some more condition which can change it?

[Jagjeet Dayal]

Are there filler fields in the copybook, and are they located at the end, or is there no filler or it's not at the end, which could impact every program using the copybook and require recompilation?

This was interview question. Not a real time situation. One of the option given was that it had fillers in the last of the copybook. And then I said, we don't need to recompile the programs which are not using the new filed/s added.

[Jagjeet Dayal]

If the copybook undergoes changes, how does the presence or absence of filler fields, and their location within the copybook, influence the impact on programs using it and the necessity for recompilation?
 

I am also looking for the answer. I am not very sure about it.

[Robert Sample]

COBOL programs, when compiled, are not using variable names.  They are using offset and length instead.  So when making changes to a copy book, AS LONG AS THE OFFSET AND LENGTH do not change, the copy book does not need to be recompiled into programs.  However, any changes to offsets or lengths requires all programs using that copy book to be recompiled.  Why?  Because the program will use the old offsets and lengths and hence will pick up data in the middle of the variable instead of at the beginning.  If you have FILLER in the copy book, COBOL ignores those fields and does not reference their offsets or lengths.  So if there is a 5-byte FILLER starting in position 23 and you need to add a 2-byte variable before it, you can add the variable and change the FILLER to 3 bytes.  The variable after the FILLER will thus be in the same position as it was, so nothing using that variable would need to be recompiled.  Take a compiled program and look at the DMAP for it -- you will see each variable has offset and length.  Having a FILLER at the end of the record allows additional fields to be added to the end of the record without changing the record length (and forcing a recompile).  The DMAP is generated by the MAP compile option and looks like:

Code: Select all

Data Division Map                                                                                                               
Data Definition Attribute codes (rightmost column) have the following meanings:                                                 
    BL= Fixed byte-length UTF-8       FB= Fixed-length blocked file          S = Spanned file                                   
    D = Object of OCCURS DEPENDING    G = GLOBAL                             U = Undefined format file                          
    DL= Dynamic length                O = Has OCCURS clause                  V = Variable-length file                           
    E = EXTERNAL                      OG= Group has own length definition    VB= Variable-length blocked file                   
    F = Fixed-length file             R = REDEFINES                          X = Unallocated                                    
Source   Hierarchy and                                    Base      Displacement  Asmblr Data                      Data Def     
LineID   Data Name                                        Locator     Structure   Definition        Data Type      Attributes   
     2  PROGRAM-ID MF0074------------------------------------------------------------------------------------------------------*
     9   77 WS-START. . . . . . . . . . . . . . . . . . .             000000000   DS 10C            Display                     
    10   77 WS-SENDING. . . . . . . . . . . . . . . . . .             000000000   DS 10C            Disp-Num-Edit  R            
End of Data Division Map                                                                                             

Code: Select all

The Displacement is the offset.

From a different post, "Why it is only for a while? Is there some more condition which can change it?"  It is not an ideal situation to have a program that was not compiled with the latest version of the copy book.  Someone could have duplicated a variable name, or done a RENAME, or otherwise done something that could impact the way the code compiles and runs.  As a professional, I would be worried about any program needing recompilation for very long.

[enrico-sorichetti]

as usual replies are concerned only about the lowly technicalities
things to consider ...

legal / auditing / paper trail
certification that the change has passed all the tests  and all the affected components have been rebuilt
most auditors frown about dates mismatches

the developing environment used,
most of them keep track of the dependencies and force a rebuild of the whole package
so the choice is automatic




 

[Jagjeet Dayal]

COBOL programs, when compiled, are not using variable names.  They are using offset and length instead.  So when making changes to a copy book, AS LONG AS THE OFFSET AND LENGTH do not change, the copy book does not need to be recompiled into programs.  However, any changes to offsets or lengths requires all programs using that copy book to be recompiled.  Why?  Because the program will use the old offsets and lengths and hence will pick up data in the middle of the variable instead of at the beginning.  If you have FILLER in the copy book, COBOL ignores those fields and does not reference their offsets or lengths.  So if there is a 5-byte FILLER starting in position 23 and you need to add a 2-byte variable before it, you can add the variable and change the FILLER to 3 bytes.  The variable after the FILLER will thus be in the same position as it was, so nothing using that variable would need to be recompiled.  Take a compiled program and look at the DMAP for it -- you will see each variable has offset and length.  Having a FILLER at the end of the record allows additional fields to be added to the end of the record without changing the record length (and forcing a recompile).  The DMAP is generated by the MAP compile option and looks like:

Code: Select all

Data Division Map                                                                                                               
Data Definition Attribute codes (rightmost column) have the following meanings:                                                 
    BL= Fixed byte-length UTF-8       FB= Fixed-length blocked file          S = Spanned file                                   
    D = Object of OCCURS DEPENDING    G = GLOBAL                             U = Undefined format file                          
    DL= Dynamic length                O = Has OCCURS clause                  V = Variable-length file                           
    E = EXTERNAL                      OG= Group has own length definition    VB= Variable-length blocked file                   
    F = Fixed-length file             R = REDEFINES                          X = Unallocated                                    
Source   Hierarchy and                                    Base      Displacement  Asmblr Data                      Data Def     
LineID   Data Name                                        Locator     Structure   Definition        Data Type      Attributes   
     2  PROGRAM-ID MF0074------------------------------------------------------------------------------------------------------*
     9   77 WS-START. . . . . . . . . . . . . . . . . . .             000000000   DS 10C            Display                     
    10   77 WS-SENDING. . . . . . . . . . . . . . . . . .             000000000   DS 10C            Disp-Num-Edit  R            
End of Data Division Map                                                                                             

Code: Select all

The Displacement is the offset.

From a different post, "Why it is only for a while? Is there some more condition which can change it?"  It is not an ideal situation to have a program that was not compiled with the latest version of the copy book.  Someone could have duplicated a variable name, or done a RENAME, or otherwise done something that could impact the way the code compiles and runs.  As a professional, I would be worried about any program needing recompilation for very long.
 

Thank you so much for this detailed explanation, this really helps me.

[Jagjeet Dayal]

as usual replies are concerned only about the lowly technicalities
things to consider ...

legal / auditing / paper trail
certification that the change has passed all the tests  and all the affected components have been rebuilt
most auditors frown about dates mismatches

the developing environment used,
most of them keep track of the dependencies and force a rebuild of the whole package
so the choice is automatic





 

Hi Enrico,

I am not sure if I follow what you are suggesting. You mean to say that copybook change is part of audit? And what choice is automatic?

[enrico-sorichetti]

You mean to say that copybook change is part of audit?

audit levels depend on the company standards, the laws under which the company operates
the application development/deployment process and the change management process ( derived from the above )
and ... there are also external audits/verifications  ( IRS for example )

since a copybook might be part of a change requests, it could be part of a audit/review

And what choice is automatic?

 

software development control applications keep track of the dependecies betwen the components (*)
copybooks, common functions/subroutines and main programs
a change in a copybook might affect lots of object
since the objective  of a software development control application is to keep everything in sync
a little change might force a rebuild of many objects
in a very strict environment even changing  a comment in a copybook might have unintended consequences

the developer has just the choice  to follow the house rules.

(*) look at the parts list dialog in ISPF