Screen Demon Revision 3.60.01 BETA-TEST Release Notice Copyright (C) 1988 - 1995, Threshold, Inc. All Rights Reserved Contents I. Environment II. Installation III. Enhancements IV. Corrections V. ICOBOL 2 Support 1. Configuration Files For ICRUN 2. Creating the New ICRUN interpreter 3. ICOBOL Assembler Routines 4. Runtime Environment 5. Console Input Handling VI. Dynamic Configuration Files 1. Dynamic Configuration Mechanism 2. Runtime Configuration Lookup 3. Configuration Source Files 4. Compiling Configuration Files 5. Linking With Configuration Files VII. Notes and Warnings I. Environment Operating system: AOS/VS 7.56 or greater AOS/VS II 2.01 or greater (requires patch number 83 for 2.01) Host language: AOS/VS Interactive COBOL 1.40 - 2.07 AOS/VS COBOL 3.20 - 4.00 AOS/VS C 4.00 Other languages to be determined II. Installation 1. Screen Demon requires a directory accessible via the pathname :SCREEN_DEMON_3.60 This can be a link if you do not want to actually load Screen Demon into your root directory. This release should be kept separate from any previous version of Screen Demon. Rev 3.60 Screen Demon programs can be run simultaneously with programs using previous versions of Screen Demon, as long as they do not share the same Screen Demon directory. 2. DIR into the above directory. 3. Load the release tape, using one of the following commands, depending on the release media: 1600 bpi 9-track tape: LOAD/V/BUFFERSIZE=8192/DELETE :(0,1) 22-meg MV/2000 cartridge tape: LOAD/V/BUFFERSIZE=16384/DELETE :(0,1) QIC tape: TAR_VS/XTRACT/FILE=:0 LOAD/V/DELETE SD360(,U).DMP DELETE/V SD360<,U>.DMP 4. Install any update patch files loaded from tape file 1 using the command APPLY_SD_UPDATE This will also create the required subdirectory structure within the Screen Demon directory. 5. Revision 3.60 uses the same format for the SCREEN_DEMON.CONTYPES file as earlier revision 3 versions, so you should copy your existing version of this file to the new directory. The SD_TERMCAPS.SR file is the same as in revision 3.52,but with a fix: the model id for a D470C should be 44, not 54. If you have customized this file, you should use your version, but make sure that the D470C model id is correct. Then execute MAKE_SCREEN_DEMON.VM to create a new Screen Demon VM file for use by rev 3.60 programs. Do not link this file to the one of the same name (SCREEN_DEMON_3.00.VM) found in a previous revision of Screen Demon! While the file formats are the same, file locking parameters have been changed to correct an error, so the file cannot be shared with other versions of Screen Demon. 6. Revision 3.60 will use the same registration file as previous revision 3 Screen Demon releases. You will need to create a link in the new :SCREEN_DEMON_3.60 directory for the file SCREEN_DEMON_REGISTRATION_3.00 to point to the file of the same name in your older version's directory. Alternatively, you may use the "Move Registration" option of the older SD_REGISTER program to move this file to the new directory. In this case, if you plan to continue running programs containing the older revision of Screen Demon, you will need to create a link for the registration file in the old Screen Demon directory pointing to the file in the revision 3.60 directory. You may also temporarily register the new version independently using the key code supplied on the last page of this release notice. 7. If you plan to use the Screen Demon mail system, you should either create a new Post Office directory using the SD_INIT_MAIL.CLI macro, or create a link in new Screen Demon directory pointing to the Post Office directory in your older Screen Demon directory: DIR :SCREEN_DEMON_3.60 CREATE/LINK SD_POST_OFFICE :SCREEN_DEMON_3.52:SD_POST_OFFICE The link will allow programs using the two different revisions of Screen Demon to exchange mail. 8. The configuration file format is similar to that of revision 3.52, but no longer contains assembler labels, and includes additional options. Because of this incompatibility, revision 3.60 cannot use configuration files from earlier revision 3 releases. Existing configuration files can be updated by copying them to the revision 3.60 directory, and then executing the command SD_CONFIG_UPDATE config-file-name This CLI macro will modify the syntax of a revision 3.52 configuration file to the form expected by revision 3.60, and add the additional options at the appropriate locations. You will then need to compile the updated configuration files using MAKE_SD_CONFIG.CLI and/or MAKE_SD_ICX_CONFIG.CLI. See the Dynamic Configuration Files section of this release notice for information about new capabilities. 9. If you were using the Printer Switcher in rev 3.52, the format of the SD_PRISWI_CONFIG.SR file in rev 3.60 is the same. You should use your existing SD_PRISWI_CONFIG files. 10. If you have customized any of the following files in rev 3.52 Screen Demon, you should merge your changes into the rev 3.60 versions of these files: APPLY_SD_UPDATE.CLI MAKE_PRISWI_CONFIG.CLI MAKE_SCREEN_DEMON.SL.CLI MAKE_SCREEN_DEMON.VM.CLI MAKE_SD_CALCULATOR.CLI MAKE_SD_CALENDAR.CLI MAKE_SD_CALL.CLI MAKE_SD_CONFIG.CLI MAKE_SD_GATES.CLI MAKE_SD_HKD.CLI MAKE_SD_ICDEB.CLI MAKE_SD_ICX.CLI MAKE_SD_ICX_CONFIG.CLI MAKE_SD_ICX_NAMTB.CLI MAKE_SD_INNER_RING.CLI MAKE_SD_PLAY.CLI MAKE_SD_SPY.CLI MAKE_SD_SWAT.CLI NAMTB.SR PLAY.CLI SD_CCL.CLI SD_CLINK.CLI SD_INIT_MAIL.CLI SD_POSSESS.CLI SD_SEND_MAIL.CLI SDCALCULATOR.CO SDCALENDAR.CO SPY.CLI 11. Link rev 3.60 Screen Demon with your programs the same way as with the previous revision. For Interactive COBOL revision 1.40 - 1.71, the MAKE_SD_ICX.CLI macro is used as before; for ICOBOL revision 2.00 and above, the new MAKE_SD_ICRUN.CLI macro is provided (see the ICOBOL 2 Support section of this release notice). When building inner ring programs and shared libraries, the MAKE_SD_INNER_RING.CLI and MAKE_SCREEN_DEMON.SL.CLI macros function the same as in previous revisions. Do not attempt to use patches from an earlier version with rev 3.60. 12. The rev 3.60 Screen Demon shared library is downward compatible with the ones in previous revisions, including rev 2.01.05. Programs linked or possessed to use the shared library of earlier Screen Demon releases do not need to be re-compiled, re-linked, or re-possessed in order to use the rev 3.60 shared library. You may wish to run the MAKE_SCREEN_DEMON.SL.CLI macro to create a customized version of the rev 3.60 shared library. Then, arrange for your programs to find the new SCREEN_DEMON.SL instead of the older version. 13. Rev 3.60 Screen Demon inner ring programs are downward compatible with those created by previous revision 3 releases. Programs linked or possessed to use inner ring programs do not need to be re-compiled, re- linked, or re-possessed in order to use rev 3.60 inner rings. You may wish to run the MAKE_SD_INNER_RING.CLI macro to create a customized rev 3.60 inner ring; the only one included on the release tape is SCREEN_DEMON_RING_6.PR. Then, arrange for your programs to find the new inner ring programs instead of the older versions. III. Enhancements 1. This release of Screen Demon supports version 2 of Interactive COBOL. For complete information about creating a Screen Demon version of the ICRUN interpreter, see the ICOBOL 2 Support section of this release notice. 2. In previous releases, the Screen Demon configuration file had to be linked directly with the Screen Demon routines in an application program, inner ring program, or shared library. This meant that changing a parameter in the configuration file required re-linking all application programs, or rebuilding the inner ring program or shared library in order for the change to be effective. Revision 3.60 offers an alternative: dynamic configuration files. A program that uses a dynamic configuration file will read its configuration information from that file at runtime. Changes to the configuration file do not require any changes to the program. This method also permits different operators to have different configuration setups for the same program. For more information, the Dynamic Configuration Files section of this release notice. 3. Improvements have been made to the Turbo Display optimizer, resulting in fewer characters being sent to the terminal. IV. Corrections All known problems have been fixed, except for those listed in the Notes and Warnings section below. A complete list of corrections can be found in the text file SD_3.60.01_FIXES.DOC V. ICOBOL 2 Support This release of Screen Demon provides full support for the ICRUN interpreter found in version 2 of Interactive COBOL. All of the ICOBOL-specific features that previous releases of Screen Demon offered for ICOBOL revision 1.40 - 1.71, such as hot key access to ICOBOL programs, orderly termination from SD_SPY, showing the current ICOBOL program name on the SD_SPY Console Status Display screen, etc., are now available under ICOBOL revision 2.00 and above. The one exception is that Screen Demon revision 3.60.01 does not provide a means of creating a Screen Demon version of the ICOBOL 2 debugger, ICDEB.PR. Since new documentation for Screen Demon revision 3.60 is not yet available, the following section summarizes the information necessary to use Screen Demon features with ICOBOL revision 2.00 and above. Refer to the Linking with ICOBOL chapter of the Screen Demon revision 3.52 COBOL Programmer's Reference for additional information. Except where noted, the procedures for ICOBOL 2 are the same as those for previous versions of ICOBOL. 1. Configuration Files For ICRUN A Screen Demon version of ICRUN uses the same configuration files as used to create Screen Demon versions of the older ICX interpreter; by default, the filename used is SD_ICX_CONFIG.SR. Special note about ICOBOL hot keys: Due to restrictions of the ICOBOL 2.00 and 2.01 interpreters, only one ICOBOL program can be active as a hot key at any one time in these revisions. Later releases of ICOBOL do not suffer from this limitation. 2. Creating the New ICRUN interpreter To incorporate Screen Demon features in the ICOBOL 2 interpreter, a new version of the interpreter must be created. Since the ICOBOL 2 system is written in the C language, relinking the interpreter requires C runtime libraries. These libraries are part of the AOS/VS C development package. ICOBOL 2 releases distributed by Data General include a library file containing the necessary subset of the C and LANG_RT (AOS/VS Common Language Runtimes) libraries; this file is CRT.LB. If you did not receive your ICOBOL 2 release from Data General, your release media will not include the CRT.LB library. However, if you have a copy of ICOBOL revision 1.70 or 1.71, the CRT.LB file distributed as part of those releases can be used with ICOBOL 2. If you do not have either the CRT.LB file or the AOS/VS C development package, a Screen Demon version of ICRUN cannot be created; contact Threshold for assistance. The MAKE_SD_ICRUN.CLI macro is used to create a Screen Demon version of the ICOBOL 2 interpreter. It functions similarly to the MAKE_SD_ICX.CLI macro used for older versions of ICOBOL, and supports the same switches, with the exception of /CBCALL, /COB32, and /LANGRT. The additional switch /CRT instructs the macro to link the new interpreter with the CRT.LB file, even if the full AOS/VS C runtime libraries are available. If this switch is not specified, the macro will use the AOS/VS C package if it is present; otherwise, it expects to find CRT.LB. By default, the output program name is SD_ICRUN.PR. Note: You may need to modify the SEARCHLIST command located near the beginning of this macro. 3. ICOBOL Assembler Routines If you have assembler or C routines which you call from your ICOBOL programs, you should read this section. ICOBOL 2 uses a different interface to callable subroutines than the AOS/VS standard calling conventions used by previous versions of ICOBOL. If your routines already follow the ICOBOL 2 scheme, simply specify the names of your object modules as arguments on the MAKE_SD_ICRUN command line, and your routines will be linked into the new interpreter. Since the Screen Demon calls follow standard AOS/VS calling conventions, a Screen Demon version of ICRUN actually supports both methods. If your routines have not yet been converted to the ICOBOL 2 interface scheme, then you can still call them from COBOL programs by having Screen Demon translate the call parameters to the older format whenever your routines are called. To do this, add the names of your routines to the NAMTB.SR file as described in the Screen Demon 3.52 COBOL Programmer's Reference and compile it. Then specify the names of your object modules as arguments on the MAKE_SD_ICRUN command line. 4. Runtime Environment A Screen Demon version of ICRUN will execute properly only on Data General terminals or compatible emulators. ICOBOL 2 offers limited Screen Demon-like features in standard form. However, when the real Screen Demon is incorporated into the ICRUN interpreter, these features are superfluous, and in some cases, detrimental. ICOBOL 2 has two "environment variables" that control its Screen Demon-like functionality: ICSDMODE, which determines how boxes are drawn on the screen, and ICSCROPT, which indicates the degree of display optimization to perform. A Screen Demon version of ICRUN will ignore the setting of ICSDMODE. Boxes will be drawn in the best way for a particular terminal. The ICSCROPT variable should be set to "off" to minimize overhead in a Screen Demon version of ICRUN; there is no need for both ICRUN and Screen Demon to consume CPU resources in order to determine the optimum way to update the terminal screen. Screen Demon's Turbo Display optimization is considerably more efficient than ICRUN's, even at the latter's "full" setting. Note that even though the standard ICRUN interpreter supports some Screen Demon calls, in a Screen Demon-linked ICRUN, these built-in versions are disabled. All calls access the true Screen Demon routines. 5. Console Input Handling Although the console input handler for ICOBOL 2 is much more efficient than that of ICOBOL 1.70 and 1.71 since it was written specifically for AOS/VS, much of the discussion in the section "Special Notes for ICOBOL revision 1.70 and 1.71" in the Screen Demon revision 3.52 COBOL Programmer's Reference applies to ICOBOL 2 as well. This is because ICRUN still uses single-character I/O to perform console input, doing all of the echoing, delete processing, etc. itself, rather than delegating this processing to the IAC. As with ICOBOL 1.7, this method requires too much overhead to be permitted in a Screen Demon version of ICRUN. Screen Demon blocks the interpreter's normal input routines, and issues the equivalent field-oriented input request to the IAC using standard AOS/VS screenedit processing. This means that screen ACCEPTs function in the same way as in earlier versions of ICOBOL; special (non-screenedit) input keys supported by a standard ICRUN, such as Ctrl-N (position forward tab) and Ctrl-R (delete character at cursor), are not available in a Screen Demon version of ICRUN. VI. Dynamic Configuration Files Dynamic configuration files were introduced to allow a program's Screen Demon configuration information to be stored separately from the .PR file. In the "static" method used by previous versions of Screen Demon, parameter values were built into the program when it was linked; these values could not be changed without re-linking the program. Beginning with Screen Demon revision 3.60, a program has the option to read its configuration data from a file during startup; such a file is called a dynamic configuration file. Note that this is only an option; "static" configuration files are still supported. Dynamic configuration files offer a number of advantages over the linked-in "static" configuration file method. The primary one is that changing the configuration file does not require re-linking the programs that use it; the changes are effective as soon as the configuration file is rebuilt. Another advantage is that a given program's Screen Demon configuration can be different for different users, since the dynamic configuration file is located via a user's searchlist. Similarly, by using dynamic configuration files, a VAR can allow a customer to customize the configuration parameters without giving the customer a way to re-link the VAR's programs. Since new documentation for Screen Demon revision 3.60 is not yet available, the following section summarizes the information necessary to utilize dynamic configuration files. Refer to the Screen Demon Configuration chapter of the Screen Demon revision 3.52 Developer's Guide for additional information. 1. Dynamic Configuration Mechanism There are two parts to dynamic configuration file: a "stub" module called a loader that is linked with programs that will use the dynamic configuration file, and the main configuration data file which contains the Screen Demon parameter information. The loader module serves primarily to define the name of the dynamic configuration data file. In revision 3.60.01, it also identifies the linked-in hot key routines available in the programs with which it is linked. 2. Runtime Configuration Lookup When a Screen Demon program begins executing, whether or not it is linked with a dynamic configuration loader module, the program can optionally first look for a dynamic configuration file whose name is the same as the program, but with a ".SD" extension instead of ".PR". If such a file is found, the configuration information in that file will be used. Otherwise, if the program was linked with a dynamic configuration file loader module, the program will look for the configuration data file specified by the loader; failure to find the specified file will cause the program to terminate with an appropriate error message. If the program was linked with static configuration parameters, those values will be used if the initial program-specific configuration lookup was unsuccessful. Note that the initial program-specific configuration lookup can be suppressed if it is not desired, and is set to NO by default. When a program is looking for a dynamic configuration file, it first tries to find the file via the searchlist. If this fails, the program will look in the special Screen Demon configuration file subdirectory :SCREEN_DEMON_3.60:CONFIG 3. Configuration Source Files There is no difference in the source code for static and dynamic configuration files. The same source file can be compiled to be used as a static linked-in version, a dynamic file read at runtime, or both. There is an new option near the beginning of Screen Demon revision 3.60 configuration files that controls whether or not to perform the initial program-specific configuration lookup described above. This question is SPECIFIC_PROGRAM_CONFIG_LOAD? NO Answer this question YES if you want all programs using this configuration file to first look for a dynamic configuration file based on the current program name, falling back to this configuration file if that lookup fails. 4. Compiling Configuration Files Whether a particular configuration file becomes a static or dynamic version depends on how it is compiled. The MAKE_SD_CONFIG.CLI macro is used to compile configuration files as in previous revisions of Screen Demon; as before, the argument to the command is the name of the configuration file to be compiled, without an extension. However, this macro now accepts switches to control its output. The particular combination of switches and switch values specified determines whether a static configuration file, dynamic configuration file, and/or loader module is to be created, and what the names of these files will be: MAKE_SD_CONFIG configfile Creates a static configuration file named "configfile.OB", ready to be linked with a program. This is the same as previous releases of Screen Demon. MAKE_SD_CONFIG/DYNAMIC configfile Creates a dynamic configuration file named "configfile.SD", along with a matching loader module named "configfile.SDL.OB" MAKE_SD_CONFIG/DYNAMIC=dynfile configfile Creates a dynamic configuration file named "dynfile", along with a matching loader module named "dynfile.SDL.OB" MAKE_SD_CONFIG/DYNAMIC=dynfile/LOADER=ldrfile configfile Creates a dynamic configuration file named "dynfile", along with a matching loader module named "ldrfile.OB" MAKE_SD_CONFIG/LOADER configfile MAKE_SD_CONFIG/LOADERONLY configfile Creates just a loader module named "configfile.SDL.OB" which matches the dynamic configuration file "configfile.SD" MAKE_SD_CONFIG/LOADER=ldrfile configfile MAKE_SD_CONFIG/LOADERONLY=ldrfile configfile Creates just a loader module named "ldrfile.OB" which matches the dynamic configuration file "configfile.SD" MAKE_SD_CONFIG/DYNAMIC=dynfile/LOADERONLY configfile Creates just a loader module named "dynfile.SDL.OB" which matches the dynamic configuration file "dynfile" MAKE_SD_CONFIG/DYNAMIC=dynfile/LOADER=ldrfile/LOADERONLY configfile MAKE_SD_CONFIG/DYNAMIC=dynfile/LOADERONLY=ldrfile configfile Creates just a loader module named "ldrfile.OB" which matches the dynamic configuration file "dynfile" This macro also accepts an additional global switch, /PROGSPECIFIC, that is independent of the above /DYNAMIC, /LOADER, and LOADERONLY switches. Its function is the same as the configuration file question SPECIFIC_PROGRAM_CONFIG_LOAD? described above. If present, the switch value replaces the answer to the question in the configuration file being compiled. This switch can be specified with or without a value; no value is equivalent to a value of YES: MAKE_SD_CONFIG/PROGSPECIFIC configfile MAKE_SD_CONFIG/PROGSPECIFIC=YES configfile MAKE_SD_CONFIG/PROGSPECIFIC=NO configfile 5. Linking With Configuration Files When linking a Screen Demon program to use a static configuration file, specify the name of the static configuration .OB file on the command line (/CONFIG=), just as in previous revisions of Screen Demon. If the program is to use a dynamic configuration file, specify the name of the matching dynamic loader module on the command line instead. VII. Notes and Warnings 1. There is an annoyance with the input of fields longer than the width of the screen on the last line of the screen, such as when entering a command line in CLI. While in insert mode via ^E, at the point when inserted characters would extend the end of the line (including any hidden characters accessible via ^A but not initially displayed) up to the right margin, the terminal will beep and it will no longer be in insert mode. 2. Field-oriented inputs that begin beyond column 80 may actually occur at column (col - 80). 3. Newer versions of VS/COBOL remember the console timeout setting from the most recent ACCEPT, and will not issue system calls to reset it if the setting is already thought to be correct. This can cause problems if a VS/COBOL subprogram is called from a hot key, since the COBOL runtimes do not expect multiple ACCEPT's to be active at the same time. If an ACCEPT in a hot key routine has a timeout, but the ACCEPT where the hot key was pressed does not, then pressing the hot key twice at the same ACCEPT will result in the hot key subprogram's ACCEPT occurring without a timeout the second time. Work-around patches for various revisions of VS/COBOL can be obtained from Threshold if this is a problem for your system. 4. Screen Demon does not support the "Selected Field Translation" option of the ?WRITE system call. The only program this seems to affect is DISPLAY.PR. 5. Screen Demon does not support the undocumented "Edit Read" subpacket of the ?READ system call. The only programs known to use this option are CEOWRITE.PR and CEO_WP.PR. 6. SD_PLAY cannot properly play a console log file backward if it contains D400 hardware window or margin commands. 7. SD_SPY only shows 80 columns even if the remote process being viewed has the screen in D400 compress mode. 8. Because of the design of the ICOBOL revision 1.70 and 1.71 interpreter, it is not possible to invoke an ICOBOL program via a Screen Demon hot key from an input occurring as a result of an assembler call from an ICOBOL program. For example, the Screen Demon Calculator program, which is written in ICOBOL, uses the SD_READ_CHAR call to input characters from the keyboard, rather than using an ACCEPT statement. If a hot key is pressed that is assigned to another ICOBOL program, such as the Screen Demon Calendar program, it will be ignored. Any other type of hot key will execute normally. 9. There is a problem with console interrupt handling in ICOBOL revisions 1.70 and 1.71 that occasionally causes the interpreter to panic or hang when ^C^A or ^C^B is pressed. This is not a Screen Demon problem, since it can also occur with the standard ICX when ^C or ^\ is pressed. However, because of the potential for ISAM file corruption, you may wish to set the Screen Demon configuration file option IGNORE_CONSOLE_INTERRUPTS? to YES. Note that the ICX switches /NOINT and /NOQUIT will not help! 10. A problem in AOS/VS revision 7.69 and 7.70 affects Remote Input in SD_SPY. If Remote Input mode is activated and then released for a particular console, it will be impossible for any Spy process to go back into Remote Input mode for that console until the process that was running on that console terminates. The error message will be "Remote PID Already Controlled By PID 0". This problem is fixed by patch # 38 for AOS/VS 7.70, which is available from Data General. 11. An optional patch distributed with AOS/VS 7.72, 7.72_XXXZRS.PR_ESBB.OPAT, mentions "Certain applications that utilize the 3rd party SCREEN DEMON software rely on this functionality." This IAC driver patch should be installed only when using Screen Demon revision 3.00.03 without the Screen Demon patch NO_?ESRD_NO_?ESBB_3.00.03.PAT; no other version of Screen Demon requires it. 12. Various real problems with the ?ESBB system option used by Screen Demon do exist in AOS/VS 7.70 and above, and AOS/VS II 2.10 and above. Each operating system release corrects earlier problems, but adds new ones! For this reason, it is suggested that the optional Screen Demon patch NO_?ESBB_3.60.01.OPTPAT be installed if you are running under these versions of the operating system. This patch should not be installed if you are running earlier versions of AOS/VS. 13. Screen Demon revision 3.60 does not support the ICOBOL 2 debugger. 14. If a Screen Demon process terminates abruptly without executing the normal shutdown procedures, such as when a CLI TERMINATE command is issued against the process, or a process trap or system crash occurs, information in the Screen Demon VM file for the console where that process was running may be left in an invalid state. This will not affect application programs containing Screen Demon, but can occasionally confuse the SD_SPY program enough that it cannot work around the corrupted data. The main symptom is that SD_SPY will hang when displaying some portion of the list of active consoles. If this occurs (it should be much less frequent in revision 3.60 than in previous releases), the Screen Demon VM file should be rebuilt using the MAKE_SCREEN_DEMON.VM.CLI macro. It is also suggested that this file be rebuilt whenever the system is rebooted following a crash. Note that console interrupts (^C^A, ^C^B, etc.) and termination via SD_SPY will not cause this problem since Screen Demon will shut down properly on these events.