Ron The summary:
VTAM USS does *not* support MVS system symbols The TN3270 server supplied by the z/OS Communications Server (CS) IP component *does* support MVS system symbols starting with z/OS V1R8. See my post to Pat O'Keefe where I quote the New Functions Summary manual for V1R8. See also my post to Martin Kline where I quote the text in the CS IP Resource Definition Reference manual in the confusing form offered by the manual authors - and - a post to Juergen Keller where I offer an improved version of the text which properly recognises that there are now *two* marker characters, the original "@" for traditional inserts[1], and the new "&"[2] only for MVS system symbols[3]. I expect that *any* MVS system symbol, the ones supplied, "system-defined", and any your system programmers create, "installation-defined", will be valid as an insert - not just "some". According to section 2.2 "What are system symbols?" in the MVS Installation and Tuning Reference manual, &SMFID[2] is *not* one of the very few system-defined static symbols - nor, unlikely in any case, one of the dynamic system symbols. Thus you are going to have to ask the assistance of your system programmers in setting up any additional system symbols you may want to appear in your USS messages, including &SMFID[2]. I too would be interested in testing mainly because the manner in which the MVS system symbol is inserted totally absent from the description, a deficiency on a par with the botched way in which this new function has been described. Chris Mason [1] Of which the first - by itself if I remember correctly - was @@LUNAME, hence the alternative LUNAME to the suboperand value SCAN - which will be required. [2] I do hope the list system isn't going to be excessively boring and screw up the ampersands. [3] Called uniquely in the CS IP Resource Definition Reference manual - I expect - and uniquely for the USS messages, "system symbolics". On Mon, 27 Jul 2009 08:47:15 -0500, Ron Wells <[email protected]> wrote: >from what I gather some synbols not support---vtam vs tcpip.. >is there or has some tested which apply..? >at this point only interested in tcpip/tn3270 and have the smfid of the >system being displayed.. > > > >From: >Martin Kline <[email protected]> >To: >[email protected] >Date: >07/24/2009 07:58 AM >Subject: >Re: USSTAB >Sent by: >IBM Mainframe Discussion List <[email protected]> > > > >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
