okinaka@ssc-vax.UUCP (Nathan Okinaka) (01/13/90)
We just upgraded our VAX 11/780 from VMS 4.7 to VMS 5.2 and now our Iris 1200 graphics processor from Silicon Grahpics will not communicate with our VAX. The Iris 1200 is connected to our VAX via ethernet using the XNS protocol. The XNS driver that we have on the VAX is no longer compatible with VMS 5.2 and we do not have the source to recompile and relink the driver. The local sales rep from Silicon Graphics politely said that they do not support the Iris 1200 anymore and I'm essentially out of luck. Is there anyone out there that may have a solution to this problem or have had a similar problem? Nate Okinaka (206)773-2687 The Boeing Company uw-beaver!ssc-bee!okinaka
hascall@cs.iastate.edu (John Hascall) (01/16/90)
(sorry to post, mail is being stupid again) In article <1393> okinaka@ssc-vax.UUCP (Nathan Okinaka) writes: }We just upgraded our VAX 11/780 from VMS 4.7 to VMS 5.2 and now our }Iris 1200 graphics processor from Silicon Grahpics will not communicate }with our VAX. The Iris 1200 is connected to our VAX via ethernet using }the XNS protocol. The XNS driver that we have on the VAX is no longer }compatible with VMS 5.2 and we do not have the source to recompile and }relink the driver. A possible solution is to patch the driver image so that it looks like it was compiled under VMS 5.x. The version number is stored at offset DPT$W_VERSION (x18) in the Driver Prologue Table (which just happens to be the first thing in the driver :-) So what you need to do is: $ patch disk:[dir]xxDRIVER.EXE PATCH> examine/word 18 00000018: 0004 <--- version 4 PATCH> deposit/word 18 = 5 <--- version 5 PATCH> update <--- write file back PATCH> exit and give it a try (might work, might not, depends on if the driver does any VMS 4.x specific things). Best of luck, John Hascall / ISU Comp Ctr
bcw@rti.UUCP (Bruce Wright) (01/17/90)
In article <288@dino.cs.iastate.edu>, hascall@cs.iastate.edu (John Hascall) writes: > A possible solution is to patch the driver image so that it > looks like it was compiled under VMS 5.x. The version number > is stored at offset DPT$W_VERSION (x18) in the Driver Prologue > Table (which just happens to be the first thing in the driver :-) > So what you need to do is: > > [procedure deleted] > > and give it a try (might work, might not, depends on if the > driver does any VMS 4.x specific things). This procedure is HIGHLY unlikely to work - it has about a 99.5% chance of crashing your system. One problem is that VMS V5.0 introduced the modular Executive, and ALL the driver entry point addresses changed (whether they needed to or not), so that they now point into a jump table rather than to the actual routine in the Executive. So all the little routines that drivers are so fond of calling (the EXE$, COM$, and IOC$ routines in particular) are no longer found in the same locations. Another problem is that numerous entry points were REMOVED from VMS V5.0. The functions they performed are now done differently - and the old routines simply don't exist. Yet another problem is that some of the system data structures grew with VMS V5.0, and a driver linked against the old system will refer to offsets whose meanings have changed and expect things like the UCBs to be smaller than they are on V5.0. Since many drives allocate extra space in a UCB extension at the end of their UCBs, this could cause fatal corruption. It's barely possible that there exist drivers which could be patched in this manner, but it's difficult to imagine them performing any useful functions. Don't try the procedure outlined above - it's unlikely to work and at best will probably crash the system; at worst it may cause widespread corruption (which would hopefully not find its way into the file system ...) Bruce C. Wright