Martin > ... but felt you should know I haven't dropped the discussion.
That's good to know! > It's highly unlikely someone would ... but, 'highly unlikely' is just the > type of open pit someone eventually falls into. Precisely. It's because of that "open pit" - 'for some value of' likely see later - that I describe this as botched and you describe it as "sloppy" whether a technician or a "suit" is responsible. If the systems programmer had been obliged to indicate that he/she knew about system symbols by means of a change in the coding of the USSMSG macro before deliberately inserting system symbol matches - and checking for unwanted matches under guidance from helpful documentation, we'd not be causing a fuss. > I believe the ampersand (x'50') is representative of the unprotected numeric field without the MDT and with normal intensity, not light-pen detectable. Correct. What it does by implication is establish a field in which whatever text is placed is coloured green when only the basic 3270 data stream is used[1]. I have seen system programmers deliberately colour their USS message fields without regard to whether or not the colour caused the field to become unprotected. > It's 'highly unlikely' and even slightly absurd to follow this with a non- numeric string like 'SYSNAME'. (Defining a numeric input field and filling it with non-numerics). The "numeric" aspect would certainly be odd but, as you said above, create a trap and someone may fall into it. The "text" aspect is much more open. It doesn't have to be a text like "SYSNAME" but something which corresponds to an installation-defined system symbol. This makes the trap one which doesn't show up on day one, but could snap shut at any time after the system programmer changes system symbols. And let us not forget the possibility that an "&" character appears in some explicit text such as a company name where blanks are left out as a matter of style or lack of 3270 space. I used a fictitious company name HAMMOND&DREW in an earlier post and supposed that a systems programmer had for, perfectly good reasons, decided to create - perhaps before the upgrade to V1R8 or at some time later - a system symbol &DREW. You might like to add that case to the tests in order to be clear about the nature of the "open pit". Chris Mason [1] In full, IIRC Green: unprotected, normal intensity Red: unprotected, high intensity Blue: protected, normal intensity White: protected, high intensity On Tue, 11 Aug 2009 08:47:28 -0500, Martin Kline <[email protected]> wrote: >>You seem to have a sandbox available to you so I would like to suggest some >>more tests. > >Yes, but only as time permits - I am working on those tests, but felt you >should know I haven't dropped the discussion. > >>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. > >It's highly unlikely someone would use an SBA ending with x'7C', the '@' >character, and immediately follow that with the character string, '@PRT', >resulting in the text '@@PRT' but, 'highly unlikely' is just the type of open >pit >someone eventually falls into. It's also 'highly unlikely' someone would turn >off >the main power to the data center, but I've seen it happen twice. > >>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. > >I'm not sure most people know the difference. I believe the ampersand (x'50') >is representative of the unprotected numeric field without the MDT and with >normal intensity, not light-pen detectable. It's 'highly unlikely' and even >slightly absurd to follow this with a non-numeric string like 'SYSNAME'. >(Defining a numeric input field and filling it with non-numerics). ---------------------------------------------------------------------- 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
