Let me state categorically that existing programs that issue messages with one-byte console IDs will continue to work.
What we have done is remove the ability to create new programs or re- assemble old programs using one-byte console ID interfaces. The ability to specify one-byte console IDs on the WTO and WTOR (and a few other macros) has been removed. We have also removed two-digit numeric console IDs as an external on the L=, CN= and CN() command parameters. In z/OS R8, we have gotten rid of the Master Console, which used to be the console to which messages were queued if the console they had been directed to was unknown. In R8, we have created a new console queuing attribute called UNKNIDS which allows messages directed to an unknown console to be queued to any console with this attribute. (We likewise created another queuing attribute INTIDS which allows messages directed to console ID 0 to be queued to any console with this attribute). Removal of the ability to specify one-byte console IDs and the introduction of the UNKNIDS attribute may seem unrelated, but in a future release messages issued with one-byte console IDs will be treated as unknown messages. However, the UNKNIDS attribute will allow these messages to still be queued to one or more consoles of your choice. So let me reiterate again: 1) programs that issue messages with one-byte console IDs will continue to work; 2) messages issued with one-byte console IDs can continue to be queued to consoles. However, in some future release, the message will be queued by the UNKNIDS attribute rather than its one-byte console ID because in that future release no console can have a one-byte console ID. W. Kevin Kelley IBM POK Lab -- Core Technical Development ---------------------------------------------------------------------- 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
