Martin Great job! - thanks for all the tests. It's just about the worst case possible. Only the upper case somewhat relieves the risk.
Even VTAM folk haven't been quite clever enough to spot the risk with the "@" variables but the chances of an "accident" with them is very, very small with all except @HOSTNET where the chance rises to very small - and the systems programmer is aware that the USS logic is scanning for "@" since he/she has specified the SCAN|LUNAME suboperand - with one small concern - see later. But the situation with the TN3270 logic is quite dreadful. The risk is quite considerable. Following my last post I've been trying work out just how significant the risk is with the ending character of the SBA sequence. For an USS message constructed for an 80x24 presentation space having 1920 character addresses, there is a 1 in 64 chance that the ending character in any SBA sequence is a particular one of the valid basic 3270 data stream characters and "&", X'50', is one of those particular characters. Thus, with each SBA sequence, the chance increases, 1 in 64 each time. If there are 8 such SBA sequences, a low estimate for a typical message created by a systems programmer designing a "pretty" panel for his/her end users, the chance for the whole USS message is 1 in 8. If the number is 16, perhaps a more reasonable estimate for an enterprising systems programmer, the chance for the whole message is 1 in 4! Now the whole reason for setting up SBA sequences is to position text - although some SBA sequences may be followed by SF sequences for the purposes of "colouring" the text - so the numbers above should be reduced where this combination applies. If the colleague of the enterprising systems programmer responsible for installation-defined system symbols happens to create one for the SBA sequence with the "&" character, the USS message, very probably USS message 10, the "good morning" message, will be ruined for all the end users who set up their TN3270 client following the IPL. I don't like those odds! - Regarding test g. The idea here was mainly to check whether the TN3270 implementation scanned for system symbols when the TEXT rather than the BUFFER operand was used. I was surprised that the VTAM implementation substituted the "@" variables but then I checked the manual and I see that is supposed to happen - which makes a small nonsense of having the SCAN|LUNAME for the BUFFER option and no comparable suboperand for the TEXT option. I'm beginning to wonder whether the thinking behind the SCAN|LUNAME suboperand might not have been about performance rather than awareness that substitution could take place. You'll note there is a rather silly comment "Note: For terminals with large screen sizes, searching the storage area for a character string might be a performance consideration." as if having a large "screen size" necessitated the USS message to be built using a large USS 3270 data stream! Anyhow, although not impossible, an USS message built using the TEXT operand is unlikely to have SBA sequences and so only the presence of a character string with an explicit "&" adjacent to text could cause a problem, my HAMMOND&DREW example. - Again, well done. Chris Mason On Wed, 19 Aug 2009 10:22:36 -0500, Martin Kline <[email protected]> wrote: >>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. > >The VTAM implementation does not skip order sequences for the '@' >character. These can also cause unintentional problems. > >>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". > >The VTAM implementation does not skip WCC chartacters either. > >>c. Does the VTAM implementation insist on upper case characters when >>matching "@"-based variables? Check with @hostnet. > >Upper and lower case are both matched. > >>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 '50', "unprotected". > >The TN3270 implementation does not skip order sequences when scanning for >ampersands either. > >>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! > >The TN3270 implementation does not skip WCC characters when scanning for >ampersands either. > >>f. Does the TN3270 implementation insist on upper case characters when >>matching system symbols? Check with &sysr1. > >The TN3270 implementation does recognize only uppercase characters when >scanning for system symbols. > >>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. > >The VTAM implementation replaces the @ variables and not system symbols. >The TN3270 implementation replaces both. > >>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! > >No kidding! ---------------------------------------------------------------------- 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
