<<< SHAVE::DECUS:[DECUSERVE]RSX.NOTE;1 >>> -< RSX >- ================================================================================ Note 1.0 Welcome to the RSX conference No replies EISNER::STAMERJOHN "RW Stamerjohn" 6 lines 29-MAR-1987 20:19 -------------------------------------------------------------------------------- This conference covers questions and comments about the RSX series of operating systems: RSX-11M, RSX-11S, Micro/RSX and RSX-11M-Plus. Use this conference to report bugs, ask questions, suggest new features, and annouce new discoveries.  ================================================================================ 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 No replies 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 4.0 This topic reserved for future use by the moderator No replies EISNER::STAMERJOHN "RW Stamerjohn" 1 line 29-MAR-1987 20:19 -------------------------------------------------------------------------------- Additional note for moderators  ================================================================================ Note 5.0 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 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 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 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 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 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 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 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 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 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 Drivers 4 replies 0 lines 3-MAY-1987 12:24 -------------------------------------------------------------------------------- ================================================================================ Note 6.2 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 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 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 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 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 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 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 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 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 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 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 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 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 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 8.0 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 8.1 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 8.2 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 8.3 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 9.0 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 9.1 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 9.2 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 9.3 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 9.4 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 9.5 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 10.0 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 11.0 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 11.1 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 12.0 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 12.1 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 12.2 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 12.3 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 12.4 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 12.5 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 12.6 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 12.7 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 12.8 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 12.9 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 12.10 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 12.11 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 12.12 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 12.13 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 12.14 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 12.15 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 12.16 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 12.17 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 12.18 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 12.19 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 13.0 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 13.2 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 13.3 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 13.4 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 13.5 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 13.6 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 14.0 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 14.1 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 14.2 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 14.3 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 14.4 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 14.5 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 14.6 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 14.7 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 14.8 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 14.9 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 14.10 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 14.11 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 14.12 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 14.13 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 14.14 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 15.0 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 16.0 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 16.1 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 16.2 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 16.3 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 16.4 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 17.0 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 17.1 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 17.2 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 18.0 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 18.1 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 19.0 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 19.1 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 20.0 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 20.1 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 20.2 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 20.3 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 20.4 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 20.5 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 20.6 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 20.7 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 21.0 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 21.1 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 21.2 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 21.3 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 21.4 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 21.5 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 21.6 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 21.7 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 22.0 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 22.1 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 22.2 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 22.3 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 22.4 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 23.0 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 23.1 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 23.2 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 23.3 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 24.0 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 24.1 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 24.2 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 24.3 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 24.4 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 24.5 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 25.0 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 25.1 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 25.2 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 25.3 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 25.4 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 25.5 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 25.6 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 25.7 Task Builder on RSTS 7 of 9 EISNER::STAMERJOHN "RW Stamerjohn" 1 line 19-OCT-1987 10:44 -< No >- -------------------------------------------------------------------------------- ================================================================================ Note 25.8 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 25.9 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 26.0 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 26.1 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 27.0 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 27.1 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 27.2 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 27.3 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 27.4 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 28.0 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 28.1 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 28.2 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 28.3 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 28.4 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 28.5 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 28.7 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 28.8 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 29.0 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 29.1 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 29.2 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 30.0 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 30.1 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 31.0 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 31.1 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 31.2 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 31.3 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 31.4 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 31.5 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 31.6 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 32.0 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 32.1 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 32.2 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 33.0 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 33.1 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 33.2 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 33.3 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 33.4 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 33.5 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 33.6 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 33.7 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 34.0 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 34.1 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 34.2 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 34.3 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 34.4 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 34.5 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 35.0 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 35.1 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 36.0 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 36.1 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 36.2 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 36.3 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 36.4 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 36.5 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 36.6 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 36.7 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 36.8 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 36.9 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 36.10 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 36.11 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 36.12 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 36.13 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 36.14 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 36.15 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 36.16 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 36.17 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 36.18 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 36.19 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 36.20 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 36.21 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 37.0 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 37.1 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 37.2 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 37.3 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 37.4 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 38.0 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 38.1 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 38.2 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 38.3 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 38.4 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 38.5 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 38.6 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 39.0 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 39.1 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 39.2 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 40.0 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 40.1 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 40.2 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 40.3 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 40.4 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 41.0 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 41.1 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 41.2 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 41.3 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 41.4 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 41.5 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 41.6 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 42.0 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 43.0 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 43.1 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 43.2 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 43.3 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 43.4 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 43.5 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 44.0 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 44.1 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 45.0 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 45.1 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 45.2 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 45.3 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 46.0 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 46.1 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 46.2 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 46.3 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 46.4 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 46.5 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 47.0 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 47.1 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 47.2 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 47.3 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 48.0 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 48.1 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 48.2 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 48.3 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 48.4 DQ11? 4 of 4 EISNER::MCCARTHY 4 lines 31-DEC-1987 16:32 -------------------------------------------------------------------------------- Me thinks is XxDRV.  ================================================================================ Note 49.0 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 49.1 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 50.0 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 50.1 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 50.2 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 51.0 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 51.1 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 51.2 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 51.3 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 51.4 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 52.0 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 52.1 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 52.2 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 52.3 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 52.4 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 53.0 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 53.1 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 53.2 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 53.3 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 53.4 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 53.5 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 54.0 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 54.1 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 54.2 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 54.3 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 54.4 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 54.5 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 54.6 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 54.7 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 54.8 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 54.9 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 54.10 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 54.11 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 54.12 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 54.13 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 54.14 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 54.15 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 54.16 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 54.17 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 54.18 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 54.19 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 54.20 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 54.21 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 54.22 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 55.0 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 55.1 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 55.2 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 55.3 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 55.4 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 55.5 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 55.6 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 55.7 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 56.0 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 56.1 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 56.2 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 56.3 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 56.4 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 56.5 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 56.6 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 56.7 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 57.0 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 57.1 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 57.2 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 57.4 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 57.5 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 58.0 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 58.1 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 58.2 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 59.0 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 59.1 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 59.2 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 59.3 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 59.4 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 59.5 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 59.6 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 59.7 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 59.8 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 60.0 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 60.1 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 60.2 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 60.3 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 60.4 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 60.5 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 60.6 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 60.7 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 60.8 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 60.9 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 60.10 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 60.11 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 61.0 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 61.1 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 62.0 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 63.0 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 64.0 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 64.1 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 64.2 RA70? 2 of 4 EISNER::MCCARTHY 4 lines 1-APR-1988 10:51 -------------------------------------------------------------------------------- Gosh, what's an RA70? :-) ================================================================================ Note 64.3 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 64.4 RA70? 4 of 4 EISNER::PERRY "Bob (Sky Scum) Perry" 2 lines 6-APR-1988 13:30 -< Isn't that a virtual disk??? >- --------------------------------------------------------------------------------  ================================================================================ Note 65.0 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 65.1 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 65.2 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 66.0 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 66.1 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 66.2 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 66.3 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 67.0 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 67.1 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 67.2 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 67.3 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 67.4 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 68.0 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 68.1 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 68.2 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 68.3 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 68.4 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 69.0 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 69.1 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 69.2 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 69.3 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 70.0 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 70.1 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 70.2 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 71.0 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 71.1 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 71.2 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 71.3 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 71.4 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 71.5 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 71.6 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 71.7 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 71.8 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 71.9 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 72.0 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 72.1 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 73.0 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 73.1 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 73.2 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 73.3 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 74.0 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 74.1 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 74.2 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 74.3 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 74.4 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 74.5 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 74.6 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 74.7 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 74.8 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 74.9 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 75.0 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 75.1 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 75.2 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 76.0 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 76.1 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 76.2 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 76.3 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 76.4 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 77.0 Virtual Disk Drivers - need help 3 replies 0 lines 6-JUN-1988 16:08 -------------------------------------------------------------------------------- ================================================================================ Note 77.1 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 77.2 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 77.3 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 78.0 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 78.1 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 78.2 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 78.3 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 78.4 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 79.0 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 79.1 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 79.2 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 79.3 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 80.0 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 80.1 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 80.2 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 81.0 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 82.0 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 82.1 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 82.2 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 82.3 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 82.4 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 82.5 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 83.0 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 83.1 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 83.2 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 83.3 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 84.0 [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 84.1 [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 84.2 [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 84.3 [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 84.4 [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 84.5 [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 84.6 [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 84.7 [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 85.0 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 85.1 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 86.0 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 86.1 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 86.2 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 86.3 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 86.4 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 86.5 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 87.0 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 87.1 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 87.2 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 87.3 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 88.0 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 88.1 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 89.0 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 89.1 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 90.0 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 91.0 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 91.1 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 91.2 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 92.0 Can I run a U-bus system 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 92.1 Can I run a U-bus system 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 92.2 Can I run a U-bus system 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 92.3 Can I run a U-bus system 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 92.4 Can I run a U-bus system 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 93.0 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 94.0 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 94.1 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 94.2 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 94.3 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 94.4 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 95.0 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 95.1 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 95.2 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 95.3 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 95.4 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 96.0 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 96.1 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 96.2 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 96.3 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 96.4 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 96.5 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 96.6 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 96.7 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 96.8 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 97.0 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 97.1 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 98.0 Kermit for RSX11m V3.2 (Moved 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 98.1 Kermit for RSX11m V3.2 (Moved 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 99.0 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 99.1 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 99.2 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 100.0 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 100.1 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 100.2 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 100.3 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 100.4 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 100.5 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 100.6 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 100.7 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 100.8 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 100.9 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 100.10 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 100.11 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 100.12 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 101.0 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 101.1 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 101.2 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 101.3 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 102.0 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 102.1 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 102.2 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 102.3 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 102.4 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 103.0 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 103.1 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 103.2 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 103.3 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 103.4 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 103.5 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 103.6 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 104.0 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 104.1 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 104.2 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 105.0 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 105.1 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 105.2 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 105.3 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 105.4 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 105.5 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 105.6 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 106.0 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 107.0 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 107.1 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 107.2 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 107.3 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 107.4 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 107.5 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 107.6 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 108.0 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 108.1 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 108.2 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 108.3 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 108.4 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 108.5 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 108.6 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 108.7 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 108.8 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 108.9 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 109.0 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 109.1 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 110.0 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 110.1 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 110.2 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 110.3 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 111.0 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 112.0 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 112.1 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 112.2 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 112.3 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 112.4 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 113.0 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 113.1 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 113.2 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 113.3 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 113.4 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 113.5 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 114.0 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 114.1 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 114.2 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 114.3 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 114.4 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 114.5 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 115.0 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 115.1 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 115.2 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 115.3 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 116.0 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 116.1 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 116.2 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 116.3 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 117.0 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 117.1 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 117.2 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 117.3 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 117.4 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 117.5 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 117.6 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 117.7 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 117.8 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 117.10 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 118.0 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 119.0 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 119.1 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 119.2 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 119.3 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 119.4 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 120.0 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 120.1 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 120.2 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 120.3 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 120.4 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 120.5 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 121.0 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 121.1 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 122.0 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 122.1 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 123.0 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 123.1 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 124.0 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 124.1 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 125.0 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 125.1 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 125.2 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 125.3 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 125.4 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 126.0 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 127.0 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 127.1 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 127.2 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 128.0 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 128.1 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 129.0 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 129.1 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 130.0 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 131.0 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 131.1 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 131.2 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 131.3 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 131.4 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 131.5 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 131.6 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 131.7 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 131.8 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 131.9 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 131.10 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 131.11 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 131.12 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 132.0 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 132.1 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 132.2 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 133.0 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 133.1 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 133.2 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 133.3 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 133.4 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 133.5 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 134.0 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 134.1 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 134.2 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 134.3 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 135.0 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 135.1 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 136.0 Needed: Spelling 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 136.1 Needed: Spelling 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 136.2 Needed: Spelling 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 136.3 Needed: Spelling 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 136.4 Needed: Spelling 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 137.0 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 137.1 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 137.2 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 138.0 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 138.1 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 138.2 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 138.3 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 138.4 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 138.5 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 138.6 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 138.7 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 138.8 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 138.9 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 138.10 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 138.11 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 139.0 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 139.1 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 139.2 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 139.3 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 139.4 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 139.5 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 140.0 MicroRSX printer despooler, MiniExchange, and 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 140.1 MicroRSX printer despooler, MiniExchange, and 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 140.2 MicroRSX printer despooler, MiniExchange, and 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 141.0 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 141.1 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 141.2 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 141.3 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 142.0 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 143.0 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 143.1 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 143.2 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 143.3 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 143.4 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 143.5 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 143.6 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 143.7 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 143.8 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 143.9 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 143.10 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 144.0 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 144.1 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 145.0 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 145.1 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 145.2 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 145.3 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 145.4 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 145.5 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 145.6 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...