From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 19-MAY-1989 08:46
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Yet another trick in migrating from VMS 4.7 to 5.1

Message-Id:  <8905191216.AA26616@crdgw1.ge.com>
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Fri, 19 MAY 89 04:51:48 PDT
Received: from RELAY.CS.NET by KL.SRI.COM with TCP; Fri, 19 May 89 04:27:47 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae23978; 19 May 89 7:27 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ae10361; 19 May 89 7:26 EDT
Date: Fri, 19 May 89 06:49 EST
From: "Claude Barbe - SDR - (203) 431 5524" <BARBE%sdr.slb.com@RELAY.CS.NET>
Subject: Yet another trick in migrating from VMS 4.7 to 5.1
To: INFO-VAX@KL.SRI.COM
X-Vms-To: IN::KL.SRI.COM::INFO-VAX, BARBE

Having stopped paying for support months ago for a major DBMS package we 
were not too much surprised to see it unusable when migrating to VMS 5.0.
The diagnoctics were simply a couple of IDENT MISMATCH when trying to start
the package up with commands like INSTALL SYS_xxxxx:[xxxxxx]IISYSSERV/HEADER.

This package comes in .EXE form, so there was no hope that reLINKing would
help.

Being confident that from an application view point VMS 5.0 was not that
different from 4.7, we decided to try the module anyway by patching the most
obvious.  So here it goes:

	$ ANAL /IMAG xxxxxxx.exe told us that GLOBAL SECTION MAJOR ID X03
							   MINOR ID X01

	while typical VMS 5.0 libraries (ie UISSHR) were MAJOR X04, MINOR X00

	$ DUMP/BLOC=END=1 let us find a 01000003 at byte position 24

	so
	$ PATC/ABSO xxxxxxx.EXE 
	PATCH> DEP 24=00000004
	PATCH> UPDATE

	And INSTALL was happy thereafter

	Since in that case xxxxxxx.EXE was a sharable library called for by
	another image, the said image complained in turn at run time that
	there was another IDENT MISDMATCH.

	$ ANAL /IMAG iiiiiii.exe showed that it expected xxxxxxx to be with
	  MAJOR ID X03 / MINOR ID X01.

	Another DUMP/BLOC=END=2 and PATCH/ABSOL to put 00000004 where 01000003
	used to be and everyone was happy.

	The package was running under VMS 5.1 after 2 hours and changing two
	long words among thousand of blocks of .EXE files.

I don't care for the DBMS package, but found the idea and results worth posting!

Well, it worked for us, meaning that some code may look like system dependant
but in fact not all internal/interface structures of VMS 5.0 changed in such a
dramatic way as to require a recompilation and a relink in all cases.

Claude