OC.PEDHEM@CU20B.COLUMBIA.EDU ("Christopher P. Lent") (12/30/86)
Hi, We just upgraded from VMS 4.2 through VMS 4.4 onto VMS 4.5. Two problems resulted, both minor. The first is that SAS 5.03 won't run. [fixable with directions] The second is that VAXTPU sections must be re-built. [ User must re-save interactively defined key_definitions ]. Unrelated to the upgrade, in the CCALC product, I realized where DSD corp. had messed up on the terminal definitions for VT100 series (worked in VT100 mode but not in VT200 mode). [Description of fix follows] ----------------------Further discussion------------------------------- *** SAS 5.03: We talked to the people out at the SAS Institute. They said (well approximately): "Oh, if you upgrade to VMS 4.4 or 4.5, SAS stops working. This is a known and correctable problem. The instructions for telling SAS to use the VMS 4.2 run-time libraries are in the document shipped on May X,1986. What? You didn't get that? Oh, we'll ship it out to you." P.S. They say SAS will not need this sort of pampering in the future. I'm expecting the document this week, but I'm wondering if there's anything else about it I should know. I would appreciate any reponses (to the address(es) below) from anyone who has been through this. *** VAXTPU: Well, I knew that there was something just a little bit too nice about being able to save interactive key definitions. One of our users just loves the EVE interface to TPU. He saved many key definitions to make EVE nicer for the himself and the secretaries. Problem: The global sections he created with EVE in VMS4.2 are unusable under VMS4.4 (and 4.5 of course :-) Query: Is there any way to read these back (even under VMS4.2) and write out the contents to be recompiled? I figure that these sections are compiled images and the whole decompilation would be about as difficult as "Here's a executable, create a source image which will compile into it." Luckily the user said he'll just go through the key definition process. I also pointed him to the SYS$LIBRARY:*.TPU files. This way in the future he can (hopefully :-) just recompile the TPU source when DEC decides to switch it's section file format again (say VMS 5.4). *** CALC We have Version 1.5A of CALC. Problem: Would work fine on VT100's or VT2X0's set to VT100 mode, BUT ..... Printed things like '[2J[H' when used on VT200 terminals which were set to VT200 mode. Solution: Apparently the terminal definition file (CCALC:SCREEN.100) used 155 Decimal instead of 27 Decimal of Escape. VT200's are not fond of 155 (or 9B for all you hex fans). Fix: First edit the file CCALC:SCREEN.100 and change all the 155's to 27. Then, since the VT100 is apparently one of the base terminal definitions compiled into CCALC, you must specify -TCCALC:SCREEN.100 on the command line. You could set the symbol CCALC$TERM to this or append the -TCCALC:SCREEN.100 to the CCALC symbol definition. In our case I converted the CCALC:CCALC.COM routine to use the logical name CCALC$TERM instead since our site is nearly all VT100 compatibles. Comments: All of these problems were probably avoidable: The first I could have found out about by calling SAS and asking "What do I have to know to updgrade from VMS 4.2". I figure the more people that do this sort of thing, the more they will realize it is in SAS's best interest to make SAS independent of VMS changes. The TPU "problem" I could have found out with a little more effort in the "Know thy user" area. The CCALC problem I should have looked at long ago, but until users started using TPU, most VT200 series were set as VT100's. This is because when we bought most of the VT200's, VMS didn't support VT200's. Also I would naively figured that DSD corp. would have mentioned this problem. Now that my flames have cooled to just little sparks of fire, I suppose this all is a result of VMS being very nice to old compiled images. I've gotten a bit lax about checking system depedencies as most images in well-established VMS languages (unfortunately VMS 'C' is not in this group) tend to work just fine across minor and most major system upgrades. Keep 'em flying Chris Lent (203) 452-1522 "The infamous answering machine" (care of) OC.PEDHEM@CU20B.COLUMBIA.EDU or ihnp4!philabs!phri!cooper!chris (cooper's down 'till Jan. 5 though). -------