Martin You seem to have a sandbox available to you so I would like to suggest some more tests.
a. Does the VTAM implementation skip order sequences when scanning for "@" characters? Check with HOSTNET preceded by an SF with attribute byte X'7C', "protected", "autoskip" and "nondisplay" - which is going to make it difficult to see! - which tends to being an excuse for not bothering since it's so unlikely. Note order sequences in inbound USS data streams *are* removed prior to the string being parsed against the USS commands. That's how I got away with using MDT[1] on the text fields in LOGON APPLID( ________ )MODE( ________ )DATA( ____________________ ) where "_" represents an input field. This was the part of the 3270 data stream I placed on line 24 of my USS 10 messages. b. Does the VTAM implementation skip WCC characters when scanning for "@" characters? Check with HOSTNET at the very beginning of the USS message with a X'7C' Write Control Character which means "reset", "80-character print line", "start print" - beware in case you have a local printer defined - and "sound alarm". c. Does the VTAM implementation insist on upper case characters when matching "@"-based variables? Check with @hostnet. d. Does the TN3270 implementation skip order sequences when scanning for "&" characters? Check with SYSR1, the volume serial number of the volume used for IPL, preceded by an SF with attribute byte X'50', "unprotected". e. Does the TN3270 implementation skip WCC characters when scanning for "&" characters? Check with SYSR1 at the very beginning of the USS message with a X'50' Write Control Character which means "40-character print line"but, since the "print bit" is not set there no risk of wasting paper! f. Does the TN3270 implementation insist on upper case characters when matching system symbols? Check with &sysr1. g. Just to be sure that this enhancement applies only to USS messages defined using the BUFFER operand and not the TEXT operand, try coding an USS message using the TEXT operand and with &SYSR1 in the text and see what happens. If the system symbol is substituted, try @@@@DATE. Now that you've mentioned that the SCAN|LUNAME suboperand is not required I can't trust any aspect of the TN3270 implementation of variable substitution in USS messages! Note that there's not too much point in checking the TN3270 implementation with "@"-based variables since the only possibly difficult one is @HOSTNET, having only one "@" character. Since @HOSTNET is not considered relevant for TN3270, it is substituted with blanks. An "accident" with "@"-based variables is possible but just about vanishingly remote. Chris Mason [1] Which reminds me I got something wrong regarding the MDT in a previous post. Recall that the "&" character when used as an attribute byte implies an "unprotected", "input", field. I suggested it was unlikely without the MDT bit. This is muddled thinking! The connection between an "input" field and the MDT bit is that the MDT bit is set when anything is actually keyed into the "input" field. Is it a sad comment on the extent to which my posts are being read that nobody spotted this! On Mon, 27 Jul 2009 13:58:39 -0500, Martin Kline <martin.kl...@yrcw.com> wrote: >My test showed system symbols were replaced by removing or adding >characters as necessary. (Because I can't remember exactly how to get >ampersands to diplay correctly on the list server and I'm too lazy to look it up, >my examples will use pound signs, '#', instead). > >For example '---#SYSNAME---' is displayed as '---SYS1---'. At least on the >1.9 release I have installed. This does NOT display as '---SYS1 ---'. > >My advice is if you depend on exact positioning for the other characters on >the screen such as drawing a box around your data, or drawing a pic of a >dinosaur (like I do), then use SBA orders to position the trailing data correctly. > >As Chris indicated, the other non-system symbols that can be replaced do >specify what happens with alignment, spaces, numerics, etc. The issue is with >the system symbols, because the names of the variables may be either longer >or shorter than the values that get substituted. > >Bonus question: > >If your USS message contains SBA orders, and the address happens to end in >X'7C', such as such as X'11C17C' for row 2 column 45 on an 80-character wide >screen, and the following characters happen to match one of the allowed >keywords, what happens? Likewise, what happens when the SBA happens to >end in X'50'? > > >Chris said: >>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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
