You are correct. The problem is when VBGEXE.SAV is used under a mapped RT-11 monitor (RT11XM) to load and initiate MACRO.SAV, especially for a system job. If RSTS/E looks like an SJ environment, then it should provide that information to an RT-11 request to determine if a mapped monitor is being used. That will be PERFECT since the problems can occur ONLY with a mapped RT-11 monitor. Can anyone verify that the CONFG2 (location 300 offset) word will show an unmapped monitor? This is extremely easy to verify. Assuming that an RT-11 distribution is available, an attempt to: SW RT11 RUN VBGEXE.SAV under RSTS/E will generate the error message that a mapped monitor is required as the very first bit of code that is executed if RSTS/E looks like a SJ monitor as far as any RT-11 program is concerned. VBGEXE.SAV is available with all RT-11 distributions starting with V05.01 of RT-11. Probably the best distribution to use is V05.03 of RT-11 which is available at: http://www.classiccmp.org/PDP-11/RT-11/dists/ There will still be the problem of extracting VBGEXE.SAV and placing the file into the RSTS/E environment. But anyone running RSTS/E under an emulator should have very little difficulty in that regard. If you run into any problems, I can probably help. Thank you again. I lost track of this file which you told me about almost a year ago. I hope that the file will provide the information. Jerome Fine

Looks like it is a close as it could be under RSTS/E. Very Good THANK YOU AGAIN!!!! This is exactly what I required. The information in this manual confirms that the .GVal EMT request for location 300 (it is actually CONFG1) will state that an unmapped monitor is running. The only other question is how to determine the device name of the program which is running. Under RT-11, the .CStatus EMT returns the physical device name of the program file which is open on channel 17 since it is overlaid. The manual states that .DStatus EMT is available, but ignores the .CStatus EMT, except by default which leads me to interrupt that such information is not available under RSTS/E. Is anyone familiar with the RSTS/E RT-11 run time system? Was .CStatus ever added for support. The possible solution is to default to assuming the program is on the system device, SY:, which is already known to work. I can place a -1 in the .CStatus area before the EMT request and if that value is still there, use SY: for the device name. Disappointing, but not much of any other option I can think of. Can anyone else suggest something I have missed? Jerome Fine

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

