On Mon, 20 May 2013 11:23:16 -0400, Brian Schenkenberger, VAXman- wrote:
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.
Yes, it comes from a V8.3 Alpha host with UPDATE-V0800 and SYS-V1000.
image name: "RTPAD"
image file identification: "X-10"
image file build identification: "XBC4-0080060000"
link date/time: 29-JUN-2006 18:18:54.69
linker identification: "A13-03"
image name: "LIBRTL"
image file identification: "X01-001"
image file build identification: "XBCA-0080070005"
link date/time: 15-OCT-2008 13:06:14.43
linker identification: "A13-03"
image name: "LIBOTS"
image file identification: "LIBOTS V1.5-00"
image file build identification: "XBC4-0080060000"
link date/time: 29-JUN-2006 18:16:58.65
linker identification: "A13-03"
Thanks! :)
G.
Johnny Billquist <bqt at softjar.se> writes:
On 2013-05-20 17:01, G. wrote:
Now that there is a TOPS-10 host on HECnet, can some people try at least to
trace on which versions it works and on which it does not?
Thanks to everyone! :)
For what it's worth, both of the addresses I previously identified fell,
according to the RTPAD.MAP, in the CODE and DATA PSECTs of module RSTSRT.
This module:
.TITLE RSTSRT RSTS/E Remote Terminal
So, it makes come sense.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 2013-05-20 17:01, G. wrote:
Now that there is a TOPS-10 host on HECnet, can some people try at least to
trace on which versions it works and on which it does not?
Thanks to everyone! :)
Hum...
.set /host=marley
NCT -- Connection rejected, Node unreachable
NCT -- Control returned to node "MIM "
.ncp tell marley sho exec
NCP -- Show failed, Listener connect failed, node unreachable
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist <bqt at softjar.se> writes:
On 2013-05-20 17:07, Paul_Koning at Dell.com wrote:
On May 20, 2013, at 11:01 AM, G. wrote:
...
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...
Port the Linux one to VMS?
Probably not something I'd recomment... :-)
However, to comment the OP, it definitely sounds like some shared
library issue.
LIBRTL and LIBOTS see to be the only shared libs.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
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.
On 2013-05-20 17:07, Paul_Koning at Dell.com wrote:
On May 20, 2013, at 11:01 AM, G. wrote:
...
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...
Port the Linux one to VMS?
Probably not something I'd recomment... :-)
However, to comment the OP, it definitely sounds like some shared library issue.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On May 20, 2013, at 11:01 AM, G. wrote:
...
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...
Port the Linux one to VMS?
paul
Hello all!
Let's try to summarize the problem.
RTPAD.EXE is the executable image behind SET HOST and SET HOST/APP=R 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=r xxxxxx
| %REM-I-CONNECTION, connection made using RTERM protocol
| %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000052D800008AA4, PC=000052D800008AA4, PS=0000001B
|
| Improperly handled condition, image exit forced.
| Signal arguments: Number = 0000000000000005
| Name = 000000000000000C
| 0000000000010000
| 000052D800008AA4
| 000052D800008AA4
| 000000000000001B
|
| Register dump:
| R0 = 0000000000000003 R1 = 0000000000008F50 R2 = 000000000000813A
| R3 = 0000000000034804 R4 = 000000007FFCF814 R5 = 0000000000009AEF
| R6 = 0000000000000000 R7 = 0000000000000001 R8 = 000000000003481C
| R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
| R12 = 000000007FFCDA98 R13 = 0000000000005170 R14 = 0000000000008E28
| R15 = 0000000000008E28 R16 = 0000000002A83089 R17 = 0000000000200000
| R18 = FFFFFFFF80903360 R19 = 0000000000009ACC R20 = 0000000000000000
| R21 = 00000000000388CB R22 = 000000007AD69A54 R23 = FFFFFFFF801877D0
| R24 = 0000000000000001 R25 = 0000000000000003 R26 = FFFFFFFF8018780C
| R27 = 000000007AD69A54 R28 = 0000000000000006 R29 = 000000007AD69A60
| SP = 000000007AD69A30 PC = 000052D800008AA4 PS = 300000000000001B
(I can obviously provide other data, such as SDA output from process dump, if
needed, or the dump itself in private mail.)
Now that there is a TOPS-10 host on HECnet, can some people try at least to
trace on which versions it works and on which it does not?
Thanks to everyone! :)
G.
I'm trying to build simh (3.9-0) out of ports and it refuses to find
VDE. I *kinda* think it's not looking in /usr/local for it? That's just
a guess. Anyone have any tips for making this work?
-brian
ps: if it doesn't I can live. I figured out what the tap issue was. I
needed to use tap:tap1 instead of just tap1 in the attach xq line.
h vlems <hvlems at zonnet.nl> writes:
<head></head><body data-blackberry-caret-color=3D"#00a8df" style=3D"backgro=
und-color: rgb(255, 255, 255); line-height: initial;"><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif; co=
lor: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255,=
255);">True (about the suits that is). How did your lmf workaround look li=
ke? </div><div style=3D"width: 100%; font-size: initial; font-family: =
Calibri, 'Slate Pro', sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);">Did you replace an RTL function=
or a program that gets interrogated to check whether a license is loaded?<=
/div> =
It looked better than your HTML-fied email. Where's the plain-text part of
your multi-part?
As for the "workaround"... I can not tell a lie, that'd be a lei. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
