Title: | VAX and Alpha VMS |
Notice: | This is a new VMSnotes, please read note 2.1 |
Moderator: | VAXAXP::BERNARDO |
Created: | Wed Jan 22 1997 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 703 |
Total number of notes: | 3722 |
I have a customer who gets an odd response from the F$GETSYI("VERSION") lexical on his 6.2 VAX system. He sees V6.2.... in SYS.EXE rather than V6.2 (padded with spaces). My 6.2 system looks fine. The only difference that he noted is that his sys.exe image is patched due to a CWSERR bugcheck problem. Is it possible that this patch also put in 000000 rather than 202020 in SYS.EXE at the version location. Thanks- Laurie Customer's sys.exe: Dump of file SYS$COMMON:[SYS$LDR]SYS.EXE;4 on 4-JUN-1997 07:22:47.78 File ID (19506,141,0) End of file block 90 / Allocated 92 Virtual block number 36 (00000024), 512 (0200) bytes 80004408 80004408 80004400 80004400 .D...D...D...D.. 000000 00000000 00000000 00000000 00000000 ................ 000010 00000000 00000000 00000000 00000000 ................ 000020 00000000 00000000 00000000 00000000 ................ 000030 4B373658 00000000 00000000 00000000 ............X67K 000040 00989C93 15CE8000 00989C93 15CE8000 ..�.......�..... 000050 00000000 000186A0 00000000 00000000 ................ 000060 00000000 00000000 000186A0 00000000 ................ 000070 0000FFFF 0000FFFF 0000FFFF 00000000 ................ 000080 0000FFFF 0000FFFF 0000FFFF 0000FFFF ................ 000090 00000000 00000000 0000FFFF 0000FFFF ................ 0000A0 00000000 322E3656 00000000 00000000 ........V6.2.... 0000B0 Dump from my V6.2 system: $dump/block=(start:36,end:36) sys$loadable_images:sys.exe Virtual block number 36 (00000024), 512 (0200) bytes 80004408 80004408 80004400 80004400 .D...D...D...D.. 000000 00000000 00000000 00000000 00000000 ................ 000010 00000000 00000000 00000000 00000000 ................ 000020 00000000 00000000 00000000 00000000 ................ 000030 4B373658 00000000 00000000 00000000 ............X67K 000040 00989C93 15CE8000 00989C93 15CE8000 ..�.......�..... 000050 00000000 000186A0 00000000 00000000 ................ 000060 00000000 00000000 000186A0 00000000 ................ 000070 0000FFFF 0000FFFF 0000FFFF 00000000 ................ 000080 0000FFFF 0000FFFF 0000FFFF 0000FFFF ................ 000090 00000000 00000000 0000FFFF 0000FFFF ................ 0000A0 20202020 322E3656 00000000 00000000 ........V6.2 0000B0
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
698.1 | Patching the SYS.EXE Version String... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Jun 05 1997 18:46 | 37 |
Looks like either a broken ECO kit was applied, or somebody has been playing around with the PATCH tool. I'd see what ECOs have been applied, to see if this is a problem with a DIGITAL ECO kit... As a fix, patch in the correct value. The version string is located at SYS$GQ_VERSION -- that is 800044B8 for most (all?) V6.x vintage systems. (See SYS$SYSTEM:SYS.MAP...) Before performing the following steps, make *certain* you have a way to restore a current /IMAGE copy of this system disk, or that you have another OpenVMS VAX system (or system disk you can boot from) available, as if the following procedure (or you) mess up, your system may end up being unbootable... $ set default SYS$COMMON:[SYS$LDR] $ copy SYS.EXE SYS.EXE_IN-CASE-I-FAIL $ patch SYS.EXE define sys$gq_version=800044b8 set mode ascii !examine sys$gq_version !examine sys$gq_version+4 deposit sys$gq_version = "V6.2" deposit sys$gq_version+4 = " " update exit $ Exit One could also switch over to the REPLACE command, or one could manually verify the old contents *before* performing the DEPOSIT, via a command such as EXAMINE. When you next reboot, you will (hopefully) have the version string problem corrected. |