Hi John, I am confused by some of your response to (b) and (c). Are you suggesting that because there are problems which occur in RT-11, but not in RSTS/E, the problems which occur in RT-11 should not be fixed? My goal is to provide a common utility which functions correctly under all OSs, not just RSTS/E or RT-11. TSX-PLUS has different issues as well. I can add code which solves the problems for RT-11, but since RSTS/E will likely be impacted, a few additional lines can prevent any impact on RSTS/E. As most programmers realize, when any changes are being made to a program, the additional effort of fixing other problems is much less than if done in a separate operation. > At 1:41 PM -0500 3/18/10, Jerome H. Fine wrote: > >> >> >>> Not sure why you need to change what MACRO/CREF are already doing; >>> they work as is under RSTS. If you're fixing a Y2k bug the file >>> chaining code, and for that matter the rest as well, works just as >>> well under RSTS as it does under RT. I would think the best >>> approach is not to change anything, unless it specifically addresses >>> a bug. >> >> >>> From my testing of MACRO / CREF under RT-11, there are 3 separate >>> 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. > > > Well, under RSTS it's a little different. Under the hood, things are > set up so that CREF is chained to (and, e.g., MACRO returned to, > though CREF is not limited to talking to MACRO) when they exist in the > system ($) account. The $ account can span multiple physical disks. > Programs don't need to [explicitly] know about it, the OS finds it for > them. However $ maps to a single [PPN]. > > So I don't see this as a limitation. If MACRO and CREF are installed > normally, everything works as it's supposed to. The real "limitation" > that I am aware of is that you can't have MACRO chain to a private > version of CREF. Say you're working on a development version of > CREF. You need to write your own harness to exercise it; you can't > use the system version of MACRO, FOR, etc., to do that. > > >From the perspective of a (former) system manager, it's not a > problem. Remember, this is a multi-user timesharing system. Quite a > bit different from the RT audience. It sounds like anyone who worked on any development versions of the MACRO / CREF utilities had to do so on their own system or at hours when no one else was around to be bothered. At DEC, that was probably not much of a problem. For RT-11 systems which support essentially only one user at a time, it is also not much of a problem. On the other hand, I have worked with applications running under RT-11 which supported many tasks running at the same time all of which were both human and other computers - a total of 15 tasks of which 4 were for human interaction and 11 were other computers. Fortunately, all were via serial lines so that the processing demands were never that critical. Since it is rather easy to see the solution after it has been found, I agree that it might not have been apparent to the RT-11 developers. Of course, MACRO and CREF might not have been part of the RT-11 development team since I understand it was probably maintained under the RSTS/E group. In that case, maybe the need to keep it simple was the more important goal. Also, the RT-11 group may not have been concerned about the two problems with MACRO running under RT-11, or at least not sufficiently to consider doing anything about the problems. But then, I have all of the technical details worked out for a Logical Name Handler, LN(x).SYS, in RT-11 which will support a Logical Name Search List to allow multiple directories to be searched in RT-11, such as in the Logical Name List feature in VMS and the PATH NAME in DOS, although the latter is limited to executable files. Again, like with READ ONLY files under RT-11, why does such a standard feature which is available under RSTS/E not have the extra code in DIR to show which files are READ ONLY? Still, even if a few extra lines of code are required for the transfer of control back and forth via the .Chain command between MACRO and CREF as the contents of a command file are processed when one or both of MACRO or CREF are not on the SY: device, I can't see that as a huge problem based on the flexibility that provides. By the way, I can't think of any other program that uses CREF except MACRO? Do you know of any? And with so little code (less than 5 blocks including data areas), I would have thought that it would have been better to use CREF as an additional overlay in MACRO rather than all the effort of using the .Chain EMT to go back and forth. Probably the bare code required for an overlay within MACRO would be less than 4 blocks of code since there would not have been the need for any extra stuff for the .Chain EMTs or other code needed because of restarting the process. Since there are 3 overlay areas within MACRO, either of the other two could have been used without making MACRO itself any bigger. I am very aware that VBGEXE is not a concept under RSTS. On the other hand, once MACRO does a .Chain request to CREF, on the return .Chain to MACRO to continue the next compile, MACRO must be reloaded. In fact, that is what the .Chain EMT does, i.e. load and initiate a program. However, since only the root of MACRO is actually loaded to begin the process, the overhead in rather low in my opinion, so the net effect of reloading or not reloading is nothing to disagree about as far as consequences are concerned. So my pointing out that reloading of MACRO does take place due to separate compiles is not to point out a problem, but rather to correct the record of how MACRO / CREF operate, namely, CREF does not terminate after it completes the cross-reference tables, but always does a .Chain EMT request back to the caller. On RT-11 under an unmapped monitor (which is how RSTS runs for RT-11 programs), that is never a problem and it is a valid method of transferring control from CREF back to MACRO. In fact, as far as my testing shows, even if the user command files has a separate RUN MACRO command for each new compile, MACRO gets reloaded again just before it terminates with no additional work to do when it finds no more separate compiles to perform. So repeated RUN MACRO commands in a command file result in MACRO being reloaded twice for every subsequent compile. Again, the number of blocks of disk access involved are too low to be of concern, so this is not a disagreement. I understand, RSTS does not have the concept of system jobs. But RT-11 does and executing the .Chain request aborts the system job. I am saying that there is a solution!!!!!!!!! The .SaveStatus information provided by RSTS provides the device name which the .CStatus information provided by RT-11 supplies. The initial question was how to determine which EMT request to use. I will attempt to explain again why the .SaveStatus EMT request results are sufficiently different between RSTS and RT-11 if on reading my explanation again you still don't understand. What I still don't know is how RSTS handles the .CStatus RT-11 EMT request. Would you be able to run a small test program under RSTS for me to determine that question. Or is there a downloadable RSTS image available that can run RSTS under SIMH available that I can use to test it myself? Based on your explanation and the documentation in the PDF on page 6-16, my assumption is that RSTS converts all time quantities to ticks based on a 60 Hz clock. So even if the actual hardware is running at 50 Hz, the conversion into ticks to satisfy the .GTim EMT request does so based on a 60 Hz clock. Otherwise, the time of day at the top of each page in the listing would be noticeably less than the correct time near the end of the day, i.e. too few ticks would be calculated. Reasonable as long as the conversion of the correct time to ticks for the RT-11 program is done at 60 Hz. Under RT-11, that states that there IS a system clock while bit 5 being zero states that the frequency is 60 Hz. So everything is CORRECT after all!!! Please let me know if you can run a small RT-11 program under RSTS to print the contents of the information provided by the .CStatus EMT request? More specifically, it would also show if there is an error returned or if RSTS just ignores the request but leaves the data block unchanged. What I would probably do is set the overlaid bit in the JSW in word 44 of block zero of the program, then execute the EMTs for channel 17: .SaveStatus .ReOpen .CStatus in that order in case RSTS aborts the program when the .CStatus EMT request is executed. If RSTS just ignores the .CStatus EMT request and returns success, but leaves the data block unchanged, then it will be trivial to determine that RSTS is running rather than RT-11. Jerome Fine

