Help with running RT-11 SAV files under RSTS/E

problems, in addition to the lack of the 4 digit year when DEC added support for the years after 1999: (a) The DEC version of the MACRO / CREF pair can ONLY be located on the SY: device since the .Chain EMT request is hard coded to transfer control back and forth to each other using only files on the device SY:. No other utility program has that restriction. Note that this problem exists on all three operating systems: RSTS/E, TSX-PLUS and RT-11. (b) Under RT-11, when running under a mapped operating system, if VBGEXE is used under a background job to explicitly load and initiate MACRO.SAV, then any subsequent CSI requests to continue with the assembly of additional files will NOT continue under VBGEXE which will frequently result in insufficient memory for MACRO.SAV to execute. If you are not familiar with the RT-11 utility VBGEXE.SAV, it is used under a mapped monitor to load into extended memory (64K in size) and execute a program which can make use the larger memory available. (c) Under RT-11, when running MACRO.SAV as a system job, VBGEXE is required to load into extended memory (64K in size) and initiate MACRO.SAV; however, if a cross-reference table is requested, the .Chain EMT will cause the job to abort with the complete loss of the listing file. As it happens, according to the PDF that you suggested that I look at, the .SaveStatus EMT request under RSTS/E returns the device name of the file in question - as opposed to the RT-11 values which are totally different. However, since there is no specific mention of the .CStatus EMT request in the PDF as to what happens if used under RSTS/E (the most probable result is that the .CStatus EMT request will be ignored under RSTS/E), then program control will be used to solve if RSTS/E is being used vs RT-11 when MACRO.SAV is found to be executing under an unmapped monitor. This is because the third word of the data block returned by RSTS/E for the .SaveStatus EMT request will be 6544 decimal (RAD50 "RO" = 12620 octal = 4096+2048+384+16) which is very different of MACRO.SAV (about 100 blocks) which is the value found in the third word under RT-11,. I found this information in the PDF on pages 6-10 and 7-57. There is also a final question about the information in the PDF on page 6-16 which states that bit 5 of offset 300 will always be zero. Are there no RSTS/E systems running where the power is 50 Hz rather than 60 Hz? Unless this omission has been corrected, but the documentation has not been updated? Otherwise, the TIME printed on the listing from MACRO.SAV will be incorrect if run under a 50 Hz system. Likewise for other programs which check bit 5 in offset 300 (the .GVal EMT request) and attempt to convert ticks to the time. If you don't use RT-11 very much, then you probably have not noticed problems (b) and (c). In addition, if you have only the DEC versions MACRO / CREF, then it is very unlikely that you will ever want to have available more than one version on a different device from SY:, but I find the restriction sort of silly if there is a simple solution to the problem. It seems that DEC almost always provided code which left out additional bells and whistles that were easy to add. But, then as a profit making company (maybe that is a more fundamental question), only the bells and whistles that were popular were added. For example, RSTS/E fully supports READ-ONLY files. By V05.06 of RT-11, this feature was also supported, but DEC never bothered to update DIR and PIP to reflect that aspect. I have tested RT-11 support for READ-ONLY files by using SIPP to set and clear the correct bit in the file header in the directory segment just to test my assumption. Works GREAT!!! But, DIR does not provide that status and PIP can't change the bit setting. Jerome Fine