G. <gerry77 at mail.com> writes:
On Mon, 20 May 2013 11:51:56 -0400, Brian Schenkenberger, VAXman- wrote:
Were you attempting to RTERM to a TOPS20 system???
=20
That's where that stack dumps seems to be taking me.
No, TOPS-10.
Well, there's no specific TOPS-10 module. I'll assume that the TOPS20 is
also for use when the target is TOPS10.
Wait, when connecting to RSTS/E it changes...
Hmm. Very peculiar.
000052D800008AA4
0000517000008AA4
OK. I have some other work to address but I'll try to look into this some
more later.
If you can go back to plain-vanilla V8.3 (ie. sans any update patches), see
if it occurs there. If it does not, one of the updates has introduced some
incompatibility. It will be much easier to trace down if you can prove and
or disprove this.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On May 20, 2013, at 11:38 AM, G. wrote:
On Mon, 20 May 2013 15:07:28 +0000, <Paul_Koning at Dell.com> wrote:
Port the Linux one to VMS?
Linux speaks RTERM, not only CTERM?! :o
That would be an interesting solution. I didn't know at all that dnprogs now
support RTERM too, and I see that the author is you... :)
Yes, or more precisely, I supplied some of the variants -- RSTS and perhaps one or two others, it's been long enough that I no longer remember.
The comment about ending up in the rtpad RSTS code makes sense. TOPS-10 terminal behavior is quite similar to RSTS, so the same protocol is apparently used by both. The other three flavors are (a) VMS, (b) RSX, and (c) TOPS-20. I forgot what Ultrix used, or Linux when in rtpad mode.
sethost.c, I suppose. At first sight the new dnlogin program appears not to
support RTERM. Am I right?
I don't remember. Perhaps a built option?
paul
On Mon, 20 May 2013 11:51:56 -0400, Brian Schenkenberger, VAXman- wrote:
Were you attempting to RTERM to a TOPS20 system???
That's where that stack dumps seems to be taking me.
I can SET PROC/DUMP and do something with ANA/PROC if needed...
G.
G. <gerry77 at mail.com> writes:
On Mon, 20 May 2013 11:29:28 -0400, Brian Schenkenberger, VAXman- wrote:
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.
So it's not a shared library issue? Anyway, I wonder what got changed in =
such
an old and perhaps not-so-much-used-today module...
Were you attempting to RTERM to a TOPS20 system???
That's where that stack dumps seems to be taking me.
--
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:43, G. wrote:
On Mon, 20 May 2013 11:29:28 -0400, Brian Schenkenberger, VAXman- wrote:
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.
So it's not a shared library issue? Anyway, I wonder what got changed in such
an old and perhaps not-so-much-used-today module...
I would be very surprised if that code have been touched in many years. More likely some corruption of the stack or some data structure. If the same code previously worked, then I'd still start by pointing at some shared library, but there might also be common data with other parts of RTPAD, which have been changed, while the RSTSRT piece was not.
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 Mon, 20 May 2013 11:41:07 -0400, Brian Schenkenberger, VAXman- wrote:
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"
Excellent. This is unscathed (ie. no patchin). The link date in the source
listing is: 29-JUN-2006 18:18
The only recent patch to RTPAD was in V7.3 for an unrelated problem.
BTW, I tried both 7.3 images too, and they do not work...
G.
On Mon, 20 May 2013 11:29:28 -0400, Brian Schenkenberger, VAXman- wrote:
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.
So it's not a shared library issue? Anyway, I wonder what got changed in such
an old and perhaps not-so-much-used-today module...
G.
G. <gerry77 at mail.com> writes:
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"
Excellent. This is unscathed (ie. no patchin). The link date in the source
listing is: 29-JUN-2006 18:18
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Mon, 20 May 2013 15:07:28 +0000, <Paul_Koning at Dell.com> wrote:
Port the Linux one to VMS?
Linux speaks RTERM, not only CTERM?! :o
That would be an interesting solution. I didn't know at all that dnprogs now
support RTERM too, and I see that the author is you... :)
sethost.c, I suppose. At first sight the new dnlogin program appears not to
support RTERM. Am I right?
G.
