VARRAY values in wrong position

, ,
1

We have a Natural subprogram whose PDA looks like this:

1 #MESSAGE-ID A 25
1 #X_ITEM_DATA (1:*)
   2 #ITEM_CODE A 18
   2 #DESCRIPTION A 150
   2 #LONG_DESCRIPTION A 240
   2 #PRIMARY_UOM A 2
   2 #STATUS_CODE A 40
   2 #ITEM_UDA_DATA_TABLE (1:*)
      3 #ATTR_NAME A 150
      3 #ATTR_DISP_VALUE A 250
   2 #ITEM_REPLACE_DATA (1:*) /*PP#43598
      3 #TYPE A 80 /*PP#43598
      3 #FROM_ITEM A 40 /*PP#43598
      3 #TO_ITEM A 40 /*PP#43598
1 #OUTPUT
   2 #SUCCESS_STATUS A 1
   2 #ERROR_DETAIL A 250

I suspect that the values for #ITEM_UDA_DATA_TABLE are provided for each occurrence of #X_ITEM_DATA, but it appears that this new #ITEM_REPLACE_VALUE is sometimes provided for each occurrence of #X_ITEM_DATA in the XML payload.

In one test case (XML sample attached), the first set of attributes for #X_ITEM_DATA did not send tags/data for #ITEM_REPLACE_VALUE, and the second set did. However, when Natural received the data, these #ITEM_REPLACE_VALUE values appeared in occurrence 1 which correlates to the 1st product, and so the Natural program not knowing differently handled them as such.

I would have expected these to appear in the Natural subprogram as such:

#TYPE(2,1) = ‘Substitute’
#FROM-ITEM(2,1) = ‘CLB201224’
#TO-ITEM(2,1) = ’ ’

#TYPE(2,2) = ‘Replacement’
#FROM-ITEM(2,2) = ’ ’
#TO-ITEM(2,2) = ‘BR1224N200R’

However, they appeared as occurrences (1,1) and (1,2).

Is there a way we can configure or organize the parameters such that if no #ITEM_REPLACE_DATA is ascribed to the first product but is ascribed to the second, that the 1st occurrence of #ITEM_REPLACE_DATA is blank and the 2nd occurrence retains the data in the intended occurrence?

Thanks,

Brian

XML.XML (7.62 KB)

2

Brian,
which version of the Natural RPC server are you using?
Thank you
Wolfgang

3

Hi Wolfgang,

Currently the environment is as such:

*** Initialize a Natural RPC server at 2015-07-12 23:31:06   
***   with name SRV1                                         
***   on host   CH40                                         
***   under     z/OS 01.07.00                                
*** Natural nucleus version       : 4.2.7                    
*** Natural system file version   : 4.2.7 service pack 14    
*** Natural RPC version           : 6.3.4 update level 0     
*** Highest supported RPC protocol: 2030                     
*** SYSIDL version                : 6.3.13.0

I know that’s old, but the good news is we are cutting over this weekend to the BC12 mainframe which will have this as the environment:

*** Initialize a Natural RPC server at 2015-07-14 08:45:46  
***   with name SRV1                                        
***   on host   CH40                                        
***   under     z/OS 02.01.00                               
*** Natural nucleus version       : 8.2.4                   
*** Natural system file version   : 8.2.4                   
*** Natural RPC version           : 8.2.4                   
*** Highest supported RPC protocol: 2040                    
*** SYSIDL version                : 6.3.13.0

Do you believe that will make a difference in how Natural receives the data from the XML payload?

-Brian

4

Hi Brian,
according to the described symptoms the Natural RPC server of NAT824 should solve the problem.
I would even recommend to use the Natural RPC NATRPC82 of NAT825L003 which is compatiblle with NAT824.
Best regards
Wolfgang

5

Wolfgang,

Many thanks for your help and advice! I will test under Natural 824 and with the NATRPC82 version supplied with NAT825L003 to see if this resolves the issue of how the input XML data maps to the Natural PDA.

Regds,

Brian