Page 1 of 1

Length Of leyword in cobol

PostPosted: Sat Nov 26, 2016 3:49 pm
by arya_starc
What is the output came after giving the LENGTH OF keyword to some variable
In program ws-variable define in working storage section as

01  WS-HOLI-TABLE.                                            
    03 WS-HOLIDAY-RECORD        OCCURS 3 TIMES                
                                INDEXED BY                    
                                X-HOLIDAY.                    
       07 WS-HOLIDAY            PIC 9(07).                    

 

And in procedure division they are using this line of code


     INITIALIZE WS-HOLIDAY-RECORD(1)                              
     MOVE WS-HOLI-TABLE          TO                              
          WS-HOLI-TABLE ( LENGTH OF WS-HOLIDAY-RECORD(1) + 1 : )  
 



Please tell the output that I get from the below line
LENGTH OF WS-HOLIDAY-RECORD(1) + 1 :
is it this below I am not sure...!!
INITIALIZE WS-HOLIDAY-RECORD(1)
MOVE WS-HOLI-TABLE TO WS-HOLI-TABLE(8:)

Re: Length Of leyword in cobol

PostPosted: Sat Nov 26, 2016 8:23 pm
by Robert Sample
Do you not know how to use the DISPLAY statement? Why not use DISPLAY to find out what the value is, rather than asking on a forum?

I suspect that the results of the MOVE are not what the coder expected. INDEXED BY doesn't change the way subscripts work.

Re: Length Of leyword in cobol

PostPosted: Sun Nov 27, 2016 3:11 am
by BillyBoyo
LENGTH OF WS-HOLIDAY-RECORD is seven. It need not, in IBM Enterprise COBOL, be subscripted - all the entries are fixed-length, so id doesn't matter if you use ( 1 ), ( 2 ), ( 3 ) or nothing. All the same.

Adding one to seven gets eight. The advantage of calculating using LENGTH OF (which is evaluated at compile-time for fixed-length fields) is that if someone changes the length of WS-HOLIDAY-RECORD, the code still works, "automatically".

The code is doing what was intended. It is an "offset move", a way of establishing a "pattern" across a table.

When COBOL's WORKING-STORAGE was more limited in size (1MB maximum) the "offset move" was the most effective way to initialise a table of packed-decimal values, or of a table with a more complicated structure.

For this example, with an exceedingly simple pattern (zeroes) I'd just MOVE ZERO TO WS-HOLI-TABLE and have done with it.

A better technique to use to efficiently initialise a table these days is to have a another table the same size (or larger), set your entire table to initial values (once) by your preferred method, and then MOVE the entire table to the second table. Then, when you need to re-initialise, MOVE the second to the first.