HECnet

hecnet@lists.dfupdate.se

15562 discussions

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

by Paul_Koning＠Dell.com

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

12 years, 1 month

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

by gerry77＠mail.com

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.

12 years, 1 month

FreeBSD, SIMH and VDE

by wonko＠4amlunch.net

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.

12 years, 1 month

Need VMS VAX ISO

by system＠TMESIS.COM

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.

12 years, 1 month

Need VMS VAX ISO

by hvlems＠zonnet.nl

I should have used 'if' not 'when', Dave Van: Dave McGuire Verzonden: zondag 19 mei 2013 22:52 PM Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Need VMS VAX ISO On 05/19/2013 08:51 PM, h vlems wrote: > When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be > able to help us out! Have there been any indications of that happening? Besides, PAK generators have been floating around since the dawn of time. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 1 month

Need VMS VAX ISO

by hvlems＠zonnet.nl

Ah, now that is a familiar symptom... Van: Dave McGuire Verzonden: maandag 20 mei 2013 00:18 PM Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Need VMS VAX ISO On 05/19/2013 06:15 PM, Brian Schenkenberger, VAXman- wrote: >> It may be related to distrust of the Suits at Big Companies. > > In this case, size doesn't matter. Suits are never to be trusted! 100% with you on that. I still wince every time I sit down. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 1 month

Need VMS VAX ISO

by hvlems＠zonnet.nl

True (about the suits that is). How did your lmf workaround look like? Did you replace an RTL function or a program that gets interrogated to check whether a license is loaded? Van: Brian Schenkenberger, VAXman- Verzonden: maandag 20 mei 2013 00:15 PM Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Need VMS VAX ISO "Cory Smelosky" <b4 at gewt.net> writes: >It may be related to distrust of the Suits at Big Companies. In this case, size doesn't matter. Suits are never to be trusted! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 1 month

Need VMS VAX ISO

by b4＠gewt.net

On Mon, 20 May 2013, h vlems wrote: The background for my remark: there used to be a tru64 hobbyist program. Not free, $200 IIRC. It no longer exists. The same may happen to VMS. I still use VMS in a productive way, e.g. checking C programs that run on other platforms. I just don't trust HP, is all. Hans I don't trust HP either... The definition of a pessimist: a realist.... Van: Brian Schenkenberger, VAXman- Verzonden: zondag 19 mei 2013 23:41 PM Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Need VMS VAX ISO Dave McGuire <mcguire at neurotica.com> writes: >On 05/19/2013 08:51 PM, h vlems wrote: >> When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be >> able to help us out! > > Have there been any indications of that happening? Like I just said, the negativity in this space never ceases to amaze me. > Besides, PAK generators have been floating around since the dawn of time. You don't even need that. The LMF is surprisingly simple to circumvent. I was able to disable it within about 5 mins. of first booting VMS V5.0 here. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity. -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments

12 years, 1 month

Need VMS VAX ISO

by hvlems＠zonnet.nl

The background for my remark: there used to be a tru64 hobbyist program. Not free, $200 IIRC. It no longer exists. The same may happen to VMS. I still use VMS in a productive way, e.g. checking C programs that run on other platforms. I just don't trust HP, is all. Hans The definition of a pessimist: a realist.... Van: Brian Schenkenberger, VAXman- Verzonden: zondag 19 mei 2013 23:41 PM Aan: hecnet at Update.UU.SE Beantwoorden: hecnet at Update.UU.SE Onderwerp: Re: [HECnet] Need VMS VAX ISO Dave McGuire <mcguire at neurotica.com> writes: >On 05/19/2013 08:51 PM, h vlems wrote: >> When HP pulls the plug on the hobbyist scheme, or VMS, I hope you will be >> able to help us out! > > Have there been any indications of that happening? Like I just said, the negativity in this space never ceases to amaze me. > Besides, PAK generators have been floating around since the dawn of time. You don't even need that. The LMF is surprisingly simple to circumvent. I was able to disable it within about 5 mins. of first booting VMS V5.0 here. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

12 years, 1 month

Another sillyness. More information in the nodename database on MIM.

by mholmes10＠hotmail.com

My info for area 39 39.1 MASON AlphaServer 800 5/333 VMS 8.3 39.10 ROXY DEC 3000-300X VMS 7.2-1 Soon to be online after disk and fan upgrade. 39.11 BOSCO MULTIA VX40 VMS 7.2-1 Location : Alexandria, VA (Washington DC metro area) USA

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet