Passed Data Revealed

Walker Passed Data is like a Rubik's cube.  Until you learn out how to work it, it seems really complicated.
However, understanding Passed Data is a critical skill for those developing Tamaris transactions.


Tips and Tools : Tamaris : Personalizers : Foundation Elements : Passed Data Revealed



The secrets to understanding Passed Data

  • Looking at the Passed Data entries for a single subtransaction is like listening to the sound of one hand clapping.  Passed Data entries operate in pairs.


  • Passed Data processing controls passing the RINP (Read INPut Area) from one transaction to another, or from one subtransaction to another.  It is not used to directly pass information between transactions and subtransactions.  (However, since the first subtransaction inherits its RINP unchanged from its transaction, Passed Data indirectly controls passing the RINP from the previous transaction to the first subtransaction of the following multi-trans.)


  • Passed Data processing is only done between transactions or substransactions that have the same 2-character Passed Data class.


  • Passed Data processing operates between two buffers — the sending RINP as it exists after the end of the execution of the previous transaction or subtransaction, and a receiving RINP which will be used by the next transaction or subtransaction.


  • Passed Data processing is not done if the receiving transaction or subtransaction is marked as a Passed Data initiator.


  • The first 2000 bytes of the receiving RINP start out filled with spaces.  After Passed Data processing, any portions of the first 2000 bytes of the receiving RINP which were not populated with data as specified by the Passed Data entries will still have spaces.


  • There are 20 Passed Data entries, identified by letters A to T.


  • Passed Data processing looks at each pair of entries in order, starting with A and ending with T.  While the Passed Data entries can be set up so that the processing of later entries overwrites the processing done by earlier ones, it is poor programming practice to rely on this "feature", since this behavior will be difficult for future developers to see. 


  • To understand what will be passed, you must look at the Passed Data entries for both the sending transaction (or subtransaction) and the receiving transaction (or subtransaction).


  • For a particular entry, if the sending and receiving lengths are equal and non-zero (appears as non-blank on the TID screen), then data will be passed.  The specified number of bytes will be copied from the sending buffer starting at the displacement specified in the sending entry, to the receiving buffer at the displacement specified in the receiving entry.


  • The Passed Data length is limited to 999 bytes.  If 1000 or more contiguous bytes need to be passed, you must use two Passed Data entries.


  • To make coding easier, programmers often use identical layouts for part or all of the RINP for related subtransactions.  This often leads to Passed Data entries for both subtransactions that have identical displacements as well as lengths.  The system doesn't care whether the displacements are identical; it is only to help the programmers.


  • It is difficult to understand correct Passed Data entries, and virtually impossible to understand incorrect or unnecessary ones.  If you want your transactions to be maintainable, make sure all entries have the correct length, and get rid of any unnecessary ones!



Written by JC Cunningham