[HECnet] Call for help to debug RTPAD.EXE on OpenVMS V8.3

G. <gerry77 at mail.com> writes: Hello all! Let's try to summarize the problem. RTPAD.EXE is the executable image behind SET HOST and SET HOST/APP=3DR on= VMS, and it can use both CTERM and RTERM protocols to connect to remote = systems. Some older OSes, notably TOPS-10 and RSTS (and others, I suppose), do = either behave badly when accessed with the newer CTERM protocol, mainly because = it's too VMS-centric, or do not work at all because they do not suppport it. = To connect to them, the solution is to always use the older RTERM protocol. RTPAD.EXE on OpenVMS V8.3 for both Alpha and Itanium (IIRC) has some = serious bug that prevents it from connecting to such older OSes using the old = RTERM protocol: actually it ACCVIOs before doing any useful work. The RTERM protocol can be used to connect to VMS too, and when connecting= to another VMS node using RTERM, the V8.3 RTPAD.EXE works as expected. So, = either some older OSes are sending out-of-standard packets (and the older = RTPAD.EXE were more forgiving), or the new RTPAD.EXE cannot understand all the = protocol variants and intricacies (as the older versions did). I tried exchanging V8.3 RTPAD.EXE (ident X-10) with a couple of older = versions (idents X-8, X-9) and even with the V8.4 one (ident X-10 too, so should = be the same as V8.3), to no avail: every one of them ACCVIOs as well. The oldest= I tried (X-8) comes from plain vanilla V7.2 (and does not work), but I'm = almost sure (I cannot swear on it, though) that RTERM worked fine in V7.2, so = I'm stuck: the same image (X-8) was working on V7.2 but it's not in V8.3. I know that testing by exchanging images among different VMS versions is = not bulletproof, but considering that I didn't get any error like SHRIDMISMAT= and such, I feel confident about thinking that they are compatible. So maybe = the problem is somewhere else, probably in some shared library. What else can I do? Is there anyone with the right knowledge (I'm = thinking to e.g. Brian Schenkenberger) that can try to track down the bug and at = least identify in which part of VMS lies the problem? Or give me some = suggestions... This is what happens: | $ set host/app=3Dr xxxxxx | %REM-I-CONNECTION, connection made using RTERM protocol |=A0%SYSTEM-F-ACCVIO,=A0access=A0violation,=A0reason=A0mask=3D00,=A0virtu= al=A0address=3D000052D800008AA4,=A0PC=3D000052D800008AA4,=A0PS=3D0000001B |=20 | Improperly handled condition, image exit forced. | Signal arguments: Number =3D 0000000000000005 | Name =3D 000000000000000C | 0000000000010000 | 000052D800008AA4 ------------------------------------^v^v^v^v^v^v^v^v | 000052D800008AA4 | 000000000000001B This looks bad. I can tell you that it's not very likely a problem VMS address which RTPAD is operating in. I suspect that 0000000000008AA4 would be close to the PC in the RTPAD image or 0000000000052D8. I would guess that some improper stack manipulation is the cause for this error. If this stack dump came from V8.3, I'll take a look in the source to see if the addresses yield anything. Please confirm that the above was from the Alpha V8.3 RTPAD. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.