CHAPTER VAX PAGESWAPPER - September 1987 - Volume 9 Number 2 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 VAX 8700 Experiences . . . . . . . . . . . . . . VAX-4 Turbo Charging VAX/VMS Ram Disk . . . . . . . VAX-13 Excerpts From DECUS France Publications . . . VAX-15 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-20 VAX System SIG Committee List . . . . . . . . VAX-110 Forms at the End INPUT/OUTPUT Submission Form . . . . . . . . . VAX-115 System Improvement Request Submission Form . . VAX-117 VAX Systems SIG Fall 1987 SIR Ballot . . . . . VAX-119 PAGESWAPPER - September 1987 - Volume 9 Number 2 To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Articles for publication in the Pageswapper can be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number of text lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - September 1987 - Volume 9 Number 2 Editor's Workfile Editor's Workfile Technology Marches On There is a mythology that to learn REAL operations techniques for a large computer center, one must study an IBM shop, because those folks truly understand "where it's at". This seems to have been dispelled by an article on page 61 of the July 6 issue of Computerworld. The article describes a plan for reducing the burden of backups, including reduction of risk, labor needs and storage requirements. The problem faced by the site featured in the article was that 99 disks had to be backed up each night and the available window for downtime was steadily shrinking. The solution? It was revolutionary enough to warrant a headline at the top of a page labeled "management". The solution was a technique apparently new to IBM shops (or at least the one featured and others known to the staff at Computerworld). The solution (hold onto your hats) was something called "incremental backups". VAX-3 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences VAX 8700 Experiences NOTE The following presentation was given by Richard Garland of Bankers Trust Co. at the monthly meeting of the New York Commercial Cluster LUG held at Bankers Trust Company, New York City, June 15, 1987. The meeting was attended by about 40 members and several representatives of DEC Field Service, including the Unit, District Support, and the Area Customer Relations manager. After the talk, questions were addressed both to the speaker and to DEC Field Service. I am in charge of hardware support, with the Distributed Processing Technical Support group of Bankers Trust. Our Group provides centralized system and hardware support to all DEC systems at Bankers Trust. Bankers Trust is a fairly centralized organization with all of its VAXes in 3 data centers in 2 locations. I would like to relate the experiences we have had in setting up and operating a number of 8700 systems. We currently run 10 8700s and 1 8500. The first 2 were installed at our New Jersey data center in October of 1986 and the last were installed in February 1987. We encountered a number of problems over the period from November to about March, all of which were eventually solved. It is our hope that the information in this presentation will be of help to other organizations using or contemplating acquiring this type of system. I will present the problems and solutions from a user's perspective. In other words I will address particular symptoms which were observed even if 2 or more symptoms had the same fix. When the FCOs are published, these problems may be broken down differently. VAX-4 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences VAX 8700 Issues and Answers o Overview o Typical Configuration o Problems o Set up problems o Early crashes - solid o LAT problems o Console problems o Intermittent crashes o Timer problems o Fixes o Summary Before describing the first problems were encountered, it is important to describe the configuration we use at the Bank, with particular regard to the system console. In what I might call the "Normal" configuration of a VAX 8700, (A slide here shows an 8700 with the Pro-380 console on a terminal stand next to the CPU) the Pro-380, which is the system console subsystem, is located adjacent to the CPU on its own stand. This configuration is typically what you would see at a DECUS symposium or a trade show. The distance between the CPU and the Pro-380 is limited be the length of the cable joining the 2, about 6 feet. In this configuration, the system operator is expected to use the Pro-380 to boot the system, Halt it, etc. This configuration is probably fine for a Lab or department with a single CPU. This configuration was not, however, the way we wished to use these systems in our data centers. Our centers typically consist of 10 - 20 VAXes in a highly conditioned room with all the system consoles in a centralized control room. This layout allows us to better manage the large number of systems and optimizes the operators' productivity. In order to use the 8700 in our environment, and upon the advice of the DEC 8700 product line, the VAX's RDC port, located on the Pro-380, was used as a console port, and an LA120 in the control room was wired to it. Appropriate commands are issued to the Pro-380 and our LA120 then becomes the system console transparently. (Another slide shows a sketch of an 8700 with the Pro-380 on top and a wire going off to a distant LA120). While the system is running, the LA120 in the control room is used for all commands and output. The Pro-380 sits on top of the 8700 and is essentially ignored. VAX-5 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences Another options which we considered, was the use of the VAX Cluster Console (a microVAX which serves as the console to several VAXes simultaneously) We considered this at one time but decided that it does not suit our needs as we currently operate. The problems we encountered after setting up the first 2 systems were both related to the use of the remote console port. The first issue was that the console would get into various states of confusion as to whether the remote port were enabled or disabled and would sometimes hang the VAX and some times require itself (the Pro-380) to be rebooted or power-cycled. The second issue was that the LA120 was incapable of sending certain control characters to the console subsystem - notably CONTROL-P. Naturally the console lacks some essential functionality in this case: we could BOOT the system but we could not HALT it. We were eventually put in touch with the development group which wrote the Pro-380 console software and in a 3 way conference call solved the control character problem. The LA120 had to be set with the "P" parameter set to 2 or 8. Ours had been set to 1 as on all the other VAXes. They also sent us a pre-release of the console software rev. D (since released) which solved the problems of console confusion when enabling the remote port. Set up Problems o Connecting the console remote port o Control character pass-through o Console problems/hangs o Fixes: LA120 Setup: Parity setting: 2 or 8 Console software Rev D At this point in time, the 8700 were given over to the users and several projects began to build applications on them. There was a general impression that things were working well although in retrospect we know there were several problems which were not yet recognized. In January of 1987 we took delivery on the fifth 8700 and immediately discovered a real problem. The system would crash 1 to 3 times a week with a Bugcheck: "Unexpected Unibus Adapter Interrupt". This was particularly unexpected since the system had no Unibus Adapter. Field Service was able to identify this as a known problem through the Colorado Support Center and a fix was obtained. This consisted of a new version of the 8700 microcode (rev. D3). This is now the released version and is part of the Console rev. E software kit. The new microcode was also put on the other 8700s although the problem seems only to VAX-6 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences have occurred on this one system. The DEC engineers refer to this as the "Read Lock Timeout" problem and it concerns the logic controlling the NMI bus and the BI controller. Early "Solid" Crash o Fatal Bugcheck: UNEXUBAINT o About every 1-3 days o Microcode bug: NMI - BI logic o Fix: New Microcode Rev. D3 Standard with Console Rev. E or New file for Console Rev. D In late February, complaints from users and data center operations personnel began to show a pattern pointing to several problems. After many meetings with our users and with DEC we could recognize 2 major problems: LAT terminal problems and crashes. The LAT problems observed were that users sessions would drop. The configuration in use for most users involved approximately 150 users in our New York City Office communicating with 4 8700s in our New Jersey facility. The users in New York were on terminals connected to DECserver-100s and DECserver-200s. The New York Ethernet was connected to the New Jersey systems using a Vitalink TransLAN, which operated over 2 T1 links. The symptom was unfortunately reminiscent of problems encountered in the Fall of 1986 due to Vitalink configuration problems. For some time users would simply say "The Vitalink just went down again" and they would complain to our telecommunications group. It was soon recognized that the Vitalinks were working properly and the problem lay in the Ethernet controller of the 8700 systems (known as a DEBNT). After lengthy study by one of our systems programmers, a correlation was found with DECnet traffic: high DECnet traffic would cause the LAT problem; LAT traffic (in itself) would not. An additional symptom was the presence of a high number of "System Buffer Unavailable" (1-2 per second worst case) when the Ethernet counts were displayed. After we had thus narrowed down the issue, DEC was able to determine that the DEBNT microcode was at fault (several VMS driver patches were first tried). A new chip set (rev. 1.3B) was sent and tested and this solved the problem. Eventually all DEBNTs in the bank were thus upgraded. An unexpected but welcome side effect was that the units performed noticeably faster with the new firmware. (DEC has since incorporated the firmware into a redesigned module which is now shipping. It is VAX-7 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences module number T1034. Older units requiring the fix will be replaced by the new module.) LAT / Ethernet Problems o User LAT sessions would drop o Only on 8700 o First suspected TransLAN (Vitalink) bridge o Occurs concurrent with heavy DECnet traffic o "System Buffer Unavailable" errors o Fix: new firmware for DEBNT: Rev. 1.3B (Since incorporated into a new module: T1034) o Improved performance a nice side effect Along with the LAT problems we became aware that the systems were crashing or hanging. We recognized several cases: use of the Pro-380 (say to edit the default BOOT file) would usually hang or cause VMS to crash. At a meeting with DEC we found that there were cases where the Pro-380 software and VMS would not interact properly, particularly when the Pro-380s disks were being accessed. This could happen in two cases: editing files on the Pro-380 (actually typing on the Pro) and reading/writing the disks from VMS. It had long been documented that the two floppies on the Pro could be used as read/write, but the hard disk (an RD53) was to be write-only from VMS. We found that any use of the disks from VMS, even simply reading the RD53, could cause problems. Using the Pro-380 to edit files likewise caused problems. DEC informed us that a new version of the Pro-380 software (rev. E) together with VMS V4.6 would solve these console disk problems. Since VMS V4.6 was (an is) not yet released, patches for VMS V4.4 and V4.5 were obtained as well as a pre-release version of rev. E console software (since released). With these fixes in place we have found that we can do all the operations that used to cause problems. There is still the restriction that VMS can not write to the Pro-380's RD53. We have told DEC that this is an inconvenience and have been told that the restriction will be lifted in the future. At this time if VMS issues a MOUNT to the RD53, a message comes back "Drive is write-locked". VAX-8 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences Problems using Console disks o Editing BOOT files using Pro-380 would hang / crash system o Accessing Console disks from VMS would hang / crash system o Fix: New Console software Rev. E and VMS V4.6 (not yet released) or new CWDRIVER (V4.4 or V4.5) o Still cannot write to Pro-380's hard disk from VMS We also recognized that VMS would sometimes crash when no one was using the Pro and no one was accessing the Pro's disks from VMS. Curiously, these crashes would generally occur on 2 out of 4 systems in New Jersey at around midnight every night, and on 2 out of 3 systems in New York at 6 PM every evening. After analyzing a number of crash dumps, DEC (in Colorado) found that we had uncovered the "18 hour crash" bug. Apparently, 18 hours after first issuing a "SYSGEN> CONNECT CONSOLE" command the system would crash. It turns out that the New Jersey systems were typically BOOTed at 6 AM each day and the New York systems are BOOTed at midnight. Our system startup procedure requires that a file be read off of the console and thus the curious timing was explained. The systems that were not crashing were running VMS V4.5. The fix was to go to VMS V4.5 (and to use console software rev. E which we had just started using). Since it was infeasible for several of our groups to go to VMS V4.5 we requested a fix to VMS V4.4 and eventually received it. Intermittent Crashes - I o Fatal Bugcheck - INVEXCEPTN o 18 hours after SYSGEN> CONNECT CONSOLE o Work around: Mount/Dismount console disk o Fix: New Console software Rev. E and VMS V4.5 or new SYSLOA8nn (V4.4) VAX-9 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences After carefully studying error logs over a 2 month period we noticed that a few crashes did not fall into the same category as the previous. The Bugcheck message were generally very obscure, never before seen bugs. DEC informed us that a memory controller error had been diagnosed which resulted in a timing problem when memory not installed at the factory was used on a system. It turns out that factory installed memory was matched with the controller but that field installed memory was not matched. The problem was very infrequent - we believe we saw it around 4 or 5 times in 6 months of running between 4 and 10 machines. New controllers (rev. F3, current rev. is F4) were sent for all of our systems. We have not seen any of these crashes since. Intermittent Crashes - II o Various Bugchecks (see following screens): SSRVEXCEPT PGFIPLHI NOTFCPWCB SECREFNEG o Infrequent o Memory controller with mixed memory types o New controller: Rev. F3 or F4 At this point it seemed that all of our systems were running reliably. We began to receive complaints from our operators that the system time which came up when the system BOOted was occasionally wrong by a random amount. If this went unnoticed it would wreak havoc with file creation times, DECnet, etc. After several attempted work-arounds, DEC sent us a fix to the console (rev. E) software which addressed the problem. It seems that on the 8700, the Pro-380 is the repository of the time when the CPU is down (unlike earlier VAXes which had a separate battery powered TODR). The Pro would fail to save the time properly when a VMS "SET TIME" command was issued (with no argument this is supposed to set the time back into the hard ware register). This fix is the only thing that was not fixed in console rev. E. and will be part of rev. F (not yet released). The patch is available from Field Service and should ship with currently shipping systems. VAX-10 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences Time of Day problems o Incorrect time values at BOOT o Seemingly random o Related to Pro-380 state since last $ SET TIME o Fix: Fixes to Console Rev. E files Summary: Problem Module Fix 1) Remote console LA120 Setup P: 2/8 2) "Unibus" Interrupt 8700 uCode Rev D3 ("Read Lock Timeout") (Cons. Rev E) 3) LAT sessions drop DEBNT Rev 1.3B or new module: T1034 4) Console disks Console Rev E VMS CWDRIVER 5) 18 hour crashes VMS V4.5 or SYSLOA8nn 6) Various other crashes 8700 Memory Controller Rev F3 or F4 7) TODR errors Console Fix to rev E At this point a representative of DEC Field Service outlined procedures for solving any of these problems. A service call should be logged for all suspected problems. All fixes and updates outlined here are available immediately. Furthermore, it was stated, in the New York Area, all installed 8700s have been audited and known problem situations have been identified. All systems shipped as of this time are said to incorporate all fixes. Users were advised to use escalation procedures, in place, if problems are not resolved. Lou Schiavone (212-714-6746), the New York Area Customer Relations manager said he would be happy to converse with DEC Field Service from VAX-11 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX 8700 Experiences other areas on these problems. Several users questioned DEC Field Service on the issue of notification to the user community at large of known problems and fixes. The publication of FCOs, it was pointed out, lags months behind problem identification and resolution. (In fact, the FCOs incorporating the fixes outlined above are not yet published as of the latest issue of DEC-O-LOG). A question on whether the information, attributed to DEC, that Local Area VAXclusters (Ethernet based) should not use an 8700/DEBNT as a load host, was due to the DEBNT problem mentioned in this presentation. DEC said they would look into that question. VAX-12 PAGESWAPPER - September 1987 - Volume 9 Number 2 Turbo Charging VAX/VMS Ram Disk Turbo Charging VAX/VMS Ram Disk Cass Witkowski ALCOA DEFENSE SYSTEMS, INC. 16761 Via Del Campo Ct. San Diego, CA 92127 (619) 592-2078 Once upon a midnight dreary, as I pondered weak and weary, Trying to get the proposal, the proposal, out the door... I was trying to get PATRAN, a structural program written by PDA Inc., to run faster on our VAXstation II/GPX. PATRAN is written for a multitude of machines and most likely not taking advantage of some of the features of VAX/VMS that could speed it up. One PATRAN operation that the engineers perform many times requires a horrendous amount of disk accesses (8000 in 13 minutes). The RD54 on the GPX speeds along at 12 I/O's per second (Did I say speed?). Monitoring the system, I found that 20% of the time was spent in kernel mode and about 70% in user mode. Next I tried the Pseudo Disk supplied with stand-alone backup (PDDRIVER). The pseudo disk was actually slower than the RD54! Only 9 I/O's per second. The system spent 70% of its time in kernel mode and only 20% in user mode. Apparently the system was spending most of its time transferring the data between the pseudo disk's memory and the user's buffer. This normally would be done by DMA hardware with a real disk. Looking into the fiche I found that the pddriver uses two routines to move the data to and from the user, IOC$MOVTOUSR and IOC$MOVFRUSR . These routines use four instructions to move each byte of data. By patching pddriver to use the MOVC3 instruction, I was able to speed it up by a factor of 3. VAX-13 PAGESWAPPER - September 1987 - Volume 9 Number 2 Turbo Charging VAX/VMS Ram Disk The patch to pddriver replaces the calls to the data movement routines with inline code that does the same function. Upon entering the patch code: R1 = Address of data in the pseudo disk memory R2 = Size of the transfer in bytes R5 = Address of the UCB The call to IOC$INITBUFWIND set R0 = Address of the user buffer and maps the first page of it. Next the amount of data to transfer is computed. Since only one page is mapped at a time, the maximum amount of data that can be transferred at one time is 512 bytes. If the user buffer is not page aligned, then only the amount of data up to the end of the page can be transferred. This amount is then minimized by the size of the transfer in R2. The transfer occurs. If more data needs to be transferred then the next page of the user's buffer is mapped and the process begins again. The engineers at our site have used this modified driver without any ill effects, except that now their coffee breaks are shorter. This was a very quick and dirty patch to get a speed improvement. A better way would be to map the entire user buffer first and then do one transfer. This is left to the reader as an exercise. As always, patching DEC code has its support problems. Remember to keep the original version around for updates. VAX-14 PAGESWAPPER - September 1987 - Volume 9 Number 2 Excerpts From DECUS France Publications Excerpts From DECUS France Publications selected and translated by Nom D. Plume, Pageswapper Linguist DECUS France News No. 14, November 1986 **************************************** Schedule of DECUS Symposia for 1987 UK, Ireland, and Mideast March Munich March Norway April France April US April Iceland May Denmark May Europe September [just before DECworld!] US December **************************************** "VTX20, the First Computer Terminal That's Both Professional and a Multistandard Videotex Terminal" Completely compatible with the VT220 family of Digital terminals, the VTX20 offers, besides the functional characteristics of the VT220, access to the three principal European videotex standards (Prestel, Teletel, and BTX/CEPT). Two sessions can be in use simultaneously, with ASCII characters for dealing with data and videotex properties for access to the VTX database. Presented first at DECville '86, it is 100% European. The VTX20 is made in France at Digital's factory in Valbonne. [Translator's note: public videotex services are widely available by telephone subscription throughout France, and since their introduction several years ago have become extremely popular. Inexpensive small videotex terminals are likewise widely available. There are directories of videotex services, ranging from tourist information through shopping services past VAX-15 PAGESWAPPER - September 1987 - Volume 9 Number 2 Excerpts From DECUS France Publications government data services to interactive pornography, the "pink services".] "Digital Networks: the Latest Figures" Digital has just made public the latest figures of its installed base, which show its dynamism in the domain of networks. (The figures exclude Digital's internal network.) March 86 June 86 ----------------------- DECnet licenses 55,000 65,000 CPU Ethernet nodes 50,000 60,000 Total Ethernet nodes (CPU, server, etc.) 73,000 95,000 DECUS France News No. 15, December 1986 Editorial by Dr. Jean-Francois Vibert, in charge of Symposia Last March, 600 of you took part in our eighth annual Symposium, making 1/6 the members of DECUS [France]; that's still too few.... The biggest new thing [of the next Symposium] will be the day of pre-Symposium seminars on April 6. "DECUS Speaks to DECUS: the Bulletin Board at Your Disposal" Alain Barthelemy, President of DECUS France We're finally there! Today our bulletin board is working at 300 and 1200 baud via modem...and that's only the beginning!... Already the members of the VAX SIG know how to use it. Your turn will come very soon! Your moderator, our friend Jean-Pierre Petit, President of the VAX SIG, will send you your username and your password on request. A permanent dialogue among all DECUS members can only make our relationship with Digital improve. So return the attached response card today. VAX-16 PAGESWAPPER - September 1987 - Volume 9 Number 2 Excerpts From DECUS France Publications DECUS France News No. 16, January 1987 Editorial by Nicole Bonis, DECUS France representative to DECUS Europe ..Thanks to its number of members, DECUS Europe is an important organization, which can talk with DECUS US about subjects like the US Newsletters, the DECUS library ["Programmatheque"], relations with Digital... The DECUS US Newsletters, for instance, are edited in the USA, but, for European users, printed in Europe, which keeps the costs down considerably. Of course, the big European event is the Symposium that takes place each year in September and brings together about 1,700 persons. It's the place where you're privileged to meet English, German, Italian, Dutch, and Finnish users... and French ones who share your concerns; as well as many developers from Digital US. Between two Symposia, the contacts between the countries aren't broken; SIG heads meet twice a year, the country representatives four times a year. So if you need a European contact, don't hesitate to talk to me. While we wait, let's dream a little (after all, X400 is coming), that all the members of DECUS Europe may have access to a European bulletin board. "Express Consultation" [insert to the newsletter] "CDROM" All the members of DECUS France are getting this publication ... For about a year Digital has offered to its clients, at least in the USA, a CDROM (Compact Disk Read-Only Memory) reader. Among the most attractive applications it might support, it's envisaged to use the medium to distribute hardware and software documentation. In this model of things, at some undefined intervals we would get a CDROM (600 megabytes) instead of the habitual unwieldy documentation kits. This medium could also allow, through a system of encryption, the distribution of software binaries. Take a few moments to give us your advice. [Second side] 1. Do you want the distribution of documentation on CDROM? Program documentation ___ no ___ exclusively ___ optionally Microfiches ___ no ___ exclusively ___ optionally Software binaries ___ no ___ exclusively ___ optionally VAX-17 PAGESWAPPER - September 1987 - Volume 9 Number 2 Excerpts From DECUS France Publications If not, please specify your reasons: 2. Would you want the documentation of groups of Digital software products on the same CDROM, or would you want one CDROM per product? ___ All products on the same disk ___ Only one product per disk 3. How often would you want to get updates? ___ At each new version of any product(s) on the disk ___ At a fixed interval of one disk each month ___ At a fixed interval of one disk each two months ___ At a fixed interval of one disk each three months ___ At a greater fixed interval 4. Would you want to get binary updates, accompanied by decryption keys tied to usage licenses, on CDROM or by traditional means? ___ Traditional means (diskettes, cassettes, tapes...) ___ 1 CDROM per product ___ All products on the same CDROM with a system of encryption/decryption This method of distribution supposes the acquisition of a CDROM for your system(s), and moreover, the generalization of this equipment. 5. If this mode of distribution were envisaged, should the reader be: ___ Sold as usual to all interested clients ___ Sold at a special price to all interested clients ___ Integrated into all new systems ___ Without surcharge ___ With a surcharge ___ Furnished in the context of a software support contract ___ Furnished and installed in all systems in the same way as remote diagnostic hardware 6. If this system of distribution were adopted, do you think it would: ___ Completely replace the distribution of support documentation on paper (the impression being given of your concern for a standard means of using it, integrated into the system) ___ Coexist with the classical support documentation on paper VAX-18 PAGESWAPPER - September 1987 - Volume 9 Number 2 Excerpts From DECUS France Publications "DECUS France CAROLLs" There were already Cesars and Oscars for the cinema, so there had also to be a trophy for DECUS. There's been one since 1984, since our Symposium in Bagnolet. The Office of DECUS France decided to pick out each year one award per SIG during the Symposium. This reward crowns the author(s) of the best program presented to DECUS during the preceding year (from one Symposium to the next). It is presented in the form of a trophy which has rapidly taken the character of an honor and a reward for the winners.... During the year, with your SIG chair, you choose the "best" among the the programs created and donated by members of the SIG. Let's understand as "best" those you use most, those that show up the most in your daily work, or those that seem to you the most useful to the community; you should really take the term "best" in its largest sense. During SIG meetings held during the Symposium, by secret ballot, winners will be chosen for each SIG. The results will be proclaimed during the General Meeting the same evening, and the Trophies solemnly bestowed.... VAX-19 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange A form for INPUT/OUTPUT submissions is available at the back of the issue. To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. ================================================================ Note 565.2 RM02's on a VAX/750 2 of 2 "Jim Preciado" 25 lines 6-JUL-1987 22:42 -< Here's the recipe >- ---------------------------------------------------------------- Open the bottom of the RM02 and slide out the MASSBUS card cage. On the right side of the card cage is a wire wrap backplane. In the upper left corner of this backplane are three jumpers. On of them is labeled 3600 RPM. Put this jumper in and your RM02 will appear now to be an RM03. Actually, this jumper has nothing to do with the spindle speed of the disk, it just toggles the low bit of the MASSBUS drive type register (RMDT). This device type is a 25 (octal) for an RM03 and 24 for an RM02. Voila, DRDRIVER configures the device as an RM03 and all is well. MASSBUS disks can be dynamically dual-ported between both ports even if one side is an RSX system. Just deal with the disk like you did in non-cluster days and mount it read/write on one side only and read-only on the other. Also include the /NOCACHE switch so that directories get updated as soon as possible on the disk. All VAX RM03 diagnostics run on this RM02 that thinks its an RM03. The seek tests will fail because the spindle speed of the drive is slower but things like data reliability work just fine. I had an arrangement where an RM02 was dual-ported between an 11/780 and an PDP-11/34. I used to back my real RM03 system disk up to the RM02 (after taking down the PDP) and it saved me a few reels of tape. RM03 and RM02 disk packs are interchangeable so I could rotate my system disk VAX-20 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT backup when done. I was also able to boot the 780 from the RM02 when the RM03 was down. The processor ran a bit slower but a slow VAX is better than no VAX at all when your system disk is in trouble. Jim Preciado 139 Johnson Ave Mahwah, NJ 07430 ================================================================ Note 599.10 Any PSI users out there? 10 of 11 "Carl Hartshorn" 23 lines 8-JUL-1987 14:24 -< Early success with PSI/DecNet >- ---------------------------------------------------------------- I used PSI at a former company over two years ago under VMS 3.5. At that time, we were one of the first in the Bay Area to set up a PSI network for more than just dial-in. We had a 9600 line to TYMNET and the intention was mail and file transfer via DecNet. After some initial PSI protocol problems, we had a link to our local office in Munich, WG. This required going TYMNET to Piscataway, NJ where RCA or ITT took over (it varied), then to the West German equivalent of Tymnet, which is government-owned. I can't remember the name of the facility. We routinely transferred large (1-Megabyte) files, usually at night or over weekends, back and forth. Transfer times were typically 0.8Meg/hour. Also mail was sent back and forth on a daily basis. The only problems were trying to log in via Set Host on the other VAX. In this case, EDT was a problem because of the nature of the X.29 protocol. (I think this has been improved in later versions of PSI. We had 1.2) Carl Hartshorn 116 Whispering Pines Ct Scotts Valley, CA 95066 408/773-8484 VAX-21 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 599.11 Any PSI users out there? 11 of 11 "Bob Tinkelman" 26 lines 8-JUL-1987 21:36 -< Experience with VAX PSI >- ---------------------------------------------------------------- < Is anyone who reads this using VAX PSI? If so, what for?> For those still interested in the original question, here's a summary of our experience. We use VAX PSI for two purposes. The primary one is for DECnet between a VAX in New Jersey and a PDP11 in Hong Kong. (Of course the 11 is running RSX PSI.) The link is brought up once a week for a few file transfers. Initially, we had a lot of grief getting all of the parameters set consistently on the two PSIs and the two hosts. Once things stabilized, we were able to run with the link staying up long enough for multi-megabyte files to get transferred. (Earlier, the symptom of most problems was "broken link".) We never satisfactorily solved the problem of low throughput though we did identify exactly what was going wrong (the subject of another note in this conference). The other use we've made of VAX PSI is for PAD terminal access. We've found performance quite acceptable here (though clearly not as good as directly connected non-multiplexed terminal connections). I guess I should mention that in our environment, all the terminals were connected to their "pads" via 9600 baud lines and all of the synchronous links in the path were at least 9600 bps. Bob Tinkelman Cambridge Computer Associates, Inc. 56 Beaver Street, 3rd floor New York, NY 10004 1-212-425-5830 VAX-22 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 604.1 VAX 11/750 Boot ROMs 1 of 1 "Stephen Simm" 22 lines 5-JUL-1987 14:36 -< DEFBOO >- ---------------------------------------------------------------- While not a direct answer to your UB1 problem the following may be of help: The VAX-11/750 processor ROM will only boot off of the zero-th unit on the controller. This device can obviously be a TU58. Now here comes the fun part: The console TU58 works the same as the console disk required to boot a VAX-11/78x. Start with an EXCHANGE COPY of the console TU58 that (hopefully) is kicking around in the box of F/S diagnostics. Create a file on the cassette containing the bootstrap commands required for the particular controller -- see the other *BOO.CMD and *GEN. procedures -- under the name DEFBOO.CMD. When BOOT58 finds this file it will start executing commands from it. For an example pull apart the V4.0 VMS upgrade kit. Digital used this tactic to boot off of an alternate root during the upgrade. Stephen Simm P.O. Box 4 Poestenkill, NY 12140-0004 518-458-2409 ================================================================ Note 607.12 DECserver 200 application ports - how? 12 of 13 "Ken A L Coar" 26 lines 2-JUL-1987 09:56 -< Finding the physical port on a DECserver >- ---------------------------------------------------------------- > Now just fix it > so I can tell what physical port I'm logged into!!! Found it! VAX-23 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT There are currently two ways of doing this (VMS 4.5). The first is to use the following sequence: $ MCR LATCP LCP> SHOW PORT LTA133 The other is to look at the UCB of your LTA terminal. At offset 134 (hex) there is a counted string containing the name of the port on the DECserver that you are physically connected to. Note that, by default, this string will be something like PORT_1, unless you've changed the name of the port on the server. Further information: Colorado Springs says that VMS 4.6 contains an `undocumented but supported' (that's a new one on me! ;-)} ) $QIO interface which will allow you to fetch this information. They wanted to get it into $GETDVI, but couldn't manage it, for 4.6, at least. When you get 4.6, call Colorado and ask for the terminal server team - they should be able to give you the details on how to use the interface. #k Ken A L Coar General Dynamics Office Systems 12101 Woodcrest Executive Drive Creve Coeur, MO 63141 (314) 851.4003 (CST) ================================================================ Note 631.1 RA81 FCT File Format 1 of 1 "Stephen Simm" 18 lines 5-JUL-1987 14:46 -< N'way at N'ville >- ---------------------------------------------------------------- I was looking for roughly the same information at the N'ville symposium. The folks at the storage systems booth said it "wasn't available with VMS up since the drive and the controller handled it." The suggestion was made (by a 3rd party F/S-type to scrounge up a set of diagnostic listings and figure it out the hard way. VAX-24 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I am still looking for a way to get the volume serial number back -- with VMS running. (I know that the GETDVI call doesn't work on RA81's...) If you find what you're looking for I'd appreciate a note... Stephen Simm P.O. Box 4 Poestenkill, NY 12140-0004 518-458-2409 ================================================================ Note 635.2 CALLABLE EDITORS IN MAIL 2 of 2 "Mark Oakley" 12 lines 21-JUL-1987 00:32 -< CALLABLE_LSE also. >- ---------------------------------------------------------------- > I'm not sure how many people are aware of it, but there > is a way to create/edit mail messages without creating a > subprocess. Simply define the following logical name: > > $ DEFINE MAIL$EDIT CALLABLE_xxx > > where "xxx" is either "TPU" or "EDT". A user brought to my attention that "xxx" can also be LSE, if you have that product. However, it is important to install LSESHR (in SYS$LIBRARY) and LSEMSG (in SYS$MESSAGE). Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 VAX-25 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 642.11 print&batch complaints 11 of 11 "John Osudar" 19 lines 30-JUN-1987 12:05 -< What does all this mean? >- ---------------------------------------------------------------- I think that the whole sequence of comments to this note reflects the basic problems with the job controller/queue manager under VMS V4.x: there is a lack of consistency in the way operations are carried out; there is a lack of documentation on both the queue manager's and the default print symbiont's operations (and please note: being able to find it "in the fiche" is NOT good enough, nor is it reasonable to force every system manager to read every manual in the VMS manual set to find the information -- especially since it may not even be there!); and there is a lack of support for the types of devices that are used on VAXes (e.g. various laser printers). I don't expect DEC to support my (brand X) laser printer directly -- but I also don't expect them to make it an order of magnitude more difficult for me (or the printer manufacturer) to support it, but quite often they DO. I guess this amounts to a plea/request/demand to the VMS developers in the queue manager/print symbiont area: PLEASE look at the problems users are having with the V4.x software, and try to give us some clean, documented fixes in that "unnamed, unnumbered", unmentionable future major release that we might be getting sometime next year. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-26 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 650.8 Heavyweight update! 8 of 12 "Reece Pollack" 18 lines 30-JUN-1987 21:05 -< Bugs in DECServers & LATplus >- ---------------------------------------------------------------- Bug Alert!! Bug Alert!! There is a bug in the standard DECserver 100, DECserver 200, and LAT-Plus distributions! The problem is with terminals mysteriously dropping off of the host and other such fun stuff. Check the rev levels of your software -- Product Standard Patched ------- ---------- ---------- DS-100 V1.3 BL15 V1.3 BL15A DS-200 V1.0 BL20 V1.0 BL20C LATPlus V1.1-23 V1.1-24X These patches should be available from your local DEC office, or wherever you normally get special patches. I spent months trying to fix some of the problems these patches fixed (including not being able to do a SET HOST/DTE to an LTAn port for more than 30 seconds at a time (this plays havoc with KERMIT). Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 650.9 Heavyweight update! 9 of 12 "Brian Tillman, Lear Siegler, Inc." 6 lines 1-JUL-1987 15:16 -< LATplus is now V1.2 >- ---------------------------------------------------------------- RE: < Note 650.8 by NODE::US216482 "Reece Pollack" > -< Bugs in DECServers & LATplus >- | LATPlus V1.1-23 V1.1-24X VAX-27 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT LATplus is now V1.2. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 656.1 Replacement of BNT 1 of 2 "Gus Altobello" 28 lines 22-JUL-1987 17:02 -< Replacement of DEBNT with DEBNA >- ---------------------------------------------------------------- Our newly-purchased (about 2 months ago) 8530 arrived with a DEBNT BI Ethernet controller. It had a number of strange hardware problems, so I called Colorado Support Center. After being told that my problems "didn't sound like any of the known problems", I asked what OTHER kind of problems were occurring. It appears that the DEBNT (which isn't listed in my Systems and Options Catalog) has been replaced by a device called the DEBNA. Later shipments of 8530's to us are reputed to contain the DEBNA device. My understanding is that there was a small window during which DEC shipped 8xxx systems with DEBNTs. Before that the only Ethernet devices were DEUNAs on a Unibus, and since then they've been shipping DEBNAs. My first 8530 fell into this window. Field Service replaced my DEBNT with a DEBNA, and things are working better now. I still haven't resolved the problem where disconnecting the transceiver cable causes circuit up/down messages to repeat at 10 second intervals, though... Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 VAX-28 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 656.2 Replacement of BNT 2 of 2 "Kevin Angley" 9 lines 30-JUL-1987 10:14 -< The "T" stands for tape >- ---------------------------------------------------------------- I have an 8550 that fell into (out of?) the DEBNT window. This is an interesting beast. DEC won't talk about it. It doesn't work well. The "T" in the DEBNT stands for tape - it has something to do with TK50 (and/or TK70). Now - does that mean that the DEBNT was a TK controller which was modified to be an Ethernet controller? Or does it mean that at one time, there was the intention that it be a dual function card? Speculate. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 660.27 Applications software standards 27 of 29 "John Osudar" 31 lines 9-JUL-1987 16:24 -< software installation maintenance issue >- ---------------------------------------------------------------- This reply is loosely related to the original topic... One thing that would be useful, both for system managers and applications software suppliers (and, most likely, to DEC as well) would be a file identifying which versions of software products are installed on the current system. (Yes, I know this can be done by checking the IDENT of executable images, but what about products that consist of command procedures or other non-EXE files?) I have developed a number of software packages that are installed on various systems here at ANL and elsewhere; some of these rely on common components. I also share system management duties on several VAXes with a couple of other people; in that role, I often have to install software packages supplied by others (including DEC, of course). When I install (or send out for another system manager to install) one of these packages, it would be very useful to know: VAX-29 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT (a) whether any of the underlying software is already installed on that system (b) if it is, whether it's the latest version (c) (and, in some cases) whether the software has been modified locally, where applicable. I could set up my own file, listing my own software components and the versions installed, but wouldn't it be more useful if this were a single, central, DEC-supported, DEC-documented (and, yes, DEC-used) facility? Your installation procedure (whether VMSINSTAL or not) could then verify, for example, that the versions of other related products currently installed are compatible with what you're attempting to install. Further, for us system-manager types, it would provide a more convenient, and certainly easier to maintain (if it's automatically maintained by installation procedures!) list of currently installed products. By making the list open to DEC, non-DEC commercial, and local software products, there would be a single, common method for determining the software available on the current system. Any comments? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 660.28 Applications software standards 28 of 29 "John Saunders" 6 lines 10-JUL-1987 19:49 -< Could you be More Specific? >- ---------------------------------------------------------------- I'm not 100% sure what you mean by "related" products. Could you give some examples? I've never had any problem with this installing commercial products. They usually don't need anything which isn't provided with the product, and they usually keep track of their own interdependencies. John Saunders FEL Computing VAX-30 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT PO Box 72 Williamsville, VT, 05362 (802) 348-7171 ================================================================ Note 660.29 Applications software standards 29 of 29 "John Osudar" 18 lines 10-JUL-1987 20:30 -< more specifically... >- ---------------------------------------------------------------- In the case of DEC-supplied products, an example of "related" products would be: CDD, Datatrieve, RDB -- new releases of these typically have certain inter-dependencies upon specific releases of the others. For a non-DEC commercial example: we have Talaris laser printers here, and Talaris supplies software, fonts, etc. to support them. You need certain versions of some software (e.g. their font manager) to support other software (e.g. font definition files), possibly to several levels (e.g. a version of TeX may depend upon a certain version of the fonts being installed). Other examples involve locally developed software, Sig tape software, and software developed at other sites. For example, I have a generic server symbiont called EXECSYMB that is used in about a dozen different software packages, and is in use at a bunch of sites (both here at ANL and around the country). When I send out a new release of one of those packages, I need to know whether the target system has the latest version of the symbiont, so that the installation procedure can install the latest version if it's not there (or can at least complain about it). John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-31 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 663.26 Comments on the SPR process 26 of 27 "John Burnet" 24 lines 22-JUL-1987 14:15 -< BTW, DSIN is now on Tymnet >- ---------------------------------------------------------------- -< DSIN: both good and bad >- On the subject of DSIN... I agree that this "service" is practically useless where getting timely information about VMS problems and bug fixes is concerned. However, I have found that there *is* a great deal of useful and interesting stuff available through DSIN. Now, I'm not talking about the "flash" items; those seem to have died out (last time I checked, there were three items listed under product "VMS"), and DEC might as well remove the "flash" facility if they're not going to add any useful items to the database. What I *have* found to be a good service is what used to be called "ssi" and is now called "txt" (text search, by keyword, of the symptom/solution database). Of course, this usually isn't much good for getting up-to-the-minute information on recently discovered bugs; but if you choose the keywords carefully, you can find out a lot of things that don't appear in the vms doc set. P. S. to the last note... DSIN can now be accessed through Tymnet. This means that all of us folks outside the 303 area code no longer have to make long-distance calls to get to it. (DEC should have provided an 800 number for DSIN years ago, but Tymnet's almost as good.) John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-32 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 670.2 Set Watch 2 of 3 "Larry Kilgallen" 57 lines 4-JUL-1987 08:53 -< Simultaneous Discovery Elsewhere >- ---------------------------------------------------------------- ================================================================ Note 684.0 UNDOCUMENTED DCL COMMAND No replies "Jerry Tardif" 50 lines 3-JUL-1987 09:28 ---------------------------------------------------------------- Recently, I came across an undocumented DCL command that causes some interesting information to dump out as you execute other DCL commands. The command is called "SET WATCH" and allows you to view (among other things) the read attributes of files accessed and the contents of the File Information Block. The command itself is invoked as follows: $ SET WATCH FILE/CLASS=ALL Currently, there appears to be only one object to watch - Files. One can only assume that DEC will at some later time add such objects as "DEVICES" and "TABLES" (Logical Name Tables?). The CLASSES options are as follows: 1) ALL 2) ATTRIBUTES 3) CONTROL_FUNCTION 4) DIRECTORY_OPERATIONS 5) DUMP 6) ATTACHED 7) MAJOR_FUNCTIONS 8) NONE 9) QUOTA_OPERATIONS I have been using this command from a privileged account running under VMS V4.5. It does not work from a non-privileged account and I have not yet attempted to determine exactly what the required privileges are. VAX-33 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I could not find anything documented in "HELP". It appears that DEC has ceased entering remarked-out help text into "HELPLIB" now that they are fully aware of our lust for unannounced "features". A call to the CSC for another problem prompted me to ask circuitous questions about "SET WATCH FILE" but was to no avail. CSC said that the problem with providing this type of information is that they have had to take a lot of heat from some customers who expect EVERYTHING to be supported whether it is documented or not. The fact that some people don't realize that DEC needs some time to develop and debug new features is really too bad because it means the rest of us lose access to early information we might have had. I would be interested in hearing from others who have tried this command, or better yet, have derived still more information regarding its use. Good Luck! Jerry Tardif CMEEC 268 Thomas Road Groton, Connecticut 06340 ================================================================ Note 670.3 Set Watch 3 of 3 "Larry Kilgallen" 28 lines 4-JUL-1987 09:05 -< "Announcement" History of SET WATCH FILE >- ---------------------------------------------------------------- This undocumented feature has been mentioned in several DECUS Symposia presentations, and I know of at least one presentation where it was mentioned (as an undocumented feature) well in ADVANCE of its release (in VMS V4.4). It has been discussed a bit in the security context, as a first level approach to finding out what a layered product (from any vendor) is doing to the file system, and a way of looking for some of the more simple-minded of Trojan Horses. It is analogous to a similar feature of TOPS-10. So how does one get this information if one does not get to go to DECUS Symposia? I think one group to hold "responsible" is those from your Local Users Group who DO get sent to symposia. The Boston VAX LUG reserves the monthly meeting after each symposium for an exchange of information learned at the symposium, with various members relating what they "covered". It turns out even those who attend symposia learn a lot from the LUG meeting because nobody can go to all the simultaneous VAX-34 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT sessions. Personally I would rather see the programmer who implemented SET WATCH FILE go on to the next neat feature (and there are several I want to see) than fight the DEC internal establishment about just when and in what fashion this should be documented/supported. Since it requires CMKRNL anyway, this discussion in the Pageswapper may be enough. Long live the Microfiche ! Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 673.3 Tab problems with LN01 3 of 5 "Reece Pollack" 7 lines 30-JUN-1987 20:49 -< DMF32 Tab Expansion >- ---------------------------------------------------------------- I confirm the fact that the DMF32 does tab expansion in its firmware, and I also recall a bug in that firmware. However, I'm not sure that the print symbiont doesn't do tab expansion; the symbiont checks the device characteristics to see if it needs to do tab expansion (otherwise a left margin might screw things up). I'll check on it and call back one of these days... Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 673.4 Tab problems with LN01 4 of 5 "Jamie Hanrahan" 7 lines 1-JUL-1987 14:23 -< print symbiont can do it too >- ---------------------------------------------------------------- Yes, the print symbiont does do tab expansion if the left margin specified in the form definition is not a multiple of 8. This suggests an interesting work-around to my problem -- specify left margins of 1 for all forms! VAX-35 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Tab expansion in firmware is a neat trick. Does anybody know the exact FCO or ECO number for the DMF? Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 ================================================================ Note 673.5 Tab problems with LN01 5 of 5 "Jonathan Pinkley" 54 lines 2-JUL-1987 15:59 -< The problem is LCDRIVER >- ---------------------------------------------------------------- We reported this problem and its cause to Colorado in April of 1986. We had just begun using the DMF32 parallel port instead of an older LP11 card. After we determined that the problem was in the incorrect interpretation of the LP$M_TAB bit in the setmode/setchar $QIO to the LCDRIVER, we reported this to Colorado. The following is essentially what we told them. We have seen problems with the DMF32 mishandling tab characters at OSD. We have printers on DMF32 parallel ports and LP11 cards. None of the printers are capable of handling tab characters. However, to tell the LP11 driver to expand tabs into spaces, we use the $ SET PRINTER/NOTAB LPxx: command. To tell the DMF32 driver to expand tabs into spaces, we say $ SET PRINTER/TAB LCxx: The negation of those commands allows tabs to be passed to printers that can handle tabs correctly. Our first call to Colorado was answered with "Make sure your DMF32 is above Rev K." After finding that the board was at Rev L, we were told "O. K. We'll be sure to fix the documentation to reflect that." (This is not a joke!) VAX-36 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT In short, the work around to the problem is to tell the LC port on the DMF to do the opposite of what the documentation indicates the /TAB switch does. It appears that our call was "Noted" (ignored). All DEC has to do is flip a bit the other way in a DMF CSR. A single instruction in the LCDRIVER could fix this problem. In fact in VMS V4.5 this can be done with the following patch to LCDRIVER.EXE: $ copy sys$system:lcdriver.exe sys$scratch: $ set default sys$scratch: $ patch lcdriver.exe PATCH>ex/ins 1f9 000001F9: BBS #06,B^44(R5),00000206 PATCH>deposit/ins 1f9='bbc #06,b^44(r5),206' old: 000001F9: BBS #06,B^44(R5),00000206 new: 000001F9: BBC #06,B^44(R5),00000206 PATCH>update PATCH>exit You can test this patch by reloading it with sysgen. For more information see fiche #150 and 151 of the VMS 4.4 fiche set. Jonathan Pinkley Gould OSD Dept. 913, Bld. 2 18901 Euclid Avenue Cleveland, OH 44117 (216)486-8300 x1335 ================================================================ Note 676.1 CMS 2.3 problem with ACL's 1 of 7 "Reece Pollack" 12 lines 30-JUN-1987 21:19 -< "MAGIC" ACE problems again >- ---------------------------------------------------------------- It looks like you got bit by the same bug DEC said would never happen with the automatic ACE trick. RMS adds an ACE to the new file which is built from the default protection for the file plus the CONTROL access. It looks like you have no access for the user by default, and since the "magic" ace has that protection... VAX-37 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Try adding a DEFAULT_PROTECTION ACE to the directory file or changing the default protections specified if you already have one to add access for the owner (I think it's owner -- somebody help me out!). DEC said that the "magic" ACE wouldn't cause problems, but they wuz wrong! This has already been SPR'd and was a lively subject of discussion at DECUS. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 676.2 CMS 2.3 problem with ACL's 2 of 7 "Brian Tillman, Lear Siegler, Inc." 13 lines 1-JUL-1987 15:24 -< OWNER field is a template for ACEs >- ---------------------------------------------------------------- RE: < Note 676.1 by NODE::US216482 "Reece Pollack" > -< "MAGIC" ACE problems again >- | (I think it's owner -- somebody help me out!). Yes, indeed. The ACL facility is going to be nice to you and grant you "OWNER" privileges. So, it takes the OWNER field as a template and creates an ACE containing your UIC, an OPTIONS=NOPROPAGATE clause, and the OWNER access with CONTROL added. So, if the DEFAULT_PROTECTION ACE specifies OWNER=RWED, the ACE will contain R+W+E+D+C. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-38 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 676.3 CMS 2.3 problem with ACL's 3 of 7 "Jack Patteeuw" 14 lines 10-JUL-1987 12:02 -< Bad Magic >- ---------------------------------------------------------------- re: .2 Yes the "magic" ACE has bitten me in the butt too !! Even if I have an ACE on the directory that specifies what the ACE should be on the files I create in that directory I get the "magic" one !! This is especially a problem because the "magic" ACE contains a OPTION=NONPROPAGATE which means that if someone else who has write access to this directory comes along and places another file with the same name in the directory I can't access it !! The "magic" ace is nice in some cases but I think if a default ACE is specified on the directory file for your identifier that you should get that ACE and NOT the "magic" one Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 676.4 CMS 2.3 problem with ACL's 4 of 7 "Michael R. Pizolato" 44 lines 13-JUL-1987 15:04 -< How we handle it >- ---------------------------------------------------------------- We use ACL's in this type of situation very heavily (on a directory structure containing thousands of files), and have had no problem. We simply insure that the default ACL's to be applied to the files ignore the "magic" ACE, so that there is an ACE to cover anyone who will be accessing the file. We have about 5 different types of users who need different kinds of access to the files, but the ACL is not terribly long, and it's self-maintaining (we put it on the directory at the top of the tree and it just propagates itself downward very nicely). Of course, if it ever has to be modified, it's a little bit VAX-39 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT difficult, but we've managed quite well so far. Here's what the ACL looks like on the top level directory (the DIRECTORY command output has been edited to fit on the screen): $ DIRECTORY/SEC CODES.DIR Directory USER_DISK:[CUSTOM] CODES.DIR;1 CUSTOM_PROGRAMS (RWE,RWED,,) (ID=[CUSTOM,CUSTOM_MGR],ACC=R+W+E+D) (ID=[CUSTOM,*]+TEST_ENGR,ACC=R+W+E+D) (ID=[CUSTOM,*]+PROD_ENGR,ACC=R) (ID=[TECH,*],ACC=R) (ID=*,ACC=NONE) (ID=[CUSTOM,CUSTOM_MGR],OPT=DEFAULT,ACC=R+W+E+D) (ID=[CUSTOM,*]+TEST_ENGR,OPT=DEFAULT,ACC=R+W+E+D) (ID=[CUSTOM,*]+PROD_ENGR,OPT=DEFAULT,ACC=R) (ID=[TECH,*],OPT=DEFAULT,ACC=R) (ID=*,OPT=DEFAULT,ACC=NONE) The first 5 lines are the protection on the directory itself, and the second 5 lines are the ACE's that get propagated down the tree. The files in the tree are owned by identifier CUSTOM_PROGRAMS so that individual users aren't charged for the space. CUSTOM_MGR is the username of the group manager for group CUSTOM. All TEST_ENGR's get full access to the files, regardless of who put them there. PROD_ENGR's and members of group TECH get read access. TEST_ENGR and PROD_ENGR are non-resource identifiers that are granted to the appropriate users. In this scheme, the "magic" ACE is completely irrelevant, since every user's access (including that of users who are "world" with respect to the tree) is covered in the ACL. Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 VAX-40 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 676.6 CMS 2.3 problem with ACL's 6 of 7 "Brian Tillman, Lear Siegler, Inc." 50 lines 14-JUL-1987 13:46 -< Thoughts on an example >- ---------------------------------------------------------------- RE: < Note 676.4 by NODE::US191492 "Michael R. Pizolato" > -< How we handle it >- ! CODES.DIR;1 CUSTOM_PROGRAMS (RWE,RWED,,) | (ID=[CUSTOM,CUSTOM_MGR],ACC=R+W+E+D) | (ID=[CUSTOM,*]+TEST_ENGR,ACC=R+W+E+D) | (ID=[CUSTOM,*]+PROD_ENGR,ACC=R) | (ID=[TECH,*],ACC=R) | (ID=*,ACC=NONE) | (ID=[CUSTOM,CUSTOM_MGR],OPT=DEFAULT,ACC=R+W+E+D) | (ID=[CUSTOM,*]+TEST_ENGR,OPT=DEFAULT,ACC=R+W+E+D) | (ID=[CUSTOM,*]+PROD_ENGR,OPT=DEFAULT,ACC=R) | (ID=[TECH,*],OPT=DEFAULT,ACC=R) | (ID=*,OPT=DEFAULT,ACC=NONE) We, too, use ACLs extensively and our files get owned by resource identifiers, just as in your example. The ACL, though, seems just a little at odds with my understanding of how things would work. Perhaps you can tell me how you perceive the operation of the above directory. My perception is as follows: Since you don't specify who holds CUSTOM_PROGRAMS, I first assume no one does. This means that any process creating a file in this directory (the process with UIC [CUSTOM,CUSTOM_MGR] and those processes in the same UIC group which hold the TEST_ENGR identifier) will wind up owning the file, since you must hold the resource identifier in order to charge against it. RMS won't add an ACE for the creating process, since the process will own the file. Now I'll assume those who are allowed WRITE access also hold the CUSTOM_PROGRAMS identifier. Why then would you not want to just have an ACE that states: (IDENTIFIER=CUSTOM_PROGRAMS,ACCESS=READ+WRITE+EXECUTE+DELETE) and just get rid of your first two ACEs (of course, the same applies to the OPTIONS=DEFAULT ACEs as well). It's not clear to me that even if the two collections of processes that are allowed write access do hold the CUSTOM_PROGRAMS identifier, that ownership would be assigned to CUSTOM_PROGRAMS, since VAX-41 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT CUSTOM_PROGRAMS isn't mentioned in the ACL at all. Finally, since the WORLD access field in the UIC-based protection doesn't allow access, the ID=* ACE is redundant. While this wasn't true in VMS 4.3 and earlier, in VMS 4.4 they changed ACLs so that WORLD protection means something, which is reasonable, since the concept of WORLD is still valid. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 676.7 CMS 2.3 problem with ACL's 7 of 7 "Kevin Angley" 15 lines 30-JUL-1987 10:38 -< Further info on Magic ACE >- ---------------------------------------------------------------- Some further thoughts on the issue ... I have spoken to people who support the magic ACE by saying "All it is doing is exactly what the owner UIC protection gives you anyway". Well, yes and no. This is true only if Access provided via UIC > Access provided by ACL As it stands in my example, the magic ACE blocks the holder's access to the file which would otherwise be granted by the ACL. If the magic ACE were at the bottom of the ACL list, there would be no problem in this case (but you;'d have to think about that too). The point is ... the magic ACE is NOT harmless ... it is not a No-op. I see WHAT it is - my question is WHY is it? Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 VAX-42 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 677.3 Bug with ACL (VMS 4.5) 3 of 8 "Reece Pollack" 15 lines 30-JUN-1987 21:27 -< Fixed in a future release... >- ---------------------------------------------------------------- Just playing the Devil's Advocate, let's look at this from DEC's side. I'll bet DEC is already spending most of their time fixing bugs in (dare I say it) V5.0, and spending the time to go back and fix a bug in V4.x when it's already fixed in V5.0 looks an awful waste of time. On the other hand... I once got an SPR answer (!) which stated a bug in V3.5 was fixed in V4.0 -- a very terse answer at that. I later got a phone call from a very embarrassed DEC employee who suddenly desired to give me full details on what the bug was and how it could be worked around. It seems his boss got ahold of his response and jumped on him with both feet for being inconsiderate. Sometimes they lose sight of the fact that waiting 6 months to a year for a bug fix is not acceptable, even if it is already fixed in the next release. Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 ================================================================ Note 677.4 Bug with ACL (VMS 4.5) 4 of 8 "Greg Isett" 35 lines 2-JUL-1987 20:43 -< BACKUP/SCRATCH ACL problem >- ---------------------------------------------------------------- -->Reply to 677.1 --> Backup/Acl problems >By the way, watch out for BACKUP and ACLs. Here at Lear Siegler >we have our disks organized such that personal files (login >directories) are on one set of disks and project files (owned >by resource identifiers and accessed via ACLs) are on another >set. VAX-43 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT We have a very similar project accounting scheme here at HRB. The only way I found restores to work is via: BACKUP/INTERCHANGE [source] [destination]/OWNER=PARENT This appears to work by /OWNER=PARENT giving the correct UIC, and /INTERCHANGE doesn't copy ACLs and thus VMS puts the appropriate default ACLs on the files. Granted, it's a real PAIN and most users forget /OWNER and get "quota exceeded" or more irritating, forget /INTERCHANGE and get "protection violation" (i.e. create a file that they can't delete). >Now, on project disks, only the resource identifiers have >quotas, so the file can't be created because the restoring >process doesn't have any quota. Tho we try to give only resource identifiers a quota on our project disks, we had to give some users a UIC quota on the project disk. We found that FORTRAN files opened as "SCRATCH" will be charged to the user's UIC quota rather than the project's quota. Greg Isett hrb-singer incorporated department 125 p o box 60 state college pa 16804 ================================================================ Note 677.5 Bug with ACL (VMS 4.5) 5 of 8 "Brian Tillman, Lear Siegler, Inc." 20 lines 6-JUL-1987 12:11 -< Scratching where it itches >- ---------------------------------------------------------------- RE: < Note 677.4 by NODE::US183688 "Greg Isett" > -< BACKUP/SCRATCH ACL problem >- | BACKUP/INTERCHANGE [source] [destination]/OWNER=PARENT Thanks, I'll try it! | We found that FORTRAN files opened as "SCRATCH" will be | charged to the user's UIC quota rather than the project's | quota. VAX-44 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT You can fool some of the images that create scratch files with: $ define FORxxx 'f$environment("default")'forxxx. If you write your own applications in FORTRAN and want to have scratch files charged to the project quota, make sure the OPEN statement contains "FILE='SYS$SCRATCH:FORxxx'" and $ define SYS$SCRATCH 'f$environment("default")' Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 677.6 Bug with ACL (VMS 4.5) 6 of 8 "Brian Tillman, Lear Siegler, Inc." 9 lines 7-JUL-1987 14:16 -< Thanks!!! >- ---------------------------------------------------------------- RE: < Note 677.4 by NODE::US183688 "Greg Isett" > -< BACKUP/SCRATCH ACL problem >- | The only way I found restores to work is via: | | BACKUP/INTERCHANGE [source] [destination]/OWNER=PARENT It work, it WORKS!!! Great! Thanks, Greg!!! This solves a TREMENDOUS problem with us. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-45 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 680.0 Looking for DEC PCFS Experiences 2 replies "Mark Oakley" 13 lines 29-JUN-1987 23:19 ---------------------------------------------------------------- We would like very much to contact any sites that use DEC PCFS (VMS Services for MS/DOS). What have your experiences been, and why did you select DEC PCFS? Please respond to this note, or contact: Brian Lockrey Ken Baugess Battelle Columbus Division Battelle Columbus Division 505 King Ave. 505 King Ave. Columbus, OH 43201-2693 Columbus, OH 43201-2693 (614) 424-7281 (614) 424-5978 Thanks! Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 ================================================================ Note 680.1 Looking for DEC PCFS Experiences 1 of 2 "M. Erik Husby" 19 lines 1-JUL-1987 17:28 -< PCFS Experiences >- ---------------------------------------------------------------- I have some limited experience with PCFS. I have it running on our 785 and our microVAX. As we were getting VAXmates to run on an ethernet there was a lot of choice. It appears to work nicely provided: Your ethernet is stable -- we had hardware problems for a while that caused transmission errors. The VAXmate would loose its virtual disks and the only way to get them back was to reboot. The VT220 and VT240 emulators could recover from the error. VAX-46 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I have not tried to measure throughput, and as we only have 3 VAXmates, I am not concerned now. Although I maybe concerned in the future. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 680.2 Looking for DEC PCFS Experiences 2 of 2 "Chris Erskine" 29 lines 2-JUL-1987 12:50 -< Additional Experience >- ---------------------------------------------------------------- I have been supporting a site that currently has about 35 VAXmates with more coming in all of the time. The biggest problem that we have had is all of the key diskettes with there own DECnet node numbers required. I am currently working on a problem which according to DEC can not be done which is assign a key diskette to the hardware and prompt for username. I also allow a user to enter a bad password and not have to reboot. (YES DEC it can be done.) The other problem we have had with PCFS is as Erik said, problems in the Ethernet system. We too lose connections to the virtual disks but have not yet been able to find where the problem is. We are running PCFS on a cluster having the connections made to the cluster alias, not a given VAX node. This feature also works. One problem which has been seen is that for the LAT terminal emulator, it hangs at times when connecting to a common service if the service table become full and all of the services being offered by the nodes offering the common service do show up in the table. When the table size is increased, this problem goes away. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 VAX-47 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 681.0 Looking for XYBION users No replies "Mark Oakley" 14 lines 29-JUN-1987 23:23 ---------------------------------------------------------------- We use a data acquisition package called XYBION, that was developed by Xybion Medical Systems of New Jersey. We are very much interested in locating other sites that use this software, so that we can share experiences. Please respond to this note, or contact: Craig Rentenberg Mark Oakley Battelle Columbus Division Battelle Columbus Division 505 King Ave. 505 King Ave. Columbus, OH 43201-2693 Columbus, OH 43201-2693 (614) 424-4801 (614) 424-7154 Thanks! Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 ================================================================ Note 682.0 $INSTALL PURGE ddcu: 3 replies "George Walrod" 24 lines 30-JUN-1987 15:23 ---------------------------------------------------------------- I was considering submitting an SPR for an improvement in the VMS Install Utility. Before doing that I would like some comments and feedback. My suggestion is to modify the PURGE option in the VMS Install Utility, so I may give a disk drive name. Currently the PURGE option removes all installed images and global sections. If I could specify the Disk to Purge this would help me to no end. If you have ever had to dismount a drive on your system and found that images were installed on that drive, then had to go back and deinstalled each image/section manually you know my headache. VAX-48 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT The syntax of the command could be as follows: For the New Interface $INSTALL PURGE ddcu: For the Old Interface INSTALL> ddcu:/PURGE This syntax would minimize the coding changes. George Walrod 4260-b chain bridge rd fairfax, va 22030 ================================================================ Note 682.1 $INSTALL PURGE ddcu: 1 of 3 "Reece Pollack" 8 lines 30-JUN-1987 21:35 -< Additional $INSTALL functionality >- ---------------------------------------------------------------- Let's go one better, George, how about a fix to INSTALL so that we can get a list of the files installed from a specified disk and/or a specified disk and directory? The we could do: INSTALL> list disk$wdp:[mass11]/full and get a list of all of the files installed from that directory? Anyone else like or need this?? Reece Pollack American Satellite Company MS 34/MIS 1801 Research Blvd Rockville, MD 20850 VAX-49 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 682.2 $INSTALL PURGE ddcu: 2 of 3 "John Saunders" 9 lines 1-JUL-1987 00:52 -< More INSTALL Functionality >- ---------------------------------------------------------------- Even better, how about allowing wildcards in all commands: INSTALL> delete sys$sysroot:[*...]wpcorp_*.exe And while we're at it, how about: INSTALL> list/global name* to get a list of all such global sections? John Saunders FEL Computing PO Box 72 Williamsville, VT, 05362 (802) 348-7171 ================================================================ Note 683.0 Multi-point DECnet No replies "Joseph Stith" 34 lines 30-JUN-1987 16:58 ---------------------------------------------------------------- I am trying to bring up a multi-point line (yes, I know DEC will not support them in the future but we did not discover that until recently) and I am having some problems. Everything is VMS 4.5 or MicroVMS 4.5 and is running 9600 baud. The control node is an 8250 with a DMP-11 and at address "00" and I am defining it with: DEFINE LINE DMP-0 PROTOCOL DDCMP CONTROL DEAD TIMER 30000 - RETRANSMIT TIMER 1200 DEFINE CIR DMP-0.0 COST 9 STATE ON TRIBUTARY 1 DEFINE CIR DMP-0.1 COST 9 STATE ON TRIBUTARY 2 The tributary is a MicroVAX with a DMV-11 at at address "02" and I am defining it with: DEFINE LINE DMP-0 PROTOCOL DDCMP TRIBUTARY STATE ON DEFINE CIR DMP-0.0 COST 9 STATE ON TRIBUTARY 2 VAX-50 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Should the tributary definition of the circuit have the tributary's address or the controller's address? Should the circuit definition have "DMP-0.0" or "DMP-0"? Any other assistance? Thanks P.S. What are people doing with their existing multi-point lines once DEC drops them. Seems like point-to-point is going to make the phone companies rich. Joseph Stith Longman Group USA Inc 520 N Dearborn Chicago, IL 60610 (312) 983-6400 ================================================================ Note 685.0 Need unread Mail count 11 replies "Alan E. Frisbie" 18 lines 5-JUL-1987 16:52 ---------------------------------------------------------------- I need to be able to find out the unread message count that Mail displays. I need to be able to do this from a command file (Login.Com). I am told that this information is kept in an indexed file, SYS$SYSTEM:VMSMAIL.DAT. Since access to this file is closely guarded, what is needed is a program that will return the unread mail count only for the user requesting it. This program can then be installed with the necessary privileges. Does anyone know of a program on the SIG tapes that does this, or will I have to write it myself? Alan E. Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 (213) 256-2575 Alan E. Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 VAX-51 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 685.2 Need unread Mail count 2 of 11 "Frank J. Nagy" 2 lines 11-JUL-1987 10:12 -< FINGER reads mail count >- ---------------------------------------------------------------- The FINGER program, found on several past SIG tapes, contains code to read the unread mail count for VMS V4.0. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 685.5 Need unread Mail count 5 of 11 "Chris Erskine" 4 lines 22-JUL-1987 09:26 -< One Caution >- ---------------------------------------------------------------- A quick gottcha you for the last one is if you have moved your VMSMAIL file from SYS$SYSTEM. This file is sometimes pointed to by the logical VMSMAIL. If this is defined, the file may be somewhere else or named something else. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 ================================================================ Note 685.6 Need unread Mail count 6 of 11 "Jack Patteeuw" 5 lines 23-JUL-1987 09:43 -< There's always DCL ! >- ---------------------------------------------------------------- There is a DCL command file called MAILUAF.COM on your system that allows System Managers to play with many of the fields in MAILUAF.DAT. Although the count field is not defined in this procedure I'm certain that you could figure out from the other example where it is and then modify this procedure to do what you want. VAX-52 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 685.7 Need unread Mail count 7 of 11 "Brian Tillman, Lear Siegler, Inc." 12 lines 23-JUL-1987 15:07 -< I know where that little guy's hiding! >- ---------------------------------------------------------------- RE: < Note 685.6 by NODE::US176598 "Jack Patteeuw" > -< There's always DCL ! >- | Although the count field is not defined in this procedure | I'm certain that you could figure out from the other | example where it is... It's in the word at bytes 34 and 35 of the mail record. I've got a program that tells you all the stuff in the mail record (your own only, of course). It's too bad DECUS doesn't have a BBS yet where we can upload (on line tape submissions would be great, eh?). If there's interest, I can just make it a note here. It's not very long. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 VAX-53 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 685.9 Need unread Mail count 9 of 11 "Bob Hassinger" 35 lines 24-JUL-1987 10:49 -< DECUS BBS and on-line software distribution >- ---------------------------------------------------------------- > ... It's too bad DECUS doesn't > have a BBS yet where we can upload (on line tape submissions > would be great, eh?). An interesting subject. DECUServe has started up but is only available to a limited group at this point and in any case it's current charter does not include this kind of function. The issues are the same for DECUS if the DECUServe system or another one is considered for this. I just got done with the DECUS/US Library Committee meetings. Some of us have been working very hard for several years along this line. It turns out to be difficult to do for a couple of reasons. One is politics and personalities of course - the bigger an organization gets the more of that you get. I hope we are making progress on that front now. The other problem area is technical and economic. A system to really do what you want is not going to be cheap. It is going to need quite a lot of disk storage. The CPUs are cheap enough but big disks are not. The people involved are very concerned with the technical design of a system that would be secure and stable and in particular we still have problems figuring out how to meet the costs. We are looking at those issues and have talked many times about the obvious options. New ideas are always welcome however. For example, does anyone know anything about the possibility of using 900 numbers to recover more than a nominal service charge? On line submissions get us into issues with signed release forms and such - ideas? Bob Hassinger Liberty Mutual 617-435-9061 Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-54 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 685.10 Need unread Mail count 10 of 11 "Bill Mayhew" 67 lines 24-JUL-1987 11:50 -< Getting it off the dime >- ---------------------------------------------------------------- There are, of course, other places where this kind of activity takes place, including software etc. specifically for VAXen. Mostly, these are "commercial" sources, e.g. CompuServe (which has a VAX forum, but where you must pay for connect time to get things), or ARIS (which has no direct charges, but does involve long-distance bills for many, and does have some "commercialness" to it by virtue of its affiliation with the DEC Professional magazine), though I don't know if ARIS has yet gotten into publicly-submitted software. By this time, the problems associated with providing a reliable, reasonably bulletproof system should be well understood and there exists considerable expertise that can be used to advantage to solve the technical implementation issues. There are also, of course, the perpetual "trojan horse" concerns which can be quite important (how do you know the software that's on the system really does what it says it will do). While the potential consequences of errant software on a multi-user system are obviously higher than they are on a PC (where this type of activity is very widespread), VMS' security features help mitigate the problem. None of the other services that I'm aware of require signed release forms. Many of them prefer source code so that the public-domain nature of the software can be more easily verified (and so the functionality can be enhanced, again in the public domain). IMHO, the major costs would be for a person(s) to maintain the library and screen the submitted software (though there is precedent elsewhere for this being a volunteer position), and the operating costs of the system. I would imagine that grants of various sorts would be reasonably readily available to establish the hardware configuration. Lurking in the wings is the FCC's new rule-in-progress to impose an approximate $5 per hour to vendors of "enhanced communications services" for access to the long-distance network. The definition of "enhanced services" has been widely distorted and I don't claim to know the definitive one, but many of the definitions I've seen would include a system such as the VAX-55 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT one described here, or, for that matter, the Pageswapper system. While DECUS is clearly the logical organization to develop and support this system, I have some trouble, personally, believing that it will happen in our lifetimes. Frankly, I feel the DECUS national organization is just *far* too political and insufficiently able to initiate new services (I am *not* criticizing the job they are doing with existing services, btw; I have great respect for the job being done with Symposia and a good deal of respect for the administration and operation of the program library.). To a large degree, I think this is an inherent consequence of a large, volunteer-run organization. My sense is that an online software exchange service is an idea whose time has been here for a good while now, and that the only way it will get off the ground anytime soon is for some private company or group of individuals to pick up the idea and run with it ... (OR for DECUS to explicitly charter a small, tightly-knit group of people to go off and get the job done, free of DECUS' politics, and with the authority to solicit hardware and cash contributions in DECUS' name to pull it off.) Having worked in and with a large number of volunteer-run, not-for-profit organizations, I am very much aware of the political and organizational challenges. However, the only way, in my opinion, for it to happen is for DECUS leadership to really *be* leaders, delegate the job, and prepare to take whatever heat falls out of that. The biggest problem in this situation is the constant study, design, restudy, redesign of the idea by committees of well-meaning volunteers who, in their earnest desire to meet everybody's individual positions and goals, cannot accomplish the job. I shudder to think what VMS would look like if it were designed by a committee of volunteers... we'd probably all still be using DOS/Batch-11. (Please forgive me if I've forgotten the exact name of that venerable product.) Now that my soapbox is beginning to sag... {grin} Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-56 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 686.0 MicroVaxII Time Measurement Limitation 2 replies "Richard Herdell" 10 lines 6-JUL-1987 18:59 ---------------------------------------------------------------- The MicroVAX II seems to have an 'available' timer resolution of 10 milliseconds. At least 10 ms is the minimum update rate to any clock register which I have access to. The larger Vaxes are different, clock register wise, and thru Macro, routines can be written where time intervals of less than 10 ms can be measured. I keep running into a wall on measuring, within Fortran, Macro..., any interval less than 10 ms on the MICROVAX II though. An auxiliary clock in the q-bus would do it but I have not yet located the beast. Any ideas? Richard Herdell 7000 Hollister Houston, TX 77040 ================================================================ Note 686.1 MicroVaxII Time Measurement Limitation 1 of 2 "Chris Erskine" 3 lines 9-JUL-1987 09:31 -< Realtime Clock >- ---------------------------------------------------------------- DEC has a product called the KWV11-C which is a programmable realtime clock. This would require you write a driver to interface with it. Chris Erskine 6001 Adams Rd. Bloomfield Hills, MI 48013 (313) 258-4049 VAX-57 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 686.2 MicroVaxII Time Measurement Limitation 2 of 2 "Frank J. Nagy" 8 lines 11-JUL-1987 10:17 -< Realtime Clock w/o needing driver >- ---------------------------------------------------------------- If you want to use a KWV11-C but don't intend to service interrupts from it, then a driver is not needed. Just write a privileged program to map a global section, using PFNMAPing, to the Q-bus addresses which correspond to the registers of the real time clock. Then write a small set of routines to read/write these registers and go to it with any normal program. I've done similar things (for hardware other than real time clocks); its easy to do and works well on MicroVAXes or any VAX for diddling simple devices. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 687.0 Directory Creation from within a Program 1 reply "Jim Preciado" 8 lines 7-JUL-1987 00:12 ---------------------------------------------------------------- Can anyone suggest an easy way of creating directories from within a program. There is an RMS function to set a default directory, how about one to create it ? Maybe an option on the RMS open to create the directory (too easy but I'd figure that I'd try) ? Maybe via the ACP QIO interface is another possibility ? I had a need to do this and solved it with a command procedure. I could not find adequate documentation on how to do this under program control so it left me wondering. Jim Preciado 139 Johnson Ave Mahwah, NJ 07430 VAX-58 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 687.1 Directory Creation from within a Program 1 of 1 "Mark Oakley" 6 lines 7-JUL-1987 07:47 -< Use LIB$CREATE_DIR >- ---------------------------------------------------------------- LIB$CREATE_DIR creates a directory or subdirectory. It is described on page RTL-26 of the VAX/VMS Run-Time Library Routines Reference Manual (Volume 8B of the VAX/VMS V4.4 Documentation set). LIB$CREATE_DIR can set ownership, protection, and file version limit. Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 ================================================================ Note 688.0 NROFF, anyone 2 replies "Carl Hartshorn" 6 lines 8-JUL-1987 14:12 ---------------------------------------------------------------- Does anyone know of a utility to convert RUNOFF to NROFF or vice-versa? Or does anyone know of a NROFF utility for VMS. (The old one I got from a 82 DECUS tape from the LBLtools doesn't seem to work correctly with the newer NROFF files that I have. Carl Hartshorn 116 Whispering Pines Ct Scotts Valley, CA 95066 408/773-8484 VAX-59 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 688.2 NROFF, anyone 2 of 2 "Greg Isett" 9 lines 9-JUL-1987 22:40 -< DEC/Shell contains nroff >- ---------------------------------------------------------------- Yes, the latest version of DEC/Shell does include NROFF. Greg Isett hrb-singer incorporated department 125 p o box 60 state college pa 16804 ================================================================ Note 689.0 C version of SEA ARC utility for vms 1 reply "DAVID JENSEN" 17 lines 9-JUL-1987 10:56 ---------------------------------------------------------------- help!! ; I have stumbled across a version of "ARC" (the great PC archive utility) for VAX/VMS. It is still in 'C' but been hacked to compile and link under VMS. [which it does without any errors] But this is my problem (I am not a C person) if I $ RUN ARC it gives me the 'normal' help screen of how it should be run with parameters and positions (just like invoking arc on the pc). How do I supply parameters to this program? Hope I have explained this well enough!? DAVID JENSEN COORS PACKAGING COMPANY PO BOX 1501 GOLDEN, CO 80401 VAX-60 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 689.1 C version of SEA ARC utility for vms 1 of 1 "Brian Tillman, Lear Siegler, Inc." 15 lines 9-JUL-1987 11:45 -< Maybe you need a foreign command >- ---------------------------------------------------------------- RE: < Note 689.0 by NODE::US206885 "DAVID JENSEN" > -< C version of SEA ARC utility for vms >- | how do i supply parameters to this program? Try making it a foreign command, i.e. enter the following: $ arc :== $your_disk:[yourdir]arc $ arc whatever I know that all the software tools (á la Kernihan and Plauger) that mimic UNIX programs but run under VMS must be defined this way and if they are executed simple with a run, as you tried, they too give their standard little help line. Try it. It can't hurt. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 690.0 New to VMS 9 replies "MICHAEL GRATTAN" 19 lines 9-JUL-1987 16:01 ---------------------------------------------------------------- I am new to DEC and my company is converting from a Datapoint system to a VAX. (Right now we have a MicroVAX II but will get a 8250 in the fall.) I have been appointed (or condemned, depending on your point of view) to be the system manager. I would greatly appreciate any thoughts and suggestions that anyone would care to share with this novice. I have thoroughly read the MicroVMS books that we got, but now I want to know more. (Can't wait for the big box and full set of documentation.) VAX-61 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT What kind of privileges do you normally give users, programmers, etc.? What kind of pitfalls should I be aware of? What publications do you suggest I get my hands on? Any thoughts at all would be greatly appreciated. Thanks. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 690.1 New to VMS 1 of 9 "M. Erik Husby" 19 lines 10-JUL-1987 09:42 -< System management notes >- ---------------------------------------------------------------- Get a hold of the latest VAX SIG tapes (the ones put out after each DECUS. They contain the back issues of the PAGESWAPPER where you will find a lot of useful information. The SIG tapes also have a lot of useful programs for managing systems. I have also found attending the DECUS to be a great source of help when I was a system manager. The installation I used to manage uses a lot of techniques I picked up from other managers. I am always willing to spend a few minutes on the phone to answer questions. System management can be a lot of fun if done with the correct mind set -- I always found that a healthy sense of paranoia was essential. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 VAX-62 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 690.2 New to VMS 2 of 9 "Brian Tillman, Lear Siegler, Inc." 8 lines 10-JUL-1987 10:32 -< Welcome to the family >- ---------------------------------------------------------------- RE: < Note 690.0 by NODE::US219201 "MICHAEL GRATTAN" > -< New to VMS >- On the whole, DEC gives fairly good advice in its manuals concerning defaults, but every site has its own requirements. As to privileges, NETMBX and TMPMBX are the only two generally needed. DON'T!!! forget to change the default passwords for the SYSTEM, FIELD, and SYSTEST accounts. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 690.3 New to VMS 3 of 9 "Frank J. Nagy" 10 lines 11-JUL-1987 10:26 -< Try DEC Ed Services also >- ---------------------------------------------------------------- Welcome to the Atilla-the-Hun School of System Management. I agree with Brian that DEC gives good advice in its manuals. If you are really feeling green, look into some of DEC's Educational Services offerings. There are courses for all levels of users and system managers which are fairly good (for the most part, there are duds of course). One thing to NOT worry about: paranoia is not a disease in a system manager; its just part of the job! Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 VAX-63 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 690.4 New to VMS 4 of 9 "Michael R. Pizolato" 30 lines 13-JUL-1987 14:35 -< Hello! >- ---------------------------------------------------------------- I've been doing system management for a while now, and I'm always willing to share ideas. Here are a few: 1. Never give a new user more that TMPMBX and NETMBX privilege. Not even if he makes a specific request for more, or is known as a guru on another system, or anything else. Then, once he's been on for a while, and if he can justify it TO YOUR SATISFACTION, you may add other privileges. 2. One of my most important observations: the number of files a user has always expands to fill his entire disk quota, no matter how big it is. Remember, to paraphrase an old Japanese saying, "to increase a disk quota is easy, but to decrease it creates enemies". 3. Decide on some basic management strategies, and DOCUMENT, DOCUMENT, DOCUMENT them. I didn't at first, and now I've been trying for over a year to do it and I don't have the time. DEC generally gives good support, so don't hesitate to turn to them (even Colorado Springs). I've had good experiences at all my training classes except one (System Performance Mgmt. - what a sleeper!). You can call me any time; I'll be glad to help any way I can. Michael R. Pizolato AT&T Technology Systems Dept. 323610 555 Union Blvd. Allentown, PA 18103 215/439-5500 VAX-64 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 690.6 New to VMS 6 of 9 "Gus Altobello" 51 lines 16-JUL-1987 21:54 -< A few more new-user hints... >- ---------------------------------------------------------------- Welcome to the wild wonderful world of system management. Here's just a few ideas to add to the preceeding ones. 1. Take the advice regarding TMPMBX and NETMBX. I do, however, make exceptions for GRPPRV, GROUP, and GRPNAM if the group leader okays it. All my new users have been restricted to these, and few problems have arisen so far. 2. Get the VAX SIG tapes from the symposia as suggested in <.2>, they're a gold mine. 3. GO to a symposium. They are NOT simply play time, you will work your tail off and enjoy every minute of it. It's the fastest way to get wide exposure to a large number of different issues, as DEC's training classes address a single issue each and cost nearly the same. (This is not to suggest you shouldn't try to attend pertinent DEC classes.) When you go to the symposium, attend a pre-symposium seminar. 4. Look up the NEWS utility on the SIG tapes. This has been a very effective method of disseminating policy statements at our site. Everyone gets notification of the news item, and new users get all the back news to read when they first enter their account. 5. READ the manual set (yes, it's big). If you get only microVAXen, buy a full set. It's expensive, but you get what you pay for. 6. Read the "Guide to Security" early on. Then, for many- user systems, TURN ON THE SECURITY LOGS! You'll be surprised at what turns up. Experience will guide you as to how much logging is too much (as will the bill for console paper). VAX-65 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT 7. Use the Customer Support Center in Colorado, if you purchase software support. Their quality can be spotty at times, but they've been life-savers for me any number of times. Don't be afraid to call back if the answer you got makes no sense or doesn't work: Sometimes you'll get a real guru who can explain away the mess you're in. Good luck! You're in for quite an experience, but that's what this career field is all about. Just don't let the system get away from you, make sure you have management behind you and your policies, and you'll keep your VAX purring nicely. Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 ================================================================ Note 690.7 New to VMS 7 of 9 "Andrew Whitt" 74 lines 20-JUL-1987 02:28 -< The start of something great! >- ---------------------------------------------------------------- Where to start? I came from the PDP RSX side of the house and have been working with VAX/VMS for little over a year. Finding help is only a symposium away! After San Francisco and Nashville, I have acquired knowledge and established personal contacts required to feel semi-confident. Anyway, here are some things that may help you get a good start down the VAX trail.... Along with the others mentioned, Disuser the RSC account. Establish logical ACCOUNT names before you start. I have had to redo the rights identifier database several times do to conflicts. Give each ACCOUNT name a unique UIC group number. As each user is added, the proper text translation of the numeric UIC group and member numbers will be displayed when files are listed with DIRECTORY /OWNER. I've even added an identifier for [1,4] so that all system files display as [VMS,OPSYS]. the SYSTEM account files display as [VMS,SYSTEM]. Now that you have LOGICAL groups identified, use the names to build directory structures for each group. Example -> DU:[OFFICEX.GRUNTS.JOE] for user Joe in group GRUNTS, which has the UIC group of 500, who works in office X. When you list a VAX-66 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT file owned by Joe, it will display; [GRUNTS,JOE]. File names can get lengthy so, use the concealed device switch of DEFINE to produce the logical device name of MY_DISK. With a definition of MY_DISK = DU:[OFFICEX.GRUNTS.], the file name DU:[OFFICEX.GRUNTS.JOE]NOTES.TXT shrinks to MY_DISK:[JOE]NOTES.TXT. This helps in keeping users from looking around the system. Even if they list [000000], they will only see fellow workers root directory files and the group login.com file. What's a group login file you ask? With printers spread through out our building, we use a group login file to create a SYS$PRINT logical name in the JOB table. Other group dependent SYMBOLS and LOGICALS can be defined here. We have a command file which runs out of the SYLOGIN.COM file and uses the default directory specified in the UAF record to determine which group login file to execute. If someone moves from one group to another, you can 'reconnect' a users root using the RENAME command. To move Joe, RENAME DU:[OFFICEX.GRUNTS]JOE.DIR TO DU:[OFFICEY. BOSSES]JOE.DIR. All of Joe's subdirectory files will follow. Don't give yourself all privileges by default! Authorize yourself for everything but Default to the basic privileges and grant others as you go with SET PROCESS/PRIVILEGE=xxx. Build a START_QUEUES.COM file for creating all system queues and forms, and STOP_QUEUES.COM to reflect each entry in the first. Unlike other systems I know, not everything gets 'flushed' when you reboot the system. Watch the ACCOUNTNG.DAT file under SYS$MANAGER. Use the /NEW_FILE option every once in a while to keep search times and disk usage down to reasonable values. Lastly, welcome to the family. If you would like to talk about other specific items, give a call. Andy Whitt General Telephone Midwest Telephone Operations 8001 W Jefferson BLVD Mail Code: IFCSO Fort Wayne, IN 46801 (219) 482-7716 VAX-67 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 690.8 New to VMS 8 of 9 "Jack Patteeuw" 15 lines 24-JUL-1987 08:51 -< Welcome >- ---------------------------------------------------------------- You are already doing one of the best things possible ... you joined DECUS !! The next best thing to do is jump in and get your feet wet, which your doing on that MicroVAX. Lastly, I found the DEC Educational Services class on VAX System Management to be invaluable. Please note that the quality of the class is dependant directly on the expertise of the instructors. I have found that the Ed Services facility outside of Boston is the best. Besides everyone needs to get away from the office for a while! Don't worry, if an (ab)user like me can become a System Mangler then anyone can ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 690.9 New to VMS 9 of 9 "RICHARD WISEMAN" 14 lines 26-JUL-1987 23:05 -< welcome to vax/vms >- ---------------------------------------------------------------- welcome to the family... one of the most important things to establish is that every one will use logical names for any hardware on the system.... this way if you have to move someone or change the hardware to something else then it's not apparent to anyone that you moved them. RICHARD WISEMAN STORAGE TECHNOLOGY CORP VAX-68 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT 2270 SOUTH 88TH STREET MAIL STOP G4 LOUISVILLE C0 80233-0001 ================================================================ Note 691.0 tape server? 2 replies "John Osudar" 3 lines 10-JUL-1987 20:49 ---------------------------------------------------------------- Does anybody out there know the status of tape server software support (a la MSCP Server for disks) for clusters (CI and/or LAVC)? Never? Ever?? Soon??? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 691.1 tape server? 1 of 2 "Frank J. Nagy" 7 lines 11-JUL-1987 10:30 -< Being worked on? >- ---------------------------------------------------------------- Last I heard, its under active consideration at least. Maybe even active development. I'll be surprised, however, if it appears in that ever-popular "future major release" we hear about (heh heh). Also, I'd heard that the spur to the development is the LAVC where now there is more need to provide access to locally connected tape drives since that's all the LAVC has! Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 VAX-69 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 691.2 tape server? 2 of 2 "John Osudar" 7 lines 11-JUL-1987 15:12 -< Let's hope so! >- ---------------------------------------------------------------- Yeah, that (LAVC) is exactly what prompted the question. We're just getting into the LAVC game, and I've got a MicroVAX-II that would love to use a real tape drive (instead of its TK50, which is a real [CENSORED]). I don't care how much (elapsed) time it might take to do useful things over my Ethernet to my TU78, it would beat what I've got now. I'm sure there are other users in the same (leaky) boat. Hope somebody at DEC is listening... John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 693.0 Opening a file with NIL sharing 17 replies "Bill Mayhew" 31 lines 13-JUL-1987 18:21 ---------------------------------------------------------------- I've discovered some interesting behavior with VAX C and RMS, on which I'd like to solicit comments. Suppose user A has a file with protections (rwed,rwed,r,r). Now suppose user B has a C program which attempts to open user A's file... and the open() call specifies "shr=nil", meaning that nobody else should be allowed to do anything with the file while user B is reading it. The open() fails, with the RMS$_PRV error code (basically, "you don't have permission to open that file"). If the file's protections are broadened to include W for the world, the open() succeeds. Likewise, if the file's protections are left alone, but "shr=get" (or default sharing) is specified, the open() succeeds. VAX-70 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT My question: Is this rational behavior, and if so, can someone explain the rationale? If it's *not* rational behavior (which I would argue, though I'm not sure if I'm on solid ground), does it happen in other languages, or is it a VAX C problem? I discovered this with VAX C V2.2 on VMS 4.5 (VAX C 2.3 did not change the behavior). Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 693.1 Opening a file with NIL sharing 1 of 17 "John Osudar" 11 lines 13-JUL-1987 20:54 -< speculation >- ---------------------------------------------------------------- How do you judge "rational" behavior? Although I have no concrete evidence, I suspect that you'll find the same behavior in other languages. RMS tends to look at access and sharing options together, and some combinations "make no sense" to it. shr=nil implies that you'll be doing something to the file that should prevent others from even reading it; if you open the file for read access only, this can be considered "unreasonable". All this implies that the specified access, and not the protection (which gives POSSIBLE access) should be the criterion for what sharing is "reasonable"; however, I doubt that the operations in question are occurring above RMS level. (But I'd also be interested in an answer from someone who's tried it in another language.) John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-71 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.2 Opening a file with NIL sharing 2 of 17 "Bill Mayhew" 27 lines 14-JUL-1987 19:43 -< well, sort of. >- ---------------------------------------------------------------- Some kind of plausible explanation along these lines, with possibly an illustrating example, is what I was hoping to find, in the event that I'm out in left field somewhere. To me, it seems perfectly rational that I might be opening a file planning only to read it, and planning to create a new version as a result of my processing; and the fact that I'm creating that new version means that I want to be sure that nobody else tries to do anything with this about-to-be-ancient data, *and* that nobody else currently has it open (in which case open() would return with a "file-locked-by-other-user" error code, or some such). Now, in reality, the problem is that the situation arose due to a routine many levels deep in my code that opens this file without particularly *knowing* what kind of sharing it should apply (the higher-level, calling routines are, as of yet, unknowledgeable about all the implications of RMS file-sharing, since they came from UNIX where this all happens "transparently" but with a much smaller set of features available to the programmer). So the actual problem is not of all that much impact to me. I did think it was mighty peculiar though, that an attempt to open a file with NIL sharing would fail if the protections on the file were world:r, but succeed if they were world:rw (assuming I fall into the "world" category of users with respect to this file). If I'm going to be doing something to the file, but opening it for read-only, as you hypothesize, and that's "unreasonable", fine, but it seems to me it should behave the same regardless of the protections on the file. Yes? Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-72 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.3 Opening a file with NIL sharing 3 of 17 "Bob Hassinger" 11 lines 15-JUL-1987 12:39 -< Are you opening for read-only with NIL? >- ---------------------------------------------------------------- I have no background or info on the language you are using and it's open statements. Just a thought though: does the mode you are using to open the file imply it is to be opened read-only? For example, in FORTRAN I believe the default for an open is read-write, even though the program only intends to read. This is not changed by the use of options to specify the kinds of sharing that are to be allowed. Many users are never aware of this because they only deal with files they have created and own and so, typically, have full RWED access to. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 693.4 Opening a file with NIL sharing 4 of 17 "Bruce Bowler" 5 lines 15-JUL-1987 13:39 -< I agree w/.3 >- ---------------------------------------------------------------- I suspect that .3 is correct. As stated, FORTRAN assumes R/W access unless stated otherwise. Although I am not well versed in VAX C, it does seem 'logical' to me that 'shr=nil' would IMPLY that want to both read AND write to the file thereby requiring that world have at least RW protection. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-73 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.6 Opening a file with NIL sharing 6 of 17 "Bill Mayhew" 16 lines 17-JUL-1987 11:41 -< Sorry, I don't buy it. >- ---------------------------------------------------------------- I'm opening the file explicitly for read-only access. It may seem "logical" to somebody that shr=nil implies read/write access, but I would think explicitly stating otherwise should overrule; after all there is no "damage" done to anybody by obeying the explicit instruction. Not to mention the fact that undocumented, implicit interactions between file protections, sharing specs, and file-open access specs bother me. It seems to me that even documented interactions should confine the programmer only to the extent that they prevent the programmer from doing something that is patently absurd. For a facility like RMS to make implicit judgments seems to me to be inappropriate, unless there's a clear and justifiable reason for doing so. Of course that's all philosophical; the practical issue is that if the documentation doesn't say it will behave this way, then it's a bug. ON THE OTHER HAND, I don't pretend to have read every word in the VMS doc set {grin}. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 693.7 Opening a file with NIL sharing 7 of 17 "Gus Altobello" 16 lines 17-JUL-1987 22:46 -< Try this, perhaps... >- ---------------------------------------------------------------- There are a number of files at my site that I have security auditing enabled for. These include the DECnet database and other system database files. I'm looking for unauthorized changes to these files, and therefore have auditing enabled only for WRITE access. VAX-74 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I've often noticed (and been annoyed by) security alarms caused by READING these files. For example, an NCP LIST command fires off an alarm, although this is a read operation. The alarm shows the access is READ/WRITE, not just READ. You may wish to enable audit alarms on your system, and put an alarm ACE on the file, just to see what comes up. -gus Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 ================================================================ Note 693.8 Opening a file with NIL sharing 8 of 17 "John Burnet" 21 lines 20-JUL-1987 11:48 -< Aren't you forgetting something? >- ---------------------------------------------------------------- I think that the problem which was originally described (in .0) is caused by not specifying "fac=get" in the open() call. Doesn't the fac (file access) default to ? If I remember correctly, it does... so you'll have to specify that in addition to "shr=nil". The way that this corresponds to keywords in a VMS Fortran OPEN statement is as follows: Fortran: status='old', readonly ! no "shared" keyword C: O_READ, "fac=get", "shr=nil" Fortran: status='old', readonly, shared C: O_READ, "fac=get", "shr=get" /* or ? */ Fortran: status='new', shared C: O_RDWR, "fac=", "shr=" I don't have the VAX C manuals with me, so I don't know whether the "" syntax is correct... maybe the vaxcrtl open() function doesn't want the angle brackets, which are used in macro-32 to prevent the assembler from interpreting the comma as an end-of-argument delimiter. John Burnet P. O. Box 1838 Evanston, IL 60204 VAX-75 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT (312) 272-6520 x2118 ================================================================ Note 693.9 Opening a file with NIL sharing 9 of 17 "Bill Mayhew" 6 lines 21-JUL-1987 12:33 -< fac=get PLUS o_read?? >- ---------------------------------------------------------------- Are you suggesting that the "fac=get" is needed, in ADDITION to O_READ? This is a novel idea. I'm afraid I don't understand the logic behind this, though; but I will try it and see what happens. I would expect that O_READ would cause a "fac=get", otherwise what is the purpose of O_READ? Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 693.10 Opening a file with NIL sharing 10 of 17 "Bill Mayhew" 4 lines 21-JUL-1987 21:50 -< Well, it *sounded* good... >- ---------------------------------------------------------------- According to my documentation, there is no "fac=..." option accepted by the C RTL. I tried it anyway and it made no difference in the behavior. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-76 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.11 Opening a file with NIL sharing 11 of 17 "John Burnet" 25 lines 22-JUL-1987 13:52 -< sorry... i'm stumped too >- ---------------------------------------------------------------- < Note 693.10 by NODE::US175845 "Bill Mayhew" > -< Well, it *sounded* good... >- >According to my documentation, there is no "fac=..." option >accepted by the C RTL. I tried it anyway and it made no >difference in the behavior. Oh well. I haven't (yet) done much experimentation with the VMS C run-time library; where C is concerned, I'm more used to Unix (where this kind of problem doesn't crop up in the first place). I agree that O_READ should imply "fac=get", but sometimes it's hard to tell what the vms c rtl developers had in mind. Which brings up another, related topic (probably should be a separate note)... it seems to me that VAXC is a kind of "ugly duckling" as far as DEC is concerned. VAXC usually doesn't get mentioned in places in the documentation where all the other compiled languages which DEC pushes for VMS are listed. Also, the 2.3 VAXC manuals--user's guide/reference manual and rtl manual--are of much lower quality (writing quality, accuracy, lack of typos, etc.) when compared to the manuals for (e.g.) Pascal or Fortran. Did the C development and documentation groups have to put up with low budgets, or what? And why does DEC try to ignore C? For the same reasons it tries to ignore Unix? John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-77 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.12 Opening a file with NIL sharing 12 of 17 "Bill Mayhew" 20 lines 22-JUL-1987 19:04 -< VAX C has its problems. >- ---------------------------------------------------------------- For one thing, VAX C is a much newer product than FORTRAN or Pascal. I can accept that as the reason why all the references one finds (in things like the system library manuals) are to Pascal or FORTRAN. DEC still seems to suffer from the delusion that virtually every VMS site runs FORTRAN. Actually, my favorite gripe about DEC and C is that (on several occasions) when I've called for telephone support on VAX C, the screening operator doesn't have the faintest idea what I'm talking about, and thinks I have some kind of new, un-released, "seed" VAX. {grin} I was sort of looking forward to the 2.3 VAX C manuals, since the 2.2 ones are such a disaster. On the other hand I've heard reliable rumors about problems with 2.3 such that Colorado is suggesting that you don't upgrade to it until you have VMS 4.6. I must say that I am considerably disappointed by this product, not because of any innate faults of the compiler, but because of incredibly poor runtime library implementation decisions and poor documentation. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-78 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.13 Opening a file with NIL sharing 13 of 17 "John Burnet" 19 lines 24-JUL-1987 15:29 -< C 2.3 >- ---------------------------------------------------------------- >I was sort of looking forward to the 2.3 VAX C manuals, since >the 2.2 ones are such a disaster. On the other hand I've heard >reliable rumors about problems with 2.3 such that Colorado is >suggesting that you don't upgrade to it until you have VMS 4.6. We're running VAXC V2.3 using the VMS V4.5 VAXCRTL with no problems. Apparently, the 4.6 RTL will provide full support for all the new ansi features that DEC included in C 2.3 (which is the major improvement in the 2.3 release, I understand). We're not using many of the new features yet, though, and our pre-2.3 C programs that just use the age-old stdio, malloc, etc. libraries link fine. The manuals *are* pretty bad. I took a pencil along on my initial trip through the 2.3 user's manual/language reference, marking up all the mistakes, typos, and inaccuracies I could find, and when I was done I practically needed a new pencil. The manuals could be a lot worse, but there are many, many little things wrong that could trip people up, especially subtle inaccuracies in the example programs listed. John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 ================================================================ Note 693.14 Opening a file with NIL sharing 14 of 17 "Frank J. Nagy" 18 lines 25-JUL-1987 11:35 -< VAX C V2.3, RTL doc and "fac=" >- ---------------------------------------------------------------- We too are using VAX C V2.3 under VMS with no problems. We aren't using any of the new RTL routines so its no problem, but are awaiting V4.6 with baited breath (but no held breath). At least the V2.3 documentation fixed the index problem for the RTL routines of having to look them all up under "B" (for Bold)... VAX-79 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Speaking of which, how many people would like to see the VAX C RTL documentation reorganized as two sections along the lines of the VAX RTL volumes. Section 1 would provide a general description of the various groups of routines, much like the current VAX C RTL manual but without the detailed descriptions of each routine. Section 2 would provide detailed descriptions of the individual routines ORGANIZED ALPHABETICALLY BY ROUTINE; again much like the VMS RTL manuals are currently organized. Any support? Finally, as I remember, the extended "fac=", etc. arguments are accepted by the VAX C RTL routines fopen(), freopen() and creat(). Others I'm not sure about. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 693.15 Opening a file with NIL sharing 15 of 17 "Bill Mayhew" 7 lines 28-JUL-1987 09:38 -< RTL doc and "fac=" >- ---------------------------------------------------------------- I would agree wholeheartedly with your proposed change to the documentation structure. As for "fac=", there are a bunch of such things that are accepted by open(), creat(), et al., it's just that "fac=" is not among them (from what I can tell). Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-80 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.16 Opening a file with NIL sharing 16 of 17 "John Burnet" 23 lines 28-JUL-1987 12:11 -< More thoughts on the central philosophical question >- ---------------------------------------------------------------- >I would agree wholeheartedly with your proposed change to the >documentation structure. Second the motion! The VAXCRTL doc really needs to be revamped. As far as I'm concerned, it's unacceptable to have to look in the index to find the description for a particular RTL routine. On the subject of nil sharing... I was thinking about that, and the more I ponder the original problem (see .0), the more I think that it makes a certain kind of sense to require write permission on a file to specify nil sharing for that file. After all, in this particular case, it's not your file, so why should you have any say about whether other people can read the file while you're accessing it? The owner of that file--or anyone with a system uic or sysprv or bypass privilege [:-)]--can give you (and others) that say by setting w:rw protection. Opening the file with "shr=get" (which is the default) will work, and that makes a kind of sense too... you're (in effect) warning other accessors of the file that you've got it open and that they shouldn't write to it; but that's no reason for them not to *read* it... John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-81 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 693.17 Opening a file with NIL sharing 17 of 17 "Bill Mayhew" 26 lines 28-JUL-1987 21:43 -< C seems to be unique in this behavior >- ---------------------------------------------------------------- I think there are reasons why I would not want other people to be able to read the file while I am, although they are admittedly somewhat obscure. Meanwhile, adding w:rw permission to the file opens it up to a whole class of other perpetrators of violence. The further problem seems to be that this behavior is, as far as I can tell, unique to VAX C. The behavior certainly doesn't appear in MACRO (where of course you're programming RMS to within an inch of its life) and I have reliable reports that it also doesn't appear in FORTRAN, where no-sharing is the default (I think). This problem is the second of three RMS-related bugs in the C RTL that I've learned about in the past two months (two of them through personal discovery). I am of the opinion that the C RTL developers responsible for the interface to RMS need to learn what RMS is all about (OR be taken out behind the woodshed for a good thrashing). I am also persuaded, more and more, that Digital doesn't seem to take C seriously outside of Ultrix (and whether it takes Ultrix seriously is another Note...). Fortunately, I learned from software support that some (undefined) of these problems or ones like them are being worked on for a future release. Otherwise I'd have an awful time delivering a reliable product to my customer tomorrow. {grin} Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-82 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 694.0 Exit Handler Bug in VMS 2 replies "Mark Oakley" 19 lines 14-JUL-1987 21:31 ---------------------------------------------------------------- I believe I have discovered another bug in VMS. Exit handlers that are declared in executive mode are NOT executed at image termination. Handlers declared in user mode (and I suspect supervisor mode) are executed. According to the documentation, you should be able to declare exit handlers in user, supervisor, and executive modes (but not kernel). I contacted TSC about this, and they ran a test program and got the same results (they could not get exit handlers declared in exec mode to execute). It appears that an exit handler declared in executive mode gets declared properly, but at image termination it is not executed. This is not a problem for our users, since they can not write executive-mode code. It's a problem for me, as there were some things I was hoping to use this for. Has anyone else ever seen this? Can anyone suggest a fix or work-around? Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 ================================================================ Note 694.1 Exit Handler Bug in VMS 1 of 2 "Jamie Hanrahan" 27 lines 15-JUL-1987 15:33 -< DCL is the culprit >- ---------------------------------------------------------------- This is not a bug, but rather a feature... er, a consequence of the context in which you were running the image -- or, rather, the context in which I *suspect* you were running the image: The DCL RUN command. VAX-83 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT DCL runs in supervisor mode. It gets control back from an image by declaring a supervisor-mode exit handler. ("Termination handler" according to the IDSM, but we'll stick with "exit handler" for brevity.) This handler returns control to the DCL command processing loop, still in supervisor mode. So the image rundown service never gets a chance to look at the lists of executive- or kernel-mode exit handlers. I'm not sure whether DCL gets rid of user-declared E-mode exit handlers at image end. I rather think that it does, but if not, your E-mode handler should be executed when your process is deleted (i.e. when you log out). User-declared E-mode and K-mode handlers WILL be called at image end if the image is run "by itself" (i.e. without DCL) in a detached or subprocess (RUN process command, or $CREPRC). (User-defined K-mode exit routines are declared not via the $DCLEXH service but via the dispatch vector in a user-written system service -- see SYS$EXAMPLES:USSDISP.MAR .) This stuff is described in sections 21.2, 21.3, 23.3, and 23.4 of the V3 IDSM. Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 ================================================================ Note 694.2 Exit Handler Bug in VMS 2 of 2 "Frank J. Nagy" 38 lines 19-JUL-1987 09:51 -< Image Rundown >- ---------------------------------------------------------------- Jamie Hanrahan is correct (<.1>) in saying that DCL is the culprit preventing your executive-mode exit handler from running. However, DCL does appear to remove these EXEC exit handlers at image exit even though they are never called; otherwise strange things would happen if an attempt was made to invoke the routines later long, long after the image was gone (long gone) from memory! VAX-84 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I once ran into this problem (way back in VMS V2.x). I started using, or attempting to use, an executive mode exit handler when my reading pointed out that a user-mode exit handler can be gotten around (as simple as having another exit handler do its own $EXIT or just by doing a $DELPRC). WHat I needed was to recover resources used at the user's behest by a package of routines interfacing to our in-house control system network. My solution to the whole thing was to discover how to patch into the image rundown handler (this was later documented with in VMS V3 with the information on how to write user-written system services). The image rundown handler executes in kernel mode and is ALWAYS called, even if a $DELPRC (or DCL STOP/ID) is done on the process. THis is the same code patch used to invoke the RMS rundown service and avoid the dangling open files left locked which are so common in RSX systems. My ultimate trick was to declare my exit handler in user-mode executive-mode and call it via my image rundown handler. If the exit code runs at user-mode it sets a flag and shortcuts its own execution at the higher access modes. This is because the system will call user-mode exit handlers first, then supervisor-mode (which is how DCL gets control), then executive-mode and finally, last of all, the image rundown code is called. The information on using the image rundown stuff is in with the information user-written system services in Appendix A of the System Services manual. Beware: your image rundown code is called in kernel mode (at IPL 0) so it had better be quite robust or you will get to watch lots of system crashes. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 VAX-85 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 695.0 VAXstation goes dead for 30 seconds 2 replies "Alan E. Frisbie" 40 lines 14-JUL-1987 23:38 ---------------------------------------------------------------- Has anyone out there done any I/O driver debugging on a VAXstation-II? I am encountering some problems (besides the usual self-inflicted ones) that lead me to believe that there is a problem with either VCDriver, WTDriver, XDelta, or the Symbolic Debugger. I am using VMS v4.5 with v3.0 of the Workstation software. The symptom I see is that when: 1. The system was booted with XDelta 2. A non-DEC driver (mine) is loaded 3. The test program (for the driver) uses the debugger with separate windows for the debugger and the test program. Before I perform any QIO's to my driver, I single line-step the test program in the debugger window (no problems so far). When the test program requests input, that has to come from the separate window. I use the mouse to select the window, but there is no keyboard response (echo of my input) for 30 seconds. The same delay occurs when I switch back to the debugger window after entering my input. A clue that indicates that this is a very low-level problem is that if I repeatedly enter control-Z (without releasing the "Ctrl" key), eventually a "z" is echoed. This means that ALL keystrokes during that 30-second dead time are ignored. Naturally, I suspected my driver first. I have breakpoints at every entry point. At the point where I first see this problem, the only driver code that has executed is the Controller Init code. It is stolen directly from the XADriver example, but with the device reset subroutine call removed. VAX-86 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT I don't want to flood you with information at this point, but will happily supply anything you might think is useful. Alan E. Frisbie Flying Disk Systems, Inc. 4759 Round Top Drive Los Angeles, CA 90065 ================================================================ Note 695.1 VAXstation goes dead for 30 seconds 1 of 2 "Frank J. Nagy" 8 lines 19-JUL-1987 09:56 -< Try adding memory >- ---------------------------------------------------------------- Alan, we have seen sort of similar problems with VAXStations, but not when debugging drivers (my driver worked first time (:-)). Mostly when people were working on UIS applications. We sort of tracked it down to being tight on nonpaged pool. THe VAXStation software likes to use lots and lots and lots of nonpaged pool so you might try increasing it beyond the current size. I'm not sure, but we might be running with 1 MB or so of nonpaged ocean (our VAXStations have 13 MB on them right now). Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 695.2 VAXstation goes dead for 30 seconds 2 of 2 "Bruce Bowler" 6 lines 20-JUL-1987 10:38 -< try VWS v3.1 >- ---------------------------------------------------------------- Alan, we too saw a similar problem on our GPX, the problem was also pool related, but it was paged pool that was taking the hit. Something kept taking VCA blocks, and never giving them back. We solved the problem by going to version 3.1 of the VWS software and have not had the same problem since Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 VAX-87 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Schenectady, NY 12345 ================================================================ Note 696.0 Wildcard filename matching 3 replies "Bruce Bowler" 15 lines 15-JUL-1987 13:47 ---------------------------------------------------------------- I am wondering if anyone out there can point me in the direction of a RTL routine or system service that will do wild card processing of file-names (STR$MATCH_WILD doesn't do the trick). The situation is as follows. I have a list of fully specified file names (which may or may not exist on disk, so LIB$FIND_FILE doesn't cut it either) and a wild card file specification. I then want to find all of the files in the fully specified list that match the wild card specification. The BIG problem with STR$MATCH_WILD is that it doesn't recognize directory specs of the form [BOWLER...] which is, of course, a valid spec. Currently I parse the stuff myself, but that's a real pain in the ^#*$%#, not very elegant, and oh so SLOOOOOOW. Any help would be greatly appreciated. Thanks Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 696.1 Wildcard filename matching 1 of 3 "Larry Kilgallen" 16 lines 15-JUL-1987 21:11 -< Try SYS$FILESCAN >- ---------------------------------------------------------------- My initial reaction is to suggest using the SYS$FILESCAN system service to pull apart the filespecs and then use STR$MATCH_WILD as appropriate. The main source of file wildcard matching used by VMS utilities is in RMS, which gets invoked by LIB$FIND_FILE. LIB$FIND_FILE and the matching LIB$FILE_SCAN are the only paths to DEC-supported parsing of search lists, but given your desire to work without the files present, these all seem inappropriate. There is a capability in SYS$PARSE (RMS) not to check for existence of directories on disk, but since you are matching against another list, that seems not to be a solution either. VAX-88 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT So, looking at the "pure" parsing routines, SYS$FILESCAN and STR$MATCH_WILD would seem to be your available tool kit. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 696.2 Wildcard filename matching 2 of 3 "Mark Oakley" 12 lines 18-JUL-1987 16:15 -< MATCHNAME in VMS Source Fiche >- ---------------------------------------------------------------- There is a routine listed in the fiche called MATCHNAME which (according the functional description) performs "the general embedded wild card matching algorithm". The routine is located in frame 532, picture B10 of the fiche. You may have to type this routine in, because it may not be available in VMS. It is fairly short (about 40 lines of macro), and I suspect very fast. You might also need to modify it to handle the strings you wish to match. I have heard good things about this routine from people who have used it. Andy Goldstein is the author. If you have to write your own pattern matching routine, this might be worth looking at. Mark Oakley Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201-2693 614/424-7154 VAX-89 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 696.3 Wildcard filename matching 3 of 3 "Bruce Bowler" 4 lines 20-JUL-1987 10:33 -< thanks >- ---------------------------------------------------------------- Thanks for the tips guys, the method Larry suggested is what I ended up using for now, but I am definitely going to take a look at the fiche for MATCHNAME. Perhaps I should get motivated and fill out an SIR suggesting a filename matching routine. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 697.0 Where's the file? 4 replies "MICHAEL GRATTAN" 9 lines 17-JUL-1987 07:43 ---------------------------------------------------------------- We have an accounting package written in Dibol. When we run reports they are automatically spooled to SYS$PRINT. This in itself is not a problem, however, when I do a SHOW/QUEUE/FILES SYS$PRINT, all I see for the file name is $DISK2:[].DDF;1. If I try a find this .DDF, I can't. Is there a LIMBO somewhere, where spooled files go? Is this a problem in the Dibol? Any thoughts would be appreciated. Thanks. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 VAX-90 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 697.1 Where's the file? 1 of 4 "M. Erik Husby" 6 lines 17-JUL-1987 10:55 -< On the disk but not in a directory >- ---------------------------------------------------------------- Those files do exist on the disk, however, it is not necessary for a file to be entered into a directory. You can find those files by using the ANALYZE/DISK/REPAIR command. You will need a directory called [SYSLOST] where ANALYZE can make directory entries for those files. M. Erik Husby Project Software & Development 14 Story St. Cambridge, MA. 02138 (617)-661-1666 ================================================================ Note 697.2 Where's the file? 2 of 4 "John Burnet" 7 lines 17-JUL-1987 16:35 -< That's normal; nothing to worry about >- ---------------------------------------------------------------- Don't be too hasty to do an ANALYZE/DISK/REPAIR, though. Having spooled files exist on the disk but not appear in a directory is completely normal behavior. If you do an ANALYZE/DISK/REPAIR while people are using the disk, and you don't give the /CONFIRM qualifier as well, you might inadvertently do some harm. ANALYZE/DISK/REPAIR should always be done on a "quiescent" disk. John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-91 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 697.3 Where's the file? 3 of 4 "Bruce Bowler" 9 lines 20-JUL-1987 10:30 -< But it may not be there... >- ---------------------------------------------------------------- John is right, don't EVER run ANALYZE/DISK/REPAIR on an active disk. Also, don't be at all surprized if when you do ANAL the disks, you don't find any trace of the "missing" files. It is not uncommon for a utility to spool a file to the printer setting the DELETE ON COMPLETION bit. There for this file that is not entered in a directory will be deleted from the disk when the print completes. If the print job doesn't terminate normally, the file should still be on disk and ANAL will put it in [SYSLOST]. Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 ================================================================ Note 697.4 Where's the file? 4 of 4 "Gus Altobello" 12 lines 25-JUL-1987 21:58 -< Magical Mystery Files... >- ---------------------------------------------------------------- Also note that doing an ANALYZE/DISK on a live disk, to see what's there, often gives you a number of spurious errors. You'll see messages about "creation date in future" and "file not in any directory", but these are caused by things like work files, editor journal files and such. These "problems" go away when the files are closed. This is the reason ANALYZE/DISK/REPAIR is dangerous on a live disk: Things that aren't broken get fixed. And you know what they say about that! :-) Gus Altobello PO Box 11274 Hauppauge, NY 11788 516/435-7036 VAX-92 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 698.0 ALL-IN-1 Communication Control No replies "Edward Chan" 9 lines 17-JUL-1987 18:43 ---------------------------------------------------------------- DidÖþ anybody try to e ALL-IN-1 Communication Control Menu to dial out to connect a Non - VAX system using LTA port and the Terminal Server ports configurations, I was able to connect to Foreign system. However, when I tried to record the session using Record Overwrite (RO), the content of the document lost all the Carriage Control even though the material is displaying correctly on the screen while it was recording. DEC support can not give me the right answer and they said it is not supported on dial out using DECSA. Edward Chan 1501 Harbor Bay Parkway Alameda, CA 94501 ================================================================ Note 701.0 DECgraph V1.5 No replies "CHUCK MCMICHAEL" 17 lines 23-JUL-1987 11:06 ---------------------------------------------------------------- DECgraph V1.5 has a command procedure GRAPH$LIBRARY:GRAPHSIXEL.COM to send sixel files to an LN03 laser printer. Occasionally, part of the graph can be lost while a %DCL_W_TKNOVF message appears on your screen. The problem occurs when the procedure tries to add some extra control characters at the end of a line that's near the maximum record size for DCL WRITE. Here's the fix: Find the line: $ write decgraph_sixel_ofile front + "P1;0;''SIZE'q" and replace it with: $! write decgraph_sixel_ofile front + "P1;0;''SIZE'q" $ MYSYMBOL = front + "P1;0;''SIZE'q" $ write/SYMBOL decgraph_sixel_ofile MYSYMBOL VAX-93 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Using WRITE/SYMBOL doubles the size of the write buffer and prevents the overflow condition. CHUCK MCMICHAEL PITTSBURGH CORNING CORP 800 PRESQUE ISLE DR PITTSBURGH PA 15239 412-327-6100 ================================================================ Note 702.0 Planning an Ethernet 4 replies "Jack Patteeuw" 26 lines 24-JUL-1987 12:30 ---------------------------------------------------------------- We are in the planning mode of *LARGE* multi-vendor Ethernet network. The backbone will be an inter-building broadband cable (already in place) with bridges to building broadbands with (possible) bridges to baseband Ethernets. We are looking seriously at Chipcom modems for the broadband, unless something else comes up. As I mentioned before this will be a multi-vendor network with one of just about everything in the world hanging off of it, mostly speaking TCP/IP, but with some DECNET and some XNS. I would like to hear from others who manage/work with multi-vendor Ethernets and find out what your trials and tribulations have been. I am especially interested in experiences with bridge products such as DEC's LAN Bridge 100 or Bridge Technologies LAN Bridge. Reliability, service and statistics are all important to us. Does anyone have any first hand experience with Wollongong's TCP/IP product for VAX ? (This is what DEC is presently recommending for VMS sites.) Does anyone have any experiences with TCP/IP routers ? Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 VAX-94 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 702.1 Planning an Ethernet 1 of 4 "John Osudar" 18 lines 24-JUL-1987 13:33 -< we'll know more soon... >- ---------------------------------------------------------------- I'm not sure how relevant this will be to your planned network -- Argonne National Laboratory is in the final stages of installing its own PBX for voice and data, including a site-wide one megabaud Ethernet transport. I know that TCP/IP, XNS, and certainly DECnet (and LAT) will all be in use -- along with, possibly, other Ethernet protocols. I suspect that many of our potential problems will originate from the pseudo-Ethernet nature of the PBX-supplied transport -- but I anticipate that some of our (soon-to-be-obtained) experiences will be relevant to other hardware configurations. I will post comments, observations, etc. as they come up. Regarding Wollongong's TCP/IP product -- we run it here on a 750 that serves as an "inter-network gateway". I have been (far) less than impressed with the product in the past, at least in the areas of (minimal) robustness, (lack of) functionality, and (poor) integration into a VMS environment. (That is my personal opinion, not Argonne's.) We just installed a new version and I haven't had enough experience with that to judge whether it's significantly improved or not. Will let you know. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-95 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 702.2 Planning an Ethernet 2 of 4 "Frank J. Nagy" 21 lines 25-JUL-1987 11:26 -< Enet experience at Fermilab >- ---------------------------------------------------------------- Fermilab has a large Ethernet system, but little if any non-DEC traffic (i.e., all DECnet/LAT/LAVC). We have several DEC LANBridges in place and have no problems with them; in fact they install and seem to disappear into the background. Its hard to wax eloquent about something that works so well it is nearly invisible! One bottleneck is that we still have a pair of Ethernet systems interconnected by a DECSA Router with 100Kbit links. We seem to be experiencing problems with overloading this box (no free buffers, etc.) which sometimes cause problems with traffic between the two Enets. Once the new computer building is finished, we will bridge these Enets with fiber-optic LANBridges and our troubles should evaporate. This will also give us a much-desired LAT bridge between our DECServer-200s "out there" and our development LAVC system "back here". Finally, we also have a LAN Traffic Monitor system. Neat box; the surprise was that with all the big systems, little systems, etc., etc. hanging off the main Ethernet in the Central Laboratory complex, we are only using 4-5% of the Ethernet bandwidth with peaks into the 11-14% range. Ethernet is a surprisingly BIG pipe! Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 VAX-96 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 702.3 Planning an Ethernet 3 of 4 "RICHARD WISEMAN" 11 lines 26-JUL-1987 22:24 -< equipment for ethernet >- ---------------------------------------------------------------- we here at storage technology have install the DEC lan bridge-100's and as one of the other replies says they fade into the background.. ours is using fiber-optic on one side.. the bridge seems to handle all the traffic with no problems... lots of tcp/ip and decnet going on at the same time... we are using a MICOM/INTERLAN tcp/ip interface in a vax 750 with on adverse effects on the system.. it only works on the ethernet and talks to 5 unix hosts... the product seems to function properly and since it's a front end processor the bulk of the overhead is in the board and not in software.. RICHARD WISEMAN STORAGE TECHNOLOGY CORP 2270 SOUTH 88TH STREET MAIL STOP G4 LOUISVILLE C0 80233-0001 ================================================================ Note 702.4 Planning an Ethernet 4 of 4 "Brian Tillman, Lear Siegler, Inc." 35 lines 28-JUL-1987 14:17 -< Diverse networking >- ---------------------------------------------------------------- RE: < Note 702.0 by NODE::US176598 "Jack Patteeuw" > -< Planning an Ethernet >- | I am especially interested in experiences with bridge | products such as DEC's LAN Bridge 100 or Bridge | Technologies LAN Bridge. We currently have a multi-vendor LAN with standard baseband Ethernet in the engineering building, a broadband LAN on which runs an Ethernet (using Chipcom -- good stuff, Maynard), a Sytek system 2000, a Sytek LocalNet 20, and a video channel between the engineering, administration, manufacturing, and contracts buildings, and ThinWire Ethernets in the administration and engineering buildings. The baseband LAN is connected to the broadband in the engineering by way of a LANbridge 100. We VAX-97 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT would also have the admin ThinWire hooked up to the broadband that way, but we couldn't afford the additional LANbridge at the time and felt we could waste the Ethernet capacity used up by garbage packets that connecting a Chipcom Ethermodem directly to a DEMPR causes. We have a money request in to get funds for the other LANbridge. There is a new Chipcom product out that is a one-port device that resolves the differences in the carrier sensing mechanism used in the two LANS so the extra traffic goes away and we might get one of those, too, to use where a LANbridge might be too expensive. The ThinWire in the engineering building is hooked up by DEMPR to the standard baseband. The Chipcom seems to be a good investment, especially since DEC will maintain it, since they sell it, too. We also use LanTel broadband synchronous and asynchronous modems for some of our DECnet traffic -- on a still different channel than the Sytek, Ethernet, and video channels. All in all, the parts play well together. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 704.0 Digi-Data Gigastore System No replies "Frank J. Nagy" 24 lines 25-JUL-1987 11:44 ---------------------------------------------------------------- We are adding a Digi-Data Gigastore to our dual-MicroVAX LAVC to handle the file system backups. Currently, we backup 2 RA81s using TK50s. At the same time we add the Gigastore, we are expanding to 4 RA81s (hence the desire to get away from TK50s for full volume backups - will probably still use TK50s for incrementals). The Gigastore is a tape transport, Q-Bus interface and software (modified VMS driver?). The media is T-120 VHS cassette - holds about 2.5 GBytes with average transfer rate of 120 KBytes/sec and a very low error rate (claim is 1 in 10**23 bits!). The low transfer rate is not bothersome; with a 2.5GB capacity, we will be able to save the entire file system using a batch job running during the wee hours - unattended and the system is pretty much VAX-98 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT idle at that time. Similar, competing systems are from Honeywell Test Instruments and ExaByte. The Honeywell system is fast, holds more (5 GB) but is more than 5 times as expensive; its more adapted to storing imaging data. The ExaByte system uses a SCSI interface; no Q-Bus interfaces or software are yet available for it. Is there anyone out there who is using a Digi-Data Gigastore? What are you experiences? Stay tuned to this topic for future announcements. Frank J. Nagy Fermilab PO Box 500 MS/220 Batavia, IL 60510 (312)840-4935 ================================================================ Note 706.0 3rd Party Peripherals 2 replies "MICHAEL GRATTAN" 13 lines 27-JUL-1987 14:44 ---------------------------------------------------------------- We have various 3rd party printers, namely Dataproducts, that we would like to have Dec service. They have agreed to service the one here in our east coast central office, but have balked at working on the one in our West coast warehouse. While the printers are not IDENTICAL, they are both fairly standard. Has anyone had a similar experience? Is this the norm for Dec Field Service? Is there a norm for Dec service? Would you suggest that we get all Dec peripherals? (I don't have carte blance as to $$$.) Any thoughts would be greatly appreciated. Thank you. MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 VAX-99 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 706.1 3rd Party Peripherals 1 of 2 "Bill Mayhew" 21 lines 28-JUL-1987 09:48 -< DECompatible service >- ---------------------------------------------------------------- DECompatible Service is, I believe, the service offering you're falling under, and it works according to the following guidelines, as I understand it: A list of third-party products is "standard" and will be supported nationwide. Other products will be supported at the discretion of the local office, based on the availability of spares and expertise. It sounds to me like your Left Coast printer is not on the "standard" list and that Digital, for whatever reason, is not prepared to support it. You should be able to get them to tell you the reason. Given their (I think reasonable, if implemented fairly) policy, it's not particularly clear what you could do to get them to change their mind, other than to start calling somebody like CDC to service *everything*, which may wake Digital up if they want your business. ON THE OTHER HAND, if their reason for not servicing that printer is based in fact, and not just in the west coast site's manager's "not invented here" syndrome, it may well be that you don't *want* them servicing it. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-100 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 706.2 3rd Party Peripherals 2 of 2 "Kevin Angley" 12 lines 30-JUL-1987 10:23 -< Depends on local service >- ---------------------------------------------------------------- We had Dataproducts B1000 printers under service by DEC, but they really weren't able to do as good a job as on DEC equipment. They "encouraged" us to not renew the printers on our contracts (how? by jacking up the price from $179/mo to $450/mo each). We looked into service from Intelogic Trace, TRW, etc. and finally selected TRW. They do a very good job at the same price DEC used to charge us. This type of issue is very dependent on the people (DEC and third party) in your area(s). You may have to have different service vendors for your different sites. Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 707.0 Disk Serving for MicroVax? 2 replies "Bill Weissborn" 32 lines 28-JUL-1987 14:46 ---------------------------------------------------------------- Our site will be receiving a MicroVax II shortly and we would like to know the following: Can our existing 11/780's user disks be accessed by the MicroVax via MSCP over Ethernet? If so, how? If not, what can be done to accomplish this? Do/will we need LAVC software? We would be interested in hearing from others who may have either done the above or are about to embark on the same adventure. We would also be interested in hearing about other's experiences with LAVCs. What hardware/software is required, what DEC didn't tell you that you need to know, etc. Also, whether or not any 3rd party products exist to accomplish the above task. VAX-101 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT By the way, the MicroVax has 2 190mb disks and one 380mb disk. It also has 9mb of memory. Thanks. Bill Weissborn Schlumberger Well Services 12770 Coit Rd. Suite 210 Dallas, Tx. 75251 (214) 980-7924 ================================================================ Note 707.1 Disk Serving for MicroVax? 1 of 2 "Bob Hassinger" 19 lines 29-JUL-1987 10:06 -< Same question here too... >- ---------------------------------------------------------------- I am interested in the same subject. We have been thinking about adding microVAX(s) to our 11/750 via an existing Ethernet, using LAVC. The 750 has Massbus disks (RM05 and RM05 emulation) and tape (TU77). The thing that keeps bothering me is that in the LAVC session at the Dallas Symposium I asked and I am sure I heard that this configuration should work as a boot node for an LAVC. HOWEVER, I keep finding DEC product descriptions that say you MUST use ONLY RA series disks. I keep getting confused. As long as they are both local disks on the 750 what is the difference? This is a non-trivial issue for a site like ours. It makes the difference between able to expand into an LAVC using microVAXs and not being able to expand at all. Clearly it is not an option for us to just buy everything and then try it to see if it really does work after all. Bob Hassinger Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-102 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 707.2 Disk Serving for MicroVax? 2 of 2 "Larry Kilgallen" 4 lines 30-JUL-1987 22:41 -< Massbus Disks are Fine >- ---------------------------------------------------------------- A DEC developer speaking at our LUG was asked about the RA disk restriction and he responded that there really was no restriction, it was just words that got added in the process of producing brochures. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 709.0 Modified Page List question 6 replies "John Osudar" 28 lines 28-JUL-1987 18:45 ---------------------------------------------------------------- VAX systems that have lots of memory (and memory IS cheap these days, at least if you know whom [not] to buy it from...) can see some nice improvements in paging performance by increasing the SYSGEN parameters related to the modified page list. (The modified page list acts as a cache; modified pages aren't written to disk and released to the free page list unless it's "necessary". If the page you need is in the modified list, very little has to be done to bring it back into your working set.) HOWEVER... certain conditions seem to make it "necessary" to flush the modified page list (i.e. write the whole thing to disk). This is worse than reaching the maximum limit on modified list size -- that only writes pages until the minimum limit, which can be set relatively high. I'm talking about writing the WHOLE list, megabyte after megabyte, all the way down to 0 modified pages left. I've spoken with TSC, I've read the relevant sections in the internals books (V3 and V4.4), and I've gotten some answers -- but I still haven't been able to determine all of the things that cause this. We found that files with nonzero global buffer counts trigger this behavior, and writeable global sections also seem to (actually, those seem to be parts of the same problem). We've eliminated those as much as possible, but we still get our modified list flushed several times a day. Does anybody out there know what else can cause this? Or, one step further, does anybody have a reasonable explanation why something that hits system VAX-103 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT performance so hard should be this easy to trigger (i.e. an ordinary non-privileged user can apparently cause the modified page list to be flushed); is it really a design limitation of VMS, or is it the implementation that's wrong??? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 709.1 Modified Page List question 1 of 6 "C J "Buck" Trayser" 21 lines 29-JUL-1987 00:58 -< There is a odd one, let me see if I can remember... >- ---------------------------------------------------------------- Very basically, if a call to MMG$FREWSLE to find a working set list entry finds one that happens to point to a page that is currently on the modified page list (probably via a dead page table scan), the modified list must be flushed and the process normally gets put in RWMPE. The list is flushed by setting MPW_HI and MPW_LO to zero. Once the list is empty then the values are reset. (This process may seem rash, but I am not familiar with any routine that will flush a single, specific page directly off of the modified list to its backing store.) Of course VMS will try to avoid writing one of these page table pages to the modified list, but there are several reasons why it may occasionally be stuck with this course of action. The most likely reasons for this to be happening (at a very high rate) are that there is a chronic lack of memory, PFRATL is set to something other than zero (often with a large WSDEC), the working set numbers are severely restrictive and/or BALSETCNT is low enough to be forcing a lot of swapping. Any of these fit your situation? C J Trayser 360 Interstate North Parkway Suite 600 - MS: 6/B4 Atlanta, Georgia 30339 VAX-104 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 709.2 Modified Page List question 2 of 6 "George Walrod" 6 lines 29-JUL-1987 07:47 -< Same Line, Different Wording >- ---------------------------------------------------------------- At the last DECUS (Nashville), I presented this question to VMS Development Group, they acknowledged the fact this problem does exist and there would be an improvement in this area in a future release. George Walrod 4260-b chain bridge rd fairfax, va 22030 ================================================================ Note 709.3 Modified Page List question 3 of 6 "John Osudar" 17 lines 29-JUL-1987 15:17 -< reply to .1 >- ---------------------------------------------------------------- Well, first of all... it doesn't happen at a very HIGH rate -- but happening at all is annoying, and writing an 8Mb modified list several times during a very busy workday can suddenly cause a dramatic increase in your page read rate (not to mention other performance effects). Regarding your list of possible reasons -- memory isn't THAT tight (32MB on 785; generally over 3000 free pages with free list SYSGEN parameters set well below that; PFRATL is zero; working sets are relatively large (DEFAULT/QUO/EXT=256/512/3072); BALSETCNT is never reached (I don't think we've swapped a single process in two or three years). I suspect that our problem may result from the aforementioned writeable global section business -- so the question should be: do writeable global sections ALWAYS cause an eventual flush of the modified list? Or is there some way to avoid it? (Since RMS global buffers and the VMS Rdb product both seem to use writeable global sections, this answer is really significant!) John Osudar Argonne National Laboratory 9700 S. Cass Ave. VAX-105 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 709.4 Modified Page List question 4 of 6 "C J "Buck" Trayser" 10 lines 29-JUL-1987 21:08 -< That is a hefty size MPL. Is there a way to avoid it? >- ---------------------------------------------------------------- 8 Meg Modified list?? What is out there? According to all the tuning info I have ever read, studied or written, MPW_HILIMIT should not be much over 10% or 12% of the size of your balance set memory. If it is mostly pages from users, then increase their working sets (specifically the WSQUOTA). Are you forcing pages out of the working set for some reason? Are you locking many pages in the working sets? Are the processes actually getting that 3000 working set?? (....Fishing) $ C J Trayser 360 Interstate North Parkway Suite 600 - MS: 6/B4 Atlanta, Georgia 30339 ================================================================ Note 709.5 Modified Page List question 5 of 6 "John D. Ferriby" 6 lines 30-JUL-1987 01:59 -< Regarding Global Sections and $UPDSEC >- ---------------------------------------------------------------- Haven't seen this *directly* mentioned...a call to $UPDSEC(W) will force the modified list to be cleared. Obviously this is a function of your particular applications and environment. This can be particularly hazardous when such calls reach a frequency to prevent the modified list from ever growing significantly. John D. Ferribyþò û 2871 Troy Centry û#2010 Troy, MI 48084 (313) 362-2595 VAX-106 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 709.6 Modified Page List question 6 of 6 "John Osudar" 23 lines 30-JUL-1987 18:56 -< reply to .4 >- ---------------------------------------------------------------- Well, first of all, we don't often get up to 8Mb modified list (especially not with the modified list getting flushed several times a day!) Running with WSQUOTA at 512 and WSEXTENT at 3072, many users end up with actual working sets over 1000 pages -- I don't think anything is getting forced out of anyone's working set for any reason I know of. Nobody is doing any unusual working set page locking either, as far as I know. We saw the same behavior with MPW_HILIMIT set lower (and it has been set at 2Mb, 3Mb, 4Mb, and 6Mb at various times in the past.) Something just causes the whole thing to get dumped. Obviously a lower HILIMIT will reduce the damage, but that's not the answer I'm looking for... a lower HILIMIT will also cause the list to be written more often due to the HILIMIT being reached. I'd be willing to increase WSQUOTA and decrease HILIMIT if that would help -- although with up to 105 balance set slots filled at times, I don't know how high I'd want to allow WSQUOTA to be. I'm also not sure I understood your previous comment in .1 -- the one about there being no way to write an individual modified page back to disk. I haven't delved too deep into the guts of VMS memory management code; were you saying that it's IMPOSSIBLE to make VMS write less than the whole list, or just that the present VMS code doesn't have a way (but a really clever VMS developer might be able to change that in a "future major release")? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-107 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT ================================================================ Note 710.0 Queue Accounting No replies "John Osudar" 25 lines 28-JUL-1987 18:59 ---------------------------------------------------------------- Our VAX runs about a dozen server queues -- some associated with network file transfers, others serving various local functions. We charge back our computer resource usage to users' projects, so we have virtually all accounting functions enabled. VMS considers server queues and print queues as equivalent, at least as far as accounting is concerned. However, server queues can do some strange things, which normal printer queues would never do -- for example, if the network link to a particular destination is down, traffic for that node gets retried at regular intervals until the link comes up. Other servers act as "intelligent generic queues" -- they examine each job, and feed it to the appropriate printer queue based on various characteristics. The problem is that VMS accounting is "all or nothing"; if you enable "print queue accounting", VMS will write a record every time a job stops processing -- whether it was completed, aborted, requeued or whatever; and whether or not the job's symbiont returned an accounting data packet in its status report. As a result, we can get thousands of blocks of accounting records that say "job aborted and requeued, 0 records read, 0 lines printed, 0 pages out". These have to be stored online, and when we do our nightly accounting run, these useless records have to be interpreted. Is there a good reason (other than the VMS Job Controller's lack of sophistication) why this has to be? Are other system managers bothered by this problem as well? Has anyone found a way around it? Would anyone else like DEC to fix this? John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 * VAX-108 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT * VAX-109 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX System SIG Committee List VAX System SIG Committee List As of June 24, 1987 CHAIR (CORE) Susan T. Rehse Lockheed Missiles & Space Co. O/19-50, B/101, P.O. Box 3504 Sunnyvale, CA 94088-3504 VICE-CHAIR (CORE) WORKING GROUP COORDINATOR Ross Miller Online Data Processing, Inc. N 637 Hamilton Spokane, WA 99202 SYMPOSIA COORDINATOR (CORE) Jack Cundiff Horry-Georgetown Technical College P.O. Box 1966 Conway, SC 29526 COMMUNICATION COORDINATOR (CORE) Don Golden Shell Oil Company Westhollow Research Center P.O. Box 1380, Room D2158 Houston, TX 77251-1380 LIBRARIAN Joseph L. Bingham Mantech International 2320 Mill Road Alexandria, VA 22314 LUG COORDINATOR (CORE) Dave Schmidt Management Sciences Associates 5100 Centre Avenue Pittsburgh, PA 15232 VAX-110 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX System SIG Committee List SYSTEM IMPROVEMENT REQUEST (CORE) Mark Oakley Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2669 SYMPOSIA COORDINATOR, ASSISTANT David Cossey Computer Center Union College Schenectady, NY 12308 PRE-SYMPOSIUM SEMINAR COORDINATOR HISTORIAN Jeff Jalbert J C C P.O. Box 381 Granville, OH 43023 PRE-SYMPOSIUM SEMINAR COORDINATOR (ACTING) June Baker Computer Sciences Corporation 6565 Arlington Boulevard Falls Church, VA 22046 COMMUNICATIONS, ASSISTANT David L. Wyse Professional Business Software 3680 Wyse Road Dayton, OH 45414-2539 VOLUNTEER COORDINATOR Elizabeth Bailey 222 CEB Tennessee Valley Authority Muscle Shoals, AL 35661 NEWSLETTER EDITOR Lawrence Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-111 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX System SIG Committee List SESSION NOTES EDITOR Ken Johnson Meridien Technology Corp. P.O. Box 2006 St. Louis, MO 63011 CAMPGROUND COORDINATOR Kirk Kendrick Shell Oil Company 333 Highway G, MS D-2146 Houston, TX 77082-8892 PAST CHAIR Marge Knox Computation Center University of Texas Austin, TX 78712 ADVISORS: -------- Joseph Angelico U.S. Coast Guard Detachment National Data Buoy Center NSTL Station, MS 39529-6000 Art McClinton Mitre 1820 Dolley Madison Blvd. McLean, VA 22102 Al Siegel Battelle Memorial Institute 505 King Avenue Columbus, OH 43201-2693 WORKING GROUPS: -------------- COMMERCIAL Robert Boyd GE Microelectronics Ctr. P.O. Box 13409, MS 7T3-01 Research Triangle Park, North Carolina, 27709-3049 VAX-112 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX System SIG Committee List FIELD SERVICE Dave Slater Computer Sciences Corporation 6565 Arlington Blvd. Falls Church, VA 22046 INTERNALS Carl Friedberg Seaport Systems, Inc. 165 William Street, 9th Floor New York, NY 10038-2605 LARGE SYSTEMS INTEGRATION Leslie Maltz Stevens Institute of Technology Computer Center Hoboken, NJ 07030 LIBRARY Glen Everhart 25 Sleigh Ride Road Glen Mills, PA 19342 MICROVAX Ray Kaplan Pivotal, Inc. 6892 East Dorado Court Tucson, AZ 85715-3264 (602) 886-5563 MIGRATION AND HOST DEVELOPMENT VAXINTOSH Jim Downward KMS Fusion Incorporated P.O. Box 156 D Ann Arbor, MI 48106 MULTIPROCESSOR Eugene Pal U.S. Army CAORA (ATORCATC) Fort Leavenworth, KA VAX-113 PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX System SIG Committee List NETWORKS Bill Hancock P.O. Box 13557 Arlington, TX 76094-0557 REAL-TIME PROCESS CONTROL Dennis Frayne McDonnel Douglas 5301 Bolsa Aveneu Huntington Beach, CA 92646 Larry Robertson Bear Computer Systems 56512 Case Avenue North Hollywood, CA SECURITY C. Douglas Brown Sandia National Labs Division 2644 P.O. Box 5800 Albuquerque, NM 87185-5800 SYSTEM MANAGEMENT Steve Tihor 251 Mercer Street New York, NY 10012 VAXCLUSTER Thomas Linscomb Computation Center University of Texas Austin, TX 78712 PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Submission Form INPUT/OUTPUT Submission Form A SIG Information Interchange Please reprint in the next issue of the Pageswapper If this is a reply to a previous I/O, which number? ________ Caption: ______________________________________________________ Message: ______________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ Contact: Name _______________________________________________________ Address ____________________________________________________ ____________________________________________________________ ____________________________________________________________ ____________________________________________________________ Telephone ____________________________ Signature _____________________________ Date ________________ Mail this form to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station, Cambridge, MA 02139-0901, USA To register for on-line submission, dial (in the United States): (617) 262-6830 and log in with the username PAGESWAPPER. PAGESWAPPER - September 1987 - Volume 9 Number 2 INPUT/OUTPUT Submission Form Tear out or photocopy reverse to submit an I/O item Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA PAGESWAPPER - September 1987 - Volume 9 Number 2 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - September 1987 - Volume 9 Number 2 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX Systems SIG Fall 1987 SIR Ballot VAX Systems SIG Fall 1987 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX cpus (check all that apply) 8700/8800 ___ 8600/8650 ____ 8500/8550 ____ 8300/8200 ____ 11/780,11/782,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX I,II ____ MicroVAX 2000, VAXstation 2000 ____ We use VAXes in the following applications(Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other __________________________ I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's): -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- I oppose the following SIR's as detrimental. (List from zero to five SIR's): -------- -------- -------- -------- -------- Mail to: Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, OH 43201-2693 USA To be counted, your ballot must be received by October 30. PAGESWAPPER - September 1987 - Volume 9 Number 2 VAX Systems SIG Fall 1987 SIR Ballot Tear out or photocopy reverse to vote on SIRs Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, Ohio 43201-2693 USA