DG/RDOS Release Notice Revision 3.00 Model Number 30568 October 1992 085-000345-11 DESKTOP GENERATION, ECLIPSE, and NOVA are U.S. registered trademarks, and DG/500, ECLIPSE MV/1000, ECLIPSE MV/1400, ECLIPSE MV/2000, ECLIPSE MV/2500, ECLIPSE MV/3000, ECLIPSE MV/3200, ECLIPSE MV/3500, ECLIPSE MV/3600, ECLIPSE MV/5000, ECLIPSE MV/5500, ECLIPSE MV/5600, ECLIPSE MV/7800, ECLIPSE MV/9000, ECLIPSE MV/9300, ECLIPSE MV/9500, ECLIPSE MV/9600, ECLIPSE MV/15000, and ECLIPSE MV/18000 are trademarks of Data General Corporation. Restricted Rights Legend Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at [FAR]52.227-7013 (May 1987) DATA GENERAL CORPORATION 4400 Computer Drive Westboro, MA 01580 Unpublished -- all rights reserved under the copyright laws of the United States. Copyright (C) Data General Corporation, 1983 - 1992 All Rights Reserved Licensed Material -- Property of Data General Corporation This software is made available solely pursuant to the terms of a DGC license agreement which governs its use. ♀ DG/RDOS model 30568 Release Notice October 1992 Page ii ♀ DG/RDOS model 30568 Release Notice October 1992 Page iii Table of Contents 1 Introduction . . . . . . . . . . . . . . . . 1 2 Product Description . . . . . . . . . . . . . 1 3 Environment . . . . . . . . . . . . . . . . 2 4 Enhancements and Changes . . . . . . . . . . . . 3 4.1 New Hardware . . . . . . . . . . . . . . 3 4.2 Release Tape Format . . . . . . . . . . . . 3 4.3 TAPEBOOT . . . . . . . . . . . . . . . . 4 4.4 DKINIT and DSKED . . . . . . . . . . . . . 4 4.5 DISKBOOT . . . . . . . . . . . . . . . . 5 4.6 System . . . . . . . . . . . . . . . . 6 4.7 SYSGEN . . . . . . . . . . . . . . . . 8 4.8 CLI . . . . . . . . . . . . . . . . . 9 4.9 ICOPY . . . . . . . . . . . . . . . . . 11 4.10 IMOVE . . . . . . . . . . . . . . . . 12 4.11 LABEL . . . . . . . . . . . . . . . . 13 5 Notes and Warnings . . . . . . . . . . . . . . 14 5.1 Notes . . . . . . . . . . . . . . . . . 14 5.2 Warnings . . . . . . . . . . . . . . . . 20 6 Documentation . . . . . . . . . . . . . . . 22 6.1 Manuals . . . . . . . . . . . . . . . . 22 6.2 Documentation Update Files . . . . . . . . . . 22 7 Software . . . . . . . . . . . . . . . . . 23 7.1 Media . . . . . . . . . . . . . . . . . 23 7.2 Organization . . . . . . . . . . . . . . 23 7.3 Files . . . . . . . . . . . . . . . . . 24 8 Installation Instructions . . . . . . . . . . . 25 8.1 For the New User . . . . . . . . . . . . . 25 8.2 Upgrading from the Previous Revision . . . . . . 26 8.3 Upgrading from RDOS . . . . . . . . . . . . 27 9 Preparing a Software Trouble Report . . . . . . . . 29 ♀ DG/RDOS model 30568 Release Notice October 1992 Page iv ♀ DG/RDOS model 30568 Release Notice October 1992 Page 1 1 Introduction The purpose of this release notice is to provide you with information about revision 3.00 of DG/RDOS that is not available in the DG/RDOS documentation. This product consists of the following parts: Description Part Number DG/RDOS revision 3.00 release notice 085-000345-11 DG/RDOS revision 3.00 release media listed in section 7 of this release notice This printed release notice always accompanies the software. After you have installed the product, you can print additional copies of this notice. Its filename is 085000345.11. This notice is printed in uppercase and lowercase. If you have an uppercase-only printer, use the CONFIG utility to enable lowercase to uppercase translation. 2 Product Description DG/RDOS is a memory-resident, dual-process, multitasking, real-time operating system. It is derived from Data General's popular and proven Real-time Disk Operating System (RDOS). Two versions of DG/RDOS are available. This version, model 30568, runs on DESKTOP GENERATION, DG/500, and S/280 16-bit computers. The other version, model 31285, runs on MV/1000 DC, MV/1400 DC, MV/2000 DC, MV/2500 DC, MV/3000 DC Series, MV/5000 DC Series, MV/7800 XP, MV/9000 Series, MV/15000, and MV/18000 32-bit computers. Except for hardware differences, the two versions of DG/RDOS offer the same capabilities. Nearly any program that runs on one version will run on the other version, with no recompilation or relinking required. Many programs that run on RDOS will also run on DG/RDOS. DG/RDOS provides a set of program development tools as a standard feature, along with backup/file transfer, Command Line Interpreter, and system customization utilities. High-level languages, communications software, and a sort/merge utility are offered by Data General as separate products. Many application packages are available from third parties. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 2 3 Environment To install and run DG/RDOS 3.00, model 30568, you need one of the following: a) a DESKTOP GENERATION model 10 or 10SP computer with 256 KB of memory, either two diskette drives or one diskette drive and a hard disk drive, either a monochrome monitor or a color monitor, and either the DG/RDOS D211 Emulator diskette (model number 30736) or the Bootable D211 Emulator diskette (model number 30745) b) a DESKTOP GENERATION model 20 or 30 computer with 256 KB of memory, a diskette drive, a hard disk drive, and a video display terminal c) a DG/500 computer with 512 KB of memory, a diskette drive, a hard disk drive, a video display terminal, and the DG/500 System Media diskette (model number 31588) d) an S/280 computer with 256 KB of memory, a 1600 BPI reel-to-reel tape drive, a hard disk drive, and a video display terminal When using diskettes, your release media type must match your unit 0's drive type. Do not attempt to perform the installation procedure with 48 TPI diskettes and a 96 TPI drive, or with 96 TPI diskettes and a 48 TPI drive. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 3 4 Enhancements and Changes 4.1 New Hardware 1) We added support for the S/280 processor. However, we have not updated "How to Generate and Run DG/RDOS" for this. We expect an experienced user will be able to determine the proper course of action based on the information about other systems in that manual and the S/280 information in this release notice. RDOS supports several devices and features that DG/RDOS doesn't support. If you don't use any such devices or features, you can switch from RDOS to DG/RDOS. Then you can take advantage of features that DG/RDOS does but RDOS doesn't support, like RAM disk and better backup utilities. DG/RDOS is capable of supporting, on an S/280, any devices it supports on MV/9000 Series and similar systems. However, you shouldn't simply assume you can use all such devices. Some may not work in a 16-bit system. Others may work but aren't supported by the 16-bit diagnostics and thus cannot be maintained effectively. 4.2 Release Tape Format We changed the release tape format in two ways to speed up the installation procedure when using certain tape drives. 1) The operating system .SV file, DKINIT and DISKBOOT (tape files 2, 4 and 5) are now written to tape with the new ICOPY utility and 8 KB records. 2) Most of the files that were formerly present in DUMP format (tape file 1) have been moved to the IMOVE dumpfile (tape file 6). When you boot the operating system from tape and use the Full or Restore option, you now receive an R prompt sooner (MUCH sooner with certain tape drives). However, the Full option now leaves you with a disk that isn't bootable; only CLI and IMOVE are present. If you don't use IMOVE to load all the files from tape file 6, you must at least use it to load DISKBOOT.SV, DGRDOS.SV and DGRDOS.OL before your disk will be bootable. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 4 4.3 TAPEBOOT 1) We made the tape bootstrap able to handle large records (up to 8 KB on MTn devices, 16 KB on UTn devices). XFER format records (514 bytes, 510 of them meaningful) are handled as before. 2) We changed the way the tape bootstrap does I/O to speed up booting from certain UTn devices and to fix some rare problems. 3) We reduced the size of the tape bootstrap from 8 KB to 4 KB. 4) We changed some messages. 4.4 DKINIT and DSKED 1) We reversed the order in which the programs ask the "Disk unit?" and "Disk drive model number?" questions. We made DSKED's ques- tions like DKINIT's -- you can ask for help, and you can enter STOP. 2) DKINIT and DSKED now obtain information about a DAn disk from the disk controller. After you answer the "Disk unit?" question, the programs display the disk's capacity. If you want to use the entire capacity, you can simply enter New Line in response to the "Disk drive model number?" question. However, there are situations in which you'll want to supply a model number -- most notably, if you have BURST backups of a disk that was formatted with an older revision of DKINIT. Versions of the programs supplied with DG/RDOS 2.60, RDOS 7.60, and older revisions looked up the model number you supplied in a table and used less than the full capacity of most DAn disks. The new versions of the programs still do this if you supply a model number. The help messages only list the DAn disks that were supported by DG/RDOS 2.60 and RDOS 7.60. If you have a newer DAn disk, simply enter New Line in response to the "Disk drive model number?" question. 3) DKINIT's FULL command now lets you request 0 patterns on DAn disks. However, we recommend you run at least 1 pattern unless you are absolutely certain your disk contains no bad blocks. 4) DKINIT now runs faster on many DAn disks because it performs larger multi-block transfers. For example, one pattern of FULL on a 500 MB R.A.M.S. disk on an MV/7800 XP used to take 51 minutes. Now it ♀ DG/RDOS model 30568 Release Notice October 1992 Page 5 takes 23 minutes. 5) The programs no longer display or accept block numbers on DAn disks in head, sector, cylinder format. 6) We fixed several problems in the logic that accesses, and that detects and decodes errors from, DAn disks. 7) We fixed problems in the logic that checks whether a multi-block transfer completed successfully. 8) The page mode supported by DKINIT's LIST command now functions properly on DSn disks. 9) Some of DKINIT's Yes/No questions now have defaults displayed in square brackets. Simply enter New Line to request the default. 10) We fixed a problem that occurred if you used New Line to cycle through DSKED's $M, $W, $N, $J, $E and $H registers. 11) Most of the routines that read from the keyboard now discard control characters without echoing them. One effect of this change is that your screen no longer goes out of roll mode when you view a long help message at a high baud rate. 12) We changed and added several help and other messages. 4.5 DISKBOOT 1) We changed the way the disk bootstrap does I/O to speed up booting from certain disks and to fix some rare problems. 2) We improved the logic that checks for disk errors. 3) We fixed a problem that made the bootstrap forget to remap blocks in a disk's bad block table. 4) We fixed problems with files larger than 65,024 bytes on disks smaller than 32 MB. 5) We fixed a problem that occurred when, for example, Y.DR was a link and the bootstrap tried to find X, which was linked to Y:Z. 6) We fixed a problem that occurred when the bootstrap loaded mi- crocode and SYS.MF was linked to a file in a subdirectory or on another disk. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 6 7) We changed the way the bootstrap reads microcode files and loads microcode to avoid problems with certain microcode files and certain CPUs. 8) We added a way to install a bootstrap root of one type on a disk of another type. 9) We fixed problems where the bootstrap would loop reporting certain errors over and over again. 10) We changed some messages. 4.6 System 1) The system now notices when blocks in random files happen to be contiguous on disk, and performs multi-block requests at the device level when programs perform multi-block .RDB, .WRB, .ERDB and .EWRB system calls. We've seen cases where this more than doubles IMOVE performance (and other cases where it hardly helps at all). The same change typically triples the performance of swapping, though few systems do enough swapping for this to affect overall system throughput. 2) The .RDB and .ERDB system calls now support a new read-next-allocated mode. When in this mode, these calls start at your input block number; skip any unallocated blocks; return the next allocated block number; read up to the next unallocated block or until your input block count is exhausted; and return the actual block count read. To enter read-next-allocated mode on a channel opened to a random disk file, use the new .IOCTL system call. See information near the end of DGPARS.SR for details. 3) The .WRB and .EWRB system calls allocate random file blocks one at a time if necessary. Only after successfully allocating all necessary blocks do they attempt to write your data. In recent revisions, these calls updated the file size each time they allocated a block past the previous end of file. In older revisions, they updated the file size before they even tried to allocate any blocks. Now they don't update the file size until they finish allocating blocks. The file size no longer includes blocks these calls allocated but never tried to write if disk space is exhausted during a multi- block write. Deleting the file still reclaims all blocks, inclu- ♀ DG/RDOS model 30568 Release Notice October 1992 Page 7 ding any that were allocated but not accounted for in the file size. 4) The current byte position in a file (set by .SPOS; read by .GPOS; used as the starting position for, and updated by, .RDL, .WRL, .RDS and .WRS) is stored inside the operating system as two values: a block number and a byte position within that block. Block I/O system calls (.RDB, .WRB, .ERDB and .EWRB) don't use that byte position; one of their inputs is a starting block number. However, in past revisions, block I/O calls overwrote the block number portion of the current byte position with their starting block number. If you performed both block I/O and buffered I/O system calls through the same channel, the block I/O calls had side effects on the buffered I/O calls. For example, if you performed .SPOS to byte X of block Y, followed by .RDB of block Z, followed by .RDS, the .RDS started reading at byte X of block Z. You may have expected the block I/O calls NOT to have side effects on the buffered I/O calls -- for the .RDS to start reading at byte X of block Y. That's how it works now. (Still, you shouldn't mix block I/O and buffered I/O calls on the same file, even on different channels. For example, .RDB can read an old copy of a block from disk after .WRS has put a newer copy in an operating system buffer; and .RDS can read an old copy from a buffer after .WRB has put a newer copy on disk.) 5) We fixed several problems involving largest-possible files. Buffered I/O system calls (like .RDS and .WRS) return an End Of File error when they access the last byte of the largest possible random or sequential file, rather than when they try to go beyond that byte. Upon indicating this error, some calls left the file position somewhere within the first block of the file. Now they leave the file position at the beginning of the first block. When using buffered I/O calls (not .MTDIO or .MTDRW), you can only write 65,536 records (of 510 data bytes each) to a single tape file. In the past, you could only read 65,535 records. Now you can read the last one. If 32 MB of data was sent to a device between when spooling started and when the device caught up, the system would behave strangely. Disk space could be allocated and never deallocated short of INIT/F. Now the system waits for the device to catch up with the spooler and then resumes spooling. Attempts to perform block I/O system calls (.RDB, .WRB, .ERDB and ♀ DG/RDOS model 30568 Release Notice October 1992 Page 8 .EWRB) where the starting block number plus the requested block count would exceed a 16-bit value now behave more reasonably in some cases. 6) We made the system return 0, rather than a meaningless value, in AC1 when .MTDIO and .MTDRW reads and writes fail in certain ways on UTn tape drives. 7) .MTDIO and .MTDRW reads still take the good return if the only error indication is End Of Tape -- unless nothing was read. In that case, they now take the error return. 8) We fixed a complex problem that could lead to panics on MV/3000 DC Series, MV/5000 DC Series, and MV/9000 Series systems. [fixed in 2.61 by patch PTMAP.PF] 9) If you typed ^C^E at the background or foreground console, the system could hang or panic. We fixed this problem. [fixed in 2.61 by patch DEBAD.PF] 10) We fixed a problem where the operating system would sometimes pass the wrong value to a task reading from QTY:64. This problem was most visible when programs used the QTY:64 mechanism to support ^C^x sequences or single-byte interrupt characters on QTY lines, and affected both Interactive COBOL and Business BASIC. [fixed in 2.61 by patch QTYINT.PF] 11) We fixed a problem with $ devices linked to ALM or ULM QTY lines. [fixed in 2.61 by patch LINKALMULM.PF] 12) We taught the system how to dismiss undefined interrupts from ALM, ULM, and similar controllers if your answer to SYSGEN's CPU ques- tion is S/280. 13) The operating system now uses 14, rather than 13, pages of memory for its own virtual overlays. The additional page contains code that was formerly resident as well as code that supports new functionality. Compared to the previous revision, you may be able to select more options in CONFIG, but your operating system may use slightly more total memory. 4.7 SYSGEN 1) We added support for the S/280 processor. SYSGEN doesn't list it on the screen, but you can request it. 2) We added a special CPU type that we now use to generate the opera- ting system that comes on the 16-bit release media. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 9 3) We changed some help messages. 4) The revision 3.00 versions of SYSGEN and the operating system libraries are rev-locked. Don't try to mix different revisions of these components. 4.8 CLI 1) CLI now uses more ECLIPSE instructions and the ECLIPSE stack. 2) Previous versions had multiple copies of several internal routines. This was a relic from when CLI had an overlay file. Over the years, fixes had been applied to some but not all copies of some routines. Now most commands call the same copy of an internal routine to perform a common function. This makes CLI smaller and makes commands' behavior more consistent. For example, all commands that accept templates now treat bad templates like -.. the same. 3) The template matching and sort logic used by most commands is only capable of handling simple filenames, not pathnames containing colons. In the past, it would behave strangely if you supplied pathnames. For example, LIST/S X:Y would only display information if a file Y existed in both directory X and the current directory, and the information displayed was for the file in the current directory. Now such logic detects and rejects most cases of pathnames that would not be handled properly. 4) Most commands no longer emit a period at the end of a filename that has no extension unless you explicitly specify one. This can change BUILD's and LIST's output, make dumpfiles slightly smaller, and have other effects. 5) BUILD now accepts a global /S (sort) switch. It also behaves better when given extremely long arguments. 6) DELETE, MOVE and UNLINK now accept global /S and local /L (listfile) switches. 7) LIST now accepts a local /L switch. It's also better at aligning columns, leaving at least one space between columns, and not wrapping lines on 80 character wide screens when files have several attributes, dates in the 21st century, and first addresses beyond 777777. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 10 8) DISK and REV now accept arguments, templates and switches. See the documentation update file for "Using the DG/RDOS Command Line Interpreter" for details. 9) We fixed problems with FILCOM when one file contained an odd number of bytes and was more than 256 bytes longer than the other file, and when you supplied two arguments but one was listfile/L. 10) We fixed problems with FPRINT and starting locations greater than 177777, and with FPRINT/Z. We changed FPRINT's output format so FPRINT/B no longer wraps lines on 80 character wide screens, so FPRINT/D displays the file location (as well as the data) in decimal, and in other ways. 11) CDIR, SPDIS, SPEBL and SPKILL used to quit after reporting an error on one argument. Now they continue with any additional arguments, as CRAND and CREATE do. CRAND and CREATE used to do nothing if you supplied no arguments. Now they complain, as CDIR, SPDIS, SPEBL and SPKILL do. 12) CCONT, CPART and RENAME used to do nothing if you supplied no arguments. Now they complain. LINK used to quit after reporting an error on one pair of arguments. Now it continues with any additional pairs of arguments. EQUIV now accepts multiple pairs of arguments. When an error occurs, these commands now include both arguments in the error message. 13) Some other commands are now better at detecting too few or too many arguments. 14) We improved the logic that scans filenames (and pathnames) and looks for extensions. Examples: The commands X.DR:ICOPY/H and X.DR:ICOPY.SV/H now function correctly. Before, CLI saw the .DR extension, thought that this was a filename with an extension other than .SV, and tried to execute X.DR:ICOPY or X.DR:ICOPY.SV as a macro. The command MAC X.DR:Y now properly creates Y.RB in directory X.DR. Before, CLI saw the .DR extension and replaced it with .RB, so MAC created X.RB in the current directory. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 11 4.9 ICOPY 1) This revision introduces a new utility, ICOPY. Its documentation consists solely of this section and the on-line help message (ICOPY/H). We haven't written an ICOPY chapter for "How to Gen- erate and Run DG/RDOS", nor have we updated the "Backing Up and Moving Files" chapter of that manual. ICOPY is a multi-task program that copies one file to another. Its input file can be a disk file, a diskette, a tape file, or an MCA line. Its output file can be a disk file, a diskette, a tape file, an MCA line, a $ device, or a QTY line. It has many advantages over MOVE, XFER and FCOPY, though it has disadvantages as well. 2) When working with disk files, ICOPY is often faster than any other method. Unlike MOVE and XFER, ICOPY performs multi-block reads and writes. This is particularly helpful with contiguous files, and can also help random files due to enhancements to the .RDB and .WRB system calls. Unlike those commands and FCOPY, ICOPY has one task reading from the input file at the same time another task is writing to the output file. This usually helps, unless you're copying a disk file to a far-away place on the same disk. In that case, FCOPY may be faster. Like MOVE, ICOPY doesn't write null-filled blocks to random files, leaving them unallocated, which saves time and disk space but may lead to future disk fragmentation. Like MOVE and FCOPY, ICOPY preserves a disk file's date and time last modified, date last accessed, and attributes (except the A attribute). But, like XFER and FCOPY, a single ICOPY command only copies one file, and ICOPY doesn't accept templates. (You can BUILD filelist and then ICOPY dir2:(@filelist@) dir1:(@filelist@).) Like XFER, ICOPY can convert random files to contiguous files and vice versa with switches on the output filename. 3) ICOPY can't copy a diskette directly to another diskette using only one diskette drive, as FCOPY can, but it has two primary advantages over FCOPY when working with diskettes. ICOPY is often much faster than FCOPY when copying one diskette to another using two diskette drives. The fastest way to make multiple copies of a diskette is often to ♀ DG/RDOS model 30568 Release Notice October 1992 Page 12 use ICOPY to copy the source diskette to a disk file, and then to copy that disk file to each destination diskette in turn. 4) We use ICOPY to place DGRDOS.SV, DKINIT.SV and DISKBOOT.SV on the DG/RDOS release tape using 8 KB records; many tape drives can boot the larger record size faster than XFER format. You can use it to copy a tape directly from one drive to another, one tape file at a time; or to copy tape files to disk files and vice versa. 5) You can use character conversion files to encrypt sensitive data, translate between lowercase and uppercase or ASCII and EBCDIC, and for other purposes. In a character conversion file, byte 0 con- tains the value null will be converted to, byte 101 (octal) con- tains the value A will be converted to, byte 172 contains the value z will be converted to, and so on. 6) With most output devices, you can use ICOPY like PRINT, TYPE or XFER/A. The global /C switch functions like a character conversion file that translates Carriage Return to New Line and New Line to Carriage Return. You can use local /C/F switches to, say, convert Form Feeds to New Lines. 7) See the on-line help message for ICOPY's command line format and details about these and other features and switches. 4.10 IMOVE 1) Performance when dumping sparse random files may be significantly better than in the past because IMOVE now uses .RDB's new read-next-allocated mode. Before, when the operating system encountered unallocated blocks, it null filled IMOVE's memory; then IMOVE found the null-filled areas and left them out of the dumpfile. Now, IMOVE never sees unallocated blocks at all; the operating system tells IMOVE the block number of the next allocated block and starts reading there. IMOVE still looks for null-filled areas in memory to leave allocated, null-filled blocks out of the dumpfile. 2) Performance when dumping and loading random files may be signifi- cantly better than in the past because the .RDB and .WRB system calls now do multi-block transfers at the device level when IMOVE requests multi-block transfers at the system call level and the random file blocks happen to be contiguous on disk. 3) IMOVE now deletes (F)COM.CM before, rather than after, a load with no filenames specified on the command line, as a small contribution toward discouraging disk fragmentation. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 13 4) When an error occurs while IMOVE is reading from disk during a dump, it now reports the error and asks whether to skip the rest of that disk file and move on to the next one. Before, it simply terminated. Depending on the type of output device, you may or may not have been able to load the files that were dumped before the error occurred. Now (if you press New Line and let the dump run to completion) you should be able to load the entire dump. However, any file that encountered a read error will appear to be null filled from where the error occurred to the end of the file. A load operation can't tell you whether any such files are present; your only indication is the error during the dump operation. THIS IS NOT THE PROPER WAY TO HANDLE NEW BAD BLOCKS ON A DISK. The proper procedures are documented in Appendix B of the "How to Generate and Run DG/RDOS" manual. This is only a tool that may help you save some of your data in a catastrophic situation -- for example, if your disk develops more bad blocks than a bad block table can hold. 5) We fixed a problem that made multi-volume loads from some MTn tape drives fail with errors like "Invalid dump block format" near the beginning of the second tape. [fixed in 2.61 by patch IMOVE.PF] 6) We added a new global /S switch, which you can use to dump and load over an MCA. Don't use this switch with tapes, diskettes, or disk files. 7) IMOVE now supports tape records (buffer-size/S with global /T) of any even number of bytes from 4 to 16384. If you don't use the global /T switch, your buffer-size/S can now be any multiple of 512 from 1024 to 16384. In the past, buffer-size/S had to be a mul- tiple of 2048. 8) We changed the help message. 4.11 LABEL 1) We fixed a problem that sometimes occurred when trying to display labels from an unlabeled diskette. 2) When displaying, LABEL now replaces non-printable characters with spaces. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 14 5 Notes and Warnings 5.1 Notes 1) You can patch the operating system to have it execute a macro called UP.MC at the completion of operating system initialization. UP.MC must exist in the master directory. It can be a link to another file, but any chain of links must be resolved solely within the master directory. If the following patch is installed, the operating system initial- ization code will create a CLI.CM file containing the command UP.MC, and will bring up the CLI using the .EXEC system call with AC2 set to error code EREXQ in order to ask the CLI to execute CLI.CM as a macro. The EREXQ flag is passed in AC2 to the first program that the operating system initialization code chains to. When LOADEM and LDIAC are finished, they pass the flag on to the CLI. If you have a RESTART.SV that chains to the CLI and if you want to take advan- tage of this patch to the operating system, your RESTART.SV must remember the value of AC2 when it starts, and it must pass that value on to the CLI. The patch to the operating system .SV file is as follows: S SYSUP SYSUP@0 17 SYSUP 2) Abbreviations and screenedit are now on by default when the CLI starts. If you have macros or programs whose names are abbreviated CLI commands, change them. In macros that call other macros, specify the .MC extension. In macros that call programs, use the XEQ command and specify the .SV extension. If you have too many conflicting macros or programs, or if you have a hardcopy console, you can patch CLI.SV such that abbreviations, screenedit, or both will be off. (Or you can use an UP macro to turn them on or off.) Patch to disable abbreviations: S 50-16 50-16@0 0 Patch to disable screenedit: S 51-16 51-16@0 0 ♀ DG/RDOS model 30568 Release Notice October 1992 Page 15 You can also patch the CLI's prompt. Location 52 (if SEDIT; 52-16 if SEDIT/Z or PATCH) contains a byte pointer to the prompt string. Your prompt can be up to 20 bytes long. If you will ever run with screenedit off, your prompt should end with a carriage return followed by a null. If you will always have screenedit on, you can place the prompt and the command on the same line on the screen by patching your prompt to end with a null but no carriage return. 3) INIT/F/N/Q performs INIT/F without asking the "Confirm?" question. This is not documented in "Using the DG/RDOS Command Line Interpreter" or its documentation update file. Use it with extreme care. Don't embed it in macros. 4) When using CONFIG to rename $ devices or to link them to QTY lines, it is your responsibility to make sure no two devices have the same name or are linked to the same QTY line. 5) In revisions before 2.60, the $ device input interrupt service routine swapped Carriage Return and New Line. Now, this is done only by .RDL in high-level code. This change may affect any software that uses .RDS or .GCHAR. For example, this change makes Carriage Return and New Line function as they did several years ago in SEDIT and the interrupt-enabled debugger -- as they always have in DSKED and the interrupt-disabled debugger. 6) In revisions before 2.60, if you entered ^C^A while output was suspended by ^S, the interrupt sequence would undo the ^S. Now, you must type ^Q yourself. This fixes some sporadic problems with certain terminals. 7) On QTY lines, if you enable interrupt characters, you should also enable ^S/^Q. If you disable ^S/^Q, interrupt characters will be disabled even if you request that they be enabled. 8) Support for ^C^x interrupt sequences on QTY lines was introduced in DG/RDOS 2.00. The old functionality (two single-byte interrupt characters) may still be requested via SYSGEN. In the future, only ^C^x sequences will be supported. You should enhance any programs that depend on the old functionality. 9) The switch from single-byte moves and ring buffers to multi-byte moves and line buffers, first seen in revision 2.60, makes spooling behave differently. Spooling is likely to start sooner. Charac- ters are spooled much more quickly. You'll probably prefer the way spooling to printers behaves now. However, you may want to disable spooling to other devices, like the background and foreground consoles. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 16 10) IMOVE equates a contiguous file on the DG/RDOS side with 0 maximum index levels on the AOS/VS side, regardless of the current number of index levels. An AOS/VS file with 3 maximum index levels will be loaded as random even if its current size and its element size are such that it has 0 current index levels. With contiguous files, the file size on the DG/RDOS side corres- ponds to the element size on the AOS/VS side, regardless of the current size. An AOS/VS file with 0 maximum index levels will be loaded as a contiguous file with a size based on the AOS/VS element size, even if its current size under AOS/VS is less than this. 11) IMOVE maps a file to an AOS/VS Business BASIC file type if it has the following file and link attributes (it may have other attribu- tes as well): File attributes Link attributes AOS/VS file type S and W BBS &, not S P and W VLF not S or & P DBF Before update 2.61, IMOVE only did this for random files. Business BASIC users may no longer need to process their files (with FIXFILE or DBFIX) before they can be used on AOS/VS. Other users may find that their files receive unexpected AOS/VS file types. 12) IMOVE's unlabeled diskette format (global /U without /T) can be used to dump to and load from disk files. One instance where this can be useful is an UP macro that loads files onto RAM disk. 13) If IMOVE or ICOPY can't keep your tape moving for more than a few seconds at a time no matter what buffer size you use or how much memory is available in your ground, try perhaps 50/P/O when writing to tape or 75/P/I when reading from tape. It should reduce wear on your tape and your tape drive, though it may not make the program finish sooner. 14) If your computer has a boot clock or clock/calendar, you must use the power-up menus to set its date and time. System calls and CLI commands only affect the operating system's internal date and time. Note that some MV/Family systems only enter the power-up menus if, on an earlier occasion, you entered the SCP-CLI command FLAGS AUTO YES. 15) RDOS and DG/RDOS use different naming conventions for disk(ette) drives. In RDOS (and in old revisions of DG/RDOS), unit numbers 0 through 3 are reserved for the first controller, and unit numbers 4 through 7 are reserved for the second controller. In DG/RDOS, the first controller is assigned unit numbers from 0 through 7; the ♀ DG/RDOS model 30568 Release Notice October 1992 Page 17 second controller, 10 through 17; the third, 20 through 27; and so on. If you are upgrading from a revision of DG/RDOS older than 2.30, there is only one device whose name has changed: the diskette drive on MV/1400 DC and MV/2000 DC systems. Its name was DA4; now, it is DA10. If you are upgrading from RDOS to DG/RDOS, there are several devices whose names have changed: any disk(ette) drive on a secon- dary controller. What was DA4 is now DA10; DA5 becomes DA11; DA6 becomes DA12; DA7 becomes DA13. Similarly, DJ4 - DJ7 become DJ10 - DJ13, and DZ4 - DZ7 become DZ10 - DZ13. You must supply the new device names to programs like DKINIT, DSKED, DISKBOOT, BURST and IMOVE. You should change any links, macros and programs to use the new device names. As a temporary measure, you may be able to take advantage of the CLI's EQUIV command or the .EQIV system call. 16) DG/RDOS and RDOS use the same basic disk format. If you convert a 16-bit RDOS machine into an MV/7800 XP or MV/9000 Series system running DG/RDOS, if you upgrade an S/280 from RDOS to DG/RDOS, or if you move RDOS disks to DG/RDOS systems, you do not need to run DKINIT on your disks. However, there are two ways that RDOS uses disks but DG/RDOS does not. DG/RDOS maintains information about certain devices ($TTI, $TTO, $LPT, etc.) in memory. RDOS creates SYS.DR entries for such devices in every initialized directory. If you INIT/F a disk while running DG/RDOS and never use that disk again while running RDOS, you can save the disk space that would be consumed by those SYS.DR entries, and you can avoid any confusion that might be caused by the presence of those SYS.DR entries. When you INIT/F a disk, RDOS creates a BOOTSYS.OL on that disk. The procedures used to boot RDOS from tape or over an MCA assume that BOOTSYS.OL is present, is of the proper size, and is in the proper location on the disk. DG/RDOS has no such special requirements. If you INIT/F a disk while running DG/RDOS and never use that disk again while running RDOS, you can save the disk space that would be consumed by BOOTSYS.OL. 17) If you upgrade a disk from RDOS to DG/RDOS, you should delete the files that are a part of RDOS itself. Such files are either replaced by files on the DG/RDOS release media, or are not sup- ported on DG/RDOS. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 18 18) The interface between the operating system, the disk bootstrap root, and DISKBOOT.SV has changed from time to time over the years. If you have any trouble booting, make sure you're using the same revision DISKBOOT.SV and operating system, and re-install a boot- strap root using that revision of DISKBOOT. 19) Certain DZn and MTn controllers may be on either the Data Channel or the Burst Multiplexor Channel. DG/RDOS determines whether DZn and MTn devices are on the DCH or the BMC at runtime and supports either access method. Some controllers have jumpers that must be set properly. 20) If an operating system with an overlay file is to be booted from a UTn tape, the .SV file must be present as tape file 2 and the .OL file must be tape file 3. 21) Operating system .SV files and stand-alone programs like DKINIT and DISKBOOT can be copied to tape with ICOPY and large records, but operating system .OL files must still use XFER format in order to be booted from tape. 22) The 22 MB cartridge tape drive gives the optimal combination of performance and capacity using 16 KB records and a multitask program (like BURST or IMOVE). This drive does not support read after write, so verifying a dump is even more important than with other drives. 23) We also recommend 16 KB records and multitask programs with the 130 MB, 150 MB, 150/320/525 MB, and 2 GB cartridge tape drives. These drives do support read after write; however, in order to maximize performance, DG/RDOS uses the drive's buffered mode, which means that errors on a write are not reported until the next operation is attempted. 24) DG/RDOS also uses the buffered mode offered by model 6586/6587 and 6588/6589 reel-to-reel tape drives. 25) By default, data compression is enabled on the model 6762 (2+ GB) cartridge tape drive. 26) This note applies to you if you have a 22 MB cartridge tape drive on a SCSI bus. This note does not apply to you if you have a 22 MB cartridge tape drive in the main chassis of a DG/500, MV/1000 DC, MV/1400 DC, MV/2000 DC, or MV/2500 DC system. Revisions of BURST and IMOVE before 2.60 included some logic that worked around a problem with old revisions of the SCSI version of the 22 MB cartridge tape drive. In order to support the 2 GB cartridge tape drive, we had to remove that logic. If you have an ♀ DG/RDOS model 30568 Release Notice October 1992 Page 19 old SCSI 22 MB cartridge tape drive, multi-volume load or verify operations using the current version of BURST or IMOVE may fail at the end of the first tape. If this happens to you, have ECO 28742 (or at least ECO 27715) applied to your 22 MB cartridge tape drive's SCSI controller card. 27) When writing to a 150, 320, or 525 MB cartridge tape, start either at the beginning of file 0 or beyond the end of all existing files. Attempts to do otherwise will either be rejected by I/O firmware or result in reduced capacity. 28) DG/RDOS device names for STn tape drives are assigned based on the SCSI IDs of the tape drives. SCSI ID 6 is device name ST0 (or ST10 on a second controller), SCSI ID 5 is ST1 (or ST11), SCSI ID 0 is ST6 (or ST16). You should set the switches on the model 5086 controller in the DG/500 chassis to select SCSI ID 7. 29) The 22 MB cartridge tape drives on various systems are all compatible, unless you have an MV/2000 DC with System Media older than revision 2.00. 30) 48 TPI diskettes written to by 48 TPI drives can be read by 96 TPI drives if IMOVE is used. However, you should not INIT, DIR onto, or write to a 48 TPI diskette in a 96 TPI drive, and you cannot use a 96 TPI diskette in a 48 TPI drive in any manner. 31) Many programs that run on RDOS will also run on DG/RDOS. The following are common reasons why some RDOS programs will not run on DG/RDOS. a) Multitask programs must be linked with the version of SYS.LB supplied with DG/RDOS, or with Mapped ECLIPSE versions of RDOS -- not with the versions of SYS.LB supplied with other ver- sions of RDOS. b) Arithmetic/logic class (ALC) instructions with both the no-load and either the never- or always-skip options behave differently on different CPUs. c) Auto increment/decrement of certain low memory locations is a function of the CPU, and is not supported by the CPUs on which DG/RDOS runs. d) Multiply/divide and floating point instructions are different on some CPUs. e) Programs that include .IDEF device drivers may only work when those devices are present. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 20 32) DG/RDOS shares several utilities (DO, ENPAT, LFE, MAC, MACXR, OVLDR, PATCH, RLDR, SEDIT, SPEED) with RDOS. The versions of such utilities supplied with this revision of DG/RDOS are the same as those supplied with RDOS 7.60. 5.2 Warnings 1) If you will release the master directory, do not boot from a subpartition. If you boot from a subpartition, do not release the master directory. There are known problems in this area. For example, if the master directory is initialized but its parent disk is not, an attempt to release the parent disk will do nothing; programs like BURST have no way of knowing that the disk is ac- tually in use. BURST and FCOPY will release the disks on which they are run. If you will run one of these programs on your system disk, do not boot from a subpartition. Also note that, when you run one of these programs on your system disk, you must CHAIN to the program, no foreground can be running, and the system will ask you to "Insert system disk; strike any key to continue" when the program terminates. 2) During the execution of certain commands, the CLI creates and opens temporary files. Most of these files are placed in the directory in which the CLI was executed (the "CLI directory," normally the same as the master directory). If you will release your CLI directory, you should CHAIN to the CLI in an initialized directory if at all possible. When recovering from an abnormal shutdown and using the CLEAR command, do not attempt to CLEAR or DELETE files in your CLI directory with names CLI.xn, where x is C, S, or T and n is a number from 0 through 5. The CLI takes care of these files itself, and may actually be using them during your recovery procedure. 3) A copy of CLI.SV should always exist in the master directory. If you redefine your master directory, move a copy of CLI to the new master directory and CHAIN to it there. 4) If your program rewinds a tape and then performs other operations on that tape, it must first wait for the rewind to finish. Our recommended way to accomplish this is to let the system perform the rewind by closing your channel and re-opening tape file 0. Another way is to issue a .MTDIO Rewind command and then watch the value returned by the .MTDIO Get Status command until the Rewinding bit clears and the Ready bit sets. The system no longer protects you ♀ DG/RDOS model 30568 Release Notice October 1992 Page 21 from failures that can occur if your program does not implement such logic. 5) Attempts to use more than 9 data channel map slots for a single .IDEFed device may not function properly. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 22 6 Documentation 6.1 Manuals Part Number Name 069-400011-00 Introduction to RDOS * 069-400017-01 RDOS/DOS Superedit Text Editor * 069-400019-01 RDOS/DOS Assembly Language and Program Utilities * 069-400020-01 RDOS/DOS Debugging Utilities 093-000470-03 How to Generate and Run DG/RDOS 093-000471-00 Using the DG/RDOS Command Line Interpreter * 093-400027-01 RDOS System Reference * This manual is identical in content to its predecessor (part number xxx-xxxxxx-00). Only the cover has changed. 6.2 Documentation Update Files There are several separate documentation update files on the release media, each file containing the changes to be made to one of the manuals in the DG/RDOS documentation set. These documentation update files are present on the release media in the IMOVE dump file and are loaded onto your system disk during the installation procedure. The filenames correspond to the part numbers of the affected manuals. For example, the file 093400027.01 contains the changes to be made to the "RDOS System Reference" manual. After installing your software, print the documentation update files listed below and follow the instructions on the first page of each file. The documentation is incomplete without its documentation update files. Filename For manual 069400019.01 RDOS/DOS Assembly Language and Program Utilities + 069400020.01 RDOS/DOS Debugging Utilities + 093000470.03 How to Generate and Run DG/RDOS + 093000471.00 Using the DG/RDOS Command Line Interpreter + 093400027.01 RDOS System Reference + This documentation update file has been revised since the last revision of this product. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 23 7 Software 7.1 Media Model Part Number Description 30568 T 082-000300-10 48 TPI 5-1/4" diskettes 082-000301-10 2 of 4 082-000302-10 3 of 4 082-000364-10 4 of 4 30568 G 081-600293-04 96 TPI 5-1/4" diskettes 081-600294-04 2 of 3 081-600295-04 3 of 3 30568 H 071-600227-01 1600 BPI reel-to-reel tape 7.2 Organization 30568 T -- 48 TPI 5-1/4" diskette media organization Part Number Format Contents 082-000300-10 MOVE CLI.SV, IMOVE.SV, DISKBOOT.SV, DKINIT.SV, SYS.SV, LOADEM.SV, DGRDOS., BYE.MC 082-000301-10 IMOVE Labeled dump of remaining operating 082-000302-10 system files 082-000364-10 30568 G -- 96 TPI 5-1/4" diskette media organization Part Number Format Contents 081-600293-04 MOVE CLI.SV, IMOVE.SV, DISKBOOT.SV, DKINIT.SV, SYS.SV, LOADEM.SV, DGRDOS., BYE.MC 081-600294-04 IMOVE Labeled dump of remaining operating 081-600295-04 system files ♀ DG/RDOS model 30568 Release Notice October 1992 Page 24 30568 H -- 1600 BPI reel-to-reel tape medium organization File Format Contents 0 TAPEBOOT Tape bootstrap 1 DUMP CLI.SV, IMOVE.SV 2 ICOPY DGRDOS.SV, 8 KB records 3 XFER DGRDOS.OL 4 ICOPY DKINIT.SV, 8 KB records 5 ICOPY DISKBOOT.SV, 8 KB records 6 IMOVE Unlabeled dump of remaining opera- ting system files, 8 KB records 7.3 Files The text file DGRDOS0300.FL lists the files that appear on your disk after you have completed the installation procedure. This file is present on the release media in the IMOVE dump file and is loaded onto your system disk during the installation procedure. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 25 8 Installation Instructions The procedure you should use to install DG/RDOS 3.00 is briefly summar- ized here. Refer to the "How to Generate and Run DG/RDOS" manual for a detailed explanation of the installation procedure. (The procedure you should use to install from tape on an S/280 system is not in the manual. Follow the instructions for MV/9500 systems; disregard information about power-up menus, SCP System Media, and microcode; and substitute virtual console commands like !22H or !I for SCP-CLI commands like BOOT 22 or RESET.) After installing the files from the DG/RDOS release media, use the SYSGEN and CONFIG programs to create a DG/RDOS 3.00 operating system customized to your hardware configuration. 8.1 For the New User If you are installing DG/RDOS for the first time, you must perform the following steps. 1) If yours is a DG/500 computer, boot your System Media. Use its menus to set the date and time and configure your parallel printer. If yours is a DESKTOP GENERATION model 10 or 10SP computer and you do not have the DG/RDOS D211 Emulator, boot the Bootable D211 Emulator diskette. 2) Boot the first DG/RDOS release diskette or the DG/RDOS release tape; DKINIT your system disk. If yours is a DG/500 computer, allocate a coresident diagnostic area at least 720 blocks in size. 3) Reboot the DG/RDOS release media; use DISKBOOT to install a boot- strap root on your system disk. 4) Boot an operating system from the DG/RDOS release media. When using DG/RDOS release diskettes, answer N if LOADEM asks "Do you want to load the emulator?" Then INIT/F the system disk, move all files from the first release diskette to the system disk, and reboot the operating system from the system disk, using commands like INIT/F DE0 MOVE/V DE0 BOOT DE0:SYS Now, if yours is a DESKTOP GENERATION model 10 or 10SP computer and you have the DG/RDOS D211 Emulator, answer Y if LOADEM asks "Do you want to load the emulator?" When using a DG/RDOS release tape, choose option F (full initialization), which will automatically INIT/F the system disk ♀ DG/RDOS model 30568 Release Notice October 1992 Page 26 and load the contents of tape file 1. 5) Use IMOVE to load the remaining operating system files from the rest of the DG/RDOS release diskettes, or from file 6 of the DG/RDOS release tape, using a command like IMOVE/A/F/V DJ0 or IMOVE/F/T/V MT0:6 6) If yours is a DG/500 computer, reboot your System Media. Use its menus to install the power-up diagnostics on your system disk. 8.2 Upgrading from the Previous Revision If you are installing DG/RDOS 3.00 onto a disk that contains DG/RDOS 2.61, you need to replace the files on your disk with the files on the release media. If your disk contains a revision of DG/RDOS older than 2.60, you also need to install a new bootstrap root on your disk. If you have release diskettes: 1) Boot the first DG/RDOS release diskette; use DISKBOOT to install a new bootstrap root on your system disk. 2) Boot the revision 3.00 operating system on the first release diskette. Use a MOVE command to transfer the files from the first release diskette to your system disk. 3) Boot the revision 3.00 operating system you just moved to the system disk. Use the revision 3.00 version of the IMOVE program (which you just moved to the system disk) to load the files from the remaining diskettes. If you have a release tape: 1) Boot the DG/RDOS release tape; use DISKBOOT to install a new bootstrap root on your system disk. 2) Boot the revision 3.00 operating system on the release tape. Choose option R (Restore), which will automatically load the contents of tape file 1 onto your system disk, replacing any existing files with the same names, while preserving all other files. 3) Use the revision 3.00 version of the IMOVE program (which was just loaded onto the system disk) to load the files from tape file 6. Be careful if you use the /R switch on MOVE or IMOVE, the /O switch on IMOVE, or the Restore option. The /R switch will not transfer a file if ♀ DG/RDOS model 30568 Release Notice October 1992 Page 27 there is an existing file of the same name that has been modified more recently than the version on the release media. For example, the new operating system .SV file will not be transferred if you have run CONFIG on your old operating system recently. Note that some utilities are rev-locked with the operating system. Also note that there are some new files on the release media. If you have files with the same names, rename your files before performing the installation. If you install DG/RDOS 3.00 onto a disk that contains a revision of DG/RDOS older than 2.30, you can delete the old disk bootstrap utility, MBOOT.SV. 8.3 Upgrading from RDOS If you are installing DG/RDOS 3.00 onto a disk that contains RDOS 7.60, you need to replace the files on your disk with the files on the release media, and you need to install a new bootstrap root on your disk. You should consider performing the steps described in the "For the New User" section of this release notice for reasons that are described in the "Notes and Warnings" section of this release notice. If those reasons do not apply to your situation, you can use the following procedure. If those reasons do apply, but you would find it difficult to back up your files under RDOS and restore them under DG/RDOS (perhaps you don't have a backup program that will run on both systems, and you have more files than can conveniently be handled by CLI DUMP), you can perform part of the following procedure, make a backup using IMOVE, and then join the "For the New User" procedure. 1) Boot an operating system from the DG/RDOS release tape. Choose option R (Restore), which will automatically load the contents of tape file 1, replacing any existing files with the same names. 2) Use the revision 3.00 version of the IMOVE program (which was just loaded onto the system disk) to load DISKBOOT.SV, DGRDOS.SV and DGRDOS.OL (or all the files) from tape file 6. 3) Boot the new disk bootstrap utility, DISKBOOT, which you just loaded onto the system disk. Install a bootstrap root on the system disk. 4) Boot the revision 3.00 starter system, DGRDOS, which you just loaded onto the system disk. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 28 5) Delete the old disk bootstrap utilities (BOOT.SV, ABOOT.SV, EBOOT.SV and MBOOT.SV). Take this opportunity to delete the other RDOS files as well, for reasons described in the "Notes and Warnings" section of this release notice -- but don't delete the files that were loaded from tape file 1 (those files are listed in the "Software" section of this release notice) or the files you loaded with IMOVE. At this point, you could use IMOVE to back up your files, and to verify your backup; then you could join the "For the New User" procedure at the point where you boot either DKINIT or the opera- ting system from tape. 6) Use IMOVE to load the files from tape file 6, if you haven't already done so. ♀ DG/RDOS model 30568 Release Notice October 1992 Page 29 9 Preparing a Software Trouble Report Gathering STR Information If you find an error in DG/RDOS, its utilities, or its documentation, or if you have suggestions to make about the product, please fill out and return a Data General Software Trouble Report (STR). (If your contract permits, you may report the information called for in this section to your Data General representative.) To help expedite STR processing, include only one problem or suggestion on each STR form. Please follow these guidelines when filling out your Software Trouble Report. 1) List the name of the product as DG/RDOS on the STR. Calling the product RDOS or CLI or SYSGEN may lead to misfiled or delayed STRs. 2) Decide what kind of STR you are writing: Enhancement -- describe the proposed enhancement clearly and tell why you want it. The better we understand what you want, the easier it is for us to evaluate your request. Documentation error -- give the page and section or paragraph, and tell why you think there is an error. Software problem -- clearly and specifically state the problem so that support personnel can try to reproduce it. Avoid phrases like "the program does not work" or "fails." 3) On the STR form provide all of the following information: o Date o Revision of the product o Revision of the microcode o Names and revisions of other software this product uses o The CPU type o Terminal and printer types, if relevant o The command line, complete instruction, or program name that caused the problem o How often the problem occurs and how serious it is o The action(s) necessary to reproduce the problem 4) You can shorten the time it takes to solve the problem by isolating the problem to the best of your ability. 5) If the problem occurred soon after you installed a new revision of the operating system, other software, or new hardware, note this. 6) If you received an error message, please write down the text (and number, if there was one) of the message. Also, record when you ♀ DG/RDOS model 30568 Release Notice October 1992 Page 30 received the message (for example, during compiling, linking, executing, etc.). 7) For problems with devices such as terminals or printers, send the device characteristics and the hardware settings. Sending Media If we cannot reproduce a problem because you did not send the necessary software (program module, break file, macro, or other crucial file), we will not be able to answer the STR quickly. Sometimes we have to close the STR with the answer "not reproducible" or "insufficient information." To avoid this, please 1) Include the smallest possible application that demonstrates the problem. This can be a shortened version of the original application. Make sure you send any necessary macros, executable programs, overlay files, or other files needed to reproduce the problem. If you send example applications, make sure they are runnable programs, not listing files. 2) Include a text file on the medium describing the application sent, calling hierarchy (if one exists), and what you've done to track down the problem. You can send hard copy, but a text file is preferable. 3) Clearly label the medium, giving the format, contents, density, buffer size, and date. Verify that the medium is readable. Unless you have a reason to do otherwise, use IMOVE format diskettes or tapes, or directory format diskettes. --End of DG/RDOS model 30568 Release Notice--