Juergen It would have helped if you had indicated where the "quotation" ended. I can't be sure whether your last paragraph is part of the quotation or your thoughts.
Anyhow thanks for dragging this confession out of IBM and passing it on to us all. Because there is (a) VTAM logic supporting text exchanges on the SSCP-LU session and (b) entirely separate TN3270 logic supporting text exchanges on the TN3270 connection, the opportunity exists for divergence. Where the two approaches should have come together is in requiring a bit to be set as a result of an USSMSG macro operand or suboperand to *authorise* the replacement of text based on detecting system symbols. This would have required a change to macros which are "owned" by the SNA (VTAM) side of the Communication Server house. You are right that one table would be nice and the mutual tolerance of the "@" variables which apply to only one environment or the other allows this. However I'm not sure that most customers would see much benefit in this. When USS support was introduced into the TN3270 server the possibility to use the VTAM table object module with the TN3270 server was a handy starting option. However if you want to benefit from the TN3270-only "@" variables, you are likely to create a table specifically for that environment. It is this table into which you are going to add the system symbols. Chris Mason On Thu, 30 Jul 2009 03:20:46 -0500, Juergen Keller <[email protected]> wrote: >hello everybody, >thank you also for the responses. My fault was, that I only looked in the >VTAM-books as done for years. So I didn't find/knew the new functions in IP. >But .. I opened a question at service-link about this and this is the answer: > >Even though both TN3270 and VTAM SNA are using the same USSMSG macros, >it is two different components in Communications Server writing the >USSMSG to the terminal. As such it takes modifications to two different >modules to understand the system symbolics, replace the variables and >write the actual content to the terminal. There was a requirement that >was addressed for TN3270 access and this function was implemented >because there were many customer asking for this. At the same time no >customer raised this request for SNA access so there was no need to put >additional code into the SNA USSMSG code. > >It would be nice to have this functions in TN3270 and SNA to have only one >unique table but as I understand we need another requirement and also many >customers asking for this.... and this will be the "problem". > >regards Juergen ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
