Martin Note that there is only one set of USS macros and they some from a VTAM distribution library, SISTMAC1.
> The IP reference, however, also indicates that you can use system symbols, whereas the SNA reference does not. Interesting! >From the explanation of the SCAN (alternately and originally LUNAME) suboperand of the BUFFER operand of the USSMSG macro as described in Chapter 16, "TN3270E Telnet server" of the Communications Server IP Resource Definition Reference manual: <quote> System symbolics are also replaced with their appropriate value. When using the system symbolics in the USS table, an extra ampersand (&) must be prepended to the system symbolic for the assembler compiler to create the correct output. For example, system symbolic &sysname. must be in the table as &&sysname. for the compiled output to be &sysname. </quote> So well done for pointing out where to find out how to specify so- called "system symbolics" - is that usual terminology for "MVS system symbols"? - in the USSMSG macro. I hadn't bothered to look in the IP manual being blinkered by the sure knowledge that the USS macros are the responsibility of the SNA side of the Communications Server product and I tend to make a rule only to seek out information from the source. Second-hand descriptions are very likely to suffer from the "Chinese whispers" effect. However this is an exception for the good reason the IP side has added function! Traditional run-time substitutions take place because the SCAN suboperand value of the BUFFER operand sets a flag which causes the managing logic to look for the @ character - as is said by the two sentences preceding the text quoted above: <quote> Specifies that the character strings listed in Table 33 on page 687 are replaced with the appropriate values in the position in the message where the character string occurred. The entire string specified by BUFFER is searched, using the character @. </quote> The text in the equivalent position, namely the explanation of the SCAN|LUNAME suboperand of the BUFFER operand in the Communications Server SNA Resource Definition Reference manual is as follows: <quote> Specifies that the character strings listed in Table 91, will be replaced with the appropriate values in the position in the message where the character string occurred. The entire string specified by BUFFER will be searched, using the character @. </quote> It is only in the Communications Server IP Resource Definition Reference manual that the additional information about so-called "system symbolics" has been added. However all this fuss about making sure that an ampersand appears in the text as compiled - or assembled - in front of the MVS system symbol name, for example ampersand|ampersand|SYSNAME (spelling out the name of the symbol and using the concatenation symbol in what may be a futile attempt to defeat the destructive attention of whatever logic processes these posts when an ampersand appears!), seems to show there is additional function supported by the TN3270 server version of the USS processing logic which relies not on searching for a @ character but an ampersand character and that specifically for following text describing MVS system symbols - or so- called "system symbolics". So it's down to a somewhat garbled description in the manual - as these confusions so often are - and the SNA-side folk responsible for the macros are not involved! Perhaps they should be! Ron's previous thread related to using something like the OSA-ICC TN3270 server as a means to be the z/OS console. If he is also going to use that particular TN3270 server to log onto TSO, for example, he will find that the flavour of USS table used with the VTAM LOCAL definitions will *not* have support for MVS system symbols or "system symbolics". > Because some of the symbols, such as sense code and RU name, can only be supplied when the message is being displayed, VTAM and TCPIP must be scanning the message for symbols and replacing them at that time. Incidentally, there are also @@@@DATE and @@@@TIME variables! Chris Mason On Fri, 24 Jul 2009 07:58:03 -0500, Martin Kline <[email protected]> wrote: >VTAM and TCPIP handle the screens differently if the manuals can be trusted. >The two manuals are SC31-8776 z/OS Communications Server IP Configuration >Reference, and z/OS Communications Server SNA Resource Definition >Reference. > >Both manuals describe the USSMSG macro. Both specify that if you want to >dynamically substitute certain values such as LUNAME, HOSTNET, SENSE, >SSCP name, etc, then y6ou have to code the USSMSG macro with the SCAN >operand. Then, in the area defined by BUF1, you can code any of the >supported symbols. Because some of the symbols, such as sense code and RU >name, can only be supplied when the message is being displayed, VTAM and >TCPIP must be scanning the message for symbols and replacing them at that >time. > >MSG10 USSMSG MSG=10,BUFFER=(BUF1,SCAN) > >BUF1 DC AL2(length of buffer) > . . . > DC C'-------WELCOME---------@@SSCPNM' > . . . > >The IP reference, however, also indicates that you can use system symbols, >whereas the SNA reference does not. SO, if this USS table is being loaded by >TCPIP/TN3270, then you may be able to use system symbols. But, if the table >is loaded by VTAM, then you may not. > >The IP reference also makes a vague reference to how the assembler handles >the ampersand symbol. It indicates that you must code double ampersands in >your 'DC' instruction in order to get a single ampersand in the assembled code. >That is correct. ---------------------------------------------------------------------- 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
