From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 17-JUL-1992 02:57:45.59 To: info-vax@sri.com CC: Subj: More VMS WP discussion I reply to various discussions about WordPerfect for VMS. First I address a few of the comments from: Date: Sun, 14 Jun 92 14:17:56 cdt From: "McMahon,Brian D" To: INFO-VAX@SRI.COM Subject: WordPerfect, a Cautionary Tale > >Much to my surprise, I have something nice to say about the installation: >Licensing. WPCorp's software licensing procedure works quite well, far >better than most such gadgets I've seen, and they deserve credit for it. Thanks, that was one of my many projects. > >Upgrading printer drivers from a 5.0 installation to 5.1 is sheer misery. >The 5.0 and 5.1 drivers and settings files are different beasts, and EVERY >BLINKING ONE OF THEM has to be converted BY HAND, ... > >Of course, PTR51 does NOT see fit to pick up the printer device type or the >..PRS filename from the old definitions. > Due to a major change in the way .PRS files were named and printer types were identified from 5.0 to 5.1, the /VERSION_UPDATE does not have the ability to automatically identify the appropriate 5.1 printer type from the 5.0 .PRS file to build the 5.1 .PRS file (5.0 .PRS customizations will have to be readded or converted to 5.1 as well). Printer files which don't bear the original unique name could never be automatically updated. Sites which must customize a .PRS file several different ways will have several versions of a .PRS file not bearing the same name. But this is the only thing /VERSION_UPDATE does not do. Everything else is copied to the 5.1 printer list from the 5.0 printer list. This manual selection of the printer type could have been a quick task, but was especially time consuming due to a combination of things about which you were obviously not adequately warned in the documentation, as well as the fact that the list of available printer types was not maintained in cache between uses. The more .ALL files you loaded during installation, the more time WordPerfect takes to create the list of available WP 5.1 printer types regardless of whether the selection is automatic (caching could improve this, but all 120 files still would have to be scanned at least once). If the same .PRS file is shared where multiple printer entries represent an identical printer type (even sharing between different .VSET files), the update process is much easier since only each .PRS, and not each printer entry must be manually selected from the 5.1 printer type definition list. WP 5.1 printer selection gives you easier access to "List" existing .PRS files which can be shared by multiple printer entries and settings files than WP 5.0 printer selection did. This will make printer management easier in the future. If I were upgrading from 5.0 to 5.1 and I knew I had several printer entries using different .PRS files which should be using the same .PRS file, I would only update the new version on one of the printer entries (but be sure to save All and not just Updated printer entries upon exit from /VERSION_UPDATE) and then use the printer list command line utility (described in section 3.14 of the 5.1-1 sysman guide) to change the name of the .PRS on the other entries so that they now all used the same .PRS file, saving me time now and in the future. I generally recommend the printer list command line utility. It can simplify printer management for sites with many printers, easily allow text editor manipulations of the list that were impossible from within printer selection, and survive .VSET file loss or corruption. If 120 or so .ALL files were loaded containing every printer known to WPCorp, the printer type selection screen will take a long time to come up. WP document WPCORP$PTR51DIR:AAAREADME.PRINTER_LIST can help you decide which .ALL files to delete or move to another directory if you installed too many. > >On top of it all, the PTR51 program is buggy as all get-out. This was obviously not by design. This program was tested like all others. I won't speculate on why it may have been buggy. I hope that all such problems have been reported and fixed. I expect that future products, being "C" rather than converted assembly language, will be generally better. > >Digression: Folks, this is not MesS-DOS. This is a VAX. Once you've read >the list of drivers in once, CACHE IT, for God's sake. Don't keep >repeating the same expensive operation time and time again. PTR51 is so >inefficient, it's breathtaking. Maybe this is tolerable on a single-user >PC, but it's the WRONG thing to do with VMS. End of digression. The printer selection list is not kept in cach between uses because it is potentially very large. If there are 1000 printers with a description, a .PRS file name, an .ALL file, indices to find the info within the .ALL file, and whatever else is required, the memory requirement is large (and the caching would make less difference in the cases where it was small. The same printer selection routine is used not only in PTR51/VERSION_UPGRADE but also to select "Additional printers" within WordPerfect, which would permanently subtract that much memory for the rest of the WordPerfect session. Another routine could be written to release the cache after print selection from within WP. Even so, caching completely fails to help the first time you access the list. In WP, the list is accessed infrequently enough that generally it would always be the first time, and so a release of cache would be the sensible thing to do so you would never have the advantage of cache, whereas properly limiting the number of .ALL files helps in all cases without the waste of memory likely in the other scheme. I am not saying that WPCorp will not reevaluate keeping this list cached between uses. But it is still important to limit the number of .ALL files kept in the main directory where PTR looks for them. Digression within a digression #1 It is too bad that VMS forces you to decide on an item-by-item basis whether or not to cache. We wish virtual memory were as unlimited as it is often thought to be, but in most cases you are still limited by PGFLQUO which some sites are forced to keep quite small. VMS severely lacks a scheme to blur the distinction between files and memory and avoid the limits inherent in PGFLQUO or the size of a process' page tables so that a program's storage use can automatically slide between disk and memory based upon its quotas without imposing artificial limits or maximum sizes. In some cases, the support for memory scalability in other operating systems seems to be better (I cringe when I say this, since I love VMS after developing on it and going to all depths in the operating system for the last 10 years). I proposed a simple scheme to several VMS engineers to accomplish better memory use. While they admitted that there was currently no good way to accomplish scalability, they seemed worried about other things just now. They seem so used to the warm fuzzy feeling that virtual memory can give you that they forget to solve the problems and real limitations it has, and another problem is RMS record structure (not trivialize its beautiful and useful aspects) which artificially makes too great of a barrier and distinction between representation of data on disk and the representation of data in memory in cases where the two should be and are identical on other operating systems. But this is too much of a digression within a digression. I would be happy to discuss this more at length later. End of digression within a digression #1 > >Digression #2: Why, at WP for VMS 5.1-1, are .PRS filenames *still* subject >to the brain-dead-DOS 8-character limit? WHY? End of Digression #2. This is by design. The name of the .PRS file is stored in the document prefix. The DOS product can only deal with an 8.3 filename in the document prefix. Sites which share documents between platforms may appreciate the fact that the documents are binary compatible, as well as the fact that the appropriate printer is selected from the list when the document is transferred between DOS and VMS by matching the .PRS file name, which must be 8.3 under DOS (auto selection does not occur if the option to reformat all documents for the user's default printer is selected). > >Printer management is unspeakably cumbersome. Keep trying, guys, you're not >quite there yet. There are still areas for improvement. Were you aware of the printer list command line interface described in section 3.14? I would appreciate specific suggestions. That's how the printer list command line interface was created. Here I begin comments on a reply by: Charles Robinson End-User Support Manager Washington University Dept of Surgery St. Louis, MO 63110 >As far as accepting WP's installation defaults, the only ones we do not accept >is setting up background queues (because we run a cluster and the Guide states >that you should not use them in a cluster) and loading all the printer files. By way of comment, background queues can still be quite useful on a cluster (it all depends upon your priorities), but clusters can be so varied and the goals of cluster management so different that the automated logic of determining where and how many background queues to set up escaped us. Loading all .ALL files seemed a preferrable option to loading NONE, since everything else seemes to be a manual selection. Perhaps the default should be all DEC printers and all others would have to be manually selected. Obviously any default is going to cause some, and possibly many, to have to customize. > >Finally, if you call WP and talk to the programmers (which is easy to do if you And you can talk to me whitmer@eisner.decus.org. > >WP is one of the most complex programs on the VAX and pushes graphics and VT >terminals to the max. If you stop and think what the program is doing when you >are scrolling through a table, showing italics and super/subscripts or View >document while handling proportional fonts, you have to be impressed how well >things work. Thanks, much of that is my own code for VAX. Now I proceed to comment on a private reply from Brian which was forwarded to me. I certainly hope that this is not improper. He raises additional questions which should be addressed. > >It did occur to me, about halfway through the list, that I could have saves a >lot of time but ripping that page out of the manager's guide and redoing the >printers from scratch OK. We will forward the comment. > >Defaulting to 8x3 filenames is one thing, but FORCING me to use xxxxxxxx.PRS is >just plain lazy. The forcing of the .PRS extension is necessary for compatibility with the DOS product. I too wish it were not that way, but I think document compatibility is essential. It certainly wasn't easier to do it that way! You will find that most other filenames are not that way. Another problem case is graphics file names, which we were able to hide in the document from the DOS product, but our only possible hiding technique make it impossible to edit the graphic on the DOS platform without destroying it (but printing it works just fine...), so VMS WP prints a message to that effect when a filename that is not DOS compatible is used. > >WordPerfect installations happen to stand out as CONSISTENTLY taking more time >(which is always in short supply) and causing more headaches (which never seem >to be in short supply) than I feel is warranted. I believe that the installation has gotten more complex to support more complex features and more complex VMS cluster situations. It would certainly be much simpler, for example, if we took DEC's approach and only supported DEC printers. As it is brought to WPCorp's attention that the installation does not satisfy everyone's needs, new options are created. Alternatives cost simplicity and time. I suspect installation is somewhat simpler if you take all the default options, but I would love to discuss ways that it could be further simplified. There frequently seem to be significant omissions from documentation. In their defense, the writers also have a real juggling act to give you a procedure that is as simple as possible while accounting for very complex situations. There are lots of judgement calls which inevitably produce errors and room for improvement. We profit most from concrete examples of how installation and the documentation could be simplified for everyone. What would you leave out? If you saw the movie "Amadeus", you saw Mozart's confusion when the king said "There were simply too many notes" (not to say that such a complaint is not legitimate, but that it is hard to deal with). Now I proceed to proceed to comment on a note by: Gary Nalley of Millsaps College > >Agreed, converting now will save you grief, like the grief you get when you >call their support and you spend half the time checking dates on files because >they don't know how to use version numbers. I do not understand this comment. How would you improve the current version scheme? > >It was FOREVER until WP Corp got a DS 300 and then wrote a printer driver that >would work with it and talk to MAJOR name non-DEC printer. > Hardware acquisitions don't happen over night, especially when it is for testing hardware compatibility in a situation where it was thought tests with similar hardware (other DECServers) should have sufficed. We still don't own every terminal server made by DEC (fortunately we don't have to own every one made outside of DEC since they are less prone to this type of incompatibility). Not to say that our response time can't be improved. But if new printer drivers had to be developed, that is not a fast process. It is especially sad that DEC seems to make such concerted efforts (if that is possible for a company the size of DEC) to exclude non-DEC printers from connections with their systems. This is very similar to what they do with disk drives. Apparently the peripherals don't sell on their own merit alone. Otherwise, why can't you print to many non-DEC printers as an attached printer (especially doing soft fonts or graphics), why can't the DEC symbiont leave non-DEC escape sequences and form control alone, or even better yet, recognize or utilize them. Why can't the same escape sequences which drive a printer on other PC or VAX ports or DECServers drive a printer on a DECServer 300? Why can't the PostScript symbiont drive non-DEC postscript printers? PostScript is the standard, not DEC. DEC has a long way to go before they can claim to have an open system in the area of printing. > >I agree, read the WHOLE System Manager's Guide. But also buy a DOS license >with all the DOCS, the DOS Printer Utility (PRS Editor) guide, and any other WP >DOS Technical books you can get your hands on even if you don't have or never >touch a DOS machine. It may take a while to figure out the subtle difference >between the DOS and VMS versions, but you sure won't find any of the >information in the VMS Docs. Granted: DOS WP documentation is sometimes superior to VMS WP documentation. VMS WordPerfect development can't compete with the DOS user base and hence supports a much more complex environment using fewer resources. The VMS WP product has come a long way since 5.0 when the only way to customize the .PRS files was to use the DOS WP printer program. But much remains to be done. > >What sysman at a large sight would not load up the whole tape when he has the >disk space? Why go hunting for a tape in the library, fight for access to the >only TK50/70 on the cluster, scan the whole tape for one ALL file when the VP >wants his new oddball (that he didn't consult anyone when he bought it and >won't admit he bought a piece of junk) printer installed and working NOW!! There probably should be documentation explaining how to move less significant .ALL files to some other directory or perhaps a way to do that automatically. > >Also, what is your definition of printer support? I have never got one of the >oddball, noname printer/print drivers to work correctly and consistently. I do not understand this. > >Also, have you ever tried to print more than 15 copies of a document to an LN03 >Scriptprinter using multiple copies under the WP print menu? Mine power-on >resets the printer. This is a bug which has been acknowledged by DEC. It has to do with the way their DEC-PostScript symbiont produces multiple copies while only sending one copy to the printer. I have reproduced the same problem printing multiple copies of PostScript from DEC-written PostScript (MSWindows) drivers. The same thing will happen on LPS20's and 40's, it just takes more copies to run out of memory. I believe that this is one of the reasons the "Multiple copies generated by" option was introduced in WordPerfect, to allow multiple copies to be generated by WPCorp so that the problem can be bypassed. > >Have any of you had the WP/GLOBAL process hang and locked out all your WP >users? Trust me, my phone was going nuts while I was listening to the >wonderful music at WP DEC support. History: This was mostly brought on by a change made to VMS (5.2, I believe) for DECWindows which caused a disconnected process to call exit handlers and an exit to occur instead of just deleting the process. There were bugs in VMS (like turning off RMS before calling the exit handler) and bugs in WPCorp fileio cleanup which in certain circumstances caused the processes to hang in the exit handler (also in a state which didn't allow blocking AST's to fire to release the cached read access which is incompatible with write access to the global settings files. All known situations which can produce the process hang have been since eliminated, and there have been no recent reports of this problem. Current status: There is one other situation which has been around since long before VMS 5.2 which still produces a similar problem. If a user control-Y's out of WordPerfect and types no following command to cause the image to exit, then the lock is not released because the image has not exited but the blocking AST cannot be delivered when the DCL prompt is active. The only known way for WordPerfect to solve this problem is to create an option which forces any control-Y to force an image exit without giving the user the ability to type "CONTINUE", which most sites would probably opt not to use. A command procedure which invoked interactive WP may issue the command: ON CONTROL_Y THEN EXIT to solve the problem. Although this variation of the problem is seldom if ever reported by customers because users who have access to control-Y at all usually follow it by another command. But we are still open to solutions. Troubleshooting: There is information in the system manager's guide to determine which process has hung the global settings file so the problem can be solved from that end. The problem may be avoided altogether by copying the globalset file to a temporary location, doing global setup on that file, and copying it back. Users won't see new printer definitions without exiting WP, but most other settings are only read during product startup anyway so it will not affect them (the blocking AST uncaches all settings and allows settings to be read from the new version of the .VSET file, but a copy delivers no blocking AST). It is also possible to hang on the local settings file, but fewer users share the same local settings file so this happens much less often. > >But why don't they admit they have problems? It is SO frustrating to me to log >into their support board, ask for a problems listing and it lists "no known >problems" but they have patches A-H listed in the program directory. I was not aware that WPCorp does not admit to having problems (see page 203 of the system manager's guide, for example, where it isexplained how to troubleshoot the frozen setup problem just discussed). It takes some effort to qualify a problem through support and problem resolution and know that it really is a problem. By the time most problems are defined, they are solved and become a patch and, hence, no more a problem. The problem list should only include problems that, for some reason, will not be fixed by a patch (and are not already documented in the system manager's guide). So the descrepency between the known-problem and patch lists should be 100%. If there are known problems (not desireable enhancements), which can not or will not be addressed in a patch, then they definately should appear in the list. I have forwarded the comments about the adequacy or inadequacy of the BBS information to those responsible. I can assure you that anything missing is an unintentional omission rather than willful concealment. > >You actually talked to a programmer? I am a programmer at WPCorp, and I talk to many users about problems that couldn't otherwise be resolved. I have also tried to talk to developers at DEC about unresolveable problems, and I believe that it is much less difficult to talk to a programmer at WPCorp than at DEC eventhough we have far fewer, but that could be a distorted perception on my part. The initial work done by support operators and problem resolution teams is invaluable and allows programmers to handle more problems and make progress much quicker. You may sometimes have to ask for a manager. The support operator may differ in opinion about the value of the answer he has given. Such cases must be resolved somehow. In my experience, this is not uncommon in any support organization. Also, you can talk to me at whitmer@eisner.decus.org. > >But you have to admit, at least Lotus can do a decent VIEW of a graphics >screen. The View Document feature in WP for VMS is a waste of code (especially >on a REGIS terminal). I don't understand how you can call the ReGIS document view a waste of code. The ReGIS display uses the same algorithm that the PC display does -- only the protocol is different -- producing a similar display. I think we need to troubleshoot your problem: If you "SHOW TERM", do you see ReGIS or SIXEL listed? As described in the system manager's guide, autoselect can only choose SIXEL or ReGIS if these terminal characteristics are set. Did you "SET TERM/INQ"? Has your problem been reported to customer support? Also, only third-party terminals support ReGIS but not SIXEL. SIXEL is simpler, more efficient, and more reliable than ReGIS (but even ReGIS produces a good display when I manually select it on the VT340 sitting on my desk and others). WPCorp even produces a usable albeit imperfect picture under DOS Kermit in SIXEL mode. If you are getting a blotchey-looking mosaic, that is definately NOT ReGIS. That is the display for a non-graphics terminal. You can manually select the ReGIS or SIXEL driver in setup if it is not practical to "SET TERM/INQ", but if you are running a VT340, WordPerfect will not know that you may have additional colors that can be discovered by doing a color request and better SIXEL resolution unles DECCRT3 is set. If you are referring to what DECTerm or certain other DEC-written terminal- emulators do with WPCorp output, I would have to place the fault with the emulators, along with the many other problems we have reported to DEC about DECTerm and other emulators, some of which, but by no means all of which have been fixed. Imperfect though it is, I would take Kermit over PCSA sethost or DECTerm any day. > >Speaking of support, why can't I have 24 hour and extended weekend VMS support >like the DOS people? DOS people don't modify their systems late at night or on >weekends like I HAVE to do?) Some after-hours support is available for VMS (weekdays 'till midnight I think, call for exact hours), and if you need more, it has always available upon special request. Many call WPCorp in advance and tell them that they anticipate the need for additional support hours at such-and-such a time on such-and-such day because they are upgrading VMS, WordPerfect, ALL-IN-1, etc. Many sites have received critical support this way. I agree that this is not quite as good as having them there all the time, but it may be workable. I'm suspect that if enough VMS managers request currently- unscheduled support to warrant it, the times will be permanently covered. DOS WordPerfect has an advantage in numbers. It is hard to hire 1/10th of a person if that is all that is justified. > >When I call with a problem, its a problem (I would love to forward our >support line to a company and see what happens). I have to admit that they are >slowly learning they have some big league VMS users out here and we expect to >receive a superior product and superior support when we shell out the bucks to >have 1500 users access their product. Your situation is by no means unique to VMS. Novell and other network managers also shell out the bucks to have 1500 users access the product (and there are also a large number of VMS sites with only a few users). I don't know that our VMS support line ever receives calls from end users. They are nearly always talking to system managers. On the other hand, given the huge number of DOS support personell, they can specialize somewhat more than the VMS group can. If the support is inadequate, it must be improved. WPCorp would profit from specific remarks on where the product or the support is inadequate. I have a huge private agenda, but until user requests come in, it is harder to sell WPCorp decision makers on specific improvements. I am certain that some Novell network managers get just as frustrated with WP DOS support as you do with WP VMS support. Customer support is never easy and always must be improved. The newly-announced WPCorp strategy includes major customer support improvements for large sites, whatever OS they may be running, because their needs are sometimes more critical. Now on to comment on Charles' reply to Gary's note. >I am puzzled about your comments on problems with DS300s. I have not >seen this with the 3 we have but there are not a lot of printers connected to >them; most of ours are on DS200s. I believe that some of the problems with the DS300 are solved by changing settings on the DS300 itself. The problem was (if my memory serves me) that the same settings that had to be set one way for DS200s and a different way for DS300's (thanks, DEC) to work correctly. >DEC says HP does handshaking wrong and DEC does it right according to the >"standard"! (Or, we dare you to use anybody else's printer on OUR network!) Surely not WPCorp! > >SIXEL is a "standard" too, but do you know anybody besides DEC who >sells one?) And then there is the problem of trying to send non-DEC printer >PostScript through a VMS queue and see how it gets mangled! > And ANSI. See previous comment about even trying PostScript with DEC's own PostScript symbiont! Or is everyone else's PostScript out of step but Johnny-DEC's? > >I agree that the BBS could be better when it comes to bugs and patches (I >suggested including the date of the unlettered patches that hadn't been gathered >into a lettered patch). Although it holds great promise, it appears that the >board was established with too little support to reach its goals (it still >doesn't know about VT420 terminals). They are trying to post patches on the >first Tuesday of the month. An accurate assessment which I will forward with the other comments.... > >They can't fix 'em if they don't know about them! Also very accurate. On to comment on a note from Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu, JHUVMS system programmer, Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 > >Why can't the upgrade procedure setup the same printer names, queues and types >that you already have?? The upgrade procedure DOES preserve everything. I have just run it several times to make sure. It preserves description, queue name, integration flags, and everything else applicable. It can't automatically correlate the different .PRS definitions lists. > >$ptr51/version_update >%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=6564223C, >PC=00109A55, PSL=0BC00004 Obviously the testers missed something. I hope it is fixed now. > >How hard is it for the procedure to figure out that you're in a cluster and >make NO the default for background printing. This is a very good point. It was discovered late in the process that a cluster's default calculations for background queues were frequently bad. My previous note explains that background queues are frequently useful on clusters. It was just WPCorps calculation of how to configure the background queues on a cluster that made the default installation option to enable background queues not useful. Perhaps background queues should probably never have been the default in any case since it was something new. (Hindsight is always 20-20, and if I remember correctly, I originally recommended that background queues be default -- oops -- although I later recommended that it be changed to never make background queues never the default -- especially on clusters -- but to let the system manager configure it as desired. But it is harder to reverse a decision that to initially make the right one). The problem with new features is that, however important they are, system managers frequently miss them and continue to complain for years about the old problems that the new feature was supposed to fix. That was the reason we originally recommended background printing to be the default. > >But the attitude of 'WPcorp' is that >the entire universe revolves around them! Perhaps this comes from the roots >in MSDOS, a glorified 'program loader and file system specification' which >gets chucked by any program that starts up. That there is anything else on the >system that has to be maintained or that the product has to coexist with >anything seems to be a foreign concept here, I mean WHAT ELSE IS THERE besides >WPCORP? I do not believe that this is an accurate representation of WPCorp attitudes, and I believe I could site much evidence to the contrary, but that is neither here nor there. The frustration and perception I do understand and sympathize with, and the shortcomings which caused the perception we intend to correct. > >>I also did not encounter crashes or register dumps when doing the automatic >>font changes in these two PRS files, but I may have been just lucky; I don't >>know why you had the problem entering file names -- I hope you reported this to >>WP. However, as the experienced programmer that you sound like you are, I'm >>sure you appreciate the complexity and difficulty in writing bug-free >>commercial software. There's nothing that a programmer hates more than a "lucky" bug which only crashes once in a while. If it crashed all the time, you can bet that both the testers and the beta sites would have uncovered it (with a very few notable exceptions which are far too embarrassing to admit here). > >Maybe they should start with the condition handler... 'improperly handled >condition - image exit forced' seems to be the most popular WPcorp error WP has no condition handler, unless you are calling from ALL-IN-1 or WordPerfect Office. We found that ALL-IN-1 abused WPCorp condition handlers so we could declare none of our own. Can you reproduce the problem? I would love to track it down (I hope you have the latest version and patches...). If it is not easily reproduced, install SYS$SHARE:IMGDMP and SET PROC/DUMP on processes likely to encounter the bug. We can usually tell a lot from a dump file. ALL-IN-1 interferes with a process dump file so you have to contact Digital to produce a dump file if it is in ALL-IN-1. I've gotten dumps more times than I care to remember from DEC software and from public domain software alike. It means some programmer or the assembly conversion program blew it. What can we say? We'll fix it ASAP in a patch! And with the demise of our assembly language converter with the future "C" versions a major source of bugs will be gone. > >After I did the 5.1-1 upgrade and did a @sys$startup:wpcorp$startup (I thought >$ was reserved to digital by the way, oh, but this is WPCORP!), I tried >to install the $@!&*(!$&(*)$!@!(&*$!@ LICENSE (I hate the LMF, but >it's there and it works, why can't they use it: WPCorp - our reinvented >wheels are better - they're square. WPCorp - doesn't every product have >it's own licensing facility? What? You mean you don't have a full time employee >maintaining Word Perfect??). See the previous praise of our license utility. But I understand your desire to use a single central LMF. Let me explain a few things standing in our way (which would lead us to call DEC's LMF the square wheel). First of all, our first iteration of a license key was developed here before DEC had an LMF. Our products still support VMS versions prior to any DEC LMF, let alone a stable LMF, and still sites on those versions (a few with no LMF, and many with no stable LMF). Not all sites are excited to upgrade to new versions of VMS. Some sites I know just recently upgraded from 3.x to 4.x... and many don't want 5.5. Secondly, the LMF was designed for DEC software pricing. WPCorp could use it if they mirrored DEC pricing schemes, raising the prices on dinosaurs to force sites to abandon old-but-reliable machines and practically giving the software away on new CPUs to encourage hardware sales. The DEC scheme seems less fair and DEC releases so many new CPUs so quickly that it rapidly becomes impossible to maintain a more equitable scheme. We eventually eliminated CPU capacity licenses not only because it was so hard to provide it equitably, but also because it draw criticism, because it would be so different from DEC's. The DEC scheme also has problems with simultaneous use licenses. The last I heard, you could not purchase a 100-user pack from DEC. If you want 1500 users on your system, do you want to install 1500 single PAKs? DEC's enforcement of concurrent use also seems wrong. We also cannot use it since a product may be activated several times independently in the same image or in subprocesses, but all such access must count as a single use. I would be happy to go into detail here as I have done on DECUSServe. The information in the DEC LMF database is also simply inadequate, and what is there is not adequately available to the program. Also, I am unaware that DEC has ever officially given anyone (at least not us) encouragement or permission to use the current LMF. Now DEC can draw criticism because WPCorp simultaneous-use licenses are better... But we are continually reviewing our decision no not use DEC LMF. We would really like to use the DEC LMF in the future. Our new products are completely written in "C" for Alpha VMS. It would be an opportune time to make the switch so we don't have to rewrite our license utility in "C" for Alpha VMS. We were very hopeful about the next release of DEC's LMF, both that DEC would cooperate and that we could use what they provide. After many months of trying, I have had one meaningful technical discussion with DEC engineers. Many issues were resolved in that session, but major obstacles remain (mostly an obstacle introduced in the new LMF which wasn't in the old, which I can't discuss because WPCorp is under nondisclosure). Perhaps we could support either type of license and let the system manager determine whether DEC LMF was worth the sacrifices. I did receive assurances from DEC that the issues would receive further consideration and they would communicate further, but I have heard nothing for quite a while again. > >>WP is one of the most complex programs on the VAX ... > >I fully agree with you, so why can't they nail the easy stuff (installation, >error handling, etc...)? We have 20/20 here (don't get me started, but at least >they use LMF) and thank god don't have Lotus (knock on formica). Maybe it's >something about a PC mindset? What is wrong with WPCorp error handling (or do, refer to the error message which you interpreted as a bad condition handler)? What normal DEC application recovers from access violations or other similar problems. I've seen to many crashes to think there is a magic solution -- DEC VUIT, anyone? Even most of the old standard VMS utilities occasionaly give me crash-dumps. Concrete examples from the installation of how simplification is feasable would be very useful. Anyone who believes that installation is easy under VMS hasn't installed ALL-IN-1. The complexity always grows with the features, especially the OS-interacting ones, and the complexity of the operating system is also a factor. Most system managers need to be able to customize the installation (you mean you don't want all .ALL files, or only DEC printers, or the installation to go to SYS$SYSROOT, or exactly n background queues on each cluster member, or queue integration, or the user to have to wait for all print processing, or intelligent printer resource management, or a multilingual user interface or language facilities, or ...) Making it simpler for one person can make it impossible for someone else. But we love to make it simpler for all wherever possible. > >While we're on it anytime we so much as touch the global printer setting a >bunch of users lose their settings and can't access most of the printers (this >happened after the upgrade as well), we have people delete their .vset >files and redo them as a not so great workaround. The only behavior that I can think of which would cause this is if you specify FORCE when modifying the printer list in the global settings file. FORCE is documented as the system manager's way to wipe out user printer lists. If the system manager goes back and changes the list back to "Default" rather than "Forced", the user's printer list will reappear unless the user has gone in and modified and resaved the printer list minus the missing printers. A non-captive user can also /FORCE/IGNORE=INHERIT and change his own list to FORCE (with a later time-stamp) and the list is recovered. If some printer corruption took place (and we are aware of no unfixed bugs which could cause corruption, but who knows?), this still doesn't destroy the user's printer list. WordPerfect 5.0 merged global settings physically into the user's local settings file (corruption and all), but 5.1 only modifies the local settings file when the user makes a modification to it, and even then, it never receives global settings. The PTR51/EXPORT command (the printer list utility previously mentioned as described in section 3.14) can also export the printer list (either global or local) to a safe ASCII file where it can be imported into a new file if you experience corruption. If this problem is not due to forcing the system printer list (and especially if it is as reproducable as you say), please contact WPCorp support. Thanks, These are wholly my own comments. I hope they are helpful. I hope I covered most issues. I will see what I can do to regain info-vax access (last time it was on a charged account, and I ran the $$$ into the hole so many times accessing info-vax, the account owner kindly asked me to never use it again...). In the mean time, someone will have to send me a copy of anything they want me to see. I would also be very interested in any discussion of how a site can get a true internet connection without sacrificing security. That was the determining factor, although the large expense figured in as well, last time WPCorp considered such a connection. Sincerely, Ray Whitmer WPCorp VMS programmer whitmer@eisner.decus.org