This TPXL0099 message floods the TPX log along with the related SNAP dump. It occurs with the XYZSYS user, which is logged by an automated process that exchanges TN3270 protocol messages.
There is no problem in the process. The goal is to eliminate the cause of this message.
TPXL0099 09/13/16.257 08:16:18.33 DATA STREAM ERROR
SNAP MODULE= 16.257 08:16:18.339492 VTERM=XYZUNIP USERID=XYZSYS APPLID=XYZIMS12 ( )
The occurrences of the DATA STREAM ERROR occur in a particular direction.
The XYZSYS user is an automated process that logs in to TPX and opens sessions with IMS. In some VTs it sends a request (a transaction) to IMS and in others called XYZUNIP or XYZUNID, it receives the answer. Despite the messages, the process works well.
In this client's setup, IMS sends an unformatted (EDTN) message to the VT in pure text, so TPX warns it with TPXL0099 DATA STREAM ERROR.
If IMS sends the message as a formatted screen, with 3270 attributes, there is no problem.
Release: NVINAM00200-5.4-TPX-Session Management-Access Management package
Since TPX is a VTAM application and needs to follow all of the 3270 protocols to display data correctly, the applications also need to follow 3270 attributes in a formatted manner.
The permanent resolution is to alter the program to send the answer as a formatted screen instead of plain text.
As an interim workaround, you can temporarily discard TPXL0099 messages from the TPX LOG by using the LOG Writer Exit. The Log Writer exit is called after a TPX LOG message has been formatted but before it has been written to the LOG DD. The exit can selectively write the message to the console or tell TPX to discard the message.
IMPORTANT >>> Since TPXL0099 can have many more messages than just DATA STREAM ERROR, we strongly encourage you to only discard these on a very temporary basis until the permanent application change can be implemented.
If you leave the exit in place permanently and encounter any future problems with TPX, then you could be missing crucial diagnostic information.
-In other cases where this problem was encountered while following 3270 protocols, this resolved the log messages for IMS: