Notes on the CONSOLE Macro

  1. CMS cannot coordinate I/O for applications that modify PSWs in low storage and issue their own DIAGNOSE code X'58' instructions. Until all applications use the console facility instead of DIAGNOSE code X'58', you may see data from two different applications mixed on the screen. If mixed data does appear on the screen, you can do one of the following (as appropriate):
    1. Your application can specify the EW or EWA options of CONSOLE WRITE to gain control of the screen.
    2. You can press the CLEAR key or issue a command that causes an erase/write.
    3. For applications running in full-screen CMS, you can write an EXEC to (a) issue a SET FULLSCREEN SUSPEND command, (b) invoke the full-screen program, and, when processing completes, (c) resume full-screen CMS by issuing a SET FULLSCREEN RESUME.
    4. When you issue CONSOLE WRITE, if CP breaks in and writes a screen or if another application had previously used the CONSOLE macro to write a screen, you will receive a return code of 32. If you get return code 32, respecify CONSOLE WRITE using the EW (erase/write) or EWA (erase/write alternate) options.

      Note that if you have issued a CONSOLE READ and CP breaks in and writes a screen (such as a CP warning message), the read is performed and a channel end/device end is returned to CMS. The Console facility gives your application a return code of 0. Your application should examine the data stream attention identification (AID) to determine whether there are any modified fields to process. An AID byte of X'60' indicates no operation or an unsolicited attention. CP will likely return X'8E' in the unit status byte of the CSW/SCSW (causing the CONSOLE macro return code 32) on the next full-screen write.

  2. If you are using the CONSOLE EXCP function or a CONSOLE WRITE with the WSF option, the CONSOLE facility does not know what operation is being requested because it does not scan the buffer or verify the CCWs. Because of this, the application may need to do more screen coordination of its own. For example, a write will be issued regardless of the fact that another path last wrote to the screen. Either an EW/EWA can be done to ensure a complete erasure of the screen, or, a CONSOLE QUERY PATH can be issued to check the CQYPLIO field. This will tell if your path was the last path to do I/O using the CONSOLE macro, and whether you need to do an EW/EWA.
  3. Applications that need to coordinate line mode and full-screen I/O should use the WAITT macro before they issue the CONSOLE macro. WAITT waits for any pending line mode I/O to complete.
  4. Many full-screen applications run disabled for interrupts in their I/O routines so they will not receive unsolicited interrupts at that time. This should also be done in applications using the Console facility so an interrupt does not come in when CONSOLE is returning to the application, particularly if the application has not established their own interrupt handling routine. This is important for WSF operations that generate attention interrupts back to CMS.