PI51031: INCORRECT OUTPUT GENERATED WHEN A TRANSACTION IS IN A LARGE INPUT FILE, BUT WORKS IN A SMALLER FILE.

APAR status

• Closed as program error.

Error description

• We are noticing a transaction is failing to generate the correct
  output when used in a large input file with several other
  transactions , but the same transaction generates the correct
  output when used in a smaller file with fewer transactions.
  
  We are getting incorrect data for one of the lines in the first
  output (CTXGOOD.SRT) as below:
  
  \GS*  ***      *    * * *
  
  This is with the transaction beginning with "5200METAVANTE CORP
  M391165550CTXSUMMARY   1509241509242681051400500001349"  in the
  input file.
  
  The same transaction when it appears in a smaller input file -
  GoodX12_success.txt  works and the output generated is correct
  and GS record is generated as below;
  
  GS:  \GS*RA*051000017*062000019*150924*1049*1*X*003020
  
  But when the same transaction appears in a large file -
  GoodX12_fails.txt which has several other transactions , it
  messes up the GS data.
  
  I was able to notice the same locally .
  
  Upon further research, I see that when using the large file
  (GoodX12_fails.txt) , the input 1 contains errors.
  
  It gives  -
  " Input type contains errors" .
  
  <inputstatus card="1" bytes="6795596" adapterreturn="0"
  contentreturn="28"/>
  
  I am not sure if this is causing an issue , because in the map
  (after I simplified) , there are 2 o/p cards and the second o/p
  card is a reject function of the whole input group. If I delete
  this 2nd o/p card, the GS is produced as expected for the large
  file as well.
  

Local fix

• WTX00047418
  AR/AR
  

Problem summary

• Users Affected:
  WebSphere Transformation Extender customers who get unexpected
  mapping output that depends on the input size or work file size
  
  Problem Description:
  In some rare case, a specific large data causes a map to build
  incorrect output or fail with 'Input type contains error'. The
  same map works correctly when using different data or paging
  sizes. The problem was caused by failing to reset types in work
  files.
  
  Platforms Affected:
  All
  

Problem conclusion

• The code was fixed to correctly clear the work file pages after
  the data is processed.
  
  Applies to:
  8.3.0.6, 8.4.0.5, 8.4.1.3
  
  Fixed in the next service packs and releases.
  
  To obtain the fix for this APAR:
  
  To see if the next service pack or product release is available,
  check the WebSphere Transformation Extender Downloads page:
  http://www.ibm.com/support/entry/portal/product/other_software/t
  ransformation_extender
  
  If the service pack or product release is available, download it
  from PassportAdvantage:
  http://www.ibm.com/software/howtobuy/passportadvantage/pao_custo
  mers.htm
  
  If the service pack or product release is not available and you
  require the APAR fix immediately, request a Limited Availability
  Interim Fix (LAIF) by opening a PMR:
  https://www.ibm.com/support/servicerequest/Home.action
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WEBSPHERE DESIG

• Fixed component ID

  5724M4008

Applicable component levels

• R830 PSY

     UP

• R840 PSY

     UP

• R841 PSY

     UP