Martin Thanks to you we now know that, when the substituted text has fewer characters than the system symbol, the length of the text string is reduced and there is no substitution with blanks, for example. This is in sharp contrast to the variables defined with the aid of the "@" character where left- justification and padding to the right with blanks is the unvarying rule!
Thanks to Scott Rowe we now know that the substituted text cannot have more characters than the system symbol. This is not allowed and would be detected at the time of definition. It was always a liberation provided by the BUFFER operand of the USSMSG macro that a systems programmer could indulge in his or her skill with the 3270 data stream.[1] Thus, as you say, it is possible to compensate for the variability[2] of text length by positioning individual elements of text by use of the 3270 data stream set buffer address (SBA) order. My experience with creating particularly USS message 10 is that the SBA order should be used routinely when the message is subject to SSCPFM=USS3270 (or USS3275) in order to position the text on the so-called "presentation space". With such an approach, any shrinkage should not be a problem. > 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'? For those not having an EBCDIC table to hand, X'7C' is "@" and X'50' is "&". I had to rely on recalling that the SNA Formats manual had the "SNA Character Sets and Encodings" section tucked away at the end of the manual. Actually, of the two cases, the "@" case is the one less likely to cause problems. Only @HOSTNET just might be a problem - for a company or a program that just happens to be called "HOSTNET" perhaps! I agree that system symbols always requiring just one "&" "introducing character" - and with the possibility of any 8-character string not already in use being available to system programmers as an user-defined system symbol - are liable to fall foul of being found as the last character of an SBA order sequence and also an attribute byte following a Start Field (SF) order[3] and join up with whatever text happens to follow so that they are literally "misinterpreted". This puts me in mind of a similar problem of "working as designed but not necessarily as intended" in the case of the "blank suppression" feature of USS messages. "Blank suppression" is not used when the BUFFER operand is used to define the message and so does not apply to SBA order sequences in a message defined with the BUFFER operand. I must have been using the 3270 data stream in a message defined with the TEXT operand. I was also positioning probably an attribute byte in the first position of the presentation space and so my SBA order address was X'4040'. When I threw up my hands in disgust at what appeared on the display fortunately I had a VTAM development colleague who pointed out that the OPT=BLKSUP|NOBLKSUP operand existed and that OPT=BLKSUP - for "terminal" USS messages - was the default. In order to complete this post, I decided to undertake a close comparison of what was stated about the "@" variables in the two manuals purporting to describe the same topic. There was something of a curiosity in the @....@zoneid variable. It is fully defined in the SNA manual but is clearly an IP entity. It is, however, described as being replaced by blanks in the IP manual![4] There is also something of a disagreement over the @....@ipadd - or should it be @....@ipaddr - variable. Crossed wires and twisted undergarments seem to be the order of the day! - and that's before I start on the convoluted way the IP manual goes about the detailed descriptions - so I won't!!! A final point is that the IP manual is not explicit as the SNA manual is about the role of the @@@@RUNAME and @@@SENSE variables. However, since MSG07|NOMSG07 are used to control an aspect of the TN3270 server processing, we are obliged to assume - not what descriptions in manuals are supposed to require! - that these two variables are handled in a manner equivalent to their role in the VTAM implementation. Chris Mason [1] In fact this was also possible with the TEXT operand but was very messy - not impossibly messy! - to code and could give rise to assembler error messages involving the number 255 - IIRC - which could safely be ignored. I think the reason I wanted to have fancy 3270 formatting with the TEXT operand was that there was a time when the USS message 7 variables were available only with the TEXT operand. [2] Not oblivious to the pun so introduced! [3] The RA order is not a problem since the sequence involves specifying the repeated character. Well, it's a problem if you don't wake up to what you are doing and use a "@" or "&" character as your, say, "box" characters. EUA is an unlikely order to be using in an USS message - although there's no accounting for ingenuity! For example, if you were to dismiss the attribute byte because it required the "modified data tag" bit to be set and you wouldn't expect that bit to have any use with an USS message, I would have to disagree since I have used it to great effect. Incidentally, I have not considered cases involving other than the basic data stream since I made it a rule to limit my USS messages in such a way that they would be valid for any 3270 "device". Particularly today, others may not feel it necessary so to limit their endeavours. [4] It's interesting to speculate on the possibility that the @....@zoneid is present in order to support one of the fields that can be carried in Control Vector 64 and so might apply to configurations involving a TN3270 server other than the z/OS Communications Server TN3270 server. For reference the CV64 subfields are as follows together with the relevant variable names: X'81' IP address subfield (always present) - @....@ipadd X'82' Application port number subfield (always present) - @@PRT X'85' IP host name subfield (optionally present) - @....@iphostname X'86' IP address scope zone identifier (optionally present) - @....@zoneid On Mon, 27 Jul 2009 13:58:39 -0500, Martin Kline <[email protected]> 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