I see that we now agree. Fortunately, the environment under which the problems occur in RT-11 can be detected and will not impact the code when executing under RSTS. However, since any solution means that the new version has to either displace the old version or be located on a different device, I chose the latter alternative so that both could be used and the results compared until everyone is confident that the new code works correctly. Since I am unable to do the testing myself, this allows everyone who chooses to help verify the new code to do so with minimum risk since the new MACRO / CREF can be in the user's private storage. If that is not an advantage, then I agree that there is no point to keeping the old version. The starting point was that only a few minor aspects seem to need fixing: (a) The year in the date was only 2 digits. (b) The time of the compile was only to the minute - I wanted the same accuracy as the elapsed time (c) The elapsed time seems to be the nearest hundredth of a second, but was actually ticks since the number after the decimal point always looped from 00 to 59. Checking the code confirmed it was ticks. I already knew about the VBGEXE problems, so they were fixed as well. Suddenly, I realized that the RSTS use might not be compatible. Plus, I decided that there should be no reason why the files had to be on SY:, as I just explained above. To me, being cautious is allowing for testing against a known result over an extended time period without any impact if that is possible. Under RT-11, the LINK and FORTRAN (also F77) compilers can all be off SY:, so they don't use CREF. I have not tested with C, but I don't think so either. Since I anticipated that RSTS might use CREF with other programs, I attempted to keep everything compatible. Maybe one day, it will actually be tested????? I will give it a try. Actually, my preference right now is to execute the .SaveStatus followed by a .ReOpen if the environment is RT-11. This will only be done if the monitor is unmapped (bit 12 of offset 300 on a .GVal is zero). Otherwise, when a mapped monitor is present, skip both and go directly to the .CStatus to get the device for the program open on the overlay channel. I don't think I made myself clear. My assumption is that RSTS provides the user of the .GTim RT-11 EMT request with a value that is correct for a 60 Hz clock even if the actual system is using a 50 Hz clock, then telling the user via bit 5 in offset 300 that a 60 Hz clock is present. That keeps everything compatible. I believe we are both saying exactly the same thing. The reason there is no conversion error is because the RT11 Run Time system under RSTS calculates ticks based on what a 60 Hz clock would generate and tells the user a 60 Hz clock is present. The user then converts ticks back to the correct time assuming a 60 Hz clock and gets the correct time. Seems sort of silly, but can't be done any other way, of course. I will certainly try. I will make that assumption then since it seems like the correct solution. However, you do not mention if the CARRY bit is clear indicating no error or set indicating an error. I would tend to assume at least the latter since otherwise the user would attempt to use data that could cause a serious problem. Can you check the question of the CARRY bit status on return from RSTS for the .CStatus EMT request? This all helps quite a bit. In fact, without the PDF and your suggestions, I probably would not have been able to justify to myself, let alone others, the reasons for all of the extra code. THANK YOU!!!!!!!!! It seems like you have access to the source code for the RT11 Run Time system under RSTS? Is that the situation? Also, I have a few older V9.0 RSTS and Micro-RSTS manuals from around 1985 that I will likely toss within a year. How can I get them to you so they can be scanned? I also have a number of RT-11 manuals of V04.00 and early V05.00 and V05.01 manuals. Also I believe a full set of V05.05 of RT-11. Since your site has so many different versions of RSTS and RT-11 which are incomplete for most versions less than the latest distributions, I thought that the manuals may be interesting to you. Also, are you aware of anyone else who is still active in writing bug fixes and enhancements for RT-11? If anyone else actually is active, I have not found them at this point. Jerome Fine