RE: V5R3 Dynamic Array Dump problem

["Bob Cozzi" <cozzi@xxxxxxxxx>]

If you are on V5R3, you may want to try %SUBARR when doing your DUMP.
I am NOT certain if it works with the DUMP instruction, but you never know.
For example:

   dump(%subarr(a:1:nbrElements));

This built-in was provided for just this kind of thing; a dynamic array
where you only want to access a subset of the array for things like SORTA
and XFOOT.

-Bob Cozzi


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bramley, Stu
Sent: Friday, November 19, 2004 8:26 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: V5R3 Dynamic Array Dump problem

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
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.