Page 1 of 1

Avoiding MAPFAIL

PostPosted: Fri Mar 23, 2012 6:17 pm
by sinmani
How can we code a program such that we will never get a MAPFAIL error?

Is it by giving FSET in parameters of any one of the fields on the MAP??? This FSET will truen MDT on and no MAPFAIL occurs??

Re: Avoiding MAPFAIL

PostPosted: Fri Mar 23, 2012 6:40 pm
by Robert Sample
How can we code a program such that we will never get a MAPFAIL error?
Short answer: there is no way to code a program to avoid a possible MAPFAIL. From the CICS Application Programming Reference manual on the RECEIVE MAP command (emphasis added):
MAPFAIL

occurs if the data to be mapped has a length of zero or does not contain a set-buffer-address (SBA) sequence. It applies only to 3270 devices. The receiving data area contains the unmapped input data stream. The amount of unmapped data moved to the user's area is limited to the length specified in the LENGTH option. The input map is not set to nulls. This condition also arises if a program issues a RECEIVE MAP command to which the terminal operator responds by pressing a CLEAR or PA key, or by pressing ENTER or a PF key without entering data. Default action: terminate the task abnormally.
So if you can educate your terminal users to NEVER use a CLEAR key, or PA key, or hit the enter key by accident before entering data -- then you could prevent a MAPFAIL. Barring that, however, you program MUST be able to handle the condition.

Re: Avoiding MAPFAIL

PostPosted: Fri Mar 23, 2012 8:12 pm
by Monitor
Normally MAPFAIL just indicates that no data has ben entered in any of the fields, and thus the MDT-bit is not set in the fileds attribute-byte. CICS issues a "Read Modified" 3270-command, and receives data from fields that has the MDT-bit set. When you get MAPFAIL, this just tells you that no field has been modified, an really is "normal".
In program logic you have to check if data has been entered in mandatory fileds. The result may vary, and is a result of users action. Zero or many fileds may have been modified.
In your program logic you should FIRST check for invalid PF/PA/Clear-keys, and ONLY do a Receive Map after the check. There is no need to do a Receive Map if the user pressed the Clear or a PA-key, as an example. The EIBAID contains the value for the key pressed to initiate this pseudoconversation - even without a Receive Map.
If you use Resp Option, coding RESP(ws-variable) in your Receive Map, you can eliminate the Mapfail problem. If you have an "old-style" program using Handle Condition, there is more to say, and recommendation is to just go away from this styel/model.