<<< DISK$PUBLIC:[COVERT.DECUSERVE]PDP-11.NOTE;1 >>> -< PDP-11 >- ================================================================================ Note 1.0 Welcome to the PDP-11 conference No replies EISNER::STAMERJOHN "RW Stamerjohn" 17 lines 29-MAR-1987 20:19 -------------------------------------------------------------------------------- Welcome to the PDP-11 Software Conference. The various PDP-11 and Professional series operating systems, RT-11, TSX, RSTS, RSX, IAS, P/OS, and others (there are at least a dozen known to exist) are all welcome. If you've written your own operating system, that's welcome too. Ultrix-11 and other PDP-11 UNIX-based systems belong in the UNIX conference, however. We cover all of the PDP-11 languages, real time issues and standalone programs. With the exception of UNIX systems, if it runs on DEC's 16-bit architecture, it belongs here. Hardware issues that are *exclusively* related to the PDP-11 could also be legitimately posted here, but might be better suited to the generic HARDWARE_HELP conference; use good judgment. [Text Modified 30-MAR-1990 22:42:55.56]  ================================================================================ Note 2.0 This topic reserved for future internal directory No replies EISNER::STAMERJOHN "RW Stamerjohn" 2 lines 29-MAR-1987 20:19 -------------------------------------------------------------------------------- The most current internal directory for this conference will be posted as responses to this topic.  ================================================================================ Note 3.0 This topic reserved for future use by the moderator 1 reply EISNER::STAMERJOHN "RW Stamerjohn" 2 lines 29-MAR-1987 20:19 -------------------------------------------------------------------------------- The most current information concerning moderation will be posted as responses to this topic. ================================================================================ Note 3.1 This topic reserved for future use by the moderator 1 of 1 EISNER::DURKIN "Mike Durkin" 18 lines 1-APR-1990 23:23 -< New Topics and Note Titling >- -------------------------------------------------------------------------------- When entering new topics to this conference, be sure to mention the most appropriate PDP category in the note title string. This will help others find information more quickly, especially if they are using the "SEARCH DECUSERVE_TITLES" feature. The note titles of all the topics, of the previously seperate conferences, were altered prior to the merge of these conferences. The conference name/category, enclosed in square brackets [ ], was appended to the front of each note title. There were five active input conferences merged, RT_11, RSTS_OS, RSX, PRO_300_SERIES and PDP_BASIC. Please use one of the five categories mentioned above or another category, provided it is unique and describes a fairly broad area of interest. Thanks in advance for your support in this matter. * Special footnote - This request does not apply to replies of existing topics. This is a guideline/request for NEW TOPICS only.  ================================================================================ Note 4.0 This topic reserved for future use by the moderator 3 replies EISNER::STAMERJOHN "RW Stamerjohn" 1 line 29-MAR-1987 20:19 -------------------------------------------------------------------------------- Additional note for moderators ================================================================================ Note 4.1 This topic reserved for future use by the moderator 1 of 3 EISNER::NEW_CONF "Bill Mayhew" 37 lines 31-MAR-1990 08:57 -< This conference is a merger of 5 others >- -------------------------------------------------------------------------------- This new DECUServe conference is both the home for PDP-11 discussions, and an adventure. For the first time, we have accomplished the full merging of multiple conferences into one. This conference is the result of the merger of the old RSX, RT-11, RSTS_OS, PRO_300_SERIES, and PDP_BASIC conferences. (RSTS_OS had previously been merged with RSTS_FUTURES in a different way.) Since this "appears" to be a new conference, all users who add this conference to their Notebooks will seem to have read none of the messages contained here. The command SET SEEN/BEFORE=28-MAR-1990 at the Notes> prompt will mark all messages that were in the original conferences, as of the time of the move, as "seen"; this is recommended for readers of the previous conferences, to logically "catch up" here. The effect of the merge was to integrate all the notes together as if they had been created in one conference to begin with. Thus, topics appear in date order, with new topic numbers. Replies are also date-ordered within the Notes data structure, but users will still perceive that the replies are tacked onto the original (.0) note of a topic, just like usual. Keywords have been moved as well. The only changes that have been made are: 1. Deletion of empty, redundant 1.0, 2.0, 3.0, 4.0 notes 2. Deletion of redundant warnings about this merger taking place 3. Insertion of text at the beginning of each Topic title that indicates which conference the topic originally came from, e.g. "[RSX]". Your comments on the success/failure of this effort are MOST welcome, and can be addressed to a moderator or to XCOM or to me (using SEND/AUTHOR will accomplish the latter). -Bill, NEW_CONFERENCE_IDEAS moderator and merge coordinator ================================================================================ Note 4.2 This topic reserved for future use by the moderator 2 of 3 EISNER::NEW_CONF "Bill Mayhew" 4 lines 31-MAR-1990 09:00 -< For the record >- -------------------------------------------------------------------------------- Note that notes 1.0, 2.0, 3.0 and 4.0 actually were NOT written by Ralph Stamerjohn. The indication that they were is an artifact of the way the merger was done (by merging the other conferences into the RSX conference). ================================================================================ Note 4.3 This topic reserved for future use by the moderator 3 of 3 EISNER::NEW_CONF "Bill Mayhew" 27 lines 31-MAR-1990 09:08 -< For the record: merger of RSTS_FUTURES with RSTS_OS >- -------------------------------------------------------------------------------- The following note (previously 1.2 in RSTS_OS) is retained here for the record: ================================================================================ Note 19.2 [RSTS]THE RSTS OPERATING SYSTEM 2 of 2 EISNER::KENNEDY "Terry Kennedy" 17 lines 17-DEC-1988 22:40 -< Merger of RSTS_FUTURES >- -------------------------------------------------------------------------------- As part of the DECUServe Executive Committee's ongoing effort to make it easier for our users to locate information, the former RSTS_FUTURES conference has been merged into this conference. Thus, this is now the single repository for all RSTS-related imfor- mation. Please feel free to post questions or comments about future RSTS versions, as well as current versions, in this conference. If you have been following the RSTS_FUTURES conference, issue the Notes command: SET SEEN/BEFORE=18-DEC-1988 to mark all merged notes as SEEN. Terry Kennedy For the DECUServe Executive Committee  ================================================================================ Note 5.0 [RSX]RSX M+ V4.0, What is it? 9 replies EISNER::EISNER "Dan L. Eisner" 5 lines 9-APR-1987 00:23 -------------------------------------------------------------------------------- What are the enhancements and new features in V4.0 of RSX M+? Since the new version is out at field test sites, what have they done to it? I hope this topic will be continuation the above questions. ================================================================================ Note 5.1 [RSX]RSX M+ V4.0, What is it? 1 of 9 EISNER::CETRON 5 lines 9-APR-1987 22:42 -< what, what 4.0? >- -------------------------------------------------------------------------------- i am a field test site for m+ 4.0, as per my agrrreement, i can't discuss it. -ed ================================================================================ Note 5.2 [RSX]RSX M+ V4.0, What is it? 2 of 9 EISNER::CETRON 14 lines 9-APR-1987 22:46 -< spilling the beans >- -------------------------------------------------------------------------------- ok, with the legalities cast aside, it is actually very similar to 3.n. A big change was going to be the inclusion of brusys on the same tape as the distribution kits but this has been scrapped. There are major enhancements to disk caching, bru (aren't there always), all priv'd tasks that can be are vectored, and there is more built-in (vs. added on) support for fast-mapping. basically, it is solid as a rock and is actually quite boring for that reason. I found one bug (with bru) and one typo and that's all. -ed ================================================================================ Note 5.3 [RSX]RSX M+ V4.0, What is it? 3 of 9 EISNER::RICE "Gary Rice" 7 lines 10-APR-1987 12:16 -< There has to be more than that >- -------------------------------------------------------------------------------- Since you're talking, P/OS has had extended logical name support for a long time. This support included a "concealed logical" mechanism similar to VMS that allows for a sort-of sub-directory structure 1 deep. Has that idea made it to M+? Gary ================================================================================ Note 5.4 [RSX]RSX M+ V4.0, What is it? 4 of 9 EISNER::KASPER "Beverly T. Kasper" 6 lines 10-APR-1987 17:32 -< No more Update's? >- -------------------------------------------------------------------------------- From somewhere or other I'd gotten the impression that the reason this is 4.0 instead of 3.1 is that a decision has been made to stop issuing updates. Instead, we will receive full maintenance releases from now on. Anyone out there who can confirm/deny? ================================================================================ Note 5.5 [RSX]RSX M+ V4.0, What is it? 5 of 9 EISNER::CETRON 5 lines 10-APR-1987 22:27 -< no logicals yet >- -------------------------------------------------------------------------------- no extended logicals as yet, I do have a great command line editor from germany but that's sig stuff.... -ed ================================================================================ Note 5.6 [RSX]RSX M+ V4.0, What is it? 6 of 9 EISNER::EISNER "Dan L. Eisner" 33 lines 11-APR-1987 00:38 -< Multi level directorys from DECUS >- -------------------------------------------------------------------------------- Multi level directories are a pain. First one needs an area that is allocated to your terminal when you log in. Then you need an area in the FCB where you keep the default directory information. OK so far. These areas are allocated in M+ 3.0. The problem is that PIP uses the default area to store/restore some of the directory information. PIP thinks it is only 12 bytes long. This blows away the default directory, so always search for directories starting at [000000]. Next only allow the directory search to go up one level. Want to have multi level directories. Modify DIRFND in the FCS routines. Add a push/pop list and parse the inputted directory strings to fill/empty the list. Be sure to reset the list when the syntax is [nnn]. If the syntax is [.xxx] push it and when it is [-] pop it. Save the block numbers of where the directories are in the list. If you use the default directory string, use the top of the list. If you input a directory string, push or pop it depending on syntax. Allow for the following syntaxs. [xxx.yyy.zzz]; [.xxx.yyy]; [-zzz]; [-zz.xxx]; [-zzz.]; [--zzz] and so on. Don't forget to look up each directory for it's block number as you traverse the directory string. Just remember PIP only knows about 12 character directory strings (including the [] or <>). If you get this far then you might as well do an ODS-2 FCS. I did this over Christmas vacation because I had bought a CDROM and I wanted to read the darn thing on my RSX system. PIP is the only problem area. The FCS was a snap. It was the PIP that proved to be a problem, I still haven't got all the bugs out but I can read and transfer the files. Do I have your appetites whetted. Check the Spring 1987 SIG tape. ================================================================================ Note 5.7 [RSX]RSX M+ V4.0, What is it? 7 of 9 EISNER::MCCARTHY 23 lines 6-MAY-1987 20:42 -< Meanwhile, back at the topic >- -------------------------------------------------------------------------------- Back to the original question, some of the features of RSX-11M-PLUS and Micro/RSX version the fourth are (these were discussed at DECUS last week, so they're no secret anymore): o Writeback data caching for temporary files (work files and the like now support cached writes as well as reads.) o The overlay runtime system uses fast map for memory resident overlays if desired o Numerous BRU reliability improvements. No, it doesn't write VMS backup tapes. o Support for terminal server based printers. o All (well most) of the Digital supplied privileged tasks are vectored (SYSGEN now reports "building the privileged task". o TTDRV enhancements for non-terminals. o A preprocessor for indirect command files, and requisite changes to AT. to run the preprocessed command files (faster). o The GIN$ directive is now docuemented. Our thanks to Bruce Mitchell. o New hardware support. o Loadable XDT, with several enhancements, is now available on all of the kits. -Brian ================================================================================ Note 5.8 [RSX]RSX M+ V4.0, What is it? 8 of 9 EISNER::BYRNE_C "Charlie Byrne" 11 lines 16-SEP-1987 15:10 -< RSX11M+ V4.0 Performance/ Mapping >- -------------------------------------------------------------------------------- 1) Does anyone have a target release date for 4.0? 2) Does "Built-In" versus "Added-On" fast mapping buy you anything? What does built-in versus added-on mean? 3) Will all the caveats about the dangers of fast mapping still apply (i.e. no IOT's etc) ? 4) Can one expect any overall performance change over 3.0? ================================================================================ Note 5.9 [RSX]RSX M+ V4.0, What is it? 9 of 9 EISNER::MCCARTHY 31 lines 21-SEP-1987 18:43 -------------------------------------------------------------------------------- -< RSX11M+ V4.0 Performance/ Mapping >- 1) Does anyone have a target release date for 4.0? Soon. Very soon. 2) Does "Built-In" versus "Added-On" fast mapping buy you anything? What does built-in versus added-on mean? It means that the overlay run-time system will know how to use fast map amongst memory resident overlays. If your application has a shallow overlay tree, and overlays frequently (this is important, some applications have many overlays but use each once, such as TKB) you will get better performance. 3) Will all the caveats about the dangers of fast mapping still apply (i.e. no IOT's etc) ? Yes. 4) Can one expect any overall performance change over 3.0? As I described above. Depends on application. Also deferred write data caching may enhance some applications. Are you having specific performance problems? Would you please describe them if yes? -Brian  ================================================================================ Note 6.0 [RSX]RSX Drivers 4 replies 0 lines 3-MAY-1987 12:24 -------------------------------------------------------------------------------- ================================================================================ Note 6.2 [RSX]RSX Drivers 2 of 4 EISNER::TRAYSER "C J "Buck" Trayser - Notes Addict!" 4 lines 3-MAY-1987 23:34 -< I think 6.0 didn't mean to say CONFERENCE... >- -------------------------------------------------------------------------------- I do believe you mean "topic" or "discussion", not conference. 6.xxx is a discussion made up of a topic note (6.0) and responses (6.1-6.n). $ ================================================================================ Note 6.3 [RSX]RSX Drivers 3 of 4 EISNER::FRISBIE "Alan E. Frisbie" 22 lines 3-MAY-1987 23:43 -< CINT$ does NOT suck! >- -------------------------------------------------------------------------------- > I think the CINT$ Executive directive sucks... I know that you're trying to bait me Jim, but I'll bite anyway. While you are right for 90%+ of the cases, the other 10% bear careful consideration. The times that I used CINT$ were when providing the same functionality in a driver would have been difficult, if not impossible. Usually, this is when there needs to be a very close coupling between the context of the I/O code and the application code. Another time is when the overhead of issuing QIO$ directives would be more than you could afford and you are already using the fastest PDP-11 available. These times are few and far between, but when you hit one, CINT$ is often the only realistic solution. Alan ================================================================================ Note 6.4 [RSX]RSX Drivers 4 of 4 EISNER::MCGLINCHEY "Fine RSX drivers for .1 Century" 43 lines 10-MAY-1987 09:01 -< only 90%+ ?? >- -------------------------------------------------------------------------------- < Note 6.3 by EISNER::FRISBIE "Alan E. Frisbie" > -< CINT$ does NOT suck! >- >> While you are right for 90%+ of the cases, the other 10% >> bear careful consideration. OK. CINT s***s in only 90+% of the uses people put it to. I 'll agree to that. Alan's right. My note was placed with the intent of starting a discussion, not a flame. There ARE appropriate uses for CINT$, and Alan and I noth know them. The problem is that users don't. They try to use CINT$ to driver disks, tapes, and (honest) DHV-11's, all things which should be normally have drivers written for them. What we ned is a way to educate users as to which is the proper technique for which kind of application. I think that CINT$ should really be documented the the "Guide to Writing a Device Driver" Manual, for example. That's where it is in VMS, and it makes sense there. The placement of the CINT$ directive description in the Exec Manual leads a user to the mistaken conclusion that this material is the sum total of what needs to be read in order to use CINT$. The user then makes a decision to use CINT$ (rather than write a device driver) based on the relative volume of information. Since CINT$ is only a few pages, the user concludes that it **must** be simpler than writing a device driver. The user simply does not realize what he/she is getting into, often until it's too late. Jim.  ================================================================================ Note 7.0 [RSX]RSX System Tuning 10 replies EISNER::MCGLINCHEY "Fine RSX drivers for .1 Century" 8 lines 3-MAY-1987 12:27 -------------------------------------------------------------------------------- ** Conference on RSX System Tuning ** This conference is a repository for hints, tricks, and techniques for tuning RSX-11M, RSX-11S, RSX-11M-PLUS, and Micro/RSX Systems. Both application and Operating System tuning advice is welcome. ================================================================================ Note 7.1 [RSX]RSX System Tuning 1 of 10 EISNER::MCGLINCHEY "Fine RSX drivers for .1 Century" 17 lines 3-MAY-1987 12:33 -< Don't REM SHF... >- -------------------------------------------------------------------------------- There's an old canard in the lore of RSX that one should REMover the Shuffler in heavily-loaded systems. Don't. SHF... has new duties, since M4.1 (I think) and M-PLUS 2.1 It now initiates checkpointing, during one of its passes. Try it and see what I mean. You'll get a whole pile of tasks sitting in memory, marked for checkpointing, and yet not going out to the good ol' checkpoint file. Jim. ================================================================================ Note 7.2 [RSX]RSX System Tuning 2 of 10 EISNER::MCCARTHY 15 lines 6-MAY-1987 20:48 -< Bah, Humbug. >- -------------------------------------------------------------------------------- > SHF... has new duties, since M4.1 (I think) and M-PLUS 2.1 > It now initiates checkpointing, during one of its passes. Huh? SHF has always had the function of checkpointing stopped tasks during pass 1. It has nothing else to do with checkpointing. If tasks are getting stuck (like is this the CIP bit getting set?) Something else is wrong. My guess is that the shuffler is effective enough to cover up a problem in the normal checkpoint algorithm. Since I'm one of the sources of the "Down with SHF!" campaign, let me restate that point: It isn't helping if you have a lot of memory. The CPU cycles it burns copying tasks could be better spent finishing one of them. -Brian ================================================================================ Note 7.3 [RSX]RSX System Tuning 3 of 10 EISNER::WALTHERS 7 lines 8-MAY-1987 00:38 -< Isn't the 'shuffle' some kind of dance ? >- -------------------------------------------------------------------------------- "RELFFUHS EHT HTIW NWOD" Most of us possess "REAL" machines. "Real machines don't need the shuffler" My real machine has 4 meg in it. The shuffler is just so much excess garbage to carry along and take up POOL. !!!! I vote to remove the shuffler, checkpointing, swapping etc. Just give ME the WHOLE machine, ALL to myself and there will be no problem. The 'shuffle' is some kind of past dance, isn't it ? ================================================================================ Note 7.4 [RSX]RSX System Tuning 4 of 10 EISNER::MCGLINCHEY "Fine RSX drivers for .1 Century" 20 lines 10-MAY-1987 08:48 -< OH? I have a case. >- -------------------------------------------------------------------------------- >> Something else is wrong. Brian: I tried removing SHF on a 2.1D system some time ago, and from thence comes my bit of wisdom. The system was fairly active, had marginally enough memory so that SHF ran about twice an hour. So I REM'd SHF. The result was not a pretty sight. The system has (I still have a picture of its RMD memory frame) many HEL tasks clogged in memory, and many more non-priv'd low priority tasks stuck in GEN. I attributed to a direct cause-and-effect relationship, and quickly perused the SHF source code. I found the call th$ICHKP (i I Think - it's been a while) and concluded that SHF initiates checkpointing on one of its passes. I may be incorrect. If so, I'll back off my assertion. Tell me more. Jim. ================================================================================ Note 7.5 [RSX]RSX System Tuning 5 of 10 EISNER::MCCARTHY 13 lines 12-MAY-1987 19:06 -< It does checkpoinint, but so does the exec >- -------------------------------------------------------------------------------- The shuffler does call $ICHKP in two circumstances. On pass 1 it checkpoints all (well most) stopped tasks on the assumption that they're not busy anyway and will fend for themselves when unstopped. On pass2, if the shuffler finds it can at least free enough memory (discontiguous, at this point) to allow space for the first task in the wait queue, it will checkpoint all tasks needed to free the space. These are in addition to, not in lieu of, the normal checkpoint mechanism. If this is reproducible, we'd like to know (like via SPR.) -Brian ================================================================================ Note 7.6 [RSX]RSX System Tuning 6 of 10 EISNER::MCGLINCHEY "Cape Malleum Majorem" 3 lines 17-MAY-1987 11:15 -< The Manual doesn't help >- -------------------------------------------------------------------------------- Just what IS a "Zero-CPU interval"? Jim. ================================================================================ Note 7.7 [RSX]RSX System Tuning 7 of 10 EISNER::FRISBIE "Alan E. Frisbie" 4 lines 17-MAY-1987 14:55 -< Zero CPU's should be obvious >- -------------------------------------------------------------------------------- >> Just what IS a "Zero-CPU interval"? This relates to multiprocessor operation. It is a period when NONE of the CPU's are on-line. :-} ================================================================================ Note 7.8 [RSX]RSX System Tuning 8 of 10 EISNER::MCCARTHY 11 lines 19-MAY-1987 12:08 -------------------------------------------------------------------------------- < Note 7.7 by EISNER::FRISBIE "Alan E. Frisbie" > -< Zero CPU's should be obvious >- >> Just what IS a "Zero-CPU interval"? A zero-cpu interval occurs when two context switches happen in the same clock tick, so that the apparent CPU time used by a task is zero, even though it's benn running. -Brian ================================================================================ Note 7.9 [RSX]RSX System Tuning 9 of 10 EISNER::STEFFEN 5 lines 5-JAN-1989 15:46 -< Elucidate zero-CPUs, please >- -------------------------------------------------------------------------------- >>> Just what IS a "Zero-CPU interval"? Just what do Zero-CPU intervals mean in terms of system performance? ================================================================================ Note 7.10 [RSX]RSX System Tuning 10 of 10 EISNER::DELARISCH "Arnold S. De Larisch" 19 lines 5-JAN-1989 15:55 -< Not much you can do about it! >- -------------------------------------------------------------------------------- >> < Note 7.9 by EISNER::STEFFEN > >> -< Elucidate zero-CPUs, please >- >> >>> Just what IS a "Zero-CPU interval"? >> Just what do Zero-CPU intervals mean in terms of system performance? Do the words "You can't do anything about it" ring a bell??? 8-{) Seriously, I don't think there is much you can do about it. This is informational, like the total number of CPU ticks and the system's time and date information. The RMD section of the System Managers Volume, discribes the meaning of this 'nebulous' information. -Arnold  ================================================================================ Note 12.0 [RSX]Batch Queue Blues 3 replies EISNER::KASPER "Beverly T. Kasper" 17 lines 7-MAY-1987 10:31 -------------------------------------------------------------------------------- I have a batch job which runs every night at 23:58. It does a bunch of administrative stuff (like running the error log report generator), waits to be sure it's after midnight, then reschedules itself for the next night. This thing has run without problems for months, including about 2 months since I went to update D. On returning from Nashville, I discovered that the last .LOG and .RPT files were dated April 30. It was in the batch queue "BLOCKED UNTIL 1-MAY-87". The system date was 4-MAY-87. There had been no system crash or anything else at all anomolous that I could find. I deleted and rescheduled it for that night. It still doesn't run. The batch queue works fine as long as I don't use the /AFTER switch. Colorado tells me it shouldn't do that. Big help. Any ideas on what might be wrong? ================================================================================ Note 12.1 [RSX]Batch Queue Blues 1 of 3 EISNER::MAXWELL "Gary Maxwell" 13 lines 8-MAY-1987 04:44 -< You, too??? >- -------------------------------------------------------------------------------- < On returning from Nashville, I discovered that the last .LOG and < .RPT files were dated April 30. It was in the batch queue "BLOCKED < UNTIL 1-MAY-87". The system date was 4-MAY-87. There had been < no system crash or anything else at all anomolous that I could find. I have seen the same behaviour, random, unpredictable, etc. I blamed it on cosmic rays, voodoo magic. Guess we better dump the queue file and crash QMG... and SPR this puppy! (By the way, none of the Batch Processors show the job as being active. It's just as though QMG... forgot about it.) ================================================================================ Note 12.2 [RSX]Batch Queue Blues 2 of 3 EISNER::KASPER "Beverly T. Kasper" 7 lines 8-MAY-1987 10:42 -< Suggestions for what to attach to the SPR >- -------------------------------------------------------------------------------- Okay, before I shutdown the system (I've got RT0 and NCPR0 hung in I/O rundown at the moment, so it's about time to dropkick the whole mess anyway), I'd like any and all ideas about what could possibly be useful to the SPR types. Colorado, as I mentioned before, just shakes its collective head. Copying the queue file shouldn't be a problem -- is a crash dump likely to be helpful also? ================================================================================ Note 12.3 [RSX]Batch Queue Blues 3 of 3 EISNER::KASPER "Beverly T. Kasper" 0 lines 13-MAY-1987 16:23 -< Reboot cleared the problem - will post further developments >- --------------------------------------------------------------------------------  ================================================================================ Note 13.0 [PRO300]Postscript on a PRO 1 reply EISNER::RICE "Gary Rice" 11 lines 6-JUN-1987 08:32 -------------------------------------------------------------------------------- The PRO offers some nice graphics capability. However, as support for the system wains at DEC, there will be devices slip by that have a legitemate place in the PRO arena. The LN03(R) Postscript printer is one of those that may never "see the light of day" on the PRO. All is not lost, however. If seems reasonable to me to at least provide some sort of connection for the LN03R to the PRO via GIDIS file conversion. Do you know what the internal format of a GIDIS file looks like? Gary ================================================================================ Note 13.1 [PRO300]Postscript on a PRO 1 of 1 EISNER::ETHINGTON "Superior Klingon Technology" 25 lines 9-JUL-1987 01:49 -< Luser-written GIDIS Interpretors >- -------------------------------------------------------------------------------- I agree, support for the LN03R would be a nice thing to add to P/OS. At least in concept, adding support for a new device is relatively easy, since everything in the Klingon Empire speaks GIDIS, and therefore all you need to do is write a GIDIS to device translator and you are in business. Translators or interpretors are already provided to LVP16, LA100/LA210/LA50, LN03, etc. The format of a GIDIS file is quite well documented in the 3.0 tool kit manual set - the GIDIS manual and the VDM manual tell yo everything you would ever want to know about the format of VDMs (virtual device metafiles) that the system can throw at you, and the GIDIS commands that such a file can contain. Sadly, the one piece of information needed to pull this off is how to interface such a interpretor to the print spooling system on P/OS. In other words, if you write a program that reads VDM/GIDIS and barfs out appropriate escape sequences/postscript commands to make the output device print the desired text and graphics, how do you interface it to the rest of the world? Presumably, the spooling system sends it message packets telling it a file to print, and something needs to be said to the spooling system to get it to call your interpretor, but this is never made clear in the 3.0 tool kit documentation. Hopefully, the 3.2 tool kit coming soon to a Pro near you will clarify this..... If not, maybe we can beat up on P/OS development and get a newsletter article for the PC Sig newsletter on how to interface. Jerry Ethington  ================================================================================ Note 14.0 [RSX]Newest CLE/SRD? 5 replies EISNER::STAMERJOHN "RW Stamerjohn" 10 lines 9-JUN-1987 12:42 -------------------------------------------------------------------------------- I have not had a chance to look at RSX SIG tapes since 1985 (working on small system with no tape drive) and have lost touch with what is what. I now have a TS11 and can look at tapes again. Some questions? Is there a CLE (command line editor) on the tapes. Specifically one which resembles VMS? Has an SRD with named directory support become available? What other goodies have I missed from the 85/86 tapes? ================================================================================ Note 14.1 [RSX]Newest CLE/SRD? 1 of 5 EISNER::TINKELMAN "Bob Tinkelman" 53 lines 9-JUN-1987 15:00 -< AUX, VFDRV and other RSX tape stuff >- -------------------------------------------------------------------------------- < Note 9.0 by EISNER::STAMERJOHN "RW Stamerjohn" > < I have not had a chance to look at RSX SIG tapes since 1985 ... < Is there a CLE (command line editor) on the tapes. Specifically < one which resembles VMS? Yes. There is at least one called AUX, written by Robin Miller, written when he was at Project Place in Cambridge. I don't know where he is now. He moved from there to Norther Telecom but has since, I believe left there. It provides a good number of VMS like command editing functions and a number of commonly used commands available via keypad functions. The version we are using does not allow those commands to be tailored other than by modifying the source code. < Has an SRD with named directory support become available? The answer is "yes and no". If you are in a named directory (or if you specify one explicitly in the command line), things basically work. There is some problem (I think) with /WB. However, named directories are not included in "wild card directory" searches. More importantly, SRD does not yet support decimal version numbers. At some sites that I know of this is the single thing preventing them from converting to using decimal versions. According to Barton Bruce, whom I was speaking to earlier today, Bob Turkelson (sorry if that's misspelled) of NASA's Marshal Space Center and SRD working group head honcho plans to address the decimal version number issue but just hasn't had time. < What other goodies have I missed from the 85/86 tapes? How about on the Spring '87 tape? VIRTUAL DISKS: There's a virtual disk utility called VFDRV which seems to include (with one annoying exception) everything provided by your original VD driver and Glen's VE driver, plus some additional bells and whistles. It can coexist with the older virtual disk packages also. It allows you to combine up to 16 files to make a single virtual disk. It allows the disks to be named anything - VF1:, VF73:, FU2:, or even DU4:. You can remove the names from all the appropriate tables when you are done with them. It seems to do a good job of cleaning up after itself as things like CON work. The thing that seems to be missing is the AVD/LI function to report on the names of the files which make up the virtual disk. ODS II ACP Well - not quite. We haven't tried to use it, but it claims to be a "read only" ACP with a subset PIP. ================================================================================ Note 14.2 [RSX]Newest CLE/SRD? 2 of 5 EISNER::CETRON 8 lines 9-JUN-1987 17:20 -< yep they are there >- -------------------------------------------------------------------------------- look for aux on a recent tapeanahiem or dallas) and mce on san fran for cle's srd newest has decimal number and named directory support. -ed ================================================================================ Note 14.3 [RSX]Newest CLE/SRD? 3 of 5 EISNER::KASPER "Beverly T. Kasper" 12 lines 10-JUN-1987 11:41 -< AUX modules need rebuild for M-Plus 3.0 >- -------------------------------------------------------------------------------- Robin Miller has left Northern Telecom -- he went to CompuGraphics about a year ago, do work in unix (gack!). He had plans to make AUX tailorable, but don't expect to see them unless some other user does it. The AUX task image on the tape will work under 2.1, but you'll get a non-fatal error under 3.0. Rebuild the 2 modules which use the GIN$ directive (I don't recall offhand which they are) to get rid of it. I seem to recall Arnold Delarisch talking about changing SRD to add decimal version numbers. Isn't there conditional code for microRSX in there? ================================================================================ Note 14.4 [RSX]Newest CLE/SRD? 4 of 5 EISNER::MAXWELL "Gary Maxwell" 43 lines 12-JUN-1987 18:25 -< More on VFDRV Virtual Disks >- -------------------------------------------------------------------------------- ! There's a virtual disk utility called VFDRV which seems to ! include (with one annoying exception) everything provided by your ! original VD driver and Glen's VE driver, plus some additional ! bells and whistles. I'm the person responsible for VFDRV. It took some pain and suffering to be able to get the package out in time for the Spring 87 tape. Fortunately, I have forgiving supervisors. The basic premise for the package was to provide shadowing support for Virtual Disks. There were new features in M-Plus V3.0 which allowed shadowing to be implemented. It seems to work OK. Dynamic database creation was something I have always envied from the VT driver. That was a little more interesting, including the CON/HRC interface. ! It can coexist with the older virtual disk packages also. It ! allows you to combine up to 16 files to make a single virtual ! disk. It allows the disks to be named anything - VF1:, VF73:, ! FU2:, or even DU4:. You can remove the names from all the ! appropriate tables when you are done with them. It seems to do a ! good job of cleaning up after itself as things like CON work. ...as long as the device name you choose doesn't already exist in the system. You CAN NOT remove the device database once it is created. Other system data structures (such as task headers) may still be pointing to the UCB when it is removed. The only exception is when AVF is creating the database. If an error occurs, AVF will remove the database, since no one will have been able to touch it. ! The thing that seems to be missing is the AVD/LI function to ! report on the names of the files which make up the virtual disk. I apologize for this. This is high on my wish list, it won't be difficult to implement, I just need some crazy people to write nasty letters to me. Maybe by Anaheim. If people are interested in the package, send me a mail message. ================================================================================ Note 14.5 [RSX]Newest CLE/SRD? 5 of 5 EISNER::DELARISCH 9 lines 20-JUL-1987 21:16 -< SRD and MCE >- -------------------------------------------------------------------------------- Yes, Bev is right, I have modifyed (Slightly) SRD V6.6 to handle decimal version numbers and named directories. I have sent it to atleast one other site (with no complaints). However, it does static assignments for decimal version numbers (i.e. it does not look at the exec symbol ??$DVN). On the otherhand, I have made some hacks to MCE (From Germany) to make it work a bit better with DCL. I'll try to submit the changes for Anahiem. If you need it really bad, let me know and we can arrange something  ================================================================================ Note 15.0 [RSX]DUDRV/RX50/RQDX3 blues No replies EISNER::GARDNER "Tim Gardner" 14 lines 12-JUN-1987 08:11 -------------------------------------------------------------------------------- I am having a problem with RX50 drives randomly and for no apparent reason, going offline. This is happening on 11/53 and 11/73 processors, all with RQDX3 controllers, all running M V4.2B. I can return the drives to operational status by flicking the offline bit, but of course, I lose the I/O operation that was in progress at the time. I have looked in the Dispatch and TXT searched DSIN but could find no references to this (or any similar) problem. Thanks in advance. TimG.  ================================================================================ Note 16.0 [RSX]Does Micro/RSX have VMR? 1 reply EISNER::STAMERJOHN "RW Stamerjohn" 6 lines 15-JUN-1987 09:16 -------------------------------------------------------------------------------- Does Micro/RSX kits come with VMR? Over long distance, I am trying to help someone construct a bootable RX50 diskette with BRU on it. I have been told though Micro/RSX does not have a VMR? If not, what if any are the tricks one can play to make a bootable RX50 system. ================================================================================ Note 16.1 [RSX]Does Micro/RSX have VMR? 1 of 1 EISNER::MCCARTHY 8 lines 17-JUN-1987 15:46 -< No VMR on Micro/RSX >- -------------------------------------------------------------------------------- Micro/RSX does not come with VMR. A bootable BRUSYS floppy can be created using the BRUSYS and the RSX-11M VMR which are supplied on full RSX-11M and RSX-11M-PLUS kits. -Brian  ================================================================================ Note 17.0 [RSX]DECnet/RSX 19 replies EISNER::MAXWELL "Gary Maxwell" 2 lines 16-JUN-1987 12:30 -------------------------------------------------------------------------------- This note is intended for DECnet/RSX discussions, problem reports, etc. ================================================================================ Note 17.1 [RSX]DECnet/RSX 1 of 19 EISNER::MAXWELL "Gary Maxwell" 5 lines 16-JUN-1987 12:32 -< FTS Crashes under V3.0C >- -------------------------------------------------------------------------------- Under M-Plus V3.0C, FTS crashes my systems on the simplest of submission commands (/SB). Has anyone else seen this problem? Does FTS work under V3.0D? (It crashes the system on other FTS commands, also.) ================================================================================ Note 17.2 [RSX]DECnet/RSX 2 of 19 EISNER::SEASTREAM 3 lines 17-AUG-1987 14:49 -------------------------------------------------------------------------------- We had a similar problem and found that when we upgraded to D and E, the problem disappeared. Suggest you do the same. (Update E fixes problems in D related to Decnet.) ================================================================================ Note 17.3 [RSX]DECnet/RSX 3 of 19 EISNER::MAXWELL "Gary Maxwell" 7 lines 20-AUG-1987 21:20 -< Wouldn't it be nice? >- -------------------------------------------------------------------------------- < We had a similar problem and found that when we upgraded to D and E, < the problem disappeared. Suggest you do the same. (Update E fixes < problems in D related to Decnet.) (sigh) If only Software Services would remember that we have software support. We don't have E. Help? ================================================================================ Note 17.4 [RSX]DECnet/RSX 4 of 19 EISNER::SEASTREAM "Steven J. Seastream" 8 lines 16-DEC-1987 13:12 -< Whither Phase V Decnet??? >- -------------------------------------------------------------------------------- For the benefit of those who may not have attended the Fall '87 DECUS Symposium, could we get an explanation of the reasons why Phase 5 of Decnet will not be supported in RSX, and what the implications of such are? (Is this an example of DEC's "continuing commitment" to the PDP-11 series?) I seem to recall that Brian McCarthy provided a brief explanation at one of the sessions. Perhaps some elaboration on this point is in line. ================================================================================ Note 17.5 [RSX]DECnet/RSX 5 of 19 EISNER::MCCARTHY 14 lines 31-DEC-1987 16:42 -------------------------------------------------------------------------------- I'm sorry. I had a whole reply typed in to this note, but I simply don't feel I can respond in writing in this forum as an official DEC position. Suffice it to say that the people who opposed the implementation (including myself) are the ones with the largest stake in PDP-11 futures, and I believe we opposed it for the customer's benefit, not the corporation's. (I'm one of those fools who believes that making customers happy benefits the corporation greatly.) -Brian ================================================================================ Note 17.6 [RSX]DECnet/RSX 6 of 19 EISNER::DELARISCH "Arnold S. De Larisch" 81 lines 2-JAN-1988 17:28 -< DEC Networks and Comm Group Commitment to DECNET/RSX! >- -------------------------------------------------------------------------------- >> < Note 12.5 by EISNER::MCCARTHY > >> I'm sorry. I had a whole reply typed in to this note, but I >> simply don't feel I can respond in writing in this forum as >> an official DEC position. I would love to see your personal opnion with respect to TECHNICAL Aspects of why Phase V DECNet would not be feasable! Considering the rather limited "IBM PC" will be migrated, I don't see any TECHNICAL reason why RSX couldn't be converted to DECNET PHASE V. I will try to second guess Brian a bit here. Considering the LACK of SUPPORT from the Networks and Communications group with RSX DECNET ... it doesn't suprize me that they will NOT be supporting Phase V. Considering they still haven't got PHASE IV to work very well, I doubt their efforts on a DECNET RSX Phase V product would be worthwhile! Just to show all of you DECs commitment to DECNET/RSX consider the following facts. I have a good number of SPRs unanswered and the one which has been answered (1 year after the fact) basically said "Yea, theres a Problem". Their answer didn't even suggest that they would even Look into Fixing the problem in an upcomming release. Every time I get a new AUTOPATCH from SDC for DECNET I have to play a game ... trying to determine how many NEW BUGS THEY HAVE INTRODUCED! Considering their NAC's Commitment to the DECUS Symposium (they had a person who has a list of the SPR's that were open/unresolved/solved). He was there basically to answer questions w.r.t. the DECNET DOS V2.0! Considering that RSX was the platform for which DECNET was based, DEC should be ashamed of themselves for LACK OF SUPPORT. It is rather funny to even think that DEC would consider PHASE V DECNET for RSX. What I consider even more dissapointing is the COMPATABILITY between VMS DECNET And RSX DECNET. Someone should have taken the CTERM spec and BURNED IT! The VMS/DECNET Engineers should also be flogged for their "Private" CTERM utilization ... they saw a loophole in the SPEC and took advantage of it ... meanwhile HETEROGENOUS systems suffer! >> Suffice it to say that the people who opposed the implementation >> (including myself) are the ones with the largest stake in PDP-11 >> futures, and I believe we opposed it for the customer's benefit, >> not the corporation's. (I'm one of those fools who believes that >> making customers happy benefits the corporation greatly.) With the above FLAME, I can understand Brian's reluctance to Phase V DECNET/RSX implementation. It is quite clear to me that the NAC group in DEC would wish that RSX would DIE. I Know why our UNIVERSITY as well as many others are migrating our applications to UNIX ... where we don't have to be completely DEPENDENT ON ONE VENDOR for our computting needs. -Arnold P.S. This note probably belongs in Soapbox ... but I think it needs to be here ... where the people who SUPPORT and USE the RSX and DECNET can further this discussion! P.P.S I don't understand why there are so many problems with Hetrogenous DECNET environments. Considering that I've tied together about a dozen different VENDORS UNIX machines with little to NO PROBLEMS. Machines which included (16-bit, 32-bit, RISC) ... I guess that UNIX vendors are more willing to stick with STANDARDS! P.P.P.S O.K. ... I'm ready to be blasted with the Fire Hoses! 8-{) ================================================================================ Note 17.7 [RSX]DECnet/RSX 7 of 19 EISNER::CETRON 15 lines 4-JAN-1988 19:16 -< i want something small - not iso! >- -------------------------------------------------------------------------------- I for one might not even move my vms boxes completely to phase V iso protocol stacks. It is ugly! huge! and simply inappropriate for use on an 11. As for ibm pc's - the port is a VERY simple VERY stripped down nothingness. As far as I am concernced, until iso really becomes useful, I will have 1 'gateway' vaxen with both protocol stacks (possible under phase V) and all others staying at phase 4, (besides the iso specs aren't even standards yet...) I don't want iso on my 11 for the same reason i don't want to run vms on it. I want a small tight system. I just want better compatibility between vms and rsx. -ed ================================================================================ Note 17.8 [RSX]DECnet/RSX 8 of 19 EISNER::MCCARTHY 9 lines 12-JAN-1988 14:49 -------------------------------------------------------------------------------- Although I won't comment on Arnold's NAC flame, I will state that Ed is closer to the logic I used. -Brian P.S. Individuals interested in this topic should take it up with me one-on-one in Cincinnati. ================================================================================ Note 17.9 [RSX]DECnet/RSX 9 of 19 EISNER::ETHINGTON "Superior Klingon Technology" 87 lines 3-FEB-1988 01:15 -< Phase V or Bust..... >- -------------------------------------------------------------------------------- Aw, heck, its cold outside and there's no place open in Frankfort KY this late so I might as well get in my 2¢ worth. I agree with Brian and Ed's logic regarding Phase V to this extent: I sure don't want to be working on ANY machine, Virtually Monstrous System or real systems, that is set up as a Phase V router. The routing protocol is a pig, the routing matrix will be huge, it will suck up LOTS of memory and CPU time, and I ain't moving out of my system to let Phase V move on and suck up all the CPU. However, I disagree COMPLETELY with the outcome that there shall be no Phase V support for M+. Item 1: Phase V end nodes will not have all that much more overhead than Phase IV. Arnold is right - if a mangy motheaten IBM PC can cut it as a Phase V end node, so can an 11. There is NO excuse at all from the technical standpoint to not offer this, although I understand that the lack of any DECnet/RSX development group may mean that there is not adequate manpower to tackle this project. This, however, can be cured - it is not a technical reason for not doing Phase V. Item 2: It might still be reasonable to offer full Phase V routing on DECnet 11M+. Although I suspect the demands are so great that you will not want this on either a VAX or an 11 being used for interactive purposes, who says you might not wish to have a dedicated 4MB 11/83 sweating up a storm with Phase V routing? They are going to offer full routing DECnet VMS for this reason, and the same reasoning applies to 11s. As for sniveling and whining that the matrix and database will be too big for 11s, baloney. Brian and his team have worked for years giving us cool features like dynamic regions and fast mapping, and it is about time that DECnet/RSX moved into the 80s and started using this sort of thing instead of writing everything in 11/34 compatibility mode for DECnet-11M. No work files or hokey overlays or bull like that - just lots of 64KB dynamic regions which will swap on demand as they are mapped and unmapped (sounds kind of like paging, doesn't it?). Nothing to say you couldn't have 50 megs worth of dynamic regions for a really HUGE Phase V database on a dedicated machine, and I suspect that developers would be surprised how easy the coding would go if they turn themselves loose with current programming capabilities instead of restricting themselves to the 11M compatible subset. Item 3: A few weeks ago, DEC and Apple announced a joint commitment to enhancing connectivity between DEC computers and Apple Macintosh computers. One of the items mentioned, of course, was DECnet support on the Macintosh, which is to be implemented through OSI layer and Phase V DECnet. Therefore, I suspect that DECnet/Mac will NOT be able to talk directly to anything but a Phase V node, and might have reduced functionality (assuming it works at all) if you use a VMS machine as a Phase V to Phase IV gateway to talk to an 11. This is the first concrete example of my loudest bitch: by locking us in at an obsolete version of DECnet, we are automatically locked out of new developments such as Macintosh connectivity. As time goes by, we will doubtless come under increasing pressure to "get rid of those nasty old incompatible 11s" because of possible problems with new versions of DECnet, LAT, terminal server software, and heaven knows what else. The VAX marketing nazis like this, thinking that getting rid of a nasty old 11 automaticlly means another 8800 cluster sale. I got news for them - it can just as easily mean more Macintosh II or IBM sales. Every time you go to an installed customer base and try to force them to "upgrade to our latest (read most profitable) product or drop dead", a certain percentage of the customer base will decide to not upgrade, or upgrade to another vendor. I do NOT want to see the lack of Phase V DECnet become a big reason to not buy an 11. I want to use 11s and VAXes and Macintoshes and have them all communicate with each other. If you keep an 11 customer happy with his DEC product, there is potential that he may at some point buy a VAX or whatever comes after VAX in the future. If you make him unhappy by failing to let him share in other DEC developments and telling him to get rid of his machine, he might decide to go to another vendor, and once that happens he is unlikely to return to DEC. If DEC can give a greater commitment to supporting IBM PCs (read: the Big Blue Enemy) under Phase V than it can its own products, then you can certainly draw your own conclusions about the depth of DEC's supposed continuing commitment to the PDP11. Sorry if this came near a flame - the point I want to make is that, by telling us we will not be sharing in the new developments in future DEC networking products, we are implicitly being told to get rid of our 11s. I do not think this is reasonable thing to do. Ed and PDP-11 working group people, I hope you give them hell over this. Go in with a full charge on your phasers and a full load of photon torpedoes, folks. "Nuke 'em till they glow then shoot 'em in the dark". If we get locked out of these advances, we probably get locked out of everything else, too. Jerry ================================================================================ Note 17.10 [RSX]DECnet/RSX 10 of 19 EISNER::CETRON 12 lines 3-FEB-1988 18:39 -< woa doagie >- -------------------------------------------------------------------------------- moderator hat on: let's hold down the emotionalism and try to keep it a tad more technical, i've received comments that we might ought to move to soapbox if we start ramble-bashing.... so let's keep it on track...... as a starter: would a 'box' (say delni size) which spoke phase V incoming, and had 8 phase IV outputs solve the problems....??? -ed ================================================================================ Note 17.11 [RSX]DECnet/RSX 11 of 19 EISNER::KILLEEN "Jeff Killeen" 4 lines 3-FEB-1988 20:18 -< ROUTING PROBLEM ONLY >- -------------------------------------------------------------------------------- > would a 'box' (say delni size) which spoke phase V incoming, and > had 8 phase IV outputs solve the problems....??? And that box will not be needed for phase IV end nodes ================================================================================ Note 17.12 [RSX]DECnet/RSX 12 of 19 EISNER::ETHINGTON "Superior Klingon Technology" 21 lines 4-FEB-1988 00:43 -< The 20% Solution >- -------------------------------------------------------------------------------- I suspect that a hypothetical mystery box to provide Phase V to Phase IV conversion would, of course, permit Phase IV nodes to communicate with Phase V, and do strange routing and the like. However, this would not address ANY of my other concerns such as compatibility with OSI, future advances in LAT servers, interconnect with DECnet/Mac, a hypothetical Phase VI, etc. The point I was trying to make is that, without Phase V support, we will be under ever-increasing pressure to move to a supported Phase V machine (IBM PS2, anyone? (blech)) in order to share in future networking developments from DEC as we charge into the 90's. A router box would address concerns with routing overhead, and provide simple connectability with Phase V nodes. To me, this seems about 20% of the problem. The only real solution is to provide at LEAST Phase V end node support for DECnet/11M+, DECnet/Micro-RSX, and Pro/DECnet. And, as I said, a case can be made that full routing capability should be offered, although I sure wouldn't like to share a machine with it. If we don't get Phase V support of some sort, we will see an ever lengthening list of DEC (and non-DEC) capabilities that we will be unable to share in. Jerry ================================================================================ Note 17.13 [RSX]DECnet/RSX 13 of 19 EISNER::KENNEDY "Terry Kennedy" 22 lines 4-FEB-1988 03:49 -< Gee, we just recently got Phase IV on RSTS! >- -------------------------------------------------------------------------------- First, this is coming from a RSTS user with no RSX experience, so please bear with me if RSX DECNET isn't quite the same... I currently have an Ethernet-based DECnet with 4 PDP-11's and a VAX 780 in area 1 and a bunch of terminal servers in area 2. The 780 is the designated router for the whole mess, as well as being the only system which can feed the terminal servers when they re-boot. This configuration (with all the 11's as end nodes) worked fine until Field Service shut down the VAX for stand-alone tests. Poof! - my 11's could no longer talk to each other. [RSTS DECnet will work with all end nodes and no router, but if you ever had a router and it goes away, it doesn't remember that it didn't need the router]. The solution was to add our lightest-loaded 11 as an alternate router, so when the VAX goes down, the systems can still talk. Now, my perception of the Phase V announcement is that the original configuration will work, but I will not be able to have my alternate router as it probably won't ever support Phase V routing. Of course, by then I'll probably have another VAX, but that means I'll have to buy another DECnet/VAX full-function license. ================================================================================ Note 17.14 [RSX]DECnet/RSX 14 of 19 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 2 lines 8-MAY-1989 16:34 -< DECnet/RSX Phase V coming >- -------------------------------------------------------------------------------- DECnet/RSX Phase V will be coming. I heard a rumor it is going to field test now. (I am not a field test site for this) ================================================================================ Note 17.15 [RSX]DECnet/RSX 15 of 19 EISNER::COVERT "John Covert, DEC, DECUServe XCom" 5 lines 12-MAY-1989 16:35 -< It's a big secret here at DEC if it's true >- -------------------------------------------------------------------------------- re .14 Well, the RSX Development Manager doesn't know anything about it. /john ================================================================================ Note 17.16 [RSX]DECnet/RSX 16 of 19 EISNER::WYANT "SOME call me ..... TOM" 20 lines 15-MAY-1989 11:18 -< Possible but not probable >- -------------------------------------------------------------------------------- >>> DECnet/RSX Phase V will be coming. I heard a rumor it is going >>> to field test now. (I am not a field test site for this) Welcome news if true. However, the DECnet/RSX product manager, the RSX product manager, and various members of RSX software engineering are also mum. Further, they are actively soliciting soliciting suggestions that will make it easier for us to live with Phase IV. Note that this does not make your rumor false, merely unlikely. It could be that: 1) They are playing things REAL close to their chests. This behaviour is untypical of the RSX folks, but DEC is capable of it (eg: the VT3xx terminals) 2) Maybe the developer isn't DEC (if Ki Research can do it for Apollo, ...) But at this stage I'm not holding my breath. ================================================================================ Note 17.17 [RSX]DECnet/RSX 17 of 19 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 6 lines 15-MAY-1989 12:17 -< A little more background >- -------------------------------------------------------------------------------- Let me give a little more background. A friend of mine at another company received a letter *from DEC* a week or so ago asking if they would like to be a field test site for DECnet/RSX Phase V. My friend wasn't interested, but he called me, thinking I might, before he threw the letter out. It is possible he misread the letter as he read it to me over the phone. ================================================================================ Note 17.18 [RSX]DECnet/RSX 18 of 19 EISNER::COVERT "John Covert, DEC, DECUServe XCom" 1 line 18-MAY-1989 21:49 -------------------------------------------------------------------------------- I'm 99.44% sure he misread the letter. ================================================================================ Note 17.19 [RSX]DECnet/RSX 19 of 19 EISNER::WYANT "SOME call me ..... TOM" 15 lines 19-MAY-1989 12:08 -< Decnet version 4.5 .NE. Decnet phase V >- -------------------------------------------------------------------------------- >>> A friend of mine at another company received a letter *from DEC* >>> a week or so ago asking if they would like to be a field test >>> site for DECnet/RSX Phase V. I've just talked to Carol Greenfield, the DECnet/RSX Product Manager. DEC is looking for field test sites for DECnet/M and S version 4.5, and DECnet/M+ version 4.3, both Phase IV products. PHASE NUMBER IS DIFFERENT THAN VERSION NUMBER (eg: look at all the VAX people who thought they were getting DECNET Phase V last year, because it said "5.0" on the kit). Carol asked me to have anyone interested in field testing any of the above products to call her at (508) 486-5475. PS - I would *LOVE* to see a copy of the letter.  ================================================================================ Note 18.0 [RSX]LOST files 6 replies EISNER::RICE "Gary Rice" 5 lines 24-JUN-1987 09:50 -------------------------------------------------------------------------------- When a file gets "LOST" on an RSX disk, running the VFY task can recover it. Specifically, what does VFY do during the recovery process? Gary ================================================================================ Note 18.2 [RSX]LOST files 2 of 6 EISNER::FRISBIE "Alan E. Frisbie" 9 lines 24-JUN-1987 14:26 -< Files-11 bit-twiddling >- -------------------------------------------------------------------------------- >> Puts the file in directory [1,3]... This is the simplified answer (like a glossy marketing brochure). If you want the dirty bit-twiddling details (technical manual style), let me know how much detail you want. I could bore you for hours on how the Files-11 disk structure is manipulated. :-) Alan ================================================================================ Note 18.3 [RSX]LOST files 3 of 6 EISNER::LEDERMAN "Bart Z. Lederman" 6 lines 24-JUN-1987 19:13 -< Be Prepared >- -------------------------------------------------------------------------------- >> Puts the file in directory [1,3]... It might be well to note that there has to be a directory [1,3] on that disk FIRST, to put the file in. I always create a [1,3] directory on all disks, just in case I'll need it some day. ================================================================================ Note 18.4 [RSX]LOST files 4 of 6 EISNER::RICE "Gary Rice" 19 lines 25-JUN-1987 10:32 -< Let the ACP do the walking . ..] >- -------------------------------------------------------------------------------- >> >> Puts the file in directory [1,3]... > This is the simplified answer (like a glossy marketing > brochure). Yes, it is. I am intimately familiar with VFY and its functions from a user's point of view. > If you want the dirty bit-twiddling details > (technical manual style), let me know how much detail > you want. YES. I want all the dirt. When a file is entered into [1,3] it appears that nothing is changed in INDEXF.SYS. Correct? What about the BITMAP file?, etc, etc. I am ready for the Gory stuff. Gary ================================================================================ Note 18.5 [RSX]LOST files 5 of 6 EISNER::WALTHERS 2 lines 27-JUN-1987 00:45 -< You had better be sure >- -------------------------------------------------------------------------------- Asking Dr. Disk for the Gory stuff on FILES-11 is like asking asking thw SMithsonian for a listing of their holdings. :^) ================================================================================ Note 18.6 [RSX]LOST files 6 of 6 EISNER::FRISBIE "Alan E. Frisbie" 344 lines 28-JUN-1987 16:09 -< Gory details of Files-11 & VFY >- -------------------------------------------------------------------------------- >> What does VFY do with lost files? >> I am ready for the Gory stuff. OK, but remember that you asked for it... :-) Before I describe how VFY, The Files-11 structure veri- fication utility, handles "lost" files, it is necessary to describe the disk structure first. It would also help if you obtain a copy of the Files-11 on-disk specification. This specification has been published several times: The April 1982 and November 1986 issues of the Multi-Tasker, and in the Spring 1987 RSX Session Notes (Nashville, TN). In addition, the RSX Session Notes from the following symposia contain additional diagrams and text explaining the disk structure: Spring 1983 (St. Louis), Fall 1983 (Las Vegas) and Spring 1987 (Nashville). In the interests of keeping this note short, this description will leave out some of the details unnecessary to understanding "lost" file handling. If anyone is inter- ested in more detail, just ask here. I will also be giving a 90-minute presentation on Files-11 at the Fall 1987 sympo- sium in Anaheim. Before we begin, it is necessary to understand a few terms: o Logical Block -- Used to number the blocks on the phy- sical disk itself. They are numbered starting from zero. o Virtual Block -- Used to number the blocks within a FILE. They are numbered starting from ONE. o File ID -- A pair of numbers used to uniquely identify a file. The first of the numbers is the number of a File Header (described below), and the second is the number of times that File Header has been used to describe a new file. Therefore, a File ID will always be unique for the life of a disk volume. The first five File IDs are unique in that the second word always matches the first word (1,1 to 5,5). THE "SACRED" OR "KNOWN" FILES. First, we need to consider three of the five "sacred", or "known", files plus one additional file. o [0,0]INDEXF.SYS (File ID 1,1) -- The Index file provides identification and access information for all files on the volume, including itself. It also con- tains the Boot and Home blocks. o [0,0]BITMAP.SYS (File ID 2,2) -- The storage bitmap file controls the allocation of logical blocks on the volume. o [0,0]000000.SYS (File ID 4,4) -- The Master File Direc- tory (MFD) is the root of the volume directory struc- ture. It contains the five known files and all user directory files. o [0,0]001003.SYS (File ID ?,?) -- A User File Directory (UFD), in this case [1,3], is identical in structure to the MFD. The only difference is that UFDs contain user files instead of the "sacred" files and directory files. THE INDEX FILE (INDEXF.SYS). The index file is comprised of four parts: o The Boot Block: Virtual Block 1 of the file and Logi- cal block 0 of the disk. Not necessary for this dis- cussion. o The Home Block: Virtual Block 2 of the file and Logi- cal block 1 (usually) of the disk. Not necessary for this discussion. o The Index File Bitmap (not to be confused with BITMAP.SYS): Virtual blocks 3 to 3+n (where "n" is a small number). This area reflects the allocation of File Headers. It is viewed as a string of bits, 4096 to a disk block (512 bytes x 8 bits). Each bit shows the allocation status of a single file header (described below); if the bit is SET, the correspond- ing File Header is in use. The low-order bit of the first word marks File Header #1, up through the high-order bit of the last word which marks File Header #4096. Since one block of the Index File Bitmap controls one File Header, there must be one block in the IFB for every POSSIBLE 4096 files. Thus, if you ever want to have 16,384 files on your disk, the IFB must be at least 4 blocks long. This is established at volume in- itialization time. o The File Headers: Virtual Blocks 4+n to the end of IN- DEXF.SYS. A File Header is a single block in the Index File which contains all data describing the physical and record structure of a single file. It is divided into three areas: o Header Area -- Contains the UIC of the File Owner (NOT the UFD), the file Protection, file Charac- teristics and the FCS or RMS file attributes. It also contains the two-word File ID as an additional consistency check. The first value SHOULD match the number of this File Header; if not, the volume has become corrupted! The second value is the number of times that this File Header has been used to create a file. This pair of numbers will uniquely identify any file, past or present, that is created on the disk volume for the life of that volume. o Identification Area -- Contains the Primary File Name, the creation date/time, the revision date/time and the expiration date. Only the File Name is relevant to this discussion. o Map Area -- Contains a pointer to any Extension File Headers (in case the first one is not big enough to map the entire file) and an ordered list of the logical block segments which comprise the file. This list is organized in what are known as "Retrieval Pointers". A single Retrieval Pointer contains an 8-bit block count value and a 24-bit starting Logical Block value. Thus, a single Retrieval Pointer can map a chunk of a file from one to 256 blocks long, starting on any arbitrary Logical Block. These chunks can be scattered anywhere on the disk in no particular order, wherever space is available. A File Header can hold up to 102 Retrieval Pointers before it is necessary to use an exten- sion File Header. Thus, a file MUST be AT LEAST 102 blocks long (each Retrieval Pointer mapping one block) before an extension header is required. Any file over 26,112 blocks long (each Retrieval Pointer mapping 256 blocks) REQUIRES an extension header. From the above description, you can see that INDEXF.SYS describes WHERE on a disk the file is located, plus some al- most irrelevant (for this discussion) information about the file owner's UIC (NOT directory), protection, dates, etc. THE STORAGE BITMAP FILE (BITMAP.SYS). [0,0]BITMAP.SYS is really "just another file", except for its special File ID (2,2) and the fact that it controls the allocation of Logical Blocks on a disk volume. The first block is a "Storage Control Block", intended to summarize the space available in each of the remaining blocks of the file. Except for a few fields at the beginning, this has never been implemented and should be considered as a block of garbage. The remaining blocks implement a bitmap, one bit per Logical Block on the disk volume. If the bit is SET, the block is FREE. Note that this is the opposite of the Index File Bitmap. Since one block of the Storage Bitmap has 4096 bits, there MUST be one block in this file for every 4096 Logical Blocks on the disk. Prior to Update "C" of RSX-11M v4.2 and M-Plus v3.0, BITMAP.SYS could not be larger than 256 blocks. Thus, 255 blocks in the bitmap, times 4096 bits per block equaled 1,044,480 bits. This meant that disks were limited to just over 500 Megabytes per volume. From this we can see that BITMAP.SYS shows which blocks on a disk are actually in use, while INDEXF.SYS tells us which blocks belong to which file. Now we need a mechanism to LOCATE these files. THE MASTER FILE DIRECTORY (000000.DIR). The Master File Directory (MFD) is "just another file" except for its known File ID (4,4) and the fact that it is the "root" of the Files-11 directory structure. It contains a list of all of the "sacred" file names and all Directory files, including itself. Each entry in the list consists of simply the File Name and the cor- responding File ID. These Directory Entries are in the form of 8-word, fixed-length records packed 32 to a disk block. Each 8-word entry is organized as follows: o File Number -- The number of the corresponding File Header in INDEXF.SYS. When a file is deleted, or a directory entry is otherwise removed, this first word is cleared to zero. o File Sequence Number -- The second word of the File ID which identifies how many times that File Header has been used. This prevents the problem of an obsolete directory entry pointing to a File header that has since been used for a new file. o One word of zeros -- The original concept of Files-11 allowed for a disk volume set to extend over multiple physical disks. This word was intended to point to which physical disk the file was on. Since this capa- bility was never implemented for RSX (but was for VMS), this word must always be zero. o File Name -- The File Name is three words long, each word containing three characters of the name in RADIX-50 code. This coding allows for 50 octal (40 decimal) different alphanumeric characters to be packed three to a 16-bit word. o File Type -- The File Type (or Extension) is one word long, also in RADIX-50. o File Version -- The version number is simply a 15-bit binary number with an upper limit of 32767 (decimal). F11ACP will not allow you to create a file with a ver- sion number higher than this. The Master File Directory normally contains directory entries for the five known files (FIDs 1,1 to 5,5), all the User File Directories, and the password file (RSX11.SYS). USER FILE DIRECTORIES (001003.DIR = [1,3]). A User File Directory is "just another file", except that it must have its own directory entry in the MFD ([0,0]). A UFD is in the exact same format at the MFD, but contains the directory entries relating USER files to their File IDs. See the above description of the MFD for the de- tails. IMPORTANT NOTE: There is NO restriction that a file have only a single directory entry! A single file may be known by several names simply by having multiple directory entries. These entries may be in the same or multiple directories. RSX-11M-Plus, Micro/RSX and P/OS support named direc- tories in addition to the traditional numeric directories. Files-11 CAN support hierarchical directories (sub-directories), but there is currently no software sup- port for them. It would take a major rewrite of FCS, RMS, F11ACP, PIP and many other utilities to implement this, so don't hold your breath. ============================================================ Now (whew!) that we have that preliminary information out of the way, we can examine what VFY does. Verify (VFY) is sim- ply a utility which examines the Files-11 structure for con- sistancy, with the optional capability for repairing SOME damage. In the default case, VFY scans every File Header in IN- DEXF.SYS, building a bit-map of which blocks are in use. VFY then compares this list with the bitmap in BITMAP.SYS and reports how many blocks each one claims are in use. If, during this scan, a block marked as in use by a File Header has already been seen as in use by an earlier File Header, a "Multiple Allocation" error is reported. In addition, a second scan of INDEXF.SYS is made to identify which files contain the multiply-allocated blocks. You must then determine which, if any, of the files contain valid in- formation and delete the rest. After deleting the clobbered files, you must run VFY again to correct BITMAP.SYS. If the default scan shows that a different number of blocks used between the Index File and the Storage Bitmap File, you must run VFY again with either the /RE or the /UP switches to correct BITMAP.SYS, depending on whether the Bitmap File or the Index File showed more blocks allocated. This is all described in the RSX-11M Utilities Manual, along with several switches for testing and recovering from some simple disk corruptions. To finally get around to answering your question, VFY provides a "Lost File" scan with the "/LO" switch. This switch caused VFY to scan the entire Index File, looking for any File Header that DOES NOT HAVE AT LEAST ONE ENTRY IN ANY DIRECTORY. If such a file is found, it is declared to be a "Lost File" and a directory entry is created in [1,3], if it ex- ists. This is done simply by searching for the first avail- able 8-word slot in file [0,0]001003.DIR (extending the file if necessary) and writing an entry there. This entry is simply the File ID (obtained from the File Header) and the corresponding File Name, Type and Version (also obtained from the File Header). NOTHING IS CHANGED IN INDEXF.SYS OR IN BITMAP.SYS! Note that the File Protection, Owner's UIC and other characteristics of the file are not changed. After VFY has created these directory entries, you may then examine the files to decide which ones should be deleted or renamed (no need to copy) into the appropriate directory. The reason for placing lost files in a single directory is that the File Owner information in the File Header is just that: the OWNER's identification. There is nothing in the Files-11 structure that prevents a file in UFD [123,321] from being owned by UIC [1,1]. Lost files are typically caused by an RSX utility (F77, TKB, etc.) having a scratch file open at the time of a system crash. Since it is possible for any program to create a file with making a directory entry, this file is now "lost". Another point to note is the way that EDT handles files. When you edit a file with EDT, it creates the new file with the name "filename.TMP". The directory entry that it creates, however, has the name that YOU designated. This is an example of a directory entry name not matching the name in the File Header. Therefore, don't be too quick to delete *.TMP files that are found by a Lost File scan. I hope that this short note has answered your question about lost files. If you have any additional questions, please leave another note. Alan E. Frisbie ("Dr. Disk", as Denny Walthers calls me) Flying Disk Systems, Inc.  ================================================================================ Note 23.0 [RSTS]MONITOR - INIT.SYS 18 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:02 -------------------------------------------------------------------------------- This topic is to be used to discuss the INIT.SYS section of the monitor. Any issue from booting the system to OPTION . ================================================================================ Note 23.1 [RSTS]MONITOR - INIT.SYS 1 of 18 EISNER::DEVELOPMENT "Brian McAllister" 15 lines 22-JAN-1988 17:34 -< SAVRES problems >- -------------------------------------------------------------------------------- I have been having a lot of trouble with SAVRES, doing off-line saves of an RA80 to magtape. I have a TE16 (TMO3) and a TS11. The machine is an 11/44 with many things in it, but I don't have any other problems with it. I can't seem to get a save with no bad compares. I have used brand new high quality tape, tape that has been verified by diagnostics, etc. The problem happens on both drives. The only time I haven't encountered it recently was when I accidentally started a save at 800bpi (on the TE16). We didn't seem to have this kind of problem before V9. Also, the drives are fine as far as DEC field service is concerned. ================================================================================ Note 23.2 [RSTS]MONITOR - INIT.SYS 2 of 18 EISNER::KILLEEN "Jeff Killeen" 4 lines 23-JAN-1988 02:04 -< HMMMM.... >- -------------------------------------------------------------------------------- > I have been having a lot of trouble with SAVRES, doing off-line > saves of an RA80 to magtape. I have a TE16 (TMO3) and a TS11. Have you tried a backup/verify? Just to see if you also get errors. ================================================================================ Note 23.3 [RSTS]MONITOR - INIT.SYS 3 of 18 EISNER::KENNEDY "Terry Kennedy" 29 lines 24-JAN-1988 03:59 -< BACKUP preferred over SAVRES >- -------------------------------------------------------------------------------- > Have you tried a backup/verify? Just to see if you also get errors. Per phone conversation: The user is running 9.2 and SAVRESing to make a backup before up- grading to 9.5. 9.2 was not the best of releases for talking to MSCP disks. I also suggested backup/verify. Notes on backing up systems before upgrading (personal opinion-style comments): 1) BACKUP is probably better than SAVRES - you get error correction [usually], and your TU80 will stream instead of sputter. 2) On versions before 9.3 (maybe before 9.2) you need to use the /ACCOUNT switch as the default was /NOACCOUNT. This has been fixed. 3) There is a barely documented file, [0,1]RECOVR.COM, which will make a bootable tape of a minimal system so you can run RESTORE to get your data back. 4) BACKUP does *NOT* preserve last login information. If this is important to you, you'd better stick with SAVRES. This problem has been SPR'd. 5) BACKUP/VERIFY wants to meet your tapes twice - once for write and one for verify. Therefore, you're better off if you can structure your backups to all fit on one reel of tape. ================================================================================ Note 23.4 [RSTS]MONITOR - INIT.SYS 4 of 18 EISNER::KENNEDY "Terry Kennedy" 9 lines 31-MAR-1988 00:57 -< Auto-restart answered... >- -------------------------------------------------------------------------------- In Latest_Release, a question about bypassing date/time prompting during booting was asked. If the question is actually about restart- ing after a SHUTUP without prompting, Kevin Herbert of RSTS Develop- ment gave out the following tidbit at the Nashville (Spring '87) RSTS technical Q&A session: If you append a CHR$(1%) to the end of the SHUTUP SYS() call, the system will auto-restart without prompting. This has been in place since at least V9.0, and was done to support Micro/RSTS. ================================================================================ Note 23.5 [RSTS]MONITOR - INIT.SYS 5 of 18 EISNER::MCALLISTER "Brian McAllister" 8 lines 31-MAR-1988 11:31 -< Auto-start on power-up >- -------------------------------------------------------------------------------- The patch in question bypasses the date/time prompts even on a cold power-up start. This is because the system has a battery-backed real time clock in it, and the date and time are set from it when the system comes up. The real point of the question was whether 9.6 was really out anywhere. ================================================================================ Note 23.6 [RSTS]MONITOR - INIT.SYS 6 of 18 EISNER::KENNEDY "Terry Kennedy" 26 lines 17-DEC-1988 21:30 -< System auto-restart >- -------------------------------------------------------------------------------- Note 5.1 MONITOR - INIT.SYS 1 of 3 EISNER::KENNEDY "Terry Kennedy" 21 lines 2-JUL-1987 19:39 -< System auto-restart >- -------------------------------------------------------------------------------- INIT needs a mechanism to allow an unattended system to auto-restart after a power outage. This would take the form of a HARDWR option: HA RESTART {OFF | n} where n is the number of seconds (minutes?) to wait before restarting. The console log would look somewhat like this: RSTS V9.3-...... Start timesharing ? Auto-restarting system... Rebuilding system disk... The only drawback to this is that the system won't have the right date and time. However, INIT can default to the date/time the system was last start- ed. At sites where this feature is needed, there are frequently other systems in a network that a user job started by [0,1]START.COM could ask for the time. ================================================================================ Note 23.7 [RSTS]MONITOR - INIT.SYS 7 of 18 EISNER::KENNEDY "Terry Kennedy" 25 lines 17-DEC-1988 21:30 -< /POWERFAIL_DELAY >- -------------------------------------------------------------------------------- Note 5.2 MONITOR - INIT.SYS 2 of 3 EISNER::HORN "Larry Horn" 20 lines 3-JUL-1987 07:02 -< /POWERFAIL_DELAY >- -------------------------------------------------------------------------------- System Manager's Guide, page 14-34, "SET SYSTEM"... /POWERFAIL_DELAY=n Sets the power fail delay to n. When a power failure occurs, the system waits n seconds before rebooting the system. The value of n can range from 1 to 300. You need SWCFG to use this qualifier. We run a PDP-11/70 under RSTS V9.3 and it restarts automatically after a powerfail. The option is enabled by a switch on the console with the options { RUN 0 | RUN 1 | HALT }. (The 0/1 is a 'simulated' switch-register-bit-0.) RSTS will attempt a restart if 1) that bit is 1, and 2) only one power failure within the reboot timeout. The RUN/HALT switch overrides (I think) the SW. If you don't have that switch, you can load the SW via ODT from the console terminal. Have I misunderstood your question? -loh- ================================================================================ Note 23.8 [RSTS]MONITOR - INIT.SYS 8 of 18 EISNER::KENNEDY "Terry Kennedy" 26 lines 17-DEC-1988 21:31 -< Try pulling the plug! >- -------------------------------------------------------------------------------- Note 5.3 MONITOR - INIT.SYS 3 of 3 EISNER::KENNEDY "Terry Kennedy" 21 lines 3-JUL-1987 21:00 -< Try pulling the plug! >- -------------------------------------------------------------------------------- >>> Have I misunderstood your question? Well, maybe. Does your 11 have the battery backup option? If not, and you pull the plug, wait 5 minutes, and plug it back in, it won't know the dif- ference between a powerfail and a normal power-on sequence. If the power just 'blips' long enough for the power monitor to INT the CPU, or if you have battery back-up, your solution works fine. I should probably have explained this more in the note. My suggested enhance- ment would have to check the boot device's 'dirty bit' to tell if there was a power failure. If the dirty bit is set, it's either a power-fail or a hard crash, and the procedure I outlined would then be used. If the dirty bit is not set, then we won't auto-start under any conditions. The reason for the last part is as follows: Many sites shut down timesharing for the weekend, but leave the CPU and disks powered on. If a powerfail happened while in this state without dirty bit being set, the system would bring up time- sharing! tmk ================================================================================ Note 23.9 [RSTS]MONITOR - INIT.SYS 9 of 18 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 9 lines 18-MAR-1989 21:35 -< DRIVE SIZE PATCHES NEEDED >- -------------------------------------------------------------------------------- We just installed a drive that looks like an RM03 *EXCEPT* it has only one head instead of five. It is of course 1/5 the size. Does anyone know what has to be patched in 9.6 to make this work? Yes I know INIT and SAVRES but at what locations? FYI - It is a CDC 9448 on a Emulex SC03/BX. The fixed drive looks like an RM02 and the removable is a 1/5 sized RM03. ================================================================================ Note 23.10 [RSTS]MONITOR - INIT.SYS 10 of 18 EISNER::KENNEDY "Terry Kennedy" 15 lines 19-MAR-1989 18:50 -< Oh well >- -------------------------------------------------------------------------------- > FYI - It is a CDC 9448 on a Emulex SC03/BX. The fixed drive looks like an > RM02 and the removable is a 1/5 sized RM03. *ONLY* Emulex would do this! I figured out all the drive size patches for you, only to discover that RSTS internally combines RM02 and RM03 infor- mation. You can't change the number of heads on one without affecting the other... Your choices are: 1) Ignore the cartridge part 2) Run the drive as a pair of 1/5 size RM03's 3) Get the controller to report one of the parts as a different drive model (like an RM05) 4) Get a different controller that knows better (preferably MSCP) ================================================================================ Note 23.11 [RSTS]MONITOR - INIT.SYS 11 of 18 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 21 lines 21-MAR-1989 23:35 -< TERRY - HOW ABOUT THIS TRICK >- -------------------------------------------------------------------------------- > you, only to discover that RSTS internally combines RM02 and RM03 infor- > mation. You can't change the number of heads on one without affecting the > 4) Get a different controller that knows better (preferably MSCP) Any chance of an option 5 - patch RSTS to use the RM05 table for the RM03 drive? (only if a simple patch) i.e. Make RSTS think the RM03 and the RM05 are the same. I don't think option 4 is viable. The CDC 9448-96 is hybrid drive. It is sort of one drive. It uses a forth tag signal to indicate fixed or removable access. The two drives share all the other signal lines. I don't think you will find an MSCP controller that will handle this. We talked to Emulex today. RSTS did use (V7,V8) separate values for RM02 and RM03 when they designed the controller. They dropped support for this configuration when V9 came out since they had stopped development on the SC03. They are willing to give a 50 percent discount towards a replacement controller but we have not confirmed any current EMULEX controller supports the CDC 9448. ================================================================================ Note 23.12 [RSTS]MONITOR - INIT.SYS 12 of 18 EISNER::KENNEDY "Terry Kennedy" 40 lines 22-MAR-1989 03:06 -< No changes to logic in V9, only addresses >- -------------------------------------------------------------------------------- > Any chance of an option 5 - patch RSTS to use the RM05 table for > the RM03 drive? (only if a simple patch) i.e. Make RSTS think the RM03 > and the RM05 are the same. Maybe - I'll have to do some more disassembly of INIT - he looks at the drive ID being returned and indexes into a table, I think. > We talked to Emulex today. RSTS did use (V7,V8) separate > values for RM02 and RM03 when they designed the controller. Nope - they're wrong (or at least their book is). In the "Emulex Patch Manual for PDP-11 Operating Systems", PD9951002 Rev C, May 1985, they say: "A modified RM02/03 disk cannot be used with an unmodified RM02/03 disk." (P 1-5), and also "RM02/03" as the drives a particular word affects (P 5-31). However, if the Emulex V8.0-07 patches worked for you, the correct offsets for V9.6 are: Old offset New offset 011110 Don't do this one 011264 014074 011344 014154 011424 014234 000046 same 001260 001756 001310 002006 000112 000122 000114 000124 000522 000526 006122 007436 000046 same 001260 001756 001310 002006 000046 same 001436 2124 000522 000526 These are from the tables on pages 5-31/32 of the above manual. If you don't have a copy, let me know and I'll fax you the two pages... ================================================================================ Note 23.13 [RSTS]MONITOR - INIT.SYS 13 of 18 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 11 lines 14-APR-1989 01:00 -< DILOG DQ153 / RSTS MU TAPE DRIVES / MULTI MU UNITS >- -------------------------------------------------------------------------------- We are in the process of replacing our TC02 with a Dilog DQ153 for our dual Cipher 910 tape drive system. The DQ153 makes these drive scream compared to the TC02. However there is a problem. The TC02 reports two different MS CSR's to the system so it thinks it has 2 controllers. The DQ153 reports one MU CSR and the MU controller reports two unit numbers. RSTS does not seem to like the idea of a MU controller that has two unit numbers. There is no DEC MU tape drive that can have more than one unit per controller. This controller works fine with VMS and two tape drives. Question - did RSTS take the cheap way out when they wrote the MU drive and assumed only one unit per controller? ================================================================================ Note 23.14 [RSTS]MONITOR - INIT.SYS 14 of 18 EISNER::KENNEDY "Terry Kennedy" 9 lines 14-APR-1989 03:05 -< So it seems >- -------------------------------------------------------------------------------- > Question - did RSTS take the cheap way out when they wrote the > MU drive and assumed only one unit per controller? So it would seem, the V9.6 release notes (P 4-2) state: "The controller number must also match the drive number." However, much of the code is common with the disk MSCP stuff, so they might fix it if you SPR it... ================================================================================ Note 23.15 [RSTS]MONITOR - INIT.SYS 15 of 18 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 3 lines 21-APR-1989 16:10 -< CONTROLLER PRIORTIES >- -------------------------------------------------------------------------------- Does anyone know why RSTS runs its MSCP controllers at priority 5 when VMS runs them at priority 4? ================================================================================ Note 23.16 [RSTS]MONITOR - INIT.SYS 16 of 18 EISNER::KENNEDY "Terry Kennedy" 7 lines 21-APR-1989 17:52 -< Oh? >- -------------------------------------------------------------------------------- > VMS runs them at priority 4? It does? The UDA-50 manual (EK-UDA50-UG-002), page 2-13, says: "All UDA50 modules are shipped with a level 5 priority plug. This is the recommended priority level for UDA50 Disk Subsystems and thus, the prio- ority plug need not be changed for the majority of installations." ================================================================================ Note 23.17 [RSTS]MONITOR - INIT.SYS 17 of 18 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 7 lines 21-APR-1989 19:32 -< HMMMMMMMMMMMMMMMMM....... >- -------------------------------------------------------------------------------- > "All UDA50 modules are shipped with a level 5 priority plug. This is the > recommended priority level for UDA50 Disk Subsystems and thus, the prio- > ority plug need not be changed for the majority of installations." Both Sigma and TD systems ship their MSCP controllers at priority 4 and claim that is the norm for VMS. In TD's case they can't change it. ================================================================================ Note 23.18 [RSTS]MONITOR - INIT.SYS 18 of 18 EISNER::KENNEDY "Terry Kennedy" 0 lines 23-APR-1989 20:51 -< More in Hardware_help >- --------------------------------------------------------------------------------  ================================================================================ Note 24.0 [RSTS]MONITOR - EXECUTIVE 28 replies EISNER::KILLEEN 3 lines 25-JUN-1987 21:05 -------------------------------------------------------------------------------- This topic is to be used to discuss the Executive section of the monitor. Issues related to SYS Calls, System Directives, and monitor data structures. ================================================================================ Note 24.1 [RSTS]MONITOR - EXECUTIVE 1 of 28 EISNER::KILLEEN 33 lines 1-JUL-1987 23:20 -< FUN WITH JOB HEADER - 1 >- -------------------------------------------------------------------------------- It is possible to access directly the job header region in a Basic-Plus-2 program. For example to access the core common area you do the following. 1. Create a MAP statement in the program as follows: MAP (CORCMN) STRING FILL=304, STRING CORE.COMMON=128 2. Modify your ODL file as follows: ORIGINAL FILE .ROOT USER USER: .FCTR SY:prgnam-LIBR LIBR: .FCTR LB:BP2OTS/LB .END MODIFIED FILE ADD> .PSECT CORCMN,RW,D,GBL,ABS,OVR .ROOT USER MOD> USER: .FCTR SY:prgnam-CORCMN-LIBR LIBR: .FCTR LB:BP2OTS/LB .END You will get the following error during the task build %TKB -- *DIAG*-Module PRGNAM multiply defines P-section CORCMN Ignore it! Remember that the SYS call functions stores their function value in the first byte of core common. ================================================================================ Note 24.2 [RSTS]MONITOR - EXECUTIVE 2 of 28 EISNER::KILLEEN "Jeff Killeen" 118 lines 8-JUL-1987 08:59 -< THE ONLY EASY WAY TO CONTROL USER LOGICALS >- -------------------------------------------------------------------------------- It is possible to access directly the user logical name table from a Basic-Plus-2 program. To access the user logical name table you do the following. 1. Create a MAP statement in the program as follows: MAP (USRLOG) STRING FILL=480, WORD USER.LOGICALS(15) 2. Modify your ODL file as follows: ORIGINAL FILE .ROOT USER USER: .FCTR SY:prgnam-LIBR LIBR: .FCTR LB:BP2OTS/LB .END MODIFIED FILE ADD> .PSECT USRLOG,RW,D,GBL,ABS,OVR .ROOT USER MOD> USER: .FCTR SY:prgnam-USRLOG-LIBR LIBR: .FCTR LB:BP2OTS/LB .END You will get the following error during the task build %TKB -- *DIAG*-Module PRGNAM multiply defines P-section USRLOG Ignore it! This is the setup of the user logical area in the job image. PPN's ARE USED CASE If bytes 25 and 26 both have a value of 255 then the setup is as follows: BYTE 1-4 RAD50 NAME OF FIRST USER LOGICAL BYTE 5-6 REAL DEVICE NAME OF FIRST USER LOGICAL BYTE 7 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 8 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 9-12 RAD50 NAME OF SECOND USER LOGICAL BYTE 13-14 REAL DEVICE NAME OF SECOND USER LOGICAL BYTE 15 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 16 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 17-20 RAD50 NAME OF THIRD USER LOGICAL BYTE 21-22 REAL DEVICE NAME OF THIRD USER LOGICAL BYTE 23 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 24 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 25-26 MUST BOTH BE 255 BYTE 27 PROGRAMMER NUMBER OF FIRST USER LOGICAL BYTE 28 PROJECT NUMBER OF FIRST USER LOGICAL BYTE 29 PROGRAMMER NUMBER OF SECOND USER LOGICAL BYTE 30 PROJECT NUMBER OF SECOND USER LOGICAL BYTE 31 PROGRAMMER NUMBER OF THIRD USER LOGICAL BYTE 32 PROJECT NUMBER OF THIRD USER LOGICAL PPN's ARE NOT USED CASE If either bytes 25 and 26 do not have a value of 255 then the setup is as follows: BYTE 1-4 RAD50 NAME OF FIRST USER LOGICAL BYTE 5-6 REAL DEVICE NAME OF FIRST USER LOGICAL BYTE 7 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 8 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 9-12 RAD50 NAME OF SECOND USER LOGICAL BYTE 13-14 REAL DEVICE NAME OF SECOND USER LOGICAL BYTE 15 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 16 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 17-20 RAD50 NAME OF THIRD USER LOGICAL BYTE 21-22 REAL DEVICE NAME OF THIRD USER LOGICAL BYTE 23 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 24 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE 25-28 RAD50 NAME OF FOURTH USER LOGICAL BYTE 29-30 REAL DEVICE NAME OF FOURTH USER LOGICAL BYTE 31 DEVICE NUMBER (ONLY REAL IF NEXT BYTE=255) BYTE 32 UNIT NUMBER FLAG 0=NONE, 255=REAL BYTE TO ARRAY MAP BYTE 1 USER.LOGICALS(0)=LOW BYTE BYTE 2 USER.LOGICALS(0)=HIGH BYTE BYTE 3 USER.LOGICALS(1)=LOW BYTE BYTE 4 USER.LOGICALS(1)=HIGH BYTE BYTE 5 USER.LOGICALS(2)=LOW BYTE BYTE 6 USER.LOGICALS(2)=HIGH BYTE BYTE 7 USER.LOGICALS(3)=LOW BYTE BYTE 8 USER.LOGICALS(3)=HIGH BYTE BYTE 9 USER.LOGICALS(4)=LOW BYTE BYTE 10 USER.LOGICALS(4)=HIGH BYTE BYTE 11 USER.LOGICALS(5)=LOW BYTE BYTE 12 USER.LOGICALS(5)=HIGH BYTE BYTE 13 USER.LOGICALS(6)=LOW BYTE BYTE 14 USER.LOGICALS(6)=HIGH BYTE BYTE 15 USER.LOGICALS(7)=LOW BYTE BYTE 16 USER.LOGICALS(7)=HIGH BYTE BYTE 17 USER.LOGICALS(8)=LOW BYTE BYTE 18 USER.LOGICALS(8)=HIGH BYTE BYTE 19 USER.LOGICALS(9)=LOW BYTE BYTE 20 USER.LOGICALS(9)=HIGH BYTE BYTE 21 USER.LOGICALS(10)=LOW BYTE BYTE 22 USER.LOGICALS(10)=HIGH BYTE BYTE 23 USER.LOGICALS(11)=LOW BYTE BYTE 24 USER.LOGICALS(11)=HIGH BYTE BYTE 25 USER.LOGICALS(12)=LOW BYTE BYTE 26 USER.LOGICALS(12)=HIGH BYTE BYTE 27 USER.LOGICALS(13)=LOW BYTE BYTE 28 USER.LOGICALS(13)=HIGH BYTE BYTE 29 USER.LOGICALS(14)=LOW BYTE BYTE 30 USER.LOGICALS(14)=HIGH BYTE BYTE 31 USER.LOGICALS(15)=LOW BYTE BYTE 32 USER.LOGICALS(15)=HIGH BYTE Remember Digital is considering changing this table! Isolate into a function or subroutine any code you write accessing this area. ================================================================================ Note 24.3 [RSTS]MONITOR - EXECUTIVE 3 of 28 EISNER::KENNEDY "Terry Kennedy" 25 lines 26-SEP-1987 02:45 -< Can you top this? >- -------------------------------------------------------------------------------- Here's one to stump the band - privileged run-time systems! I have been working on some extensive mods to Brian Nelson's CLE package (a VMS-like command recall package). I now support editing from hardcopy terminals, not getting confused if the CRT is in VT52 mode, etc. The last thing I tried was going to be the simplest (I thought). I put in regain/drop temporary privileges arount all the directives re- quiring INSTAL privilege, and set the CLE.RTS protection to <232>. Lo and behold, no temporary privileges! The monitor clears the job keyword on entry, so you can never get temporary privs. A cheat for this is to create a null file FOO.CLE<232> and run it. That will get you in with- out INSTAL, but the monitor returns you to your previous RTS after you issue a command. Looking at the System Directives manual, what I need is a sub-function of the .RTS call which combines the -1 and -2 options - change default RTS without clearing job context (and thus preserving the keyword). However, DEC doesn't document such an option (and it isn't -3). How- ever, DCL.RTS is a <232> RTS and gets very upset if you rename it to <104> or some such. Therefore, it *is* possible to do what I want. I asked several of the gurus in the user community (some who have fiche, as well) and none of them could come up with any suggestions. Anybody have any ideas? ================================================================================ Note 24.4 [RSTS]MONITOR - EXECUTIVE 4 of 28 EISNER::KENNEDY "Terry Kennedy" 4 lines 30-SEP-1987 19:57 -< Ask a strange question, get a strange answer >- -------------------------------------------------------------------------------- Well, the answer came in today. The trick is to do a CHAIN to yourself (the .RTS file) every time you need privs. I didn't know you could do such a think, but if that's what they say, I'll try it. ================================================================================ Note 24.5 [RSTS]MONITOR - EXECUTIVE 5 of 28 EISNER::KENNEDY "Terry Kennedy" 15 lines 3-OCT-1987 04:58 -< DCL performance improvement possible >- -------------------------------------------------------------------------------- Did you know that many DCL commands cause a disk read to get the directory entry information for DCL.RTS? This information is already in memory, in the RTS Descriptor Block. A transparent switch of run-time system (as in saying $@comfilename from RSX causes 4 directory reads (2 each for DCL and RSX.RTS). This is apparently the cause of one of DCL's bigger preformance problems, and it only gets worse with heavy disk activity. Some testing shows that the DCL speed can improve 40% when issuing commands from within DCL and about 500-700% when running a COM file from another RTS if the lookup is done against the RTS Descriptors as opposed to disk. The issue (and 3 other related items) has been SPR'd to DEC. If I get an answer I will post the gist (but not the text [MMMPPHHH GRMMMPPHHH!]) here. ================================================================================ Note 24.6 [RSTS]MONITOR - EXECUTIVE 6 of 28 EISNER::KENNEDY "Terry Kennedy" 14 lines 12-OCT-1987 21:43 -< And the answer is... >- -------------------------------------------------------------------------------- > The issue (and 3 other related items) has been SPR'd to DEC. If I get an > answer I will post the gist (but not the text [MMMPPHHH GRMMMPPHHH!]) > here. The response came back rather oddly worded. I get the impression that they think it is a good idea, but would be unable to implement it for a while, due to the 'need to test it extensively'. Usually answers to suggestion SPR's come back as 'thank you - maybe later, sometime'. The fact that this came back differently makes me think that someone actually thought out the code to do it, which implies that it has a better-than-average chance of getting implemented. Of course, maybe I'm just reading something into the reply that really isn't there... ================================================================================ Note 24.7 [RSTS]MONITOR - EXECUTIVE 7 of 28 EISNER::KILLEEN "Jeff Killeen" 5 lines 29-NOV-1987 19:06 -< CACHE QUESTION >- -------------------------------------------------------------------------------- Please read note 12.7 in the PDP_BASIC conference. Does anyone having any ideas why RSTS did not keep the BP2 compiler in cache by itself? ================================================================================ Note 24.8 [RSTS]MONITOR - EXECUTIVE 8 of 28 EISNER::KILLEEN "Jeff Killeen" 42 lines 9-MAY-1988 08:19 -< MORE FUN WITH RSTS DATA CACHING >- -------------------------------------------------------------------------------- If you have read my BP2 notes you know that cache acts weird. Now to add to the mystery consider the following for 30K sequential reads.... WITH A 1MB DATA CACHE..... CPU MEMORY CONTROLLER DISK CACHE TIME ----- ------ ---------- -------- ----- ---- 11/73 PMI SPECTRA-25 9715-515 DIR 189 11/73 PMI SPECTRA-25 9715-515 DIR/DATA 260 11/83 PMI SPECTRA-25 9715-515 DIR 187 11/83 PMI SPECTRA-25 9715-515 DIR/DATA 256 WITH A 12 BLOCK DATA CACHE..... CPU MEMORY CONTROLLER DISK CACHE TIME ----- ------ ---------- -------- ----- ---- 11/73 PMI SPECTRA-25 9715-515 DIR 189 11/73 PMI SPECTRA-25 9715-515 DIR/DATA 230 You will note that using a 1MB data cache *SLOWED* down the transfer. Meaning it took the CPU longer to search the data cache than 9715 took to find and transfer the data. Also note that when there was a very small cache the overhead of using the cache in and of itself *SLOWED* down the transfer. AFTER THIS PLUS MY EXPERIENCES WITH THE BP2 COMPILER I BELIEVE DEC HAS DONE A POOR JOB OF IMPLEMENTING DATA CACHING. The basic overhead of using it on a very fast drive wipes out its value. When it has a lot of blocks in cache the search time is excessive. My guess is the reason why the BP2 compiler ran faster when I installed the blocks sequentially was it put the most used blocks at the top of the search list. P.S. I have found that all DEC disk drives are too slow to cause this effect. ================================================================================ Note 24.9 [RSTS]MONITOR - EXECUTIVE 9 of 28 EISNER::KENNEDY "Terry Kennedy" 15 lines 17-DEC-1988 21:38 -< STANDARD USER LOGICALS a la VMS >- -------------------------------------------------------------------------------- Note 6.1 MONITOR - EXECUTIVE 1 of 20 EISNER::KILLEEN "Jeff Killeen" 10 lines 15-JUL-1987 11:27 -< STANDARD USER LOGICALS a la VMS >- -------------------------------------------------------------------------------- VMS supports the following standard user logicals. Whenever the system does I/O to one of the devices it uses the logicals. This would be a very useful RSTS compatibility feature to support. This fits well within the RSTS architecture and 16-bit address space. SYS$COMMAND SYS$DISK SYS$ERROR SYS$INPUT SYS$OUTPUT ================================================================================ Note 24.10 [RSTS]MONITOR - EXECUTIVE 10 of 28 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 21:38 -< SEPERATE SYSTEM PASSWORDS >- -------------------------------------------------------------------------------- Note 6.2 MONITOR - EXECUTIVE 2 of 20 EISNER::KILLEEN "Jeff Killeen" 8 lines 11-AUG-1987 09:34 -< SEPERATE SYSTEM PASSWORDS >- -------------------------------------------------------------------------------- We need sperate system passwords for local, remote, and network users. Right now we only set the system password for remote users because we do not want someone dialing in who got a password from a user. It would be nice to have a password for the local users so if someone left we could change the system password and lock them out of all accounts. If we had the sperate passwords we could do this and still keep the extra level of security on the dialup lines. ================================================================================ Note 24.11 [RSTS]MONITOR - EXECUTIVE 11 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:38 -< TERMINAL PASSWORDS >- -------------------------------------------------------------------------------- Note 6.3 MONITOR - EXECUTIVE 3 of 20 EISNER::KILLEEN "Jeff Killeen" 3 lines 11-AUG-1987 09:37 -< TERMINAL PASSWORDS >- -------------------------------------------------------------------------------- It would be nice to have a terminal password for each terminal. It is very easy to check in the applications code what terminal a user is running at. Howvever you have no guarantee the right user is on that terminal. ================================================================================ Note 24.12 [RSTS]MONITOR - EXECUTIVE 12 of 28 EISNER::KENNEDY "Terry Kennedy" 14 lines 17-DEC-1988 21:38 -< I'll do that >- -------------------------------------------------------------------------------- Note 6.4 MONITOR - EXECUTIVE 4 of 20 EISNER::KENNEDY "Terry Kennedy" 9 lines 11-AUG-1987 18:33 -< I'll do that >- -------------------------------------------------------------------------------- Regarding additional passwords, both system and terminal, I will write the necessary changes to LOGIN. The changes will be posted on the newsletter system when completed, and I'll leave a note here announcing their avail- ability. By the way, the system password and many other things set with the SET system command are actually the attributes (as in SHOW ACCOUNT) of account [0,1]. SH ACC is smart enough to not print them, however. All LOGIN does is look up the attributes and determine the job class. ================================================================================ Note 24.13 [RSTS]MONITOR - EXECUTIVE 13 of 28 EISNER::KENNEDY "Terry Kennedy" 11 lines 17-DEC-1988 21:38 -< A biggie >- -------------------------------------------------------------------------------- Note 6.5 MONITOR - EXECUTIVE 5 of 20 EISNER::CONROY "Alan Conroy" 6 lines 11-AUG-1988 14:31 -< A biggie >- -------------------------------------------------------------------------------- I hear rumors that V10 will have multi-level directories. Just in case this is ONLY a rumor, let me put in my two-cents to the RSTS/E developers: Please give us multi-level directories! I realize this is a MAJOR change and not something that will happen over-night, but this is probably THE major drawback to RSTS/E. (Did I say RSTS/E had a drawback!?! Oh well, the truth hurts sometimes.) ================================================================================ Note 24.14 [RSTS]MONITOR - EXECUTIVE 14 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:38 -< That's a biggie! >- -------------------------------------------------------------------------------- Note 6.6 MONITOR - EXECUTIVE 6 of 20 EISNER::SCOPELLITI "Whatsa behind is uva no importan" 3 lines 11-AUG-1988 18:13 -< That's a biggie! >- -------------------------------------------------------------------------------- Boy, has this been on the wish list for a long time! BTW, IMHO, RSTS/E's biggest drawback is 16 bits. ================================================================================ Note 24.15 [RSTS]MONITOR - EXECUTIVE 15 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:38 -< Not a RSTS/E drawback >- -------------------------------------------------------------------------------- Note 6.7 MONITOR - EXECUTIVE 7 of 20 EISNER::CONROY "Alan Conroy" 3 lines 12-AUG-1988 12:00 -< Not a RSTS/E drawback >- -------------------------------------------------------------------------------- > BTW, IMHO, RSTS/E's biggest drawback is 16 bits. Ah, but that's not a RSTS/E drawback, that's a PDP-11 drawback! :-) ================================================================================ Note 24.16 [RSTS]MONITOR - EXECUTIVE 16 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:38 -< migration: VAX/VMS --> VAX/RSTS >- -------------------------------------------------------------------------------- Note 6.8 MONITOR - EXECUTIVE 8 of 20 EISNER::HORN "Larry Horn, Millsaps College" 3 lines 13-AUG-1988 12:01 -< migration: VAX/VMS --> VAX/RSTS >- -------------------------------------------------------------------------------- >> Ah, but that's not a RSTS/E drawback, that's a PDP-11 drawback! :-) Anyone for VAX/RSTS (directly, not like RSX)? ================================================================================ Note 24.17 [RSTS]MONITOR - EXECUTIVE 17 of 28 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 21:39 -< I HAVE 85 CUSTOMERS WAITING >- -------------------------------------------------------------------------------- Note 6.9 MONITOR - EXECUTIVE 9 of 20 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 4 lines 14-AUG-1988 12:20 -< I HAVE 85 CUSTOMERS WAITING >- -------------------------------------------------------------------------------- > Anyone for VAX/RSTS (directly, not like RSX)? Yes but who would write it 8-( ================================================================================ Note 24.18 [RSTS]MONITOR - EXECUTIVE 18 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:39 -< Cringe! >- -------------------------------------------------------------------------------- Note 6.10 MONITOR - EXECUTIVE 10 of 20 EISNER::CONROY "Alan Conroy" 3 lines 15-AUG-1988 12:10 -< Cringe! >- -------------------------------------------------------------------------------- > Yes but who would write it 8-( ...There's always ROSS/V....(cringe) ================================================================================ Note 24.19 [RSTS]MONITOR - EXECUTIVE 19 of 28 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 21:39 -< I/O counts needed >- -------------------------------------------------------------------------------- Note 6.11 MONITOR - EXECUTIVE 11 of 20 EISNER::CONROY "Alan Conroy" 4 lines 15-AUG-1988 12:17 -< I/O counts needed >- -------------------------------------------------------------------------------- How about some sort of I/O count per job. Even better would be two I/O counts - one for slow devices (like terminals), and one for fast devices (like disk & tape). This a) helps in resource accounting/charging, and b) helps in determining I/O bottlenecks. ================================================================================ Note 24.20 [RSTS]MONITOR - EXECUTIVE 20 of 28 EISNER::KENNEDY "Terry Kennedy" 19 lines 17-DEC-1988 21:39 -< LAT support >- -------------------------------------------------------------------------------- Note 6.12 MONITOR - EXECUTIVE 12 of 20 EISNER::CONROY "Alan Conroy" 14 lines 13-SEP-1988 13:30 -< LAT support >- -------------------------------------------------------------------------------- Pardon me if this isn't the right place for this, but it looked like the best fit... I just received a software dispatch yesterday which says: "RSTS/E Version 9.6 includes LAT (Local Area Transport) support that allows systems with DECnet/E Version 4.0 to connect terminals..." WHAT!?? Does this really mean what it says? Do we HAVE to have DECnet to make RSTS/E LAT work? Why? This is silly. If this is true, DEC just lost some harware sales to us (for ethernet controllers), because we certainly are not going to buy DECNET/E! Does anyone else know any more about this. Does anyone care? P.S. I hope the above quote is not in violation of the DECUServe rules. If so, please let me know. Thanks. ================================================================================ Note 24.21 [RSTS]MONITOR - EXECUTIVE 21 of 28 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 21:39 -< The Joy of Marketing... >- -------------------------------------------------------------------------------- Note 6.13 MONITOR - EXECUTIVE 13 of 20 EISNER::KENNEDY "Terry Kennedy" 7 lines 13-SEP-1988 17:58 -< The Joy of Marketing... >- -------------------------------------------------------------------------------- > WHAT!?? Does this really mean what it says? Do we HAVE to have DECnet > to make RSTS/E LAT work? Why? This is silly. So they say. When it is released, I'm going to play with it. I'm pretty sure this *is* a requirement, but that it *isn't* for a technical reason. If there is a way around it which doesn't require DECNET/E, I'll write it up for the Newsletter and summarize it here. ================================================================================ Note 24.22 [RSTS]MONITOR - EXECUTIVE 22 of 28 EISNER::KENNEDY "Terry Kennedy" 25 lines 17-DEC-1988 21:39 -< More thoughts >- -------------------------------------------------------------------------------- Note 6.14 MONITOR - EXECUTIVE 14 of 20 EISNER::KENNEDY "Terry Kennedy" 20 lines 14-SEP-1988 03:36 -< More thoughts >- -------------------------------------------------------------------------------- Let me add something here. The LAT code certainly wasn't written yesterday. As a matter of fact, if you looked in the MSD booth at Anaheim (Fall '87) at the right time, you might have seen an *very* early 9.6 version. I think it's safe to say that the code was spec'd well before that. The market realities have changed a bit since then. At that time, no LAT server was available which didn't need downloading from a host, and old- style interfaces were less costly per port than LAT boxes. Therefore, DEC *may* have assumed (I'm guessing here) that users who wanted LAT had A) Another system to load the server and B) DECNET. Since then, other companies have announced LAT boxes which don't need downloading, and the price/port on the DECserver 500 is competitive with the DEC terminal cards in many cases. I think DEC will probably react to these changes in a while. Meanwhile, as I posted, I will do what I can to see if it can run without DECNET. However, I *do* think we should thank DEC *strongly* for putting in the effort to give us LAT. As I editorialized in the September '87 DECUS Newsletter, it certainly isn't a trivial piece of code. ================================================================================ Note 24.23 [RSTS]MONITOR - EXECUTIVE 23 of 28 EISNER::KENNEDY "Terry Kennedy" 22 lines 17-DEC-1988 21:39 -< Three cheers for the RSTS/E development group >- -------------------------------------------------------------------------------- Note 6.15 MONITOR - EXECUTIVE 15 of 20 EISNER::CONROY "Alan Conroy" 17 lines 14-SEP-1988 12:32 -< Three cheers for the RSTS/E development group >- -------------------------------------------------------------------------------- > I think DEC will probably react to these changes in a while. Meanwhile, I hope so. We have DECNET, but it's only on our VAXs. The PDPs are almost exclusively used for timesharing and there is no need to connect them to the VAXs, or to each other. We currently use DMGNET to allow our terminals to get access to those systems without a proliferation of switchboxes and cables (We do have a couple reverse-LAT lines). Since most people are on servers it would be really nice if we could use them to connect to the PDPs... > However, I *do* think we should thank DEC *strongly* for putting in the > effort to give us LAT. Don't get me wrong, I DO applaud their efforts. I only wish (for the reasons stated above) that DECNET wasn't a required part of the picture. I am always a little worried that DEC will someday disband the RSTS/E development group or reduce it to maintenance only, so the last thing I want to do is show a lack of appreciation for new functionality! ================================================================================ Note 24.24 [RSTS]MONITOR - EXECUTIVE 24 of 28 EISNER::KENNEDY "Terry Kennedy" 19 lines 17-DEC-1988 21:40 -< Under construction... >- -------------------------------------------------------------------------------- Note 6.16 MONITOR - EXECUTIVE 16 of 20 EISNER::KENNEDY "Terry Kennedy" 14 lines 23-SEP-1988 04:18 -< Under construction... >- -------------------------------------------------------------------------------- I've been digging in the 9.6 tape (arrived yesterday) to look into this. Currently I've been able to fake the monitor into loading that LAT code at system startup, but doing a $SET NODE/LAT/ENABLE=(0)/ID="Just testing" gives me a '??DECnet/E not started' error. The $LATMGR program is doing a SYS(CHR$(6%)+CHR$(22%)+CHR$(-12%)...), which is an undocumented SYScall. I think it is used to talk NML to the DECnet/E monitor-mode code, and I'm relatively sure the target of this send/receive is in the monitor. So, I've got two possibilities: o Create my own NSP receiver and fake the responses o Find out the SYScalls for NCP SET SYSTEM and NCP SET EXEC STATE ON Possibly tomorrow... ================================================================================ Note 24.25 [RSTS]MONITOR - EXECUTIVE 25 of 28 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 21:40 -< Ladies and Gentlemen, a big round of applause... >- -------------------------------------------------------------------------------- Note 6.17 MONITOR - EXECUTIVE 17 of 20 EISNER::CONROY "Alan Conroy" 3 lines 23-SEP-1988 10:58 -< Ladies and Gentlemen, a big round of applause... >- -------------------------------------------------------------------------------- Thanks for the hard work, Terry. I'm sure there are a lot of us who appreciate it (at least I do). If I ever get 9.6 installed, maybe I can contribute. :-) ================================================================================ Note 24.26 [RSTS]MONITOR - EXECUTIVE 26 of 28 EISNER::KENNEDY "Terry Kennedy" 7 lines 17-DEC-1988 21:40 -< It's not done yet... >- -------------------------------------------------------------------------------- Note 6.18 MONITOR - EXECUTIVE 18 of 20 EISNER::KENNEDY "Terry Kennedy" 2 lines 23-SEP-1988 19:51 -< It's not done yet... >- -------------------------------------------------------------------------------- -< Ladies and Gentlemen, a big round of applause... >- ================================================================================ Note 24.27 [RSTS]MONITOR - EXECUTIVE 27 of 28 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 21:40 -< LAT has been SPRed >- -------------------------------------------------------------------------------- Note 6.19 MONITOR - EXECUTIVE 19 of 20 EISNER::CONROY "Alan Conroy" 7 lines 26-SEP-1988 12:15 -< LAT has been SPRed >- -------------------------------------------------------------------------------- Incidentally, I have sent a SPR (Suggestion mode) to DEC, the text of which states: "Please allow use of LAT without DECNET, or else supply enough of DECNET to everyone to make LAT work." I might suggest that everyone do the same. The squeaky wheel... ================================================================================ Note 24.28 [RSTS]MONITOR - EXECUTIVE 28 of 28 EISNER::KENNEDY "Terry Kennedy" 16 lines 17-DEC-1988 21:40 -< SPR response (abbreviated) >- -------------------------------------------------------------------------------- Note 6.20 MONITOR - EXECUTIVE 20 of 20 EISNER::CONROY "Alan Conroy" 11 lines 10-NOV-1988 11:57 -< SPR response (abbreviated) >- -------------------------------------------------------------------------------- DEC's repsonse to my SPR: Thank you for your SPR. DECnet is required in order to use LAT because DECnet provides the necessary diagnostic tools required to diagnose problems that may occur. This is consistent with other PDP-11 systems that offer LAT. We will consider allowing LAT use without the need to purchase DECnet in some future release of RSTS.  ================================================================================ Note 25.0 [RSTS]MONITOR - TERMINAL SERVICE 32 replies EISNER::KILLEEN 3 lines 25-JUN-1987 21:07 -------------------------------------------------------------------------------- This topic is to be used to discuss the Terminal Service section of the monitor. Anything that relates to Terminal I/O or Terminal control. ================================================================================ Note 25.1 [RSTS]MONITOR - TERMINAL SERVICE 1 of 32 EISNER::LEFEBVRE "Kenneth LeFebvre" 8 lines 15-JUL-1987 08:50 -< Autobaud >- -------------------------------------------------------------------------------- I have always assumed that AutoBaud meant that I would never have to manually set the baud-rate of my terminals again. However, the other day, when I tried to log in at 2400 baud rather than 9600 baud, it didn't work. I had to raise the terminal's baud rate to 9600 again before I could get in. That doesn't seem to be very different from having my terminal port set to NoAutobaud, Speed=9600. What did I do wrong, or do I misunderstand the use of Autobaud? ================================================================================ Note 25.2 [RSTS]MONITOR - TERMINAL SERVICE 2 of 32 EISNER::HORN "Larry Horn" 5 lines 15-JUL-1987 14:55 -< more info? >- -------------------------------------------------------------------------------- Which version of RSTS? There were several problems with autobaud which were fixed along the way from 9.0 to 9.3. Most of my lines are not autobaud, but I've not noticed any problems under 9.3. ================================================================================ Note 25.3 [RSTS]MONITOR - TERMINAL SERVICE 3 of 32 EISNER::KENNEDY "Terry Kennedy" 19 lines 16-JUL-1987 02:25 -< More autobaud suggestions >- -------------------------------------------------------------------------------- Autobaud was fixed in 9.2. However, there is one remaining bug if you have DHV11 (and maybe other DH models as well). If you have modem control enabled, and start pounding CR right away, you may get a wedged interface and have to hang up and try again. Also, the autobaud code is sometimes sensitive to the data bits/parity setup of your terminal. Also, if you have a program (like DISPLY) which grabs the terminal when logged-out, the characteristics may not be reset (because a job has the device allocated). Make sure you have the /PERM qualifier on the /AUTOBAUD line, as: $ SET TERM/PERM/AUTOBAUD KB10: Lastly, if you don't successfully autobaud, wait 5 seconds and try again before pressing more RETURNs. The driver has a 3-second timeout and after that, it starts guessing anew. If you still have problems after this, leave me a MAIL message and I can discuss these issues in more detail off-line. terry ================================================================================ Note 25.4 [RSTS]MONITOR - TERMINAL SERVICE 4 of 32 EISNER::LEFEBVRE "Kenneth LeFebvre" 11 lines 25-JUL-1987 20:14 -< My RSTS Version >- -------------------------------------------------------------------------------- >> Which version of RSTS? There were several problems with autobaud >> which were fixed along the way from 9.0 to 9.3. I am currently running Micro/RSTS V2.0. I have also added many of the development-type tools from a full RSTS/E V9.0 distribution. I believe that Micro/RSTS V2.0 is actually a subset of RSTS/E V9.1. We have in our store-room a RSTS/E V9.3 tape that just came in, but my boss is trying to get it exchanged for V9.4 since it was shipped AFTER V9.4 was announced. ================================================================================ Note 25.5 [RSTS]MONITOR - TERMINAL SERVICE 5 of 32 EISNER::LEFEBVRE "Kenneth LeFebvre" 4 lines 25-JUL-1987 20:17 -< I also have DHV >- -------------------------------------------------------------------------------- I also have a DHV on my system... Apparently my combination of V9.1 and DHV isn't very good for autobauding, huh? Should I know anything about my DHV when I upgrade to V9.3 or 9.4? ================================================================================ Note 25.6 [RSTS]MONITOR - TERMINAL SERVICE 6 of 32 EISNER::KENNEDY "Terry Kennedy" 5 lines 25-JUL-1987 22:38 -< Try it - it should work >- -------------------------------------------------------------------------------- > Should I know anything about my DHV when I upgrade to V9.3 or 9.4? Not really. If is doesn't work and you've followed my suggestions in .3, let's bring up the topic again. terry ================================================================================ Note 25.7 [RSTS]MONITOR - TERMINAL SERVICE 7 of 32 EISNER::MCALLISTER "Brian McAllister" 23 lines 26-FEB-1988 22:04 -< remove/job doesn't hang up dialup line? >- -------------------------------------------------------------------------------- I think I may have discovered a bug in V9.5 . We have all the ports on our 11/44 connected to an Equinox DataSwitch, configured as "dialup". The problem is that if I kill a job with the "remove/job" command, RSTS does not drop the control signals for the associated keyboard, and the DataSwitch does not break its connection. If the job is logged out normally, everything works as expected. I am reasonably sure that this did not happen with V9.2 . (I went straight from 9.2 to 9.5). I can't be certain, but I know that I killed jobs this way, and I am fairly sure that they disconnected properly. I don't feel like re-installing 9.2 to make sure. Has anyone encountered this behavior? Is it new with 9.5, or was it in earlier versions? {By the way, if this is how it is SUPPOSED to work, let me know.} Also, does anyone use DZQ11's as dialups under V9, and did you have any problems? (I did, but they work fine with V8). ================================================================================ Note 25.8 [RSTS]MONITOR - TERMINAL SERVICE 8 of 32 EISNER::KENNEDY "Terry Kennedy" 30 lines 26-FEB-1988 23:38 -< It's documented >- -------------------------------------------------------------------------------- > Has anyone encountered this behavior? Is it new with 9.5, > or was it in earlier versions? > {By the way, if this is how it is SUPPOSED to work, let me know.} From the "RSTS/E Release Notes", AA-KW28A-TC, Pg. 47: "4.6.3 LOGIN.TSK and LOGOUT.TSK The LOGIN and LOGOUT programs control when to drop the carrier on a dial-up line. If you access the system from a captive account over a dial-up line and the command procedure you are running aborts abnormally, the carrier will not be dropped. A workaround to this problem is to trap all possible errors within the command procedure and exit by using the LOGOUT command." Having parroted that, let me add that we run a 256 terminal x 128 port Gandalf data switch. It is strapped for a 10-minute inactivity timeout, after which it simulates a modem hanging up. This successfully convinces RSTS to 'let go' of the line and frees it up for the next user. In the meanwhile, the Gandalf holds it 'busy' so no-one gets dead air. > Also, does anyone use DZQ11's as dialups under V9, and did you > have any problems? (I did, but they work fine with V8). Not DZQ11's, but I have used DZV11's and DHV11's - I had to tie pin 4 to pin 5 in the modem cable in order to have reliable connections. The symptom seemed to be that autobaud would fail if you pressed RETURN right after connecting. If you waited 4 seconds or more, things would be fine. Does this help? ================================================================================ Note 25.9 [RSTS]MONITOR - TERMINAL SERVICE 9 of 32 EISNER::MCALLISTER "Brian McAllister" 43 lines 29-FEB-1988 13:10 -< OK, will use LOGOUT, not REMOVE >- -------------------------------------------------------------------------------- >>From the "RSTS/E Release Notes", AA-KW28A-TC, Pg. 47: >> >>"4.6.3 LOGIN.TSK and LOGOUT.TSK >> >>The LOGIN and LOGOUT programs control when to drop the carrier on >>a dial-up line. This restriction was first mentioned in the 9.3 release notes. I realized that most of the jobs I killed were already hibernating (=disconnected), so it probably worked this way with 9.2 also. >>Having parroted that, let me add that we run a 256 terminal x 128 >>port Gandalf data switch. It is strapped for a 10-minute inactivity >>timeout, after which it simulates a modem hanging up. This successfully >>convinces RSTS to 'let go' of the line and frees it up for the next >>user. In the meanwhile, the Gandalf holds it 'busy' so no-one gets >>dead air. The Equinox switch has the same features, and I use them on most of our lines. There is a set of ports, however, that are reserved for the use of our software development people (and myself), that do not have a timeout. I still want them to disconnect if the job is killed. I guess I will have to remember to force a LOGOUT, instead of just REMOVing them. >> > Also, does anyone use DZQ11's as dialups under V9, and did you >> > have any problems? (I did, but they work fine with V8). >> Not DZQ11's, but I have used DZV11's and DHV11's - I had to tie pin >> 4 to pin 5 in the modem cable in order to have reliable connections. >> The symptom seemed to be that autobaud would fail if you pressed >> RETURN right after connecting. If you waited 4 seconds or more, things >> would be fine. Does this help? My problem had to do with losing the connection after it was established. I would connect, the autobaud would work, I would log in, and ~30 sec-1 min later, something would cause the modem control signals on the port to go away, and our dataswitch would break the connection. Doesn't seem to be the dataswitch (I tried several ports), but it could be the DZQ11. I haven't had the chance to try another one. It may be that your fix would solve this problem. (But why??) ================================================================================ Note 25.10 [RSTS]MONITOR - TERMINAL SERVICE 10 of 32 EISNER::KENNEDY "Terry Kennedy" 31 lines 1-MAR-1988 03:45 -------------------------------------------------------------------------------- > My problem had to do with losing the connection after it was > established. I would connect, the autobaud would work, I > would log in, and ~30 sec-1 min later, something would cause > the modem control signals on the port to go away, and our > dataswitch would break the connection. Doesn't seem to be > the dataswitch (I tried several ports), but it could be the > DZQ11. I haven't had the chance to try another one. It may > be that your fix would solve this problem. (But why??) Two possibilities - first, somthing "inside" the system (not LOGIN itself) runs a timer for the modem control lines - I think it may be the part of the monitor that spawns LOGIN. If, for example, you ^C LOGIN, some time later the system will hang up on you, even though LOGIN isn't running any more. This code looks for (I think) a job # associated with the port to make the decision - might be broken, but then all interface types should have problems... Second, the 4-5 jumper cures the problem of the fancier interface cards wanting to see signals the old (Unibus) DZ11's didn't look at. 4-5 returns 'I'm ok' when the interface goes 'you ok?'. Obvious- ly, we need to establish communication before all signals are set (example: answer phone before carrier detect). Therefore, the timer mentioned above may force the 4-5 signal to be ignored until it expires, which could cause your problem. Also, these 'intelligent' terminal interfaces make assumptions about how long a modem will take from DTR high (to answer the phone) to CD high (modem detected carrier). Data switches generally toss all these assumptions out the window - the protocol is nearly in- stantaneous. An early DHV11 I had actually *crashed* when hooked up to the data switch - I had to have it upgraded. ================================================================================ Note 25.11 [RSTS]MONITOR - TERMINAL SERVICE 11 of 32 EISNER::MCALLISTER "Brian McAllister" 16 lines 10-MAY-1988 19:31 -< How can you do true 8-bit input? >- -------------------------------------------------------------------------------- I have a question for you RSTS wizards. A friend of mine is attempting to do 8-bit terminal input under V9.5. He is trying to get control characters in (including XON/XOFF) without having RSTS pay attention to them. We tried setting the eighth bit, but this doesn't seem to do the trick. The only way he can make it work is by using binary mode. He has tried this from both PASCAL and BASIC+, with both DZQs and DHVs. I believe that his system is not genned for multiple private delimiters, but that shouldn't be a problem here. Is there some simple way to do this? Brian ================================================================================ Note 25.12 [RSTS]MONITOR - TERMINAL SERVICE 12 of 32 EISNER::KENNEDY "Terry Kennedy" 10 lines 10-MAY-1988 23:26 -< Binary mode! >- -------------------------------------------------------------------------------- > A friend of mine is attempting to do 8-bit terminal input... That is what binary mode is for! Setting a port /Eightbit just im- plies that the (terminal, whatever) connected to it generates and accepts DEC's multinational characters. You still have to turn off XON/XOFF, ^C/R/T/U/X processing as well. Binary mode bypasses all of this stuff without you having to worry about it. Multiple private delimiters help because a timeout in binary mode clears it. By the way, according to the 9.5 release notes, MulPriDel will be required in all future RSTS versions... ================================================================================ Note 25.13 [RSTS]MONITOR - TERMINAL SERVICE 13 of 32 EISNER::KILLEEN "Jeff Killeen" 26 lines 11-MAY-1988 00:26 -< BASIC IS THE LANGUAGE OF CHOICE FOR SYSTEM PROGRAMMING >- -------------------------------------------------------------------------------- > trick. The only way he can make it work is by using binary mode. > He has tried this from both PASCAL and BASIC+, with both DZQs and > DHVs. I believe that his system is not genned for multiple private > delimiters, but that shouldn't be a problem here. The only way I know to do this is with binary input mode. Once you open a terminal in binary mode the standard system delimiters no longer have any effect. There are two approaches you can use here. 1. Use get and put statements with recount..... OPEN "KB27:/MODE:1" AS FILE 1% GET#1% Z%=RECOUNT FIELD#1%, Z% AS INPUT.DATA$ The data will come in a few chars at a time - input data will contain whatever data was available at the time of the GET 2. The other approach is to re-sysgen with private delimiters Do a $SET TERM/DELIMITER=xx/PERM (xx equals the ASCII value of delim) Then use the same code as above - the gets will return data when a delimiter is "typed" as opposed to every few chars. ================================================================================ Note 25.14 [RSTS]MONITOR - TERMINAL SERVICE 14 of 32 EISNER::MCALLISTER "Brian McAllister" 16 lines 12-MAY-1988 11:38 -< OK, but why does it only look at 7 bits? >- -------------------------------------------------------------------------------- I do understand that this is what binary mode is for. We were trying to avoid it by setting bit 8 on the control characters. My question is really: why doesn't that work? According to the VT220 Programmer Guide, an XON (hex 11) with the eighth bit turned on (hex 91) is "PU1". To all appearances, unless binary mode is used, RSTS only looks at the low-order 7 bits, sees an XON, and swallows the character so it never gets to the program. Why does it do this? (BTW: What is PU1?). I don't think that using binary mode is a problem, it's just that we don't understand why it behaves this way. Thanks. ================================================================================ Note 25.15 [RSTS]MONITOR - TERMINAL SERVICE 15 of 32 EISNER::MCALLISTER "Brian McAllister" 12 lines 12-MAY-1988 17:45 -< Why binary mode not desired >- -------------------------------------------------------------------------------- Just a note to further clarify things: The reason that we would like to avoid binary mode is that it is desired to KEEP XON/XOFF control, so as not to lose data. The latest report is that everything seems to work except ESCAPE. Do you know any way to get an escape (or some- thing like an escape with extra bits) past the terminal driver? Brian ================================================================================ Note 25.16 [RSTS]MONITOR - TERMINAL SERVICE 16 of 32 EISNER::KILLEEN "Jeff Killeen" 1 line 12-MAY-1988 17:54 -< TRY OPENING THE TERMINAL IN MODE 16384 >- -------------------------------------------------------------------------------- Check page 4-33 of the programming maunual ================================================================================ Note 25.17 [RSTS]MONITOR - TERMINAL SERVICE 17 of 32 EISNER::MCALLISTER "Brian McAllister" 13 lines 16-MAY-1988 12:59 -< Mode 16384 is for OUTPUT >- -------------------------------------------------------------------------------- >> -< TRY OPENING THE TERMINAL IN MODE 16384 >- >> >>Check page 4-33 of the programming maunual Mode 16384 is for Transparent Control Character OUTPUT. There does not appear to be an equivalent for INPUT. On the other hand, page 4-21 implies that you can have XON/XOFF processing while the terminal is in binary mode. Does anyone have experience with this? Brian ================================================================================ Note 25.18 [RSTS]MONITOR - TERMINAL SERVICE 18 of 32 EISNER::KILLEEN "Jeff Killeen" 2 lines 16-MAY-1988 18:29 -< NO PROBLEM >- -------------------------------------------------------------------------------- I use binary mode with XON/XOFF all the time. Just open the terminal with both the binary mode and *AND* the XON/XOFF bits set. ================================================================================ Note 25.19 [RSTS]MONITOR - TERMINAL SERVICE 19 of 32 EISNER::HORN "Larry Horn, Millsaps College" 69 lines 29-JUN-1988 02:35 -< how PK's affect KB numbering sequence >- -------------------------------------------------------------------------------- This is a COPY of 41.* (which has been set NOWRITE): <<< EISNER::DUA0:[NOTES$LIBRARY]RSTS_OS.NOTE;1 >>> -< RSTS OPERATING SYSTEM >- ================================================================================ Note 41.0 An old timer's question... 3 replies EISNER::SCOPELLITI "Pat 'Enzo' Scopelliti" 12 lines 24-JUN-1988 00:22 -------------------------------------------------------------------------------- Here's a question from a former RSTS manager (does V5B-24 count as old?). I'm now in VAX land - but... has RSTS every changed the way pseudo keyboards were inserted into the KB numbering sequence? i.e. If you genned 4, your first KB was KB5. I was at a RSTS feedback session where this was asked for, and the response was "We'd like to move the PK defintions, but there's a comment in the code saying 'Whatever you do, don't move these!' We don't know who wrote it or why, but no one's had the guts to move it." Well.. has anyone had the guts? ================================================================================ Note 41.1 An old timer's question... 1 of 3 EISNER::KENNEDY "Terry Kennedy" 22 lines 24-JUN-1988 02:44 -< Possible but not pretty >- -------------------------------------------------------------------------------- > I'm now in VAX land - but... has RSTS every changed the way pseudo > keyboards were inserted into the KB numbering sequence? Well, in Cinci when DEC discussed LAT and other new features for the (forthcoming) RSTS V9.6, it was mentioned that PK's are now dynamic and map in after your real KB's. Of course, you can still gen static PK's if your application needs them. But more to the point, why do you want to move them? You could always open them independent of KB number by opening 'PKxx'. Also, RSTS since V9 has had 'controller' syntax, sort of like VMS, in that PK's are KBDxx, DZ's are KBGxx, DHV's are KBHxx, etc. Anyway, if you are bound and determined you will need the source kit, and it *is* possible. In short, you need to modify the references in TBL, add a new table to handle .FSSing the controller syntax into the new order while preserving the old controller syntax letters, modify INIT to change the jam list order, etc. In other words, it's possible but it isn't pretty. And remember, DL's must be first because KB0 is a 'sacred' device name. If you want more info, drop me a Mail message (SEND/AUTHOR here). ================================================================================ Note 41.2 An old timer's question... 2 of 3 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 24-JUN-1988 08:12 -< WHY DO YOU WANT TO MOVE THEM? >- -------------------------------------------------------------------------------- ================================================================================ Note 41.3 An old timer's question... 3 of 3 EISNER::SCOPELLITI "Pat 'Enzo' Scopelliti" 6 lines 28-JUN-1988 23:29 -< A slight mis-interpretation. >- -------------------------------------------------------------------------------- Thanks for the info.... The last that I touched RSTS/E was V7.2 (sigh!) At the time we had the problem that changing the number of PKs changed the first real KB number (besides KB0). So, if you had programs that were KB specific, you had a problem. Like I said... just a question from a FORMER RSTS manager. ================================================================================ Note 25.20 [RSTS]MONITOR - TERMINAL SERVICE 20 of 32 EISNER::MCALLISTER "Brian McAllister" 19 lines 13-JUL-1988 14:04 -< Does RSTS support DHQ11 in DHU11 mode? >- -------------------------------------------------------------------------------- I am looking for help on using DHQ11 muxes with RSTS V9.5 . This board is supposed to be able to emulate either a DHV11 or a DHU11. There is a switch on the board to set the config- uration, but all it really seems to do is set a register bit so software can figure out which it is. Unfortunately, even with it set to DHU11 emulation, RSTS still treats it as a DHV11. We really need to use the interrupt-timer feature of the DHU mode (system idle time goes from ~2% to ~30%). If we go into ODT and poke the timer register by hand, we can get it to work, but we need a turnkey implementation. Is there any way to get RSTS to handle this right, or does it just refuse to believe that you can have a DHU11 on a Q-bus? Any suggestions? Brian ================================================================================ Note 25.21 [RSTS]MONITOR - TERMINAL SERVICE 21 of 32 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 13-JUL-1988 20:59 -< THE DHQ11 IS ONLY SUPPORTED IN DHV11 MODE >- -------------------------------------------------------------------------------- ================================================================================ Note 25.22 [RSTS]MONITOR - TERMINAL SERVICE 22 of 32 EISNER::MCALLISTER "Brian McAllister" 12 lines 14-JUL-1988 14:41 -< Unfortunate. When will full support happen? >- -------------------------------------------------------------------------------- >>> -< THE DHQ11 IS ONLY SUPPORTED IN DHV11 MODE >- Where is this documented, and is there any intention of providing support for the DHU11 mode? BTW: If you want to set the interrupt/timing stuff "by hand", you do get the desired result. That is, all the necessary support is in the driver, you just have to enable it on the board. We are going to see if this can be done successfully after RSTS is already up and running. ================================================================================ Note 25.23 [RSTS]MONITOR - TERMINAL SERVICE 23 of 32 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 6 lines 14-JUL-1988 15:47 -< COLD FEET >- -------------------------------------------------------------------------------- > -< Unfortunate. When will full support happen? >- When the infernal regions become frosty P.S. what does DHU over DHV emulation buy you? ================================================================================ Note 25.24 [RSTS]MONITOR - TERMINAL SERVICE 24 of 32 EISNER::MCALLISTER "Brian McAllister" 31 lines 14-JUL-1988 18:40 -< DHU is much more efficient for large input >- -------------------------------------------------------------------------------- >>> What does DHU over DHV emulation buy you? The DHU11 has an interrupt timer capability. I am not familiar with all the details, but it allows you to set the device so that it does not interrupt on every received character. It allows the on-board FIFO silo to fill to a specified level or until a timer expires, and then interrupts. If you are receiving large amounts of data, on a fairly continuous basis, this reduces system overhead by a very significant amount. Even better would be DMA in (equivalent to the existing DMA out), but nobody makes that yet (or software to support it). In the application in question, on average, we are transmitting ~75 char/sec, and receiving ~325 char/sec. In our tests, with the interrupt timer enabled, a system under heavy I/O load went from <5% idle to ~30% idle. I was under the impression that RSTS would use this feature of a real DHU11, as it is mentioned in the V9.0 release notes. Since a DHQ11 in DHU11 mode should be equivalent, and the driver supports the DHU11, the only problem seems to be that the system initialization code doesn't enable the timer. As I mentioned in a previous note we should be able to write a program to do this during system startup. BTW: Our tests also told us that we get more throughput using DZQ11s that an equivalent number of DHV11s, perhaps because there is less actual multiplexing going on and because we don't have lots of output (where the DMA on the DHV would help). ================================================================================ Note 25.25 [RSTS]MONITOR - TERMINAL SERVICE 25 of 32 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 14-JUL-1988 20:58 -< I WILL PASS THIS ON TO SIG PRODUCT PLANNING CHAIR >- -------------------------------------------------------------------------------- ================================================================================ Note 25.26 [RSTS]MONITOR - TERMINAL SERVICE 26 of 32 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 17 lines 19-NOV-1988 17:56 -< V9.6 TERMINAL SERVICE PROBLEMS >- -------------------------------------------------------------------------------- There are two problems with version 9.6 terminal service. 1. There is no way to tell RSTS how many lines you have active on a D??11 multiplexer. This means if you have some of the third party boards which report 16 sub lines when there is only 8 you have 8 new phantom terminal lines. 2. You can no longer reserve terminal number slots for communication boards you may add in the future. We use to pre-gen all of our RSTS versions with 4 DLV11's, 4 DZV11's, and 8 DHV11's. Then ship that version to 30 sites. Because most of these sites did not have all of those devices all of their terminal numbers will change under V9.6. Now you may say that won't effect me - question what will happen to terminal numbers if VH1 goes bad and you disable it and reboot? You got it while you are waiting for field service all of your terminals above VH1 will have their KB number shifted by 8. ================================================================================ Note 25.27 [RSTS]MONITOR - TERMINAL SERVICE 27 of 32 EISNER::KENNEDY "Terry Kennedy" 28 lines 19-NOV-1988 23:09 -< KB autoconfigure, comments >- -------------------------------------------------------------------------------- > 1. There is no way to tell RSTS how many lines you have active > on a D??11 multiplexer. This means if you have some of the third party > boards which report 16 sub lines when there is only 8 you have 8 new > phantom terminal lines. Well, that's the famous *emulation problem*. Many of the 3rd-party DH emulators got away with an imperfect emulation because they 'knew' that DEC would 'never' have anything but an 8-line Q-Bus DH. When DEC came out with a different board, their emulations broke. That is what happens when you design a clone solely by testing with one version of the software, rather than reading the manual. I had one of these, where any access to the eight 'phantom' lines would crash the system. > Now you may say that won't effect me - question what will happen to > terminal numbers if VH1 goes bad and you disable it and reboot? You got > it while you are waiting for field service all of your terminals above > VH1 will have their KB number shifted by 8. o If a board fails completely enough that it will not respond to INIT's poke routine, INIT won't see any boards at higher float- ing addresses anyway. So, all higher numbered devices will be disabled anyway. o Your biggest problem will be in adding LAT users, since there is no permanent linkage between the terminal location and the KB number. ================================================================================ Note 25.28 [RSTS]MONITOR - TERMINAL SERVICE 28 of 32 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 9 lines 19-NOV-1988 23:14 -< IT REALLY HAPPENS TO US >- -------------------------------------------------------------------------------- > o If a board fails completely enough that it will not respond to > INIT's poke routine, INIT won't see any boards at higher float- > ing addresses anyway. So, all higher numbered devices will be > disabled anyway. Out of the 75 Qbus systems we support we have 2 to 3 board fail to this level each year. You can return the higher numbered devices by using HA CSR option. This is not a theoretical discussion for us it happens. ================================================================================ Note 25.29 [RSTS]MONITOR - TERMINAL SERVICE 29 of 32 EISNER::CONROY "Alan Conroy" 13 lines 21-NOV-1988 13:05 -< It may be worse than you think >- -------------------------------------------------------------------------------- The strange problem I mentioned in this conference about trap to 4 during startup went away when our DHV11 (Emulex emulation) was removed. Actually, it wasn't removed - we had replaced a bad board and maintenance didn't configure the switches properly so INIT never saw it. We started up fine (forgetting to check the HA LI first). When we took the machine back down and configured the DHV properly then the problem reappeared (worse than before even). We also have been logging a lot of KB errors for no apparent reason. Oh yes - this strange problem did not appear on our UNIBUS PDP-11/44, which also had Emulex controllers. It might just be coincidence that others are having DHV11 problems with V9.6 and we might have a hardware problem. On the other hand... I'd be curious to hear from anyone else who has a Q-bus system on V9.6 with Emulex boards - especially if they are NOT having any problems. ================================================================================ Note 25.30 [RSTS]MONITOR - TERMINAL SERVICE 30 of 32 EISNER::CONROY "Alan Conroy" 9 lines 5-DEC-1988 14:05 -< V9.6 has DHV11 problems >- -------------------------------------------------------------------------------- Well, we dropped back to 9.5 on the 11/73 that was having problems and guess what? That's right - the problem vanished. Then I installed 9.6 on our 11/70 and - no problems. We also had no problems on our 11/44. All of these systems had Emulex terminals controllers. The evidence is pretty strong that V9.6 has problems with third-party DHx11 controllers. Besides the trap to 4 during startup, the lines would just go dead randomly if there was a lot of noise on them. NOTHING would clear this problem short of a reboot (sounds like problems from a couple versions ago, no?) I'm SPRing DEC on this. ================================================================================ Note 25.31 [RSTS]MONITOR - TERMINAL SERVICE 31 of 32 EISNER::CONROY "Alan Conroy" 6 lines 25-FEB-1989 03:45 -< V9.6/CS02 problem solved >- -------------------------------------------------------------------------------- After several weeks of phone calls, faxes, and mail back and forth between DEC and yours truely the following has been discovered: RSTS/E V9.6 requires Rev. M (or later) PROMS for Emulex CS02 (DHV11 emulation). Rev K is definitely out, Rev L is unknown (it may or may not work). When the CS02 was upgraded, the trap-to-4 problem went away. ================================================================================ Note 25.32 [RSTS]MONITOR - TERMINAL SERVICE 32 of 32 EISNER::KENNEDY "Terry Kennedy" 9 lines 25-FEB-1989 05:19 -< More notes on terminal interfaces and INIT >- -------------------------------------------------------------------------------- > When the CS02 was upgraded, the trap-to-4 problem went away. Also, for those who have *lots* of terminal interfaces (DEC does not define 'lots'), you may need a patch to INIT.SYS, published in the latest RSTS Dispatch. Unfortunately, this patch cannot co-exist with the INIT patch for memory fragmentation. A correction is expected in a subsequent Dis- patch.  ================================================================================ Note 26.0 [RSTS]MONITOR - INSTALLATION 4 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:09 -------------------------------------------------------------------------------- This topic is to be used to discuss the installation of the RSTS monitor. Issues related to the sysgen installation or update process. ================================================================================ Note 26.1 [RSTS]MONITOR - INSTALLATION 1 of 4 EISNER::KENNEDY "Terry Kennedy" 21 lines 17-DEC-1988 21:54 -< Hooks for user .COMS >- -------------------------------------------------------------------------------- Note 8.1 MONITOR - INSTALLATION 1 of 3 EISNER::KENNEDY "Terry Kennedy" 16 lines 2-JUL-1987 19:44 -< Hooks for user .COMS >- -------------------------------------------------------------------------------- Every time I put up a release, I find myself making the same old patches (manually, of course). It sure would be nice if [0,1]INSTAL.COM invoked a user-supplied .COM file with the names of the products being installed/ updated so this could be automated. The change to do this is trivial, and I have actually done it. However, since it is a change to INSTAL, each RSTS update wipes out my version. ------------------------------------------------------------------------- Likewise, it would be handy if INSTAL executed a user-supplied .COM file to re-assign system logicals. Right now you have to say 'NO' to the pro- ceed? question and then execute your .COM. Have you ever tried to update a RSTS system with system programs=all on a system w/ 4 RL02's? Likewise, trivial to implement. ================================================================================ Note 26.2 [RSTS]MONITOR - INSTALLATION 2 of 4 EISNER::KENNEDY "Terry Kennedy" 15 lines 17-DEC-1988 21:54 -< UPDATES WHERE LIB'S ARE NOT ON THE TARGET DISK >- -------------------------------------------------------------------------------- Note 8.2 MONITOR - INSTALLATION 2 of 3 EISNER::KILLEEN 10 lines 2-JUL-1987 20:45 -< UPDATES WHERE LIB'S ARE NOT ON THE TARGET DISK >- -------------------------------------------------------------------------------- >>> Likewise, it would be handy if INSTAL executed a user-supplied .COM file >>> to re-assign system logicals. Right now you have to say 'NO' to the pro- >>> ceed? question and then execute your .COM. Have you ever tried to update >>> a RSTS system with system programs=all on a system w/ 4 RL02's? 10 of ours sites have CDC 9715-500's we map as 6 RM03's. We put the 0,* accounts on DR5:. We find updates a pain also because of this. Your solution is a good one! ================================================================================ Note 26.3 [RSTS]MONITOR - INSTALLATION 3 of 4 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 21:55 -< But will DEC do it for us? >- -------------------------------------------------------------------------------- Note 8.3 MONITOR - INSTALLATION 3 of 3 EISNER::KENNEDY "Terry Kennedy" 8 lines 3-JUL-1987 20:53 -< But will DEC do it for us? >- -------------------------------------------------------------------------------- >>> Likewise, it would be handy if INSTAL executed a user-supplied .COM file >>> to re-assign system logicals. Right now you have to say 'NO' to the pro- >>> ceed? question and then execute your .COM. Have you ever tried to update >>> a RSTS system with system programs=all on a system w/ 4 RL02's? But, it would be so much nicer if DEC gave us these hooks, so we don't have to hack up INSTAL.COM each and every time... tmk ================================================================================ Note 26.4 [RSTS]MONITOR - INSTALLATION 4 of 4 EISNER::KENNEDY "Terry Kennedy" 19 lines 2-SEP-1989 23:16 -< V9.7 install broken for packages not on SY0: >- -------------------------------------------------------------------------------- A warning if you're installing V9.7 and have moved any of the system logicals to another disk. V9.0-9.6 allowed you to say no at the "are you ready to proceed?' question, reassign your logicals, and then PROCEED. That doesn't work in V9.7 - even though it says it assigned logicals before you reassigned them, it ignores yours and uses the ones it set up. You will have to move each one back to the system disk, update it and move it back out. DEC wasted (my opinion) a *lot* of development time giving us a new video-mode install/update (complete with bugs) which is used exactly *one* per update. *WHY* couldn't they have spent that time on fixing *any* of the long-term "restriction" bugs, such as: o RT11 tape support o SET HOST failings o DR/DB disk error logging o  ================================================================================ Note 27.0 [RSTS]MONITOR - RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 21:39 -------------------------------------------------------------------------------- This topic is reserved for future monitor topics  ================================================================================ Note 28.0 [RSTS]MONITOR - OTHER 8 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:41 -------------------------------------------------------------------------------- This topic is to be used for other monitor issues. Issues other than INIT.SYS, Executive, Terminal Service, or Installation issues. ================================================================================ Note 28.1 [RSTS]MONITOR - OTHER 1 of 8 EISNER::KILLEEN "Jeff Killeen" 17 lines 30-JUL-1987 08:58 -< BYE BYE TU56,RP11,ECT.... >- -------------------------------------------------------------------------------- The following devices will no longer be supported by RSTS after December 1988. RPR02 RP03 TU56 PC11 ALL CARD READERS DJ11 ALL TERMINALS WITH 5 AND 6 BIT CHARACTER LENGTHS The following software will no longer be supported by RSTS after December 1988. SAVRES - IMAGE BACKUP IS COMMING FLINT ================================================================================ Note 28.2 [RSTS]MONITOR - OTHER 2 of 8 EISNER::LEFEBVRE "Kenneth LeFebvre" 11 lines 14-OCT-1987 13:02 -< How does EMT Logging Work? >- -------------------------------------------------------------------------------- I just recently performed a new Sysgen for a Version 9 RSTS. Mostly for the fun of it, I genned in EMT logging. I though I would run the unsupported EMTCPY to see what would happen... Nothing happened! Have I misunderstood what EMT logging does? I was under the impression that, somehow, I could write a program to log various system operations. Does EMTCPY work? Does anybody use EMT logging? Thanks, Ken ================================================================================ Note 28.3 [RSTS]MONITOR - OTHER 3 of 8 EISNER::HORN "Larry Horn" 22 lines 15-OCT-1987 04:26 -< off by default >- -------------------------------------------------------------------------------- In addition to installing the support code in the monitor, you must 'turn on' logging for each system directive you'd like to have logged. By default, all logging is turned off. (I gen in the support, in case I ever want to use it, but normally leave it turned off. It's not supposed to cost any performance if it's not turned on. Lurkers -- if it does, let me know!) This is described in the Maintenance Notebook, Seq 3.5.1 F. A template ONLPAT command file is provided in UPDATE$:PA0305.001 that you may edit to turn on/off whichever directives you want. The selection can be done online, but requires a reboot to take effect. In addition, see Appendix G of the Programming Manual for a description of the EMT logging syscalls and messages. The sample program provided may be used as a guideline -- it's cute, put eats a lot of paper. I played with EMT logging when it was first available (V8 ??), but haven't had time to do anything serious with it. Just for fun, enable all logging (in the evening) to play with the sample program, but for 'real' use you'll probably want to just enable a few EMT's; otherwise you'll spend all your time processing EMT logs. ================================================================================ Note 28.4 [RSTS]MONITOR - OTHER 4 of 8 EISNER::LEFEBVRE "Kenneth LeFebvre" 51 lines 15-NOV-1987 13:55 -< My Boot isn't Working! >- -------------------------------------------------------------------------------- Here's a problem for you: I had Micro/RSTS V2.0 installed and running perfectly (well, as perfectly as you can get anything to run) on my Micro/PDP-11/73. The devices on that system were as follows: 1MB RAM DHV11 - 8 various terminals TQK50 RQC25 - 1 master unit RLV12 - 4 RL02 drives RQDX3 - RD53, RX50, RD54 Now, I am installing the very same Micro/RSTS V2.0 distribution on another RD53 for installation on a PDP-11/23+. Here is the configuration for the 23+: 2.5MB RAM DZV11 - 4 various terminals LPV11 RLV12 - 4 RL02 drives RQDX3 - RD53 RQC25 - 1 master unit I booted the RD53 with Micro/RSTS V2.0 several times on the 73 just fine. But when I take it to the 23+, it fails. Right after it says 36 devices disabled, it gives me an @ sign. One time, during my fooling around with it, I was able to get an error message from RSTS that said ?Can't find file or account and a long list of zeroes (apparently registers) with one register showing 00040 or something like that. Right underneath that I got what I assume was a corrupted RSX prompt RSTS> which accepted my input almost always giving me error messages such as ?Can't find file or account or ??Bad directory for device. When I tried to run anything I knew was in [1,2] I got a message saying the right resident library wasn't installed. However, I was able to RUN SHUTUP and go back to the option prompt. Every other time, though, I got the @ sign. Can anybody give me any insight? Have you ever experienced a similar situation? Is there something that RSTS is looking for in its processor that an 1//23+ doesn't have? (It does have the chip upgrade to support DECnet and boot the RC25 or RD53). I appreciate any and all help you might be able to offer. Thank you! Ken ================================================================================ Note 28.5 [RSTS]MONITOR - OTHER 5 of 8 EISNER::LEFEBVRE "Kenneth LeFebvre" 16 lines 15-NOV-1987 17:31 -< Module RSTS is missing a required symbol! >- -------------------------------------------------------------------------------- Here is another interesting clue I've found in my struggles to get Micro/RSTS V2.0 to run on this 11/24. When I boot using the full start option (typing out START), I get the following message Starting MICRO.SIL... -----> Module RSTS is missing a required symbol What is missing? It booted fine on an 11/73! There must be some hardware difference between an 11/24 and an 11/73 that RSTS doesn't like or that isn't genned into the canned Micro/RSTS system. If there is something else that should have been genned into this systm, why doesn't Digital say something about the requirement for certain machines? ================================================================================ Note 28.6 [RSTS]MONITOR - OTHER 6 of 8 EISNER::LEFEBVRE "Kenneth LeFebvre" 33 lines 21-NOV-1987 15:16 -< The mystery continues... >- -------------------------------------------------------------------------------- Just to update you a little on this problem... I've had Digital Field Service out here on and off for about a week now. Being very helpful and cooperative, my Field Service rep allowed me to talk directly with the Software people in Colorado (I think her thick Russian accent made the Software Support man a little more eager to talk with me and my non-accent!) Anyway, he said that RSTS V9.3 has a bug in the code for driving MSCP disk devices. The problem gets worse, he says, when there are two MSCP disks on the system. Interesting, but it wasn't our problem. I have been able to boot RSTS/E V9.3 on the RC25, but not the RD53. A possible root-problem is that whenever I am running timesharing (booted from the RC25 since I can't boot the RD53), SHOW DEVICES says that the RC25 and the RD53 have the VERY SAME address. In fact, they both have the non-standard address. That could be because the non-standard address is lower, but still RSTS should be able to see two controllers. I think the problem with the missing module was actually due to corrupted disk. When I took the very same RD53 back to my real system in Cleveland (I'm in Washington, D.C., now), it was all corrupted and no longer bootable or even readable. It seems that whatever is causing the problem is actually destroying our disks, too. Still looking for solutions... Ken ================================================================================ Note 28.7 [RSTS]MONITOR - OTHER 7 of 8 EISNER::KENNEDY "Terry Kennedy" 2 lines 21-NOV-1987 22:05 -< Let's work on it... >- -------------------------------------------------------------------------------- Ken - Give me a call again (you should have the numbers) and we'll ork on this some more... ================================================================================ Note 28.8 [RSTS]MONITOR - OTHER 8 of 8 EISNER::KENNEDY "Terry Kennedy" 12 lines 27-NOV-1987 18:57 -< LUNs may be the problem >- -------------------------------------------------------------------------------- Here is something you have to watch out for on 'low-end' MSCP disks: Each MSCP controller must have unique logical unit numbers assigned to it. All 'low-end' MSCP boards from DEC come with a LUN jumper area on them. The board at the primary CSR should be jumpered for LUNs 0-3 (usually no LUN jumper installed), and the board at the alternate CSR should be jumpered for LUNs 4-7. Otherwise, RSTS will see two boards (and two MSCP controllers), both of which think they are talking to a DU0: device. This wildl surely confuse things. 'Real' MSCP (RA-series) does unit select based on the plug on the disk drive itself, so that won't be an issue for RA-based systems.  ================================================================================ Note 29.0 [RSTS]CUSPS - EDITORS 2 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:43 -------------------------------------------------------------------------------- This topic is to be used for a discussion of the system editors. Issues related to TECO and EDT. ================================================================================ Note 29.1 [RSTS]CUSPS - EDITORS 1 of 2 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 21:59 -< EDT I4 vs. I 4 >- -------------------------------------------------------------------------------- Note 11.1 CUSPS - EDITORS 1 of 2 EISNER::KENNEDY "Terry Kennedy" 8 lines 2-JUL-1987 19:47 -< EDT I4 vs. I 4 >- -------------------------------------------------------------------------------- In either V3.0 or V3.1 of EDT, the functionality of line mode commands was changed. Previously, things like I4 to insert before 4 were allowed. Now we have to do I 4. I have some programs (without source) which generate editor command files the 'old way'. The problem was SPR'd, and the developers agreed (at least those who are not TECO fans). Unfortunately, RSTS doesn't 'own' EDT. As a matter of fact, no group admits to owning it. What to do? ================================================================================ Note 29.2 [RSTS]CUSPS - EDITORS 2 of 2 EISNER::KENNEDY "Terry Kennedy" 14 lines 17-DEC-1988 21:59 -< I like RSTS EDT, but... >- -------------------------------------------------------------------------------- Note 11.2 CUSPS - EDITORS 2 of 2 EISNER::LEFEBVRE "Kenneth LeFebvre" 9 lines 10-JUL-1987 08:41 -< I like RSTS EDT, but... >- -------------------------------------------------------------------------------- I have gotten very used to using SEDT (a public domain version of EDT for MS-DOS, VMS, etc. -which, by the way, was written by DEC) which allows some very nice features that RSTS EDT doesn't: 1. LEARN mode (similar to KED on RT-11) 2. Access to O/S commands during edit (handy for those times when you need to check a directory, etc.) 3. A ruler  ================================================================================ Note 30.0 [RSTS]CUSPS - ERROR PACKAGE 1 reply EISNER::KILLEEN 2 lines 25-JUN-1987 21:44 -------------------------------------------------------------------------------- This topic is to be used to discuss the error reporting package. Issues related to anything in ERROR$: ================================================================================ Note 30.1 [RSTS]CUSPS - ERROR PACKAGE 1 of 1 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 22:00 -< ERRDIS via DCL? >- -------------------------------------------------------------------------------- Note 12.1 CUSPS - ERROR PACKAGE 1 of 1 EISNER::KENNEDY "Terry Kennedy" 4 lines 2-JUL-1987 19:50 -< ERRDIS via DCL? >- -------------------------------------------------------------------------------- Let's hook the ERRDIS utility into DCL, a la VMS. We should also allow the same sort of qualifiers. Right now, it's hard to get a report of groups of errors (you can't specify all disks, or everything but start-up events).  ================================================================================ Note 31.0 [RSTS]CUSPS - SPOOLING 7 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:47 -------------------------------------------------------------------------------- This topic is to be used to discuss the spooling packages. Issues related to the OPSER spooling package or the new spooling package. ================================================================================ Note 31.1 [RSTS]CUSPS - SPOOLING 1 of 7 EISNER::KILLEEN "Jeff Killeen" 48 lines 13-JUL-1987 20:55 -< GURU KENNEDY HAS ENLIGHTENED ME >- -------------------------------------------------------------------------------- EISNER::KILLEEN "Jeff Killeen" 14 lines 13-JUL-1987 10:25 -< /COLLATE >- -------------------------------------------------------------------------------- Currently when you do a wild card print and request more than one copy your copies come out bunched together. For example if you have 3 files and 2 copies they come out as follows: FLAG PAGE - FILE 1 - FILE 1 - FILE 2 - FILE 2 - FILE 3 - FILE 3 I would like to be able to collate the copies with something like a /COLLATE switch. They would come out as follows: FLAG PAGE - FILE 1 - FILE 2 - FILE 3 - FLAG PAGE - FILE 1 - FILE 2 - FILE 3 I know user could do this by submiting the print request twice. However, It is best with my users to keep it as simple as possible! -------------------------------------------------------------------------------- EISNER::KENNEDY "Terry Kennedy" 23 lines 13-JUL-1987 19:54 -< Try /JOB_COPIES=n >- -------------------------------------------------------------------------------- >> Currently when you do a wild card print and request more than one copy >> your copies come out bunched together. For example if you have 3 files >> and 2 copies they come out as follows: Unless I misunderstand you, the /JOB_COPIES=n switch will do what you want: PRINT/COPY=2 filea,fileb,filec filea filea fileb fileb filec filec PRINT/JOB=2 filea,fileb,filec filea fileb filec filea fileb filec tmk ================================================================================ Note 31.2 [RSTS]CUSPS - SPOOLING 2 of 7 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 22:02 -< WHY OPSER? >- -------------------------------------------------------------------------------- Note 13.1 CUSPS - SPOOLING 1 of 6 EISNER::KILLEEN 4 lines 26-JUN-1987 01:08 -< WHY OPSER? >- -------------------------------------------------------------------------------- This question is for those of you who under V9 and running both the OPSER spooling package and the new spooling package. What is missing from the new package that keeps you from getting rid of the old one? ================================================================================ Note 31.3 [RSTS]CUSPS - SPOOLING 3 of 7 EISNER::KENNEDY "Terry Kennedy" 17 lines 17-DEC-1988 22:02 -< Personalized forms >- -------------------------------------------------------------------------------- Note 13.2 CUSPS - SPOOLING 2 of 6 EISNER::LEFEBVRE "Kenneth LeFebvre" 12 lines 10-JUL-1987 08:45 -< Personalized Forms >- -------------------------------------------------------------------------------- This really doesn't have to do with Spooling, but PRINT services are tied into PBS, so... I would like to be able to define a special form for printing. For example, we need a line across the tope of each page (similar to a compiler listing has) that identifies the file printed and the company name. This could be implemented as an element of FORMS.SYS and a qualifier to PRINT specifying whether or not to use the "title line". ================================================================================ Note 31.4 [RSTS]CUSPS - SPOOLING 4 of 7 EISNER::KENNEDY "Terry Kennedy" 32 lines 17-DEC-1988 22:02 -< Sending Special Codes >- -------------------------------------------------------------------------------- Note 13.3 CUSPS - SPOOLING 3 of 6 EISNER::LEFEBVRE "Kenneth LeFebvre" 27 lines 10-JUL-1987 08:53 -< Sending Special Codes >- -------------------------------------------------------------------------------- Another PRINT request... I would like to be able to send an initialization sequence to my printer before printing. For example, with an LN03, it would be nice to be able to select the tiny font for printing 132 column files. This would, of course, require a reset sequence at the end of the print job to return the printer to the proper mode(s) for everybody else. Perhaps this, too, could be in FORMS.SYS. How about this? In FORMS.SYS allow any non-PBS command to stand for a special escape sequence or whatever. Then if you added a PBS qualifier like /SEND=xxxxx you could send that sequence. Example: FORM.SYS contains: TINY=[15m LONG=[91t SQUISH=[4w Then, the print request would be entered as: $ PRINT/SEND=(TINY,LONG,SQUISH) FILE.TXT Does this sound reasonable? ================================================================================ Note 31.5 [RSTS]CUSPS - SPOOLING 5 of 7 EISNER::KENNEDY "Terry Kennedy" 17 lines 17-DEC-1988 22:02 -< kludge workaround >- -------------------------------------------------------------------------------- Note 13.4 CUSPS - SPOOLING 4 of 6 EISNER::HORN "Larry Horn" 12 lines 10-JUL-1987 16:06 -< kludge workaround >- -------------------------------------------------------------------------------- >>> I would like to be able to send an initialization sequence to my >>> printer before printing. You may already be doing this as a work-around, but we have a few files in $ like 16CPI.ESC, 8LPI.ESC that contain just the escape sequences to set up the printer (in our case an LA120). Then use the command PRINT $16cpi.esc,myfile.lis Kludgy, but it get's us by. If you're printing headers, etc., you'd want to turn into to requests, of course -- print the esc file /noflag, etc. ================================================================================ Note 31.6 [RSTS]CUSPS - SPOOLING 6 of 7 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 22:02 -< OK FOR NOW >- -------------------------------------------------------------------------------- Note 13.5 CUSPS - SPOOLING 5 of 6 EISNER::KILLEEN "Jeff Killeen" 8 lines 10-JUL-1987 16:17 -< OK FOR NOW >- -------------------------------------------------------------------------------- >>> Kludgy, but it get's us by. If you're printing headers, etc., you'd >>> want to turn into to requests, of course -- print the esc file /noflag, >>> etc. Yes this Kludgy - an ok solution for now. However DEC really should let users specify setup and exit command files when spooling. More and more printers (read postscript) are going to need this! ================================================================================ Note 31.7 [RSTS]CUSPS - SPOOLING 7 of 7 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:03 -< Hear hear! >- -------------------------------------------------------------------------------- Note 13.6 CUSPS - SPOOLING 6 of 6 EISNER::CONROY "Alan Conroy" 3 lines 11-AUG-1988 14:05 -< Hear hear! >- -------------------------------------------------------------------------------- I couldn't agree more. Whay not something like the VMS device libraries. One could use .ULBs (more or less equivalent to VMS .TLBs). Seems like an easy thing to include in the software.  ================================================================================ Note 32.0 [RSTS]CUSPS - BACKUP 7 replies EISNER::KILLEEN 2 lines 25-JUN-1987 21:49 -------------------------------------------------------------------------------- This topic is to be used to discuss the system backup packages. Issues related to the V8 restore package or the V9 backup package. ================================================================================ Note 32.1 [RSTS]CUSPS - BACKUP 1 of 7 EISNER::KILLEEN 11 lines 1-JUL-1987 10:59 -< HOW TO BACKUP A RA81 USING 6 RA60 PACKS >- -------------------------------------------------------------------------------- When you mount a disk under backup it checks the amount of free space remaining. It then uses that information to determine how much data can be written to that disk. Unfortunately, if you are using the packs over and over again for the same backup proceedure it does not delete your output container set file before doing it's free space check. This means if your container set uses 99% of the disk the next time through you use 1% of the disk. To add to the fun on that second pass you end up with a pack that is 99% free since it replaces the large container set file from the first pass with smaller one from the second pass. We do a $DELETE DUn:[*,*]*.* before using the pack (since we only use the pack for backup data). This solves the problem. ================================================================================ Note 32.2 [RSTS]CUSPS - BACKUP 2 of 7 EISNER::KILLEEN 8 lines 1-JUL-1987 11:13 -< /BLOCK_SIZE >- -------------------------------------------------------------------------------- The /BLOCK_SIZE switch is important for both disk and tape backups. At first we thought that /BLOCK would only be useful for tape backups since you want to keep the inter-record gaps to a minimum. However, it has an effective on disk backup performance. A 75% full RA81 to RA60 backup took 2.8 hours an 2.2 packs with the default block size. It took 1.7 hours and 1.8 packs with a block size of 7680. Under V9.3 we are setting all of our backups to /BLOCK_SIZE=MAX. Under V9.0-2 we are setting all of our backups to /BLOCK_SIZE=7680. ================================================================================ Note 32.3 [RSTS]CUSPS - BACKUP 3 of 7 EISNER::KENNEDY "Terry Kennedy" 25 lines 17-DEC-1988 22:06 -< DISK BACKUP NEEDS HELP >- -------------------------------------------------------------------------------- Note 14.1 CUSPS - BACKUP 1 of 5 EISNER::KILLEEN 20 lines 1-JUL-1987 11:30 -< DISK BACKUP NEEDS HELP >- -------------------------------------------------------------------------------- Problem: If you have a backup system were the operator uses the same output packs over and over again you can run into problems. Backup computes the amount of free space on the output pack before it opens it container set file. This means the old container set file is still there when it does the check. If you are using more than one pack you cannot delete the old files before backup without having to mount and dismount each pack first. Using the /INIT switch means that the operator, at a minimum, has to wait for a disk erase on each pack. Wish: Give use some way to quickly overwrite the old container sets. Possible solutions: 1. /INIT/NOERASE/NOPATTERNS 2. /DELETE_FILE=(DU2:[*,*]*.BCK) 3. /OVERWRITE or /REPLACE ================================================================================ Note 32.4 [RSTS]CUSPS - BACKUP 4 of 7 EISNER::KENNEDY "Terry Kennedy" 19 lines 17-DEC-1988 22:06 -< enhancement: /NOTIFY, /BELL >- -------------------------------------------------------------------------------- Note 14.2 CUSPS - BACKUP 2 of 5 EISNER::HORN "Larry Horn" 14 lines 1-JUL-1987 18:31 -< enhancement: /NOTIFY, /BELL >- -------------------------------------------------------------------------------- I submitted a suggestion SPR on this; reply was 'good idea, will consider'. I'd like to see a /BELL or /NOTIFY qualifier for the BACKUP and RESTORE commands. Currenty, an operator has to continually monitor the terminal to see when the next tape needs to be mounted - very inconvenient if the op is working in another room. /BELL would just ring the terminal bell whenever input was needed (as in 'where is next volume'). /NOTIFY, with arguments similar to the BROADCAST command, would alert the operator at another terminal when input was required. ================================================================================ Note 32.5 [RSTS]CUSPS - BACKUP 5 of 7 EISNER::KENNEDY "Terry Kennedy" 18 lines 17-DEC-1988 22:07 -< SELECTIVE RESTORES >- -------------------------------------------------------------------------------- Note 14.3 CUSPS - BACKUP 3 of 5 EISNER::KILLEEN "Jeff Killeen" 13 lines 17-OCT-1987 08:47 -< SELECTIVE RESTORES >- -------------------------------------------------------------------------------- Backup needs a better way to do selective restores. Currently you do a $RESTORE/EXCLUDE=([*,*]*.*)/INCLUDE=([1,111]FOO.DAT) Having to do an /EXCLUDE is not obvious to a novice user. Something like $RESTORE/SELECT=([1,111]FOO.DAT) would be a good solution. ================================================================================ Note 32.6 [RSTS]CUSPS - BACKUP 6 of 7 EISNER::KENNEDY "Terry Kennedy" 36 lines 17-DEC-1988 22:07 -< Strange and mysterious BACKUP >- -------------------------------------------------------------------------------- Note 14.4 CUSPS - BACKUP 4 of 5 EISNER::KENNEDY "Terry Kennedy" 31 lines 18-OCT-1987 18:14 -< Strange and mysterious BACKUP >- -------------------------------------------------------------------------------- > Backup needs a better way to do selective restores. And selective backups - trying to back up a few files scattered around various accounts is a real pain. However, I am uncertain if we are 'worse' than VMS or just 'different' - every time I try to restore a VAX backup set on VMS, I wind up with some- thing like: DUA0:[TERRY.TERRY.TERRY.SUBDIR]FILENAME.TYPE Which is at least equally silly. It looks like we will need new, different command switches to do it right. RSTS Backup still isn't really compatible with VMS Backup - each system has file attributes that the other doesn't know about, and VMS is basically a heirarchical directory structure, whereas RSTS is a 2-level flat struc- ture. I question whether Backup is the ideal solution for all cases. For example, Backup doesn't preserve last login information - so when I back up a disk to reformat it and restore the backup set, I lose all last login info. This wreaks havoc with my accounting system, as an account with no last login date is set up to say 'Your password is expired...'. Comments made by the developers, as well as in the RSTS Release Notes, in- dicate that SAVRES is going away. This is unfortunate, because there is a need for a utility which copies the disk image to tape (or to another disk), without making decisions as to what parts of the data the user wants to keep/ discard, and without using up all the extra tape. Now if we could only get SAVRES to stream! ================================================================================ Note 32.7 [RSTS]CUSPS - BACKUP 7 of 7 EISNER::KENNEDY "Terry Kennedy" 16 lines 17-DEC-1988 22:07 -< Backup and TSV05 drives >- -------------------------------------------------------------------------------- Note 14.5 CUSPS - BACKUP 5 of 5 EISNER::KENNEDY "Terry Kennedy" 11 lines 18-OCT-1987 18:19 -< Backup and TSV05 drives >- -------------------------------------------------------------------------------- While I'm picking on Backup, here is a silly nit I'd like to see fixed - on the TSV05 tape subsystem, Backup will kick the drive into high-speed mode when writing or restoring backup sets, but not while searching for them on the tape. This means that, if all the save set names are known, it is faster to do: $ RESTORE/BUFF=64/EXCLUDE=[*,*]*.* MS0:FILE1.BCK DU0:[*,*]*.* $ RESTORE/BUFF=64 MS0;FILE2.BCK DU0:[*,*]*.* than to just issue the second command alone and let Backup position the tape for itself!  ================================================================================ Note 33.0 [RSTS]CUSPS - RSX UTILITIES 3 replies 0 lines 25-JUN-1987 21:51 -------------------------------------------------------------------------------- ================================================================================ Note 33.1 [RSTS]CUSPS - RSX UTILITIES 1 of 3 EISNER::KILLEEN 2 lines 25-JUN-1987 21:59 -< CUSPS - RSX UTILITIES >- -------------------------------------------------------------------------------- This topic is to be used to discuss the RSX Utilities. Issues related to such utilities as TKB, LIBR, and MACRO. ================================================================================ Note 33.2 [RSTS]CUSPS - RSX UTILITIES 2 of 3 EISNER::HORN "Larry Horn" 17 lines 29-JUL-1987 04:16 -< searching for identity >- -------------------------------------------------------------------------------- About three years ago I wrote a Basic+ program to dump the label blocks of a task image so I could see when it was actually linked, what libraries it used, etc. All this information is documented in Appendix "C" of the task builder reference manual. Unfortunately, an item I decided (tonight) to retrieve is not indicated in the description of the label blocks - the identification (%IDENT "string" in BP2). Appendix B indicates that it is stored in the label blocks, and using UNSUPP$:DSKDMP I can indeed find it in simple tasks - however, I'd like to have the correct links (and mnemonics) to follow to 'officially' track it down. Where I need it most is in more complicated tasks which are too complex to plunder with DSKDMP. What I'd really like to do is chain down all (at least user-compiled) modules in the task and indicate ident and compile date. Is this possible? ================================================================================ Note 33.3 [RSTS]CUSPS - RSX UTILITIES 3 of 3 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:08 -< GIVE US VSECT - FOR REAL >- -------------------------------------------------------------------------------- Note 15.1 CUSPS - RSX UTILITIES 1 of 1 EISNER::KILLEEN 3 lines 26-JUN-1987 01:14 -< GIVE US VSECT - FOR REAL >- -------------------------------------------------------------------------------- Please support and document the VSECT command in TKB. This is a very valuable command when you are using dynamic regions. It works now if you know about it.  ================================================================================ Note 34.0 [RSTS]CUSPS - RT-11 UTILITIES 5 replies 0 lines 25-JUN-1987 21:52 -------------------------------------------------------------------------------- ================================================================================ Note 34.1 [RSTS]CUSPS - RT-11 UTILITIES 1 of 5 EISNER::KILLEEN 2 lines 25-JUN-1987 22:09 -< CUSPS - RT-11 UTILITIES >- -------------------------------------------------------------------------------- This topic is to be used to discuss the RT-11 Utilities. Issues related to LINK, MACRO, ECT. ================================================================================ Note 34.2 [RSTS]CUSPS - RT-11 UTILITIES 2 of 5 EISNER::HORN "Larry Horn" 9 lines 9-FEB-1988 10:51 -< PIP /RMS error >- -------------------------------------------------------------------------------- Anyone seen this (discovered about 15 minutes ago under V9.5)? PIP dest = source /RMS If the output is to a disk, using the /RMS switch results in "Can't find " unless you have WREAD privilege, regardless of the protection or location of either source or destination. Anyone know of a solution? ================================================================================ Note 34.3 [RSTS]CUSPS - RT-11 UTILITIES 3 of 5 EISNER::KENNEDY "Terry Kennedy" 6 lines 10-FEB-1988 00:14 -< Very odd... >- -------------------------------------------------------------------------------- > Anyone seen this (discovered about 15 minutes ago under V9.5)? I just tried it on my 11/44 here, under 9.5-08 and it works for me. My account has all privs, but I did a SET JOB/PRIV=NONE first. Very interesting! ================================================================================ Note 34.4 [RSTS]CUSPS - RT-11 UTILITIES 4 of 5 EISNER::HORN "Larry Horn" 4 lines 10-FEB-1988 18:43 -< works on '84, not '70 >- -------------------------------------------------------------------------------- Acutally, it works on our PDP-11/84, not on our PDP-11/70. The only installation difference on the two systems is the hardware; the monitor options are the same. ================================================================================ Note 34.5 [RSTS]CUSPS - RT-11 UTILITIES 5 of 5 EISNER::KENNEDY "Terry Kennedy" 12 lines 10-FEB-1988 22:06 -< Curiouser and curiouser... >- -------------------------------------------------------------------------------- > Actually, it works on our PDP-11/84, not on our PDP-11/70... Strange - I don't have any '70 machines here (yet - 2 are on the way soon), so I can't verify the problem. But it *shouldn't* be CPU- model related anyway. Do the 2 PIP's ('84 vs. '70) compare? You may want to try the following 'standard remedy #1': o Delete [0-1,*]*.095 o Delete $VER095.SYS o Mount 9.5 update tape and do another update  ================================================================================ Note 35.0 [RSTS]CUSPS - RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 21:53 -------------------------------------------------------------------------------- This topic is reserved for future CUSPS issues  ================================================================================ Note 36.0 [RSTS]CUSPS - RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 21:54 -------------------------------------------------------------------------------- This topic is reserved for future CUSPS issues  ================================================================================ Note 37.0 [RSTS]CUSPS - RESVERED No replies EISNER::KILLEEN 1 line 25-JUN-1987 21:56 -------------------------------------------------------------------------------- This topic is reserved for future CUSPS issues  ================================================================================ Note 38.0 [RSTS]CUSPS - OTHER 16 replies EISNER::KILLEEN 2 lines 25-JUN-1987 22:13 -------------------------------------------------------------------------------- This topic is to be used to discuss other CUSPS issues. Issues other than those covered in topics 11.xx through 19.xx. ================================================================================ Note 38.1 [RSTS]CUSPS - OTHER 1 of 16 EISNER::KILLEEN "Jeff Killeen" 20 lines 13-JUL-1987 12:36 -< GIVE ME CAT >- -------------------------------------------------------------------------------- We put the following COM file on our systems in [1,2]: $ IF F$INSTR(1,P1,"/") .EQ. 0 THEN GOTO IDM_DIR $ _DIR 'P1' 'P2' 'P3' 'P4' 'P5' 'P6' 'P7' 'P8' $ GOTO EXIT $IDM_DIR: IF P1 .EQS. "" THEN P1=F$USER $ PIP 'P1'/DI:NA:EX:SI:PR:LA:DA:TI:CL:HD:RT:AL $EXIT: We also modify the system [0,1]LOGIN.COM file to included the following: $ DIR-ECT:==@$DIR.COM $ CAT-ALOG:==@$DIR.COM This will give you the old style BASIC CATALOG listing. If you prefer to see the number of block used instead of the number of blocks allocated delete the ":AL" from the PIP specification. Also if add any DCL switch to your DIR command the command will execute as a normal DCL command. ================================================================================ Note 38.2 [RSTS]CUSPS - OTHER 2 of 16 EISNER::MCALLISTER "Brian McAllister" 18 lines 26-FEB-1988 12:40 -< DSKINT fails on RL02 with bad spots? >- -------------------------------------------------------------------------------- I am encountering problems with DSKINT.TSK on RL02s. If the disk has no bad spots, it works fine. If it has bad spots, DSKINT fails in the first exercise pass with a "RESERVED INSTRUCTION TRAP" error. One of the disks in question was previously initialized as a RSTS disk (RDS0). It had the bad spots on it then. This is being done under RSTS V9.5, and I am running the program directly (not using DCL INIT command). Also, is DSKINT itself documented anywhere in the V9 manuals, or only the DCL commands? I'd like to know if anyone else has this problem before I send in an SPR. Brian McA. ================================================================================ Note 38.3 [RSTS]CUSPS - OTHER 3 of 16 EISNER::KENNEDY "Terry Kennedy" 16 lines 26-FEB-1988 18:19 -< Not known here... >- -------------------------------------------------------------------------------- > Also, is DSKINT itself documented anywhere in the V9 manuals, > or only the DCL commands? I thought it was in either the back of the System Manager's guide or the Installation and Update manual - I'll search if you like. > I'd like to know if anyone else has this problem before I > send in an SPR. Not here - although I do have problems with the RL02 driver in 9.5 - might be related somehow. As documented in the Release Notes, there is a problem with DSKINT and MSCP disks, where garbage is printed instead of error information. One question, just for my own curiosity - is the system this is happening on a F-11 based system (11/23 or 11/24?)? ================================================================================ Note 38.4 [RSTS]CUSPS - OTHER 4 of 16 EISNER::MCALLISTER "Brian McAllister" 18 lines 26-FEB-1988 20:05 -< Machine is 11/44 >- -------------------------------------------------------------------------------- >>> Also, is DSKINT itself documented anywhere in the V9 manuals, >>> or only the DCL commands? >I thought it was in either the back of the System Manager's guide or >the Installation and Update manual - I'll search if you like. I think I looked in both of those places. They document the INIT command, but not the program itself. >One question, just for my own curiosity - is the system this is >happening on a F-11 based system (11/23 or 11/24?)? The system is an 11/44 (no floating point). The problem also seems to exist in the V9.2 DSKINT. Question: Is it correct to assume that no sane program should get a "RESERVED INSTRUCTION TRAP" no matter what the device its working with does? ================================================================================ Note 38.5 [RSTS]CUSPS - OTHER 5 of 16 EISNER::KENNEDY "Terry Kennedy" 30 lines 26-FEB-1988 23:56 -< Actually, a known bug... >- -------------------------------------------------------------------------------- > I think I looked in both of those places. They document the INIT > command, but not the program itself. I guess they just want us to use DCL (grin). Actually, I think it was an oversight in the documentation when they 'DCLized' the docs. > Question: Is it correct to assume that no sane program should get > a "RESERVED INSTRUCTION TRAP" no matter what the device > its working with does? Well, sort of. RSTS spits that message for a number of errors. The one that bites me the most is a BPT in a source file, which usually has a comment like ';; Can never happen...'. You can also get this sort of thing when a monitor phase is presumed mapped, but isn't for some reason. However, these usually take the system down as BPT's in the exec crash dump and reboot the system. All that aside, a little research shows that this is a known prob- lem scheduled for fixing 'in the next release'. I don't know of a patch, so it's probably too complex to patch. You might try using the offline (INIT-based) DSKINT as it is made of rather different stuff than the on-line version. The reason that I asked about F-11's is that some code (not much of RSTS, fortunately) fails on these CPU's because they implement the PDP-11 instruction set differently than most 'modern' 11's. A good reference for this is 'William's Hack Book', serialized in early issues of the DECUS Combined Newsletters. Hope this helps... ================================================================================ Note 38.6 [RSTS]CUSPS - OTHER 6 of 16 EISNER::MCALLISTER "Brian McAllister" 12 lines 29-FEB-1988 13:19 -< How did you know? >- -------------------------------------------------------------------------------- Thanks for the info ( the background stuff too). It's nice to know I'm not stupid/software not corrupt/etc... One question: >> All that aside, a little research shows that this is a known prob- >> lem scheduled for fixing 'in the next release'. Where did you find this info?? It doesn't appear to be in the Software Dispatch. Do you have some other source for this kind of information, and can others (like me) access it? ================================================================================ Note 38.7 [RSTS]CUSPS - OTHER 7 of 16 EISNER::KENNEDY "Terry Kennedy" 9 lines 1-MAR-1988 03:48 -< Reader-supplied SPR's >- -------------------------------------------------------------------------------- > Where did you find this info?? It doesn't appear to be in > the Software Dispatch. Do you have some other source for > this kind of information, and can others (like me) access it? I get bunches of SPR's (and occasionally answers to them) from the RSTS Newsletter readers. The ones of general interest which will still be unfixed by the time the newsletter issue sees print are published. The rest I keep in a big file folder for answering questions like this... ================================================================================ Note 38.8 [RSTS]CUSPS - OTHER 8 of 16 EISNER::KENNEDY "Terry Kennedy" 19 lines 17-DEC-1988 22:10 -< SHUTUP sources... >- -------------------------------------------------------------------------------- Note 20.1 CUSPS - OTHER 1 of 7 EISNER::KENNEDY "Terry Kennedy" 14 lines 2-JUL-1987 19:54 -< SHUTUP sources... >- -------------------------------------------------------------------------------- We need a way to specify auto-reboot with the $SHUTUP utility. The monitor already has the hooks in it to do this. Perhaps this indicates a wider range of problems with shutup: 1) do you need auto-reboot? 2) do you need to terminate tasks gracefully (database server, etc?) 3) do you need to notify other DECnet nodes? 4) ... etc. We should ask that the SHUTUP source be put on the RSTS distribution kit. The developers thought it was already on there, but it isn't. The statement at Nashville was that the SIG had the final say as to what CUSP sources got on the kit. What do you think? ================================================================================ Note 38.9 [RSTS]CUSPS - OTHER 9 of 16 EISNER::KENNEDY "Terry Kennedy" 20 lines 17-DEC-1988 22:11 -< more on SHUTUP >- -------------------------------------------------------------------------------- Note 20.2 CUSPS - OTHER 2 of 7 EISNER::HORN "Larry Horn" 15 lines 3-JUL-1987 07:19 -< more on SHUTUP >- -------------------------------------------------------------------------------- I'd like to see: 1) SHUTUP from other than KB0: -- yes, I'll take the responsibility to see that KB0: isn't in use. 2) re #2 in previous note: one possibility would be a SHUTUP 'config' file which contained tasks to do during the shutdown, such as SEND RECEIVER rec_name "message" WAIT jobname ! wait for job to complete well, you get the idea; not quite as neat as VMS's SYSHUTDWN.COM, but workable. ================================================================================ Note 38.10 [RSTS]CUSPS - OTHER 10 of 16 EISNER::KENNEDY "Terry Kennedy" 15 lines 17-DEC-1988 22:11 -< more on SHUTUP >- -------------------------------------------------------------------------------- Note 20.3 CUSPS - OTHER 3 of 7 EISNER::KENNEDY "Terry Kennedy" 10 lines 3-JUL-1987 21:04 -< more on SHUTUP >- -------------------------------------------------------------------------------- This just points out the need for the source on the dist. kit. Let's get together with the SIG and request it. As mentioned in .1, the developers have no objection to this. The current SYScall doesn't care about KB0:, and if you set the first zero byte to a one (undocumented) it will auto-restart. Armed with this info, one could write a replacement, but as the Library slogan used to be, "why re-invent the wheel?" tmk ================================================================================ Note 38.11 [RSTS]CUSPS - OTHER 11 of 16 EISNER::KENNEDY "Terry Kennedy" 10 lines 17-DEC-1988 22:11 -< HELP$HELP.HLP >- -------------------------------------------------------------------------------- Note 20.4 CUSPS - OTHER 4 of 7 EISNER::CONROY "Alan Conroy" 5 lines 11-AUG-1988 14:21 -< HELP$HELP.HLP >- -------------------------------------------------------------------------------- How about fixing the update procedure for the help package. Every time I update the system, HELP$:HELP.HLP is over-written and there go all my additions. Then I have to spend time trying to find out what I added to the file and edit it again. VMS is nice in this respect - user changes to the main Help file are retained after updates. ================================================================================ Note 38.12 [RSTS]CUSPS - OTHER 12 of 16 EISNER::KENNEDY "Terry Kennedy" 17 lines 17-DEC-1988 22:11 -< Possible patch >- -------------------------------------------------------------------------------- Note 20.5 CUSPS - OTHER 5 of 7 EISNER::KENNEDY "Terry Kennedy" 12 lines 11-AUG-1988 17:30 -< Possible patch >- -------------------------------------------------------------------------------- > How about fixing the update procedure for the help package. Every time I > update the system, HELP$:HELP.HLP is over-written and there go all my... Would the following help? I have a patch which makes HELP.TSK combine the contents of two help root libraries - HELP.HLP for DEC stuff and LHELP.HLP (local Help) for local stuff. The stuff comes out sorted in the right order, and if there is local help for something that also has system help, local wins... Of course, you could always just keep a copy of HELP.HLP and copy it over after DIFFing... it should only be pointers anyway. ================================================================================ Note 38.13 [RSTS]CUSPS - OTHER 13 of 16 EISNER::KENNEDY "Terry Kennedy" 10 lines 17-DEC-1988 22:12 -< I'll take the patch until DEC fixes the problem >- -------------------------------------------------------------------------------- Note 20.6 CUSPS - OTHER 6 of 7 EISNER::CONROY "Alan Conroy" 5 lines 12-AUG-1988 11:59 -< I'll take the patch until DEC fixes the problem >- -------------------------------------------------------------------------------- Sounds like a good idea to me. Still, one wishes that DEC would provide this so we didn't have to patch HELP. Since I'm lazy, I didn't bother making a patch - it would have been easier to just modify HELP$:HELP.HLP each time. However, since you already have a pacth, I would definitely like it! What's the best way to get it? ================================================================================ Note 38.14 [RSTS]CUSPS - OTHER 14 of 16 EISNER::KENNEDY "Terry Kennedy" 10 lines 17-DEC-1988 22:12 -< Real Soon Now >- -------------------------------------------------------------------------------- Note 20.7 CUSPS - OTHER 7 of 7 EISNER::KENNEDY "Terry Kennedy" 5 lines 12-AUG-1988 19:00 -< Real Soon Now >- -------------------------------------------------------------------------------- > What's the best way to get it? Let me add 'just a few more things' and I'll post it on the Newsletter system (see other notes here for details). I'll post a reply here when it is available (just a few days). ================================================================================ Note 38.15 [RSTS]CUSPS - OTHER 15 of 16 EISNER::CONROY "Alan Conroy" 5 lines 19-DEC-1988 11:56 -< Status report? >- -------------------------------------------------------------------------------- > Let me add 'just a few more things' and I'll post it on the Newsletter >system (see other notes here for details). I'll post a reply here when >it is available (just a few days). Not to complain, but it's been "a few days" now. Any progress? ================================================================================ Note 38.16 [RSTS]CUSPS - OTHER 16 of 16 EISNER::KENNEDY "Terry Kennedy" 5 lines 19-DEC-1988 18:11 -< Soon... >- -------------------------------------------------------------------------------- > Not to complain, but it's been "a few days" now. Any progress? Sad to say, it's been a few months. A few less hairs, too, but that's another story. This week, Ok?  ================================================================================ Note 39.0 [RSTS]OTHER - DCL 17 replies EISNER::KILLEEN 1 line 25-JUN-1987 22:16 -------------------------------------------------------------------------------- This topic is to be used discuss DCL issues. ================================================================================ Note 39.1 [RSTS]OTHER - DCL 1 of 17 EISNER::KILLEEN "Jeff Killeen" 16 lines 10-JUL-1987 22:24 -< PRIVATE FILE BLOCK INFO >- -------------------------------------------------------------------------------- EISNER::KENNEDY "Terry Kennedy" 12 lines 10-JUL-1987 21:21 -< If you knew UUO like I know UUO... >- -------------------------------------------------------------------------------- >> Boy do I agree with this one. I hate the fact I can not create and set >> DCL symbols from a user program. Creating files and reading them in DCL >> is not the right answer! Every time I figure out how UUO.PFB works, they change it (and it's file structure). I had it working in 9.1, but then it fell apart. I don't have the heart to try again. For those not in the know, UUO.PFB (Private File Block?) is the system call used to 'hide' the DCL channels. These are the 16 additional channels used to hold your log file, your symbol table, and nested command files. tmk ================================================================================ Note 39.2 [RSTS]OTHER - DCL 2 of 17 EISNER::KENNEDY "Terry Kennedy" 20 lines 6-AUG-1987 03:44 -< V9.4 DCL bug >- -------------------------------------------------------------------------------- In V9.4, running the following .com file generates some interesting results: $ OPEN/WRITE/REPLACE 1 T.TMP $ INQUIRE A $ WRITE 1 A $ CLOSE 1 $ EXIT It generates: ?Unable to write data file HEN keyword ?Illegal byte count for I/O A user left this goodie on the newsletter system and I thought you might like to know about it. Of course, under the gag order, once I SPR this I can no longer admit that I know anything about it [see SOAPBOX and LATEST RELEASE INFORMATION for more on that]. Terry ================================================================================ Note 39.3 [RSTS]OTHER - DCL 3 of 17 EISNER::CONROY "Alan Conroy" 14 lines 9-AUG-1988 14:39 -< PFB >- -------------------------------------------------------------------------------- >Every time I figure out how UUO.PFB works, they change it (and it's file >structure). I had it working in 9.1, but then it fell apart. I don't have >the heart to try again. In V9.2 the PFB (and a bunch of other stuff) was moved to a new job data structure called the JCR. To the best of my knowledge, it has been fairly stable since. >For those not in the know, UUO.PFB (Private File Block?) is the system call >used to 'hide' the DCL channels. These are the 16 additional channels used >to hold your log file, your symbol table, and nested command files. PFB means "Permanent File Block". If you are still interested in pursuing this, I have more detailed info... ================================================================================ Note 39.4 [RSTS]OTHER - DCL 4 of 17 EISNER::KENNEDY "Terry Kennedy" 6 lines 17-DEC-1988 22:16 -< GET US SPAWN >- -------------------------------------------------------------------------------- Note 21.1 OTHER - DCL 1 of 10 EISNER::KILLEEN 1 line 26-JUN-1987 01:26 -< GET US SPAWN >- -------------------------------------------------------------------------------- We need $SPAWN in RSTS DCL! ================================================================================ Note 39.5 [RSTS]OTHER - DCL 5 of 17 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:16 -< EASY VMS COMPATIBILITY >- -------------------------------------------------------------------------------- Note 21.2 OTHER - DCL 2 of 10 EISNER::KILLEEN 3 lines 2-JUL-1987 14:30 -< EASY VMS COMPATIBILITY >- -------------------------------------------------------------------------------- Every place there is a /QUERY switch in DCL please add and alias switch /CONFIRM. This is for VMS compatibility. /QUERY and /CONFIRM do the same thing. ================================================================================ Note 39.6 [RSTS]OTHER - DCL 6 of 17 EISNER::KENNEDY "Terry Kennedy" 18 lines 17-DEC-1988 22:16 -< Command Line Editing >- -------------------------------------------------------------------------------- Note 21.3 OTHER - DCL 3 of 10 EISNER::KENNEDY "Terry Kennedy" 13 lines 2-JUL-1987 20:00 -< Command Line Editing >- -------------------------------------------------------------------------------- Command line editing is needed. Since V9, commands have become longer and harder to remember (for those migrating from earlier versions). Something like VMS command line editing would help greatly. Brian Nelson has contributed a utility called CLE (Command Line Editor) to the 1986 DECUS RSTS SIG Tape Copy. It works well within the limitations of the current RSTS monitor. Problems include no ^T at the command line, gar- bling of logfiles due to escape sequences, and the inability to edit the input requested by user programs (as opposed to command lines) The developers use CLE. If we could take that away, we'd get real editing capabilities sooner! ================================================================================ Note 39.7 [RSTS]OTHER - DCL 7 of 17 EISNER::KENNEDY "Terry Kennedy" 11 lines 17-DEC-1988 22:17 -< F$xxx >- -------------------------------------------------------------------------------- Note 21.4 OTHER - DCL 4 of 10 EISNER::LEFEBVRE "Kenneth LeFebvre" 6 lines 10-JUL-1987 09:00 -< F$xxx >- -------------------------------------------------------------------------------- Why can't more lexicals be implemented? For instance, it would be much nicer to be able to get all of the SHOW-type of information directly from lexicals rather than have to capture to a logfile, open the logfile, etc... ================================================================================ Note 39.8 [RSTS]OTHER - DCL 8 of 17 EISNER::KENNEDY "Terry Kennedy" 19 lines 17-DEC-1988 22:17 -< DCL debugging feature >- -------------------------------------------------------------------------------- Note 21.5 OTHER - DCL 5 of 10 EISNER::HORN "Larry Horn" 14 lines 10-JUL-1987 16:14 -< DCL debugging feature >- -------------------------------------------------------------------------------- I suppose there are technical reasons why not, but I'd like to see an alternative to the implementation of the DCL debugging feature. If I SET VERIFY, all I see in the echoed command lines is the untranslated symbols ($ OPEN 1 'TMP', for example). To see the translations, I have to turn on debug mode which then prints two lines $ OPEN 1 'TMP' ($ OPEN 1 xlatedfile) I'd rather just see the translation by default and have the 'TMP' show up in debug mode. ================================================================================ Note 39.9 [RSTS]OTHER - DCL 9 of 17 EISNER::KENNEDY "Terry Kennedy" 24 lines 17-DEC-1988 22:17 -< One man's explanation >- -------------------------------------------------------------------------------- Note 21.6 OTHER - DCL 6 of 10 EISNER::KENNEDY "Terry Kennedy" 19 lines 10-JUL-1987 20:51 -< One man's explanation... >- -------------------------------------------------------------------------------- >> Why can't more lexicals be implemented? Here's the answer that I see - I may be wrong, however. In VMS, DCL has an arbitrarily large process space to work with. In RSTS, DCL and it's symbols must all reside within a 32Kw region. Furthermore, even without the address space restraint, we have the problem that VMS system services return data in a manner directly useful to DCL. In RSTS, we need to 'wrap' a utility program around the system service to return useful information. Therefore, a simple f$ lexical would wind up spawning a task image to return the data. What do we do if there are no more job slots on the system? What can we return if the task can't be found? >Answer: ?Lexical not installed< There were many design tradeoffs in the design of DCL for V9.x. I don't agree with all of them, but the product is there and it works (mostly - the ?Memory management trap bug won't be fixed until 9.5 at the earliest). *MY* major gripe is that symbol table support should be in the monitor, not DCL. That way user programs could interpret and set symbols as needed. ================================================================================ Note 39.10 [RSTS]OTHER - DCL 10 of 17 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 22:17 -< YES YES YES >- -------------------------------------------------------------------------------- Note 21.7 OTHER - DCL 7 of 10 EISNER::KILLEEN "Jeff Killeen" 8 lines 10-JUL-1987 21:14 -< YES YES YES >- -------------------------------------------------------------------------------- >>>*MY* major gripe >>>is that symbol table support should be in the monitor, not DCL. That way user >>>programs could interpret and set symbols as needed. Boy do I agree with this one. I hate the fact I can not create and set DCL symbols from a user program. Creating files and reading them in DCL is not the right answer! ================================================================================ Note 39.11 [RSTS]OTHER - DCL 11 of 17 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 22:18 -< DIRECTORY command >- -------------------------------------------------------------------------------- Note 21.8 OTHER - DCL 8 of 10 EISNER::HORN "Larry Horn" 7 lines 10-JUL-1987 23:09 -< DIRECTORY command >- -------------------------------------------------------------------------------- I'd like to see a /[no]ATTRIBUTES qualifier to the DCL DIRECTORY command. I'd be satisfied if it only worked in conjunction with the /FULL qualifier. The only PIP directory switch I still use with any regularity is /LI:FU just so I can get guaranteed one-line entries for all files; in many cases I do want to see all the other info, but NO ATTRIBUTES. ================================================================================ Note 39.12 [RSTS]OTHER - DCL 12 of 17 EISNER::KENNEDY "Terry Kennedy" 28 lines 17-DEC-1988 22:18 -< DCL/PBS ERROR TRAPPING GRANULARITY >- -------------------------------------------------------------------------------- Note 21.9 OTHER - DCL 9 of 10 EISNER::KILLEEN "Jeff Killeen" 23 lines 11-NOV-1987 18:33 -< DCL/PBS ERROR TRAPPING GRANULARITY >- -------------------------------------------------------------------------------- The old ATPK program had the following commands: $ALLOW NO ERRORS $ALLOW WARNING ERRORS $ALLOW FATAL ERRORS The old Batch program had the following commands: $JOB/ERROR:FATAL $JOB/ERROR:WARNING $JOB/ERROR:NONE In both case these command were used to set at what level the command file would be error trapped. Unfortunately, the new DCL/PBS command files do not allow this level of granularity on error control. It is all or nothing at all. $SET ON $SET NOON I would like to see a way to ignore warning errors while still trapping fatal and severe errors. ================================================================================ Note 39.13 [RSTS]OTHER - DCL 13 of 17 EISNER::KENNEDY "Terry Kennedy" 5 lines 17-DEC-1988 22:18 -< $ ON WARNING THEN CONTINUE? >- -------------------------------------------------------------------------------- Note 21.10 OTHER - DCL 10 of 10 EISNER::KENNEDY "Terry Kennedy" 0 lines 11-NOV-1987 18:52 -< $ ON WARNING THEN CONTINUE? >- -------------------------------------------------------------------------------- ================================================================================ Note 39.14 [RSTS]OTHER - DCL 14 of 17 EISNER::MCALLISTER "Brian McAllister" 13 lines 15-MAR-1989 14:22 -< Default directory logical wanted >- -------------------------------------------------------------------------------- Is there any chance that a default directory logical could be implemented in DCL? What I have in mind is something like the DK: logical in RT11. It would seem this would not need any changes to the disk structure, etc. as named directories would. The only problem would be making sure that DK: is automatically assigned to the login account. For people to be happy with it, it would probably be necessary for this NOT to take up a "user logical" slot. Having only three is bad enough. ================================================================================ Note 39.15 [RSTS]OTHER - DCL 15 of 17 EISNER::KENNEDY "Terry Kennedy" 8 lines 15-MAR-1989 15:00 -< Some thoughts on the proposal >- -------------------------------------------------------------------------------- > Is there any chance that a default directory logical could be > implemented in DCL? The problem with this is that file ownership is tied to the directory the file is placed in. You'd be creating things in other people's directories, counted against their quota. Also, you'd need WREAD/WWRITE privs to do this. Should utilities default to [] if the user doesn't have both privs? What about the case of WREAD but not WWRITE? A rather stick situation... ================================================================================ Note 39.16 [RSTS]OTHER - DCL 16 of 17 EISNER::MCALLISTER "Brian McAllister" 27 lines 17-MAR-1989 10:31 -< Access control by privs, just like it is now >- -------------------------------------------------------------------------------- > The problem with this is that file ownership is tied to the directory the >file is placed in. You'd be creating things in other people's directories, >counted against their quota. Also, you'd need WREAD/WWRITE privs to do this. >Should utilities default to [] if the user doesn't have both privs? What >about the case of WREAD but not WWRITE? A rather stick situation... I don't really see this as an issue. I do all of this now, using the logical D:, but it gets tiresome having to redefing commands or type the extra stuff all the time. Access would be controlled as it is now, ie. dependent on the users privileges, with the basic default being that you only get to see/modify files that are world-readable/writable. We have projects that occupy groups of accounts, with all the accounts having GREAD/GWRITE/GACNT, with GWRITE normally turned off. It is somewhat of a pain to have to actually log in to another account, basically just to avoid having to type PPNs all the time. I also use accounts just for holding software under development which I never log into, so I don't have to worry about setting them all up with the right privileges, login.com, etc. What I really was asking was, how feasible would it be to implement this? Could it be done just by modifying DCL, or would other parts of the system be affected? ================================================================================ Note 39.17 [RSTS]OTHER - DCL 17 of 17 EISNER::MCALLISTER "Brian McAllister" 11 lines 17-MAR-1989 10:37 -< Maybe we have an unusual situation >- -------------------------------------------------------------------------------- It occurs to me that the way that we use RSTS here, as a software development environment with many people using the same accounts and people using many accounts, is perhaps unusual? I can see that what I am asking about here would not be very useful on a system where access is tightly controlled, and the purpose of accounts is to limit access to files, not to organise them. Is what I am looking for that different from setting a default directory on VMS or RSX, or the unix CD command?  ================================================================================ Note 40.0 [RSTS]OTHER - RMS-11 No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:16 -------------------------------------------------------------------------------- This topic is to be used to discuss RMS-11 issues.  ================================================================================ Note 41.0 [RSTS]OTHER - SORT/MERGE No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:17 -------------------------------------------------------------------------------- This topic is to be used to discuss SORT/MERGE issues.  ================================================================================ Note 42.0 [RSTS]OTHER - RSX EMULATOR No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:18 -------------------------------------------------------------------------------- This topic is to be used to discuss RSX emulator issues  ================================================================================ Note 43.0 [RSTS]OTHER - RT-11 EMULATOR 3 replies EISNER::KILLEEN 1 line 25-JUN-1987 22:20 -------------------------------------------------------------------------------- This topic is to be used to discussRT-11 emulator issues. ================================================================================ Note 43.1 [RSTS]OTHER - RT-11 EMULATOR 1 of 3 EISNER::MCALLISTER "Brian McAllister" 19 lines 30-MAR-1988 18:32 -< SRCCOM blows up? >- -------------------------------------------------------------------------------- I just got a strange one. Running SRCCOM.SAV (yes I know its unsupported...) under V9.5: RUN UNSUPP$:SRCCOM *[2,5]CU.MAP,DK:CU.MAP ; this works normally *DK:CU.MAP,[2,5]CU.MAP ; this gets me some differences, and then I get: ?M -?Memory management trap at user PC 013774 There doesn't seem to be anything strange about the files, and there are only three lines of differences. I couldn't make it do this with other files. Any ideas/comments? Brian ================================================================================ Note 43.2 [RSTS]OTHER - RT-11 EMULATOR 2 of 3 EISNER::KENNEDY "Terry Kennedy" 1 line 31-MAR-1988 00:52 -< Maybe RMS-attributed files? >- -------------------------------------------------------------------------------- ================================================================================ Note 43.3 [RSTS]OTHER - RT-11 EMULATOR 3 of 3 EISNER::MCALLISTER "Brian McAllister" 3 lines 31-MAR-1988 11:28 -< shouldn't have attributes >- -------------------------------------------------------------------------------- Both files were RT-11 link maps, one created on RSTS, the other copied from RT-11 using FIT.  ================================================================================ Note 44.0 [RSTS]OTHER - DECNET/E 11 replies EISNER::KILLEEN 1 line 25-JUN-1987 22:20 -------------------------------------------------------------------------------- This topic is to be used to discuss DECNET/E issues. ================================================================================ Note 44.1 [RSTS]OTHER - DECNET/E 1 of 11 EISNER::HORN "Larry Horn" 17 lines 28-OCT-1987 08:06 -< NETUNS.TSK (set host to VMS) >- -------------------------------------------------------------------------------- As you may have noticed, SET HOST to a VAX system gives you the error [ RSTS/E V9.3 <--> VMS V4.5 ] ?Unsupported Virtual Terminal Protocol The SPD says there is an UNSUPPORTED utility provided as a courtesy [cute] that allows you to connect to a VAX. Well where is it? You don't get it with a vanilla installation. The backup saveset DNEUSP.BCK on the distribution tape has it! The file is NETUNS.TSK. There are two others as well: NFTDBG.TSK and FALDBG.TSK. [ This may be in the documentation, but I haven't had time to see.] So, do any of you know of bugs that exist in NETUNS.TSK? Any reason why I shouldn't just replace NET.TSK with it? ================================================================================ Note 44.2 [RSTS]OTHER - DECNET/E 2 of 11 EISNER::KENNEDY "Terry Kennedy" 17 lines 28-OCT-1987 18:20 -< As good as NET >- -------------------------------------------------------------------------------- > [ This may be in the documentation, but I haven't had time to see.] Nope, it's a secret! > So, do any of you know of bugs that exist in NETUNS.TSK? Any reason > why I shouldn't just replace NET.TSK with it? We have been using it here since RSTS 9.3 / VMS 4.4. We don't see any problems in RSTS-RSTS mode that aren't also in NET.TSK. As far as talking to VMS, you should know that command line editing and ^T don't work quite right. Also, VMS 4.6 gives you a bogus 'Logical link failure to remote node {vmsnodename} - NSP reason code = success', which is pretty silly. It has been SPR'd to VMS Development. NETUNS uses the original 'Ethernet Terminal Server' protocol to talk to VMS, not CTERM. This also means you will get an object spawn failure when SET HOSTing from VMS to RSTS. ================================================================================ Note 44.3 [RSTS]OTHER - DECNET/E 3 of 11 EISNER::KILLEEN "Jeff Killeen" 6 lines 28-OCT-1987 19:34 -< VMS HAS THE "BUGS" >- -------------------------------------------------------------------------------- > So, do any of you know of bugs that exist in NETUNS.TSK? Any reason > why I shouldn't just replace NET.TSK with it? The bugs are in VMS not RSTS. VMS changed CTERM without telling anyone. They broke a few other O/S's also. ================================================================================ Note 44.4 [RSTS]OTHER - DECNET/E 4 of 11 EISNER::PRIGOT "Jonathan M. Prigot" 7 lines 29-OCT-1987 14:55 -< Mostly OK >- -------------------------------------------------------------------------------- At least up to RSTS V9.3, NETUNS.TSK wants to take in a line of data from the terminal and send it to the VAX. With many programs, this is acceptable (e.g. DIR NODE::[dir]*.* ). If you try it with a program that does any kind of screen painting/forms filling, it is a dog, since the keystroke has to go from the RSTS machine to the VAX to get echoed onto the screen. With a 9600 bps link it's annoying. With anything less, it's intolerable. ================================================================================ Note 44.5 [RSTS]OTHER - DECNET/E 5 of 11 EISNER::MAYHEW "Bill Mayhew" 12 lines 29-SEP-1988 21:09 -< RSTS<->VMS update? >- -------------------------------------------------------------------------------- One of our users on CompuServe has asked about a problem using DECnet between his RSTS (v8.n) system and VMS, which apparently reared its head when he went to VMS V5. Basically, he says he can't go from VMS to RSTS. I thought his problem was a SET HOST connection, but it occurs to me now that I have no evidence to support this. Can anybody give me a current rundown on what the scoop is here -- what works, what doesn't, in very abbreviated form -- and, to what degree upgrading to RSTS v9.6 solves it? I could swear I read something about RSTS (some, or all versions?) DECnet not being compatible with the so-called "phase IV-Plus" of DECnet that VMS v5 supports, but I can't find it anywhere, now. ================================================================================ Note 44.6 [RSTS]OTHER - DECNET/E 6 of 11 EISNER::SCOPELLITI "Whatsa behind is uva no importan" 5 lines 30-SEP-1988 01:44 -< A parallel matching event. >- -------------------------------------------------------------------------------- Not directly applicable, but, when we upgraded to VMS V5 we couldn't SET HOST to RSX-11M systems unless they had the proper updates inplace. Problem was caused by DECnet IV-Plus on VMS V5. So, at least the problem has occurred in other environs. ================================================================================ Note 44.7 [RSTS]OTHER - DECNET/E 7 of 11 EISNER::KENNEDY "Terry Kennedy" 34 lines 30-SEP-1988 05:17 -< Not officially supported, but... >- -------------------------------------------------------------------------------- > Can anybody give me a current rundown on what the scoop is here > -- what works, what doesn't, in very abbreviated form -- and, to > what degree upgrading to RSTS v9.6 solves it? RSTS versions prior to V9.3 were Phase III DECnet nodes, with all the interoperability restrictions noted in the Phase IV manuals. Of course, if you don't have Phase IV books, how do you find out? The last rel- eases of Phase III DECnet/E were DECnet/E V2.0 and 2.1. RSTS 9.3 and newer versions use DECnet/E V4.0, which is a Phase IV product, supporting Ethernet (as of V9.3), LAT (as of V9.6), and Level-1 routing (V9.3, within area only). According to SPR answers and Symposia discussions with the developers, SET HOST is only 'supported' to other RSTS nodes. However, an unsupp- orted version of the NET task is provided on the kit, which works (mostly). So much for the facts from DEC. Now for some independent investigation: RSTS speaks IMP-10 as its SET HOST protocol, which goes to show you just how old RSTS SET HOST is. The replacement NET task speaks something even more useful - Ethernet Terminal Server V1.0! At least VMS knows how to speak ETS, though. [Marginally]. The only current problems in SET HOST to VMS are: 1) Spurious error message at end of session - 'Logical link failure - reason = success', 2) Improperly formatted messages (for ex- ample, the reverse-video 'Interrupt' message, 3) Line editing is broken, 4) poor performance, 5) Strange handling of multiple ^C's. From VMS to RSTS, you get a spurious 'Object spawn failure' when VMS tries to spawn the CTERM handler object, but then VMS tries something else which works. This mess is one of the few remaining sore spots in DECnet/E now that LAT is done. Bythe way, the above results are for RSTS V9.6 with VMS V5.0-1. ================================================================================ Note 44.8 [RSTS]OTHER - DECNET/E 8 of 11 EISNER::MAYHEW "Bill Mayhew" 6 lines 30-SEP-1988 11:36 -< Misery loves company >- -------------------------------------------------------------------------------- Terry, Thanks for all that info. It gives me gladness of heart to know that we RSXers aren't the only ones suffering with inadequate DECnet-with-VMS support. {grin} I'll forward the info to the requester, with credit of course. -Bill ================================================================================ Note 44.9 [RSTS]OTHER - DECNET/E 9 of 11 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 30-SEP-1988 12:06 -< IT IS INADEQUATE DECNET PDP-11 TO VMS SUPPORT >- -------------------------------------------------------------------------------- ================================================================================ Note 44.10 [RSTS]OTHER - DECNET/E 10 of 11 EISNER::KENNEDY "Terry Kennedy" 49 lines 17-DEC-1988 22:19 -< DEC'not'/E? >- -------------------------------------------------------------------------------- Note 26.1 OTHER - DECNET/E 1 of 2 EISNER::KENNEDY "Terry Kennedy" 44 lines 2-JUL-1987 20:14 -< DEC'not'/E? >- -------------------------------------------------------------------------------- The product literature the Digital sales force distributes claims that if you have DECNET on each of your systems, you have one big happy family. This isn't quite the actual story, at least on RSTS. For example: I - SET HOST a - SET HOST to VMS is 'unsupported' - no ^T, no command line recall, etc. b - SET HOST from VMS to RSTS generates 'object spawn failures' on the RSTS side c - SET HOST from RSTS to RSTS - many problems, most having to do with not knowing to transparently go into ODT mode. VMS knows about transparent ODT. This means that things like SET TERMINAL/INQUIRE won't work. d - No proxy logins II - COPY a - COPYing a file from VMS to RSTS won't work if issued from the VAX side. This is a 'known restriction' in VMS b - COPYING a file from RSTS to RSTS loses the protection code c - The DCL COPY command cannot be used with many files because of large block sizes. You have to use NFT's COPY command in- stead. III - PBS a - You can't print to a printer on another node. IV - LAT a - LAT isn't supported. The 'Digital solution' is to buy as many DECserver 200/MC's as you need and 'reverse LAT' them into your RSTS system. Sounds like a great way to sell these servers, but how do you justify having three Ethernet interfaces on each system to management? (One for the 'real' interface, and two to get 16 ports of Ethernet access?) If the terminal driver worked correctly in the first place, you wouldn't need 'reverse LAT' support - you could just hook up the server to any old version of RSTS. It sounds like someone in marketing dreamed up the term 'reverse LAT' to give us users the impression something was being done, when in fact, it wasn't. We finally gave up on Ethernet for terminal services and bought a 256 terminal by 128 port data switch. It doesn't have all the functionality promised for the future of Ethernet, but at least 'this customer has it now'. By the way, due to the COPY situation, we move BACKUP sets between systems for file interchange. ================================================================================ Note 44.11 [RSTS]OTHER - DECNET/E 11 of 11 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 22:20 -< I AM NOT ALONE! >- -------------------------------------------------------------------------------- Note 26.2 OTHER - DECNET/E 2 of 2 EISNER::KENNEDY "Terry Kennedy" 4 lines 4-JUL-1987 02:55 -< I AM NOT ALONE! >- -------------------------------------------------------------------------------- You may be interested in looking at topic 15 in the DEC_SOFTWARE conference for some other user's opinions of 'perverse LAT' tmk  ================================================================================ Note 45.0 [RSTS]RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:23 -------------------------------------------------------------------------------- This topic is reserved.  ================================================================================ Note 46.0 [RSTS]RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:24 -------------------------------------------------------------------------------- This topic is reserved.  ================================================================================ Note 47.0 [RSTS]RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:25 -------------------------------------------------------------------------------- This topic is reserved.  ================================================================================ Note 48.0 [RSTS]Links to other Conferences 3 replies EISNER::KILLEEN 1 line 25-JUN-1987 22:25 -------------------------------------------------------------------------------- This topic is reserved. ================================================================================ Note 48.1* [RSTS]Links to other Conferences 1 of 3 EISNER::HORN "Larry Horn" 3 lines 15-JAN-1988 01:18 -< TeX >- -------------------------------------------------------------------------------- Are implementations of TeX available on RSTS? See: DESKTOP_PUBLISHING, Note 36.0 ================================================================================ Note 48.2* [RSTS]Links to other Conferences 2 of 3 EISNER::HORN "Larry Horn, Millsaps College" 7 lines 8-MAY-1988 01:08 -< SMD controller timings >- -------------------------------------------------------------------------------- RSX 74.* -- "Help with controller SMD caching controller" also pointed to by VMS 198.* (same title) discussion of timing of Specta 25 and Spectra 501 controllers (? same as Sigma SDC-RQ and Webster SMD ?) ================================================================================ Note 48.3 [RSTS]Links to other Conferences 3 of 3 EISNER::KILLEEN "Jeff Killeen" 4 lines 8-MAY-1988 10:26 -< IT IS THE SAME BOARD >- -------------------------------------------------------------------------------- > (? same as Sigma SDC-RQ and Webster SMD ?) The exact same Webster design is used for all three boards.  ================================================================================ Note 49.0 [RSTS]SERVICES - DOCUMENTATION 19 replies EISNER::KILLEEN 2 lines 25-JUN-1987 22:34 -------------------------------------------------------------------------------- This topic is to be used for a discussion of the RSTS documentation set. ================================================================================ Note 49.1 [RSTS]SERVICES - DOCUMENTATION 1 of 19 EISNER::KENNEDY "Terry Kennedy" 7 lines 17-DEC-1988 22:24 -< MASTER INDEX >- -------------------------------------------------------------------------------- Note 31.1 SERVICES - DOCUMENTATION 1 of 19 EISNER::KILLEEN 2 lines 26-JUN-1987 01:39 -< MASTER INDEX >- -------------------------------------------------------------------------------- A master index for all operating system documentation. Any Bozo could do it. ================================================================================ Note 49.2 [RSTS]SERVICES - DOCUMENTATION 2 of 19 EISNER::KENNEDY "Terry Kennedy" 11 lines 17-DEC-1988 22:24 -< No bozos need apply >- -------------------------------------------------------------------------------- Note 31.2 SERVICES - DOCUMENTATION 2 of 19 EISNER::KENNEDY "Terry Kennedy" 6 lines 2-JUL-1987 20:18 -< No bozos need apply >- -------------------------------------------------------------------------------- >> Any bozo could do it. << Any bozo could also do it *WRONG*! Consider the Basic-Plus 2 V2.3 doc set, which usually referred you to the wrong manual (and they only had 3 to choose from). Also the VAX C manual, where all of the run-time library routines were documented under 'errors'. ================================================================================ Note 49.3 [RSTS]SERVICES - DOCUMENTATION 3 of 19 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 22:24 -< RSTS Tech Notes >- -------------------------------------------------------------------------------- Note 31.3 SERVICES - DOCUMENTATION 3 of 19 EISNER::LEFEBVRE "Kenneth LeFebvre" 7 lines 10-JUL-1987 09:04 -< RSTS Tech Notes >- -------------------------------------------------------------------------------- How about a real technical manual (could be extra $$ of course). I needed it when we had real troubles a while back and RSTS was failing for apparently random reasons. If I could have known what was actually happening inside, I might have been able to isolate the problem. As it is our 11/73 was almost completely rebuilt and we ended up getting another distribution! ================================================================================ Note 49.4 [RSTS]SERVICES - DOCUMENTATION 4 of 19 EISNER::KENNEDY "Terry Kennedy" 11 lines 17-DEC-1988 22:25 -< ^T Abbreviations >- -------------------------------------------------------------------------------- Note 31.4 SERVICES - DOCUMENTATION 4 of 19 EISNER::LEFEBVRE "Kenneth LeFebvre" 6 lines 10-JUL-1987 09:05 -< ^T Abbreviations >- -------------------------------------------------------------------------------- As a matter of curiosity, I would like to know what all of the abbreviateions are for ^T. I'm smart enough to figure out FP, ^C, and such as that, but what about the meaning of the FIP abbrev. and many of the numbers listed. ================================================================================ Note 49.5 [RSTS]SERVICES - DOCUMENTATION 5 of 19 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 22:25 -< QUESTION >- -------------------------------------------------------------------------------- Note 31.5 SERVICES - DOCUMENTATION 5 of 19 EISNER::KILLEEN "Jeff Killeen" 4 lines 10-JUL-1987 09:07 -< QUESTION >- -------------------------------------------------------------------------------- >>> How about a real technical manual (could be extra $$ of course). How would this be different from the internals manual? ================================================================================ Note 49.6 [RSTS]SERVICES - DOCUMENTATION 6 of 19 EISNER::KENNEDY "Terry Kennedy" 22 lines 17-DEC-1988 22:25 -< My $.02 >- -------------------------------------------------------------------------------- Note 31.6 SERVICES - DOCUMENTATION 6 of 19 EISNER::KENNEDY "Terry Kennedy" 17 lines 10-JUL-1987 20:57 -< My $.02 >- -------------------------------------------------------------------------------- >> How would this be different from the internals manual? Well, for one thing, it would be up-to-date. This may sound silly to a VMS person, but some of the information in it is sadly out of date. For another, it could include more useful data. Yes, it'e very nice to know how/why the developers did something, but what we need to know is how to do/change it ourselves. Can you write a device driver based on this information? Could you add a new SYS() call? I think not. You need the source kit, of course. But you'll learn more by reading the sources than by reading the internals manual. P.S. - After reading the internals manual, could you even tell me how DISPLY handles its detach/attack and suspend processing? Maybe, but I think you'd do better looking at DISPLY.BAS tmk ================================================================================ Note 49.7 [RSTS]SERVICES - DOCUMENTATION 7 of 19 EISNER::KENNEDY "Terry Kennedy" 18 lines 17-DEC-1988 22:25 -< VMS Internals Manuals not much more timely... >- -------------------------------------------------------------------------------- Note 31.7 SERVICES - DOCUMENTATION 7 of 19 EISNER::HASSINGER "Bob Hassinger" 13 lines 13-JUL-1987 11:47 -< VMS Internals Manuals not much more timely... >- -------------------------------------------------------------------------------- > Well, for one thing, it would be up-to-date. This may sound silly to > a VMS person, but some of the information in it is sadly out of date. Since I have been involved in working with VMS it has been customary for the internals book to be one full major release behind. In fact, there are those who claim to be able to tell when the next major release will be out by watching the internals manual publishing schedule. (Did you notice the pre-publication version of part of the VMS V4 internals manual at the Spring Symposium?) :-) Bob H ================================================================================ Note 49.8 [RSTS]SERVICES - DOCUMENTATION 8 of 19 EISNER::KENNEDY "Terry Kennedy" 13 lines 17-DEC-1988 22:26 -< Not quite what I meant... >- -------------------------------------------------------------------------------- Note 31.8 SERVICES - DOCUMENTATION 8 of 19 EISNER::KENNEDY "Terry Kennedy" 8 lines 13-JUL-1987 19:52 -< Not quite what I meant... >- -------------------------------------------------------------------------------- > Well, for one thing, it would be up-to-date. This may sound silly to > a VMS person, but some of the information in it is sadly out of date. I think you took that as the opposite of what I meant - I meant that to a VMS person (who has been waiting all these years for a Version 4 VMS internals manual) the (minor) out-of-datedness of the RSTS internals manual would be silly. tmk ================================================================================ Note 49.9 [RSTS]SERVICES - DOCUMENTATION 9 of 19 EISNER::KENNEDY "Terry Kennedy" 15 lines 17-DEC-1988 22:26 -< Tech Manual >- -------------------------------------------------------------------------------- Note 31.9 SERVICES - DOCUMENTATION 9 of 19 EISNER::LEFEBVRE "Kenneth LeFebvre" 10 lines 15-JUL-1987 08:56 -< Tech Manual >- -------------------------------------------------------------------------------- I am interested inknowing what RSTS does while booting. No, I don't want to know that it boots then looks for START.COM. In fact, I don't even want to know about SYSINI.COM. I want to know what all of those overlays are that it uses as its booting. I want to know what has been done when it says "xx devices disabled" and what still needs to be done. I want to know what my system is capable of doing when it fails to boot properly and I fall to the DCL dollar-sign, but everything I type says "?Command not installed". Who can tell me these things? Not the Internals manual. ================================================================================ Note 49.10 [RSTS]SERVICES - DOCUMENTATION 10 of 19 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 22:26 -< Do you really want to know? >- -------------------------------------------------------------------------------- Note 31.10 SERVICES - DOCUMENTATION 10 of 19 EISNER::KENNEDY "Terry Kennedy" 7 lines 16-JUL-1987 02:14 -< Do you really want to know? >- -------------------------------------------------------------------------------- >> Who can tell me these things? Not the Internals manual. Well, if the community in general wants to read about all the gory details, I'll gladly post a reply here with as much detail as I can come up with. I have done a good bit of hammering and sawing in INIT, so I think I can tell you lots of neat stuff. tmk ================================================================================ Note 49.11 [RSTS]SERVICES - DOCUMENTATION 11 of 19 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 22:26 -< Do I want to know? >- -------------------------------------------------------------------------------- Note 31.11 SERVICES - DOCUMENTATION 11 of 19 EISNER::LEFEBVRE "Kenneth LeFebvre" 7 lines 25-JUL-1987 20:09 -< Do I want to know? >- -------------------------------------------------------------------------------- -< Do you really want to know? >- No I don't really want to know, but it might have been helpful when we were having problems with our system... ================================================================================ Note 49.12 [RSTS]SERVICES - DOCUMENTATION 12 of 19 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:26 -< Do tell! >- -------------------------------------------------------------------------------- Note 31.12 SERVICES - DOCUMENTATION 12 of 19 EISNER::CONROY "Alan Conroy" 3 lines 11-AUG-1988 14:16 -< Do tell! >- -------------------------------------------------------------------------------- > Do you really want to know? Of course! Inquiring minds ALWAYS want to know! ================================================================================ Note 49.13 [RSTS]SERVICES - DOCUMENTATION 13 of 19 EISNER::KENNEDY "Terry Kennedy" 21 lines 17-DEC-1988 22:27 -< I'll look around >- -------------------------------------------------------------------------------- Note 31.13 SERVICES - DOCUMENTATION 13 of 19 EISNER::BYRNE_C "Charlie Byrne" 16 lines 15-AUG-1988 10:42 -< I'll look around >- -------------------------------------------------------------------------------- I might have a tape around with the sources for V7.0 (circa 1980). I don't remember where it came from and don't know if I could copy it. In fact the tape may not even be good anymore, but if it is, and you have never seen the sources for the O/S (even if it is ridiculously dated) I think you would get a kick out of looking around. There was some interesting stuff in there, comments such as "WOMP the SAT" (it took me a few years to figure out what WOMP stood for (I think I know, anyway). Also if you set the Switch registers to a certain address upon booting a cryptic message would appear on the console (something referring to Tolkein, or "that's interesting, but anyway..."). All I remember is that most of this code was written by Anton Chernov (sp?) and Mark Bramhall and also Simon Szetzu (sp?) who was the RSTS development honcho at the time. Anyway I'm wandering... ================================================================================ Note 49.14 [RSTS]SERVICES - DOCUMENTATION 14 of 19 EISNER::KENNEDY "Terry Kennedy" 7 lines 17-DEC-1988 22:27 -< Talk about old! >- -------------------------------------------------------------------------------- Note 31.14 SERVICES - DOCUMENTATION 14 of 19 EISNER::CONROY "Alan Conroy" 2 lines 15-AUG-1988 12:12 -< Talk about old! >- -------------------------------------------------------------------------------- You think V7.0 sources are old! I have a hardcopy of V5 sitting on a shelf at home! ================================================================================ Note 49.15 [RSTS]SERVICES - DOCUMENTATION 15 of 19 EISNER::KENNEDY "Terry Kennedy" 21 lines 17-DEC-1988 22:27 -< A small historical digression. >- -------------------------------------------------------------------------------- Note 31.15 SERVICES - DOCUMENTATION 15 of 19 EISNER::SCOPELLITI "Whatsa behind is uva no importa" 16 lines 15-AUG-1988 21:10 -< A small historical digression. >- -------------------------------------------------------------------------------- OK.. what _DOES_ WOMP stand for? The "That's interesting, but anyway..." message would appear if you asked for help at the Option: prompt by typing "HELP"! After all, the message said 'Type "HELP" for help.' Names were Mark Bramhull and Simon Szeto. Mark was one (or the one?) of the original RSTS architects. Back in V2, he would arrive at your door with a DECtape containing a custom generated version of RSTS-11 for your machine. Things have changed some.... Simon (when I met him) was the BASIC-PLUS product manager. The one name missing is Martin Minow, who was also involved in DECtalk development. ================================================================================ Note 49.16 [RSTS]SERVICES - DOCUMENTATION 16 of 19 EISNER::KENNEDY "Terry Kennedy" 18 lines 17-DEC-1988 22:28 -< New system date format available in V9.x >- -------------------------------------------------------------------------------- Note 31.16 SERVICES - DOCUMENTATION 16 of 19 EISNER::KENNEDY "Terry Kennedy" 13 lines 15-AUG-1988 21:40 -< New system date format available in V9.x >- -------------------------------------------------------------------------------- For fun with recent versions of RSTS (V9.x), try: SET SYSTEM/DATE=STARDATE Yes, it does what you think it does, *and* it is available through the system date/time conversion routines, but *only* when it is the system default format. Additionally, there is explicit code to con- vert integer stardates + time into fractional stardates for the DCL $ SHOW TIME command. Now, if this gets yanked out because we found it, we should ask for it to be put back in and documented. See - I found a way to put this under the *documentation* topic legitimately! ================================================================================ Note 49.17 [RSTS]SERVICES - DOCUMENTATION 17 of 19 EISNER::KENNEDY "Terry Kennedy" 12 lines 17-DEC-1988 22:28 -< need new topic? >- -------------------------------------------------------------------------------- Note 31.17 SERVICES - DOCUMENTATION 17 of 19 EISNER::HORN "Larry Horn, Millsaps College" 7 lines 17-AUG-1988 01:07 -< need new topic? >- -------------------------------------------------------------------------------- >> it to be put back in and documented. See - I found a way to put this >> under the *documentation* topic legitimately! Let's not start straining gnats ! Why not start a new topic of bizarre features that are needed (or exist but aren't documented)? For instance, I dumped DCL.RTS (looking for something else) and found a state (like NETWORK or BATCH) called "HYPERSPACE". ================================================================================ Note 49.18 [RSTS]SERVICES - DOCUMENTATION 18 of 19 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:28 -< Truely cosmic >- -------------------------------------------------------------------------------- Note 31.18 SERVICES - DOCUMENTATION 18 of 19 EISNER::CONROY "Alan Conroy" 3 lines 17-AUG-1988 11:42 -< Truely cosmic >- -------------------------------------------------------------------------------- > found a state (like NETWORK or BATCH) called "HYPERSPACE". Use the force, Luke... ================================================================================ Note 49.19 [RSTS]SERVICES - DOCUMENTATION 19 of 19 EISNER::KENNEDY "Terry Kennedy" 9 lines 17-DEC-1988 22:28 -< That's been my guess >- -------------------------------------------------------------------------------- Note 31.19 SERVICES - DOCUMENTATION 19 of 19 EISNER::BYRNE_C "Charlie Byrne" 4 lines 17-AUG-1988 14:52 -< That's been my guess >- -------------------------------------------------------------------------------- WOMP the SAT Write Out Modified Pages to Storage Allocation Table  ================================================================================ Note 50.0 [RSTS]SERVICES - DISTRO KITS No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:36 -------------------------------------------------------------------------------- This topic is to be used to discuss the RSTS distribution kits  ================================================================================ Note 51.0 [RSTS]SERVICES - UPDATE SERVICES 1 reply EISNER::KILLEEN 1 line 25-JUN-1987 22:37 -------------------------------------------------------------------------------- This topic is to be used to discuss the software update services. ================================================================================ Note 51.1 [RSTS]SERVICES - UPDATE SERVICES 1 of 1 EISNER::KENNEDY "Terry Kennedy" 6 lines 17-DEC-1988 22:31 -< the future of SPR's >- -------------------------------------------------------------------------------- Note 33.1 SERVICES - UPDATE SERVICES 1 of 1 EISNER::HORN "Larry Horn" 1 line 28-OCT-1987 08:29 -< the future of SPR's >- -------------------------------------------------------------------------------- See the SPR thread in SOAPBOX to stimulate your thinking.  ================================================================================ Note 52.0 [RSTS]SERVICES - SPR 6 replies 0 lines 25-JUN-1987 22:40 -------------------------------------------------------------------------------- ================================================================================ Note 52.1 [RSTS]SERVICES - SPR 1 of 6 EISNER::KILLEEN 4 lines 26-JUN-1987 17:03 -< SERVICES - SPR >- -------------------------------------------------------------------------------- This topic will be used to discuss SPRs and possible solutions. Only problem/error SPRs should be discussed in this topic. Suggestions and enhancement SPRs should be discussed under the appropriate topic in the RSTS Futures conference. ================================================================================ Note 52.2 [RSTS]SERVICES - SPR 2 of 6 EISNER::KILLEEN 2 lines 26-JUN-1987 17:06 -< SERVICES - SPR >- -------------------------------------------------------------------------------- This topic is also for the discussion of the SPR service itself. However, lets avoid th usual flames! ================================================================================ Note 52.3 [RSTS]SERVICES - SPR 3 of 6 EISNER::KILLEEN "Jeff Killeen" 5 lines 8-JUL-1987 23:40 -< BACKUP HANGS >- -------------------------------------------------------------------------------- There is known bug in V9.0 9.1 9.2 & 9.3 backup. If a asynch I/O request gets screwed up the backup program goes into infinite I/O wait. You can tell if this has happened if you kill the job, it goes to priority 127, and never goes away. The only way to kill the job is to crash the system. ================================================================================ Note 52.4 [RSTS]SERVICES - SPR 4 of 6 EISNER::HORN "Larry Horn" 1 line 28-OCT-1987 08:26 -< A search for flames >- -------------------------------------------------------------------------------- See "Is the SPR process broken?" thread in SOAPBOX. ================================================================================ Note 52.5 [RSTS]SERVICES - SPR 5 of 6 EISNER::KENNEDY "Terry Kennedy" 1 line 28-OCT-1987 18:40 -< Is that anything like Quest for Fire? >- -------------------------------------------------------------------------------- > -< A search for flames >- ================================================================================ Note 52.6 [RSTS]SERVICES - SPR 6 of 6 EISNER::KILLEEN "Jeff Killeen" 3 lines 15-JAN-1988 18:58 -< 9.5 DIRECTORY CORRUPTION >- -------------------------------------------------------------------------------- There is a "fun" bug in V9.5. If you shrink files your directories will *SLOWLY* get corrupted. The patch is in the February dispatch.  ================================================================================ Note 53.0 [RSTS]SERVICES - RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 22:41 -------------------------------------------------------------------------------- This note is reserved for future service issues.  ================================================================================ Note 54.0 [PDPBAS]PDP-11 BASICS 2 replies EISNER::KILLEEN 6 lines 25-JUN-1987 23:25 -------------------------------------------------------------------------------- The purpose of this conference is to discuss the major PDP-11 basic products. The conference is initially setup in two parts. One set of topics, 5.xx through 14.xx, deal with current released versions. The other set of topics, 15.xx thorugh 19.xx deal with futures or wish list items. The wish list items will be foward to the PDP-11 languages group. ================================================================================ Note 54.1 [PDPBAS]PDP-11 BASICS 1 of 2 EISNER::KILLEEN "Jeff Killeen" 33 lines 8-JUL-1987 15:06 -< THE THREE BASICS >- -------------------------------------------------------------------------------- Some background on the three major BASIC products available on PDP-11's. BASIC-PLUS on RSTS: This is the oldest of the three BASICs. BASIC-PLUS-2 on RSTS, RSX, PRO, and VMS were originally based on this language's definition. The code for BASIC-PLUS on RT-11 is based on this BASIC with extensions. It is a high speed interpreter, or incremental compiler. It is a great development tool since a user can interrupt execution, examine code and variables, and change statements. It does not support RMS-11. Most code written in this BASIC will run on the other two. BASIC-PLUS on RT-11: This is the newest of the three BASICs. This product is an extended version of RSTS BASIC-PLUS. In addition to all the above features of RSTS BASIC-PLUS it allows the user to define new language statements, and supports callable macro subroutines. It can be overlaid to create more user program space. BASIC-PLUS-2: This is the only true compiler BASIC available from Digital for the PDP-11's. It is the same product on RSTS, RSX, and the PRO. Version 2 initially shared the same BLISS code with VAX BASIC. It is the most powerful of the three. RSTS BASIC-PLUS RT-11 BASIC-PLUS BASIC-PLUS-2 !-----------------------!-----------------------!------------------ RSX ! ! Works but not ! supported ! ! supported ! !-----------------------!-----------------------!------------------ RSTS ! supported ! ! supported !-----------------------!-----------------------!------------------ RT-11 ! ! supported ! !-----------------------!-----------------------!------------------ ================================================================================ Note 54.2 [PDPBAS]PDP-11 BASICS 2 of 2 EISNER::KILLEEN "Jeff Killeen" 1 line 10-OCT-1987 13:31 -< RT BASIC-PLUS >- -------------------------------------------------------------------------------- Please see the LATEST CONFERENCE topic 73.0  ================================================================================ Note 58.0 [PDPBAS]RSTS BASIC-PLUS HINTS & KINKS 4 replies EISNER::KILLEEN 1 line 25-JUN-1987 23:39 -------------------------------------------------------------------------------- This topic will be used to discuss RSTS BASIC-PLUS hints and kinks. ================================================================================ Note 58.1 [PDPBAS]RSTS BASIC-PLUS HINTS & KINKS 1 of 4 EISNER::KILLEEN 14 lines 2-JUL-1987 00:43 -< FORMAT CONTROL >- -------------------------------------------------------------------------------- We add the following statements to our EDTINI.EDT files. They allow us to easly create code that can be used by both BP and BP2. ! ! BASIC LANGUAGE LINE FORMAT COMMANDS ! ! BACKSPACE = Statement continuation - "&" ! LINEFEED = Line continuation - "\&" ! EOL(keypad) = End of line - "&" ! GOLD H = Setup a section header ! DEFINE KEY CONTROL H AS "I & ^Z." DEFINE KEY CONTROL J AS "I \ & ^Z." DEFINE KEY 02 AS "I & ^Z." DEFINE KEY GOLD H AS "I?'Line Number: ' ! & ! ?' Title: ' & ^Z." ================================================================================ Note 58.2 [PDPBAS]RSTS BASIC-PLUS HINTS & KINKS 2 of 4 EISNER::KILLEEN "Jeff Killeen" 8 lines 6-MAR-1988 02:00 -< HELLO USER SPACE - BYE BYE COMPILE/TKB >- -------------------------------------------------------------------------------- We have installed BAS24 on our system. This is a relinked version of RSTS BASIC-PLUS. It works just like BASIC-PLUS but you get a 24K user area instead of the standard 16K. I am finding that it gives you about the same amount compile space as BP2. I STRONGLY RECOMMEND this product for anyone who is doing BP development. The ordering information is in the DEC PRO and the cost is $2950. They will send you a demo tape for $50. ================================================================================ Note 58.3 [PDPBAS]RSTS BASIC-PLUS HINTS & KINKS 3 of 4 EISNER::KENNEDY "Terry Kennedy" 8 lines 6-MAR-1988 03:09 -< Examining hat carefully (magic trick?) >- -------------------------------------------------------------------------------- > We have installed BAS24 on our system. This is a relinked version of > RSTS BASIC-PLUS. Can you still select relevant GEN options? (matrices, string , debug)? Does this mean you don't get garbage collection problems at ~15K any- more? Where did the other 8Kw come from - are some (less-used) parts in an overlay? ================================================================================ Note 58.4 [PDPBAS]RSTS BASIC-PLUS HINTS & KINKS 4 of 4 EISNER::KILLEEN "Jeff Killeen" 35 lines 6-MAR-1988 04:15 -< THIS LOOKS LIKE A REALLY SOLID PRODUCT >- -------------------------------------------------------------------------------- > Can you still select relevant GEN options? (matrices, string , debug)? You get three versions 2 word math - No FPP 4 word math - No FPP 4 word math - FPP You get Log functions, Print Using, Trace, Break, and Dump. You don't get Trig functions, Matrices, or String Arithmetic. You only get scale with FPP systems. > Does this mean you don't get garbage collection problems at ~15K any- > more? We have not seen any problems > Where did the other 8Kw come from - are some (less-used) parts in an > overlay? They split BASIC-PLUS into three run-time systems. One for keyboard commands, one to compile the source into intermediate code, and one to run the intermediate code. And before you ask they do not thrash each other. The sad thing about this DEC paid EG&H to develop the original version of BASIC-PLUS and then Citi-Bank paid EG&H for the enhanced version with the extended variable names and DEC never funded any further development. Also since it was not developed in house no one inside of DEC really never knew the product that well. These changes were not that difficult to implement and could have been done years ago (with version 5). Peter Dick who owns the product checked with EG&H before he did the project. Looking back on the last 10 years if DEC had done this I could have had 6 months of my life back instead of waiting for BP2 compiles and task builds  ================================================================================ Note 59.0 [PDPBAS]RT-11 BASIC-PLUS HINTS & KINKS No replies EISNER::KILLEEN 1 line 25-JUN-1987 23:40 -------------------------------------------------------------------------------- This topic will be used to discuss RT-11 Basic-Plus Hints & Kinks.  ================================================================================ Note 60.0 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 9 replies EISNER::KILLEEN 2 lines 25-JUN-1987 23:41 -------------------------------------------------------------------------------- The topic will be used to discuss PRO, RSX, RSTS Basic-Plus-2 Hints & Kinks. ================================================================================ Note 60.1 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 1 of 9 EISNER::KILLEEN 14 lines 2-JUL-1987 00:41 -< FORMAT CONTROL >- -------------------------------------------------------------------------------- We add the following statements to our EDTINI.EDT files. They allow us to easly create code that can be used by both BP and BP2. ! ! BASIC LANGUAGE LINE FORMAT COMMANDS ! ! BACKSPACE = Statement continuation - "&" ! LINEFEED = Line continuation - "\&" ! EOL(keypad) = End of line - "&" ! GOLD H = Setup a section header ! DEFINE KEY CONTROL H AS "I & ^Z." DEFINE KEY CONTROL J AS "I \ & ^Z." DEFINE KEY 02 AS "I & ^Z." DEFINE KEY GOLD H AS "I?'Line Number: ' ! & ! ?' Title: ' & ^Z." ================================================================================ Note 60.2 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 2 of 9 EISNER::KENNEDY "Terry Kennedy" 15 lines 10-JUL-1987 00:54 -< BP2 V2.4 not compatible w/ V2.3 >- -------------------------------------------------------------------------------- Having just installed [endured] BP2 V2.4 on RSTS, I have discovered that at least one of the Basic-Plus 'compatibility' features has gone away. This means that several of the RSTS/E CUSPS will not compile under this version. I'm now re-installing 2.3 - it had some bugs, but at least it compiled the stuff. My main gripe is that in the past, a considerable amount of effort was expended by DEC to ensure that BP2 was a reasonable superset of B+. This release, in one stroke, negates that. The particular item I found first was the LINE keyword - used for reporting the current program line for ^C trapping. It doesn't matter how easy it is to change the basic program, why should I have to change it at all? tmk ================================================================================ Note 60.3 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 3 of 9 EISNER::HORN "Larry Horn" 2 lines 10-JUL-1987 15:58 -< RSTS BP2 V2.3 -> 2.4? >- -------------------------------------------------------------------------------- Could you give a brief list of things that break? I'm planning to install v2.4 in a week or so and would like to be prepared. ================================================================================ Note 60.4 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 4 of 9 EISNER::KENNEDY "Terry Kennedy" 17 lines 10-JUL-1987 20:38 -< Here's an idea >- -------------------------------------------------------------------------------- >> Could you give a brief list of things that break? I'm planning >> to install v2.4 in a week or so and would like to be prepared. Well, I tried compiling the RSTS CUSPS and got lots of errors, so I ran screaming back to 2.3. The best way to check in your programs is to run the cross-reference utility with option /KEYWORDS. Now look up the list in the Reference Manual index. I know that's hard, but... All the items which have gone away were not documented in the 2.3 manual set (or at least I couldn't find any). They all seem to have been in for purposes of B+ compatibility. If your appli- cation was originally written in BP2, you're probably safe. **** BACK UP YOUR ENTIRE INSTALLED 2.3 COMPILER BEFORE INSTALLING 2.4 **** I've re-installed 2.3 on one system. Since I have 4 systems here, I can have one be back-level for purposes of compiling system code. You DON'T want to have to re-install if 2.4 is sour for you, though - it takes too long. ================================================================================ Note 60.5 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 5 of 9 EISNER::TABOR "Bill Tabor" 58 lines 12-JUL-1987 14:51 -< Using the VARIANT to compile my Programs >- -------------------------------------------------------------------------------- I add the following code to all of my programs written in BP2 or VAX BASIC. %LET %RSTS = 2 %LET %RSXMP = 4 %LET %RSXM = 8 %LET %POS = 16 %LET %VMS = 32 %IF %VARIANT AND 1 %THEN %LET %DEBUG = -1 %ELSE %LET %DEBUG = 0 %END %IF %IF %VARIANT AND (4 + 8 + 16) %THEN %LET %RSX = -1 %ELSE %LET %RSX = 0 %END %IF %IF %VARIANT AND (2 + 4 + 8 + 16) %THEN %LET %PDP11 = -1 %ELSE %LET %PDP11 = 0 %END %IF %IF %DEBUG %THEN %IF %VARIANT AND %RSTS %THEN PRINT "Compiled for RSTS" %END %IF %IF %VARIANT AND %RSXMP %THEN PRINT "Compiled for RSX-11M+" %END %IF %IF %VARIANT AND %RSXM %THEN PRINT "Compiled for RSX-11M" %END %IF %IF %PDP11 %THEN PRINT "Compiled for PDP-11" %END %IF %IF %RSX %THEN PRINT "Compiled for RSX" %END %IF %IF %VARIANT AND %VMS %THEN PRINT "Compiled for VMS" %END %IF %IF %DEBUG %THEN PRINT "Compiled with DEBUG" %END %IF %END %IF ================================================================================ Note 60.6 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 6 of 9 EISNER::KENNEDY "Terry Kennedy" 3 lines 24-JUL-1987 23:54 -< More gotcha's in V2.4 >- -------------------------------------------------------------------------------- For more bad news on Basic-Plus 2 / RSTS V2.4, see the info in the LATEST_RELEASE_INFORMATION conference. I've found more gotcha's. terry ================================================================================ Note 60.7 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 7 of 9 EISNER::HORN "Larry Horn" 23 lines 26-JUL-1987 22:44 -< only one error >- -------------------------------------------------------------------------------- >> This means that several of the RSTS/E CUSPS will not compile [under >> V2.4]... The particular item I found first was the LINE keyword ... Several - do you have a source kit? The only error I found when compiling the programs in SOURCE$ was one use of LINE in the LOGIN program. Everything else compiled and linked just fine. I also recompiled and linked several (maybe a dozen) utility programs that I've written and received no errors. After that I stopped testing, since that covered my immediate needs and had to go on to another project. In a couple weeks I'll start testing our administrative software (the V2.4 compiler is on our academic machine only for now). I'll report on my [non]success after I've rebuilt those programs. >> It doesn't matter how easy it is to change the basic program, why >> should I have to change it at all? In this case, I think a cover-letter note in the release package would have been sufficient (since as far as I can tell, it only affected one program). Larry Horn ================================================================================ Note 60.8 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 8 of 9 EISNER::KENNEDY "Terry Kennedy" 21 lines 26-JUL-1987 23:28 -< More on the LINE bug >- -------------------------------------------------------------------------------- >> Several - do you have a source kit? No, I don't have the source kit - I've been using some of the code in the V8 kits as a base for some local code since DEC no longer dis- tributes sources. The source kit is on order for delivery in October. >> In this case, I think a cover-letter note in the release package >> would have been sufficient (since as far as I can tell, it only >> affected one program). The point I was trying to make is that this is an ommission from the product for no apparent reason. The outboard XREF utility still thinks that the LINE keyword is valid. Only the compiler has trouble with it. As I said in an off-line conference with Jeff Killeen, 'I'm mas as hell but it doesn't particularly affect me'. My objection is that something went away without any notification. How would you feel if all of the '%Language feature is declining' keywords vanished? Arguably, that will never happen. However, if we accept LINE and others without comment, that may bring 'never' a little bit closer. Terry Kennedy ================================================================================ Note 60.9 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 HINTS & KINKS 9 of 9 EISNER::TABOR "Bill Tabor" 8 lines 7-MAR-1988 20:20 -< Fast map works >- -------------------------------------------------------------------------------- I Just finished a project on a RSTS/E V9.5 system allows me to use an external function to remap my array to n 4kw segments. This gives me any size of in memory array I want to use. This program does fast mapping. The cost of cpu time was about 6% in 1,000,000 random accesses to the a stright memory access just using subscrips. It took 25% less cpu then accessing a virtual disk file on an RD53. and was 200% wall clock faster. Fast map does work!  ================================================================================ Note 61.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 23:43 -------------------------------------------------------------------------------- This is a reserved topic.  ================================================================================ Note 62.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 25-JUN-1987 23:43 -------------------------------------------------------------------------------- This is a reserved topic.  ================================================================================ Note 63.0 [PDPBAS]RSTS BASIC-PLUS QUESTIONS 4 replies EISNER::KILLEEN 2 lines 25-JUN-1987 23:56 -------------------------------------------------------------------------------- This topic will be used to ask questions regarding RSTS Basic-Plus. The questions can be; how to; have you done; or do you know. ================================================================================ Note 63.1 [PDPBAS]RSTS BASIC-PLUS QUESTIONS 1 of 4 EISNER::MCALLISTER "Brian McAllister" 16 lines 6-OCT-1988 12:59 -< CSPCOM info wanted >- -------------------------------------------------------------------------------- Can anyone explain why CSPCOM sometimes works, and sometimes doesn't? I am not talking about BASIC+2 features that it doesn't understand, but about cases where it appears to successfully compile, and the task build works, but the executable doesn't. Also, is it possible to do the task build so that the CSPLIB shared library is used properly? I have tried this while modifying CUSPs (LOGOUT in particular), and managed to get programs that worked but were ~50% larger than the .TSKs that came with RSTS. Finally, can LOGIN be successfully rebuilt with CSPCOM, or is BP2 required? ================================================================================ Note 63.2 [PDPBAS]RSTS BASIC-PLUS QUESTIONS 2 of 4 EISNER::KENNEDY "Terry Kennedy" 21 lines 6-OCT-1988 18:35 -< It's not so bad >- -------------------------------------------------------------------------------- > I am not talking about BASIC+2 features that it doesn't understand, > but about cases where it appears to successfully compile, and the > task build works, but the executable doesn't. Aside from the deassign logical problem, I'd be interested in seeing any examples of this. > Also, is it possible to do the task build so that the CSPLIB > shared library is used properly? I have tried this while modifying > CUSPs (LOGOUT in particular), and managed to get programs that worked > but were ~50% larger than the .TSKs that came with RSTS. Misassuption: CSPLIB is not used with CSPCOM, but only with BP2. There is no DEC-supplied resident library support for CSPCOM, but if you have a BP2 V1.6 tape, you might be able to cook up something. > Finally, can LOGIN be successfully rebuilt with CSPCOM, or is BP2 > required? Yes, if you fix the CSPCOM bug. The fix is in the Oct. 88 RSTS Newsletter, or you can get it fro the RSTS SIG BBS (see topic on BBS here). ================================================================================ Note 63.3 [PDPBAS]RSTS BASIC-PLUS QUESTIONS 3 of 4 EISNER::MCALLISTER "Brian McAllister" 12 lines 7-OCT-1988 10:54 -< Deassign logical problem? >- -------------------------------------------------------------------------------- < Note 10.2 by EISNER::KENNEDY "Terry Kennedy" > >> cases where it appears to successfully compile, and the >> task build works, but the executable doesn't. > Aside from the deassign logical problem, I'd be interested in seeing any >examples of this. The specific case I had in mind was LOGIN. What deassign logical problem? ================================================================================ Note 63.4 [PDPBAS]RSTS BASIC-PLUS QUESTIONS 4 of 4 EISNER::KENNEDY "Terry Kennedy" 16 lines 7-OCT-1988 22:58 -< *That* problem... >- -------------------------------------------------------------------------------- > The specific case I had in mind was LOGIN. > What deassign logical problem? A=B. LOGIN's problem is with deassigning logicals - The CSPCOM.OLB rou- tine to do this function is what traps LOGIN. Try this: File to patch? CSPCOM.OLB Base address? 107430 Offset address? 0 Base Offset Old New? ?????? 000000 005040 ? ?????? 000002 020037 ? 20027 ?????? 000004 000734 ? ?????? 000006 101374 ? ^C  ================================================================================ Note 64.0 [PDPBAS]RT-11 BASIC-PLUS QUESTIONS No replies EISNER::KILLEEN 2 lines 25-JUN-1987 23:57 -------------------------------------------------------------------------------- This topic will be used to ask questions regarding RT-11 Basic-Plus. The questions can be; how to; have you done; or do you know.  ================================================================================ Note 65.0 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 9 replies EISNER::KILLEEN 3 lines 26-JUN-1987 00:01 -------------------------------------------------------------------------------- This topic will be used to ask questions regarding PRO, RSX, and RSTS Basic-Plus-2. The questions can be; how to; have you done; or do you know. ================================================================================ Note 65.1 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 1 of 9 EISNER::KILLEEN "Jeff Killeen" 11 lines 11-NOV-1987 17:40 -< IMPROVED BP2 PERFORMANACE >- -------------------------------------------------------------------------------- Since I spend most of my time doing BP2 compiles on RSTS I would like to know your favorite ticks for improving performance. I have PDP-11/73B with 4MB of PMI memory RD53 RD52 Dual RL02's Dual RX33's It is a one user system - so anything goes ================================================================================ Note 65.2 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 2 of 9 EISNER::KENNEDY "Terry Kennedy" 19 lines 11-NOV-1987 18:24 -< Virtual disk >- -------------------------------------------------------------------------------- > I would like to know your favorite ticks for improving performance. I find that the major bottleneck in BP2 compiler performance is that the compiler spends at least 75% of its time loading other portions of itself from disk overlays. For machines with the CIS option (11/23, 24, 44) simply putting the compiler image on the virtual disk will help a lot for RSTS. From talking to several RSX people, I get the impression performance is better under RSX. Perhaps this is because RSX people are more used to changing the files used to TKB the com- piler. Certainly, building the compiler as an I&D space task will help, if it can be done. Or, for the really adventurous, several resident libraries could be made from the old overlay code, and one could just re-map as needed. Regarding the virtual disk idea - it will probably help even on a system without CIS, but it will *kill* the system for other users. To try it, just copy $BP2IC2.TSK to DV0: and RUN DV0:$BP2IC2. The switch BP2 command will pull up the non-DV0: version, so don't use it. ================================================================================ Note 65.3 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 3 of 9 EISNER::KENNEDY "Terry Kennedy" 9 lines 11-NOV-1987 18:28 -< RSTS BP2 programs on VMS? >- -------------------------------------------------------------------------------- And now back with a question of my own - Why can't a simple BP2 program like: 10 PRINT "THIS IS A TEST" 20 END after being compiled and TKB'd on a RSTS system, be run on a VAX under the RSX AME? I get 'Non-RSX EMT encountered'. However, the same task will work if copied to a RSX system! It seems that the BP2 run-time library does some checking or initialization at startup time which requires RSTS/E or real RSX. Any ideas on a way around this? ================================================================================ Note 65.4 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 4 of 9 EISNER::KILLEEN "Jeff Killeen" 11 lines 11-NOV-1987 18:40 -< VIRTUAL DISK DID NOT WORK >- -------------------------------------------------------------------------------- >Regarding the virtual disk idea - it will probably help even on a >system without CIS, but it will *kill* the system for other users. >To try it, just copy $BP2IC2.TSK to DV0: and RUN DV0:$BP2IC2. The >switch BP2 command will pull up the non-DV0: version, so don't >use it. When I tried this the virtual disk took longer. I normally have the system set cache all - with a 1MB cache. Yes I did turn cache off for the test. I would agree that this is a good idea for a CIS system. ================================================================================ Note 65.5 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 5 of 9 EISNER::KENNEDY "Terry Kennedy" 22 lines 11-NOV-1987 18:48 -< Code for non-CIS is ugh! >- -------------------------------------------------------------------------------- > When I tried this the virtual disk took longer. Well, here goes with some RSTS monitor/device driver stuff: If you have CIS, then the CIS 'move string' opcode is used to copy the data from the memory region of the virtual disk to your job's data area. I know this hasn't changed. For non-CIS systems, the last time I looked, the transfer was done the following way: 1) Map virtual disk area 2) Load up 4 registers with 4 words of virtual disk data 3) Map user job area 4) Store 4 words of data from registers to job area 5) Repeat 128 times It seems the reason for this is that both methods will be interruptable by a higher-priority operation. If we could get both the virtual disk area and the user job area mapped at the same time, things would get a lot better for non-CIS systems. In the meanwhile, you might look at one of the virtual disk products that emulates a 'real' DEC disk device. Then RSTS will use the normal NPR transfer mechanism to move the data. ================================================================================ Note 65.6 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 6 of 9 EISNER::TABOR "Bill Tabor" 13 lines 16-NOV-1987 21:28 -< How Fast is FAST? >- -------------------------------------------------------------------------------- How I optimized my RSX system was to build a large DISK cache for My source DISK and made sure the LB: pointed to this disk as well as SY: the compiler is also on this DISK. I have secondary Cache set to 96k. On an 11/73 with 2mb I can compile a 700 line program in 3 Min. Is that fast? I use to work on a system that took 2 hours to compile and 16 to task build. There was a macro-11 system that was built with this system that took 12 hours to macro and 2 hours to task build. As to why PDP-11 Basic program won't work on a VAX in the RSX AME. You can't build the complier under the AME either. ================================================================================ Note 65.7 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 7 of 9 EISNER::KILLEEN "Jeff Killeen" 59 lines 29-NOV-1987 19:02 -< BP2 RSTS COMPILER PERFORMANCE >- -------------------------------------------------------------------------------- After much research here is what I found about RSTS BP2 compiler performance...... COMPILER WORK FILE TIME IN TEST# LOCATION LOCATION MINUTES ----- ---------------------- ---------------------- ------- 1. DU0: (NOCACHE) DU0: (NOCACHE) 22 2. DU0: (CACHE ALL) DU0: (CACHE ALL) 19 (86%) 3. DU0: (CACHE ALL) DV0: (VIRTUAL DISK) 18 (82%) 4. DU0: (FORCED CACHE ALL) DU0: (CACHE ALL) 14 (64%) 5. DV0: (VIRTUAL DISK) DU0: (CACHE ALL) 14 (64%) 6. DU0: (FORCED CACHE ALL) DV0: (VIRTUAL DISK) 13.5 (61%) 7. DV0: (VIRTUAL DISK) DV0: (VIRTUAL DISK) 12 (55%) NOCACHE = The system's automatic data caching was turned off. VIRTUAL DISK = 1.2MB RSTS virtual disk. FORCE CACHE ALL = The BP2IC2.TSK was forced into the system by using the program listed below. The program that was used to force the compiler into the cache was the following: 10 OPEN "[1,5]BP2IC2.TSK/MO:8448" FOR INPUT AS FILE 1% 20 GET#1%, BLOCK Z% FOR Z%=1% TO 924% 30 END The system cache was set: CLUSTERSIZE=4 KEEP=15 The system is configured as follows: 11/73B (quad board) CPU Clearpoint QED1 4MB PMI (11/83 type) memory (17% faster than a DEC 73) 1.0MB allocated to cache 1.2MB allocated to the virtual disk RQDX3 disk controller RD53 71MB disk drive The surprise in this was RSTS by itself *DID NOT* use cache very well. It is clear that if you have a large enough cache and the system to yourself you should force load the BP2 compiler into the system cache via the program above. It it also clear if you have enough memory, you have the system to yourself, and you don't mind 100% of the CPU going to the BP2 compile, then you should place the compiler and the work files on the virtual disk. Bytes 47-50 in block 7 of the compiler task image (BP2IC2.TSK) contain where the work files are to be located. Comments about the RSTS cache should be made in the RSTS_OS conference. ================================================================================ Note 65.8 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 8 of 9 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 15 lines 30-AUG-1989 22:08 -< 4-byte RMS Key problem >- -------------------------------------------------------------------------------- Using BASIC-Plus-2 v2.3 under RSX-11M v4.1, I am trying to open an RMS indexed file. The primary key is a LONG, which the compiler accepts, but fails at run time with error 160 (File attributes not matched). The file was created and loaded on RSX using the standard RMS utilities. RMSDSP shows the key type as Binary, Length=4. If the exact same data is used to build a file where the primary key is a WORD (with the matching change to the BP2 program), it works just fine. If I compile and run on a VAX (as a LONG), it also works just fine. Since my key values range to 99999, and the customer only has a PDP-11, this is not a solution. Am I doing something wrong, or is this a bug? Is it fixed in a later release? ================================================================================ Note 65.9 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 QUESTIONS 9 of 9 EISNER::KENNEDY "Terry Kennedy" 6 lines 31-AUG-1989 06:07 -< Example? >- -------------------------------------------------------------------------------- > Since my key values range to 99999, and the customer only > has a PDP-11, this is not a solution. Am I doing something > wrong, or is this a bug? Is it fixed in a later release? Could be (bug/fixed). Why don't you Mail me a short sample program and I'll try it under V2.6 (current).  ================================================================================ Note 66.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:06 -------------------------------------------------------------------------------- This is a reserved topic  ================================================================================ Note 67.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:07 -------------------------------------------------------------------------------- This is a reserved topic  ================================================================================ Note 68.0 [PDPBAS]RSTS BASIC-PLUS FUTURES No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:09 -------------------------------------------------------------------------------- This topics is to be used to discuss wish list items for RSTS Basic-Plus.  ================================================================================ Note 69.0 [PDPBAS]RT-11 BASIC-PLUS FUTURES No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:11 -------------------------------------------------------------------------------- This topics is to be used to discuss wish list items for RT-11 Basic-Plus.  ================================================================================ Note 70.0 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 FUTURES 2 replies EISNER::KILLEEN 2 lines 26-JUN-1987 00:12 -------------------------------------------------------------------------------- This topics is to be used to discuss wish list items for PRO, RSX, and RSTS Basic-Plus-2. ================================================================================ Note 70.1 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 FUTURES 1 of 2 EISNER::KILLEEN "Jeff Killeen" 17 lines 7-MAR-1988 20:50 -< BUILT IN FAST MAP FUNCTION >- -------------------------------------------------------------------------------- I have just finished a major project that required fast mapping. BP2 needs a built in function to take advantage of fast mapping. Every time you do a fast map call through an external function call you get at least an extra 14 instructions. 7 register saves and 7 register restores. With a built in function they could cut this way down. You may say who cares about 14 instructions? You do it 100000's of times a day and it adds up. We need two fast map calls. FASTMAP1(apr_code,region_offset) FASTMAP2(apr_code,region-offset,window_length) The data returned would be the contents of R0 (IS.SUC). ================================================================================ Note 70.2 [PDPBAS]PRO, RSX, RSTS BASIC-PLUS-2 FUTURES 2 of 2 EISNER::CONROY "Alan Conroy" 3 lines 12-AUG-1988 12:33 -< How about a heap? >- -------------------------------------------------------------------------------- Including a heap mechanism (like those in Pascal or C) would be a real help. At the risk of making it RSTS/E specific: A un-named dynamic region could be used to implement it.  ================================================================================ Note 71.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:12 -------------------------------------------------------------------------------- This is a reserved topic.  ================================================================================ Note 72.0 [PDPBAS]RESERVED No replies EISNER::KILLEEN 1 line 26-JUN-1987 00:13 -------------------------------------------------------------------------------- This is a reserved topic.  ================================================================================ Note 73.0 [RSX]RSX for the PRO? 14 replies EISNER::EISNER "Dan L. Eisner" 31 lines 30-JUN-1987 19:27 -------------------------------------------------------------------------------- The following notes were extracted from the errors conference. It sounds like it may be a good topic for RSX. <<< EISNER::DUA0:[NOTES$LIBRARY]ERRORS.NOTE;1 >>> -< Our Errors >- ================================================================================ Note 12.22 DCL trouble 22 of 23 EISNER::MCCARTHY 5 lines 30-JUN-1987 13:50 -< P/OS?? >- -------------------------------------------------------------------------------- Funny, I have no trouble with my PRO at all. But, then again, I'm running Micro/RSX V3.0. -Brian ================================================================================ Note 12.23 DCL trouble 23 of 23 EISNER::FRISBIE "Alan E. Frisbie" 8 lines 30-JUN-1987 14:52 -< Real RSX for the PRO! >- -------------------------------------------------------------------------------- >> Funny, I have no trouble with my PRO at all. But, then again, >> I'm running Micro/RSX V3.0. Is there any way a user can obtain Micro/RSX for the PRO? A friend of mine would like very much to make the switch, and I might even buy a PRO if I could run real RSX on it. Alan ================================================================================ Note 73.1 [RSX]RSX for the PRO? 1 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 13 lines 1-JUL-1987 11:16 -< The "Let 'em eat cake" department >- -------------------------------------------------------------------------------- > Funny, I have no trouble with my PRO at all. But, then again, > I'm running Micro/RSX V3.0. > > -Brian It's comments like that that make the peasants storm the Bastille with pitchforks and torches! Seriously, there are many of us out here who would like to turn our PROs into something really useful with a "real" operating system. ================================================================================ Note 73.2 [RSX]RSX for the PRO? 2 of 14 EISNER::COVERT "John Covert" 5 lines 1-JUL-1987 13:38 -< You probably don't want it >- -------------------------------------------------------------------------------- What Brian doesn't tell you is that (unless things have changed) Micro/RSX V3.0 for the PRO doesn't support the PRO bitmap terminal. Brian has a VTxxx plugged into the printer/console port. /john ================================================================================ Note 73.3 [RSX]RSX for the PRO? 3 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 15 lines 1-JUL-1987 18:42 -< That's not the real problem >- -------------------------------------------------------------------------------- A lot would depend on how it was genned. If you look at an M-Plus kit you can see support for the PRO in conditional code. And if you look at the PRO Microfiche, you can see the drivers. Since P/OS is basically emasculated M-Plus, there is no reason why Micro-RSX couldn't be genned with the bitmap driver. The only "real" question is how much it would cost DEC to develop the kit (mostly packaging, SDC, and cataloging and literature costs, which I believe would cost more than actually genning the kit) and how much they could get in revenue from selling it. I think DEC would also receive a huge benefit in increasing the good will of the many customers who would appreciate the kit and would be better disposed twords buying things from DEC, but it's very hard to put a dollar value on that when trying to convince a business manager to support a product. ================================================================================ Note 73.4 [RSX]RSX for the PRO? 4 of 14 EISNER::COVERT "John Covert" 8 lines 1-JUL-1987 19:51 -------------------------------------------------------------------------------- It isn't quite that simple; the bitmap driver doesn't support the normal CLI interface; that would have to be added and debugged before it could be used at all. In fact, isn't that really the main difference between P/OS and RSX: CLI support and the terminal interface to the CLI? /john ================================================================================ Note 73.5 [RSX]RSX for the PRO? 5 of 14 EISNER::MCCARTHY 11 lines 1-JUL-1987 20:15 -------------------------------------------------------------------------------- Before I'm swamped: NO, Nobody can have a copy of RSX for the PRO. Don't feel bad, I won't give it out inside DEC either. We did some work on the project and then abandoned it due to business reasons. It is running on one PRO-380. It is not finished and would take a goodly amount of work to make useful. -Brian ================================================================================ Note 73.6 [RSX]RSX for the PRO? 6 of 14 EISNER::MCCARTHY 54 lines 1-JUL-1987 20:30 -< A few missing details >- -------------------------------------------------------------------------------- And before John and Bart kill each other on speculation: The bitmap isn't the problem. I got the bitmap to work in the early days of the project. In fact, one of my favorite pastimes in that corner of the lab is the following: >INS $PIPFSL/PAR=BITMAP/XHR=NO >PIP NL:=[*]*.*;* And then watch pip run on the bitmap display. You have to be careful where the cursor is or the blinking will kill PIP. Why /XHR=no? So that when you hit enough returns and the firmware scrolls PIP, only pip blows up. The system goes away if the header gets scrolled. The major problem with the Bitmap is that part of TTDRV must be 32 word block aligned, so I couldn't easily get the driver to build in one pass, which doesn't help our system build procedure. The major problems which precluded distribution are threefold: 1) One of the organs "emasculated" in P/OS was on-line reconfiguration and HRC. In Micro/RSX, HRC... does disk sizing (so does sav in HRSIZ) and I never finished the code to do disk sizing on the PRO. 2) The system does require a BCC08 and a terminal on the printer port to boot. I never did the SAVe work to get it to understand consoleless systems. 3) To be useful with RSX, you'd have to be able to use the Comm port, and use the real printer port instead of console emulation, and to use the mux board. I never did the port drivers for these. There are also some small items like a SETUP task. Oh yeah, and the firmware don't fit in the installation system all that well. You need a Q-bus to CTI bus bridge to install the software on a PDP-11 and move it to a PRO. Other than that, no problem. Well, XDT needs some work, and there never were any crash drivers done for the PRO disks. But other than that... Oh and Error logging, of course. But other than that... And I don't know if the firmware would work on a 380 with I/D space enabled. Some guy like Alan Frisbie with a M+ 3.0 distribution kit and a P/OS source listing or fiche could finish it, I'm sure. -Brian ================================================================================ Note 73.7 [RSX]RSX for the PRO? 7 of 14 EISNER::FRISBIE "Alan E. Frisbie" 10 lines 1-JUL-1987 20:48 -< Thanks, but no thanks >- -------------------------------------------------------------------------------- >> Some guy like Alan Frisbie with a M+ 3.0 distribution kit and a >> P/OS source listing or fiche could finish it, I'm sure. You are just trying to keep me from working on the VMS project, aren't you? :-) Besides, Jim McGlinchey just finished telling me about all the "wonderful" aspects of the PRO that I wasn't aware of. Now I can see why you compare it (unfavorably) to a bowling ball. Alan ================================================================================ Note 73.8 [RSX]RSX for the PRO? 8 of 14 EISNER::CETRON 7 lines 2-JUL-1987 16:55 -< i take credit for this faux pas >- -------------------------------------------------------------------------------- for those who don't know, I was in spit brook the day brian 'announced' m+ 3.0 for the pro.....so blame me for the peasant rebellion not brian..... -ed ================================================================================ Note 73.9 [RSX]RSX for the PRO? 9 of 14 EISNER::TABOR "Bill Tabor" 5 lines 2-JUL-1987 19:21 -< RSX-11M FOR THE PRO >- -------------------------------------------------------------------------------- There is a version of RSX-11m running on the PRO. It was developed at Racal-Milgo by the D.E.C. resident software person. This software has been the field for over a year. It is running a turn key application so I do not know if everything is there. I'll call overthere next week and get some more information. ================================================================================ Note 73.10 [RSX]RSX for the PRO? 10 of 14 EISNER::MCCARTHY 15 lines 6-JUL-1987 17:38 -< It's the same software >- -------------------------------------------------------------------------------- > There is a version of RSX-11m running on the PRO. It was developed > at Racal-Milgo by the D.E.C. resident software person. It is RSX-11M-PLUS, not RSX-11M. The specialist took the work we had done very early and got it to work for his applications. It has all of the restrictions I mentioned earlier, works only on the bounded configuration @ Racal-Milgo, (It uses a terminal on the printer port and doesn't support the bitmap) and DEC has no intention of making it available elsewhere. It is also stuck (I beleive) at an unsupported (or supported for Racal-Milgo under their specific contract) version of RSX-11M-PLUS. -Brian ================================================================================ Note 73.11 [RSX]RSX for the PRO? 11 of 14 EISNER::RICE "Gary Rice" 10 lines 29-AUG-1987 10:33 -< Spread the word >- -------------------------------------------------------------------------------- > . . . aren't you? :-) Besides, Jim McGlinchey just finished telling > me about all the "wonderful" aspects of the PRO that I wasn't > aware of. Now I can see why you compare it (unfavorably) to > a bowling ball. Just WHAT did Jim tell you? My PRO objects VIOLENTLY to being rolled down the street. Gary ================================================================================ Note 73.12 [RSX]RSX for the PRO? 12 of 14 EISNER::MCGLINCHEY "Cape Malleum Majorem" 15 lines 30-AUG-1987 10:43 -< What Jim told Alan... >- -------------------------------------------------------------------------------- >>< Note 14.11 by EISNER::RICE "Gary Rice" > >> -< Spread the word >- >> >>> . . . aren't you? :-) Besides, Jim McGlinchey just finished telling >>> me about all the "wonderful" aspects of the PRO that I wasn't >>> aware of. Now I can see why you compare it (unfavorably) to >>> a bowling ball. >> >>Just WHAT did Jim tell you? My PRO objects VIOLENTLY to being rolled >>down the street. ... all the way to the sewer. Jim. ================================================================================ Note 73.13 [RSX]RSX for the PRO? 13 of 14 EISNER::ETHINGTON "Superior Klingon Technology" 89 lines 3-SEP-1987 00:32 -< A bowling ball????? >- -------------------------------------------------------------------------------- Awwwwwllllrite, enough snide sniping at the Pro hardware. If you got the whole poop, you would see that Pros have both flashes of brilliance in hardware design as well as flashes of, er, well, uh, less than inspired engineering and marketing influence there on. Good stuff: CTI Bus - cheap to manufacture, excellent architecture with inherent diagnostics and boot roms on each card, very easy to install and remove cards. No programming for a fixed vector and CSR, both are a function of the slot you stick a card into and drivers can easily handle slot independance of hardware. Many cards have dedicated lines on the CTI bus to their connectors, eliminating a lot of cabling. Interrupt controllers on mother board instead of each card - lower cost cards again, only slightly nastier to program Relatively affordable and portable - try being a consultant, paying big zorkmids for a Micro-11 chassis 11/53, and THEN try lugging it around in your front seat to various customer sites - not a pretty picture. Micro-11 box is not so darned Micro if you have to move it around a lot. Built-in printer port, communications port, and Ethernet port (not the card, just the connector) on every Pro. No cabling necessary for Ethernet card, either - the card to Ethernet port is wired into the CTI bus backplane, so you just slap in a DECNA and go. DECNA Ethernet card - VERY high performance, has 128KB of on board dual ported memory for buffers. Actually has higher throughput than either DEUNA or DEQNA - not sure about DELUA/DELQA. Could have been done better: Bitmap memory - should have been more of it with higher resolution so that the pixel aspect ratio would have been 1:1, (1 pixel vertically would be the same size/distance as one pixel horizontally). Although that would have meant more bitmap memory and more expensive video control hardware and monitors, this would have made the software for driving the bitmap MUCH more simple and faster. Video graphics assist controller - one or two more functions (like partial screen vertical scroll assist) would have greatly improved video performance. No character generator for video - absolutely ALL functions are done in software, even loading individual bits in the bitmap to make characters. For years, I thought this was just awful; recently, however, I admit that this gives tremendous flexibility, since to get new video functionality all you have to do is put in new software. Performance has greatly improved over the years, too - 350 systems cruise at about 7900 baud, and 380 systems at about 11800 baud - and blinking the cursor now costs less than .5% of the CPU. For instance, P/OS V3.0 shipped new terminal software that adds full VT200 functionality including down-line-loadable character sets. Try asking a Rainbow owner with his high-speed character generator if he can do that. Rotten stuff: The absolute WORST disk controllers ever conceived by the mind of man. Non-DMA, restricted to devices with 8 or fewer heads - absolutely AWFUL. Should have been replaced years ago by an RQDX3 for the CTI bus. Limited number of slots - particularly a problem on 325/350s. 350s and 380s have 6 slots, and you can't hook up an expansion box to get more. On 350s, you have to dedicate one slot to memory and one to the video controller. On all systems, the floppy controller takes a slot and each winchester controller takes a slot. 350 needed one more slot if you added extended bitmap card for color support. Get a 350, a winchester, and color and suddenly you're down to one lousy slot to hold Ethernet, more memory, TMS option, etc. This would have been greatly improved by a CTI bus RQDX3, since that would merge 3 cards (two winchester controllers, one floppy controller) into one slot. Additions and couterpoints welcome, all..... Jerry ================================================================================ Note 73.14 [RSX]RSX for the PRO? 14 of 14 EISNER::MCCARTHY 54 lines 21-SEP-1987 18:32 -< One man's opinion >- -------------------------------------------------------------------------------- Taking off my DEC spokesengineer hat and being simply an engineer: > CTI Bus - cheap to manufacture, excellent architecture with > inherent diagnostics and boot roms on each card, very > easy to install and remove cards. No programming for > a fixed vector and CSR, both are a function of the slot > you stick a card into and drivers can easily handle > slot independance of hardware. Many cards have dedicated > lines on the CTI bus to their connectors, eliminating > a lot of cabling. All good points, and I think these were all good product features, but where is the law forbidding the Q-bus to do these things? > Built-in printer port, communications port, and Ethernet port > (not the card, just the connector) on every Pro. No > cabling necessary for Ethernet card, either - the card > to Ethernet port is wired into the CTI bus backplane, > so you just slap in a DECNA and go. Same comment > No character generator for video - absolutely ALL functions > are done in software, even loading individual bits in > the bitmap to make characters. For years, I thought > this was just awful; recently, however, I admit that > this gives tremendous flexibility, since to get new > video functionality all you have to do is put in new > software. Performance has greatly improved over the > years, too - 350 systems cruise at about 7900 baud, > and 380 systems at about 11800 baud - and blinking the > cursor now costs less than .5% of the CPU. For instance, > P/OS V3.0 shipped new terminal software that adds full > VT200 functionality including down-line-loadable character > sets. Try asking a Rainbow owner with his high-speed > character generator if he can do that. 2 gazillion years of software down the tubes because the thing doesn't have a *&&^%$ console at 177560/60. In my opinion, this was the worst decision made in the product. > The absolute WORST disk controllers ever conceived by the mind > of man. Non-DMA, restricted to devices with 8 or fewer > heads - absolutely AWFUL. Should have been replaced > years ago by an RQDX3 for the CTI bus. Oh, yeah? Ever BENCHMARK the suckers? The bottom line is this: Most RSX transfers are 1 block. On the PRO, you tell it about the block in 20 instructions and then spend 256. instructions copying the data. On the RQDX you spend 500 instructions coaxing the controller to copy it for you. -Brian  ================================================================================ Note 74.0 [PRO300]PRO/Comm , et. al. 2 replies EISNER::RICE "Gary Rice" 132 lines 1-JUL-1987 09:55 -------------------------------------------------------------------------------- The following notes have been moved from the ERRORS conference. Gary ================================================================================ Note 12.13 DCL trouble 13 of 24 EISNER::LEDERMAN "Bart Z. Lederman" 16 lines 21-JUN-1987 15:49 -< Problems with PCs >- -------------------------------------------------------------------------------- You will have noticed that, when you use a Rainbow by itself or with most emulation packages, you get a VT102 equivalent: this means that the VT220 keys (Find, Select, Do, Next Screen) will not work. Only packages that do true VT220 emulation (rather than the built-in VT102 emulation) will get you the extra keys. I see something similar: I use a PRO which, in PRO mode, does do VT220 emulation including the extra keys. However, I think Notes doesn't properly recognize a PRO as being a VT220 equivalent as I don't get the extra keys unless I execute a local command to turn them on. VMS does know that a PRO does the same as a VT220/VT240 but gives it a separate terminal type. Has anyone else seen this? Does a VT220/VT240 get the extra keys by default when a SET TERM/INQ has set the terminal to the correct terminal type? ================================================================================ Note 12.14 DCL trouble 14 of 24 EISNER::HYDE "Mark Hyde" 9 lines 22-JUN-1987 07:59 -< PRO works great for me >- -------------------------------------------------------------------------------- Bart, What version of P/OS and PRO/Comm are you using? I almost always use a PRO as my DECUServe terminal and get VT220 mode just fine. I'm using P/OS V3.0 and PRO/Comm V3.0. Which 'extra keys' specifically are you referring to? mark ================================================================================ Note 12.15 DCL trouble 15 of 24 EISNER::LEDERMAN "Bart Z. Lederman" 7 lines 22-JUN-1987 18:52 -< My version of P/OS is older >- -------------------------------------------------------------------------------- I use P/OS 2.0 and PRO/Comm 2.0 The "extra keys" are the keys not found on a VT220: The extra keypad labeled Find, Insert Here, Remove, Select, etc, and the top row (F5 through F20). I can switch them on manually but they are not activated by notes the way the basic keypad (0 through 9 and PF1 to PF4) are. ================================================================================ Note 12.16 DCL trouble 16 of 24 EISNER::HYDE "Mark Hyde" 7 lines 23-JUN-1987 08:40 -< that's the problem >- -------------------------------------------------------------------------------- It's the version that you are using. PRO/Comm 2.0 wasn't a 'real' 220 emulation. It identified as 200_series but behaved as you describe. It wasn't till version 3.0 that we had 'real' 200 series emulation. mark 'PRO/Comm Support in a former life' ================================================================================ Note 12.17 DCL trouble 17 of 24 EISNER::LEDERMAN "Bart Z. Lederman" 15 lines 23-JUN-1987 14:08 -< Another dissatisfied DEC customer >- -------------------------------------------------------------------------------- > It identified as 200_series but behaved as you describe. Actually it identifies itself as a PRO_series, but I know what you mean. I'm still very upset that ReGIS emulation only works in communication mode and not "locally", and that it doesn't even really emulate a VT125 in communication mode (won't upload SIXEL output to the Comm. line, for example). Like the vast majority of PRO users, I never went to 3.0: it just didn't seem worth while spending a lot of money to buy all new software, with no trade in or upgrade allowance, just to use more disk space. The improvements appear to be trivial, at best, and it's not worth sinking more mony into a PRO. You are about the only person I know who is using 3.0 ================================================================================ Note 12.18 DCL trouble 18 of 24 EISNER::RICE "Gary Rice" 9 lines 24-JUN-1987 10:50 -< Broadening your horizons >- -------------------------------------------------------------------------------- >> worth sinking more mony into a PRO. You are about the only person I >> know who is using 3.0 Based on the letters that I get as the PC SIG Newsletter Editor (PRO specific), I would say that about half of the PRO community has opted to upgrade to P/OS v3. I run BOTH v2 and v3 on separate systems. Gary ================================================================================ Note 12.19 DCL trouble 19 of 24 EISNER::COVERT "John Covert" 5 lines 25-JUN-1987 00:55 -------------------------------------------------------------------------------- And then there are diehards like me, sitting at home here typing on a PRO that's still running the pre-pre-field test, the first version of P/OS that would even boot. /john ================================================================================ Note 12.20 DCL trouble 20 of 24 EISNER::TRAYSER "C J "Buck" Trayser - Notes Addict!" 0 lines 25-JUN-1987 01:33 -< I still have my FT2 doc for P/OS V1.0...Sigh! >- -------------------------------------------------------------------------------- ================================================================================ Note 12.22 DCL trouble 22 of 24 EISNER::MCCARTHY 5 lines 30-JUN-1987 13:50 -< P/OS?? >- -------------------------------------------------------------------------------- Funny, I have no trouble with my PRO at all. But, then again, I'm running Micro/RSX V3.0. -Brian ================================================================================ Note 74.1 [PRO300]PRO/Comm , et. al. 1 of 2 EISNER::ETHINGTON "Superior Klingon Technology" 40 lines 9-JUL-1987 02:22 -< Pro Comm Keypads >- -------------------------------------------------------------------------------- Bart: Pre-3.0 versions of Pro/Comm emulated sort of a VT150; they could do some things that VT1xx terminals couldn't, but not everything that a VT2xx could. The current release of Pro/Comm does give a reasonably complete VT241 emulation, with all keys functional (even with down line loadable key definitions), sixel graphics to your printer support, etc. I highly recommend going to 3.x; there are a HUGE number of cool new features, which many people are not aware of. If you really want a detailed rundown on 3.x features, I suspect we should start a separate note on the subject. As far as getting trade-in or upgrade allowances to make upgrading more economical, a little known fact is that indeed you DO get upgrade discounts. How to get P/OS software (cheap): Plan A: Since you are already a licensed owner of P/OS software and Pro/Comm, you are eligible to buy current releases at the upgrade price instead of the full list price. Upgrades are in the catalogs as the same part number as the normal item, but with an "-HZ" instead of "-AZ"; in other words, you are getting an H kit. Typically, depending on the specific Pro software product, this saves anywhere from 40% to 60%. Plan B: Since you frequently attend Decus symposia, you can roll into the PSG (or whatever they're calling themselves this week) Bookstore in the exhibit hall and pick up P/OS software like P/OS V3.1 (3.2 by Anaheim), Tool Kit, and Pro Comm or Synergy (which includes Pro Comm, Prose-Plus word processing/graphics editor, Calendar, File Services, Data Manager, Graph, Calculator, and Spreadsheet) at discounts of about 50-60%. With either plan, the cost of upgrading to current versions is probably a lot less than you had anticipated; even if you need only a few of the features of P/OS V3.x and Pro Comm 3.x, it might make the upgrade a much more attractive proposition. Jerry Ethington ================================================================================ Note 74.2 [PRO300]PRO/Comm , et. al. 2 of 2 EISNER::LEDERMAN "Bart Z. Lederman" 36 lines 9-JUL-1987 19:28 -< Interesting, sort of. >- -------------------------------------------------------------------------------- > Pre-3.0 versions of Pro/Comm emulated sort of a VT150; they could > do some things that VT1xx terminals couldn't, but not everything > that a VT2xx could. If I manually switch keys (the F5), I can get the top row to work. I rarely bother, though. I've never needed downloaded characters. > I highly recommend going to 3.x; there are a HUGE number of cool > new features, which many people are not aware of. Maybe, but so what. I don't have an LN03, LA75, etc., so I don't need the new device support. I don't really care much about an upgrade to PRO/Comm, because terminal emulation works well enough, and file transfer doesn't work at all. Pro/Host Communications, never worked very well, and most systems don't have it anyway. I use Kermit when I have to stransfer files. I can spawn the tool kit on TT2: if I want to, but rarely use two terminals except on rare occations, and then mostly just to run RMDEMO on the second terminal which I can do by redirecting output without spawaning the tool kit. I rarely use the window systems, so improvements there don't help me. I am concerned about disk space, and will have less of it under 3.x Most of what I do is in the tool kit with DECUS or other RSX software, and for that 2.0 is fine. The information about discounts is interesting. However, I've been in the bookstore during Symposia, and have looked at the prices on the PRO software, and didn't think the prices were all that great. Bottom line: it just isn't worth investing money into my home PRO. I don't need an "official" announcement to know it's abandoned by DEC, and I already have the software (like Fortran and DTR) I need. Any new software I want (like a Basic interpretor, Runoff, "C", etc.) I get from DECUS or write myself.  ================================================================================ Note 75.0 [RSX]BUG IN KMV-11 DRIVER No replies EISNER::TABOR "Bill Tabor" 8 lines 7-JUL-1987 07:10 -------------------------------------------------------------------------------- The Bug is that the Driver is not writen to support I and D space. The fix is to change the kernal registors from pointing to instruction to point to the data area. This Bug has been reported to DEC several times since October 1985 but still is not fixed (thru update D or RSX-11M+).  ================================================================================ Note 76.0 [PRO300]P/OS LA75/LN03 Plus Update No replies EISNER::ETHINGTON "Superior Klingon Technology" 28 lines 9-JUL-1987 02:44 -------------------------------------------------------------------------------- At the Nashville DECUS Sympoium in May, P/OS Engineering distributed (informally) an update to P/OS V3.1 which adds support for LA75 and LN03-Plus printers. The update is on 2 RX50 floppies, and installs much as the P/OS V3.1 update installs on top of V3.0 - you delete the print queues, boot the update floppies (a stand alone update system), follow the instructions on the screen, then reboot the Winchester and add you print queues back. For anyone who did not attend the Nashville symposium, I think the Atlanta telephone support center may give copies to contract customers. For anyone who is not on contract, you can get a copy from someone like myself who did go to Nashville. If you would like to get a copy from me, all I ask is that you send me 2 RX50 preformatted floppies, a note saying what you want, and return label and postage. Anything sent to me not meeting these rules will be cheerfully regarded as a generous donation to foster the advancement of superior Klingon technology. My address: Jerry Ethington Prolifix, Inc. 245 Hawkeegan Drive Frankfort KY 40601 I installed the update as soon as I returned from Decus and tried an LN03 Plus, and had no problems at all with either the update or the added functionality. Haven't tried an LA75 yet - I don't know anyone who has one. Jerry Ethington  ================================================================================ Note 77.0 [PRO300]I need OBSOLETE software 14 replies EISNER::RICE "Gary Rice" 7 lines 11-JUL-1987 07:42 -------------------------------------------------------------------------------- I am about to get a PRO-380. Do you have a copy of P/OS v2.0A (Note the "A" in the version number) available that I could buy, trade, whatever? I don't really want to use P/OS v3 on it and DEC won't/can't provide me a copy of anything besides the OS currently shipping. Gary ================================================================================ Note 77.1 [PRO300]I need OBSOLETE software 1 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 15 lines 11-JUL-1987 18:32 -< You can't sell PRO software >- -------------------------------------------------------------------------------- >I am about to get a PRO-380. Do you have a copy of P/OS v2.0A I feel obligated to point out DEC's licencing policy on PCs, which is exactly the opposite from all other systems. ALL software (operating system and layered products) bought for a PC go with it when it is sold. There are never any extra copies of a product: you either get it from DEC, or you get what comes with a used machine. If you are buying a used machine, make sure you get all of the software which was sold for it (unfortunately, most, if not all, of the equipment brokers don't transfer the software like they are supposed to). If you are buying a new machine, you are going to have to accept what DEC sells you, or work "under the table". ================================================================================ Note 77.2 [PRO300]I need OBSOLETE software 2 of 14 EISNER::RICE "Gary Rice" 20 lines 13-JUL-1987 10:01 -< "Under-the-table?" >- -------------------------------------------------------------------------------- > I feel obligated to point out DEC's licencing policy on PCs, which is > exactly the opposite from all other systems. ALL software (operating > system and layered products) bought for a PC go with it when it is sold. > There are never any extra copies of a product: you either get it from > DEC, or you get what comes with a used machine. I have no problem buying software from DEC, but unlike the VAX and PDP software lines, the PC policy is: Once a new version is shipping, the previous one(s) are NOT AVAILABLE. Now, since I can't get the S/W I need from DEC, I have to look elsewhere. Also, I suspect that if the licensing policy that DEC has were to be challenged in court, the ruling would be "Restraint-of-trade" since what I want, they won't sell, but they won't let me get it from someone else. Which leads me back to the original request: Do you have P/OS v2.0A? Gary ================================================================================ Note 77.3 [PRO300]I need OBSOLETE software 3 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 6 lines 13-JUL-1987 19:02 -< I sort of have 2.0 >- -------------------------------------------------------------------------------- I have P/OS 2.0 and I think it's 2.0A. But I don't have a "real" kit" I have what was on the machine when I bought it used, but the dealer shortchanged me, and it did not come with the manuals or original distribution kit. ================================================================================ Note 77.4 [PRO300]I need OBSOLETE software 4 of 14 EISNER::RICE "Gary Rice" 17 lines 14-JUL-1987 09:53 -< Its easy to tell a 2.0a system >- -------------------------------------------------------------------------------- > I have P/OS 2.0 and I think it's 2.0A. There is a quick way to tell if it is 2.0A. When the system boots up and the "Main Menu" appears, the title line will read 2.0A rather than 2.0. As for documentation, I don't care about that. 2.0 and 2.0a are identical in all respects except for the non-visible changes to support the 380 and RD52. Also, all I really want is the first 4 diskettes, not the complete set. BUT . . . I HAVE to have a set of diskettes that will actually install a system. Gary ================================================================================ Note 77.5 [PRO300]I need OBSOLETE software 5 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 8 lines 14-JUL-1987 20:32 -< Main Menu? >- -------------------------------------------------------------------------------- >There is a quick way to tell if it is 2.0A. When the system boots up >and the "Main Menu" appears, the title line will read 2.0A rather >than 2.0. Who looks at the main menu? I have my system set to go directly into the tool kit. ================================================================================ Note 77.6 [PRO300]I need OBSOLETE software 6 of 14 EISNER::RICE "Gary Rice" 12 lines 15-JUL-1987 09:58 -< Is it done with mirrors? >- -------------------------------------------------------------------------------- > Who looks at the main menu? I have my system set to go directly > into the tool kit. Sounds like a "hack" to me. Did you modify the startup task? As far as I can tell, avoiding the Main Menu was formally supported with P/OS v3, but not before. I will see if I can find out if the Logical "POS$VER" gives any clue about the version level. Gary ================================================================================ Note 77.7 [PRO300]I need OBSOLETE software 7 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 9 lines 15-JUL-1987 19:27 -< It's documented somewhere >- -------------------------------------------------------------------------------- > -< Is it done with mirrors? >- No, it's done with a file called FIRSTAPPL.PTR (or something like that) which has the name of the directory of the application you want P/OS to go into when you boot the system. It can be any P/OS application, and in my case it's the tool kit. It is a documented, but apparently not well known feature of P/OS. I can, of course, press the EXIT key and go back to the menues if I ever want to. ================================================================================ Note 77.8 [PRO300]I need OBSOLETE software 8 of 14 EISNER::ETHINGTON "Superior Klingon Technology" 10 lines 16-JUL-1987 00:26 -< Moth Eaten Software >- -------------------------------------------------------------------------------- Gary, I've still got an official copy lying around. Send me blank floppies and I'll roll you off a copy. I don't think anyone cares if a licensed user, which as an owner of P/OS version x.x you are, grabs an OLD copy of software they are licensed for - clearly they would like to get money, and rightfully so, for a newer version than the one you are licensed for (an upgrade), but I don't think they would care to charge for a downgrade. Jerry ================================================================================ Note 77.9 [PRO300]I need OBSOLETE software 9 of 14 EISNER::RICE "Gary Rice" 12 lines 18-JUL-1987 10:20 -< Sounds like Vaporware to me . . . >- -------------------------------------------------------------------------------- > No, it's done with a file called FIRSTAPPL.PTR (or something > like that) which has the name of the directory of the application you > want P/OS to go into when you boot the system. It can be any P/OS > application, and in my case it's the tool kit. It is a documented, but > apparently not well known feature of P/OS. I've looked EVERYWHERE I can think of to find the documentation you mention. Can you be more specific? Gary ================================================================================ Note 77.10 [PRO300]I need OBSOLETE software 10 of 14 EISNER::ETHINGTON "Superior Klingon Technology" 15 lines 20-JUL-1987 00:31 -< A Kludge for All Seasons >- -------------------------------------------------------------------------------- He's right; long, long ago when I was using P/OS 2.0, I found the note and used the method to fire up Tool Kit when the system booted. If I recall correctly, it is mentioned in the first chapter or two of the old 2.0 Tool Kit reference manual or User's Guide, one or the other. The deal was, you create LB:[ZZSYS]FIRSTAPPL.PTR, which contains exactly one line - the directory name where the .INS file lives, without brackets, and padded on the right if necessary to a length of 9 characters. Not necessary on 3.0 or later systems; you can set up an application to start at login time on an account's user environment services menu, and you can define an account to be automatically logged into at boot time via system environment services, account management, so the old somewhat nasty functionality is no longer needed. Jerry ================================================================================ Note 77.11 [PRO300]I need OBSOLETE software 11 of 14 EISNER::HYDE "Mark Hyde" 7 lines 21-JUL-1987 15:23 -< beware of FIRSTAPPL.PTR >- -------------------------------------------------------------------------------- Just beware that on V2.0 systems, if you screw up FIRSTAPPL.PTR, (i.e spell the directory name wrong), your system is sunk. A fouled up FIRSTAPPL.PTR renders the PRO unbootable. mark 'former P/OS hack' ================================================================================ Note 77.12 [PRO300]I need OBSOLETE software 12 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 6 lines 21-JUL-1987 19:57 -< Gosh, it worked for me >- -------------------------------------------------------------------------------- > Just beware that on V2.0 systems, if you screw up FIRSTAPPL.PTR, > (i.e spell the directory name wrong), your system is sunk. Odd: I've found that if it was spelled wrong, it just didn't do anything with it and went into the normal main menu. ================================================================================ Note 77.13 [PRO300]I need OBSOLETE software 13 of 14 EISNER::HYDE "Mark Hyde" 5 lines 22-JUL-1987 12:38 -< Well, I did say 'former' >- -------------------------------------------------------------------------------- Could be a memory failure on my part. Maybe it was in V1.7 that is was dangerous and it got fixed in V2.0 to be less so. mark ================================================================================ Note 77.14 [PRO300]I need OBSOLETE software 14 of 14 EISNER::LEDERMAN "Bart Z. Lederman" 7 lines 4-NOV-1988 09:24 -< Anyone have the Tek 4014 emulator? >- -------------------------------------------------------------------------------- On the subject of "obsolete" software for the PRO: does anyone have a copy of the Tektronix 4014 terminal emulator which used to be available for the PRO? It was sold by DEC, but was probably written by a third party vendor. I think it was discontinued before P/OS went to 3.0, but that's O.K. as I still run 2.0. I would like to be able to do occasional Tek graphics on my PRO if it won't cost too much.  ================================================================================ Note 78.0 [PDPBAS]Interpreted BASIC 1 reply EISNER::LEDERMAN "Bart Z. Lederman" 9 lines 11-JUL-1987 18:48 -------------------------------------------------------------------------------- I would like to propose that this conference go beyond Basic-Plus-2 to include interpreted Basic. I propose both the older BASIC-11 product (which we still run at our company), and Reese Basic (which I now run on my PRO, and which may show up on the VAX). I would even extend it to other Basics, since I'm sure people are going to run Basic on their VAXmates, and even Rainbows. ================================================================================ Note 78.1 [PDPBAS]Interpreted BASIC 1 of 1 EISNER::KILLEEN "Jeff Killeen" 8 lines 11-JUL-1987 19:44 -< GODD IDEA! >- -------------------------------------------------------------------------------- | I would like to propose that this conference go beyond | Basic-Plus-2 to include interpreted Basic. I propose both the older | BASIC-11 product (which we still run at our company), and Reese Basic | (which I now run on my PRO, and which may show up on the VAX). FYI - RSTS BASIC-PLUS and RT11 BASIC-PLUS are interpreters. However, a topic on the above BASICs is a good idea!  ================================================================================ Note 79.0 [RSTS]Newsletter System 8 replies EISNER::KENNEDY "Terry Kennedy" 31 lines 12-JUL-1987 19:35 -------------------------------------------------------------------------------- There is now a RSTS Newsletter system available. This will facilitate electronic submission of newsletter articles, as well as a way for SIG members who are interested to contact SIG leadership. The system also has available on-line the combined spring/fall 86 SIG tape. Other items on-line are back issues of the newsletter (starting w/ the August 87 issue). MAIL is available for sending messages, and Kermit is available for up- and down-loading files. To access the system, call (201) 435-2546 at 300 or 1200 baud, 24 hours, 7 days a week. Press until you get the RSTS login banner, then use 2,1 as your account number. No password is required. If you would like a 'real' account as opposed to a guest account, MAIL a request to NEWS. Be sure to include a telephone number where you may be contacted so I can tell you what your account and password are. The system currently is composed of the following hardware: Micro PDP-11/23 w/ FPA, CIS 2 Mb memory 2 RD52 (30 Mb each) disk drives 1 DHV11 (8 terminal ports) 1 TSV05 tape 1 DEQNA Ethernet to other systems If you can think of any other items you'd like to see on the newsletter, or have any comments, you can either make replies here, send MAIL to KENNEDY on this system, or send MAIL to NEWS or TERRY on the newsletter system itself. ================================================================================ Note 79.1 [RSTS]Newsletter System 1 of 8 EISNER::KENNEDY "Terry Kennedy" 8 lines 16-JUL-1987 02:29 -< More Info >- -------------------------------------------------------------------------------- A number of people have asked me where the SIG tapes are stored. They are currently in accounts [50,*]. Newsletter back issues are in account [49,0]. Note that to me a 'back issue' is the one that will be published in two months, so if you're desperate to see the latest news, give the system a call. More information on where things are stored is available with the com- mand HELP NEWSLETTER once you are logged on. ================================================================================ Note 79.2 [RSTS]Newsletter System 2 of 8 EISNER::KENNEDY "Terry Kennedy" 14 lines 5-AUG-1987 04:27 -< Field Testers Needed for CB >- -------------------------------------------------------------------------------- I am *considering* making modifications to Phil Hunt's CB program to allow it to run across the Ethernet with RSTS/E 9.4 or later. DECNET isn't required, although Ethernet hardware is. This will allow the for- mation of truly massive CB sessions, like those found on Compuserve. If you are interested in Field Testing this software, MAIL me a note here on decuserve, or call the newsletter system (see .0) and mail a note to TERRY there, giving name, address, phone, and media type re- quired. Just as with DEC, I make no commitment that this software will be released ever, in any form, etc, etc. Notwithstanding that, I would like to have enough Field Test input so that I can submit a tape to the DECUS program library at Anaheim. ================================================================================ Note 79.3 [RSTS]Newsletter System 3 of 8 EISNER::KILLEEN "Jeff Killeen" 1 line 5-AUG-1987 08:58 -< ? >- -------------------------------------------------------------------------------- What is the "CB" program? ================================================================================ Note 79.4 [RSTS]Newsletter System 4 of 8 EISNER::KENNEDY "Terry Kennedy" 22 lines 6-AUG-1987 03:38 -< What CB is... >- -------------------------------------------------------------------------------- >> What is the "CB" program? Oops! I thought everybody knew... 'CB' is a program written by Phil Hunt (formerly of SI, now of DEC) which allows users on a single RSTS system to communicate with each other using a system similar to a CB radio. Think of NOTES with all parties talking at once, with no storage of the conversation, and you'll sort of get the idea. Many of the large 'consumer timesharing' outfits like Compuserve offer a service like this. In fact, Compuserve's is called CB also, although it isn't the same program. The difference between them and the DECUS library CB program is that DECUS CB is limited to the number of people you can load onto one RSTS system. My mods change that by allowing it to have a CB session across the whole DECNET. Imagine this running on a net like DEC's internal net. You could have 40 conferences (40 CB channels) going at once, in- volving possibly thousands of users, instead of the 63 maximum with one RSTS system. Terry ================================================================================ Note 79.5 [RSTS]Newsletter System 5 of 8 EISNER::KENNEDY "Terry Kennedy" 6 lines 27-AUG-1987 22:54 -< User needs documentation >- -------------------------------------------------------------------------------- Help - A user needs the documentation for the RSTS to IBM protocol converter/emulator products, which DEC no longer sells. Please see note 26.0 in the DEC_SOFTWARE conference for all the details... Thanks, Terry Kennedy ================================================================================ Note 79.6 [RSTS]Newsletter System 6 of 8 EISNER::KENNEDY "Terry Kennedy" 2 lines 3-OCT-1987 04:52 -< No November Newsletter >- -------------------------------------------------------------------------------- There won't be a RSTS SIG Newsletter in November - things were just too crazy around here with the start of school. Look for a big one in Dec. ================================================================================ Note 79.7 [RSTS]Newsletter System 7 of 8 EISNER::KENNEDY "Terry Kennedy" 7 lines 17-NOV-1987 19:29 -< New phone # for Newsletter system >- -------------------------------------------------------------------------------- The telephone number of the Newsletter system has changed - the new number (effective immediately) is (201) 915-9361 [yes, 915!]. There is a recording on the old number directing people to the new one. I will keep it on until I have to give the old # back to the phone co. Also, there are now 2 modems, but still 1200 baud. At least it won't be busy so often with two lines. ================================================================================ Note 79.8 [RSTS]Newsletter System 8 of 8 EISNER::KENNEDY "Terry Kennedy" 7 lines 25-MAR-1988 22:46 -< 1987 tape copy tape now available >- -------------------------------------------------------------------------------- The combined Spring/Fall 1987 RSTS SIG 'tape copy' tape is now on- line on the newsletter system. It can be found in accounts [87,*] on the system disk. See previous notes in this topic for information on accessing the system. The tape should also be filtering through the local tape copy sys- tem at this time.  ================================================================================ Note 80.0 [RSTS]SYSTEM MANAGEMENT - H & K 13 replies EISNER::HORN "Larry Horn" 6 lines 14-JUL-1987 04:10 -------------------------------------------------------------------------------- This topic is for the discussion of global system management techniques. This is not for 'my favorite break-in technique', nor is it for explicit discussion of 'holes' in security. Discussions which may compromise the security of systems will be removed. ================================================================================ Note 80.1 [RSTS]SYSTEM MANAGEMENT - H & K 1 of 13 EISNER::LEFEBVRE "Kenneth LeFebvre" 32 lines 15-JUL-1987 08:45 -< Account Structures, How? >- -------------------------------------------------------------------------------- What have most people found to be the best method of organizing accounts? Being a development house, we have several different packages up and running (and being modified) at one time. Employees are divided into projects, but an employee may be in more than one project at a time. We have DECmail, so we would like to be able to keep a person to one account. Example: Programmers: Projects: Karl DIBS, LMS Joe XYZ, ABC Jerry ABC, DEF, DIBS Martha XYZ, DIBS, LMS Assume that file protections are vital across project boundaries. If I put Karl, Jerry, and Martha in one Group for DIBS, then Karl will not have the privileges to get at the XYZ files (if I set the file protection codes down then Jerry will be able to get at them, too). I currently have all programmers in one group and all operators in another group. I have compromised security by lowering file protection codes as necessary. However, we are looking at going online and possibly even hook into a network. Before we do that, our security must be higher. How have others done this? ================================================================================ Note 80.2 [RSTS]SYSTEM MANAGEMENT - H & K 2 of 13 EISNER::MCALLISTER "Brian McAllister" 12 lines 26-FEB-1988 20:25 -< Disk defrag. anyone? >- -------------------------------------------------------------------------------- Does anyone have any experience with disk-defragmentation under RSTS? I am looking into DISKIT/RSTS, but it requires copying to a second disk and back. Is it really impossible to do it online (like RSX and VMS)?? Can similar consolidation be achieved by restoring a full backup? Do you have to actually delete the original files first? Any suggestions? (Also, is it worth the trouble?) ================================================================================ Note 80.3 [RSTS]SYSTEM MANAGEMENT - H & K 3 of 13 EISNER::KENNEDY "Terry Kennedy" 20 lines 26-FEB-1988 23:17 -------------------------------------------------------------------------------- > Can similar consolidation be achieved by restoring a full backup? > Do you have to actually delete the original files first? 1) Yes 2) Here is how we do it a) BACKUP/VERIFY/EXCLUDE=([0,1]SWAP?.SYS) inspec outspec b) Invoke [0,1]RECOVR.COM to create a 'recover tape' - the only place this is documented is in the 9.0 relnotes c) Shutdown d) Boot recover tape. DSKINT system disk w/ use bad=y, pat=0, erase= e) Re-boot recover tape, re-load monitor+DCL+BACKUP f) Boot system disk, re-create swapfiles g) Restore backed up data > Any suggestions? (Also, is it worth the trouble?) The above can be a real pain. We don't see any big gain, but then our disks are pretty static. Frequent (nightly) REORDRing seems to help more. ================================================================================ Note 80.4 [RSTS]SYSTEM MANAGEMENT - H & K 4 of 13 EISNER::HORN "Larry Horn" 9 lines 27-FEB-1988 16:45 -< file positions >- -------------------------------------------------------------------------------- Can the RECOVR command file be modified to POSITION the files when it does it initial restore? (I'm at home and can't look it up.) By default it restores all the system files to the lowest clusters of the disk (or maybe marking the files positioned would work?). I usually rebuild to a spare disk and HOOK it rather than using RECOVR.COM. HOOK is documented in Release note "Seq 22.3.1". This way I can put every file just where I want it. ================================================================================ Note 80.5 [RSTS]SYSTEM MANAGEMENT - H & K 5 of 13 EISNER::KENNEDY "Terry Kennedy" 11 lines 27-FEB-1988 20:02 -< Not so important (for us) because... >- -------------------------------------------------------------------------------- > Can the RECOVR command file be modified to POSITION the files when > it does it initial restore? (I'm at home and can't look it up.) Since the RECOVR tape is not a Backup tape, setting the position bit for the files probably won't help. However, consider the following: Most of the files RECOVR brings back are not kept open during time- sharing, or are used only during recovery or startup (like INIT.SYS and SYSGEN.SIL). Your SIL will be restored placed if it was placed to start with. If you /REPLACE on the BACKUP command line, things like PIP and DCL will be replaced with the placed versions as well. ================================================================================ Note 80.6 [RSTS]SYSTEM MANAGEMENT - H & K 6 of 13 EISNER::CONROY "Alan Conroy" 28 lines 9-AUG-1988 14:56 -< Don't backup/restore >- -------------------------------------------------------------------------------- > I am looking into DISKIT/RSTS, but it requires copying to a > second disk and back. Is it really impossible to do it online > (like RSX and VMS)?? I was sick of not being able to on-line disk defragmentation on RSTS/E so I wrote my own program to do this. It seems to work OK (except for a bug which causes it to hibernate while trying to find the next file to reorder). If you're interested, I could see if management will let me give it out (not as easy as it might seem when you're working for a software company). > Can similar consolidation be achieved by restoring a full backup? > Do you have to actually delete the original files first? Yuk! I HIGHLY recommend that you do NOT do reorgs in this manner. Any decent reorg package (such as DISKIT or DSKBLD) will be more efficient simply because a backup/restore only defragments files and cleans up UFDs. Granted that is the major concern, however, they also create scratch areas (good if your pre-V9.5), and reorder the UFDs to have most recently accessed files at the beginning of the directory. The worst thing about backup/restore is that for a period of time you ONLY have your data on tape. What happens if you have a soft spot on the tape that can't be read at restore time (especially in the middle of DCL.RTS, etc). Tapes are about the weakest link of any data storage system and I trust them as little as possible. A disk to disk copy is MUCH preferrable. > (Also, is it worth the trouble?) I say YES! ================================================================================ Note 80.7 [RSTS]SYSTEM MANAGEMENT - H & K 7 of 13 EISNER::MCALLISTER "Brian McAllister" 24 lines 10-AUG-1988 18:22 -< Share it if you can. >- -------------------------------------------------------------------------------- > I was sick of not being able to on-line disk defragmentation on RSTS/E so >I wrote my own program to do this. It seems to work OK (except for a bug which >causes it to hibernate while trying to find the next file to reorder). If >you're interested, I could see if management will let me give it out (not as >easy as it might seem when you're working for a software company). Yes, I am interested, and I would think that others would be too. If your company will let you, you should submit it to the DECUS library. >decent reorg package (such as DISKIT or DSKBLD) will be more efficient simply What is DSKBLD? >They also create scratch areas (good if your pre-V9.5) Why are scratch areas less important with V9.5? >reorder the UFDs to have most recently accessed files at the beginning >of the directory. For the kind of work we do here, this isn't really that important. Besides, this can be done independent of de-fragmentation. ================================================================================ Note 80.8 [RSTS]SYSTEM MANAGEMENT - H & K 8 of 13 EISNER::CONROY "Alan Conroy" 30 lines 11-AUG-1988 13:30 -< DSKBLD et al >- -------------------------------------------------------------------------------- > Yes, I am interested, and I would think that others would be too. > If your company will let you, you should submit it to the DECUS > library. I've asked my boss and am waiting to hear back. Before I submit it I'll aslso make sure the spurious bug is gone. > What is DSKBLD? A disk defragmenter for RSTS/E, made by Grey-Matter software. I used it for a few years and it seemed pretty solid. Their number is 206-285-7414. > Why are scratch areas less important with V9.5? In pre-V9.5 the system had to search the SATT beginning with the first DC. This meant that if you had a lot of files and they were all at the beginning of the disk, you had extra overhead everytime the system needed to allocate more space on the disk. In V9.5 the system keeps the first free DCN in memory so the search begins there. There are other advantages to scratch space, and the overall overhead for searches, etc really depends on how you have your system configured. There are some alarm bells in my head now, maybe it was V9.4 that this change appeared. In any case, the overhead was reduced by this change to the monitor, whenever it was. > For the kind of work we do here, this isn't really that important. > Besides, this can be done independent of de-fragmentation. True, but it's nice to have a package which does all these things for you automagically. ================================================================================ Note 80.9 [RSTS]SYSTEM MANAGEMENT - H & K 9 of 13 EISNER::CONROY "Alan Conroy" 3 lines 22-AUG-1988 11:59 -< RSTS/E REORG >- -------------------------------------------------------------------------------- Well, I received approval to submit the RSTS/E REORG program to DECUS. I will do so as soon as I fix the last spurious bug (should take no time, once I HAVE time) - maybe at the fall symposium. ================================================================================ Note 80.10 [RSTS]SYSTEM MANAGEMENT - H & K 10 of 13 EISNER::MCALLISTER "Brian McAllister" 11 lines 10-MAR-1989 18:17 -< Want MACRO/RT11 as the default for DCL >- -------------------------------------------------------------------------------- According to both the online HELP and the System User's Guide, the default action of the DCL MACRO command is MACRO/RSX11, "unless your system manager changes it". Is this really possible, and if so, how does one do it? I couldn't find anything else relating to this in the manuals. Brian ================================================================================ Note 80.11 [RSTS]SYSTEM MANAGEMENT - H & K 11 of 13 EISNER::KENNEDY "Terry Kennedy" 8 lines 11-MAR-1989 22:45 -< Via a DCL symbol >- -------------------------------------------------------------------------------- > "unless your system manager changes it". > Is this really possible, and if so, how does one do it? What they mean is by a symbol defined in the system-wide LOGIN.COM file, such as: MAC*RO == "MACRO/RT11" ================================================================================ Note 80.12 [RSTS]SYSTEM MANAGEMENT - H & K 12 of 13 EISNER::MCALLISTER "Brian McAllister" 9 lines 14-MAR-1989 11:57 -< Should be a more permanent way... >- -------------------------------------------------------------------------------- > What they mean is by a symbol defined in the system-wide LOGIN.COM file This had occurred to me, but I was hoping there was a more "hard-wired" way (like a SET SYS/DEFAULT or something). It might be nice if there was some way to make a CCL take precedence over a DCL command. ================================================================================ Note 80.13 [RSTS]SYSTEM MANAGEMENT - H & K 13 of 13 EISNER::KENNEDY "Terry Kennedy" 13 lines 15-MAR-1989 03:01 -< Yet more methods >- -------------------------------------------------------------------------------- > This had occurred to me, but I was hoping there was a more > "hard-wired" way (like a SET SYS/DEFAULT or something). Well, what I posted is what the developers meant. You could go into DCL.RTS ans change the meanings of the commands (see my newsletter article or Symposium session) where I show how to redefine stuff in DCL. I believe the example I gave was making SHOW NETWORK do NCP SHO KNO NOD instead of SHO ACT NOD. > It might be nice if there was some way to make a CCL take precedence > over a DCL command. MAC*RO == "CCL MACRO"  ================================================================================ Note 81.0 [RSX]licence question 4 replies EISNER::TABOR "Bill Tabor" 5 lines 14-JUL-1987 22:42 -------------------------------------------------------------------------------- Help! I can not get an answer out of my local DEC office. I want to move the MMDRV from an M+ full system to a system that has the pregen kit. Is this a violation of the licence or is a system with pregen kit still licenced for full M+? ================================================================================ Note 81.1 [RSX]licence question 1 of 4 EISNER::CETRON 9 lines 15-JUL-1987 03:18 -< taking license with response >- -------------------------------------------------------------------------------- first, the obvious questions: which pregen kit??? second, as I recall the license states RSX11-M+, the DISTRIBUTION method specifies whether you get pregen or not....rlo2's are pregen, ra81's are not...... -ed ================================================================================ Note 81.2 [RSX]licence question 2 of 4 EISNER::MCCARTHY 22 lines 15-JUL-1987 16:22 -< A technicality >- -------------------------------------------------------------------------------- > second, as I recall the license states RSX11-M+, the DISTRIBUTIO > method specifies whether you get pregen or not....rlo2's are pregen, > ra81's are not...... Well, not exactly. The License for the pregenned RL02 kit is in fact not the same license as the non-RL02 kit. The RL02 is QR503 and QY503 for class H and class L, respectively. The normal distribution is QR500 and QY505, all suffixed -UZ, of course. The license difference was instituted primarily as a tracking mechanism. They are technically different however. Now if one were to ask an RSX product manager's opinion (I'm not a product manager) one might receive a "we don't really care if you run M+ on that machine" answer. -Brian ================================================================================ Note 81.3 [RSX]licence question 3 of 4 EISNER::TABOR "Bill Tabor" 3 lines 15-JUL-1987 21:26 -< M-plus Pregen >- -------------------------------------------------------------------------------- < first, the obvious questions: which pregen kit??? it is the rsx-11m+ pregen kit. ================================================================================ Note 81.4 [RSX]licence question 4 of 4 EISNER::MCCARTHY 6 lines 16-JUL-1987 14:35 -< Late breaking news... >- -------------------------------------------------------------------------------- This just in from our bureau in New Hampshire ... The license difference I described will soon go away. -Brian  ================================================================================ Note 82.0 [PRO300]P/OS V3.x TFEA$ Bug Fix No replies EISNER::ETHINGTON "Superior Klingon Technology" 91 lines 16-JUL-1987 01:05 -------------------------------------------------------------------------------- Users of P/OS V3.0 and V3.1 systems may be interested in the following article which I have submitted for publication to the PC SIG newsletter. Jerry Ethington P/OS V3.0/3.1 Bug - TFEA$ Directive Doesn't Work Jerry Ethington, Prolifix, Inc., Frankfort, KY Developers and programmers utilizing some of the many new features present on P/OS version 3 systems may have noticed a very useful new directive, TFEA$ - the Task Feature directive. TFEA$ can return important information to a task about itself - whether it was linked for fast mapping (another new version 3 directive), whether it is privileged, whether it was linked with memory resident overlays, and many other pieces of information from the status words T.ST2, T.ST3, and T.ST4 in its own task control block (TCB). The first thing I tried to use TFEA$ for was to determine whether the task had been linked with fast mapping support, so at run time I could dynamically decide to use the new fast map directive or, on pre-version 3 systems, I could fall back to the much slower MAP$ directive to remap dynamic regions for an application. I quickly discovered, however, that TFEA$ did not work as documented, or in fact work at all. According to the documentation, the directive status word ($DSW) should return one of four possible values; IS.CLR, indicating the feature being tested is NOT present; IS.SET, indicating the feature being tested IS present; and the two standard return codes, IE.ADP and IE.SDP, respectively indicating that the DPB is out of the issuing task's address space or that the DPB size or DIC are invalid. Instead, testing discovered that whether or not the specified feature was enabled, an error code of IE.ITS (inconsistent task state) was ALWAYS returned, making the directive useless. Fortunately, the all too limited source microfiche supplied with the P/OS version 3.0 Tool Kit contained the code involved, and through the miracles of superior Klingon technology I was able to locate and solve the problem. I am distributing the correction for P/OS V3.0 and V3.1 to other PRO users and developers so they may take advantage of this new functionality before the official correction from DEC appears in the future release of P/OS V3.2. To correct the problem, you must create the following file and use the ZAP utility supplied with the Tool Kit to apply the correction to the P/OS system image. You must be logged in as a privileged user and, in PRO/Clusters, you must be logged on local at the file server system. The file name given in the first line will depend upon whether or not you are using the PRO/Cluster functionality added in P/OS V3.0. ALL users must apply the correction file to LB:[ZZSYS]POS.SYS, but users of Pro/Clusters must ALSO apply it to the file server system image, LB:[ZZSYS]POSFS.SYS, so they will need to make two files and apply both of them with ZAP. Create the correction file or files, enter the Tool Kit and issue the command "RUN $ZAP". ZAP will prompt with "ZAP>", and you enter the name of the file you created as an indirect command file. For example, if you create the correction file with the name TFEA.ZAP, the dialogue would look like: $ RUN $ZAP ZAP>@TFEA.ZAP ZAP will print several numbers as it applies the correction and then exit. After you reboot the system, the correction will be in place and the TFEA$ directive will work as documented. The correction will also take effect on all diskless workstations in a PRO/Cluster after the workstation is rebooted. The correction file is as follows: Lb:[Zzsys]Pos.Sys/Ab (or Lb:[Zzsys]Posfs.Sys/Ab) 200+3:200+120000-120000;0R 213+3:000+126572-120000;1R 0,320+330/ 053332V Q+100000 1,72/ 005742V 240 1,124/ 000004V Q-2 1,132/ 000006V Q-2 1,140/ 000022V Q-2 X  ================================================================================ Note 83.0 [RSX]LPA-11 Task in I&D Space 2 replies EISNER::DELARISCH 5 lines 21-JUL-1987 15:05 -------------------------------------------------------------------------------- Does anyone know why I can't use the LPA-11 (Laboratory Peripheral Accelerator LA:) with an I & D space task? I've got an application which I need as much buffer space as I can get. I get rather encryptic error numbers (Messages) when I attempt to RUN the task built I&D. Any guesses? ================================================================================ Note 83.1 [RSX]LPA-11 Task in I&D Space 1 of 2 EISNER::DELARISCH 9 lines 27-JUL-1987 13:59 -< More info on the LPA-11 >- -------------------------------------------------------------------------------- Just wanted to add some information. The subroutines are located in LB:[1,1]LPA.OBJ. The error information is from the SETADC subroutine and the I/O status block (4 words) is 333 66 0 0. The other routines are similarly failing. There is NO information in either the I/O driver's reference nor the LPA-11 User's guide on what this means. Any Ideas? Does anyone know if Source Code for these routine are on the M-Plus Distribution? (Please note that these are not the K-series routines but the LPA-11.) Help! ================================================================================ Note 83.2 [RSX]LPA-11 Task in I&D Space 2 of 2 EISNER::TABOR "Bill Tabor" 7 lines 27-JUL-1987 21:01 -< Sounds like Code not built for I & d >- -------------------------------------------------------------------------------- sounds like the LPA-11 routines are not built for I and D space suggest you get a copy of DISOBJ from one of the sig tapes decompile the code and check for proper segmentation. or SPR it if you can wait.  ================================================================================ Note 84.0 [RSX]DECMail-11/RSX 1 reply EISNER::KASPER "Beverly T. Kasper" 19 lines 21-JUL-1987 16:58 -------------------------------------------------------------------------------- Anyone out there who has tried to install Update E of DECMail-11/RSX has probably run into the bug which causes it to choke on one of the library updates, due to a multiply defined entry point. The following patch was provided by a DEC System Support Engineer; I applied it today, and the install went smoothly. 1. Copy the DECmail-11 update files off the update E media. 2. Before starting the DECmail installation procedure, use ZAP to change the following values in the file MAILUPDE.EP in the update account. Note the /AB switch must be on the filespec supplied to ZAP. The locations are: Location Corrupt value Correct value -------- ------------- ------------- 1041:230 10000 12000 1041:672 2000 2100 3. Proceed with the installation as normal. ================================================================================ Note 84.1 [RSX]DECMail-11/RSX 1 of 1 EISNER::WYANT "Tom Wyant" 10 lines 13-OCT-1988 12:41 -< Thanks - we love you, Bev >- -------------------------------------------------------------------------------- >>> Anyone out there who has tried to install Update E of DECMail-11/RSX >>> has probably run into the bug .... Thanks for the info (a year late...). At this remove, I thought you'd like to know that SOMEONE read and appreciated your note. Does this fix the problem in "D" where the DECmail traps out on "File not found"? We're a bit behind here (no fault of mine - when I went to the European project my boss decided he could backfill my job with a highschool graduate - more about that in a more private forum).  ================================================================================ Note 85.0 [RSX]Where or where is my CDA gone? 1 reply EISNER::STAMERJOHN "RW Stamerjohn" 3 lines 22-JUL-1987 15:01 -------------------------------------------------------------------------------- Can anyone help my memory, I think I submitted the Crash Dump Analysis seminars materials to the Fall 1982 SIG Tape in [346,101] but am told no such files. Does anyone know were the file are? ================================================================================ Note 85.1 [RSX]Where or where is my CDA gone? 1 of 1 EISNER::NORTON 2 lines 17-AUG-1987 16:25 -< Here is where it could be >- -------------------------------------------------------------------------------- The well-thumbed copy I have kept for years is marked Spring 1981 [346,101].  ================================================================================ Note 86.0 [PRO300]Printed circuit design software on PRO? No replies EISNER::JOHNSON "Sharon Linnea Johnson" 15 lines 22-JUL-1987 20:27 -------------------------------------------------------------------------------- Does anyone know of any printed circuit design software which runs on a PRO and where to get it? Thanks in advance, Sharon Johnson %Division of Epidemiology (University of Minnesota) Stadium Gate 27 611 Beacon Street SE Minneapolis, MN 55455 (612) 624-9479 Bitnet: SHARON@SIMVAX  ================================================================================ Note 87.0 [RSTS]Interesting mods to system software 20 replies EISNER::KENNEDY "Terry Kennedy" 95 lines 24-JUL-1987 04:49 -------------------------------------------------------------------------------- Since things have been rather quiet in this conference, I thought I'd throw in some goodies I've been cooking up for future newsletter articles. Please let me know via MAIL if you'd like to see more of this sort of thing on this system. Did you ever wish that you could supply a real username instead of a cryptic PPN to login? (This is known as 'VMS envy'). Well, now you can - if you have DECMAIL-11 for RSTS. The enclosed patch to LOGIN.BAS lets you supply your MAIL username as a valid response to LOGIN's User: prompt. RSTS/E version 9.3 or later and DECMAIL-11 version V3.0-00.04 were used for this modification. You may have to edit the supplied patch for other releases of either product. Enter the patch into a COPY of your LOGIN.BAS. Don't modify the original! Then compile it with Basic-Plus 2 if you have it, as documented in the Maintenance Notebook. If you don't have BP2, you can use Basic-Plus. CSPCOM will not work, so don't use it! Now, log onto your system from at least two terminals (so you can recover if something goes wrong). Rename $LOGIN.TSK to $LOGIN.OLD, and copy the new LOGIN program (either LOGIN.TSK for BP2 or LOGIN.BAC for B+) to $. Ensure it has a protection code of <232>. Basic installation is now complete. You may now enter any valid MAIL username when logged-out, and then provide the password in the usual manner. If you want this new feature to work when logged-in also, read the next paragraph, otherwise don't bother. DCL will try to outsmart you my not allowing non-numeric user information in the DCL LOGIN command. You can cure this by inserting the following two lines in their respective files: In [0,1]START.COM: $ define/command/system LOG-IN $LOGIN.* /privilege In [0,1]LOGIN.COM: $ LOG-IN == "CCL LOGIN" Note that this will 'break' the DCL command login/terminal. To work around this, simply put an underscore in front of that command wherever it is used, as so: _login/terminal=kb1: [1,2]. This problem only happens when you add the two lines for logged- in name translation. Name translation will not work in DECNET requests for access information, as they are not handled by LOGIN. Oh well. If you have any problems or questions about this modification, leave a reply here or call the RSTS SIG newsletter system at (201) 435-2546 [see related topic in this conference]. Change the line number of line 13001 to 13008. Insert the following code immediately before that line: 13001 OPEN "MAIL$:NAMES.SYS" FOR INPUT AS FILE #2%, RECORDSIZE 512%, & MODE 8192% ! ** 23-Jul-87 - tmk - allow named logins & \ FIELD #2%, 512% AS MAIWRK$ & \ LOGIN1$=CVT$$(LOGIN$,34%) & \ GOTO 13004 IF LOGIN1$="" & \ GET #2%, BLOCK 1% & \ MAIREC%=CVT$%(MID(MAIWRK$,5%,2%)) & ! OPEN THE MAIL NAMES FILE & ! CONVERT TYPED USERNAME TO UPCASE, NO SPACES OR TABS & ! GET THE FIRST RECORD OF MAIL USERNAMES & 13002 GET #2%, BLOCK MAIREC% & \ FOR MAITMP%=33% TO 512% STEP 16% & \ MAINAM$=CVT$$(MID(MAIWRK$,MAITMP%,12%),160%) & \ GOTO 13003 IF MAINAM$=LOGIN1$ & \ NEXT MAITMP% & \ MAIREC%=CVT$%(LEFT(MAIWRK$,2%)) & \ GOTO 13002 UNLESS MAIREC%=0% & \ GOTO 13004 & ! READ THE FIRST USERNAME BLOCK & ! LOOK AT ALL THE POSSIBLE NAMES IN IT & ! IF WE HAVE A MATCH, EXIT & ! ELSE LOOK AT REST & ! IF NOT FOUND, DETERMINE NEXT RECORD AND LOOP IF NOT AT END & ! ELSE RETURN A NON-MATCH & 13003 LOGIN$="["+NUM1$(ASCII(MID(MAIWRK$,MAITMP%+12%,1%))) & +","+NUM1$(ASCII(MID(MAIWRK$,MAITMP%+13%,1%)))+"]" & ! CONSTRUCT PPN FROM MAIL USERNAME ENTRY & 13004 CLOSE #2% & ! CLOSE THE MAIL NAMES FILE & Change the start of line 13900 as follows: 13900 RESUME 13008 IF ERL=13001 & \ resume 13008 if ERL=13002 & \ RESUME 19999 IF KB.SPAWNED% OR (NOT (LOGGED.IN%)) OR A%=0% & \ PRINT "?Invalid entry - try again" IF A% & ================================================================================ Note 87.1 [RSTS]Interesting mods to system software 1 of 20 EISNER::CONROY "Alan Conroy" 18 lines 9-AUG-1988 15:06 -< A better way >- -------------------------------------------------------------------------------- We've had this basic ability (login by name) since V8.0. Basically, you add four statements to your LOGIN.BAS program which allows you to login by logical name. For example, if a logical called FRED pointed to [2,2], then typing HELLO FRED (and supplying a proper password) would log you into [2,2]. This is nice because you don't have to have MAIL and besides its nice to refer to someone else's account as NAME:. I have SPRed this to DEC twice as a suggestion. They wrote back and said "sounds like a good idea. You'd want to make sure that it would only accept logicals which point to SY:. We may include it in a future release." (slightly paraphrased). After 5 minor versions and still nothing, I SPRed them a second time and included the code necessary to do this (if I make it easy, maybe they'll do it - I'm sick of modifing the LOGIN program all the time). As far as having the logicals only point to SY: - well, in our shop I can't see any reason why we'd care about this restriction. You certainly can't log into anything but the system disk and if the account doesn't exist there, then so what? In all cases, you still have to supply a password. I don't have the code right in front of me, but maybe I'll include it here in a couple days. ================================================================================ Note 87.2 [RSTS]Interesting mods to system software 2 of 20 EISNER::KENNEDY "Terry Kennedy" 16 lines 9-AUG-1988 23:51 -< Generic=useful, here >- -------------------------------------------------------------------------------- > We've had this basic ability (login by name) since V8.0. Basically, you > add four statements to your LOGIN.BAS program which allows you to login by > logical name. Yes, I've heard from many users who have done the same mod you have. The problem I have with this is my systems have hundreds (sometimes thousand) acoounts and that takes up a *lot* of logical name table space. The mod I did is readily adaptable to *any* name-lookup scheme you want, even text files. There is a new mod to LOGIN coming from me in the near future. You get last interactive/non-interactive, logfail info (like VMS, but *with* KB:, date of last failure), warning of account expiration, and individual passwords for local/dialup/net, and per-terminal passwords. However, code length restrictions (20 line max) prevent me from posting it here, so it will be on the RSTS Newsletter system (see other topic here). ================================================================================ Note 87.3 [RSTS]Interesting mods to system software 3 of 20 EISNER::CONROY "Alan Conroy" 7 lines 11-AUG-1988 13:11 -< Not a problem >- -------------------------------------------------------------------------------- > problem I have with this is my systems have hundreds (sometimes thousand) >acoounts and that takes up a *lot* of logical name table space. The mod I I can understand that, but I think MOST RSTS users would be satisfied with using a little extra XBUF space. The only restriction, really, is the 9 character limit on logical names. BTW: 1000 logicals = 9000 bytes (2000 logicals would be 9K - not a problem for most people). ================================================================================ Note 87.4 [RSTS]Interesting mods to system software 4 of 20 EISNER::CONROY "Alan Conroy" 17 lines 16-SEP-1988 12:00 -< SPR response >- -------------------------------------------------------------------------------- I received a reponse to my SPR suggestion, mentioned in .-3, a week or two ago. I post the response here for the edification of all... "Thank you for your SPR. And thank you for taking the time to send us the details of your code changes. We believe that the best way to implement "named directories" is to do so in the monitor rather than in a CUSP, so that references to directories by name would be valid from all of RSTS rather than just from LOGIN. We will consider such an enhancement for possible implementation in a future release of RSTS/E." P.S. I agree, however it would be nice to have an interim solution... ================================================================================ Note 87.5 [RSTS]Interesting mods to system software 5 of 20 EISNER::MCALLISTER "Brian McAllister" 4 lines 16-SEP-1988 18:18 -< where's the code? >- -------------------------------------------------------------------------------- Well, Alan, are you going to give us this interesting mod or just tell us how wonderful it is? ================================================================================ Note 87.6 [RSTS]Interesting mods to system software 6 of 20 EISNER::CONROY "Alan Conroy" 47 lines 19-SEP-1988 12:09 -< Here it is >- -------------------------------------------------------------------------------- > where's the code? Sorry. I didn't know anyone was interested. Here it is: Replace line 13010 with the following: 13010 I%=-1% & \ SLASH$="/" UNLESS LEN(LOGIN$) & \ GOTO 13020 UNLESS LEN(LOGIN$) & \ LOGIN$=CVT$$(LOGIN$,64%) & \ CHANGE SYS(CHR.6$+CHR$(-10%)+LOGIN$+':') TO M% & \ M%(28%)=M%(28%) AND (NOT 16%) & \ GOTO 13014 & ! SET DEFAULT TO ERROR CONDITION & ! SKIP THE REST IF THE LENGTH OF LOGIN$ IS ZERO & ! TRY A LOGICAL FIRST & ! IGNORE FLAG FOR COLON & 13012 LOGIN$="["+LOGIN$ UNLESS INSTR(1%,LOGIN$,"(") & \ LOGIN$=LOGIN$+"]" UNLESS INSTR(1%,LOGIN$,")") & \ CHANGE SYS(CHR.6$+CHR$(-10%)+LOGIN$) TO M% & ! PUT THE BRACKETS AROUND THE PPN IF NOT ALREADY IN THE STRING & ! DO THE SYS CALL TO SEE IF THE PPN IS REAL & 13014 I%=0 IF M%(5%)<=254% AND M%(6%)<=254% AND M%(6%)<>0% & AND (M%(28%) AND 154%)=0% & ! I%=0% IF THERE IS NO ERROR IN THE PPN & & And add the following line to the error handler: 32405 RESUME 13012 IF ERL=13010% & ! IGNORE ERROR ON ATTEMPTED LOGICAL TRANSLATION & If you compare this to the original code, it will be obvious that this is a minor change (involving about 4 additional statements and the breaking of one line into 3). This is specific to V9.5 login, but if I remember correctly, this same change will work in any version of login, all the way back to V8.0. I've double checked for errors, but since I hand-typed this in, one can never be sure. Be aware that the same rules apply to this as to any changes to the LOGIN program (save the old version, make sure you're logged in somewhere, and test it on another terminal). Finally, neither I nor my company claims responsibility for any errors appearing herein or any problems caused by its use. :-) ================================================================================ Note 87.7 [RSTS]Interesting mods to system software 7 of 20 EISNER::MCALLISTER "Brian McAllister" 16 lines 14-OCT-1988 18:40 -< Doesn't work if already logged in.. >- -------------------------------------------------------------------------------- I have tried out this mod, and it basically works. However, it has one problem, and I am wondering whether there is a way around it, and whether Terry's method (using MAIL) has the same restriction. To wit: It only works if you are not logged in. If you are already logged in and you try LOGIN BRIAN (for instance), you get "?Invalid account", which would seem to be coming from DCL, not LOGIN. Since changing accounts is still the only way to change directories (something I do frequently), this is a major drawback. Any ideas? Brian ================================================================================ Note 87.8 [RSTS]Interesting mods to system software 8 of 20 EISNER::CONROY "Alan Conroy" 6 lines 14-OCT-1988 20:21 -< It's DCL >- -------------------------------------------------------------------------------- You are right, that's DCL that's interferring. I never noticed this since we use a CCL called HELLO (thus we type HELLO FRED). I tried defining a system command as LOGIN, but DCL takes precedence. This would affect ANY changes to LOGIN.TSK, since DCL is trying to parse the command before passing it to LOGIN. All I can say is define some command (like HELLO) and teach people to use that. Sorry I don't have a better workaround. ================================================================================ Note 87.9 [RSTS]Interesting mods to system software 9 of 20 EISNER::KENNEDY "Terry Kennedy" 9 lines 14-OCT-1988 23:58 -< But it's so *easy*! >- -------------------------------------------------------------------------------- > You are right, that's DCL that's interferring. Hmmm. You both flunk the quiz. (grin). Do: 1) In [0,1]START.COM: $ DEFINE/COMMAND/SYSTEM LOG*IN $LOGIN.TSK/LINE=CCL/PRIV 2) In [0,1]LOGIN.COM: $ LOG*IN=="CCL LOGIN" Now, all that won't work is LOGIN/TERMINAL, for which you just need to do _LOGIN/TERMINAL... ================================================================================ Note 87.10 [RSTS]Interesting mods to system software 10 of 20 EISNER::CONROY "Alan Conroy" 5 lines 17-OCT-1988 14:52 -< Fallen from RSTS/E guru-dom >- -------------------------------------------------------------------------------- 1) In [0,1]START.COM: $ DEFINE/COMMAND/SYSTEM LOG*IN $LOGIN.TSK/LINE=CCL/PRIV 2) In [0,1]LOGIN.COM: $ LOG*IN=="CCL LOGIN" Thanks Terry. I had tried #1, but didn't do #2 also, so it didn't work. I guess I'm getting rusty on RSTS/E issues. * sigh * ================================================================================ Note 87.11 [RSTS]Interesting mods to system software 11 of 20 EISNER::MCALLISTER "Brian McAllister" 16 lines 20-OCT-1988 15:21 -< line=ccl ==> 'Attach?' >- -------------------------------------------------------------------------------- > In [0,1]START.COM: $ DEFINE/COMMAND/SYSTEM LOG*IN $LOGIN.TSK/LINE=CCL/PRIV Terry, this doesn't quite seem to do it. 'LINE=CCL' is the same as 'LINE=30000', right? This is the entry point if you are ATTACHing to another job. From perusing the source, it appears that LOGIN has at least four entry points, depending on how it is invoked. Presumably, DCL (and UTLMGR for some) decides what line to actually chain to. To complicate matters, it appears that the entry point, when invoked from a logged in job, depends on whether the PPN is specified or you just typed "LOGIN". Is this really the case? Brian ================================================================================ Note 87.12 [RSTS]Interesting mods to system software 12 of 20 EISNER::MCALLISTER "Brian McAllister" 9 lines 20-OCT-1988 16:18 -< LINE=0 seems to be the answer >- -------------------------------------------------------------------------------- On further investigation, I think what we want is: $ DEFINE/COMMAND/SYSTEM LOGIN $LOGIN.TSK/LINE=0/PRIV This seems to work properly for all cases I have tried. Brian ================================================================================ Note 87.13 [RSTS]Interesting mods to system software 13 of 20 EISNER::KENNEDY "Terry Kennedy" 5 lines 20-OCT-1988 22:13 -< Oops! >- -------------------------------------------------------------------------------- > $ DEFINE/COMMAND/SYSTEM LOGIN $LOGIN.TSK/LINE=0/PRIV Uh... Yes. I posted that in a rush to get out the door. The handout I had in Cinci listed it correctly, and it's also right in the text on the newsletter system. ================================================================================ Note 87.14 [RSTS]Interesting mods to system software 14 of 20 EISNER::MCALLISTER "Brian McAllister" 20 lines 28-OCT-1988 19:06 -< Now only logicals work!!! >- -------------------------------------------------------------------------------- I am still having a problem with this. The change to LOGIN has been made, the CCL defined, the DCL symbol defined, etc. The problem occurs as follows: You are already logged in. Logging in to another account using a logical name works fine. Logging in to another account using an explicit PPN fails with a "?Invalid entry - try again" message, exiting back to DCL. If the user has the necessary privilege to log in to the other account without a password (WACNT or GACNT), then there is no problem. If not, it acts (sort of) like a password was entered incorrectly. I have perused LOGIN without seeing anything obvious that would explain this behaviour. I don't know if it is a problem with the program itself, or with the point at which it is entered. Ideas? ================================================================================ Note 87.15 [RSTS]Interesting mods to system software 15 of 20 EISNER::CONROY "Alan Conroy" 6 lines 28-OCT-1988 20:38 -< Hmmmm. >- -------------------------------------------------------------------------------- Brian, I have tried to reproduce the problem on my system and cannot. Is the protection on LOGIN.TSK equal to <232>? That's the only thing that I can think of that would cause the symptoms you mentioned. Barring that, are you sure the LOGIN symbol is REALLY what it's supposed to be? What version of RSTS/E are you running? If you don't define the LOGIN symbol, then does it work with a UIC? ================================================================================ Note 87.16 [RSTS]Interesting mods to system software 16 of 20 EISNER::MCALLISTER "Brian McAllister" 26 lines 31-OCT-1988 19:06 -< Looks OK to me? >- -------------------------------------------------------------------------------- >Is the protection on LOGIN.TSK equal to <232>? $dir $login.tsk Name .Typ Size Prot Name .Typ Size Prot SY:[1,2] LOGIN .TSK 66C <232> >Are you sure the LOGIN symbol is REALLY what it's supposed to be? $sho com/sys login LOGIN- = SY:[ 1,2 ]LOGIN .TSK /LINE=0 /PRIVILEGE $sho sym login LOGIN == "CCL LOGIN" >What version of RSTS/E are you running? Version 9.5 >If you don't define the LOGIN symbol, then does it work with a UIC? Yes. If you type "_login" to prevent symbol translation by DCL, then PPNs work and logicals don't. Are you sure that you are trying this while logged in? There is no problem at initial login, only when changing accounts. ================================================================================ Note 87.17 [RSTS]Interesting mods to system software 17 of 20 EISNER::CONROY "Alan Conroy" 19 lines 1-NOV-1988 12:45 -< If at first you don't succeed... >- -------------------------------------------------------------------------------- > Are you sure that you are trying this while logged in? There is > no problem at initial login, only when changing accounts. I've tried every combination that I could think of and have not been able to make it fail. I even double checked this morning with the same results. I've tried going from priv to non-priv, both with PPN and logical name; from non-priv to priv, both with PPN and logical name. I assume you have the LOGIN symbol redefined in [0,1]LOGIN.COM? You lose the symbol if you change accounts without doing that. Of course, I can't see how that would cause this problem. Also, are you sure that the logical you are using is not redefined by your job to point elsewhere. Barring that... Since it works at my site (on several machines), and doesn't at yours, I can only assume that there is some configuration difference that is causing this. The problem, of course, is finding it. Can you mail me a copy of your [0,1]LOGIN.COM, give me the two PPNs and what privileges they have. Let me know which direction doesn't work and supply me a list of the LOGIN.COM for the source account. I can take that and try to reproduce your exect config. here and see if anything pops out at me. Is anyone else out there using the patch with or without problems? ================================================================================ Note 87.18 [RSTS]Interesting mods to system software 18 of 20 EISNER::CONROY "Alan Conroy" 2 lines 4-NOV-1988 12:01 -< V9.6 >- -------------------------------------------------------------------------------- I have verified that the same patch works with V9.6 LOGIN as it has with everything since 8.0. ================================================================================ Note 87.19 [RSTS]Interesting mods to system software 19 of 20 EISNER::MCALLISTER "Brian McAllister" 25 lines 9-NOV-1988 20:14 -< AHA! We lost our temp. privs >- -------------------------------------------------------------------------------- I believe that I have identified (and fixed) the problem. The error that was causing the login to fail was a privilege violation while trying to get the date/time of last login. This was happening because the error handler (invoked IF the test for a logical fails) turns off temporary privileges. The solution seems to be just to make sure that they are turned on again (using a construction copied from the code where this subroutine is originally called). Replace line 13012 as given above (38.??) with the following: 13012 A$=SYS(PRIV.ON$) IF A% & \ LOGIN$="["+LOGIN$ UNLESS INSTR(1%,LOGIN$,"(") & \ LOGIN$=LOGIN$+"]" UNLESS INSTR(1%,LOGIN$,")") & \ CHANGE SYS(CHR.6$+CHR$(-10%)+LOGIN$) TO M% & ! PRIVS ON SO WE GET LAST LOGIN DATE & ! PUT THE BRACKETS AROUND THE PPN IF NOT ALREADY IN THE STRING & ! DO THE SYS CALL TO SEE IF THE PPN IS REAL & Alan: It would seem to me that you must have done something like this, or you would have seen the same behaviour. Are you sure you didn't ? (Maybe in the error handler?) BTW: In line 5200, the comment says "drop temporary privileges permanently" (we're about to exit), but the code says SYS(PRIV.ON$), which turns them ON. Can this be correct? ================================================================================ Note 87.20 [RSTS]Interesting mods to system software 20 of 20 EISNER::CONROY "Alan Conroy" 16 lines 10-NOV-1988 11:52 -< Thanks for the bug fix >- -------------------------------------------------------------------------------- Thanks for the fix! That was certainly a definite bug. > Alan: It would seem to me that you must have done something like > this, or you would have seen the same behaviour. Are you sure > you didn't ? (Maybe in the error handler?) Now that I see the problem, I am perplexed as to why it worked on our systems. I, in fact, did not do anything like this. Weird huh? > BTW: In line 5200, the comment says "drop temporary privileges > permanently" (we're about to exit), but the code says > SYS(PRIV.ON$), which turns them ON. Can this be correct? I think the comment is wrong, but the code is right. The privileges need to be there so that the SYS call (14) will do the "@[0,1]LOGIN.COM", even if the LOGIN.COM is protected against everyone.  ================================================================================ Note 88.0 [PDPBAS]Problems In BASIC-PLUS II V2.4 7 replies EISNER::TABOR "Bill Tabor" 1 line 25-JUL-1987 13:56 -------------------------------------------------------------------------------- This topic will be used to discuss Problems in BASIC-Plus II V2.4 ================================================================================ Note 88.1 [PDPBAS]Problems In BASIC-PLUS II V2.4 1 of 7 EISNER::TABOR "Bill Tabor" 38 lines 25-JUL-1987 14:00 -< Reported Problems >- -------------------------------------------------------------------------------- The following notes were extracted from the Lastest version conference. < Note 46.0 by EISNER::KENNEDY "Terry Kennedy" > -< Basic-Plus 2 / RSTS/E >- We have just installed RELEASE 2.4 of Basic-Plus 2 for RSTS/E. None of the problems fixed in this release had affected us, so I can't comment about improvements. However, the compiler task image is a good bit larger. < Note 46.1 by EISNER::KENNEDY "Terry Kennedy" > -< V2.4 not so hot >- Well, now that I've tried it, I discovered that the compiler no longer supports statements that it accepted in V2.3, such as the LINE variable. We're moving back to 2.3 on all systems until such time as the compat- ibility between B+ and BP2 is restored. tmk < Note 46.2 by EISNER::KENNEDY "Terry Kennedy" > -< More holes in 2.4 (swiss cheese?) >- The latest thing to bite us with BP2 V2.4 / RSTS is that it will not correctly generate code to run with disk-based BP2OTS and resident library DAP. All combinations blow up. Disk-based OTS + disk-based RMS/DAP works ok, but kills your task due to swapping to remain in 32K. I haven't tried this with 2.3 yet, because the people here want to 'use the latest version', and the source code will ship to lots of sites with 2.4. I have heard other problems (unconfirmed here) with BP2 V2.4 and the RMS interface. Other problems include the compiler generating an .OBJ file even after a fatal syntax error during compile. DEC (if you're listening): You should be ashamed to release a product in this condition. The index now gets you to the correct section (something it didn't always do in 2.3), but the compiler is full of holes. tmk ================================================================================ Note 88.2 [PDPBAS]Problems In BASIC-PLUS II V2.4 2 of 7 EISNER::TABOR "Bill Tabor" 14 lines 25-JUL-1987 14:07 -< Would like some more Information >- -------------------------------------------------------------------------------- < The latest thing to bite us with BP2 V2.4 / RSTS is that it will not < correctly generate code to run with disk-based BP2OTS and resident < library DAP. All combinations blow up. Disk-based OTS + disk-based < RMS/DAP works ok, but kills your task due to swapping to remain in 32K. < I haven't tried this with 2.3 yet, because the people here want to 'use < the latest version', and the source code will ship to lots of sites < with 2.4. I like some more information on this since I have been running 2.4 for sometime now on RSX-11M Plus and have not run into this problem. ================================================================================ Note 88.3 [PDPBAS]Problems In BASIC-PLUS II V2.4 3 of 7 EISNER::KENNEDY "Terry Kennedy" 7 lines 25-JUL-1987 22:26 -< SPR attachment follows >- -------------------------------------------------------------------------------- > I like some more information on this since I have been running 2.4 > for sometime now on RSX-11M Plus and have not run into this problem. The next reply is the attachment I send along with the SPR - Warning: It is quite long. terry ================================================================================ Note 88.4 [PDPBAS]Problems In BASIC-PLUS II V2.4 4 of 7 EISNER::KENNEDY "Terry Kennedy" 231 lines 25-JUL-1987 22:35 -< Here is the SPR attachment (231 lines) >- -------------------------------------------------------------------------------- RED::$. sw bp2 PDP-11 BASIC-PLUS-2 V2.4-00 BASIC2 old n.bas BASIC2 list N 11:04 PM 24-Jul-87 1 extend 10 print "node"; & \ input node$ & \ print "account"; & \ input line acct$ & \ acct$=mid(acct$,1%,len(acct$)-2%) & \ print "file"; & \ input file$ & \ a$=node$+'"'+acct$+'"::'+file$ & \ print a$ 15 open a$ for input as file #1, sequential 20 input line #1,a$ 30 print a$; 40 goto 20 32767 end BASIC2 rem first we will try the book example (pg. 18-14, 18-15) BASIC2 set /seq BASIC2 rmsres rmsres BASIC2 set /cluster : dapres BASIC2 compile/obj N 11:05 PM 24-Jul-87 BASIC2 build BASIC2 $ RED::$. type n.cmd SY:N/FP=SY:N/MP UNITS = 13 ASG = SY:5:6:7:8:9:10:11:12 CLSTR = DAPRES,RMSRES:RO // RED::$. type n.odl .ROOT BASIC2-RMSROT-USER,RMSALL USER: .FCTR SY:N-LIBR LIBR: .FCTR LB:BP2OTS/LB @LB:BP2IC1 @LB:RMS11X .END RED::$. tkb @n %TKB -- *DIAG*-Module R0AUTO multiply defines symbol $DXTHR ... here follow about 80 more, deleted to save NOTES space ... %TKB -- *DIAG*-Module R3DELE multiply defines symbol $DEL3E ^C RED::$. ! not so good - let's try another way... RED::$. sw bp2 PDP-11 BASIC-PLUS-2 V2.4-00 BASIC2 old n.bas BASIC2 set /seq BASIC2 rmsres rmsres BASIC2 set /cluster : dapres BASIC2 rem now we'll add the ODLRMS from page 18-15: BASIC2 odlrms lb:daprlx BASIC2 rem note that we had to insert LB: in front of the manual's example, BASIC2 rem which is incorrect (again). BASIC2 compile N 11:10 PM 24-Jul-87 BASIC2 build BASIC2 $ RED::$. type n.cmd SY:N/FP=SY:N/MP UNITS = 13 ASG = SY:5:6:7:8:9:10:11:12 CLSTR = DAPRES,RMSRES:RO // RED::$. type n.odl .ROOT BASIC2-RMSROT-USER,RMSALL USER: .FCTR SY:N-LIBR LIBR: .FCTR LB:BP2OTS/LB @LB:BP2IC1 @LB:DAPRLX .END RED::$. tkb @n RED::$. run n ?Protection violation RED::$. ! now, why did that happen - look at my privs: RED::$. show job/priv DATES DEVICE EXQTA GACNT GREAD GWRITE HWCFG HWCTL INSTAL JOBCTL MOUNT PBSCTL RDMEM RDNFS SEND SETPAS SHUTUP SWCFG SWCTL SYSIO TMPPRV TUNE USER1 USER2 USER3 USER4 USER5 USER6 USER7 USER8 WACNT WREAD WRTNFS WWRITE RED::$. ! must be an internal bug... RED::$. ! let's try it with disk-based DAP: RED::$. sw bp2 PDP-11 BASIC-PLUS-2 V2.4-00 BASIC2 old n ?Can't find file or account BASIC2 old n.bas BASIC2 set /seq BASIC2 odlrms lb:dap11x BASIC2 compile N 11:13 PM 24-Jul-87 BASIC2 build BASIC2 $ RED::$. type n.cmd SY:N/FP=SY:N/MP UNITS = 13 ASG = SY:5:6:7:8:9:10:11:12 // RED::$. type n.odl .ROOT BASIC2-RMSROT-USER,RMSALL USER: .FCTR SY:N-LIBR LIBR: .FCTR LB:BP2OTS/LB @LB:BP2IC1 @LB:DAP11X .END RED::$. tkb @n RED::$. run n node? news account? [1,254] xxxxxx file? login.com news"[1,254] xxxxxx"::login.com $ ! LOGIN.COM for TMK $ ! Last change - 11-Jan-86 $ ASSIGN DU1: U: $! ASSIGN [0,209] TMP: $ HD=="_SET TERM/LOCAL_ECHO" ! These 2 are for $ FD=="_SET TERM/NOLOCAL_ECHO" ! file transfers $ MEM=="_RUN UNSUPP$:MEMORY" ! Memory map $ ERRDIS=="_RUN ERROR$:ERRDIS" ! Error display $ PR*INT=="@TOOLS:PRINT" ! Print on LP0: ^C RED::$. dir n.tsk Name .Typ Size Prot Name .Typ Size Prot SY:[1,254] N .TSK 170C <104> Total of 170 blocks in 1 file in SY:[1,254] RED::$. ! well, that worked, but we've linked in all of RMS disk-resident RED::$. ! into the task image, so it has to thrash the disk heavily for RED::$. ! each read - on an RP06 it takes about 1 to 1 1/2 seconds per line RED::$. ! printed. When copied to the RSTS virtual disk, it takes about 1/8 RED::$. ! second per line - better, but not adequate. RED::$. close/log ================================================================================ Note 88.5 [PDPBAS]Problems In BASIC-PLUS II V2.4 5 of 7 EISNER::TABOR "Bill Tabor" 46 lines 26-JUL-1987 13:06 -< Works on RSX-11M Plus. >- -------------------------------------------------------------------------------- This is an incorrect format for using DAPRES See your decnet manuals Possible documentation bug. I do not have The manual handy. RED::$. type n.cmd SY:N/FP=SY:N/MP UNITS = 13 ASG = SY:5:6:7:8:9:10:11:12 CLSTR = DAPRES,RMSRES:RO // RED::$. type n.odl .ROOT BASIC2-RMSROT-USER,RMSALL USER: .FCTR SY:N-LIBR LIBR: .FCTR LB:BP2OTS/LB @LB:BP2IC1 @LB:RMS11X .END this is the correct format for cmd and odl RED::$. type n.cmd SY:N/FP=SY:N/MP UNITS = 13 ASG = SY:5:6:7:8:9:10:11:12 CLSTR = DAPRES,RMSRES:RO // RED::$. type n.odl .ROOT BASIC2-RMSROT-USER,RMSALL USER: .FCTR SY:N-LIBR LIBR: .FCTR LB:BP2OTS/LB @LB:BP2IC1 @LB:DAPRLX .END This works just fine on RSX-11M PLUS As to why you get a protection violation I suggest you check the protection of your libraries. If they are set correctly then this is an RMS or RSTS/E bug not a BP2 bug. ================================================================================ Note 88.6 [PDPBAS]Problems In BASIC-PLUS II V2.4 6 of 7 EISNER::TABOR "Bill Tabor" 4 lines 26-JUL-1987 13:16 -< Try BP2IC7 >- -------------------------------------------------------------------------------- just noticed a difference between my odl and yours. I always use BP2IC7 for any decnet access programs since I do not know the exact format of a file on an other system. ================================================================================ Note 88.7 [PDPBAS]Problems In BASIC-PLUS II V2.4 7 of 7 EISNER::KENNEDY "Terry Kennedy" 12 lines 26-JUL-1987 23:32 -< Problem resolved (mostly) >- -------------------------------------------------------------------------------- Thank you for your input - I see that the only difference between my original .CMD/.ODL and yours is the DAPRLX ODL. The way I did it is the way it was (incorrectly) documented in the 2.4 manual. The ?Protection violation message came from a condition at this site which I doubt any other users will hit. The .CMD/.ODL pairs shown were all generated by BP2's BUILD command. This can be a source of confusion to the user. [If you cant trust the compiler, who can you trust?] tmk  ================================================================================ Note 89.0 [PRO300]Faster Fortran 77 Compiles 1 reply EISNER::ETHINGTON "Superior Klingon Technology" 99 lines 26-JUL-1987 03:18 -------------------------------------------------------------------------------- The following is an article I am writing for the DECUS PC Sig newsletter. It describes a patch to the Tool Kit Fortran 77 compiler that improves the compile speed quite a bit, particularly for large programs. If you use Fortran 77 and would like a faster compiler, read on, this Bud's for you. Brought to you through the miracles of superior Klingon technology..... Jerry ____________________________________________________________________ Faster Compiles with PRO/Tool Kit Fortran-77 Jerry Ethington, Prolifix, Inc., Frankfort, KY PRO/Tool Kit Fortran 77 version 5.0 is a pre-packaged version of the PDP-11 Fortran 77 product. The compiler is supplied as a task image instead of an object library and task build command files, so Pro developers do not have the opportunity to tune the compiler parameters for improved performance or different default switches. Although in general the supplied compiler defaults are indeed quite reasonable, there is one glaring problem that causes compiles to take much longer than necessary on Pro systems. If you want the Fortran 77 compiler to run MUCH faster on your Pro, read on. The guilty culprit is the task extension for the compiler itself. The compiler uses any available task extension it is installed with as memory for symbol table storage when compiling your source program. The default on PDP-11 Fortran 77, and the setting the Tool Kit Fortran 77 compiler was linked with, is to allocate 8 pages (4 kilobytes) of memory for symbol table storage. If your program is large enough to need more symbol table storage than this (hint - most programs ARE bigger than this), then the compiler implements a software virtual memory system, "paging" the symbol table to a work file on disk during compilation. Clearly, once your program has overflowed the available memory and the compiler begins using a disk work file, the compile speed drops off dramatically. On PDP-11 Fortran 77, the setting for this parameter is a trade off between the compile speed and the increased memory used by the compiler. On old PDP-11 systems with a very limited amount of memory, the default setting was a reasonable compromise, resulting in a compiler using about 46 kilobytes of memory - on multiuser systems with no more than 256 kilobytes of memory available, such as an 11/34, this was about as much memory as one dared use for the compiler. On more modern PDP-11 systems, with far larger amounts of memory, it is entirely reasonable to use the entire 64 kilobytes of address space available to the compiler in order to improve compile speeds. On Professionals, which are usually single user systems and have at least 512 kilobytes of memory standard, it is also reasonable to maximize the amount of memory the compiler uses for symbol table storage in order to improve compile speeds. The following patch to the Fortran 77 compiler itself, applied with our good friend ZAP from the Pro/Tool Kit, will increase the task extension so that the maximum amount of memory possible will be used for symbol table space, greatly reducing the use of the disk work file during compiles. This will result in a compiler using 64 kilobytes of memory during compiles. On P/OS version 3.0 and later systems, you will need to be logged in to a privileged account and, on Pro/Cluster systems, you will need to be logged in on the file server itself instead of on a workstation. On systems before version 3.0, you will need to enter the Tool Kit application and type the command "SHOW LOGICAL APPL$DIR" to find the directory where the Fortran 77 compiler is stored. Create the following command file with your favorite editor, such as EDT: LB:[ZZPRODCL]PF7.TSK/AB (For pre-V3.0 systems, the directory will be different - use the directory shown from the SHOW LOGICAL command above) 1:352/ 000100V 561 X To apply the patch, run the Tool Kit application. Type the command "RUN $ZAP", and then enter the name of the command file you just created as an indirect command file. For example, if you created the command file with the name F77.ZAP, the commands would be: $ RUN $ZAP ZAP>@F77.ZAP The patch will take effect the next time you enter the Tool Kit application or reboot. Symbol table memory is increased from 8 pages to 46 pages, an almost six fold increase. The effect this has on compiling a large program is startling. On my Pro 380 development system, one particularly large program took 29 minutes 51 seconds to compile before. After applying the patch, compile time was cut to 12 minutes 10 seconds, 2 1/2 times faster. On small programs, the improvement will not be as dramatic, but there should be a noticeable improvement on almost any program. A new release of Tool Kit Fortran 77, version 5.2, should be becoming available at about the time this article is published. Owners of the current 5.0 version of Fortran 77 will be able to buy an upgrade to the new version at a cost much less than the full price of the compiler. I do not know whether or not this problem will exist in the new release, but I will publish a follow up article at a later date in the PC Sig newsletter to provide a new patch for the 5.2 compiler if necessary. ================================================================================ Note 89.1 [PRO300]Faster Fortran 77 Compiles 1 of 1 EISNER::ROECKEL 11 lines 22-AUG-1987 15:38 -< Thanks a million >- -------------------------------------------------------------------------------- WOW !!!!! and WOW again !!!! You are an absolute lifesaver !!! I applied the fix you specified to my FORTRAN77 compiler, and the thing performs at lightning speed !! You really have saved me a bunch of time --- Thanks a million !!! Bruce (a new PRO hacker)  ================================================================================ Note 90.0 [RSX]Virtual Disks and F11ACP 7 replies EISNER::DELARISCH 18 lines 28-JUL-1987 16:58 -------------------------------------------------------------------------------- We have a system which is primarily (Disk) I/O Bound. We are using the Virtual Disk package (VD off of the Fall 86 Sig Tape). I have seperate F11ACP's for each of the Large Disks and use VD driver to break the disk up into reasonable segments. Is there any advantage in giving each Virtual Disk its own F11ACP. The Virtual disks seem to want to use the Generic F11ACP instead of the unique ones. I've got physical memory to burn ... what's the best approach? 1. Installing a unique F11ACP for each Virtual and Physical Disk 2. Installing a unique F11ACP for each Large disk and forcing the virtual disk to use the same ACP as the disk is resides on. 3. Leaving the virtual disks use the generic F11ACP (I don't think so.) 4. Buying a VAX for Real time work ;-}}}} (Ha Ha Ha) Any comments? -Arnold ================================================================================ Note 90.1 [RSX]Virtual Disks and F11ACP 1 of 7 EISNER::TINKELMAN "Bob Tinkelman - CCA" 18 lines 28-JUL-1987 20:32 -< Unique ACPs for VDs >- -------------------------------------------------------------------------------- < I've got physical memory to burn ... what's the best approach? If you have a large physical disk containing a number of VDs, then the ACP associated with the physical disk is used ONLY when you do the AVD to allocate the virtual disk. After that, it is not used at all. Files-11 I/O to the virtual disk will go through the ACP associated with the VD and then to VDDRV. VDDRV will modify the logical block number and pass on the QIO to the driver for the physical device. As it will be a "logical IO" and not a "virtual IO", no ACP will be involved at this step. So, you buy a lot of "parallelism" by having unique ACPs per VD and not very much more by making the ACPs unique for the parent physical disks (unless, of course, you do a lot of Files-11 stuff directly to them). Further, with "physical memory to burn", I guess you should choose the biggest, flatest APCs. ================================================================================ Note 90.2 [RSX]Virtual Disks and F11ACP 2 of 7 EISNER::MAXWELL "Gary Maxwell" 11 lines 29-JUL-1987 20:35 -< Something else to tinker with >- -------------------------------------------------------------------------------- The other thing to try is to enable logical I/O disk data caching on the physical volume. This will help if all of your virtual disk have a high locality of reference. Otherwise, I agree with Bob that the dedicated ACP should go first to the disks, then to the physical disk. Run some benchmarks and let us know what you find. I am especially interested in that I am giving a session on VDDRV and FXDRV in Anaheim and I would like to see other real world applications and the performance obtained. Anyone else? ================================================================================ Note 90.3 [RSX]Virtual Disks and F11ACP 3 of 7 EISNER::MAXWELL "Gary Maxwell" 6 lines 29-JUL-1987 20:37 -< On caching virtual disks >- -------------------------------------------------------------------------------- I just remembered... I have failed to get data caching to work on Virtual Disks. I enable IO.STC as a valid control function (not a no-op as is standard for a virtual disk), and the system goes belly-up after about fifteen seconds. Any ideas here? ================================================================================ Note 90.4 [RSX]Virtual Disks and F11ACP 4 of 7 EISNER::TINKELMAN "Bob Tinkelman - CCA" 13 lines 29-JUL-1987 21:24 -< Cache the physical and not the virtual disk >- -------------------------------------------------------------------------------- < I have failed to get data caching to work on Virtual Disks. > Unless you are trying to do some very fine tuning of getting caching on some parts of a physical disk (i.e. the part that is holding a VD) and not other parts, I don't understand why you'd want to cache the VD. It seems that turning caching on for the physical disk would be better - letting the caching algorithm decide what to cache (sort of like the idea that paging is usually better than structured overlays). You certainly don't want to turn on caching (even if you could) for both the virtual disk and its parent physical disk. That would (if it worked) seem to me to incur double overhead - with each block cached twice. (Or am I missing something?) ================================================================================ Note 90.5 [RSX]Virtual Disks and F11ACP 5 of 7 EISNER::MAXWELL "Gary Maxwell" 16 lines 20-AUG-1987 21:11 -< Who knows what may help a particular case? >- -------------------------------------------------------------------------------- < Unless you are trying to do some very fine tuning of getting caching on < some parts of a physical disk (i.e. the part that is holding a VD) and < not other parts, I don't understand why you'd want to cache the VD. I don't really know what benefit would be derived from caching VD. Caching is one of those things that you don't know what you get out of it until you try. My plan was (still is) to have a VD do everything that a physical disk can do. Caching, booting, and SAVing are all that's left. As for caching, it may help if you want caching on only a small part of a system's utilization. If you cache the whole disk, you lose most control over which applications are cached; you only control the type of data transfer. Caching a virtual disk gives more control. And yes, I can't imagine caching both. ================================================================================ Note 90.6 [RSX]Virtual Disks and F11ACP 6 of 7 EISNER::MCCARTHY 9 lines 21-SEP-1987 17:34 -------------------------------------------------------------------------------- re: System going belly up after caching VD: Where does it crash? Does the VD database have DV.MSD set? I suspect the problem is related to not having UCB extensions for the virtual disks. -Brian ================================================================================ Note 90.7 [RSX]Virtual Disks and F11ACP 7 of 7 EISNER::MAXWELL "Gary Maxwell" 29 lines 18-NOV-1987 02:30 -< Cached VD: crash (say that fast three times!) >- -------------------------------------------------------------------------------- (Nothing like logging in after two months!!!) Where does VD: crash while caching, do you ask? First, DV.MSD IS set. A UCB extension is created, and the error logging system has a blast trying to figure out what the bleep it is (Riddle: How is a DEC sales person like RPT? Answer: Ask for hardware configurations and they both say "Unknown.") Remember that with this new implemetation I'm using the Internal I/O scheme, which is the only way I could figure out how to implement volume shadowing for VD:. (It also makes for easier implementation of multiple container files.) When I last tried it (about a year ago), the system crashed rather mean and nasty. I tried to look into the crash, but it became obvious that I would have to tackle some smaller test cases to track it down. (Foolish me -- I enabled cacheing and then did a disk-to-disk BRU -- it was brutal.) If I get some time (ha!), I would love to try to nail it down. Maybe someone out there who has a real application for this stuff can try it. The code to enable cacheing is in the driver; it merely enables the IO.STC function, and do likewise in the database. Any other ideas, Brian?  ================================================================================ Note 91.0 [RSX]Forcing size in vectored resident libraries 7 replies EISNER::LEDERMAN "Bart Z. Lederman" 32 lines 28-JUL-1987 19:30 -------------------------------------------------------------------------------- A collegue whom I would like to oblige has posed the following question which I can't quite answer. He has, with much effort, built a vectored, clustered, memory-resident library to support C applications (mostly DECUS C). One of the key advantages to a vectored library is that tasks built against it are supposed to be immune to future changes; i.e., since the entry-points all stay at the same place, there is no need to re-task-build with each new release of the library. BUT: If a new release of the library grows beyond the size of the "baseline" release (i.e. the one the tasks were originally linked against), the tasks blow up. This is probably because the task cannot access the virtual addresses above the "end-of-resident-library" mark that existed at the time the task was originally built. He proposes the solution to this is to make the "baseline" library as big as it can possibly grow to be, i.e., 16Kb (2 APRs worth). Then code can be added until the time that the 16Kb boundary is hit, without problem. The question is: how, when task-building the library, do you make the library "appear" to be a full 16Kb long? (In reality it's around 9.5Kb.) What's the best way to do this, transparently, so that I don't have to muck with the taskbuilder command files etc. as the library grows? I would add, can anyone think of a better solution? I can't and don't recall any of the DEC supplied libraries (FCSRES, RMSRES) running up against this situation (but I'm afraid my "going into the internals" on RSX ended with M-Plus 2.1 E). Alternatively, can anyone suggest why this should not be done at all? ================================================================================ Note 91.1 [RSX]Forcing size in vectored resident libraries 1 of 7 EISNER::TABOR "Bill Tabor" 25 lines 28-JUL-1987 22:24 -< Use EXTSCT option of TKB >- -------------------------------------------------------------------------------- < The question is: how, when task-building the library, do you make the < library "appear" to be a full 16Kb long? (In reality it's around < 9.5Kb.) What's the best way to do this, transparently, so that I don't < have to muck with the taskbuilder command files etc. as the library < grows? Build a Psect with a name so that it is the last Psect in the task now use the EXTSCT = option of the task builder to extend the Psect to its maximum size This does two things. 1) extends the task 2) gives you a patch space to correct problems without rebuilding the library. This is what DEC does. I'll give you the exact syntax as soon as I find my library build command files. I'm in the process of moving and do not know where everything is. ================================================================================ Note 91.2 [RSX]Forcing size in vectored resident libraries 2 of 7 EISNER::LEDERMAN "Bart Z. Lederman" 18 lines 29-JUL-1987 08:24 -< Sounds too easy to be true >- -------------------------------------------------------------------------------- < The question is: how, when task-building the library, do you make the < library "appear" to be a full 16Kb long? (In reality it's around < 9.5Kb.) What's the best way to do this, transparently, so that I don't < have to muck with the taskbuilder command files etc. as the library < grows? > Build a Psect with a name so that it is the last Psect in the task > now use the EXTSCT = option of the task builder to extend the Psect > to its maximum size I know about EXTSCT for extending "task" tasks, but didn't know it worked for things like resident libraries, and don't recall seeing this on resident library builds (though I will go back and look). ================================================================================ Note 91.3 [RSX]Forcing size in vectored resident libraries 3 of 7 EISNER::TABOR "Bill Tabor" 16 lines 29-JUL-1987 09:43 -< EXTEND SECTION NOT TASK >- -------------------------------------------------------------------------------- > I know about EXTSCT for extending "task" tasks, but didn't know it > worked for things like resident libraries, and don't recall seeing this > on resident library builds (though I will go back and look). EXTSCT is extend section EXTTSK is extend task suggest you use the Psect name of $$$PAT TASK BUILD YOU LIBRARY FIND THE NUMBER OF BYTES TO FILL OUT THE APR EDIT THE COMMAND FILE AND REBUILD ================================================================================ Note 91.4 [RSX]Forcing size in vectored resident libraries 4 of 7 EISNER::LEDERMAN "Bart Z. Lederman" 18 lines 29-JUL-1987 13:37 -< I think PAR= is the answer >- -------------------------------------------------------------------------------- > TASK BUILD YOU LIBRARY > FIND THE NUMBER OF BYTES TO FILL OUT THE APR > EDIT THE COMMAND FILE AND REBUILD This it the process he is trying to avoid. Now that I've gone back to an RSX system and done some looking, I think I made a dumb request. What I think he needs is the PAR option, as in PAR=GEN:0:40000 This will automatically extend the task out to a boundary without having to go in and fiddle with individual PSECTS. This is what I found in the FCS and RMS resident library build files, and I ran a short test on a simple task which seemed to work. ================================================================================ Note 91.5 [RSX]Forcing size in vectored resident libraries 5 of 7 EISNER::LEDERMAN "Bart Z. Lederman" 13 lines 29-JUL-1987 21:45 -< It's not so simple after all? >- -------------------------------------------------------------------------------- > Now that I've gone back to an RSX system and done some looking, > I think I made a dumb request. Well, I don't think so any more. I just checked and the build file already has the PAR=GEN:0:40000 option and it's not enough. I've been told that he is also using the /EL switch in the task builder, and it -APPEARS- to be doing the right thing in the way it extends the library, and yet when tasks are built to it they don't pick up the extended length of the library, they pick up the "true" length. I don't recall seeing any other "tricks" in the FCS and RMS build command files (though I'll obviously have to look again). Anybody know how it's done? ================================================================================ Note 91.6 [RSX]Forcing size in vectored resident libraries 6 of 7 EISNER::ETHINGTON "Superior Klingon Technology" 9 lines 22-AUG-1987 01:24 -< How to Vector Resident Libraries >- -------------------------------------------------------------------------------- A full explanation of how to do this kind of exceeds what I'm willing to type in without MFT or Kermit to beam the stuff up from my system, so I'll just say that this is the topic of an article I am writing for the MultiTasker. Look for it in about the October or November DECUS newsletters, coming soon to a theatre near you. Hope the information will prove worth the wait..... Jerry Ethington Prolifix, Inc. ================================================================================ Note 91.7 [RSX]Forcing size in vectored resident libraries 7 of 7 EISNER::MCCARTHY 14 lines 21-SEP-1987 17:43 -------------------------------------------------------------------------------- To the best of my recollection, using PAR= and /EL should work. This is what we do for RMSRES. When you say the tasks get the smaller reference, is this in the task image or the installed task's header? INS may do some processing, I can't remember. FCSRES is slightly different. Since it is a single region with multiple segments, and a null root, the offset to the second segment can't change, either. Thus the first segment is boosted to be 4KW big. This was previously done via multiple builds and changing an EXTSCT, but that's been replaced by RNDSEG. -Brian  ================================================================================ Note 92.0 [RSX]System Accounting Report Generator 4 replies EISNER::DELARISCH 8 lines 3-AUG-1987 21:20 -------------------------------------------------------------------------------- Does anyone know if there is a program submitted on an RSX SIG tape which will take RSX-11M+ accounting information and generate reports and billing info. I really would not like to have to write it from scratch. I'm aware of a couple of commercial packages ... but my management isn't willing to shell (my apologies to unix users 8-}) out big bucks for it. -Arnold ================================================================================ Note 92.1 [RSX]System Accounting Report Generator 1 of 4 EISNER::CETRON 8 lines 3-AUG-1987 23:50 -< hmm, i think i remember one... >- -------------------------------------------------------------------------------- try tom east, dept of anesthiesiology.... 801-581-6393 or teast%anesth@cc.utah.edu or for you uucp types: ...!utah-cs!teast%anesth@cc.utah.edu -ed ================================================================================ Note 92.2 [RSX]System Accounting Report Generator 2 of 4 EISNER::LEDERMAN "Bart Z. Lederman" 14 lines 4-AUG-1987 09:42 -< I did some once >- -------------------------------------------------------------------------------- > Does anyone know if there is a program submitted on an RSX SIG tape > which will take RSX-11M+ accounting information and generate reports > and billing info. I had submitted a package that re-defined all of the Datatrieve record definitions and procedures, and showed how to do something useful with the accounting information, along with the text of the presentation I gave at Symposia, to the RSX SIG tapes, and to the Datatrieve SIG tapes (which has been on the last two VAX and RSX SIG tapes). There were also some Fortran programs for massaging the data, and for graphing results on a PRO. Look in UIC [350,5*] on recent RSX tapes, or [.DTRSIG] on the last two VAX tapes. ================================================================================ Note 92.3 [RSX]System Accounting Report Generator 3 of 4 EISNER::MCGLINCHEY "Cape Malleum Majorem" 13 lines 19-AUG-1987 20:06 -< It's on the kit somewhere >- -------------------------------------------------------------------------------- Re: .0 Arnold, On the M-PLUS kits there is (at least once there was) a template DATATRIEVE procedure for doing just that. Memory is fading right now, and I don't have an RSX system at hand, but if I can get more description of it I'll pass it along. - Glinch. ================================================================================ Note 92.4 [RSX]System Accounting Report Generator 4 of 4 EISNER::MAXWELL "Gary Maxwell" 6 lines 20-AUG-1987 21:14 -< We've got one here >- -------------------------------------------------------------------------------- Arnold, we rolled our own here. It's in Fortran-77, should be easily tailorable, it does require Sort-11 (or something akin) to sort an intermediate text file. We haven't submitted it because it is too rough. Given your request, send me a tape (again), and I'll see it gets on the next SIG tape.  ================================================================================ Note 93.0 [RSX]F77FSL? 3 replies EISNER::DELARISCH 7 lines 4-AUG-1987 00:11 -------------------------------------------------------------------------------- How does one go about creating a Fortran-77 Supervisory mode library? Is it possible? Is there some documentation I'm missing which indicates how to do such? Can it be done with standard DEC OTS modules? Inquiring minds want to know! -Arnold ================================================================================ Note 93.1 [RSX]F77FSL? 1 of 3 EISNER::CETRON 5 lines 13-AUG-1987 00:01 -< call me direct, then post answer >- -------------------------------------------------------------------------------- send arpa mail (uucp) and I will describe or call me on phone...too tired (and busy to type) -ed ================================================================================ Note 93.2 [RSX]F77FSL? 2 of 3 EISNER::MCCARTHY 8 lines 21-SEP-1987 17:47 -------------------------------------------------------------------------------- Although it is possible to create A F77 OTS library which is linked to FCSFSL, I don't believe it is possible to create a F77 OTS library which is mapped in supervisor mode. The OTS contains pure data areas which can't be mapped in super mode. -Brian ================================================================================ Note 93.3 [RSX]F77FSL? 3 of 3 EISNER::MAXWELL "Gary Maxwell" 0 lines 18-NOV-1987 02:31 -< Not to mention it passes parameters on the stack >- --------------------------------------------------------------------------------  ================================================================================ Note 94.0 [RSX]F77 5.2 and Fast Mapping 5 replies EISNER::SEASTREAM 42 lines 10-AUG-1987 16:22 -------------------------------------------------------------------------------- We have just installed the new PDP-11 F77 V5.2 on our PDP-11/44 running RSX11M+ V3.0E. One of the features of this new "improved" version is the use of "fast" mapping for virtual arrays which is supposed to speed up virtual array processing. However, after recompiling and building several tasks using virtual arrays we found they seemed to run slower! (We are using the FCS OTS, merged into SYSLIB.) To verify this, we wrote a short test program and built it with and without the /FM switch: program test virtual ibuf(30000) integer*3 ibuf integer*4 ticks,start,finis start = ticks() do 100 i=1,30000 ibuf(i) = 123 100 continue finis = ticks() call report(start,finis) end (Function ticks() returns the current system time in ticks, subroutine report() reports the elapsed time in ticks. The program was built /-CP and run at priority 160. on a lightly loaded system.) We found that use of Fast Mapping consistently causes this program to take twice as long to execute. (The times reported coincide with observed execution time, the "fast" program runs noticably slower.) Is there a known problem with the new F77 OTS in this area or are we doing something wrong here?? There was no mention of restrictions/bugs on the new fast mapping feature in the release notes. ================================================================================ Note 94.1 [RSX]F77 5.2 and Fast Mapping 1 of 5 EISNER::DELARISCH 12 lines 11-AUG-1987 16:34 -< Not until V4.0 M+ >- -------------------------------------------------------------------------------- >> < Note 24.0 by EISNER::SEASTREAM > >> -< F77 5.2 and Fast Mapping >- >> >> We have just installed the new PDP-11 F77 V5.2 on our PDP-11/44 >> running RSX11M+ V3.0E. I thought that the (Transparent) Fast Mapping Directive wasn't going to be supported until RSX-11M-PLUS V4.0! I don't think that F77 V5.2 is smart enough to take advantage of it now. Am I wrong? -Arnold ================================================================================ Note 94.2 [RSX]F77 5.2 and Fast Mapping 2 of 5 EISNER::SEASTREAM 7 lines 17-AUG-1987 14:44 -< doesn't need 4.0 >- -------------------------------------------------------------------------------- I don't think this is the case, there was no mention of having to use version 4.0 of M+ in the release notes describing the fast mapping feature. Also if this were the case I think that the /FM tasks would run at the same speed, not slower. We have DEC working on the problem internally, no word yet aside from that there does seem to be a real problem. ================================================================================ Note 94.3 [RSX]F77 5.2 and Fast Mapping 3 of 5 EISNER::MAXWELL "Gary Maxwell" 5 lines 20-AUG-1987 21:18 -< A question and a comment >- -------------------------------------------------------------------------------- Do you have array bounds checking enabled (/CK) at compile-time? What is the difference in speed with/without it? I know Jerry Ethington wrote the fast map support for F77 under P/OS, and he said the performance was remarkable. ================================================================================ Note 94.4 [RSX]F77 5.2 and Fast Mapping 4 of 5 EISNER::ETHINGTON "Superior Klingon Technology" 71 lines 22-AUG-1987 01:19 -< F77 Virtual Array Performance >- -------------------------------------------------------------------------------- > I know Jerry Ethington wrote the fast map support for F77 under > P/OS, and he said the performance was remarkable. Oooolp, my name has been invoked and, like an evil demon, I rise from the dark mists to respond to the summons..... I disassembled the PDP-11 F77 OTS modules involved for F77 V5.0 and wrote my own fast map code to replace them. The test I performed was to write a simple program like this: Program FooBar Integer Varray Virtual Varray(4097) Do 10 I=1,1000 Varray(0) = 0 10 Varray(4097) = 0 End This gives you the idea - the real version had code to do timing so I could measure elapsed time in the loop. The value 4097 was specifically chosen to force a remap on every array reference, since this would reach beyond one APR in size. I compiled the hummer with /-CK, /TR:NONE, and (surprisingly) /-OP - it turned out that the optimizer jumped on this code and optimized the #(*#@&^ out of it and deleted the loop, and just set the two variables to zero directly. I looked at the generated code, and deemed it acceptable - no weird stuff, just straightforward accessing of a virtual array variable. With various permutations of the beastie, I set out to measure the overhead involved. The tests were done under P/OS V3.0 on my old development machine, a Pro 350 (now replaced by a Pro 380). I came up with the following figures: Loop overhead for access to static array element Overhead = 0.0271875 milliseconds Loop using conventional MAP$ and OTS support No Remap = 0.1984375 milliseconds (+ 0.17125) Remap = 1.595312 milliseconds (+ 1.5681245) Loop using fast remap routine No Remap = 0.1365625 milliseconds (+ 0.109375) Remap = 0.3321875 milliseconds (+ 0.305) You will notice there is a significant performance penalty involved with virtual arrays even if there is not a remap. By my count, if I recall correctly there are 28 instructions to be executed in the supplied OTS routines in the best case - no subscript checking, no remap. This overhead makes the loop 7 times slower if you are using virtual arrays. If the array reference causes a remap, which uses the MAP$ directive, the penalty goes up to 60 times slower - yuk. I wrote a super optimized replacement using fast map, no support for subscript checking, and a modified algorithm for determining whether or not to remap, all in an attempt to pull down the overhead in the case of no remap. This routine turned in an overhead of about 5 times for no remap, a useful improvement. The big win, however, was in the case of a remap - the 60x degradation plummets to a (mere!!!) 12x, a fivefold improvement over the conventional MAP$ support routine. The actual executive code to perform a fast map as opposed to a MAP$ is claimed to be 100 times faster or some such, but there is so much overhead (and none of it can really be improved upon without losing functionality) in the OTS routine that the performance gain drops to a still respectable 5X boost - a very useful improvement in view of how little is required to implement it. Jerry Ethington Prolifix, Inc. ================================================================================ Note 94.5 [RSX]F77 5.2 and Fast Mapping 5 of 5 EISNER::MCCARTHY 57 lines 21-SEP-1987 18:01 -< Your benchmark doesn't test fastmap. >- -------------------------------------------------------------------------------- First, to correct a misconception: F77 V5.2 on RSX-11M-PLUS version 3.0x will support fast mapping of virtual arrays. I'll reply to this benchmark here the way I have everywhere else: The benchmark as shown does not measure the performance of fast map. The first map in the FORTRAN OTS must be done by the OTS instead of FAST map. The OTS will only perform fast map or map operations when a virtual array reference: 1) References a different array than the previous reference, or 2) References a different 4K of the same array as the last reference Thus, sequentially writing to 30000 elements of an array requires 7 mapping operations, 1 of which is always a map. each of the 6 fast maps would have to be 5000 instructions longer than the map code to even come close to the run time of the program, since 30,000 instructions are needed just to store the data, let alone update loops. I have tested the program from .0 on several different systems and have gotten precisely the results I expected, i.e. no measurable difference with/without fast map. You are adding overhead via some other means when you test. By the way, a better benchmark is as follows: VIRTUAL II(30000),JJ(30000),KK(30000) DO 10 I = 1 , 30000 II(I) = I 10 CONTINUE TIME1 = SECNDS(0.0) ! Secnds is an OTS provided timing ! routine, giving seconds since the ! arg, or in this case since midnite DO 20 I = 1 , 30000 JJ(I) = II(I) KK(I) = II(I) 20 CONTINUE TIME2 = SECNDS(TIME1) ! Time2 is now loop time in seconds This benchmark generates, if my figuring is correct, 120,000 map operations. I've used it to benchmark fast map (when I did the OTS changes) and received values (on an 11/73) that were 7 times better with fast map than without. -Brian  ================================================================================ Note 95.0 [PRO300]Coming Soon to A Pro Near You No replies EISNER::ETHINGTON "Superior Klingon Technology" 19 lines 14-AUG-1987 05:17 -------------------------------------------------------------------------------- Well, according to SDC the scheduled FCS (first customer ship) for P/OS V3.2 and Tool Kit V3.2 is August 21. The list didn't show the corresponding release of Pro/DECnet, V2.1 - I guess it will be delayed a few weeks or something. V3.2 adds some nice new DCL commands and features, like a catchall task (finally!), flying install of tasks in APPL$DIR, a customization process for small disk systems so you can delete P/OS features you don't use, a new Application Builder that finally builds V3 compatible .INB files, a cool new utility to find bad blocks on your disk and handle them, new device support (LA75, LN03+, RD32, RD53), and many little assorted odds and ends. (Sigh) time to get out the checkbook, and get ready to order them there upgrade licenses, folks.....or, for those of you going to the Fall 87 Decus in Anaheim, I expect kits will be available in the PSG (or whatever the *^%#@^&% they're calling themselves this week) bookstore at SUBSTANTIAL savings..... Jerry  ================================================================================ Note 96.0 [RSX]Task Builder on RSTS 9 replies EISNER::HORN "Larry Horn" 18 lines 18-AUG-1987 04:59 -------------------------------------------------------------------------------- (This is a copy of note 15.2 in RSTS_OS, from 7/29/87) About three years ago I wrote a Basic+ program to dump the label blocks of a task image so I could see when it was actually linked, what libraries it used, etc. All this information is documented in Appendix "C" of the [RSTS] task builder reference manual. Unfortunately, an item I decided (tonight) to retrieve is not indicated in the description of the label blocks - the identification (%IDENT "string" in BP2). Appendix B indicates that it is stored in the label blocks, and using UNSUPP$:DSKDMP I can indeed find it in simple tasks - however, I'd like to have the correct links (and mnemonics) to follow to 'officially' track it down. Where I need it most is in more complicated tasks which are too complex to plunder with DSKDMP. What I'd really like to do is chain down all (at least user-compiled) modules in the task and indicate ident and compile date. Is this possible? ================================================================================ Note 96.1 [RSX]Task Builder on RSTS 1 of 9 EISNER::ETHINGTON "Superior Klingon Technology" 26 lines 22-AUG-1987 01:39 -< Module Idents and TKB/PAB >- -------------------------------------------------------------------------------- > What I'd really like to do is chain down all (at least user-compiled) > modules in the task and indicate ident and compile date. Is this > possible? In a word - no. Sadly, all such information is pitched before going into a task image. The ident of the first module encountered, or the value specified to TKB/PAB with the IDENT = option, appears in the variable part of the task header. This is in figure B-9 in the Task Builder Reference manual - not sure of the reference in the RSTS task builder manual. Actually, this is an item I want to put on the RSX wish list, a process somewhat facilitated by the fact that I am the new RSX SIG menu coordinator. I want support added to TKB to facilitate intermodule checking by newer languages such as Modula-2. Modula places within each object module a record identifying all definition modules it imports. The idea is that if you change a definition module, say to change a calling sequence, then try to link it with an object module bearing the ident stamp of the old definition module, the task builder would be able to see the different identification stamps and barf out an error message and abort. The ident stamp is in most Modula implementations a date/time stamp showing when the definition module was compiled, so this might prove useful for other languages too. Jerry Ethington ================================================================================ Note 96.2 [RSX]Task Builder on RSTS 2 of 9 EISNER::RICE "Gary Rice" 15 lines 22-AUG-1987 10:00 -------------------------------------------------------------------------------- > ...intermodule checking by newer languages such as Modula-2. Modula > places within each object module a record identifying all definition > modules it imports. The idea is that if you change a definition > module, say to change a calling sequence, then try to link it with > an object module bearing the ident stamp of the old definition module, > the task builder would be able to see the different identification > stamps and barf out an error message and abort. The ident stamp > is in most Modula implementations a date/time stamp showing when > the definition module was compiled, so this might prove useful for > other languages too. Sounds like an ADA environment to me. Gary ================================================================================ Note 96.3 [RSX]Task Builder on RSTS 3 of 9 EISNER::ETHINGTON "Superior Klingon Technology" 25 lines 25-AUG-1987 00:25 -< Nuts to ADA >- -------------------------------------------------------------------------------- > Sounds like an ADA environment to me. In this way alone, you're right - unlike ADA, however, Modula-2 is lean, mean, clean, simple, very Pascal-like (not surprising, since Niklaus Wirth conjured up both Pascal and Modula), and, due to its simplicity, it will be possible to implement on almost any computer system. The despicable complexity of ADA practically guarantees that development environments will be restricted to VERY large-memory, powerful machines, and even the execute environment is quite likely to be restricted. There will not be very many full implementations of ADA, for these reasons - subset implementations will abound, with only the simple and useful stuff retained to keep the size down. Enough ADA-bashing, back to the subject at hand - I just want generic support in the friendly neighborhood task builder to permit modern languages such as Modula or ADA to perform intermodule consistency checking. As a side effect, this would give the capability the original author of this subject requested - TKB would understand date/time stamps in object modules, and presumably could do something intelligent with them like stuff them into an .STB file or map or some bogus location in the task image or SOMETHING. Jerry ================================================================================ Note 96.4 [RSX]Task Builder on RSTS 4 of 9 EISNER::KENNEDY "Terry Kennedy" 13 lines 25-AUG-1987 20:45 -< Roll your own >- -------------------------------------------------------------------------------- > ... checking. As a side effect, this would give the capability the > original author of this subject requested - TKB would understand > date/time stamps in object modules, and presumably could do something > intelligent with them like stuff them into an .STB file or map or > some bogus location in the task image or SOMETHING. Well, look at VMS with ANALYZE/IMAGE and ANALYZE/OBJECT - all that info and LINK still doesn't know what to do with most of it. I think it is a pretty safe guess that if DEC won't do it for VMS, they won't do it for us PDP-11 users. Of course, the object module format IS documented, so an enterprising soul could come up with a TKB replacement which is fas- ter and also does what you want. It won't be me, however! Terry ================================================================================ Note 96.5 [RSX]Task Builder on RSTS 5 of 9 EISNER::ETHINGTON "Superior Klingon Technology" 7 lines 26-AUG-1987 22:51 -< Virtually Monstrous Software >- -------------------------------------------------------------------------------- > Well, look at VMS with ANALYZE/IMAGE and ANALYZE/OBJECT Yuk - Geeeeeez, do I *****HAVE***** to? ;} Jerry ================================================================================ Note 96.6 [RSX]Task Builder on RSTS 6 of 9 EISNER::KILLEEN "Jeff Killeen" 8 lines 18-OCT-1987 12:50 -< DUAL .PSECT NAMES FOR THE SAME THING >- -------------------------------------------------------------------------------- OK TKB wizards... I have two .PSECTS defined in a program. We will call them CHAN01 and USRMAP. At TKB time I want to assign them both to the same section of memory. I *DO NOT* want to assign them to a library or give them their own VSECT. Is there a TKB option or command that lets you assign two .PSECTS to the same memory without having to use up APR to do it? ================================================================================ Note 96.7 [RSX]Task Builder on RSTS 7 of 9 EISNER::STAMERJOHN "RW Stamerjohn" 1 line 19-OCT-1987 10:44 -< No >- -------------------------------------------------------------------------------- ================================================================================ Note 96.8 [RSX]Task Builder on RSTS 8 of 9 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 11 lines 9-DEC-1987 08:44 -< Subsets? Probably not. >- -------------------------------------------------------------------------------- RE: < Note 25.3 by EISNER::ETHINGTON "Superior Klingon Technology" > -< Nuts to ADA >- | There will not be very many full | implementations of ADA, for these reasons - subset implementations | will abound, with only the simple and useful stuff retained to keep | the size down. Of course, any such subset will not then be Ada, by definition, and will not be accepted by any government agency, so no one would use it. ================================================================================ Note 96.9 [RSX]Task Builder on RSTS 9 of 9 EISNER::FRIEDBERG 9 lines 25-APR-1988 04:20 -< Cross ref & obj mod info >- -------------------------------------------------------------------------------- RE: VMS link maps: (Sorry, folks, I am in both RSX and VMS) If you say $LINK/FULL/CROSS/MAP, you get eight different pieces in the resulting map, and one of them gives pretty exhaustive information on the compiler which generated the object module, etc. (as I recall). I never print these things out, but I always keep one version around when ever I am developing. You'd be surprised how useful it can be. Incidentally, I do the same thing with TKB; I always do a /CR on the map, and don't print it. About one time in 3 I need to look at the CR to find something or other; and I am grateful that it is there.  ================================================================================ Note 97.0 [RSX]SORT-11 PROBLEMS 1 reply EISNER::AMICK 20 lines 18-AUG-1987 13:39 -------------------------------------------------------------------------------- SORT-11 has giveûn me a number of problems. I have brought these up at symposia, and get acknowledgment of the problems, but no answers. Perhaps you can help. The symptoms are these: 1. Often the sort will go through the whole process and not write an output file. This is particularly so when using the sort statistics switch (/ss) 2. From time to time, sort will write only part of the output file and exit with an RMS error. 3. Sort will die with a mixed-key error when there is no chance of a mixed key. 4. As far as I can tell these problems occur relatively randomly, that is, I may or may not be able to reproduce the erroneous results. I have done these sorts with batch and command files, to rule out the likelihood of operator error, but the same batch submitted two times may yield two results. ================================================================================ Note 97.1 [RSX]SORT-11 PROBLEMS 1 of 1 EISNER::KENNEDY "Terry Kennedy" 9 lines 18-AUG-1987 19:55 -< I've seen that... >- -------------------------------------------------------------------------------- > 1. Often the sort will go through the whole process and not > write an output file. This is particularly so when using the > sort statistics switch (/ss) I've had this one under RSTS/E. It was fixed (at least it hasn't happened to me) since we upgraded to V9.0. I think it was actually a RMS problem, as the SORT image hadn't changed. I had the problem with a large (1 Mb) file in stream format, variable length records, most about 200 bytes long. Terry  ================================================================================ Note 98.0 [RSX]Dual-ported RK07's on M-Plus 4 replies EISNER::FRISBIE "Alan E. Frisbie" 32 lines 20-AUG-1987 12:46 -------------------------------------------------------------------------------- A friend of mine has a problem with dual-ported disks and we are looking for someone with actual experience with this. The system is in Italy, which accounts for the sketchiness of the information. CPU: PDP-11/44 (two) O/S: RSX-11M-Plus (version not known at this time) System Disk: Not known at this time Data Disks: Dual-ported RK07 look-alikes (solid-state disk emulators) with one CPU on each port. The desire is to have each drive mounted read/write on the primary CPU and read-only on the secondary CPU. I think that this is SUPPOSED to be supported. The problem as described to me is as follows: CPU "A" mounts an "RK07" with no problems. Files can be read and written OK. CPU "B" tries to mount the same drive and MOUnt never completes. MOUnt can be aborted, however. The drives and controller pass the diagnostics without problems (naturally). The question is: Does this work OK with real DEC RK07 drives or is this a hardware problem with the foreign disk controller? Is there an RSX version dependency that I should be aware of? Thank you, Alan Frisbie ================================================================================ Note 98.1 [RSX]Dual-ported RK07's on M-Plus 1 of 4 EISNER::STAMERJOHN "RW Stamerjohn" 4 lines 20-AUG-1987 13:23 -< It works for RP06's >- -------------------------------------------------------------------------------- I have done this with RP06's so I know there is nothing in executive or MOU which prevents dual-access to the same drive. Whatever problem there is must be in RK07 driver or this device. Suggest looking at volume valid code in RK07 driver. ================================================================================ Note 98.2 [RSX]Dual-ported RK07's on M-Plus 2 of 4 EISNER::KENNEDY "Terry Kennedy" 16 lines 20-AUG-1987 18:11 -< Used to work on RSTS... >- -------------------------------------------------------------------------------- >> The question is: Does this work OK with real DEC RK07 >> drives or is this a hardware problem with the foreign >> disk controller? Is there an RSX version dependency >> that I should be aware of? I did something similar with real RK's on RSTS/E a while ago. The only problems I had were with the rev level on the dual-access card and the port interface card, and the restriction that the cable lengths had to be the same, and could only be 1/2 the length allowed for single-port operation. However, this is all very specific to 'real' RK's. The quick test if they were real would be to pop the unit select/ready plug out and back in. That resets volume valid. Terry ================================================================================ Note 98.3 [RSX]Dual-ported RK07's on M-Plus 3 of 4 EISNER::DELARISCH 30 lines 20-AUG-1987 19:30 -< Not Supported Under M+ >- -------------------------------------------------------------------------------- >> < Note 27.0 by EISNER::FRISBIE "Alan E. Frisbie" > >> -< Dual-ported RK07's on M-Plus >- >> >> >> The desire is to have each drive mounted read/write on >> the primary CPU and read-only on the secondary CPU. >> I think that this is SUPPOSED to be supported. >> >> The question is: Does this work OK with real DEC RK07 >> drives or is this a hardware problem with the foreign >> disk controller? Is there an RSX version dependency >> that I should be aware of? I don't believe the configuration you are referring to is supported by DEC under RSX. According to the SYSGEN manual for RSX-11M-PLUS V3.0 page 1-9 under the section "dual-access device" the last paragraph states: "A dual-access [dual-ported] device can also be connected to controllers on two separate systems, but RSX-11M-PLUS does not support this configuration." I think there are a few problems with the ACP caching the directories and some other stuff. However, since hackers sneer at warnings which DEC makes ;-} I would agree with .-1 and .-2 that the problem is with the volume vaild section of the driver. -Arnold ================================================================================ Note 98.4 [RSX]Dual-ported RK07's on M-Plus 4 of 4 EISNER::MCCARTHY 30 lines 21-SEP-1987 18:14 -< Loosely coupled dual port disks - blecch. >- -------------------------------------------------------------------------------- A few words about systems coupled via dual port peripherals: In the lowest sense, it "works" with DEC peripherals. That is to say the drivers (DM,DB,DR) are reasonably familiar with recognizing that a drive is seized to the opposite port and waiting to get it back. In the next highest sense of "works", no, it doesn't. The ACP caches things such as directories and file headers, so although the single R/W, single R/O case won't corrupt anything on the disk, the R/O systems perception of the disk may become quite flawed. (e.g. The R/W system writes a record to an RMS ISAM file which splits a bucket and extends the file. The R/O system now sees the new data, but still has the old header, so the VBNs of the extended file are illegal.) In the highest sense of the word (Do we support it?), absolutely not. Not to throw stones at foreign disks, but historically the dual port logic, shall we say, has not received the attention to detail characteristic of emulating peripheral implementations. I recently saw an identical scenario, by the way. The Brand X disk did not set the dual port bit in the CSRs, which is what caused MOU to hang (the driver thought the drive was busted, not seized elsewhere). -Brian  ================================================================================ Note 99.0 [PRO300]DEC's support of the PRO 3 replies EISNER::ROECKEL 16 lines 21-AUG-1987 10:17 -------------------------------------------------------------------------------- I am a newcomer to the PRO arena and would like to here more about DEC's position on support of the PRO. My department recently aquired five PRO-350's and a MicroVAX II, all tied together with DECnet. The system performs real well, and I have had a blast writing code on the PRO that access files all over the network. The reason I ask about support, is that we are about to purchase a multi-million dollar system from DEC (based on three VAX 8800's and 10-12 MicroVAX's) and the vendor is quoting the standard VAX console. Come to find out that the VAX console is a PRO-380 running P/OS !! I was excited about it at first, but now am wondering if we should request a 'cluster console' based on the MicroVAX. Any comments/suggestions???? -- Bruce ================================================================================ Note 99.1 [PRO300]DEC's support of the PRO 1 of 3 EISNER::RICE "Gary Rice" 23 lines 22-AUG-1987 09:49 -< Down but NOT out >- -------------------------------------------------------------------------------- > The reason I ask about support, is that we are about to purchase > a multi-million dollar system from DEC (based on three VAX 8800's > and 10-12 MicroVAX's) and the vendor is quoting the standard VAX > console. Come to find out that the VAX console is a PRO-380 running > P/OS !! The reason for using a 380 or not really has NOTHING to do with PRO support. A more correct approach is how many console devices do you have room for? > I was excited about it at first, but now am wondering if > we should request a 'cluster console' based on the MicroVAX. Rumors abound regarding the life expectancy of the PRO. I anticipate a definitive announcement at Fall DECUS Symposium or around that time. In the meantime, the PRO continues to receive software updates from a small but active development team. In addition, there is STILL new activity in the third party arena both in software development as well as HARDWARE. You will have to look HARD to find it, but it is there. Gary ================================================================================ Note 99.2 [PRO300]DEC's support of the PRO 2 of 3 EISNER::ROECKEL 23 lines 22-AUG-1987 15:49 -< Setting me straight >- -------------------------------------------------------------------------------- Thank you Gary for setting me straight. I guess you are correct about making a decision on space instead of support. I am sure DEC won't drop support of the VAX consoles!!! It's good to here that there is still some activity out there in the third party world. Unfortunately, I am not in a position to purchase much new software/hardware for the PRO's. (the money just isn't around!!) My only concern would be that DEC will still maintain the equipment --- and maybe thats were I am getting 'support' confused. I guess when everyone talks about 'support', they must be refering to software updates/enhancements, etc. I also own a Rainbow-100A and hear alot of moans and groans about DEC support. Again, I am not in any position to purchase anything for my PC, so I don't let the 'lack-of-support' bother me too much. I enjoy writing software and have developed all my own programs for both the Rainbow (at home) and the PRO-350's (at work.) Thanks for the REPLY!!! I am new to all of this fancy conferencing, and am realy getting alot out of it. I think all of those people involved in setting up this system should get a big THANKS!! Bruce :-) ================================================================================ Note 99.3 [PRO300]DEC's support of the PRO 3 of 3 EISNER::RICE "Gary Rice" 16 lines 23-AUG-1987 08:31 -< Hardware support vs. Softare Support >- -------------------------------------------------------------------------------- > It's good to here that there is still some activity out there in > the third party world. Unfortunately, I am not in a position to > purchase much new software/hardware for the PRO's. (the money just > isn't around!!) My only concern would be that DEC will still maintain > the equipment --- and maybe thats were I am getting 'support' confused. DEC's offcial HARDWARE support position is "We will stock parts and cover repairs for 10 years after the announcemen of a "retirement" of a product. I have seen NOTHING that would lead me to believe anything else. In fact, we have a BUNCH of DX-11 equipment (PDP-11 to IBM communications stuff) that was discontinued 15 years ago. We can STILL get it repaired at the local DEC service center. They no longer allow us to have it on service contract, but will do "time & materials" repairs for us. Gary  ================================================================================ Note 100.0 [RSX]HELP! HOW CAN I FIND MY DZ 8 replies EISNER::TABOR "Bill Tabor" 8 lines 22-AUG-1987 12:10 -------------------------------------------------------------------------------- HELP! I HAVE TWO SYSTEMS RUNNING RSX-11M 3.2 WITH DT07 BUS SWITCHS. AND TRYING TO UPGRADE TO M-PLUS (PREGEN KIT). WE HAVE THE BUS SWITCH SOFTWARE FROM CSS. PROBLEM: HOW DO YOU TELL M-PLUS THAT A SECOND DZ IS ON THE OTHER SIDE OF THE SWITCH. ================================================================================ Note 100.1 [RSX]HELP! HOW CAN I FIND MY DZ 1 of 8 EISNER::MCGLINCHEY "Cape Malleum Majorem" 13 lines 22-AUG-1987 16:26 -< DT07 - How to...? >- -------------------------------------------------------------------------------- >> PROBLEM: HOW DO YOU TELL M-PLUS THAT A SECOND DZ IS ON THE OTHER >> SIDE OF THE SWITCH. I dunno either. I have a more elememtary problem: How do you tell M-PLUS SYSGEN that yu have a UNIBUS Switch? I can't seem to find the question. Oh, BTW, Lower case is preferred unless you want to SHOUT AT EVERYBODY. Politely, Jim ================================================================================ Note 100.2 [RSX]HELP! HOW CAN I FIND MY DZ 2 of 8 EISNER::TABOR "Bill Tabor" 16 lines 22-AUG-1987 21:07 -< Try Building the BS (bus switch) Driver >- -------------------------------------------------------------------------------- >> I dunno either. I have a more elememtary problem: How >> do you tell M-PLUS SYSGEN that yu have a UNIBUS Switch? >> I can't seem to find the question. There is a bus switch drive (BSDRV) on your sysgen kit, or in my case we bought the Bus switch software from Digital. We can get the system to see us switching the TE16 tape drive from one system to the other (got the MM driver from a full M-Plus kit) and if we load the drive the system will mark the unit offline until we switch the drive over using the manual switch. The pregen kit seems to have a funny terminal driver code and there is no way to get the system to mark the second DZ as being there. I suspect that I am missing something in the CON> commands that is so simple that I can't see it. ================================================================================ Note 100.3 [RSX]HELP! HOW CAN I FIND MY DZ 3 of 8 EISNER::DELARISCH 28 lines 25-AUG-1987 14:58 -< DT-07 Still In Use?ýé >- -------------------------------------------------------------------------------- >> < Note 28.2 by EISNER::TABOR "Bill Tabor" > >> -< Try Building the BS (bus switch) Driver >- >> >> >> I dunno either. I have a more elememtary problem: How >> >> do you tell M-PLUS SYSGEN that yu have a UNIBUS Switch? >> >> I can't seem to find the question. >> There is a bus switch drive (BSDRV) on your sysgen kit, or in my >> case we bought the Bus switch software from Digital. First of all, I'm impressed that anyone is still using a DT-07 (other than the RSX-11M-PLUS Development team!). For everyone's information and edification the DT-07 Bus switch is Supported under RSX-11M+ only with multiprocessor support Gened in and DEC will NOT support the configuration (however it works great)! The other alternative is to get the Bus Switch Driver from CSS (according to Brian McCarthy it works better then there's ever did!). 8-} As for your delema Bill, did you try something dumb like >CON ONLINE ALL I've had some flakey drivers that would ONLY respond to this "Brute Force" method of making it known. If you could do a >CON DISP ALL FU and give me the "current state" c CON thinks the driver is in ... we may be able to figure it out faster. -Arnold ================================================================================ Note 100.4 [RSX]HELP! HOW CAN I FIND MY DZ 4 of 8 EISNER::TABOR "Bill Tabor" 4 lines 9-SEP-1987 18:57 -< Still Can not get it Work! >- -------------------------------------------------------------------------------- This is a second call for HELP! I do have the BUS Switch Driver from CSS. They have been unable to help me as of yet. There request was to fill out an SPR. Is there anyone out there that has gotten CSS's BSDRV to work under RSX-11M Plus? ================================================================================ Note 100.5 [RSX]HELP! HOW CAN I FIND MY DZ 5 of 8 EISNER::MAXWELL "Gary Maxwell" 14 lines 17-NOV-1987 02:10 -< Something tells me... >- -------------------------------------------------------------------------------- Dusting off SYSGEN cobwebs in the back of my mind, mind you... But I believe I heard a developer (I won't blame any individual) who said that one MUST generate the multi-processor version of M-Plus to make the stuff work, and tell SYSGEN that you only have one CPU. Doing that turns on a LOT of stuff (scares the !%@^#%@ out of me!), which I believe will make the handling of the DT07 easier. By the way, what is the DT07 switched with? What's going on when you try to bring it up? Regards, A uniprocessor friend. ================================================================================ Note 100.7 [RSX]HELP! HOW CAN I FIND MY DZ 7 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 55 lines 21-NOV-1987 00:42 -< How to GEN a Uni-processor Multiprocessor M+ Sys >- -------------------------------------------------------------------------------- >> < Note 28.5 by EISNER::MAXWELL "Gary Maxwell" > >> -< Something tells me... >- >> Dusting off SYSGEN cobwebs in the back of my mind, mind you... Are you sure Gary that that isn't dust from the last Earth Quake? 8-} >> But I believe I heard a developer (I won't blame any individual) Don't Pick on Brian McCarthy like that Gary! 8-} >> who said that one MUST generate the multi-processor version of >> M-Plus to make the stuff work, and tell SYSGEN that you only >> have one CPU. Doing that turns on a LOT of stuff (scares the >> !%@^#%@ out of me!), which I believe will make the handling >> of the DT07 easier. I've done it (Gened a Uni-processor Multi-processor). It is a bit scary. Several things don't work quite the same. For instance, RMD constantly shows "A: *IDLE*" for running tasks which weren't expressly installed with an affinity to CPU A. Many non DEC drivers Break (multi- processor Driver support can't be tested ... so many Vendors leave it out!) DEC won't officially support your machine (Big Deal!). Further, there are a couple of problems which you will have to overcome in the sysgen. One is the Vector and CSR for the IIST device. Before you go and look it up in your SYSGEN man and fail to find it, it is the Inter-processor Interrupt and Sanity Timers. This is where the RSX Kernel can kick a processor in the side (to get its attention) and has all sorts of other goodies in it. DEC was nice enough (Thanks B.M.) to provide the critical lowcore stuff conditionally on the existance of the device. Hence, take the defaults for Vector and CSR. There is some incorrectly conditioned SYSGEN code which causes the SYSVMR.CMD file to contain a command which attempts to create a CPUPAR without reguard to how many processors are configured. The CPUPAR creation will fail if only one processor is configured. Hence comment it out in SYSVMR. I'm sure I forgot a bunch of stuff ... but this is enough to get you started. Please note that the last time I did this was for a PDP 11/44 under RSX-11M-Plus V3.0B. You should also read the IIST module as well as the BSDRV.MAC (I think thats what its called) which is the DT-07 specific code. Brian McCarthy told me that the BSDRV code wasn't the greatest in the world (there are comments in the code to prove it) and the Bus Switch should probably be done MANUALLY rather than by software. (Please correct me on it Brian if I have misquoted you or got the info from another RSX Developer!) -Arnold P.S. I liken my creating a Uni_processor Multi-processor RSX-11M+ system to putting a F-4 body on a single engine plane. It may sort of look like an F-4 Fighter Jet ... but it don't perform like one! ================================================================================ Note 100.8 [RSX]HELP! HOW CAN I FIND MY DZ 8 of 8 EISNER::MCCARTHY 64 lines 27-NOV-1987 18:40 -------------------------------------------------------------------------------- >>> But I believe I heard a developer (I won't blame any individual) > Don't Pick on Brian McCarthy like that Gary! 8-} I take the blame. >>> who said that one MUST generate the multi-processor version of >>> M-Plus to make the stuff work, and tell SYSGEN that you only >>> have one CPU. Doing that turns on a LOT of stuff (scares the >>> !%@^#%@ out of me!), which I believe will make the handling >>> of the DT07 easier. We, of course, run the development system (a four CPU 11/74 with two DT07s) with mP turned on. Judging by my past experience with other DEC operating systems on cofigurations different from the development group's system, it would scare the !%@^#%@ out of me to turn it off :-) > I've done it (Gened a Uni-processor Multi-processor). It >is a bit scary. Several things don't work quite the same. For instance, > >RMD constantly shows "A: *IDLE*" for running tasks which weren't expressly >installed with an affinity to CPU A. Ah, this is an iteresting one. Interesting given that nobody ever thinks about RMD and how it works. Has it ever occurred to you that RMD should always show RMD as the current task? RMD scans the ATL for the next active task and prints that name, not its own. In the early days of mPs, RMD showed the same task running all over. So now it only shows a task on the CPUs it isn't on, and apparently scans the ATL, but only for tasks with affinities. > Many non DEC drivers Break (multi- >processor Driver support can't be tested ... so many Vendors leave it out!) >DEC won't officially support your machine (Big Deal!). Interesting. We didn't change any drivers, just the exec. Except for drivers that call GTPKT from a subroutine, they shouldn't break on mPs. We did have to work on DUDRV, but that was written after mP support. I don't want to talk about TTDRV. > There is some incorrectly conditioned SYSGEN code which causes >the SYSVMR.CMD file to contain a command which attempts to >create a CPUPAR without reguard to how many processors are configured. >The CPUPAR creation will fail if only one processor is configured. Hence >comment it out in SYSVMR. I didn't know that. > Brian McCarthy told me that the BSDRV code wasn't the greatest in >the world (there are comments in the code to prove it) and the Bus Switch >should probably be done MANUALLY rather than by software. (Please correct >me on it Brian if I have misquoted you or got the info from another RSX >Developer!) My comments were based on the fact that there is a fundamental design stupidity in the driver. After a powerfail, the bus is reswitched well after the system's had a chance to attempt looking at switched devices. This means that the system in general will crash on power up. -Brian  ================================================================================ Note 101.0 [PRO300]Ever heard of CALL MSG ??? 8 replies EISNER::ROECKEL 20 lines 24-AUG-1987 09:22 -------------------------------------------------------------------------------- I need some help tracking down something I read in the PDP-11 FORTRAN77 OTS reference manual supplied with the PRO Fortran. Manual is Order # AA-V195A-TK Title is as stated above Chapter 9 - Error Processing and Execution Control Section 9.5 - User Interfacing to Terminal Message Output This section talks about a subroutine called MSG that is suppose to output a single line to the terminal. When I attempt to utilize this routine on the PRO, I get an unresolved external reference during LINK. Does anyone know what library this is in??? I am assuming that this routine is what MAIL uses to issue the 'new mail' message to the screen, correct?? I want to do something exactly like this with a program that will run in background on the machine. Can anyone lend a hand with this one?? Thanks Bruce ================================================================================ Note 101.1 [PRO300]Ever heard of CALL MSG ??? 1 of 8 EISNER::RICE "Gary Rice" 14 lines 24-AUG-1987 11:26 -< Not Supported >- -------------------------------------------------------------------------------- > I need some help tracking down something I read in the PDP-11 FORTRAN77 > OTS reference manual supplied with the PRO Fortran. > This section talks about a subroutine called MSG that is suppose > to output a single line to the terminal. Just above the program example is a little more info. The reference is resolved by a call to the $ERRLG routine. Normally, this is in SYSLIB. BUT, PROs have no error logging facility available. Hence, the module is not IN SYSLIB. You might try importing the module from an RSX system, but the PRO doesn't have it. Gary ================================================================================ Note 101.2 [PRO300]Ever heard of CALL MSG ??? 2 of 8 EISNER::ROECKEL 11 lines 24-AUG-1987 16:56 -< Then how does MAIL do it?? >- -------------------------------------------------------------------------------- If the PRO does not support this routine, how does the DECnet MAIL utility send its message to the terminal? It's such a nice feature, and I would love to utilize the same logic in some of my own programs. By the way, as soon as I figure out how to move data around in EVE, I will be able to create references like you'all do !! It only takes time !!! :-) Bruce ================================================================================ Note 101.3 [PRO300]Ever heard of CALL MSG ??? 3 of 8 EISNER::FRISBIE "Alan E. Frisbie" 9 lines 25-AUG-1987 01:20 -< MSG and $ERRLG >- -------------------------------------------------------------------------------- >> This section talks about a subroutine called MSG that is suppose >> to output a single line to the terminal. The MSG subroutine that is referenced is the eight lines of MACRO-11 code in the example on that page. You are expected to include this code yourself. It in turn calls $ERRLG, which is alleged to be missing on the PRO. Alan ================================================================================ Note 101.4 [PRO300]Ever heard of CALL MSG ??? 4 of 8 EISNER::RICE "Gary Rice" 15 lines 26-AUG-1987 12:53 -< 'Fess UP! >- -------------------------------------------------------------------------------- > If the PRO does not support this routine, how does the DECnet MAIL > utility send its message to the terminal? I don't know. I assume that it uses something that is part of DECnet. > By the way, as soon as I figure out how to move data around in EVE, > I will be able to create references like you'all do !! It only > takes time !!! :-) EVE? References??? What do you mean????? I have heard hints of uploads, but I currently type all my entries in via EDT. What are YOU planning? Gary ================================================================================ Note 101.5 [PRO300]Ever heard of CALL MSG ??? 5 of 8 EISNER::ROECKEL 32 lines 27-AUG-1987 13:47 -< EVE or EDT??? >- -------------------------------------------------------------------------------- > EVE? References??? What do you mean????? I have heard hints of > uploads, but I currently type all my entries in via EDT. What are > YOU planning? What I mean by references is how you extract verbage from the note you are REPLYing to and place ">" signs in front of it. As you can see, I just figured it out !! All it takes is a little light reading on my part :-) By the way, how did you get EDT?? I followed the instructions on setting the EVE keypad to emulate EDT, but I am still in EVE !! > I don't know. I assume that it uses something that is part of DECnet. Does anyone else know?? I must say I don't agree with Gary on his assumption. MAIL is a program that executes on the PRO and receives or sends mail to other nodes (PRO's or VAX's) on our network. When the MAIL utility receives mail and places it my hard disk, a message is generated and displayed on my terminal. The nice thing about this is that no matter what program I am running under P/OS (PROSE, 20/20 Spreadsheet, PRO/Comm, etc.) this message will automatically appear on line 24 of the screen !!! As a matter of fact, as I am writing this REPLY in notes, MAIL just informed me I have received something new. The format of the message generated agrees with the description given in the FORTRAN77 manual --- the name of the program, followed by a single line message. What mail puts out is: MAIL - New mail has been recived on node VARS Any ideas anyone ??? ================================================================================ Note 101.6 [PRO300]Ever heard of CALL MSG ??? 6 of 8 EISNER::RICE "Gary Rice" 26 lines 28-AUG-1987 11:34 -< Is THIS more convincing? >- -------------------------------------------------------------------------------- > . . .light reading on my part :-) By the way, how did you get EDT?? > I followed the instructions on setting the EVE keypad to emulate EDT, > but I am still in EVE !! I had the same touble. Here is the way to do it: Issue the command: SET PROFILE/EDITOR=(EDT,CALLABLE) That should do it for you. >> > I don't know. I assume that it uses something that is part of DECnet. > Does anyone else know?? I must say I don't agree with Gary on his > assumption. MAIL is a program that executes on the PRO and receives > or sends mail to other nodes (PRO's or VAX's) on our network. When > I don't know. I assume that it uses something that is part of DECnet. I made that statement based on my own two systems. DECnet is not installed on either of them. AND, I have never seen a message appear on line 24 from some source besides a program that I wrote myself. I therefore connected your MAIL message to DECnet . . . Gary ================================================================================ Note 101.7 [PRO300]Ever heard of CALL MSG ??? 7 of 8 EISNER::ETHINGTON "Superior Klingon Technology" 15 lines 30-AUG-1987 00:08 -< Mail Messages >- -------------------------------------------------------------------------------- I have DECnet installed on my systems, too. I suspect Mail (and Phone for that matter) are just performing QIOs to output their message to the terminal. Some of the QIO subfunctions that would be useful to a program attempting to output messages like this (all of which are documented in the P/OS system reference manual), are write with breakthrough, restore cursor, and terminal independent cursor positioning. I suspect Mail and phone use write with breakthrough, so they can interrupt output from other programs; terminal independent cursor positioning to place the cursor on line 24, column 1; and restore cursor, so the system will output the message and then move the cursor back to where it was before the message interrupted it. Read the chapter on the terminal driver in system reference; the whole thing is well documented in there. Jerry ================================================================================ Note 101.8 [PRO300]Ever heard of CALL MSG ??? 8 of 8 EISNER::DELARISCH 16 lines 31-AUG-1987 15:09 -< Yes, but what about EDT??? >- -------------------------------------------------------------------------------- >> < Note 14.7 by EISNER::ETHINGTON "Superior Klingon Technology" > >> -< Mail Messages >- >> >> I suspect Mail and phone use write with >> breakthrough, so they can interrupt output from other programs; >> terminal independent cursor positioning to place the cursor on line >> 24, column 1; and restore cursor, so the system will output the >> message and then move the cursor back to where it was before the >> message interrupted it. Read the chapter on the terminal driver >> in system reference; the whole thing is well documented in there. Maybe, but EDT does its own internal cursor positioning (I got bit bad with this one!) instead of using the system service calls that the underlying O/S provides (for O/S independence I guess :-{ ). -Arnold  ================================================================================ Note 102.0 [RSX]LAT BUG? 2 replies EISNER::NORTON 6 lines 26-AUG-1987 11:05 -------------------------------------------------------------------------------- LAT terminals on an RSX V3.0B system. Terminal user does connect to the RSX node, then gets NO response ( no > even). More connects to the same node work OK. If the user disconnects that session and someone else happens to connect to that particular TTn:, they're dead too. Is the TTn: UCB getting corrupted or something? Restarting LAT on the node doesn't help, rebooting does. ================================================================================ Note 102.1 [RSX]LAT BUG? 1 of 2 EISNER::DELARISCH 25 lines 26-AUG-1987 17:04 -< More LAT Bugs! >- -------------------------------------------------------------------------------- >> < Note 29.0 by EISNER::NORTON > >> -< LAT BUG? >- >> >> LAT terminals on an RSX V3.0B system. Terminal user does connect >> to the RSX node, then gets NO response ( no > even). More connects >> to the same node work OK. If the user disconnects that session >> and someone else happens to connect to that particular TTn:, they're >> dead too. Is the TTn: UCB getting corrupted or something? Restarting >> LAT on the node doesn't help, rebooting does. Yup, It acts just like a normal terminal ... if the TTDRV database gets messed up ... either reboot or use OPEn to blast the database to sanity! There is also another Nasty bug under V3.0B (and LAT), when someone aborts out of a terminal session with the terminal set to /NOECHO the database changed back to echo. (i.e. I get a LOT of phone calls telling me that the system is down and I need to do something about it .... It was one smartass L-user who set every LAT terminal to /NOECHO and aborted out of his sessions!) -Arnold P.S. By the way ... we fixed the L-user (An Asst. Prof.) by giving him his own MacIntosh and taking away his terminal!!! P.P.S The /NOECHO bug has been fixed around update C or D! ================================================================================ Note 102.2 [RSX]LAT BUG? 2 of 2 EISNER::BOSTWICK 23 lines 15-SEP-1987 19:22 -< Maybe not a bug, but a feature >- -------------------------------------------------------------------------------- -< Possibly Not a LAT Bug per se' >- > LAT terminals on an RSX V3.0B system. Terminal user does connect > to the RSX node, then gets NO response ( no > even). I know it's unsupported, but we run a print queue through a LAT port. This only works because the queue is set up (and thus grabs the lat port) at boot time, BEFORE anyone else tries to log on! There is a problem with this, however. If the net goes down, or the 73, but not the terminal server, when things come back again, the server goes out and tries to re-connect the 'orphan' sessions. It does NOT try to use the same TT ports, however. This can, and usually does, result in some user getting stuck on the spooled TT:! Which can lead to the behavior you see. Actually, any port set 'funny' (e.g., SLAVE, NOECHO, etc.) can do this. I know this is not exactly the problem you are seeing, but it may give some food for thought.  ================================================================================ Note 103.0 [RSX]RD54's with Micro/RSX v3.1? 1 reply EISNER::FRISBIE "Alan E. Frisbie" 11 lines 26-AUG-1987 20:41 -------------------------------------------------------------------------------- I note that in the latest (Electronic Store) copy of the Micro/RSX v3.1 SPD, it says nothing about support for the RD54. Does anyone know if the RD54: 1) Works with Micro/RSX v3.1? (The important question) 2) Works, but with restrictions? 3) Is supported? (Much less important) 4) Will be supported in a future major/minor release/update/enhancement/bug-fix? Alan ================================================================================ Note 103.1 [RSX]RD54's with Micro/RSX v3.1? 1 of 1 EISNER::MCCARTHY 21 lines 21-SEP-1987 18:21 -< It should work >- -------------------------------------------------------------------------------- I note that in the latest (Electronic Store) copy of the Micro/RSX v3.1 SPD, it says nothing about support for the RD54. Does anyone know if the RD54: 1) Works with Micro/RSX v3.1? (The important question) To the best of my knowledge, yes. We tested it on 3.1 and we made no changes to support the RD54 at all. 2) Works, but with restrictions? 3) Is supported? (Much less important) It's as supported as anything else in a Micro/RSX release, i.e. we'll try our darndest to fix it but reserve the right to say restriction. 4) Will be supported in a future major/minor release/update/enhancement/bug-fix? It will be in the SPD for version 4.0. -Brian  ================================================================================ Note 104.0 [RSX]RSX11S? 6 replies EISNER::DEGUMBIA 7 lines 4-SEP-1987 23:39 -------------------------------------------------------------------------------- I have a question about RSX11S. Just what is it? As I explained (sort of) in WHO_AM_I, we are running RSX11M 3.1 at my shop. We are in the process of changing that. We are going to upgrade to the latest version of M+. We use two 11/70's as our redundant main computers, and two 11/70's as communication front-ends. I am wondering what advantage S has over M+ in this situation. I understand that S doesn't use disks, or need a console? ================================================================================ Note 104.1 [RSX]RSX11S? 1 of 6 EISNER::GARDNER "Tim Gardner" 38 lines 5-SEP-1987 08:24 -< 11S is basically a Run Only 11M >- -------------------------------------------------------------------------------- > I have a question about RSX11S. Just what is it? > > I understand that > S doesn't use disks, or need a console? You will find that RSX-11S is a memory resident subset of RSX-11M. It was designed for dedicated, run-only environments, where an operating system could be download via some commications path (i.e. DECnet) and local disks were not necesary. Disks are supported, and if you really want it, you can get a file system on them, but 11S does not require any disk. This is in obvious contrast to 11M, where a disk is mandatory. The lack of a local disk implies that all tasks are memory resident (i.e. FIXed). Dynamic task loading can be accomplished when a local disk is present, but is not as flexible/useful as its counterpart in 11M. A console terminal is also supported, but not required. If you don't have a terminal, you don't need MCR, so it too, is optional. DECnet support is available, and if present can be used to downline load the 11S system from an 11M or M+ host. Upline dumping is also available. Most of the directives in 11M are available in 11S, but a few are missing. These generally fall into the category of ``not useful'' in a run only environment. In short, if you have static applications, 11S may be useful to you. If you want to do ANY program development (or for that matter, virtually any interactive application), you'd best look to M or M+. Hope this clears the mud at least a little. T. ================================================================================ Note 104.2 [RSX]RSX11S? 2 of 6 EISNER::MCGLINCHEY "Cape Malleum Majorem" 18 lines 5-SEP-1987 19:55 -< Subset of M, not M-PLUS. >- -------------------------------------------------------------------------------- >> >> You will find that RSX-11S is a memory resident subset of RSX-11M. >> I feel I must comment here. This description is correct, but you must remember that it _is_ a subset of RSX-11M, not M-PLUS. The difference is very important. RSX-11S does not support: Supervisor Mode I and D space separation secondary pool or any of the other performance enhancing goodies that make M-PLUS different from M. -GLinch. ================================================================================ Note 104.3 [RSX]RSX11S? 3 of 6 EISNER::TINKELMAN "Bob Tinkelman - CCA" 11 lines 5-SEP-1987 21:41 -< I remember, I think, that... >- -------------------------------------------------------------------------------- My memory is a little fuzzy, but I think I recall the following from one of the "What DEC always wanted to know about RSX" symposia sessions: Brian MacCarthy asked questions which made me think at the time that he (or DEC) really wanted to get rid of RSX-11S as a separate thing. He seemed to be asking "suppose we forgot about all that stuff that's in only RSX11S and gave you a version of RSX11M-Plus which you could tailor to run without a file system. Would that be OK?". I think that the answer he got was "Yes". Does anyone else remember that conversation? (Including Brian?) ================================================================================ Note 104.4 [RSX]RSX11S? 4 of 6 EISNER::GARDNER "Tim Gardner" 16 lines 8-SEP-1987 07:41 -< Quite correct >- -------------------------------------------------------------------------------- > > >> > >> You will find that RSX-11S is a memory resident subset of RSX-11M. > >> > > > I feel I must comment here. This description is correct, > but you must remember that it _is_ a subset of RSX-11M, > not M-PLUS. The difference is very important. > Of course, you are quite correct. I didn't mean to imply otherwise (and should have been explicit). T. ================================================================================ Note 104.5 [RSX]RSX11S? 5 of 6 EISNER::MCCARTHY 30 lines 21-SEP-1987 18:39 -< The fate of RSX-11S-PLUS >- -------------------------------------------------------------------------------- >My memory is a little fuzzy, but I think I recall the following from one >of the "What DEC always wanted to know about RSX" symposia sessions: > > Brian MacCarthy asked questions which made me think at the time > that he (or DEC) really wanted to get rid of RSX-11S as a > separate thing. He seemed to be asking "suppose we forgot about > all that stuff that's in only RSX11S and gave you a version of > RSX11M-Plus which you could tailor to run without a file system. > Would that be OK?". I think that the answer he got was "Yes". > >Does anyone else remember that conversation? (Including Brian?) Yup. I remember it quite well. In fact we did a significant amount of planning and some prototyping for RSX-11S-PLUS at the time. However, we can't do everything we'd like to do, and S+ came to an abrupt end due to resource conflicts. We deemed that VAX CoPRocessor/RSX was more important. I would point out that someone who looks remarkably like me stood up in Nashville and described a "possible future direction for VAX CoPRocessor/RSX" as using Ethernet transports, VAX hosts, and any old PDP-11 as the tartget. Other than VAX-only host support, this configuration would look remarkably like RSX-11S-PLUS, only much more integrated at the systems level. Your 11S system can share files with a VAX application. -Brian ================================================================================ Note 104.6 [RSX]RSX11S? 6 of 6 EISNER::DEGUMBIA 6 lines 21-NOV-1987 13:03 -< Thanks >- -------------------------------------------------------------------------------- Thank you all for taking the time to reply. I have been away for quite some time, working on our M 3.1 to M+ 4.0 conversion. I must say, things have changed a LOT! (and remained the same) I just managed to obtain a stained, photocopied RSX11S SPD from my sales rep. Once I get it translated, along with your input, I think I'll be all set. Thank you all.  ================================================================================ Note 105.0 [PRO300]Macro PSECT Names No replies EISNER::SACHS 24 lines 10-SEP-1987 14:45 -------------------------------------------------------------------------------- I recently experienced a problem that took me several days to solve. I thought I'd relate it here for the benefit of others who may have experienced weird run-time problems. If you write MACRO subroutines, you should give the .PSECTs different names, as the linker concatenates *identically named* .PSECTions without regard to even/odd address placement. This can result in randomly operating subroutines and bomb-outs (e.g., odd-address traps, illegal memory access violations). You can even play Russian roulette with your subroutines just by changing their listed order in the .ODL file. This problem had cropped up recently, and it involved MACRO sub- routines (usually linked to FORTRAN or PASCAL programs) that I have been using for the past two years. They all had no declared .PSECT names (in which case, I believe, the default .BLK. is then used). I guess most of those old routines were coincidentally of even-byte lengths, and I just now happened to write some odd-length stuff. It was a poser in any case. P.S. The linker always starts a uniquely named PSECT at an even address.  ================================================================================ Note 106.0 [RSX]Problem with borrowed RA81 2 replies EISNER::NORTON 19 lines 21-SEP-1987 11:32 -------------------------------------------------------------------------------- <<< This is a duplicate of Note 55.0 in HARDWARE_HELP >>> I borrowed an RA81 from our VAXcluster to use on an 11/70 under RSX11M-Plus. Problem is that when I try to run the bad block scan on it, the RCT task reports "Write back caching data lost. Unit write locked", and BAD dies. The manual says this is due to the "writeback cache in use" bit being set in the disk's RCT, and that this is very rare. Question is, how do I clear this bit? Is there a way to clear it online? Would reformatting the RA81 on the HSC do it, or would I have to format from the 11/70? ================================================================================ Note 106.1 [RSX]Problem with borrowed RA81 1 of 2 EISNER::MCCARTHY 10 lines 21-SEP-1987 18:46 -------------------------------------------------------------------------------- I think reformatting on the HSC would, but not sure. We've seen this on occasion, but aren't sure why. To get it, some system has to have enabled the write-back cache and then gone belly up. I don't believe any DEC system enables it, so we don't understand how it ever happens. -Brian ================================================================================ Note 106.2 [RSX]Problem with borrowed RA81 2 of 2 EISNER::KASPER "Beverly T. Kasper" 0 lines 22-SEP-1987 15:12 -< Answers are in Hardware_help >- --------------------------------------------------------------------------------  ================================================================================ Note 107.0 [RSX]Suggested CON enhancement 7 replies EISNER::NORTON 5 lines 22-SEP-1987 15:20 -------------------------------------------------------------------------------- How about enhancing CON and RD: to be able to modify the physical unit number in a disk's UCB? This would make the unit ID plug as flexible as the device type. ================================================================================ Note 107.1 [RSX]Suggested CON enhancement 1 of 7 EISNER::MCCARTHY 35 lines 22-SEP-1987 20:33 -< Not as easy as it looks. >- -------------------------------------------------------------------------------- It's a nice idea, but it isn't all that simple. In addition to changing the U.UNIT field in the UCB, the KRB UCB table entry corresponding to the new unit number on the controller. SYSGEN creates the KRB UCB table with a fixed size which reflects the highest unit number SYSGEN knows about. Fear of changing SYSGEN has always stopped me from doing this. Also, for MSCP controllers the UCB table would need to be 256 words long, which would eat some pool. There's also cross checking of unit numbers in dual port configurations to consider. Why do I remember all these complications so quickly, you may ask? Or you may not but I'll tell you anyway. The first week I was with the RSX group I was put to work on a problem where some benchmark tests would occasionally hang up an RP06 in a state where it would flash once every 4 seconds for 32 seconds, then go about it's business. I did a SYSGEN for our 4 processor multiprocessor system to test with, and screwed up some unit numbers. I editted SYSTB and changed U.UNIT, but neglected the KRB UCB table. (Obviously, I didn't know that at the time). In the next two weeks I found four, count 'em four, problems in the exec and DBDRV which would cause this symptom. One of them was the one I was looking for, and the benchmark ran fine, but my stupid test system still didn't work right. The KRB UCB table is only used when the system actually does an overlapped seek, so forcing it to happen wasn't too easy. When I finally found it, I considered the 4 problems I'd found and reached the conclusion that user stupidity plays an extremely important role in improving the quality of software. -Brian ================================================================================ Note 107.2 [RSX]Suggested CON enhancement 2 of 7 EISNER::FRISBIE "Alan E. Frisbie" 10 lines 23-SEP-1987 03:03 -< Foolproof software... >- -------------------------------------------------------------------------------- >> I considered the 4 problems I'd found >> and reached the conclusion that user stupidity plays an >> extremely important role in improving the quality of >> software. Thus the need for field test sites. :-) "It is difficult to make anything foolproof because fools are so dammed ingenious." Alan ================================================================================ Note 107.3 [RSX]Suggested CON enhancement 3 of 7 EISNER::NORTON 10 lines 23-SEP-1987 12:03 -------------------------------------------------------------------------------- > It's a nice idea, but it isn't all that simple. In addition to > changing the U.UNIT field in the UCB, the KRB UCB table entry > corresponding to the new unit number on the controller. Have I set myself up for problems by modifying the physical unit for one of the disks in DUTAB.MAC and reassembling and linking DUDRV? DU: config. is DUA --> DU0:,DU1:(RX50), DUB --> DU2:(RA81). The SYSGEN specified physical unit 2 for DU2 and the actual drive turned out to have a 4 plug in it. ================================================================================ Note 107.4 [RSX]Suggested CON enhancement 4 of 7 EISNER::MCCARTHY 10 lines 23-SEP-1987 19:00 -------------------------------------------------------------------------------- Right at this particular moment, I'm not sure how the DU driver back links from the controller to the UCB. I believe that DUDRV has to use that linkage constantly (unlike DB/DR/DM) and as a result if the driver is working at all it's probably going to work all the time. We may have sized that stuff at controller on-line, I'm not sure, but will check. -Brian ================================================================================ Note 107.5 [RSX]Suggested CON enhancement 5 of 7 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 89 lines 23-SEP-1988 18:39 -< the problem is BIGGER than CON >- -------------------------------------------------------------------------------- >>> How about enhancing CON and RD: to be able to modify the physical >>> unit number in a disk's UCB? This is a wonderful idea. But I see it as only part of a bigger problem. RSX does not give you adequate flexibility in assigning numbers and arbitrarily forces needless restrictions that preclude what should be valid hardware configurations. I will describe such a configuration and then how to do it in spite of SYSGEN 'protecting' you from doing the needed thing. CON changing unit physical numbers would simply make things more flexible and smoother. These comments are all targeting DU type devices. Take 3 11/84s and put them in a triangle. Between each 2 cpus place 2 ra81s dual ported to each cpu. The idea is to have a backup machine that can get at some of either of the other machine's disks. Note that each cpu has 4 connections filling its UDA50, and each runs exactly the same sysgen. Let us assume the sysgened physical numbers were 0,1,2,3. Note also that even with a drive's A and/or B buttons set for only one port, the other port still 'sees' the unit plug number. Now assign unit plugs to the 6 drives such that each cpu only sees any number once (twice is illegal on a hardware level). You simply CAN'T do it. You could do 3 seperate gens. One for 0,1,2,3 and another for 2,3,4,5 and the last for 4,5,0,1. That would work but what a pain. The fix to CON would help. Far simpler, simply gen 6 UCBs. One each for physical numbers 0,1,2,3,4,5. Now RSX's data structures do the right thing and everything simply works! But wait a minute, SYSGEN won't let you do it... The fix to SYSGEN is simple. Extract SGNMAS from [200,200]SYSGEN.CLB and edit 2 lines. These are M+ 4.1 line numbers. At line 3584 there is: .SETN TEMPN NCONTR*4 That simply sets the limit of units at 4 times controllers. Change it to: .SETN TEMPN 400 Then at line 4625 there is: .IF NUNT'ZZN' LT 4 .GOTO CHKC5 That can be changed to: .IF NUNT'ZZN' LT 400 .GOTO CHKC5 Or simpler yet: .GOTO CHKC5 Then stick SGNMAS.cmd back in SYSGEN.CLB, and of course send a 'thank-you' SPR to Spitbrook Road. The biggest I have done was an M+ 2.1 system that went to DU17: on one controller and another also to DU17:, but 0-7 on the first UDA-50, and 10-17 on the second. Both worked fine. Also WATCH those buttons!! and your handy operators. Normally (for sanity, not necessity) you have DUxx:'s xx match the physical number which on RA60/81/82 is a plug you break fingers off to encode. You then write the number on the plug or use those nice stickers DEC provides. RSX wants OCTAL. Guess what happens when plug #17 wanders over to the VAX's disks... These changes are also necessary if you are buying any other brand controller that gives you more than 4 units. There are ones that could give you: 4 big disks, 2 floppies = 6 units 4 physical * 4 splits each = 16 'units' 8 1.23g SMDs on a DUAL Q! = 8 units And so on. There is also a controller company that WRITES the unit number on the disk during formating, and IGNORES unit number plugs and buttons! They planned for never-to-be-moved winchesters and forgot about the now popular removable winchesters, and MY old CDC-9766s (RM05s). If you have only 6 packs in your library, or only mount one at a time so all 60 packs can be numbered 'unit 2' there is no problem. If CON were fixed, you would also be set, but otherwise consider how much pool 60 UCBs would take! Or if you were at 65, what would break with the 3 numbers in DU101:? They are looking at a microcode 'fix', but failing that, watch for a follow-on note in the HARDWARE conference. ================================================================================ Note 107.6 [RSX]Suggested CON enhancement 6 of 7 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 3 lines 23-SEP-1988 18:47 -< Whoops - count again >- -------------------------------------------------------------------------------- >>> Or if you were at 65, what would break with the 3 numbers in DU101:? Miscounted - 65 units would be DU100:, sorry. ================================================================================ Note 107.7 [RSX]Suggested CON enhancement 7 of 7 EISNER::KENNEDY "Terry Kennedy" 8 lines 23-SEP-1988 19:58 -< It *could* be worse... >- -------------------------------------------------------------------------------- Well, at leat this isn't VMS! In VMS we couldn't get an RA81 with a unit plug of 27 to mount on a UDA - got 'Unit number out of range'! [And, of course, DEC ships exactly *one* unit select plug with each drive because Field Service never makes mistakes, right? For those of you who followed the Alan Frisbie caster saga, can you tell me what the 'next higher assembly' for a RA81 unit select plug is? Can you say 'RA81-AA'? DEC knew you could.]  ================================================================================ Note 108.0 [RSX]J11 COPROCESSOR FOR VAX 5 replies EISNER::KILLEEN "Jeff Killeen" 13 lines 22-SEP-1987 22:55 -------------------------------------------------------------------------------- This question comes from a RSTS user (no flak please). I saw the J11 VAX Coprocessor project mentioned in the Futures in real time Conference. I have some questions. 1. How much of a M+ environment does the user get? 2. Could this be used for general commercial applications? Being able to run my PDP-11 apps on both an 11 and a VAX might make me think about becoming an RSX user. Since I have an installed base of 78 PDP systems this could solve a very big problem for me. ================================================================================ Note 108.1 [RSX]J11 COPROCESSOR FOR VAX 1 of 5 EISNER::MCCARTHY 32 lines 23-SEP-1987 18:57 -< This idea has much promise and merit >- -------------------------------------------------------------------------------- >This question comes from a RSTS user (no flak please). I saw the J11 >VAX Coprocessor project mentioned in the Futures in real time >Conference. I have some questions. > 1. How much of a M+ environment does the user get? Well, in version 1 the user doesn't get RSX batch, but can invoke RSX tasks from VMS batch. You also don't get the RSX print command, so applications that spawn print may require modification if they use syntax that VMS doesn't understand. Other than that we expect complete compatability with a full function RSX I/D supervisor mode system. > 2. Could this be used for general commercial applications? Yes. In fact V1 is better suited to this than to many real time applications because of the KXJ's limited I/O devices (It can't really communicate well with off board peripherals.) >Being able to run my PDP-11 apps on both an 11 and a VAX might make me >think about becoming an RSX user. Since I have an installed base of 78 >PDP systems this could solve a very big problem for me. I would feel that we had been more successful than I could have dreamed if we have provided a reasonable migration and coexistence path for RSTS users. -Brian ================================================================================ Note 108.2 [RSX]J11 COPROCESSOR FOR VAX 2 of 5 EISNER::KILLEEN "Jeff Killeen" 18 lines 23-SEP-1987 19:16 -< HMMM... MORE QUESTIONS >- -------------------------------------------------------------------------------- ! >Being able to run my PDP-11 apps on both an 11 and a VAX might make me ! >think about becoming an RSX user. Since I have an installed base of 78 ! >PDP systems this could solve a very big problem for me. ! ! I would feel that we had been more successful than I could have ! dreamed if we have provided a reasonable migration and coexistence ! path for RSTS users. Don't get to excited yet! You would also have to officially support RT-11 Basic-Plus (which really is RSTS Basic-Plus) running under the RSX RT emulator. From what I understand this works now but is not supported. And another question. How many jobs (oops tasks) can one of these boards support? I am looking best guess here - not 3000 bench marks. ================================================================================ Note 108.3 [RSX]J11 COPROCESSOR FOR VAX 3 of 5 EISNER::FRISBIE "Alan E. Frisbie" 27 lines 23-SEP-1987 22:21 -< Great, but not yet perfect >- -------------------------------------------------------------------------------- >> In fact V1 is better suited to this than to many real time >> applications because of the KXJ's limited I/O devices (It can't >> really communicate well with off board peripherals.) That is the main problem that I have with trying to work it into my applications. If a future version will remove that restriction, I will be in heaven. I understand the hardware problems (I think) and will be interested to see how you solve them. Even so, I am very excited about this product and am proposing its use for some very CPU intensive applications. As an example, one project has an incoming data stream where the high-order bit of each 16-bit word must be thrown away. The remaining bits in the buffer must be packed together. This is a lot of bit shifting that has nothing to do with the analysis of the data and could easily be offloaded to another CPU. This is the simplest of the bit manipulation tasks that the system must do. The others get REALLY wild! We have already implemented this on an 11/44, but the actual analysis of the data has outstripped the address space of the PDP-11 and we need to move to a VAX. If I can keep the dirty bit-diddling work on the KXJ, I can make the analysis programs run *really* fast. Alan ================================================================================ Note 108.4 [RSX]J11 COPROCESSOR FOR VAX 4 of 5 EISNER::CETRON 8 lines 30-SEP-1987 15:46 -< wild rumour from my pre-doc days >- -------------------------------------------------------------------------------- this is but a rumour (brian will correct me) but I seem to recall at least one other 11 group was going to 'port' THEIR os over to the system once it started working... but I can't remember if it would run under rsx or instead of... -ed ================================================================================ Note 108.5 [RSX]J11 COPROCESSOR FOR VAX 5 of 5 EISNER::TINKELMAN "Bob Tinkelman - CCA" 28 lines 30-SEP-1987 23:26 -< "Project" for KXJ11-C RT? >- -------------------------------------------------------------------------------- < this is but a rumour (brian will correct me) but I seem to recall < at least one other 11 group was going to 'port' THEIR os over to < the system once it started working... but I can't remember if it < would run under rsx or instead of... There is, of course, the MicroPower Pascal group. They were there first - porting MPP from the KXT11-C to the KXJ11-C. However, I assume that's not what you were talking about. I had lunch one day at Nashville with a fellow from the RT group who was quite excited about a project (NOTE - not a product) to put RT on the KXJ. There were several interesting points: Their architecture would allow the 14 KXJs (the hardware imposed limit) on the Q-bus instead of 4 (the limit imposed by CPR's scheme of mapping all 256K of KXJ memory onto the Q-bus. Their plan did not involve VAXen at all. It appeared their goal was increased throughput, not migration to VMS. They were planning on supplying (oops, I guess that's developing) drivers for the on-board devices, in contrast to what Brian McCarthy had said about CPR in his Nashville session. (Why is that, Brian?) They were contracting out the work (or at least a good chunk of it) to some outside software vendor. Remember - this was a "Planned Project" and definitely NOT a "Product".  ================================================================================ Note 109.0 [PRO300]PRO Device Drivers 2 replies EISNER::RICE "Gary Rice" 1 line 23-SEP-1987 19:48 -------------------------------------------------------------------------------- This topic is for the discussion of PRO device drivers. ================================================================================ Note 109.1 [PRO300]PRO Device Drivers 1 of 2 EISNER::RICE "Gary Rice" 5 lines 23-SEP-1987 19:50 -< Is it a "File Server"? >- -------------------------------------------------------------------------------- When you do a DCL "$ SHOW DEVICES" command, one of the displayed items is the FS: device. Do you know what this device is? I can't find it documneted in any of my PRO docs. Gary ================================================================================ Note 109.2 [PRO300]PRO Device Drivers 2 of 2 EISNER::ETHINGTON "Superior Klingon Technology" 21 lines 29-SEP-1987 22:37 -< FS: and Pro/Clusters >- -------------------------------------------------------------------------------- FS0:-FS3: are used for diskless workstations in Pro/Clusters (or if you wish to avoid irritating Vax marketing Nazis who think they added the word CLUSTER to the Funk and Wagnalls, Pro/Server). The standard system image, which is used both on standalone systems and on diskless workstations, uses FS: - if you do a show device on a file server, which has a different system image, you won't see it. On standalone systems, startup processing places all FS: devices offline. If, however, you boot as a member of a cluster, FS0:-FS3: will allow you to access up to 4 disk devices on the file server. If the server has a winchester and two floppies, they will show up on every workstation in the cluster as FS0:-FS2:. Through the magic of concealed devices and cool V3 logical names, all the software is fooled into thinking they are local disk devices so nothing breaks. On standalone systems, FS: is always offline - the only penalty of using the same system image for workstations and standalone systems is standalone systems will have a few hundred words less primary pool, which on V3 systems is no problem anyway. Jerry  ================================================================================ Note 110.0 [PRO300]New Releases of Pro Software 12 replies EISNER::ETHINGTON "Superior Klingon Technology" 12 lines 29-SEP-1987 23:29 -------------------------------------------------------------------------------- P/OS V3.2, Pro/Tool Kit V3.2, and Pro/DECnet V2.1 have all been released. I actually have received SDC copies of P/OS V3.2 and Pro/DECnet V2.1 in my hot little hands; Pro/Tool Kit was back ordered, but should be here any day. I have installed P/OS and Pro/DECnet already - I think you will like some of the new features in them. Since I am leaving on a two week vacation at 8 in the morning, I don't think I'll stay up all night writing this stuff up, but when I get back I'll post more info on the new stuff - maybe Tool Kit will show up by then too. Get them checkbooks and Master Cards out, folks - it's that time again..... Jerry ================================================================================ Note 110.1 [PRO300]New Releases of Pro Software 1 of 12 EISNER::HASSINGER "Bob Hassinger" 1 line 30-SEP-1987 02:48 -< Please make entries in LATEST... too. >- -------------------------------------------------------------------------------- ================================================================================ Note 110.2 [PRO300]New Releases of Pro Software 2 of 12 EISNER::RICE "Gary Rice" 5 lines 11-OCT-1987 09:32 -------------------------------------------------------------------------------- Jeff Killeen's note in the HARDWARE conferecne referenced a "Product" called PRO TOOLKIT EMERGENCY SUB. Do you know what that is? Gary ================================================================================ Note 110.3 [PRO300]New Releases of Pro Software 3 of 12 EISNER::KILLEEN "Jeff Killeen" 4 lines 11-OCT-1987 10:16 -< WHICH NOTE >- -------------------------------------------------------------------------------- > Jeff Killeen's note in the HARDWARE conferecne referenced a WHICH NOTE? ================================================================================ Note 110.4 [PRO300]New Releases of Pro Software 4 of 12 EISNER::RICE "Gary Rice" 40 lines 12-OCT-1987 09:57 -< CAUTION: Brain Muddled >- -------------------------------------------------------------------------------- >> Jeff Killeen's note in the HARDWARE conferecne referenced a > WHICH NOTE? My mistake. The note is actually in the LATEST_RELEASE_INFO confernece as: ================================================================================ Note 58.6 FCS SCHEDULE 6 of 6 EISNER::KILLEEN "Jeff Killeen" 79 lines 10-OCT-1987 15:07 -< FY88 #12 >- -------------------------------------------------------------------------------- REMEMBER THIS IS *NOT* A GUARANTEED SCHEDULE!!! .___.___.___.___.___.___.___. ! ! ! ! ! ! ! ! | d | i | g | i | t | a | l | N e w s !___!___!___!___!___!___!___! SCHEDULED FCS DATES FY'88 #12 - 17-September-1987 FY'88 #12 SCHEDULED FCS DATES SCHEDULED PRODUCT/VERSION Q # FCS DATE SPD # --------------- --- --------- ----- . . . . *MICROPOWER/PASCAL QY029 18 SEP 87 18.24.06 U/RSX V2.4 *MICROPOWER/PASCAL-VMS V2.4 Q*029 18 SEP 87 26.24.09 *PRO/TOOL KIT EMERGENCY SUB QBA14 18 SEP 87 40.19.XX ^^^^^^^^^^^^^^^^^^^^^^^^^^^ QBE14 Sorry for the confusion. THIS is the entry I was referring to. Gary ================================================================================ Note 110.5 [PRO300]New Releases of Pro Software 5 of 12 EISNER::ETHINGTON "Superior Klingon Technology" 10 lines 15-OCT-1987 23:53 -< Emergency Sub?!?!?! >- -------------------------------------------------------------------------------- I think that "emergency sub" business is the indication that, yet again, SDC has screwed up the duplication of Tool Kit and actually shipped some bogus Tool Kit 3.2 copies. They are getting their #&%*&^#@ together and should be shipping the correct stuff about any day now. I still haven't received my 3.2 Tool Kit; guess that saves me the aggravation of getting a broke one. I have received P/OS 3.2 and PRO/DECnet V2.1; you CAN use Tool Kit 3.0 with them, so I can limp along until the new Tool Kit ships. Jerry ================================================================================ Note 110.6 [PRO300]New Releases of Pro Software 6 of 12 EISNER::ROECKEL 18 lines 18-NOV-1988 14:28 -< P/OS V3.2 up and running >- -------------------------------------------------------------------------------- I have just recently received updates to the following PRO software: P/OS HD V3.2 PRO/DECnet V2.1 PRO/Communications V3.1 PRO/ToolKit V3.2 PRO/TK F77 V5.2 Synery Window Manager V2.1 It's been up and running for about a week now, and everything seems to be just fine. Lucky for me that I screemed loud enough to get DEC to ship it all *FREE*, even though our Maintenance Contract was signed one month AFTER the announced releases. I realy enjoy the GIDIS to SIXEL converter -- now I can send my PRO 20/20 plots and PROSE PLUS drawings to the LN03+ !! Bruce ================================================================================ Note 110.7 [PRO300]New Releases of Pro Software 7 of 12 EISNER::RICE "Gary Rice" 14 lines 19-NOV-1988 14:16 -< Almost Current >- -------------------------------------------------------------------------------- > I have just recently received updates to the following PRO software: > P/OS HD V3.2 > PRO/DECnet V2.1 > PRO/Communications V3.1 > PRO/ToolKit V3.2 >>>>> PRO/TK F77 V5.2 > Synery Window Manager V2.1 Well, you almost made the "Most-Up-To-Date" list. Had you gotten PRO/TK F77 v5.3, then you would have it all. Gary ================================================================================ Note 110.8 [PRO300]New Releases of Pro Software 8 of 12 EISNER::ROECKEL 19 lines 25-NOV-1988 13:04 -< Not enough APR's ?? >- -------------------------------------------------------------------------------- > Well, you almost made the "Most-Up-To-Date" list. Had you gotten > PRO/TK F77 v5.3, then you would have it all. Interesting. I took another look at the floppy and it sure does say F77 V5.2 On another subject --- I have ran into a problem since the upgrade. When I enter the ttolkit, I get an error message when trying to install F77. It says: INS -- Not enough APR's for task image. This seems to have shown up AFTER I installed the Regis-to-GIDIS and GIDIS-to-Sixel conversion programs. What is an APR? How can I fix this problem? Thanks ! Bruce ================================================================================ Note 110.9 [PRO300]New Releases of Pro Software 9 of 12 EISNER::MAYHEW "Bill Mayhew" 30 lines 25-NOV-1988 14:03 -< Translation: Buy a VAX :-} >- -------------------------------------------------------------------------------- An APR is an Active Page Register, part of the memory management hardware. Essentially, these map your logical (hesitating to use the word "virtual") address space to physical memory. On a 350, there are 8 of them, each of which can map up to 8Kb of memory into your 64Kb address space. Ordinarily one gets this problem when one has written software that needs more than 8 distinct memory segments, for whatever reason (assuming a Pro 350, which has 8 APRs). It's a bit surprising to see it coming from a DEC product. The only explanations I can come up with are: (a) the version of F77 that you have is intended for a 380 (which is a separate-I-and-D-space machine and therefore can run larger programs, and has 8 instruction-space and 8 data-space APRs -- though I have *no* idea if any DEC software *actually* makes use of the hardware capabilities, never having owned a 380); (b) Somehow, installing one of the two conversion programs you mentioned increases the size of some shared memory region, such as a resident library, so that it takes more APRs than it used to, and more than F77 can give it. De-install the conversion programs and see what that buys you. Then you can re-install them, one at a time, till it breaks; and, further, you can watch the sizes of the regions and see which one is at fault. Not that there's likely to be a user-installable fix, you understand... ================================================================================ Note 110.10 [PRO300]New Releases of Pro Software 10 of 12 EISNER::RICE "Gary Rice" 27 lines 27-NOV-1988 11:34 -< Yes, there ARE F77 v5.2 Problems >- -------------------------------------------------------------------------------- > When I enter the ttolkit, I get an error message when trying to > install F77. It says: > INS -- Not enough APR's for task image. > This seems to have shown up AFTER I installed the Regis-to-GIDIS > and GIDIS-to-Sixel conversion programs. I haven't seen this problem, but there were some others in the v5.2 version of Fortran. If you have back issues of the Newsletters, check out the May '88 issue. The first article in the PC section details some compatibility problems with programs built from the v5.2 compiler. > (a) the version of F77 that you have is intended for a 380 (which > is a separate-I-and-D-space machine and therefore can run larger > programs, and has 8 instruction-space and 8 data-space APRs -- though > I have *no* idea if any DEC software *actually* makes use of the > hardware capabilities, never having owned a 380); Bill's assessment of the PRO 380 hardware is slightly misleading. I and D space on the PRO (ANY model) was never implemented, so you can rule out any hardware dependency as the root of your problem. There ARE some subtle differences between the 325/350 and the 380, but having both, I have found NO application, complier, product, etc. that won't work on either the F11 350 or the J11 380. Gary ================================================================================ Note 110.11 [PRO300]New Releases of Pro Software 11 of 12 EISNER::MAYHEW "Bill Mayhew" 29 lines 27-NOV-1988 18:06 -< But the book says... >- -------------------------------------------------------------------------------- > I and D > space on the PRO (ANY model) was never implemented, so you can rule > out any hardware dependency as the root of your problem. For the record... I'm perfectly prepared to believe your conclusion, but I have some difficulty with the premise {grin}. The hardware documentation I have for the 380 states that I&D space does indeed exist on the 380. (See Pro 300 Series Technical Manual, Vol. 1, EK-PC300-V1-001, p. 6-36, for one place.) I am fully prepared to believe that P/OS has never implemented I & D space, and I allowed for that possibility in my reply, but it sure looks to me like the hardware has it. Indeed, I can't think of a reason why the hardware *wouldn't* have it, since it's a J11 chip and the memory management hardware is on the chip. The answer is of a little more than idle curiosity (though not much) since it goes to the question of whether non-P/OS operating systems can run separate I&D on a 380, if they choose to. It may well have nothing to do with the original question, though. Can anyone confirm that I&D is, or is not, available on the 380 to software (including operating system software) that chooses to use it? ================================================================================ Note 110.12 [PRO300]New Releases of Pro Software 12 of 12 EISNER::ROECKEL 25 lines 19-DEC-1988 09:11 -< Place foot in mouth ... >- -------------------------------------------------------------------------------- > The only explanations I can come up with are: > > (a) the version of F77 that you have is intended for a 380 (which > is a separate-I-and-D-space machine and therefore can run larger > programs, and has 8 instruction-space and 8 data-space APRs -- though > I have *no* idea if any DEC software *actually* makes use of the > hardware capabilities, never having owned a 380); > > (b) Somehow, installing one of the two conversion programs you > mentioned increases the size of some shared memory region, such > as a resident library, so that it takes more APRs than it used to, > and more than F77 can give it. > Well, the problem ended up to be my own doing. I was stupid enough to try and ZAP the latest version of the Fortran compiler with the fixes that made the old version run at lightning speeds. Well, after I re-loaded the compiler, everything worked O.K. (Thats what I get for not thinking before acting!!) Does anyone know if the new version of the Fortran compiler can, or needs to be improved in the area of speed?  ================================================================================ Note 111.0 [RSTS]Anybody home? 8 replies EISNER::KENNEDY "Terry Kennedy" 12 lines 3-OCT-1987 05:02 -------------------------------------------------------------------------------- Hello [pause] H e l l o [echo from large, vacant area] This area has been pretty dead lately. Sometimes I think I'm talking to the wall. Surely there are other RSTS users out there. Come on in and say a word or two. You can't let the VMS gang have all the fun, can you? Seriously, I am concerned that if activity does not pick up here, we may get the plug pulled on the RSTS conferences. That would be a shame. Per- haps you know of a RSTS user who ignored the DECUServe application kit because they figured 'oh, it's all VAX stuff - nothing there for me!' Not so! Please tell them & get them interested. It is only the user's interest that keeps DEC interested in RSTS. If we 'go away', so will it! ================================================================================ Note 111.1 [RSTS]Anybody home? 1 of 8 EISNER::HORN "Larry Horn" 14 lines 3-OCT-1987 19:03 -< (echo) Hello >- -------------------------------------------------------------------------------- Maybe the VMS folks have more to complain about? (Just *kidding* -- hold the tomatoes, please!) I check all the conferences every day, so I'm keeping up with the RSTS conferences. I haven't come up with any good ideas to promote them. I wouldn't want to duplicate the efforts of WHO_AM_I, but what do you RSTS lurkers think of a site-directory topic? That way we'd at least know who's out there. Hello? LOH ================================================================================ Note 111.2 [RSTS]Anybody home? 2 of 8 EISNER::KILLEEN "Jeff Killeen" 5 lines 3-OCT-1987 21:03 -< AH PERFECTION! >- -------------------------------------------------------------------------------- The old problem - how do you improve perfection? You don't talk about it - you sit and wait for others to reach the same virtual level. ================================================================================ Note 111.3 [RSTS]Anybody home? 3 of 8 EISNER::KENNEDY "Terry Kennedy" 8 lines 3-OCT-1987 21:20 -< Good idea - let's do it! >- -------------------------------------------------------------------------------- > I wouldn't want to duplicate the efforts of WHO_AM_I, but what do > you RSTS lurkers think of a site-directory topic? That way we'd > at least know who's out there. Good idea. We could post equipment info & software used info as well, so we could assist each other on media conversions, etc. [No, Jeff, you don't have to list all 78 systems individually! :-)] I don't think this will compete with WHO_AM_I as there aren't many of us here (yet). ================================================================================ Note 111.4 [RSTS]Anybody home? 4 of 8 EISNER::HORN "Larry Horn" 19 lines 6-OCT-1987 15:02 -< site directory format >- -------------------------------------------------------------------------------- [ sorry for the delay -- I've been sick ] Ok. I'll start a topic reserved (by consensus) just for site info; before doing so, how about comments on the format? My suggestions: Title of replies: company name Body: summary of system configurations, type of applications Ending with: contacts; whether you can/will take phone calls or letters; whether you can/will do media conversions To keep the topic concise, when your entry needs updating, delete it and re-enter with the corrections rather than having updates scattered throughout the topic. Rather than have discussions going on in the site directory, carry them on in this topic (39.*), then update your site entry as appropriate. ================================================================================ Note 111.5 [RSTS]Anybody home? 5 of 8 EISNER::KENNEDY "Terry Kennedy" 2 lines 6-OCT-1987 20:31 -< Keywords? >- -------------------------------------------------------------------------------- Sounds good - perhaps we could use keywords to indicate version, layered products used, and areas of expertise? ================================================================================ Note 111.6 [RSTS]Anybody home? 6 of 8 EISNER::LEFEBVRE "Kenneth LeFebvre" 10 lines 12-OCT-1987 08:04 -< Aye! for the Directory >- -------------------------------------------------------------------------------- Hello! I am here; I have been monitoring the RSTS conferences regularly, but just haven't anything to add at the moment. I am in favor of the Site Directory topic. I'll try to think of something to say... Ken ================================================================================ Note 111.7 [RSTS]Anybody home? 7 of 8 EISNER::HORN "Larry Horn" 5 lines 12-OCT-1987 22:29 -< any traffic welcome >- -------------------------------------------------------------------------------- Hi, Ken -- I was hoping you were still out there. I'll wait a few more days for any further comments and then start the topic. ================================================================================ Note 111.8 [RSTS]Anybody home? 8 of 8 EISNER::CONROY "Alan Conroy" 11 lines 9-AUG-1988 15:24 -< My $0.02 >- -------------------------------------------------------------------------------- I'm pretty new to DECUServe and have only just now gotten around to looking at the RSTS/E conference. Sorry, but since we have more VAXen in use than PDP-11s, I felt obligated to go through the entire VMS conference before coming here, but my heart has always belonged to RSTS! I think that there is something to be said about the compartive robustness of RSTS/E as compared to VMS. A lot of VMS topics seemed related to PROBLEMS with VMS. Now, RSTS/E isn't perfect, but as a system manager of both O/S, I think RSTS/E is less troublesome. That may very well be part of the reason for so little action in this conference. RSTS FOREVER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ================================================================================ Note 112.0 [RSX]Using VIRTUAL Arrays 1 reply EISNER::RICE "Gary Rice" 18 lines 7-OCT-1987 13:26 -------------------------------------------------------------------------------- I wrote a test program that creates and manipulates a VIRTUAL ARRAY in FORTRAN. The array is 16K words in size. From a simple program it works fine. After getting it working as a subroutine, I linked it into a large (overlaid) program. The link was successful, but upon running the resulting program, I got a message indicating Virtual array initialization failure. The diagnostic in the manual suggested insufficient mapping pointers as the problem. This is consistent with the link which includes a cluster of 3 libraries plus inclusion of 1 resident library that is not clustered. Total APRs prior to the inclusion of the virtual array code was 4. Question: Is there anything I can do to get this new virtual array code to function in the overlaid program, or must I throw it out and go to a disk file to hold the data? Gary ================================================================================ Note 112.1 [RSX]Using VIRTUAL Arrays 1 of 1 EISNER::MCCARTHY 5 lines 14-OCT-1987 22:50 -------------------------------------------------------------------------------- Linking the task I/D may give you more space, space, if the application is amenabsdaenable to that environment. -Brian  ================================================================================ Note 113.0 [RSX]Problem with Priveledged Task 21 replies EISNER::MCGLINCHEY "Cape Malleum Majorem" 11 lines 7-OCT-1987 22:30 -------------------------------------------------------------------------------- Help. I got a problem reading a file. I've got a priveleged UIC and a preveledged task that writes logical blocks into the Index File in order to undelete a file that I've inadvertently deleted. But I still can't open the Index File. Is it because of my Priviledged UIC or do I need to use another UIC to get at the Index FILE? Any suggestions will be appreciated. -Glinch. ================================================================================ Note 113.1 [RSX]Problem with Priveledged Task 1 of 21 EISNER::HASSINGER "Bob Hassinger" 5 lines 8-OCT-1987 00:45 -< A classic problem? >- -------------------------------------------------------------------------------- Please pardon a possibly dumb comment. This sounds a little like something I have heard before - it may be a classic problem. Something like something else has the file open already (like the file system?)? Bob H ================================================================================ Note 113.2 [RSX]Problem with Priveledged Task 2 of 21 EISNER::NORTON 1 line 8-OCT-1987 09:53 -< Dumb answer >- -------------------------------------------------------------------------------- Isn't this what the MOU /UNL command is for? ================================================================================ Note 113.3 [RSX]Problem with Priveledged Task 3 of 21 EISNER::MCCARTHY 28 lines 14-OCT-1987 22:55 -< Arrrrrgggghhh!!! >- -------------------------------------------------------------------------------- Priveledged task? Slowly I turned, inch by inch, step by step ...  Alright, let's get this straight, once and for all. There is one user error I simply will not tolerate. Priviledge is not a word. Privelege is not a word. Privledge is not a word. Privlege is not a word. Privilige is not a word. The word is: **** **** ***** * * ***** * ***** *** ***** * * * * * * * * * * * * **** **** * * * * * **** * ** **** * * * * * * * * * * * * * * * ***** * ***** ***** ***** *** ***** Thank you for your support. ================================================================================ Note 113.4 [RSX]Problem with Priveledged Task 4 of 21 EISNER::KILLEEN "Jeff Killeen" 38 lines 14-OCT-1987 23:47 -< TIME >- -------------------------------------------------------------------------------- People wonder why it takes so long for development - or why there is no time to develop VMS Backup for RSX  !< Note 36.3 by EISNER::MCCARTHY > ! -< Arrrrrgggghhh!!! >- ! ! ! !Priveledged task? Slowly I turned, inch by inch, step by step ... ! ! ! ! !Alright, let's get this straight, once and for all. There is one user !error I simply will not tolerate. ! ! Priviledge is not a word. ! Privelege is not a word. ! Privledge is not a word. ! Privlege is not a word. ! Privilige is not a word. ! !The word is: ! ! **** **** ***** * * ***** * ***** *** ***** ! * * * * * * * * * * * * ! **** **** * * * * * **** * ** **** ! * * * * * * * * * * * * ! * * * ***** * ***** ***** ***** *** ***** ! ! !Thank you for your support. ! ! The developers are off drawing on their VDT's 8-) ================================================================================ Note 113.5 [RSX]Problem with Priveledged Task 5 of 21 EISNER::FRISBIE "Alan E. Frisbie" 9 lines 15-OCT-1987 20:55 -< Purity... >- -------------------------------------------------------------------------------- >> The developers are off drawing on their VDT's 8-) The Committee for Purity in Spelling thinks that that is a cheap shot. :-) We support Brian 100%. Now if we could just do something about kernel... Alan (and others) ================================================================================ Note 113.6 [RSX]Problem with Priveledged Task 6 of 21 EISNER::MCGLINCHEY "SANCHO! My armor! My TECO Macros" 8 lines 18-OCT-1987 10:30 -< Ta-Dum. >- -------------------------------------------------------------------------------- re: Brian's reply - I hereby volunteer to be the RSX SIG's designated straight man. -Glinch ================================================================================ Note 113.7 [RSX]Problem with Priveledged Task 7 of 21 EISNER::KILLEEN "Jeff Killeen" 5 lines 18-OCT-1987 11:30 -< OH LUCKY YOU >- -------------------------------------------------------------------------------- > I hereby volunteer to be the RSX SIG's designated > straight man. I am sure you will find being B.M.'s straight man a "priviileeedggee" ================================================================================ Note 113.8 [RSX]Problem with Priveledged Task 8 of 21 EISNER::MCCARTHY 7 lines 16-NOV-1987 19:31 -------------------------------------------------------------------------------- By the way, find a Franklin spelling ACE and ask it to correct "privlege". -Brian ================================================================================ Note 113.9 [RSX]Problem with Priveledged Task 9 of 21 EISNER::MAXWELL "Gary Maxwell" 12 lines 18-NOV-1987 02:53 -< It's certainly been a privaledge... >- -------------------------------------------------------------------------------- Please let us all have the humility to accept partial blame for what our industry has done to the English (or is that American?) language. Everything from an "interrupt" (it's a verb, not a noun) to a disk/disc/disque(?) drive. Look at our acronyms! I refuse to accept a paper unless all acronyms are spelled out at least once. I guess as the technology rushes forward, our ability to communicate dissipates without vigilence (or is that vigilance?) Take me to SOAPBOX! ;-} ================================================================================ Note 113.10 [RSX]Problem with Priveledged Task 10 of 21 EISNER::MCCARTHY 22 lines 19-NOV-1987 18:29 -< Notes will save us from our Schooling >- -------------------------------------------------------------------------------- There's hope for the industry, and the technology you're using is it. For the past twenty years, computer geeks have spent their time interacting with machines, and when they weren't allowed to do that, they stood around and talked to other computer geeks about interacting with machines. Nobody ever got to see them write stuff down. With the new technology of notes, they're suckered in by the fact that now they can interact with machines about interacting with machines, and not ever have to face other humans at all. Of course, this requires the use of written English, airing one's illiteracy in front of God and country (and DECspell). So, if we subtly (I looked up the spelling in My English Language User's Guide, the most frequently referenced manual in my doc set) remind each other of our misteaks we will overall improve the ability of the species to communicate. -Brian ================================================================================ Note 113.11 [RSX]Problem with Priveledged Task 11 of 21 EISNER::CETRON 10 lines 19-NOV-1987 20:12 -< munch munch munch >- -------------------------------------------------------------------------------- from brian mccarthy: remind each other of our misteaks we will overall improve the ^^^^^^ just like brian, always thinking of food..... :-) -ed ================================================================================ Note 113.12 [RSX]Problem with Priveledged Task 12 of 21 EISNER::MCCARTHY 11 lines 27-NOV-1987 18:26 -------------------------------------------------------------------------------- > remind each other of our misteaks we will overall improve the ^^^^^^ That was a joke, son, a joke. Kind of intentional, ya know? just like brian, always thinking of food..... :-) Well, Ed, as I pointed out in WHOAREYOU, at least I am prepared to DO something about it, not just talk like some people I know.:-) -Brian ================================================================================ Note 113.13 [RSX]Problem with Priveledged Task 13 of 21 EISNER::DEGUMBIA 3 lines 3-DEC-1987 12:57 -< Yes, but >- -------------------------------------------------------------------------------- I really enjoyed reading all the replies (replys) to this note, but I am rather interested in a solution to the problem, if there is one (a solution, that is). ================================================================================ Note 113.14 [RSX]Problem with Priveledged Task 14 of 21 EISNER::RICE "Gary Rice" 12 lines 4-DEC-1987 11:34 -< Try Mount/Foreign >- -------------------------------------------------------------------------------- > Help. I got a problem reading a file. I've got a > priveleged UIC and a preveledged task that writes > logical blocks into the Index File in order to > undelete a file that I've inadvertently deleted. The only way I know of to do this is mount the disk foreign (sorry to you M users, this is an M+ ONLY feature). Then manipulate the info to your heart's desire. CAUTION: without FILES-11 there to help, you HAVE to know what you are doing or you will destroy the disk entriely. Gary ================================================================================ Note 113.15 [RSX]Problem with Priveledged Task 15 of 21 EISNER::COVERT "John Covert" 10 lines 8-DEC-1987 15:44 -------------------------------------------------------------------------------- The correct answer (MOUNT /UNL) for allowing access to the index file has already appeared in reply .2. re Mount Foreign Although it's true that Mount Foreign is an M-Plus only feature, 11M users can take heart: the default condition (prior to mounting at all) on 11M is equivalent to Mount Foreign on M-Plus. /john ================================================================================ Note 113.16 [RSX]Problem with Priveledged Task 16 of 21 EISNER::FRISBIE "Alan E. Frisbie" 7 lines 13-DEC-1987 01:18 -< Mount/Foreign in 11M >- -------------------------------------------------------------------------------- >> Although it's true that Mount Foreign is an M-Plus only >> feature Wrong, 8-wheeled mutant, MOUNT/FOREIGN is in RSX-11M. It just doesn't do anything. Alan ================================================================================ Note 113.17 [RSX]Problem with Priveledged Task 17 of 21 EISNER::COVERT "John Covert" 8 lines 13-DEC-1987 22:52 -< Skating in circles >- -------------------------------------------------------------------------------- >MOUNT/FOREIGN is in RSX-11M. >It just doesn't do anything. OK, right. But lest we confuse the readership: It doesn't do anything because it doesn't have to. On 11M, a disk is in the same condition both before and after a MOUNT/FOREIGN as it would be on M-Plus after a MOUNT/FOREIGN. /john ================================================================================ Note 113.18 [RSX]Problem with Priveledged Task 18 of 21 EISNER::FRISBIE "Alan E. Frisbie" 9 lines 14-DEC-1987 17:38 -< Explaining references >- -------------------------------------------------------------------------------- >> -< Skating in circles >- >> But lest we confuse the readership For the benefit if those that didn't see John's performance at the Fall Symposium, the 8-wheeled mutant reference was to his strange roller skates: in-line wheels (like the blade on ice skates). Alan ================================================================================ Note 113.19 [RSX]Problem with Priveledged Task 19 of 21 EISNER::DELARISCH "Arnold S. De Larisch" 14 lines 14-DEC-1987 20:41 -< Not OCTAL ... 6 wheeled (I think!)! >- -------------------------------------------------------------------------------- >> < Note 36.18 by EISNER::FRISBIE "Alan E. Frisbie" > -< Explaining references >- >> >> -< Skating in circles >- >> But lest we confuse the readership >> For the benefit if those that didn't see John's performance >> at the Fall Symposium, the 8-wheeled mutant reference was >> to his strange roller skates: in-line wheels (like the >> blade on ice skates). But Alan, I thought he was a 6-wheeled mutant ... not OCTAL wheel muntant! 8-{) -Arnold ================================================================================ Note 113.20 [RSX]Problem with Priveledged Task 20 of 21 EISNER::COVERT "John Covert" 4 lines 15-DEC-1987 00:49 -------------------------------------------------------------------------------- Arnold, after building the 16-beer stack, you counted wrong. My Rollerblades are four wheels each. /john ================================================================================ Note 113.21 [RSX]Problem with Priveledged Task 21 of 21 EISNER::BOSTWICK 12 lines 15-DEC-1987 20:06 -< The REST of the story >- -------------------------------------------------------------------------------- >> Arnold, after building the 16-beer stack, you counted wrong. >> My Rollerblades are four wheels each. Questions of counting and radix aside, the sight of an n-wheeled nebish in a three-piece suit careening down the aisle at VAX Magic carrying a stuffed White Elephant nearly as big as he is... Well that was just something to see! { The elephant was RSX' birthday present to VMS }  ================================================================================ Note 114.0 [RSX]Dynamic device database building 4 replies EISNER::NORTON 15 lines 8-OCT-1987 10:22 -------------------------------------------------------------------------------- As a VAR that installs Micro/11's with M-Plus, I would like to know why we are denied the flexibility of Micro/RSX's autoconfigure setup. I really *hate* having to do a custom SYSGEN just because a customer has three DHV's instead of one, or two disk controllers. The ability to perform device table building at startup would let me generate ONE system per M+ update (no, I don't want Micro/RSX). Is this a big strategic thing with DEC so that they're hogging it for themselves, or would it cause too many support headaches, or what? We (DECUS membership) have already figured out how to get loadable XDT and loadable crash drivers into our M+ systems so why not let us have the rest of the flexibility enhancements? ================================================================================ Note 114.1 [RSX]Dynamic device database building 1 of 4 EISNER::MCCARTHY 16 lines 14-OCT-1987 23:00 -------------------------------------------------------------------------------- Autoconfigure for the general M+ case is a major pain in the butt. You have to worry about exec support for the big disk drivers, the strange and wonderful device data structures for massbus devices, and a host of other complexities we didn't care to tackle. I do like your attitude, however. Why do you do SYSGENs in the first place? What precludes you from using a pregenned system? Oh, and by the way, for a really good exercise to see why we don't want to do this, look up what the data structures for 4 TU77s on 2 TM03s and an RP06 all on the same RH70 looks like. -Brian ================================================================================ Note 114.2 [RSX]Dynamic device database building 2 of 4 EISNER::NORTON 13 lines 15-OCT-1987 10:14 -< How about this way? >- -------------------------------------------------------------------------------- Well, how about using the same limitations that the Micro/RSX autoconfigure has, namely only MSCP disks and tapes and DH*, and DZ* terminals, plus DEQNA/DELQA? Everything we've sold in the last three years or so has been "modern" with only the odd RL02 thrown in for a removable device. However, systems have often included mixes of RDxx/RC25 in varying quantities of each drive type, as well as varying numbers of DH/DZ terminals. It seems like if it were included in the M+ kit with no support like loadable XDT, we could figure out how to use it at our own risk. ================================================================================ Note 114.3 [RSX]Dynamic device database building 3 of 4 EISNER::FRISBIE "Alan E. Frisbie" 8 lines 15-OCT-1987 20:59 -< Lotsa crud on his '11 >- -------------------------------------------------------------------------------- >> Oh, and by the way, for a really good exercise to see why we don't >> want to do this, look up what the data structures for 4 TU77s on >> 2 TM03s and an RP06 all on the same RH70 looks like. And if you want something really gross and disgusting, look at the performance. :-) Alan ================================================================================ Note 114.4 [RSX]Dynamic device database building 4 of 4 EISNER::BOSTWICK 26 lines 14-DEC-1987 18:06 -< Poor Man's Autoconfigure >- -------------------------------------------------------------------------------- > Well, how about using the same limitations that the Micro/RSX > autoconfigure has, namely only MSCP disks and tapes and DH*, and > DZ* terminals, plus DEQNA/DELQA? We already do something of the kind. We gen up a system with everything we ever use and then some (like 3-DH, 2-DZ, 2-DLV1J, and so on). Wastes a bit of pool for unused data structures, but not so much as to be painful. What about 'standard' CSR and VECTOR, you ask? Simple. We use CON to shuffle CSR and VEC assignments around to match the hardware. That way, if anyone ever DOES run Autoconfig, it will work. We build other drivers (DL, MT, etc.) loadable with loadable database - see old MultiTasker article for how. The only pool truly wasted is for TTDRV and DU. By the way, there are special CSR (160000 I think) and VEC (0) settings that tell CON the things aren't really there. About the only drawback is the number of offline TT units that come up on the DEV TT list. Otherwise, we do a single gen for about 15 11/73s - most with differing serial port configurations. jim  ================================================================================ Note 115.0 [RSX]Modem problem 6 replies EISNER::KASPER "Beverly T. Kasper" 17 lines 20-OCT-1987 10:55 -------------------------------------------------------------------------------- We have an M+ 2.1 system on which we're trying to set up a modem for dial-in use. It's set up as REMOTE, SPEED=1200, NOABAUD. It works about 1 out of 6 tries. The others vary -- sometimes it won't answer; sometimes it connects, issues garbage for a second or 2, then drops carrier; sometimes it appears to connect, but doesn't respond. I saw a similar problem on an 11/70 -- after reboot, it would connect once, then it was unusable (connect but no response) until the next boot. We solved that one by forcing DTR high, and setting it NOREMOTE. When we upgraded to an 11/84 running 3.0 we tried again, but had the same problem. In both cases, we've checked the modem out on other systems and other ports. It appears to be an RSX problem, but (of course) Colorado insists we must be imagining it or doing Something Wrong. Has anyone else run into this? While it doesn't crash the system or anything, the solution is inelegant as well as a potential security hole. ================================================================================ Note 115.1 [RSX]Modem problem 1 of 6 EISNER::KASPER "Beverly T. Kasper" 8 lines 20-OCT-1987 12:13 -< More detail >- -------------------------------------------------------------------------------- Forcing DTR didn't work on the 2.1 system - it still worked sometimes, not others. The only reliable configuration seems to be a Hayes modem at 300 baud. Not optimal. Help? ================================================================================ Note 115.2 [RSX]Modem problem 2 of 6 EISNER::KENNEDY "Terry Kennedy" 10 lines 20-OCT-1987 18:04 -< Some ideas >- -------------------------------------------------------------------------------- What type of terminal interface are you using (DH, DZ, etc.)? Also, dou you have a genuine DEC modem and cable around? You may be able to 'borrow' one from another systems remote diagnosis port. Then hook it up - DEC modem, DEC cable, DEC computer. If it doesn't work, call software support - after all, it's in the SPD. One other thing - are you using a 'real' modem or a smart-modem type unit? Many of the Hayes-alike units don't support the full signal set that DEC systems require. ================================================================================ Note 115.3 [RSX]Modem problem 3 of 6 EISNER::KASPER "Beverly T. Kasper" 6 lines 20-OCT-1987 21:04 -< Thanks, I'll look into it >- -------------------------------------------------------------------------------- The ports are DZ's on both systems. I may be able to track down a DEC modem and cable (I'm at home now); I'll check, also, exactly what types of modems we're using. I'm pretty sure the signalling is okay, though. We have a very knowledgable hardware person here, who spent many hours with a breakout box trying to track it down. ================================================================================ Note 115.4 [RSX]Modem problem 4 of 6 EISNER::BOSTWICK 16 lines 14-DEC-1987 18:14 -< Me, too >- -------------------------------------------------------------------------------- I am currently fighting V2.1 with a DH and a Vadic 3451PA modem. It appears that if the line drops before user logs off, the logout message occasionally gets to the modem's autodial dialog! This can have truly wierd and wonderful results - like a perpetual huh-what loop between the modem and MCR. Also, we see occasionally the problem you describe, wherein everything is hunky-dory, but the computer refuses to talk to the next caller - modem answers OK, MCR doesn't. Sometimes we see the port left SLAVE, sometimes not. I've been praying for the V4 kit to arrive in the hopes that all this would just go away... jim ================================================================================ Note 115.5 [RSX]Modem problem 5 of 6 EISNER::FRIEDBERG 26 lines 25-APR-1988 04:52 -< various fun items with modems >- -------------------------------------------------------------------------------- RE: Various and sundry problems with MODEMs on RSX: I won't bore you with all the time I've wasted on various runarounds on this. Part of the problem is that DEC is changing their standards; part is a lack of comprehension by DEC on how ingenious users can be in using their computers. Be ware of the TC.DLU function. THis is very helpful for DIALOUT, but watch it on dial in. Watch the REMOTE answer speed, which is different than the normal default. Make sure, if you disable autobaud, that you use the MCR command to set the remote answer speed, something like MCR SET /REMOTE=TTnn:2400 or whatever (don;'t ask, I'm miles from any known RSX system). If anyone has tried to use a dial out modem, you have probably discovered that something funny happens when the remote system answers. This is because the CARRIER line comes up high, and wonderful RSX decides, that since the CARRIER line just came up, that an incoming phone call (!) was just answered, and it RESETS all those wonderful terminal attributes to the default. I have a patch which works on 2.1, 3.0, and 4.0, which checks the value of TC.DLU; if it is two (the value for dialout), then this reset logic is bypassed, and the CARRIER state transition is ignored. That makes maintaining the state of TC.DLU critical. Anyone who wants my patch (it is about 3 lines) can call me at 212 233 5470 and I will get it out to you. (NOT SUPPORTED!!!!!). ================================================================================ Note 115.6 [RSX]Modem problem 6 of 6 EISNER::MAYHEW "Bill Mayhew" 18 lines 25-APR-1988 10:45 -< dialin/dialout on RSX >- -------------------------------------------------------------------------------- Actually, we just finished setting up a dialin/dialout modem on an RSX system with not all that much trouble. This was on a MicroRSX V3.1 system, using a DF224 on a DZQ (or perhaps a DZV). We wanted to leave the line set to autobaud on incoming calls. The dial-out business is _all_ done through Kermit-11 via a KERMIT.INI file. Installed under A-to-Z, we have set up a simple A-to_Z menu that allows the user to choose which (known) system they want to dial to, and Kermit takes over and makes the connection. The only real problem we had was getting the line set back to non-dialout, autobaud mode, once the Kermit session was finished. We wrote a short little MACRO program to do that, and if I remember right it had to be linked with privileges (/PR:0). If anybody wants to see how this was done I could post the few lines of Kermit commands required to do the dirty work and the Macro source for the other thing (I think it was around 10 lines long). -Bill  ================================================================================ Note 116.0 [RSTS]Site Directory 7 replies EISNER::HORN "Larry Horn" 19 lines 28-OCT-1987 08:22 -------------------------------------------------------------------------------- This topic is reserved as a site directory. SUGGESTIONS: To keep the topic concise, please limit yourself to one entry. If you need to update your information, delete the old note and replace it with a new one. Rather than have discussions going on about the directory here, carry them on in 39.*, then update your site entry as appropriate. Use your company name as the title of the reply. Give a summary of your system(s) and type of applications. Specify whether you can/will take phone calls or letters, whether you can/will do media conversions, etc. [ Now, I'm going offline to figure out what I will put here :-) ] ================================================================================ Note 116.1 [RSTS]Site Directory 1 of 7 EISNER::KASPER "Beverly T. Kasper" 5 lines 28-OCT-1987 11:46 -< A caveat >- -------------------------------------------------------------------------------- Please be aware that some companies consider such information as how many of which computers they have doing what to be proprietary. I'd expect less of this in RSTS-land than in VMS-land, but you might want to keep it in mind . . . ================================================================================ Note 116.2 [RSTS]Site Directory 2 of 7 EISNER::KILLEEN "Jeff Killeen" 27 lines 28-OCT-1987 12:33 -< JEFF KILLEEN >- -------------------------------------------------------------------------------- Jeff Killeen Information Design & Management, Inc. 31 Hopedale St. Hopedale, Ma. 01747 (617) 478-8098 We support 79 RSTS systems and 2 VMS systems CPU's include 11/23, 11/53, 11/73A, 11/73B, 11/83, 11/34, 11/44, 11/84, 11/60, 11/70 DISK's include RD51, RD52, RD53, RD54, RD31, RX33, RX50, RA80, RA81, RA60, RK07, RM02, CDC-9448-96, CDC-9710-80, CDC-9715-160, CDC-9715-340, CDC-9715-500, FUJI-EAGLES-451MB, MAXTOR-160MB TAPE's include TU10-7 track, TU10-9 track, TS11, TU78, TU80, TK25, TK50, TSV05, CDC-TK25, CDC-92181, CDC-92185, CIPHER-910, CIPHER-990, CIPHER-880 CONTROLLER's include SPECTRA-25, SC03, SC02, UC02, TC02, TC05 ================================================================================ Note 116.3 [RSTS]Site Directory 3 of 7 EISNER::LEFEBVRE "Kenneth LeFebvre" 27 lines 28-OCT-1987 17:56 -< Sytek, Inc. >- -------------------------------------------------------------------------------- Kenneth LeFebvre Sytek, Inc. 19 Church Street Berea, Ohio 44017 (216) 243-1613 We have one in-house RSTS/E V9 system running on a Micro/PDP-11/73. The system disk is an RD53. Other devices on the system include: RD54 DHV11 TQK50 RQC25 RX50 RLV11 The system shares an RX33 with an RT-based 11/53. We run all of our internal computing on this system. Because we are a software house catering mainly to VMS and RT customers, we only support two customers with RSTS. One has Micro-RSTS V1.0 and the other has RSTS V8.0. We have been using RSTS since approximately V7.0 (at least that is as far back as I go with RSTS). ================================================================================ Note 116.4 [RSTS]Site Directory 4 of 7 EISNER::KENNEDY "Terry Kennedy" 31 lines 28-OCT-1987 18:38 -< St. Peter's College >- -------------------------------------------------------------------------------- Terry Kennedy Saint Peter's College Dep't of Computer Science 2641 Kennedy Blvd. Jersey City, N.J. 07306 (201) 435-0252 [this may change soon] We operate 5 PDP-11's, all running RSTS/E V9. The systems are 2 11/44's, an 11/83, an 11/23+ (micro-11), and a N1100 (Brand X '73 upgrade for a '24). The systems are mainly used for teaching Computer Science, and for running lab simulations & analysis. All are DECnetted together, along with a VAX 780 and a VAX 730, via Ethernet. We can read/write RX01, RX02, RX33, RX50, 800/1600/6250 magtape, RL02, RK07, and RA60 media for interchange. We can also accept Kermit or Xmodem data and put it on any of these formats, or the reverse. Feel free to contact me if you need such conversion. We have BP2, F77, Fortran 4, C81, COBOL 4.4, MAIL and DECNET/E from DEC, Oregon Pascal from Oregon Software, C, APL, LISP and FOCAL from DECUS, so we can probably compile most anything for you if you have the source only and not an executable (a common problem on DECUS Library tapes). Again, call. We have been running RSTS since V7.0, and have complete bootable kits going back to V7.2, which allows us to do installs requiring discontinued software for installation. You can also call to ask general questions about RSTS if you are stuck. One of the systems is up 24 hours, 7 days, dedicated to RSTS information exchange. See the topic 'Newsletter system' for more information. ================================================================================ Note 116.5 [RSTS]Site Directory 5 of 7 EISNER::HORN "Larry Horn" 29 lines 29-OCT-1987 22:36 -< Millsaps College, Jackson, MS >- -------------------------------------------------------------------------------- Larry Horn Millsaps College Computer Services 1701 North State Jackson, MS 39202 (601) 354-5201 [-5202 evenings] PDP-11/70, RSTS/E V9, Administrative use 2 - RM80 1 - RA81 1 - TE16 1 - TK50 PDP-11/84, RSTS/E V9, Academic use 1 - RA60 1 - TU10 1 - TK50 Software Most applications written in-house using Basic-Plus-II and Datatrieve. Our software variety is mostly on the VAXen. Other VAX-11/750 (VMS V4), uVAX II (PC-ALL-IN-1), uV2000 (VMS V4) Micom Micro 600/2 Port Selector All this (except Micom) on Ether/DECnet, including 2 optical fiber links. ================================================================================ Note 116.6 [RSTS]Site Directory 6 of 7 EISNER::CONROY "Alan Conroy" 46 lines 9-AUG-1988 15:19 -------------------------------------------------------------------------------- Hi, Alan Conroy here from sunny Seattle. (Well it was sunny yesterday...) 1 PDP-11/73: 2 Mb memory 1 TK50 1 CDC 1600 bpi tape drive (don't recall the model numebr) 1 CDC EMDI disk 2 CDC Lark drives (yuk!) 48 DH/DZ style lines 1 PDP-11/44: 2 Mb memory 1 Cipher 910X tape drive 1 RA81 1 RL02 32 DH-flavor lines 2 PDP-11/70s: 2 Mb memory each 1 TE16 each (sigh) 2 RM05 2 RA81 2 RM03 1 RL02 88 DH/DZ-style lines We also have a slew of 11/23+, 11/24s, etc which are sitting in storage until we decide what to do with them (along with scads of DZs). I hope to take one home some day (I always wanted a RSTS/E machine at home). The 1173 is for development, the other are timesharing. All have RSTS/E V9.5, BASIC-Plus-2 V2.5, DMGNET, DECUS C and APL, some public domain version of Forth. We're licensed for a whole bunch of other stuff (like Dec-word), which we don't use anymore. My phone: 206-822-3140 (work) 206-281-8386 (home) Address: Timeline Inc. 3055 112th Ave NE Suite 106 Bellevue, WA 98004 (home) 111 Florentia St. Seattle, WA 98109 Did I forget anything? ================================================================================ Note 116.7 [RSTS]Site Directory 7 of 7 EISNER::BYRNE_C "Charlie Byrne" 4 lines 9-AUG-1988 16:46 -< Welcome >- -------------------------------------------------------------------------------- Did you forget anything? I don't think so, except that you may want to also put the personal information in WHO_AM_I, if not there already.  ================================================================================ Note 117.0 [RSX]RSX LSE? 2 replies EISNER::RICE "Gary Rice" 11 lines 30-OCT-1987 14:58 -------------------------------------------------------------------------------- We have a requirement for writing APT programs (Automated Program Tool) and would like to do editing & syntax checking on a 11/73 (m+ I think). The user has requested that an interpretive type of program be developed but the description of the requirements could indicate the use of an LSE (Language Sensitive Editor) type of product could work. Is there an LSE style product available anywhere? Gary ================================================================================ Note 117.1 [RSX]RSX LSE? 1 of 2 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 6 lines 30-OCT-1987 19:36 -< Well, sort of... >- -------------------------------------------------------------------------------- We've done something like that in the past by editing the APT sources so that only the parsing section was retained and no output file was generated. We would then batch the input file through APT to perform the syntax checking. I don't know of anything that would do the syntax checking on the fly, which is what I assume you really want. ================================================================================ Note 117.2 [RSX]RSX LSE? 2 of 2 EISNER::MAXWELL "Gary Maxwell" 2 lines 18-NOV-1987 02:59 -< A long time ago... >- -------------------------------------------------------------------------------- I did some work on a reconfigurable LSE for grad school. It's not as easy as it looks, as I quickly found out.  ================================================================================ Note 118.0 [PRO300]Non_standard (non_DEC) disk drive 7 replies EISNER::RICE "Gary Rice" 19 lines 3-NOV-1987 10:01 -------------------------------------------------------------------------------- I received a letter from a user who told me about his experiences with a "non-standard" disk. He purchased a CMI 6640 (40 mb) disk from the pages of the Computer Shopper, installed it (P/OS v2) and it loaded! I checked the Computer Shopper and found only used drives, but the price was right: $250. My user asks a question regarding his controller: "My controller card has the following ROMs on it: R1:014B2 R2:013B2 R3:021B2. From Tom Hintz's submission in the July '87 newsletter, I couldn't figure out what Rev level it was since R3 with 021B2 was not listed. Do you know what Rev level my controller is?" I don't know although I suspect that he is at Rev H1. Do YOU know? Gary ================================================================================ Note 118.1 [PRO300]Non_standard (non_DEC) disk drive 1 of 7 EISNER::BAISLEY "Wayne E. Baisley" 12 lines 21-JUN-1988 13:35 -< A hack for a bigger pack ? >- -------------------------------------------------------------------------------- > I received a letter from a user who told me about his experiences > with a "non-standard" disk. He purchased a CMI 6640 (40 mb) disk > from the pages of the Computer Shopper, installed it (P/OS v2) > and it loaded! I checked the Computer Shopper and found only used > drives, but the price was right: $250. A question, since I'm looking into replacing my RD51 with something bigger, faster and cheaper (than DEC's offerings, anyway): Has anybody figured out how to brainwash V2.0/V2.0A to use geometries other than RD50/51/52's ? It doesn't need to be anything fancy like autosizing. A simple ZAP with the right numbers would do. ================================================================================ Note 118.2 [PRO300]Non_standard (non_DEC) disk drive 2 of 7 EISNER::BAISLEY "Wayne E. Baisley" 12 lines 22-JUN-1988 08:14 -< It may be Rev. C0, and another variation >- -------------------------------------------------------------------------------- > "My controller card has the following ROMs on it: > R1:014B2 R2:013B2 R3:021B2. From Tom Hintz's submission > in the July '87 newsletter, I couldn't figure out what > Rev level it was since R3 with 021B2 was not listed. > Do you know what Rev level my controller is?" I have two controllers, one about 2 years old, the other ancient. The ancient board has the same ROMs listed above and is etched as Rev. C. The newer board has: R1:014B2 R2:013B2 R3:063B2 and a sticker with "414 H1" which I take to mean Rev. H1. I haven't tried anything larger than an RD51 yet with either, but I hope to soon. ================================================================================ Note 118.3 [PRO300]Non_standard (non_DEC) disk drive 3 of 7 EISNER::RICE "Gary Rice" 7 lines 22-JUN-1988 10:39 -------------------------------------------------------------------------------- > The newer board has: R1:014B2 R2:013B2 R3:063B2 and a sticker with > "414 H1" which I take to mean Rev. H1. I haven't tried anything larger > than an RD51 yet with either, but I hope to soon. The "H1" board will handle the ST225 (20 mb) and probably the RD52 (33 mb) as well as the CMI drive. The other board is limited to the RD51 and RD50 (10 and 5 mb respectively). ================================================================================ Note 118.4 [PRO300]Non_standard (non_DEC) disk drive 4 of 7 EISNER::MAYHEW "Bill Mayhew" 11 lines 22-JUN-1988 10:41 -< There's a solution out there in the fog, somewhere >- -------------------------------------------------------------------------------- There _is_ a third-party company out there which has the patches required to V2.something (0 or 0A) to support the RD31/ST225 geometry and possibly others. Unfortunately I don't remember who they are. I think they're located in upstate New York, and they charge something like $25-50 for the thing, or include it if you buy the drive etc. from them. They advertise in a Rainbow-related publication that's put out by NewLine Software of Tiverton RI from time to time. If I come across my copy of the last issue (probably 3 months ago?) I'll post their name and number... ================================================================================ Note 118.5 [PRO300]Non_standard (non_DEC) disk drive 5 of 7 EISNER::RICE "Gary Rice" 11 lines 22-JUN-1988 10:42 -------------------------------------------------------------------------------- > Has anybody figured out how to brainwash V2.0/V2.0A to use geometries > other than RD50/51/52's ? It doesn't need to be anything fancy > like autosizing. A simple ZAP with the right numbers would do. In a word: "yes". For P/OS v2.0 (ONLY! not 2.0a) refer to the June '87 issue of the Newsletters (PC SIG) for a ZAP to P/OS v2 that allows an ST225 (20 mb) drive to be used at full capacity. Gary Rice PC SIG Newsletter Editor ================================================================================ Note 118.6 [PRO300]Non_standard (non_DEC) disk drive 6 of 7 EISNER::ROECKEL 17 lines 27-JUN-1988 14:03 -< Heres one from California >- -------------------------------------------------------------------------------- >> There _is_ a third-party company out there which has the patches >> required to V2.something (0 or 0A) to support the RD31/ST225 geometry >> and possibly others. Unfortunately I don't remember who they are. I purchased an ST225 (20 Meg) drive from an outfit out of California. They also advertised PATCHES for version 2 of P/OS, although I did not need it (I am running V3.1) The company is: PRONTO SYSTEMS 1238 JOSEPHONE ST. BERKELEY CA 34703 Sorry, I have lost the phone number. Bruce ================================================================================ Note 118.7 [PRO300]Non_standard (non_DEC) disk drive 7 of 7 EISNER::RICE "Gary Rice" 22 lines 1-JUL-1988 13:51 -< Address Correction Requested >- -------------------------------------------------------------------------------- > The company is: > PRONTO SYSTEMS > 1238 JOSEPHONE ST. > BERKELEY CA 34703 > Sorry, I have lost the phone number. Bruce You would have a hard time getting to them with this address. Zip 34703 is somewhere in the eastern half of the country. The actual address is PROTO SYSTEMS 1238 Josephine St. Berkley, CA 94703 The Phone # there is: (415)420-9579. Gary  ================================================================================ Note 119.0 [RSX]RSX SIG tape offer 4 replies EISNER::TINKELMAN "Bob Tinkelman - CCA" 17 lines 6-NOV-1987 15:53 -------------------------------------------------------------------------------- We have heard stories from a good number of people which seem to indicate problems with the normal "tree distribution" of RSX SIG tapes. For those who are experiencing problems getting these tapes, I'd like to extend a (temporary) offer. If you want either of the two most recent RSX SIG tapes (Fall 86 or Spring 87), please send a blank 2400' tape and return postage to Barton Bruce, Cambridge Computer Associates, Inc. 222 Alewife Brook Parkway, Cambridge, MA 02138 Specify what tape you'd like and the highest density that you can accept (6250 is much preferred). If you're really in a panic for a tape, send me mail here. It is my expectation that while there is a need for our offer, it is not so great that we will be buried in tapes. If that happens, of course we'll quickly withdraw our offer. ================================================================================ Note 119.1 [RSX]RSX SIG tape offer 1 of 4 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 34 lines 9-NOV-1987 12:52 -< There's a better way... >- -------------------------------------------------------------------------------- xD The 'normal' tree distribution of which you speak is known as the "croney" tree. There is an "official" distribution method: the LUG distribution method. All Local Users Groups receive{_ notification of the SIG tapes (regardless of type) within 1-2 weeks of their release date. All the LUG has to do is request the tape from the regional tape distributor. Generally, there is a 1-3 week delay from the time the tape is officially released by the SIG tape coordinator until the tape can be in the hands of the LUG member. I am the national tape distributor for ALL SIG tapes. I GUARANTEE all tapes to be distributed to the DECUS regions (6 of 'em) within 2-3 weeks of the time that I receive them. We've been doing this for over 4 years now, but apparently the word still isn't getting out sufficiently. If you need more information on the distribution method and how to get tapes either: 1) send me mail here on EISNER::}i (PERRY) or 2) send me mail on DCS (PERRY) or 3) call me for information concerning the tape distributor for your region. I won't make tapes for you, but your re}igional tape distributor will{_ make tapes for your LUG. Not a ~rLUG membe}ir, you asy? Too bad, join one. Even if it's long distance. Just get on their mailing list and you qualify for tape copy activities. Bob (PERRY) (503) 627-5410 ================================================================================ Note 119.2 [RSX]RSX SIG tape offer 2 of 4 EISNER::HASSINGER "Bob Hassinger" 56 lines 9-NOV-1987 16:02 -< Problems with NLO channel => reason for alternatives... >- -------------------------------------------------------------------------------- I know Bob's good work on the SIG tapes and I am sure we all thank him very much for all his efforts, * BUT *, in real life the process often just does not turn out the way he suggests, at least when measured from the other end of the pipeline. That is, from the time Joe random DECUS member leaves the Symposium until he actually gets the tapes in his hands. The first and most obvious delay is in the SIG tape coordinator's handling of the material. Some of them do a great deal of work on the tape that takes months. In other cases the tape is delayed for many months for a variety of reasons like people quitting or not knowing what to do, SIG leadership not giving the subject enough of the right kind of attention and supervision and so on. Once the tape gets from the coordinator to Bob things move pretty reliably but then in the next step after Bob at the regional level problems start to develop. Some of the excuses I have been given include regional distributors dropping out, moving, "not getting" the tapes sent from the LUGs and so on. I think the last time or two this has gone much better for our LUG by the way. The biggest problem seems to come at the point where the LUG is supposed to get the tapes from region and get them distributed to their members. The results here seem to be HIGHLY variable. Some LUGs do a great job. Some don't seem to do it at all. What I have seen typically when there is a problem is LUG leadership that is not up to speed on the process or that does not give it the attention it requires. I have seen problems like the notices about the tapes going to a new LUG chair who has no idea what they are so they get lost. There have been many problems like this at the local level. When the process is not working at the local level it takes a very knowledgeable member of the LUG who is very persistent to beat on the local organization until it straightens out. Many LUGs are not fortunate enough to have someone like that keeping things working. Note that it is not enough to fix it once. The process tends to keep breaking every time new people come into it. The real problem is that, as organized, the NLO distribution depends on dedicated, well trained people at EVERY level. It breaks if anyone along the way drops the ball. As you get further and further from the national leadership who specialize in the SIG tape process, awareness and knowledge seems to fall off very fast. Many times a LUG or SIG has leadership that really knows very little about the process and does not understand the impact of a few months delay while they get their act together. These problems are built into the NLO distribution system. The problems that result are among the reasons the SIG tree survives. The fact that the NLO process simply can not serve many DECUS members who can not be in a LUG for any one of many reasons also contributes to the need for both the SIG tree and the DECUS Library as alternative distribution channels. Bob H ================================================================================ Note 119.3 [RSX]RSX SIG tape offer 3 of 4 EISNER::KASPER "Beverly T. Kasper" 9 lines 9-NOV-1987 20:18 -< Local people often a problem >- -------------------------------------------------------------------------------- I agree with Bob - problems often occur on a local level. However, it's not always because of new people. I belonged to a LUG for a while where the tape librarian rarely showed up to meetings. When he did, he'd promise copies of tapes, then not send them. It sometimes took months of phone calls to get results. If the NLO really wants to be the distributor, it needs to keep tabs a bit better than it has done in the past. ================================================================================ Note 119.4 [RSX]RSX SIG tape offer 4 of 4 EISNER::CETRON 7 lines 10-NOV-1987 00:18 -< wooaaa nelly.... >- -------------------------------------------------------------------------------- we are drifting folks.... (and wow my first chance to be a moderator) so lets move it over to decus membership. For now, I won't drag over the previous 3 notes, but if requested..... -ed  ================================================================================ Note 120.0 [RSX]Need help with 11M to 11M+ 6 replies EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 9 lines 12-NOV-1987 11:51 -------------------------------------------------------------------------------- Help ! I'm about to begin (within the next few months) }ito convert about 15 11/73 RSX11-M systems to RSX11-M+ . Can anyone help me by telling }ime what to expect in the conversion process ? I know that I'll have to scan most of the command files we use as some of the 11M commands won't work in M+ ie: set /uic . 1) Will I have to re-task build all my images ? 2) Are the upgrade (??) differences documented anywhere ? ================================================================================ Note 120.1 [RSX]Need help with 11M to 11M+ 1 of 6 EISNER::CETRON 10 lines 12-NOV-1987 18:13 -------------------------------------------------------------------------------- well, lets see, I think I changed the 'welcome' banner to say m+ but other then that nothing more then would change during a new sysgen anyway. One needs to be VERY careful about named directories and decimal version numbers, but those can be disabled if desired. I would actually not worry TOO much, moving things to vms was much more painful... -ed ================================================================================ Note 120.2 [RSX]Need help with 11M to 11M+ 2 of 6 EISNER::OSUDAR "John Osudar" 14 lines 12-NOV-1987 18:48 -< "have to" vs. "want to" >- -------------------------------------------------------------------------------- Ed's right. There's very little you'll HAVE TO do -- converting any user-written (i.e. non-DEC-supplied) device drivers (that aren't already conditionalized for M-Plus) is one thing that comes to mind -- but there may be some things you'll WANT TO do. Since you're running 11/73's, you may want to take advantage of I/D space, supervisor mode libraries, etc. (that's pronounced "et cetera", not "Ed Cetron"... he's not part of M+!) You don't have to use DCL or named directories or decimal version numbers, but you may want to... when I converted a major in-production project from M to M-plus (many, many moons ago, I'll admit) I started out with things just as they had been, and gradually changed to make use of M+'s features. I haven't seen what M+ V4 does for you, but I'll bet that there's lots of good stuff that you'll want to use, eventually. ================================================================================ Note 120.3 [RSX]Need help with 11M to 11M+ 3 of 6 EISNER::DELARISCH "Arnold S. De Larisch" 37 lines 12-NOV-1987 21:50 -< A bit of work is necessary! >- -------------------------------------------------------------------------------- >> < Note 41.0 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Need help with 11M to 11M+ >- >> 1) Will I have to re-task build all my images ? There are a few gotcha's. Firstly, any privileged code (i.e. anything built with /PR:4 or /PR:5) needs to be rebuilt. Secondly, you should tread very softly when it comes to NAMED directories. If your programs are too smart (like error checking directory specifications for two octal numbers) you will have to 'fix' it. Ditto goes with Decimal version numbers (although we haven't had a problem with them. Of course, any non DEC supplied Device Drivers need to be rebuilt. Hopefully, the code has been conditionalized to work with either M or M+ (Don't count on it!). If not, you will need to modify the driver code slightly and the driver database rather extensively. There is an appendix in the RSX-11M-Plus Guide to writing an I/O Driver which talks about the mods. Non-priv tasks which are not linked to RES libs will run just fine! >> 2) Are the upgrade (??) differences documented anywhere ? Yea ... and no. The major differences in M+ vs M are in the Drivers and other Privileged Code. Further, If you want to take full advantage of the "M+" goodies (Like Supervisory mode libs and Seperate I/D space) you should Rebuild your tasks. You really should rebuild anything which uses FCS routines if you are gonna use NAMED DIRS or DECIMAL Version numbers! Thats all I can think of! -Arnold ================================================================================ Note 120.4 [RSX]Need help with 11M to 11M+ 4 of 6 EISNER::FRISBIE "Alan E. Frisbie" 6 lines 12-NOV-1987 22:50 -< Hello down there >- -------------------------------------------------------------------------------- >> (that's pronounced "et cetera", not >> "Ed Cetron"... he's not part of M+!) No, Ed is Micro/RSX :-) Alan ================================================================================ Note 120.5 [RSX]Need help with 11M to 11M+ 5 of 6 EISNER::STAMERJOHN "RW Stamerjohn" 7 lines 13-NOV-1987 11:39 -< FCSRES/FCSFSL >- -------------------------------------------------------------------------------- Re relinking tasks, if you use RSX-11M resident library (FCSRES) you will need to drag it along from 11M to avoid relinking. You can put up M+ FCSFSL (same thing, supervisor mode) and as things are linked, convert the LIBR option to a SUPLIB. The only real gotcha to the old 11M FCSRES is it will know nothing about named directories. ================================================================================ Note 120.6 [RSX]Need help with 11M to 11M+ 6 of 6 EISNER::FRIEDBERG 2 lines 25-APR-1988 04:58 -< ask Allen Watson >- -------------------------------------------------------------------------------- Allen Watson has given some nice DECUS presentations a few years back on M to M+ migration, and also written some articles. Allen - you there?  ================================================================================ Note 121.0 [RSX]Multibuffered FCS - a tutorial No replies EISNER::TINKELMAN "Bob Tinkelman - CCA" 146 lines 12-NOV-1987 17:41 -------------------------------------------------------------------------------- The following introduction to FCS multibuffering was written by Barton Bruce of Cambridge Computer Associates, Inc. He is not (yet) on DECUServe and allowed my to upload this file for him. MULTIBUFFERING/LARGEBLOCKING WITH RSX11M FCS Barton Bruce, Cambridge Computer Associates, Inc. Tasks that never have to wait for i/o, and that have no noticable idle time are easy to make. There are a few simple steps that can convert many of your programs to this mode. A task normally uses one 512 byte buffer for each file it has open. The task often finds itself waiting for some i/o to complete with that single buffer. By simply making the buffer bigger, the number of times one waits decreases, but one still waits. By having a 2nd spare buffer one need never wait. But by having two large buffers, one never waits and the disk is not going a dance across the floor. For writing, the other buffer should be free to spill over into when the current buffer is full. The current buffer is then written asynchronously while your task continues. When written this buffer becomes the empty spare. For reading the exact opposite is needed. The other buffer must contain the preread next blocks from disk ready for use when the current buffer is emptied. All this sounds like a lot of complex houskeeping to help you lose data and grow grey hair. The simple truth is that FCS already has support for all this. You just have to turn it on. Everything else is the same. Your writes and reads look the same as before. If it is so good, why doesn't everyone always use this support? First, although support has been claimed to be there for many many years, it didn't always work... Second, the necessary buffer space may not be available in many tasks. Third, DEC hasn't advertised the virtues of doing this enough. Rather than write a lot more, I am going to say a few specific things and then give you a sample program to try. ACTFIL is NOT really the number of files you have open, but really the number of 512 byte (plus overhead) buffers you need. 'READONLY', aside from obvious usage, also sets the bit that requests anticipatory read-aheads into extra buffers rather than the default write-behind action. Vanilla SYSLIB does not support multi-buffering. Big (ansi mag tape) buffer support is there on M+, and is in ANSLIB on plain RSX. DEC supplies modules to upgrade your syslib but do it in a separate library as some modules are slightly larger and some other task may need the older small version. Three or more buffers works, but won't normally help, and takes space. It is better to use 2 bigger ones. Our example is written in F77 and reads and writes sequentially through its files and does some simple counting. Make a multi-buffering version of syslib: pip mbflib.olb=lb:[1,1]syslib.olb lbr mbflib/rp=lb:[1,1]fcsmbf Make a big text file to test : pip yuk.tmp/bl:8000.=nl: pip yuk.tmp/up=lb:[11,10]*.mac Our simple program - speed.ftn : program speed implicit integer*2 (a-z) parameter bufsiz=4096 ! 8 x 512 -> uses ACTFIL = 8 parameter bufct=2 ! x 2 -> need ACTFIL=16 for each file c later try the following to see how slow it is: c parameter bufsiz=512,bufct=1 parameter in='yuk.tmp', out='yukyuk.tmp' integer*4 lines,chars,cpl(0:255),comnts character*255 buf data lines,chars,cpl,comnts / 0,0,256*0,0 / open (unit=1,name=in,blocksize=bufsiz,status='old', 1 buffercount=bufct,readonly) open (unit=2,name=out,blocksize=bufsiz,status='new', 1 buffercount=bufct,form='unformatted', 2 carriagecontrol='list', 3 extendsize=-4000) ! request space infrequently do 100 x = 1,1,0 ! loop forever buf(1:1) = ' ' ! don't count comment twice if ! zero len line follows read (1,10,end=200) q, buf 10 format (q,a) lines=lines+1 chars=chars+q cpl(q)=cpl(q)+1 ! count lines with this many chars if (buf(1:1).eq.';') comnts=comnts+1 ! count comment lines write (2) buf(:q) 100 continue 200 do 210 i=0,255 if (cpl(i).ne.0) type * , cpl(i) ,' lines ', i, ' bytes long' 210 continue type *, comnts, ' comment lines' type *, chars, ' bytes,', lines, ' lines' close (unit=1) close (unit=2) end If you are using F77 v5.2 the /DS switch ensures I/D separation if you are unsure how your compiler's default was built. This demo hardly needs the extra space I/D separation gives, but real tasks may need it. Vanilla RSX (and non i/d M+) folks should simply leave out the /ID in SPEED.TKB. f77 speed,speed/-sp=speed/id Make a TKB command file SPEED.TKB : speed/id,speed/-sp=speed lb:[1,1]f77fcs/lb mbflib/dl / ; 16 for each big/multi buffered file, 1 for type * to terminal actfil=33 ; allow records bigger than 128 bytes maxbuf=255 / Now build it: tkb @speed.tkb If you have console lights (11/70s) warn your operator that NO idle pattern at all does NOT mean you have crashed or are in a hard loop. run speed If you like the speed this gives you, consider sending DEC an SPR suggesting the M+ FCSRES/FCSFSL be a multi-buffering version rather than simply a big-buffering one (they HAD to at least do that for ANSI tape support). Call if you need to. Barton F. Bruce Cambridge Computer Associates, Inc. 222 Alewife Brook Parkway Cambridge, Mass. 02138 (617)-868-1111  ================================================================================ Note 122.0 [RSX]Need RSX mail information. 5 replies EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 5 lines 17-NOV-1987 17:18 -------------------------------------------------------------------------------- Has anyone ever come across an RSX mail package which: 1) has store and forward capability 2) can talk across DECNet to VMS systems (VMS mail interface capability) ================================================================================ Note 122.1 [RSX]Need RSX mail information. 1 of 5 EISNER::COVERT "John Covert" 3 lines 17-NOV-1987 17:29 -------------------------------------------------------------------------------- How about DECmail/RSX (for M-Plus only)? /john ================================================================================ Note 122.2 [RSX]Need RSX mail information. 2 of 5 EISNER::CETRON 5 lines 19-NOV-1987 14:13 -< decus library does it again... >- -------------------------------------------------------------------------------- or even cheaper the software tools mailer...works real well.... -ed ================================================================================ Note 122.3 [RSX]Need RSX mail information. 3 of 5 EISNER::DELARISCH "Arnold S. De Larisch" 13 lines 21-NOV-1987 00:48 -< But No Store and Forward! >- -------------------------------------------------------------------------------- >> < Note 43.2 by EISNER::CETRON > >> -< decus library does it again... >- >> or even cheaper the software tools mailer...works real well.... If its the one on the RSX SIG tape (donated by the NETWORKS Group and/or the one from the RSX Group)... It doesn't do store and forward. Further it has a Poor Man's Routing System. It works and its REAL cheap! -Arnold ================================================================================ Note 122.4 [RSX]Need RSX mail information. 4 of 5 EISNER::CETRON 7 lines 23-NOV-1987 14:27 -< ...totally independent... >- -------------------------------------------------------------------------------- no, the software tools mailer is part of a larger software tools package which gives a sort of 'unixy' feel to the machine with utilities like ls, cd, ar,...and pipes and filters. -ed ================================================================================ Note 122.5 [RSX]Need RSX mail information. 5 of 5 EISNER::DELARISCH "Arnold S. De Larisch" 16 lines 26-NOV-1987 14:20 -< I assum your are referring to the Lawerence Livermore tools >- -------------------------------------------------------------------------------- >> < Note 43.4 by EISNER::CETRON > >> -< ...totally independent... >- >> >> >> no, the software tools mailer is part of a larger software tools >> package which gives a sort of 'unixy' feel to the machine ... I assume you are referring to the Lawerence Livermore Tools package. The one I installed DIDN'T have any DECNET hooks ... so it was good only on a single RSX machine. (Please note: this was a very early version of the tools!) -Arnold  ================================================================================ Note 123.0 [RSX]RMS bug? 1 reply EISNER::NORTON 12 lines 19-NOV-1987 10:51 -------------------------------------------------------------------------------- An indexed file gets corrupted even when none of the programs accessing it have aborted. The problem shows up as failure to find a given record by one of the alternate keys, even when it can be found by the primary key. I'm told by the programmers involved that the primary activity on the records is modifying, not adding or deleting, and that the alternate keys do change. The system is M+V2.1E, but that's still RMS V2.0 isn't it? Suggestions? ================================================================================ Note 123.1 [RSX]RMS bug? 1 of 1 EISNER::RICE "Gary Rice" 17 lines 20-NOV-1987 10:44 -< "Corrpution" is usually more serious >- -------------------------------------------------------------------------------- > An indexed file gets corrupted even when none of the > programs accessing it have aborted. The problem shows up as failure > to find a given record by one of the alternate keys, even when it > can be found by the primary key. I'm told by the programmers involved ... First, I'm not sure that "corrupted" is quite the right word to use. In the sense of RMS errors at least, "corrupted" is used to refer to an index file that can't be read at ALL under ANY conditions. Your problem may be something else. When you access an indexed file via secondary keys, you get the records in key order, but if you have duplicate key values, the records are returned to your program IN THE ORDER THAT THEY WERE WRITTEN to the file. This ordering may be what you are seeing at least if you are accessing a record that has a duplicate secondary key value. Gary  ================================================================================ Note 124.0 [PRO300]PRO3XX disk/control/firmware compatible 1 reply EISNER::KOZAM 14 lines 19-NOV-1987 22:22 -------------------------------------------------------------------------------- Does anyone have information about disk/controller/firmware compatibility? Specifically, are there different controllers for the RD50, RD51, RD52, RD53, RD31, RD32? Can I take out the RD50 and put in an RD52 and expect it to work? Do I need to change or upgrade the controller firmware? DEC's Add-On and Upgrade people had no idea about this. In fact, I don't think they even knew what firmware was (I guess firmware wasn't in their latest catalog, thus they figured it couldn't be too important :-). Thanks for any help you can offer. Marc Kozam ================================================================================ Note 124.1 [PRO300]PRO3XX disk/control/firmware compatible 1 of 1 EISNER::RICE "Gary Rice" 32 lines 20-NOV-1987 10:36 -< A rose is a rose . . . >- -------------------------------------------------------------------------------- > Does anyone have information about disk/controller/firmware > compatibility? Specifically, are there different controllers for > the RD50, RD51, RD52, RD53, RD31, RD32? There is a very good article in the Newsletters about this sort of thing. It was published in the July '87 issue and written by Tom Hintz. Rather than repeat the article here, I will summarize it by adding some new info supplied to me by Jeff Slayback, DEC PRO Counterpart. He states: First released controller for RD50 ONLY had the following ROMS 013B2 014B2 015B2 ROM Change 013B2 014B2 021B2 ROM Change 013B2 014B2 063B2 (the 63 might have been 61 or 62, don't know for sure) LAST Change 071B2 072B2 073B2 The last change provided support for ALL disks that are available fro the PRO from the RD50 thru the RD53 as well as the RD31 and RD32. The only thing you need to worry about if you have the ROMS on your controller is the REV of P/OS necessary to support the disk. Gary  ================================================================================ Note 125.0 [PRO300]WPSPLUS -- LNO3 3 replies EISNER::HAHN 7 lines 20-NOV-1987 16:33 -------------------------------------------------------------------------------- I need information on how to control an LN03 in WPSPLUS on the PRO. Is it in the same manner as the DECMATE, that is to say use control on / off and indicate PRINTER FONT NORMAL font# size hw vs, where the font number is the SGR# - 9. Any help will be appreciated. Pierre ================================================================================ Note 125.1 [PRO300]WPSPLUS -- LNO3 1 of 3 EISNER::RICE "Gary Rice" 12 lines 21-NOV-1987 08:30 -------------------------------------------------------------------------------- > I need information on how to control an LN03 in WPSPLUS on the PRO. I don't use WPS (although I DO have it on my PRO), so I can't help with the WPS specific part of the question. However, P/OS didn't provide support for the LN03 until AFTER P/OS v3.1 was released. The DEC developers provided a patch that was distributed at Nashville to support the LN03. This patch is now incorporated into P/OS v3.2. So, if you don't have the patch and aren't running v3.2, the LN03 is going to be less than a printer and only slightly more than a boat anchor. Gary ================================================================================ Note 125.2 [PRO300]WPSPLUS -- LNO3 2 of 3 EISNER::LEFEBVRE "Kenneth LeFebvre" 22 lines 21-NOV-1987 15:25 -< WPS-PLUS Printer Control Codes >- -------------------------------------------------------------------------------- For the short time that I had a PRO running WPS-PLUS, I tried to get my LN03 to work on it. It works fine as a standard printer, but obviously you are trying to get the nicer Laser-features out of it, huh? The best way I could get anything wa by using the table feature of WPS-PLUS. I am not intimately familiar with the system, so you will have to use your manual instead of my notes here, but basically what I did was to run the WPS-PLUS Installing/Configuration program to define special control codes in its control-code table. What happens is you define your own unique keyword to be used in a PRINT CONTROL Block. The definition simply assigns an ASCII sequence of characters to the keyword, so whenever you use that keyword in the PRINT CONTROL Block, the appropriate escape sequence (or whatever you defined) is sent to the printer. The place to look for documentation would be inthe installation guide, I think. I wish that I had those manualks still so that I could look up a page number for you. I am sure that you can find it easily enough, once you know what to look for. Ken ================================================================================ Note 125.3* [PRO300]WPSPLUS -- LNO3 3 of 3 EISNER::HASSINGER "Bob Hassinger" 1 line 23-NOV-1987 10:03 -< See OFFICE_AUTOMATION 31.* for more discussion... >- --------------------------------------------------------------------------------  ================================================================================ Note 126.0 [RSX]Need VAXNET for RSX. 3 replies EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 4 lines 23-NOV-1987 15:54 -------------------------------------------------------------------------------- I'm looking for something akin to VAXNET, which runs under VMS, to run on my 11/73s. This is a communication package to do things like dialing out, file xfer (I think), answering phone calls, etc. Has anyone come across such a beast? ================================================================================ Note 126.1 [RSX]Need VAXNET for RSX. 1 of 3 EISNER::CETRON 6 lines 23-NOV-1987 18:07 -< just a little green frog >- -------------------------------------------------------------------------------- bob, all I've seen is kermit....sorry.... -ed ================================================================================ Note 126.2 [RSX]Need VAXNET for RSX. 2 of 3 EISNER::KASPER "Beverly T. Kasper" 4 lines 23-NOV-1987 21:43 -< It's called RSXNET >- -------------------------------------------------------------------------------- Robin Miller, the creator of VAXNET, was an old RSX hacker. So, of course, he also wrote RSXNET!! I know it was on one or more of the Symposium tapes; sorry, I don't know which. Look on S85 or earlier. ================================================================================ Note 126.3 [RSX]Need VAXNET for RSX. 3 of 3 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 1 line 24-NOV-1987 13:20 -< THanks, I'll look for RSXNET... >- --------------------------------------------------------------------------------  ================================================================================ Note 127.0 [RSX]V4.0 Vectored Drivers -- Bad distribution 5 replies EISNER::DOHERTY "Bob Doherty" 14 lines 2-DEC-1987 21:55 -------------------------------------------------------------------------------- We recently received v4.0 and apparently got a bad distribution. The file RSXVEC.STB was missing quite a number of symbols, and as a result all of the vectored driver builds failed. From TSC we were told that the file should be 14 blocks long whereas the one in our distribution was only 10 blocks. We will presently get a distribution from SDC which we hope will be correct, however, in the meantime does anyone know how to build the correct RSXVEC.STB? There is no command file to build it, that we could find, and there does not seem to be any macro source with the RSXVEC psect referenced. Bob. ================================================================================ Note 127.1 [RSX]V4.0 Vectored Drivers -- Bad distribution 1 of 5 EISNER::MCGLINCHEY "SANCHO! My armor! My TECO Macro" 21 lines 21-DEC-1987 22:48 -< You, too? >- -------------------------------------------------------------------------------- >> The file RSXVEC.STB was missing quite a number of symbols, and >> as a result all of the vectored driver builds failed. I'm doing vectored driver development on Micro/RSX 4.0 and haven't found any symbols missing. COuld you post which ones are missing? I have found, though, that the symbols RSX11M.STB (called IDEXEC.STB in Micro/RSX) have a different value from those in the Exec map (called MICROD.MAP). The workaround is to build your own map our of IDEXEC.STB with the command line TKB ,IDEXECSTB.MAP/-SP=LB:[1,54]IDEXEC.STB -Glinch ================================================================================ Note 127.2 [RSX]V4.0 Vectored Drivers -- Bad distribution 2 of 5 EISNER::DOHERTY "Bob Doherty" 18 lines 28-DEC-1987 18:58 -< Missing symbols >- -------------------------------------------------------------------------------- The missing symbols are: $BLKC2 $FRKHD $QINSB $CRPAS $IODSA $QRMVA $CVLBN $LOGER $STMAP $DQUMP $MPPHY $ULDRQ $DVTMO $MPUB1 $UMWRT $FNERL $MPUBM $VOLVD The builds which these showed up in(not all in each build) were: PUCOM,DUDRV,MSDRV,DYDRV, and LPDRV. We could not find the macro source from which the RSXVEC.STB was built anywhere on the distribution. The PSECT in the stb was RSXVEC(I think) and we couldn't find this referenced in any macro file in the distribution. Bob. ================================================================================ Note 127.3 [RSX]V4.0 Vectored Drivers -- Bad distribution 3 of 5 EISNER::MCCARTHY 21 lines 31-DEC-1987 15:56 -------------------------------------------------------------------------------- I'm not sure this problem still exists, but I'll ask anyway. Have you installed DECnet? If so did you apply update A first? the existing DECnet used to wipe out RSXVEC with its own copy. RSXVEC can easily be reconstructed on the full distribution kit. >SET /UIC=[3,54] >MAC RSXVEC.STB=[11,10]SFVC2 will do it. As for Jim's problem, we rebuilt the exec's at the last minute for Micro/RSX and didn't think of the maps when we decided not to rebuild the advanced programmers kit. -Brian ================================================================================ Note 127.4 [RSX]V4.0 Vectored Drivers -- Bad distribution 4 of 5 EISNER::DOHERTY "Bob Doherty" 10 lines 2-JAN-1988 16:15 -< Problem in the dist. itself >- -------------------------------------------------------------------------------- We did apply Update A first to Decnet. We also looked at the STB on the virgin distribution, and it was only 10 blocks(the correct one is 14). We missed the comments in SFVC2.mac, on building the stb, however, we have since gotten a correct dist from SDC, so our problem is solved. Bob. ================================================================================ Note 127.5 [RSX]V4.0 Vectored Drivers -- Bad distribution 5 of 5 EISNER::FRIEDBERG 11 lines 25-APR-1988 05:05 -< vectored drivers/priv programs gotcha >- -------------------------------------------------------------------------------- re vectored drivers -- there is a gotcha here (maybe); the documentation in the V4.0 M+ release notes is corrected by the cover letter; if you lost the cover letter, you could be in for some nasty surprises whilst tring to vector up those privileged drivers, etc. As always, don't read the documentation, just grab one of DEC's vectored drivers (and privileged tasks, they are different!) and do what DEC does. If anyone is interested, I have vectored up the UCB program which seems to run fine now on V4 of M+. Carl Friedberg, 212 233 5470.  ================================================================================ Note 128.0 [PRO300]PRO/Toolkit 1 reply EISNER::RICE "Gary Rice" 12 lines 5-DEC-1987 10:00 -------------------------------------------------------------------------------- Now that the new version of the PRO/Toolkit has been out for a while (v3.2), have you had any experience using it? Is there enough new stuff in it to warrant buying a copy? (I'm not on maintenance, so I am looking at a $500 price tag). The few bugs that I have found in the v3.0/3.1 version aren't serious enough (for me, at least) to justify upgrading to a new version based on "bug fixes" alone. Gary ================================================================================ Note 128.1 [PRO300]PRO/Toolkit 1 of 1 EISNER::ETHINGTON "Superior Klingon Technology" 19 lines 27-JAN-1988 00:19 -< 3.2 Tool Kit >- -------------------------------------------------------------------------------- Since you already have a Tool Kit license, you are really looking at a fair bit less money - you can buy the -HZ option at something on the order of half price. Is there enough new stuff to justify buying it? Well, depends on what you are looking for. You can install Tool Kit 3.0/3.1 on P/OS 3.2 and, if you do so, you will get all the new DCL features like TDX and such. If the modest bug fixes in Tool Kit do not interest you, then all that is left is the new documentation (corrections and new DCL documentation, mostly) and the new microfiche listings, which now contain several new components like INSREM and SUMFBI. If you do install the old Tool Kit on 3.2, be sure to apply the updates from 3.1 after installation - several modules in SYSLIB are replaced by 3.1 to correct bugs in high level language interface and FMS. Jerry  ================================================================================ Note 129.0 [RSX]Need help with RD: 3 replies EISNER::TACKETT 25 lines 5-DEC-1987 16:17 -------------------------------------------------------------------------------- I have a program which needs occasionally to turn a specific device on or off line. I would like to use the RD: (reconfiguration device, if memory serves) driver to handle this, but after poring over the sources for CON and HRC I must admit I'm stumped. I don't need all the capability of CON, just the ability to turn the controller and unit on/off line. My current kluge is to spawn a command to CON, but this requires a bit of magic as the users of the program aren't privileged. My 'magic' involves sending (VSDA$ ?) the CON command line to a privileged task which toggles on the privilege bit in the user terminal's UCB, spawns the command, waits for it to complete, and then toggles the privilege bit back to off. I do a few checks to prevent other privileged commands from being sent, but it's difficult to be satisfied with the security of this technique. Also I think it's not very elegant, but at least it gets the job done. Any suggestions? Can someone provide me with info about RD:? You can reach me by phone at (408)742-6448 between 6:30 AM and 3:00 PM Pacific time, by mail at the address below, or (of course) here in DECUServe. Galen Tackett LMSC O/68-31, B/190 PO Box 3504 Sunnyvale, CA 94088-3504 ================================================================================ Note 129.1 [RSX]Need help with RD: 1 of 3 EISNER::MAXWELL "Gary Maxwell" 37 lines 19-DEC-1987 03:24 -< Gee, me too >- -------------------------------------------------------------------------------- < I would like to use the RD: (reconfiguration device, if memory serves) < driver to handle this, but after poring over the sources for CON and HRC I < must admit I'm stumped. I don't need all the capability of CON, just the < ability to turn the controller and unit on/off line. Gee, me too. I needed an interface to HRC to bring a new device online with my Virtual Disk package. It was the last step to the package, and I got plenty confused going through CON and HRC. < My current kluge is to spawn a command to CON, but this requires a bit of < magic as the users of the program aren't privileged. My 'magic' involves < sending (VSDA$ ?) the CON command line to a privileged task which < toggles on the privilege bit in the user terminal's UCB, spawns the command, < waits for it to complete, and then toggles the privilege bit back to off. I have a problem in that I create a new device database on the fly. This will require HRC to increase the buffer size of RD: to read all device database information (it always reads the entire database - sometimes two or three times -- maybe it's never sure it got it right). CON tells HRC to resize its buffer, but it doesn't work for me. I had to send a special I/O call to RD: directly to tell it to increase its stupid buffersize, and then I spawn CON with a CON/NOMSG command to bring the Virtual Device online. Needless to say, the AVF utility is privileged. In that case, non-privileged users can use it. You may want to make your application /PR:0, or use the GIN$ directive to toggle your privilege bit. That's what I did. If you don't have the Spring '87 tape, stop by sometime or give me a call and I'll zap it to you. After all this, I mentioned my problems to the "anonymous developer," who assured me that confusion about CON and HRC was rampant. What should we do: stomp out confusion or stomp out CON/HRC/RD:? :-)> Hope this helps. ================================================================================ Note 129.2 [RSX]Need help with RD: 2 of 3 EISNER::MCCARTHY 126 lines 31-DEC-1987 16:30 -< Some info on the RD: interface >- -------------------------------------------------------------------------------- Oh, fiddlesticks. This would be a lot easier if there were a direct way to get the source over here, but since I'm such a nice guy I'll type it all back in. I'm not such a nice guy as to support it, though. This is an unofficial friendly reply, I'll answer questions on it here as time permits, but I don't ever want to see, for example, an SPR on the subject, OK? Here's an example of a program which manipulates the device states through QIOs to RD: .MCALL QIOW$S, DIR$, OLRDF$ OLRDF$ ; Define HRC offset definitions ATTQIO: QIOW$ IO.ATT,1,1 ; HRC QIO to online a unit. The QIO uses the Multi-function function ; function to HRC with a single ONLINE function in the list. This is ; because this is how CON does everything, so the code was the easiest ; to figure out. The buffer (P1LIST) describes a list of things to ; do, in this case 1. RCUQI: QIOW$ IO.MFC,1,1,,IOSB,, IOSB: .WORD 0,0 P1LIST .WORD IO.ONL ; On line function (IO.OFL is offline, ; I think) .WORD DESC1,LEN1 ; Device descriptor descriptor .WORD DESC2,LEN2 ; Device status descriptor P1LEN=.-P1LIST ; Notice that there are two descriptors referenced above. HRC will ; take the device info from the first, and return new device status ; via the second. Hence we create one descriptor and zero the other. DESC1: .ASCII /DK/ ; C$DNAM - Device name ; ^^ ; ++--- Unit name (DK1:) goes in these two places ; v .BYTE 0,1 ; C$PUN (don't use) , C$LUN - Logical unit .WORD 0 ; C$DSCT , C$DEVT - don't use .WORD 0 ; C$DSTS - don't know .WORD 0 ; C$DST2 - descriptor (0 => unit) LEN1=.-DESC1 DESC2: .WORD 0 ; Returned .WORD 0 ; device .WORD 0 ; information .WORD 0 ; from .WORD 0 ; HRC... LEN2=.-DESC2 ; HRC QIO to online the controller HRCCQI: QIOW$ IO.MFC,1,1,,IOSB,, IOSB: .WORD 0,0 P2LIST .WORD IO.ONL ; On line function (IO.OFL is offline, ; I think) .WORD DESC3,LEN3 ; Device descriptor descriptor .WORD DESC4,LEN4 ; Device status descriptor P2LEN=.-P2LIST DESC3: .ASCII /DK/ ; C$DNAM - Device name ; ^^ ; ++---- Controller name (DKA) goes in these two places ; v .BYTE 0,0 ; C$PUN (don't use) , C$LUN - Logical unit .WORD 0 ; C$DSCT , C$DEVT - don't use .WORD 0 ; C$DSTS - don't know .WORD 200 ; C$DST2 - descriptor (200 => controller) LEN3=.-DESC3 DESC4: .WORD 0 ; Returned .WORD 0 ; device .WORD 0 ; information .WORD 0 ; from .WORD 0 ; HRC... LEN4=.-DESC4 START: DIR$ #ATTQIO ; Attach RD: (Assigned at taskbuild) ; We assume this works. DIR$ #HRCCQI ; Online the controller MOV $DSW,R0 ; Collect up status of QIO MOV IOSB,R1 ; and status of the I/O itself MOV IOSB+2,R2 ; Sophisticated error handline technique, ; don't you think? DIR$ #HRCUQI ; Now try the unit (harmless if ; the controller online failed) MOV $DSW,R3 ; Determining purpose of this section MOV IOSB,R4 ; is an exercise for the reader MOV IOSB+2,R5 ; Thank heaven this machine has 6 free ; registers. IOT ; Format output and print it. .END START ----------------------------------------------------------------------- As for Gary's database problem, there is a routine ($HRCIN) which should be called whenever HRC's database may be faulty. It's called via: MOV something,R0 ; Put the number of a LUN that HRC ; can use in R0 CALL $HRCIN ; and re-init HRC. It's found in OLR.OLB. ---------------------------------------------------------------------- -Brian ================================================================================ Note 129.3 [RSX]Need help with RD: 3 of 3 EISNER::SIMONS "Paul, Not that CONVEX!" 5 lines 13-JUL-1988 10:48 -< Kudos! >- -------------------------------------------------------------------------------- Without being overly syrupy, I'd like to say a heartfelt "Thank you"! We needed to develop an online/offline facility like that expressed in the previous notes. With your reply, Brian, we were able to put together an effective subsystem in short order. I, for one, am *very* grateful for your help.  ================================================================================ Note 130.0 [RSX]DQ11? 4 replies EISNER::DEGUMBIA 6 lines 10-DEC-1987 17:13 -------------------------------------------------------------------------------- Here's one for all you "Senior" RSX types. What ever happened to the DQ11-DA? We are busy upgrading from RSX-11M V3.1 to RSX-11M+ V4.0, and can't find any software to support the device. Moving to the DUP11 doesn't seem like a good idea, because romour has it that it puts a hefty load on the cpu. Does anyone know when the DQ11 was last supported? Maybe we could port the driver? Help! ================================================================================ Note 130.1 [RSX]DQ11? 1 of 4 EISNER::TINKELMAN "Bob Tinkelman - CCA" 23 lines 11-DEC-1987 11:41 -< DQ11-DA with RSX HASP product >- -------------------------------------------------------------------------------- > Here's one for all you "Senior" RSX types. What ever happened to > the DQ11-DA? We are busy upgrading from RSX-11M V3.1 to RSX-11M+ > V4.0, and can't find any software to support the device. Under M, were you using a DEC driver? (DQDRV?) Our only experience with DQ11-DAs for was with DEC's RSX RJE HASP product (still in the current CSS catalogue). HASP did not depend on (or use) an "operating system driver". It was a kludge with its own "driver" code built in. (Depending on how you conditionally assembled the whole thing, code was included for DQ or DU or DP or DUP or ...). > Moving to the DUP11 doesn't seem like a good idea, because romour has > it that it puts a hefty load on the cpu. Right. The DUP is a character interrupt device and will cost you CPU cycles every character in and out. > Does anyone know when the DQ11 was last supported? As indicated above, we didn't use a real driver. When we went to M-Plus, we did hack up the RSX HASP code to make it work there. (We had gotten pretty good at changing the code over the years.) I don't remember how big an effort this change was. We are still running HASP, using the DA, under M-Plus today. ================================================================================ Note 130.2 [RSX]DQ11? 2 of 4 EISNER::DEGUMBIA 3 lines 11-DEC-1987 15:54 -< DQ11 under RSX11S >- -------------------------------------------------------------------------------- Yes, it was a Digital driver (DUDRV). We managed to obtain an SPD for RSX-11S, and it is listed as a supported device there. So now we will bang on our sales rep's door. Thanks. ================================================================================ Note 130.3 [RSX]DQ11? 3 of 4 EISNER::MAXWELL "Gary Maxwell" 12 lines 19-DEC-1987 03:28 -< Reusable code - now THAT'S INCREDIBLE! >- -------------------------------------------------------------------------------- < -< DQ11 under RSX11S >- < < Yes, it was a Digital driver (DUDRV). We managed to obtain an SPD < for RSX-11S, and it is listed as a supported device there. So now < we will bang on our sales rep's door. Thanks. And now, that same DUDRV is handling all of our MSCP devices! When DEC writes a driver, they make sure it lasts through multiple hardware generations! (Or at least until they run out of alphabetic combinations) ================================================================================ Note 130.4 [RSX]DQ11? 4 of 4 EISNER::MCCARTHY 4 lines 31-DEC-1987 16:32 -------------------------------------------------------------------------------- Me thinks is XxDRV.  ================================================================================ Note 131.0 [RSX]Where is *served* printer support? 1 reply EISNER::NORTON 11 lines 17-DEC-1987 15:45 -------------------------------------------------------------------------------- Version 4.0 of M+ is supposed to support printers on terminal servers. I find no mention of this in the release notes, nor in the DECNET autopatch procedure notes from [230,200] on the layered product update tape. Can anyone tell me: 1. Do I need some future version of DECNET as well as M+V4.0? 2. If the patches to DECNET V3 from the M+V4 layered product update tape are enough, what commands do I use to set up a served printer? ================================================================================ Note 131.1 [RSX]Where is *served* printer support? 1 of 1 EISNER::DELARISCH "Arnold S. De Larisch" 19 lines 19-DEC-1987 00:30 -< DECNET-RSX-11M+ V4.0 NEEDED! >- -------------------------------------------------------------------------------- >> < Note 49.0 by EISNER::NORTON > >> -< Where is *served* printer support? >- >> >> Version 4.0 of M+ is supposed to support printers on terminal servers. >> >> Can anyone tell me: >> 1. Do I need some future version of DECNET as well as M+V4.0? Yup! V4.0 DECNET-RSX-11M+ >> >> 2. If the patches to DECNET V3 from the M+V4 layered product update >> tape are enough, what commands do I use to set up a served printer? Refer to above answer. There is a way (documented in the release notes) to connect up to a DEDICATED printer on a Terminal Server. Haven't tried it ... but ... -Arnold  ================================================================================ Note 132.0 [RSX]M 3.1 on an 11/84?! 2 replies EISNER::DEGUMBIA 7 lines 18-DEC-1987 17:04 -------------------------------------------------------------------------------- Alas, here at CONVEX we are still running RSX-11M 3.1. Our sales rep tells us that we can run 3.1 on an 11/84. Digital even loaned us one so we could try it out. Alas, we have been unsuccessful in booting the system. We have an RP06, and an RK05. Digital supplied us with a M 4.1 RP06 driver, to no avail. We are wondering if anybody knows of an overwhelming reason why we cannot run RSX-11M 3.1 on an 11/84. ================================================================================ Note 132.1 [RSX]M 3.1 on an 11/84?! 1 of 2 EISNER::FRISBIE "Alan E. Frisbie" 26 lines 18-DEC-1987 22:12 -< It can be done, but NOT easily >- -------------------------------------------------------------------------------- >> Our sales rep tells us that we can run 3.1 on an 11/84. This must be the same guy that used to sell beachfront property in Nevada. >> Alas, we have been unsuccessful in booting the system. >> We are wondering if anybody knows of an overwhelming reason >> why we cannot run RSX-11M 3.1 on an 11/84. Back when RSX-11M v3.1 was written, the only machine with Unibus mapping registers (UMRs) was the 11/70. This also implied that the RP06 controller was on an RH70 Massbus controller, which has 22-bit addressing. Your 11/84 also has UMRs, but the RP06 is on an RH11 Massbus controller which does NOT have 22-bit addressing. The RH11 must access memory via the Unibus Map. Not only must the drivers be modified, but SAVe and BOOt as well. I would also be surprised if the v4.1 driver you were given works without modification. I would give you more details, but the line noise is really fierce tonight. Call me if you need more help. Alan ================================================================================ Note 132.2 [RSX]M 3.1 on an 11/84?! 2 of 2 EISNER::MCCARTHY 14 lines 31-DEC-1987 16:47 -------------------------------------------------------------------------------- >This must be the same guy that used to sell beachfront property >in Nevada. Contrary to the desires of some inhabitants of the granola belt, beachfront property in Nevada is a great investment. Just a couple more years, now. :-) Alan's explanation is accurate. Even if you can get the driver to work, the special drivers for save and boot had to be changed to add a delay for the 11/84. -Brian  ================================================================================ Note 133.0 [RSX]Virtual Disk Trouble in New version of BRU 4 replies EISNER::DELARISCH "Arnold S. De Larisch" 29 lines 29-DEC-1987 14:32 -------------------------------------------------------------------------------- Attention RSX-11M+ users: There is a problem with the Virtual Disk Package and new BRU. BRU has become a bit smarter and now checks U.CW1 for the DV.MSD (Mass Storage Bit). Most of the Virtual Disk packages we have come across have NOT set this bit. The FIX is rather easy. Locate the Driver database file (xxTAB.MAC) find the entry for U.CW1. Logically OR U.CW1 with DV.MSD (Octal 100). In Jim Bostwick's Virtual Disk Package (FALL 1986, I think?) the following lines must be changed: Original VDTBL.MAC .IF B,SGL .WORD DV.DIR!DV.F11!DV.MNT ;(U.CW1 ) .IFF .WORD DV.DIR!DV.F11!DV.MNT!DV.SDI ;(U.CW1) MODIFIED VDTBL.MAC .IF B,SGL .WORD DV.DIR!DV.F11!DV.MNT!DV.MSD ;(U.CW1 ) .IFF .WORD DV.DIR!DV.F11!DV.MNT!DV.SDI!DV.MSD ;(U.CW1) Please Note: VDTBL.MAC is used to create VDTAB.MAC in the Bostwick Package! -Arnold ================================================================================ Note 133.1 [RSX]Virtual Disk Trouble in New version of BRU 1 of 4 EISNER::BOSTWICK 16 lines 7-JAN-1988 17:59 -< Spread The Blame >- -------------------------------------------------------------------------------- > >Please Note: VDTBL.MAC is used to create VDTAB.MAC in the Bostwick Package! > You are SO right, Arnold! However, I can take only partial blame for the goofy name - I ripped the base package of of several people's work on earlier tapes. There are still original Stammerjon comments in the driver source! { I'm to blame for being too lazy to fix the file name and the build command files. } I plan to fix this little bug up, AND change the file name, AND (hopefully) get AVD/DVD Vectored, all in time for Cinci. You heard it here first! Jim ================================================================================ Note 133.2 [RSX]Virtual Disk Trouble in New version of BRU 2 of 4 EISNER::CETRON 7 lines 8-JAN-1988 18:48 -< Oh Gary, where are you? >- -------------------------------------------------------------------------------- re .-1, why? look at Maxwell's new package - it has most all of those things already done. -ed ================================================================================ Note 133.3 [RSX]Virtual Disk Trouble in New version of BRU 3 of 4 EISNER::SIMONS "Paul, Not that CONVEX!" 4 lines 15-APR-1988 09:16 -< I need it bad! >- -------------------------------------------------------------------------------- In the previous note, "Maxwell's new package was mantioned. I work in Southington, CT (south of Hartford) Does anyone who has that package work nearby? I need it bad. (Bad defined as sometime next week.) ================================================================================ Note 133.4 [RSX]Virtual Disk Trouble in New version of BRU 4 of 4 EISNER::MAXWELL "Gary Maxwell" 8 lines 5-MAY-1988 23:18 -< I'm here (sometimes)... >- -------------------------------------------------------------------------------- < In the previous note, "Maxwell's new package was mantioned. < I work in Southington, CT (south of Hartford) Does anyone who < has that package work nearby? I need it bad. (Bad defined as sometime < next week.) If you still need it bad, call me at (415) 329-5618.  ================================================================================ Note 134.0 [RSX]Can you gen D/N E/N from a F/F kit ? 4 replies EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 10 lines 5-JAN-1988 15:26 -------------------------------------------------------------------------------- Can anyone tell me if it is possible to gen a DECNet-RSX11-M+ end-node from a full function distribution kit? I'm going to upgrade all my 11M systems to 11M+ including DECNet (they're all 11/73's). I object to having to buy an H-kit for the end node systems since DEC doesn't want to sell the media separately from the documentation (although you can buy the documentation separately from the media). All my systems are currently properly licensed for 11M and D/N and I intend to buy the H-kit for my F/F node anyway. Can I do it ? ================================================================================ Note 134.1 [RSX]Can you gen D/N E/N from a F/F kit ? 1 of 4 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 3 lines 5-JAN-1988 16:00 -< Shouldn't be a problem. >- -------------------------------------------------------------------------------- From my DECnet distribution notes, it seems that I recall the docs saying that E/N distributions can only be E/Ns, but if you have F/F, you can optionally configure it as E/N if you wish. ================================================================================ Note 134.2 [RSX]Can you gen D/N E/N from a F/F kit ? 2 of 4 EISNER::DELARISCH "Arnold S. De Larisch" 14 lines 5-JAN-1988 20:28 -< No problems Here! >- -------------------------------------------------------------------------------- >> < Note 52.1 by EISNER::TILLMAN "Brian Tillman, Smiths Industries." > >> -< Shouldn't be a problem. >- >> >> From my DECnet distribution notes, it seems that I recall the docs >> saying that E/N distributions can only be E/Ns, but if you have F/F, >> you can optionally configure it as E/N if you wish. Yup, NO PROBLEM! I was sent the Full Function M+ kit and I've genned an End Node from it for about a year and a half! Just make sure to specify that you DO NOT want a Full Function Node. -Arnold ================================================================================ Note 134.3 [RSX]Can you gen D/N E/N from a F/F kit ? 3 of 4 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 1 line 6-JAN-1988 13:07 -< I owe a drink/dinner to someone... >- -------------------------------------------------------------------------------- Thanks, guys, you just saved me about $1,000. ================================================================================ Note 134.4 [RSX]Can you gen D/N E/N from a F/F kit ? 4 of 4 EISNER::FRISBIE "Alan E. Frisbie" 4 lines 6-JAN-1988 22:06 -< Small, unmarked bills will also do >- -------------------------------------------------------------------------------- >> Thanks, guys, you just saved me about $1,000. DECUServe will take its small cut now. Just post your American Express account number and we will do the rest. :-)  ================================================================================ Note 135.0 [RSX]V4.0 SYSGEN on 11/24?*!#? 5 replies EISNER::BOSTWICK 55 lines 7-JAN-1988 18:20 -------------------------------------------------------------------------------- There are probably a few (very few :^} ) people out there masochistic enough to want to do this. For the rest of you, this will just be for amusement's sake... MPLUS V4.0 SYSGEN will fail under the following conditions: Hardware: 11/24 (! <- I suspect any non-I/D system) DH-11 w/modem support ( the culprit) DL-11 w/modem support Software (SYSGEN Options): Standard Function System Character Translation Support (AKA ACD support) Support for network products With the above, TTDRV is *TOO BIG* to takbuild - fails with the good old 'TASK HAS ILLEGAL ADDRESS LIMITS' message. The map shows 82xx. words - yup, that's too big, all right. Further examination of the map reveals all sorts of curious stuff automagically included in TTDRV. Like, both DH and DHV modules, DZ (!?) modules, and LAT support. Whew! Now, maybe the DH and DHV code share pieces or something, but DZ? There are two cures for this (at least). First, you can drop the ACD support. This yields a TTDRV of 79xx. words which will run. The other is to manually go into RSXMC.MAC ('pause to edit before assembling...'), and turn off LAT support. This yields a smaller driver (I forget, something like 72xx. words with ACD support), which also runs. I tried once excluding the DZ code, but the thing wouldn't run. This may be 'cause I just rebuilt TTDRV, rather than the whole SYSGEN (lazy). Or, the system may really need something from the DZ code. Note that there are NO DZ's specified for the system! There is a comment in RSXMC that "DZ always included in MPLUS"), (one for LAT, too)... I wonder how many people take the standard system and don't realize that they're getting a couple of K of LAT code that most will never use? Maybe nobody cares anymore with memory as cheap as it is. Anyway, it appears that, for an 11/24 (probably any non-I/D system), you can have any 2 of : [DH, LAT, ACD] support, and that's it. I *KNOW* the first reply is: "Get a reasonable CPU"! Only retort is: "yea, but they're cheap". :^} jim ================================================================================ Note 135.1 [RSX]V4.0 SYSGEN on 11/24?*!#? 1 of 5 EISNER::CETRON 8 lines 8-JAN-1988 18:52 -< ..ah 18bits.... >- -------------------------------------------------------------------------------- actually there are a LOT of logicals that can be dissappeared in the 4.0 kitbuild and fit the whole thing in 18-bits..... more on request..... -ed ================================================================================ Note 135.2 [RSX]V4.0 SYSGEN on 11/24?*!#? 2 of 5 EISNER::BOSTWICK 11 lines 11-JAN-1988 20:01 -< ahem - 22-bit! >- -------------------------------------------------------------------------------- > > ..ah 18bits.... > But Ed, this is *NOT* an 18-bit SYSGEN! The 11/24 in question (and all 11/24's ARE in question :^} ) has the KT-24, 320KW of memory (a lot of it even DEC memory), and in general knows about 22-bit addressing. I did a 'vanilla' (SFS) M+V2.1"E" Gen on it with no hacks whatsoever... jim ================================================================================ Note 135.3 [RSX]V4.0 SYSGEN on 11/24?*!#? 3 of 5 EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 11-JAN-1988 20:53 -< You let Bruce do YOUR dirty work! >- -------------------------------------------------------------------------------- >> < Note 53.2 by EISNER::BOSTWICK > >> -< ahem - 22-bit! >- >> >> > >> > ..ah 18bits.... >> > >> But Ed, this is *NOT* an 18-bit SYSGEN! The 11/24 in question (and >> all 11/24's ARE in question :^} ) has the KT-24, 320KW of memory >> (a lot of it even DEC memory), and in general knows about 22-bit >> addressing. I did a 'vanilla' (SFS) M+V2.1"E" Gen on it with no hacks >> whatsoever... ^^^^^^^^ That MAY be true ... however ... as I understand it you let Bruce Mitchell do your dirty work (hacking) on that poor 11/24! (remember the ACNT HACK???) 8-{))) -Arnold ================================================================================ Note 135.4 [RSX]V4.0 SYSGEN on 11/24?*!#? 4 of 5 EISNER::MCCARTHY 31 lines 12-JAN-1988 15:12 -< Some TTDRV notes >- -------------------------------------------------------------------------------- About the structure of the terminal driver: 1) The driver code is in three psects: MAP5 - Things which must be mapped in APR5. MAP5.6 - Things which can be mapped in either APR 5 or 6. MAP6 - Things which must be mapped in APR6. With the minimal driver, size(MAP5)+size(MAP5.6) < 4K. This means that the APR6 code doesn't wind up in APR6, which means the driver won't work. Since most systems (current systems, not those *&^% antiques) have DZs and/or DHVs and/or LAT, we found the simplest solution to be putting those drivers in unconditionally. Although this causes headaches for certain rabble-rousers with weird configurations, it makes the general case work. 2) TTDRV comes in two pieces on non-I/D RSX-11M-PLUS systems: TTDRV and TTEXT. TTEXT contains the TTATT module. On I/D systems, there is also TTCOM, the data space portion of the driver, like buffers. All of the pieces are interlinked, so they ALL must be rebuilt or the resulting driver probably won't work. Additionally, whenever TTDRV is UNLoaded/LOAded with VMR on an I/D system, TTCOM must be removed and re-installed to trigger the drivers initialization code when the system starts up. -Brian ================================================================================ Note 135.5 [RSX]V4.0 SYSGEN on 11/24?*!#? 5 of 5 EISNER::BOSTWICK 24 lines 19-JAN-1988 18:05 -< A chicken and egg problem... >- -------------------------------------------------------------------------------- >>> addressing. I did a 'vanilla' (SFS) M+V2.1"E" Gen on it with no hacks >>> whatsoever... ^^^^^^^^ >That MAY be true ... however ... as I understand it >you let Bruce Mitchell do your dirty work (hacking) on that >poor 11/24! (remember the ACNT HACK???) 8-{))) At the risk of being superfluous (someone else's title :^} ), it would seem obvious that a running system is required before hacking the acount program. Besides, *I* hacked the thing so it would run out of batch! It's nice we don't have to do such things on V4. Before another goofy flame comes back, I never EVER do anything with the baseline except get it out of the way and on to real RSX ASAP. Once walked into a guy's site who had 5000 files (RM02) in [200,200], had never done a SYSGEN in his life, and wondered if I could help get some of the documented features of RSX to work! Can't stand the sight of the baseline ever since..... jim  ================================================================================ Note 136.0 [RSX]HELP!!! 22 replies EISNER::TILLMAN "Brian Tillman, Smiths Industries." 37 lines 8-JAN-1988 15:07 -------------------------------------------------------------------------------- I'm running a PDP-11/34 under RSX-11M V4.1. This guy's SOLE purpose is to act as a HASP workstation. There aren't even any terminals attached, except for the console. It uses a modified verion of RSX/HASP. This modification was made by a DEC software person in Canada for the Canadian Ministry of Agriculture and we bought it and modified it (at least three years ago) to run on our machine. The modifications basically involve rehosting the console subsystem so it executes on a VAX and talks to the HASP emulation via DECnet. Files returned by HASP are routed back to the VAX. It basically gives people on our VAX a means to submit IBM batch jobs and get their results back. Most of the time it runs well (as well as it can, at least), but once in a while (once a month or less; sometimes more), the FCS (that goes through DECnet to put files on the VAX) crashes with the following information on the console: XX:XX:XX Task "HSPFCS" terminated Memory protection violation R0=000001 R1=040574 R2=037513 R3=000021 R4=000000 R5=003120 SP=001232 PC=170000 PS=170001 I haven't the faintest idea what this info means, nor where I can start looking to even begin to diagnose the problem. I am the system manager of the PDP, so I can't go ask someone else. I did the current sysgen (what a PAIN!), but find some of the process somewhat obscure. Caould this be an intermittent hardware problem? As I said, this thing does the same thing day after day, over and over again: Get a file from the VAX, send it to the IBM, get an answer from the IBM, send it back to the VAX. ================================================================================ Note 136.1 [RSX]HELP!!! 1 of 22 EISNER::CETRON 16 lines 8-JAN-1988 18:58 -< a first order response, more data please? >- -------------------------------------------------------------------------------- A real quick response is that memory protect violation is usually a sign of trying to get to memory that your task is not allowed to access. A VERY common symptom is a subroutine call with the wrong number of parameters which causes a return from subroutine to go to a bizarre, unmapped address. The numbers are the current processes registers, and the pc looks mighty suspicious. IF the code for the 'fcs' is privileged (and that would make sense) and if the 'fcs' is mapped to the I/O page (which would also make sense if it was doing direct I/O rather then using a driver), isn't the task trying to RUN out of the I/O page??? Is there ROM up there? -hmmmm -ed ================================================================================ Note 136.2 [RSX]HELP!!! 2 of 22 EISNER::FRISBIE "Alan E. Frisbie" 17 lines 9-JAN-1988 00:01 -< Still more information needed >- -------------------------------------------------------------------------------- I agree, the PC value looks VERY suspicious. What sources, if any, do you have for this code and/or the HASP code? If I understand correctly, the code that is aborting is the custom code written by DEC to talk DECnet to the VAX. Is that correct? This is a very difficult kind of problem to track down without hands-on access to put in mousetraps, breakpoints, etc. It is almost impossible without source code. Such intermittent failures are usually due to intermittent hardware failures or VERY subtle bugs. My first suggestion is to taskbuild the task with post-mortem dump enabled so that you can get a look at the stack. Alan ================================================================================ Note 136.3 [RSX]HELP!!! 3 of 22 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 23 lines 11-JAN-1988 15:58 -< What do you need to know? >- -------------------------------------------------------------------------------- RE: < Note 54.1 by EISNER::CETRON > -< a first order response, more data please? >- What data do you want? | IF the | code for the 'fcs' is privileged How do I tell? | if the 'fcs' is mapped to the I/O page There is something about I/O page in the code. | isn't the | task trying to RUN out of the I/O page??? How do I tell? | Is there ROM up there? Not that I know of. ================================================================================ Note 136.4 [RSX]HELP!!! 4 of 22 EISNER::MCCARTHY 47 lines 12-JAN-1988 15:36 -------------------------------------------------------------------------------- The 170000 that's in the PC looks suspiciously like a PS value. There aren't that many ways that the user task gets a copy of the PS. There are only three that I can think of: 1) Jumping indirect through the copy of the initial PS that's in the tasks copy of its header. This is highly unlikely. 2) An AST 3) An SST In either of the last two cases a PS is pushed on the stack, often with other parameters which the application must remove before resuming operation prior to the trap. If the code to clean up the stack doesn't work right, it could RTI, ASTX$ or return to the wrong address. An RTI or ASTX$ is unlikely since they would have restored the PS as well, the PS looks healthy and probably wouldn't have received a reasonable value by accident. On investigation I take that back. When an AST occurs, the stack has the following: SP+n+4 - > Saved event flag mask word SP+n+2 - > Saved PS SP+n - > Saved PC SP+n-2 Parameters . . If the AST routine popped off the parameters AND the PC, the stack would be left with the PS and mask word. Let's suppose that the task is waiting for EFN 1,17,33, or 49 when the trap occurs. The saved flag word is a 1, and the exec sets 170000 in the PS on restore to protect itself, resulting in the value 170001, so the PS might look wierd. This can be diagnosed in a PMD by the fact that the tasks DSW may be junk, since it would be restored from junk. Likewise an SST could mung the stack and accidentally leave a 1 under the PS. In this case the hardware sets the 170000 in the PS (An RTI can only set bits in the previous/current mode in the PS). Likely that some error condition mismanages the stack. -Brian ================================================================================ Note 136.5 [RSX]HELP!!! 5 of 22 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 10 lines 12-JAN-1988 16:26 -< Say, what? >- -------------------------------------------------------------------------------- Brian, Most of what you said is pure gobbldegook to me. All those acronyms mean nothing. The question that bothers me most is why, if the code does the same thing over and over successfully, does it glitch just now and then when it's not doing anything different than it usually does. The I/O page is at address 170000 isn't it? Thanks for the help. ================================================================================ Note 136.6 [RSX]HELP!!! 6 of 22 EISNER::FRISBIE "Alan E. Frisbie" 32 lines 12-JAN-1988 22:48 -< Getting tossed into the deep end of the pool >- -------------------------------------------------------------------------------- >> Most of what you said is pure gobbldegook to me. >> All those acronyms mean nothing. If you REALLY want to find out what is causing your problem, you will HAVE to understand them. If you don't understand the concepts of the system you are debugging, you will be wasting your time. (I'm sure that this sounds offensive, but I don't mean it that way. I'm just being blunt.) >> The question that bothers me most is why, if the code >> does the same thing over and over successfully, does it >> glitch just now and then when it's not doing anything >> different than it usually does. Probably because it is taking some kind of an error path that happens only once in a blue moon. After all, this is a communications system and we all know about strange noise bursts. >> The I/O page is at address 170000 isn't it? No. 160000. Seriously, if you don't understand AST's, SST's and all that goes with them, you will be better off finding someone who does to do the debugging. On the other hand, this might be just the time to learn. They are valuable concepts that apply to VMS systems as well as RSX. I would suggest that you start with chapter 2 of the Executive Reference Manual. Alan ================================================================================ Note 136.7 [RSX]HELP!!! 7 of 22 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 8 lines 13-JAN-1988 10:44 -< I'm not quite a total ignoramous >- -------------------------------------------------------------------------------- Well I do know what an AST is and how to use it. My biggest problem is that, while I am familiar with assembly language, the particulars of Macro-11 exscape me. I can't be sure in many cases what a particular segment of code is doing and why, because I don't know some of the mnemonics. No, I remember the command procedure that built the IOPAGE module referencing 170000. I'll check. ================================================================================ Note 136.8 [RSX]HELP!!! 8 of 22 EISNER::CETRON 10 lines 13-JAN-1988 12:39 -< more help, call the Dr. >- -------------------------------------------------------------------------------- Note: this is NOT a solicitation for a job, but, if you would like Brian (tillman), I'd be glad to look at the code for you (though in a somewhat cursory manner) for no charge and make some preliminary recommendations. -ed 801-581-6499 ================================================================================ Note 136.9 [RSX]HELP!!! 9 of 22 EISNER::FRISBIE "Alan E. Frisbie" 26 lines 13-JAN-1988 12:44 -< With foot in mouth, he offers to go for a walk... >- -------------------------------------------------------------------------------- >> -< I'm not quite a total ignoramous >- I didn't mean for it to sound that way. My apologies. >> My biggest problem >> is that, while I am familiar with assembly language, the particulars >> of Macro-11 escape me. I can't be sure in many cases what a particular >> segment of code is doing and why, because I don't know some of the >> mnemonics. If you would like to send me a copy of the source listing (output from the assembler, not the raw source), I would be happy to walk through it with you (no charge). If you don't want to send a large paper listing, you could just send it on any DEC floppy disk (or mag tape) and I can print it here. The more information you include, the better. If it gets too deep, I can refer you to an RSX consultant in your area. Alan Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 (213) 256-2575 ================================================================================ Note 136.10 [RSX]HELP!!! 10 of 22 EISNER::TINKELMAN "Bob Tinkelman - CCA" 28 lines 14-JAN-1988 05:44 -< RSX/HASP code? I'm warning you guys... >- -------------------------------------------------------------------------------- From: < Note 54.8 by EISNER::CETRON > > but, if you would like ... I'd be glad to look at the code for you ... and From: < Note 54.9 by EISNER::FRISBIE "Alan E. Frisbie" > > If you would like to send me a copy of the source listing ... To Ed and Alan and any others tempted (or forced) to look at the RSX/HASP code. Take this as a friendly warning from someone who at one time (years ago) dealt with the code to (1) make it deal simultaneously with multiple remote hosts and later (2) make the result run under 11M-Plus and (3) declined even going to a job interview at DEC for the position of RSX/HASP maintainer: THE CODE IS A BEAR. IT IS TERRIBLE. It does direct device control of the hardware (we use a DQ11) from the same program that does the bisynch protocol handling AND the HASP level logic AND everything else. Forget about clean driver interfaces. Forget about modular programming ... I was told once that the code was originally written as a "stand alone PDP11 program" and then later shoe-horned into an operating system - RSX. I can believe it. I do remember that we fixed a number of bugs related to error recovery from what turned out to be hardware errors on the DQ. The symptoms were busted output files from the IBM host. It took us months to track it down and we weren't even sure it was triggered by bad hardware until we got our second DQ and could point to failures on one DQ and not on the other. At this point, if we had any problems which involved opening up the code, I'd throw out what we have and buy something else - possibly Software Results Q-bus board for our microVAX. ================================================================================ Note 136.11 [RSX]HELP!!! 11 of 22 EISNER::TILLMAN "Brian Tillman, DECUServe MoS" 52 lines 15-AUG-1989 13:16 -< They're bbbaaacccckkkk!!! >- -------------------------------------------------------------------------------- Well, I'm back. The problem I described in .0 cleared up all by itself as the thing's been working well since .0 was posted (January of 88). All of a sudden, things are failing again, mostly with the same problem as in .0 (but with different register contents). The registers for the "memory protection violation" error look like this (there are several instances): R0=000001 R0=000001 R0=000001 R0=000001 R0=000001 R0=000001 R1=036764 R1=036764 R1=040574 R1=036764 R1=036764 R1=040574 R2=036747 R2=100010 R2=040035 R2=122306 R2=036745 R2=040305 R3=000021 R3=000021 R3=000021 R3=000022 R3=000021 R3=000021 R4=000000 R4=000000 R4=000000 R4=000004 R4=000000 R4=000000 R5=003120 R5=003120 R5=003120 R5=003120 R5=003120 R5=003120 SP=001232 SP=001232 SP=001232 SP=001226 SP=001232 SP=001232 PC=170000 PC=170000 PC=170000 PC=170000 PC=170000 PC=170000 PS=170001 PS=170001 PS=170001 PS=170001 PS=170001 PS=170001 R0=000001 R1=040574 R2=040301 R3=000021 R4=000000 R5=003210 SP=001232 PC=170000 PS=170001 In addition to these memory protect violation errors, I also get something called "T-bit trap or BPT execution", with register dumps of: R0=021342 R0=021342 R1=000001 R1=000001 R2=036764 R2=040574 R3=000021 R3=000021 R4=036745 R4=040035 R5=003120 R5=003120 SP=001234 SP=001234 PC=170001 PC=170001 PS=170021 PS=170021 And finally, a "Odd address or other trap four" error, with registers: R0=021342 R1=000001 R2=036764 R3=000021 R4=100010 R5=003120 SP=001234 PC=170001 PS=170004 I can guess what the first error message means (although I don't know what to do about it), but what the heck are the other two errors and do the registers mean anything (what do those registers usually contain)? For example, does one of the registers usually contain a return address after a call, or does one point to an argument list address? Any insight would be *very* appreciated! ================================================================================ Note 136.12 [RSX]HELP!!! 12 of 22 EISNER::WYANT "SOME call me ..... TOM" 111 lines 15-AUG-1989 15:49 -< You asked for it ... >- -------------------------------------------------------------------------------- Well, I guess it's my turn in the barrel. Except for SP, PC, and PS, the meanings of the registers is purely conventional (they *ARE* billed as general-purpose registers), and as I read .10, you can probably count on the conventions *NOT* being followed. That caveat out of the way, let's take a hack at the questions at hand. >>> I can guess what the first error message means (although I don't >>> know what to do about it), but what the heck are the other two >>> errors [?] The PDP-11 has hardware support for debuggers. This comes in two forms: the "T" bit in the PSW (PS for short on your dumps), and the BPT instruction. The "T" bit if set, or the BPT instruction if executed, will cause a hardware trap which would normally be passed off to your debugger. In the absence of a debugger, the operating system performs error recovery by aborting your program. In all the cases of "T-bit or BPT", the T-bit is in fact set. The PS is a 16 bit register, laid out as follows: 170021 (your "T-bit" PS) = 1 111 000 000 010 001: 11 11 0 000 1 0 0 0 1 cc pp g xxx ppp t n z v c ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | +-- Carry bit (set). | | | | | | | | +---- Overflow bit (clear). | | | | | | | +------ Zero bit (clear). | | | | | | +-------- Negative bit (clear). | | | | | +---------- Trace bit (set). | | | | +------------- Processor priority (0). | | | +----------------- Unused (that was easy!) | | +-------------------- General register set (RSX uses 0) | +----------------------- Previous mode = user. +-------------------------- Current mode = user. How did your t-bit get set in the absence of a debugger? Usually it's because some piece of code screwed up the stack. Brian McCarthy's note in this thread covers the main causes of this under RSX. As for the "odd address or other trap 4": this generally means the program has attempted to operate on a word (2 bytes) of data stored at an odd address. Since instructions are words, the PC of 170001 explains this adequately. This error also takes place if you are attempting to access non-existent memory, but in this case I would leave that possibility until later. The bad PC could also be explained by a screwed-up stack. >>> and do the registers mean anything (what do those registers >>> usually contain)? With the original caveat about what registers contain thoroughly in mind: R0 - The FORTRAN calling convention returns function results in this register. I have no idea whether your package uses this convention. FCS passes the FDB address using this register, but I think FCS is not involved here -- the FDB address also has to be even. R1-R3 - Ditto, if required (normally not). R4 - Used by FORTRAN IV for threading code (probably not applicable here). R5 - A widely-used subroutine calling convention uses R5 to point to the argument list. I note that all your errors have the same value in R5. The first word of the argument list is the number of arguments passed; subsequent words are the addresses of the corresponding arguments. SP - Stack storage; typically contains subroutine return addresses, saved PSWs, saved registers, etc. Can also be used by the program any time it wants a few words of storage. PC - Program counter - but your 17000x is probably bogus. PS - Processor status register. Picked apart above. The "C" bit is typically (but NOT universally) set by a subroutine to indicate an error to the caller. >>> For example, does one of the registers usually contain a return >>> address after a call, No, this is not an IBM machine. >>> or does one point to an argument list address? See above discussion and associated caveats. With all this out of the way, what should you do? Well, my "gut feel" is that the symptoms indicate a flakey hardware error condition that is being fielded by even flakeyer software. I have the horrible feeling that you're trying to field interrupts without locking them out in your interrupt handler (your PSs show a CPU priority of zero). Under RSX, it would be nice to switch to kernel mode before locking out interrupts. Do you have any idea what your hardware is doing? Since it may be REAL difficult to get the software straight, you might want to check out your hardware, and make sure it's up to snuff. PS - what's in your machine at address 170000? PPS - if you didn't before, follow up on .1 through .10; they're written by some of the best in the business. ================================================================================ Note 136.13 [RSX]HELP!!! 13 of 22 EISNER::TILLMAN "Brian Tillman, DECUServe MoS" 9 lines 16-AUG-1989 12:00 -< Thanks >- -------------------------------------------------------------------------------- Thanks. In answer to one of your questions, the I/O page (whatever that is) is at 170000. In response to something else you said ("FCS is probably not involved here"), the task that is experiencing these problems is call HSPFCS, and *is* an FCS that uses DECnet to a VAX for its I/O instead of the PDP. By the way, DEC did find one hardware problem (the ribbon cable for the disk drives had some exposed wires rubbing on the cabinet enclosure) and possibly another (a DQ-11 seems bad). He taped the ribbon cable until he can get a new one and has ordered another DQ. ================================================================================ Note 136.14 [RSX]HELP!!! 14 of 22 EISNER::WYANT "SOME call me ..... TOM" 82 lines 17-AUG-1989 10:26 -< NOW we're getting somewhere .. maybe. >- -------------------------------------------------------------------------------- >>> ... the I/O page (whatever that is) is at 170000. ... The PDP-11 (like the VAX and many other minicomputers, but unlike the typical (?) IBM machine) does not have any I/O instructions. Instead, it does "memory-mapped I/O". What this means is that a range of memory addresses is reserved for things that look like memory to the CPU, but are actually I/O controllers. The net effect is that a MOV something,somewhere instruction can have un-obvious consequences (like printing or reading a character, performing a seek, closing a relay, or whatever ...). It's called the "I/O page" on a PDP-11 because it occupies one page of memory (PDP-11 pages are 8KB), at the top of the CPU's 16 bit address space; so normally it covers addresses 160000 (octal) to 177777 (also octal). So 170000 is smack dab in the middle of it (unless you have certain models, like the MINC 11/03 and 11/23, which can be modified to have a a 4KB I/O page starting at 170000). If you divide the number of bytes in the I/O page by the number of interfaces plugged into your machine, you will conclude that either each interface requires a POT LOAD of space, or that the I/O page is mostly empty. The latter is the case - even complex device controllers seldom occupy more than 64 bytes, and the typical terminal multiplexer needs about 8 (DEC doesn't put the port driver on the interface card the way Apple does). The intent of the question "What's at 170000" was: "is there a device controller plugged into the bus at or about that address? or is this an invalid address that nobody has any business touching?". DEC *MAY* be able to tell you the answer to this. A quick (but not entirely safe, in terms of operating system integrity) way to find out is to use the MCR command OPE 170000/KNLD (assuming you're an M+ system) and see if it displays anything. If you're not M+, you'll have to go after the physical address (170000 for machines with 16 bit address capability, 770000 for 18 bit machines, or or 17770000 for 22 bit machines). OPE will report an error if there's nobody home at that address, or report the contents of the address if anything's thare (press at this point to get out without modifying the address). >>> In response to something else you said ("FCS is probably not >>> involved here"), the task that is experiencing these problems is >>> call HSPFCS, and *is* an FCS that uses DECnet to a VAX for its >>> I/O instead of the PDP. The "FCS" I was referring to was "File Control Services", which is one of two record access methods available under RSX (the other being RMS). File Control Services supports ONLY sequential files, and has NO DECnet support. Why is it still around? Because it was there first, and because what it does at all, it does better than RMS (smaller code, faster execution). Was HSPFCS the task that died? I may well have lost context somewhere along the line. My statement "FCS is probably not involved" was based on a "troubleshooter's hunch" - something I'll pursue if I haven't got anything better to go on, but NOT something I take as a serious hypothesis without furthere corroboration. Depending on what the "FCS" in "HSPFCS" really means, I may have to retract the hypothesis. >>> By the way, DEC did find one hardware problem (the ribbon cable >>> for the disk drives had some exposed wires rubbing on the >>> cabinet enclosure) Yukkkk! >>> and possibly another (a DQ-11 seems bad). He taped the ribbon >>> cable until he can get a new one and has ordered another DQ. Also Yukkkk! I'm not terribly into DEC part numbers (he said sheepishly!), but the DQ-11 sounds like the Q-bus equivalent of the DU-11, which would make it a synchronous communications interface. Is this by any chance the device used for your HASP link? If so, it fits right in with the "flakey hardware behaviour being mishandled by flakey software" hypothesis. ================================================================================ Note 136.15 [RSX]HELP!!! 15 of 22 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 13 lines 17-AUG-1989 12:26 -< PC = 1700xx is a red flag >- -------------------------------------------------------------------------------- > PC = 170001 This is a fairly typical value to find in the PSW (Previous and current modes = User, C-bit set), lending weight to the suggestion that the stack got screwed up. Since both the PC and PSW are similar, it would appear that some code was entered with the PC/PSW on the stack, but only popped off the PC. When it returned, this extra word on the stack got used as the PC. Whammi! (A technical term) :-) It may be that your hardware problems are causing the software to execute a code path that is seldom used (and therefore not debugged). Fixing the hardware may just mask the problem. ================================================================================ Note 136.16 [RSX]HELP!!! 16 of 22 EISNER::TILLMAN "Brian Tillman, DECUServe MoS" 7 lines 17-AUG-1989 16:42 -< A mask is good enough to hide behind >- -------------------------------------------------------------------------------- RE: < Note 54.15 by EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" > -< PC = 1700xx is a red flag >- | not debugged). Fixing the hardware may just mask the problem. I'll settle for masked. The silly machine has worked with only minor problems for the better part of five years. ================================================================================ Note 136.17 [RSX]HELP!!! 17 of 22 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 9 lines 17-AUG-1989 18:03 -< DQ-11 is UNIBUS >- -------------------------------------------------------------------------------- > Also Yukkkk! I'm not terribly into DEC part numbers (he said > sheepishly!), but the DQ-11 sounds like the Q-bus equivalent of > the DU-11, which would make it a synchronous communications > interface. DQ-11 is an early (it has its own backplane) DMA (its manual of that era says NPR) UNIBUS sync device that came in a variety of flavors. Dec's RJE HASP does support it. ================================================================================ Note 136.18 [RSX]HELP!!! 18 of 22 EISNER::TILLMAN "Brian Tillman, DECUServe MoS" 2 lines 18-AUG-1989 15:23 -< I'm going to start digging in the software soon. Yuck! >- -------------------------------------------------------------------------------- What we're using is a modified version of DEC's RJE HASP. The differenc is that its console and file access are to a VAX over DECnet. ================================================================================ Note 136.19 [RSX]HELP!!! 19 of 22 EISNER::RICE "Gary Rice" 9 lines 20-AUG-1989 10:09 -------------------------------------------------------------------------------- > What we're using is a modified version of DEC's RJE HASP. The differenc > is that its console and file access are to a VAX over DECnet. Good Luck. I lived thru a year of suffering using the HASP product (in it's natural pristine state) over a DUP-11 circuit. It was hard enough to figure out in it's "supported" version. Gary ================================================================================ Note 136.20 [RSX]HELP!!! 20 of 22 EISNER::GLEASON "CyberPunk" 15 lines 22-AUG-1989 00:52 -< I remember only good things about it >- -------------------------------------------------------------------------------- Hmmm...At one of my sites, the RSX HASP product performed so well, so long, that we sorely missed it when we moved the RJE link to a VAX and used an early version of VMS 2780/3780. The fact that sources were included made it eay to customize the user interface to do exactly what we needed, as well. It was also the earliest reference I have seen to the "TANK" data structure that you still see referenced in the VMS terminal driver code. The only problem we had with the RSX link to the mainframe occurred when the DQ-11 failed. The system was maintained by a 3rd party CAD vendor, and their maintenance tech mis-identified the option as a DH-11...and started swapping boards ... ================================================================================ Note 136.21 [RSX]HELP!!! 21 of 22 EISNER::WYANT "SOME call me ..... TOM" 11 lines 22-AUG-1989 14:49 -< Ooooops! >- -------------------------------------------------------------------------------- >>> > Also Yukkkk! I'm not terribly into DEC part numbers (he said >>> > sheepishly!), but the DQ-11 sounds like the Q-bus equivalent of the >>> > DU-11, which would make it a synchronous communications interface. >>> DQ-11 is an early (it has its own backplane) DMA (its manual of that >>> era says NPR) UNIBUS sync device that came in a variety of flavors. >>> Dec's RJE HASP does support it. Thanks, Barton! I never let ignorance of a subject prevent me from expressing an opinion on it. Guess I was thinking of a DUV-11 (??). ================================================================================ Note 136.22 [RSX]HELP!!! 22 of 22 EISNER::TILLMAN "Brian Tillman, DECUServe MoS" 21 lines 22-AUG-1989 16:55 -< Solution reached >- -------------------------------------------------------------------------------- Call this topic closed. After digging around today, I discovered what was going wrong. I noticed that not everyone was having problems getting jobs back, just those jobs that were really being printed (as opposed to being routed to a disk file). The problem was that the printer to which the jobs were being queued had an incorrectlt specified associated queue. In other words, someone on the VAX side had said: $ set device/spooled lca0 instead of: $ set device/spooled=sys$print lca0 Files that are to be printed instead of placed on disk are written directly to the printer device (a Fortran open specifying LCA0 as the file name). When the remote software tried to close the "file", the job controller tried to queue it to a nonexistent queue. Once I reset the queue name properly, all worked as before. Thanks for all the suggestions.  ================================================================================ Note 137.0 [RSX]Need 'C' compiler ordering help... 7 replies EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 7 lines 19-JAN-1988 13:58 -------------------------------------------------------------------------------- OK, I give up. I've checked with DECDirect, my local office, and everyone else I can think of, but no results. Is there a DEC supported 'C' compiler (no, I don't want to use the DECUS 'C' compiler). If there is one, where can I get information on it (ie; order numbers, SPD, etc) ? ================================================================================ Note 137.1 [RSX]Need 'C' compiler ordering help... 1 of 7 EISNER::DELARISCH "Arnold S. De Larisch" 24 lines 19-JAN-1988 14:56 -< No DEC RSX C but Whitesmiths has one! >- -------------------------------------------------------------------------------- >> < Note 55.0 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Need 'C' compiler ordering help... >- >> OK, I give up. I've checked with DECDirect, my local office, >> and everyone else I can think of, but no results. Is there a DEC >> supported 'C' compiler (no, I don't want to use the DECUS 'C' >> compiler). If there is one, where can I get information on it (ie; >> order numbers, SPD, etc) ? To the best of my knowledge, there is no DEC 'C' compiler available yet! If you want a commercial C compiler for RSX-11M+, I would suggest looking at Whitesmith's 'C' compiler for RSX11M+ Version 3.x. We've got it here, its got a few bugs ... and there installation command file stinks, but its a WHOLE lot better than DECUS C. There is an interactive DEBUGGER, Many different flavors of C Libraries, etc. The compiler requires an I/D space machine to run. You can, however, have it build code for a non-I/D space machine. I would talk to them about it. -Arnold ================================================================================ Note 137.2 [RSX]Need 'C' compiler ordering help... 2 of 7 EISNER::KENNEDY "Terry Kennedy" 5 lines 19-JAN-1988 15:02 -< Larcenous beasties, those folks... >- -------------------------------------------------------------------------------- > If you want a commercial C compiler for RSX-11M+, I would suggest > looking at Whitesmith's 'C' compiler for RSX11M+ Version 3.x. Do they still make you pay 3/4 full list price for an update that doesn't even fix their bugs? ================================================================================ Note 137.3 [RSX]Need 'C' compiler ordering help... 3 of 7 EISNER::CETRON 7 lines 19-JAN-1988 16:34 -< patience... >- -------------------------------------------------------------------------------- re: dec 'standard' pdp c - dec sort of, more or less, maybe kinda implied at the last symposia that it was in house under development but never really came right out and made a formal announcement. -ed ================================================================================ Note 137.4 [RSX]Need 'C' compiler ordering help... 4 of 7 EISNER::NORTON 4 lines 19-JAN-1988 16:58 -< Seems like a lot for what you get... >- -------------------------------------------------------------------------------- Whitesmiths charged us $2K for an M+ compiler, and now wants $500 for the maintenance contract. For this we get patches, a newsletter, and 50% off new releases. Such a deal. 8-( ================================================================================ Note 137.5 [RSX]Need 'C' compiler ordering help... 5 of 7 EISNER::ROBITAILLE "Mike Robitaille" 10 lines 19-JAN-1988 20:29 -< They've been more or less and maybe for a while... >- -------------------------------------------------------------------------------- Re Note 55.3: I distinctly recall that about three symposia ago, the DEC IAS developer folks said that they were using a pdp c (not DECUS C) for various "throwaway" coding requirements. I think the real logjam is that DEC is unsure whether they really want to go through the hassles of announcing, supporting, and etc. a product that may not really have that great a demand... If you want the thing, I respectfully submit that you are going to have to push for it - and push hard! ================================================================================ Note 137.6 [RSX]Need 'C' compiler ordering help... 6 of 7 EISNER::MCCARTHY 15 lines 25-JAN-1988 16:03 -< An official non-reply >- -------------------------------------------------------------------------------- > I distinctly recall that about three symposia ago, the DEC IAS developer > folks said that they were using a pdp c (not DECUS C) for various > "throwaway" coding requirements. I think the real logjam is that DEC is > unsure whether they really want to go through the hassles of announcing, > supporting, and etc. a product that may not really have that great > a demand... > If you want the thing, I respectfully submit that you are going to > have to push for it - and push hard! I of course can't comment on whether we are or aren't producing a C compiler, but whatever one IAS was using is not the one that is or isn't under development. -Brian ================================================================================ Note 137.7 [RSX]Need 'C' compiler ordering help... 7 of 7 EISNER::WYANT "Tom Wyant" 8 lines 10-NOV-1988 16:34 -< Shades of C. Matco ... >- -------------------------------------------------------------------------------- >>> I of course can't comment on whether we are or aren't producing a >>> C compiler, .... I believe that at this fall's symposium, a DECcie in one of the L&T sessions was collecting business cards from people who might want to field test a hypothetical PDP-11 "C" compiler that DEC may or may not be working on.  ================================================================================ Note 138.0 [RSX]Problem with Whitesmiths C 7 replies EISNER::NORTON 25 lines 20-JAN-1988 16:48 -------------------------------------------------------------------------------- We're trying to use Whitesmiths C compiler V3.2 for M+ to call FORTRAN subroutines that do WRITE statements. I've discovered why programs blow up inside the WRITES - Whitesmiths uses names like $OPEN, $CLOSE, etc. in *their* runtime system too. So the FORTRAN OTS call to $OPEN from inside $INITIO ends up getting the wrong thing. Has anyone come up with a workaround for this problem? And besides... *FLAME ON* What sort of company is Whitesmiths that they ignore long-term, well-publicized DEC standards that say "$ is reserved for DEC"? Do they want lots of DEC users to buy their stuff or not? Is this conflict intentional to keep us from mixing icky old FORTRAN with their wonderful new language? Do they figure we're all going to convert our *tested* FORTRAN routines to C just to fix this? Thanks, I needed that. *FLAME OFF* ================================================================================ Note 138.1 [RSX]Problem with Whitesmiths C 1 of 7 EISNER::FRISBIE "Alan E. Frisbie" 12 lines 20-JAN-1988 22:59 -< Can't mix and match >- -------------------------------------------------------------------------------- >> What sort of company is Whitesmiths that they ignore long-term, >> well-publicized DEC standards that say "$ is reserved for DEC"? >> Do they want lots of DEC users to buy their stuff or not? >> Is this conflict intentional to keep us from mixing icky old >> FORTRAN with their wonderful new language? Have you ever tried mixing more than one DEC-supported PDP-11 language? You will have the same problem. When the VAX came along, DEC used that as an opportunity to standardize. Alan ================================================================================ Note 138.2 [RSX]Problem with Whitesmiths C 2 of 7 EISNER::KENNEDY "Terry Kennedy" 15 lines 20-JAN-1988 23:03 -< Attitudes >- -------------------------------------------------------------------------------- > What sort of company is Whitesmiths that they ignore long-term, > well-publicized DEC standards... Back in the late 70's I worked for Whitesmith's only distributor (in a technical support position). As such, I had many occasions to talk to them about their product. Whitsmiths is (was?) created by Plaugher (of Kernighan and...). This person has a mindset of 'this is the way I did it, so this must be the [only] right way...' Whitesmith's generates numerous examples of this - The no-update update policy as well as your problem come to mind. Also, there is the classic 'Whitesmith's craftsmans sticker', which is a sticker you put on your system to prove (to who, the computer?) that you are licensed to run the product. The funniest thing about that gag was that a Chiquita banana sticker stays on better and looks nicer... ================================================================================ Note 138.3 [RSX]Problem with Whitesmiths C 3 of 7 EISNER::FRISBIE "Alan E. Frisbie" 4 lines 21-JAN-1988 14:00 -< Whitesmith's Craftsmans sticker >- -------------------------------------------------------------------------------- >> The funniest thing about that gag was that a >> Chiquita banana sticker stays on better and looks nicer... Which one stuck better to a banana? :-) ================================================================================ Note 138.4 [RSX]Problem with Whitesmiths C 4 of 7 EISNER::NORTON 2 lines 21-JAN-1988 14:39 -< wait, there's more... >- -------------------------------------------------------------------------------- Whitesmiths claims that the ANSI standard for C requires them to use names for library routines like $OPEN. How likely is this? ================================================================================ Note 138.5 [RSX]Problem with Whitesmiths C 5 of 7 EISNER::KENNEDY "Terry Kennedy" 4 lines 21-JAN-1988 19:28 -< Har! >- -------------------------------------------------------------------------------- I think ANSI proposed underscore, not $. Also, with the symbol length restriction in TKB, they can't be compliant on the longer names, any- way. ================================================================================ Note 138.6 [RSX]Problem with Whitesmiths C 6 of 7 EISNER::DELARISCH "Arnold S. De Larisch" 14 lines 21-JAN-1988 22:07 -< RAD 50 has no underscore Character! >- -------------------------------------------------------------------------------- >> < Note 56.5 by EISNER::KENNEDY "Terry Kennedy" > >> -< Har! >- >> >> I think ANSI proposed underscore, not $. Also, with the symbol length >> restriction in TKB, they can't be compliant on the longer names, any- >> way. I think Whitesmith did a SUB/_/$/WH on all the sources. They were indicating that the underscore is NOT a RAD50 character ... hence ... since all module names have to be in RAD50 ... they didn't have a whole lot of choice! -Arnold ================================================================================ Note 138.7 [RSX]Problem with Whitesmiths C 7 of 7 EISNER::KENNEDY "Terry Kennedy" 7 lines 22-JAN-1988 00:51 -< Exactly! >- -------------------------------------------------------------------------------- > I think Whitesmith did a SUB/_/$/WH on all the sources. They were > indicating that the underscore is NOT a RAD50 character ... hence ... > since all module names have to be in RAD50 ... they didn't have a > whole lot of choice! Exactly the point! Since they can't be compliant, why pick something that causes problems?  ================================================================================ Note 143.0 [RT11]Using Ethernet with TSX+ 2 replies EISNER::KOZAM 22 lines 29-JAN-1988 02:44 -------------------------------------------------------------------------------- Is anyone out there using Ethernet with TSX+? Home brew software or prepackaged? How does it work/is it worth the cost? I'm particularly interested in the following: 1. DECnet compatability 2. Ability to have diskless TSX+ systems, possibly getting data from another TSX+ system or (even better) a VMS system. 3. LAT for terminals using TSX+ (reverse-LAT doesn't count!) I know people do #1, but don't know about vendors or performance. I think #2 should be possible, but would require a special bootable ethernet handler (and type-in bootstrap'), plus "server" software for whatever system will be supplying disk blocks. I suspect that #3 is impossible, due to the fact that TSX+ keeps terminal handling code well inside the system. Marc Kozam ================================================================================ Note 143.1 [RT11]Using Ethernet with TSX+ 1 of 2 EISNER::CAMPBELL 25 lines 22-APR-1989 14:31 -< Some options >- -------------------------------------------------------------------------------- > 1. DECnet compatability As far as I know, there is no DECnet compatible software for TSX+. Even the RT-11 product (which I think has been retired) is/was relatively useless in a modern network environment. > 2. Ability to have diskless TSX+ systems, possibly getting > data from another TSX+ system or (even better) a VMS system. There are several vendors that provide "remote disk" service over Ethernet to RT-11 and TSX+ nodes. The ones I can think of are Etherdisk from Omnex and TPserve from Hammondsoftware (through Serdula International in Ontario). A third one is called Iranet, but I can't remember the name of the company (in Santa Monica, CA) makes it. Process Software has a TCP/IP product for RT-11 and TSX+. > 3. LAT for terminals using TSX+ (reverse-LAT doesn't count!) > > ... I suspect that #3 is > impossible, due to the fact that TSX+ keeps terminal handling code well > inside the system. Actually,the hard part here is probably the LAT protocol (of which I know nothing). While not supported by S&H, pretending to be a TSX+ terminal with foreign equipment is do-able. ================================================================================ Note 143.2 [RT11]Using Ethernet with TSX+ 2 of 2 EISNER::BILLING 8 lines 24-JUL-1989 14:29 -< Using Ethernet with TSX+ and TCP/IP >- -------------------------------------------------------------------------------- Marc, See RT note 14 where similar questions are being asked specifically about TCP/IP Ethernet software. Something I forgot to mention there about the FTP package is that it is DECnet compatible. You have to see Process Software for information. Also I didn't mention there, but I think EtherNet/EtherDisk products are TSX+ compatible.  ================================================================================ Note 144.0 [RT11]v5.4 LS: won't work with DLV11-E No replies EISNER::FRISBIE "Alan E. Frisbie" 10 lines 29-JAN-1988 12:09 -------------------------------------------------------------------------------- I am having a problem with the RT-11 v5.4 (no update) LS: handler. I was given a possible fix at the European DECUS symposium in Rome, but have since lost it. Under v5.2, I can use the LS: handler with a DLV11-E serial board and have no problems. Under v5.4, I can't even INStall the handler. Anyone know what the problem is and if it is fixed in an update? Is there a patch for it? Alan  ================================================================================ Note 145.0 [RSX]User subs in TKTN 5 replies EISNER::SIMONS "Paul G. Simons" 5 lines 29-JAN-1988 15:13 -------------------------------------------------------------------------------- We are working with a vendor who is upgrading our AGC/SCADA system to work on M+ V4.0. They claim that they have to modify TKTN in order to trap ALL task failures (Ex: Stack abort with pending SST). This info iccescessary to determine if a failover to the standby system should be initiated. Could this really be true? ================================================================================ Note 145.1 [RSX]User subs in TKTN 1 of 5 EISNER::CETRON 5 lines 30-JAN-1988 17:16 -< and now, a toughie - time out for the fiche >- -------------------------------------------------------------------------------- I thought that tktn caught almost.... hmmm....time to read the sources.... -ed ================================================================================ Note 145.2 [RSX]User subs in TKTN 2 of 5 EISNER::MCCARTHY 9 lines 3-FEB-1988 17:54 -------------------------------------------------------------------------------- What they are referring to is the fact that there is no way in the application to trap some failures, such as bad stack detected during an attempt to delived an SST to the task. Yes, it is true. In a debugged application, this will catch some tiny fraction of possible hardware problems. -Brian ================================================================================ Note 145.4 [RSX]User subs in TKTN 4 of 5 EISNER::SIMONS "Paul, Not that CONVEX!" 12 lines 6-FEB-1988 18:27 -< A Better Explanation? >- -------------------------------------------------------------------------------- The application they are providing us with could be called an "Error Server". It consists of two tasks. The one task issues a CINT$ directive and loads some code into DSR that intercepts illegal instruction traps and checks for a particular opcode. If it finds it then it uses the ITB from the CINT$ to get to the ISR. The ISR collects pertinant data from the erroring task, decides the erroring tasks fate, and queues an AST to the second task. The second task takes the info off its stack and uses it to build an english error message. All this is well and good, but it has a hole in it. The hole is that it doesn't trap and report errors that originate in the Exec. It appears that, short of modifing TKTN, ALL errors cannot be sensed. I hope this makes the question clearer. ================================================================================ Note 145.5 [RSX]User subs in TKTN 5 of 5 EISNER::SIMONS "Paul, Not that CONVEX!" 3 lines 29-MAR-1988 21:04 -< The jaws are closing.. >- -------------------------------------------------------------------------------- The time of arrival is at hand... I humbly petition any thoughts on the previous note, else we will have to live with (sob) a modified exec (horrors!).  ================================================================================ Note 146.0 [PRO300]RX33 on a PRO? 2 replies EISNER::RICE "Gary Rice" 10 lines 30-JAN-1988 10:05 -------------------------------------------------------------------------------- For some time, I have been curious as to WHY the PRO is GEN'd for 4 floppy drives. Is is possible to add another RX50 controller and another RX50 box? Or better yet, Add an RX50 controller and plug in an RX33 box? Also, Virtual Microsystems is no longer selling the MS-DOS bridge that came with new ROMs for the RX50. (You know the ones that let the RX50 read IBM-PC format). Do you know if these ROMs are available from ANY other source? Gary ================================================================================ Note 146.1 [PRO300]RX33 on a PRO? 1 of 2 EISNER::LEDERMAN "Bart Z. Lederman" 10 lines 30-JAN-1988 16:39 -< Remnent of the 325? >- -------------------------------------------------------------------------------- My guess as to why the PRO comes genned for 4 floppies is that I'm fairly certain I recall seeing an early PRO-325 equipped with 4 floppies (two in the normal location and two where the hard disk would go on a 350). I also recall a floppy disk only version of P/OS a log time ago (V1.7?) which wasn't much use because it didn't know about hard disks so it couldn't be used for thinks like hard disk backup. (Does anyone still run PCs on floppy disk only, changing diskettes everytime you change programs and/or files?) I -think- the PRO controller can handle 4 floppy drives, if you moved the hard disk out into an expander box. ================================================================================ Note 146.2 [PRO300]RX33 on a PRO? 2 of 2 EISNER::ETHINGTON "Superior Klingon Technology" 27 lines 3-FEB-1988 00:15 -< Alas, poor RX50 Controller... >- -------------------------------------------------------------------------------- P/OS WILL support 4 floppies - I think the controller might be too dumb to handle both drives so you might need a second controller, but all the code is in place to handle it. It's actually not too stupid a thing to wish to do in a Pro/Cluster (read Pro/Server) environment where you don't really need a hard disk for much. Sadly the idiot RX50 controller will not push an RX33. I was told that the microprocessor is too slow to handle the transfer rate, since the RX33 does NOT do sector interleaving on 1.2 MB formatted floppies and would therefore have double the transfer rate - I'm not sure I buy this story, but that is what I was told. For sure, though, it would take a new ROM chip to tell the idiot controller how to handle switching densities and formatting and stuff, as well as new support code in the DZ: driver. The RX33 at 1.2 MB would actually make something near a nice backup device for Pros (speaking as someone who last week backed up his RD53 to 136 floppies - geez, I gotta order me one of the Cipher tape backup drives.....) The only way I know of getting the current (microcode level 10) rom chip for the RX50 controller is through field service. I don't know the part number to just order the thing - if you are on good terms with field circus, you can make them research it for you. All replacement RX50 controllers they dish out are SUPPOSED to have the level 10 rom - you might get them to replace the whole board if you are so inclined and they are agreeable. Jerry  ================================================================================ Note 147.0 [RT11]Need RT-11 PORTACALC... 1 reply EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 8 lines 1-FEB-1988 13:21 -------------------------------------------------------------------------------- Anyone know if there is an RT-11 version of Glenn Everhart's PORTACALC ? If there is, where could I find it. I have a copy of all the SIG tapes ever made (I think). Bob ================================================================================ Note 147.1 [RT11]Need RT-11 PORTACALC... 1 of 1 EISNER::HAHN 2 lines 1-FEB-1988 15:56 -------------------------------------------------------------------------------- As far as I know it only works under RSX for the PDP-11 however send a note to Glenn on DCS. Pierre  ================================================================================ Note 148.0 [RSX]Wanted: 11M Minus Help 2 replies EISNER::ETHINGTON "Superior Klingon Technology" 34 lines 3-FEB-1988 00:26 -------------------------------------------------------------------------------- I need help defogging ancient memories of 11M (not M+) systems, since I haven't touched one in over 5 years and no longer have any documentation or anything. How is UCB online/offline handled on 11M device drivers? I vaguely recall that 11M uses the powerfail entry point, but I don't remember whether the driver itself flips the US.OFL bit or LOA flips it or what. The objective is: I am doing some modernization work on the network virtual device package sources that were submitted to the SIG tape back in 1980. One of the changes I am making is to have the driver resist being unloaded when a unit is still connected to a remote system - make you VDV DISCONNECT VDn:, before unloading the driver. Needless to say, if you unload and then disconnect some VERY unpleasant things might happen. I certainly know how to do this for 11M+ and P/OS families, but don't remember enough 11M to keep from breaking the 11M conditional code, and I have no way to test on 11M. Does the driver data base contain US.OFL on? If so, does LOA clear it? Does the driver clear it? What determines which units to bring online (for instance, if you had a database genned for 4 RL02s and boot or load on a system with 2 RL02s, what code determines NOT to set online the non-existent drives?)? And, at UNL time, what reasserts US.OFL? The driver? If it is the driver, and I do NOT set US.OFL because the DECnet link is still up, will UNL just give a nice bitch message and give up (hopefully)? Hope someone out there remembers enough 11Mspeak to answer this stuff. I'd like to not break the 11M code for the resubmission of the network stuff to the sig tape if at all possible. "Thank you for your support"..... Jerry ================================================================================ Note 148.1 [RSX]Wanted: 11M Minus Help 1 of 2 EISNER::MCCARTHY 6 lines 3-FEB-1988 18:02 -------------------------------------------------------------------------------- Save (or LOA, I believe) sets the device online if the CSR exists. The only knowledge of individual units is for disks, etc, which SAVe knows how to size. -Brian ================================================================================ Note 148.2 [RSX]Wanted: 11M Minus Help 2 of 2 EISNER::ETHINGTON "Superior Klingon Technology" 11 lines 4-FEB-1988 00:32 -< The fogs lift..... >- -------------------------------------------------------------------------------- Ah! Then, assuming we are talking about a driver such as VD: that is loaded via LOA as opposed to VMR, and it has no CSRs, being a sort of metaphysical device, LOA on 11M would cheerfully online all units? And conversely, when UNLoading, UNL offlines everything without looking at anything? Therefore, there is no way for a strange metaphysical device driver to tell UNL to forget it, jack, I don't WANNA go offline? (Sure makes coding simple.....if it can't be done on 11M, geez, won't take any time at all to write code that can't be done.....) Jerry ;^)  ================================================================================ Note 149.0 [RT11]What about some Controversy! 14 replies EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 4-FEB-1988 19:40 -------------------------------------------------------------------------------- O.k ... I see we have started off this conference to a slow ... but steady pace. I've got a question for all the RT-11 Folk. Since DEC has said VAXELN is the ONLY answer (must have been a very stupid question 8-{) ) to REAL TIME on a VAX ... do you think that this provides a Universal solution for YOUR problems? Will you be migrating all of your RT-11 systems to keep pace with DEC and the 32-Bit world? Will S&H's RT-32 program announcment take care of your 32-Bit needs? Inquiring minds want to know! -Arnold P.S. Did anyone get to go to the RT-32 BOF (Birds of a Feather) talk at the Anaheim Symposium??? ================================================================================ Note 149.1 [RT11]What about some Controversy! 1 of 14 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 5 lines 5-FEB-1988 12:29 -< Real-time on a VAX is like speeding in a VW >- -------------------------------------------------------------------------------- Would someone enlighten me about what/who S&H are and what their RT-32 program is all about? I have missed most of the BOF's about RT-32 since DEC announced that it wasn't persuing it. ================================================================================ Note 149.2 [RT11]What about some Controversy! 2 of 14 EISNER::DELARISCH "Arnold S. De Larisch" 17 lines 5-FEB-1988 17:33 -< The TSX People! >- -------------------------------------------------------------------------------- >> < Note 8.1 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Real-time on a VAX is like speeding in a VW >- >> Would someone enlighten me about what/who S&H are and what their >> RT-32 program is all about? I have missed most of the BOF's about >> RT-32 since DEC announced that it wasn't persuing it. S&H are the company who produces the TSX product. TSX, as I understand it, is a multi user version of RT-11. They got interested in the RT-32 project when DEC said "NO WAY". That's all I know about it ... anyone else have info??? -Arnold ================================================================================ Note 149.3 [RT11]What about some Controversy! 3 of 14 EISNER::KILLEEN "Jeff Killeen" 4 lines 5-FEB-1988 18:08 -< STANDARD NOTE 101 >- -------------------------------------------------------------------------------- Just in case there is someone on this system who is associated S&H please read the commercialism gudeline that is posted in the DECUServe information conference. Please also be advised that you can comment under that guideline. ================================================================================ Note 149.4 [RT11]What about some Controversy! 4 of 14 EISNER::FORBES "Bill Forbes - DAARC SIG Counterpart" 19 lines 9-FEB-1988 15:39 -< What about VMS? >- -------------------------------------------------------------------------------- Re: .0 > Since DEC has said VAXELN is the ONLY answer (must have been a very > stupid question 8-{) ) to REAL TIME on a VAX ... For the record, DEC (and many of it's customers) believes that VMS is a viable, indeed excellent, answer to realtime on a VAX, for certain realtime applications. That's what VAXlab is all about. That's what VAX/VMS-based flight simulators and other HPRT applications are all about. VAXELN is a superior realtime operating environment in many respects and forms an important part of DEC's realtime strategy. However, it is not "...the ONLY answer..." Bill Forbes Laboratory Data Products Group DAARC SIG Counterpart ================================================================================ Note 149.5 [RT11]What about some Controversy! 5 of 14 EISNER::CETRON 18 lines 10-FEB-1988 00:14 -< Why push the vax? >- -------------------------------------------------------------------------------- re: .-1 Okay, if VAXELN is not the "...ONLY..." answer, what are the others? VMS is just plain too big for small quick and dirty applications, and sometimes operating system isn't even considered since 32bits and the cost of the system is well beyond what is needed. Doesn't anyone in digital remember the PDP-11??? You know, the business group within digital the size of coors beer was it? All we here is vax vax vax and I STILL can buy a MINC for 5K which can outperform the vaxlab at 40K in terms of ease of use, size, low overhead and speed up to 6Khz sampling, and with new dma boards could compete right up to 200Khz. -ed ================================================================================ Note 149.6 [RT11]What about some Controversy! 6 of 14 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 1 line 10-FEB-1988 13:21 -< Here, here...I agree... >- -------------------------------------------------------------------------------- ================================================================================ Note 149.7 [RT11]What about some Controversy! 7 of 14 EISNER::DELARISCH "Arnold S. De Larisch" 0 lines 10-FEB-1988 21:34 -< Me Three!!! >- -------------------------------------------------------------------------------- ================================================================================ Note 149.8 [RT11]What about some Controversy! 8 of 14 EISNER::MCALLISTER "Brian McAllister" 7 lines 11-FEB-1988 18:58 -< Does ELN roll over and play dead? >- -------------------------------------------------------------------------------- Question for someone who knows VAXeln: Is it as cheerful as RT-11 when you try to throw it away so your program can have the machine to itself? What about stealing vectors and putting them back later? ================================================================================ Note 149.9 [RT11]What about some Controversy! 9 of 14 EISNER::CAMPBELL 23 lines 22-APR-1989 14:44 -< Not with S&H, but know something >- -------------------------------------------------------------------------------- > Would someone enlighten me about what/who S&H are and what their > RT-32 program is all about? I have missed most of the BOF's about > RT-32 since DEC announced that it wasn't persuing it. As another note says, S&H are the makers of TSX+, which essentially provides multiple RT-11 background job environments on a single PDP-11. TSX+ includes a lot of extra "nice" things not found in basic RT-11. S&H has been working on what they call "TSX-32" for a long time, it is just recently entered field test for the first time. While S&H originally thought that TSX-32 would be VAX based, for various reasons they have implemented it for Intel 80386 based systesm (specifically the high-end IBM PS/2 and one or two others). While S&H has said that TSX-32 might be ported to other 32-bit machines at some point, it seems likely that either they will be successful with the '386 version, and therefore too busy to port, or they will be unsuccessful, and therefore too poor. While TSX-32 is supposed to include the real-time features of TSX+, of which there are some nice ones. Given the target machine, it may not be a good upgrade path, since it involves changing hardware, development tools, controllers and operating system vendors. ================================================================================ Note 149.10 [RT11]What about some Controversy! 10 of 14 EISNER::KOZAM 10 lines 22-APR-1989 21:54 -< S & H Wisely Goes 80386 >- -------------------------------------------------------------------------------- > S&H originally thought that TSX-32 would be VAX based, for various > reasons they have implemented it for Intel 80386 based systems I think this is a good decision. Dollar for dollar, 80386 based products seem to be far more cost effective than VAX based product, unless you're held hostage by VMS. Now, I'd be really excited to see a Q-bus based 80386 board that ran TSX-32! (I recall some 86000 based products for the Q-bus, so this isn't so outrageous.) ================================================================================ Note 149.11 [RT11]What about some Controversy! 11 of 14 EISNER::KENNEDY "Terry Kennedy" 15 lines 23-APR-1989 20:57 -< Comments on 386 systems >- -------------------------------------------------------------------------------- |> S&H originally thought that TSX-32 would be VAX based, for various |> reasons they have implemented it for Intel 80386 based systems Well, when you're playing 'bet the company' you have to take a long look at the pros and cons of your alternatives. The 386 does give them the ability to sell a *lot* of power at very low cost. > I think this is a good decision. Dollar for dollar, 80386 > based products seem to be far more cost effective than VAX based product, > unless you're held hostage by VMS. Having just come back from a 2-day trip to a major computer show, I can agree. A 386 motherboard with 1 Mb included, at 16 Mhz, was selling for $675 qty 1. Add a case, power supply for $100 more. Items like EPROM/PAL programmers sell for $70-$200. What more could you ask for? ================================================================================ Note 149.12 [RT11]What about some Controversy! 12 of 14 EISNER::CROWELL "Shefth of the Fourth Order" 11 lines 24-APR-1989 10:32 -< Don't hold your breath >- -------------------------------------------------------------------------------- > While > S&H has said that TSX-32 might be ported to other 32-bit machines > at some point... I'd be very much surprised if S&H port their TSX-32 to anything once they've got it going on the PS2. They probably aren't as interested as you and I, Milt, in the real-time characteristics. Most of S&H's business is in the business/office-automation world. It would take a strong marketing message with visions of lots of sales to get them to port TSX-32 event to a Q-bus (or better yet, VMS bus) 80386 system. ================================================================================ Note 149.13 [RT11]What about some Controversy! 13 of 14 EISNER::CAMPBELL 14 lines 29-APR-1989 19:35 -< Continuing to breath >- -------------------------------------------------------------------------------- > I'd be very much surprised if S&H port their TSX-32 to anything once > they've got it going on the PS2. They probably aren't as interested > as you and I, Milt, in the real-time characteristics. Most of S&H's > business is in the business/office-automation world. It would > take a strong marketing message with visions of lots of sales to > get them to port TSX-32 event to a Q-bus (or better yet, VMS bus) > 80386 system. I agree completely. But that is why TSX-32 may not be a potential place for RT-11 users to go. While I think it could be an upgrade path from TSX+, I have not yet figured out how to tell a current TSX+ customer that I want to change *everything* (hardware & software) just so I can upgrade him to TSX-32. Lacks a certain credibility. ================================================================================ Note 149.14 [RT11]What about some Controversy! 14 of 14 EISNER::KOZAM 4 lines 1-MAY-1989 01:36 -< RT -> VAXELN v. RT -> TSX-32 >- -------------------------------------------------------------------------------- > Lacks a certain credibility. No more so than suggesting upgrading to a Microvax running VAXELN plus a separate VMS development system on the side!  ================================================================================ Note 150.0 [RT11]Complain, complain... 1 reply EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 5 lines 11-FEB-1988 13:13 -------------------------------------------------------------------------------- WHy is this conference RT_11 instead of RT-11 ? (Just trying to get activity going here). ================================================================================ Note 150.1 [RT11]Complain, complain... 1 of 1 EISNER::DELARISCH "Arnold S. De Larisch" 22 lines 11-FEB-1988 14:28 -< Standards ... those damm Standards! >- -------------------------------------------------------------------------------- >> < Note 9.0 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Complain, complain... >- >> >> >> >> WHy is this conference RT_11 instead of RT-11 ? (Just trying >> to get activity going here). Ah ... Now thats a Good Question! The answer is ... STANDARDS! There has been an Unofficial standard which says "Thou shall not create DECUSERVE Converences with "-" ... Thou must use "_"!" I Don't like it either ... when in Rome ...! If it REALLY bothers you, you can add it into your notebook using any name you like! Check the online help on adding a conference to your notebook. -Arnold Moderator of the RT-11 (RT_11) conference  ================================================================================ Note 151.0 [RSX]Default protection UIC's 8 replies EISNER::SIMONS "Paul, Not that CONVEX!" 8 lines 11-FEB-1988 13:22 -------------------------------------------------------------------------------- At the second bullet in section 4.11.4 of the "Command Language" manual (Set UIC), it says that, "Several system command files, as well as the command files of some users, set the UIC of the file's owner to match the UIC of the directory's owner." How is this majic performed ? None of *our* user command files do this. We are trying to give our priviledged users an easy way (via command file addition to TDX) to change protection UIC's to a named directory's default UIC. We're on M+ V4.0, by the way. ================================================================================ Note 151.1 [RSX]Default protection UIC's 1 of 8 EISNER::MAXWELL "Gary Maxwell" 16 lines 12-FEB-1988 19:43 -< Please elaborate... >- -------------------------------------------------------------------------------- << At the second bullet in section 4.11.4 of the "Command Language" << manual (Set UIC), it says that, "Several system command files, as << well as the command files of some users, set the UIC of the file's << owner to match the UIC of the directory's owner." I don't have my latest Command Language manual handy, but are we trying to change the ownership of a file to match the owner of the directory in which the file is contained? If so, I believe "PIP filename.ext;1/PR/FO" does this trick. You ususally have to be either the owner of the file or a system user to be able to do this. Please correct if I'm wrong or have misinterpreted. ================================================================================ Note 151.2 [RSX]Default protection UIC's 2 of 8 EISNER::SIMONS "Paul, Not that CONVEX!" 14 lines 17-FEB-1988 17:10 -< Futher clarifacation >- -------------------------------------------------------------------------------- < are we trying to change the ownership of a file to match < the owner of the directory in which the file is contained? No, I understand the protection as it applys to Files-11, it's when the terminal gets invovled that I have problems. An example: I am a priveledged user (UIC = [7,77]). The system is in Named Directory mode. I type: SET DEF [200,200] My default directory is [200,200], but my protection UIC is still [7,77]. I understand why this is - and it's a good thing - but I want to impliment an easy way for priveledged users to change both their default and protection at the same time. I thought a command file under TDX would be a good implimentation. ================================================================================ Note 151.3 [RSX]Default protection UIC's 3 of 8 EISNER::BYRNE_C "Charlie Byrne, Freeport NY" 10 lines 17-FEB-1988 21:05 -< A Breif Aside >- -------------------------------------------------------------------------------- >< Note 59.0 by EISNER::SIMONS "Paul, Not that CONVEX!" > > -< Default protection UIC's >- > > performed ? None of *our* user command files do this. We are trying > to give our priviledged users an easy way (via command file addition ^^^^^^^^^^^ ||||||||||| Quick! Fix it before Brian logs in! (See 36.3) :-) ================================================================================ Note 151.4 [RSX]Default protection UIC's 4 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 46 lines 17-FEB-1988 22:35 -< A Psuedo Command File >- -------------------------------------------------------------------------------- >> < Note 59.2 by EISNER::SIMONS "Paul, Not that CONVEX!" > >> -< Futher clarifacation >- >> >> < are we trying to change the ownership of a file to match >> < the owner of the directory in which the file is contained? >> >> No, I understand the protection as it applys to Files-11, it's when >> the terminal gets invovled that I have problems. An example: >> I am a priveledged user (UIC = [7,77]). >> The system is in Named Directory mode. >> I type: SET DEF [200,200] >> My default directory is [200,200], but my protection UIC is still >> [7,77]. >> I understand why this is - and it's a good thing - but I want to >> impliment an easy way for priveledged users to change both their >> default and protection at the same time. I thought a command file >> under TDX would be a good implimentation. Well, I don't have my Indirect manual with me ... so I will write is psuedo "indirect". .enable substitution .disable display .iff .exit !If they aren't privileged why bother .if P1 = "" .exit !If they haven't entered a dir exit !Really need to do some idiot checking !here and make sure that the P1 !parameter has a numeric UIC! .parse P1 "[,]" junk group member junk2 !Parse the 1st parameter for UIC spec CHD 'group','member !Change into the directory requested .ift then CHU 'GROUP','MEMBER' !If in named mode, change user also .EXIT !Wave the nice L-user bye bye call the command CD.CMD and put it into LB:[3,54] (or whatever you have as your default LIBUIC. @CD [200,200] should give you the desired effects. I'll try to actually get something running and upload it if its only a few lines. -Arnold ================================================================================ Note 151.5 [RSX]Default protection UIC's 5 of 8 EISNER::SIMONS "Paul, Not that CONVEX!" 14 lines 18-FEB-1988 17:30 -< Another example >- -------------------------------------------------------------------------------- An example: >> I am a priveledged user (UIC = [7,77]). >> The system is in Named Directory mode. >> I type: SET DEF [200,200] >> My default directory is [200,200], but my protection UIC is still >> [7,77]. Another Example: I am a priveledged user (UIC = [7,77]). The system is in Named Directory mode. I type: SET DEF [RJE] My default directory is [RJE], but my protection UIC is still [7,77]. The files in [RJE] all have an owner UIC of [200,200]. How do I find out what the file's owner UIC is (using a command file)? The example given in the manual seems a bit impractical. ================================================================================ Note 151.6 [RSX]Default protection UIC's 6 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 24 lines 19-FEB-1988 13:22 -< Find out who owns the Directory! >- -------------------------------------------------------------------------------- >> < Note 59.5 by EISNER::SIMONS "Paul, Not that CONVEX!" > >> -< Another example >- >> >> An example: >> >> I am a priveledged user (UIC = [7,77]). >> >> The system is in Named Directory mode. >> >> I type: SET DEF [200,200] >> >> My default directory is [200,200], but my protection UIC is still >> >> [7,77]. >> Another Example: >> I am a priveledged user (UIC = [7,77]). >> The system is in Named Directory mode. >> I type: SET DEF [RJE] >> My default directory is [RJE], but my protection UIC is still >> [7,77]. The files in [RJE] all have an owner UIC of [200,200]. >> How do I find out what the file's owner UIC is (using a command file)? >> The example given in the manual seems a bit impractical. I knew you were gonna ask me that! (say it in a 'Get Smart' voice) The only 'easy' way would be to do a DIR/full on sy:[0,0]'DIRECTORY'.DIR;1 and see who owns it. Then CHD/CHU into that account! -Arnold ================================================================================ Note 151.7 [RSX]Default protection UIC's 7 of 8 EISNER::SIMONS "Paul, Not that CONVEX!" 15 lines 19-FEB-1988 19:24 -< Say, What? >- -------------------------------------------------------------------------------- > The only 'easy' way would be to do a DIR/full on sy:[0,0]'DIRECTORY'.DIR;1 >and see who owns it. Then CHD/CHU into that account! I don't know how to put this... Does anybody see the above "'easy' way" as a problem ? Am I missing something obvious ? I grew up on RSX11M V 3.1, so a lot of concepts are new to me. I think named directories are great, and I think I understand UIC's, but I guess I'm confused when it comes to putting them together. The default protection on all our named directories is set to [200,200], but that will change as we impliment group global event flags, etc. Does this mean that, as a privelidged (sic) user, I have to DIR [0,0]/full *every* time I SET DEF ?!? Maybe I'm attaching too much importance to SET UIC ? ================================================================================ Note 151.8 [RSX]Default protection UIC's 8 of 8 EISNER::SIMONS "Paul, Not that CONVEX!" 104 lines 22-APR-1988 18:29 -< A "solution"? >- -------------------------------------------------------------------------------- The following command file is my solution to the "problem" of named directories and UIC's. Comments are solicited. .; cha.cmd .; This command file impliments the CHange All command of TDX. .; .; Author: Paul G. Simons .; Connecticut Valley Electric Exchange .; 297 Belleview Ave. .; Southington, CT 06489 .; (203)276-6435 .; .; Calling Sequence: .; cha [200,200] cha 200,200 .; cha [200200] cha 200200 .; asn [200,200] = main cha main .; .; NB: Since this implimentation is slow enough already, it was .; decided that the DIR command that generates [200,200]DIR.DAT .; would not be done at execution time. This means that every .; time a CRE/DIR is done a CHA 200,200 .; DIR /FULL/OUT:DIR.DAT [0,0] .; should also be done, or it's error time! .; .enable substitution .disable display .setn cr 15 !carriage return .; Set indir to directory spec, without any brackets. .parse p2 "[]" withou with trash !Allow for brackets .if withou eq "" .sets indir with !It had brackets .if with eq "" .sets indir withou !It didn't have brackets .massag: .; If INput DIRectory contains a comma, it is a numeric directory. .test indir "," !Test for comma .if = 0 .goto named !No comma, it's named .; It's a numeric spec, change it into its named equivelent and store .; the results in dirnam. 1,54 becomes 001054. .sets grp indir[1:-1] !Get group number .sets mbr indir[+1:*] !Get member number .sets dumb grp !Dummy subroutine parm .gosub leadz !Add necessary zeros .sets dirnam dumb !Group is done .sets dumb mbr !Do same for member .gosub leadz .sets dirnam dirnam+dumb !Translation complete .goto match !Go see if it's real .named: .; We have a "name". See if it's a logical or actual name. .; The results go to dirnam. .translate [*] 'indir' !Is it a logical? .if eq "" .goto notlog !All set if not .test "::" !On some other system? .if <> 0 .goto notlog !Yes, ignore logical .parse "[]" trash indir trash2 !Trash all but spec .goto massag !Run it thru again .notlog: .sets dirnam indir !No modification needed .match: .; The input directory specification has been massaged into a .; standard directory filename. [200,200]DIR.DAT contains an .; up to date list of the files in [0,0], look in there for a .; match. .openr [200,200]dir !Open directory file .nxtrec: .read dirlin !Read line from file .if eq .goto noent !No entry by that name! .test dirlin "." !Test for "name.dir" .if = 0 .or .if cr <> 'dirlin%v' .goto nxtrec !nope .if dirnam ne dirlin[3:-1] .goto nxtrec !Match? .; Dirnam does indeed contain a real directory name. The next line .; in the file contains the UIC. .read dirlin !Read next line .parse dirlin "[]" trash uic trash2 !Trash all but UIC .close !Close DIR.DAT .; We can now do what we came to do. set def ['dirnam'] .; Check privilege status, and politely tell the nonprivileged user .; that it's quicker to use CHD. .ift set uic ['uic'] .iff ; You will get much quicker response using CHD. .exit '' .noent: ; I can''t find the entry in [200,200]dir.dat for 'dirnam'.dir! .close .exit '' .leadz: .; This subroutine will take the string passed in "dumb", and make .; it three characters long, padding with leading zeros if needed. .begin !Keep labels local .test dumb !How many characters? .if gt 3 .goto alelse !Check for badness .goto '' !Else, pad as needed .alelse: ; Illegal group or member number: 'dumb' .stop .1: .sets dumb "00"+dumb .goto 3 .2: .sets dumb "0"+dumb .3: .end .return  ================================================================================ Note 152.0 [RT11]NEW FEATURES No replies EISNER::DELARISCH "Arnold S. De Larisch" 8 lines 12-FEB-1988 17:12 -------------------------------------------------------------------------------- I'll take this opportunity to start a discussion stream of what new features you would like to have added to RT-11 and related O/S. It is my hope (no guarantees) that this information will be passed on to DEC RT-11 Development group for consideration. Well folks ... starty typing!!! 8-{) -Arnold  ================================================================================ Note 153.0 [RT11]BUG REPORT No replies EISNER::DELARISCH "Arnold S. De Larisch" 10 lines 12-FEB-1988 17:27 -------------------------------------------------------------------------------- While I'm at it ... may as well ad a discussion stream for known/suspected bugs. Please use this note stream for problem discussions but be aware that there is a Conference for SPRs. Please include the RT-11 version number and component/module/device-handler in question and any other useful information. -Arnold  ================================================================================ Note 154.0 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 11 replies EISNER::RUMFORD 19 lines 16-FEB-1988 10:40 -------------------------------------------------------------------------------- < DEC-net 4.0 & RSX11M+ 4.0 > I recently got the RSX11M+ 4.0 and Dec-net 4.0 distribution kits. After successfully generating the RSX operating system, I processed to Netgen a system using a DLV11 at 9600 baud in a multidrop slave environment as an end node. This was the same configuration as I had done using RSX 3.0 and Dec-net 3.0 in the past. In performing the @NETINS, the NCP SET EXE STA ON command produces the following error: NCP -- Set failed, component in wrong state, System and therefore does not work. I can't seem to find anything in the manuals to help me through this problem. It can't be the hardware, since I can slap a 3.0 system in and it comes up with no error. There must be something else that is different from 3.0 that I need to do, but what? -Update Blues ================================================================================ Note 154.1 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 1 of 11 EISNER::MCCARTHY 21 lines 16-FEB-1988 16:02 -< This must be a fairly basic problem >- -------------------------------------------------------------------------------- In order to get that on the SET EXE STA ON, one of three things probably didn't happen: 1) NM: driver was never loaded, 2) The NM: device wasn't CON'd online. 3) The NCP SET SYS command wasn't executed or failed. It could also conceivably be that a needed process wasn't marked for load during the NETGEN. -Brian Can you post the results of the following commands here? DEV NM: CON DIS FULL FOR NM: NCP SHOW SYS NCP SHOW KNOWN PROC ================================================================================ Note 154.2 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 2 of 11 EISNER::RUMFORD 39 lines 17-FEB-1988 10:05 -< RESPONSE FOR DECNET 4.0 BUG? >- -------------------------------------------------------------------------------- < Note 60.1 by EISNER::MCCARTHY > -< This must be a fairly basic problem >- In order to get that on the SET EXE STA ON, one of three things probably didn't happen: 1) NM: driver was never loaded, 2) The NM: device wasn't CON'd online. 3) The NCP SET SYS command wasn't executed or failed. It could also conceivably be that a needed process wasn't marked for load during the NETGEN. -Brian Can you post the results of the following commands here? DEV NM: CON DIS FULL FOR NM: NCP SHOW SYS NCP SHOW KNOWN PROC Brian, My system I was doing this on is temporarily unavailable. I should be able to find that info out within a couple of days if you can check back then. However, I do have a hardcopy of the NETINS process and: 1) The NM driver appears to be loaded correctly. 2) The NM driver was onlined. 3) The NCP SET SYS executed with only the normal NTL -- System name change to "MKI001" message. I'll get that info as soon as I can. Thanks again. -Dan ================================================================================ Note 154.3 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 3 of 11 EISNER::RUMFORD 55 lines 18-FEB-1988 14:10 -< RESPONSES REQUESTED GIVEN >- -------------------------------------------------------------------------------- < Note 60.2 by EISNER::RUMFORD > -< RESPONSE FOR DECNET 4.0 BUG? >- < Note 60.1 by EISNER::MCCARTHY > -< This must be a fairly basic problem >- In order to get that on the SET EXE STA ON, one of three things probably didn't happen: 1) NM: driver was never loaded, 2) The NM: device wasn't CON'd online. 3) The NCP SET SYS command wasn't executed or failed. It could also conceivably be that a needed process wasn't marked for load during the NETGEN. -Brian Can you post the results of the following commands here? DEV NM: CON DIS FULL FOR NM: NCP SHOW SYS NCP SHOW KNOWN PROC ------------------------------------------------------------------------ Brian, Here is the responses you requested: 1) The NM driver appears to be loaded correctly. 2) The NM driver was onlined. 3) The NCP SET SYS executed with only the normal NTL -- System name change to "MKI001" message. >DEV NM: NM0: LOADED >CON DIS FULL FOR NM: CON -- No device name matches select string "NM:" >NCP SHOW SYS NCP -- Show failed, component in wrong state, System >NCP SHOW KNOWN PROC NCP -- Show failed, component in wrong state, System It looks like something is wrong with "NM:"? I Don't understand what that means. Thanks for responding. -Dan ================================================================================ Note 154.4 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 4 of 11 EISNER::DELARISCH "Arnold S. De Larisch" 11 lines 18-FEB-1988 15:23 -< Try CON DIS FULL FOR NM0: >- -------------------------------------------------------------------------------- < Note 60.3 by EISNER::RUMFORD > -< RESPONSES REQUESTED GIVEN >- >CON DIS FULL FOR NM: CON -- No device name matches select string "NM:" Try the following: >CON DIS FULL FOR NM0: -Arnold ================================================================================ Note 154.5 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 5 of 11 EISNER::RUMFORD 25 lines 22-FEB-1988 12:25 -< RESPONSE FOR CON DIS FULL FOR NM0: >- -------------------------------------------------------------------------------- < Note 60.4 by EISNER::DELARISCH "Arnold S. De Larisch" > -< Try CON DIS FULL FOR NM0: >- < Note 60.3 by EISNER::RUMFORD > -< RESPONSES REQUESTED GIVEN >- >CON DIS FULL FOR NM: CON -- No device name matches select string "NM:" Try the following: >CON DIS FULL FOR NM0: -Arnold Arnold, here is the response using NM0: >CON DIS FULL FOR NM0: NM0: Online,Accpath,Driver It looks good to me, unfortunately. Appreciate any other response from anyone. Thanks again. -Dan ================================================================================ Note 154.6 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 6 of 11 EISNER::DELARISCH "Arnold S. De Larisch" 28 lines 22-FEB-1988 16:01 -< Looks good to me ... >- -------------------------------------------------------------------------------- >> < Note 60.3 by EISNER::RUMFORD > >> -< RESPONSES REQUESTED GIVEN >- >> >> >CON DIS FULL FOR NM: >> CON -- No device name matches select string "NM:" >> >> Try the following: >> >> >CON DIS FULL FOR NM0: >> >> -Arnold >> >> >> Arnold, here is the response using NM0: >> >> >CON DIS FULL FOR NM0: >> NM0: Online,Accpath,Driver >> >> It looks good to me, unfortunately. Appreciate any other response >> from anyone. Thanks again. >> >> -Dan Looks good to me also .... just what I've got on my PDP 11/44. Brian ... any ideas??? -Arnold ================================================================================ Note 154.7 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 7 of 11 EISNER::MCCARTHY 10 lines 23-FEB-1988 11:37 -< Looks good to me too. >- -------------------------------------------------------------------------------- It looks as if the SET SYS isn't completing successfully. We could use a PAR listing of the system after the SET SYS, picularly the NT.* and POOL.. partitions to see if they loaded. Also,any text between the SET SYS and SET EXE STA . You might also want to include your CETAB.MAC, so we can look at t process definitions. -Brian ================================================================================ Note 154.8 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 8 of 11 EISNER::RUMFORD 20 lines 24-FEB-1988 08:16 -< GETTING NEW INFO >- -------------------------------------------------------------------------------- < Note 60.7 by EISNER::MCCARTHY > -< Looks good to me too. >- It looks as if the SET SYS isn't completing successfully. We could use a PAR listing of the system after the SET SYS, picularly the NT.* and POOL.. partitions to see if they loaded. Also,any text between the SET SYS and SET EXE STA . You might also want to include your CETAB.MAC, so we can look at t process definitions. -Brian Brian, I'll get that info for you. Is there a good way to enter that information into this system for you other than typing it all in? Thanks for responding. -Dan ================================================================================ Note 154.9 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 9 of 11 EISNER::RICE "Gary Rice" 4 lines 24-FEB-1988 10:10 -------------------------------------------------------------------------------- > I'll get that info for you. Is there a good way to enter that > information into this system for you other than typing it all in? Kermit is now available . . . ================================================================================ Note 154.10 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 10 of 11 EISNER::RUMFORD 96 lines 29-FEB-1988 13:07 -< PAR & CETAB.MAC DEFINITIONS >- -------------------------------------------------------------------------------- < Note 60.9 by EISNER::RICE "Gary Rice" > > I'll get that info for you. Is there a good way to enter that > information into this system for you other than typing it all in? Kermit is now available . . . Here is the requested PAR and CETAB.MAC..... PAR NT.* lines 042324 07615600 00003100 RO COM !NT.DLV! 042054 07620700 00006100 RO COM !NT.DCP! 042010 07627000 00014600 RO COM !NT.DLX! 041060 07643600 00024600 RO COM !NT.RTH! 040760 07670400 00015000 RO COM !NT.NCT! 040474 07705400 00015200 RO COM !NT.XPT! 040210 07722600 00017100 RO COM !NT.ECL! 040144 07741700 00006100 RO COM !NT.EVL! 040014 07750000 00006200 RO COM !NT.AUX! 036630 07756200 00016600 RO COM !POOL..! 035614 07775000 00002000 DRIVER (HT:) 032410 07777000 00001000 DRIVER (NM:) CETAB.MAC .TITLE CETAB .IDENT /V04.3/ ; ; Copyright (C) 1982, 1983, 1985, 1987 by ; Digital Equipment Corporation, Maynard, Mass. ; .MCALL SYS$DF SYS$DF PDV$DF ,, SLT$DF DLV,DCP,XPT,LF.TIM!LF.MFL!LF.MTP,0,0,SLAVE,0.,0.,15. STA$DF 1.,XPT,SF.ENA,11.,1,15.,0. LLC$DF AUX,ZF.LLC!ZF.TIM!ZF.MTM!ZF.MFL,0,0. LLC$DF EVL,ZF.LLC!ZF.TIM!ZF.MFL,0,0. LLC$DF ECL,ZF.LLC!ZF.TIM!ZF.MFL!ZF.COU,0,0,NS LLC$DF XPT,ZF.LLC!ZF.TIM!ZF.MFL!ZF.COU,0,1. LLC$DF NCT,ZF.LLC!ZF.TIM!ZF.MFL!ZF.SLI!ZF.INI,0,0. LLC$DF RTH,ZF.LLC!ZF.TIM!ZF.MFL!ZF.SLI!ZF.INI,0,0.,RT LLC$DF DLX,ZF.LLC!ZF.TIM!ZF.MFL,0,1.,NX DLC$DF DCP,ZF.DLC,0,1.,1. DDM$DF DLV,ZF.DDM,5,0,1. CNT$DF 0,430,170430,5,,NX UNT$DF 0,167074,131,,11.,,11. LOG$ST 1 EVT$DF 0,<711,0,0,0>,CONSOLE EVT$DF 200,<3,0,0,0>,CONSOLE EVT$DF 300,<4,0,0,0>,CONSOLE EVT$DF 400,<137777,5,0,0>,CONSOLE EVT$DF 500,<160000,1,0,0>,CONSOLE EVT$DF 10000,<6,0,0,0>,CONSOLE EVT$DF 10400,<40000,0,0,0>,CONSOLE EVT$DF 10500,<1,0,0,0>,CONSOLE ROU$DF 0.,1022.,10.,300.,0.,0.,0.,1022.,0.,0. NOD$DF ,,1.,2.,1.,2. FEA$DF NS,000627,100000,100000 DEC$DF 10.,10.,15.,30.,36.,1,1,6,2,5,30.,0,0,0 REM$DF ,1.,1. REM$DF ,1.,3. OBJ$DF 0.,,2,0 OBJ$DF 15.,,0,0 OBJ$DF 16.,,2,200,5 OBJ$DF 17.,,0,300,10 OBJ$DF 18.,,2,0 OBJ$DF 19.,,1,200,5 OBJ$DF 23.,,2,0 OBJ$DF 25.,,2,200,5 OBJ$DF 26.,,2,200,5 OBJ$DF 29.,,2,200,5 OBJ$DF 42.,,2,0 OBJ$DF 63.,,2,0 BUF$DF 8.,40.,10.,292.,11.,34.,2.,8. PAR$DF ,GEN,28.,TOP,NONE,12. END$DF EXPPDT ,, EXPSLT , EXPLLT EXPSTT EXPPVT ,, .LIST .END The only message between the two NCP SET commands was the node name changed message. I hope this is of help. Thanks, Dan ================================================================================ Note 154.11 [RSX]RSX 4.0 & DEC-NET 4.0 GEN ERROR 11 of 11 EISNER::MCCARTHY 18 lines 1-APR-1988 11:10 -------------------------------------------------------------------------------- Sorry I took so long to get back, but I'm afraid I don't have much help to offer, either. The purpose of the last set of data was to verify that all of the network components were loaded correctly. They seem to be. If you examine your CETAB, you'll see that all of the processes are marked to be loaded (ZF.MFL in LLC$DF) and the PAR list shows them all to be loaded. It certainly appears that the SET EXE should work. When I get a chance, I'll ask the DECnet folks if they have any ideas. Meantime, perhaps the output of SHOW SYS and SHO EXEC from CFE would suggest something. Sorry I can't be more helpful. -Brian  ================================================================================ Note 155.0 [RSX]BRU Ha Ha on a uVAXEN! 1 reply EISNER::DELARISCH "Arnold S. De Larisch" 15 lines 17-FEB-1988 23:13 -------------------------------------------------------------------------------- I posted a similar note in VMS ... without response ... so I'll try it here. I'm trying to read a RSX BRU tape on a MicroVAX II system equipped with a TSV05 tape drive. No ... I don't have VAX-11/RSX or VAX AME ... or whatever they call it this week! 8-{) Yes I've got a PDP 11/44 on the other side of campus ... but the TE16 is acting up and I don't trust it with my ONLY copy of this tape! I don't think the VMS EXCHANGE utility handles BRU ... Any Ideas??? -Arnold ================================================================================ Note 155.1 [RSX]BRU Ha Ha on a uVAXEN! 1 of 1 EISNER::CETRON 6 lines 17-FEB-1988 23:57 -< the only way >- -------------------------------------------------------------------------------- Send me the tape with the LABSTAR release notes and I will interchange it for you.... Boy us moderators aim to please ;-) -ed  ================================================================================ Note 156.0 [RSX]Help wanted with obsolete device No replies EISNER::NORTON 60 lines 22-FEB-1988 09:23 -------------------------------------------------------------------------------- Maybe someone can help us with a problem we're having with the good ol' KW11Y Watchdog Timer. Those with long memories will recall that this was an alarm sold for 11/34's that would honk if the CPU halted. The customer's original 11/34 - 11M3.2 system has been upgraded to an 11/44 - M+4.0 system, and the customer would still like the alarm feature to work. The computer sits unattended in a noisy blue computer room. If the alarm works, they can re-boot even before the users get irate. I discovered the code for this beast is still present in the exec, so I defined the symbol K$$W11=172400 in RSXMC.MAC before exec assembly. The rest of the sysgen went OK. When run, the watchdog alarm sounds immediately and continuously - incorrect behavior. Proof that the hardware is working: If the original 11/34's 11MV3.2 system disk is booted on the 11/44, the alarm shuts off and works properly. Only two places in the exec seem to reference the conditional assembly symbol K$$W11, and seem to be identical to the 11MV3.2 references: .TITLE TDSCH .IDENT /13.03/ ; K. L. NOEL 15-DEC-86 13.02 ; ; KLN030 -- SET INTERRUPT ENABLE BIT ON WATCHDOG TIMER ; .IF DF K$$W11 MOV #103,K$$W11 ;;;ENABLE AND START TIMER ;KLN030 ...the 11m code MOV's #3, K$$W11 instead, but this looks like a ...reasonable change, since #100 always seems to be the interrupt enable bit .ENDC ...and in module POWER.MAC... .TITLE POWER .IDENT /10.00/ .IF DF K$$W11 CLR K$$W11+2 ;CLEAR CLOCK ERROR FLAGS MOV #1,K$$W11+6 ;ENERGIZE OUTPUT RELAY .ENDC Anyway, should I expect this to work anymore? ...and if not, why was K.L. Noel fixing something for obsolete hardware in 1986? Or - did the fix introduce a bug? The manuals have been lost by now so I can't even tell what the change did. If anyone can offer advice, reply here or by phone to 414-797-6810. Thanks. \bill  ================================================================================ Note 157.0 [RSX]Fall '87 RSX tape is now in distribution... No replies EISNER::PERRY "Bob (Sky Scum) Perry" 7 lines 25-FEB-1988 13:30 -------------------------------------------------------------------------------- Yesterday I sent out the Fall '87 RSX SIG tape to the regional LUG tape distributors. They should receive it within the next couple of days. You can get your copy by requesting one from your LUG librarian. The tape was one 2400' reel @1600 bpi. Compliments of Glenn Everhart.  ================================================================================ Note 158.0 [RSX]RA70? 4 replies EISNER::SIMONS "Paul, Not that CONVEX!" 2 lines 26-FEB-1988 16:54 -------------------------------------------------------------------------------- I've been asked to ask if anyone knows of plans to support the RA70 under M+ ? ================================================================================ Note 158.1 [RSX]RA70? 1 of 4 EISNER::CETRON 5 lines 26-FEB-1988 18:29 -< it is a good bet. >- -------------------------------------------------------------------------------- I've heard it will be, and given the track record of RSX in covering new devices, I'd probably put money on it. -ed ================================================================================ Note 158.2 [RSX]RA70? 2 of 4 EISNER::MCCARTHY 4 lines 1-APR-1988 10:51 -------------------------------------------------------------------------------- Gosh, what's an RA70? :-) ================================================================================ Note 158.3 [RSX]RA70? 3 of 4 EISNER::OSUDAR "John Osudar" 4 lines 1-APR-1988 12:17 -------------------------------------------------------------------------------- > Gosh, what's an RA70? :-) Yeah, that's what the users with orders for RA70-based products have been saying... ;-{) ================================================================================ Note 158.4 [RSX]RA70? 4 of 4 EISNER::PERRY "Bob (Sky Scum) Perry" 2 lines 6-APR-1988 13:30 -< Isn't that a virtual disk??? >- --------------------------------------------------------------------------------  ================================================================================ Note 159.0 [RSX]What does PEM$ stand for? 2 replies EISNER::ETHINGTON "Superior Klingon Technology" 17 lines 2-MAR-1988 01:15 -------------------------------------------------------------------------------- Having crapped out completely on the DECnet conference, I'll try my luck here. One of the explicitly undocumented DECnet/RSX family macro calls is PEM$. Without asking for documentation on an explicitly undocumented beastie, could some friendly neighborhood developer feed my curiosity and tell me this much: What do the initials PEM stand for????? If you want to see a use of PEM$, look at the network virtual device package on a 1981 RSX SIG tape. PEM$ is used to create a DECnet object task (creating say FAL.0 from FAL$$$) and send a message to it. It apparently also can be used to return a message - perhaps it is a generalized local intertask communication facility, sort of like SDRC$ - send, request, and connect. Some of us just got curious what the mnemonic stood for - Product Event Message? Pigs Eat Marshmellows? Darned if I know..... Jerry 8^) ================================================================================ Note 159.1 [RSX]What does PEM$ stand for? 1 of 2 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 1 line 2-MAR-1988 15:04 -< Hmmm. >- -------------------------------------------------------------------------------- How about "Process Electronic Mailbox"? ================================================================================ Note 159.2 [RSX]What does PEM$ stand for? 2 of 2 EISNER::MAXWELL "Gary Maxwell" 10 lines 15-MAR-1988 21:53 -< Try some more... >- -------------------------------------------------------------------------------- It's an attention getter: "Please Excuse Me" It's a poison pill: "Please Exterminate Me" A fuzzy reasoning interface: "Probable Error Message" A debugging aid: "Print Ethernet Microcode" My favorite: "Power-off Every Machine"  ================================================================================ Note 160.0 [PDPBAS]Need BP2/RSX v1.6 Installation Guide 2 replies EISNER::FRISBIE "Alan E. Frisbie" 9 lines 8-MAR-1988 21:08 -------------------------------------------------------------------------------- I need to re-install BASIC-Plus-2 v1.6 (!) on an RSX-11M v4.1 system, but have no manuals. At a minimum I need a copy of the Installation Guide and the Release Notes. Would anyone be willing to loan me a copy of these (and any others that exist) so that I may copy them? Thank you, Alan ================================================================================ Note 160.1 [PDPBAS]Need BP2/RSX v1.6 Installation Guide 1 of 2 EISNER::TABOR "Bill Tabor" 4 lines 31-MAR-1988 21:31 -< I have the v 1.6 manuals >- -------------------------------------------------------------------------------- V1.6 requires 1.8 of rms. This means you would need an old syslib as well if you want to task build and run a program. I have the manuals if you want them. ================================================================================ Note 160.2 [PDPBAS]Need BP2/RSX v1.6 Installation Guide 2 of 2 EISNER::FRISBIE "Alan E. Frisbie" 20 lines 1-APR-1988 00:06 -< Upward compatible it isn't! >- -------------------------------------------------------------------------------- >> V1.6 requires 1.8 of rms. This means you would need an old syslib >> as well if you want to task build and run a program. As I found out the hard way! I now have two sets of SYSLIB, BASIC libraries, etc. with names of the form OLDxxxxxx.yyy for all the v1.6/v1.8 stuff. I also had to write a simple command file to modify the command file produced by the BASIC BUILD command. It is a royal hack, but at least the customer is up and running. >> I have the manuals if you want them. Yes, please. Then I might be able to go back and do the job right! I will return them as soon as I can copy them. My address is: Alan E. Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065  ================================================================================ Note 161.0 [RSX]Need help setting Q's in 11-M+... 3 replies EISNER::PERRY "Bob (Sky Scum) Perry" 17 lines 9-MAR-1988 13:37 -------------------------------------------------------------------------------- On my 11/73 I have a DHV-11 and I run 11M+ v3.2 . I want to use port #1 for my line printer (an EPSON FX-80). I have the following in my STARTUP.CMD file: QUE /STOP:QMG ;just in case QUE /START:QMG QUE 1:/CR/NM QUE TT1:/SPOOL/NOFLAG/FORM:0/SHR/LOWER At this point QUE comes back at me and says: QUE -- Processor task not installed What processor task is it referring to? ================================================================================ Note 161.1 [RSX]Need help setting Q's in 11-M+... 1 of 3 EISNER::DELARISCH "Arnold S. De Larisch" 34 lines 9-MAR-1988 15:39 -< A little bit more info! >- -------------------------------------------------------------------------------- >> < Note 66.0 by EISNER::PERRY "Bob (Sky Scum) Perry" > >> -< Need help setting Q's in 11-M+... >- >> >> >> >> On my 11/73 I have a DHV-11 and I run 11M+ v3.2 . I want to >> use port #1 for my line printer (an EPSON FX-80). I have the following >> in my STARTUP.CMD file: >> >> QUE /STOP:QMG ;just in case >> QUE /START:QMG >> QUE 1:/CR/NM >> QUE TT1:/SPOOL/NOFLAG/FORM:0/SHR/LOWER >> >> At this point QUE comes back at me and says: >> >> QUE -- Processor task not installed >> >> What processor task is it referring to? I believe the is reference to the Prototype Print Processor taks (LPPxxx). What you need to do is the following: > INS $LPPFSL/TASK=TT1 !Install prototype print proc > QUE /START:QMG !Start the Queue manager > QUE TT1:/CR/NM !Create the DEVICE queue > QUE TT1:/SPOOL/NOFLAG/FORM:0/SHR/LOWER !Set up the queue characteristics > QUE TT1:/AS:PRINT !Assign default print queue to TT1 > QUE TT1:/STA:TT1 !start queue TT1 I believe this to be correct, I don't have my manual set in front of me nor is my queue manager start file handy. -Arnold ================================================================================ Note 161.2 [RSX]Need help setting Q's in 11-M+... 2 of 3 EISNER::MCGLINCHEY "SANCHO! My armor! My TECO Macros" 8 lines 19-MAR-1988 20:35 -< NIT >- -------------------------------------------------------------------------------- >> On my 11/73 I have a DHV-11 and I run 11M+ v3.2 . RSX-11M-PLUS never had a release 3.2. Do you mean RSX-11M Version 3.2, or RSX-11M-PLUS version 3.0 or 4.0? -Glinch ================================================================================ Note 161.3 [RSX]Need help setting Q's in 11-M+... 3 of 3 EISNER::PERRY "Bob (Sky Scum) Perry" 11 lines 21-MAR-1988 14:11 -< It was VM/CMS... >- -------------------------------------------------------------------------------- You know, on a daily basis I timeshare my time between 4.2bsd UNIX, various flavors of VMS, RSX11-M, RSX11-M+, and MS/DOS. I do my checkbook updating in octal, and when I skydive I read my altimeter in hex ( don't ask why I've never cratered in... ). I REALLY meant RSX11-M+ v3.0 (4.0 hasn't arrived, yet - Will this make a difference ?) . Bob (pork for brains) PERRY  ================================================================================ Note 162.0 [PRO300]Using Logical QIOs under P/OS v3 2 replies EISNER::RICE "Gary Rice" 8 lines 15-MAR-1988 08:07 -------------------------------------------------------------------------------- Ever since P/OS v3 came out, I have been unable to issue Logical QIOs to the system disk successfully. The QIO ALWAYS fails with a "Privilege Violation" (even if the image is linked "/PR"). Is there anything I can do to allow this type of QIO to work successfully? Gary ================================================================================ Note 162.1 [PRO300]Using Logical QIOs under P/OS v3 1 of 2 EISNER::ETHINGTON "Superior Klingon Technology" 41 lines 17-MAR-1988 01:05 -< "This Is Not A Problem" >- -------------------------------------------------------------------------------- Yes, indoody - on P/OS V3.0 and later systems, you can only perform logical QIOs to a mounted disk (such as the system disk) IF you have set the bit T4.LIO in offset T4.STS of the task's TCB. If T4.LIO is NOT set, as you correctly noted, the exec poops on all requests, even those from a privileged task, with IE.PRI status. The following code fragment, developed through the miracles of superior Klingon technology, should do the job. This is for a task built as /PR:0, and using the SWST$ directive to enter system state. ; ; If we are on P/OS V3.0 or later, we must have the T4.LIO bit set in ; T4.STS in order to perform logical I/O to a mounted volume, or all ; IO.RLB/IO.WLB barf with IE.PRI errors. The use of executive vectoring ; should let this task function on P/OS V2.0 and later, and checking the ; presence of P/OS should let the task image function on P/OS or M+. ; Sub #16.*2,SP ; We need a 16 word buffer Mov Sp,R5 ; R5 => buffer Gtsk$S R5 ; Get task parameters Bcs 10$ ; If it barfed, just give up Cmp G.Tssy(R5),#11 ; Are we on P/OS today? Bne 10$ ; If not, skip all this Wimp$S #Gi.Fmk,R5,#9. ; Get system feature masks - since this ; subfunction was implemented beginning ; with P/OS V3.0, it will barf on older ; versions of P/OS Bcs 10$ ; If CS, must be older than V3.0 Swst$S #20$,#20$ ; Set bit in system state 10$: Add #16.*2,SP ; Fix up stack Return ; All done 20$: Mov @#$Veclc,R4 ;; R4 => $Stack Mov $Tktcb-$Stack(R4),R4 ;; R4 => our TCB Bis #T4.Lio,T.St4(R4) ;; Set logical I/O privilege bit Return ;; All done This should do the trick for you; if you have any problems, I should be able to help. Jerry ================================================================================ Note 162.2 [PRO300]Using Logical QIOs under P/OS v3 2 of 2 EISNER::RICE "Gary Rice" 24 lines 30-MAY-1988 10:16 -< Crashing Code >- -------------------------------------------------------------------------------- Well, I tried this code fragment (after, of course turning it into a callable subroutine) and it DOES work in little test programs. It also works in one serious effort, namely the CVL program (Change Volume Label from one of the RSX SIG tapes). BUT . . . . It fails when I try to use it with REI, the file reincarnator program ALSO from the RSX SIG tapes. When I build REI from the original macro source, the program executes "normally" simply telling me that I can't access the hard disk by generating an error message. When I include a call to the subroutine that I made out of Jerry's code, it produces an odd address trap in most cases. I have experimented with the placement of the call and been able to change the contents of the registers and program counter (and also been able to CRASH the PRO by messing around with Jerry's code). HELP! Gary  ================================================================================ Note 163.0 [RSX]Dual OS's on one disk 4 replies EISNER::SIMONS "Paul, Not that CONVEX!" 9 lines 17-MAR-1988 17:12 -------------------------------------------------------------------------------- We are considering maintaining two copies of the operating system on one system disk. The reason is that the "other" system will reside on a disk that is too small to do developement work on. What is the "best" way to impliment this? The manuals suggest that the sysgen be performed on another disk, and the resultant files be moved to the system disk. Since we only have one disk big enough to perform a sysgen on, this solution doesn't apply to us. Would a "Virtual" disk on the system disk be appropriate? Would it work? Any other ideas? ================================================================================ Note 163.1 [RSX]Dual OS's on one disk 1 of 4 EISNER::DELARISCH "Arnold S. De Larisch" 32 lines 17-MAR-1988 18:17 -< Need More Input! >- -------------------------------------------------------------------------------- >> < Note 67.0 by EISNER::SIMONS "Paul, Not that CONVEX!" > >> -< Dual OS's on one disk >- >> >> We are considering maintaining two copies of the operating system >> on one system disk. The reason is that the "other" system will reside >> on a disk that is too small to do developement work on. Could you be more specific on this. Why do you NEED two different copies of the O/S? >> What is the "best" way to impliment this? More information as to the Version of the O/S (11M,11M+,Micro/RSX)? Specifically what hardware (particularly what size and how many disks!). >> The manuals suggest that the sysgen be performed on another disk, >> and the resultant files be moved to the system disk. Since we only >> have one disk big enough to perform a sysgen on, this solution doesn't >> apply to us. >> Would a "Virtual" disk on the system disk be appropriate? Yes ... I often do SYSGENs on a Virtual Disk. There are, however, a number of limitations to the Virtual disk. You cannot hardware boot a virtual disk ... I also believe that SAVe doesn't work either. >> Would it work? Any other ideas? To do a SYSGEN ? YES -Arnold ================================================================================ Note 163.2 [RSX]Dual OS's on one disk 2 of 4 EISNER::SIMONS "Paul, Not that CONVEX!" 34 lines 23-MAR-1988 12:30 -< More Info >- -------------------------------------------------------------------------------- {>> We are considering maintaining two copies of the operating system {>> on one system disk. The reason is that the "other" system will reside {>> on a disk that is too small to do developement work on. { Could you be more specific on this. Why do you NEED two different { copies of the O/S? Because the the boot devices are different. (We develop on a RP06, we have a front-end system that uses a RK05) {>> What is the "best" way to impliment this? { More information as to the Version of the O/S (11M,11M+,Micro/RSX)? { Specifically what hardware (particularly what size and how many { disks!). We are upgrading to RSX-11M+ 4.0 (See Who_am_I for the grizzlies). The main systems have a system RP06 and a RK05, the front-end's have RK05's. {>> The manuals suggest that the sysgen be performed on another disk, {>> and the resultant files be moved to the system disk. Since we only {>> have one disk big enough to perform a sysgen on, this solution doesn't {>> apply to us. {>> Would a "Virtual" disk on the system disk be appropriate? { Yes ... I often do SYSGENs on a Virtual Disk. There are, however, { a number of limitations to the Virtual disk. You cannot hardware { boot a virtual disk ... I also believe that SAVe doesn't work { either. We envision using the VD: just to keep everything seperate until we move it over to the RK05. ================================================================================ Note 163.3 [RSX]Dual OS's on one disk 3 of 4 EISNER::DELARISCH "Arnold S. De Larisch" 1 line 23-MAR-1988 16:09 -< Use a Virtual Disk! >- -------------------------------------------------------------------------------- >> < Note 67.2 by EISNER::SIMONS "Paul, Not that CONVEX!" > ================================================================================ Note 163.4 [RSX]Dual OS's on one disk 4 of 4 EISNER::MAXWELL "Gary Maxwell" 18 lines 5-MAY-1988 23:00 -< A Way to Do It >- -------------------------------------------------------------------------------- This topic may be stale, but... I have maintained two versions of the operating system on one disk for years. Reason: distrust of new versions; I keep the old version around in case I have to yank the old version out. Here's what I do: Keep one system in [1,54],[3,54], and a Network UIC Keep another system in [1,55], [3,55], and another Network UIC Keep alternative copies of library files in [1,1], such as SYSLIBV30.OLB and SYSLIBV40.OLB. Have a [1,2]STARTUP command file which interprets the system UIC, and creates directory entries in [1,1] for the appropriate library files. And yes, use virtual disks.  ================================================================================ Note 164.0 [RSX]an M-Plus V4.0 bug 4 replies EISNER::OSUDAR "John Osudar" 28 lines 1-APR-1988 19:04 -------------------------------------------------------------------------------- Just in case someone else might get bitten by this bug: A colleague of mine has been devoting considerable time to SYSGENing a "small" version of M-Plus V4.0, using his own knowledge and the advice of various DECUS and DEC people. He finally produced a reasonable-looking system -- but it was unusable, because any attempt to run a task that wasn't installed produced a "deferred binding not supported" message. (Deferred binding of LUNs was one of the features he left out.) We did some poking around, and found the following: RUN $FOO fails with "deferred binding not supported" message RUN $FOO/DFB=NO fails the same way RUN $FOO/DFB=YES works! The documentation says that /DFB=YES should be the default, meaning "use deferred binding". From this, we concluded that something was very confused (besides us!) He then looked at the source code, and found a problem in module [12,10]INSLB.MAC, at line 636. The code there (lines 635 to 638) looks like: BIT #1,$FLGS3 ; /DFB=YES SWITCH SEEN? BEQ 699$ ; IF EQ - NO JMP INSL41 ; ISSUE "DFB NOT SUPPORTED" ERROR MESSAGE 69$: (...etc.) The problem is with the sense of the branch to 699$ -- in fact, it should be a BNE because that bit is set if NO deferred binding is specified (as is seen from code immediately following that shown above.) This will be SPR'ed. ================================================================================ Note 164.1 [RSX]an M-Plus V4.0 bug 1 of 4 EISNER::MAXWELL "Gary Maxwell" 9 lines 5-MAY-1988 23:16 -< Another INS bug?! >- -------------------------------------------------------------------------------- I am immensly amused by this. I have found more bugs in INS than in any other DEC utility (even BRU). For an exercise in humor, experienced RSX people should read INS to see how archaic it is in today's world of I/D, deferred binding, and clusters. A developer no longer with RSX once said that INS was to be rewritten. I think they dropped it because then they would not be able to laugh at the code anymore. ;-) ================================================================================ Note 164.2 [RSX]an M-Plus V4.0 bug 2 of 4 EISNER::WYANT "Tom Wyant" 7 lines 11-NOV-1988 15:44 -< Just a moment, INS-breath! >- -------------------------------------------------------------------------------- >>>> I am immensly amused by this. I have found more bugs in INS >>>> than in any other DEC utility (even BRU). I'll put OTL up against INS any day (though you might say they're brothers under the skin). In fact, I'll back OTLHD.MAC against all comers as buggiest module in RSX. ================================================================================ Note 164.3 [RSX]an M-Plus V4.0 bug 3 of 4 EISNER::RICE "Gary Rice" 6 lines 12-NOV-1988 04:58 -------------------------------------------------------------------------------- > I'll put OTL up against INS any day (though you might say > they're brothers under the skin). OK, I'll bite. What is OTL? Gary ================================================================================ Note 164.4 [RSX]an M-Plus V4.0 bug 4 of 4 EISNER::WYANT "Tom Wyant" 20 lines 14-NOV-1988 14:21 -< You asked for it... >- -------------------------------------------------------------------------------- > I'll put OTL up against INS any day (though you might say > they're brothers under the skin). >> OK, I'll bite. What is OTL? OTL officially stands for "online task loader", though it has been alleged to stand for "Out to Lunch". OTL is an RSX-11S utility to install and fix a task in a running system from RT-11 or DOS-11 format media (now you see why I called them "brothers under the skin"). We don't upgrade 11S systems that often, but I can NEVER remember running a version of OTL that I didn't have to patch first. Most recently (but still some time ago), there was the OTL that assumed you never mapped more than one resident common or library. Prior to that was the one that forgot to initialize the Offspring Control Block listhead.  ================================================================================ Note 165.0 [RSX]Need D/N-11M+ v4.0 help... 3 replies EISNER::PERRY "Bob (Sky Scum) Perry" 40 lines 12-APR-1988 14:13 -------------------------------------------------------------------------------- OK, here's one that's really got me stumped. I have: 1)11/73 2)RSX11-M+ v4.0 3)DECNet v4.0 I gen a new system and it runs fine. This system has 2 - RD-52 type disks and an RX-33 type floppy drive and 1MB memory. In addition, it has a clock/calendar board, a DEQNA, and a DHV-11. OK, the system is brand spanking new (the O/S, that is). I selected a standard system whin I did the sysgen & selected networking products to be included. I then did a NETGEN and, again, selected a standard system with the DEQNA as the communications device. Standard CSR's and default vector assignments all around. When I do the NETINS.CMD procedure it installs fine. 5 seconds later I get: Event type 5.13, Initialization failure Occurred 7-APRIL-88 14:49:36 on node 1.17 (ZAPPA) Line QNA-0 Re-netgenned the system and got the same thing. Called telephone support and they suspect the driver is loaded into a portion of bad memory, so we try: NCP>set cir qna-0 state off NCP>set line qna-0 loc first NCP>set circ qna-0 state on The circuit comes up like a champ and connects to all my other nodes. Unfortunately, it crashes the system 15 seconds later. Repeatedly. I rebuild thfe QNA driver in case it got trashed somehow. Same results. I swap out the 1MB memory board with another known good board. Same results. I boot up my 3.0 M+ system with the older version of DECNet and it runs like a champ. No crash. Colo. Springs says to send them a crash dump as none of their other customers report any of these problems. Before I do this does anyone have any suggestions? ================================================================================ Note 165.1 [RSX]Need D/N-11M+ v4.0 help... 1 of 3 EISNER::CETRON 9 lines 12-APR-1988 23:43 -< some possible causes. >- -------------------------------------------------------------------------------- I've seen the initialization failure several times - and each time it was a hardware problem. SQE heartbeat on/off improperly (now did 4.0 use different spec? 802.3 rather then ethernet-1? 'specially as compared to 3.0?) also, when we had excessive collisions we got the same message... -ed ================================================================================ Note 165.2 [RSX]Need D/N-11M+ v4.0 help... 2 of 3 EISNER::PERRY "Bob (Sky Scum) Perry" 4 lines 14-APR-1988 14:56 -< Yes, but.. >- -------------------------------------------------------------------------------- If it was a hardware problem, how come I can get 3.0 to come up ok? ================================================================================ Note 165.3 [RSX]Need D/N-11M+ v4.0 help... 3 of 3 EISNER::CETRON 9 lines 16-APR-1988 14:59 -< ethernet is NOT ethernet >- -------------------------------------------------------------------------------- there are 3 different ethernet specs. Ethernet type 1, type 2, and 802.3 and are not always compatible. VMS decnet just announced (4.5 or so) that they would support ONLY 802.3. IF RSX decnet did the same thing in 4.0 this would explain it. It all has to do with SQE (heartbeat) and other mystical voodoo incantations..... -ed  ================================================================================ Note 166.0 [RSX]TOo much memory . . . 2 replies EISNER::FRIEDBERG 3 lines 25-APR-1988 05:44 -------------------------------------------------------------------------------- I may have missed something somewhere, but I am in the habbit of crashing any system that I play with, and it seems surprising that I can't get the full 4 Mbyte dump out of CDA. What did I do wrong (it only gives 124KW???) ================================================================================ Note 166.1 [RSX]TOo much memory . . . 1 of 2 EISNER::GARDNER "Tim Gardner" 11 lines 25-APR-1988 08:44 -< CDA still believes in 18bit systems >- -------------------------------------------------------------------------------- RE: < Note 70.0 by EISNER::FRIEDBERG > >I may have missed something somewhere, but I am in the habbit of crashing >any system that I play with, and it seems surprising that I can't get the >full 4 Mbyte dump out of CDA. What did I do wrong (it only gives 124KW???) CDA dumps only 124Kw by default. There is a switch to tell it what the proper memory size is (Sorry, I don't remember it and don't have a manual nearby). tg ================================================================================ Note 166.2 [RSX]TOo much memory . . . 2 of 2 EISNER::STAMERJOHN "RW Stamerjohn" 8 lines 29-APR-1988 13:03 -< /memsiz:n >- -------------------------------------------------------------------------------- The switch is /MEMSIZ:n where 'n' is the KW or memory on your system. Use this switch when reading raw dump to a crash file, for example: >cda ,file/memsiz:512.=ms: Note, some crash devices only dump 124KW. The one which comes to mind is the TU10.  ================================================================================ Note 167.0 [RSX]BACKUP/LIST output to a file 9 replies EISNER::MAYHEW "Bill Mayhew" 7 lines 26-APR-1988 09:28 -------------------------------------------------------------------------------- On MicroRSX, V3.1 (one version old), I need to do a BACKUP/LIST/SAVE_SET:foo with the results sent to a file instead of to my terminal -- i.e. I need a file that lists the contents of a save set. I can't seem to find a way to do it, and I can't shake the idea that either I'm missing something really dumb, or DEC did a really dumb implementation. Anybody have any ideas? ================================================================================ Note 167.1 [RSX]BACKUP/LIST output to a file 1 of 9 EISNER::NORTON "Bill Norton" 4 lines 26-APR-1988 16:03 -< One way... >- -------------------------------------------------------------------------------- The quick way do it is to put the command in a BATCH job and use the batch log file as the output. There's also a BRUDIR program on one of the RSX SIG tapes. ================================================================================ Note 167.2 [RSX]BACKUP/LIST output to a file 2 of 9 EISNER::DELARISCH "Arnold S. De Larisch" 22 lines 26-APR-1988 18:49 -< BRUDIR ... A real winner! >- -------------------------------------------------------------------------------- >> < Note 71.1 by EISNER::NORTON "Bill Norton" > >> -< One way... >- >> >> The quick way do it is to put the command in a BATCH job >> and use the batch log file as the output. A reasonalble way ... but you only get Filename and directory info. >> >> There's also a BRUDIR program on one of the RSX SIG tapes. A great piece of software (although doesn't work YET with named directories ... it still shows the owner UIC). Its written in Fortran and works VERY well. You are allowed to specify the output device (File, or terminal, or other device... printer) and a level of listing (Breif, List, Full). -Arnold P.S. I really wish that someone would update BRUDIR for named directories!!!! ================================================================================ Note 167.3 [RSX]BACKUP/LIST output to a file 3 of 9 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 15 lines 27-APR-1988 00:27 -< OK, I'll do it >- -------------------------------------------------------------------------------- >> P.S. I really wish that someone would update BRUDIR for named >> directories!!!! OK, OK! I know I promised to do it months ago, but I've been busy. I will try to get it onto the Spring SIG tape. I'll let you know here when it is done. One question: How do you want numbered directories displayed? [ 1, 5] [1,5] [001,005] [001005] Alan ================================================================================ Note 167.4 [RSX]BACKUP/LIST output to a file 4 of 9 EISNER::DELARISCH "Arnold S. De Larisch" 19 lines 27-APR-1988 11:44 -< Good ... Better ... Best! >- -------------------------------------------------------------------------------- >> < Note 71.3 by EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" > >> -< OK, I'll do it >- >> One question: How do you want numbered directories displayed? >> >> [ 1, 5] Nope! >> [001,005] Good! >> [1,5] Better! >> [001005] BEST! -Arnold ================================================================================ Note 167.5 [RSX]BACKUP/LIST output to a file 5 of 9 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 24 lines 27-APR-1988 12:42 -< More BRUDIR questions >- -------------------------------------------------------------------------------- || >> [ 1, 5] || Nope! || || >> [001,005] || Good! || || >> [1,5] || Better! || || >> [001005] || BEST! Would you mind giving some reasons why you prefer "[001005]" over "[1,5]" for numbered directories? Remember, BRUDIR will be used by people who never use named directories. Does anyone else have an opinion? On another issue: Currently, BRUDIR only lists the UFD when it changes. This makes a pretty listing, but is difficult to turn into a command file or use with GREP. Does anyone find this to be a problem? (The first person who suggests making it an option gets to implement it!) :-) Alan ================================================================================ Note 167.6 [RSX]BACKUP/LIST output to a file 6 of 9 EISNER::DELARISCH "Arnold S. De Larisch" 22 lines 28-APR-1988 13:24 -< [1,5] Traditional, [001005] Modern! >- -------------------------------------------------------------------------------- >> < Note 71.5 by EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" > >> -< More BRUDIR questions >- >> || >> [1,5] >> || Better! >> || >> || >> [001005] >> || BEST! >> Would you mind giving some reasons why you prefer "[001005]" >> over "[1,5]" for numbered directories? Remember, BRUDIR >> will be used by people who never use named directories. >> Does anyone else have an opinion? The rational behind my (humble?) opnion is that it seems more consistant with the named directory format. I like both of them ... I guess if you were born and raised on Pre-named directories (like me) you probably prefer [1,5] ... but I prefer 'modern' art ... thats why I choose [001005]. -Arnold (In a Very Silly Philosophical Mood) ================================================================================ Note 167.7 [RSX]BACKUP/LIST output to a file 7 of 9 EISNER::RICE "Gary Rice" 12 lines 28-APR-1988 20:10 -------------------------------------------------------------------------------- >> || >> [001005] >> || BEST! >> Would you mind giving some reasons why you prefer "[001005]" >> over "[1,5]" for numbered directories? Remember, BRUDIR... Alan, forgive me if I suggest something "crude", but this is EXACTLY how it is done on the PRO, a system that had Named Directories 5 years before M+ did. Gary ================================================================================ Note 167.8 [RSX]BACKUP/LIST output to a file 8 of 9 EISNER::SIMONS "Paul, Not that CONVEX!" 3 lines 4-MAY-1988 17:13 -< Another Vote >- -------------------------------------------------------------------------------- I vote for [001054]. It is closer to reality (001054.DIR), and it seems that M+ is moving away from numbered directories, to named directories. ================================================================================ Note 167.9 [RSX]BACKUP/LIST output to a file 9 of 9 EISNER::BRUCE 11 lines 23-JUN-1988 12:37 -< use VMS set host for bru listing >- -------------------------------------------------------------------------------- -< BACKUP/LIST output to a file >- >> ...or DEC did a really dumb implementation. (of course!) >> Anybody have any ideas? This is very obvious, and limited to being networked to a VAX, but it is what I always do, and if it helps is worth suggesting: SET HOST/LOG=bru.lis rsxnod done from any connected vax  ================================================================================ Note 168.0 [PRO300]Access to PDL 2 replies EISNER::RICE "Gary Rice" 9 lines 28-APR-1988 20:06 -------------------------------------------------------------------------------- The Laboratory Data Products system MODEM phone number is once again answering the call with a friendly SQEEEEELLLL", but the Username (PDL) and Password (PDL) don't work. Has the PDL account been re-activated or is this just a co-incidence and I am actually getting a system that I have no business getting? Gary ================================================================================ Note 168.1 [PRO300]Access to PDL 1 of 2 EISNER::HERDELL 4 lines 28-NOV-1988 11:21 -< LDP Dialup?? >- -------------------------------------------------------------------------------- Gary, I have never heard of LDP dialup ... Was this ever resolved? Tnx ... ================================================================================ Note 168.2 [PRO300]Access to PDL 2 of 2 EISNER::RICE "Gary Rice" 18 lines 29-NOV-1988 08:45 -------------------------------------------------------------------------------- > I have never heard of LDP dialup ... Was this ever resolved? Just a short update. At Fall Symposium, I stopped by the LDP booth on the exhibit floor and asked about the system. There were 5 people from DEC standing around. Only 1 of them had the vaguest idea about what I was referring to. When I mentioned the "Sysop's" name (Bernie Eiben), that drew a little better response. He is still with DEC, but working at a different location and a different group. They suggested that I call the main DEC switchboard in Maynard and ask for him. I haven't yet done that, however. Gary  ================================================================================ Note 169.0 [RSX]M-Plus, VMS, and DECnet 1 reply EISNER::OSUDAR "John Osudar" 22 lines 4-MAY-1988 15:23 -------------------------------------------------------------------------------- We just had something peculiar happen while trying to do a file copy from a VMS V4.7 system to an M-Plus V3.0E system. For reasons that I'd rather not get into, the default network block count (SET RMS_DEFAULT/NETWORK_BLOCK_COUNT) on the VMS system was set to its maximum value, 127. With that setting, attempts to copy a file to M-Plus using VMS COPY would fail. (Also, attempts to open a file from Fortran across DECnet would fail.) Other DECnet operations, such as DIRECTORY, or even OPEN/WRITE from DCL, would work fine. COPY (and the program OPEN) would hang forever, with no activity on either end (but with FAL active on M-Plus). Once I discovered the network block setting was 127, I set it down to its default (8), and lo and behold, the COPY (and program OPEN) worked fine. In fact, any value up to 63 would work, and any value over 63 wouldn't. Now, since 63*512 bytes is 32256, and 64*512 bytes is 32768 (or -32768 in sixteen bits), it would appear that while trying to establish the connection between the VMS program and RSX FAL, FAL is interpreting the proposed buffer size as a negative, and is hanging forever without responding. (The logical link IS created, and will continue to exist forever and ever...) The question is: is this a bug in the M-Plus code? (Or is this RSX's way of punishing VMS users? ;-{) ================================================================================ Note 169.1 [RSX]M-Plus, VMS, and DECnet 1 of 1 EISNER::WYANT "Tom Wyant" 7 lines 14-NOV-1988 13:56 -< A day late and a dollar short ... >- -------------------------------------------------------------------------------- DAP has had a number of interesting bugs around the sign bit over the years... One version of FAL displayed negative block allocations for files between 32768 and 65535 blocks. >65535 got a DAP error. In fact, the whole thing was a DAP problem, and took a couple releases to fix. So... Stupid recommendation #1: Submit an SPR.  ================================================================================ Note 170.0 [RSX]RVT where are you? 3 replies EISNER::MERUSI 7 lines 5-MAY-1988 08:34 -------------------------------------------------------------------------------- Does anyone know how to build the task RVT. RVT allows RSX users to log into VAX/VMS systems. We have a copy of RVT that's been floating around for about 6 years now, and I figured I should rebuild it one of these days. I can find no references to RVT anywhere in any of the DEC RSX DECnet manuals, and the person who originally built RVT 6 years ago is not around. I would appreciate hearing from anyone who has had experience with RVT. Thanx. ================================================================================ Note 170.1 [RSX]RVT where are you? 1 of 3 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 1 line 5-MAY-1988 09:27 -< RVT isn't the only way, but... >- -------------------------------------------------------------------------------- RVT is an unsupported product that comes on the DECnet release kit. ================================================================================ Note 170.2 [RSX]RVT where are you? 2 of 3 EISNER::CETRON 4 lines 5-MAY-1988 16:10 -< ..check the kit.... >- -------------------------------------------------------------------------------- Instructions should be somwwhere in [200,200] ================================================================================ Note 170.3 [RSX]RVT where are you? 3 of 3 EISNER::BRUCE 10 lines 23-JUN-1988 12:49 -< do you need RVT? >- -------------------------------------------------------------------------------- >>I would appreciate hearing from anyone who has had experience >>with RVT. Thanx. As has already been answered, RVT (and other stuff) in in [200,200]unsgen.cmd. BUT are you really on an old system and can't use a new M+ Decnet? If you are about to do a new netgen on an M+ system you need not be looking for RVT as you can now simply say: SET HOST vax UNSGEN.cmd IS worth running if for nothing else than to make CEDUMP.tsk.  ================================================================================ Note 171.0 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 9 replies EISNER::KILLEEN "Jeff Killeen" 9 lines 7-MAY-1988 10:37 -------------------------------------------------------------------------------- Is anyone using a SPECTRA 501, SIGMA SDC-RQ, or WEBSTER SMD disk controller? These are all the same board. I am getting some strange timming results with board under RSTS and I want to see if it is the board or RSTS. With a CDC 9715-515 doing 30K sequential gets takes 390 seconds with cache on and 576 seconds with cache off. The problem is with the older SPECTRA-25 board it only takes 187 seconds. This is due to either the board, MSCP overhead, or the RSTS driver. If the board times out the same under RSX then we can eliminate the RSTS driver. ================================================================================ Note 171.1 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 1 of 9 EISNER::KILLEEN "Jeff Killeen" 14 lines 7-MAY-1988 11:20 -< ANOTHER WAY OF TESTING THE DRIVER >- -------------------------------------------------------------------------------- I would be interested in some other RSX timmings UNDER RSTS: CPU DISK TIME ----- ----- ---- 11/44 RA80 551 seconds 11/44 RA81 531 Again this for 30K sequential gets with no CPU caching ================================================================================ Note 171.2 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 2 of 9 EISNER::KENNEDY "Terry Kennedy" 13 lines 7-MAY-1988 19:39 -< More info? >- -------------------------------------------------------------------------------- > with the older SPECTRA-25 board it only takes 187 seconds. What emulation is the Spectra-25? Do either of these boards document the interleave factor used? I haven't used any of these boards, but I have found that, given identical controllers and drives, MSCP is faster than RM/RP. The tests were done by changing the microcode on the controller - the exact same board, cables and drive were used for both RP and RA emulation tests (without reformatting the drive). Of course, this is for a particular controller, under RSTS 9.5, and 'your actual mileage may vary'. ================================================================================ Note 171.3 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 3 of 9 EISNER::KILLEEN "Jeff Killeen" 3 lines 7-MAY-1988 22:53 -< SOME MORE INFO >- -------------------------------------------------------------------------------- SPECTRA-25 is RM and SPECTRA 501 is MSCP. Neither board is interleaved. Both can handle transfer rates in excess of the CDC 9715-515. ================================================================================ Note 171.4 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 4 of 9 EISNER::KENNEDY "Terry Kennedy" 16 lines 8-MAY-1988 02:07 -< Ummm... >- -------------------------------------------------------------------------------- > Neither board is interleaved. You mean both write sectors consecutively on disk? If so, that may be your problem. Medium-older boards usually used 2901-based logic which was quite fast, but a bear to program. Newer boards generally use 'simple' microcontroller chips (8031, 8048, 63705, etc.) in con- junction with intelligent custom chips. The only drawback to this is that with the *very* short time between sectors on a SMD drive, you may wind up missing the next sector and have to wait for the desired sector to spin around again. That is why the newer boards generally have either a (slightly) smaller number of sectors (more space between) or a programmable interleave. Some, like the Andromeda SMDC, are *completely* con- figurable (Don't like the firmware? Run one of the alternates - it's all in EEPROM!) ================================================================================ Note 171.5 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 5 of 9 EISNER::KILLEEN "Jeff Killeen" 13 lines 8-MAY-1988 09:11 -< WHO NEEDS INTERLEAVES WHEN YOU READ EVERY 4TH BLOCK? >- -------------------------------------------------------------------------------- > You mean both write sectors consecutively on disk? If so, that may > be your problem. Medium-older boards usually used 2901-based logic > which was quite fast, but a bear to program. Newer boards generally > use 'simple' microcontroller chips (8031, 8048, 63705, etc.) in con- > junction with intelligent custom chips. The only drawback to this is > that with the *very* short time between sectors on a SMD drive, you > may wind up missing the next sector and have to wait for the desired > sector to spin around again. The SPECTRA 501 is cached and only has to read every fourth block (sector) in this test - that is why I am concerned by the results. If the timming comes back the same from an RSX system I will know for sure it is the board. ================================================================================ Note 171.6 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 6 of 9 EISNER::KENNEDY "Terry Kennedy" 8 lines 8-MAY-1988 21:16 -< Eh? >- -------------------------------------------------------------------------------- > The SPECTRA 501 is cached and only has to read every fourth block > (sector) in this test - that is why I am concerned by the results. Oh. From reading the original posting, '30K sequential gets', I assumed you were reading all blocks in a contiguous file. If this is not the case (every fourth block, as you say), then a number of other variables get introduced. Do you know if the problem ex- sists on a sequential contiguous read as well? ================================================================================ Note 171.7 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 7 of 9 EISNER::KILLEEN "Jeff Killeen" 11 lines 8-MAY-1988 21:36 -< DOES THIS EXPLAIN? >- -------------------------------------------------------------------------------- > Oh. From reading the original posting, '30K sequential gets', I > assumed you were reading all blocks in a contiguous file. If this > is not the case (every fourth block, as you say), then a number > of other variables get introduced. Do you know if the problem ex- > sists on a sequential contiguous read as well? As far as the system is concerned these are 30K sequential contiguous reads - since the controller reads four blocks at a time the next three blocks are in cache thus it is doing "real" disk read only on every fourth block and it reads four blocks at a time. ================================================================================ Note 171.8 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 8 of 9 EISNER::KENNEDY "Terry Kennedy" 11 lines 9-MAY-1988 05:30 -< Nope >- -------------------------------------------------------------------------------- > ... since the controller reads four blocks at a time the next three > blocks are in cache thus it is doing "real" disk read only on every > fourth block and it reads four blocks at a time. Nope - it may *seem* to be reading four blocks at a time in one request, but that is four *discrete* operations to the disk, still. If the con- troller can't get the next read posted in time, it will take you four rev's to read the four blocks. Or, you might make it sometimes and not others. Caching won't help a slow controller. Trust me - I used to write the microcode for these thingies... ================================================================================ Note 171.9 [RSX]HELP WITH CONTROLLER SMD CACHING CONTROLLER 9 of 9 EISNER::KILLEEN "Jeff Killeen" 0 lines 9-MAY-1988 07:47 -< HMMMMM,,,,,, (BUT I AM STILL CURIOUS TO SEE AN RSX TIMMING) >- --------------------------------------------------------------------------------  ================================================================================ Note 172.0 [RSX]DECnet file creation dates 2 replies EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 4 lines 8-MAY-1988 11:54 -------------------------------------------------------------------------------- Does the current version of RSX DECnet preserve file creation dates on file transfers (like VMS DECnet)? Alan ================================================================================ Note 172.1 [RSX]DECnet file creation dates 1 of 2 EISNER::FRIEDBERG "Carl Friedberg, Rocket Science In" 8 lines 26-MAY-1988 01:11 -< see release notes >- -------------------------------------------------------------------------------- {< Note 75.0 by EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" > { -< DECnet file creation dates >- { {Does the current version of RSX DECnet preserve file creation {dates on file transfers (like VMS DECnet)? Alan, there is information on this topic in the DECnet 4 release notes ================================================================================ Note 172.2 [RSX]DECnet file creation dates 2 of 2 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 10 lines 26-MAY-1988 11:50 -< Dates are preserved >- -------------------------------------------------------------------------------- >> {Does the current version of RSX DECnet preserve file creation >> {dates on file transfers (like VMS DECnet)? >> >> Alan, there is information on this topic in the DECnet 4 release >> notes Since I don't have the release notes, I asked at the symposium. The answer was "Yes". Alan  ================================================================================ Note 173.0 [RT11]CoProcessor RT11 7 replies EISNER::TINKELMAN "Bob Tinkelman - CCA" 11 lines 26-MAY-1988 12:31 -------------------------------------------------------------------------------- At Cincinnati, there were people talking about Coprocessor RT products. That is, RT11 running on a KXJ11-C board, plugged into a Q-bus, not as its main host. Did anyone attend sessions, talk to DEC developers, or in any other way learn much about this product? How many KXJ11-Cs are supported on the same Q-bus? Does it run on KXT11-C also? Is it hosted under RT11 (say on an 11/73) as well as under VMS (say on a microVAX II)? Can it coexist with CoProcessor RSX? If so, what are the restrictions? What's its status? At field test? More generally, what are the tradeoffs between using RT and RSX in this environment? ================================================================================ Note 173.1 [RT11]CoProcessor RT11 1 of 7 EISNER::BRIDGE "Adam Bridge" 20 lines 11-JUN-1988 01:53 -< RT-11 on IOP >- -------------------------------------------------------------------------------- DIGITAL made a program announcement of VAX RT-11 ie RT-11 running on the KXJ-11CA in Anaheim. In Cincinnati they essentially repeated the same information. This product essentially makes a VAX into a big fat peripheral - acting as a server for RT-11 virtual disks (which are part of the VMS file structure), booting RT-11 onto the IOP, shutting down the IOP, and other services. A user on a VAX terminal will be able to use some form of SET HOST command to attach to the console terminal of the IOP. The IOP will be able to access files in the host's native file system. The system will also run with a Q-bus PDP-11 host running RT-11. There are also synchronization and mailbox services available that are managed through the host system. Since the product wasn't announced it isn't in field test. Adam ================================================================================ Note 173.2 [RT11]CoProcessor RT11 2 of 7 EISNER::CROWELL 12 lines 13-JUN-1988 04:10 -< RT & RSX on IOP >- -------------------------------------------------------------------------------- Adam hit on all the salient features of the Co-processor RT-11. As to its comparison to the RSX product, I speak from second-hand information only inasmuch as I have no first-hand experience with the RSX co-processor product. Apart from the normal advantages RT-11 has over RSX, it is my understanding that the RSX product supports only one co-processor and has no support for the on-board devices (serial ports, parallel port, timers, DMA controller). The RT-11 product supports up to 14 boards (if you have enough power and cooling) and sports device handlers for the on-board stuff. ================================================================================ Note 173.3 [RT11]CoProcessor RT11 3 of 7 EISNER::CETRON 10 lines 13-JUN-1988 19:18 -< Minor RSX clarification >- -------------------------------------------------------------------------------- 1. I don't know of any RSX limits to the number of boards....maybe I will try to find them :-) 2. If RSX (Native) has a driver for any of the 'other' stuff on the kxj, it should run on the coprocessor - I KNOW the serial ports do just fine. -ed ================================================================================ Note 173.4 [RT11]CoProcessor RT11 4 of 7 EISNER::MCALLISTER "Brian McAllister" 10 lines 14-JUN-1988 18:28 -< Will we really have RT under RT? >- -------------------------------------------------------------------------------- >> The system will also run with a Q-bus PDP-11 host running RT-11. Does this really mean an RT co-processor running in an RT host? If so, what kind of support is there for getting services from the host (and its peripherals)? Brian ================================================================================ Note 173.5 [RT11]CoProcessor RT11 5 of 7 EISNER::TINKELMAN "Bob Tinkelman - CCA" 14 lines 14-JUN-1988 21:02 -< CPR - clarifications of clarifications >- -------------------------------------------------------------------------------- RE: < Note 12.3 by EISNER::CETRON > -< Minor RSX clarification >- The following are based on my memory of Brian MacCarthy's remarks at the CPR sessions at a recent Symposia (at least at one of the most recent 4-5): 1. As CPR's strategy for getting at KXJ on board memory is to "map it all", it's not really reasonable to put more than 4 KXJ's running CPR on one Q bus. 4 boards * 512K bytes each = 2 meg = 1/2 of Q-bus space! 2. CPR is distributed without any drivers (without any supported drivers?) for the onboard devices. However, you can certainly write your own. At least that was DEC's plan at the time of the presentations. If they've changed their mind, I haven't seen it in any official source. ================================================================================ Note 173.6 [RT11]CoProcessor RT11 6 of 7 EISNER::DELARISCH "Arnold S. De Larisch" 7 lines 15-JUN-1988 14:50 -< Bob's .-1 note is correct! >- -------------------------------------------------------------------------------- I believe Bob to be correct ... there is a direct mapping of CPR memory to host processor memory. Further there are NO Digital supplied device drivers ... but you could always 'roll your own'! Please remember this is Coprocessor RSX not an RT coprocessor! -Arnold ================================================================================ Note 173.7 [RT11]CoProcessor RT11 7 of 7 EISNER::CROWELL 21 lines 16-JUN-1988 03:35 -< RT-11/RT >- -------------------------------------------------------------------------------- >> What kind of support is there for getting services from the host >> (and its peripherals)? I'm not sure I understand the question. The "disks" for the RT-11 system on the co-processor are either files on the host system that look like RT-11 logical disks (but need not be mounted as such) or actual RT-11 disks. (i.e any RT-11 file-structured device may serve as a unit of the "KS" device. The "KP" device which permits access to host directories on the VMS hosts, similarly "mounts" to devices on the RT-11 host. The line printer driver on the co-processor winds up sending its output to the host's spooler(RT) or a print queue (VMS). There're mailbox services so that programs running on different IOP's can send messages to each other or to programs running on the host. (Remember that the RT-11 host can be running up to 8 jobs - one of which is the coprocessor server and one is the print spooler.) (access to the host's magtape is not likely to show up in V1.)  ================================================================================ Note 174.0 [RSX]Any truth to DEC C rumors? 4 replies EISNER::TACKETT 4 lines 4-JUN-1988 17:30 -------------------------------------------------------------------------------- There have been rumors that DEC was working on a PDP-11 C compiler (perhaps started by the column "Let's C now" in an issue of DEC Professional a few months back). Was there any word about such a project at the Spring symposium? Does anyone know anything about such a project? ================================================================================ Note 174.1 [RSX]Any truth to DEC C rumors? 1 of 4 EISNER::KILLEEN "Jeff Killeen" 3 lines 4-JUN-1988 18:12 -< PLEASE REMEMBER >- -------------------------------------------------------------------------------- A reminder that no non-disclosure information should be placed on this system. Only information that is publicly available should be posted. ================================================================================ Note 174.2 [RSX]Any truth to DEC C rumors? 2 of 4 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 15 lines 5-JUN-1988 13:33 -< They sort of said they were working on it >- -------------------------------------------------------------------------------- >> There have been rumors that DEC was working on a PDP-11 C compiler (perhaps >> started by the column "Let's C now" in an issue of DEC Professional a few >> months back). Was there any word about such a project at the Spring >> symposium? Does anyone know anything about such a project? I was in a session at Cincinnati where a DEC representative was asked about their PDP-11 C compiler. The answer was evasive, but indicated that you shouldn't expect anything for AT LEAST six months, if then. My personal opinion is that I would be surprised to see ANY new language support for the PDP-11 at this stage in its life. However, stranger thing have happened before. Alan ================================================================================ Note 174.3 [RSX]Any truth to DEC C rumors? 3 of 4 EISNER::LAMBERT_M "Mike Lambert" 2 lines 16-JAN-1989 11:48 -< No C (for IAS, and .?.) >- -------------------------------------------------------------------------------- Per a conversation (Jan 89) with the IAS Product Manager at DEC, there is no such thing as a PDP11 C compiler. ================================================================================ Note 174.4 [RSX]Any truth to DEC C rumors? 4 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 6 lines 16-JAN-1989 19:44 -< Beta Test offer = 'its coming' >- -------------------------------------------------------------------------------- DEC still didn't say they were working on it, but they DID say that those interested in being BETA test sights for SUCH a product would do well to contact some named person that I think wasn't in that session, but who was there in Anaheim. Sorry I don't remember the name. Its the same general group as F77.  ================================================================================ Note 175.0 [RSX]Virtual Disk Drivers - need help 3 replies 0 lines 6-JUN-1988 16:08 -------------------------------------------------------------------------------- ================================================================================ Note 175.1 [RSX]Virtual Disk Drivers - need help 1 of 3 EISNER::CETRON 8 lines 11-JUN-1988 15:05 -< Try Gary Maxwell for latest. >- -------------------------------------------------------------------------------- Send mail to maxwell (on this system) who I believe has written vf: and can tell you the most about it..... -ed (ps. VF: is an upgrade to VE: which is an upgrade to VD:) ================================================================================ Note 175.2 [RSX]Virtual Disk Drivers - need help 2 of 3 EISNER::PERRY "Bob (Sky Scum) Perry" 2 lines 1-SEP-1988 18:22 -< Do they still work...? >- -------------------------------------------------------------------------------- On this topic, does anyone know if the virt. disk drivers work under M+ v4.0 ? If so, which one ? ================================================================================ Note 175.3 [RSX]Virtual Disk Drivers - need help 3 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 11 lines 1-SEP-1988 21:32 -< old VD works on M+4.1 >- -------------------------------------------------------------------------------- >> On this topic, does anyone know if the virt. disk drivers work >> under M+ v4.0 ? If so, which one ? I have built and run the OLD VDDRV we always use on M+4.1 successfully. Some have been caught on recent sys versions because they didn't have DV.MSD set in U.CW1. Ours must have been set long ago, so we didn't get caught. Hardly ever touch the others, but would use VFDRV if it ever gets AVD /LI, but would assume they should simply all just work.  ================================================================================ Note 176.0 [RT11]File transfer 1 reply EISNER::HAHN 7 lines 8-JUN-1988 17:08 -------------------------------------------------------------------------------- Transfering files between RT11 systems I would like to do away with our "sneaker net". I understand that the possibility of using DRV11 on each system and cross coupling the 16bit I/O there is some DECUS software availabel to effect file transfer. I need guidance, on finding such. We run RT11 V05.01B RT11FB. Pierre ================================================================================ Note 176.1 [RT11]File transfer 1 of 1 EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 8-JUN-1988 17:58 -< Have you looked into Kermit? >- -------------------------------------------------------------------------------- >> < Note 13.0 by EISNER::HAHN > >> -< File transfer >- >> >> Transfering files between RT11 systems >> >> I would like to do away with our "sneaker net". I understand that >> the possibility of using DRV11 on each system and cross coupling >> the 16bit I/O there is some DECUS software availabel to effect file >> transfer. I need guidance, on finding such. We run RT11 V05.01B >> RT11FB. Pierre Pierre, Have you looked into running KERMIT? I don't remember if it works using the FB monitor or if you need the XM monitor. This would be my first choice! -Arnold  ================================================================================ Note 177.0 [RSX]Anybody remember Able QuadrAsync patch? 4 replies EISNER::OSUDAR "John Osudar" 19 lines 15-JUN-1988 18:24 -------------------------------------------------------------------------------- The request attached below comes from a colleague of mine who is not currently on DECUServe. Can anybody help? ------------------------------------------------------------------------ Remember when RSX-11M V3.2 came out? Back then, when DZs cost a fortune and DHs cost even more, Able sold a nice board called a QuadrAsync that had four DL11-type interfaces on it. It was a single Unibus board with a single Unibus load for four terminals. Unfortunately, there was a slight difference between the QuadrAsync and a genuine DEC DL11. The old half duplex terminal driver didn't care, but the full duplex driver did. Able, if I remember right, fixed the design pronto, but early vintage QuadrAsyncs needed a patch to module TTYL to work correctly. Over the years, we took DZs out of our VAX, put them in PDP-11s, removed the QuadrAsyncs, and lost the patch to TTYL. Now we have to put a QuadrAsync back into a PDP-11, and I can't find the patch. Does anyone remember that patch? ================================================================================ Note 177.1 [RSX]Anybody remember Able QuadrAsync patch? 1 of 4 EISNER::KENNEDY "Terry Kennedy" 4 lines 15-JUN-1988 20:54 -< Call Able? >- -------------------------------------------------------------------------------- > Can anybody help? Have you tried calling Able - they are still around and seem quite willing to support even ancient stuff... ================================================================================ Note 177.2 [RSX]Anybody remember Able QuadrAsync patch? 2 of 4 EISNER::HASSINGER "Bob Hassinger" 9 lines 16-JUN-1988 11:25 -< Me too - call Able... >- -------------------------------------------------------------------------------- I had the hardware and had the problem at that point. I called Able and they sent me a new board the next day, allowing me to return the old one when it was convenient - best response I ever had from a third party vendor! I do not recall a software patch ever being mentioned. Yes, I would start by calling Able - they have been good as they come and I think you have a good chance going that route. Bob H ================================================================================ Note 177.3 [RSX]Anybody remember Able QuadrAsync patch? 3 of 4 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 11 lines 17-JUN-1988 14:59 -< The fix is in HARDWARE_HELP >- -------------------------------------------------------------------------------- >> Unfortunately, there was a slight difference between the QuadrAsync and >> a genuine DEC DL11. The old half duplex terminal driver didn't care, >> but the full duplex driver did. Able, if I remember right, fixed the >> design pronto, but early vintage QuadrAsyncs needed a patch to module >> TTYL to work correctly. As usual, I found the fix in my archives. However, it is a hardware fix, so I will put your question and my reply in HARDWARE_HELP. Alan ================================================================================ Note 177.4 [RSX]Anybody remember Able QuadrAsync patch? 4 of 4 EISNER::MCCARTHY 13 lines 21-JUN-1988 17:06 -< Almost compatible. >- -------------------------------------------------------------------------------- As I recall, the "slight incompatibility" had to do with the Quadrasync board not killing a pending interrupt request when interrupts were disabled. Another popular "slight incompatibility" is to interrupt whenever both IE and RDY are both 1s, rather than when the last of the two transits to 1. (The MXV11 does this). If it's the first of those two, get the boards fixed. It's an accident looking for a place to happen! -Brian  ================================================================================ Note 178.0 [RSX]Memory disk and DECnet 3 replies EISNER::FRIEDBERG "Carl Friedberg, Rocket Science I" 21 lines 21-JUN-1988 20:35 -------------------------------------------------------------------------------- RSX Memory Disk Problem: We are using the FXDRV from the DECUS tapes, with some local mods to let it work on V4 (e.g., it is now vectored). I have already set the DV.MSD bit in the UCB, and have just finished a slight patch during Powerfail (where the initialization code is) to put in the disk geometry (assuming 32 tracks per sector, one surface, and fudge in the appropriate number of cylinders from the partition size) into U.PRM. All this works fine, and the driver works same as it did in V3.0 of Mplus. We use it as a single directory device, with a size of 3584. blocks. However, we can't make this work with DECnet. That is, for certain small, temporary files, we want to transfer to/from the memory disk. However, all attempts to do this fail. When we use NFT, for instance, we get the error something like NFT cannot access FX:; FCS error code 6 (which I assume is IE.SPC -- illegal buffer????). Even an NFT FX0:/LI fails with a similar message: NFT -- error in reading directory FX:, FCS error code 6. Is this just due to the fact that we use FX as a single directory device? Or is there some other explanation? Any help would be appreciated. ================================================================================ Note 178.1 [RSX]Memory disk and DECnet 1 of 3 EISNER::BRUCE 11 lines 23-JUN-1988 13:13 -< extra bit set? >- -------------------------------------------------------------------------------- >>Or is there some other explanation? This sounds horribly familiar. VDdrv used to have problems with NFT, etc. because VDdrv had originally been written to work even on such things as RP02/03s that required I/O buffers be aligned on a double word boundary. I can't seem to find the FX source we had on disk, but a ('84) mod to an old VDDRV's VDTAB shows byte U.CTL's UC.LGH (the 2 low order bits) changed from 3 to 1 to allow any word alignment. I even think this got SPR'd (I will now go look at my old unanswered file). ================================================================================ Note 178.2 [RSX]Memory disk and DECnet 2 of 3 EISNER::CLARK_W 12 lines 19-JAN-1989 09:07 -< Does FX: Work Under M-Plus V4.1? >- -------------------------------------------------------------------------------- Is anyone using the FX: driver (memory resident disk) under M-Plus V4.1? If so, did you have to modify the original source? I have been using the driver under version 3 and version 4.0 with no problems. When I upgraded to 4.1, however, I could not get it to work. The driver builds and loads fine. I mount it foreign with no problem. Then I try to run BAD and it aborts with a memory protect violation. I try to INI the drive and I get a message that says the allocation for SYS file exceeds volume limit. ================================================================================ Note 178.3 [RSX]Memory disk and DECnet 3 of 3 EISNER::CLARK_W 8 lines 13-MAR-1989 19:56 -< FX driver fix under M+ V4.1 and later. >- -------------------------------------------------------------------------------- I have found and fixed the problem that I spoke about in the previous note. The source for the FX driver contains a call to $srnam. This routine was modified for M+ V4.1. The driver can be corrected by calling $srmai instead of calling $srnam. Details of the change to $srnam can be found in the M+ V4.1 Release Notes on page 1-14. More information can be obtained by looking at the exec code in module PLSUB.  ================================================================================ Note 179.0 [RSTS]An old timer's question... 4 replies EISNER::SCOPELLITI "Pat 'Enzo' Scopelliti" 12 lines 24-JUN-1988 00:22 -------------------------------------------------------------------------------- Here's a question from a former RSTS manager (does V5B-24 count as old?). I'm now in VAX land - but... has RSTS every changed the way pseudo keyboards were inserted into the KB numbering sequence? i.e. If you genned 4, your first KB was KB5. I was at a RSTS feedback session where this was asked for, and the response was "We'd like to move the PK defintions, but there's a comment in the code saying 'Whatever you do, don't move these!' We don't know who wrote it or why, but no one's had the guts to move it." Well.. has anyone had the guts? ================================================================================ Note 179.1 [RSTS]An old timer's question... 1 of 4 EISNER::KENNEDY "Terry Kennedy" 22 lines 24-JUN-1988 02:44 -< Possible but not pretty >- -------------------------------------------------------------------------------- > I'm now in VAX land - but... has RSTS every changed the way pseudo > keyboards were inserted into the KB numbering sequence? Well, in Cinci when DEC discussed LAT and other new features for the (forthcoming) RSTS V9.6, it was mentioned that PK's are now dynamic and map in after your real KB's. Of course, you can still gen static PK's if your application needs them. But more to the point, why do you want to move them? You could always open them independent of KB number by opening 'PKxx'. Also, RSTS since V9 has had 'controller' syntax, sort of like VMS, in that PK's are KBDxx, DZ's are KBGxx, DHV's are KBHxx, etc. Anyway, if you are bound and determined you will need the source kit, and it *is* possible. In short, you need to modify the references in TBL, add a new table to handle .FSSing the controller syntax into the new order while preserving the old controller syntax letters, modify INIT to change the jam list order, etc. In other words, it's possible but it isn't pretty. And remember, DL's must be first because KB0 is a 'sacred' device name. If you want more info, drop me a Mail message (SEND/AUTHOR here). ================================================================================ Note 179.2 [RSTS]An old timer's question... 2 of 4 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 24-JUN-1988 08:12 -< WHY DO YOU WANT TO MOVE THEM? >- -------------------------------------------------------------------------------- ================================================================================ Note 179.3 [RSTS]An old timer's question... 3 of 4 EISNER::SCOPELLITI "Pat 'Enzo' Scopelliti" 6 lines 28-JUN-1988 23:29 -< A slight mis-interpretation. >- -------------------------------------------------------------------------------- Thanks for the info.... The last that I touched RSTS/E was V7.2 (sigh!) At the time we had the problem that changing the number of PKs changed the first real KB number (besides KB0). So, if you had programs that were KB specific, you had a problem. Like I said... just a question from a FORMER RSTS manager. ================================================================================ Note 179.4 [RSTS]An old timer's question... 4 of 4 EISNER::HORN "Larry Horn, Millsaps College" 8 lines 29-JUN-1988 02:41 -< please use *.0 topics if appropriate >- -------------------------------------------------------------------------------- Anyone, please scan (DIR) the *.0 topics that Jeff has set up to see if your question or comment belongs under one of them before starting a new discussion. A COPY of 41.* has been moved to discussion 7.* and 41.* has been set to NOWRITE. Thanks.  ================================================================================ Note 180.0 [RSX]RSX Spring '88 tape is out 2 replies EISNER::BRUCE "Barton F. Bruce / CCA" 14 lines 24-JUN-1988 12:28 -------------------------------------------------------------------------------- The SPRING '88 RSX SIG tape has arrived. It all fits onto a very small tape reel at 1600 bpi and fits on the smallest I have at 6250. If anyone in the NYC or Boston lugs (or anyone else either in a big rush or not in a lug that still gets the RSX tape) wants a copy, send me a tape and specify 800, 1600, or 6250. Return postage is appreciated. Send to (note new address for our Camb. Ma. office): Barton F. Bruce Cambridge Computer Associates, Inc. 92 Sherman Street Cambridge, Ma. 02140 (617) 868-1111 ================================================================================ Note 180.1 [RSX]RSX Spring '88 tape is out 1 of 2 EISNER::MAYHEW "Bill Mayhew" 2 lines 24-JUN-1988 15:39 -< What's on it? >- -------------------------------------------------------------------------------- How 'bout a table of contents (i.e. a directory listing) posted here? Moderators -- is this appropriate? ================================================================================ Note 180.2 [RSX]RSX Spring '88 tape is out 2 of 2 EISNER::PERRY "Bob (Sky Scum) Perry" 5 lines 27-JUN-1988 12:29 -< Why settle for less... ? >- -------------------------------------------------------------------------------- It would be much easier if you would just contact your LUG chair to get a copy of the tape. It was only distributed as a 600' reel this time due to lack of submissions at Cincinnatti.  ================================================================================ Note 181.0 [RSX]Distributed System Management input needed No replies EISNER::KAPLAN "A Frenetic Fellow" 5 lines 25-JUN-1988 05:01 -------------------------------------------------------------------------------- I have been asked by a DEC friend of mine to collect some input on DISTRIBUTED SYSTEM MANAGEMENT. Given that we have some input into what may be the design or implementation phase of what may or may not become a product (or part of a product) some day, we need to help answer some questions. Please see note number 110 in the DEC_NETWORKING conference.  ================================================================================ Note 182.0 [RSX]Using DTR-11 Dates from FORTRAN 5 replies EISNER::RICE "Gary Rice" 11 lines 25-JUN-1988 11:20 -------------------------------------------------------------------------------- I am writing an application that needs to store various dates. I have Datatrieve-11 on the system, so I would like to take advantage of DTR's date manipulation capability. However, I don't feel comfortable with MACRO, so I am developing the application in my favorite high-level language (which is NOT COBOL). Is there any software in existence that will allow me to store dates as DTR compatible "clunks", but still allow me to manipulate the 64 bits of the date variable from my program (written in FORTRAN-77). I am using RSX11M+. Gary ================================================================================ Note 182.1 [RSX]Using DTR-11 Dates from FORTRAN 1 of 5 EISNER::LEDERMAN "Bart Z. Lederman" 10 lines 25-JUN-1988 20:50 -< It's been published in the newsletters. >- -------------------------------------------------------------------------------- There is a set of routines supplied as part of RMS-11 which will convert dates between ASCII strings and quadword binary values (which, by the way, are not unique to Datatrieve or VMS). There is also a module within Datatrieve which can be linked into your program if you keep the DTR-11 distribution kit on disk. The way to do both has been published in the newsletters, which are also available in the DECUS library, the VAX SIG tape, and a few past RSX SIG tapes. I can get exact issue dates if you need them. By the way, this method also works with IAS and RSTS/E. ================================================================================ Note 182.2 [RSX]Using DTR-11 Dates from FORTRAN 2 of 5 EISNER::RICE "Gary Rice" 11 lines 26-JUN-1988 09:10 -------------------------------------------------------------------------------- >< Note 82.1 by EISNER::LEDERMAN "Bart Z. Lederman" > > -< It's been published in the newsletters. >- > I can get exact issue dates if you need them. I have all of the issues of the "Big-One", but nothing before that. I will begin looking, but if you could point me in the right direction, I would appreciate it. Gary ================================================================================ Note 182.3 [RSX]Using DTR-11 Dates from FORTRAN 3 of 5 EISNER::LEDERMAN "Bart Z. Lederman" 2 lines 27-JUN-1988 07:56 -< Volume 1 Number 2 - October 1985 >- -------------------------------------------------------------------------------- You're in luck. The article was in the second issue of the "Big One". ================================================================================ Note 182.4 [RSX]Using DTR-11 Dates from FORTRAN 4 of 5 EISNER::RICE "Gary Rice" 15 lines 1-JUL-1988 14:16 -------------------------------------------------------------------------------- >< Note 82.3 by EISNER::LEDERMAN "Bart Z. Lederman" > > -< Volume 1 Number 2 - October 1985 >- > You're in luck. The article was in the second issue of the "Big > One". Well, it turns out that I lied. Upon reviewing my stack of issues, I found (having forgotten and remembered later) that I never got issues 2 and 3 of the Big One. I'm not sure why that happened, but it did. Do you have any alternatives? Gary ================================================================================ Note 182.5 [RSX]Using DTR-11 Dates from FORTRAN 5 of 5 EISNER::LEDERMAN "Bart Z. Lederman" 6 lines 1-JUL-1988 19:27 -< Some alternatives. >- -------------------------------------------------------------------------------- As mentioned, the last 3 or 4 VAX SIG Symposium tapes have the DTR/4GL SIG collection, which contains all issues of the newsletter from volume 0 through volume 7, so that would include the issue in question (our volume 7 is their volume 1). One of the RSX SIG tapes a year or so back also had the collection. And it's in the DECUS library. Or, check your local LUG.  ================================================================================ Note 183.0 [RT11]TCP/IP on RT-11 2 replies EISNER::PATTEEUW "Jack Patteeuw, Ford Motor Company" 15 lines 28-JUN-1988 10:20 -------------------------------------------------------------------------------- <<< EISNER::DUA0:[NOTES$LIBRARY]DEC_NETWORKING.NOTE;1 >>> -< DEC_NETWORKING >- ================================================================================ Note 111.0 TCP/IP on RT-11 1 reply EISNER::PATTEEUW "Jack Patteeuw, Ford Motor Company" 8 lines 27-JUN-1988 12:05 -------------------------------------------------------------------------------- We are looking for TCP/IP under RT-11 so that we can use FTP to download files from a Prime. Process Software sells such a package. Any opinions ? Any other vendors ? ================================================================================ Note 183.1 [RT11]TCP/IP on RT-11 1 of 2 EISNER::BILLING 29 lines 24-JUL-1989 14:19 -< TCP/IP on RT-11, etc >- -------------------------------------------------------------------------------- Jack, I've been looking at Process Software's TCP/IP software, too. I'm especially interested because you can talk to other operating systems somewhat transparently. I'm about ready to buy. Process Software's phone number is (800)722-7770. Terrance Mulryan can answer questions for you. If 800 number doesn't get him try (508)879-6994. They have an FTP package that will work on RT, TSX+, RSX and IAS. They tell me that there is a PC package available from someone called STP Software. I haven't found them yet. Another source tells me that a package from Execlan is in use here locally. Back to Process Software, they also have an ethernet terminal emulator called TELNET and a inter-task communications package called TCPIP for RT. Other solutions: Omnex Corp., (415)966-8400, has two packages available called EtherExchange and EtherDisk. These are a file transfer package and a file server package. They are RT and VMS only and I think NOT TCP/IP. There was a session given at the Spring 88 DECUS on Ethernet software by Roland Barnard, (505)844-5115, that covered both of these products. Since I need to do transfers between RT, RSX, VMS, PC-DOS and some H-P machines, it looks like I'm committed to the Process Software products. I have heard that DEC is interested in offering a product through cooperative marketing. I'll be interested to hear what others have to say as well. ================================================================================ Note 183.2 [RT11]TCP/IP on RT-11 2 of 2 EISNER::MCALLISTER "Brian McAllister" 8 lines 16-OCT-1989 21:43 -< TCP/IP for DOS >- -------------------------------------------------------------------------------- -< TCP/IP on RT-11, etc >- They tell me that there is a PC package available from someone called STP Software. ^^^ This is "FTP Software". They do have TCP/IP for PCs. Phone is (617) 246-0900. They are in Massachusetts.  ================================================================================ Note 184.0 [RSX]M+ 4.1 where are you?? 3 replies EISNER::BRUCE "Barton F. Bruce / CCA" 28 lines 30-JUN-1988 15:53 -------------------------------------------------------------------------------- If this is the wrong place to put this, sorry, and please move it. Better than a month ago now one of the RSX team said he had finished the M+ 4.1 kit to get it into SDC before he left for Cinncinatti. After calling local S/W contract types to find out the status today I got vague answers and so poked deeper into DEC's innards and got the following: 1) at one time, JUNE 30 (today) had been a targeted FCS date. 2) the young lady that cuts the tape (with all our addresses, etc. for SDC to ship to) hasn't because the product isn't ready yet. 3) 'they' (RSX developers, I suppose) havn't met the SDC requirements yet! On further probing this translates to: "they havn't provided the 'FIRE STORAGE TAPE and FICHE'", whatever that all is. What is going on? Does ANYONE know a good way to find RELIABLE data on FCS dates in general, or is everyone destined to harass they local contacts regularly. It would seem in everyone's interest if DEC could officially post the TRUTH in a timely manner and save customers and their own staff MUCH wasted phone time. ================================================================================ Note 184.1 [RSX]M+ 4.1 where are you?? 1 of 3 EISNER::KENNEDY "Terry Kennedy" 26 lines 30-JUN-1988 18:37 -< In defense of DEC >- -------------------------------------------------------------------------------- > It would seem in everyone's interest if DEC could officially post > the TRUTH in a timely manner and save customers and their own staff > MUCH wasted phone time. Speaking as someone who was once in the software writing business for (another) company... 1) There is often a long time between when a developer is done with the product and when it ships, because: a) Documentation must be updated b) Software and documentation must be reviewed by the Legal Department as well as the Standards Department. c) The support team must be trained on the new release d) The Duplication Department must schedule time on all supported media types to have all the kits ready at the same time. Speaking as a veteran DEC-watcher, and from viewing the DEC_NEWS_1 articles here... 2) Things like a major VMS release appear to busy-out the SDC (I know *I* wouldn't wnat to have any other orders while making up N thousnad VMS kits. 3) The *tentative* FCS dates posted by DEC_NEWS_1 have been rather reliable. Was the date you got from the SDC or from a developer? ================================================================================ Note 184.2 [RSX]M+ 4.1 where are you?? 2 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 8 lines 1-JUL-1988 17:18 -< where the dates were from >- -------------------------------------------------------------------------------- >>>> Was the date you got from the SDC or from a developer? A developer said he had rushed to just finish the kit to ship to SDC the day before he left for Decus. The tentative Jun 30 date was quoted not by SDC but by a more local type that answers customer software contract questions and hears rumors from undefined sources within Dec. ================================================================================ Note 184.3 [RSX]M+ 4.1 where are you?? 3 of 3 EISNER::MAYHEW "Bill Mayhew" 8 lines 2-JUL-1988 00:22 -< 30+ days: not enough >- -------------------------------------------------------------------------------- In my experience it actually takes more like 60 to 90 days for a product to get from the "allegedly released to SDC" state to the "no longer a rumor, it's in my hands" state. Some of this is due to some of the hoops SDC makes the developers jump through, I gather, which, since SDC is a Digital organization, probably change from time to time :-). I think the "mainstream" products that are in very active development with short release lifecycles probably do better than that.  ================================================================================ Note 185.0 [RSX][200,200]UNSGEN.CMD 7 replies EISNER::SIMONS "Paul, Not that CONVEX!" 5 lines 11-JUL-1988 12:17 -------------------------------------------------------------------------------- In note 73.*, [200,200]UNSGEN.CMD is mentioned. I am having problems getting DECnet to do what I want it to. My project involves downloading a propriatory operating system from a VAX 8200 to several PDP 11/70's. Is there any place I can find out more about how to use what's in UNSGEN.CMD? ================================================================================ Note 185.1 [RSX][200,200]UNSGEN.CMD 1 of 7 EISNER::WYANT "Tom Wyant" 26 lines 24-OCT-1988 17:47 -< Son of UNSGEN >- -------------------------------------------------------------------------------- >> In note 73.*, [200,200]UNSGEN.CMD is mentioned. I am having problems >> getting DECnet to do what I want it to. My project involves downloading >> a propriatory operating system from a VAX 8200 to several PDP 11/70's. >> Is there any place I can find out more about how to use what's in >> UNSGEN.CMD? UNSGEN.CMD is a command file that generates unsupported DECnet components. The recommended way to find out what's in it is to read it. If memory serves, it contains (at least) the following: VD: - Networks disk driver. Allows you to make a disk or file on another node look like a disk on your node. I tried it once, and could never dissociate the disk from the file afterwards. This is NOT the Ralph Stamerjohn VD:, and it does NOT allow tdisk or file sharing. VM: - Networks magtape driver. Like the above, only for tapes. it seems to work, but you will be underwhelmed by the throughput. VP: - Networks printer. Never tried it. RVT - "RMT" to VMS. Kind of flakey, tho maybe no worse than CTERM RST - Ditto for RSTS, but I haven't tried it. In summary, I don't think there is anything here to help you. ================================================================================ Note 185.2 [RSX][200,200]UNSGEN.CMD 2 of 7 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 25 lines 24-OCT-1988 21:07 -< Try NE017 from Anaheim >- -------------------------------------------------------------------------------- >>> In summary, I don't think there is anything here to help you. May not help the original problem, but UNSGEN also has PMR (poor mans router) and CEDUMP (Comm Exec DUMP). CEDUMP everyone should build, and occasionally run to get a glimps at the somewhat overwhelming number of different variables that keep Decnet running. This is the only way to get at some of the information. Getting back to the original MOP question, there was a LATE Thu night session at Anaheim about "Downline Loading using MOP" that I didn't attend. It was at 10:15 pm on Thursday and was NE017. UPS hasn't yet delivered my 3 crates of heavy paper, but I think it was given by Robert Gezeler (sp?) who writes some sort of RSX column in one of the trade mags. You may be able to get him to send you any handouts or xeroxes of slides, or order the tape for NE017 from Chesapeake Audio.Video Communications Inc., 6330 Howard Lane, Eldridge Maryland 21227. 301-796-0040 or FAX 301-379-0812. The RSX decnet manuals refer to the "Maint. Operations Protocol Spec" which presumably is published by Dec, but may be buried in some bigger Decnet spec. ================================================================================ Note 185.3 [RSX][200,200]UNSGEN.CMD 3 of 7 EISNER::KENNEDY "Terry Kennedy" 12 lines 25-OCT-1988 03:00 -< Reference manual cited >- -------------------------------------------------------------------------------- > The RSX decnet manuals refer to the "Maint. Operations Protocol > Spec" which presumably is published by Dec, but may be buried in > some bigger Decnet spec. "DECnet Digital Network Architecture Phase IV Maintenance Operations Functional Specification Order No. AA-X436A-TK, December 1983" Does this help? ================================================================================ Note 185.4 [RSX][200,200]UNSGEN.CMD 4 of 7 EISNER::SIMONS "Paul, Not that CONVEX!" 9 lines 26-OCT-1988 18:05 -< Downloading Blues >- -------------------------------------------------------------------------------- After we bought the rest of our DELUA's, I was finally able to try an 11/70 to 11/70 download - and discovered that, "You can't get there from here". More specifically, a "trigger" command will work, even though there are no Ethernet boot ROM's installed (?!), whereas the "load" command will not work at all. All this has been passed on to Colorado Support (always refered to as the Colorado Cowboys), who verified it, and generated an SPR to Engineering. Thanks for the info, I was sheduled to go to Anahiem, and wanted to attend that session. ================================================================================ Note 185.5 [RSX][200,200]UNSGEN.CMD 5 of 7 EISNER::SIMONS "Paul, Not that CONVEX!" 10 lines 26-OCT-1988 18:10 -< Downloading Blues >- -------------------------------------------------------------------------------- After we bought the rest of our DELUA's, I was finally able to try an 11/70 to 11/70 download - and discovered that, "You can't get there from here". More specifically, a "trigger" command will work, even though there are no Ethernet boot ROM's installed (?!), whereas the "load" command will not work at all. All this has been passed on to Colorado Support (always refered to as the Colorado Cowboys), who verified it, and generated an SPR to Engineering. Thanks for the info, I was sheduled to go to Anahiem, and wanted to attend that session. About CDUMP, I know this sounds wimpy, but do I just need to install and run it? ================================================================================ Note 185.6 [RSX][200,200]UNSGEN.CMD 6 of 7 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 10 lines 26-OCT-1988 22:48 -< invoking CEDump >- -------------------------------------------------------------------------------- >>>About CDUMP, I know this sounds wimpy, but >>>do I just need to install and run it? If you INS [5,54]CEDUMP, then you can say CED /HE for help or even CED /AL for ALL possible output, or anything in between, and when you are done you will be back at the mcr prompt. Or get to CED> (by simply typing CED if installed or RUN [5,54]CEDUMP) and you can type commands all day to each succeeding CED> until you hit ctl-. ================================================================================ Note 185.7 [RSX][200,200]UNSGEN.CMD 7 of 7 EISNER::SIMONS "Paul, Not that CONVEX!" 1 line 27-OCT-1988 17:59 -< But of course! >- -------------------------------------------------------------------------------- Ah, the joys of modern operating systems and their help files! Thanks!  ================================================================================ Note 186.0 [PRO300]POS Overlay Problem 3 replies EISNER::CROWELL "Shefth of the Fourth Order" 20 lines 14-JUL-1988 09:21 -------------------------------------------------------------------------------- I have a client at Rocky Flats, Colorado with a POS or F77 problem. POS Version 3.2 F77 Version 5.0 PRO-380 When program is overlayed he gets an odd-address trap, even though each of the subroutines in the overlays has been thoroughly wrung out and work if they're in the root. I don't have any more details at this time. Is there a known bug in F77 or the POS taskbuilder or overlay handler? Is it fixed in newer versions? Please leave info here, in MAIL, or call me at (916)756-3291. Thanks ================================================================================ Note 186.1 [PRO300]POS Overlay Problem 1 of 3 EISNER::RICE "Gary Rice" 18 lines 15-JUL-1988 09:30 -------------------------------------------------------------------------------- >< Note 25.0 by EISNER::CROWELL "Shefth of the Fourth Order" > > -< POS Overlay Problem >- > When program is overlayed he gets an odd-address trap, even though > each of the subroutines in the overlays has been thoroughly wrung out > and work if they're in the root. I have seen the same thing. The offending routine is a menu routine supplied with P/OS Toolkit. The Odd Address Trap occurs the second time that the routine is called during the execution of the program. The only thing that I have been able to do to fix the problem is put the offending routine in the root. Nothing else that I could come up with did any good. > Is it fixed in newer versions? There will be no more versions of P/OS. V3.2 was the last. Gary ================================================================================ Note 186.2 [PRO300]POS Overlay Problem 2 of 3 EISNER::CROWELL "Shefth of the Fourth Order" 2 lines 15-JUL-1988 09:53 -< Thanks, but... >- -------------------------------------------------------------------------------- Is there a name associated with the offending routine? What do I tell my client to avoid? ================================================================================ Note 186.3 [PRO300]POS Overlay Problem 3 of 3 EISNER::RICE "Gary Rice" 16 lines 16-JUL-1988 09:12 -------------------------------------------------------------------------------- > Is there a name associated with the offending routine? The call is part of the menu interface library (POSRES) and is the multiple choice dynamic menu routine (MMENU). I seem to recall that the DMENU routine (Single choice dynamic menu) has the same trouble. > What do I tell my client to avoid? I have successfully overlaid code that uses these routines, but success is random. The only way that I have had 100% reliability with the overlay problem is to put all calls to the offending routine(s) into the root segment of the overlay. Gary  ================================================================================ Note 187.0 [RSX]Say KS.UCB 1 reply EISNER::SIMONS "Paul, Not that CONVEX!" 13 lines 14-JUL-1988 17:43 -------------------------------------------------------------------------------- I'm trying to write a device driver for the old DV11 synchronous interface under M+. If anyone can spare me the grief, I'd sure appreciate it. Until then, I'm trying to figure out how to make use of the table of UCB's that might be at the end of my KRB's. In the infamous "Guide to Writing I/O Driver"(sic), there are all kinds of referances to this table (see page 4-45 KS.UCB, page 1-10 section 1.4.1, page 2-8 section 2.3.3, etc.), but, as usual, no solid examples. (It sure would be nice if it said, "See this Digital driver for an example of this". I know, dream on.) The DV11 is (was?) known for it's spurious interrupts, so I need to validate all interrupts. A simple way to do this would be to set the UCB address in the KRB odd, and then check for oddness in the ISR. But does some exec routine use this table? Help? ================================================================================ Note 187.1 [RSX]Say KS.UCB 1 of 1 EISNER::SIMONS "Paul, Not that CONVEX!" 4 lines 22-MAR-1989 16:23 -< It works! >- -------------------------------------------------------------------------------- Drivers are a wonderful thing. If anyone cares, I have the driver up and running. No EXEC routines use the table of UCB's, unless you're writting a disk driver. So, in the average case, you can use it for whatever you want.  ================================================================================ Note 188.0 [RSTS]RSTS/E <==> Loyalty 2 replies EISNER::SCOPELLITI "Pat 'Enzo' Scopelliti" 23 lines 22-JUL-1988 00:56 -------------------------------------------------------------------------------- Things have been quiet around here, so.... A bunch of us were sitting around talking about the good old days when men were men and dinosaurs ruled the earth - you know, RSTS/E V6B and its family of patches, and the Carl&Dave/Dave&Carl shows. Anyway, there has always been the issue that RSTS folks are fundamentalists - they LOVE and cling to RSTS/E like no others seem (my view) with any other system. The question is "why?". A possible answer is that RSTS/E is an operating system that is rich in functionality, yet can be just about completely understood by someone who is not runner-up in the Noble Prize race. This endowed the system manager with a certain amount of pride and satisfaction. VMS is SO large and complex that most cannot fully fathom all its intricacies. I've even heard of a study done within DEC to determine what it was about RSTS/E that created such loyalty in comparison to VMS. Wish I knew what conclusions they drew. Thoughts? ( Mark, Anton, Martin, Simon, et al.... Ya done good! ) ================================================================================ Note 188.1 [RSTS]RSTS/E <==> Loyalty 1 of 2 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 22-JUL-1988 01:41 -< NO DISAGREEMENTS HERE - A VERY EASY SYSTEM TO MANAGE >- -------------------------------------------------------------------------------- ================================================================================ Note 188.2 [RSTS]RSTS/E <==> Loyalty 2 of 2 EISNER::KENNEDY "Terry Kennedy" 38 lines 22-JUL-1988 04:10 -< One fan's reply... >- -------------------------------------------------------------------------------- > The question is "why?". A possible answer is that RSTS/E is an > operating system that is rich in functionality, yet can be > just about completely understood by someone who is not runner-up > in the Noble Prize race. This endowed the system manager with a > certain amount of pride and satisfaction. Well, here's my personal set of answers (no particular order): 1) Agreement with quoted text above 2) It seems a *lot* easier to accomplish something on RSTS than the same thing on VMS, even when the methods are equally well understood for both environments. 3) There is a certain pride of accomplishment in tweaking a small system for speed - I have an 11/23 that whomps an 8600 in BP2 com- piles (back when both compilers were built from the same sources). Sure, you can move more stuff in a dump truck than in a sports car - but it's not nearly as much fun! 4) When I have a problem, I can just call up the responsible devel- oper and go 'why is this?'. Have you ever been able to call some- one who admitted to being a responsible VMS developer? [This is for raw phone calls, not at Symposia]. Hey, they even have more than one person working on the VMS TTDRIVER! 5) The feeling of togetherness that RSTS emits tends to encourage more of the same. So we don't have the swarms of people that VMS brings to Symposia - but we do get *very* interested people. 6) RSTS has been through a number of very major architectural changes, and it now rides them out quite well. On the other hand, I think VMS is still reeling from the V3 to V4 change, and it [unfortunately] has come to rely on its missing integrity to the point that there are a lot of sharp edges sticking out. The single worst case this week is the 'feed NCP from .COM file' problem, with the 'biggest protruding frob' special recognition award go- ing to the VMS DCL ampersand (&) operator...  ================================================================================ Note 189.0 [RSTS]Have You Seen This Acronym? 4 replies EISNER::BYRNE_C "Just Say NOtes" 15 lines 24-JUL-1988 06:51 -------------------------------------------------------------------------------- I don't know about others, but there seem to be certain folks on this system who use certain acronyms that I previously had never seen. In common usage FYI, I see all over. But where did these come from: WRT (With Respect To) BTW (By The Way) OTOH (On The Other Hand) IMHO (In My Humble Opinion) Are they used more commonly in, say, the military, or maybe have they developed on other networks? I never saw any of these acronyms before in my life. ================================================================================ Note 189.1 [RSTS]Have You Seen This Acronym? 1 of 4 EISNER::KENNEDY "Terry Kennedy" 58 lines 24-JUL-1988 16:42 -< Mysteries unveiled >- -------------------------------------------------------------------------------- > Are they used more commonly in, say, the military, or maybe have > they developed on other networks? I never saw any of these > acronyms before in my life. Well, many of them date from the era of Telex communications - at least that's where I first met many of them. In addition, the more bizarre ones came from the MIT hacker tradition. Here is what the cookie file entry for abbreviations says: COM MODE (variant: COMM MODE) [from the ITS feature for linking two or more terminals together so that text typed on any is echoed on all, providing a means of conversation among hackers] n. The state a terminal is in when linked to another in this way. Com mode has a special set of jargon words, used to save typing, which are not used orally: BCNU Be seeing you. BTW By the way... BYE? Are you ready to unlink? (This is the standard way to end a com mode conversation; the other person types BYE to confirm, or else continues the conversation.) CUL See you later. FOO? A greeting, also meaning R U THERE? Often used in the case of unexpected links, meaning also "Sorry if I butted in" (linker) or "What's up?" (linkee). FYI For your information... GA Go ahead (used when two people have tried to type simultaneously; this cedes the right to type to the other). HELLOP A greeting, also meaning R U THERE? (An instance of the "-P" convention.) NIL No (see the main entry for NIL). OBTW Oh, by the way... R U THERE? Are you there? SEC Wait a second (sometimes written SEC...). T Yes (see the main entry for T). TNX Thanks. TNX 1.0E6 Thanks a million (humorous). When the typing party has finished, he types two CRLF's to signal that he is done; this leaves a blank line between individual "speeches" in the conversation, making it easier to re-read the preceding text. : When three or more terminals are linked, each speech is preceded by the typist's login name and a colon (or a hyphen) to indicate who is typing. The login name often is shortened to a unique prefix (possibly a single letter) during a very long conversation. /\/\/\ The equivalent of a giggle. At Stanford, where the link feature is implemented by "talk loops", the term TALK MODE is used in place of COM MODE. Most of the above "sub-jargon" is used at both Stanford and MIT. -- From the AI Hackers' Dictionary Of course, the BYE/F you sometimes see in from us RSTS types when we use Phone is the fast logout under RSTS. There has got to be a better place to discuss this - but I'll be darned if I can think of where - perhaps VAX_NOTES_UTILITY? ================================================================================ Note 189.2 [RSTS]Have You Seen This Acronym? 2 of 4 EISNER::HASSINGER "Bob Hassinger" 4 lines 24-JUL-1988 18:33 -< The little faces were not enough?? !! >- -------------------------------------------------------------------------------- Yes, VAX_NOTES...would be good because the information is equally useful to all Notes users Bob H ================================================================================ Note 189.3 [RSTS]Have You Seen This Acronym? 3 of 4 EISNER::BYRNE_C "Charlie Byrne" 7 lines 25-JUL-1988 12:17 -< Not where I thought I was! >- -------------------------------------------------------------------------------- This actually was intended to be in SOAPBOX, I must have been tired I think I wrote it at some odd hour. When I went into SOAPBOX this morning it had mysteriously disappeared (or so I thought) so I re-posted it there. Could you guys move your repsonmes to SOAPBOX? (OR move the whole thing to VAX_NOTES...) but I think it is more SOAPBOXISH fun stuff myself. ================================================================================ Note 189.4 [RSTS]Have You Seen This Acronym? 4 of 4 EISNER::BYRNE_C "Charlie Byrne" 4 lines 25-JUL-1988 13:39 -< This topic now NOWRITE >- -------------------------------------------------------------------------------- I've set this TOPIC to NOWRITE. Note 43.1 has been moved to the TOPIC created in SOAPBOX. Charlie - RSTS/OS CoModerator  ================================================================================ Note 190.0 [RSX]Misc M+ v4.0 questions... 5 replies EISNER::PERRY "Bob (Sky Scum) Perry" 12 lines 29-JUL-1988 12:47 -------------------------------------------------------------------------------- 1) How does one kill the print header page for M+ v4.0 ? 2) When using RMD you get a list of 4 drives and their free space. We gen'd in 4 rl01's which we don't have on our 11/73 system, but we do have 4 DU devices. Unfortunately, only the RL's show up on RMD. How do I get the DU devices to show up instead ? Boy, you folks are sure nice for answering this. Scum ================================================================================ Note 190.1 [RSX]Misc M+ v4.0 questions... 1 of 5 EISNER::LEDERMAN "Bart Z. Lederman" 5 lines 29-JUL-1988 18:13 -< Can be done at task build time >- -------------------------------------------------------------------------------- It's been a long time since I did this: but I distinctly remember there were some options in the task build file which let you set the default device name and number for the various disk devices (at least the first four, maybe more if you include the I page). Look in [1,20] and [1,24] for RMDBLD, etc. ================================================================================ Note 190.2 [RSX]Misc M+ v4.0 questions... 2 of 5 EISNER::DELARISCH "Arnold S. De Larisch" 22 lines 30-JUL-1988 17:39 -< Use GBLPAT at TKB time! >- -------------------------------------------------------------------------------- >> < Note 86.1 by EISNER::LEDERMAN "Bart Z. Lederman" > >> -< Can be done at task build time >- >> It's been a long time since I did this: but I distinctly remember >> there were some options in the task build file which let you set >> the default device name and number for the various disk devices >> (at least the first four, maybe more if you include the I page). >> Look in [1,20] and [1,24] for RMDBLD, etc. Correct! There are Global Patches which you can 'Hard-Code' specific devices into RMD to display 'Free'. The patches are two numbers. The first number is the Octal Value of the two ASCII characters that make up the device name (Use CVT to get these values" and the second number of each patch is the Unit number. The instructions are in the build file ... I don't have a system available to get specific (We lost due to lighting a DSU/CSU which connects us with the rest of CAMPUS) -Arnold ================================================================================ Note 190.3 [RSX]Misc M+ v4.0 questions... 3 of 5 EISNER::WYANT "Tom Wyant" 15 lines 14-OCT-1988 14:22 -< There's always the "Conan the Barbarian" approach... >- -------------------------------------------------------------------------------- >> -< Can be done at task build time >- >> It's been a long time since I did this: but I distinctly remember >> there were some options in the task build file which let you set >> the default device name and number for the various disk devices >> (at least the first four, maybe more if you include the I page). >> Look in [1,20] and [1,24] for RMDBLD, etc. Of course, a REAL man wouldn't want several versions of RMD hanging around - he'd just change mode to kernel and rearrange the DCB pointers so that the default RMD device search produced the correct behaviour. The same can be done to the system image with ZAP. *:> ================================================================================ Note 190.4 [RSX]Misc M+ v4.0 questions... 4 of 5 EISNER::PERRY "Bob (Sky Scum) Perry" 8 lines 16-NOV-1988 13:53 -< Need LAT help on M+ v4.0... >- -------------------------------------------------------------------------------- \\ Can someone tell me how you fire up LAT s ervices on M+ v4.0 ? I gen'd it in, but can't seem to get it to talk to the server (200). Thanks, Scum ================================================================================ Note 190.5 [RSX]Misc M+ v4.0 questions... 5 of 5 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 21 lines 16-NOV-1988 18:38 -< turning LAT on under RSX11M+ >- -------------------------------------------------------------------------------- >>Can someone tell me how you fire up LAT s ervices on M+ v4.0? >>I gen'd it in, but can't seem to get it to talk to the server (200). In your [5,1]netins.cmd there will be things conditionalised on $lat. If you invoke this from startup, first do a .SETT $LAT. Netins.cmd may lack a line such as: .IFT $LAT LCP CREATE/TERM=20 (or however many you want) which must PRECEED the LCP START line. Try LCP help, also, as you need to have defined the service you offer and the announce strings, etc. The file these and other related parameters are all in is lat.dat, and can actually be mucked with using an editor, but is best to do with LCP. Just like CFE and CETAB.MAC... DON't bother BUYING an H kit for your 11s DS200 support if you have VAXES around. Only get the VMS kit for DS200s. Just copy the PR0801ENG.SYS image from MOM$LOAD on the VAx to on the 11. This may sound like cheating, but the DS200 is what is licensed, AND DECies at DECUS always say that that is of course the thing to do.  ================================================================================ Note 191.0 [PRO300]06/06/88 DEC news: IVIS phase down No replies EISNER::TINKELMAN "Bob Tinkelman - CCA" 62 lines 4-AUG-1988 23:39 -------------------------------------------------------------------------------- .___.___.___.___.___.___.___. ! ! ! ! ! ! ! ! | d | i | g | i | t | a | l | PROD - N e w s !___!___!___!___!___!___!___! IVIS PRODUCTS TO BE PHASED DOWN - 06-June-1988 ******************************************************************************* o Place final orders by September 30, 1988 o Final systems ship December 30, 1988 IVIS products are being phased down in conjunction with the phase down of the Professional 380 systems. A follow-on product is not being planned since sufficient marketing demand has not been indicated to warrant further development. A small quantity of IVIS systems are still available and will be sold on a first-come, first- served basis, while quantities last. The following IVIS hardware and software products will be phased down. Place orders for these products no later than September 30, 1988, with delivery to occur no later than December 30, 1988. IVIS Hardware Order No. Description PC38V-AC IVIS System Canada/French PC38V-AE IVIS System UK/Ireland PC38V-AJ IVIS System Japan/Katakan PC38V-AQ IVIS System Canada/English PC38V-AR IVIS System Non-Spain PC38V-AU IVIS System Non-Portugal PC38V-AY IVIS System Japan/Hirigana PC38V-AZ IVIS System Australia/N2 PC38V-BC IVIS Touch Sys Canada/French PC38V-BE IVIS Touch Sys UK/Ireland PC38V-BJ IVIS Touch Sys Japan/Katakan PC38V-BQ IVIS Touch Sys Canada/English PC38V-BR IVIS Touch Sys Non-Spain PC38V-BU IVIS Touch Sys Non-Portugal PC38V-BY IVIS Touch Sys Japan/Hirigana PC38V-BZ IVIS Touch Sys Australia/N2 PC38V-CA PRO380/IVIS U.S., No Hard Disk PC38V-DA PRO380/IVIS Touch U.S., No Disk PC38V-EA IVIS System Arabic PC38V-FA IVIS Touch Arabic PC3VX-AA Sony/Pioneer IVIS CTL/SIG CBL IVIS Software Order No. Description QBA27-A3 PRO/Producer Tech Kit V1.6 QBA22-H3 IVIS System Software NOTE: IVIS application software was included with the Professional 300 Series product phase-down announcement. VAX/Producer, Q*040-xx, and VAX/Producer Interpreter, Q*041-xx, will continue to be available.  ================================================================================ Note 192.0 [RSX]Need RMD build help... 3 replies EISNER::PERRY "Bob (Sky Scum) Perry" 4 lines 29-AUG-1988 13:32 -------------------------------------------------------------------------------- Are the [14,*] directories built on the fly during SYSGEN on M+ v4.0 ? We want to modify the RMD display to show the free space on our DU devices instead of our DL devices and I can't seem to locate the build file sources. ================================================================================ Note 192.1 [RSX]Need RMD build help... 1 of 3 EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 29-AUG-1988 16:25 -< Use GBLPATs in [1,24] build files >- -------------------------------------------------------------------------------- >> < Note 87.0 by EISNER::PERRY "Bob (Sky Scum) Perry" > >> -< Need RMD build help... >- >> Are the [14,*] directories built on the fly during SYSGEN on M+ >> v4.0 ? We want to modify the RMD display to show the free space >> on our DU devices instead of our DL devices and I can't seem to >> locate the build file sources. Seek out the appropriate build file in [1,24]. Burried in there are GBLPATs for the 'Free Space' entries. You need to specify the octal equiv. of the two character 'ASCII' Device name. The unit number is the unit number (in Octal). If you need further details, you can leave me mail here or contact me thru BITNET (DELARISC@SERVAX) or give me a call (407) 338-2225 (11AM-7PM EST). -Arnold ================================================================================ Note 192.2 [RSX]Need RMD build help... 2 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 24 lines 29-AUG-1988 20:13 -< use [1,20]rmdbld.bld >- -------------------------------------------------------------------------------- >>>< Note 87.1 by EISNER::DELARISCH "Arnold S. De Larisch" > >>> Seek out the appropriate build file in [1,24]. Burried in there >>>are GBLPATs for the 'Free Space' entries. You need to specify the octal >>>equiv. of the two character 'ASCII' Device name. The unit number is the >>>unit number (in Octal). That is all true, except there will be NO RMDxxx files in [1,24] (except a .olb ) unless you have actually BUILT RMD. With everything vectored these days, you won't find as much in [1,24]. Sysgen will use [1,20]RMDBLD.BLD to make the [1,24] files it gives to TKB. I prefer to edit the .bld files in [1,20] for such permanent changes as: PIP /CD, and [1,5] being our default for @ files, and /-SP on things like TKB. If we needed custom RMD device selection, I would do it in [1,20], and then anyone running sysgen to build the task will get the changes. I have never tried this, but you might also, assuming all your disk drivers are loadable, try LOAding them in VMR in the sequence you prefer. If you are a bit more daring, rechain your DCBs on the fly using a PRIV task. RMD supposedly shows SY: and the next 3 disks, so sequence should help. ================================================================================ Note 192.3 [RSX]Need RMD build help... 3 of 3 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 12 lines 29-AUG-1988 23:37 -< It works very well, once you get it right >- -------------------------------------------------------------------------------- >> Seek out the appropriate build file in [1,24]. Burried in there >> are GBLPATs for the 'Free Space' entries. You need to specify the octal >> equiv. of the two character 'ASCII' Device name. The unit number is the >> unit number (in Octal). Be *very* careful and have someone else proofread your changes. If you don't do it EXACTLY right, your system will crash the instant you run RMD. How, do you ask, do I know this? Well, that is a tale for another day... (He says with a red face) Alan  ================================================================================ Note 193.0 [RSTS]Bad Block recovery, etc. 2 replies EISNER::MCALLISTER "Brian McAllister" 24 lines 6-SEP-1988 15:37 -------------------------------------------------------------------------------- Some questions regarding bad-block handling on RSTS, and on DU-type disks in particular. I was doing a BACKUP recently, and had a series of errors associated with a cluster in the middle of a file (disk is RA80). The final "error" was one reporting a "WRITE command" with a "Successful Completion" status code and the following report from the driver: Driver Error Code 000001 Packet was generated by BBR BBR Failure Code 013 Could not restore saved LBN data BBT Flag Byte 005 RBN non-primary BBR successful My questions are as follows: 1) Is the proper procedure just to delete the file, and restore a good copy from a previous BACKUP? 2) What is the difference between "RBN was primary" which I got on previous (recovered) errors, and "RBN non-primary"? 3) Is there any was to get information on how many bad-blocks have been detected on a DU disk, and where they are, and what blocks they were replaced with? ================================================================================ Note 193.1 [RSTS]Bad Block recovery, etc. 1 of 2 EISNER::KENNEDY "Terry Kennedy" 28 lines 7-SEP-1988 04:25 -< Answer: Your drive is dying >- -------------------------------------------------------------------------------- > 1) Is the proper procedure just to delete the file, and restore > a good copy from a previous BACKUP? Yes, but see answer to 2) first. > 2) What is the difference between "RBN was primary" which I got > on previous (recovered) errors, and "RBN non-primary"? If you *ever* get an unrecoverable data error, *or* a non-primary RBN, get Field Service to rev the drive and/or relace the logic & hda. What you saw should *not* happen, *ever*. You've got two problems - a sector went completely away (your bas spot was > ~96 bytes. Also, you had at leat 5 bad spots in that control region. (Call it a track for sanity's sake...) Therefore, a good amount of the track has gone bad, possibly due to a partial head crash. > 3) Is there any was to get information on how many bad-blocks > have been detected on a DU disk, and where they are, and > what blocks they were replaced with? Yes, but it's not pretty. The only (available to users) software to do this lives in the HSC, and if you've got RSTS, your drive *isn't* on an HSC. [Why not? Call DEC and ask for HSC support in RSTS!]. You *could* write a program that talked to the UDA without benefit of an OS to find out this info, but I can't tell you the format or how to get it. Of course, you *could* buy the MSCP Protocol Manual Set, which is a licensed product for mucho dollars... Sorry. ================================================================================ Note 193.2 [RSTS]Bad Block recovery, etc. 2 of 2 EISNER::MCALLISTER "Brian McAllister" 11 lines 7-SEP-1988 10:06 -< New HDA on the way (hopefully) >- -------------------------------------------------------------------------------- >> If you *ever* get an unrecoverable data error, *or* a non-primary >>RBN, get Field Service to rev the drive and/or relace the logic & hda. Thanks. Since this was only the latest in a series of problems, I called FS right away yesterday, and expect a new HDA today. BTW: All problems can be traced to an overheating condition caused by AC failure ~3 months ago. Have already had the "personality module" replaced, which seemed to fix a problem with spontaneous spin-down.  ================================================================================ Note 194.0 [RSX]VOL_CHANGE.TSK... 1 reply EISNER::PERRY "Bob (Sky Scum) Perry" 5 lines 6-SEP-1988 16:27 -------------------------------------------------------------------------------- Anyone know of a program which will allow one to change the volume label of a device ( a disk drive in this case ) ? ================================================================================ Note 194.1 [RSX]VOL_CHANGE.TSK... 1 of 1 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 29 lines 6-SEP-1988 18:03 -< HOM, or CVL change vol. label >- -------------------------------------------------------------------------------- >> Anyone know of a program which will allow one to change the >> volume label of a device ( a disk drive in this case ) ? Sure! HOM which is simply INI installed with that special name to tell it to do the other functions. See your Dec doc. set. It can change all sorts of volume defaults. The super pain is that it (as does INI) demands that the volume be not only MOU /FOR, but also ALLocated. This make it a bit of a problem to do it to the system disk one is booted on. I think SYSVMR even does it for you: INS INI/task=...HOM. This functionality was added many releases ago, but if you are on a super old system you may not have it. There was a venerable old Decus program called CVL (Change Vol. Label) that used to work well and does it on your MOUnted system disk with no problem, too. The CVL on our disk is a 70 block .mac, and a 1 block .cmd both dated 10-feb-81, and they are in [344,43] so they were in some KMS kit. I seem to recall some problem using CVL recently, probably because it hadn't been rebuilt on the system I was on. HOM solved my problem so I didn't explore further. If you can't find CVL on a newer Sig tape, and if HOM won't do, I can could send you a tape of the old pieces I found, or if you are in a super rush arrangements could be made for you to dial in to Kermit it out.  ================================================================================ Note 195.0 [PRO300]Running on Empty (batteries) 3 replies EISNER::LEDERMAN "Bart Z. Lederman" 24 lines 8-SEP-1988 20:10 -------------------------------------------------------------------------------- My PRO-350 has started to develop occasional memory lapses, in the form of forgetting the date. When I boot it up, it usually has the correct date and time, but once in a while it has the default date (somewhere in early 1982, for P/OS 2.0). I surmise that the Ni-Cd batteries that keep the clock alive with the power off are dying. It's been a while since I had my PRO open, but I remember a two AA cell size battery pack with a plug in cable. It also had on it, of course, a warning to replace it only with a genuine DEC part, and a part number. Before I spend a lot of money on a DEC replacement (if I can get one), does anyone have any experience replacing these with industry standard batteries? As someone who used to repair TV sets, I can't resist the comparison with the radio and TV sets which said "Replace only with genuine Capehart tubes" (or various other brands). Most of the companies didn't make their own tubes or other components, and there was no way to buy replacements: not even if you were an authorized repair depot. You used tubes and capacitors and whatever else you needed from any good quality supplier, unless it was something really unique like a tuner: and even then, there were alternative sources. (Also, does anyone know the part number? My PRO is ticked into a custom cabinet and it's a real pain to pull it out and lift the cover as I have to pull off all of the cables.) ================================================================================ Note 195.1 [PRO300]Running on Empty (batteries) 1 of 3 EISNER::MAYHEW "Bill Mayhew" 6 lines 8-SEP-1988 21:22 -< You won't believe this... >- -------------------------------------------------------------------------------- My Pro pocket service guide lists the part number as 12-19245-00. My Self Maintenance Services catalogue lists that part at $19, orderable through DECdirect. Now, wasn't that easy? {grin} (I think that's the first time in about six months that I looked up the price for some part and (a) found it, and (b) decided it was affordable :-} ) ================================================================================ Note 195.2 [PRO300]Running on Empty (batteries) 2 of 3 EISNER::RICE "Gary Rice" 22 lines 9-SEP-1988 08:45 -< Only for Hackers or TV-Repairmen >- -------------------------------------------------------------------------------- > a two AA cell size battery pack with a plug in cable. It also had > on it, of course, a warning to replace it only with a genuine DEC > part, and a part number. Before I spend a lot of money on a DEC > replacement (if I can get one), does anyone have any experience > replacing these with industry standard batteries? I thought about doing the same thing. Here is why I didn't: 1) The 2 batteries are soldered to the wires that then go to the back of the PRO, requiring some melting and re-soldering of the non-battery components of the pack; 2) The batteries are rated at a weird voltage and I didn't think that I would be able to locate comparable units; However, Bill's price of $20 is a lot higher than I remember paying by dropping in at the service center and buying the part "over-the-counter". Granted, that was over 3 years ago, but I think I paid something like $7.00. Gary ================================================================================ Note 195.3 [PRO300]Running on Empty (batteries) 3 of 3 EISNER::LEDERMAN "Bart Z. Lederman" 16 lines 20-SEP-1988 13:20 -< A solution: use the system more. >- -------------------------------------------------------------------------------- Well, I thought about the problem for a while, and realized that I wasn't using my PRO much. Though I use it every evening (to log into DECUServe and CompuServe), I recently was using it for only a few minutes each day. I thought maybe I just didn't have it turned on enough to charge the batteries, so I've been leaving it turned on longer even if my work is completed. So far it hasn't forgotten the date since I started doing this. Maybe it's my PRO's way of telling me I'm not using it enough? By the way, obtaining NiCd batteries with solder tabs is no big trick. And it's impossible to have a NiCd battery with a non-standard voltage (though a pack with an unusual number of cells might not be an off-the-shelf item). But good AA size cells start at around $2.50 each (more for high capacity or rapid charge), so the DEC part might not be a bad buy after all.  ================================================================================ Note 196.0 [RSX]F77 V5.2-23 linking problem 1 reply EISNER::NORTON "Bill Norton" 12 lines 12-SEP-1988 17:06 -------------------------------------------------------------------------------- I have F77 V5.2-23 on a M+ V4.1 system, using the F7SRES resident library. One program(at least) is getting a multiple definition of $FIND from module SPSUB when linked to F7SRES. $FIND sounds like an FCS sort of routine name, and it appears in F77EP.MAC, used in building the resident library. However, $FIND also appears as an entry point in module SPSUB in SYSLIB. How can I avoid the multiple definition and still link to F7SRES? ================================================================================ Note 196.1 [RSX]F77 V5.2-23 linking problem 1 of 1 EISNER::NORTON "Bill Norton" 11 lines 30-JAN-1989 11:34 -< Workaround provided >- -------------------------------------------------------------------------------- Here's the resolution of the problem - via SPR yet! "The doubly defined symbol $FIND, is a dummy entry point in the F77 vector module. The workaround for using with FORTRAN-77 version 5.2 is to rename the entry point $FIND, in the F77EP.MAC module to $FND. By the way, this solution has been included in the newly released version of PDP-11 FORTRAN-77, version 5.3. After you rename the entry point, the vector module and library will have to be re-built. Also any application which reported the doubly-defined symbol must be re-built."  ================================================================================ Note 197.0 [RSX]Problems with LAT ports No replies EISNER::NORTON "Bill Norton" 28 lines 19-SEP-1988 17:47 -------------------------------------------------------------------------------- In setting up a system with 30 LAT application ports, using M+ V4.1 and DECnet patched from the M+V4.1 tapes, I've run across the following problems: 1. The LCP command line isn't long enough to say "LCP CREATE/TERM=30/RESERVED=1,2,3,4,5,6,7,8,9,10.....,30" ...so the reserved group stops at less than you want it to. Unfortunately there's no shorthand way of specifying this. 2. Since these ports are all for non-terminal devices, I initially set them /SLAVE, /FDX, /RPA, and /EBC after defining the ports with commands of the form: LCP SET PORT TTn:/SERVER=LAT_008002B0568F3/PORT=PORT_n. Any attempt to access one of these ports resulted in a system hang. A workaround appears to be to not set /FDX, /RPA, or /EBC until after the connection to the port has been made. So now I PIP a very short file to each port in order to force the establishing of its connection. This has the interesting side effect of corrupting the database for one of the LAT ports. When the first PIP has completed, several (4?) characters are lost off the end of the server name of another LAT port. Only the first PIP seems to cause trouble, and only one other port gets clobbered. The workaround for this seems to be using shorter (6-char) server names. Do these ring a bell with anyone? Or is it just crazy to try to get it to do this?  ================================================================================ Note 198.0 [RSX]M+ needs Optimizing 2 replies EISNER::BRUCE "Barton F. Bruce - CCA/MA" 51 lines 26-SEP-1988 16:39 -------------------------------------------------------------------------------- Now that RSX11M+ seems to have reached a mellow kind of maturity, and even BRU hasn't caused any spectacular problems recently, it would seem reasonable to make some suggestions to DEC about how they should spend those precious maint. dollars that still flow into their pockets. If we don't get some nice new improvments, maybe it is time to consider DROPPING the maint. contract, and then PAYING for each upgrade if, and only if, each seems well worth it. The days of the continual bugs needing fixing seems over, and I have not heard of anything forthcoming to M+ itself that would encourage me to keep such an expensive contract alive for too much longer. In years past, saving memory was the big goal. Now, almost all the 11s I use are 4 meg. And they never seem to have all the memory used. Most machines are I/D and Supervisor mode compatible, and now I would rather have all the many Dec utilities tuned to give maximum speed, and to ignore memory usage if speed can be gained. Note 42 in this conference suggests Dec shipping SYSLIB built with the FCSMBF modules. I think there should be an alternate set of utilities, or at least support in sysgen to do them all at once, to expand the vanilla/...res/...fsl concept to have a another flavor that is FASTEST, which individually may mean being built to FCSRES, or FCSFSL (both of which should support multibuffering) or whatever, but also built I/D with enough big and multibuffers to seldom wait for I/O, and with an overlay structure utilizing any remaining space gained with I/D to cut overlays even more, even though they should be all memory resident, anyway. We now have very fast disks, and 11 cpus are about to reach undreamed of speeds with or without Dec's cooperation, and 4 meg is installed widely. It is time to tune for more speed, and memory be ignored. I know that PIP does many things, but it is an example of some kind of gross ineffiency. If I need to see a directory listing fast, or make one I can easily read with an indirect command file I ALWAYS use SRD. If I need to find free space and fragmentation stats, I use FRAG which runs circles around poor PIP. Dec need not compete with each and every Decus utility, but there are many utilities that could use some TLC. Of course there are some small memory machines left, and some non I/D ones, too, so I am not suggesting dropping the current compact versions of the utilities, only adding more options. I suspect there are many other things other people would like to see, too. Does anyone KNOW of what DEC is planning to do? ================================================================================ Note 198.1 [RSX]M+ needs Optimizing 1 of 2 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 29 lines 28-AUG-1989 21:32 -< Any new S/W releases do out soon? >- -------------------------------------------------------------------------------- >Now that RSX11M+ seems to have reached a mellow kind of maturity, >If we don't get some nice new improvments, maybe it is time to >consider DROPPING the maint. contract, and then PAYING for each >upgrade if, and only if, each seems well worth it. The days of >... >keep such an expensive contract alive for too much longer. >Does anyone KNOW of what DEC is planning to do? That was almost a year ago. We still run M+3.0, but have built 4.1 packs experimentally. Maybe we never will go live on 4.2. Dec just sent a letter CANCELING support and maint. $s on the Peripheral Processor Toolkit - RSX, and this again raised the question of what we needed on the 11's contract. We have left: M+ f-77 RSX-11S MPP-RSX DECNET Does anyone KNOW of any immediately impending significant releases for any of these? (sure would hate to miss a new tape by canceling just a month too soon). If not, I bet we are about to save $448. a month. ================================================================================ Note 198.2 [RSX]M+ needs Optimizing 2 of 2 EISNER::MAYHEW "Bill Mayhew" 23 lines 29-AUG-1989 00:56 -< MPP's essentially dead >- -------------------------------------------------------------------------------- > Dec just sent a letter CANCELING support and maint. $s on the > Peripheral Processor Toolkit - RSX... This is odd, since this product just recently entered its 18-month retirement cycle. Support was supposed to continue through late 1990. Now, whether it's worth paying for support under those conditions is a different question, which introduces... > We have left: > M+ > f-77 > RSX-11S > MPP-RSX > DECNET If "MPP-RSX" is MicroPower-Pascal, then it is in the same state. It entered the retirement cycle in April '89. OTOH there was discussion here or in DEC_NET recently about DEC seeking beta sites for a new release of DECnet/RSX, so one might guess that's coming sometime soon.  ================================================================================ Note 199.0 [RT11]Kermit-RT manual 2 replies EISNER::ALLEN_C 7 lines 6-OCT-1988 13:48 -------------------------------------------------------------------------------- Hi there, I am in need of a copy of Kermit-RT doco. Does anyone have a quick and easy method for obtaining same? Thanks, Charly ================================================================================ Note 199.1 [RT11]Kermit-RT manual 1 of 2 EISNER::KENNEDY "Terry Kennedy" 7 lines 6-OCT-1988 18:42 -< Get it from the BBS >- -------------------------------------------------------------------------------- > I am in need of a copy of Kermit-RT doco. Does anyone have a quick > and easy method for obtaining same? Is it based on Kermit-11 by Brian Nelson? If so, the complete K11 dis- tribution (including docs) can be found in directory [87,6] on the RSTS SIG BBS, at (201) 915-9361. Feel free to grab what you need - access is open to all. ================================================================================ Note 199.2 [RT11]Kermit-RT manual 2 of 2 EISNER::CROWELL "Shefth of the Fourth Order" 10 lines 8-OCT-1988 13:24 -< KERMIT/RT Doc >- -------------------------------------------------------------------------------- I can copy the stuff onto a floppy for you. Usual ground rules: Send blank floppy and return postage to: John M. Crowell Multiware, Inc. 2121-B Second St. Suite 107 Davis, CA 95616 You'll also want to check out a two-part article about KERMIT/RT in the June and July, 1988 issues of the DECUS Newsletter.  ================================================================================ Note 200.0 [RSX]Can I run a U-bus sys on a Q-bus machine??? 4 replies EISNER::WYANT "Tom Wyant" 8 lines 14-OCT-1988 14:30 -------------------------------------------------------------------------------- Does anyone have any experience with running the same SYSgen on both a Unibus and a Q-bus machine? What's the situation here in general? If the general answer is "yes, it will work without much finagling" the second part of the question is: What finagles are needed? Specifically,under what versions of RSX-11M+ (if any) will the TT: driver handle both DHUs and DHVs? Does M+ V3.0 "E" have a problem? ================================================================================ Note 200.1 [RSX]Can I run a U-bus sys on a Q-bus machine??? 1 of 4 EISNER::WYANT "Tom Wyant" 42 lines 31-OCT-1988 16:41 -< Physician, heal thyself >- -------------------------------------------------------------------------------- >>> Does anyone have any experience with running the same SYSgen >>> on both a Unibus and a Q-bus machine? For the benefit of future readers of this topic who are wondering- yes, it does work. This topic was posted because Telephone Support told us "no, it won't work", and I wanted a second opinion. After mucking through various kits and pseudo-kits left behind by the previous "system manager", trying to cram a bootable RM- based system onto an RD51 while preserving its bootability, and other exploits you don't want to hear about, we finally decided to ignore TSX and try our 11/70 SYSGEN anyway. It worked, at least for what we were trying to do (which was to get enough of RSX running to boot a custom gen) we: * Initialized a scratch RM05 lookalike with the index file at the beginning, and with a 1000 block header file. * BRUed [1,1], [1,54], and [3,54] to the new disk (yes, we could have used the aorresponding BRU switches) * Modified our standard SYSVMR abit to exclude unwanted tasks and drivers. * VMRed the sucker. * Booted and saved. * Blew away everything we didn't absolutely need (and a few things we did - but once you've VMRed, the only side effect of blowing away TTCOM seems to be to make SAV complain). * Did an image BRU to RX50 (it took 5) * Booted standalone BRU on the 11/53 (RX33) and BRUed my RX50s over to the winnie. * Booted the sucker. The only drivers that have been tested are DU: and TT: (DL-11 port driver only). But at least that part works. ================================================================================ Note 200.2 [RSX]Can I run a U-bus sys on a Q-bus machine??? 2 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 49 lines 31-OCT-1988 18:52 -< 1 sysgen, 2 busses >- -------------------------------------------------------------------------------- THE SIGNIFICANT THING TO REALIZE IS THAT DEC SHIPS ONE M+ BIG DISK TAPE KIT TO Q and U USERS ALIKE that will boot on any of the supported disks that share the common boot code! You can boot an M+ U system on a Q system and vice-versa. And you don't need to BRU or anything in between. To not BRU, you do need a disk that is available on both buses. BRUing, but not VMRing, you need disks that use the same boot code. Without looking it up, I think all the BIG disks would work without VMRing, as long as there is hardware to match. A U RM05, or even RP04 could be BRU'd (via tape or directly) to a RAxx disk that would be then bootable on a Q machine. Both drivers would have to have been loaded in VMR for boot to work, but that is all. There is a list somewhere of different disks that are interbootable, and this is more a boot issue that Q/U, and BRU simply enforces it by replacing your boot with "this disk does not contain a bootable system" if you BRU to a disk outside the interbootable groupings. If you are willing to reVMR, and since you can always to a component mode gen for a new disk driver, you NEVER have to redo a full gen just to switch buses or disks IF and only IF you have your resident driver table stuff all GEN'd in (TTdriver's database, etc) as that part, being not loadable, was built with the EXEC. M+ is better about interbootability of different disks than M was when I last looked, and this sort of issue is probably why DEC says to use an M BRU on M and an M+ BRU on M+. RL02s or RK05s or RAxxs should just work on either BUS as they have controllers for both, but if BRU'd to one another, would need reVMRing (reguardless of bus) as these are not interbootable (don't have common boot code). The thing that has skunked me is that there is no Q bus DH (YH). The U equiv of a DHV/DHQ (YV) is a DHU (YV, also). We and our customers seem to have old style U DHs and new Q DHVs so we have to gen for both! DZs simply work on either bus. The ONLY thing TSC might be right about is DECNET. I bet Q/U does make a difference to DECNET, and I bet you need to do a new netgen for each bus. What do they ship for DECNET for pregenned MicroRSX? Is it 1 kit for either bus? ================================================================================ Note 200.3 [RSX]Can I run a U-bus sys on a Q-bus machine??? 3 of 4 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 10 lines 2-NOV-1988 12:55 -< DECnet may not be a problem with some boards >- -------------------------------------------------------------------------------- >> The ONLY thing TSC might be right about is DECNET. I bet Q/U does >> make a difference to DECNET, and I bet you need to do a new >> netgen for each bus. Correct only for those boards that do not have equivalents, such as Ethernet. For DZ11/DZV11/DZQ11 and similar boards, I don't think there is any problem. I haven't actually tried it, but strongly suspect this is the case. Alan ================================================================================ Note 200.4 [RSX]Can I run a U-bus sys on a Q-bus machine??? 4 of 4 EISNER::WYANT "Tom Wyant" 17 lines 10-NOV-1988 16:57 -< Post-mortem ---- >- -------------------------------------------------------------------------------- >> The ONLY thing TSC might be right about is DECNET. Yeah, we found that out a couple days ago -- a QNA doth not a UNA make. The previous "system manager" had left things in such disarray that nobody was sure where the kits were, so we hadn't the option of using the baseline - though we tried. Our SYSGEN disks (and corresponding BRU tapes) had already had the systems booted and saved, so that the baseline was not bootable any longer. We tried re-VMRing the baseline, but never got anywhere (the system would soft boot, but wouldn't load any tasks -- this was done perforce on an 11/44 with the system on a CDC 9766 masquerading as an RM05 (DR2:), hanging on an Emulex SC21). I suppose some hacking with the boot block could have restored the baseline system to bootability, but I'm not as young as I used to be ...  ================================================================================ Note 201.0 [RSX]TCP/IP on RSX or P/OS? No replies EISNER::RICE "Gary Rice" 13 lines 22-OCT-1988 12:31 -------------------------------------------------------------------------------- At Symposium this week, an Apple product called MacWorkstation was described. The basis of the product is you use a host computer to manipulate the MAC user interface over a comm link. Upon questioning the speaker, I found that the Ethernet protocol is TCP/IP. I would like to use this product, but don't know ho to get TCP in and out of my RSX system. Will I need to write a driver or can I use the existing Ethernet driver to deliver and receive TCP/IP to the Ethernet? Gary  ================================================================================ Note 202.0 [RSX]Can Someone Fix My PIP? 4 replies EISNER::ALLEN_C 11 lines 25-OCT-1988 14:22 -------------------------------------------------------------------------------- Hi all, Has anyone ever used the exclude switch in PIP successfully? If so, could you please give me the correct syntax and limitations of this pain in the neck switch. What I tried to do was copy all files except one - no go. Then I tried just doing a pip/li excluding one file - no go. I could not copy from one location to another or even from the directory to itself. What to do?? Thanks Charly ================================================================================ Note 202.1 [RSX]Can Someone Fix My PIP? 1 of 4 EISNER::DELARISCH "Arnold S. De Larisch" 33 lines 25-OCT-1988 15:41 -< We do PIP /EX all the time! >- -------------------------------------------------------------------------------- >> < Note 94.0 by EISNER::ALLEN_C > >> -< Can Someone Fix My PIP? >- >> Has anyone ever used the exclude switch in PIP successfully? If >> so, could you please give me the correct syntax and limitations >> of this pain in the neck switch. What I tried to do was copy all >> files except one - no go. Then I tried just doing a pip/li excluding >> one file - no go. I could not copy from one location to another >> or even from the directory to itself. What to do?? No Problem! I also find this switch to be a pain in the neck! Lets assume that you wish to exclude version 2 of a file called sub2.ftn and get a listing of the directory. The syntax would be: >PIP SUB2.FTN;2/EX & /LI Be VERY, VERY careful with this switch when deleting stuff. If the first command (the exclude) fails the second command continues! So I prefer to use the /EX switch interactively! >PIP PIP> SUB2.ftn;2/EX PIP> /li Please note that the version number is MANDATORY for the exclude clause! -Arnold ================================================================================ Note 202.2 [RSX]Can Someone Fix My PIP? 2 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 45 lines 25-OCT-1988 18:15 -< can use pip @xxx, also >- -------------------------------------------------------------------------------- >>>The syntax would be: >>>>PIP SUB2.FTN;2/EX & /LI >>>>So I prefer to use the /EX switch interactively! >>>>>PIP >>>>PIP> SUB2.ftn;2/EX >>>>PIP> /li Arnold is right, of course, about this but I am just going to further amplify what is happening here. Originally Dec didn't document this properly, but manuals are presumably now fixed. Perhaps you are using an older one. You will have the SAME problems trying to use other switches such as /DD (date) or /DF. They (DEC) chose not to be able to do it in one normal command line (as SRD does) so they need you to be INTERACTIVE and first have a seperate line to set (latch) the other controls. Then subsequent lines would have these switches apply. As this does not allow oneshot MCR PIP lines to use these switches, they dreamed up the trick of letting you put "&" on the line to have 2 (or more) seperate PIP command lines given to the same invocation of PIP from the MCR level without having to invoke PIP interatively. To have a truely LONG load of pip commands executed under this kind of switch, simply .OPEN a temp command file for pip, fill it with what you need to do, and then PIP @ it. A dumb example: .open pipyuktmp.tmp .sets temp .data *.dat;*/ex .data /dd:*:10-jan-87 .data *.*;*/tr/nm .data alllist.lis=*.*;*/fu:132. .data maclist.lis=*.mac;*/fu:132. .data ftnlist.lis=*.ftn;*/fu:132. .data objlist.lis=*.obj;*/fu:132. .close pip @'temp' pip 'temp'/de/nm ================================================================================ Note 202.3 [RSX]Can Someone Fix My PIP? 3 of 4 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 14 lines 1-NOV-1988 11:14 -< Tanks for the help >- -------------------------------------------------------------------------------- Thanks guys, That was wonderful advise. For some reason, in my recent involvement with DCL, I haven't done a lot of 'boning up' on PIP in the manual. I/we hadn't any idea that & could be used in this case. My PIP is now fitting nicely back on my shoulders. (Bye the bye, in case you weren't aware, a PDP - in high school ROTC - is the officer's ornament which is placed on the shoulders. My daughter, now a 2nd Lt in the Army, called me one day and said that she had dropped her PIP. I thought that was mighty funny and, thus, came the term - can someone fix my PIP.) That was just a little trivia. Thanks again. Charly ================================================================================ Note 202.4 [RSX]Can Someone Fix My PIP? 4 of 4 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 4 lines 1-NOV-1988 11:27 -< Oops, not PDP but PIP!! >- -------------------------------------------------------------------------------- Oops, that was supposed to say PIP not PDP about the high school ROTC. Is it the same in regular armed forces?? Charly  ================================================================================ Note 203.0 [RSX]Packets and Windows HELP!! 4 replies EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 15 lines 28-OCT-1988 17:40 -------------------------------------------------------------------------------- Hello all, Do we have any resident expertise with such items as packets, windows, and message servers. I have need to solve a problem totally out of my league about a program that is being run which, if aborted or exited in a not-normal manner, does not "reassign the LUNS", according to my user. The program cannot be re-run as things are going wrong with windows and packets. I can get more details to enable a really educated opinion. Basically, I need to know if the expertise is here to ask the question. I also think it may require a user-written driver (yuk). I'll get the whole picture next week and provide more information. Thanks, Charly ================================================================================ Note 203.1 [RSX]Packets and Windows HELP!! 1 of 4 EISNER::SIMONS "Paul, Not that CONVEX!" 4 lines 31-OCT-1988 08:06 -< Give us your best shot! >- -------------------------------------------------------------------------------- I personally have found that if a question can't be answered here, it can't be answered. Also that if, by some quirk of fate, the question is answered elsewhere, everyone here would like to know as well. So, give us a try! ================================================================================ Note 203.2 [RSX]Packets and Windows HELP!! 2 of 4 EISNER::WYANT "Tom Wyant" 17 lines 31-OCT-1988 17:04 -< I don't do windows, but ... >- -------------------------------------------------------------------------------- >>> I have need to solve a problem ... about a program that is being >>> run which, if aborted or exited in a not-normal manner, does not >>> "reassign the LUNS", according to my user. The program cannot be >>> re-run as things are going wrong with windows and packets. Charly - Is this a fixed task? Normally, any time that a disk-resident task is loaded, the LUN assignments (as well as any other task attributes) revert to their original values. Various other things could go wrong with a fixed task, also. Does the user know a LUN from a hole in the ground? If not, devices may not being reset properly, or -- well, I hate to think. 'Til you post more info, we're all shooting in the dark. Tom W. -- *:> ================================================================================ Note 203.3 [RSX]Packets and Windows HELP!! 3 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 11 lines 31-OCT-1988 20:02 -< is it P.S.I.? >- -------------------------------------------------------------------------------- >>> ... with such items as packets, windows, and ... problem ^^^^^^^ ^^^^^^^ ^^^^^^^ Those 3 sound like RSX P.S.I. - DEC's x.25 packet software supported? by (or at least written by) Dec's Reading England troops. One gets the impression from its Product Line Manager(s) (2 latest, at least) that they would have prefered it if you had NOT figured out they were related to THAT product. Is it P.S.I. that your questions are about? ================================================================================ Note 203.4 [RSX]Packets and Windows HELP!! 4 of 4 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 8 lines 8-NOV-1988 10:36 -< Problem solved - thanx >- -------------------------------------------------------------------------------- Hi again, The problem has been "solved". My person decided to write his own device driver and to avoid 'fooling around with packets'. I wished him godspeed and told him I do not envy him that predicament. Thanx anyway, Charly  ================================================================================ Note 204.0 [RSX]need help accessing RSX BBS 8 replies EISNER::BRUCE "Barton F. Bruce - CCA/MA" 12 lines 31-OCT-1988 20:21 -------------------------------------------------------------------------------- Help! How does one log into the RSX BBS? Jim Bostwick gave me his card and wrote the BBS phone # on it, but what do I need to log in. Is there a 1st time account to register, or is a prearranged personal password needed, or ... I looked in a recent Multitasker, and the BBS # was listed as a way to enter Multitasker submissions, but no USER/PSWD info. If an answer isn't postable, please send me mail. ================================================================================ Note 204.1 [RSX]need help accessing RSX BBS 1 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 20 lines 1-NOV-1988 00:17 -< RSX BBS Acccess Info >- -------------------------------------------------------------------------------- >> < Note 96.0 by EISNER::BRUCE "Barton F. Bruce - CCA/MA" > >> -< need help accessing RSX BBS >- >> Help! How does one log into the RSX BBS? >> Jim Bostwick gave me his card and wrote the BBS phone # on it, >> but what do I need to log in. The user name is: ACCOUNT The password is: REQUEST The phone number is easy to remember: (612) SPR-PONG thats...(612) 777-7664 This starts a BATCH Job that sets up an account for you. Let me know if there's a problem with the above info ... so I can change it! -Arnold ================================================================================ Note 204.2 [RSX]need help accessing RSX BBS 2 of 8 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 3 lines 2-NOV-1988 12:58 -< PONG! -- The sound of your SPR hitting DEC's mailbox >- -------------------------------------------------------------------------------- >> The phone number is easy to remember: (612) SPR-PONG ^^^^ Any number can play this game! ================================================================================ Note 204.3 [RSX]need help accessing RSX BBS 3 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 2 lines 2-NOV-1988 19:18 -< Yup! Thats the sound (and Action) SPRs have P.O. BOX F! >- -------------------------------------------------------------------------------- >> < Note 96.2 by EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" > >> -< PONG! -- The sound of your SPR hitting DEC's mailbox >- ================================================================================ Note 204.4 [RSX]need help accessing RSX BBS 4 of 8 EISNER::RICE "Gary Rice" 16 lines 12-NOV-1988 05:02 -< SnailMAIL? >- -------------------------------------------------------------------------------- >> Help! How does one log into the RSX BBS? > The user name is: ACCOUNT > The password is: REQUEST > The phone number is easy to remember: (612) SPR-PONG > thats...(612) 777-7664 > This starts a BATCH Job that sets up an account for you. I did that the Monday following Symposium. To date the results of the Batch job are not apparent. How do I know what my account is (and password)? Gary ================================================================================ Note 204.5 [RSX]need help accessing RSX BBS 5 of 8 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 11 lines 12-NOV-1988 21:36 -< RSX BBS P/W >- -------------------------------------------------------------------------------- >>How do I know what my account is (and password)? When I first logged in, it either gave me 'last_name'/'first_name' or more probably 'last_name'/'decus_number'. I don't even remember which, but P/W was from just suplied data, and then I logged back in and changed the P/W to something I would remember. They currently simply log you out so you can log in as yourself, and so I had suggested to Jim at Anaheim that he use BYE /HOLD so people don't have to redial. If someone with priv on that machine (Arnold?) is listening they might remember to fix that. ================================================================================ Note 204.6 [RSX]need help accessing RSX BBS 6 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 13 lines 14-NOV-1988 15:57 -< No Privs on RSX BBS, However will pass on Request fo BYE/HOLD! >- -------------------------------------------------------------------------------- >> < Note 96.5 by EISNER::BRUCE "Barton F. Bruce - CCA/MA" > >> -< RSX BBS P/W >- >> They currently simply log you out so you can log in as yourself, >> and so I had suggested to Jim at Anaheim that he use BYE /HOLD >> so people don't have to redial. If someone with priv on that machine >> (Arnold?) is listening they might remember to fix that. No Privs here ... In fact that is the FIRST RSX machine I've ever used that I don't have privs on! However, I will pass that request on to Jim Bostwick, RSX SIG Chair and BBS Maintainer! -Arnold ================================================================================ Note 204.7 [RSX]need help accessing RSX BBS 7 of 8 EISNER::RICE "Gary Rice" 6 lines 16-NOV-1988 10:20 -< Is it really a BBS? >- -------------------------------------------------------------------------------- Well, I got in to the BBS. Thanks for the ID/Password combination. BUT, all I saw there is some "news" from the Sysop, a mail facility and little else. Am I missing something? Gary ================================================================================ Note 204.8 [RSX]need help accessing RSX BBS 8 of 8 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 41 lines 16-NOV-1988 18:07 -< RSX's own BBS needs activity >- -------------------------------------------------------------------------------- >>< Note 96.7 by EISNER::RICE "Gary Rice" > >> -< Is it really a BBS? >- >>Well, I got in to the BBS. Thanks for the ID/Password combination. >>BUT, all I saw there is some "news" from the Sysop, a mail facility >>and little else. That is what I saw, too. I think there may be a few Decus Sig tape things out there, and if someone hadn't seen them before, reading their help, or trying them might be of interest. The SRD there was VERY old, but Jim depends on some master kit at work that someone else does not often update with the latest sig tape stuff. He did say there may be a faster and I/D type CPU coming, and a tape drive, that would make things better. I poked around and read such things as SYSLOGIN.cmd, and found a list of all users appended to as they request accounts, and filled with duplicates. I amused myself by writing a command file to sort it and shrink out duplicates. I found that AT. is very slow on an 11/24, and the initial 1 way bubble sort turned into a 2 way one to get done in a reasonable amount of MINUTES. It does take some amount of stuff there, and some amount of new stuff and interaction with other users to have that critical mass to then be self sustaining. I do fear that it is still on the way to building such mass, and with this BBS here being so relatively active and offering something new of interest in at least some conference for every time one logs in, people would tend to use this for RSX stuff even though the RSX one is FREE. I sent a requested DZ controller card to it today, and there is need for more hardware if anyone has spare stuff to contribute. I wish it luck and plan to check in periodically. Maybe it will get rolling faster. >>Am I missing something? I doubt it.  ================================================================================ Note 205.0 [RSX]TU77 on 11/84: Can It Be Done??? 1 reply EISNER::ROSENSTEIN "Steve Rosenstein" 19 lines 9-NOV-1988 09:40 -------------------------------------------------------------------------------- We would like to upgrade our PDP 11/44 system to a PDP 11/84 system. The PDP 11/44 system has a TU77 as its tape drive, which we would like to carry over to the 11/84 system. We have heard conflicting remarks from different sources as to whether the TU77 does or does not work in an 11/84 configuration. If there is anyone out there who has crossed this bridge, and is currently using a TU77 in an 11/84 or has found out that it definately will *Not* work, we would appreciate the information. The is being entered for some of the PDP-types in my shop, so if you have any hot leads, please contact: Barry Essig, Bob Martin, or Lillian Hertel Grumman Aircraft Systems MS G01-14 Bethpage, NY 11714 (516) 575-1038 or 575-3352 Thank You! -- Steve Rosenstein ================================================================================ Note 205.1 [RSX]TU77 on 11/84: Can It Be Done??? 1 of 1 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 78 lines 9-NOV-1988 20:16 -< TU77 fine on 11/84 >- -------------------------------------------------------------------------------- >> The PDP 11/44 system has a TU77 as its tape drive, which we would >> like to carry over to the 11/84 system. We have heard conflicting >> remarks from different sources as to whether the TU77 does or does >> not work in an 11/84 configuration. I am assuming you are using a recent M+ system, but can't offhand even think of any reason this shouldn't work on vanilla M. Of course it works! The TU77 is NOT a very heavy load. The TM03 formatter in a master drive connects to a standard Massbus which you have provided in your 11/44 with an RH11. The 11/84 should be able to take anything that you can hang on your slower 11/44. The only 'feature' the 11/44 supports that the 11/84 doesn't is the CIS hardware, and that is a CPU, not Unibus area issue. I have used an RM05 on an 11/84, and that WAS some trick to do. DEC had to do an ECO for the RH11. RP04/5s and TU77/45/16 and other SLOW stuff all run fine on a vanilla RH11. The ECO'd one was needed for the RM05 that has 32 x 512 byte sectors / revolution at 3600 RPM. That averages to 983040 bytes / second, but the peek transfer rate while actual data is moving is faster. The RP04s that easily work I think are about 22 sectors / track and that is 675840 bytes / sec (actually peeks faster as on the RM05). The TU77 is only 125 ips, and at 1600 bpi that is a piddling 200,000 bytes / second max. The TU78 (that does work on an 11/70, and for which they provide the M+ driver) is 125 ips x 6250 = 781250 bytes per second which puts it between the RP04 and the RM05. I bet the TU78 would even work on the 11/84 with the ECO'd RH11, and there is a chance it would work without the RH11 ECO. I would even assume an TU77 would work on an 11/24! The relatively recent ECOs for the TU/TA78 fell into 2 areas. First was to read or write electronics and does not apply to you. The other ones were to the mechanical parts in a desperate attempt to have the drive occasionally self thread the first time... These latter fixes apply egually well to the TU77. Just keep beating on F/S until they put them in. With slave TU77 drives selling used at the same price as a few months of service, the market message is that these are expensive to maintain DOGS that there is little demand for. The last time I noticed someone trying to unload one was MANY months ago for well LESS than $1k. Except to use on hand hardware, don't spend a lot of money on them as it is cheaper to BUY a newer better GCR streamer drive than just to maintain the old slow PE vacuum column one over a modest period of time. DEC won't officially state that combinations of hardware are supported unless they have tried it and lots of different people have signed off of on its working. I dare say there in little incentive to do any extensive (and expensive) testing with TU77s on 11/84s. The RH11 ECO for RM05s is talked about here in HARDWARE_HELP 203.0. Any problems with it, and I could even give you the names on the 2 DEC engineers that did the ECO (both appear regularly at DECUS). The 11/84 PLM is George Paquin. I can't seem to find his card, but a call to Maynard will get you connected. If the local DEC types are giving too much B/S try him. He will know of all sorts of successful but unsupported configurations for HIS cpu. He can't force unsupported combinations on F/S or anything like that, but may be able to give you needed encouragement. The Tx7x drive PLM was Bruce Gordon a few DECUSes ago, and may still be, although I havn't seen him since. It may not be SOP for customers to bug DEC Product Line Managers (except at Symposia, of course), but he will know the TU78 ECO #s and might have suggestions on getting a stubborn local F/S manager to apply them to a TU77, and may know about 11/84 support, too. I have yet to stick myself in WHO_AM_I, but if you need to reach me, it is: (617) 868-1111.  ================================================================================ Note 206.0 [RSTS]Version 9.6 Sysgen Help 9 replies EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 8 lines 11-NOV-1988 16:54 -------------------------------------------------------------------------------- Hello all, Has anyone done a 9.6 'gen lately?? Have you had/found a solution to/etc. a problem that develops in the first stages - after or during the copy of [0,1] from tape to RL01???? Help will be definitely appreciated.. Charlotte ================================================================================ Note 206.1 [RSTS]Version 9.6 Sysgen Help 1 of 9 EISNER::KENNEDY "Terry Kennedy" 7 lines 11-NOV-1988 22:37 -< More information needed >- -------------------------------------------------------------------------------- > Has anyone done a 9.6 'gen lately?? Have you had/found a solution > to/etc. a problem that develops in the first stages - after or > during the copy of [0,1] from tape to RL01???? Could you be more specific? What error message do you get, and what was the previous message? Is this a new install or an update? How many free blocks are on your system disk? ================================================================================ Note 206.2 [RSTS]Version 9.6 Sysgen Help 2 of 9 EISNER::CONROY "Alan Conroy" 13 lines 14-NOV-1988 13:32 -< V9.6 startup weirdness >- -------------------------------------------------------------------------------- I don't know if this is the problem you've been experiencing, but we've had some bizzare happenings that started after installing V9.6 on our 11/73. In any case, it might be helpful to others if I post it here. Trying to start the system causes a trap to 4. After some epxerimentation I found that changing the size of XBUF down from what it was would fix the problem and let me start. The next time I was down, guess what? Yup - so I adjusted it down again and it started fine. XBUF was originally 296K, then I changed it to 256K, now it's 250K. I haven't SPRed this yet since I want to do some more experimentation (such as, does the fix happen if I adjust the size of XBUF up? Does this problem happen on an 11/70? etc). When I know more I'll post a reply here (and send in a SPR). I'm fairly certain this is an INIT.SYS bug. I would hazard to guess that something is not initialized properly in the memory map and changing XBUF's size fixes it. ================================================================================ Note 206.3 [RSTS]Version 9.6 Sysgen Help 3 of 9 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 25 lines 16-NOV-1988 11:25 -< More information supplied >- -------------------------------------------------------------------------------- Hi, The situation is this: I provided the computer for a customer to use for building his RSTS system. I haven't used RSTS since 1982 and only stood by in case he needed hardware help, etc. He booted his standalone system from MS: (the tape drive); it came up with "Start timesharing?" to which he took the default...etc. until he got to the prompt, "Please mount the RSTS/E Installation media... Installation device?<_MS0:>" to which he took the default. The next things he saw were "Restoring required _SY0:[0,1]components" and "RSTS V9.6-11 SYSGEN (DL0) INIT V9.6-11" and "Start timesharing?" again. He explained to me that the system had crashed, rebooted itself and started again. He also stated that, when he was a beta test site, DEC had "fixed" a bug that occured during updating. I have no idea what this all means - unless he was supposed to mount a different tape when it asked for "the RSTS/E Installation media". Does this give you any more information? Also, I must add that, when my young man talked to DEC, they told him to enter the hardware option and disable all devices not needed...that didn't work either. Thanks for whatever, Charly ================================================================================ Note 206.4 [RSTS]Version 9.6 Sysgen Help 4 of 9 EISNER::CONROY "Alan Conroy" 7 lines 16-NOV-1988 13:09 -------------------------------------------------------------------------------- > I have no idea what this all means - unless he was supposed to mount > a different tape when it asked for "the RSTS/E Installation media". I'm not sure what is happening, but I can safely say that mounting the wrong tape would not crash the system unless he had 1) a hardware problem, 2) a software problem (the OS), or 3) both of the above. Did he try it again? With/without the same results? ================================================================================ Note 206.5 [RSTS]Version 9.6 Sysgen Help 5 of 9 EISNER::KENNEDY "Terry Kennedy" 21 lines 17-NOV-1988 01:56 -< Next iteration >- -------------------------------------------------------------------------------- > The next things he saw were "Restoring required _SY0:[0,1]components" > and "RSTS V9.6-11 SYSGEN (DL0) INIT V9.6-11" and "Start timesharing?" > again. He explained to me that the system had crashed, rebooted itself > and started again. He also stated that, when he was a beta test > site, DEC had "fixed" a bug that occured during updating. First, another go-round on some of my questions: 1) I'll assume this was an update (since you had no disk initialize text in your note). What version were you updating from? 2) How many free blocks on the disk? (This is important) Next, I haven't seen this problem or the Trap 4 problem on any of my (multitude of) systems. Doesn't mean it can't happen, though... Since your user stated 'he was a beta test site', I'd mention that it is important to run the real SDC version of the tape, rather than any test tape. Even if they have the same version numbers, they might not be identical. For V9.6 on 1600 BPI magtape, the part number is BB-P016N-BC. One last thing - how much memoryis in the system? ================================================================================ Note 206.6 [RSTS]Version 9.6 Sysgen Help 6 of 9 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 12 lines 17-NOV-1988 18:29 -< Unsure but sure >- -------------------------------------------------------------------------------- As far as I know, the RL01 he was working on had no problems. I can't be that sure about his tape. He tried again with the same results numerous times. Realizing that I am quite ignorant as far as the RSTS end of this goes, I guess I should say I have been system mangling this 11/44 for at least 1-1/2 years and, though it has it's share of problems, I can't see any hardware problems at the moment. I know less about whether/or how my young man modified/added-to his tape. I suspect he may have tried to append information to it - but I'm not sure. Charly ================================================================================ Note 206.7 [RSTS]Version 9.6 Sysgen Help 7 of 9 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 43 lines 17-NOV-1988 18:58 -< I'll explain thoroughly now >- -------------------------------------------------------------------------------- I appreciate the questions - I can ask him the same. This is what I see on the console copy: . Bo MS0 followed by "program" followed by RSTS V9.6 (MS0) INIT v9.6-11 followed by query for today's date . "Installing RSTS on a new system disk " - he took the default . "Disk?" DL0 followed by information and questions on pack, create account [1,2], etc. followed by disk pack serial number, then pattern 1 then copying required system files, then "performing limited hardware scan. . Query - start timesharing? - took default - followed by "starting sysgen.sil... followed by rebooting ... . RSTS identification information followed by "Creating SWAP.SYS file with minimum size of 128 blocks...memory available to RSTS is 1408K words...crash.sys file...please mount the RSTS/E Installation media and enter the name and unit number...installa- tion device? (took the default)...Restoring required _SY0: [0,1]components. . Then it comes back with RSTS V9.6-11 Sysgen (DL0) INIT V9.6-11 and asks "Start timesharing?" again. He takes the default, it says disk is being rebuilt, disables devices and asks if he wants to perform an installation or update (he says installation). . It goes through more printing about mounting and naming installa- tion media...asks if he wants to start timesharing again (he says no) and prompts for option. . he types 'RE'..then tye system asks him what refresh suboption he types 'li' and it lists system files (swap,ovr,err,buff,crash) and other files (bad,satt,sysini....getsys.tsk). He then chooses the option BO (boot) and it asks which device. He says MS0... it boots, asks if he wants to update...he says yes..and DL0... . It then copies files, prints 'start timesharing' again..he says yes...it goes through the map stuff again...he tells it to update ...it says restoring _sy0:[0,1]components again and asks about timesharing again - he says no. I could go on forever but I hope this will help. He is using, as I said, an RL01 disk which is, as far as I can tell, empty. The 11/44 has 1024K of memory. Does this help explain what he is doing? Thanks, Charly ================================================================================ Note 206.8 [RSTS]Version 9.6 Sysgen Help 8 of 9 EISNER::KENNEDY "Terry Kennedy" 48 lines 17-NOV-1988 20:09 -< *Long* response w/ solution follows >- -------------------------------------------------------------------------------- > . "Disk?" DL0 followed by information and questions on pack, create > account [1,2], etc. followed by disk pack serial number, then > pattern 1 then copying required system files, then "performing > limited hardware scan. Retry this step taking the default 3 patterns. By the explanation above, your user only did one test pattern to save time. You may have a marginal bad spot. > file with minimum size of 128 blocks...memory available to RSTS > is **1408K words**...crash.sys file...please mount the RSTS/E But you say below that your machine has 1024KW. Very strange. You can't get 1408KW using DEC boards. Try booting diagnostics (XXDP) and issue the command: R ZMSP?? and look for any error messages or unusual output. The first report out is something like nnn Kwords of MS11x, etc. I need to see that. Also run diagnostic KKAB?? but be sure to cycle power first or it will fail. > . Then it comes back with RSTS V9.6-11 Sysgen (DL0) INIT V9.6-11 > and asks "Start timesharing?" again. He takes the default, it At this point, answer DE to the start... question. When asked 'any mem- ory allocation changes, say 'yes'. answer 'LI' to 'table suboption'. Re- port results here. ------------------ It looks like you have a memory configuration problem or a bad memory card. If you're up to it, power off the system, take the top off the 11/44 and look in the memory slots (there should be a decal on the cover to in- dicate which slots those are). Or, working from right to left, each slot (if occupied) has a board numbered M709x, where x is 0 at the right slot and counts up one for each slot to the left. The sequence ends somewhere around M7097. The first slot to the left of the sequence end is the first memory slot, and the next 3 are also memory slots. Write down the M numbers of the boards in the 4 memory slots (some may be empty). These numbers are probably M87xx or M88xx series. That will also help. Lastly, your user may want to try the install again, but with the fol- lowing changes: AT the first 'start timesharing', say 'IN SYSGEN' instead of . Then say 'DE' to 'Option?'. Say 'yes' to 'memory allocation changes' Say 'XBUF' to 'table suboption'. Say 'RESET'. Say 'lock' to 'table suboption'. Respond '512K-1407K' to 'lock address is'. Say 'XBUF' to 'table suboption'. Say '80K' to 'enter ... size'. Use to get back to 'Option ?' Press to proceed. This will disable all memory above 512K in RSTS. ================================================================================ Note 206.9 [RSTS]Version 9.6 Sysgen Help 9 of 9 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 16 lines 22-NOV-1988 10:35 -< Appreciation...hug,hug >- -------------------------------------------------------------------------------- Thanks Terry, I am in the process of checking our system out and I will be in touch with my user first of next week (if all goes well). We have been (during 1986-1987) straining to justify keeping our PDPs. Now, with request for assistance coming in on an EXtremely constant flow, I may be able to convince my management that the 200 plus PDPs in GM plants and other EDS areas still need support. Partly due to your input, I will also be able to justify proper maintenance of our 'development' system. I'll let you know what we find out. Happy Thanksgiving to you - and to all. Charly  ================================================================================ Note 207.0 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 5 replies EISNER::KENNEDY "Terry Kennedy" 10 lines 13-NOV-1988 20:07 -------------------------------------------------------------------------------- <<< EISNER::DUA0:[NOTES$LIBRARY]VAX_PUBLIC_DOMAIN_SOFTWARE.NOTE;1 >>> -< VAX Public Domain Software >- ================================================================================ Note 54.0 PDP/RSTS Driver for HP LASER JET No replies EISNER::MCDOUGALL "Bob McDougall" 3 lines 13-NOV-1988 18:29 -------------------------------------------------------------------------------- Does anyone know if there is a driver for the HP LASER Jet printer 500 which would run on a PDP/RSTS system? If so, where can I find out more about it? ================================================================================ Note 207.1 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 1 of 5 EISNER::KENNEDY "Terry Kennedy" 18 lines 13-NOV-1988 20:20 -< No driver normally required >- -------------------------------------------------------------------------------- > Does anyone know if there is a driver for the HP LASER Jet printer > 500 which would run on a PDP/RSTS system? > If so, where can I find out more about it? Depends on what you mean by 'a driver'. All LaserJets I have seen have either a RS-232 serial interface or a Centronics-type parallel interface. For the serial case, RSTS's V9.x Print/Batch Services will use a serial port to talk to it, and you'll get full system banner pages, etc. The parallel interface is not the same as the current LP11 line, but the controller can be strapped to accomodate the LaserJet. Just set the control- ler up for a LA180-style interface. The printer doesn't require any special driver software to print straight text. Many 3rd-party packages support soe of the LJ's features such as fonts and graphics, or you could write your own from the descriptions in the HP programmer's manual. ================================================================================ Note 207.2 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 2 of 5 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 6 lines 13-NOV-1988 20:53 -< WE NEEDED TO DO SOMETHING >- -------------------------------------------------------------------------------- > -< No driver normally required >- We have used HP LJ's on RSTS and had to imbed escape sequences in the text to get them to work properly. I did not do the project - I will check on this. ================================================================================ Note 207.3 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 3 of 5 EISNER::MCDOUGALL "Bob McDougall" 10 lines 20-NOV-1988 12:33 -< any luck checking? >- -------------------------------------------------------------------------------- > < Note 46.2 by EISNER::KILLEEN "Jeff Killeen DECUServe Chair" > > -< WE NEEDED TO DO SOMETHING >- > >> -< No driver normally required >- > >We have used HP LJ's on RSTS and had to imbed escape sequences in the text >to get them to work properly. I did not do the project - I will check on >this. any luck checking? ================================================================================ Note 207.4 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 4 of 5 EISNER::HAVEMANN 42 lines 22-NOV-1988 13:41 -< HP Laserjet Formatting Program (RSTS-E) >- -------------------------------------------------------------------------------- < Note 46.0 by EISNER::KENNEDY "Terry Kennedy" > -< RSTS driver for HP LASER JET (Moved from VAX_PD 54.0) >- <<< EISNER::DUA0:[NOTES$LIBRARY]VAX_PUBLIC_DOMAIN_SOFTWARE.NOTE;1 >>> -< VAX Public Domain Software >- ================================================================================ Note 54.0 PDP/RSTS Driver for HP LASER JET No replies EISNER::MCDOUGALL "Bob McDougall" 3 lines 13-NOV-1988 18:29 -------------------------------------------------------------------------------- Does anyone know if there is a driver for the HP LASER Jet printer 500 which would run on a PDP/RSTS system? If so, where can I find out more about itK? -< RSTS driver for HP LASER JET (Moved from VAX_PD 54.0) >- We have written and use extensively an in-house formatting program for the HP Laserjet + Series 2. Some of the features are as follows: - automatic font downloading - portrait and landscape mode - line, box, and pattern drawing - proportional and fixed font centering and right justification - support for italics, boldfacing, and underlining - setting of margins, print position, etc. The program works by embedding ASCII commands as part of of the document created by EDT. The actual formatting program operates as a detached message-receiving job and accepts document filenames to be printed (and other commands) via a CCL call. It handles spooling, job prioritizing and cancelling, etc. If there is sufficient interest in this program from the DEC community we will consider marketing it. Contact Lee Havemann at: HSH Associates 1200 Route 23 Butler, NJ 07405 (201)838-3330 ================================================================================ Note 207.5 [RSTS]RSTS driver HP LASERJET (From VAX_PD 54.0) 5 of 5 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 31 lines 22-NOV-1988 14:15 -< HOPE THIS HELPS >- -------------------------------------------------------------------------------- Bob... Here are the setups we use.... 10 ! NOTE: THE SEQUENCE OF COMMANDS IS VERY IMPORTANT!! & 1210 ESC$=CHR$(155%) \ & LEAD.IN$=ESC$+"&l" & 2010 PRINT #1%, ESC$; "E"; ! PRINTER RESET & 2020 PRINT #1%, ESC$; "&k0G"; ! END OF LINE TERMINATION & 2030 ! PRINT #1%, LEAD.IN$; "66P"; ! PAPER LENGTH=66 & 2040 ! PRINT #1%, LEAD.IN$; "0O"; ! PORTRAIT ORIENTATION & 2050 PRINT #1%, LEAD.IN$; "1E"; ! TOP MARGIN=1 & 2052 PRINT #1%, LEAD.IN$; "65F"; ! TEXT LENGTH=65 & 2054 PRINT #1%, ESC$; "&a1L"; ! LEFT MARGIN=COLUMN 1 & 2056 ! PRINT #1%, ESC$; "&a82M"; ! RIGHT MARGIN=COLUMN 82 & 2060 PRINT #1%, LEAD.IN$; "6D"; ! LINES PER INCH=6 & 2065 PRINT #1%, LEAD.IN$; "0L"; ! PERFORATION SKIP=DISABLED & 2070 PRINT #1%, LEAD.IN$; "1X"; ! COPIES=1 &  ================================================================================ Note 208.0 [RSX]Kermit for RSX11m V3.2 (From VAX_PD 55.0) 1 reply EISNER::KENNEDY "Terry Kennedy" 11 lines 13-NOV-1988 20:25 -------------------------------------------------------------------------------- <<< EISNER::DUA0:[NOTES$LIBRARY]VAX_PUBLIC_DOMAIN_SOFTWARE.NOTE;1 >>> -< VAX Public Domain Software >- ================================================================================ Note 55.0 KERMIT for RSX-11m V3.2; PDP-11/34 No replies EISNER::MCDOUGALL "Bob McDougall" 4 lines 13-NOV-1988 18:33 -------------------------------------------------------------------------------- Is there a KERMIT for RSX-11m V3.2 running on a PDP-11/34? I have the last couple KERMIT tapes that were distributed, what files should I be looking for? ================================================================================ Note 208.1 [RSX]Kermit for RSX11m V3.2 (From VAX_PD 55.0) 1 of 1 EISNER::KENNEDY "Terry Kennedy" 7 lines 13-NOV-1988 20:28 -< K11*.* >- -------------------------------------------------------------------------------- > Is there a KERMIT for RSX-11m V3.2 running on a PDP-11/34? > I have the last couple KERMIT tapes that were distributed, > what files should I be looking for? All Kermits for the PDP-11 share a common set of sources. Look for K11*.* on the tape. As Columbia does not distribute binaries, you'll need to re-assemble and taskbuild it. Files to do so are included.  ================================================================================ Note 209.0 [RSX]DR11-C Blues 2 replies EISNER::CLARK_W 26 lines 15-NOV-1988 20:32 -------------------------------------------------------------------------------- I am upgrading a system from M V3.2 to M+ V3.0 and I've run into a problem. The existing system has an interface with a custom driver that uses a DR11-C. This thing has worked for years on the M system. I modified the M driver for M+, but still couldn't get the interface working. In despration, I started using OPE to control the device and did not even load the driver. I found that under M, the REQ A bit in the CSR will be cleared just by stepping through the device registers, and that the device will send back data if I OPE the output register and deposit a command. Under M+, the REQ A bit never clears and I never get any data back. My only thought was that some other device in the M+ system was conflicting with the DR11-C, but I've created new system images and left out practically everything except the TT and disk drivers. The DR11-C CSR is at 167770 and the vector is 160. I do not have an RL02 in the system. I run the M and M+ systems on the exact same hardware. I'd welcome any ideas on why OPE can't talk to this device under M+. Bill Clark E. I. Du Pont (302) 366-4179 ================================================================================ Note 209.1 [RSX]DR11-C Blues 1 of 2 EISNER::STAMERJOHN "RW Stamerjohn" 3 lines 16-NOV-1988 14:19 -< Check m+ ope switches >- -------------------------------------------------------------------------------- shot in the dark, but you might need to use /KNLD switch to make sure you are hitting I/O page and not memory (or use absolute 22-bit address of 17767770). ================================================================================ Note 209.2 [RSX]DR11-C Blues 2 of 2 EISNER::CLARK_W 13 lines 16-NOV-1988 15:40 -< More info on DR11-C Blues >- -------------------------------------------------------------------------------- < Note 99.1 by EISNER::STAMERJOHN "RW Stamerjohn" > -< Check m+ ope switches >- shot in the dark, but you might need to use /KNLD switch to make sure you are hitting I/O page and not memory (or use absolute 22-bit address of 17767770). Thanks for the idea. During my testing I tried both the 22-bit address and the /KNLD form. The results were the same in both cases. Also, the system is an 11/70 and the M+ system is generated as a full function executive.  ================================================================================ Note 210.0 [PRO300]POS Printer FormFeeds 3 replies EISNER::HERDELL 6 lines 28-NOV-1988 11:47 -------------------------------------------------------------------------------- I have a problem controlling all of the extra formfeeds the printer driver is throwing in when a dcl print command is issued. I have not yet found a way to control the FFs in V3.0..anybody solved this one? Tnx.. Richard ================================================================================ Note 210.1 [PRO300]POS Printer FormFeeds 1 of 3 EISNER::RICE "Gary Rice" 15 lines 29-NOV-1988 08:51 -------------------------------------------------------------------------------- > I have a problem controlling all of the extra formfeeds the printer > driver is throwing in when a dcl print command is issued. I have > not yet found a way to control the FFs in V3.0..anybody solved this one? There were NUMEROUS problems with the P/OS V3.0 printer S/W. DEC's contrinuous answer to the FF problem, lost jobs problem, incompatible sequence problems, etc. was to ugrade to v3.1. Then after v3.1 came out, they decided to give the patches to the v3.1 print S/W to the public domain (and included the stuff with v3.2). If you can locate the v3.1 P/OS S/W, I can provide you with the v3.1 patches. Or better still, use v3.2. It is MUCH better than the v3.0 stuff that you have. Gary ================================================================================ Note 210.2 [PRO300]POS Printer FormFeeds 2 of 3 EISNER::HERDELL 9 lines 29-NOV-1988 16:22 -< 3.2 drivers on 3.0 >- -------------------------------------------------------------------------------- Gary ... sure sounds like you are saying I need to upgrade to 3.2. Do you mean just upgrade my drivers or the complete kit. The driver upgrade is feasable if 3.2 drivers can be located but upgrading the complete system is not feasable anymore. I wonder when or if DEC will release the POS source so we can enhance Klingon Technology? Richard ================================================================================ Note 210.3 [PRO300]POS Printer FormFeeds 3 of 3 EISNER::RICE "Gary Rice" 26 lines 30-NOV-1988 08:22 -< Sources? Maybe. >- -------------------------------------------------------------------------------- > Gary ... sure sounds like you are saying I need to upgrade to 3.2. > Do you mean just upgrade my drivers or the complete kit. The driver... The patch that I have can be applied to P/OS v3.1 systems ONLY. It was INCLUDED in v3.2 for you. Therefore, you need to be at v3.1 or better to take advantage of the fixes. > I wonder when or if DEC will release the POS source so we can enhance > Klingon Technology? I have talked extensively to Jeff Slayback (the PC SIG PRO Counterpart at DEC) about this issue. His response (ie: DEC's response) is: If the product doesn't conflict with other DEC product lines that are still being sold, then there is some chance that the sources will make it to the public domain. You can read that as: PRO/Sight Yes Synergy Yes P/OS NO! Languages NO! Toolkit NO! etc. Gary  ================================================================================ Note 211.0 [PRO300]Multiple OS PRO 4 replies EISNER::HERDELL 14 lines 28-NOV-1988 12:07 -------------------------------------------------------------------------------- I have two hard disks with different OS's on them which I physically (remove from the cab) switch out of the system when I want to change the OS. One drive has Venix & the other POS 3.0. The last time I did this this, I didn't ground myself and I zapped my 3.0 drive & ended up doing a reload. Before I do a hardware hack on an electronic switch for these disk drives, I would like to know if anybody has already built one. By the way, in the world of 'Klingon' technology, what is the cost effective way to add hard drives to a PRO350? Tnx..Richard ================================================================================ Note 211.1 [PRO300]Multiple OS PRO 1 of 4 EISNER::RICE "Gary Rice" 17 lines 29-NOV-1988 08:57 -------------------------------------------------------------------------------- > By the way, in the world of 'Klingon' technology, what is the cost effective > way to add hard drives to a PRO350? Our good friend from "Klingon Technology" is sadly no longer logging in to DECUServe. He decided that the benefit wasn't worth the cost. As for disk drives, How much disk capacity do you desire (up to a PRO maximum of 71 MB)? Depending on the answer, you will have a different matrix of S/W versions, patches, Controller card ROMs and vendors. However, these days, the most expensive (non DEC) drive that fills the bill fill run you under $1,000. Gary ================================================================================ Note 211.2 [PRO300]Multiple OS PRO 2 of 4 EISNER::MAYHEW "Bill Mayhew" 33 lines 29-NOV-1988 12:04 -< Some possibilities >- -------------------------------------------------------------------------------- It is theoretically possible to put a second bootable hard disk on a Pro... or for that matter just to put a second hard disk there, and boot it via an intermediate boot from the floppy. The Pro Expansion Box, or whatever it's called, provides a free-standing disk expansion unit into which you can add whatever supported disk you like. However, as far as DEC is concerned, it requires a separate controller. (Note that a single controller can in fact, from a hardware standpoint, support multiple drives -- DEC just doesn't support it, cabling being one of the issues I guess.) From my days digging into (and reverse assembling!) the Pro boot ROM, I recall that there is an address to which you can jump, with appropriate values in the registers (esp. R0), that tells the ROM to boot your Pro from a given "unit number". Hence you could write a suitably privileged P/OS program that loads R0 with the right stuff and then jumps to the appropriate ROM address, thereby booting your system from the other (Venix) disk... and vice-versa. Or, you could write a little standalone program and put it on an RX50 that would boot the Venix disk, again assuming it's on the expander box. The thought of doing any kind of mechanical switch-based trick to allow switching the two gives me mild chills. It is also possible (again theoretically), given a big enough disk, to create a big contiguous file under P/OS which happens to be "the Venix disk"... i.e. put both operating systems on the same drive, each "owning" part of the physical space. Again, a privileged P/OS program, or a standalone floppy, could boot Venix. I actually started down this road (using Idris, not Venix) but didn't have enough time to follow through (and "time" also equates to "market demand"). ================================================================================ Note 211.3 [PRO300]Multiple OS PRO 3 of 4 EISNER::LEDERMAN "Bart Z. Lederman" 4 lines 29-NOV-1988 12:56 -< How about a second system? >- -------------------------------------------------------------------------------- Considering the current cost of used PRO-350s, have you considered that it might be cheaper to just buy a second unit? Especially if someone has a unit with a dead disk that you can slip your second disk into. ================================================================================ Note 211.4 [PRO300]Multiple OS PRO 4 of 4 EISNER::HERDELL 5 lines 29-NOV-1988 16:43 -< Good Stuff >- -------------------------------------------------------------------------------- The idea of supporting two disk drives on one controller sounds more reasonable than an electronic switch .. I agree. I have no experience with an expander box, or even if I can pick one up reasonably. Creating two daisy-chained connectors sounds like a solvable problem....Tnx  ================================================================================ Note 212.0 [PRO300]MS-DOS on a PRO No replies EISNER::HERDELL 4 lines 29-NOV-1988 16:50 -------------------------------------------------------------------------------- Is anybody using a MS-DOS daughter board in their PRO? If so, what is your opinion of it. Where did you get it? Richard  ================================================================================ Note 213.0 [PRO300]PRO HARDWARE 16 replies EISNER::PROVOST 1 line 30-NOV-1988 14:02 -------------------------------------------------------------------------------- This TOPIC is for discussion of PRO hardware issues. ================================================================================ Note 213.1 [PRO300]PRO HARDWARE 1 of 16 EISNER::PROVOST 17 lines 30-NOV-1988 14:04 -< PRO MEMORY EXPANSION >- -------------------------------------------------------------------------------- I HAVE ENTERED THE FOLLOWING QUESTION IN HARDWARE_HELP TOPIC 7. I repeat it here in case someone here has an answer. Given: 1 PRO-350 with 512K memory. Needed: More memory without sacraficing slots. I am told this can be done by changing chips on the mother board. There was an article on how to do this in a past SIG Newsletter. Can anyone point me more directly at the article? Alternatively, can you tell me what must be done? Thanks, Tom ================================================================================ Note 213.2 [PRO300]PRO HARDWARE 2 of 16 EISNER::LEDERMAN "Bart Z. Lederman" 11 lines 30-NOV-1988 14:28 -< daughter board upgrade >- -------------------------------------------------------------------------------- You do not change chips on the motherboard. There are two small memory daughter boards which contain 128k each. You can remove the 64k rams from these boards (carefully, with a soldering iron) and then put in 256k rams to make each board 512k each: you also solder in two wire jumpers on the board so that the CPU will recognize how much memory is on each board. I've done four: the first two I soldered in sockets and plugged in the rams (the safe and reccomended way) and the second two I soldered the rams directly on the boards (the not so safe way: I reccomend sockets). If you are good with a soldering iron, it's an easy upgrade: if not, let someone else do it, especially when you consider how much rams cost now. ================================================================================ Note 213.3 [PRO300]PRO HARDWARE 3 of 16 EISNER::KOZAM 7 lines 30-NOV-1988 21:43 -< See DEC Professional, September 1986 >- -------------------------------------------------------------------------------- Do-it-yourself PRO memory expansion was written up in the September, 1986 DEC Professional (PRO 350 Memory Expansion by Bruce M. Eteson, page 56). It includes pictures and detailed instructions (i.e. exactly which jumpers need to be soldered). If you can't find the issue, I can send a photocopy (only 3 pages long). ================================================================================ Note 213.4 [PRO300]PRO HARDWARE 4 of 16 EISNER::PROVOST 3 lines 1-DEC-1988 14:52 -< Thanks for the memory >- -------------------------------------------------------------------------------- Thanks! I have the article. Tom Provost ================================================================================ Note 213.5 [PRO300]PRO HARDWARE 5 of 16 EISNER::LEDERMAN "Bart Z. Lederman" 24 lines 12-JAN-1989 18:57 -< Getting disk/controller errors. Help? >- -------------------------------------------------------------------------------- My PRO is having problems with the hard disk or controller. Occasionally when I start it up it fails to find the hard disk, and prompts me for a floppy. If I leave it alone or power off and on it will find the disk and boot. Once it boots the RMD display shows no errors, and installing and running the diagnostic utility shows no errors. Today it drew the picture of the system with the first slot highlighted, and the numbers 010013 000401 with the first 01 on the top line in reverse video, and prompted for a floppy. Naturally I put in the self staring diagnostics, which ran and found no errors. When I re-powered the system it booted without problems. I don't have full documentation for this system (bought it from Newman Computer). Can someone interpret what's going on? I'd like to try to figure out if it's the controller, or the disk, so I can determine what to do next. P.S.: I have P/OS V2.0 and Diagnostics V1.5 ================================================================================ Note 213.6 [PRO300]PRO HARDWARE 6 of 16 EISNER::MAYHEW "Bill Mayhew" 12 lines 12-JAN-1989 23:33 -< Probably flaky/dirty connections >- -------------------------------------------------------------------------------- The most frequent cause of this class of problems in my experience is a controller board, and/or drive cables, that need to be reseated. Take the beast apart, pull the controller, blow all the dust out (esp. the "zero-insertion-force" connector on the controller and the mother board. Similarly blow the dust off the drive cable connectors. Put everything back together. I have sometimes had to go through this charade 2 or 3 times before things become stable. (Fortunately a Pro is easy to use with its cover off!) If this doesn't help, try the cable connections at the drive, but I have most often found the controller connections to be at fault. ================================================================================ Note 213.7 [PRO300]PRO HARDWARE 7 of 16 EISNER::RICE "Gary Rice" 11 lines 13-JAN-1989 13:21 -< Here's another Cable to look at >- -------------------------------------------------------------------------------- > -< Probably flaky/dirty connections >- Definitely a possibility. However, another problem that can cause this error is the power supply to Motherboard (and by extension: bus) cable. The cable can do a "meltdown" like the Micro PDP-11 problem that was described in HARDWARE_HELP. In early stages there are no visible symptoms, but in later stages, the cable begins to darken and will give off an odor. Gary ================================================================================ Note 213.8 [PRO300]PRO HARDWARE 8 of 16 EISNER::LEDERMAN "Bart Z. Lederman" 24 lines 2-JAN-1990 08:02 -< Intermittant Floppy Drive Controller? >- -------------------------------------------------------------------------------- After more than a year without problems, my PRO is complaining again. There appears to be an intermittant problem with the floppy disk controller. I can be using the PRO and everything will be fine for a while. Then the motor will start up on the floppy drive and the system hangs. My guess is the controller has decided on it's own to do I/O on the floppy (there is nothing in the drive) and the system is hung waiting for it to complete. Powering off and on will usually clear the problem. Occasionally, on reboot I get the picture of the system with the second board (the floppy controller) highlighted. Of course, when the system does boot running the diagnostics finds no problem: and when it doesn't boot it's the floppy drive which is bad so I can't run the stand-alone diagnostics. I've already cleaned the contacts and re-seated the board. Any other suggestions? If not, does anyone know a cheap source for replacement boards and/or board repairs? (I can easily run this thing without the floppy controller for a while.) Or should I just put the system as-is into SWAP-MEET and get what I can for it? ================================================================================ Note 213.9 [PRO300]PRO HARDWARE 9 of 16 EISNER::MAYHEW "Bill Mayhew" 13 lines 2-JAN-1990 10:45 -< Try on-line diagnostics >- -------------------------------------------------------------------------------- There's an outfit called "Efficient Field Service" that advertises RX50 _drive_ repairs for $79, in the back of DR and DN. I've heard from a couple of their satisfied customers. Don't know if they can handle the Pro controller or not. The diagnostics can be installed as an application on the hard disk. I don't think a problem with the floppy or controller, per se, should keep you from being able to boot... P/OS should just give you the message that there is a problem, "Press RESUME to continue", and off you go... and then you could run the diagnostics on-line. What are the numbers that accompany the boot-time graphic diagnostic? ================================================================================ Note 213.10 [PRO300]PRO HARDWARE 10 of 16 EISNER::RICE "Gary Rice" 10 lines 3-JAN-1990 10:54 -< Don't Sell your PRO Just Yet >- -------------------------------------------------------------------------------- > Any other suggestions? If not, does anyone know a cheap source > for replacement boards and/or board repairs? I have been having an ongoing conversation with a guy in Las Cruces, NM who says that he knows of a company in Phoenix that will repair PRO boards (any kind - so he/they claim) for $65. As soon as I have their name and address, I will post it here. Gary ================================================================================ Note 213.11 [PRO300]PRO HARDWARE 11 of 16 EISNER::LEDERMAN "Bart Z. Lederman" 25 lines 4-JAN-1990 20:20 -< Bad drive can appear as a bad controller. >- -------------------------------------------------------------------------------- I wouldn't have expected this, but: With some help from Bill Mayhew who looked up some numbers for me, I found that the system was actually complaining about the floppy disk controller, though I did get one 'system' error. I ran the system for a day with the floppy disk controller removed, and got no errors (as I expected). I would probably have left it at that except that there happen to be a couple of defunct Rainbows where I work and the person responsible for them let me borrow an RX50 drive unit. I just ran the system for over 2 hours with the controller back in and the 'new' drive and have had no errors, and I've been exercising the system and the drives all that time. So it looks like a bad drive can cause the system to think the controller is bad. I guess the error logging on the PRO isn't quite as accurate as RSX or VMS systems. To be fair, I've had very little trouble with the system. Now if I can persuade the manager to let me keep the RX50 (and if it didn't make grinding noises when the heads seek...) Thanks to everyone for your help. ================================================================================ Note 213.12 [PRO300]PRO HARDWARE 12 of 16 EISNER::MAYHEW "Bill Mayhew" 5 lines 4-JAN-1990 21:06 -< Indeed! >- -------------------------------------------------------------------------------- My experience with several dozen Pros indicates that the firmware diagnostic can only identify problems to the "subsystem" (e.g. drive+controller) level. I've never seen the drive "lit up" on the graphic display, even when the drive (Winchester or floppy) has been demonstrated to be bad. ================================================================================ Note 213.13 [PRO300]PRO HARDWARE 13 of 16 EISNER::RICE "Gary Rice" 14 lines 5-JAN-1990 10:27 -------------------------------------------------------------------------------- Glad to see that your PRO is "all-better-now". But just in case you need repairs, I have located the info that I promised. This comes to you from a happy customer (Wilber Sitze) of the repair service offered by: SYSTECH 5052 S. 40th St. Phoenix, AZ 85040 (800) 888-8251 Their deal: $60.00/hr labor plus parts. They claim to be able to repair almost ANY board within 1 hour. Wilber bears this out with an LA50 that was debugged and repaired (bad recifier) in 15 minutes. Your mileage may vary. Gary ================================================================================ Note 213.14 [PRO300]PRO HARDWARE 14 of 16 EISNER::LEDERMAN "Bart Z. Lederman" 7 lines 5-JAN-1990 18:38 -< Any RX50 maintenance feasible? >- -------------------------------------------------------------------------------- Thanks for the address: I'm sure someone will need it sooner or later (though I hope not, but I'm a realist). While on the subject; I now have a reasonable RX50, but regarding the noisy one, is it at all reasonable to re-grease the slides in this thing? Is there anything in the drive which can be or is worth servicing? If so, does anyone know how? ================================================================================ Note 213.15 [PRO300]PRO HARDWARE 15 of 16 EISNER::RICE "Gary Rice" 22 lines 6-JAN-1990 09:38 -------------------------------------------------------------------------------- > While on the subject; I now have a reasonable RX50, but regarding > the noisy one, is it at all reasonable to re-grease the slides in > this thing? Is there anything in the drive which can be or is worth > servicing? The only maintenance source that I have is a copy of the Profseeional 300 Series Pocket Service Guide" (PN: EK-PC350-PS-001) I obtained my copy frm a DEC Field Service Person one day while my system was being serviced (Hard Disk ROM Upgrade). It states: "The diskette drive is a single FRU. Do not disassemble the diskette drive or remove any printed circuit boards. All adjustments must be made in a special test configuration." Now, that wouldn't stop ME from opening a dead RX50 "just to see what it looks like inside", but as I said, its all the published info I have. Gary ================================================================================ Note 213.16 [PRO300]PRO HARDWARE 16 of 16 EISNER::MAYHEW "Bill Mayhew" 49 lines 7-JAN-1990 14:26 -< Don't try this at home, esp. with a shag carpet :-) >- -------------------------------------------------------------------------------- I have actually ventured into an RX50. This was about 6 months after I got my Pro, which means it was about 8 months after DEC introduced 'em. My RX50 up and died. Having been used to excellent DEC engineering, I was amazed at what I found :-{ ... There is one motor that drives the head assembly (no surprise, that's why you get two drives for the price(?) of one). The motor shaft has a hard-plastic sleeve over the end. There is a spiral groove cut into this sleeve. For matters of simplicity, think of each head assembly as a popsicle stick with the head at one end. At the other end, there is a spring-mounted "cup". In this cup sits a ball (as in a "ball bearing". The ball rides in the groove in the sleeve. This is hard to communicate in words and I'm not sure a picture is worth more than 10 words in this case, but: _____ ____ <--sleeve at end of motor shaft _____| / / | "/ /" represents spiral groove _____ / / | |_/ /____| ball-> O ----- <--head cup-> U | ----------------------------------------- <--"popsicle stick" The other head assembly is inverted (compared to this one). The spring action of the "cup" is designed to hold the ball in the groove. As the motor turns, the head assembly is pushed back and forth linearly, resulting in a "seek". In my case, a ball fell out. It soon became clear there was no practical way to repair this, so it sat over the weekend until DEC could come and drive-swap. The characteristic grinding noise of early RX50s seems to be largely related to the movement of the ball in the groove (but that's partly conjecture). The groove is not smooth (or wasn't in mine); it seemed to have "detents" which, I imagine, correspond to the track-positions as the head moves across the floppy. Later RX50s are virtually whisper-quiet. I have not disassembled one but I have to think they use a significantly different design to achieve that quiet (and increased reliability!). But Efficient Field Service (see a few notes back) *does* service RX50s and sends you a replacement (I think) for your defective one + $79.  ================================================================================ Note 214.0 [RSX]RSX to VMS 5.0 DECnet problems 12 replies EISNER::SIGMAN "Michael Sigman" 18 lines 30-NOV-1988 18:12 -------------------------------------------------------------------------------- We have a number of PDP's running RSX11M V4.1 Patch C thru E and DECnet V4.0. While testing VMS V5.0 we discovered the DECnet problem (feature), that does not allow connections to RSX nodes that are not running the latest and greatest RSX and DECnet. Some of these system are supplied by OEM's and we really do not want to upgrade them as those good ol' PDP's are doing there job just fine if they would only talk to VMS 5.0 nodes. The person I talked to at DEC phone support indicated that it may be possible to patch NETACP on the RSX nodes to ignore the 'new' field in the connect header that was added in V5.0 (or something like that), but he could not be more specific. Does anyone have any further information ? ================================================================================ Note 214.1 [RSX]RSX to VMS 5.0 DECnet problems 1 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 18 lines 30-NOV-1988 19:21 -< some hope for old D/N RSX >- -------------------------------------------------------------------------------- This is discussed further in DEC_NETWORKING 140.*. But I can add another tidbit. One of the D/N developers took a LOT of flak at Anaheim. Officially, old systems don't get support, but I got the distinct feeling he planned to look at it when he got back. He certainly won't dare show up an another symposium if he does not. We trapped him in the hall for about an hour after a session. He did mumble something about: the call to xxx in zzz needs commenting out, and that should fix it. It sounds as though it will be easy to fix when he gets to it. The 'FIX' will be to the OLD systems, though, NOT the new ones. It is some module in a library, and you will need the pieces to rebuild some D/N task. I suppose there is a chance that it would be ZAPable, but if you have the listings and map, you probably have everything to simply rebuild it. ================================================================================ Note 214.2 [RSX]RSX to VMS 5.0 DECnet problems 2 of 12 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 6 lines 1-DEC-1988 12:59 -< Push Colorado for the patch. It works. >- -------------------------------------------------------------------------------- DEC gave me the patch. I fixed a 4.1 11/34 and it works just fine. Indeed, it was just a matter of nooping a test. I'd put the details here (or, rather, in DEC_NETWORKING), but I'm not at all sure that it's legal. The patch is *totally* unsupported (but I was unsupported already, so what the hey) and patches given over the phone, I think, remain the property of Digital. ================================================================================ Note 214.3 [RSX]RSX to VMS 5.0 DECnet problems 3 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 17 lines 1-DEC-1988 20:15 -< could the patch be spread >- -------------------------------------------------------------------------------- >> DEC gave me the patch. I fixed a 4.1 11/34 and it works just fine. 4.1 M or 4.1 M+? I thought the fix had to be to the older machine, and it is generally the few old machines that are keeping networks of VAXes from migrating to 5.0, so it has to be the old 11 that is fixed in that case. >> I'd put the details here (or, rather, in DEC_NETWORKING), but I'm >> not at all sure that it's legal. The patch is *totally* >> unsupported (but I was unsupported already, so what the hey) and >> patches given over the phone, I think, remain the property of >> Digital. Is there some chance this could be clearly determined, and in this case where there has been so much trouble caused maybe someone in Dec could officially sanction spreading the '*totally* unsupported' patch. ================================================================================ Note 214.4 [RSX]RSX to VMS 5.0 DECnet problems 4 of 12 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 1 line 2-DEC-1988 15:14 -< I'll ask >- -------------------------------------------------------------------------------- I'll check if I can post it. ================================================================================ Note 214.5 [RSX]RSX to VMS 5.0 DECnet problems 5 of 12 EISNER::TILLMAN "Brian Tillman, Smiths Industries." 57 lines 5-DEC-1988 13:19 -< The DECnet-RSX to DECnet-VMS patch revealed! >- -------------------------------------------------------------------------------- Well, here is is, the RSX patch to allow your old RSX-11M (note: NOT M-Plus, although I suspect a similar approach would work there, too) to talk to your VMS V5.0 system. I talked to Colorado and they said, "Well, DECUS will get it sooner or later, anyhow. Sure, you can tell 'em. If they have a service contract, just tell them to call us and we'll be glad to share the patch, but there are probably some who don't have a service contract." Keep in mind that this is a totally unsupported patch. Using it will make your system unsupported as well. This is the method to correct NETACP. First, *make a copy of your current NETACP!* Then make an ASCII dump. You'll need to look for something. > set/uic=[5,54] > pip netacp.org=netacp.tsk > dmp netacp.txt=netacp.tsk Then, use EDT (or whatever) to locate a word containing 032705 followed by a word containing 177774 and followed by a word containing 001xxx (where xxx doesn't really matter. I found mine in block 14, starting at offset 130. This is a test of the proxy flag and we are going to NOP it. Get into ZAP (absolute mode) and let's get rid of the offending test. Note: in the example below, the underscore is what I'm using for ZAP's prompt. I don't know don't know if, in the absolute mode ZAP prompts with "ZAP>" or not. > zap ZAP> netacp.tsk/ab _ 14:130/ ; the system should show you 032705 _ 240 ; NOPs the first word _ ; should show you 177774 _ 240 ; NOPs the second word _ ; should show 001xxx _ 240 ; NOP the last word _ ^Z ; CTRL-Z out. > Now, I have NETACP.TSK VMRed in, so I have to create a new system to find the patched version. > set/uic=[1,54] > pip rsx11m.sys/co/nv/bl:498.=rsx11m.tsk > vmr @sysvmr > set/uic=[5,54] > vmr @netvmr > set/uic=[1,54] > boo rsx11m XDT> g > time hh:mm dd-mmm-yy > time ; to verify the time got set and I'll likely reboot > sav /wb Now I reboot, my STARTUP.CMD runs, which sets my DECnet executor on, and lo and behold, VMS V5.0 can connect to my heart's content! ================================================================================ Note 214.6 [RSX]RSX to VMS 5.0 DECnet problems 6 of 12 EISNER::SIGMAN "Michael Sigman" 72 lines 5-DEC-1988 17:35 -< I got the patch. >- -------------------------------------------------------------------------------- < Note 100.5 by EISNER::TILLMAN "Brian Tillman, Smiths Industries." > -< The DECnet-RSX to DECnet-VMS patch revealed! >- Well, here is is, the RSX patch to allow your old RSX-11M (note: NOT M-Plus, although I suspect a similar approach would work there, too) to talk to your VMS V5.0 system. I talked to Colorado and they said, "Well, DECUS will get it sooner or later, anyhow. Sure, you can tell 'em. If they have a service contract, just tell them to call us and we'll be glad to share the patch, but there are probably some who don't have a service contract." Keep in mind that this is a totally unsupported patch. Using it will make your system unsupported as well. This is the method to correct NETACP. First, *make a copy of your current NETACP!* Then make an ASCII dump. You'll need to look for something. > set/uic=[5,54] > pip netacp.org=netacp.tsk > dmp netacp.txt=netacp.tsk Then, use EDT (or whatever) to locate a word containing 032705 followed by a word containing 177774 and followed by a word containing 001xxx (where xxx doesn't really matter. I found mine in block 14, starting at offset 130. This is a test of the proxy flag and we are going to NOP it. Get into ZAP (absolute mode) and let's get rid of the offending test. Note: in the example below, the underscore is what I'm using for ZAP's prompt. I don't know don't know if, in the absolute mode ZAP prompts with "ZAP>" or not. > zap ZAP> netacp.tsk/ab _ 14:130/ ; the system should show you 032705 _ 240 ; NOPs the first word _ ; should show you 177774 _ 240 ; NOPs the second word _ ; should show 001xxx _ 240 ; NOP the last word _ ^Z ; CTRL-Z out. > Now, I have NETACP.TSK VMRed in, so I have to create a new system to find the patched version. > set/uic=[1,54] > pip rsx11m.sys/co/nv/bl:498.=rsx11m.tsk > vmr @sysvmr > set/uic=[5,54] > vmr @netvmr > set/uic=[1,54] > boo rsx11m XDT> g > time hh:mm dd-mmm-yy > time ; to verify the time got set and I'll likely reboot > sav /wb Now I reboot, my STARTUP.CMD runs, which sets my DECnet executor on, and lo and behold, VMS V5.0 can connect to my heart's content! Well, looks like I'm a little late. I'm glad DEC agreed to let you post the patch. I had to get my local office to call Colorado and request the patch for me, before they would give it out. I agree with the above except that I also have NETACP VMR'ed in. But, since you are ZAPing the disk image without changing it's location, you don't have to make a new system image, just take the network down and back up to read the ZAP'ed image into memory. Looks like I'm out of excuses, VMS V5 here I come. ================================================================================ Note 214.7 [RSX]RSX to VMS 5.0 DECnet problems 7 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 8 lines 5-DEC-1988 18:19 -< M+ NETACP has same words 4 bytes later >- -------------------------------------------------------------------------------- >> (note: NOT M-Plus, although I suspect a similar approach would work there, >> too) THANKS! On an M+ 2.1 system it turned out to be 2 words later @ 14:34. And when it gets rebooted one of these days, we will see if it works... ================================================================================ Note 214.8 [RSX]RSX to VMS 5.0 DECnet problems 8 of 12 EISNER::WYANT "Tom Wyant" 31 lines 7-DEC-1988 09:15 -< It ain't necessarily so (what you read in the Bible) >- -------------------------------------------------------------------------------- >>> Now, I have NETACP.TSK VMRed in, so I have to create a new system >>> to find the patched version. Not to put myself ahead of TSC, but I see no need to go to this length. I should think a simple reinstallation of NETACP would be sufficient: >SET /UIC=[1,54] >VMR Enter filename: RSX11M VMR>REM NETACP VMR>INS [5,54]NETACP VMR>^Z Before doing this, It's probably smart to re-install NETACP in the running system, just to try it out: >NCP SET EXECUTOR STATE OFF >NCP CLEAR SYSTEM >REM NETACP >INS LB:[5,54]NETACP >NCP SET SYSTEM >NCP SET EXECUTOR STATE ON This way, if you fouled up somehow and NETACP crashes your system, you come up clean. After you've watched it run for a while, you can VMR it. I prefer STATE OFF for the first NCP command, as STATE SHUT is sometimes so graceful you can't get the system down at all. Even so, the DECmail queue server has to be aborted to get DECnet to go away (MAILQ, or some such task name). ================================================================================ Note 214.9 [RSX]RSX to VMS 5.0 DECnet problems 9 of 12 EISNER::WYANT "Tom Wyant" 4 lines 7-DEC-1988 09:19 -< But if you've SAVed with the net up ... >- -------------------------------------------------------------------------------- PS - Those who have SAVed their system with DECnet running will have to do a complete re-VMR after all. But the second half of 100.8 (=.-1) still applies - you can get the patched NETACP without having to reboot. ================================================================================ Note 214.10 [RSX]RSX to VMS 5.0 DECnet problems 10 of 12 EISNER::NORTON "Bill Norton" 2 lines 31-MAY-1989 09:30 -< M+V3.0B addresses >- -------------------------------------------------------------------------------- An M+ V3.0B system had the test in block 16, offset 540. Patch worked fine. ================================================================================ Note 214.11 [RSX]RSX to VMS 5.0 DECnet problems 11 of 12 EISNER::WYANT "SOME call me ..... TOM" 10 lines 31-MAY-1989 15:37 -< Caveat User >- -------------------------------------------------------------------------------- >>> An M+ V3.0B system had the test in block 16, offset 540. >>> Patch worked fine. I found it about block 50. A word to the wise: look for yourself. Also, the problem only manifests itself in one direction. It seems M V4.1 will connect to VMS V5.0 just fine. It's when VMS tries to connect to RSX (or new RSX to old RSX) that the problem arises. ================================================================================ Note 214.12 [RSX]RSX to VMS 5.0 DECnet problems 12 of 12 EISNER::BRYANT "Geoff Bryant" 1 line 14-JUN-1989 13:52 -< How 'bout for REALLY old RSX? >- -------------------------------------------------------------------------------- Anyone know the magic patch for REAL OLD RSX - 11M V3.2?  ================================================================================ Note 215.0 [RT11]Incremental Backup Ideas 1 reply EISNER::KOZAM 35 lines 4-DEC-1988 15:36 -------------------------------------------------------------------------------- Backing up RT/TSX systems is a real pain, especially if you've got a combo such as RD53/RX50. Unfortunately, BUP is only useful for physical device backups. Since the volume of new data on a daily basis is small, what I need is a method of incremental backup. Several problems are involved: 1. RT-11 doesn't support file modification dates, so it's hard to tell if a file needs to be backed up. 2. Logical disks provide a sort of hierarchical file system, but unless a logical disk is mounted, it's just a file. I don't know of any way to mount a disk from within a program using RT-11 (TSX+ has special EMTs to allow you to do this). Problem 1 can be overcome by calculating checksums for each file and storing them somewhere. When running backup, if the newly calculated checksum is different from the stored one, then it's time to back up the file (and replace the old checksum with the new one). Problem 2 can be handled by having code within an application that can directly interpret RT-11 directories. I've written some code that works its way through RT-11 directories and logical disks (up to 8 levels deep), while calculating checksums and writing them to a log file as it goes. By doing a DIFF on two logs files, I can tell if any files have been added/deleted/ modified, but that's as far as I've gotten. Clearly there much more to do. In particular, how to handle multi-volume backup sets and how to use them to reconstruct the system following a mishap. Has anyone else pondered these issues? Is there something obvious (other than buy a TK50) that I'm missing? Are there any dead ends I'm going to run into? ================================================================================ Note 215.1 [RT11]Incremental Backup Ideas 1 of 1 EISNER::CROWELL "Shefth of the Fourth Order" 6 lines 5-DEC-1988 10:20 -< BUP (BACKUP) Alternative >- -------------------------------------------------------------------------------- Horizon Data Systems has a backup/restore program I use for incremental backups (and device backups for that matter). I much prefer it to BUP. It'll backup files to other disks, (multiple) floppies, magtape and TK50. Files may be included or excluded by before/after dates. Talk to Jack Peterson (804) 740-9244.  ================================================================================ Note 216.0 [PRO300]Task Segment Fault Aborts 2 replies EISNER::COOPER 11 lines 5-DEC-1988 20:15 -------------------------------------------------------------------------------- We are having a problem with tasks aborting with a TKTN abort code of 2 (segment fault). The tasks that are aborting are doing alot of RMS file opens and closes. They work for awhile before aborting. The tasks are written in PRO/PASCAL (using the VMS Host toolkit). We are running P/OS V2.0a. Has anyone come across this and, if so, did you find a solution? Thanks, Steve ================================================================================ Note 216.1 [PRO300]Task Segment Fault Aborts 1 of 2 EISNER::RICE "Gary Rice" 15 lines 5-DEC-1988 21:34 -< Could be RMS >- -------------------------------------------------------------------------------- > We are having a problem with tasks aborting with a TKTN abort code of 2 > (segment fault). The tasks that are aborting are doing alot of RMS > file opens and closes. They work for awhile before aborting. I have seen what may be a related problem using PRO/FORTRAN. In a heavily overlaid task that opens and closes Indexed Sequential files with buffer sizes above 512 bytes, FORTRAN will return "No Buffer Room" after awhile. The only "fix" that the P/OS developers came up with was: "Increase the 'ACTFIL=nnn' value in the Taskbuild file" and/or "Increase the 'MAXBUF=nnn' value as well". This is tough in an overlaid program, as I'm sure you are aware. Gary ================================================================================ Note 216.2 [PRO300]Task Segment Fault Aborts 2 of 2 EISNER::COOPER "Steve Cooper" 12 lines 25-JAN-1989 19:20 -< Problem Solved >- -------------------------------------------------------------------------------- I found the problem. Looking through the sources, I came across an old (1984) user action routine to clean up XABs after closing indexed, keyed files. Apparently, the P/OS close neglected to remove the XABs from the program's dynamic storage (the heap). There is one XAB allocated for each key. The UAR had some bugs that I fixed, but the heap was still getting used up. It turned out that P/OS was allocating 104(8) bytes for the XABs even though they are only 70(8) bytes long. I redefined the XAB for disposal and now everything works just fine. - Steve  ================================================================================ Note 217.0 [RSX]Help! My tape's too big! 3 replies EISNER::WYANT "Tom Wyant" 25 lines 13-DEC-1988 10:57 -------------------------------------------------------------------------------- Has anyone ever encountered the I/O error IE.BLK (logical block number too large) on a tape drive? We are attempting to write some data to an Exabyte 8mm tape drive on a Contemporary Cybernetics controller (the Hitchhiker's Guide defines the Marketing Division of Contemporary Cybernetics as ...), all masquerading as a TK50. The writing is done by some user-written software that does logical block I/O to the tape. The tape is mounted foreign. We get about a quarter of the way into the cartridge, and then the QIO craps out with the above error code. We have checked the user-written code once to be sure of the error code, and are plowing through MUDRV.MAC and PUCOM.MAC now, so far without luck (you would think that as devices become more sophisticated the drivers would become simpler!). We found the LBN check code in the XXDRV code, but it wasn't assembled for the tape, and it would either fail immediately if it WAS assembled, (because U.CW2 and U.CW3 are zero) or work all the time (because P4 and P5 in the QIO are defaulted). I suppose we COULD be clobbering our own code, but we didn't look forward to investigating that possibility, and wanted to wait until some of the other options were exhausted. The Exabyte cartridge IS too large relative to a TK50, but I would expect that to manifest itself by something like a device timeout on rewind or file search. ================================================================================ Note 217.1 [RSX]Help! My tape's too big! 1 of 3 EISNER::DOHERTY "Bob Doherty" 13 lines 13-DEC-1988 18:57 -< We don't see it... >- -------------------------------------------------------------------------------- We have been using that combination with backup for about two months and haven't noticed anything like that. We have put up to ca. 1.8 GB on a tape(32k blocks) and have not gotten IE.BLK. We have also copied backup save sets from an ANSI mounted ts11 to an ANSI mounted Exabyte tape, and have had not problem(ca 3/4 of the tape filled). The only idiosyncrasy we have run into occurs when we try to truncate the tape by writing tape marks with QIO's. We get a tape position lost error and the controller gets wedged(show dev says host not available). The only recourse that we've found is to cycle the power on the unibus(bus inits DON'T do it). Hope this helps. ================================================================================ Note 217.2 [RSX]Help! My tape's too big! 2 of 3 EISNER::KENNEDY "Terry Kennedy" 7 lines 13-DEC-1988 22:26 -< Weak suggestion >- -------------------------------------------------------------------------------- Warning: The Surgeon General has determined that the author of this reply does *not* speak RSX and may be all wet on this one... Is your write failing on a block number that is some multiple of 2^n bits long? It may be possible that the system cannot directly address that many blocks. Is there a distinction between 'write block N' and 'write the next block after the current one'? ================================================================================ Note 217.3 [RSX]Help! My tape's too big! 3 of 3 EISNER::WYANT "Tom Wyant" 21 lines 14-DEC-1988 14:29 -< We'll take what we can get. >- -------------------------------------------------------------------------------- >>> Warning: The Surgeon General has determined that the author of >>> this reply does *not* speak RSX and may be all wet on this >>> one... No problem. We're not proud. >>> Is your write failing on a block number that is some multiple of >>> 2^n bits long? I confess my first thought was you were all wet. My second thought was that if I'm so smart, why haven't I got the answer? The QIO does not specify an LBN, and according to the manual (he said naively) logical block number is not specified on an IO.WLB to a tape. In the back of the I/O operations guide, the appendix on ACP QIOs (have you noticed that all the good stuff is in the appendices?) says the IO.WVB QIO requires either an unspecified LBN, or an LBN equal to the last one, plus one. We don't believe MTAACP is involved since the tape is mounted FOREIGN, but we appreciate the thought, and need all the brainwaves we can get.  ================================================================================ Note 218.0 [RSX]PDP 11/70-84, IAS, AMHS 4 replies EISNER::LAMBERT_M "Mike Lambert" 4 lines 14-DEC-1988 17:27 -------------------------------------------------------------------------------- I'm running IAS 3.2 on 4 PDP 11/84s (moved from 11/70s) for one of DOD's Automated Message Handling Systems (AMHS). Anyone else out there in the same boat? Mike ================================================================================ Note 218.1 [RSX]PDP 11/70-84, IAS, AMHS 1 of 4 EISNER::GLEASON "CyberPunk" 16 lines 15-DEC-1988 01:33 -< ;-) >- -------------------------------------------------------------------------------- > I'm running IAS 3.2 on 4 PDP 11/84s (moved from 11/70s) for one > of DOD's Automated Message Handling Systems (AMHS). Anyone else > out there in the same boat? Mike Ahh...IAS, now, there was an operating system. Years after DEC decided to "kill" it, VMS and RSX have almost caught up to it in terms of functionality and ease of use. I think you'll find that most currently active IAS sites (with a few notable exceptions) are government installations - and they don't have much to say in the DECUS world. Just remember, when you do your resume, to call your IAS experience "RSX family" - you'll save yourself a lot of explanation during interviews... ================================================================================ Note 218.2 [RSX]PDP 11/70-84, IAS, AMHS 2 of 4 EISNER::ROBITAILLE "Mike Robitaille" 9 lines 15-DEC-1988 10:26 -< A blast from the past... >- -------------------------------------------------------------------------------- I spent five years on a Navy system which used IAS. In fact, that's my ONLY qualification for moderating this here conference! (I bet you've been wondering why I've been so doggone quiet). Did quite a bit of FORTRAN and MACRO development on it, and still remember quite a bit (albeit 1 year old). Great system, but horribly ignored by DEC. You can't get a decent DECNET that will talk to anything other than other IAS machines - they couldn't even get it up to Phase IV. ================================================================================ Note 218.3 [RSX]PDP 11/70-84, IAS, AMHS 3 of 4 EISNER::LAMBERT_M "Mike Lambert" 2 lines 15-DEC-1988 10:50 -------------------------------------------------------------------------------- Mike, your name is familiar. I believe I've talked with you about some LUG info or whatever. I'm in Tyson's Corner, Va. Ring a bell? ================================================================================ Note 218.4 [RSX]PDP 11/70-84, IAS, AMHS 4 of 4 EISNER::LAMBERT_M "Mike Lambert" 2 lines 15-DEC-1988 10:56 -------------------------------------------------------------------------------- Thank you the resume hint :-). As a matter of fact, I'm currently working on one. Next job will be System Manager.  ================================================================================ Note 219.0 [RSTS]SYSTEM MANAGEMENT - WISH LIST 1 reply EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:32 -------------------------------------------------------------------------------- Note 36.0 SYSTEM MANAGEMENT - WISH LIST 1 reply EISNER::HORN "Larry Horn" 4 lines 14-JUL-1987 04:13 -------------------------------------------------------------------------------- This topic is for the discussion of global features you'd like to see that impact system management. If the feature is specific to a particular program, please discuss it in the appropriate topic already provided (features in INIT.SYS, for example). ================================================================================ Note 219.1 [RSTS]SYSTEM MANAGEMENT - WISH LIST 1 of 1 EISNER::KENNEDY "Terry Kennedy" 8 lines 17-DEC-1988 22:32 -< Performance monitoring? >- -------------------------------------------------------------------------------- Note 36.1 SYSTEM MANAGEMENT - WISH LIST 1 of 1 EISNER::DEVELOPMENT "Brian McAllister" 3 lines 15-JAN-1988 15:06 -< Performance monitoring? >- -------------------------------------------------------------------------------- Wouldn't it be nice if DEC did something real in the area of performance monitoring? At the least, a statistics package that is supported (and even documented properly).  ================================================================================ Note 220.0 [RSX]Primary pool depleting. Help! 6 replies EISNER::KESTERSON 34 lines 20-DEC-1988 15:33 -------------------------------------------------------------------------------- [ Problem with primary pool depleting ] I have a problem with a mciro/rsx v3.1 system where we are loosing primary pool and crashing the system. The problem doesnt happen all the time, but only occasionally. Therefore it's hard to find the bug. If it is one. We have a real time application where we "poll" remote devices every minute with with a set of 7 polling tasks. These tasks come in and out of memory (2mb) every minute opening and closing 3-4 files a piece. There are also 5 data handling task on the system which start running during a reboot and are constantly in memory awaiting for data packets from these polling task. Secondary pool is not depleting, but primary pool. The handlers open 5-6 files a piece and keep them open (shared) at all times also (to speed file access). Primary pool seems to be going away when out of no where, a task (polling usually) will have trouble opening or closing a file, which puts it into our error checking routine which sees a fortran 30 or 28 error, waits for a significant event to occur (primary poll deallocation hopefully), waits another 20 milliseconds, and then then tries the open or close again. The retry evidently never works and instead of exiting the loop we are in now, we retry constantly because we have to have that file opened or closed. When this loop gets hung is when we start to see primary pool start to go away a little at a time, but it is depleting constantly. After awhile then primary pool will get critically low and all task trying to open or close files will start to error out and the system will either bomb those task or come to a screaching halt. I know it needs this primary pool to survive, what i dont know is how the system uses primary pool in this case and what is happening to it. Please help. Thanx Greg K. (ESC) ================================================================================ Note 220.1 [RSX]Primary pool depleting. Help! 1 of 6 EISNER::MAYHEW "Bill Mayhew" 16 lines 20-DEC-1988 18:35 -< Retries shooting themselves in the foot? >- -------------------------------------------------------------------------------- This is something of a shot in the dark, but I would suspect your error-handling routine itself... the part of it that retries opening and/or closing the file after a significant event occurs. I don't do FORTRAN, so am not familiar with the error codes you cited, but I suspect that (assuming for the moment an OPEN fails) the failed OPEN is not releasing pool the way you want it to... and every time you retry it, you compound the problem. I'd do something like comment-out the OPEN/CLOSE retries as an experiment, then see what that does. If pool depletes much more slowly (or not at all), then you are looking in the right direction. But as I said, this is something of a shot in the dark. Are you running on an 11/23 or a 53/73/83, btw? (the latter allow more primary pool to start with, I believe) It might also be worth noting, though certainly not for my benefit {grin}, what version of FORTRAN you are using. ================================================================================ Note 220.2 [RSX]Primary pool depleting. Help! 2 of 6 EISNER::KESTERSON 12 lines 21-DEC-1988 10:12 -< More info about problem... >- -------------------------------------------------------------------------------- [ Problem with primary pool depleting ] continued... Greg again,... The system is running on a 11/73 and we are using FORTRAN version 5.?????...... I believe 5.1. Version 5.0 or better. As for leaving out the error routine, we can't do that because for the programs crash when they get the open errors cause they have a primary pool allocation error, and for another; we have to get and store that data every minute for critical data handling and reporting so we must try again. Thanx, Greg K. (ESC) ================================================================================ Note 220.3 [RSX]Primary pool depleting. Help! 3 of 6 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 30 lines 21-DEC-1988 14:21 -< The brute force approach to pool analysis >- -------------------------------------------------------------------------------- >> Problem with primary pool depleting My "standard" approach to this problem is to take a crash dump. Then lock yourself in a room with a large table and a supply of colored pens. Go through the formatted part of the dump and find the pool address of each structure. Use a unique color to mark it in both the formatted and pool-dump listings. Alongside the pool dump, note the name of the structure ("UCB for TT12:") and the page number from the formatted dump. When you are finished, you may find some areas that are not identified. This can be caused by privileged tasks or drivers allocating pool for their own purpose (perfectly legal). A little detective work with the Octal/RAD50/ASCII dump should help you locate the owner of these areas. Aside from finding out who has eaten up most of your pool, you will also learn a LOT about RSX data structures. Not to mention the fact that it will keep you off the streets and out of trouble for a while. :-) Hint: Take an early look at MCR command line buffers. A terminal line that connects to another system (or a verbose modem) can get into a rapid-fire dialog with MCR with each system thinking that the other is trying to log in. This is known as a "huh/what" loop. Alan Frisbie ================================================================================ Note 220.4 [RSX]Primary pool depleting. Help! 4 of 6 EISNER::WYANT "Tom Wyant" 76 lines 21-DEC-1988 18:45 -< Another country heard from ... >- -------------------------------------------------------------------------------- There is a general algorithm for solving this kind of problem: if you want to know where pool has gone, look in pool and see what it's being used for. Alan's recommendation is the only sure-fire way to know what's in pool. Reading crash dumps is like going to the dentist: doing it is frequently not as bad as looking forward to doing it. When you know what's in pool, then you have a good lead as to WHY it's there. Assuming you are reluctant to bite the bullet, there is the brainstorming approach - which MAY be easier, but is NOT guaranteed to work at all. I suppose what we can contribute to that is thoughts on what dynamic structures go in primary pool, and what might cause these structures to increase ad nauseum. First: I don't buy the "FORTRAN bug" hypothesis (though I would not dismiss it outright, I would just put it on the back burner for when all else fails). No matter WHO opens a file, the open works down to an ACP QIO (see the relevant appendix to I/O Drivers (or I/O operations, I forget which)), which is fielded by F11ACP (unless you've written your own). The ACP looks up the file and allocates an FCB (for the first opener) and a window block (one per opener) out of its own address space (first choice) or primary pool (second choice). I could be hazy on the specifics; the point is that I would think the QIO interface should isolate things pretty will from the specific implementation language and its associated bugs. Working hypothesis: pool depletion is caused by the failure of the data logger task to dequeue packets. For this to happen, SOME primary pool resource must be required to queue the packet in the first place. You haven't described the exact nature of the interface; this would be helpful. In the absence of this data, some guesses are: * Send/request - Primary pool required for server task TCB, PCB, and possibly header. Assuming the number of servers is limited, this shouldn't cause continuous depletion. * Send/request/connect - In addition to the above, this needs an OCB for each call to send/request/connect. I say again: EVERY TIME the data polling task calls SDRC, an OCB gets allocated; if it sends 1000 packets, you have 1000 OCBs in primary pool. Moreover, these OCBs do NOT go away until the logging task exits or emits status. Specifically, they DON'T go away when the parent task exits (voice of experience). These considerations apply for ANY interface that involves the parent/offspring directives. * Send-by-reference - a PCB goes in primary pool for each message. * Some message driver or other - an I/O packet in primary pool for each message. * DECnet - POOL.. overflows to primary pool. Re the recommendation on retrying errors: you need to isolate this problem, too. There are many file open errors that retrying until you're blue in the face won't solve. I suspect FORTRAN error 29 is one of these (it is frequently trying to tell you that you have an incorrect logical, or your task has the wrong default device or directory). FORTRAN error 30 means nothing by itself - you need the detailed FCS or RMS error code returned in the error message or by ERRSNS to make the determination and fix the problem. If it IS one of those errors that retries won't help, then punt the retry: the argument that you have to retry because you need the data becomes invalid. Smart move: do some error analysis in that error routine, and only retry if retry will help. Don't beat your machine to death retrying a privilege violation, for example; instead, get your task running under the correct UIC. Are yor really getting CLOSE errors? These generally mean something serious; generally this only happens when you can't flush the last buffer on a close (disk full, write-protected, ...). ================================================================================ Note 220.5 [RSX]Primary pool depleting. Help! 5 of 6 EISNER::LEDERMAN "Bart Z. Lederman" 15 lines 21-DEC-1988 20:22 -< Look for OPA on the SIG and Library tapes >- -------------------------------------------------------------------------------- It's not often that I would dare disagree with Alan about how to look at something on RSX, but there is a better way to look at pool. Check the older RSX SIG tapes from around 1983 to 1985 in UICs [350,50] through [350,55] for OPA, the Online Pool Analyzer as modified by Kitty Bethe and submitted from Bankers Trust (by me). This is a program you can run which will give you an analysis of what's in pool, identifying as many types of packets as possible. I don't know if it's been updated since then, but it was fairly complete when we put it on. You can run it on a periodic basis on your system and get a "moving picture" of what is happening to your pool. A caveat: since it does mess with executive structures, it has to be build on the actual system it will run on, and there is always a small chance it will crash the system (though it never did it to me). ================================================================================ Note 220.6 [RSX]Primary pool depleting. Help! 6 of 6 EISNER::NORTON "Bill Norton" 4 lines 19-SEP-1989 17:22 -------------------------------------------------------------------------------- How about an updated version of CPA, the *Crashed* Pool Analyzer? I have a dump showing 500 words of free pool and I'd like to avoid the brute-force analysis.  ================================================================================ Note 221.0 [RSX]RSX11S Problem with Ethernet 2 replies EISNER::MERUSI 10 lines 5-JAN-1989 15:38 -------------------------------------------------------------------------------- I am currently having a problem with an RSX11S system. I can download it over Ethernet from a VAX 8700 to a PDP-11/24. The 11S system comes up and displays its banner. Then, the DECnet executor state changes from off to on. The system is apparently stable at this point. However, once I turn the Ethernet circuit on (it is a DELUA in the 11/24) the 11S crashes to location 140002(8) which happens to be right in the middle of the terminal driver. Has anyone else had a similar experience or offer any advice as to what's happening here? Thanx. ================================================================================ Note 221.1 [RSX]RSX11S Problem with Ethernet 1 of 2 EISNER::KENNEDY "Terry Kennedy" 8 lines 5-JAN-1989 22:54 -< Nebulous suggestion >- -------------------------------------------------------------------------------- There are 3 possibilities: 1) Bus error 2) A 'real' HALT or similar opcode there 3) Code corruption Is the code near the halt location what you exepct to be there (compare with a known good system?) ================================================================================ Note 221.2 [RSX]RSX11S Problem with Ethernet 2 of 2 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 24 lines 6-JAN-1989 16:08 -< Crash VIRTUAL address vs PHYSICAL address >- -------------------------------------------------------------------------------- >> The system is apparently stable at this point. However, once >> I turn the Ethernet circuit on (it is a DELUA in the 11/24) the 11S >> crashes to location 140002(8) which happens to be right in the middle of >> the terminal driver. First of all, a crash at 140002(8) does NOT mean that it crashed at PHYSICAL location 140002, but at VIRTUAL location 140002. Since drivers, etc. are mapped to start at virtual address 140000, your crash is at the entry point of SOME driver (or other privileged code). To find out WHICH code was mapped at the time of the crash, look at the first page of the crash dump. Look at the sixth line of the KERNEL I-SPACE PAR listing. This is the start of the code mapped by APR 5 (140000). Append two zeros to this value to get the PHYSICAL memory address of the crash. Now use the CDA /PAR switch to find out what partition (program, driver, etc.) occupies that location. I have a wild, off-the-wall theory. I'll bet you an ice cream cone that the physical crash address is up near the top of memory. Alan  ================================================================================ Note 222.0 [RSX]Disk Cacheing Parameters, Etc. 6 replies EISNER::STEFFEN 5 lines 5-JAN-1989 16:22 -------------------------------------------------------------------------------- I have used disk cacheing before with RC25 and it appeared to give better i/o performance. Now I'm at a site with RA60s and disk cacheing ruins i/o performance. I/Os per second (RMD I page) go from 25-30 without cacheing to 10-13 with cache. I really haven't seen any thorough examination of cacheing, such as when does hurt to do it and how to improve it. ================================================================================ Note 222.1 [RSX]Disk Cacheing Parameters, Etc. 1 of 6 EISNER::MAYHEW "Bill Mayhew" 12 lines 5-JAN-1989 20:52 -< One of us misunderstands the cache<->IOs/sec relationship >- -------------------------------------------------------------------------------- But wait...?? I would think that a reduction in I/Os per second as seen on the RMD I screen is exactly what you'd want to see -- fewer references to the disk, since more stuff is available (in the cache) without having to go to the disk. If I'm wrong, please tell me. I have never gotten brave enough to turn on caching because I'm a bit worried about what it would do to my (extremely custom) DBMS... (and most of my systems need the memory for other things, anyway) ================================================================================ Note 222.2 [RSX]Disk Cacheing Parameters, Etc. 2 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 21 lines 6-JAN-1989 00:03 -< check RMD C,D, and S >- -------------------------------------------------------------------------------- > I would think that a reduction in I/Os per second as seen on the > RMD I screen is exactly what you'd want to see -- fewer references > to the disk, since more stuff is available (in the cache) without > having to go to the disk. Exactly so. The I screen is for actual hardware I/O. The C and D screens will give you the caching stats where you can see what was intercepted, and the S screen will show you the actual total system QIOs all types. Depending on your application, you should tune your caching parameters. The defaults can always be improved on it seems. Other disk related tuning is also wise, but it all depends on what you are doing, etc. The disk's defaults for such things as WIN, LRU, and default EXTENDSIZE bear scrutiny. Directories destined to be large should be made with: UFD ... /ALLOC=x where x is a tad bigger than the max files you expect in it. (That reminds me: by now everyone should know that UFD .../DE deletes empty directories). And every disk worth its salt gets mounted with /ACP=UNIQUE. ================================================================================ Note 222.3 [RSX]Disk Cacheing Parameters, Etc. 3 of 6 EISNER::MAYHEW "Bill Mayhew" 13 lines 6-JAN-1989 11:17 -< /ACP=UNIQUE rule of thumb >- -------------------------------------------------------------------------------- > ... every disk worth its salt gets mounted with /ACP=UNIQUE. I wondered about this... This means you have separate ACPs and separate in-memory queues. How does this interact with the situation where the additional disk is on a shared controller, and the controller is MSCP (which has on-controller queues)? (By "shared controller" I mean that there are 2 (or more) drives on one controller.) I haven't thought this through but am curious as to whether /ACP=UNIQUE is a good or a bad idea in such a situation, and why. ================================================================================ Note 222.4 [RSX]Disk Cacheing Parameters, Etc. 4 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 11 lines 6-JAN-1989 21:46 -< Use UNIQUE ACPs >- -------------------------------------------------------------------------------- >> I haven't thought this through but am curious as to whether /ACP=UNIQUE >> is a good or a bad idea in such a situation, and why. It doesn't hurt you in that situation, assuming you do have spare memory. The 2 reasons I always do it are 1) so a slower device (try a tu58...) won't bottle-neck access to a fast one. and, more commonly 2) so all the window and directory etc. stuff an ACP caches to speed operations used to be bounded by just its task space, so the more ACPs the better. Now that an ACP can use secondary pool, and there is a seperate CACHE subsystem than can do DIRs, seperate ACPs may not help as much, but if you have space for them I would use them. ================================================================================ Note 222.5 [RSX]Disk Cacheing Parameters, Etc. 5 of 6 EISNER::STEFFEN 15 lines 9-JAN-1989 09:24 -< Whoops, more inportantly... >- -------------------------------------------------------------------------------- >>-< Disk Cacheing Parameters, Etc. >- I forgot to mention the most important symptom, the response time with cacheing enabled is terrible. I enable cache and the users start aborting the application because they think something's hung. I should have thought about the physical I/O count, that's sounds about right that there should less physical I/Os. Something that I would like to know is, if I create a very BIG cache region, could it possibly take longer to determine if something is in cache than to actually read it in from disk? I believe in separate ACPs, but in this case there is only the one disk. ================================================================================ Note 222.6 [RSX]Disk Cacheing Parameters, Etc. 6 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 74 lines 9-JAN-1989 18:49 -< What and When to Cache >- -------------------------------------------------------------------------------- >> I forgot to mention the most important symptom, the response time >> with cacheing enabled is terrible. I enable cache and the users >> start aborting the application because they think something's hung. What is your application? How big are the reads, what % of the time is the data being written, are there MANY files in MANY dirs, or is there just one monster file. What %s are currently shown on the RMD C and D screens? Some applications simply are no good for cache. If there is little chance of the same part of the disk being frequently accessed, and you have a hugh amount of stuff on disk, the cache code is busy wasting more CPU time shoving stuff into cache than it is saving. You sometimes only need certain files cached, and MUST not cache others to get significant performance increase. You have one disk, so are a bit stuck, but several tricks still are possible. If the application can take advantage of reading several sectors at once on the file that MUST not be cached, set the transfer size limit to not cache these, and then use big-buffering to EXCLUDE that file! (As an aside comment, I normally like to big and double buffer, but there is some evidence that RSX still has bugs in this area when I/Os complete in some order other than what they were issued in, and the RA drives seem to cause these bugs to surface. Brian M. said something like: "I think Tim was last looking at this, and if you really need it I can find out what he found, but it is not apt to be fixed...". Big buffering alone is OK.) Another trick to limit which files get cached is to use the VF: driver. VD: does not, and VE: I think does not, but VF: does support caching, and sticking files needing it on a VF: disk on your real disk might give you the control you need. Again, not knowing what you are doing, I can only guess, but sometimes simply using the FX: ram disk for some key file, or using virtual arrays (from F77) now that they are FAST-MAPPED may be a more productive way to use spare memory. If you are on an 84 with 4 megs, but aren't on the latest M+, you may only have 1920kw available, but should have 2044kw. That is the size of a full 11/34 they were simply wasting because the hadn't fixed SAVSIZ properly. If this fits your case, and you need the space and can't get to a newer M+, I can tell you how to get the rest. >> Something that I would like to know is, if I create a very BIG cache >> region, could it possibly take longer to determine if something is in >> cache than to actually read it in from disk? This is sort of true, but it is really the Hording stuff that won't be needed and search and never found waste, and, if you are flat out of CPU cycles, wasting CPU cycles moving stuff found in cache when disk DMA input simply grabs some bus bandwidth, but saves CPU cycles for others. I suspect you could always determine IF you had it faster than READING it, but a low hit rate on an already flat out CPU, and you lose. CPU based caching is best when the CPU has spare cycles, and you are simply idle waiting for a block to be read again that was recently read. Also, my experience has been that when one is winning well with cache, say maybe 85% hits, doubling cache space available MAY not help the %hit rate, or even if it does slightly, might slightly hurt total throughput. It may well be worth trying cutting cache some to find an optimum size. If the application presents a steady load, find some metric to measure through put. It may be as simple as total QIOs (RMS S screen) or the rate some output file grows (shame for not doing huge preallocations) or seconds between "another 10,000 widgits yuked" messages. Then tune cache to maximize it.  ================================================================================ Note 223.0 [RT11]Non RT user faces RT - help! 7 replies EISNER::BRUCE "Barton F. Bruce - CCA/MA" 50 lines 9-JAN-1989 01:36 -------------------------------------------------------------------------------- Not having used RT for MANY MANY years, and not having any recent RT manuals may make this question rather dumb, but here goes. A prospective client is having a problem with his RT system running some modified MCBA S/W. The former programmer who did most of the work has married this guy's ex, and so this is NOT a viable route for any info/help. We wanted to copy a lot of files to tape, and assumed we would have to /ze the tape first, and then worry about the pesky file-type switches. We only had a short time that day before they closed, so we could not experiment much or get many files. They had a much newer RT system that any I had ever seen. We discovered we could INIT the tape, and then pip'd using /x/m:1, but the damned tape kept rewinding for each file. When we got home (to RSX land) we thought we would have to trot out FLX, but it was a weird (labels 512 bytes long) but readable ANSII tape! We are simply exploring as yet, and need to look at all of his files back here before we decide whether we even want to get involved. Could we have written ANY file type safely with a *.* spec? and how do we stop the rewind between each file. Is there some better utility to get everything to a tape that will be readable under RSX or VMS. Big block sizes would help, too. Everything on his system is in DIBOL, and he has a tape feed from some other system that monthly sends in new prices. The tape is unlabeled, starts with a file mark, and then has zillions of 352 byte records up to a trailing filemark. This is trivial to read under RSX using MOU /NOL, MAG, and PIP, but is there an easy way under RT? Will the RT system be able to read ANSII tapes RSX writes? Only if BS = RS, or even if BS = 10*RS? Will the 80 byte labels be ok? With all the features he wants to add, and due to our almost total lack of current RT experience, we want to move him to something other than an 11/34 + RT + 2*RK07 + TS11 + DZ11. A used 11/44 for well less than $3k can even use his MS11LD memory (with more, of course), his boot chips from his M9312 (or even the M9312 itself), and all his peripherals, and will let him move to M+ where I am totally comfortable, but what about DIBOL, and what else may bite? Any comments, even nasty ones from RT fans, will be welcome! ================================================================================ Note 223.1 [RT11]Non RT user faces RT - help! 1 of 7 EISNER::HAHN "DECUServe Vice Chair" 5 lines 9-JAN-1989 06:58 -< Just use the COPY command >- -------------------------------------------------------------------------------- When I had a tape drive under RT (last year) I just used COPY tape:*.* disk:*.* or disk:*.* tape:*.*; where disk and tape are the device name. No switches needed. Depending on the version your user has there may be a help capability for COPY. What version of RT ? ================================================================================ Note 223.2 [RT11]Non RT user faces RT - help! 2 of 7 EISNER::HASSINGER "Bob Hassinger" 23 lines 9-JAN-1989 11:19 -< Yep, "ANSI", RSX was good, RTEM-11 is good on VAX, look for a sw >- -------------------------------------------------------------------------------- It has been even longer since I used RT and even then not much with mag tape, but... I think in those days you could get two flavors of magtape support, one that supported an "ANSI format". I think you had to pick so you may have to look and see what this system is set up for. As you noted the most interesting characteristic of the "ANSI" support was the odd full block size label records. Given a fairly tolerant ANSI tape support implementation on another system you could get the data off the tape pretty well. Writing tapes to go the other way may be a problem - I don't know what RT does with 80 byte label records. I had my best luck getting RSX-11M to read the tapes. VMS was less tolerant back then. Since then however RTEM-11 on the VAX has gotten pretty good. I understand it you can, in effect, get RT to read the tape back on the VAX then you can use various tools to move it to VMS files if you like. I think you can go the other way as well. Check for an obscure switch to control the rewind-on-every-file problem. Can't remember any more if it was RT or RSX where it was vital to use the right switch to avoid this. ================================================================================ Note 223.3 [RT11]Non RT user faces RT - help! 3 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 36 lines 9-JAN-1989 20:46 -< RT-11 tapes are a pain in the A**, but readable >- -------------------------------------------------------------------------------- >> We discovered we could INIT the tape, and then pip'd using >> /x/m:1, but the damned tape kept rewinding for each file. Change the /m:1 to /m:-1 and it will copy each file to the tape without rewinding. NOTE! This allows you to cause later problems by having two files on the tape with the SAME name. If you are just copying *.* you should be OK. The equivalent DCL command is COPY/POS:-1. >> but it was a weird (labels 512 bytes long) but readable ANSII >> tape! It is an ANSI level 1 tape, while RSX and VMS use level 3. I used VMS EXCHANGE to read RT-11 tapes under VMS v4.x, but either I have forgotten how to do it or EXCHANGE is broken for v5.0. If you need more information on the various tape formats, let me know. I went through all this several years ago and still have all the documentation (somewhere). >> The tape is unlabeled, starts with a file mark, and then has >> zillions of 352 byte records up to a trailing filemark. This is >> trivial to read under RSX using MOU /NOL, MAG, and PIP, but is >> there an easy way under RT? Not without writing your own program to talk directly to the mag tape handler. >> will let him move to M+ where I am totally comfortable, but >> what about DIBOL, and what else may bite? DIBOL is supported under M+ (but not M). I don't know how compatible they are. Alan ================================================================================ Note 223.4 [RT11]Non RT user faces RT - help! 4 of 7 EISNER::CROWELL "Shefth of the Fourth Order" 15 lines 11-JAN-1989 04:12 -< caveat >- -------------------------------------------------------------------------------- The tapes produced by RT-11 INIT and COPY, as described in this stream can be read by VMS, either directly or via exchange. (There is an option on the VMS MOUNT command that tells it about RT-11's using only one HDR and one EOF record; I don't recall it at the moment.) If you copy directly, there will be problems with ASCII and OBJ files not being compatible. If you copy via EXHCHANGE, it'll make the conversions for you. There is a problem, however, with file names. With versions 5.4 and earlier, file names with fewer than six characters are padded with spaces, and VMS is not ready to accept that. So a file named FILE.DAT comes out as "FILE .DAT".; (not nice). (This is fixed in V5.5.) ================================================================================ Note 223.5 [RT11]Non RT user faces RT - help! 5 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 22 lines 11-JAN-1989 17:42 -< RT-11 and VMS still don't want to communicate >- -------------------------------------------------------------------------------- >> The tapes produced by RT-11 INIT and COPY, as described in this >> stream can be read by VMS, either directly or via exchange. (There >> is an option on the VMS MOUNT command that tells it about RT-11's >> using only one HDR and one EOF record; I don't recall it at the >> moment.) You are thinking of the /[no]HDR3 switch. RT-11 tapes don't even have HDR2!! The MOUNT manual says to mount the tape /FOREIGN and use EXCHANGE. >> If you copy directly, there will be problems with ASCII >> and OBJ files not being compatible. If you copy via EXHCHANGE, >> it'll make the conversions for you. About an hour of experimenting with both direct and EXCHANGE copying under VMS v5.0-2 was unsuccessful. Every file read was of ZERO length! I know that this worked under v4.x. Am I doing something wrong? The tape was written by RT-11 v5.4, so has something changed there? Is there (perish the thought!) a bug in VMS? Alan ================================================================================ Note 223.6 [RT11]Non RT user faces RT - help! 6 of 7 EISNER::HAHN "DECUServe Vice Chair" 20 lines 12-JAN-1989 07:32 -< RT tapes to VMS disk >- -------------------------------------------------------------------------------- This worked with RT V 5.? and VMS 4.6..4.7 have not tried it with VMS 5. $! copy rt11 tape files to current directories. $! Volume Label is P1 $! $ allocate mua0: $ set process/priv=VOLPRO $ mount/over=(owner,expir,access) mua0: 'p1' tape $ exchange init/create/allocate=32000 mt.dsk mount/virtual dt: mt.dsk show copy/log mua0:*.* dt:/allocate=1/transfer=block copy/log dt:*.*/transfer=block [] exit $ dismount mua0: $ set process/priv=NOVOLPRO $ deallocate mua0: ================================================================================ Note 223.7 [RT11]Non RT user faces RT - help! 7 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 13 lines 12-JAN-1989 14:29 -< Tape copy procedure works, but with a small bug >- -------------------------------------------------------------------------------- >> This worked with RT V 5.? and VMS 4.6..4.7 have not tried it with >> VMS 5. I just tried it under VMS v5.0-2 and it worked OK, but with a small problem. There is an extra CR/LF every 512(?) bytes in the text files I examined. I'll look at it further when I have some more time. I suspect that the /TRANSFER=BLOCK switch is what I was missing before, when I just got zero-length files. At least for now I can just edit out the extra CR/LF. Alan  ================================================================================ Note 224.0 [RT11]Need a few minutes of help with v5.4-F 1 reply EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 4 lines 9-JAN-1989 21:37 -------------------------------------------------------------------------------- Does anybody here have RT-11 v5.4-F (or later) that could spare a few minutes to answer some questions via telephone? Alan ================================================================================ Note 224.1 [RT11]Need a few minutes of help with v5.4-F 1 of 1 EISNER::CROWELL "Shefth of the Fourth Order" 1 line 11-JAN-1989 04:14 -< Call me some time >- -------------------------------------------------------------------------------- Of course, Allen. Call me at (916) 756-3291.  ================================================================================ Note 225.0 [RSX]Does BAD cheat, or RMD lie? No replies EISNER::BRUCE "Barton F. Bruce - CCA/MA" 9 lines 9-JAN-1989 22:52 -------------------------------------------------------------------------------- How does BAD do it! Or does RMD lie? I have just been watching RMD while bad runs, and du27: shows 6 QIOs/sec and 339456 words. That is 56576. words / qio, or 113,152 bytes or 221 blocks. Even if a QIO can do 113,152 bytes (can it?), where is BAD getting the buffer space in a 65k max task? I am sure I SPR'd this years ago, and never got any answer. I am still curious.  ================================================================================ Note 226.0 [RSX]M-Plus 2.1 to 4.0 migration: problems? 6 replies EISNER::LEDERMAN "Bart Z. Lederman" 16 lines 12-JAN-1989 18:50 -------------------------------------------------------------------------------- We have some systems here which are still running RSX-11M-Plus Version 2.1 (the last version I installed before I left that department some years ago!). Now they are thinking of upgrading the systems, and are considering going to V4.0 (4.1?). They have been talking to someone in DEC who says they have to make a lot of software changes, rebuild everything, get a new version of the FORTRAN compiler, etc. While it's probably a good idea to get the latest version of the compiler, I wouldn't think there would have to be a lot of changes: possibly one device driver might have to be updated. Does anyone know if there were any major changes in functionality between 2.1 and 4.0 which would REQUIRE programming changes? We are not using DECnet (for programs, we do sometimes NFT files on an individual basis), most of the software is fairly reasonable Fortran-IV-Plus (maybe Fortran-77 by now) code. I know about fast mapping and disk caching, but that shouldn't require changing code. ================================================================================ Note 226.1 [RSX]M-Plus 2.1 to 4.0 migration: problems? 1 of 6 EISNER::ROBITAILLE "Mike Robitaille" 17 lines 12-JAN-1989 22:41 -------------------------------------------------------------------------------- Bear in mind that I used IAS - not RSX - but I believe that what I'm about to say is still valid. We converted a whole bunch of F4p code and recompiled it using the F77 switch that indicated older F4P code (/F66?). The F77 runtime library was much larger, and caused old F4P programs that were close to the limit to fail to build because their task image size was too large. Had to use the supervisor mode libraries (FCSFSL for the file system stuff) and had to change overlay structures. RSX had I&D, so if your PDP hardware knows about that, definitely use it! IAS never got around to supporting I&D. When asked when IAS would, DEC IAS techies replied that they would "whenever RSX got their bugs out." sigh. If all of the above are used, and some programs still won't build, look at some of your larger fortran modules and see if they can't be broken up into smaller pieces to make a tighter overlay structure. The other thing to worry about are your privileged tasks. Doubtless things changed in the exec between 2.1 and V4.?. Enjoy. ================================================================================ Note 226.2 [RSX]M-Plus 2.1 to 4.0 migration: problems? 2 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 17 lines 13-JAN-1989 15:37 -< M+ 2.1 -> 4.1 simple + safe, but... >- -------------------------------------------------------------------------------- > Does anyone know if there were any major changes in functionality > between 2.1 and 4.0 which would REQUIRE programming changes? Everything non priv should just work, but watch out for anything that expects octal version numbers, or gen for no decimal support. All that changes is ONE bit, and it is easy to manually flip it later if you change your mind either way. Rebuild tasks built to resident FCS librarys. If overlaying the new system on an old pack watch out for old xxxFSL or old xxxRES system utilities. Two changes have happened that can cause unexpected problems. M+ will give only the optimum version of a task. I.E. if there is NO benefit to the xxxFSL version, you won't have it. And INS $xxx now is smarter and tries the xxxFSL and xxxRES first before the vanilla xxx so you might just accidently get an old version installed by mistake if it was lurking there on disk. ================================================================================ Note 226.3 [RSX]M-Plus 2.1 to 4.0 migration: problems? 3 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 2 lines 13-JAN-1989 15:40 -< Remember the now old VD bug, also >- -------------------------------------------------------------------------------- One more problem some got bitten by was with VDs. Make sure the US.MSD bit is set in the VD's UCB. ================================================================================ Note 226.4 [RSX]M-Plus 2.1 to 4.0 migration: problems? 4 of 6 EISNER::WYANT "Tom Wyant" 40 lines 17-JAN-1989 12:16 -< Onward and Upward! >- -------------------------------------------------------------------------------- My experience is that upgrading RSX is seldom a problem as far as application functionality goes. The last one that bit us hard was M V3.1 to 3.2, when we got the full duplex TT: driver and device independant cursor positioning (Did you know that if you say P(3) = ' ', FORTRAN stores ' ' just in case you wanted that second blank after all? We couldn't understand why all our output came out with '[32;32H' in front). For 2.1 to 3.0 (the last one I did before leaving MY old group), the major things we encountered were around named directories and extended logical names. * Named directories: DECmail didn't like it if the account file didn't specify a directory name, and tried to put the mail in []. This resulted in all the mail you sent out coming right back to you, and mail from off-node didn't get delivered at all (we had TT0: logged out), with the sender getting "Device Offline" or some such nonsense. * Extended logicals: These are easy to trip over if you aren't careful. Several of us acquired over the years the habit of using our initials for devices, files, etc when we were just hacking around. Well, with 3.0 and up, if you (for example) do >ASN TI:=TW: >EDT TW.FTN >F77 TW=TW FORTRAN tries to compile your terminal. * SRD You should get a current copy to get full named directory functionality, but we've run for years with just a relinked '83 version. No problem, it just says [000,000] at the top of a listing of a named directory. * DECnet See the note elsewhere in this conference. ================================================================================ Note 226.5 [RSX]M-Plus 2.1 to 4.0 migration: problems? 5 of 6 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 12 lines 18-JAN-1989 00:13 -< Potential significant event problem >- -------------------------------------------------------------------------------- Another problem that could POSSIBLY bite you is that a round-robin pass that results in no new task being scheduled does NOT cause a significant event. The previous action was to cause one every time. This is a problem for you ONLY if your application has a task that waits for a significant event, expecting to get one at every round-robin run. I don't recall at exactly which version this happened. Alan ================================================================================ Note 226.6 [RSX]M-Plus 2.1 to 4.0 migration: problems? 6 of 6 EISNER::LEDERMAN "Bart Z. Lederman" 15 lines 18-JAN-1989 08:06 -< Looks like it's not a problem. >- -------------------------------------------------------------------------------- I don't think the round-robin change will affect us. We do have programs which pass data on a circular queue. A program comming in has to check a 'busy' bit in the common region, and if it's busy it does a wait for significant event and checks again. BUt the program which has region busy is going to have to set the common bit clear when it leaves and there should be enough I/O activity and other stuff going on that someone somewhere will cause a significant event of some kind. They are now also considering migration to VAX after I explained that most of their stuff would run without significant changes, but they may still have to stick with PDP11s for various (mostly financial, but also the length of time needed to convert) reasons. Thanks to everyone for the information.  ================================================================================ Note 227.0 [RSX]Anyone have C on IAS? 9 replies EISNER::LAMBERT_M "Mike Lambert" 8 lines 16-JAN-1989 11:55 -------------------------------------------------------------------------------- We are thinking of putting C on our IAS 3.2 PDP11/84. Doing it from scratch means picking up the DECUS C tape and rewriting the directive library. This is what I'll probably be doing soon unless I run into someone that already has it up and running on IAS. Question: Does anyone have (or know someone that knows someone ...) C already running under IAS 3.x? If the wheel has already been invented... ================================================================================ Note 227.1 [RSX]Anyone have C on IAS? 1 of 9 EISNER::KENNEDY "Terry Kennedy" 15 lines 16-JAN-1989 20:22 -< Opinions on DECUS C >- -------------------------------------------------------------------------------- > Doing it from > scratch means picking up the DECUS C tape and rewriting the directive > library. Question - how does IAS differ from M (un-plus flavor). If the answer is 'not by much', then simply rebuilding the compiler might work for you. Next, I've put in substantial maintenance time on the DECUS C compiler (several hundred hours). The compiler isn't bad, but it is *not* 'modern' C, and will barf on some newer constructs. It is also one of the 'missing semicolon generates thousands of errors' kind. The run-time library, on the other hand, is rather poor. If you're really going to do a re-write, take something like the JPL public-domain library and implement the prim- itives it needs. That will get you a fully functional library in far less time. ================================================================================ Note 227.2 [RSX]Anyone have C on IAS? 2 of 9 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 13 lines 17-JAN-1989 17:54 -< try Whitesmiths >- -------------------------------------------------------------------------------- > Question: Does anyone have (or know someone that knows someone ...) > C already running under IAS 3.x? If the wheel has already been > invented... I don't know if they do or do not, but you could try Whitsmiths. They don't charge much, but when you complain about something, their answer seems to almost be that you got what you paid for. I know of user provided enhancements they were GIVEN, that they never used, but I think there was one RTL fix they were given they did incorporate (under M+). RSX (and I assume IAS) is foreign to them, and they only boot their RSX pack when absolutely necessary. ================================================================================ Note 227.3 [RSX]Anyone have C on IAS? 3 of 9 EISNER::LAMBERT_M "Mike Lambert" 2 lines 15-FEB-1989 15:01 -< JPL public domain library? >- -------------------------------------------------------------------------------- Terry, what is the JPL public-domain library you mentioned? Mike ================================================================================ Note 227.4 [RSX]Anyone have C on IAS? 4 of 9 EISNER::LAMBERT_M "Mike Lambert" 2 lines 15-FEB-1989 15:02 -< Whitsmiths? >- -------------------------------------------------------------------------------- Barton, Whitsmiths? Do you have a phone number? Mike ================================================================================ Note 227.5 [RSX]Anyone have C on IAS? 5 of 9 EISNER::MAYHEW "Bill Mayhew" 8 lines 15-FEB-1989 15:18 -< Whitesmiths >- -------------------------------------------------------------------------------- Whitesmiths, Ltd. is in Westford, MA... last phone number I have for them (508-369-8499, taking into account the area code change) was for their previous Concord, MA office, but may get you close. I agree with what Barton said, btw. I used two of their products for a number of years and found them well-engineered (as long as you stay away from DEC opsys-dependent stuff!) but not very well supported. ================================================================================ Note 227.6 [RSX]Anyone have C on IAS? 6 of 9 EISNER::LAMBERT_M "Mike Lambert" 2 lines 15-FEB-1989 15:44 -< Wsmiths phone number thanks >- -------------------------------------------------------------------------------- Bill, thank you for the Whitesmiths phone number. Mike ================================================================================ Note 227.7 [RSX]Anyone have C on IAS? 7 of 9 EISNER::MAYHEW "Bill Mayhew" 4 lines 15-FEB-1989 16:43 -< Intermetrics buying Whitesmiths >- -------------------------------------------------------------------------------- I forgot to mention that Whitesmiths is in the process of being bought out by Intermetrics, which is headquartered in Cambridge last I heard. I have no idea what this means in terms of product availability or support. ================================================================================ Note 227.8 [RSX]Anyone have C on IAS? 8 of 9 EISNER::KENNEDY "Terry Kennedy" 13 lines 16-FEB-1989 01:32 -< Info on JPL library & where to get it >- -------------------------------------------------------------------------------- > Terry, what is the JPL public-domain library you mentioned? Mike It's a relatively complete C run-time library written by the folks at the Jet Propulsion Labs. If you can provide some low-level file I/O functions, you can get a rather complete C library. It's all writ- ten in C, and is available on many BBS systems. You could try the following BBS: The High Frontier (201) 739-3693 24 Hours/day, 1200/2400 baud The file is out there in the C section as JPL-C.ARC... ================================================================================ Note 227.9 [RSX]Anyone have C on IAS? 9 of 9 EISNER::LAMBERT_M "Mike Lambert" 3 lines 17-FEB-1989 11:59 -< JPL C Library >- -------------------------------------------------------------------------------- Terry, thanks for the info on the JPL C library. I'll get it with PC and transfer it to the PDP. Mike  ================================================================================ Note 228.0 [RSTS]USING A RSTS SYSTEM TO BACKUP VMS FILES 4 replies EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 28 lines 21-JAN-1989 15:10 -------------------------------------------------------------------------------- If I setup a VAXstation 3100 and MicroPDP-11 on the same E-net both running DECnet can I do the following.... Option A. 1. Backup a set of files to a VMS backup file on the 3100 2. Copy that VMS backup file over the net to a RSTS disk 3. Use RSTS backup to load that file to a tape. Option B. 1. Backup a set of files to a VMS backup file on the 3100 2. Copy that VMS backup file over the net to a RSTS tape Will this work? Will I lose any file attributes on the VMS file in the process? If I lose attributes can they be replace easily? The reason why I want to do this is because the 3100 will have a RRD40 and I want to avoid putting a tape drive on it. This will be a development machine so we are looking at about 5-10MB of backup per day. ================================================================================ Note 228.1 [RSTS]USING A RSTS SYSTEM TO BACKUP VMS FILES 1 of 4 EISNER::KENNEDY "Terry Kennedy" 38 lines 21-JAN-1989 19:53 -< Doable - yes, practical - maybe >- -------------------------------------------------------------------------------- > Option A. > 1. Backup a set of files to a VMS backup file on the 3100 Ok. > 2. Copy that VMS backup file over the net to a RSTS disk Ok. > 3. Use RSTS backup to load that file to a tape. Nah - Just COPY it. Otherwise that file will get real *big* on the tape (2 sets of XOR blocks). Also, when you restore this, you'll probably have to use FILE or some such to get the right attributes back. If you really want to be sure, let me know and I'll go try it. >Option B. > 1. Backup a set of files to a VMS backup file on the 3100 Ok. > 2. Copy that VMS backup file over the net to a RSTS tape You'll be retiured first... > Will I lose any file attributes on the VMS file in the process? Probably - see above > If I lose attributes can they be replace easily? Likewise. But easily restored once the method is understood (remember Kermiting conference files?) > The reason why I want to do this is because the 3100 will have a RRD40 and > I want to avoid putting a tape drive on it. This will be a development > machine so we are looking at about 5-10MB of backup per day. Given that 150Mb of 1/4" cartridge tape backup costs me about $1000 with the TMSCP controller, I'd opt for the tape. Especially if you just want backup and not interchange. However, presumably this system is to develop software for customers, and they have to be able to read the end result without convolutions, so you'll probably need some form of DEC tape media eventually. ================================================================================ Note 228.2 [RSTS]USING A RSTS SYSTEM TO BACKUP VMS FILES 2 of 4 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 14 lines 21-JAN-1989 21:00 -< OK I'LL TAKE THAT OFFER >- -------------------------------------------------------------------------------- > Also, when you restore this, you'll probably have to use FILE or some > such to get the right attributes back. If you really want to be sure, > let me know and I'll go try it. If you wouldn't mind giving it a try.... > Given that 150Mb of 1/4" cartridge tape backup costs me about $1000 with > the TMSCP controller, I'd opt for the tape. Especially if you just want > backup and not interchange. However, presumably this system is to develop > software for customers, and they have to be able to read the end result > without convolutions, so you'll probably need some form of DEC tape media > eventually. Remember the 3100 has no Q or U bus. ================================================================================ Note 228.3 [RSTS]USING A RSTS SYSTEM TO BACKUP VMS FILES 3 of 4 EISNER::KENNEDY "Terry Kennedy" 138 lines 21-JAN-1989 23:04 -< Test complete, try SCSI tape in 3100 >- -------------------------------------------------------------------------------- > Remember the 3100 has no Q or U bus. Does it support a SCSI tape drive interface? If so, try the 5150ES drive - it might work. > If you wouldn't mind giving it a try.... Here goes - *large* logfile appended CONNECT 9600/ARQ DECserver 200 Terminal Server V2.0 (BL29) - LAT V5.1 121 Glenwood LAT #2 (2.4) Please type HELP if you need assistance Local> c spcvxa Local -010- Session 1 to SPCVXA established Welcome to SPCVXA.STPETERS.EDU (VAX-11/780) Username: TERRY Password: Welcome to VAX/VMS version V5.0-2 on node SPCVXA Last interactive login on Saturday, 21-JAN-1989 22:27 Last non-interactive login on Friday, 20-JAN-1989 21:31 Z> AMAZING BUT TRUE... There is so much sand in Northern Africa that if it were spread out it would completely cover the Sahara Desert. $ backup/log []*.com test.bck/save %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]ADDUSER.COM;7 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]EDIT.COM;3 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]FOO.COM;7 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]LOGIN.COM;2 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]MONITOR.COM;5 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]TIMESERV.COM;3 %BACKUP-S-COPIED, copied SYS$SYSDEVICE:[TERRY]XMODEM.COM;1 $ copy test.bck spc11b:: $ set host spc11b %REM-I-REMOTE, connection established to remote node SPC11B:: Welcome to RSTS/E V9.6-11 on node SPC11B RSTS V9.6-11 SPC11B.SPC.EDU Job 7 KB42: 21-Jan-89 10:58 PM User: 1,254 Password: Last interactive login on Saturday, 21-Jan-89 10:26 PM at KB42: Last non-interactive login on Wednesday, 18-Jan-89 10:07 PM 1 other user is logged in under this account Special memo for instructors: Please be certain to delete any student accounts which have expired. We need the disk space! If you break a cup or plate, it will not be the one that was already chipped or cracked. -- Denys Parsons SPC11B::$ backup/dir [2,2]test.bck Please mount volume 1 of Backup set TEST .BCK Where can this volume be located? %Invalid Backup set attributes - can't use it Where can this volume be located? ^Z SPC11B::$ dir/full [2,2]test.bck Name .Typ Size Prot Access Date Time Clu RTS Pos SY:[2,2] TEST .BCK 126 < 60> 21-Jan-89 21-Jan-89 10:57 PM 32 ...RSX 11289 RF:FIX=32256FO:SEQ USED:127:0 RECSI:32256 Total of 126 blocks in 1 file in SY:[2,2] SPC11B::$ bye Saved all disk files on SY: 9152 blocks in use Job 7 User 1,254 logged off KB42: at 21-Jan-89 10:58 PM 1 other user still logged in under this account System RSTS V9.6-11 SPC11B.SPC.EDU Run time was 7.8 seconds Elapsed time was 0 minutes Good evening > %REM-S-END, control returned to node _SPCVXA:: $ dir test.bck/size Directory SYS$SYSDEVICE:[TERRY] TEST.BCK;2 126 Total of 1 file, 126 blocks. $ del test.bck;* $ copy spc11b::test.bck [] $ backup/list test.bck/save Listing of save set(s) Save set: TEST.BCK Written by: TERRY UIC: [000010,000376] Date: 21-JAN-1989 22:54:40.09 Command: BACKUP/LOG []*.COM TEST.BCK/SAVE Operating system: VAX/VMS version V5.0 BACKUP version: V5.0 CPU ID register: 014037B2 Node name: _SPCVXA:: Written on: _DUA0: Block size: 32256 Group size: 10 Buffer count: 3 [TERRY]ADDUSER.COM;7 14 21-FEB-1987 03:17 [TERRY]EDIT.COM;3 2 21-FEB-1987 03:26 [TERRY]FOO.COM;7 14 21-FEB-1987 03:17 [TERRY]LOGIN.COM;2 1 7-NOV-1988 02:52 [TERRY]MONITOR.COM;5 1 20-MAY-1987 20:11 [TERRY]TIMESERV.COM;3 1 8-JAN-1989 05:42 [TERRY]XMODEM.COM;1 2 11-MAY-1988 06:43 Total of 7 files, 35 blocks End of save set $ lo TERRY logged out at 21-JAN-1989 22:57:32.59 Accounting information: Buffered I/O count: 616 Peak working set size: 643 Direct I/O count: 117 Peak page file size: 2759 Page faults: 2527 Mounted volumes: 0 Charged CPU time: 0 00:00:12.21 Elapsed time: 0 00:03:30.50 Local -011- Session 1 disconnected from SPCVXA Local> lo Local -020- Logged out port 8 NO CARRIER ================================================================================ Note 228.4 [RSTS]USING A RSTS SYSTEM TO BACKUP VMS FILES 4 of 4 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 21-JAN-1989 23:47 -< THANKS! >- --------------------------------------------------------------------------------  ================================================================================ Note 229.0 [PRO300]Disappearing Files 3 replies EISNER::COOPER "Steve Cooper" 6 lines 23-JAN-1989 15:08 -------------------------------------------------------------------------------- Has anyone ever written a file under P/OS, closed it with a status of success, and then not have the file on disk? If so, did you ever find the reason? Thanks, Steve ================================================================================ Note 229.1 [PRO300]Disappearing Files 1 of 3 EISNER::MAYHEW "Bill Mayhew" 4 lines 23-JAN-1989 17:30 -< Hasn't happened to me, but one explanation... >- -------------------------------------------------------------------------------- There is a bit in the RMS FAB that says this is a marked-for-deletion file (FB$MKD), which will be deleted when the file is closed. What software are you using to write this file? ================================================================================ Note 229.2 [PRO300]Disappearing Files 2 of 3 EISNER::COOPER "Steve Cooper" 4 lines 25-JAN-1989 19:10 -< False Alarm >- -------------------------------------------------------------------------------- Oops! Turns out there is no problem here. I couldn't figure out why this was happening so I checked into log files that we keep and discovered that our users had led me astray. The files were not there because they were never actually sent. ================================================================================ Note 229.3 [PRO300]Disappearing Files 3 of 3 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 9 lines 25-JAN-1989 20:51 -< USER TRUST >- -------------------------------------------------------------------------------- > discovered that our users had led me astray. The files were not What you trusted a user! 8-) My company supports about 1400 users at 80 plus sites and as I tell my staff..... Rule 1 - Humor the user but assume the error report is garbage Rule 2 - Refer to rule 1  ================================================================================ Note 230.0 [RSX]UCB, EMT377, etc. 1 reply EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 15 lines 26-JAN-1989 12:16 -------------------------------------------------------------------------------- I'm not exactly sure of how to ask this question. My co-worker is trying to write/modify a device driver. He says that, when the task is "abnormally aborted" it does not appear to redirect the LUNS. He also says that the UCB control bits appear to be set and it goes to EMT377. The question he asked me, and I have no idea how to answer, is what happens...what is the chain of events...after an abort. I guess he wants to know what gets opened, closed, redirected, etc. and what he might look for in the code (he mentioned "Cancel I/O entry" having something to do with it)? If this sounds like rambling, please tell me what you need to know in order to answer an intelligent question. Thanx. Charly ================================================================================ Note 230.1 [RSX]UCB, EMT377, etc. 1 of 1 EISNER::WYANT "Tom Wyant" 59 lines 27-JAN-1989 15:11 -< Requiem for a task >- -------------------------------------------------------------------------------- >>> The question he asked me, and I have no idea how to answer, is >>> what happens...what is the chain of events...after an abort. Haven't we had this conversation before? I'll be glad to share my bit of misinformation - it might outrage others enough to tell you the real story. When a task exits for any reason fair or foul, the exec takes it upon itself to clean up any I/O it may have left laying around. As I understand it, this is done by faking an IO.KIL on the task's LUNs. On IO.KIL, the exec flushes the driver's request queue without the driver being any the wiser (at least for the generic case - is it also true for TT: and other drivers that look at the packets before they are queued?). The Cancel I/O driver entry is for active requests. Most drivers ignore "Cancel I/O". The public reason for this is that I/O completes so quickly that nothing is gained by going out of your way to terminate it early. Sometimes this even holds water - but if it were universally true, why is ABORT/I_MEAN_IT such a popular request? Anyhow, the task can't go away until all it's I/O completes. Sometimes this is an unnoticable interval. Sometimes the task spends days marked for abort, in I/O rundown state, with one or more I/O requests outstanding, and people are driven to OPE xxxxxx+2/KNLD. If this is the problem, he needs to figure out how to make the driver terminate the I/O cleanly, or live with the consequences. Once the task exits, the device database -SHOULD- be clean. The task's database is too, as all it "knows" at this point is the UCB address the LUNs are assigned to. That's the easy part. Now as for narrowing down the problem... >>> He says that, when the task is "abnormally aborted" it does not >>> appear to redirect the LUNS. This is his interpretation of the symptoms. Unfortunately, this interpretation doesn't seem to mesh too well with reality. A driver hain't got LUNS, and a task normally can't avoid having them cleaned up. What is the system actually doing, to cause him to say the LUNs aren't redirected? In particular, what is the task state? >>> He also says that the UCB control bits appear to be set Now we're getting warmer. What fields in the UCB/DCB/SCB/ whatever, and what bits? This is something we can work with. >>> and it goes to EMT377. Huh? The DRIVER is executing an EMT377? How did it get there? Anyhow, that's my shot at it. Give a 'phone call if you'd like to talk it over.  ================================================================================ Note 231.0 [RSX]The upgrade nightmare 3 replies EISNER::SIMONS "Paul, Not that CONVEX!" 10 lines 27-JAN-1989 11:41 -------------------------------------------------------------------------------- We are upgrading our PDP from 4.0 to 4.1 of M+. This is the first time we have everactually upgraded an RSX system. We were on 3.1 of M for seven years, and life was, at least, stable. Then we went and bought 4.0, and ported everything over to it. Now we have things to our liking, but when we call CSS, they roll their eyes and say we'll have to upgrade to the lastest version. So we decided to upgrade. And now the question: How do we upgrade to 4.1 without losing our versions of [1,2]startup.cmd, sysvmr.cmd, etc. Do we have to do selective restores from tape? Are we missing something obvious? Is this nightmare for real? ================================================================================ Note 231.1 [RSX]The upgrade nightmare 1 of 3 EISNER::DELARISCH "Arnold S. De Larisch" 26 lines 27-JAN-1989 13:47 -< Need more input on hardware/environment to do SYSGEN >- -------------------------------------------------------------------------------- >> < Note 110.0 by EISNER::SIMONS "Paul, Not that CONVEX!" > >> -< The upgrade nightmare >- >> And now the question: How do we upgrade to 4.1 without losing our >> versions of [1,2]startup.cmd, sysvmr.cmd, etc. Do we have to do >> selective restores from tape? Are we missing something obvious? >> Is this nightmare for real? Well ... It depends if you are doing an 'on-line' SYSGEN or a 'standalone' SYSGEN. It also depends if you have one or more 'free' disk drives available. Generally, we do our SYSGENS online to a pair of RK07 disks (all you really need is one, but the stupid BASTART.CMD want a second drive to dump the sources to! We SYSGEN the system and do a Virgin boot and save the system. Then we reboot the original system and do all the customizations eventually needing to reboot the 'new system' to do the actual SYSVMR. There are other ways depending on your configuration and available 'down time'. ... NEED MORE INPUT! -Arnold ================================================================================ Note 231.2 [RSX]The upgrade nightmare 2 of 3 EISNER::WYANT "Tom Wyant" 9 lines 27-JAN-1989 15:18 -< Freddie lives! >- -------------------------------------------------------------------------------- >>> Is this nightmare for real? In general, the answer is "yes", though you can minimize it. Rather than do selective restores from tape, I recommend doing a selective backup in the first place, followed by a full restore. With a "real-sysgen" system, I generally use another disk, and just copy over the stuff I need. I generally look at DEC's SYSVMR to see if they've played any new tricks, and then throw it away. Ditto for their STARTUP.CMD ================================================================================ Note 231.3 [RSX]The upgrade nightmare 3 of 3 EISNER::SIMONS "Paul, Not that CONVEX!" 14 lines 27-JAN-1989 16:49 -< Fooling around in the dark >- -------------------------------------------------------------------------------- < Note 110.1 by EISNER::DELARISCH "Arnold S. De Larisch" > Then we reboot the original system and do all the customizations eventually needing to reboot the 'new system' to do the actual SYSVMR. < Note 110.2 by EISNER::WYANT "Tom Wyant" > I generally look at DEC's SYSVMR to see if they've played any new tricks, and then throw it away. Ditto for their STARTUP.CMD So it looks like we're a long way from VMSINSTALL, and probably better for it. Thank you for your timely replys.  ================================================================================ Note 232.0 [PRO300]TMS on Leased Lines 2 replies EISNER::COOPER "Steve Cooper" 6 lines 27-JAN-1989 12:43 -------------------------------------------------------------------------------- Has anyone tried using TMS on a leased line? If so, do you have any pointers? We are trying to talk to our remote sites using better and faster modems, but the comm port is used for a leased line connection to meteorological towers. - Steve ================================================================================ Note 232.1 [PRO300]TMS on Leased Lines 1 of 2 EISNER::RICE "Gary Rice" 10 lines 28-JAN-1989 09:15 -------------------------------------------------------------------------------- > Has anyone tried using TMS on a leased line? If so, do you have... I haven't, but here is an observation: The TMS is a MODEM device capable of 1200 BAUD MAX. If you can only communicate at 1200 BAUD, does it make sense (economically) to lease a line if you can only drive it at that speed? Gary ================================================================================ Note 232.2 [PRO300]TMS on Leased Lines 2 of 2 EISNER::COOPER "Steve Cooper" 23 lines 1-FEB-1989 18:33 -< Even Worse Than 1200 >- -------------------------------------------------------------------------------- > The TMS is a MODEM device capable of 1200 BAUD MAX. If you can only > communicate at 1200 BAUD, does it make sense (economically) to lease > a line if you can only drive it at that speed? Currently, it's even worse than 1200. The modems in the towers are capable of 300 bps. The company that manufactures the meteorological towers is looking at 1200, but the price tag will probably be too high for some of our customers to bother to convert. The Pros that have towers are generally a mile or two from the tower. The software polls the tower for data every 15 minutes. I think it depends on the location whether they use an actual leased line or a long line with the modem as a "long-haul driver". The TMS unit is currently used to connect to us via dial-up while a standalone DEC modem is used for the dedicated line to the tower. What I would like to do is use the TMS unit for the tower so we could free up the comm port to allow higher speed (and better) modems to connect to us. I think it can be done using the IO.ORG (originate) function. I just won't have the time to try it for awhile so I was wondering if anyone else had done so. - Steve  ================================================================================ Note 233.0 [RSX]RSX11M V4.5 is alive! No replies EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 6 lines 30-JAN-1989 17:56 -------------------------------------------------------------------------------- Holey Sysgen, I just received RSX11M V4.5...will it ever end? Will they soon decide there are enough bugs in V4.xxx and bring out V5.0??? Anyway, for what its worth, this is the latest I know of on RSX.  ================================================================================ Note 234.0 [RSX]A lonely plea for TECO help 4 replies EISNER::HUDGINS 5 lines 31-JAN-1989 11:30 -------------------------------------------------------------------------------- Does anyone out there have a version of RSX TECO that supports named directories? If not, has someone already made this mod for the PRO, and might it work with RSX? Just who is the keeper of the TECO source code these days, anyway (Brian, is Digital still maintaining it internally?) and can one get a copy of it yet? ================================================================================ Note 234.1 [RSX]A lonely plea for TECO help 1 of 4 EISNER::SIEMSEN "Pete Siemsen" 16 lines 15-AUG-1989 00:08 -< The TECO Collection might help >- -------------------------------------------------------------------------------- I'm not an RSXer, but I am the librarian for the TECO Working Group of the Languages and Tools SIG in DECUS. I maintain a collection of TECO stuff. I just started (submitted version 1 of the collection about 1 week ago). I have three TECOs written in C, unfortunately none for RSX. I do have the most recent TECO manual, which describes the TECO DEC distributes. The manual is newer than the one that comes from DEC: it's the latest version of the manual that they just haven't bothered to send to their publishing department. It describes features of the editor you already use that you probably don't know about, like binding keys to TECO macros, using q-registers that are local to a macro, and more. If you'd like me to send you a machine-readable copy of the manual, please send me mail. I'll send a table-of-contents of the collection, too. ================================================================================ Note 234.2 [RSX]A lonely plea for TECO help 2 of 4 EISNER::HUDGINS "Jerry Hudgins" 4 lines 18-AUG-1989 15:18 -< Yes, I think it would >- -------------------------------------------------------------------------------- That sounds great. I can read TK50's (BACKUP, BRU, ANSI, DOS/FLX/EXCHANGE), 1600 BPI magtape (but not BACKUP), and RX50's (ODS-1 only). I'll happily make a copy and return your media, if you like. My current mailing address is in WHO AM I. Thanks. ================================================================================ Note 234.3 [RSX]A lonely plea for TECO help 3 of 4 EISNER::HUDGINS "Jerry Hudgins" 14 lines 5-OCT-1989 19:39 -< The Beast is Bagged! >- -------------------------------------------------------------------------------- If Anyone Still Cares Dept.: With the help of a kind DECUServe friend, I have obtained enough RSX TECO source material to produce a V36 TECO which supports named directories. I also was able to turn on EIS support, which should speed things up a bit more. As suspected, the directory problem required only a relink with newer FCS code. The result is wholly satisfactory and appears to be reliable. This is the end of a long quest for me. I HOPE I WASN'T DUPLICATING PREVIOUS EFFORTS!!! If there are any other RSX/TECO weenies out there that would like a copy of this wonderful creation, send MAIL. Kermit arrangements could be made; the task is only 91 blocks. ================================================================================ Note 234.4 [RSX]A lonely plea for TECO help 4 of 4 EISNER::TACKETT "Galen Tackett" 1 line 7-OCT-1989 15:41 -< I'd like to have it! >- -------------------------------------------------------------------------------- Your updated TECO would be handy to have...  ================================================================================ Note 235.0 [RSX]Kermit-11 crashes Micro/RSX V4.0 5 replies EISNER::HUDGINS 6 lines 31-JAN-1989 11:36 -------------------------------------------------------------------------------- Kermit-11 (V3.56) crashes my Micro/RSX V4.0 system, probably when setting or resetting comm port characteristics. Has anyone else seen this problem, and is there a workaround? I've left a couple of notes on Brian Nelson's Kermit download service, but have received no response. ================================================================================ Note 235.1 [RSX]Kermit-11 crashes Micro/RSX V4.0 1 of 5 EISNER::KENNEDY "Terry Kennedy" 20 lines 1-FEB-1989 09:38 -< Offer of help, possible update >- -------------------------------------------------------------------------------- > I've left a couple > of notes on Brian Nelson's Kermit download service, but have received > no response. Same here. However, I did speak to him about Kermit bugs (I got him to call me by sending him a message saying "I fixed a bug but I'm not telling you the bug or the fix until I get a phone call.") He is very busy with other things, and doesn't have much (any?) time to deal with Kermit or other stuff lately. The latest Kermit-11 directly from him is V3.59, which is found on the RSTS SIG 1987 SIG tape. You can pull it off the RSTS Newsletter system at (201) 915-9361. It's in [87,something]. Look for K11CMD.MAC. The fornt of that file has the edit history for all changes. Note that 3.59 is newer than either Columbia *or* his dialup system has. I've been fixing some bugs in the non-os-dependant parts (like the protocol engine) as well as in the RSTS-unique parts. If you want to send me a MAIL message with the gory details, I'd be glad to look at it for you. I don't have RSX, so it may be a bit of guesswork. ================================================================================ Note 235.2 [RSX]Kermit-11 crashes Micro/RSX V4.0 2 of 5 EISNER::HUDGINS "Jerry Hudgins" 6 lines 2-FEB-1989 16:55 -< A possible diagnosis and workaround >- -------------------------------------------------------------------------------- I've rediscovered the M+ SF.SMC problem (see "Simple SF.SMC crashes Micro/RSX"), which I suspect is the culprit in my Kermit-11 problems. I need to apply the workaround (use SF.SMC only while privileged) to my old Kermit-11 V3.56 sources and check it out. I'll let you guys know the result. Jerry ================================================================================ Note 235.3 [RSX]Kermit-11 crashes Micro/RSX V4.0 3 of 5 EISNER::HUDGINS "Jerry Hudgins" 10 lines 9-FEB-1989 11:53 -< Yep, that was it. >- -------------------------------------------------------------------------------- > I've rediscovered the M+ SF.SMC problem (see "Simple SF.SMC > crashes Micro/RSX"), which I suspect is the culprit in my > Kermit-11 problems. This was indeed the problem. K11M41.MAC contains a couple of instances of SF.SMC to the remote port which occur while privileges are down. I'll document these (and a couple of local-terminal-handling problems) and report them to Brian Nelson. Jerry ================================================================================ Note 235.4 [RSX]Kermit-11 crashes Micro/RSX V4.0 4 of 5 EISNER::HUDGINS "Jerry Hudgins" 6 lines 22-MAR-1989 12:54 -< Kermit-11 fixed and available soon >- -------------------------------------------------------------------------------- Brian Nelson sent me a tape of his V3.59 Kermit-11 sources and I've applied patches that fix the aforementioned M+ crash problem and also speed up CONNECT mode local terminal handling. I've tentatively dubbed this version V3.60 and am returning the changes to Brian. He should be making the new version available (at least on his bulletin board) soon. If anyone needs it sooner, give me a buzz. ================================================================================ Note 235.5 [RSX]Kermit-11 crashes Micro/RSX V4.0 5 of 5 EISNER::HUDGINS "Jerry Hudgins" 5 lines 4-JUN-1989 00:58 -< Kermit-11 V3.60 released >- -------------------------------------------------------------------------------- Brian has released to his Kermit download service Kermit-11 V3.60, which contains the aforementioned SF.SMC patches and buffering of local terminal input (so SET /INQUIRE, etc. will finally work). You can download it directly from Toledo if you don't want to wait for the next Columbia tape.  ================================================================================ Note 236.0 [RSX]Simple SF.SMC crashes Micro/RSX 5 replies EISNER::HUDGINS "Jerry Hudgins" 60 lines 2-FEB-1989 09:48 -------------------------------------------------------------------------------- In the process of doing other things, I've managed to write a simple MACRO task which handily kills my Micro/RSX V4.0 system. All it attempts to do is set TC.DLU=2 for a terminal port, which I've done elsewhere using the same techniques without any problem. It sounds suspiciously like the same problem I'm having with Kermit-11 under this revision (see previous note). The code is presented below: .title ADL -- Sets Up Autodial Port .mcall Gmcr$,Dir$,Alun$s,Qiow$s,Exit$s ; .psect rwdata,rw,d getdpb: Gmcr$ ; DPB, get MCR command line setblk: .byte TC.DLU,2 ; SF.SMC block, set autodial SETLEN =: .-setblk ; .psect rocode,ro,i adl: Dir$ #getdpb ; get command line cmp #3,$DSW ; argument specified? bhis 10$ ; no, just exit mov #getdpb+G.MCRB+4,R0 ; addr of port number in R0 Call $cotb ; make it binary Alun$s #1,#"TT,R1 ; assign port to LUN 1 Qiow$s #SF.SMC,#1,#1,,,,<#setblk,#SETLEN> ; set port 10$: Exit$s .end adl This seemingly innocent code fragment causes the system to trap to XDT with the following register dump: SO:004146 XDT>$0/044432 $1/000050 $2/021314 $3/020550 XDT>$4/000002 $5/027710 $6/000054 $S/000340 XDT> XDT>$6/000054 @ D 000054 /002452 D 000056 /030000 D 000060 /012164 D 000062 /000340 D 000064 /012144 D 000066 /000340 D 000070 /003304 D 000072 /000356 D 000074 /003304 D 000076 /000357 D 000100 /053216 172352/004451 172354/004651 XDT>172372/004451 172374/004243 XDT> XDT> Because (alas) I'm running Micro/RSX, I have no sources with which to attack this problem. Would one of you fine gentlemen with a source kit and a healthy interest in things RSX please try to reproduce this and suggest a workaround? I'll support you in any way possible; my work phone is (804) 948-6006. I'd be interested in knowing if this will occur with V4.1 as well. It does NOT occur with a V3.1 system. ================================================================================ Note 236.1 [RSX]Simple SF.SMC crashes Micro/RSX 1 of 5 EISNER::WYANT "Tom Wyant" 9 lines 2-FEB-1989 12:18 -< Adding fuel to the fire ... >- -------------------------------------------------------------------------------- Wish I had a solution - instead of more scope. I was writing up the notes from the Fall 1988 RSX Software clinic, and came across this: "Using QIO with SMC function on another terminal causes hard system crash under M+ V4.0 and 4.1" The response was the inevitable "Submit an SPR". Hope he did, 'cause with M/S V4.5 already out can M+ V4.2 be far behind? ================================================================================ Note 236.2 [RSX]Simple SF.SMC crashes Micro/RSX 2 of 5 EISNER::HUDGINS "Jerry Hudgins" 16 lines 2-FEB-1989 16:49 -< OK, I found a workaround >- -------------------------------------------------------------------------------- ! Wish I had a solution - instead of more scope. I was writing up ! the notes from the Fall 1988 RSX Software clinic, and came ! across this: ! ! "Using QIO with SMC function on another terminal causes hard ! system crash under M+ V4.0 and 4.1" Sounds like this is a known problem (except to me, until now). I've found the workaround that doubtless others already know about, which is to make the calling task privileged (/pr:0). This seems to work just fine. This may well be the answer to my aforementioned Kermit-11 problem, too; I'll have to check it out. I noted, however, that the TKB /PR:0 switch does not set bit TS$IOP in the task header flag word L$BFLG. Is this a documentation error? ================================================================================ Note 236.3 [RSX]Simple SF.SMC crashes Micro/RSX 3 of 5 EISNER::ROBITAILLE "MRobitaille@PaxRv-NES.Arpa" 6 lines 4-FEB-1989 15:32 -< I vote documentation error >- -------------------------------------------------------------------------------- > I noted, however, that the TKB /PR:0 switch does not set bit TS$IOP > in the task header flag word L$BFLG. Is this a documentation error? TS$IOP looks suspiciously like an indicator for mapping to the I/O page - which ought to be missing for /PR:0 and present for just plain vanilla /PR switches. If so, definitely documentation error. ================================================================================ Note 236.4 [RSX]Simple SF.SMC crashes Micro/RSX 4 of 5 EISNER::WYANT "Tom Wyant" 41 lines 8-FEB-1989 09:39 -< Comes the dawn ... >- -------------------------------------------------------------------------------- >>> I've found the workaround that doubtless others already know >>> about, which is to make the calling task privileged (/pr:0). NOW it makes sense! The last time I looked, RSX would NEVER allow SF.SMC against a terminal other than the issuing task's TI:, unless the task was built /PR:something. However, when I was a lad it used to enforce this by returning IE.PRI to the caller. Of course, crashing the system also prevents the SF.SMC from occuring, but sounds a little drastic ... >>> I noted, however, that the TKB /PR:0 switch does not set bit >>> TS$IOP in the task header flag word L$BFLG. Is this a >>> documentation error? As a fellow of my acquaintence said under similarly frustrating circumstances, "It's not wrong, it's just misleading." A little history is in order. Once upon a time, there was no such thing as a T$$IOP bit. In those simpler though not necessarily happier days, INS made the implicit assumption that any /PR:4 or /PR:5 task wanted to have the same mapping as the exec - and that meant APR7 had to map the I/O page. However, it became increasingly apparent that most people wanted to write /PR:5 code not to do direct I/O (which could be done more cleanly by putting a partition in the I/O page anyway), but to map the exec (and pool) and tinker with the things found therein. Some of these tasks were larger than 8KW (...AT. comes to mind), and every time you installed one of the beggars, INS would complain. Eventually, DEC got tired of looking at this message also, and invented the INS /IOP=NO keyword, to say, in effect, "I **KNOW** I'm mapping the I/O page, dammit! Now shaddup and do what you're told!" Shortly thereafter came the /-IP taskbuilder switch, and the T$$IOP bit. So that's the history of the T$$IOP bit. Using the term "Privileged Task" in a way that excludes /PR:0 tasks is, unfortunately, ingrained in the jargon. Perhaps the manual should say "/PR:4 or /PR:5 task does not map I/O page." But the REAL use of the bit is: "TURN OFF THE DAMN MESSAGE." ================================================================================ Note 236.5 [RSX]Simple SF.SMC crashes Micro/RSX 5 of 5 EISNER::HUDGINS "Jerry Hudgins" 4 lines 9-FEB-1989 11:47 -< Ah, now I get it! >- -------------------------------------------------------------------------------- Thanks, Tom, for the historical origins of the TS$IOP flag and how it (doesn't) relate to my observation. I love this sort of lore. That's pretty twisted, isn't it? Good thing people will actually pay us for this stuff.  ================================================================================ Note 237.0 [RSX]5 DHQ11's crash Micro/RSX!!! 3 replies EISNER::HUDGINS "Jerry Hudgins" 31 lines 2-FEB-1989 11:44 -------------------------------------------------------------------------------- Here I am, complaining about crashing Micro/RSX again. This time it's V3.1, and it occurs in an 11/83 with the following devices: RD53/RQDX3 RA81/KDA50 TK50 DHQ11's (5) System autoconfigures properly (according to ACFPAR.DAT) but crashes on the CON ONLINE ALL. Removing 1 DHQ11 solves the problem. Swapping DHQ's shows problem is not in the controller. The SPD for Micro/RSX says nothing about a maximum number of DH-type devices. Am I nevertheless running into a pregen table limit, or something like that? If so, would V4.0 solve my problem? Just in case you want to check my work, the CSR's and vectors are: console 177560/60 DUA 172150/154 TQK50 174500/260 DUB 160334/300 DHQ11-1 160500/310 DHQ11-2 160520/320 DHQ11-3 160540/330 DHQ11-4 160560/340 DHQ11-5 160600/350 All of this is pretty standard. In fact, the system is brand-new from Digital and the configuration therefore has their implicit blessing. This just leaves a software problem. Ideas, guys? I'm sort of in warm water on this one, as I recommended the config. ================================================================================ Note 237.1 [RSX]5 DHQ11's crash Micro/RSX!!! 1 of 3 EISNER::KENNEDY "Terry Kennedy" 0 lines 2-FEB-1989 17:30 -< DEC sold it, let them fix it before paying the bill >- -------------------------------------------------------------------------------- ================================================================================ Note 237.2 [RSX]5 DHQ11's crash Micro/RSX!!! 2 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 8 lines 3-FEB-1989 02:44 -< gens are good for you >- -------------------------------------------------------------------------------- Sorry this doesn't really directly help, but I must say I never really understood MicroRSX. I thought is was about the same price and prevented you from doing what you want (as you seem to have discovered). M+ sysgens are faster than ever, and you get the pieces to tinker with. I suppose if one lacked adequate disk and tape resources a pre-genned system could be handy, otherwise why not simply do your own gens? ================================================================================ Note 237.3 [RSX]5 DHQ11's crash Micro/RSX!!! 3 of 3 EISNER::HUDGINS "Jerry Hudgins" 25 lines 3-FEB-1989 15:55 -< Problem solved, but... >- -------------------------------------------------------------------------------- > Sorry this doesn't really directly help, but I must say I > never really understood MicroRSX. I thought is was about the same price > and prevented you from doing what you want (as you seem to have discovered). Well, I must agree. There's only about $300 difference each in the license and D&D, if you buy the advanced programmer's kit. For an unsophisticated user, however, who can't be expected to do his/her own SYSGEN's, I think it's a good thing. Same can be said of the pre-genned M+. The autoconfiguration, installation, backup, etc. facilities work pretty well. Give the guys some credit. Also, from a marketing standpoint, the base system is a pretty cheap way to get a working platform for layered products. Of course, I hate the thing for my own use, but I'm not responsible for the choice. These are customer systems to which we add software. Now, for the problem at hand: the 5-DHQ crash does NOT occur on Micro/RSX V4.0. This is an acceptable workaround for us. I'm a little miffed, however, that V3.1 went belly-up on this, even though the SPD says nothing about a software limitation in this area. I still suspect that this is a SYSGEN issue, and that the number of allowed DHV/Q's has been expanded for V4.0. True? Jerry  ================================================================================ Note 238.0 [RSX]Device Drivers 101 3 replies EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 82 lines 8-FEB-1989 14:56 -------------------------------------------------------------------------------- Well, here goes again. I am refering to the mistaken info in 109. I got my coworker to write out exactly what his question is - and, man o man, he wrote it *all* out. Here it is, straight from the horse's mouth: "What service does RSX offer for cleaning up a driver after a task exits? The task, in this case, has called upon the driver to create a buffer that functions as pseudo device. The problem occurs when the task exits without deleting the buffer. The driver buffers provide a task-to-task mailbox facility modeled on that of VMS. The mailbox appears as a mounted device on the system, although there is no ACP task. When a mailbox is created, a Window Block is allocated for it, and all subsequent I/O is queued through this structure. The mailboxes are defined as record-oriented devices in the driver UCB, with U.CW1 set to DV.REC. An application opens a mailbox by: 1. assigning an available LUN to the driver 2. issuing a QIO with functions io.acw and io.cre to the driver. An ASCII name for the mailbox is stuffed into QIO parameter block and passed along. 3. posting an application abort AST. The driver, at a Create function following the INI entry, then takes the name off the I/O packet, checks for duplicates, and queues the mailbox name in a linked list of Volume Control Blocks. Space is allocated for the mailbox buffer in an area of pool reserved by the driver. The application can then write (io.wvb) and read (io.rvb), by mailbox name, to other application mailboxes similarly mapped by the driver. In normal operation, the application at some point will close the mailbox with a QIO IO.DAC, using the TCB address from the packet. Alternately, an application abort will trigger the AST with the same result. However, if the application is ill-behaved and exits without closing the mailbox - because of an SST or some errant coding that bypasses the close call - the mailbox space and name become orphaned. When the user restarts the application task, it attempts to open the mailbox under the hard-coded name. The driver checks the name in the QIO DPB against the driver's VCB, finds the name in the list, and rejects the QIO as a duplicate. It appears that this situation should be handled by the driver. In the Cancel IO entry of the driver there is coding that should kill outstanding I/O and delete the mailbox using TCB info that it receives somehow. However, in my test application, cancel I/O is never entered after the application exits or aborts. (I have a macro coded in the driver cancel I/O entry point that writes an ASCII string to the vector address of the console.) Cancel I/O is entered, though, whenever a new mailbox is created. I have no idea what purpose this serves. How does the executive clean up when a task exits? My understand- ing - or misunderstanding - is that at the time of task exit the Executive initiates an I/O rundown using the memory resident copy of the task header LUT. For non-block addressable devices, the second lun word in the LUT, the window block address, is passed to the cancel I/O entry point of the device driver designated by the first lun word in the table. Evidently this is not happening. The driver data base UCB seems correct. U.CTL byte of the UCB is set to UC.QUE!UC.KIL!UC.PWF. The UC.KIL symbol apparently enables entry to CAN:: even when the unit is not busy. Perhaps there are other UCB (or SCB or other) offsets that tell the operating system when to use the entry? Cancel I/O would seem to be a more useful entry when the attached application is exiting - when there might be outstanding I/O and the mailbox buffer might need to be deaccessed and deleted - rather than at the time a mailbox is created, when there is no I/O to cancel and no mailbox to delete. Such are the mysterious workings of RSX." There you have it...the horse's mouth is long-winded but I hope this clears up what he is asking me to answer. I don't remember enough about writing device drivers (or macros) to answer. What do you think, guys? ================================================================================ Note 238.1 [RSX]Device Drivers 101 1 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 4 lines 8-FEB-1989 18:33 -< Have you considered using VSDRV >- -------------------------------------------------------------------------------- This isn't what you asked for, but are you by any chance reinventing the wheel. The VSDRIVER (can't remember which tape the latest is on) might do all you need. Our conpany has used it as the 'guts' for several projects. ================================================================================ Note 238.2 [RSX]Device Drivers 101 2 of 3 EISNER::OSUDAR "John Osudar" 4 lines 9-FEB-1989 17:53 -< (...or at least look at VSDRV cleanup) >- -------------------------------------------------------------------------------- Gee, Barton, thanks for the plug! :-) I was about to suggest that you look at VSDRV to see how it accomplishes cleanup when a task exits. If you don't have a copy, let me know by MAIL and I'll get you a current one, one way or another. ================================================================================ Note 238.3 [RSX]Device Drivers 101 3 of 3 EISNER::ALLEN_C "Charlotte L. Allen (Charly)" 6 lines 10-FEB-1989 11:00 -< Muchy Gratcy >- -------------------------------------------------------------------------------- Thanks, both of you. I absolutely detest reinventing wheels. I will pass this information along. Thershould be, in my mess of tapes, at least one DECUS tape with VSDRV on it. I'll look. Thanx again, Charly  ================================================================================ Note 239.0 [RSX]Letdown about DECnet 10 replies EISNER::SIMONS "Paul, Not that CONVEX!" 11 lines 16-FEB-1989 17:56 -------------------------------------------------------------------------------- I'm depressed. We have an application that sends large buffers of data across PCL-11's. By large I mean around 30,000(8) bytes. Well, we finally have upgraded our operating system (RSX) to M+ 4.1 and now we can use DECnet! We figured we would retrofit our server tasks to use DECnet over the PCL's and thence to Ethernet. On our first try, we got an error message that says our buffer is too big. Hah, we know how to handle that! Our servers were already /PR:0 to get around the address checking the executive does, so we made our test programs /PR:0. DECnet was not amused. Does this mean we have to design a method to split up our buffers and put them together again on the other side?!!? Please, tell me I'm missing something! ================================================================================ Note 239.1 [RSX]Letdown about DECnet 1 of 10 EISNER::RICE "Gary Rice" 8 lines 17-FEB-1989 15:24 -------------------------------------------------------------------------------- > our test programs /PR:0. DECnet was not amused. Does this mean > we have to design a method to split up our buffers and put them together > again on the other side?!!? Please, tell me I'm missing something! Well, yes and no. Have you considered packaging the data as a file and then using NFT (in block mode) to copy the file to the other side? Gary ================================================================================ Note 239.2 [RSX]Letdown about DECnet 2 of 10 EISNER::SIMONS "Paul, Not that CONVEX!" 8 lines 17-FEB-1989 15:57 -< It's like this... >- -------------------------------------------------------------------------------- No, we hadn't. But I think involving a file transfer would be too slow. The situation is as follows: We have redundant PDP 11/70's running a proprietary database manager. The standby database is currently updated using the PCL's. The database is used to control the transmission and generation of electricity throughout Connecticut and western Massachusetts. We cannot afford to have the databases out of sync for more than a few seconds. The database is memory resident for speed. ================================================================================ Note 239.3 [RSX]Letdown about DECnet 3 of 10 EISNER::WYANT "Tom Wyant" 14 lines 17-FEB-1989 16:40 -< More is less ... >- -------------------------------------------------------------------------------- >>> We have an application that sends large buffers of data across >>> PCL-11's. By large I mean around 30,000(8) bytes. ... On our >>> first try, we got an error message that says our buffer is too >>> big. ... Does this mean we have to design a method to split up >>> our buffers and put them together again on the other side?!!? I hate to be discouraging, but the documentation for both SND$ and SNDNT days the maximum buffer size is 8128. bytes. Why it's not 8192 I don't know, but either way it's far short of 30KB. You could TRY setting up DECnet with 30KB LDBs (you might have to use EDT on CETAB.MAC), but I wouldn't want to be anywhere nearby when that net got loaded. I don't know how your code works, but my knee-jerk reaction in this case would be to loop thru the buffer and send it in pieces. ================================================================================ Note 239.4 [RSX]Letdown about DECnet 4 of 10 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 13 lines 17-FEB-1989 17:10 -< Memory DISK? >- -------------------------------------------------------------------------------- > ...running a proprietary database manager. > The database is memory resident for speed. Now if the database looked like a file, and was really on the memory resident FX: disk, you could NFT right into it, or better simply update individual records as they changed. Using a cooperating task on the target end might not even be necessary, as a task on the source end, using RMS (and probably DAPRES), could simply poke in the updates. Do you really need to move ALL that, or simply various changes. It sound as though you are shoving the WHOLE database over. ================================================================================ Note 239.5 [RSX]Letdown about DECnet 5 of 10 EISNER::SIMONS "Paul, Not that CONVEX!" 7 lines 21-FEB-1989 12:44 -< More info >- -------------------------------------------------------------------------------- The database takes up about 1.5 meg of memory, and about 16,000 disk blocks. It is moved over in pieces, called tables. The whole table is moved if one record changes. Most of the tables are under 20,000(8) bytes long. The manager was created long before RMS or DECnet, so the records in memory don't resemble RMS records. (More application detail) Every 20 seconds, a task (called LURK) checks a bit in each entry in the table directory which shows if the table has been modified. ================================================================================ Note 239.6 [RSX]Letdown about DECnet 6 of 10 EISNER::MAYHEW "Bill Mayhew" 19 lines 21-FEB-1989 13:28 -< My two cents >- -------------------------------------------------------------------------------- If most of the tables are under 20000(8) bytes long, then they're under 8192. bytes long (if my mental oct-to-dec converter is working), so you should be very close to OK with DECnet. Sending the thing over in pieces sounds to me like the way to go. Looks like it should never take more than 2 pieces. A trivial plan then would simply be to divide the size of the table in half and put in two calls to transmit a chunk to the other side. This however is not good design, since it will break as soon as one table exceeds 2*8128. bytes. DECnet will make sure the receiving side gets the packets in order, so the change, even to go to a full-blown loop that will work with any size table in any number of parts, should be straightforward. (Of course, monkeying with an existing, working application is *never* straightforward, especially a big app on the -11, but that's another issue!) I think I understand what you're after, and I don't think the suggestion in .4 would help -- you want full redundancy on the two machines, not just access to known-to-be-in-sync databases, right? So if one machine takes a licking, the other keeps on ticking? ================================================================================ Note 239.7 [RSX]Letdown about DECnet 7 of 10 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 8 lines 21-FEB-1989 13:53 -< How much How often? >- -------------------------------------------------------------------------------- >Every 20 seconds, a task (called LURK) checks a bit in each >entry in the table directory which shows if the table has been modified. You didn't say how often LURK (great name!) finds work, or how much is the average. If it is bursty, but you need to be up to date as soon as possible, maybe LURK should run every 10 seconds, especially if you are now going to be using slower transport. ================================================================================ Note 239.8 [RSX]Letdown about DECnet 8 of 10 EISNER::WYANT "Tom Wyant" 28 lines 22-FEB-1989 09:19 -< More ideas from beyond the fringe >- -------------------------------------------------------------------------------- A couple of really off-the-wall thoughts triggered by the FX: driver suggestion: * Can you extend the memory partition a few "disk blocks" on the FRONT? If you use the right INI switches, you can get INI to put all the Files-11 structures ahead of your database. Then create a sequential file with fixed-length records that covers your database. Then, you can use RMD DAP to move things between nodes. This works because a sequential file with fixed-length records HAS no structure. Credit goes to Alan Frisbie for the original idea. * The DECnet kit contains some unsupported utilities, including a network disk driver (called VD:). See [200,200]UNSGEN.CMD (or something like that) for details. You could modify the server task to go against your partition instead of a real disk or file, mount the "disk" foreign, and issue QIO IO.RLBs and IO.WLBs. To clarify: System "A" System "B" +---------------+ +---------------+ | | DECnet | | | VD: driver -------------------> VD server | | ^ | | | | | QIO | | | QIO | | | | | | V | | Your task | | Your partition| | | | | +---------------+ +---------------+ ================================================================================ Note 239.10 [RSX]Letdown about DECnet 10 of 10 EISNER::SIMONS "Paul, Not that CONVEX!" 8 lines 22-MAR-1989 16:35 -< Thanks! >- -------------------------------------------------------------------------------- > A couple of really off-the-wall thoughts triggered by the FX: driver Indeed, if we had the time to get familiar with RMS, DAP, FX:, and the rest, it sounds slick. After some consideration, we've opted for splitting the tables in half and rebiulding them. Dull, but it should work in the shortest time. And thank you for your ideas!  ================================================================================ Note 240.0 [RSX]QIO problem with DECnet terminals No replies EISNER::HUDGINS "Jerry Hudgins" 15 lines 17-FEB-1989 10:06 -------------------------------------------------------------------------------- On Micro/RSX V4.0 w/ DECnet V4.0, I've noticed a problem with reads from a CTERM-type terminal. Don't know if this is an RSX or DECnet issue; however: Attempting to read the typeahead buffer for an RT device with a zero timeout doesn't return immediately, but requires a delimiter. Using IO.RNE!TF.TMO with a timeout of 0 will correctly read the typeahead buffer up to the length requested, but will NOT complete the QIO without a , etc. With considerable piddling around, I was still unable to get it to work. Those of you who use IO.ATA!TF.NOT with the above technique beware; this is how I ran across it. Folks who use zero-timeout to clear the typeahead buffer (instead of SF.SMC with TC.TBF=0) will also be disappointed. I've coded around this, but now I'm curious: anyone have a work-around?  ================================================================================ Note 241.0 [RSX]V4.1 Logical name problem 4 replies EISNER::NORTON "Bill Norton" 16 lines 22-FEB-1989 09:39 -------------------------------------------------------------------------------- Here's one for all you source readers: 1. A logical name is created by a virtual terminal. 2. ASN shows the logical and the terminal, say VT4: 3. When the virtual terminal is eliminated, the results of ASN change over time, eventually altering enough that ASN odd address traps. I'm guessing that the creating terminal reported by ASN is gotten by a pointer to the terminal's UCB in the logical name structure, and that whan the VT is eliminated, the UCB is destroyed, returning to normal unpredictable pool use. Can anyone verify this? ================================================================================ Note 241.1 [RSX]V4.1 Logical name problem 1 of 4 EISNER::WYANT "Tom Wyant" 12 lines 23-FEB-1989 09:42 -< A workaround in the hand ... >- -------------------------------------------------------------------------------- >>> 3. When the virtual terminal is eliminated, the results of ASN >>> change over time, eventually altering enough that ASN odd >>> address traps. >>> I'm guessing that the creating terminal reported by ASN is >>> gotten by a pointer to the terminal's UCB in the logical name >>> structure, No, I haven't read the source yet, but your analysis sounds credible. Are you logging off the VT: before you eliminate it? BYE should clean up the logical name table. You're probably lucky you haven't crashed. ================================================================================ Note 241.2 [RSX]V4.1 Logical name problem 2 of 4 EISNER::NORTON "Bill Norton" 1 line 23-FEB-1989 10:27 -------------------------------------------------------------------------------- It wasn't logging-off the VT before eliminating. I'll try that. ================================================================================ Note 241.3 [RSX]V4.1 Logical name problem 3 of 4 EISNER::NORTON "Bill Norton" 7 lines 24-FEB-1989 09:49 -------------------------------------------------------------------------------- Changed it to logoff the VT before elimination. No difference. Note the logical in question is a *group* logical, so it's supposed to hang around after logoff. You'd think Brian (or someone) would have caught this in development and pointed it at the prototype's UCB. That never goes away. ================================================================================ Note 241.4 [RSX]V4.1 Logical name problem 4 of 4 EISNER::WYANT "Tom Wyant" 10 lines 24-FEB-1989 11:30 -< Group logical s with UCB pointers?!? >- -------------------------------------------------------------------------------- >>> Note the logical in question is a *group* logical, so it's >>> supposed to hang around after logoff. I didn't understand that from the original statement. Sounds like a bug to me ... I don't understand why group logicals need a UCB pointer in the first place. It was a couple releases after their introduction that group event flags finally started working. In this case, if the application will allow it, I would create them from a real terminal. If not, someone is just going to have to read the code.  ================================================================================ Note 242.0 [RSX]M+ V4.1 Crashes 5 replies EISNER::NORTON "Bill Norton" 16 lines 27-FEB-1989 12:16 -------------------------------------------------------------------------------- Does M-Plus V4.1 seem to be any more crash-prone than earlier releases? Several sites we support have been experiencing more crashes than before going from V3B to 4.1. The message is the always-uninformative: Facility 300("Other"), error code 100(Odd address trap). The one dump I've started to look at showed Kernal APRs 5 & 6 pointed at TTDRV, TTEXT, and TTCOM, but since it was a pregenn'd system and the system and driver maps hadn't been saved, I didn't get far. One other thing seemed odd: the kernal stack shown in Stammerjohn's CDA workbook gives different values for R0-5 than CDA's printout. Has something in the stack layout changed, or have I forgotted they aren't supposed to match or something. ================================================================================ Note 242.1 [RSX]M+ V4.1 Crashes 1 of 5 EISNER::AZZOLI 8 lines 27-FEB-1989 19:32 -< Stability of 4.1 >- -------------------------------------------------------------------------------- < Note 120.0 by EISNER::NORTON "Bill Norton" > -< M+ V4.1 Crashes >- > Does M-Plus V4.1 seem to be any more crash-prone than earlier releases? I thought it was fairly stable. The one main difference is that I do not use the pre-generated system due to our hardware configuration while you do. ================================================================================ Note 242.2 [RSX]M+ V4.1 Crashes 2 of 5 EISNER::NORTON "Bill Norton" 3 lines 28-FEB-1989 08:46 -------------------------------------------------------------------------------- We're seeing it both with pregen's and fully-genned systems, it's just that the pregenned one was the first to provide me with a crashdump to look at. ================================================================================ Note 242.3 [RSX]M+ V4.1 Crashes 3 of 5 EISNER::HUDGINS "Jerry Hudgins" 2 lines 28-FEB-1989 17:12 -< Me too, I think >- -------------------------------------------------------------------------------- I believe I've occasionally seen this problem with Micro/RSX V3.1 and V4.0, though I haven't tried to track it down. ================================================================================ Note 242.4 [RSX]M+ V4.1 Crashes 4 of 5 EISNER::NORTON "Bill Norton" 38 lines 18-MAY-1989 13:49 -< Crash resolution >- -------------------------------------------------------------------------------- At long last, I have the reasons behind the increased crash frequency with V4.1 (and V4.0). It seems there are two problems that hit us, both associated with the /hostsync support on DHQ cards. The first one involved the issuance of XON if the card was in DHQ mode. TTDRV would do a MOVB (SP)+,Rn followed by a TSTB (SP)+ *to increment SP to the next even word boundary*. Whoever was maintaining this code must have been pretty green to not know SP is *never* inc'd by just 1. You can avoid that code path by always setting DHQ cards to DHV mode. V4.1 fixed this bug. The second one involves the same thing at at different point. Routine SNDXON in module TTICH doesn't save R4 around the call to CTRD. You end up with a crashdump having a in R4 at the time of the crash. DEACB in TTSUB uses a non-existent IO page address instead of valid TT UCBX pointer. If there are enough devices present that CSR+60 turns out to be valid, the contents of the register at CSR+60 are then used as the address of an AST control block to deallocate, and the real TT UCB doesn't get updated, but some part of exec data space does. The odds on crashing later seem pretty good. I would think the TT whose UCB didn't get updated could also never finish it's current IO or allow new IO to start. A possible workaround is to turn off /hostsync on as many ports as possible, since it won't call SNDXON if it hasn't previously sent an XOFF and it won't do that without /hostsync set. There's a fix for this in V4.2. Actually, analyzing these recent crashes went like a piece of cake for a change; everything on the kernal stack made sense. SO WHY ISN'T THIS SORT OF THING REPORTED IN THE SOFTWARE DISPATCH ANYMORE!? ISN'T THAT WHAT IT'S FOR? ================================================================================ Note 242.5 [RSX]M+ V4.1 Crashes 5 of 5 EISNER::SMITH_PA 12 lines 9-JUN-1989 11:04 -< Terminal response degradation >- -------------------------------------------------------------------------------- We found a pool problem in M+ V4.0 which may not have been fixed in V4.1 Symptom: System terminal response degrades over time. Reason: TTDRV fails to return pool space in some (unknown) circumstances after fork processing. Work around: REBOOT! We submitted an SPR and haven't seen any indication of a fix. (We find V4.x unusable and operate on V3.0 Rev E)  ================================================================================ Note 243.0 [RSX]RSX11S created under VAX/RSX bad! 1 reply EISNER::MERUSI 8 lines 27-FEB-1989 15:35 -------------------------------------------------------------------------------- Doing an RSX11S sysgen, and/or netgen under Version 2.2 of the VAX/RSX package running under Version 4.6of VMS produces an RSX11S system image that crashes. I can take the very same distribution disk (I have everything on an RA60) over to a PDP-11/84, runs the same command procedures for sysgen and netgen, and the system image produces works! This is both a warning and a question ... has anybody else out there experienced this kind of thing. I have never had a problem with VAX/RSX, and have done countless RSX11M and RSX11M+ sysgens and netgens with it. ================================================================================ Note 243.1 [RSX]RSX11S created under VAX/RSX bad! 1 of 1 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 15 lines 27-FEB-1989 21:13 -< RSX-11S crashes can be caused by non-contiguous file >- -------------------------------------------------------------------------------- >> Doing an RSX11S sysgen, and/or netgen under Version 2.2 of the VAX/RSX >> package running under Version 4.6of VMS produces an RSX11S system image that >> crashes. I thought this was supposed to have been fixed, but you might check to see if the .SYS image produced by VMS is contiguous. Early versions would not. If you boot a system image which is not contiguous, you will get the first part, plus some amount of unknown junk -- CRASH! This was doubly bad because VMR did Logical Block I/O to the .SYS file, using the LBN of the the first block of the .SYS file as a base. If the .SYS file was not contiguous, you could wind up writing all over something you didn't want to. If this has not been fixed, you should SPR it.  ================================================================================ Note 244.0 [RSTS]Is RSTS 9.6 the last release? 1 reply EISNER::MACKENZIE 8 lines 9-MAR-1989 01:11 -------------------------------------------------------------------------------- Is 9.6 going to be the last release of RSTS? Some say yes :-) Some say no :-( I hear that DEC has disbanded their RSTS team. Is there any truth to that rumor? Ron MacKenzie ================================================================================ Note 244.1 [RSTS]Is RSTS 9.6 the last release? 1 of 1 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 15 lines 9-MAR-1989 01:32 -< YOU WILL SEE RSX & RSTS DEVELOPMENT FOR AT LEAST 2-3 MORE YEARS >- -------------------------------------------------------------------------------- > Is 9.6 going to be the last release of RSTS? > Some say yes :-) > Some say no :-( As you know field test rules prevent me from speaking about the next version ;-) > I hear that DEC has disbanded their RSTS team. Is there any > truth to that rumor? YES AND NO. Is there a pure RSTS development anymore - NO. Does the group still exist - YES. The RSTS development group is now called something like the Application Timesharing Development Group. They are still very much alive and developing RSTS. They also handle a few VAX products.  ================================================================================ Note 245.0 [RSX]Big IO.WLB to RT: crashes RSX 1 reply EISNER::HUDGINS "Jerry Hudgins" 6 lines 14-MAR-1989 18:49 -------------------------------------------------------------------------------- On Micro/RSX V4.0 with DECnet/RSX V4.0, an associate of mine is able to crash the system by performing a large write to an RTn: (CTERM) device. An IO.WLB with a buffer length of 1840 causes a system fault @122670, facility 300, error code 106. The same task works fine on hard ports and HTn: (RMT) ports. Anyone have a handle on this? (Fixed in V4.1, right???) ================================================================================ Note 245.1 [RSX]Big IO.WLB to RT: crashes RSX 1 of 1 EISNER::WYANT "SOME call me ..... TOM" 43 lines 9-JUN-1989 17:12 -< Known problem. I don't know when/if fixed. >- -------------------------------------------------------------------------------- >>> An IO.WLB [to RTn: - trw] with a buffer length of 1840 causes a >>> system fault @122670, facility 300, error code 106. ... (Fixed >>> in V4.1, right???) Apparantly not in 4.1; maybe 4.2. I have a copy of an SPR (Thanks, Eva!!!) dated 14-Mar-1989 that appears to relate to this. I have quoted the problem description below (except for the example program, which has had a few extraneous lines deleted so as to qualify as a "code fragment"). After upgrading from RSX-11M+ 3.0 to RSX11M+ 4.0/4.1 the attached Program crashes the system with an IOT if it runs on an RT: terminal. No problem on a local or LAT terminal. It seems to be a timing problem, because a Wait between the two QIO's removes the problem. The crash does also not occur, if the bufferlength is reduced to 512. (1024. causes the crash again) It does also not occur, independant of the bufferlength, if the SET Multiple Char is not done before the Write QIO. ************************ Program fragment ************************ .MCALL QIOW$, EXIT$S, DIR$, MRKT$, WTSE$S QIOSSC: QIOW$ SF.SMC,5,1,200,,, ; Set ter nowrap QIOOUT: QIOW$ IO.WLB,5,1,200,,, ; Bild I/O BILBUF: .REPT 256. .ASCII "0123456789abcdefghij" .ENDR TCACR: .BYTE TC.ACR .BYTE 0 STCACR=.-TCACR START: DIR$ #QIOSSC ; SET /WRAP=ti: (START-TI) ; MRKT$S #2,#1,#2 ; Wait a second and the program ; WTSE$S #2 ; does not crash the system any more DIR$ #QIOOUT ; QIO PICTURE . . . *****************************************************************  ================================================================================ Note 246.0 [RSX]Mom, what's an ACD? 1 reply EISNER::SIMONS "Paul, Not that CONVEX!" 17 lines 15-MAR-1989 22:27 -------------------------------------------------------------------------------- Would someone be kind enough to tell me if I understand the difference between ACD's and ACP's ? As I see it, an ACP is used to provide continuity across different devices of the same type. For instance, F11ACP makes all disks into FILES-11 ODS1 structures. An ACD is used to help the terminal driver talk Bocci to water vaporators. Before ACD's, if the protocol was ugly, one would write a big, special driver, a simple driver and ACP, or a simple driver and ugly program. Is this true ? Here's my story. We use AYDIN display generators. We talk to them asynchronously using DL11E's, synchronously using DQ11's, and parallelly (ouch) using DR11C's. Of course, that's one driver per device. The serial devices are 5217's, and the parallel devices are 5215's. Would an ACD be a good fit ? Could I roll all the software into an ACD an let the terminal driver handle the details ? Would I then be able to use LAT and travel around the Ethernet ? And I do believe in the Easter Bunny, so be nice. If ACD's are the way to go, I've got some specific questions. ================================================================================ Note 246.1 [RSX]Mom, what's an ACD? 1 of 1 EISNER::WYANT "SOME call me ..... TOM" 40 lines 16-MAR-1989 15:46 -< I don't know ... go ask your Dad. >- -------------------------------------------------------------------------------- >>> Would someone be kind enough to tell me if I understand the >>> difference between ACD's and ACP's ? ... The usual caveat given here is that TTDRV is not a communications handler. That said, we can go on and talk about what to do to use it as such. I have no direct experience with ACDs (I generally do TT: driver and big ugly program). However: Although they do similar things at the level you described them, an ACD is SIGNIFICANTLY different than an ACP. For instance, an ACP is a task, which intercepts QIOS, breaks them up, re-queues them, and so on. An ACD is not a task, but is more like a unit-specific addition to TTDRV which executes in kernel mode. As I understand things, the ACD never even sees the QIO - all it knows about is certain driver events (like arrival of a character). Unlike an ACP, you can't complete a QIO in an ACD. According to Brian McCarthy, ACDs were invented so FMS wouldn't eat your CPU alive with all the context switches and single-character QIOS. Then FMS didn't re-implement using ACDs. As I recall the story, they wrote 4 ACDs while testing: 1) The null ACD. It did nothing, and was just a sanity check on the implementation. 2) The April Fool ACD. It buffered all output characters until it saw a carriage return, and then spat the buffered characters out again in reverse order. 3) The George Orwell ACD. It routed all characters in both directions to a ring buffer. A task would then empty the ring buffer to another terminal. 4) The Command Line Editor ACD. VMS saw this thing and said "Hey, that's neat! Why don't we do that?" The best reference I know on ACDs is Jim Bostwick. If he's not on DECUServe, you can reach him on DAN::, the RSX Bulletin Board - (612) 777-7664 (autobaud 110 to 1200). The initial login is account ACCOUNT, password REQUEST.  ================================================================================ Note 247.0 [RSX]Looking for help with DLX 1 reply EISNER::MERUSI 11 lines 17-MAR-1989 09:53 -------------------------------------------------------------------------------- I I am looking for information from anyone out there who has had any experience implementing DLX. We thought it would be a nice way to have DECnet up, and at the same time, have a facility for performing very streamlined network I/O for a real-time application we're developing. We have been completely unsuccessful in getting the blasted thing to work. We're using an LAN analyzer, and apparently, there is nothing coming out of the RSX system (we are transmitting a packet to a VAX). Examples from book and from DEC have not worked. Help! ================================================================================ Note 247.1 [RSX]Looking for help with DLX 1 of 1 EISNER::RICE "Gary Rice" 10 lines 17-MAR-1989 10:31 -------------------------------------------------------------------------------- I have been using DLX for several weeks without any trouble. (On a PRO, however). One thing I had to do was change the source code of the sample program (XTS.MAC) to conform to the DECnet address that I wanted to send packets to. With that change made and a new task image built, XTS sends packets like a champ. Gary  ================================================================================ Note 248.0 [RSX]S/A BRU question 4 replies EISNER::NORTON "Bill Norton" 25 lines 21-MAR-1989 16:17 -------------------------------------------------------------------------------- Standalone BRU is acting strange on one of our customers' systems. If you enter /DEV to the 'Enter first device' prompt, you get the column headings but no device data. If you enter DU0:, you get the cursor moving to the start of the next line, but no action until you hit Return again. Then when you enter MS0: to the 'Enter second device' prompt, it comes back with "MCR -- 1". Is this a known behavior of S/A BRU? DEC FS says the hardware's OK. We sent them another S/A BRU floppy which did the same thing, as does their [6,54] version. Things that come to mind are: 1. The 11/23's interrupt chain is broken so CNF can't elicit interrupts. But M-Plus works OK, so interrupts *must* be OK? 2. The console terminal is maladjusted, like maybe having newline enabled or something, so that CNF can't understand the answers. But can CNF be 'dumber' than RSX in that regard? ================================================================================ Note 248.1 [RSX]S/A BRU question 1 of 4 EISNER::MAYHEW "Bill Mayhew" 5 lines 21-MAR-1989 17:26 -< Check console comm settings >- -------------------------------------------------------------------------------- > 2. The console terminal is maladjusted... I have seen behavior like this before, though not on S/A BRU. Check the bits/parity setting on the console... this has bitten me more than once! ================================================================================ Note 248.2 [RSX]S/A BRU question 2 of 4 EISNER::HAHN "DECUServe Vice Chair" 1 line 22-MAR-1989 12:05 -< LA36 has problems as console >- -------------------------------------------------------------------------------- ================================================================================ Note 248.3 [RSX]S/A BRU question 3 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 4 lines 22-MAR-1989 15:25 -< LA36s work for us >- -------------------------------------------------------------------------------- >> -< LA36 has problems as console >- We use an LA36, and have NO problems. We have customers with nothing but LA36s on rooms full of 11s. What do you see happening? ================================================================================ Note 248.4 [RSX]S/A BRU question 4 of 4 EISNER::NORTON "Bill Norton" 3 lines 27-MAR-1989 09:21 -< original problem solved >- -------------------------------------------------------------------------------- The problem we were seeing was fixed by attaching a VT220 (for easy setup visibility) and removing the newline characteristic and adding 8-bit character characteristic.  ================================================================================ Note 249.0 [RSX]LN01's anyone ? No replies EISNER::SIMONS "Paul, Not that CONVEX!" 5 lines 22-MAR-1989 16:17 -------------------------------------------------------------------------------- We have the opportunity of acquiring an LN01S-LH for next-to-nothing. It uses a serial interface. Has anyone out there in RSX land used one of these ? How's the reliability/maintainability ? Can I hang it off a DZ ? How would I spool it ? Better yet, can I convert it back to a LN01S and run it off an LP11 ?  ================================================================================ Note 250.0 [RSTS]XMODEM for RSTS 1 reply EISNER::HAHN "DECUServe Vice Chair" 1 line 14-APR-1989 11:43 -------------------------------------------------------------------------------- Is there such a software to use XMODEM on RSTS ?? ================================================================================ Note 250.1 [RSTS]XMODEM for RSTS 1 of 1 EISNER::KENNEDY "Terry Kennedy" 7 lines 14-APR-1989 19:31 -< Yes >- -------------------------------------------------------------------------------- > Is there such a software to use XMODEM on RSTS ?? Yes - a pair of *real* short BASIC programs are available to do 'original' XMODEM (128-byte blocks, checksum) are available. They should be somewhere on the Newsletter BBS (201) 915-9361. Look for MODEMR.BAS and MODEMS.BAS. Send Mail here if you need them and can't find them there...  ================================================================================ Note 251.0 [RT11]TSX problem? 1 reply EISNER::CAMPBELL 8 lines 29-APR-1989 19:21 -------------------------------------------------------------------------------- One of my customers has a TSX-Plus system (V6.3) with 8 LS: flavored spooled printers. Periodically one or another of the printers will start producing reams of garbage, with the immediate need to turn the thing off. It never recovers. The only fix appears to be rebooting TSX, which is a pain. At first I thought this was a data overrun (i.e. a missed XOFF from the printer) but it does not recover even when the spooler queue eventually empties. Any ideas? ================================================================================ Note 251.1 [RT11]TSX problem? 1 of 1 EISNER::CAMPBELL 7 lines 18-MAY-1989 10:41 -< More data >- -------------------------------------------------------------------------------- At the TSX-Plus Magic session at the recent symposium, 2 or 3 other people reported similar problems. At least one thinks it was "fixed" by using CL: lines instead of LS:. One of the other sites had the problem with LP:, which tends to rule out data overrun. None of the other sites had as many printers (2 was the max) so the number of printers is probably not the base problem, although it may cause it to appear more often.  ================================================================================ Note 252.0 [RT11]TSX problem with VTCOM No replies EISNER::CAMPBELL 5 lines 29-APR-1989 19:23 -------------------------------------------------------------------------------- When I upgraded from TSX+ V6.2 to V6.4, VTCOM started letting confused escape sequences through to the terminal. I am pretty sure this is a version compatibility problem, and further that it is discussed in the TSX documentation, but I can't find it. Anybody know where it is?  ================================================================================ Note 253.0 [RSX]Old RSX/DECNET HT: device HELP! 2 replies EISNER::MCGRATH "Kevin McGrath" 6 lines 4-MAY-1989 12:56 -------------------------------------------------------------------------------- I've recently started up DECNET on my Micro PDP-11/23+ running RSX-11M-Plus V2.1 and I don't know how to set up the HT: device to think it is a VT type terminal. I don't have any documentation for RSX DECNET as my OEM never sent any when they installed my system and I'm also wondering if I purchase the current documentation set if it would be any help. Any info would be appreciated. ================================================================================ Note 253.1 [RSX]Old RSX/DECNET HT: device HELP! 1 of 2 EISNER::WYANT "SOME call me ..... TOM" 50 lines 5-MAY-1989 15:58 -< It's just like TT: - if you ignore the bugs >- -------------------------------------------------------------------------------- >>> I've recently started up DECNET on my Micro PDP-11/23+ running >>> RSX-11M-Plus V2.1 and I don't know how to set up the HT: device >>> to think it is a VT type terminal. I don't think the doc set will help you in this case (the section on RMT in the M+ V4.0 manual is a mind-boggling six pages long). Having the docs is still a good idea, though you'll have a tough time buying DECnet-M+ 2.1 documentation in 1989. Normally, the device characteristics are propagated forward through the RMT session, so whatever you were on the local system you will be also on the remote system. Normally, the standard SET commands also work, just as they did on the TT: driver; except for the "H" instead of "T" as the first letter of the device name (and fourth letter of task name), no difference. Note the repetition of the word "normally". The HT: driver is not without its problems. I remember a release (and I believe it was M+ V2.1) that didn't really know what a VT2xx was - if you were a VT2xx on the local system, or if you SET /VT2XX=TI: on the remote system, it thought you were a hardcopy terminal (a real pain in EDT) - though if you did DEV TI:, it told you you were a VT2xx. As I recall, the workaround was to SET /VT100=TI:. This has minor consequences in EDT (the VT100 doesn't have line-editing), but was an acceptable workaround. You can have SYSLOGIN.CMD do something like .TESTDEVICE TI: .SETS S$DRVR [1:2] .IF S$DRVR = "HT" .IF = n SET /VT100=TI: where the "n" is whatever number represents a VT220. I don't have the number handy, but you can determine it by logging on a VT220 and then doing >@TI: AT.>.ENABLE SUBSTITUTION AT.>;'' AT.>^Z I wound up writing a .CMD file to simulate SET TERMINAL/INQUIRE and imbedded the HT: check in it. I can MAIL you a copy if you're interested (moderator: is there a law against MAILing code? I know there's one against posting it, but I submit that the above are fragments for illustrative purposes only). It'll have to be after the symposium. Tom Wyant ================================================================================ Note 253.2 [RSX]Old RSX/DECNET HT: device HELP! 2 of 2 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 28 lines 5-MAY-1989 17:35 -< upgrade desirable, both H/W + S/W >- -------------------------------------------------------------------------------- > I've recently started up DECNET on my Micro PDP-11/23+ running > RSX-11M-Plus V2.1 This goes beyond the scope of what you asked for, but... If you started DECNET, I assume you want to talk to something else. A VAX? If so look at 100.* here, and probably DEC_NETWORKING 140.* Whatever your application is, if you can upgrade to an I/D machine (53,73,83) class machine, and get an I/D sysgen also supporting sup mode libraries, you should be MUCH happier. A newer version of M+ will also support LAT, which might be of interest. 2.1 is getting pretty old. Even NEW, the dual (OEM model) 73 card isn't very expensive, but you have boot card and possibly other support issues. The other I/D cards will all cost more. There is an official upgrade path to the better CPUs that should be easy from a PDP-11/23+, but it might be a lot more expensive than some more creative solution. Will your OEM get you a newer (and I/D) version on M+ at an attractive price, or are you in one of those delicate 'we don't talk to them anymore' situations? Heck, buy the S/W upgrade from DEC, and have fun yourself. You will get LAT support, NAMED dirs, extended logical names, disk caching (now with deferred write on TMP files), and much more. Any nonPRIV application stuff will still work in the new system.  ================================================================================ Note 254.0 [RSX]Need Dungeon sources... 1 reply EISNER::PERRY 5 lines 17-MAY-1989 17:30 -------------------------------------------------------------------------------- Anyone have the sources to DUNGEON for RSX ? I have a client who wants it. I would pay all shipping expenses for a copy on tape (which I would send you with return postage). ================================================================================ Note 254.1 [RSX]Need Dungeon sources... 1 of 1 EISNER::VANMATRE 13 lines 18-SEP-1989 16:03 -< Sources Found >- -------------------------------------------------------------------------------- < Note 128.0 by EISNER::PERRY > -< Need Dungeon sources... >- Anyone have the sources to DUNGEON for RSX ? I have a client who wants it. I would pay all shipping expenses for a copy on tape (which I would send you with return postage). H It's a long time from when you posted the source request. I have a copy. My name is Ethan VanMatre and if you still need it call . (206) 699-5760.  ================================================================================ Note 255.0 [RT11]Separate I & D No replies EISNER::CAMPBELL 16 lines 18-MAY-1989 10:46 -------------------------------------------------------------------------------- I have been contemplating how to use separate I/D space in TSX-Plus (and eventually RT-11). I decided to limit my initial investigations to FORTRAN-77/RT. Anyone else given any thought to how to take advantage of it now that TSX-Plus sort of supports it? Ideas: 1. Put the OTS into I-space, which means that you need a large D-space region in "parallel". 2. Try to LINK a program. The general method would be to make a program that preprocesses .OBJ files before feeding them to LINK. This program would separate the PSECTs into I and D groups, so that separate runs of LINK could be used to build individual I and D images. Presumably, a fair amount of "glue" would be necessary to hook them back together.  ================================================================================ Note 256.0 [RSX]Micro/RSX to be retired? 1 reply EISNER::HUDGINS "Jerry Hudgins" 6 lines 22-MAY-1989 12:00 -------------------------------------------------------------------------------- I've heard a (totally unsubstantiated) rumor that Digital plans to discontinue Micro/RSX in favor of full M+ in the same fashion that Micro/VMS was discontinued. Can anyone comment on this one way or the other? If you prefer anonymity, reply to HUDGINS via MAIL. (Well, relative anonymity; I'll keep any such replies confidential.) ================================================================================ Note 256.1 [RSX]Micro/RSX to be retired? 1 of 1 EISNER::MAYHEW "Bill Mayhew" 3 lines 22-MAY-1989 19:24 -< Not yet, if ever >- -------------------------------------------------------------------------------- I have not heard the rumor, but MicroRSX V4.2 was just announced, so it ain't happened yet. The announcement carried no information about any possible retirement.  ================================================================================ Note 257.0 [RSTS]9.6 on 11/23+ 4 replies EISNER::DAILY "Scott Daily" 17 lines 23-MAY-1989 17:12 -------------------------------------------------------------------------------- My firm inherited a PDP-11/23 PLUS with 2 DZV11's, an RL02, and a disk subsystem consisting of an Emulex SC02/BX with a CDC7930-160 emulatting 2 RM02's. It arrived with RSTS V8.0-06 on it and boots up fine. When I boot V9.6 from the RL02 all appears ok until I actually want to start timesharing, and the system halts (apparently while trying to load the SIL). In talking to the friendly folks at Emulex they informed me that a patch was issued for the 8.0 INIT.SYS to support the RH70 lookalike controller but there was no need for that for V9 since 'big disks' were supported. I've tried everthing I can think of to get 9.6 to at least load. All rev levels on all hardware is up to snuff -- all patches in INIT.SYS & all SIL's (both mine and SYSGEN) but still no luck. What stumps me is that the system runs 8.0 but not 9.6... Anyone have any ideas??? ================================================================================ Note 257.1 [RSTS]9.6 on 11/23+ 1 of 4 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 27 lines 23-MAY-1989 18:11 -< IT WORKS AND SOME QUESTIONS >- -------------------------------------------------------------------------------- > My firm inherited a PDP-11/23 PLUS with 2 DZV11's, an RL02, and > a disk subsystem consisting of an Emulex SC02/BX with a CDC7930-160 > emulatting 2 RM02's. It arrived with RSTS V8.0-06 on it and boots up fine. First I assume you mean a SC03/BX - the SC02 emulates RP11,RL,RK06/7 disks. I also assume it is a CDC 9730-160 MMD 14 inch disk drive. What firmware level are you running on the SC03 and have you confirmed with Emulex it is the latest firmware? I also assume you have the 22 bit addressing chip installed in the SC03 with the 22-bit switch enabled. I am running an 11/73 with an RL02 and a SC03/CDC9730-80 under 9.6 with no problem. ***HOWEVER*** when we upgraded several of our 11/23's running V8 to 11/73's running V9 we needed to upgrade the SC03 firmware to keep the systems from crashing. > the SIL). In talking to the friendly folks at Emulex they informed me that > a patch was issued for the 8.0 INIT.SYS to support the RH70 lookalike > controller but there was no need for that for V9 since 'big disks' were > supported. The V8 patch was to make sure RSTS would use the RM controller BAE register on a Q-BUS machine. RSTS development fix it under V9 so RSTS would allow RM disks on the Q-BUS. ================================================================================ Note 257.2 [RSTS]9.6 on 11/23+ 2 of 4 EISNER::DAILY "Scott Daily" 23 lines 24-MAY-1989 12:54 -< OOPS... >- -------------------------------------------------------------------------------- Well, the secret is out... I never learned how to type.. Yes it is a 9730 and an SC03/BX. Everything according to Emulex is at current rev levels and the board is set up properly (ie RH70 vs RH11, etc). At current I have the bus unpopulated except for the SC03, the CPU and memory. I COPYied the RL02 to one of the 'logical' RM02's and booted (to OPTION) succesfully. When trying to start the SYSGEN SIL the console halts at 120240. Emulex suggested that since the RL02 with V9.6 on it came from one of our 11/70's that I needed to do a sysgen on the 11/23+ since "RSTS builds itself for the specific type of CPU" (????). I was careful not to use any of the I&D tasks when building the RL02 since the 23+ doesn't do I&D. It still appears that the SIL can't start running. Are there other things I should be looking for? I've got all appicable RTS files out there (I thought it might be a DCL problem...) I also assume that if a file or RTS or other such thing was missing that INIT.SYS would object and go back to Option. My next thing to try is to cut the head off a live chicken and sprinkle its blood over the CPU while chanting the Kama Sutra. Any other ideas? ================================================================================ Note 257.3 [RSTS]9.6 on 11/23+ 3 of 4 EISNER::KENNEDY "Terry Kennedy" 21 lines 24-MAY-1989 21:11 -< More things to try >- -------------------------------------------------------------------------------- Pardon my lack of quoting your text - I'm on a defective laptop today... 1) RSTS and CPU type: pure bunk - proves that they have *no* understanding of RSTS (but, we knew that already). Even trying a disk build for I/D sup- port will only give '?Missing special feature' when you try MAC, TKB, etc. The monitor will use I/D if present, but will ignore it if not. 2) Firmware rev's - if you're brave, pull out the board(s) and copy down the info on the ROM stickers - I don't have any Emulex disk stuff but maybe Jeff can help. I wouldn't belive Emulex when they say you're up to rev... 3) Try this: At Option say HA LI and post the response here. Also, do a DEFALT, when it says any memory allocation table changes', say yes. At the table suboption prompt say reset. Try again. 4) Do you get the halt before the date/time output (after you start)? Let me try that again: after you say yes to start timesharing, does the date/time print out and then you halt or do you halt without the date/time display? 5) Last thing - try saying START instead of just CR at the start time- sharing prompt. Let me know if that says anything funny. ================================================================================ Note 257.4 [RSTS]9.6 on 11/23+ 4 of 4 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 0 lines 25-MAY-1989 16:40 -< TRY LOCKING OUT MEMORY ABOVE 124KW >- --------------------------------------------------------------------------------  ================================================================================ Note 258.0 [RSTS]But can I hang a terminal off it? 2 replies EISNER::DEMOSS "VMS on $5 a day" 13 lines 25-MAY-1989 18:57 -------------------------------------------------------------------------------- The other night my 11/44 had an unscheduled (weather-related) shutdown; when I brought RSTS (9.6) back up, all my keyboard numbers had increased by one! SHOW DEVICES listed a new terminal, KBA1 (KL0), at the CSR formerly occupied by DD0, which was now missing. I called out DEC field service, who "fixed" it by disabling KL0. Now my keyboard numbers are correct (I coulda done THAT!), but I'd still like to know what happened. Any thoughts? ================================================================================ Note 258.1 [RSTS]But can I hang a terminal off it? 1 of 2 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 10 lines 25-MAY-1989 19:10 -< YOU ARE NOT ALONE >- -------------------------------------------------------------------------------- > The other night my 11/44 had an unscheduled (weather-related) shutdown; > when I brought RSTS (9.6) back up, all my keyboard numbers had increased > by one! Over the weekend we had one of our 11/44 crash due to power. For some unknown reason we had the net effect of a HARDWARD RESET at the option level. This might be what happen to you. Also MAKE SURE DEC did not leave the maintenace jumper in DD0 (KL1) - it will cost you 25 percent of your CPU. ================================================================================ Note 258.2 [RSTS]But can I hang a terminal off it? 2 of 2 EISNER::KENNEDY "Terry Kennedy" 17 lines 26-MAY-1989 17:47 -< Your DECtape is dead >- -------------------------------------------------------------------------------- > But can I hang a terminal off it? Yes - read on... > SHOW DEVICES listed a new terminal, KBA1 (KL0), at the CSR formerly > occupied by DD0, which was now missing. This is a common problem in the 11/44 system unit (11X44 model variants). These systems have a dual DECtape II (TU58) on the second DL11 emulator in the CPU. Although TU58 support was dropped as of V8.0, INIT.SYS still checks all DL lines for TU58's. If it finds one, you get DDX, if not, you get KBAx. Your TU58 has either died or become 'wedged' from the power failure. If you power off, wait a few minutes, and power back on and you still don't have a DD0:, it's gone for good. You can change the connector and put a terminal on the port, but it is subject to all the restrictions noted in the SPD about DL11's - upper speed limit 1200, etc.  ================================================================================ Note 259.0 [RSX]Where's that DQDRV ? No replies EISNER::SIMONS "Paul, Not that CONVEX!" 13 lines 26-MAY-1989 09:55 -------------------------------------------------------------------------------- I find myself with an interesting problem. We used to run M 3.1. Then we saw the light and converted to M+ 4.1. Several devices suddenly found themselves without support. We managed to shake everything down and get up and running; except for one device. It is known as a DQ-11. The DQDRV undef M+ is for some sort of disk. The DQ is still supported under M 4.5. We need the latest version of the driver because, believe it or not, we are expanding our use of this device and need some additional features. Digital officially says that we have to buy the H kit for M if we want the driver. They're also the ones who said it would be easy to upgrade. Does anyone, preferably someone near Connecticut, have a copy of DQDRV under M? My DECrep is working on finding someone, but he's in floating point emulation mode.  ================================================================================ Note 260.0 [PRO300]PROporri No replies EISNER::RICE "Gary Rice" 97 lines 5-JUN-1989 07:19 -------------------------------------------------------------------------------- I received a letter from an avid PRO user this week. I have excerpted pieces of it and am posting those pieces here. There are MANY questions being posed. Please respond to any or many of them. Gary Is there any documentation on how to allocate more space for a PRO/SIGHT V1.0 work file? When an existing picture contains more objects than fit in the assigned buffer, only the last objects created can be selected as a group for edit! This restriction makes changes to a complex picture nearly impossible. Is a driver for any HP hard copy devices (laser, desk jet, color jet .etc) available to print/translate PRO/Sight .gid files? P/OS V3.0 cannot print SIGHT V1.0 .gid files properly on a DEC LN03 nor LA75 printers. An LA50 hard copy does not provide adequate picture quality. Public Domain SYM-4 software update applies "only to P/OS V3.1". Is there any help for a PRO owner stuck at P/OS V3.0? Is any part of the V3.1 software update distributed at the Spring '87 symposium adaptable to P/OS 3.000? Can the PRO Document VDM interpreter be applied to create a P/OS gidis+text file that is transportable to another DEC system for quality printing? When PRO/INSTL & MAINT V3.0 is updated on hard disk with PRO/TMS COMM TEST SERV V1.2, runtime errors and/or a program crash results. TMS is inhibited from normal operation until P/OS V3.0 is re-booted. TMS tests run properly from floppy with Maintenance-P/OS V2 but not V3.0. The reason for concern is a quick TMS verification run before going on line with a data base that charges by the minute! Also need definition of a "loop back" to include the cable up to the phone jack in a self test. It would seem reasonable that DEC should make the source code for maintenance software available so that PRO-TMS owners could update it to more current operating systems. Hardware theory of operation with component level documentation is necessary for self maintenance and to establish a better basis for software development. TMS has been "retired" but it should not be put to death before its useful life expires! Have all the source files for a spelling checker by Jef Hamilton (F85 DECUS) but have not been able to build task images that run under P/OS V3.0 even though all build errors have been "fixed". Is a cookbook available on how to convert from FCS to P/OS - PROF77 support? Has anyone been succesful in altering this spell checker application for P/OS? Has a converted version with source and build.cmd files been submitted to your library? Is the F-88 spell checker for RSX and RT-11 (directory [373,211]) a better program? Is it available from your library? Are source, documentation, and build files included? I are an engenier, and badly need any Computer Adided Communication help I can get. Now have four different task images of Glen Everhart's PortaCalc/AnalytiCalc running on P/OS V3.0, but none support optional keypad.cmd files. It is rather intimidating to wade through the vast amount of operating system specific information Mr. Everhard published, and try to sort out what portion applies to these four task images. I've been able to perform basic spreadsheet tasks, but have only trial and error means to define what capabilities the different .tsk images support. Would like a compatible database application from which AnalytiCalc can import data, but if keypad commands are not functional, import from foreign data files does not seem likely. Has anyone collected all the necessary F77 compatible source files, and devised a means to build AnalytiCalc from scratch, with all the bells and whistles, on a PRO3xx system? Maybe Glen Everhard would submit PRO specific source and build instructions to your Public Domain library! Maybe he also has modified, or created, a compatible database package to work on PRO's. I'm sure he would enjoy seeing a DECUS Newsletter announcment of his support for the PRO3xx in active retirement. Current DECUS library version of Portacalc/Analyticalc does not indicate P/OS is supported!??! Believe someone developed a means to run RT-11 from a P/OS hard disk. Do you have this tool in your library or do you know someone who uses it and is willing to part with a copy? I have RT-11 V5.1c and P/OS V3.0, PRO Communications V3.0, RT Basic & Fortran, P/OS Pascal V1.2 & Fortran V5.0, and PRO tool kit V3.0 delivered with a PC380 I bought recently. Have built some P/OS applications (at least Bonner Runoff works) and read enough of the Tool Kit manuals to be rather dangerous. Presently, have no experience with RT-11, but would like to switch-hit between the two operating systems, and learn enough to adapt DECUS RT-11 programs to the PRO3xx Public Domain. Maybe RT-11 is the best long term means to support a retired PRO3xx? Any cookbook available to give a non-computer-scientist some basic hints on program conversion between RT11 and P/OS? P/OS 3.0 supports multiple hard disks. Can P/OS be booted from one disk while RT-11 is bootable from another? Does anyone sell a hard disk interface card, a cable, and external disk box & power supply at a reasonable price? Has anyone documented PRO3xx external disk cable/connector requirements so one can use readily available non-DEC parts? Here are some additional Public Domain wish list items: Complete sources of Bonner Lab RUNOFF from RSX SIG Fall 1987 [332,12]. Believe this is the latest update version. Collection of the latest and greatest of DECUS C language system with full P/OS and/or RT-11 support. Kermit-11 updates and Kermit source for other operating systems that support the advanced features incorporated in Kermit-11 by Brian Nelson. An EDT clone that runs on RT-11  ================================================================================ Note 261.0 [RT11]Writing RT-11 tapes on VMS No replies EISNER::CROWELL "Shefth of the Fourth Order" 32 lines 14-JUN-1989 13:29 -------------------------------------------------------------------------------- I've finally found a way to write VMS files to magtape on VMS so that they can be read on RT-11. Maybe some of you already do this, but it was a revelation to me. Encapsulate the files in a logical disk! 1. With EXCHANGE, create a logical disk file with a legitimate RT-11 file name. 2. With EXHCNAGE copy the files you want moved to RT-11 into the logical disk. Let EXHCNAGE take care of converting ASCII and OBJ files to proper formats. 3. Initialize the magtape normally. 4. Mount the magtape with /BLOCKSIZE=512/NOHDR3. 5. Copy the logical disk file to the magtape. 6. Now the logical disk file (a nice image file) can be read by RT-11 and copied to an RT-11 disk and mounted as an LD unit. 7. The files in the LD unit can be used normally. This is as close as I've ever come to making an RT-11 magtape from VMS. Reading RT-11 magtapes with EXCHANGE works too, with a wrinkle. If the magtape was written by RT-11 before Version 5.5, file names are padded with spaces, so that VMS interprets ABC.DEF as "ABC .DEF".; and EXCHANGE doesn't know what to do. Version 5.5 FSM fixes this so that there are no embedded spaces in the file name.  ================================================================================ Note 262.0 [RSX]BRU, File Error -10 12 replies EISNER::SMITH_PA "Paul Smith" 21 lines 26-JUN-1989 22:25 -------------------------------------------------------------------------------- I have had problems with BRUing to a mounted disc: MCR>BRU /NOINI/MOU/UFD/VER DU0: DU1: I get: File Error -10, File Id n,m and the BRU continues. The File ID bears no obvious relationship to the actual file that has problems. A file is however, trashed at the destination and appears to have a valid header, but no data (just previous sector contents). I recently BRUed 13255 files and had 16 bad transfers. I run a binary compare to find the actual dead files. Fortunately, one of the dead files was our main .OLB and so nothing compiled - real obvious - but some little-used source files could have gone unnoticed. The DEC DSIN bulletin board lists this problem, and gives no solution. Does anybody know if it is fixed? Has anybody found a workaround? ================================================================================ Note 262.1 [RSX]BRU, File Error -10 1 of 12 EISNER::SMITH_PA "Paul Smith" 16 lines 2-JUL-1989 22:10 -< More pleas, please. >- -------------------------------------------------------------------------------- > -< BRU, File Error -10 >- >I have had problems with BRUing to a mounted disc: >... >Does anybody know if it is fixed? Has anybody found a workaround? Do to the underwhelming response, I thought I would broaden the question. Has anybody else had this problem? Does anybody care? Is there anybody still using RSX? Does anybody still use BRU? ================================================================================ Note 262.2 [RSX]BRU, File Error -10 2 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 21 lines 3-JUL-1989 04:29 -------------------------------------------------------------------------------- >Do to the underwhelming response, I thought I would broaden the question. OK! I'll clutter up with a not very helpful answer... > Has anybody else had this problem? Not specifically, but BRU reporting the wrong FILE rings a very OLD bell. > Does anybody care? yes > Is there anybody still using RSX? M+ > Does anybody still use BRU? of course, and actually like it (at last). Still have a long wish list for improvements to it, but I know better than to waste time asking again for them. ================================================================================ Note 262.3 [RSX]BRU, File Error -10 3 of 12 EISNER::WYANT "SOME call me ..... TOM" 45 lines 11-JUL-1989 16:30 -< A stab in the dark >- -------------------------------------------------------------------------------- < Note 131.1 by EISNER::SMITH_PA "Paul Smith" > -< More pleas, please. >- >>> -< BRU, File Error -10 >- >>>I have had problems with BRUing to a mounted disc: >>>... >>>Does anybody know if it is fixed? Has anybody found a workaround? >>>Do to the underwhelming response, I thought I would broaden the question. >>> Has anybody else had this problem? It depends. I had something very like it under RSX-11M+ V2.0. What version of RSX are you using? The problem occurred on multiheader files, and then only under restricted circumstances. As I recall, it was another case of BRU trying to sort retrieval pointers and getting totally lost. -10 is "End-of-file detected" if my RSX-11M V3.1 Pocket Reference is still good, and as I recall my problem I was getting EOF reported on the OUTPUT volume, even though that's not where the problems were. Do the file IDs make sense if applied to the INPUT volume? As I recall, the workaround applied at the time was to go back and do the individual files one at a time. I haven't seen this problem lately, though. If you're an "old" RSX site, try obtaining a more recent BRU.TSK. >>> Does anybody care? Sure. But we can't always check the bulletin board as often as we'd like. >>> Is there anybody still using RSX? Sure. You gotta use SOME system to get the work done, and the VAXen are all busy running MAIL. >>> Does anybody still use BRU? It's my favorite backup utility - I've learned more about FILES-11 ODS-1 from fixing BRU's screw-ups than from any other single cause. ================================================================================ Note 262.4 [RSX]BRU, File Error -10 4 of 12 EISNER::SMITH_PA "Paul Smith" 49 lines 17-JUL-1989 22:41 -< Extension Header the culprit >- -------------------------------------------------------------------------------- >< Note 131.3 by EISNER::WYANT "SOME call me ..... TOM" > >>>> -< BRU, File Error -10 >- > What version of RSX are you using? RSX11M+, V2.1E and V3.0E. Both do it "at times". Refer to an earlier resonse as to why we do not use V4.n > The problem occurred on multiheader files, and then only under > restricted circumstances. As I recall, it was another case of > BRU trying to sort retrieval pointers and getting totally lost. > -10 is "End-of-file detected" if my RSX-11M V3.1 Pocket > Reference is still good, and as I recall my problem I was > getting EOF reported on the OUTPUT volume, even though that's > not where the problems were. Do the file IDs make sense if > applied to the INPUT volume? According to DSIN, it occurs when BRU's internal table of File IDs gets confused by something called the "extension header" (What is one of those?) occurring at the end of the table. What happens is that it then uses the file ID of some other element in the table (not clear which one) and tries to extend it. That file is of course already closed and returns a -10 (EOF). It is a file ID on the output volume. > As I recall, the workaround applied at the time was to go back > and do the individual files one at a time. This works because now there is no table of IDs to get lost in. BRU'ing the individual bad files again (from the good copy) works. Most of the bad files in my last exercise in frustration were .OLB or .OBJ. > It's my favorite backup utility - I've learned more about > FILES-11 ODS-1 from fixing BRU's screw-ups than from any other > single cause. The following questions about FILES-11 ODS-1 now spring to mind:-- 1) What is an "Extension Header"? 2) How can I find files that have them? (So I could BRU them individually) 3) How can I avoid creating files that have them? 4) Can I restructure an existing file that has one into one that doesn't? ================================================================================ Note 262.5 [RSX]BRU, File Error -10 5 of 12 EISNER::RICE "Gary Rice" 38 lines 18-JUL-1989 11:00 -------------------------------------------------------------------------------- > 1) What is an "Extension Header"? When a file is created and then extended (for whatever reason), the original file header that was created to "map" the file has room for only a finite number of pointers to the disk blocks that make up the file. I forget the number but it is not a large one. When you need more pointers than can be provided in the original file header, the system builds an "extension" header and links it to the original header. This process can be repeated a total of 255 times (I think) per file giving you the ability to create VERY large files. > 2) How can I find files that have them? > (So I could BRU them individually) Look for a copy of SRD (from the RSX SIG tapes) later than 1984. SRD has a switch that lets you specify ONLY multi-header files > 3) How can I avoid creating files that have them? Pre-allocate space in ALL file creation activities. That is, open the file with an initial size as big as the file will ever be. Please note that if the file is VERY big (I think that the number is approximately 26,000 disk blocks), you will have a multi-header file no matter what you do. Also, request that the file be contiguous, assuming that you have that much contiguous space available. > 4) Can I restructure an existing file that has one into one > that doesn't? Yes. Gererally, FCS (and RMS) will compact the number of pointers (by compacting the location of the disk blocks it uses to store the file on) whenever the file is copied. Also, if you request that a file copy activity creates a contiguous copy, that will do it by default. Again, if the file is larger than the magic number (Alan, help me here, I don't remember the exact value), no amount of copying will get rid of the extension header(s). Gary ================================================================================ Note 262.6 [RSX]BRU, File Error -10 6 of 12 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 38 lines 18-JUL-1989 14:02 -< A long answer to a short question (26,112) >- -------------------------------------------------------------------------------- >> Generally, FCS (and RMS) will compact the number of pointers >> (by compacting the location of the disk blocks it uses to store >> the file on) whenever the file is copied. Also, if you request >> that a file copy activity creates a contiguous copy, that will >> do it by default. When you copy a file (usually via PIP or BRU), FCS and RMS don't get involved at all. Both PIP and BRU do block copies, while FCS & RMS are for record access. It is F11ACP that handles the Retrieval Pointers that map chunks of your file to chunks of disk space. If your disk is very fragmented, the output file will be fragmented unless you request that the output file be contiguous (PIP only). >> Again, if the file is larger than the magic number (Alan, >> help me here, I don't remember the exact value), no amount of >> copying will get rid of the extension header(s). A file header has room for 102 retrieval pointers, each of which will map up to 256 contiguous blocks. Therefore, a single file header can map from 102 1-block chunks up to 102 256-block chunks. If your file is larger than 102*256 blocks long, it will require an extension header. So, the magic number is 26,112. *HOWEVER*, when you open your file, F11ACP reads the file header(s) to produce an in-memory set of retrieval pointers. These in-memory pointers use a 16-bit word (instead of an 8-bit byte) to specify the size. Therefore, a single in-memory retrieval pointer can map up to 2**16 (65,536) contiguous blocks. Remember, when you back up your disk with BRU, it does its best to make *every* file contiguous. So, the key is to do regular BRU backups, use the NEW copy to run with, and (if you use RMS Indexed files) reorganize your files regularly to minimize bucket fragmentation. ================================================================================ Note 262.7 [RSX]BRU, File Error -10 7 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 14 lines 18-JUL-1989 18:11 -< best get SRD from Fall 87 or later >- -------------------------------------------------------------------------------- >Look for a copy of SRD (from the RSX SIG tapes) later than 1984. SRD has >a switch that lets you specify ONLY multi-header files That switch is /MU Also, since you are using 3.0, if you are using maned directories, or decimal version numbers, you need an even newer SRD than that. The use of FEAT (a $ is in there somewhere) to determine DECIMAL or NAMED DIR support was added just days before a symposium, and display of taskbuild date + time was added to SRD's /ID display. A copy of SRD that has not been rebuilt since then says it was built 29-nov-87 11:58:55.8 and so get one off fall 87 or later. ================================================================================ Note 262.8 [RSX]BRU, File Error -10 8 of 12 EISNER::SMITH_PA "Paul Smith" 31 lines 20-JUL-1989 22:10 -< Wrong Tree >- -------------------------------------------------------------------------------- Thanks to all respondents to date, but it would seem that we have been barking up the wrong tree. I set up a test for the extension header theory and now have reduced the problem to a single UIC [3,20] that always fails when doing BRU /MOU/NOINI/DISP DU1:[3,20] DU0: DU0:[3,20] is empty when the BRU begins. The catch is, all the source files are contiguous and there aren't any multi-header files. What happens is that several hundred files into BRU's file list display, we get a stream of -10 errors. It recovers and finishes. But, the first nine files in the directory as listed in [0,0]003020.DIR are trashed on the output disc. These nine files also happpen to have contiguous file IDs in INDEXF.SYS. Deleting the first file in the directory on the source, creating a new file in the directory and repeating the BRU gives the same result -- first nine files in directory trashed. The new file entry was placed in the first DU1:[0,0]003020.DIR element but was allocated a file ID non-contiguous with the other dying files. It is now trashed along with the other eight. Therefore, the problem would seem to be positional within the directory file. Any more theories? ================================================================================ Note 262.9 [RSX]BRU, File Error -10 9 of 12 EISNER::SMITH_PA "Paul Smith" 22 lines 21-JUL-1989 17:31 -< More data >- -------------------------------------------------------------------------------- Using the fact described above that the first file name in the directory gets trashed, we created a simple text file using EDT and a known pattern: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB ... GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG The BRU now trashes the copy of that file. What is exiting is that the trashing bears a relation to the correct data in the source file. Block 1 of the trashed file contains the string of A's B's etc except that there are only 78 (instead of 79) of them. In addition, the source strings were EDT line format but the destination had additional bytes inserted between the 78 byte strings. It is almost as though BRU was reading the file and writing it out in record mode, interpreting the source blocks in some fashion to come up with the additional bytes and inserting them as some sort of record header. Is this feasible? ================================================================================ Note 262.10 [RSX]BRU, File Error -10 10 of 12 EISNER::WYANT "SOME call me ..... TOM" 25 lines 1-AUG-1989 10:53 -< OK, let's bash the directory a bit. >- -------------------------------------------------------------------------------- >>> the first nine files in the directory as listed in >>> [0,0]003020.DIR are trashed on the output disc. This is beginning to sound more and more like an SPR. People who have worked with BRU for a while know that nothing is beyond it. Is there anything unique about the directory file itself? For example, is it unusually large (possibly multiheader), owned/protected strangely, locked, very sparse, or whatever? Do a header dump, and compare the dump with a "normal" directory: >DMP output/-SP=[0,0]003020.DIR/HD/BL:0:0 You can also use RMSDSP, or even ALAYZE/RMS/INTERACTIVE from your friendly neighborhood VAX. A brute force thing to try might be to completely re-create the directory. I would approach it this way: >PIP [0,0]003377.DIR/RE=[0,0]003020.DIR >UFD SY:[3,20] >PIP [3,20]/RE=[3,377]*.*;* >PIP [0,0]003377.DIR;*/DE ================================================================================ Note 262.11 [RSX]BRU, File Error -10 11 of 12 EISNER::SMITH_PA "Paul Smith" 42 lines 3-AUG-1989 19:30 -< Magic number 512 strikes again. >- -------------------------------------------------------------------------------- > < Note 131.10 by EISNER::WYANT "SOME call me ..... TOM" > > This is beginning to sound more and more like an SPR. For a variety of reasons we are running RSX11M+ V3.0. DEC does not want to know about problems in old versions. I do not know if the problem exists in V4.n -- but several other problems do! > Is there anything unique about the directory file itself? For No. > A brute force thing to try might be to completely re-create the > directory. I would approach it this way: The entire directory can be recreated - same problem. All the files can be PIPped to another newly created directory - same problem. More info: The directory contains 681 files, mainly 1/2 block *.obj with 2 x .olb. Another directory with 881 files, mainly .mac, .c, .h source file, BRU's successfully. Hypothesis: number of files in directory causes problems. Test: reduce number of files Result: At 512 files in directory it works; at 513 it dies, by trashing 1 file - the first in the .dir. 514 files trases 2 files, etc. then recovers after 7 trashes. Deleting files around 512, to change the 512'th does not affect the outcome -- the magic is in the file number. Test: Increase number of files Result: With the number of files doubled (PIP *.*/NV=*.*) It trashes the same first 7, THEN, trashes the files corresponding to files 513, 514, ... in the .dir. The saga continues... ================================================================================ Note 262.12 [RSX]BRU, File Error -10 12 of 12 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 19 lines 10-AUG-1989 00:56 -< Try a large contiguous DIR >- -------------------------------------------------------------------------------- > A brute force thing to try might be to completely re-create the > directory. I would approach it this way: > > >PIP [0,0]003377.DIR/RE=[0,0]003020.DIR > >UFD SY:[3,20] > >PIP [3,20]/RE=[3,377]*.*;* > >PIP [0,0]003377.DIR;*/DE With such a large directory, is there a chance its size and possible fragmentation of the DIR itself may be playing a role here? If so, and in general for efficiency, modify the above suggestion as follows: >PIP [0,0]003377.DIR/RE=[0,0]003020.DIR >; pick some number LARGER than the MAX number of files you >; ever will have in it... >UFD SY:[3,20]/alloc=800. >PIP [3,20]/RE=[3,377]*.*;* >ufd sy:[3,377]/de  ================================================================================ Note 263.0 [RSX]Setting File Attributes 2 replies EISNER::RICE "Gary Rice" 10 lines 28-JUN-1989 10:45 -------------------------------------------------------------------------------- On the PRO, there is a "system service" called PROATR that allows you to set the characteristics of a file. The routine accepts a FILE ID and sequence number and a 32 byte buffer. The buffer contains bits and bytes that determine the file's record type, max record size, carriage control, etc. Is there an equivalent routine available for RSX (M or M+)? Gary ================================================================================ Note 263.1 [RSX]Setting File Attributes 1 of 2 EISNER::WYANT "SOME call me ..... TOM" 26 lines 11-JUL-1989 16:45 -< You can do it under RSX -- if you're careful. >- -------------------------------------------------------------------------------- >>> On the PRO, there is a "system service" called PROATR that >>> allows you to set the characteristics of a file. ... Is there an >>> equivalent routine available for RSX (M or M+)? The answer is "yes and no". Or rather, "no and yes". No, there is no distinct system service that allows you to do this. But yes, it can be done. In the back of the "I/O Drivers Reference" (appendix "C" in my copy) is "QIO Interface to the ACPs" (Note: this information is in "I/O Operations" in some vintages of the doc set, and you'll need that volume anyway to know how to set up all the data structures). What you basicly do is use a QIO Read to get the current file attributes, then you modify the ones that need modifying and write them back with a QIO write. Depending on what you're trying to change, it may be possible to do it using either FCS or RMS calls, rather than going straight to the ACP (which gives some people the willies). You can't (theoretically) corrupt the disk, but you can definitely render a file unusable by using the QIOs. Test on a file you can afford to lose. Drop me a note if you'd like to see some code fragments. ================================================================================ Note 263.2 [RSX]Setting File Attributes 2 of 2 EISNER::WYANT "SOME call me ..... TOM" 8 lines 17-JUL-1989 12:23 -< Fragments provided sub rosa >- -------------------------------------------------------------------------------- >>> Drop me a note if you'd like to see some code fragments. Just for closures' sake: the note was dropped, and fragments were provided, cribbed from LBC (Fall 1987, plus DECUS library). Unfortunately, they broke the thirty-line rule rather badly, and so were forwarded with MAIL, not posted.  ================================================================================ Note 264.0 [RSX]Auto Set Time @ Boot 5 replies EISNER::MERUSI 5 lines 29-JUN-1989 15:25 -------------------------------------------------------------------------------- Looking for information from anyone about what products are available that would allow the system to automatically set the time at boot time. We have a TCU-100 from Digital Pathways, it doesn't control the year, and we were looking for something a little than that. Appreciate hearing from anyone about this, thanx. ================================================================================ Note 264.1 [RSX]Auto Set Time @ Boot 1 of 5 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 19 lines 29-JUN-1989 17:14 -< For Q-Bus: Codar Q-Timer 102 >- -------------------------------------------------------------------------------- >> Looking for information from anyone about what products are available >> that would allow the system to automatically set the time at boot time. I use the Codar Q-Timer 102 for my system, but the Q-Timer 150 does everything you need for setting date/time. They may have newer models available now. The 102 (and earlier 101) also provide a boot ROM with commands to set/display the date & time, 8 bits of parallel I/O and some other goodies. The 150 takes these away and gives you a watchdog timer. Both units give you a 4KB battery-backed-up CMOS RAM in which to keep data across boots. The latest address I have for Codar is: Codat Technology, Inc. 1500 Kansas Avenue, Building 2E Longmont, CO 80501 (303) 776-0472 I have no financial interest in Codar. ================================================================================ Note 264.2 [RSX]Auto Set Time @ Boot 2 of 5 EISNER::DOHERTY "Bob Doherty" 8 lines 29-JUN-1989 21:20 -< This really sounds silly, but ... >- -------------------------------------------------------------------------------- This is going to sound silly as hell, but we use our 750 to supply the time to a '44 running M+. When both machines come up at the same time, the '44 patiently waits for the 750 to get all the DECNET crap loaded, then uses a simple task-to-task decnet channel to steal the show time output from the VAX, and uses it to set the time on the '44. Naturally, this is only practical if you are 1) networked, and 2) the network has a VAX with a TOY on it. ================================================================================ Note 264.3 [RSX]Auto Set Time @ Boot 3 of 5 EISNER::SMITH_PA "Paul Smith" 11 lines 29-JUN-1989 22:38 -< Hayes Chronograph >- -------------------------------------------------------------------------------- >Looking for information from anyone about what products are available >that would allow the system to automatically set the time at boot time. We use a Hayes Chronograph on one of our systems. Simple async interface. We actually have duplexed PDP's and use our own gadget to gain control of the chronograph by setting DTR. This arbitrates between the CPUs as to who has the right to reset it. It also acts as a wall clock. ================================================================================ Note 264.4 [RSX]Auto Set Time @ Boot 4 of 5 EISNER::HUDGINS "Jerry Hudgins" 16 lines 10-JUL-1989 10:39 -< Grant Technology Model 307 >- -------------------------------------------------------------------------------- I've used the Digital Pathways product, but prefer the Grant Technology Model 307. It has a few neater tricks, like automatic leap year recognition and programmable daylight savings time, and doesn't have to be periodically touched by software to make things like leap year work. Cheap and recommended for simple applications. A nice utility called CLOCK on an old DECUS RSX symposium tape is already available to set/read the board, and can be embedded in STARTUP.CMD to get the time on powerup. Give me a call if you want more specific information, or send MAIL. Grant's address: Grant Technology Corp. 321 Billerica Road Chelmsford, MA 01824 (305) 974-5500 Approximate board cost is $300. I've no connection with Grant Technology. ================================================================================ Note 264.5 [RSX]Auto Set Time @ Boot 5 of 5 EISNER::WYANT "SOME call me ..... TOM" 16 lines 12-JUL-1989 08:44 -< We're silly too >- -------------------------------------------------------------------------------- >>> This is going to sound silly as hell, but we use our 750 to >>> supply the time to a '44 running M+. We do the same thing - in fact, we have a whole room full of PDP-11s asking each other (and handy nearby VAXen) what time it is. We got into the time-server business due to a persistent problem with an 11S system on the factory floor - some of the guys out there couldn't type the time correctly if their lives depended on it. This lead fairly naturally to setting up one PDP-11 as our time master, and loading all the others off it. If the "master master" was down, secondary (tertiary, quaternary, ...) masters were checked until SOMEONE was found who knew what time it was. The invention of the Set Time directive made all this much easier.  ================================================================================ Note 265.0 [RSX]Crashes from HELLO on LAT port 3 replies EISNER::NORTON "Bill Norton" 7 lines 5-JUL-1989 12:01 -------------------------------------------------------------------------------- We've recently discovered you can crash an M+ system by spawning HELLO to a LAT port. The port *is* associated with a TT unit and things like PIPing to it work fine, but HELLO to it kills the system. Does this ring a bell with anyone? Should it be expected to work? ================================================================================ Note 265.1 [RSX]Crashes from HELLO on LAT port 1 of 3 EISNER::NORTON "Bill Norton" 12 lines 22-AUG-1989 14:34 -< further info... >- -------------------------------------------------------------------------------- I've had a chance to look briefly at a dump caused by this. This one was a yellow stack limit trap. SP(K) was 376. There weren't any easily-recognizable patterns on the stack. The kernal mapping was: I SPACE D SPACE 5 Base of NT.QNA Base of NT.QNA 6 Inside TT: Inside POOL.. So does THIS jog anyone's memory? ================================================================================ Note 265.2 [RSX]Crashes from HELLO on LAT port 2 of 3 EISNER::DELARISCH "Arnold S. De Larisch" 30 lines 23-AUG-1989 19:40 -< If it hurts when doing that, Don't do it! >- -------------------------------------------------------------------------------- >> < Note 134.1 by EISNER::NORTON "Bill Norton" > >> -< further info... >- >> I've had a chance to look briefly at a dump caused by this. >> This one was a yellow stack limit trap. SP(K) was 376. >> There weren't any easily-recognizable patterns on the stack. >> The kernal mapping was: >> I SPACE D SPACE >> 5 Base of NT.QNA Base of NT.QNA >> 6 Inside TT: Inside POOL.. >> So does THIS jog anyone's memory? Yes ... it does ... I remember there are TWO things you NEVER, NEVER do with a LAT port (That is if you don't want to crash your system)! 1. CON OFFLINE any lat terminal (I can't see why it would loose its sence of humor about this) 2. Spawn HELLO from an 'unconnected' LAT terminal. Our solution to this problem was the same as going to the doctor and saying "It hirts when I do this" ... The answer DON'T DO THAT! -Arnold ================================================================================ Note 265.3 [RSX]Crashes from HELLO on LAT port 3 of 3 EISNER::NORTON "Bill Norton" 3 lines 29-AUG-1989 10:11 -------------------------------------------------------------------------------- The problem has been worked around by not spawning MCR... and passing it the HELLO command, but installing the dialog as ...tsk and spawning it directly. Runs fine from the not-logged-in LAT terminal.  ================================================================================ Note 266.0 [RSX]PEM$ revisited 1 reply EISNER::KELLEY_C "O, Captain! My Captain!" 8 lines 26-JUL-1989 18:00 -------------------------------------------------------------------------------- Does anyone know where I can find documentation on the undocumented RSX/DECnet macro PEM$? I am trying to figure out how the unsupported virtual device drivers work, and I ran across the PEM$ macro. I read note 65. in this conference, and there was no info. other than it is used for communication between network objects. Any hints, thoughts, suggestions . . . ================================================================================ Note 266.1 [RSX]PEM$ revisited 1 of 1 EISNER::WYANT "SOME call me ..... TOM" 26 lines 1-AUG-1989 11:05 -< General-purpose response. >- -------------------------------------------------------------------------------- >>> Does anyone know where I can find documentation on the >>> undocumented RSX/DECnet macro PEM$? A generalized, default answer, to be used only if nobody who knows anything posts in this thread: There are several sources of information, some of them truly weird, on undocumented RSX thingies: * Extract the macro from the library and read it. * Write a piece of code that does a .LIST ME and then expands it. * Disassemble any modules called by it. * Check help files. This may not pan out for DECnet, as there's not (to my knowlege) any help on writing DECnet code. * Reverse engineer it, starting from the comm drivers where it's used, and Jerry "Superior Klingon Technology" Ethington's observation that is is a communications interface of some kind. * Read the source (in this case, that probably means buying the fiche).  ================================================================================ Note 267.0 [RT11]Fix to USR Shoe Horn 1 reply EISNER::CROWELL "Shefth of the Fourth Order" 16 lines 27-JUL-1989 12:36 -------------------------------------------------------------------------------- When copying files, or opening files of known length, the RT-11 USR finds an empty space on the disk that is the closest fit to the file, and puts it there. A lot of us would rather that the file be put in the first available empty space that is large enough. The following change in USR.MAC will change the "best fit" to "first fit." Old Code: Change to: BHI 9$ BEQ 131$ BEQ 131$ BR 9$ 132$: MOV R4,(R5)+ 132$: MOV R4,(R5)+ It'll work for all monitors. This problem is discussed a little in the September Newsletter. I should have a reliable binary patch procedure worked out for the October issue. ================================================================================ Note 267.1 [RT11]Fix to USR Shoe Horn 1 of 1 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 2 lines 27-JUL-1989 12:56 -< I like it. Thank you. >- -------------------------------------------------------------------------------- >> < Note 23.0 by EISNER::CROWELL "Shefth of the Fourth Order" > >> -< Fix to USR Shoe Horn >-  ================================================================================ Note 268.0 [RSX]Needed: Spell checker for M-Plus/MicroRSX 4 replies EISNER::MAYHEW "Bill Mayhew" 12 lines 4-AUG-1989 13:07 -------------------------------------------------------------------------------- Could be public-domain or commercial (preference toward commercial with support, since this is for a client and I don't particularly want to deal with supporting it). In an ideal world, this would know how to read A-to-Z word processing documents (a/k/a DECtype). "Fat chance", you say? OK, I'll take something that can read ASCII text, if I can integrate it into a program I'll write myself to do the translation. If there is nothing specifically for RSX, then a spell-checker (with a good-sized dictionary) available in C source from another environment (say, VMS) would be a solution. ================================================================================ Note 268.1 [RSX]Needed: Spell checker for M-Plus/MicroRSX 1 of 4 EISNER::KENNEDY "Terry Kennedy" 7 lines 5-AUG-1989 06:20 -< Try PC-oriented magazines >- -------------------------------------------------------------------------------- > If there is nothing specifically for RSX, then a spell-checker (with > a good-sized dictionary) available in C source from another environment > (say, VMS) would be a solution. Check out an Austin Code Works ad in a magazine like Dr. Dobbs or Micro C. They have lots of low-cost stuff in C with source included. ================================================================================ Note 268.2 [RSX]Needed: Spell checker for M-Plus/MicroRSX 2 of 4 EISNER::LEDERMAN "Bart Z. Lederman" 2 lines 6-AUG-1989 13:05 -< VAX SIG tape has at least one spell checker >- -------------------------------------------------------------------------------- If PD is o.k. as a last chance, have you looked at the 'Vassar' and other spell checkers on the VAX SIG tapes? ================================================================================ Note 268.3 [RSX]Needed: Spell checker for M-Plus/MicroRSX 3 of 4 EISNER::MAYHEW "Bill Mayhew" 7 lines 7-AUG-1989 11:46 -< RSX-specific choices (including DECUS library)? >- -------------------------------------------------------------------------------- Thanks for those suggestions... is there anything specifically for RSX that is worth investigating? I see two listings in the DECUS library, for example: 110679 and 110745 (both written in FORTRAN 77 which I can't do much with, however, lacking the compiler). Has anyone used either of these? I gather nobody knows of a supported product. ================================================================================ Note 268.4 [RSX]Needed: Spell checker for M-Plus/MicroRSX 4 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 5 lines 10-AUG-1989 01:03 -< you can run F77 here >- -------------------------------------------------------------------------------- > library, for example: 110679 and 110745 (both written in FORTRAN 77 > which I can't do much with, however, lacking the compiler). Has If you do get these, you are welcome to come over and compile them here especially if I can get a copy of the DECUS tape they are on.  ================================================================================ Note 269.0 [RSX]An brief aside about BRU 2 replies EISNER::STAMERJOHN "RW Stamerjohn" 10 lines 9-AUG-1989 00:27 -------------------------------------------------------------------------------- Just as an aside to the thread on BRU 131.* (starting as new topic so BRU war stores don't kill the thread). At the 1981 magic session a Digital developer started to tell a War story with the introduction "How Many of you have used BRU?" Many hands went up, then from the back of the room came a clear voice "How many have used it twice." He never finished his story. ================================================================================ Note 269.1 [RSX]An brief aside about BRU 1 of 2 EISNER::WYANT "SOME call me ..... TOM" 32 lines 11-AUG-1989 16:37 -< Bash and Ruin Utility >- -------------------------------------------------------------------------------- >>> Just as an aside to the thread on BRU 131.* (starting as new >>> topic so BRU war stores don't kill the thread). Does that mean we *are* starting a BRU war stories thread here? My first symposium was Spring '82. DEC announced Fortran-77, and handed out a bunch of yoyos with "Digital" emblazoned on them. I went up to the campground the next day, and found the then-current BRU maintainer. He was trying (unsuccessfully) to get the yoyo to come back up to his hand. More recently (San Francisco, I think), there was the famous dialog (possibly paraphrased): Tony Scandora: "If BRU doesn't work by now it never will. Why don't you start over?" Brian McCarthy: "What makes you think we'll do any better?" In line with the current rage of butt-covering, the following disclaimer is in order: I am not now, nor have I ever, been employed in any capacity by any yoyo manufacturers or backup utility producers. ================================================================================ Note 269.2 [RSX]An brief aside about BRU 2 of 2 EISNER::MCGLINCHEY "Sancho! My armor! My TECO Macro" 25 lines 29-AUG-1989 14:36 -< BRU - an accessory to crime? >- -------------------------------------------------------------------------------- You asked for it, Rakph. I am currently doing some consulting as an expert witness in a product liability suit. Although DEC is not a party in the suit, BRU figures heavily in the arguments. "Sir, did you assert the /VER switch?" "uh, no." "Why not?" "The backup would take too long" "So you DIDN'T know tha tape was blank when you sent it out." and so on. It's the only legal case I've seen where BRU is named as accessory-instead-of-the-fact. -- Glinch (who's back doing some good ol' RSX-ing)  ================================================================================ Note 270.0 [RSX]Remote terminal entry needed 11 replies EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 10 lines 10-AUG-1989 11:47 -------------------------------------------------------------------------------- I am looking for an RSX program that will allow me to "enter" a command for another terminal. This would allow me to cause a remote terminal to exit the program it is running and then log it off. I seem to recall one called FORCE, but (if my memory is correct) it was only for entering MCR commands, not solicited input (to a program). Does anyone remember anything on the SIG tapes or elsewhere? ================================================================================ Note 270.1 [RSX]Remote terminal entry needed 1 of 11 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 9 lines 10-AUG-1989 15:27 -< try RMC >- -------------------------------------------------------------------------------- We use RMC. It came from the KMS kits stuff in [344,43] and was written in FORTRAN. It spawns to MCR, or maybe in the later versions uses RPOI. It is easy to log in a remote RMD displaying terminal that has a crippled keyboard, or to log off some idle terminal remotely. The command line allows for waiting for the exit status of the remote command, or simply firing off the command and not waiting. ================================================================================ Note 270.2 [RSX]Remote terminal entry needed 2 of 11 EISNER::DELARISCH "Arnold S. De Larisch" 11 lines 10-AUG-1989 17:38 -< We used a modified version of FRC! >- -------------------------------------------------------------------------------- >> < Note 138.1 by EISNER::BRUCE "Barton F. Bruce - CCA/MA" > >> -< try RMC >- Another program was called FRC (FORCE). I don't remember which SIG tape I pulled it off of, but it was in the 1983-1984 time frame. Its written in FORTRAN-77 and spawn a command to the terminal in question. Kind of fun to play with a 'unexpecting' users mind. I put some hooks in it to Log to the console logger Non-priv attempts to use it. -Arnold ================================================================================ Note 270.3 [RSX]Remote terminal entry needed 3 of 11 EISNER::LEDERMAN "Bart Z. Lederman" 3 lines 10-AUG-1989 18:21 -< I remember a different FRC >- -------------------------------------------------------------------------------- Are you sure that FRC was on a SIG tape? The version I remember using came off of the RSX-11M-Plus V1.0 distribution kit, which included a number of unsupported utilities in source form. ================================================================================ Note 270.4 [RSX]Remote terminal entry needed 4 of 11 EISNER::WYANT "SOME call me ..... TOM" 11 lines 11-AUG-1989 16:43 -< Are we barking up the wrong tree? >- -------------------------------------------------------------------------------- >>> I am looking for an RSX program that will allow me to "enter" a >>> command for another terminal. ... I seem to recall one called >>> FORCE, but (if my memory is correct) it was only for entering >>> MCR commands, not solicited input (to a program). I agree with the previous remarks on the thread, but it sounds like you want to stuff characters to a QIO, not just stuff command lines to MCR. Right? I don't have any experience with such, but I do remember seeing an ad in Digital Review a couple years ago for a "spy" program from an outfit called (rather ominously) XDT Systems. ================================================================================ Note 270.5 [RSX]Remote terminal entry needed 5 of 11 EISNER::POKEL "Lisa J. Pokel" 23 lines 11-AUG-1989 17:35 -< Try FORCE.MAC on RSX84A >- -------------------------------------------------------------------------------- > I am looking for an RSX program that will allow me to "enter" a > command for another terminal. ... I seem to recall one called > FORCE, but (if my memory is correct) it was only for entering > MCR commands, not solicited input (to a program). Take a look at FORCE.MAC on Spring 1984 SIG Tape (by Frank Penner). Modelled after RSTS/E utility, FRC it will force characters to another keyboard (including control characters by using the carat symbol). Command lines can be forced with or without trailing carriage returns by using tilde. I have one of the MCR command line FORCE's installed as FRC and this one installed as SHV (for "shove"). > I agree with the previous remarks on the thread, but it sounds > years ago for a "spy" program from an outfit called (rather > ominously) XDT Systems. There is a product called PEEK/SPY for VMS by a company that also makes a multisession product called VXTD (which is somewhat close to XDT, but no cigar). Company is Networking Dynamics Corporation. ljp ================================================================================ Note 270.6 [RSX]Remote terminal entry needed 6 of 11 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 10 lines 12-AUG-1989 12:05 -< Not just MCR command lines >- -------------------------------------------------------------------------------- > I agree with the previous remarks on the thread, but it sounds > like you want to stuff characters to a QIO, not just stuff > command lines to MCR. Right? Right. Sending command lines to MCR for another terminal is easy. In this case, the remote users are all running a known program which I wish to terminate before logging them out. I would prefer not to abort the program since I don't want to give users the idea that aborting programs is a normal thing to do. (It also tends to screw up files.) ================================================================================ Note 270.7 [RSX]Remote terminal entry needed 7 of 11 EISNER::NORTON "Bill Norton" 4 lines 12-AUG-1989 16:04 -< How about an ACD? >- -------------------------------------------------------------------------------- This sounds like a good place to use an ACD, on the users' terminals, just passing traffic until they try to log out, when it would stuff the shutdown and logout commands into the typeahead buffer and turn it loose. ================================================================================ Note 270.8 [RSX]Remote terminal entry needed 8 of 11 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 12 lines 12-AUG-1989 23:57 -< Close enough to give me an idea >- -------------------------------------------------------------------------------- > This sounds like a good place to use an ACD, on the users' > terminals, just passing traffic until they try to log out, when > it would stuff the shutdown and logout commands into the > typeahead buffer and turn it loose. No, what I want to do is "become" their terminal long enough to exit the program they are running and then log them out. The ACD might be the way to accomplish this, however. It would just pass traffic until my (priv) program tells it to listen to *my* terminal instead of theirs. I was hoping to find something on the SIG tapes, however. ================================================================================ Note 270.9 [RSX]Remote terminal entry needed 9 of 11 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 6 lines 15-AUG-1989 02:32 -< will global EF or ABO AST work? >- -------------------------------------------------------------------------------- These following two ideas are common/obvious, so I assume there is some reason they don't apply. If the task they all are in is 'yours', have it check for a global EF set externally, or use the ABO AST to wake up and shut down cleanly when someone tries to kill it. ================================================================================ Note 270.10 [RSX]Remote terminal entry needed 10 of 11 EISNER::POKEL "Lisa J. Pokel" 119 lines 25-AUG-1989 19:14 -< Try FORCE 84A (echo echo echo...) >- -------------------------------------------------------------------------------- > In this case, the remote users are all running > a known program which I wish to terminate before logging > them out. I would prefer not to abort the program since > I don't want to give users the idea that aborting programs > is a normal thing to do. (It also tends to screw up files.) I have used FORCE (see 138.5) to send character strings (NOT MCR commands) to get people out of programs in a more "dignified" manner than ABOrting the suckers. For example, you can FRC ttnn:^Z and then FRC ttnn:EXIT^M to save and exit from EDT. Unless I am STILL in the wrong ballpark, that *sounded* like what you are attempting to perform. By the way, it is also great for sending ^Q to terminals that ari "broken" and printers that "refuse to print." > No, what I want to do is "become" their terminal long enough > to exit the program they are running and then log them out. Unfortunately, you do have to TYPE BLINDLY as you CANNOT SEE to what you are giving commands. Of course YOU are a WIZARD and KNOW what is on their screens ;-) Mere mortals, such as myself, have to make educated guesses or resort to the "low tech" solution of going to their offices or plugging a terminal into their lines in the computer room (obviously not always feasible or even physically possible in remote situations). I would use it to get people out of our word processor but I can't get it to pass ESC correctly (after some feeble attempts at hacking the assembler). It also "automatically converts tabs to a single space, removes trailing blanks, upcases, etc.... Therefore, it is currently not possible to force lowercase characters." Not knowing your application, these restrictions may knock this program out of contention right off the bat. The following is the documentation file for FORCE. As you can see, the example given sends character strings to WORD-11 to perform certain functions. Hopefully this helps describe the program better than I had done in #138.5 (otherwise just shut me up and hit KP3!) - ljp  -------------------------------------------------------------------- Program FORCE (FRC) This will program is modeled after the RSTS/E Utility command, FORCE. It enables a privileged user to effectively type on another terminal on the system, using his own terminal. For example, typing: FRC TT16:HELLO terminated by a carriage return, would cause the system to behave as if the string HELLO followed by a carriage return, were actually typed on terminal TT16:. A special character to FORCE is the uparrow (^). An uparrow means that the following character should be forced as a control character. For example, typing: FRC TT16:^Q terminated by a carriage return, would be the same as if a control-Q and a carriage return were typed on TT16:. Two uparrows in a row force an uparrow. It is currently not possible to force a control uparrow. If the FRC command line to the CLI (Command Line Interface, DCL or MCR) is terminated with a carraige return, the carriage return is also forced to the target terminal. If the command line is terminated by a tilde (~) character, the tilde is not forced. Therefore, using the tilde, it is possible to force without a trailing carriage return. A characteristic of RSX indirect command files is that CLI command lines are executed as if they had been typed terminated by an tilde. This means that when using FORCE from an indirect command procedure, no carriage returns will be forced unless there explicitly in the form of an ^M. For example, here is an indirect command file for starting Word-11 spoolers: .ENABLE QUIET .ENABLE SUBSTITUTION .SETS TT "TT16:" FRC 'TT'HEL PENNER^M .DELAY 3.S FRC 'TT'PASSWO^M .DELAY 3.S FRC 'TT'WORD11^M .DELAY 3.S FRC 'TT'U^M .DELAY 5.S FRC 'TT'AD^M .DELAY 3.S FRC 'TT'TT5:^M .DELAY 3.S FRC 'TT'FORCE^M .DELAY 3.S FRC 'TT'^M .DELAY 3.S FRC 'TT'^M .DELAY 3.S FRC 'TT'AD^M .DELAY 3.S FRC 'TT'TT6:^M .DELAY 3.S FRC 'TT'FORCE1^M .DELAY 3.S FRC 'TT'^M .DELAY 3.S FRC 'TT'^M .DELAY 3.S FRC 'TT'^M .DELAY 5.S FRC 'TT'F^M .DELAY 3.S FRC 'TT'LOG^M .DELAY 3.S the delay directives are to allow Word-11 time to execute each command. Finally, the MCR dispatcher, the part of RSX that invokes FORCE, automatically converts tabs to a single space, removes trailing blanks, upcases, etc.... Therefore, it is currently not possible to force lowercase characters. -------------------------------------------------------------------- ================================================================================ Note 270.11 [RSX]Remote terminal entry needed 11 of 11 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 12 lines 26-AUG-1989 16:41 -< That's it! >- -------------------------------------------------------------------------------- > I have used FORCE (see 138.5) to send character strings (NOT > MCR commands) to get people out of programs in a more > "dignified" manner than ABOrting the suckers. For example, you > can FRC ttnn:^Z and then FRC ttnn:EXIT^M to save and exit from > EDT. Unless I am STILL in the wrong ballpark, that *sounded* > like what you are attempting to perform. That is exactly what I wanted and I now have extracted it from the Spring '84 SIG tape, [300,70]. Thanks a lot. My confusion was because an earlier program of the same name would only generate MCR commands for the remote terminal.  ================================================================================ Note 271.0 [PRO300]PRO Public Domain Software 3 replies EISNER::RICE "Gary Rice" 20 lines 14-AUG-1989 15:07 -------------------------------------------------------------------------------- About a year and a half ago, the PC SIG (principally Tom Hintz) organized a "final Hurrah" for the PRO. This took the form of collecting ALL of the known PD software that was specifically written for the PRO (as well as S/W that would be appropriate for the PRO but not specifically written for it) and build it into a tape. I am happy to say that the effort is concluded and I have a copy of the results. I will be formally "announcing" the tape in the November Newsletter, but I thought I would let you know here first. The tape is VMS Backup format (6250 BPI - 1/2"). Distribution plans are not yet firm, but I can make a limited number of copies if you would like one. The tape is organized into 3 save sets. Collectively, they occupy about 100,000 disk blocks. More details about the tape contents will be available if you request them. Gary ================================================================================ Note 271.1 [PRO300]PRO Public Domain Software 1 of 3 EISNER::RICE "Gary Rice" 47 lines 20-OCT-1989 09:35 -< DEC Offers PRO Software >- -------------------------------------------------------------------------------- The following "memo" appeared in my DCS account this morning: D E C U S - I N T E R O F F I C E M E M O R A N D U M Date: 19-Oct-1989 03:51pm EST From: Jeff Slayback SLAYBACK Dept: Symp. Counterparts TO: Thomas R. Hintz ( HINTZ ) TO: Gary Rice ( RICE ) Subject: PRO software to DECUS library Tom, Gary Took a trip to the DECUS office this morning and dropped off some software. Could one of you at the PC ROADMAP can give the news to the DECUS people? What I supplied was: P/OS V3.2 PRO/BASIC V1.4 PRO/COMM V3.1 PROSE PLUS V2.1 SYNERGY V2.1 SIGHT V1.1 TOOLKIT V3.1 INSTALLATION & MAINT V3.3 PRO/DECNET After talking with them this morning we may not offer PRO/COMM and PROSE PLUS as separate packages since they are part of SYNERGY. I will let you both know the outcome of that. I will write something up for the PC ROADMAP for one of you. I have a conflict and will be giving another session in the L&T area. See your both in Anaheim. Jeff As you can see, the PRO STILL has a few "cycles" left in it. Gary ================================================================================ Note 271.2 [PRO300]PRO Public Domain Software 2 of 3 EISNER::ROECKEL "Bruce W. Roeckel" 9 lines 30-OCT-1989 14:47 -< How do we obtain ? >- -------------------------------------------------------------------------------- > Took a trip to the DECUS office this morning and dropped off some > software. Could one of you at the PC ROADMAP can give the news to the > DECUS people? What does this mean, exactly? This software will be given away FREE at the SIG campground? -Bruce ================================================================================ Note 271.3 [PRO300]PRO Public Domain Software 3 of 3 EISNER::RICE "Gary Rice" 15 lines 31-OCT-1989 09:48 -------------------------------------------------------------------------------- >> Took a trip to the DECUS office this morning and dropped off some >> software > What does this mean, exactly? It means that the varoius PRO products (mentioned in the original note) have been submitted to the DECUS Library. > This software will be given away FREE at the SIG campground? Nope. The Campground will have MAC software and probably little else in the way of PD software. Gary  ================================================================================ Note 272.0 [RT11]Device Handler: Logical Device Name Access No replies EISNER::CAMPBELL "Milton Campbell" 60 lines 16-AUG-1989 10:51 -------------------------------------------------------------------------------- At a session at the spring 1989 Symposium in Atlanta I learned about an interesting "trick" having to do with RT-11 "special directory" device handlers. Special directory devices are those that do not contain an RT-11 file structure, the classic example being mag-tape. For such devices, the RT-11 USR does not process the various file processing requests such as .LOOKUP, .ENTER and .CLOSE. Instead, the requests are passed to the handler for any special processing. The "trick" has to do with the file name that the handler sees on a .ENTER or .LOOKUP request. RT-11 passes the name to the handler as a four word RAD50 block, with the device name in the first word, the file name in the second and third words, and the file type in the fourth word. Normally, a special directory handler does not use the device name word because the handler "knows" who it is. However, it turns out that the device name word contains the original device name requested by the user, not the name of the handler that actually processes the request. This means that if the request uses a logical device name (associated with the real device by the ASSIGN command) the handler sees the logical name in the device word. This is useful because special directory handlers can be used to extend RT-11 in a number of ways. One example is the networking product described in the Symposium session. With the logical name available, special directory handlers have additional information about the request. Because the "buffer address" passed to the handler by the operating system points to the start of the file name, extra code is needed to actually get at the device name. The buffer address must be backed up a word, which in turn may cross a PAR boundary. Below is a code fragment to do the backup. I have extended it for TSX-Plus from a fragment by John Crowell for RT-11 XM. mov XXcqe,r4 ; Point to queue element sub #2,Q$BUFF(r4) ; Back up to device name .if ne mmg$t .if eq tsx$p ; Check for TSX ;code for RT-11 XM cmp Q$BUFF(r4),#2000 ; Cross PAR1 boundary? .iff ;code for TSX-Plus cmp Q$BUFF(r4),#140000 ; Cross PAR6 boundary? .endc bhis 5$ ; If still in PAR region add #20000,Q$BUFF(r4) ; Adjust offset sub #200,Q$PAR(r4) ; and PAR bias 5$: .endc  ================================================================================ Note 273.0 [RSX]Is that six or fourteen windows ? 5 replies EISNER::SIMONS "Paul, Not that CONVEX!" 15 lines 21-AUG-1989 18:21 -------------------------------------------------------------------------------- It would be most appreciated if someone out there would please explain to me what the WS.UDS flag in the status word of a WDB *really* means. I thought I had a handle on the concept of instruction and data spaces. The way I understand it, once I & D space is enabled in the hardware, you have to be much more aware of what instructions you are using. Ok, I admit it, it's still a Black Art to me. I understand that words are words and they become "instructions" or "data" only because I set the proper (hopefully) flag in the .PSECT directive. The thing that confuses me is that, according to my interpretation of $DRCRW, the window gets created in instruction space by default. I can understand mapping instructions using the data APR's (to put hookpoints in the Exec, for example), but not mapping data using instruction APR's. To ask the question another way, if I have a nonID task that takes two APR's, how many one APR windows can I create on an 11/70 under RSX-11M+ with ID space enabled ? ================================================================================ Note 273.1 [RSX]Is that six or fourteen windows ? 1 of 5 EISNER::MAYHEW "Bill Mayhew" 6 lines 21-AUG-1989 22:23 -< In search of portable code? >- -------------------------------------------------------------------------------- > I can understand mapping instructions using the data APR's ... > but not mapping data using instruction APR's. A non-I/D machine only has "instruction" APRs... no "data" APRs. I have always figured this was the reason for the default condition. ================================================================================ Note 273.2 [RSX]Is that six or fourteen windows ? 2 of 5 EISNER::WYANT "SOME call me ..... TOM" 57 lines 22-AUG-1989 15:18 -< A (shaky) enlargement on the situation. >- -------------------------------------------------------------------------------- >>> The way I understand it, once I & D space is enabled in the >>> hardware, you have to be much more aware of what instructions >>> you are using. Well, not THAT much more aware, though you DO have to avoid the use of linkage registers (ie - passing data to subroutines using code like JSR R5,FOOBAR .WORD stuff .WORD more.stuff BCS 60$ because the taskbuilder puts the data in I space (that's where you told it to), but the machine will try to get it from D space). This kind of thing is why you used to have to patch the F77 compiler (the non-I/D version uses linkage registers to call OTS routines). >>> I understand that words are words and they become "instructions" >>> or "data" only because I set the proper (hopefully) flag in the >>> .PSECT directive. To get ***REAL*** picky, the .PSECT directive tells the assembler (which tells the task builder, which tells the loader) which parts to map with what kind of APRs. The machine then goes to I space on all instruction fetches and the first data fetch on all R7 operands, and D space on all others. I don't know that this explanation is quite complete, but it's been enough to keep me going for years. >>> The thing that confuses me is that, according to my >>> interpretation of $DRCRW, the window gets created in instruction >>> space by default. I can understand mapping instructions using >>> the data APR's (to put hookpoints in the Exec, for example), but >>> not mapping data using instruction APR's. By default, user D-space is disabled, so all data references go through the I-space APRs. Which version of RSX are we talking about? It seems to me like there was a bug where /ID tasks got only I/D windows -- a feature that was not terribly useful. >>> To ask the question another way, if I have a nonID task that >>> takes two APR's, how many one APR windows can I create on an >>> 11/70 under RSX-11M+ with ID space enabled? Try it and see. I believe the answer is six. The max is probably 12, not 14 (since even if RSX turns on D-space it must map the first two data APRs to your task, to make sure it has included all your task's data (eg: stack) in its address space). I also suspect the average application wouldn't be able to use I-space windows much (though I'm sure SOMEONE has a use for them). But you can probably attach to more regions than that (up to a max of 15??), you just can't have them all mapped simultaneously. PLAS directives aren't my strong suit. Would someone else care to amend/comment? Or even better, convince Brian to resubscribe. ================================================================================ Note 273.3 [RSX]Is that six or fourteen windows ? 3 of 5 EISNER::SIMONS "Paul, Not that CONVEX!" 8 lines 23-AUG-1989 11:00 -< Some elucidation >- -------------------------------------------------------------------------------- We are using M+ 4.1 (tonight should see us up on 4.2). Another thought I had was, "If I have an I space window that starts at 100000, and a D space window that starts at 100000, and they are mapped to separate regions, how do I access the two regions ?" I know I am missing something basic. I'm confused by the possibility of a choice implied by the presence of the WS.UDS bit. If ID space is disabled, only instruction APR's are used; if ID space is enabled, data can only be accessed through data APR's. ================================================================================ Note 273.4 [RSX]Is that six or fourteen windows ? 4 of 5 EISNER::MCGLINCHEY "Sancho! My armor! My TECO Macro" 16 lines 29-AUG-1989 14:41 -< It's in the addressing modes >- -------------------------------------------------------------------------------- >> We are using M+ 4.1 (tonight should see us up on 4.2). Another thought >> I had was, "If I have an I space window that starts at 100000, and >> a D space window that starts at 100000, and they are mapped to separate >> regions, how do I access the two regions ?" The regions are differentiated by the addressing mode on the operand being accessed. It's listed in the processor handbook for your machine. Certain addressing modes are automatically D-Space references, and certain ones are I-Space references. If, of course, you have I-and-D space enabled, etc. etc. -- Glinch ================================================================================ Note 273.5 [RSX]Is that six or fourteen windows ? 5 of 5 EISNER::WYANT "SOME call me ..... TOM" 21 lines 31-AUG-1989 14:24 -< Explaining an already clear explanation ... >- -------------------------------------------------------------------------------- >>> Another thought I had was, "If I have an I space window that >>> starts at 100000, and a D space window that starts at 100000, >>> and they are mapped to separate regions, how do I access the two >>> regions ?" ... if ID space is enabled, data can only be accessed >>> through data APR's. To put it another way, you access the I- space region with a JMP or similar transfer-of-control instruction, and D- space with a MOV or similar data manipulation statement. Or, looking at it from the other side, you can't access data it's mapped in D- space, and you can't execute code unless it's mapped in I- space. The choice of which mapping register is used is implicit in how you access the data. So how does I- space get loaded anyway? The loader maps the task's region in D- space, reads it from the .TSK file (which is "just data") into memory, then instructs the exec how to set up the mapping. PS to 'Glinch: Glad you haven't been completely consumed by your new duties!  ================================================================================ Note 274.0 [RSX]MicroRSX print despooler/MiniExchange/DTR 2 replies EISNER::MAYHEW "Bill Mayhew" 33 lines 28-AUG-1989 16:05 -------------------------------------------------------------------------------- I have a DEC MiniExchange (DFMSA) here that I'd like to use to share printers between two or three CPUs. One of them is an RSX system, and that's the one I'm most concerned about persuading to work. Briefly, the MiniExchange is an 8-port device originally marketed by DEC back in the Rainbow/Pro/DECmate era that acts as a "port switch"; any port can "connect" to any other. To trigger the MiniExchange, the requesting CPU essentially drops DTR, raises it again, sends a few characters that cause the MiniExchange to auto-baud, then sends a couple characters that identify the port the requestor wants to talk to. The question in a nutshell is, can I persuade Micro/RSX (M-plus) to do this? The port to be used is a DZV11 (or possibly DZQ11) RS232 port. If I set it to /REMOTE before setting it /SPOOLED, will RSX raise DTR when it starts to send a job to the printer, and turn it off when it's done? And, can I create some sort of top-of-job thing that will spit out the characters I need at the beginning of each print job? My fallback is to punt the RSX print spooler, set the port to /REMOTE, and write my own little program that toggles DTR, sends the MiniExchange what it wants, and then reads the file specified in its command line and sends it to the printer, though this is obviously less desirable. Does anybody know enough about the RSX print spooler to know if I have any hope of getting this to work? Bear in mind that I have MicroRSX which means I have no source modules to the spooler to tinker with. ================================================================================ Note 274.1 [RSX]MicroRSX print despooler/MiniExchange/DTR 1 of 2 EISNER::KENNEDY "Terry Kennedy" 12 lines 29-AUG-1989 01:23 -< Strongly discouraged... >- -------------------------------------------------------------------------------- > I have a DEC MiniExchange (DFMSA) here that I'd like to use to share > printers between two or three CPUs. My advice is: Don't. The mini-exchange is brain-dead and you will be, too, by the time you're done with it. You can by an Inmac switch or something else from, say, Black Box which will do waht you want without the DTR silliness. In case you think I'm not serious, I wrote a tiny Basic that runs in the vertical format unit of a Dataproducts 22-series printer, as well as adding a disk drive to the buffered send/receive option for the LA36, so I have no axe to grind about crazy projects 8-). *BUT* I strongly suggest you stay away from the mini-exchange... ================================================================================ Note 274.2 [RSX]MicroRSX print despooler/MiniExchange/DTR 2 of 2 EISNER::MAYHEW "Bill Mayhew" 24 lines 29-AUG-1989 10:05 -< Yes, but... >- -------------------------------------------------------------------------------- That advice is well-placed, but... (there's always a but ) I went through the wars with the Mini-Exchange several years ago, and (while I may be a little rusty) think I understand it pretty well. It is certainly not the best-documented piece of hardware DEC ever produced, but that can be said of much DEC gear of that era... I was successful enough to integrate support for it into a UNIX-clone device driver, and it worked. With that in mind, the MiniExchange is here and "free" and I can't justify spending $$ on an alternative right now. Some poking around with RSX last night has led me to conclude that I can't get DTR to toggle under the sole control of the despooler (at least not without modifying and rebuilding the despooler). So I'm working instead on an alternate method that will use a program (indirect command file, actually) to "allocate" the printer through the MiniExchange and restart the queue, and an accompanying program to "release" it. Not nearly as transparent as I'd really like, but adequate for the purpose at hand. If anyone has any insight into how to do it more transparently, I'd still like to hear about it.  ================================================================================ Note 275.0 [RSX]Restriction on renaming directories? 3 replies EISNER::MAYHEW "Bill Mayhew" 30 lines 31-AUG-1989 13:23 -------------------------------------------------------------------------------- I have upgraded my (and some clients') MicroRSX system from 3.0 or 3.1 to 4.0 recently, and have run into a problem. If I... $ CREATE/DIR [FOO] . . . $ RENAME [0,0]FOO.DIR [0,0]BAR.DIR $ PRINT [BAR]WHATEVER.TXT ... it fails, trying to access [FOO]WHATEVER.TXT instead! This occurs regardless of whether WHATEVER.TXT is created in [BAR] *after* the rename, or created in [FOO] *before* the rename. The same thing happens with batch jobs, btw; SUBMIT [BAR]BATCH.JOB fails, looking for [FOO]BATCH.JOB. A call to Colorado says that there has been a "restriction" against renaming directories, going back to V3.0. I can't find it documented in my 3.0 release notes; is anyone else aware of this problem, and is it truly a restriction? (It strikes me as really odd behavior, especially odd for it to survive this long.) Despite Colorado's comments, this works just fine on 3.0 or 3.1. These version numbers, and presumably the problem, also apply to 11M-Plus, by the way, for those of you who know not about MicroRSX. ================================================================================ Note 275.1 [RSX]Restriction on renaming directories? 1 of 3 EISNER::WYANT "SOME call me ..... TOM" 65 lines 31-AUG-1989 14:53 -< "Restricted" = "Watch out!" >- -------------------------------------------------------------------------------- >>> If I... >>> $ CREATE/DIR [FOO] >>> . >>> . >>> . >>> $ RENAME [0,0]FOO.DIR [0,0]BAR.DIR >>> $ PRINT [BAR]WHATEVER.TXT >>> >>> ... it fails, trying to access [FOO]WHATEVER.TXT instead! I don't know any reason why a directory can't be renamed, but I do know some reasons why it may not give the results you want - and they go back a lot farther than 3.0! It may be that the queue manager has been modified in a way that makes it vulnerable to one of these things. In your particular case, you're probably falling over the old "partial rename" feature. RENAME is a directory operation only -- it doesn't touch the file name stored in the header. Now, I don't have the layout of all the queue manager packets handy, but I know that the only information a serial despooler packet has about the directory is it's file ID. Now, if you rename the directory, any software that attempts to reconstruct the directory name from its file ID is going to become very confused. You can write your own rename utility that hammers the name into the file header as well as the directory (and which will fail unless it has write access to the file as well as the directory it's in). But for this case you could just modify the way you create the new directory: Supported: $ CREATE/DIR [FOO] . . . $ CREATE/DIR [BAR] $ RENAME [FOO]*.*;* [BAR] $ DELETE [0,0]FOO.DIR; $ PRINT [BAR]WHATEVER.TXT Unsuppored, but faster (still not as fast as your way, but more likely to work, I think.) $ CREATE/DIR [FOO] . . . $ CREATE/DIR [BAR] $ MCR PIP [0,0]BAR.DIR/UP=[0,0]FOO.DIR $ DELETE [0,0]FOO.DIR; $ PRINT [BAR]WHATEVER.TXT There is yet another problem you can run into when renaming directories, and that is the directory cache. RSX caches the file IDs of the most recently used directories in pool. You can rename all you like, but until your directory gets flushed out of cache, RSX will continue to find it under the old name. The tried-and-true way to flush the cache, unfortunately, is to dismount the disk. ================================================================================ Note 275.2 [RSX]Restriction on renaming directories? 2 of 3 EISNER::MAYHEW "Bill Mayhew" 31 lines 31-AUG-1989 15:46 -< Just trying to avoid Murphy... >- -------------------------------------------------------------------------------- > Now, if you rename the > directory, any software that attempts to reconstruct the > directory name from its file ID is going to become very confused. This is, I think, the explanation for what I'm seeing. I'm still befuddled as to why it would suddenly bite me with V4, but... The "rename all the files" gambit was DEC's suggested workaround. I'm not happy with it, though. One of the things I use directory renames for is to keep users out of a database while maintenance work is being done on it. (The database, and only the database, lives in [FOO]; so I rename it to [BAR], do the maintenance work, then rename it back.) The rename operation is "sufficiently atomic" ;-} that users can't foul things up. Murphy says, OTOH, that renaming all the files introduces too big a window of vulnerability. Now this is all fine, except that the maintenance work is run as a batch job, and the batch job file itself lives in [FOO] as well. So once I rename [FOO] to [BAR] and SUBMIT MAINT.BAT... well, it can't find MAINT.BAT any more, since the batch processor looks for it in [FOO]. Possibly I can COPY MAINT.BAT NEWMAINT.BAT, then SUBMIT that... I'll have to try it. OTOH I could always change the protections on the directory instead of renaming it, I suppose... since the directory is owned by a privileged account, and the users are all "somebody else." I appreciate the warning about the directory cache, too. Not a cause of the present problem, to be sure (since the system was rebooted overnight, after the dir was renamed and before the PRINT was attempted), but certainly a consideration. ================================================================================ Note 275.3 [RSX]Restriction on renaming directories? 3 of 3 EISNER::WYANT "SOME call me ..... TOM" 28 lines 6-SEP-1989 15:14 -< PS --- >- -------------------------------------------------------------------------------- >>> This is, I think, the explanation for what I'm seeing. I'm >>> still befuddled as to why it would suddenly bite me with V4, >>> but... Me too. >>> The "rename all the files" gambit was DEC's suggested >>> workaround. I'm not happy with it, though. Hindsight says that you could point a system-wide logical name at the directory, have everyone go after it be the logical name, and just change it when you want things to yourself. Unfortunately, your users already know where things *really* are (and they would probably figure out in time anyway). >>> I appreciate the warning about the directory cache, too. Not a >>> cause of the present problem, to be sure (since the system was >>> rebooted overnight, after the dir was renamed and before the >>> PRINT was attempted), but certainly a consideration. The directory cache MAY prevent the directory rename from working anyway (though I agree that that's not causing your present problems). Then again, it may not. You can try the PIP /UP dodge mentioned earlier. Or for some real fun, see the back of the I/O operations guide (or the drivers manual, I forget which). You can find enough info othere to do a REAL rename, including changing the name stored in the header.  ================================================================================ Note 276.0 [RSX]What made VFY break? No replies EISNER::MAYHEW "Bill Mayhew" 23 lines 31-AUG-1989 13:32 -------------------------------------------------------------------------------- I have an old copy of VFYRES.TSK (going back to MicroRSX 1.5*... not sure just what version of M-Plus that corresponds to) which now doesn't work for some purposes under MicroRSX V4.0. If I try to do a VFY DU0:/LO (to locate "lost" files), I get: Failed to open directory file Error code -39. - Directory [000,000] As a result, no files will be entered in [1,3] The following files were not in any directory File ID 000001,000001 INDEXF.SYS;1 Owner [1,1] ...and it proceeds to list every file on the disk (well, it appears to, I haven't actually checked ). Anybody know why this is happening? -39. is IE.NBF, Open - No buffer space available for file. This worked on 3.0 and 3.1. *The reason for this is that VFY is not shipped on vanilla MicroRSX; you have to buy the Advanced Programmer's Kit to get it... but this is about all I use from the A/P kit, and I can't justify spending an extra $800 every time there's a new MicroRSX release for one program which SHOULD be shipped with the base system so one can fix broken filesystems!  ================================================================================ Note 277.0 [RSX]ASTs in FORTRAN 10 replies EISNER::RICE "Gary Rice" 11 lines 6-SEP-1989 12:32 -------------------------------------------------------------------------------- I am writing an RSX application that needs AST support. However, to make the code "supportable", I need to write it in FORTRAN (or some other high-level language - Pascal is available). I have reviewed the relevant DOCs and conclude that I am in for trouble with this combination. Can you offer any suggestions (or code samples from the DECUS tapes) that could be of some help? Gary ================================================================================ Note 277.1 [RSX]ASTs in FORTRAN 1 of 10 EISNER::WYANT "SOME call me ..... TOM" 36 lines 6-SEP-1989 15:28 -< You can't do it. And here's how. >- -------------------------------------------------------------------------------- >>> I am writing an RSX application that needs AST support. However, >>> to make the code "supportable", I need to write it in FORTRAN >>> (or some other high-level language - Pascal is available). I >>> have reviewed the relevant DOCs and conclude that I am in for >>> trouble with this combination. The conclusion I draw from the relevant docs is that from DEC's point of view, ASTs in FORTRAN aren't supported, period. So you're damned if you do, and damned if you don't. >>> Can you offer any suggestions (or code samples from the DECUS >>> tapes) that could be of some help? You probably aren't going to get around writing *SOME* MACRO-11. It seems to me that DECnet had at one time some hooks for FORTRAN ASTs, (you had to pass an extra argument to OPNNT to turn it on), but the hooks are unsupported, and in fact undocumented (I stumbled across it while disassembling modules from NETFOR, chasing an *extremely* flakey problem that turned out to be a problem on the VAX on the other end of the link). There are two basic approaches: 1) Write the AST routines in MACRO-11, but don't have them do much. This is my favorite approach. Typically, you just set a local event flag in the AST, and let the mainline do the rest. 2) Write a stub AST in MACRO-11, that stashes registers and otherwise pretties up the stack, and then calls a piece of FORTRAN to do the *real* work. Either way, beware that FCS (and the FORTRAN OTS routines, if you're doing (2)) are NOT reentrant. Don't do FCS I/O (or FORTRAN I/O) from the AST if you're doing it from the mainline, unless you're *VERY* careful. And remember, CALL EXIT does I/O. ================================================================================ Note 277.2 [RSX]ASTs in FORTRAN 2 of 10 EISNER::OSUDAR "John Osudar" 18 lines 6-SEP-1989 15:30 -< We did an entire system this way >- -------------------------------------------------------------------------------- About six or seven years ago, we did an entire control/data acq. system that was AST-driven and was (primarily) written in Fortran. Obviously, the problems arise from Fortran OTS code being non-reentrant. So... you have to avoid the situations that cause problems. We couldn't build our system without using Fortran I/O (and other calls) in the AST portion of the code -- so we had to protect each Fortran I/O statement (or other call that was also used at AST level) with AST disable/enable calls. It wasn't fun doing all that extra work -- but the system worked as we wanted it to. The moral of the story, I guess, is this: it isn't easy, but it's worth doing. If you want more details, or answers to specific questions, fire away... ================================================================================ Note 277.3 [RSX]ASTs in FORTRAN 3 of 10 EISNER::LEDERMAN "Bart Z. Lederman" 6 lines 6-SEP-1989 20:22 -< I've done some ASTs with good results >- -------------------------------------------------------------------------------- I'll also say it's possible, if you avoid OTS stuff within the AST routine (though sometimes it will work, but sometimes isn't always good enough). I have used abort ASTs in RSX programs with good results. I think I wrote an article for the newsletter on this and put it on the SIG tapes some years ago. I could dig up the reference if it would help. ================================================================================ Note 277.4 [RSX]ASTs in FORTRAN 4 of 10 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 17 lines 7-SEP-1989 01:12 -< Fortran AST hints and kinks >- -------------------------------------------------------------------------------- The things you have to remember when using Fortran ASTs: 1) Save and restore the general registers (R0-R5) or you will clobber your mainline. 2) Save and restore the floating-point registers (F0-F5) if you are going to execute *any* FP instructions. 3) Don't call any subroutine (including OTS, Fortran I/O [QIO is OK], etc.) from both mainline and AST routines unless it is re-entrant. Actually, you can do it if you can guarantee that the AST will never interrupt the mainline (careful design or Disable/Enable AST recognition). 4) Compile all Fortran AST routines with traceback disabled. Otherwise, your AST routines will clobber the mainline traceback data. ================================================================================ Note 277.5 [RSX]ASTs in FORTRAN 5 of 10 EISNER::RICE "Gary Rice" 11 lines 8-SEP-1989 10:36 -------------------------------------------------------------------------------- > It seems to me that DECnet had at one time some hooks for > FORTRAN ASTs, (you had to pass an extra argument to OPNNT to > turn it on), but the hooks are unsupported, and in fact > undocumented (I stumbled across it while disassembling modules Now HOW did you know I was doing a DECnet program? Seriously, though if you have any vestigages of theis exercise left, I would very much like to see them. Gary ================================================================================ Note 277.6 [RSX]ASTs in FORTRAN 6 of 10 EISNER::RICE "Gary Rice" 14 lines 8-SEP-1989 10:40 -------------------------------------------------------------------------------- > results. I think I wrote an article for the newsletter on this > and put it on the SIG tapes some years ago. I could dig up the > reference if it would help. Found it on the Fall 84 tape. It was called ABORT.MAC (and came with an ABORT.DOC as well). In the ".DOC", you mentioned a series of articles that appeared in the MultiTasker prior to yours dealing with ASTs in FORTRAN. Does anyone recall these articles (and better yet, know how I can obtain a copy)? Gary ================================================================================ Note 277.7 [RSX]ASTs in FORTRAN 7 of 10 EISNER::WYANT "SOME call me ..... TOM" 8 lines 11-SEP-1989 11:29 -< I trashed it. But ... >- -------------------------------------------------------------------------------- >>> Now HOW did you know I was doing a DECnet program? Seriously, >>> though if you have any vestigages of theis exercise left, I >>> would very much like to see them. I don't have anything left of this particular exercise (I trashed it in disgust when I found out what the REAL problem was). What are you using ASTs for? If it's just to manage the DECnet mailbox, I have a sample to forward you. ================================================================================ Note 277.8 [RSX]ASTs in FORTRAN 8 of 10 EISNER::RICE "Gary Rice" 8 lines 12-SEP-1989 10:10 -------------------------------------------------------------------------------- > are you using ASTs for? If it's just to manage the > DECnet mailbox, I have a sample to forward you. I would like to use DECnet (from a VMS host) to wake up a (hopefully) sleeping task, send it some data, accept some results, and let the task go back to sleep. Gary ================================================================================ Note 277.9 [RSX]ASTs in FORTRAN 9 of 10 EISNER::WYANT "SOME call me ..... TOM" 20 lines 14-SEP-1989 11:25 -< There may be a better way ... >- -------------------------------------------------------------------------------- >>> I would like to use DECnet (from a VMS host) to wake up a >>> (hopefully) sleeping task, send it some data, accept some >>> results, and let the task go back to sleep. If this is ***REALLY*** all it is, I wouldn't bother with the AST. I would just have the VMS host OPEN (UNIT=NETLUN,NAME='RSX::''TASK=RCVR''', ... and then just issue FORTRAN READs and WRITEs to NETLUN. The RSX task RCVR then just gets activated, calls OPNNTW, GNDNTW (I think that's the one, but don't quote me!), ACCNTW, and then the DECnet output and input subroutines. RSX can normally activate a task in a couple hundred milliseconds (and if you FIX it, you can read "microseconds" instead of "milliseconds" in that statement), whereas VMS would consume several seconds to create the network process and fault in the image. Indeed, considerable effort has gone into optimizing RSX for just this sort of thing. ================================================================================ Note 277.10 [RSX]ASTs in FORTRAN 10 of 10 EISNER::RICE "Gary Rice" 13 lines 15-SEP-1989 10:19 -------------------------------------------------------------------------------- > If this is ***REALLY*** all it is, I wouldn't bother with the > AST. I would just have the VMS host > OPEN (UNIT=NETLUN,NAME='RSX::''TASK=RCVR''', ... > and then just issue FORTRAN READs and WRITEs to NETLUN. Well, there IS a bit more to it than that, but I LIKE your idea. After working on other operating systems, I tend to forget that RSX does a real good job of task management. It is DEFINITELY better to have a lot of little tasks than one BIG task. Thanks. Gary  ================================================================================ Note 278.0 [RSTS]20th anniversary? 4 replies EISNER::SCOPELLITI "Whatsa behind is uva no importan" 8 lines 6-SEP-1989 20:17 -------------------------------------------------------------------------------- At DECUS/Atlanta I heard about a 20th anniversary event for RSTS/E scheduled for the Fall DECUS. Gave my card to someone looking for volunteer help - old war stories, manuals, memorabilia, etc. (since I was a happy user of RSTS/E for a number of years V5B -> V7.2). Haven't heard word one... What happened? ================================================================================ Note 278.1 [RSTS]20th anniversary? 1 of 4 EISNER::KENNEDY "Terry Kennedy" 13 lines 7-SEP-1989 04:01 -< Ummm... >- -------------------------------------------------------------------------------- > At DECUS/Atlanta I heard about a 20th anniversary event for RSTS/E > scheduled for the Fall DECUS. Gave my card to someone looking for > volunteer help - old war stories, manuals, memorabilia, etc. (since I > was a happy user of RSTS/E for a number of years V5B -> V7.2). It's scheduled for New Orleans, Spring '90. Due to some last-minute political problems 8-( some of the preliminary events scheduled for Fall '89 were deleted (with full erase patterns being run 8-). The people involved may still be shell-shocked, or they may just be busy with real jobs. I'll forward your comment to them. Terry Kennedy RSTS/E Newsletter Editor (sort of) ================================================================================ Note 278.2 [RSTS]20th anniversary? 2 of 4 EISNER::SCOPELLITI "Whatsa behind is uva no importan" 2 lines 12-FEB-1990 00:10 -< Still in wait-state >- -------------------------------------------------------------------------------- So.. what's the story? Haven't heard/seen a thing about the 20th anniversary event. ================================================================================ Note 278.3 [RSTS]20th anniversary? 3 of 4 EISNER::KENNEDY "Terry Kennedy" 6 lines 12-FEB-1990 22:08 -< In the preliminary program? >- -------------------------------------------------------------------------------- > So.. what's the story? Haven't heard/seen a thing about the 20th > anniversary event. Should be a feature article in the preliminary info packet. (At least there had beeter be - they made me jump through hoops to get the bulldog logo to the officee to meet the deadline...) ================================================================================ Note 278.4 [RSTS]20th anniversary? 4 of 4 EISNER::SCOPELLITI "Whatsa behind is uva no importan" 2 lines 5-MAR-1990 17:18 -< Trying to avoid a conflict! >- -------------------------------------------------------------------------------- Looks like the RSTS birthday party made it in.. however, one item was missing: What time is the party on Wednesday night?  ================================================================================ Note 279.0 [RSX]What's my queue entry number? 1 reply EISNER::CHRISTIAN "Michael Christian" 34 lines 27-SEP-1989 10:32 -------------------------------------------------------------------------------- Does anybody know how to get an entry number for a job in a batch queue? I have a job that I run at 17:30 every day. At the end of the command file, I re-submit it for 17:30:TOMORROW. Upon occasion, it needs to be released earlier in the day. It is fairly simple to do a SHQ and then QUE /EN:n/MOD/AF, but I would like other users to be able to release this job without having to worry about entry numbers. I tried to redirect the output of the SHQ command by: >PIP QMGXYZ.TSK=QMGCLI.TSK (so that the following commands would not mess up PRI, SUB, eveyone else's QUE) >INS QMGXYZ/TASK=QUETx (where X is whatever terminal I am on) >REA QUETx 2 file >QUE QUEUE:/LI but this didn't work. I looked at the source code for SHOWQ in [25,10], and the output device for the show is attached, but never openned. I guess that I could write a little utility that looks up the information in the queue file just like QUE does and then spawn the QUE /MOD command. Is this the correct way to do it, or is there as easier way? Have I forgotten something simple? This seems alot like swatting flies with a car. Maybe I should just tell my users to look up the entry number themselves, but something a little more user friendly would be nice. ================================================================================ Note 279.1 [RSX]What's my queue entry number? 1 of 1 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 9 lines 27-SEP-1989 19:13 -< submit a job to sho the que >- -------------------------------------------------------------------------------- > Does anybody know how to get an entry number for a job in > a batch queue? If you want a directory listing of what BRU has on tape, you either set host /log=xxx from a vax, or submit a batch job and read the log file. You could do the same here. Fire of a batch job, and when it finishes openr the log file. There must be a better way, but that should work.  ================================================================================ Note 280.0 [RSX]Need a 'CNTL-S' Killer... 6 replies EISNER::CONKLIN "Dale J. Conklin" 16 lines 28-SEP-1989 16:32 -------------------------------------------------------------------------------- Anyone know of a 'CNTL-S' killer routine out there?? We're operating seven PDP-11's (44's and 84's) here at Chevron's lovely El Segundo CA refinery and are constantly plagued by some mysterious force which will 'X-OFF' a DZ or DH port. The ports are connected to slaved terminals and such scattered out among the bowels of the refinery via line drivers and MUX's and twisted pair wires (or telephone lines). Sure, a wholesale boot will fix it, and so will plugging in a VT-100 and entering a 'CNTL-Q'. Seems like there has got to be a better (software) way to tell that port to 'X-ON'. We're running RSX-11M+ V4.1. Any ideas??? Thanks... ================================================================================ Note 280.1 [RSX]Need a 'CNTL-S' Killer... 1 of 6 EISNER::POKEL "Lisa J. Pokel" 10 lines 28-SEP-1989 17:12 -< Can send ^Q with FORCE >- -------------------------------------------------------------------------------- > Seems like there has got to be a better (software) > way to tell that port to 'X-ON'. We're running RSX-11M+ V4.1. See my note 138.10 about FORCE from Spring '84 SIG tape. I use it all the time to send ^Q's to slaved printers, modems that won't answer, terminals that are "dead," etc. I haven't tried it on M+4.1 but source is provided on tape (make sure you get the "right" FORCE, there are several). ljp ================================================================================ Note 280.2 [RSX]Need a 'CNTL-S' Killer... 2 of 6 EISNER::WYANT "SOME call me ..... TOM" 12 lines 28-SEP-1989 17:14 -< You can roll your own, if you're careful >- -------------------------------------------------------------------------------- >>> < Note 145.0 by EISNER::CONKLIN "Dale J. Conklin" > >>> Anyone know of a 'CNTL-S' killer routine out there?? A lot of people have written their own - you just have to duplicate the relevant TT: driver code, and add a command interface. We did one to cover DH, DL, DJ, and DZ (which tells you how long ago it was). This was a big issue while the LA180 was still around, but has since died down. I'd love to post a code fragment, but my subscription expires the day after tomorrow, and the renewal has gone through the mill VERY slowly. If you're desparate, see my Who-am-I for how to get me. ================================================================================ Note 280.3 [RSX]Need a 'CNTL-S' Killer... 3 of 6 EISNER::WYANT "SOME call me ..... TOM" 10 lines 28-SEP-1989 17:18 -< Accept no substitutes >- -------------------------------------------------------------------------------- >>> < Note 145.1 by EISNER::POKEL "Lisa J. Pokel" > >>> -< Can send ^Q with FORCE >- >>> See my note 138.10 about FORCE from Spring '84 SIG tape. ... >>> I haven't tried it on M+4.1 but source is provided on tape (make sure you get the "right" FORCE, there are several). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There sure are. And most of them (including the "original" M+ V1.0 one) only stuff command lines to MCR. ================================================================================ Note 280.4 [RSX]Need a 'CNTL-S' Killer... 4 of 6 EISNER::TINKELMAN "Bob Tinkelman - CCA" 9 lines 28-SEP-1989 22:18 -< DECUS had it then >- -------------------------------------------------------------------------------- RE: < Note 145.0 by EISNER::CONKLIN "Dale J. Conklin" > > Anyone know of a 'CNTL-S' killer routine out there?? One was published in the MultiTasker (way back in the years before the combined SIG Newletters). As I recall it took the terminal (eg TT32:) as a command line argument and then went and diddled the UCB (?) to reset the ^S bit. If you can't dig up a copy, let me know (mail here or see my WHO_AM_I entry). I can probably find it somewhere in my office. ================================================================================ Note 280.5 [RSX]Need a 'CNTL-S' Killer... 5 of 6 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 10 lines 28-SEP-1989 22:47 -< It works just fine on M+ >- -------------------------------------------------------------------------------- > (make sure you get the "right" FORCE, there are several). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > There sure are. And most of them (including the "original" M+ > V1.0 one) only stuff command lines to MCR. We already went around on this one. The one Lisa is referring to DOES stuff characters to any task. However, it is for M+ only and I haven't gotten around to rewriting it for M. ================================================================================ Note 280.6 [RSX]Need a 'CNTL-S' Killer... 6 of 6 EISNER::CONKLIN "Dale J. Conklin" 8 lines 2-OCT-1989 16:47 -< Muchas Gracias..... >- -------------------------------------------------------------------------------- Lisa, Tom, Bob, Alan..... Thanks for the ideas. I'll try to scrounge up that DECUS tape. Incidentally, I read Lisa's 138.10 after I left the distress call last week and was very encouraged. Currently we infrequently use a version locally identified FRCCMD which only sends MCR command lines as you caution...  ================================================================================ Note 281.0 [RSX]DRV11s and DRV11-Js with RSX 7 replies EISNER::MAYHEW "Bill Mayhew" 69 lines 26-OCT-1989 16:32 -------------------------------------------------------------------------------- I have a situation where an old 11/03 is performing some "real-time" control tasks using a bunch (4) of DRV11s and/or old Heathkit equivalents. The software, including the "operating system", is completely home-grown. There is no mass storage local to the system; software changes are accomplished by building the programs on an Ultrix-11 system and downloading them to the 11/03 over an RS232 line. Normal communications with the 11/03 is accomplished via the same path. The 11/03 is getting hard to maintain, and adding/debugging new features in the software is a pain. (The hardware is 10+ years old.) The other functions that the Ultrix-11 system (a MicroPDP-11/73, btw, so it uses the KDJ11-Bx) was performing have all migrated elsewhere, so that it is now solely servicing the 11/03, as a "data collector" and as a software development platform. We would like to replace the 11/03 with the 11/73, and (preferably) run some variant of RSX on it. We can move the applications program easily enough, but I have questions about RSX's ability to communicate with the DRV11s. (Assume that the Heathkit boards are "history" and will be replaced either by multiple real DRV11s, or the whole bunch of parallel boards will be replaced by one DRV11-J.) The SPD for M-Plus indicates that the DRV11 is supported, sort of, but the language is ambiguous enough to make me worry. It says, under "Supported Hardware": "- Laboratory I/O Subsystem configured using the following options: - AA11-K ... - AAV11-A, ADV11-A, KWV11-A, and DRV11 real-time options" (and it goes on to mention some other stuff.) The SPD doesn't mention the DRV11-*J* at all, nor does it indicate a limit on the number of DRV11s. Questions: 1. Is "Laboratory I/O Subsystem" some specific _thing_? Since it's capitalized, I tend to think so, but I've not heard of it in DECspeak before. 2. Does a DRV11 (not -J) work on an 11/73 (with 22-bit addressing)? I believe it's only a 16-bit-addressed device... do I have to play funny software games with it to get it into the 22-bit-addressed device address space, or does RSX do it for me, or is it unnecessary? 3. Does a DRV11-J work? The handbook I grabbed that has a writeup on the DRV11-J doesn't indicate if it expects a 16- or a 22-bit bus address. 4. Is a DRV11-J supported? (different question from (3) :-} ) 5. If there are problems using either the DRV11 or the -J with the 11/73, will swapping in an 11/23-Plus (KDF11, quad-board) CPU help? (I think not, still 22-bit addressing after all.) 6. If the DRV11s or DRV11-J are not supported in the way I need them, I should be able to build my user task with access to the I/O page so that I can twiddle the registers myself, right? Again, are there any "gotchas" here with respect to 16-vs.-22-bit addressing? 7. Any other gotchas or other considerations I should bear in mind? ================================================================================ Note 281.1 [RSX]DRV11s and DRV11-Js with RSX 1 of 7 EISNER::DELARISCH "Arnold S. De Larisch" 61 lines 26-OCT-1989 22:54 -< Confusion among Real-Time devices! >- -------------------------------------------------------------------------------- >> < Note 146.0 by EISNER::MAYHEW "Bill Mayhew" > >> -< DRV11s and DRV11-Js with RSX >- >> The SPD for M-Plus indicates that the DRV11 is supported, sort >> of, but the language is ambiguous enough to make me worry. It >> says, under "Supported Hardware": >> "- Laboratory I/O Subsystem configured using the following options: >> >> - AA11-K ... >> >> - AAV11-A, ADV11-A, KWV11-A, and DRV11 real-time options" >> (and it goes on to mention some other stuff.) >> >> The SPD doesn't mention the DRV11-*J* at all, nor does it indicate >> a limit on the number of DRV11s. >> Questions: >> 1. Is "Laboratory I/O Subsystem" some specific _thing_? Since it's >> capitalized, I tend to think so, but I've not heard of it in DECspeak >> before. This 'reference' I believe is to the Laboratory Peripheral Accelerator or LPA-11 I/O subsystem. This system (My University Still owns/uses one) is really neet. A seperate UNIBUS backplane has a slave KMC11 microprocessor, a buffer board, and a master KMC11 microprocessor board which sits on the host 'UNIBUS'. The backplane is populated with Real-Time boards, Micro Code is loaded into the KMC11, and the LPA-11 passes back 'full' buffers from your Lab stuff. It unloads the interrupt processing from the host computer (and bus traffic). Neet for 1977! Anyway, back to your question, the devices that plugged to this Laboratory I/O Subsystem had the -K designation after them. The devices that were supported were AD11-K, AA11-K, DR11-K, KW11-K, AM11-K. I suspect that whomever typeset the SPD may have run-on the 'realtime' devices. As for the DRV11-J supporting '22 Bit addressing' the answer is YES for DEC's board. To quote DEC's Microcomputer Products Handbook EB 26078 (copyright 1985), Chapter 37 - Introduction to Parallel Interfaces ... DRV11-J High-Density Parallel Interface "The DRV11-J is a high-density parallel interface providing four 16-line ports. It also includes an advanced interrupt structure that accepts interrupt requests from up to 16 I/O lines, generating up to 16 individual vector addresses. It supports program selection of fixed or rotating interrupt priorities within the interface. Two DRV11-Js can be connected as a link between two Q-buses. The DRV11-J supports 16-, 18-, or 22-bit addressing." As for How many are supported, the hardware manual doesn't indicate, however only 3 address are 'reserved' on the I/O map for the DRV11-Js, additional devices have to come out of the floating address space. Hope this helps! -Arnold ================================================================================ Note 281.2 [RSX]DRV11s and DRV11-Js with RSX 2 of 7 EISNER::MAYHEW "Bill Mayhew" 15 lines 27-OCT-1989 00:12 -< I think support is unrelated to LPA11 >- -------------------------------------------------------------------------------- > This 'reference' I believe is to the Laboratory Peripheral > Accelerator or LPA-11 I/O subsystem. > ...the devices that plugged to this Laboratory I/O Subsystem > had the -K designation after them... > I suspect that whomever typeset the SPD may have run-on the > 'realtime' devices. Hmm... I don't think so, particularly since there are several Q-bus items listed which would clearly not go along with the LPA11. Also, the LPA11 is listed separately in the SPD in its own right. However, thanks for the clarification on the DRV11-J addressing! I don't think we'd need more than one. Now... anybody know about the RSX support issues? ================================================================================ Note 281.3 [RSX]DRV11s and DRV11-Js with RSX 3 of 7 EISNER::CHRISTIAN "Michael Christian" 14 lines 27-OCT-1989 09:36 -< It will work. Go for it. >- -------------------------------------------------------------------------------- >> Now... anybody know about the RSX support issues? It's been a few years, but I have used two DRV11-J boards simultaneously on both Micro-11/23 and Micro-11/73 systems. We were running RSX-11M V3.mumble at the time. The technique that we used, though, was nothing new, and should be supported on all versions/flavors of RSX. We just directly mapped to the DRV11 boards in the I/O page and performed memory mapped I/O just as if the DRV11 boards were Fortran comman arrays. No problems. Worked great for years. I haven't been using DRV11 boards for about 4 years, but only because I changed companies, and I am now using a different I/O subsystem. ================================================================================ Note 281.4 [RSX]DRV11s and DRV11-Js with RSX 4 of 7 EISNER::MAYHEW "Bill Mayhew" 1 line 27-OCT-1989 12:07 -< Thanks! >- -------------------------------------------------------------------------------- ================================================================================ Note 281.5 [RSX]DRV11s and DRV11-Js with RSX 5 of 7 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 57 lines 27-OCT-1989 15:37 -< Sounds like you have a fun task ahead of you >- -------------------------------------------------------------------------------- > (Assume that the Heathkit boards are "history" > and will be replaced either by multiple real DRV11s, or the whole > bunch of parallel boards will be replaced by one DRV11-J.) You should note that the Heathkit parallel interfaces (H11-2) are *not* programmed the same as the DEC DRV11. They "look" like DEC DL11(DLV11) type devices. Obviously, the external connections are not the same either. You could actually use the Heath H11-2 interfaces with the RSX terminal driver! > 2. Does a DRV11 (not -J) work on an 11/73 (with 22-bit addressing)? > I believe it's only a 16-bit-addressed device... do I have to play > funny software games with it to get it into the 22-bit-addressed > device address space, or does RSX do it for me, or is it unnecessary? Sure, no sweat. DMA devices are the only ones you have to worry about regarding 16/18/22 bit addressing. > 3. Does a DRV11-J work? The handbook I grabbed that has a writeup > on the DRV11-J doesn't indicate if it expects a 16- or a 22-bit > bus address. See above. > 4. Is a DRV11-J supported? (different question from (3) :-} ) There is no DEC-supplied driver for the DRV11-J. This device is a real beast to program for. My primary advice is to get the documentation on the Intel chip that DEC uses on the DRV11-J. Another DECUServe subscriber, Jim McGlinchey, once wrote an RSX driver for the DRV11-J, but I doubt that it would serve your needs. Perhaps he could be persuaded to write one for you. > 5. If there are problems using either the DRV11 or the -J with the > 11/73, will swapping in an 11/23-Plus (KDF11, quad-board) CPU help? > (I think not, still 22-bit addressing after all.) No problems, since these devices are all PIO, not DMA. > 6. If the DRV11s or DRV11-J are not supported in the way I need > them, I should be able to build my user task with access to the > I/O page so that I can twiddle the registers myself, right? Again, > are there any "gotchas" here with respect to 16-vs.-22-bit addressing? Again, no problems with addressing, other than the usual RSX task-to-physical addressing conversion. However, for PIO devices, this should not be an issue. I *strongly* suggest that you use a driver, rather than building support into your tasks. This would allow the tasks to have their full address space, be non-privileged and easier to maintain. > 7. Any other gotchas or other considerations I should bear in mind? I think I've hit them all above, but be sure to allow pleanty of time for the learning curve(s). ================================================================================ Note 281.6 [RSX]DRV11s and DRV11-Js with RSX 6 of 7 EISNER::MAYHEW "Bill Mayhew" 16 lines 27-OCT-1989 16:49 -< Probably not so tough (I hope) >- -------------------------------------------------------------------------------- Alan, Thanks for the detailed response. The application's use of the H11-2s and DRV11s is VERY straightforward: read-a-word, or write-a-word. I think there may be one sub-application that is interrupt-driven on input data, but most of it is simply an issue of sampling the input-data register every n clock-ticks, or altering the output-data register. Going from the H11-2s to DRV11s will probably simplify the code ... I agree in general about the preference of using a driver. However, this application's use of the I/O is _so_ simple, and the budget so limited, that I suspect it may not be worth the effort... or perhaps that would be a feature added in a future unnamed major release. :-} ================================================================================ Note 281.7 [RSX]DRV11s and DRV11-Js with RSX 7 of 7 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 9 lines 30-OCT-1989 00:34 -< Handling interrupts in a task is tricky >- -------------------------------------------------------------------------------- > I agree in general about the preference of using a driver. However, > this application's use of the I/O is _so_ simple, and the budget > so limited, that I suspect it may not be worth the effort... As long as you aren't using interrupts from the devices, I will agree. If you *are* using device interrupts, writing a driver will save you lots of grief over using CINT$ (Connect to Interrupt). CINT$ is only appropriate in *very* specialized applications.  ================================================================================ Note 282.0 [RSX]MAIL between RSX and VMS 8 replies EISNER::CHRISTIAN "Michael Christian" 27 lines 27-OCT-1989 11:51 -------------------------------------------------------------------------------- I am wanting to be able to send/receive mail to/from a VAX node. I have a couple of products in question if anybody would be willing be comment. I am on RSX-11M-Plus V4.2 and have DECNET-11M+ V4.0 installed. DECmail-11 is one product. If I buy DECmail-11 and install it, will I be able to magically receive mail from a VMS node? The SPD for the product is a little vague. It indicates that it is able to send and receive mail from VMSmail, use the VMS Message Router and VMSmail Gateway software, but it is unclear if I would have to write an interface for any or all of the above products. On a side note, I ran across an SPD for Message Router for RSX-11M-Plus. It says that it supports Phase III and Phase IV networks. We already have Message Router installed on a VMS node in our network. Since RSX DECNET is not currently planning to go to Phase V, is this product even worth investigating? The second mail product that I have found is a mail utility that I found on a DECUS tape. (I can't find the author or date of the tape.) It allows an RSX node to communicate with VMS mail. There are four tasks called MAIL, MAILSRV, NETSND and MAINOT. Has anybody used this product? Does anybody know if it will communicate the VMS V5.x? Will it work under RSX-11M-Plus V4.2? ================================================================================ Note 282.1 [RSX]MAIL between RSX and VMS 1 of 8 EISNER::MAYHEW "Bill Mayhew" 11 lines 27-OCT-1989 12:14 -< DECmail-11 _probably_ the answer >- -------------------------------------------------------------------------------- I have used A-to-Z Electronic Mail on RSX to send mail between VMS and RSX systems (VMS systems running just plain vanilla VMSmail). It works, nothing fancy required. It is now a required product. However, I _believe_ (can't swear to it though) that, under the hood (or, "under the menus"?) it is DECmail-11. So if nobody else can give you a firm answer, you can take this as corroboration of the _probability_ that DECmail-11 will be fine. I can't find Message Router for M-Plus in my current SPD books (from the Digital Reference Service). What's the SPD number? I suspect it may be retired, too. ================================================================================ Note 282.2 [RSX]MAIL between RSX and VMS 2 of 8 EISNER::CHRISTIAN "Michael Christian" 12 lines 27-OCT-1989 17:22 -------------------------------------------------------------------------------- >> I can't find Message Router for M-Plus in my current SPD books (from >> the Digital Reference Service). What's the SPD number? I suspect >> it may be retired, too. I found it from an SPD search on DSIN. The number is 14.29.02. The DEC part numbers are QY321-** for QBUS and QP320-** for UNIBUS. There is a copyright date of 1989, but further down in the SPD under the MINIMUM HARDWARE REQUIRED is a date of 1984. ================================================================================ Note 282.3 [RSX]MAIL between RSX and VMS 3 of 8 EISNER::DELARISCH "Arnold S. De Larisch" 35 lines 27-OCT-1989 19:57 -< DECUS version of Mail-11 works rather well ... for the price! >- -------------------------------------------------------------------------------- >> < Note 147.0 by EISNER::CHRISTIAN "Michael Christian" > >> -< MAIL between RSX and VMS >- >> DECmail-11 is one product. If I buy DECmail-11 and install >> it, will I be able to magically receive mail from a VMS node? Yup! No 'Store-and-forward' but normal mail works fine! >> The second mail product that I have found is a mail utility >> that I found on a DECUS tape. (I can't find the author or >> date of the tape.) It allows an RSX node to communicate >> with VMS mail. There are four tasks called MAIL, MAILSRV, >> NETSND and MAINOT. Has anybody used this product? Does anybody >> know if it will communicate the VMS V5.x? Will it work >> under RSX-11M-Plus V4.2? Well, interesting question. The 'DECUS' offering was 'anomously' submitted to the RSX SIG tapes twice. The latest version was executables only, the eariler is available in source code form. It works fine under RSX-11M-PLUS V3.x and seemed to work under at least one 4.x version (sorry, I can't be more explicit). The software is written in 3 languages: Macro-11, FORTRAN 77, and an unreleased version of BASIC. You can modify/hack all but the BASIC program (which actually performs the send). There are a couple of 'little things' that need fixing. In particular, the 'Personal Name' is extracted by using a $GIN directive. Its no big deal, just a changed offset. It works real good, lasts 'long time'. Consider, this software was released in the earily 1980s (during Phase III DECnet) and STILL works under Phase IV. It's a 'little' Klugy ... but its FREE! If its a 'nice to have' function, the DECUS offering is what I'd use. If you are looking for a 'finished/polished' product, buy DECmail-11. -Arnold ================================================================================ Note 282.4 [RSX]MAIL between RSX and VMS 4 of 8 EISNER::KENNEDY "Terry Kennedy" 9 lines 28-OCT-1989 05:12 -< DECmail-11 fine by us >- -------------------------------------------------------------------------------- >> DECmail-11 is one product. If I buy DECmail-11 and install >> it, will I be able to magically receive mail from a VMS node? > Yup! No 'Store-and-forward' but normal mail works fine! The RSTS/E version of DECmail-11 (V3.1 is current) does do store+forward. If the VAX is down, is asks "queue mail for later delivery?". It is a very nice product - our users vastly prefer it to VMS mail (and we've got 7,500 of 'em [user's that is], spread out over a dozen or so 11's). ================================================================================ Note 282.5 [RSX]MAIL between RSX and VMS 5 of 8 EISNER::MAYHEW "Bill Mayhew" 10 lines 30-OCT-1989 12:05 -< Message Router for M-Plus: Retired >- -------------------------------------------------------------------------------- < Note 147.2 by EISNER::CHRISTIAN "Michael Christian" > > I found [Message Router for RSX-11M-Plus] from an SPD search on DSIN. > The number is 14.29.02. Aha! That number and product title shows up under the "Products No Longer Marketed Index" in the SPR books, so this is evidently a retired product. ================================================================================ Note 282.6 [RSX]MAIL between RSX and VMS 6 of 8 EISNER::HUDGINS "Jerry Hudgins" 4 lines 31-OCT-1989 10:53 -< DECmail does a good job >- -------------------------------------------------------------------------------- I'm using RSX DECmail-11 on a network with VMS nodes and it works just fine. Does the store-and-forward as previously described for RSTS/E. Actually a very nice package, I think. Recommended, for what it's worth. ================================================================================ Note 282.7 [RSX]MAIL between RSX and VMS 7 of 8 EISNER::WYANT "SOME call me ..... TOM" 17 lines 2-NOV-1989 13:40 -< Go for it! >- -------------------------------------------------------------------------------- >>> < Note 147.6 by EISNER::HUDGINS "Jerry Hudgins" > >>> -< DECmail does a good job >- Sure does. In fact, the store-and-forward works better than the VMS Message Router (not hard!). And I think after using it you'll throw rocks at VMS mail. For one thing, DECmail-11 lets you edit all message attributes (title, addressees, ...) AFTER the message is created. And if it can't find one of the addressees, you get a chance to corect the name. Too bad VMS 5.0 came out. Another great feature of DECmail-11 used to be getting calls from people asking "how did you get MAIL to do 'cc:'?" Answer: BUY a PDP-11! ================================================================================ Note 282.8 [RSX]MAIL between RSX and VMS 8 of 8 EISNER::CHRISTIAN "Michael Christian" 9 lines 4-NOV-1989 16:40 -< Thanks for all of the input >- -------------------------------------------------------------------------------- For the moment, I took the DECUS version and worked it over a little to meet the needs of our site. It seems to be working very well. Imagine, just two hours after I had it installed, my lowly litle PDP-11/44 end node was routing mail messages between two VAX cluster nodes! Ain't science wonderful.  ================================================================================ Note 283.0 [RSX]Snookered again ? 1 reply EISNER::SIMONS "Paul, Not that CONVEX!" 12 lines 30-OCT-1989 17:08 -------------------------------------------------------------------------------- My management was convinced that swapping a set of TU45's for a TU80 was a good deal. New technology and all that. Since then our operations people have taken to bringing cots with them on the days we do a full backup. Is there a way to make a TU80 wake up ? My understanding is that BRU (wonderful though it is ;-)} ) can't supply data fast enough to keep the TU80 in streaming mode; and that the TU81+ solved that problem by providing a hardware cache. Since I have no chance of getting a TU81+, is there another solution ? Can any of the tape utilities on the SIG tapes cause a TU80 to stream ? The TU80 has a PERTEC interface, right ? Could I get a helical-scan tape drive that might be as slow, but operators could put on at night and forget til morning ? We are running M+ 4.1. ================================================================================ Note 283.1 [RSX]Snookered again ? 1 of 1 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 55 lines 30-OCT-1989 19:04 -< Tu80 is PERTEC, but 8mm w/Pertec not cheap >- -------------------------------------------------------------------------------- None of this may solve your problem, but here are various comments. >Is there a way to make a TU80 wake up ? Not being plagued with a streamer, I am not sure about this, but I seem to recall that there is a new switch for multi buffering for streamers, but that in invalid with /VER or some other such stupidity. If DEC would make an I/D version of BRU, or do something else worth while with our SIZEABLE s/w maint $s, there would be less incentive to drop the contract and there is some chance of making it run faster. If maint $s are not your problem, and if your (mis)managment is looking the other way, you can get used TU77 masters for < $1k, and slaves for even less. An RH11 (unless you are on an 11/70) is a few hundred more, but try to convince your TU77 source to include it so you can help him by unloading Tu77s he can't sell. The TU77 will scream through BRU tapes, but MAINT $s, if you don't fix them yourself, will kill you. What you really want is a vacuum column GCR drive, or dual ported disks and use the new BAC on a VAX to do the work. > The TU80 has a PERTEC interface, right ? Could I get a helical-scan > tape drive that might be as slow, but operators could put on at night > and forget til morning ? Yes it is a Pertec interface. And yes it is really a Dilog DU132 controller but with proms that only support 1 drive rather than 4. But there is only 1 company making a Pertec interface for 8 mm drives, and they charge so much more that it is MUCH cheaper to buy a new SCSI controller for your SCSI 8MM drive. But now check out DAT drives (also SCSI) before you buy. Now here is ANOTHER solution for your style managment ... Used TU80s are just under $1000 now, and a used Dilog DU132 should be cheap. (If you have to Buy the controller new, get the 142, or if they have the TMSCP version for U bus (like the Q bus DQ153) GET IT instead.) Hang several used TU80s on the same controller. I know BRU supports at least 2 drives (e.g. ... MS0:,MS1:), does it support 4? (... MS0:,MS1:,MS2:, MS3:)? By the time your operators return in the morning, it will be about time to hang up 4 more tapes. I don't know what size disks you are using, but also consider a monster 5 1/4 wini and BRU to it or to VDs on it if you need to backup several small disks. Spinning them off to tape later will then be fast as the wini copies will be defraged. If you have a spare drive identical to a main SYS drive and want to get it backed up FAST, use the SHADOW support M+ has, and when the catchup copy is done, kill the shadowing and you have a backup you can casually either remove (if removable), or spin off to tape.  ================================================================================ Note 284.0 [RT11]RT-11 PHYSICAL devices No replies EISNER::CROWELL "Shefth of the Fourth Order" 57 lines 1-NOV-1989 12:06 -------------------------------------------------------------------------------- There is an undocumented (i.e. unsupported) feature in RT-11's USR to support bypassing logical name tables in file operations (i.e. to force the .LOOKUP or .ENTER of a file on a specific physical device even if the name of that device has been "ASSIGNED" elsewhere). Moreover, for .LOOKUP, .ENTER, and .RENAME, there is a provision for a user subroutine to be called by USR in order to handle extra words in the directory entry. QUESTION: Does anyone know whether TSX-Plus provides the same "features" and in the same guise? EMT Parameter blocks: .LOOKUP .ENTER .RENAME +-------+-------+ +-------+-------+ +-------+-------+ | 1 | chan | | 2 | chan | | 4 | chan | +-------+-------+ +-------+-------+ +-------+-------+ | devblk + 1 | | devblk + 1 | | devblk + 1 | +---------------+ +---------------+ +---------------+ | sequence num | | length | | (ignored) | +---------------+ +---------------+ +---------------+ | (ignored) | | sequence num | | (ignored) | +---------------+ +---------------+ +---------------+ | usersub (+1) | | usersub (+1) | | usersub (+1) | +---------------+ +---------------+ +---------------+ devblk = Address of RAD50 file specification Using 'devblk+1' tells USR to look at 5th word. usersub = Address of user subroutine to be called by USR (usually to handle extra directory entry words) Using 'usersub+1' forces bypass of logical name tables when finding device specified in . There are similar constructs for .FPROT, .GFDAT, .SFDAT, .GFSTA, .SFSTA, .GFINF, and .SFINF, but there is no callback to . Only bit-0 of the fifth word is examined to determine whether to bypass logical name tables. Bypassing logical name tables is also possible in .DSTAT and .FETCH by having an odd adress for the device specification. e.g. .DSTAT addr,#devblk+1 .FETCH addr,#devblk+1 Before I go off doing some newsletter article about this or presenting it at a symposium, I'd like to know whether TSX-plus provides these functions; and if so, if they work the same way. Anybody know?  ================================================================================ Note 285.0 [RSX]no more MCR in M+? 2 replies EISNER::OSUDAR "John Osudar" 4 lines 13-NOV-1989 17:47 -------------------------------------------------------------------------------- My partner heard a rumor (while at the symposium in Anaheim) that MCR will not be included in the next release of RSX-11M-Plus. In his words, "Is this an ugly rumor or the truth?" Does anyone know? ================================================================================ Note 285.1 [RSX]no more MCR in M+? 1 of 2 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 8 lines 13-NOV-1989 23:40 -< MCR is not likely to go away >- -------------------------------------------------------------------------------- > My partner heard a rumor (while at the symposium in Anaheim) that > MCR will not be included in the next release of RSX-11M-Plus. > In his words, "Is this an ugly rumor or the truth?" Since this would require major changes to DCL, I doubt that it will ever happen. Also, consider the fact that most of DEC's command files (for example, SYSGEN) are written for MCR. I don't think you have to worry. ================================================================================ Note 285.2 [RSX]no more MCR in M+? 2 of 2 EISNER::WYANT "SOME call me ..... TOM" 11 lines 20-NOV-1989 11:47 -< I wouldn't worry about losing MCR >- -------------------------------------------------------------------------------- >>> Since this would require major changes to DCL, If anything, Alan understates the case. Bear in mind that right now, as far as RSX is concerned, DCL is a "user-written CLI" - that is, it works by translating DCL commands into MCR commands, then passing them to MCR using the RPOI$ directive (that's why DCL has SET DEBUG). Ditching MCR would mean rewriting everything but the parser. I wouldn't loose any sleep over it.  ================================================================================ Note 286.0 [RSX]Which AST gets delivered first? 2 replies EISNER::CHRISTIAN "Michael Christian" 29 lines 15-NOV-1989 09:31 -------------------------------------------------------------------------------- I have an application running on M+ that is gathering data over an RS-232 link. I also have a timeout AST queued in case a QIO fails to complete. The order of things is: - Mark Time with AST - Queue Read with AST - twiddle thumbs - RSX comes along and schedules other tasks - Read finishes while RSX off doing other things - Mark time finishes during this same interval while RSX is still busy My question is: Which AST will be delivered first, the QIO or the mark time? Is it based on which one was queued first, which one finished first, or if there are multiple ASTs available when a task is eligible to run, is there a specific order they are delivered (such as all mark times first, all QIOs second, etc.) ? I seem to be having some synchronization problems, and I am trying to see if the AST delivery is getting in my way. I realize that I am queuing the mark time before the QIO. Normally you would do it the other way around, but in this application I can't. I know that the mark time and the QIO are both getting queued without RSX causing a task reschedule in between them. ================================================================================ Note 286.1 [RSX]Which AST gets delivered first? 1 of 2 EISNER::HUDGINS "Jerry Hudgins" 4 lines 16-NOV-1989 07:58 -< FIFO on completion (I think) >- -------------------------------------------------------------------------------- I have always operated under the assumption that AST's are delivered FIFO based on completion, and have never seen any behavior to suggest otherwise. Does someone with the sources (I have Micro/RSX these days) have the definitive answer? ================================================================================ Note 286.2 [RSX]Which AST gets delivered first? 2 of 2 EISNER::MCGLINCHEY "DECUS Board of Directors" 10 lines 16-NOV-1989 17:18 -< Always FIFO >- -------------------------------------------------------------------------------- AST's are always queued FIFO to the requesting task. You can count on it. __ Jim McGlinchey  ================================================================================ Note 287.0* [PDPBAS]Proposal to merge this conference with others 1 reply EISNER::MAYHEW "Bill Mayhew" 13 lines 17-NOV-1989 17:43 -------------------------------------------------------------------------------- A proposal has been put forward in NEW_CONFERENCE_IDEAS to merge the PDP_BASIC, PRO_300, RT_11, RSX, and RSTS_OS conferences into one single PDP-11 conference. If you have anything (pro or (especially) con) to say about this, please do so soon. The discussion can be found in topic 81 of NEW_CONFERENCE_IDEAS, particularly notes 81.11 and later. If NEW_CONFERENCE_IDEAS is not in your Notebook, you can press keypad-7 right now to add it. -Bill, moderator of NEW_CONFERENCE_IDEAS ================================================================================ Note 287.1 [PDPBAS]Proposal to merge this conference with others 1 of 1 EISNER::MAYHEW "Bill Mayhew" 9 lines 27-MAR-1990 14:16 -< Construction zone >- -------------------------------------------------------------------------------- The merger is imminent. Please read note 81.70 in NEW_CONFERENCE_IDEAS for some details that will be of interest. I expect the merger to take place this week. You may see some brief disruptions of service in this conference during the process. Once the new conference is created and all notes have been moved from here to there, this conference will be write-locked, but will remain available for a while as a precaution.  ================================================================================ Note 292.0 [RSTS]RSTS TAPE DRIVE INIT PROBLEM 1 reply EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 18 lines 2-DEC-1989 00:30 -------------------------------------------------------------------------------- I am having the same problem with two different tape drives under RSTS V9.7 Sub-System 1 QBUS TD Systems QTA CTL + Archive 2150 S Sub-System 2 QBUS DILOG DQ153 + DEC TU80 $INIT/FORMAT=ANSI MU0: FOO works $INIT/FORMAT=DOS MU0: causes a drive hung or write locked error Any ideas? ================================================================================ Note 292.1 [RSTS]RSTS TAPE DRIVE INIT PROBLEM 1 of 1 EISNER::KENNEDY "Terry Kennedy" 3 lines 2-DEC-1989 04:42 -< Error log? >- -------------------------------------------------------------------------------- > $INIT/FORMAT=DOS MU0: causes a drive hung or write locked error What are you getting in your error log for these events?  ================================================================================ Note 293.0 [RSX]Looking for command-line editor CLI 5 replies EISNER::HUDGINS "Jerry Hudgins" 6 lines 8-DEC-1989 13:57 -------------------------------------------------------------------------------- I'm looking for a command-line editor for M+ that's implemented as a CLI. I saw such a beast (AUX) on an older SIG tape, but it was set up for IAS and I haven't had time to try to fix it up. I've been using a version of CLE that's a couple of years old, but it's been causing me some problems on LAT terminals. Anyone have any recommendations? Has someone re-implemented CLE as a real CLI? ================================================================================ Note 293.1 [RSX]Looking for command-line editor CLI 1 of 5 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 10 lines 8-DEC-1989 21:14 -< I use MCE from Han Hanmakers >- -------------------------------------------------------------------------------- < Note 152.0 by EISNER::HUDGINS "Jerry Hudgins" > > -< Looking for command-line editor CLI >- I have been using MCE by Hans Hanmakers in The Netherlands. It has appeared on the RSX SIG Tapes and I like it very much. It will build for either M or M+. I don't believe it is implemented as a CLI, but I have had no problems using it with both MCR and DCL. Unfortunately, I don't have an RSX system with LAT, so I can't tell you if it works there. ================================================================================ Note 293.2 [RSX]Looking for command-line editor CLI 2 of 5 EISNER::CHRISTIAN "Michael Christian" 9 lines 10-DEC-1989 19:19 -------------------------------------------------------------------------------- I have been using one called CED that is implemented as a real honest to goodness CLI. I am at home right at the moment, and I can't remember where I got it from (some older DECUS SIG tape from what I remember.) I'll hunt around and see if I can find the source. I am using it under RSX-11M+ V4.2. It works well on local terminals, and doesn't get it the way on RT class terminals, but I haven;t been able to successfully edit a command line on the RT terminals. The escape sequences get snarfed up somewhere along the line and execute the recalled command rather than editting it. ================================================================================ Note 293.3 [RSX]Looking for command-line editor CLI 3 of 5 EISNER::CHRISTIAN "Michael Christian" 15 lines 11-DEC-1989 08:50 -< I found it! >- -------------------------------------------------------------------------------- CED is on the Spring '84 RSX tape under the UIC [344,377]. It was written by a David Strait from Applied Dynamics International. I have modified it quite a bit to fit our site. Send me a mail message if you don't have access to the Spring '84 tape. I have looked at the MCE edittor that Alan mentioned. It is a very nice editor with lots of bells and whistles. It is implemented as a program, and not a CLI, so there are no problems with losing escape sequences across the net. I have used it some, and I actual prefer it over the CED that I am using right now. The only "hitch" that I have seen in MCE is that it attaches to the terminal. If you run a program that also needs to attach, you have to remember to type a ^T to make MCE release the terminal for 10 seconds. This gets in the way if you SET HOST alot. ================================================================================ Note 293.4 [RSX]Looking for command-line editor CLI 4 of 5 EISNER::HUDGINS "Jerry Hudgins" 1 line 13-DEC-1989 08:47 -< Thanks >- -------------------------------------------------------------------------------- Thank you, gentlemen, for your prompt attention. ================================================================================ Note 293.5 [RSX]Looking for command-line editor CLI 5 of 5 EISNER::WYANT "SOME call me ..... TOM" 4 lines 15-DEC-1989 15:14 -< Who, us? >- -------------------------------------------------------------------------------- >>> Thank you, gentlemen, for your prompt attention. ^^^^^^^^^ Perhaps you have mistaken us for another SIG?  ================================================================================ Note 294.0 [RSX]DECUS C installation help needed 8 replies EISNER::VANMATRE "Ethan VanMatre" 8 lines 12-DEC-1989 11:15 -------------------------------------------------------------------------------- I have the older releases of the DECUS C complier and I think the new release. I tried to build the compiler on my RSX-11m V4.5 system and failed. I'll be after it again soon. This is a request for sage words and advice by those of you who have jumped all of the barriers. Tell me your secrets. Thanks, --Ethan-- ================================================================================ Note 294.1 [RSX]DECUS C installation help needed 1 of 8 EISNER::KENNEDY "Terry Kennedy" 23 lines 12-DEC-1989 22:38 -< Can you wait for (and afford) DEC's PDP-11 C? >- -------------------------------------------------------------------------------- > release. I tried to build the compiler on my RSX-11m V4.5 system and > failed. I'll be after it again soon. This is a request for sage words > and advice by those of you who have jumped all of the barriers. Tell > me your secrets. 1) If you're doing more than just playing, wait for DEC's PDP-11 C V1.0. This may even be true if you're just trying to learn C. Here's why: a) DECUS C is "old" or "classic" C. You won't learn (or be able to use) modern features with it. b) A single misplaced } or ; gives you the "thousands of errors" syndrome. c) The I/O in the RTL has some obscure bugs 2) If you _must_ build it (it does build character - I spent about 600 man- hours on it before going to PDP-11 C), write down the errors you get and post 'em here - I may remember what the tricks are. [For those about to cry "Foul ball - he said Field Test!" I'll just mention that DEC put me on the Field Test Panel at the last Symposium. _They_ told you, not me. But no, I'm not going to say a lot about the product beyond what I said on the panel until FCS - after that I expect I'll have a lot to say] ================================================================================ Note 294.2 [RSX]DECUS C installation help needed 2 of 8 EISNER::HUDGINS "Jerry Hudgins" 11 lines 13-DEC-1989 08:45 -< DECUS C wasn't so bad >- -------------------------------------------------------------------------------- Apparently, experiences differ. While I agree with Terry that you'd be far better off to purchase PDP-11 C from Digital if you're doing anything very serious, I did not have THAT much trouble with the DECUS offering. I've built the old Second Master Release tape a couple of times without incident. I did try to build the I/D space extensions on a later tape with much less luck; various modules still required modification to separate code and data, and I let the project die. The older release did not support named directories either, and I don't know how much trouble it would be to fix it up. Beyond that, however, I found the DECUS compiler to be quite useful (as least as good as the Whitesmiths product I evaluated.) ================================================================================ Note 294.3 [RSX]DECUS C installation help needed 3 of 8 EISNER::VANMATRE "Ethan VanMatre" 10 lines 13-DEC-1989 16:33 -< I'll try it again >- -------------------------------------------------------------------------------- >>> Apparently, experiences differ. While I agree with Terry that you'd >>> be far better off to purchase PDP-11 C from Digital if you're doing >>> anything very serious, I did not have THAT much trouble with the >>> DECUS offering. Great I'm glad to hear that you have had good experiences with the build. I don't have the money to put DIGITAL C on my home system. I'll dig back into it this holiday. Thanks -- Ethan -- ================================================================================ Note 294.4 [RSX]DECUS C installation help needed 4 of 8 EISNER::KENNEDY "Terry Kennedy" 18 lines 13-DEC-1989 23:07 -< More >- -------------------------------------------------------------------------------- > Apparently, experiences differ. While I agree with Terry that you'd > be far better off to purchase PDP-11 C from Digital if you're doing > anything very serious, I did not have THAT much trouble with the > DECUS offering. Well, I built it for RSTS and RT, but not native RSX. The RSTS RT emulation version worked quite well, once I fixed a bunch of library foulups. Things like KBnn: being translated internally to TT:, so you couldn't open another KB from a C program, like the RTL choking on RMS files, etc. The RSTS RSX emulation variety was a lot more work. I managed to get the compiler and assembler built under RSTS RSX, but the RTL was a big problem. Much of the work for the RSX+RMS RTL was incomplete (and worked on by several people, so you have edit histories like: ABC - insert FOO code / XYZ - remove FOO code / ABC re-insert FOO code removed (in error) by XYZ). Building natively (under real RSX) would certainly help, as at least you have the command files available. ================================================================================ Note 294.5 [RSX]DECUS C installation help needed 5 of 8 EISNER::HUDGINS "Jerry Hudgins" 2 lines 14-DEC-1989 11:10 -< Yes, I should have mentioned... >- -------------------------------------------------------------------------------- You're right, Terry, I was building under native RSX (Micro/RSX V3.1). This was fairly painless. ================================================================================ Note 294.6 [RSX]DECUS C installation help needed 6 of 8 EISNER::MAYHEW "Bill Mayhew" 11 lines 15-DEC-1989 00:15 -< Still using DECUS C after all these years >- -------------------------------------------------------------------------------- I'll also leap to the defense of DECUS C, as we have used it to build several software products for RSX that were born under UNIX, migrated to RSX, and later migrated to VMS. I agree with the assessment that it is at least as good as Whitesmiths' product, overall. We too were using MicroRSX and basically took the compiler executables for the P/OS version and put them on MicroRSX and they ran just fine. I think we did build the thing from the sources at one point, though it was a good while ago now. We did end up basically writing our own RTL (we had a lot of it in source form anyway) to deal with RMS "properly" (a very application- and user-specific term :-}). ================================================================================ Note 294.7 [RSX]DECUS C installation help needed 7 of 8 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 14 lines 15-DEC-1989 11:39 -< Another fan of DECUS C >- -------------------------------------------------------------------------------- > -< Still using DECUS C after all these years >- Back in 1982, I wrote a real-time application in DECUS C (my first large program in C). It did not use RMS, but did make extensive use of ASTs and other hooks into the RSX executive. There were a few problems with the run-time routines, especially concerning ASTs. Fortunately, Bob Denny's office was right across the street and I could just walk over to discuss these problems and get fixes. These fixes were then incorporated in the later releases of DECUS C. This application has been running fine ever since, and the customer is happy. I think that DECUS C is one of the best values you will find. ================================================================================ Note 294.8 [RSX]DECUS C installation help needed 8 of 8 EISNER::VANMATRE "Ethan VanMatre" 13 lines 15-DEC-1989 17:32 -< Expandibility >- -------------------------------------------------------------------------------- > This application has been running fine ever since, and the > customer is happy. I think that DECUS C is one of the > best values you will find. Thats the real key here. I get C for Free, just my time. Sources are there and as one builds it you get an insite to the workings. I like to add additional hardware to my systems. If I could get someone (any takers?) to give me an ATnT DSP-32c chip I would hook it into the C lib. The DSP-32c can do 10 Mflops... --Ethan--  ================================================================================ Note 295.0 [RT11]RT-11 in New Mexico No replies EISNER::CROWELL "Shefth of the Fourth Order" 25 lines 23-DEC-1989 20:12 -------------------------------------------------------------------------------- There is apparently going to be a substantial RT-11/TSX+ presence at the New Mexico regional symposium. This is a good chance to participate in a DECUS symposium without the full expense of going to a national symposium. This year (the 8th NM symposium) it's in Las Cruces at the Hilton. Pre-symposium seminars are on Wednesday, March 14, 1990. Sessions on Thursday and Friday, March 15-16 with the "usual" reception on Thursday night. Digital will have an exhibit area on Thursday and Friday. Keynote Speaker: Bill Hancock (Mr. Networks!) Symposium registration is only $75.00. Pre-symposium seminars are $100.00 Get a registration kit and/or call for participation from New Mexico Digital - Computer Users' Symposium P.O. Box 5019 Las Cruces, NM 88003 (If you'd like to give a talk, there's still time. Deadline for abstracts is January 15.)  ================================================================================ Note 296.0 [RSX]Current RSX versions? 4 replies EISNER::HUDGINS "Jerry Hudgins" 3 lines 28-DEC-1989 18:05 -------------------------------------------------------------------------------- Simple question(s) regarding versions: what are the current versions of Micro/RSX and DECnet for Micro/RSX? And are new versions of either one shortly forthcoming? ================================================================================ Note 296.1 [RSX]Current RSX versions? 1 of 4 EISNER::MAYHEW "Bill Mayhew" 4 lines 2-JAN-1990 10:39 -< From LATEST_RELEASE_INFORMATION >- -------------------------------------------------------------------------------- SEARCHing topic 90 in the LATEST_RELEASE_INFORMATION conference reveals that Micro/RSX V4.2 was released on/about 7/31/89, and DECnet-Micro/RSX V4.3 was released in November '89. The most current postings do not indicate any immediately-pending releases of either. ================================================================================ Note 296.2 [RSX]Current RSX versions? 2 of 4 EISNER::OSUDAR "John Osudar" 14 lines 11-JAN-1990 18:56 -< Where's V4.3? >- -------------------------------------------------------------------------------- (Since the title referred to "RSX" and not specifically Micro/RSX, I'm posting this here instead of in a separate topic...) What does it mean when DECnet V4.3 is released for M-Plus (or for Micro/RSX, for that matter) but the operating system release of the same number isn't out? Is DECnet V4.3 intended for use with V4.2 of the operating system? Is M-Plus V4.3's release imminent, even though it isn't listed in the last posted FCS schedule? Did anyone hear anything (e.g. at the Anaheim symposium) about when M-Plus V4.3 is due out? (We're about to do several sysgens and need to know whether to do V4.2 or wait for V4.3; when we got the DECnet distribution we figured that M-Plus would follow soon after. Obviously, we figured wrong.) ================================================================================ Note 296.3 [RSX]Current RSX versions? 3 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 10 lines 12-JAN-1990 16:29 -< contract dead, 3.0 running, 4.2 on shelf >- -------------------------------------------------------------------------------- > Is M-Plus V4.3's release imminent, > even though it isn't listed in the last posted FCS schedule? The local contract woman who kept bugging me about a renewal on M+ and ALL the other layered stuff with it knew full well that she better get me an answer to that same question if she wanted $s. She got me NO info, and the contract expired a couple of days ago. I do think she tried hard. From her rather resigned voice I suspect she has been hearing the same message from other users, too. ================================================================================ Note 296.4 [RSX]Current RSX versions? 4 of 4 EISNER::CHRISTIAN "Michael Christian" 11 lines 15-JAN-1990 10:34 -< Go for it. It should work. >- -------------------------------------------------------------------------------- < Note 154.2 by EISNER::OSUDAR "John Osudar" > > What does it mean when DECnet V4.3 is released for M-Plus (or for > Micro/RSX, for that matter) but the operating system release of > the same number isn't out? Is DECnet V4.3 intended for use with > V4.2 of the operating system? If you look on page 2-1 of the release notes, DECnet-11M-PLUS V4.3 will work on RSX-11M-PLUS V4.2. I installed it on my V4.2 system in late November of '89 and I haven't been having any problems.  ================================================================================ Note 297.0 [RSX]Need a DR11-W Driver 3 replies EISNER::OSTRANDER "Bill Ostrander #372" 3 lines 11-JAN-1990 13:58 -------------------------------------------------------------------------------- We need a driver for a DR11-W. Does one exist? How may we obtain it? ================================================================================ Note 297.1 [RSX]Need a DR11-W Driver 1 of 3 EISNER::TABOR "Bill Tabor" 5 lines 11-JAN-1990 18:20 -< What do you need it to do? >- -------------------------------------------------------------------------------- What do you need it to do? or are you just looking for an outline driver. I have one that connects two 11's together so that on system is a warm backup of the other. ================================================================================ Note 297.2 [RSX]Need a DR11-W Driver 2 of 3 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 18 lines 12-JAN-1990 13:01 -< Probably not what you wanted to hear >- -------------------------------------------------------------------------------- > We need a driver for a DR11-W. Does one exist? How may we > obtain it? There are *lots* of DR11-W drivers. Unfortunately, almost every one of them is written for a *specific* application, with lots of assumptions about what it is connected to, what type of application will be using it, and so on. For example, I am currently converting five drivers from RSX to VMS. Three of them use a DR11-W, but I am sure that none of them would do you a bit of good (as well as being the property of my customer). If you could tell us a bit more about your proposed use fo the DR11-W, perhaps we could point you in the right direction. There may be a public domain driver that can be modified for your needs. Failing that, we can give you pointers to the tools you need to write your own driver. ================================================================================ Note 297.3 [RSX]Need a DR11-W Driver 3 of 3 EISNER::CORNELIUS 18 lines 19-FEB-1990 03:59 -< FermiLab driver >- -------------------------------------------------------------------------------- -< One possibility >- > We need a driver for a DR11-W. Does one exist? How may we > obtain it? I have used the FermiLab DR11-W driver that appeared on the RSX Sig Tapes (1984?), and have submitted a version of it that supports 22-bit systems, RSX11M-Plus, and some Q-bus controllers. Unfortunately, I do not know if the driver from the Sig Tapes will still work with the latest releases of RSX. It has been in use locally, I believe, until quite recently, so may have kept up with RSX releases. The Fermi driver is a bit complex, but it does have some appealing features if used from MACRO - such as support for a kind of "unsolicited input" AST notifying a receiver process that a packet had been queued for it. It also provides support for a "null" link, for task-to-task communications within a single CPU.  ================================================================================ Note 298.0 [RSX]ACD without exec support crashes system No replies EISNER::NORTON "Bill Norton" 4 lines 11-JAN-1990 15:15 -------------------------------------------------------------------------------- Just a warning for anyone that didn't select "character translation support" during their SYSGEN. If you forget and issue an ACD INSTALL command you'll crash your system. Seems the ACD task doesn't check for exec support before munging the exec data structures.  ================================================================================ Note 299.0 [RSX]DECNET-11M+ V4.3 access problems No replies EISNER::CHRISTIAN "Michael Christian" 18 lines 18-JAN-1990 10:21 -------------------------------------------------------------------------------- Oops. I may have spoken too soon in note 154.4. I just ran across an intermittent problem with DECNET-11M-PLUS V4.3 that could cause you all kinds of headaches. I have primarily seen it with NFT, but an occasional NCP TELL xxx will fail. The symptom is network commands that have successfully worked for years will start getting "Unrecognized node name" and "access control violation" error messages. Colorado Springs has already had several report about this problem, and I just added my name to their list of complainers. I have been successfully running DECNET-11M-PLUS V4.3 since late November without any sign of problems. This error has mysteriously started occuring within the last two weeks.  ================================================================================ Note 300.0 [RSX]Finding Files-11 free blocks 6 replies EISNER::HUDGINS "Jerry Hudgins" 20 lines 24-JAN-1990 17:10 -------------------------------------------------------------------------------- RSX guru types: I'm looking for a way to look up the amount of free space on a Files-11 volume on the fly. Let me preface this question with: 1) I don't have CSC support, so I can't just ask Digital, and 2) I'm running Micro/RSX, which means I have no sources to peruse myself. Your indulgence is humbly requested. Two ways of doing this occur to me: 1) Open BITMAP.SYS and figure it out the hard way. This is presumably what PIP /FR does, given how long it takes. (True? False?) I've looked into this, but have been stopped by this question: What's in the first block of BITMAP.SYS? It looks like the bitmap itself actually starts in block 2. 2) Since RMD can fetch the volume free space quickly, it is obviously doing this another way. Is the information stored in the DU: driver UCB and accessible by privileged tasks? If not, how does RMD get the counts? And why doesn't PIP do it this way? ================================================================================ Note 300.1 [RSX]Finding Files-11 free blocks 1 of 6 EISNER::LEDERMAN "Bart Z. Lederman" 8 lines 24-JAN-1990 21:37 -< Try looking at the FRG program. >- -------------------------------------------------------------------------------- I don't know the answer off-hand, but I can think of at least one place to look. The FRG utility (it's been on the RSX SIG tapes) lists a fragementation map of a disk, and the total free space. Since it comes in source form on the SIG tapes you could pick up the code from there. An alternative, if you aren't in too much of a hurry, is to run the output of PIP or VFY into a file and read it. ================================================================================ Note 300.2 [RSX]Finding Files-11 free blocks 2 of 6 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 34 lines 24-JAN-1990 22:03 -< Finding free space on disks >- -------------------------------------------------------------------------------- > Open BITMAP.SYS and figure it out the hard way. This is > presumably what PIP /FR does, given how long it takes. (True? > False?) True > I've looked into this, but have been stopped by this question: > What's in the first block of BITMAP.SYS? It looks like the > bitmap itself actually starts in block 2. The first block of BITMAP.SYS contains some flags indicating the version/format of the file. It was originally *supposed* to contain a summary of the free space on the volume, but this was never implemented. Therefore, aside from the format information, block 1 should be considered as garbage. If you MAIL me your address, I will send you a copy of the Files-11 specification and some notes on the structure. This specification has been published several times in the RSX SIG newsletter and in several symposium RSX session notes. > Since RMD can fetch the volume free space quickly, it is > obviously doing this another way. Is the information stored in > the DU: driver UCB and accessible by privileged tasks? Yes. F11ACP maintains it in a UCB extension, but I forget the exact offset. Check the CDA reference manual for offsets. > And why doesn't PIP do it this way? Because PIP needs to scan BITMAP.SYS to find contiguous space. ================================================================================ Note 300.3 [RSX]Finding Files-11 free blocks 3 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 12 lines 25-JAN-1990 03:07 -------------------------------------------------------------------------------- > I don't know the answer off-hand, but I can think of at least one > place to look. The FRG utility (it's been on the RSX SIG tapes) Both FRG and HOLES do the job blindingly fast. PIP gives you LESS info much slower I think simply because it bit twiddles EVERY bit even in bytes that are all 0s or all 1s. > An alternative, if you aren't in too much of a hurry, is to run > the output of PIP or VFY into a file and read it. If you are going to .OPENR it from AT., use VERify. PIP's output should be used only if you like torture. ================================================================================ Note 300.4 [RSX]Finding Files-11 free blocks 4 of 6 EISNER::SEATON "Andrew Seaton" 18 lines 8-FEB-1990 03:43 -< Anybody got a RA82 or 90 I can dump? >- -------------------------------------------------------------------------------- Greetings, I've completed this program (I work with Jerry nowadays) using the open the BITMAP and start counting method. A couple of interesting problems. First BITMAP.SYS's header is not fully defined, and one of the fields not defined is the end of file pointers. When I tried to read it with a higher level language, it died with a read past end of file. So I pulled out MACRO and went to work reading logical blocks from the disk. This worked quite well, once I stopped yelling at the various offsets and pointers. One question remains. On a RA81, the second retrieval point of BITMAP.SYS contains 218 blocks (the first points to header block). On larger disks, does the BITMAP use a third retrieval pointer if the bitmap is longer than 256 blocks, or does it set the Storage Bit Map Cluster Factor (H.SBCL) field in the Home Block to 2? BTW, The UCB offset for free blocks are not documented in the CDA manual, and we don't have sources (I can't get them to buy M+). ================================================================================ Note 300.5 [RSX]Finding Files-11 free blocks 5 of 6 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 19 lines 8-FEB-1990 21:26 -< Some ODS-I notes >- -------------------------------------------------------------------------------- > First BITMAP.SYS's header is not fully defined, and one of the > fields not defined is the end of file pointers. You have to remember that this is part of the "user attribute area", and is *not* part of Files-11, per se. It is the responsibility of FCS (or RMS or whatever) to maintain this area. Since BITMAP.SYS is not an FCS (or RMS) file, these fields are not guaranteed to be meaningful. Therefore, you can only read the file by doing Read Virtual Blocks and either waiting for Read Past EOF or look at the file statistics block (which DMP does). > On larger disks, does the BITMAP use a third retrieval pointer > if the bitmap is longer than 256 blocks, or does it set the > Storage Bit Map Cluster Factor (H.SBCL) field in the Home Block > to 2? It uses a third retrieval pointer. ODS-I has never used a cluster factor other than one. ================================================================================ Note 300.6 [RSX]Finding Files-11 free blocks 6 of 6 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 13 lines 12-APR-1990 14:21 -< how RMD gets free block count on the fly >- -------------------------------------------------------------------------------- > 2) Since RMD can fetch the volume free space quickly, it is obviously > doing this another way. Is the information stored in the DU: > driver UCB and accessible by privileged tasks? If not, how Look at MDPAGE.mac in [14,10] (RMD sources). After verifying that the UCB is a disk mounted Files-11, it goes to the VCB for what it wants. The following is from MDPAGE.MAC mov U.VCB(r4),r3 mov V.FRBK(r3),(r2)+ ; high byte of block count + LRUC clrb -1(r2) ; clear out LRUC mov V.FRBK+2(r3),(r2)+ ; low word of block count  ================================================================================ Note 301.0 [RSX]A to Z file corruption 2 replies EISNER::TYRRILL "Al Tyrrill" 42 lines 25-JAN-1990 03:38 -------------------------------------------------------------------------------- I'm working on an A to Z file corruption problem. I know something about RSX and RMS files, but nothing about A to Z (except that DEC no longer supports it). User did a backup from a manu, onto floppies. This invokes a BRU image backup of the A to Z data files. Backup seemed to go fine. User then did a Reorganization from a menu, which apparently runs RMSCNV, and got ?CNV-F-ER$ATR code 5 on three files, ORDHDR.OLD, TXTFIL.OLD, TAXCOD.OLD. User went into Order Entry, which bombed early-on with message "fatal file error 30 on ORDHDR file". User then restored from backup floppy set, got Open error, I/O error code = -35 (which is a file id, file number check) on four files: TAXCOD.DAT;1, ORDHDR.DAT;1, TXTFIL.DAT;1, COMFIL.DAT;1. The Order Entry failure persisted. The user is strictly an A to Z person who does not even work at the RSX CLI level. I got involved and found that DIR DU1:[70,1] gave file ID, file number or sequence number checks on the above 4 files. Running BRU from the command line, I was able to extract the above 4 files from the backup set. TAXCOD.DAT seemed to be OK, but ORDHDR.DAT was still bad. In Order Entry, still got the "error 30 on ORDHDR file" (but at a later point). Ran RMSCNV on ORDHDR.DAT, it bombed with a bucket format error after converting about 3% of the file. Restored ORDHDR.DAT from the only other backup set available (6 months old). Order Entry now displayed a recent order number (which must have come from a different file) and hung. I think I can restore most of the data from the bad ORDHDR.DAT by writing program to read all possible RFA numbers, then building a new indexed file. I do have two questions, though. What other files does Order Entry access and how do I make them consistent with the new ORDHDR.DAT, which will probably have some missing data? Any ideas how the corruption occurred and whether it will again? I and others have impressed on the user the need to do regular full-disk backups. ================================================================================ Note 301.1 [RSX]A to Z file corruption 1 of 2 EISNER::MAYHEW "Bill Mayhew" 32 lines 25-JAN-1990 11:35 -< Not an A-to-Z problem; what application is involved? >- -------------------------------------------------------------------------------- "Order Entry" is not part of A-to-Z. It must be some third-party vendor's application (unless, possibly, it is part of MDAS, "Multiuser Digital Accounting System", which "counts" as a third-party vendor's application for my purposes :-})... So you need to find out "whose" order entry application this is. The only problem I'm aware of with A-to-Z that touches this area at all is that the A-to-Z "save user area" function ASSUMES that LOGIN.CMD in the user area is OWNED BY the same user ID that owns the directory, etc. We ran into a problem once where a LOGIN.CMD had been replaced by a priv'd user (e.g. [1,10], a/k/a MICRO) and when the normal user then tried to save his area, A-to-Z tried to save the priv'd user's files instead! Fortunately a file protection error occurred, otherwise it would have worked transparently and we would have never known this happened... Also, [70,1] is not a typical A-to-Z UIC. A-to-Z assigns [200,*] (in some versions) or [2xx,2xx] as UICs to its users. [70,1] must be a manifestation of the third-party application. A-to-Z is strictly a user interface and a set of keyboard and menu conventions, so it does nothing to RSX per se. RMS still works like RMS on a vanilla RSX system, CNV works like (and is) vanilla CNV, etc. etc. (In fact I don't believe A-to-Z uses CNV anywhere -- again the "reorganization" function you refer to must be the third-party app's.) I do a lot of work with A-to-Z on 11s and VAXen and will be glad to be of whatever help I can, but the application you're running doesn't sound like one I'm familiar with. (Probably because we always sold our own business applications, not someone else's :-}) ================================================================================ Note 301.2 [RSX]A to Z file corruption 2 of 2 EISNER::MAYHEW "Bill Mayhew" 26 lines 25-JAN-1990 11:44 -< Full-disk backups are overkill in general >- -------------------------------------------------------------------------------- BTW, I have several MicroPDP A-to-Z clients who NEVER do full-disk backups (because the only medium is floppy on the systems in question). We've never had a problem with area-by-area backups other than the one I mentioned in .-1. I maintain that insisting on full-disk backups is overkill, ASSUMING that the application is designed with the area-by-area scheme in mind and that it therefore tells the user the names of ALL the areas that must be backed up, and assuming that the user has a good backup "system" in effect. That last assumption is the real key... My definition of "A good backup system" on one of these machines is: A. The backups are done B. The backups are done C. All areas that relate to a given application -- e.g. any common areas (like your [70,1] I'm guessing) AND user-specific areas -- are backed up at the same time so the backups are internally consistent D. Other users are kept out of the application, and preferably off the system altogether, during the backups -- good idea for the other users' OWN sanity since floppy backups tend to consume about 90% of the machine E. Multiple generations of backups are maintained, i.e. at least 2 sets of floppies that are used on alternate days/weeks/whatever, with one cycling "off-site" F. The backups are done :-)  ================================================================================ Note 302.0 [RSX]PDP-11 Instruction Set / MTPS 4 replies EISNER::RICE "Gary Rice" 11 lines 31-JAN-1990 14:46 -------------------------------------------------------------------------------- A co-worker recently inherited a piece of RSX MACRO code (a driver, I think). He is studying it in anticipation of a move to VMS. He just stopped by and asked me what the MTPS instruction does. I tried to find it in my RSX Hardware Handbook, but it wasn't listed. I asked him if he wasn't wrong about the letters. He showed me an asmebler listing that showed the instruction (which assembled without error.) What is the MTPS instruction? Gary ================================================================================ Note 302.1 [RSX]PDP-11 Instruction Set / MTPS 1 of 4 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 20 lines 31-JAN-1990 15:54 -< This is MTPS >- -------------------------------------------------------------------------------- > What is the MTPS instruction? According to page 110 of the PDP-11 Architecture Handbook (EB-23657-18): "The eight bits of the effective operand replace the current contents of the PS<7:0>. The source operand address is treated as a byte address. Note that PS bit 4 cannot be set with this instruction. The source operand remains unchanged." This instruction first appeared in the LSI-11 (PDP-11/03), and has been implemented in almost all processors since then (21, 23, 24, 34, and all J-11 processors (73, 83, 84)). Note that it was *not* implemented in the 11/04, 11/44, or 11/60, even though they were introduced after the 11/03. MTPS is often implemented as a macro so that it will assemble correctly for your machine, depending on the contents of [11,10]RSXMC.MAC. ================================================================================ Note 302.2 [RSX]PDP-11 Instruction Set / MTPS 2 of 4 EISNER::MCFARLAND "Bob, Who am I #343" 6 lines 2-FEB-1990 22:20 -< Why invent an MTPS instruction? >- -------------------------------------------------------------------------------- I believe that the MTPS instruction was added for the LSI-11 because the Processor Status Word didn't have an address in the I/O page. Thus, the new instruction was invented to allow software to stick something into the Processor Status Word. The CPUs that map the Processor Status Word into the I/O page don't have a MTPS instruction. Thus the need for a macro, so that Executive code will execute correctly. ================================================================================ Note 302.3 [RSX]PDP-11 Instruction Set / MTPS 3 of 4 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 13 lines 6-FEB-1990 13:40 -< More CPU differences >- -------------------------------------------------------------------------------- > The CPUs that map the Processor Status Word into the I/O page > don't have a MTPS instruction. Not true. The 11/23 (and 11/24), 11/34, and all J-11 (11/73, 11/83, 11/84, etc.) processors implement *both* the MTPS instruction and the I/O page address of the PSW. You are correct, however, that the MTPS instruction was introduced in the LSI-11 (11/03) because it was cheaper/easier to add a new instruction than implement the I/O page address. Note: All this discussion about MTPS applies equally to MFPS also. ================================================================================ Note 302.4 [RSX]PDP-11 Instruction Set / MTPS 4 of 4 EISNER::HARVEY "Jack - Xcom - Customer Assistance" 7 lines 23-FEB-1990 20:40 -< We should explain those mnemonics >- -------------------------------------------------------------------------------- MTPS = Machine Transparent Parallel Shift, and  MFPS = Multiply Floating Polish Stack  ================================================================================ Note 303.0 [RSX]Can CINT$ and shared commons coexist? 1 reply EISNER::VANMATRE "Outerplane Observatory" 5 lines 31-JAN-1990 19:06 -------------------------------------------------------------------------------- Has anyone used the CINT$ directive in a task that collects data and then shares that data and some access code via a resident common? If so could you show me an example. Thanks, Ethan ================================================================================ Note 303.1 [RSX]Can CINT$ and shared commons coexist? 1 of 1 EISNER::SIMONS "Paul, Not that CONVEX!" 5 lines 12-FEB-1990 15:03 -< Additional info, please. >- -------------------------------------------------------------------------------- I think the Cint$ directive is a wonderful thing, and I've built several applications around it. However, it does have some definite, and reasonable, limitations. The major one is that only one task can access the device interrupt. So you need to explain what you mean by "some access code".  ================================================================================ Note 304.0 [RSX]DECnet-11M-Plus V4.3 nodename database 2 replies EISNER::OSUDAR "John Osudar" 53 lines 15-FEB-1990 20:35 -------------------------------------------------------------------------------- I'm posting this for a friend -- if you want more details, please discuss with him (Tony Scandora, at 708-972-7541 or by Internet mail at B35048@ANLCMT.CMT.ANL.GOV): ================================================================================ I just installed DECnet-11M-Plus V4.3 on an RSX-11M-Plus V4.2 system. All of the DECnet drivers and tasks are loaded and installed into the system image file by VMR. DECnet is also loaded into the system image by a VNP> SET SYSTEM ALL command. All processes are loaded. All lines are clear and the exec is off. When we boot, we >SCP START FROM LB:'' TEMP 150 SIL (I) >NCP SET EXEC STATE ON >NCP SET LINE UNA-0 ALL >NCP SET LINE KDZ-0-* ALL ! yup, we do async >NCP SET CIRCUIT UNA-0 STATE ON >NCP SET CIRCUIT KDZ-0-* STATE ON We have been doing this (without the SCP command, of course) for many releases of DECnet and it has always worked. Now, with the new name server, the temporary node name database does not get loaded. This is a level 1 router on an Ethernet with 15 other routers, 150 active nodes in this area, and a top address of 499, so we are not swimming in pool. NETINS.CMD does a >CFE @NETRND and then renames NETRND.CMD to .COM and stops using it. Even if nothing is installed from VMR/VNP and you let NETINS do its thing on every boot, sometimes the names all disappear. Then you have to rename NETINS.COM to .CMD to get them back on the next >@NETINS. The entire documentation kit for DECnet RSX, all five volumes of it, has been reprinted for this release. It is in gray binders, and every individual manual has a new AA- number, publication date, and "Supercession/Update Information: Revised for new covers." Unfortunately, the text in those books has not changed. The release notes have seven pages of stuff that you are supposed to scribble into the right spots in eight of the stale but reprinted manuals. The release notes also discuss the Node Name Service, but not well enough for my feeble mind. For now, when I start up, I do >NCP SET NODE nnn NAME xxx commands to define the few names I really care about. This gets the async lines up and they can get to the systems they care about, but it's a little inelegant. Would someone kindly explain how the temporary node name database gets loaded? How to reload it from the permanent database? How the permanent node name database can get all of its names deleted, if that is what is really happening? Why Digital went through the trouble, expense, and trees involved in reprinting the entire five volume manual set without changing its contents? ================================================================================ Note 304.1 [RSX]DECnet-11M-Plus V4.3 nodename database 1 of 2 EISNER::SIMONS "Paul, Not that CONVEX!" 9 lines 1-MAR-1990 16:16 -< It's all a mystery ... >- -------------------------------------------------------------------------------- I'm in the midst of designing a Decnet server so we can get rid of our PCL's. During one of my frequent calls to Colorado, I asked if I could hook into the node name server. I was told that I shouldn't use RSX11M+ Decnet 4.3 because people were having problems with disappearing node names. And no, I can't hook into the server. Paul Fix (The (only?) Sixteen Bit Team decnet guy) called "Engineering" and was told that was all the documentation there was going to be. So how the server works is a "mystery". Neat, huh? ================================================================================ Note 304.2 [RSX]DECnet-11M-Plus V4.3 nodename database 2 of 2 EISNER::RICE "Gary Rice" 7 lines 2-MAR-1990 11:22 -------------------------------------------------------------------------------- > Paul Fix (The (only?) Sixteen Bit Team decnet guy) Paul (a VERY COMPETENT Fellow) shares the 16-bit Networks questions with another guy (whose name I have forgotten at the moment.) The 2 of them comprise the team. Gary  ================================================================================ Note 305.0 [PRO300]Formatting RX50 Diskettes 3 replies EISNER::RICE "Gary Rice" 11 lines 25-FEB-1990 09:32 -------------------------------------------------------------------------------- According to a source within DEC, there were some PRO 350 RX50 controllers that were built as field test units. These controllers could be told to format RX50s in the drives that the controller was attached to. If you know of the existance of one of these field test units, please contact me via MAIL on this system. Thanks. Gary ================================================================================ Note 305.1 [PRO300]Formatting RX50 Diskettes 1 of 3 EISNER::LEDERMAN "Bart Z. Lederman" 3 lines 25-FEB-1990 12:47 -< Any way to tell? >- -------------------------------------------------------------------------------- Do you know of any numbers we can look at or test which can be done which would let us know if one of these units trickled out to the public? ================================================================================ Note 305.2 [PRO300]Formatting RX50 Diskettes 2 of 3 EISNER::RICE "Gary Rice" 11 lines 26-FEB-1990 10:58 -------------------------------------------------------------------------------- > Do you know of any numbers we can look at or test which can be done > which would let us know if one of these units trickled out to the > public? Sorry, no. My source was NOT the provider of the equipment, only the recipient of the results of the tests. He could tell me nothing more than what I have already stated. Gary ================================================================================ Note 305.3 [PRO300]Formatting RX50 Diskettes 3 of 3 EISNER::RICE "Gary Rice" 46 lines 26-MAR-1990 08:27 -------------------------------------------------------------------------------- I contacted Jerry Ethington, asking him if he was ever a "hardware field test site" for the PRO. Here is his response. I have edited it slightly to remove some personal comments that he intended for MY eyes only. Gary -------------------------------------------------------------------------- Date: 15-Mar-1990 11:23pm EST From: Jerry Ethington ETHINGTON Dept: Menu Coordinator Tel No: 502-223-5489 TO: Gary Rice ( RICE ) Subject: RE: Field Tests Sorry Gary, I never field tested any of the hardware..... I was told that Field Service wouldn't let the cmpany release the ROM to do formatting. The original RX50 REV A drive had several engineering bugs (the main one I can remember was a spring that lost tension after a while and caused the head positioner to become sloppy) and as a result it wasn't so good for formatting floppies; Rainbows attempting to do formatting with REV A RX50s had mucho problems. But the REV B drive fixed that and, to the best of my knowledge, would work fairly reliably with formatting. Maybe Field Circus didn't want to replace all the old RX50 drives to get formatting reliable; who knows. The root of the problem is, for whatever reason, the new microcode ROM for the Pro RX50 controller never made it out the door. The software is there - if the DZ driver discovers you have a microcode level 11 ROM in the controller, you can format away under P/OS 3.2. But level 10 was the highest they ever let out the door. (I've got that ROM - it added support for speed check functions and was also needed to try to read IBM single sided single density floppies). I'd like to have a version 11 ROM too, and I suspect all the old REV A drives have long ago been replaced - most recent drive I got when I cooked the one in the 380 was rev C1..... Sorry I can't help more. Jerry  ================================================================================ Note 306.0 [RSTS]Version 9.7 and KERMIT 2 replies EISNER::DURKIN "Mike Durkin" 12 lines 26-FEB-1990 14:45 -------------------------------------------------------------------------------- This note is posted on behalf of a friend of mine. His problem relates to Version 9.7 of RSTS/E and KERMIT. After performing a Version 9.7 SYSGEN, enabling Multiple Private Delimiters - (the default ??), he invokes KERMIT and receives the following bad messages. ? No Space, unable to attach to Resident Library ? No Space, can't find file or account The version of KERMIT he has, used to execute under V9.6, however, it wouldn't permit file transfer owing to MPD's not enabled in the SIL. Any ideas ? My RSTS is a bit rusty. ================================================================================ Note 306.1 [RSTS]Version 9.7 and KERMIT 1 of 2 EISNER::DURKIN "Mike Durkin" 7 lines 27-FEB-1990 11:28 -< RMS libraries were missing. >- -------------------------------------------------------------------------------- After I posted this note I reflected...  After I reflected, it seemed all too obvious that some RMS libraries were missing. After RMSRES and its satellite libraries were installed, he was able to execute KERMIT. ================================================================================ Note 306.2 [RSTS]Version 9.7 and KERMIT 2 of 2 EISNER::KENNEDY "Terry Kennedy" 19 lines 1-MAR-1990 20:41 -< Some comments >- -------------------------------------------------------------------------------- > This note is posted on behalf of a friend of mine. His > problem relates to Version 9.7 of RSTS/E and KERMIT. After > performing a Version 9.7 SYSGEN, enabling Multiple Private > Delimiters - (the default ??), he invokes KERMIT and receives > the following bad messages. Glad to see you've solved the original problem. I just thought I'd add some comments: Neither V9.6 or V9.7 prompt for any terminal options. If he got a question about multiple private delimiters, he was installing V9.5 or older. The problem with not being able to specify a PPN is due to a bug where "[" and "]" are parsed as part of the filespec. I fixed this in X3.60 (on the RSTS SIG tapes, _not_ the same as T3.60 or V3.60 from the official distribution). I sent my changes back to Brian Nelson when I made them, but nothing came of it. If you want to get my version, send me MAIL about it.  ================================================================================ Note 307.0 [RSX]M-Plus DECnet outgoing proxies 3 replies EISNER::OSUDAR "John Osudar" 16 lines 6-MAR-1990 22:33 -------------------------------------------------------------------------------- Another DECnet-11M-Plus V4.3 question: Is anyone successfully using outgoing proxies from M-Plus DECnet V4.3 into a VMS V5.3 (or later) system? How about from DECnet V4.2 into VMS V5.3 or later? I know this used to work -- can't swear exactly when, but sometime in the last year. Now it doesn't. I can't determine if it's a VMS problem (all my systems are at V5.3 now) or an M-Plus DECnet problem (I've got a DECnet V4.3 and a V4.2, and neither works.) I've set up the proxies on the VMS side correctly, I believe (including /DEFAULT) and have enabled outgoing proxy access on the RSX side. Any ideas? ================================================================================ Note 307.1 [RSX]M-Plus DECnet outgoing proxies 1 of 3 EISNER::AZZOLI 7 lines 7-MAR-1990 19:49 -------------------------------------------------------------------------------- I don't personally use it in the RSX to VMS direction, but I know that it did work from DECnet M-plus V4.3 to VMS V5.2 after I enabled the outgoing proxies (like you did). I don't remember anything else being required, but I will look through the manual tomorrow and see if anything rings a bell. ================================================================================ Note 307.2 [RSX]M-Plus DECnet outgoing proxies 2 of 3 EISNER::CHRISTIAN "Michael Christian" 7 lines 8-MAR-1990 10:22 -< No problems here. >- -------------------------------------------------------------------------------- I am using the default proxies (shame on me), and everything seems to be going fine between my DECNET-11M-Plus V4.3 and my VMS V5.3. Are you getting hit by the node name data base bugs on the RSX system? ================================================================================ Note 307.3 [RSX]M-Plus DECnet outgoing proxies 3 of 3 EISNER::OSUDAR "John Osudar" 9 lines 8-MAR-1990 12:54 -< nodenames OK >- -------------------------------------------------------------------------------- > Are you getting hit by the node name data base bugs on the RSX > system? My colleague who set up the M-Plus system (and prompted me to post the earlier note inquiring about the nodename database stuff) had given up on that stuff working -- so we have a nice static node database set up by a NODENAMES.CMD file. That's not the problem with proxies. We just found that proxies don't work from this system into another M-Plus system... so I'm still looking for an answer...  ================================================================================ Note 308.0 [RSX]DZ11 swap? 4 replies EISNER::MCMICHAEL "Chuck McMichael" 3 lines 9-MAR-1990 09:50 -------------------------------------------------------------------------------- I need to know if a 20 milliamp DZ11 can be replaced by an EIA port DZ11 without doing another SYSGEN on an M+ system. I think it could, but I'd like some confirmation before I tear the machine apart. ================================================================================ Note 308.1 [RSX]DZ11 swap? 1 of 4 EISNER::KENNEDY "Terry Kennedy" 12 lines 9-MAR-1990 20:05 -< Partial answer (is that like partial modem control?) >- -------------------------------------------------------------------------------- > I need to know if a 20 milliamp DZ11 can be replaced by an EIA port DZ11 > without doing another SYSGEN on an M+ system. I think it could, but I'd > like some confirmation before I tear the machine apart. This is _not_ an RSX-specific answer. You may get a better response from an RSX person, but: The boards have an identical programming interface, _except_ for modem control (no modem control on the 20 ma version). Thus, they should plug right in for local EIA terminals. If you need the modem control, *some* operating systems may need a SYSGEN (Not sure about RSX, RSTS V9.6 and after doesn't, VMS doesn't). ================================================================================ Note 308.2 [RSX]DZ11 swap? 2 of 4 EISNER::NORTON "Bill Norton" 6 lines 12-MAR-1990 11:29 -------------------------------------------------------------------------------- The cards will swap with no problem as long as they're at the same CSR and vector, and you won't need an RSX sysgen if in the last sysgen you answered YES to the question: "Do any of the DZ ports require modem support?" ================================================================================ Note 308.3 [RSX]DZ11 swap? 3 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 34 lines 12-MAR-1990 20:54 -------------------------------------------------------------------------------- > CSR and vector, and you won't need an RSX sysgen if in the last sysgen > you answered YES to the question: > "Do any of the DZ ports require modem support?" And even if you didn't, you don't need a sysgen unless you NEED modem support. Maybe you changed only to cut down on EMI/RFI, or you have newer terminals and needed to change, of any other non modem related reason. The following may be in the 'dream on' category, but might just happen to apply to your situation. If you ARE sysgenning, and if you are buying hardware, you just might be able to find a 'goodie' such as an Emulex CS11 at a super bargain price now that U bus stuff is 'out'. It has a seperate controller and then up to 4 smart panels. The CC11 controller card should be CHEAP. The CP11 or 12 16 port panels I have paid as little as $65 for and recently have seen them for even less, and the newer CP34 16 port panels might cost a tad more but are VERY desirable. The benefits? Up to 64 ports on 1 hex card, 1 - 34 wire ribbon cable up to 50' from card to panels, FULL modem control, DMA output (M+ supports it!), whole thing becomes a DMF32 (async ports only, of course, and 48 ports max) with only a PROM change, and (only with the CP34 panels) a Q bus CC04 (~$1000, NEW) card to replace that CC11 and you have up to 64 ports of DHV on your Q bus 11 or MV2 or 3! Also, supports CRAZY split baud rates, 19.2, and 38.4, and (thank you EMULEX) even out of band flow control without DEC's driver even knowing about it. If you still need some 20 ma current loop stuff, one high-tech junk shop I frequent even had some of the relatively rare 20 ma 8 port sub panels that go into CP11s within the last week or so. You can intermix freely at the panel level. ================================================================================ Note 308.4 [RSX]DZ11 swap? 4 of 4 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 5 lines 12-MAR-1990 20:59 -< CON will chanve CSRs and VECs >- -------------------------------------------------------------------------------- > The cards will swap with no problem as long as they're at the same > CSR and vector, And even if you choose to use a different CSR or VEC, CON can change your gen'd values either in VMR, or in startup.cmd each time you boot.  ================================================================================ Note 309.0 [RT11]Troubles with dates in the 1990's 2 replies EISNER::KOZAM 23 lines 17-MAR-1990 13:47 -------------------------------------------------------------------------------- The version of TSX-Plus I'm running (6.2) has troubles with the 1990's. To be exact, attempting to do DATE 17-MAR-90 fails as an illegal date. RT-11 doesn't have this problem. The answer, of course, is to set the date BEFORE you bring up TSX+ (a good practice, in any case). I don't know if the error lies in the command parser or in the system function call itself. The work around I used was to set the date to 31-DEC-89 then do the following: TIME 23:59:59 TIME 23:59:59 etc... Each iteration advances the time over midnight, and thus the date also. Maybe this is fixed in newer versions. You may ask, why not simply reboot RT, set the date, and start TSX? Well, I wasn't anywhere near the system at the time and had to do this via modem. ================================================================================ Note 309.1 [RT11]Troubles with dates in the 1990's 1 of 2 EISNER::YOUDELMAN "Billy Y" 7 lines 17-MAR-1990 14:30 -< Trouble with dates in the 1990's >- -------------------------------------------------------------------------------- > The version of TSX-Plus I'm running (6.2) has troubles with the >1990's. To be exact, attempting to do DATE 17-MAR-90 fails as an >illegal date. RT-11 doesn't have this problem. This is fixed in version 6.3 where the year may be up to 1999. As of 6.4, it seems 1999 is still the max year, at least as may be set from the keyboard after it's running.. ================================================================================ Note 309.2 [RT11]Troubles with dates in the 1990's 2 of 2 EISNER::CROWELL "Shefth of the Fourth Order" 8 lines 24-MAR-1990 15:20 -< The new era of RT-11 >- -------------------------------------------------------------------------------- > This is fixed in version 6.3 where the year may be up to 1999. > As of 6.4, it seems 1999 is still the max year, at least as may be > set from the keyboard after it's running.. The for 'old' RT-11 date word structure, 1999 was the last year accomodated. Beginning with V5.5 of RT-11, the formerly unused bits in the date word are used as an "era" field to accomodate the next century or so.  ================================================================================ Note 310.0 Accessing RSX Device Registers 9 replies EISNER::RICE "Gary Rice" 11 lines 31-MAR-1990 09:30 -------------------------------------------------------------------------------- There is a device register (on a PRO system) that contains the microcode level of the RX50 controller. Having never written a device driver, extracting this information seems like a "black art". In generic RSX terms, I am told that accessing device registers is NOT a lot of code. It's just **privileged** code. How do I access device registers (on an M+ system)? Gary ================================================================================ Note 310.1 Accessing RSX Device Registers 1 of 9 EISNER::MAYHEW "Bill Mayhew" 50 lines 31-MAR-1990 21:40 -< Are you sure you really want to do this? :-) >- -------------------------------------------------------------------------------- Do you really need to access the device registers from a program, or do you just want to check the specific register you mention? I've never written an RSX device driver either, but I believe the Task Builder manual describes how to build a privileged task that has access to the I/O page, using some TKB options/switches. Once you've done that, you can address the registers like any other memory location. On the other hand if you just want to check the value of a static register like this one, it's probably best just to look at it using console ODT. Console ODT is available on a Pro (325 and 350, and I believe 380 as well) simply by connecting a terminal to the 9-pin printer port, set to 4800 baud, AND shorting pins 8 and 9 on the 9-pin connector. A BCC08-xx cable does this for you, or you can build your own M-to-F 9-pin-to-9-pin adapter, with all pins wired straight thru except 8 and 9, which are jumpered together on the Pro end... and then plug a BCC05-xx (standard printer cable) into the other (male) end. Or you can build your own 9-to-25 pin BCC08 equivalent using the information in the Pro Pocket Service Guide or Technical Manual. Once you've done this, cycle the power on your Pro, and voila', it comes up in console ODT mode. However, this is a more complex problem in the case of the Pro hardware. The Pro's device registers are not much like those of any other PDP-11. There's a lot of "indirection" and "multipurpose registers" (registers that give you different information each time you address them) which make the job a bit more complicated. This is definitely true in the case of the register in question. In particular, you have to load a "Report Controller Version Number" extended-function selector (octal 4) in the RX5CS5 register, then load the command to perform the extended function (octal 120) in the RX5CS0 register, then access the RX5GO register to actually initiate the function; then wait for a DONE bit in RX5CS0, or the assertion of INTRQA; then read the RX5CS2 register to get the microcode level. Whew! (The above is what I recall, as augmented from a quick look at the Pro series technical manuals, and may not even be complete!) And on top of all that, the addressing of these registers, to begin with, is a little odd, since the address of each register depends on which slot the board is in! I _think_ there's something on one of the P/OS Installation and Maintenance diskettes that will tell you the microcode version number. You may need to go into "field service mode" (push F12, F19, F5, in that order, while at the Maintenance Services menu) to see it. Then again I may be all wet! ================================================================================ Note 310.2 Accessing RSX Device Registers 2 of 9 EISNER::LEDERMAN "Bart Z. Lederman" 12 lines 1-APR-1990 13:30 -< Easier options? >- -------------------------------------------------------------------------------- If the register you want shows up somewhere in physical addressing space (which it should on the I/O bus) then you don't even need ODT. The MCR command OPEN will open and display the value of any memory location. You can get to it from the P/OS Tool Kit DCL by going .OPEN 1777000 or any similar address. WARNING: you can also MODIFY the contents of memory this way. From a program, you can reference an I/O bus address, taskbuild as /PR:5 (or /PR:4) and read it like any other location. I don't remember if I've tried this on P/OS but it must work as other RSX privileged code works when re-linked on P/OS. I can try it if you want. ================================================================================ Note 310.3 Accessing RSX Device Registers 3 of 9 EISNER::RICE "Gary Rice" 21 lines 2-APR-1990 08:38 -------------------------------------------------------------------------------- Here is what I am after. Apparently, there DOES exist a version of the RX50 ROM (v11) that allows formatting of RX50 diskettes. In fact, P/OS v3.2 has code included to allow for it IF v11 of the ROM is detected. A small number of systems were field tested with this ROM. I would like my Newsletter Readers to help in the search. If I can give them an EASY way to determine the rev of the ROM in their machine, that will make the search a bit easier. .OPEn has possibilities since the ROM rev. is copied into a field in the DZ: driver during the boot sequence. I'm not sure just where, though. From Bill's description of the nature of the device registers, that does NOT appear to be a simple process. I ALSO tried using the Maintenance Application, but struck out. The info just wasn't displayed. However, I have a VERY EARLY version (1.5). I will try to obtain a more recent version and try it again. Gary ================================================================================ Note 310.4 Accessing RSX Device Registers 4 of 9 EISNER::NEW_CONF "Bill Mayhew" 20 lines 2-APR-1990 10:52 -< OPE 177......../knld (by EISNER::BRUCE) >- -------------------------------------------------------------------------------- The following reply to this topic was posted in the RSX conference after a snapshot of that conference was taken to create the new PDP-11 conference: ================================================================================ Note 165.1 Accessing Device Registers 1 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 11 lines 31-MAR-1990 17:52 -< OPE 177......../knld >- -------------------------------------------------------------------------------- Depending on what you have to do there, you may well be able to do it from a terminal. Look up OPE, and remember its /KNLD switch. Do you have XDT? Remember BRK. On the other hand, you hardly even need a driver unless you need access to the exec's support for drivers. A simple fortran program can go mucking about in the I/O page with great ease. And without even booting up, but depending on which machine you have, you can try console ODT. ================================================================================ Note 310.5 Accessing RSX Device Registers 5 of 9 EISNER::NEW_CONF "Bill Mayhew" 35 lines 2-APR-1990 10:54 -< Programming Nits (by EISNER::HARVEY) >- -------------------------------------------------------------------------------- The following reply to this topic was posted in the RSX conference after a snapshot of that conference was taken to create the new PDP-11 conference: ================================================================================ Note 165.2 Accessing Device Registers 2 of 3 EISNER::HARVEY "Jack - Xcom - Customer Assistance" 26 lines 31-MAR-1990 21:18 -< Programming Nits >- -------------------------------------------------------------------------------- [Here we are merrily writing notes that will have to be transplanted within a day or two...] There are two general methods of accessing device registers from a running program under RSX. 1. Make it a privileged task. In that case, the upper 4K words of your address space is the device register page, and the device registers are just accessed as though the program was running on a 28K PDP-11/20. Suppose the register you want to read is at address 777562. In MAC, (the only useful language under RSX) the syntax is: MOVB @#777562,R0 ;read console keyboard into R0 2. Define a partition surrounding the device register(s) you want to access. Then map your program to the partition. This doesn't require that the program be privileged, but then anybody on the system can also map to the same partition. This is the way most Fortran programmers do it. [Hey, I thought I had gotten over all this stuff. Look what you're doing to me!] ================================================================================ Note 310.6 Accessing RSX Device Registers 6 of 9 EISNER::NEW_CONF "Bill Mayhew" 18 lines 2-APR-1990 10:56 -< 2 low-tech ideas for similar cases (by EISNER::KENNEDY) >- -------------------------------------------------------------------------------- The following reply to this topic was posted in the RSX conference after a snapshot of that conference was taken to create the new PDP-11 conference: ================================================================================ Note 165.3 Accessing Device Registers 3 of 3 EISNER::KENNEDY "Terry Kennedy" 9 lines 1-APR-1990 00:05 -< 2 low-tech ideas for similar cases >- -------------------------------------------------------------------------------- > There is a device register (on a PRO system) that contains the microcode > level of the RX50 controller. While this won't help you on a PRO, if you have a RSTS kit around that's relatively recent, you can do a HA ECO command in INIT and it will tell you about all the hardware which has host-readable revision info. In many cases, it's simpler / faster to open up the computer and look, though... ================================================================================ Note 310.7 Accessing RSX Device Registers 7 of 9 EISNER::RICE "Gary Rice" 8 lines 3-APR-1990 08:51 -------------------------------------------------------------------------------- > In many cases, it's simpler / faster to open up the computer and look, > though... This does not appear to be true for the PRO. There are markings on the ROM, but nothing that has been "certified" as meaning "v11". Gary ================================================================================ Note 310.8 Accessing RSX Device Registers 8 of 9 EISNER::KENNEDY "Terry Kennedy" 20 lines 3-APR-1990 21:33 -< DEC's PROM numbering scheme >- -------------------------------------------------------------------------------- > This does not appear to be true for the PRO. There are markings on the > ROM, but nothing that has been "certified" as meaning "v11". Ok, here's the scoop: All EPROMs on DEC-built modules will be part number 23-xxxEy, where xxx is the unique identifier for the part and y indicates the size of the part in a coded-value. The same numbering scheme is used on parts which are pin-com- patible with the 27xx EPROM family, such as the character generator in the VT220. The number may be abbreviated by omitting the 23- prefix, leaving you with something like 375E2 (which is _not_ a PRO part, it's from a TM78...). There may be many different ROM numbers for "v11", but if the number is different the code is different. Might be patches, might be sub-versions, but definitely different. The only problem you might have is if non-DEC folks copied/updated the EPROM and didn't propagate the number onto the new part's label. In such a case, the only sure way to verify the version is to do a byte-for-byte com- pare against a known reference set of EPROMs. ================================================================================ Note 310.9 Accessing RSX Device Registers 9 of 9 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 16 lines 12-APR-1990 13:36 -< DEC has it NOW, help them find it >- -------------------------------------------------------------------------------- This search for a V 11 prom might be able to be simplified. Maybe it is late enough in history that DEC and F/S don't care if that version gets into the field, and would allow it to be FREELY copied, etc. If that sort of permission can be obtained from high enough in DEC, collectively we must know enough DECies to be able 1) find someone who has it but wasn't going to give it out with permission, or 2) find someone who knows how to find it. I think this is an excelent example of where DECUServe should post BINARY and Intel-Hex formats of the PROM(s) when DEC donates them to DECUS. Everyone wins. How many likely DECies can you think of...?  ================================================================================ Note 311.0 Porting files from RSTS/E to RSX via magtape HELP! 5 replies EISNER::NEW_CONF "Bill Mayhew" 30 lines 2-APR-1990 11:09 -------------------------------------------------------------------------------- The following note was posted in the RSTS_OS conference after a snapshot of that conference was taken to create the new PDP-11 conference: ================================================================================ Note 57.0 Porting files from RSTS/E to RSX via magtape HELP! No replies EISNER::FUTTERMAN "Matt Futterman" 22 lines 31-MAR-1990 19:28 -------------------------------------------------------------------------------- I need to retrieve a (database) file from a PDP 11/44 running under RSTS/E. I want to transfer this file to my machine, a PDP 11/84 running under RSX-11M-PLUS, version 4.0, using magtape. The resident RSTS/E expert has left, and no one knows what happened to the RSTS/E documentation (!) Basically, what I need to know is this: - Does RSTS/E use Files-11 format? If so, does it have RSX-type PIP/FLX/BRU to copy files to magtape that can later be read under RSX? - If Files-11 format isn't used, will FLX handle the RSTS/E to-RSX file conversion? The PDP-11 Software Handbook (my sole source of info on RSTS/E) mentions "runtime systems" under RSTS/E, one of which is RSX. Is the choice of runtime system made during sysgen? How does the selected run-time system affect my goal of transferring a file from RSTS/E to RSX via magtape? I would sincerely appreciate any help. - Matt ================================================================================ Note 311.1 Porting files from RSTS/E to RSX via magtape HELP! 1 of 5 EISNER::DELARISCH "Arnold S. De Larisch" 28 lines 2-APR-1990 16:20 -< Here is one possible solution. For what its worth! >- -------------------------------------------------------------------------------- >> Note 57.0 Porting files from RSTS/E to RSX via magtape HELP! No replies >> EISNER::FUTTERMAN "Matt Futterman" 22 lines 31-MAR-1990 19:28 DISCLAIMER: I haven't worked with RSTS/E since V7.0.1! >> - Does RSTS/E use Files-11 format? If so, does it have RSX-type >> PIP/FLX/BRU to copy files to magtape that can later be read under >> RSX? No, it uses a DOS-11 file format. The backup program under modern versions of RSTS/E writes VMS Backup compatiable tapes. RSX, however, can't read them. I would use an 'ansi labled' tape and use the COPY command to copy files to the tape. However, this is a FLAT file structure ... all files in the same directory!!!! >> - If Files-11 format isn't used, will FLX handle the RSTS/E >> to-RSX file conversion? FLX can be used to read native DOS-11 tapes. However, becareful transfering Binary files using this format. You need to tell the utility what 'type' of file it is formatted ascii, formatted binary, fortran control, or image mode. Further, if memory serves, you also need to tell FLX the number of decimalbytes the file occupies! Yuck! Anyway ... your best bet is to use DCL COPY with ANSI Labeled mag tapes. -Arnold (who may be all wet due to antiquated information!) ================================================================================ Note 311.2 Porting files from RSTS/E to RSX via magtape HELP! 2 of 5 EISNER::HILL_R "Rich Hill, SIM USA, Inc." 16 lines 2-APR-1990 21:20 -< Use ANSI Labeled Tapes >- -------------------------------------------------------------------------------- Are you talking about RMS file here? If so then just use an ANSI labeled tape for the transfers (as indicated in the previous note), and the file attributes (record size, format, etc.) will all be handled for you. The same is true when copying to VMS. $ INIT/FORMAT=ANSI MS0: XYZZY $ MOUNT MS0: XYZZY $ COPY file.dat MS0: Then on the RSX end just copy them off with a the DCL COPY command. If they are not RMS files, you might need to turn them into RMS files on RSTS first with the /RMS:FA or /RMS:FB qualifiers to PIP. See the PIP help for more info. I hope this helps. ================================================================================ Note 311.3 Porting files from RSTS/E to RSX via magtape HELP! 3 of 5 EISNER::HARVEY "Jack - Xcom - Customer Assistance" 4 lines 3-APR-1990 22:23 -< Watch Tape Blocking Factor >- -------------------------------------------------------------------------------- My (way back) experience with using ANSI tapes with RSX is that the tape blocking factor had better be significant. Block size in the thousands of bytes if you need to move lots of data. Otherwise, the tape transfer is veerry slow. ================================================================================ Note 311.4 Porting files from RSTS/E to RSX via magtape HELP! 4 of 5 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 3 lines 12-APR-1990 13:41 -< RSTS writes VMS BAC tapes >- -------------------------------------------------------------------------------- RSTS is foreign to me but I do know that RSTS can write VMS BACkup tapes. And VMS talks to RSX many ways, but if you are on a Network that would be best. ================================================================================ Note 311.5 Porting files from RSTS/E to RSX via magtape HELP! 5 of 5 EISNER::KENNEDY "Terry Kennedy" 13 lines 12-APR-1990 20:33 -< How about... >- -------------------------------------------------------------------------------- > RSTS is foreign to me but I do know that RSTS can write VMS BACkup tapes. > And VMS talks to RSX many ways, but if you are on a Network that would be > best. A few cautions about RSTS BACKUP tapes going to VMS - Only RSTS V9.0 and higher can write these tapes - the older RSTS BACKUP used a private-to-RSTS format. There are also some oddities with file formats that don't exist on the other system. I have just about every media type still supported by DEC here (and a few that aren't 8-), so if your data is not sensitive I could probably convert it for you (if it isn't an on-going project of 1200 Mb 8-). Send VMS mail to KENNEDY if interested.  ================================================================================ Note 312.0 Comments on the consolidation of 5 Conferences 3 replies EISNER::COY "Dale E. Coy" 13 lines 2-APR-1990 17:49 -------------------------------------------------------------------------------- I am interested in comments from the users of the "consolidated" PDP-11 Conference, about how the merger was accomplished. In particular: o What things could we have done to make it easier for you? o What things that we _did_ do, were not needed? o Or did we do it "just right"? Also, for those of you who had strong opinions about the desirability of the merger (pro or con): No flames, please, but if the result confirms or contradicts your prior opinion, I'm interested. The objective is to assure that we benefit from this experience. ================================================================================ Note 312.1 Comments on the consolidation of 5 Conferences 1 of 3 EISNER::POKEL "Lisa J. Pokel" 27 lines 3-APR-1990 17:30 -< How about keywords? >- -------------------------------------------------------------------------------- > o What things could we have done to make it easier for you? > o What things that we _did_ do, were not needed? > o Or did we do it "just right"? (These may have been discussed in other areas but heres by $0.02.) As the conference is to support "The various PDP-11 and Professional series operating systems, RT-11, TSX, RSTS, RSX, IAS, P/OS, and others" as well as "all of the PDP-11 languages, real time issues and standalone programs," it would be helpful to add the operating systems and programming languages as keywords. I just did a SHOW KEYWORDS and got the following: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ CINT, CONFERENCE, DCL, ERROR, GIDIS, GRAPHICS, KERMIT, KEY, LA100, LA120, LA50, LN03, LVP16, M-PLUS_V4.0, P/OS, POSTSCRIPT, PRINTER, Pro/Comm, SHF, RAINBOW, REGIS, VT125, VT1XX, VT220, VT240, VT2XX Right now, there isn't a way to do DIRECTORY/KEYWORD=MY_FAVORITE_OS, for example (eg. MY_FAVORITE_OS=RSX). I realize that keywording has been sporadic, so it may be a case of "GIGO." I did appreciate the original conference notation in the directory listing, although I think that it needs to go further or this will end up as a catch-all. Those items quoted from message 1.0 would be great starting points for adding keywords. FWIW ljp ================================================================================ Note 312.2 Comments on the consolidation of 5 Conferences 2 of 3 EISNER::MAYHEW "Bill Mayhew" 17 lines 3-APR-1990 18:39 -< Some information about keywording here (and elsewhere) >- -------------------------------------------------------------------------------- > Right now, there isn't a way to do DIRECTORY/KEYWORD=MY_FAVORITE_OS, > for example (eg. MY_FAVORITE_OS=RSX). Yes, but you *can* do DIR/TITLE=MY_FAVORITE_OS... that's why we put the operating system in the title of the base note. (This will only work for topics, not for replies.) The issue of keywording in general is up to the moderators. Many DECUServe conferences are not keyworded, or not well-keyworded. VMS is the only conference (I believe) that is "automatically" keyworded, using a resource-consumptive method in overnight batch jobs (otherwise, it's up to each user to keyword his/her own notes as they are added... probably too big a hurdle for the DECUServe audience). The keywords that you see are indeed those that existed in the original conferences; no better and (we believe) no worse. ================================================================================ Note 312.3 Comments on the consolidation of 5 Conferences 3 of 3 EISNER::BRUCE "Barton F. Bruce - CCA/MA" 10 lines 12-APR-1990 13:51 -------------------------------------------------------------------------------- I was NOT for the merger, and still am not. It is not as horrible as I feared it might be, so it still is in my notebook. I have poked through most everything (again for RSX, of course), and don't remember finding anything of interest outside RSX. Fortunately there are not too many of the 'others'. Sadly there aren't many new RSX. One GOOD thing is that author names are intact. Most transplants lose it, so if you remember who wrote it, you still can't find it because you don't remember who transplanted it. Here at least that didn't happen.  ================================================================================ Note 313.0 PDP-11 20th Anniversary Celebration 1 reply EISNER::MCGLINCHEY "DECUS Board of Directors" 39 lines 19-APR-1990 14:48 -------------------------------------------------------------------------------- The DECUS Spring 1990 Symposium in New Orleans will feature a celebration of the 20th Anniversary of the PDP-11. Digital is presenting several sessions which are designed to be a good mix of nostalgia, entertainment, and technical information. The details: Monday, May 7: 4:30-5:30 PM: a Press Event devoted to the PDP-11 2oth Anniversary. How many computer companies can make the claim that a product first introduced 20 years ago is still being bought in major qualtities? 6PM - 7PM: PDP-11 College Bowl A PDP-11 Technical Trivia Contest, with teams made up of users and Digital People, arguing the (always) technical trivia. For instance, what does "TECO" _really stand for? 7PM - 9PM: A Walk Down PDP-11 Memory Lane Digital MSD Executives, all long-time PDP-11 users, and a select panel will remember their own introduction to the PDP-11. Guaranteed to be entertaining! Be forewarned: Digital has a major surprise up its sleeve! Q+A session follows. 9PM - 11PM: Reception Please see your Sessions-at-a-Glance for location/room. -- Jim McGlinchey ================================================================================ Note 313.1 PDP-11 20th Anniversary Celebration 1 of 1 EISNER::KILLEEN "Jeff Killeen DECUServe Chair" 6 lines 19-APR-1990 20:00 -< ANY IDEA WHO IS ON THE PANEL? >- -------------------------------------------------------------------------------- > Digital MSD Executives, all long-time PDP-11 > users, and a select panel will remember their > own introduction to the PDP-11. Guaranteed to > be entertaining! Be forewarned: Digital has > a major surprise up its sleeve! > Q+A session follows.