>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
