"Why does my (3270 / 5250) component work properly when I animate step by step, but give unexpected results (or throw errors) when I execute in Designer or deploy it as a service?"  This is a question that almost all new users of these enablers seem to ask at some point.  The answer is usually quite simple, and usually involves a component where the navigation (MAP Screen) and associated send key (SEND ATTENTION KEY) actions has been modified with the use of copy and paste.

Although not recommended, Copy and Paste are supported in these enablers.  When I speak of Copy and Paste, I am referring to the copying of Map Screens and their actions, not copying and pasting non-navigation or "regular" actions such as ordinary Map actions.  Although it may seem more time-consuming at development time, it is almost always much safer and less costly to re-record sections of script than it is to copy and paste from other sections or components.

Several things can (and often do) go wrong when pasting Map Screens and their actions.  When recording, xCommerce captures the number of fields on each screen, then (by default) uses it as a way to enforce the integrity of the script when it's deployed.  By comparing the number of fields received on a screen against the expected (recorded) value, xCommerce can throw an error which will notify someone that either the script is 'off course' (not on the expected screen), or the actual screen has been changed in production.  If a BMS (green screen) is changed in production after a recording, the field numbers on the new screen may not correspond with the originals, thus the script may be moving data to incorrect fields.  If you copy and paste a Map Screen, you will most likely need to disable the integrity check by double clicking on the Map Screen, and uncheck the "Error when" box (see below), and then add modify the count once the new screens field count is known.  Remember if you do not re-check the "Error when" box and modify the count, then you are going to deploy components that will be ignorant of any changes made to the BMS maps and the result may be bad data returned to the requestor.

At runtime, this simple Map Screen will throw an error in if there are not 27 fields on the green-screen.  To disable it, double click on the Map Screen action and disable the check in the dialog below.

The most common problem with unexpected results comes from a Map Screen with no Attention-Key followed by another Map Screen.  Each Map Screen must send one (and only one) Attention-Key, before another screen can be received.  The two most common instances of errors are:

1)       An "Attention-Key" is sent under a decision branch, but not both (all) branches

2)       Complex logic where a screen is received, then a loop with other screens executes below it.  This type of logic might be used when sending PF keys to scroll screen data left/right or paging up/down or creating your own 'Multi-row' type of navigation. 

The code sample above might run properly in Designer, when stepping through an animation.  However, when this code is executed in Designer, or deployed to the Server, unpredictable results will occur when the False path is taken.  To correct the code above, place another Attention-Key within the False path.

The reason it is hard to test an action model of this sort adequately at design time is that, in order to test comprehensively, every path of every decision fork (in all possible combinations) must be executed to see that no bugs are hidden in a given branch. Testing of this sort is tedious and (under deadline conditions) sometimes impractical to do. And sometimes, even if you step through a "bad fork" using Animation, you find that there are no apparent errors, but the same code, at runtime, doesn't work. Defensive programming is your only out.

A simple way of determining that an Attention-Key is missing from a Map Screen is to look at the Message Log.  You will most likely see the following message somewhere in the listing:

More than 1 screen has queued up already. Error

Before going into production, study your Message Log. You might find some surprises there.