Martin Having now verified that Scott Rowe was correct, there will be no overlaying because the substituted text is too long since this is not allowed. However, I can see that, in the event that you inadvertently use a valid system symbol name following your second address byte or the attribute byte, you will destroy the address byte or attribute byte and so distort the presentation of the text.
Yes, the whole design is a total mess. I suggest you hit your IBM support with this shoddy design with as much force as you can muster. It's incompetence piled on incompetence, in the implementation *and* the description. It shows what can happen when the "suits" force a "quick-and-dirty" enhancement and use developers who clearly don't understand the environment in which they are working to implement it. When the "@" variables were introduced into the text specified by the BUFFER operand - starting with @@LUNAME - the VTAM developers thought about what they were doing. In case of the massively unlikely - but still possible - event that, for whatever your reasons, you had @@LUNAME already coded in your USS messages, you were obliged to acknowledge - the LUNAME and then SCAN suboperand - that you had sorted this out before committing to the additional manipulation of your text. Having acknowledged that you wanted this substitution to take place, you were now primed for any additional variables being introduced.[1] Thus what should have happened is that a new bit needed to be specified - corresponding to a new (sub)operand in the USSMSG macro - so that, with the introduction of system symbol support, the systems programmer can inform the processing logic that he or she understands that he or she wants the new function and has taken care that "accidents" - very much more likely in this case - will not happen. Instead the "people of inadequate intelligence" have amazingly done the exact opposite. They don't even care about the SCAN|LUNAME bit. Thus even if the systems programmer had noticed the change, he or she may have noted that there was no risk since the SCAN|LUNAME bit would not be set. Actually all this is a bit unlikely but developers are supposed to take such considerations into account - and used to![2] I'm guessing that the reason they shied away from altering the USSMSG macro in order to have, as it were, *permission* to modify the possibly long- established USS message text is that they didn't want to involve the SNA (VTAM) side of the Communication Server house in their clandestine enhancement. It's cheaper if you just impose the change in the TN3270 server logic. Incidentally, in the light of the mendacity involved in slipping in the description of this "new function" under the description of the SCAN|LUNAME operand with which you say it has absolutely nothing to do, I now have to revise my supposedly improved description of this "new function". So, here's my second revision of the description of this botched enhancement and its botched description: <improved text 1> LUNAME|SCAN Specifies that the entire string specified by BUFFER is searched using the @ character. When @ character is detected, 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. </improved text 1> with something like the following to be placed under "Usage notes": >improved text 2> Guideline: Support for system symbols Whether or not the SCAN|LUNAME suboperand is specified, when the BUFFER operand is used, the entire string specified by BUFFER is searched using the & character. When a & character is detected, system symbols are replaced with the appropriate values in the position in the message where the character string occurred. When using system symbols, an extra & must be prepended to the system symbol in order that the assembler compiler creates the correct output. For example, system symbolic &sysname. must be in the table as && [3]sysname. for the compiled output to be &sysname.. </improved text 2> I'm assuming that the system symbol replacement happens only in the case of the use of the BUFFER operand and not in the case of the use of the TEXT operand. Chris Mason [1] OK, I have to admit that this doesn't allow for a scenario all too frequent these days of the systems programmer who understood what was going on being "let go" and the "suits" appointing a replacement who imagines USS stands for UNIX System Services having, say, been to a number of SHARE meetings where USS was massively misused! [2] How often have I seen the IBM internal documents which are the output of the designers to the coders and authors and wondered at how thorough the considerations had been. [3] I hope this stops the list processing from making a meal of the double- ampersand! On Tue, 28 Jul 2009 11:26:57 -0500, Martin Kline <[email protected]> wrote: >"Strange and wonderful" was a good guess. The code which scans the buffer >does not check for 3270 orders, and may simply overlay them. Aparable? Since >the description reads, "The entire string specified by BUFFER is searched, >using the character @," I suppose this depends on how you want to interpret >the text. > >Another strange behavior is that the system symbols are converted whether >or not 'SCAN' is specified on the USSMSG macro, but the other '@' variable >substitutions occured only when SCAN was specified. Also aparable? > > > >John said: >>From the context in which you ask, I'd guess something "strange and >>wonderful" occurs; but I've been too long away from "serious" 3270 >>datastream coding to remember anything unusual about SBA addresses >>ending with the values you cite. Of course, I'm "ass.u.ming" you follow >>the SBAs immediately with SF[E] orders.... ---------------------------------------------------------------------- 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
