V5R3 Dynamic Array Dump problem

["Bramley, Stu" <stu.bramley@xxxxxxxxxxxxx>]

In OS/400 V5R2, if an RPG program containing a dynamic array is dumped, the
dump contains output similar to the following: 

NAME                  ATTRIBUTES           VALUE                 
                      DS                                         
  ARRAYELEMENT        CHAR(10)             DIM(32767)            
                        (1-32767)          NOT ADDRESSABLE       

In i5/OS V5R3, the dump contains output 

   ARRAYELEMENT        CHAR(10)             DIM(32767)     
                         (1)                NOT ADDRESSABLE
                         (2)                NOT ADDRESSABLE
                         (3)                NOT ADDRESSABLE
                         (4)                NOT ADDRESSABLE
                         (5)                NOT ADDRESSABLE
                         (6)                NOT ADDRESSABLE
                         (7)                NOT ADDRESSABLE
                         (8)                NOT ADDRESSABLE
                         ..(snipped)..                       
  
                                This continues for a number of elements
(variable in different jobs) until 

                        (1195)             NOT ADDRESSABLE   
                        (1196)             NOT ADDRESSABLE   
                        (1197)             NOT ADDRESSABLE   
                        (1198-32767)       NOT ADDRESSABLE   

This can make the size of the dumps very large and time consuming to produce
when the technique has been used.

Moreover, in attempting to address the individual elements of the dynamic
array that have not yet had memory allocated to them, the dump process
causes large number of authority failures (domain violations) to appear in
the security audit journals. 

These authority failures appear against an object of type *QTCPS. 

If a dynamic array has been declared with an arbitrary maximum length of
32767 elements then there can be in the region of 64000 authority failures
in the journal - which can very quickly consume a large amount of disk
space. 

The actual number of failures does not seem to bear an exact mathematical
relationship to the declared size of the array (i.e. it is not double the
size, or double minus the number of elements before the 'block' not
addressable entry) however it seems to be more than coincidence that it is
nearly double the number of array elements. 

If the basing pointer is de-allocated before the dump, the problem still
occurs. 

If the basing pointer is de-allocated with the (N) extender to set it to
null before the dump, the problem does not occur. 

This problem can be re-created with the following test harness (move/amend
the dealloc line to observe the changes in behaviour):

D dynamicArray@   S               *                              
D                 DS                  BASED(dynamicArray@)       
D  arrayElement                 10A   DIM(32767)                 
                                                                 
D nbrElements     S              5i 0 INZ(100)                   
                                                                 
 /FREE                                                           
   dynamicArray@ = %alloc(nbrElements * %size(arrayElement));    
   arrayElement(1) = 'TEST';

   dump(a);
   dealloc(n) dynamicArray@;

   *inlr = *on;                                                  
   return;                                                       
 /END-FREE                                                       

This problem does not occur at V5R2. 

Has anyone else experienced this and know of a workaround? We are planning
to place a call with IBM about this shortly... 

Regards,
Stu

Stuart Bramley 
Senior Technical Developer 
Skandia Life::GroupIT 
Southampton 
t: 023 80 72 64 29 e: stu.bramley@xxxxxxxxxxxxx 
IBM Certified Specialist