Hi Folks,
I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an HP=
64700 Emulator via Ethernet. The command Adaw workbench probe crashs with t=
he following info on the vax: "System-f-ACCVIO, access violation, reason ma=
sk=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4". It then d=
oes a callstack dump.

Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ago?

Thanks,
Vic

AlsysQ wrote 2012-07-20 21:18:
> Hi Folks, I am trying to get AdaProbe to running on a VMS/VAX 6.2...

Is this some software specificaly for OpenVMS ?
Or are you porting something to OpenVMS ?
Link(s) to whatever you are using will, as usualy, help.


> to
> connect to an HP64700 Emulator via Ethernet. The command Adaw workbench
> probe crashs with the following info on the vax: "System-f-ACCVIO,
> access violation, reason mask=00, virtual address=000004, PC=008613E,
> PSL=03c000A4". It then does a callstack dump.
>
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years
> ago?
>
> Thanks, Vic
>

AlsysQ wrote 2012-07-20 21:18:
> Hi Folks, I am trying to get AdaProbe to running on a VMS/VAX 6.2 to
> connect to an HP64700 Emulator via Ethernet. The command Adaw workbench
> probe crashs with the following info on the vax: "System-f-ACCVIO,
> access violation, reason mask=00, virtual address=000004, PC=008613E,
> PSL=03c000A4". It then does a callstack dump.
>
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years
> ago?
>
> Thanks, Vic
>

I also noticed that this patch-readme mentions HP 64700 :

ftp://ftp.aonix.com/pub/adats/outgoing/0079/5.5.2/U1/0079V552-U1.README

I have no idea if it is related...

On Friday, July 20, 2012 2:25:43 PM UTC-5, Jan-Erik Soderholm wrote:
> AlsysQ wrote 2012-07-20 21:18:
> > Hi Folks, I am trying to get AdaProbe to running on a VMS/VAX 6.2...
> 
> Is this some software specificaly for OpenVMS ?
> Or are you porting something to OpenVMS ?
> Link(s) to whatever you are using will, as usualy, help.
> 
> 
> > to
> > connect to an HP64700 Emulator via Ethernet. The command Adaw workbench
> > probe crashs with the following info on the vax: "System-f-ACCVIO,
> > access violation, reason mask=00, virtual address=000004, PC=008613E,
> > PSL=03c000A4". It then does a callstack dump.
> >
> > Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years
> > ago?
> >
> > Thanks, Vic
> >

Hi Jan,
This software runs on the VAX. Its a symbolic debugging tool for Ada 83 programmming language.

On Friday, July 20, 2012 2:27:54 PM UTC-5, Jan-Erik Soderholm wrote:
> AlsysQ wrote 2012-07-20 21:18:
> > Hi Folks, I am trying to get AdaProbe to running on a VMS/VAX 6.2 to
> > connect to an HP64700 Emulator via Ethernet. The command Adaw workbe=
nch
> > probe crashs with the following info on the vax: "System-f-ACCV=
IO,
> > access violation, reason mask=3D00, virtual address=3D000004, PC=3D0=
08613E,
> > PSL=3D03c000A4". It then does a callstack dump.
> >
> > Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 yea=
rs
> > ago?
> >
> > Thanks, Vic
> >
>=20
> I also noticed that this patch-readme mentions HP 64700 :
>=20
> ftp://ftp.aonix.com/pub/adats/outgoing/0079/5.5.2/U1/0079V552-U1.README
>=20
> I have no idea if it is related...

Thanks Jan,
This is not quite related, but also interesting though. One of the problems=
 is that the documents says we should use Wollongong TCPIP package for vms =
5.2 version when using the ethernet, but we are using vms 6.2 and i am able=
 to telnet so i don't think i need the wollongong package. One big question=
 is that after adaprobe is installed should it be able to run with the emul=
ator without any user application downloaded on to the eumlator. Such as mo=
st debuggers will come up and then the user can load their code???
Vic

On Friday, July 20, 2012 2:18:27 PM UTC-5, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, re=
ason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4&quot=
;. It then does a callstack dump.
>=20
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>=20
> Thanks,
> Vic



On Friday, July 20, 2012 2:18:27 PM UTC-5, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, re=
ason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4&quot=
;. It then does a callstack dump.
>=20
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>=20
> Thanks,
> Vic



On Friday, July 20, 2012 2:18:27 PM UTC-5, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, re=
ason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4&quot=
;. It then does a callstack dump.
>=20
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>=20
> Thanks,
> Vic



On Friday, July 20, 2012 2:18:27 PM UTC-5, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, re=
ason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4&quot=
;. It then does a callstack dump.
>=20
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>=20
> Thanks,
> Vic



On Friday, July 20, 2012 2:18:27 PM UTC-5, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, re=
ason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4&quot=
;. It then does a callstack dump.
>=20
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>=20
> Thanks,
> Vic

AlsysQ wrote 2012-07-20 21:54:
> On Friday, July 20, 2012 2:27:54 PM UTC-5, Jan-Erik Soderholm wrote:
>> AlsysQ wrote 2012-07-20 21:18: > Hi Folks, I am trying to get
>> AdaProbe to running on a VMS/VAX 6.2 to > connect to an HP64700
>> Emulator via Ethernet. The command Adaw workbench > probe crashs
>> with the following info on the vax: "System-f-ACCVIO, > access
>> violation, reason mask=00, virtual address=000004, PC=008613E, >
>> PSL=03c000A4". It then does a callstack dump. > > Anyone
>> familiar with Alsys and/or Adaprobe, HP emulators from 20 years >
>> ago? > > Thanks, Vic >
>>
>> I also noticed that this patch-readme mentions HP 64700 :
>>
>> ftp://ftp.aonix.com/pub/adats/outgoing/0079/5.5.2/U1/0079V552-U1.README
>>
>>
>>
I have no idea if it is related...
>
> Thanks Jan, This is not quite related, but also interesting though. One
> of the problems is that the documents says we should use Wollongong
> TCPIP package for vms 5.2 version when using the ethernet,

OK. I'm not sure how VMS knowlegable you are :-) but Wollongong was one
TCPIP package available for VMS (before it was called OpenVMS :-) ).
It is/was probably one of the oldest TCPIP packages, possibly
before there was a usable TCPIP product from Digital.

If there wasn't some specific binding to the Wollongong product,
it should work with any IP package, I guess.

If you can telnet *to* the VMS system, you obviously have
a telnet server running. If that is in any way related to
any possible needs from the specific softare is unknown.


> but we are
> using vms 6.2 and i am able to telnet so i don't think i need the
> wollongong package. One big question is that after adaprobe is installed
> should it be able to run with the emulator without any user application
> downloaded on to the eumlator. Such as most debuggers will come up and
> then the user can load their code??? Vic
>

Have you ever used this software (on VMS) ?
Was Adaprobe installed right now (reasently) ?

Have you used the same product on any other plattform ?
That is, are you familiar with the software product as such ?

Maybe you should post a cut-n-paste where the actual command
is shown and the full output incl the callstack dump. That could
point to wheither it crashes within Adaprobe or in some other
component of VMS.

If you are running TCPIP/Services you could also post the
output of $ TCPIP SHOW VERSION. On later TCPIP/VMS versions
it looks something like :

$ tcpip show version

   HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 3
   on an AlphaServer DS25 running OpenVMS V8.4

$

Post your output (if any :-) ).

On Fri, 20 Jul 2012 12:54:04 -0700, AlsysQ wrote:

>  One of the
> problems is that the documents says we should use Wollongong TCPIP
> package for vms 5.2 version when using the ethernet, but we are using
> vms 6.2 and i am able to telnet so i don't think i need the wollongong
> package. One big question is that after adaprobe is installed should it
> be able to run with the emulator without any user application downloaded
> on to the eumlator. Such as most debuggers will come up and then the
> user can load their code???

Wollongong disappeared many years ago, though IIRC it was mentioned in 
the VMS V6.2 documentation as an alternative to DEC's own UCX package 
(later known at TCP/IP Services for OpenVMS). Multinet and TCPware were 
also mentioned, again IIRC and these are now both supplied by Process 
Software.

Various software packages contain components specific to the TCP/IP stack 
you are using.  Does the AdaProbe documentation offer support for 
alternatives to Wollongong?

$ SHOW NETWORK

will tell you which TCP/IP stack you are using.

What advantages does AdaProbe offer over the standard VMS debugger for 
Ada?  I personally found the VMS debugger quite competent for use with 
Ada.

-- 
Paul Sture

On 2012-07-21, Paul Sture <paul@sture.ch> wrote:
> On Fri, 20 Jul 2012 12:54:04 -0700, AlsysQ wrote:
>
>>  One of the
>> problems is that the documents says we should use Wollongong TCPIP
>> package for vms 5.2 version when using the ethernet, but we are using
>> vms 6.2 and i am able to telnet so i don't think i need the wollongong
>> package. One big question is that after adaprobe is installed should it
>> be able to run with the emulator without any user application downloaded
>> on to the eumlator. Such as most debuggers will come up and then the
>> user can load their code???
>

All the use of telnet proves here is that you have network connectivity.

If the binaries you are using have been compiled against Wollongong that
may force the use of that specific stack if the program is using a
Wollongong specific API.

>
> Various software packages contain components specific to the TCP/IP stack 
> you are using.  Does the AdaProbe documentation offer support for 
> alternatives to Wollongong?
>
> $ SHOW NETWORK
>
> will tell you which TCP/IP stack you are using.
>

Did that work for the TCP/IP stacks which ran on V6.2 era VMS ?

To the OP: if the command doesn't work (and I cannot remember when the
TCP/IP stacks started integrating with it), try "ucx show ver" (for UCX)
or "multi show" for Multinet.

> What advantages does AdaProbe offer over the standard VMS debugger for 
> Ada?  I personally found the VMS debugger quite competent for use with 
> Ada.
>

Notice the OP talks about connecting to a network based emulator and is
not talking about debugging code running on the same system as the
debugger.

I never heard of either AdaProbe or the emulator mentioned so I went
looking. The emulator appears to be a in-circuit emulator for Motorola
68020/68030 class processors. As far as I can tell, the OP is using
a debugger client running on VMS to debug code over a network link
running on a completely different class of processor.

[A more modern example of this setup would be using a cross-compiled gdb
running on a Linux x86 box to debug code running on a ARM/Freescale/whatever
board connected to the Linux box over a JTAG (or Ethernet) link.]

As far as I know, the VMS debugger simply does not have the ability to
work in this way. As VMS is been used as a client here, the VMS debugger
client/server option is not applicable and even if one were to try to use
the VMS PC based client directly, it would need to speak whatever
over-the-wire debugging protocol is in use here as well as support
the architecture and board in question.

I had a look to see how VAXELN handled this and it appears when debugging
was done in a VAXELN setup, it seems to have been done using a dedicated
VMS hosted debugging client in much the same way as the OP is trying to
make work.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 07/20/12 19:18, AlsysQ wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with the following info on the vax: "System-f-ACCVIO, access violation, reason mask=00, virtual address=000004, PC=008613E, PSL=03c000A4". It then does a callstack dump.
>
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ago?
>
> Thanks,
> Vic

I found the 64000/64700 series development systems in a 1989 hp catalog and
there's no mention of AdaProbe. The 64702 is a standalone emulator with
logic analyser capabilities. It looks like it has a dedicated interface to
the development host, which can be vax, pc, or hp9000/300 series running 
hp/ux.
 From this, I can't see where the AdaProbe fits in and it may be that you
have a variety of hardware and software which isn't compatable. Just what is
overall systems layout, from dev host to target hardware ?.

It would be usefull to know if this effort is for maintenance of some old
system, or just out of interest. Also, what the target cpu is and what 
format
the sources are in. Trying to get old kit like that working can be a real
trial, even if you have all the docs and software and it's often easier to
buy new hardware and translate the old sources to something that more modern
systems understand. If it's avionics or related work, you have also the
problem of how the modified software is verified for approvals, which have
become far more stringent over the intervening years...

Regards,

Chris

On 07/21/12 16:06, ChrisQ wrote:
> On 07/20/12 19:18, AlsysQ wrote:
>> Hi Folks,
>> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to
>> an HP64700 Emulator via Ethernet. The command Adaw workbench probe
>> crashs with the following info on the vax: "System-f-ACCVIO, access
>> violation, reason mask=00, virtual address=000004, PC=008613E,
>> PSL=03c000A4". It then does a callstack dump.
>>
>> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years
>> ago?
>>
>> Thanks,
>> Vic
>

Digging a bit more, found pics of the 64700 series at the Hp Computer
Museum, under peripherals, but there's no network connector, which is
what one would expect for 1985 vintage kit. Just how is this connecting
via the network ?...

Regards,

Chris

On 2012-07-21 16:53:26 +0000, ChrisQ said:

> On 07/21/12 16:06, ChrisQ wrote:
>> On 07/20/12 19:18, AlsysQ wrote:
>>> Hi Folks,
>>> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to
>>> an HP64700 Emulator via Ethernet. The command Adaw workbench probe
>>> crashs with the following info on the vax: "System-f-ACCVIO, access
>>> violation, reason mask=00, virtual address=000004, PC=008613E,
>>> PSL=03c000A4". It then does a callstack dump.
>>> 
>>> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years
>>> ago?
>>> 
>>> Thanks,
>>> Vic
>> 
> 
> Digging a bit more, found pics of the 64700 series at the Hp Computer
> Museum, under peripherals, but there's no network connector, which is
> what one would expect for 1985 vintage kit. Just how is this connecting
> via the network ?...


Agilent (the spin-off containing HP's test and measurement folks) has 
the <http://cp.literature.agilent.com/litweb/pdf/5091-3930E.pdf> intro 
posted, including part numbers for software.  And yes, the HP 64700 
series systems can have a LAN interface.


-- 
Pure Personal Opinion | HoffmanLabs LLC

> [...] One of the problems is that the documents says we
> should use Wollongong TCPIP package for vms 5.2 version when
> using the ethernet, but we are using vms 6.2 and i am able to
> telnet so i don't think i need the wollongong package.
> [...]

   I'd say that one of the problems is that only one of us
can see "the documents", and with that explanation, I can't
tell who needs what where or why.  Also, "Ethernet" and
"Telnet" are spelled differently for a reason.

> [...] "System-f-ACCVIO, access violation, reason mask=00,
> virtual address=000004, PC=008613E, PSL=03c000A4". It then
> does a callstack dump.

   Many things can cause an ACCVIO, and the invisible
traceback also tells me nothing.

> Wollongong disappeared many years ago, [...]

   Its last known home was Attachmate.  But I see no real
evidence that any networking software was at fault here.  Or
am I missing something obvious?

On 2012-07-21, Steven Schweda <sms.antinode@gmail.com> wrote:
>    Its last known home was Attachmate.  But I see no real
> evidence that any networking software was at fault here.  Or
> am I missing something obvious?

Based on the limited information we have so far, my guess is that the
OP's debugger binaries have been statically linked (static because
otherwise it would be a image activation problem) with the Wollongong
stack and that said code is not cleanly handling the case when it's
run on a system without this stack installed.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 07/21/12 17:15, Stephen Hoffman wrote:

>
>
> Agilent (the spin-off containing HP's test and measurement folks) has
> the <http://cp.literature.agilent.com/litweb/pdf/5091-3930E.pdf> intro
> posted, including part numbers for software. And yes, the HP 64700
> series systems can have a LAN interface.
>
>

Looks like it did have a lan option, but this was quite unusual for
embedded system development at the time. HP instrument division were
always ahead of the curve, but expensive. The 64000 system cost 50k per
seat at late eighties prices, which made it a very high end solution.
Mere mortals had to make do with ribbon cable / emulator direct from
the host to the target. The first time I used network based debug was
around 1995, with Microtek Masterworks at the host end and Vxworks
at the target.

TCP/IP options were very limited on vms. We used Wollongong on
several microvaxen and it was always a bit flaky compared to out of the
box networking on Sun and Hp workstations. IIrc, the vms versions at the
time were 4.7-5.4, running on Microvax II and II GPX machines. If I were
trying to get such a a system running, I might try one of those versions
of vms, where it's known to work. There are other problems that can cause
wobblies, such with deqna boards locking up, or even crashing the system.
The later delqa seemed more robust...

Regards,

Chris

> [...] my guess is [...]

   It's not implausible, but actual evidence remains sparse.
My dim recollection suggests that there was a TWGLIB.EXE and
a TWGLIB.OLB.

   It might be worth searching the relevant executable(s) for, say,
"TWG", or other suggestive strings.

   I have an Attachmate PathWay 3.0 kit from 1997 on CD-ROM
(and I might have a TK50 somewhere which is even older, but
no bets on that).  The 3.0 kit claims suitability for VMS VAX
V5.3 or higher, but getting the stuff to run without an
official Authorization Number from the vendor may be
difficult.

> [...] We used Wollongong on
> several microvaxen and it was always a bit flaky compared to
> out of the box networking on Sun and Hp workstations. [...]

   Perhaps, but, in that time frame, it was always more than a
bit better than the VMS-Ultrix Connection (UCX), in that it
was not entirely useless.

> [...] If I were
> trying to get such a a system running, I might try one of
> those versions [...]

   If I were serious about trying to get such a a system
running, then I'd start with versions of everything which
were known to work together.  An image backup of an old,
known-working system might be a good start.

On Jul 20, 8:18=A0pm, AlsysQ <blackware...@gmail.com> wrote:
> Hi Folks,
> I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect to an =
HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs with=
 the following info on the vax: "System-f-ACCVIO, access violation, reason =
mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4". It then=
 does a callstack dump.
>
> Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 years ag=
o?
>
> Thanks,
> Vic


For Vic, Paul, Chris, and others.

1) Alsys vs DEC Ada vs XD Ada

The DEC Ada debugger, and the VAX Ada front end, were two of the main
selling points behind XD Ada, a VMS-hosted compiler targetting a few
embedded-Ada targets including some flavours of M68K, with SD Scicon
providing the target-side stuff, including connectitvity direct from
VAX Debug (as it then was) to relevant target runtimes. XD Ada lives
on, on Alpha and IA64 too apparently, and via a rather circuitous
route is now nominally looked after by HP. Like many similar products
the current price reflects its limited market then and now.

Alsys apparently took a different approach, relying on an "industry
standard" logic analyser/emulator from HP to provide the target-side
connectivity, and then accessing the HP box via a LAN from a VMS-
hosted application (not one I know personally).


2a) Smart Questions

There is nothing like enough info here to make an informed comment on
what might be broken. More info is needed, even in simple cases.

2b) Wollongong

There is extensive mention of Wollongong in the resulting discussion,
fair enough, but is there any actual evidence that it is relevant?

VMS has commands such as ANALYZE /IMAGE which may sometimes be helpful
in deterrmining the libraries used by a given executable image (eg
Wollongong or whatever). A decent VMS person will know how to use
these facilities, they won't need to be [and probably won't be] an
Alsys expert. A decent VMS person will also know how to look at
network setups and network activity.

2c) Usual questions which need answering.

Has anything like this Alsys/VMS setup ever worked, for anybody? [In
the early era of the HP 64000, I had access to its Tektronix
competitor, an 85xx emulator/analyser. At that time, the 85xx
diagnostics were broken, as confirmed by Tek tech support. Someone
attempting to revive that setup and using the diagnostics would see
the diagnostics fail and conclude that something was broken. That
conclusion would probably be wrong. The equipment worked, the diags
were broken]

So, has this particular setup ever worked, either in the organisation
currently trying it or elsewhere?

Is anybody still around that remembers it either working or not
working, in this setup or elsewhere?

If it ever worked, what (other than the date, the users, etc) might
have changed since then?

What, exactly, is the user actually trying to do (presumably with
Adaprobe) at the time of the ACCVIO?

What is the Adaprobe application, and underneath it, the VMS system,
actually trying to do at the time of the ACCVIO? (If appropriate, run
from a privileged account and use $ SET WATCH FILE/CLASS=3DMAJOR to see
some indication of what files are being accessed, no guarantees this
will help).

Are relevant aspects of the HP 64000 known to be working OK (eg can it
co-operate relevantly and successfully with other devices on the LAN)?

Are relevant aspects of the VAX known to be working OK (eg can it co-
operate relevantly and successfully with other devices on the LAN)?
[Telnet may or may not be relevant

And once these are answered there WILL be more to follow.


3) Way forward

A quick look at Wikipedia says that some relevant Alsys assets and
knowledge may have ended up with Atego, who do still trade, though
whether they can offer relevant expertise is a different question.

The limited market for this kind of product and in particular for this
combination of products may mean that a significant part of the
approach for fixing this particular situation is via a more generic
approach using a knowledgeable computer bod from the era (a computer
paleontologist? I have seen, but cannot remember, better names) rather
than Alsys experts or HP64K experts.

Where, geographically, is this kit, and does access to it require any
particular security clearances? This task isn't particularly likely to
be amenable to remote support, although the VMS-specifics might be.

That'll have to do for now, the sun shines and the garden awaits.

Best of luck.

On Sunday, July 22, 2012 7:07:50 AM UTC-5, John Wallace wrote:
> On Jul 20, 8:18=A0pm, AlsysQ <blackware...@gmail.com> wrote:
> > Hi Folks,
> > I am trying to get AdaProbe to running on a VMS/VAX 6.2 to connect t=
o an HP64700 Emulator via Ethernet. The command Adaw workbench probe crashs=
 with the following info on the vax: "System-f-ACCVIO, access violatio=
n, reason mask=3D00, virtual address=3D000004, PC=3D008613E, PSL=3D03c000A4=
". It then does a callstack dump.
> >
> > Anyone familiar with Alsys and/or Adaprobe, HP emulators from 20 yea=
rs ago?
> >
> > Thanks,
> > Vic
>=20
>=20
> For Vic, Paul, Chris, and others.
>=20
> 1) Alsys vs DEC Ada vs XD Ada
>=20
> The DEC Ada debugger, and the VAX Ada front end, were two of the main
> selling points behind XD Ada, a VMS-hosted compiler targetting a few
> embedded-Ada targets including some flavours of M68K, with SD Scicon
> providing the target-side stuff, including connectitvity direct from
> VAX Debug (as it then was) to relevant target runtimes. XD Ada lives
> on, on Alpha and IA64 too apparently, and via a rather circuitous
> route is now nominally looked after by HP. Like many similar products
> the current price reflects its limited market then and now.
>=20
> Alsys apparently took a different approach, relying on an "industry
> standard" logic analyser/emulator from HP to provide the target-side
> connectivity, and then accessing the HP box via a LAN from a VMS-
> hosted application (not one I know personally).
>=20
>=20
> 2a) Smart Questions
>=20
> There is nothing like enough info here to make an informed comment on
> what might be broken. More info is needed, even in simple cases.
>=20
> 2b) Wollongong
>=20
> There is extensive mention of Wollongong in the resulting discussion,
> fair enough, but is there any actual evidence that it is relevant?
>=20
> VMS has commands such as ANALYZE /IMAGE which may sometimes be helpful
> in deterrmining the libraries used by a given executable image (eg
> Wollongong or whatever). A decent VMS person will know how to use
> these facilities, they won't need to be [and probably won't be] a=
n
> Alsys expert. A decent VMS person will also know how to look at
> network setups and network activity.
>=20
> 2c) Usual questions which need answering.
>=20
> Has anything like this Alsys/VMS setup ever worked, for anybody? [In
> the early era of the HP 64000, I had access to its Tektronix
> competitor, an 85xx emulator/analyser. At that time, the 85xx
> diagnostics were broken, as confirmed by Tek tech support. Someone
> attempting to revive that setup and using the diagnostics would see
> the diagnostics fail and conclude that something was broken. That
> conclusion would probably be wrong. The equipment worked, the diags
> were broken]
>=20
> So, has this particular setup ever worked, either in the organisation
> currently trying it or elsewhere?
>=20
> Is anybody still around that remembers it either working or not
> working, in this setup or elsewhere?
>=20
> If it ever worked, what (other than the date, the users, etc) might
> have changed since then?
>=20
> What, exactly, is the user actually trying to do (presumably with
> Adaprobe) at the time of the ACCVIO?
>=20
> What is the Adaprobe application, and underneath it, the VMS system,
> actually trying to do at the time of the ACCVIO? (If appropriate, run
> from a privileged account and use $ SET WATCH FILE/CLASS=3DMAJOR to see
> some indication of what files are being accessed, no guarantees this
> will help).
>=20
> Are relevant aspects of the HP 64000 known to be working OK (eg can it
> co-operate relevantly and successfully with other devices on the LAN)?
>=20
> Are relevant aspects of the VAX known to be working OK (eg can it co-
> operate relevantly and successfully with other devices on the LAN)?
> [Telnet may or may not be relevant
>=20
> And once these are answered there WILL be more to follow.
>=20
>=20
> 3) Way forward
>=20
> A quick look at Wikipedia says that some relevant Alsys assets and
> knowledge may have ended up with Atego, who do still trade, though
> whether they can offer relevant expertise is a different question.
>=20
> The limited market for this kind of product and in particular for this
> combination of products may mean that a significant part of the
> approach for fixing this particular situation is via a more generic
> approach using a knowledgeable computer bod from the era (a computer
> paleontologist? I have seen, but cannot remember, better names) rather
> than Alsys experts or HP64K experts.
>=20
> Where, geographically, is this kit, and does access to it require any
> particular security clearances? This task isn't particularly likely t=
o
> be amenable to remote support, although the VMS-specifics might be.
>=20
> That'll have to do for now, the sun shines and the garden awaits.
>=20
> Best of luck.

Thanks gentlemen for all the good info.=20
I am not a VAX anything. Unfortunately, I have to get the test environment =
to work before I can do the work I assigned up for which is to update the p=
roduct software which is embedded and runs on a 68000 processor. The HP is =
used as an ICE debugger and the VAX was the development environment used in=
 those days. One of the requirements is that I have to use the certified en=
vironment from 1992. Any tricks or ways to debug VAX issues would be helpfu=
l. ie. Can I trace what the vax is executing before it crashed? Can I invok=
e the command in some sort of debugger and see it run?=20

From the comments you gentlemen have provided here are some dumps: PS sho n=
etwork and tcpip show version did not work but ucx sho ver did (if that mea=
ns anything ...)

HERE IS MY DUMP:

        Welcome to OpenVMS VAX V6.2

Username: SYSTEM
        Welcome to OpenVMS VAX version V6.2
    Last interactive login on Sunday, 22-JUL-2012 18:03
    Last non-interactive login on Thursday, 19-JUL-2012 16:44
SYSMGR> victor
  DKB200:[USERS.VICTOR]
USERS.VICTOR> cd trial
  DKB200:[USERS.VICTOR.TRIAL]
USERS.VICTOR.TRIAL> cd 64kprobe
  DKB200:[USERS.VICTOR.TRIAL.64KPROBE]
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE> ucx sho ver

  Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 4
  on a MicroVAX 3100 running OpenVMS V6.2

...USERS.VICTOR.TRIAL.64KPROBE> typ demo_probe.com
$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
$! File: ADA_PROBE.COM -- Transfer and execute xxx.abs program. !!
$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
$!
$! Note: TARGET must use the name in the TARGETS.DAT file.  For
$!       instance, if the exact VMS device name associated with
$!       the line is TXB5 and the kernel runs at a baud rate of
$!       9600, then set TARGETS.DAT to
$!       LAB_M   SERIAL   TXB5   9600   ENCODE_XON_XOFF
$!       where LAB_M is the name used by TRANSFER to
$!       reference the device.
$ SET TERM/DEVICE=3DVT200
$ ADAW WORKBENCH.PROBE                                          -
    PROGRAM=3Dpgm64k.ABS       -
    TARGET=3Dhp64                                                 -
    OUTPUT=3DTERMINAL                                             -
    LOG=3Ddemo_PROBE.LOG,    -
    DIALOG=3DAUTOMATIC,                                           -
    FORMAT=3DSRECORD,                                             -
    TRANSFER=3DDIFFERENTIAL,                                      -
    MEMORY=3D200
$ SET TERM/DEVICE=3DVT200
$!
$ EXIT
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE> set watch file/class=3Dmajor
...USERS.VICTOR.TRIAL.64KPROBE> @demo_probe
%XQP, Thread #0, Lookup  (1688,3,0) Status: 00000001
%XQP, Thread #0, Access ADA.EXE;4 (2538,16,0) Status: 00000001
%XQP, Thread #0, Access ADA.BTL;2 (1807,19,0) Status: 00000001
%XQP, Thread #0, Deaccess (1807,19,0) Reads: 4, Writes: 0, Status: 00000001
%XQP, Thread #0, Access  (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup  (17,1,0) Status: 00000001
%XQP, Thread #0, Access  (0,0,0) Status: 00000910
Alsys Ada Version 5.3.1
Copyright (C) Alsys, 1985, 1990. All rights reserved.
%XQP, Thread #0, Access  (0,0,0) Status: 00000910
%XQP, Thread #0, Access  (0,0,0) Status: 00000910
Opening library DKB200:[USERS.VICTOR.TRIAL.64KPROBE.LIB_64K]
%SYSTEM-F-ACCVIO, access violation, reason mask=3D00, virtual address=3D000=
00004, PC=3D0008613E, PSL=3D03C000A4
%TRACE-E-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs P=
C

                                                           002BF64E  002BF6=
4E
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=3D00, virtual address=3D000=
00004, PC=3D0008613E, PSL=3D03C000A4
----- end of exception message
UPI_OUTPUT_TERM INIT_OUTPUT                       666      0000034C  000861=
3E
UPI_INITIALISAT INIT_UPI                          529      0000010C  001B6B=
52
ADAPROBE_MAIN.P PROBE_CLI                       34074      00000247  0014D8=
16
ADAPROBE_MAIN   START_PROBE_SESSION               439      0000010D  00147D=
16
ADAPROBE        ADAPROBE                           38      00000017  0024CF=
3F
ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          00000009  0006A0=
15
SHELL$MATCH_WIL SHELL$MATCH_WILD                           0000010B  0025CF=
7F
                                                           002BF41D  002BF4=
1D
ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          0000001B  0006A0=
27
SHELL$MATCH_WIL SHELL$MATCH_WILD                           000000E6  0025CF=
5A
%NONAME-E-NOMSG, Message number 00000002
%XQP, Thread #0, Deaccess (2538,16,0) Reads: 11, Writes: 0, Status: 0000000=
1
%XQP, Thread #0, Deaccess (3451,33,0) Reads: 1, Writes: 0, Status: 00000001
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE>
...USERS.VICTOR.TRIAL.64KPROBE>

On Saturday, July 21, 2012 5:08:35 PM UTC-5, Steven Schweda wrote:
> > [...] my guess is [...]
>=20
>    It's not implausible, but actual evidence remains sparse.
> My dim recollection suggests that there was a TWGLIB.EXE and
> a TWGLIB.OLB.
>=20
>    It might be worth searching the relevant executable(s) for, say,
> "TWG", or other suggestive strings.
>=20
>    I have an Attachmate PathWay 3.0 kit from 1997 on CD-ROM
> (and I might have a TK50 somewhere which is even older, but
> no bets on that).  The 3.0 kit claims suitability for VMS VAX
> V5.3 or higher, but getting the stuff to run without an
> official Authorization Number from the vendor may be
> difficult.
>=20
> > [...] We used Wollongong on
> > several microvaxen and it was always a bit flaky compared to
> > out of the box networking on Sun and Hp workstations. [...]
>=20
>    Perhaps, but, in that time frame, it was always more than a
> bit better than the VMS-Ultrix Connection (UCX), in that it
> was not entirely useless.
>=20
> > [...] If I were
> > trying to get such a a system running, I might try one of
> > those versions [...]
>=20
>    If I were serious about trying to get such a a system
> running, then I'd start with versions of everything which
> were known to work together.  An image backup of an old,
> known-working system might be a good start.

Hi Steven,
We took the old tapes and installed them a vax 3100/20. Maybe we missed som=
ething. There are symbolics ie TWG$COMMON etc which points to directories b=
ut I did not find the two files you mentioned. We suspect one of the proble=
ms might be that we don't have wollongong installed (as it was mentioned th=
at adaprobe might be looking for it even though I can telnet). "UCX sho ver=
" command worked so does that mean I am using VMS-Ultrix Connection (UCX)? =
Any ideas on any vax commands that are useful in tracking down problems. Th=
e "set watch" did not help.
Vic 

On 2012-07-22 23:18:18 +0000, AlsysQ said:

> 
> Thanks gentlemen for all the good info.I am not a VAX anything. 
> Unfortunately, I have to get the test environment to work before I can 
> do the work I assigned up for which is to update the product software 
> which is embedded and runs on a 68000 processor. The HP is used as an 
> ICE debugger and the VAX was the development environment used in those 
> days. One of the requirements is that I have to use the certified 
> environment from 1992. Any tricks or ways to debug VAX issues would be 
> helpful. ie. Can I trace what the vax is executing before it crashed? 
> Can I invoke the command in some sort of debugger and see it run?

You mean... Can you become familiar sufficiently with instruction-level 
debugging using a platform and tools that you're unfamiliar with, using 
a software version and network configuration that you don't currently 
have, with a knot of missing and conflicting requirements, using a 
newsgroup as your source of support and product information, and in an 
environment -- with ancient VAX/VMS, Wollongong, Ada and this old HP 
(now Agilent) ICE widget -- that few folks around have ever seen?

Ummmmmm... Yeah.   Good luck with that.

Is it possible to trace instructions?  Yes.  It's usually a whole lot 
of dumping and digging around in the executable code of the image to 
see exactly what's going on here.  Basically, this involves 
reverse-engineering executable VAX code, first to figure out what the 
code is doing, and then resolving the error.

> From the comments you gentlemen have provided here are some dumps: PS 
> sho network and tcpip show version did not work but ucx sho ver did (if 
> that means anything ...)
> 
> HERE IS MY DUMP:
> <<<----big snip---->>>
> Opening library DKB200:[USERS.VICTOR.TRIAL.64KPROBE.LIB_64K]
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual 
> address=00000004, PC=0008613E, PSL=03C000A4
> %TRACE-E-TRACEBACK, symbolic stack dump follows
> module name     routine name                     line       rel PC    abs PC
> 
>                                                            002BF64E  002BF64E
> ----- above condition handler called with exception 0000000C:
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual 
> address=00000004, PC=0008613E, PSL=03C000A4
> ----- end of exception message
> UPI_OUTPUT_TERM INIT_OUTPUT                       666      0000034C  0008613E
> <<<----big snip---->>>

As a guess, it looks like something had a zero in a pointer to a data 
structure that the code wasn't expecting to find, and (when it looked 
at whatever was stored at offset 4 from that pointer) the code blew up 
with an ACCVIO access violation.

On no evidence piled precariously atop guesswork, I'd guess that it's 
not finding the network interface that it expects, or as it expects.

Easiest approach is not reverse-engineering an image.  It's building or 
finding the same environment that was originally used.  You're going to 
want to re-create the original VAX/VMS environment, and probably with 
the Wollongong IP stack installed and configured, if that's required by 
this product.  That, or encouraging the management and project and 
customer folks that have tied this project into knots whether they'll 
release a few of those knots.




-- 
Pure Personal Opinion | HoffmanLabs LLC

On 7/22/2012 6:18 PM, AlsysQ wrote:
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000004, PC=0008613E, PSL=03C000A4
> %TRACE-E-TRACEBACK, symbolic stack dump follows
> module name     routine name                     line       rel PC    abs PC
>
>                                                             002BF64E  002BF64E
> ----- above condition handler called with exception 0000000C:
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000004, PC=0008613E, PSL=03C000A4
> ----- end of exception message
> UPI_OUTPUT_TERM INIT_OUTPUT                       666      0000034C  0008613E
> UPI_INITIALISAT INIT_UPI                          529      0000010C  001B6B52
> ADAPROBE_MAIN.P PROBE_CLI                       34074      00000247  0014D816
> ADAPROBE_MAIN   START_PROBE_SESSION               439      0000010D  00147D16
> ADAPROBE        ADAPROBE                           38      00000017  0024CF3F
> ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          00000009  0006A015
> SHELL$MATCH_WIL SHELL$MATCH_WILD                           0000010B  0025CF7F
>                                                             002BF41D  002BF41D
> ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          0000001B  0006A027
> SHELL$MATCH_WIL SHELL$MATCH_WILD                           000000E6  0025CF5A
> %NONAME-E-NOMSG, Message number 00000002

I am a bit confused by this trace.

The shell$match_wild shows up on my VAX/VMS 7.3 as part of the VAXCRTL.

The shell$match_wild also takes two null terminated char * arguments, no 
user call back options.

So a stack trace that ends with SHELL$MATCH_WILD should not be 
referencing anything below it that is not a VMS supplied routine, and 
definitely SHELL$MATCH_WILD should never be calling ADA$* routines.

This indicates that the SHELL$MATCH_WILD in the trace is not the one 
supplied by VAX/VMS, which also indicates that the programmer violated 
the VMS symbol naming conventions by using a VMS reserved symbol name 
for one of their routines.

This indicates that you may have a more difficult time in trying to find 
out what exactly is missing in your environment for obvious reasons, no 
one can predict what else that programmer did.

 From the looks of the stack trace, and your previous comments, my best 
guess is that it is trying to call a routine to set up a network 
connection to exchange the debugging information and that the connection 
seems to be emulating a terminal type connection.

The VMS TCP/IP network programming made a major shift with VAX/VMS 
5.5-2.  The C compiler was shifted from VAX C to a much superior DEC C 
compiler and DECCRTL library.

That DECCRTL library dynamically loaded the UCX shared images on request.

Before that, with VAX C, all programmers had to either build to a 
specific TCPIP stack, or call an additional library that hid the 
differences from their program.

Once the DECCRTL started doing this, all the other TCPIP vendors, except 
CMU-IP provided emulations of the UCX shared images, so programs written 
in C could work with out caring what TCPIP was in use.

Now you state this program documentation goes back to VMS 5.2 which 
means that it predates all this, and is pretty ancient, if it wants a 
specific TCP/IP program, it will need to see it.

Do you have access to a working system that currently has this 
configuration deployed?  That way you could use those tools to look at 
how the image is actually running.

Even then, with out the source, you will have a difficult time as has 
been pointed out.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

> We took the old tapes and installed them a vax 3100/20. Maybe
> we missed something.

   With my weak psychic powers, I have no idea exactly what
you did, nor what you might have missed.

>  There are symbolics ie TWG$COMMON etc
> which points to directories but I did not find the two files
> you mentioned. We suspect one of the problems might be that
> we don't have wollongong installed (as it was mentioned that
> adaprobe might be looking for it even though I can telnet).
> "UCX sho ver" command worked so does that mean I am using
> VMS-Ultrix Connection (UCX)?

   Most likely.  It's too bad the the actual output from that
command is such a big secret.

>  Any ideas on any vax commands
> that are useful in tracking down problems. [...]

   That depends on the problems.

   You can have multiple IP products installed.  The system
start-up procedures should decide which one to start, and
take the necessary steps to do so.  If "UCX sho ver" works,
then you would seem to have UCX running.  (The product name
was later changed to "TCPIP Services", but the license PAK
feature name stayed "UCX".)  It would be a waste of time to
define any TWG* logical names if the corresponding software
were not installed.  And typically, most of those logical
names are defined by the PathWay start-up procedure.

   I don't know what happens if you try to start both of
them.

   The only system I have with Wollongong/Attachmate PathWay
installed is a VAXstation 2000, running VMS V5.5-2, which I
seldom use.  (It needs some hardware and license work before
it could actually be useful.  However it does reveal a few
things...)

WEAK $ show logi twg*
[...]
(LNM$SYSTEM_TABLE)

  "TWG$TCP" = "TWG_DEVICE:[WPW.V2R5.SYS0.PATHWAY.]"
        = "TWG_DEVICE:[WPW.V2R5.COMMON.PATHWAY.]"
  "TWG_DEVICE" = "DUA1:"
[...]


WEAK $ run TWG$TCP:[PATHWAY_ADMIN]PATHWAY$LIST_SOFTWARE.EXE
Installed PathWay Products:
--------------------------
PathWay for OpenVMS                 2.5.1


   As for the run-time libraries:

WEAK $ dire /date /prot /size TWG$TCP:[000000...]twglib

Directory TWG$TCP:[000000.NETDIST.ETC]

TWGLIB.EXE;1            187   2-JUN-1995 19:03:32.22
(RWED,RWED,RE,RE)

Total of 1 file, 187 blocks.

Directory TWG$TCP:[000000.NETDIST.LIB]

TWGLIB.OLB;1            418  31-JAN-1996 20:32:01.53
(RWED,RWED,RWED,RE)

Total of 1 file, 418 blocks.

Grand total of 2 directories, 2 files, 605 blocks.

   I did find one network-using executable lying around:

Directory DUA1:[UTILITY]

RTIME.C;24               12  17-APR-1996 15:53:50.00
(RWED,RWED,RE,RE)
RTIME.EXE;3               8  17-MAR-1998 07:51:19.10
(RWED,RWED,RE,RE)
RTIME.OBJ;4               7  17-MAR-1998 07:49:28.38
(RWED,RWED,RE,RE)
RTIME.OPT;1               1  17-MAR-1998 05:22:10.00
(RWED,RWED,RE,RE)

   Apparently, it was linked using the shareable image:

WEAK $ type RTIME.OPT
rtime.obj
twglib /share           <--- That would be TWGLIB.EXE

   And the image analyzer seems to believe it:

WEAK $ anal /imag RTIME.EXE /outp = RTIME.ANI
%ANALYZE-I-ERRORS, DUA1:[UTILITY]RTIME.EXE;
3                               0 err
ors
WEAK $ sear RTIME.ANI twg
                        global section name: "TWGLIB_001"
                1)  "TWGLIB"

(You can search the .EXE directly, but it's noisy.)

   So, if you can find something like that in your
executable, then you may really need to be using the PathWay
(formerly known as "WIN/TCP") software.  ("TWG" refers to
"The Wollongong Group".)

   The two start-up procedures may be:

      TWG$TCP:[NETDIST.MISC]STARTINET.COM
      SYS$MANAGER:UCX$STARTUP.COM

(Other IP products also existed, and used others.)

   As I recall, I defined TWG$TCP myself so that I could
easily find the PathWay stuff, but STARTINET.COM will (re-)do
it.  It does seem to use TWG_DEVICE, so someone may need to
define that.  Around here, for example:

$ DEFINE /SYSTEM /EXECUTIVE_MODE  TWG_DEVICE  DUA1:

The path to the PathWay stuff varies according to the whims
of the person who installed the stuff, but you should find a
NETDIST directory somewhere, and that's where the stuff was
installed.  Around here, for example:

WEAK $ dire TWG_DEVICE:[000000...]netdist.dir

Directory DUA1:[WPW.V2R5.COMMON.PATHWAY]

NETDIST.DIR;1

Total of 1 file.

Directory DUA1:[WPW.V2R5.SYS0.PATHWAY]

NETDIST.DIR;1

Total of 1 file.

Grand total of 2 directories, 2 files.


   After running TWG$TCP:[NETDIST.MISC]STARTINET.COM, I have
more TWG* logical names:

WEAK $ show logi twg*
[...]
(LNM$SYSTEM_TABLE)

  "TWG$COMMON" = "TWG_DEVICE:[WPW.V2R5.COMMON.PATHWAY.]"
  "TWG$ETC" = "TWG_DEVICE:[WPW.V2R5.SYS0.PATHWAY.NETDIST.ETC.]"
        = "TWG_DEVICE:[WPW.V2R5.COMMON.PATHWAY.NETDIST.ETC.]"
  "TWG$SPECIFIC" = "TWG_DEVICE:[WPW.V2R5.SYS0.PATHWAY.]"
  "TWG$TCP" [super] = "TWG_DEVICE:[WPW.V2R5.SYS0.PATHWAY.]"
        = "TWG_DEVICE:[WPW.V2R5.COMMON.PATHWAY.]"
  "TWG$TCP" [exec] = "TWG$SPECIFIC:"
        = "TWG$COMMON:"
  "TWG$TMP" = "TWG_DEVICE:[WPW.V2R5.SYS0.PATHWAY.NETDIST.TMP.]"
  "TWGLIB" = "TWG$TCP:[NETDIST.ETC]TWGLIB.EXE"
  "TWG_DEVICE" = "DUA1:"
  "TWG_FTPAPI" = "TWG$TCP:[NETDIST.ETC]TWG_FTPAPI.EXE"
  "TWG_HELPLIB" = "TWG$TCP:[NETDIST.HELP]PATHWAY.HLB"
  "TWG_KERNAPI" = "TWG$TCP:[NETDIST.ETC]TWG_KERNAPI.EXE"
  "TWG_SMTP_IMAGE" = "TWG$TCP:[NETDIST.SERV]SMTP.EXE"
  "TWG_TELNETAPI" = "TWG$TCP:[NETDIST.ETC]TWG_TELNETAPI.EXE"
[...]

>    Most likely.  It's too bad the the actual output from that
> command is such a big secret.

   It took me a while, but I found it.  A jump from VMS V5.2
to V6.2 is not a small thing.

>    I have an Attachmate PathWay 3.0 kit from 1997 on CD-ROM
> (and I might have a TK50 somewhere which is even older, but
> no bets on that).  [...]

   I found a V2.5.1 CD-ROM, too.  It's dated 1994, which may
still be much newer than whatever you might have.  It claims
to support VMS V5.3 through V6.2 (and V6.1 and V6.2 on that
new-fangled Alpha thing).


> This indicates that the SHELL$MATCH_WILD in the trace is not
> the one supplied by VAX/VMS, [...]

   Well, it indicates something.  Possibly an uninformative
traceback.

AlsysQ wrote 2012-07-23 01:18:




> Thanks gentlemen for all the good info. I am not a VAX anything...

OK. Maybe time to get some help with this. Depending on our schedule
for the assignment, a news-group might be OK. But if you're time
limited it might be better to get someone one-site.

> Unfortunately, I have to get the test environment to work before I can
> do the work I assigned up for which is to update the product software
> which is embedded and runs on a 68000 processor.

Now, we do not know under what circumstances you have assigned for this
work, but did you do that without at least a faint idea of how
you should execute the assignment ?

What is the budget for this "work" ?

I guess you'd better get someone VMS knowledgeable into the
game to help with the environment as such. As I read it, your
area of expertees is around the 68000 application, right ?

> The HP is used as an
> ICE debugger and the VAX was the development environment used in those
> days. One of the requirements is that I have to use the certified
> environment from 1992.

The actual environment you are using now, is that the original
environment where this setup actualy *did* work in 1992 ?
If not, how do you know that this new-old VMS envir is
correctly setup with all needed components ?


> Any tricks or ways to debug VAX issues would be
> helpful. ie. Can I trace what the vax is executing before it crashed?
> Can I invoke the command in some sort of debugger and see it run?
>

Now, this software *should* run, if all the bits and pieces are
in the right place. I do not think that deep debugging on the
instruction level is the right tool at this moment.

A lot points to that the application is linked staticaly against
Wollongong and that IP stack is not available (or not started).

Begin on that level before diggig deeper. Doing some basic
ANALYZE/IMAGE as has been shown here is also a good idea.

Jan-Erik


> From the comments you gentlemen have provided here are some dumps: PS
> sho network and tcpip show version did not work but ucx sho ver did (if
> that means anything ...)
>
> HERE IS MY DUMP:
>
> Welcome to OpenVMS VAX V6.2
>
> Username: SYSTEM Welcome to OpenVMS VAX version V6.2 Last interactive
> login on Sunday, 22-JUL-2012 18:03 Last non-interactive login on
> Thursday, 19-JUL-2012 16:44 SYSMGR> victor DKB200:[USERS.VICTOR]
> USERS.VICTOR> cd trial DKB200:[USERS.VICTOR.TRIAL] USERS.VICTOR.TRIAL>
> cd 64kprobe DKB200:[USERS.VICTOR.TRIAL.64KPROBE]
> ..USERS.VICTOR.TRIAL.64KPROBE> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE> ucx sho ver
>
> Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 4 on a
> MicroVAX 3100 running OpenVMS V6.2
>
> ..USERS.VICTOR.TRIAL.64KPROBE> typ demo_probe.com
> $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! $!
> File: ADA_PROBE.COM -- Transfer and execute xxx.abs program. !!
> $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! $! $!
> Note: TARGET must use the name in the TARGETS.DAT file.  For $!
> instance, if the exact VMS device name associated with $!       the line
> is TXB5 and the kernel runs at a baud rate of $!       9600, then set
> TARGETS.DAT to $!       LAB_M   SERIAL   TXB5   9600   ENCODE_XON_XOFF
> $!       where LAB_M is the name used by TRANSFER to $!       reference
> the device. $ SET TERM/DEVICE=VT200 $ ADAW WORKBENCH.PROBE
> - PROGRAM=pgm64k.ABS       - TARGET=hp64
> - OUTPUT=TERMINAL                                             -
> LOG=demo_PROBE.LOG,    - DIALOG=AUTOMATIC,
> - FORMAT=SRECORD,                                             -
> TRANSFER=DIFFERENTIAL,                                      -
> MEMORY=200 $ SET TERM/DEVICE=VT200 $! $ EXIT
> ..USERS.VICTOR.TRIAL.64KPROBE> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE> set watch file/class=major
> ..USERS.VICTOR.TRIAL.64KPROBE> @demo_probe %XQP, Thread #0, Lookup
> (1688,3,0) Status: 00000001 %XQP, Thread #0, Access ADA.EXE;4
> (2538,16,0) Status: 00000001 %XQP, Thread #0, Access ADA.BTL;2
> (1807,19,0) Status: 00000001 %XQP, Thread #0, Deaccess (1807,19,0)
> Reads: 4, Writes: 0, Status: 00000001 %XQP, Thread #0, Access  (0,0,0)
> Status: 00000910 %XQP, Thread #0, Lookup  (17,1,0) Status: 00000001
> %XQP, Thread #0, Access  (0,0,0) Status: 00000910 Alsys Ada Version
> 5.3.1 Copyright (C) Alsys, 1985, 1990. All rights reserved. %XQP, Thread
> #0, Access  (0,0,0) Status: 00000910 %XQP, Thread #0, Access  (0,0,0)
> Status: 00000910 Opening library
> DKB200:[USERS.VICTOR.TRIAL.64KPROBE.LIB_64K] %SYSTEM-F-ACCVIO, access
> violation, reason mask=00, virtual address=00000004, PC=0008613E,
> PSL=03C000A4 %TRACE-E-TRACEBACK, symbolic stack dump follows module name
> routine name                     line       rel PC    abs PC
>
> 002BF64E  002BF64E ----- above condition handler called with exception
> 0000000C: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
> address=00000004, PC=0008613E, PSL=03C000A4 ----- end of exception
> message UPI_OUTPUT_TERM INIT_OUTPUT                       666
> 0000034C  0008613E UPI_INITIALISAT INIT_UPI                          529
> 0000010C  001B6B52 ADAPROBE_MAIN.P PROBE_CLI                       34074
> 00000247  0014D816 ADAPROBE_MAIN   START_PROBE_SESSION               439
> 0000010D  00147D16 ADAPROBE        ADAPROBE                           38
> 00000017  0024CF3F ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE
> 00000009  0006A015 SHELL$MATCH_WIL SHELL$MATCH_WILD
> 0000010B  0025CF7F 002BF41D  002BF41D ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE
> 0000001B  0006A027 SHELL$MATCH_WIL SHELL$MATCH_WILD
> 000000E6  0025CF5A %NONAME-E-NOMSG, Message number 00000002 %XQP, Thread
> #0, Deaccess (2538,16,0) Reads: 11, Writes: 0, Status: 00000001 %XQP,
> Thread #0, Deaccess (3451,33,0) Reads: 1, Writes: 0, Status: 00000001
> ..USERS.VICTOR.TRIAL.64KPROBE> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE>
>

On 2012-07-22, AlsysQ <blackwaresys@gmail.com> wrote:
>
> Thanks gentlemen for all the good info. 
> I am not a VAX anything. Unfortunately, I have to get the test environment to
> work before I can do the work I assigned up for which is to update the product
> software which is embedded and runs on a 68000 processor. The HP is used as an
> ICE debugger and the VAX was the development environment used in those days.
> One of the requirements is that I have to use the certified environment from
> 1992. Any tricks or ways to debug VAX issues would be helpful. ie. Can I trace
> what the vax is executing before it crashed? Can I invoke the command in some
> sort of debugger and see it run? 
>

There are some things I don't understand here.

Which certification standards are involved ?

If there's a certified environment from 1992 involved, didn't someone
snapshot the system (maybe in the form of a standalone backup) so that
it could be restored at a later date ?

How will you know when you have re-created the certified environment ?
Is there certification documentation around which specifies the software
versions and configuration in use ?

Depending on the certification standards, just getting the same software
to run again in some form may not be enough to satisfy the certification
requirements.

Unless everything, including software versions, and configuration of the
software, has been documented how can you hope to recreate the exact
certified configuration ?

Is the VMS version part of the certification process ?

> From the comments you gentlemen have provided here are some dumps: PS sho
> network and tcpip show version did not work but ucx sho ver did (if that means
> anything ...)
>
> HERE IS MY DUMP:
>
>         Welcome to OpenVMS VAX V6.2
>
> Username: SYSTEM
>         Welcome to OpenVMS VAX version V6.2
>     Last interactive login on Sunday, 22-JUL-2012 18:03
>     Last non-interactive login on Thursday, 19-JUL-2012 16:44
> SYSMGR> victor
>   DKB200:[USERS.VICTOR]
> USERS.VICTOR> cd trial
>   DKB200:[USERS.VICTOR.TRIAL]
> USERS.VICTOR.TRIAL> cd 64kprobe
>   DKB200:[USERS.VICTOR.TRIAL.64KPROBE]
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE> ucx sho ver
>
>   Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 4
>   on a MicroVAX 3100 running OpenVMS V6.2
>
> ..USERS.VICTOR.TRIAL.64KPROBE> typ demo_probe.com
> $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> $! File: ADA_PROBE.COM -- Transfer and execute xxx.abs program. !!
> $!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> $!
> $! Note: TARGET must use the name in the TARGETS.DAT file.  For
> $!       instance, if the exact VMS device name associated with
> $!       the line is TXB5 and the kernel runs at a baud rate of
> $!       9600, then set TARGETS.DAT to
> $!       LAB_M   SERIAL   TXB5   9600   ENCODE_XON_XOFF
> $!       where LAB_M is the name used by TRANSFER to
> $!       reference the device.
> $ SET TERM/DEVICE=VT200
> $ ADAW WORKBENCH.PROBE                                          -
>     PROGRAM=pgm64k.ABS       -
>     TARGET=hp64                                                 -
>     OUTPUT=TERMINAL                                             -
>     LOG=demo_PROBE.LOG,    -
>     DIALOG=AUTOMATIC,                                           -
>     FORMAT=SRECORD,                                             -
>     TRANSFER=DIFFERENTIAL,                                      -
>     MEMORY=200
> $ SET TERM/DEVICE=VT200
> $!
> $ EXIT
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE> set watch file/class=major
> ..USERS.VICTOR.TRIAL.64KPROBE> @demo_probe
> %XQP, Thread #0, Lookup  (1688,3,0) Status: 00000001
> %XQP, Thread #0, Access ADA.EXE;4 (2538,16,0) Status: 00000001
> %XQP, Thread #0, Access ADA.BTL;2 (1807,19,0) Status: 00000001
> %XQP, Thread #0, Deaccess (1807,19,0) Reads: 4, Writes: 0, Status: 00000001
> %XQP, Thread #0, Access  (0,0,0) Status: 00000910
                                           ^^^^^^^^
I wonder if this and the other missing files are anything important.

Anything in the log file mentioned above ?

Did you use a existing targets.dat file or have you manually re-created it ?

> %XQP, Thread #0, Lookup  (17,1,0) Status: 00000001
> %XQP, Thread #0, Access  (0,0,0) Status: 00000910
> Alsys Ada Version 5.3.1
> Copyright (C) Alsys, 1985, 1990. All rights reserved.
> %XQP, Thread #0, Access  (0,0,0) Status: 00000910
> %XQP, Thread #0, Access  (0,0,0) Status: 00000910
> Opening library DKB200:[USERS.VICTOR.TRIAL.64KPROBE.LIB_64K]
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000004, PC=0008613E, PSL=03C000A4
> %TRACE-E-TRACEBACK, symbolic stack dump follows
> module name     routine name                     line       rel PC    abs PC
>
>                                                            002BF64E  002BF64E
> ----- above condition handler called with exception 0000000C:
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000004, PC=0008613E, PSL=03C000A4
> ----- end of exception message
> UPI_OUTPUT_TERM INIT_OUTPUT                       666      0000034C  0008613E
> UPI_INITIALISAT INIT_UPI                          529      0000010C  001B6B52
> ADAPROBE_MAIN.P PROBE_CLI                       34074      00000247  0014D816
> ADAPROBE_MAIN   START_PROBE_SESSION               439      0000010D  00147D16
> ADAPROBE        ADAPROBE                           38      00000017  0024CF3F
> ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          00000009  0006A015
> SHELL$MATCH_WIL SHELL$MATCH_WILD                           0000010B  0025CF7F
>                                                            002BF41D  002BF41D
> ADA$ELAB_ADAPRO ADA$ELAB_ADAPROBE                          0000001B  0006A027
> SHELL$MATCH_WIL SHELL$MATCH_WILD                           000000E6  0025CF5A
> %NONAME-E-NOMSG, Message number 00000002
> %XQP, Thread #0, Deaccess (2538,16,0) Reads: 11, Writes: 0, Status: 00000001
> %XQP, Thread #0, Deaccess (3451,33,0) Reads: 1, Writes: 0, Status: 00000001
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE>
> ..USERS.VICTOR.TRIAL.64KPROBE>

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Slightly off topic but XD Ada is still available at 

http://www.swep-eds.com/XD%20Ada/XD%20Ada.html

On 2012-07-23 04:16:58 +0000, John E. Malmberg said:
> 
> I am a bit confused by this trace.
> 
> The shell$match_wild shows up on my VAX/VMS 7.3 as part of the VAXCRTL.

I'd suspect this code is linked against a DEC/shell library, John.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On Sunday, July 22, 2012 7:01:59 PM UTC-5, Stephen Hoffman wrote:
> On 2012-07-22 23:18:18 +0000, AlsysQ said:
>=20
> >=20
> > Thanks gentlemen for all the good info.I am not a VAX anything.=20
> > Unfortunately, I have to get the test environment to work before I c=
an=20
> > do the work I assigned up for which is to update the product softwar=
e=20
> > which is embedded and runs on a 68000 processor. The HP is used as a=
n=20
> > ICE debugger and the VAX was the development environment used in tho=
se=20
> > days. One of the requirements is that I have to use the certified=20
> > environment from 1992. Any tricks or ways to debug VAX issues would =
be=20
> > helpful. ie. Can I trace what the vax is executing before it crashed=
?=20
> > Can I invoke the command in some sort of debugger and see it run?
>=20
> You mean... Can you become familiar sufficiently with instruction-level=
=20
> debugging using a platform and tools that you're unfamiliar with, usi=
ng=20
> a software version and network configuration that you don't currently=
=20
> have, with a knot of missing and conflicting requirements, using a=20
> newsgroup as your source of support and product information, and in an=20
> environment -- with ancient VAX/VMS, Wollongong, Ada and this old HP=20
> (now Agilent) ICE widget -- that few folks around have ever seen?
>=20
> Ummmmmm... Yeah.   Good luck with that.
>=20
> Is it possible to trace instructions?  Yes.  It's usually a whole lot=
=20
> of dumping and digging around in the executable code of the image to=20
> see exactly what's going on here.  Basically, this involves=20
> reverse-engineering executable VAX code, first to figure out what the=20
> code is doing, and then resolving the error.
>=20
> > From the comments you gentlemen have provided here are some dumps: P=
S=20
> > sho network and tcpip show version did not work but ucx sho ver did =
(if=20
> > that means anything ...)
> >=20
> > HERE IS MY DUMP:
> > <<<----big snip---->>>
> > Opening library DKB200:[USERS.VICTOR.TRIAL.64KPROBE.LIB_64K]
> > %SYSTEM-F-ACCVIO, access violation, reason mask=3D00, virtual=20
> > address=3D00000004, PC=3D0008613E, PSL=3D03C000A4
> > %TRACE-E-TRACEBACK, symbolic stack dump follows
> > module name     routine name                     line       rel PC  =
  abs PC
> >=20
> >                                                            002BF64E =
 002BF64E
> > ----- above condition handler called with exception 0000000C:
> > %SYSTEM-F-ACCVIO, access violation, reason mask=3D00, virtual=20
> > address=3D00000004, PC=3D0008613E, PSL=3D03C000A4
> > ----- end of exception message
> > UPI_OUTPUT_TERM INIT_OUTPUT                       666      0000034C =
 0008613E
> > <<<----big snip---->>>
>=20
> As a guess, it looks like something had a zero in a pointer to a data=20
> structure that the code wasn't expecting to find, and (when it looked=
=20
> at whatever was stored at offset 4 from that pointer) the code blew up=20
> with an ACCVIO access violation.
>=20
> On no evidence piled precariously atop guesswork, I'd guess that it&#=
39;s=20
> not finding the network interface that it expects, or as it expects.
>=20
> Easiest approach is not reverse-engineering an image.  It's building =
or=20
> finding the same environment that was originally used.  You're going =
to=20
> want to re-create the original VAX/VMS environment, and probably with=20
> the Wollongong IP stack installed and configured, if that's required =
by=20
> this product.  That, or encouraging the management and project and=20
> customer folks that have tied this project into knots whether they'll=
=20
> release a few of those knots.
>=20
>=20
>=20
>=20
> --=20
> Pure Personal Opinion | HoffmanLabs LLC

Stephen,
It is what I am trying to do, which is re-establish the test/development en=
vironment. Some more info: This command (ada_probe by Alsys) has two versio=
ns, the native and the cross (the vax and the target) The command (ada_prob=
e) on the native side (vax) works. Is there a way to determine if maybe in =
fact what I think I am executing for the target is actually for the native =
so ie I am executing a native ada_probe in a cross environment. I am aware =
that ultimately, I might go to management and tell them I need wollongong, =
but I need so ammo.
Thanks,
Vic

On Monday, July 23, 2012 8:32:43 AM UTC-5, Stephen Hoffman wrote:
> On 2012-07-23 04:16:58 +0000, John E. Malmberg said:
> > 
> > I am a bit confused by this trace.
> > 
> > The shell$match_wild shows up on my VAX/VMS 7.3 as part of the VAXCRTL.
> 
> I'd suspect this code is linked against a DEC/shell library, John.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Does the trace go bottom to top? ie the shell$match_wild is the start of the trace?

On 2012-07-23 14:23:31 +0000, AlsysQ said:
> 
> It is what I am trying to do, which is re-establish the 
> test/development environment. Some more info: This command (ada_probe 
> by Alsys) has two versions, the native and the cross (the vax and the 
> target) The command (ada_probe) on the native side (vax) works. Is 
> there a way to determine if maybe in fact what I think I am executing 
> for the target is actually for the native so ie I am executing a native 
> ada_probe in a cross environment. I am aware that ultimately, I might 
> go to management and tell them I need wollongong, but I need so ammo.

That would be information which unfortunately tells me basically 
nothing.  That information makes about as much sense (to me) as would a 
long and detailed series of postings on reverse-engineering VAX 
executables using the VAX architecture definition, the VMS image 
formats, and PATCH, DEBUG, DUMP and related tools, and using those to 
sort out what's actually going on underneath this HP/Agilent ICE tool 
chain (to you).

Put another way, you're basically asking for a simple fix, or a 
advanced course in VAX/VMS historical reverse-engineering.  That course 
doesn't exist, though there are folks around which know how to do that. 
 I'd not expect a simple fix here either, other than recreating the 
environment.

You could hope to find "The Guy" that understands all the pieces or 
manage to get somebody onto the project that can help you 
reverse-engineer this.   "The Guy" you need here would probably be in 
the form of an engineer that might still be working at Agilent or HP, 
or (more likely) a retiree from either of these organizations.  An 
engineer that actually worked on the VMS version of this ICE package.  
Assuming anybody from the HP (now Agilent) project team is even still 
around, obviously; this is old gear.

In the absence of "The Guy", you will want to get somebody onto this 
project sort out the VMS environment for you, or to reverse-engineer 
the environment and the tools, and it's still going to be an expensive 
slog if (when) reverse-engineering the non-working code becomes 
necessary.  Particularly given the likelihood that there are 
dependencies on long-dead products and ancient versions.  Or you need 
to sort out the dependencies and rebuild the lost environment.

Or you need to move to a different platform with an ICE interface (as 
described in that Agilent document), and use the ICE tools from there.

If it's the network (and whether that's at fault here or whether 
Wollongong is involved at all is not even remotely clear to me), then 
you might want to see if the serial path into the ICE works better than 
the network path.

Whomever sold you on this project to you has handed you a large mess; 
the conflicting requirements and approved products list and the lack of 
a preserved VMS environment.  But you know that.  Whether the ICE stuff 
is also a mess is another matter.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On Monday, July 23, 2012 10:05:03 AM UTC-5, Stephen Hoffman wrote:
> On 2012-07-23 14:23:31 +0000, AlsysQ said:
> > 
> > It is what I am trying to do, which is re-establish the 
> > test/development environment. Some more info: This command (ada_probe 
> > by Alsys) has two versions, the native and the cross (the vax and the 
> > target) The command (ada_probe) on the native side (vax) works. Is 
> > there a way to determine if maybe in fact what I think I am executing 
> > for the target is actually for the native so ie I am executing a native 
> > ada_probe in a cross environment. I am aware that ultimately, I might 
> > go to management and tell them I need wollongong, but I need so ammo.
> 
> That would be information which unfortunately tells me basically 
> nothing.  That information makes about as much sense (to me) as would a 
> long and detailed series of postings on reverse-engineering VAX 
> executables using the VAX architecture definition, the VMS image 
> formats, and PATCH, DEBUG, DUMP and related tools, and using those to 
> sort out what's actually going on underneath this HP/Agilent ICE tool 
> chain (to you).
> 
> Put another way, you're basically asking for a simple fix, or a 
> advanced course in VAX/VMS historical reverse-engineering.  That course 
> doesn't exist, though there are folks around which know how to do that. 
>  I'd not expect a simple fix here either, other than recreating the 
> environment.
> 
> You could hope to find "The Guy" that understands all the pieces or 
> manage to get somebody onto the project that can help you 
> reverse-engineer this.   "The Guy" you need here would probably be in 
> the form of an engineer that might still be working at Agilent or HP, 
> or (more likely) a retiree from either of these organizations.  An 
> engineer that actually worked on the VMS version of this ICE package.  
> Assuming anybody from the HP (now Agilent) project team is even still 
> around, obviously; this is old gear.
> 
> In the absence of "The Guy", you will want to get somebody onto this 
> project sort out the VMS environment for you, or to reverse-engineer 
> the environment and the tools, and it's still going to be an expensive 
> slog if (when) reverse-engineering the non-working code becomes 
> necessary.  Particularly given the likelihood that there are 
> dependencies on long-dead products and ancient versions.  Or you need 
> to sort out the dependencies and rebuild the lost environment.
> 
> Or you need to move to a different platform with an ICE interface (as 
> described in that Agilent document), and use the ICE tools from there.
> 
> If it's the network (and whether that's at fault here or whether 
> Wollongong is involved at all is not even remotely clear to me), then 
> you might want to see if the serial path into the ICE works better than 
> the network path.
> 
> Whomever sold you on this project to you has handed you a large mess; 
> the conflicting requirements and approved products list and the lack of 
> a preserved VMS environment.  But you know that.  Whether the ICE stuff 
> is also a mess is another matter.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Thanks Stephen, I guess I am looking for someone who has used AdaProbe in the past or Alsys. I started with this forum. Any suggestions as to a forum where I would be more successful. This is for folks probably in their 50's, 60's.

On Monday, July 23, 2012 4:13:12 PM UTC+1, AlsysQ wrote:
> On Monday, July 23, 2012 10:05:03 AM UTC-5, Stephen Hoffman wrote:
> > On 2012-07-23 14:23:31 +0000, AlsysQ said:
> > > 
> > > It is what I am trying to do, which is re-establish the 
> > > test/development environment. Some more info: This command (ada_probe 
> > > by Alsys) has two versions, the native and the cross (the vax and the 
> > > target) The command (ada_probe) on the native side (vax) works. Is 
> > > there a way to determine if maybe in fact what I think I am executing 
> > > for the target is actually for the native so ie I am executing a native 
> > > ada_probe in a cross environment. I am aware that ultimately, I might 
> > > go to management and tell them I need wollongong, but I need so ammo.
> > 
> > That would be information which unfortunately tells me basically 
> > nothing.  That information makes about as much sense (to me) as would a 
> > long and detailed series of postings on reverse-engineering VAX 
> > executables using the VAX architecture definition, the VMS image 
> > formats, and PATCH, DEBUG, DUMP and related tools, and using those to 
> > sort out what's actually going on underneath this HP/Agilent ICE tool 
> > chain (to you).
> > 
> > Put another way, you're basically asking for a simple fix, or a 
> > advanced course in VAX/VMS historical reverse-engineering.  That course 
> > doesn't exist, though there are folks around which know how to do that. 
> >  I'd not expect a simple fix here either, other than recreating the 
> > environment.
> > 
> > You could hope to find "The Guy" that understands all the pieces or 
> > manage to get somebody onto the project that can help you 
> > reverse-engineer this.   "The Guy" you need here would probably be in 
> > the form of an engineer that might still be working at Agilent or HP, 
> > or (more likely) a retiree from either of these organizations.  An 
> > engineer that actually worked on the VMS version of this ICE package.  
> > Assuming anybody from the HP (now Agilent) project team is even still 
> > around, obviously; this is old gear.
> > 
> > In the absence of "The Guy", you will want to get somebody onto this 
> > project sort out the VMS environment for you, or to reverse-engineer 
> > the environment and the tools, and it's still going to be an expensive 
> > slog if (when) reverse-engineering the non-working code becomes 
> > necessary.  Particularly given the likelihood that there are 
> > dependencies on long-dead products and ancient versions.  Or you need 
> > to sort out the dependencies and rebuild the lost environment.
> > 
> > Or you need to move to a different platform with an ICE interface (as 
> > described in that Agilent document), and use the ICE tools from there.
> > 
> > If it's the network (and whether that's at fault here or whether 
> > Wollongong is involved at all is not even remotely clear to me), then 
> > you might want to see if the serial path into the ICE works better than 
> > the network path.
> > 
> > Whomever sold you on this project to you has handed you a large mess; 
> > the conflicting requirements and approved products list and the lack of 
> > a preserved VMS environment.  But you know that.  Whether the ICE stuff 
> > is also a mess is another matter.
> > 
> > 
> > 
> > -- 
> > Pure Personal Opinion | HoffmanLabs LLC
> 
> Thanks Stephen, I guess I am looking for someone who has used AdaProbe in the past or Alsys. I started with this forum. Any suggestions as to a forum where I would be more successful. This is for folks probably in their 50's, 60's.

If you don't find a person with that exact experiance then you may find contacting the XD Ada people via
http://www.swep-eds.com/General/Contact%20Us.html
useful. They work on a similar but different product and are some of them a cetainly old enough :-)

On 2012-07-23 14:27:15 +0000, AlsysQ said:

> On Monday, July 23, 2012 8:32:43 AM UTC-5, Stephen Hoffman wrote:
>> On 2012-07-23 04:16:58 +0000, John E. Malmberg said:
>> >
>> > I am a bit confused by this trace.
>> >
>> > The shell$match_wild shows up on my VAX/VMS 7.3 as part of the VAXCRTL.
>> 
>> I'd suspect this code is linked against a DEC/shell library, John.
>> 
>> 
>> --
>> Pure Personal Opinion | HoffmanLabs LLC
> 
> Does the trace go bottom to top? ie the shell$match_wild is the start 
> of the trace?

A general explanation of the access violation (ACCVIO) on OpenVMS is 
available here: <http://labs.hoffmanlabs.com/node/800>

The instruction that encountered the error is listed (dumped) first in 
the stackdump, then the last-chance handler walks up the call stack  
(when the call stack is valid), which means that the error is listed at 
the top of the dump and the call stack is listed (dumped) on subsequent 
lines of the stackdump.

The VAX stack builds from high addresses down to lower addresses, which 
means the layout of a stackdump is reversed from the layout in virtual 
memory.  The handler walks up the call stack (from low to high virtual 
addresses), dumping call frames out as it finds them (from top to 
bottom in the dump output).

The shell$match_wild call and related code was packaged very 
differently on old VAX/VMS releases; it was part of a separate layered 
product known as DEC/shell.  In more recent VMS releases, parts of the 
now-long-retired DEC/shell product have been migrated into the C 
run-time library.  (And IIRC, the DEC/shell product will crash VMS, if 
an attempt is made to start it on a too-new version of VMS.)

As for the cause of John's puzzlement, it's comparatively unusual to 
see user code listed "underneath" or "below" a VMS library call in the 
dump of a call stack.  That configuration would usually involve some 
sort of asynchronous activity, or a callback from the particular 
routine, or possibly a stack corruption.  I'm here guessing that 
there's a callback here, but I'd have to dig up and then dig through 
the DEC/shell documentation to be sure.

In older VAX/VMS releases, it's also common to see some layered product 
code linked directly into the image.  With "more recent" layered 
products, the developers have tended to provide shareable images, and 
have usually encouraged the use shareable image code, or have only 
provided shareable images.  The code from layered product object 
libraries gets static-linked directly into the application, which means 
the application developer has to relink to load any fixes provided in a 
newer version of layered product.  Properly-constructed shareable 
images don't have the requirement to relink the application code; they 
are used to dynamically activate the most current layered product code.

And what the trigger here for this stackdump might be is wide open.  
This could be a system set-up error, a change in the kernel, a missing 
layered product, or most anything else.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-07-23 15:13:12 +0000, AlsysQ said:

> 
> Thanks Stephen, I guess I am looking for someone who has used AdaProbe 
> in the past or Alsys.

Apparently, I was unclear.  You are best looking for somebody that 
worked on the product back then, or supported it.  Folks that simply 
used this ICE - as rare as they might be - would likely not know the 
details of this stackdump, of the innards of the product, and probably 
wouldn't do much better than pointing you at the prerequsite products 
and requirements.  Which I've already pointed you at.

>  I started with this forum. Any suggestions as to a forum where I would 
> be more successful. This is for folks probably in their 50's, 60's.

I am aware of how old "The Guy" would have be here.  Apparently rather 
more than you realize, too. :-)

The key here is somebody that worked on or that supported this stuff at 
HP or maybe at Agilient, as the end-users and the system managers that 
dealt with this ICE (as customers) likely installed and configured the 
prerequisite products, and probably then never saw this stackdump.

Or somebody that can reverse-engineer this.

Or somebody that can scrounge and set up the required environment on 
VMS here, or (if some of the administrative project shackles can be 
released) scrounge an alternative environment on another operating 
system platform that had host support for this ICE.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On Monday, July 23, 2012 10:26:53 AM UTC-5, Stephen Hoffman wrote:
> On 2012-07-23 14:27:15 +0000, AlsysQ said:
> 
> > On Monday, July 23, 2012 8:32:43 AM UTC-5, Stephen Hoffman wrote:
> >> On 2012-07-23 04:16:58 +0000, John E. Malmberg said:
> >> >
> >> > I am a bit confused by this trace.
> >> >
> >> > The shell$match_wild shows up on my VAX/VMS 7.3 as part of the VAXCRTL.
> >> 
> >> I'd suspect this code is linked against a DEC/shell library, John.
> >> 
> >> 
> >> --
> >> Pure Personal Opinion | HoffmanLabs LLC
> > 
> > Does the trace go bottom to top? ie the shell$match_wild is the start 
> > of the trace?
> 
> A general explanation of the access violation (ACCVIO) on OpenVMS is 
> available here: <http://labs.hoffmanlabs.com/node/800>
> 
> The instruction that encountered the error is listed (dumped) first in 
> the stackdump, then the last-chance handler walks up the call stack  
> (when the call stack is valid), which means that the error is listed at 
> the top of the dump and the call stack is listed (dumped) on subsequent 
> lines of the stackdump.
> 
> The VAX stack builds from high addresses down to lower addresses, which 
> means the layout of a stackdump is reversed from the layout in virtual 
> memory.  The handler walks up the call stack (from low to high virtual 
> addresses), dumping call frames out as it finds them (from top to 
> bottom in the dump output).
> 
> The shell$match_wild call and related code was packaged very 
> differently on old VAX/VMS releases; it was part of a separate layered 
> product known as DEC/shell.  In more recent VMS releases, parts of the 
> now-long-retired DEC/shell product have been migrated into the C 
> run-time library.  (And IIRC, the DEC/shell product will crash VMS, if 
> an attempt is made to start it on a too-new version of VMS.)
> 
> As for the cause of John's puzzlement, it's comparatively unusual to 
> see user code listed "underneath" or "below" a VMS library call in the 
> dump of a call stack.  That configuration would usually involve some 
> sort of asynchronous activity, or a callback from the particular 
> routine, or possibly a stack corruption.  I'm here guessing that 
> there's a callback here, but I'd have to dig up and then dig through 
> the DEC/shell documentation to be sure.
> 
> In older VAX/VMS releases, it's also common to see some layered product 
> code linked directly into the image.  With "more recent" layered 
> products, the developers have tended to provide shareable images, and 
> have usually encouraged the use shareable image code, or have only 
> provided shareable images.  The code from layered product object 
> libraries gets static-linked directly into the application, which means 
> the application developer has to relink to load any fixes provided in a 
> newer version of layered product.  Properly-constructed shareable 
> images don't have the requirement to relink the application code; they 
> are used to dynamically activate the most current layered product code.
> 
> And what the trigger here for this stackdump might be is wide open.  
> This could be a system set-up error, a change in the kernel, a missing 
> layered product, or most anything else.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Thanks,
I used Vax over 20 years ago, but if you have any debugging commands or other vax commands that can help me dig deeper I would appreciate it.
Vic

On Monday, July 23, 2012 10:40:58 AM UTC-5, Stephen Hoffman wrote:
> On 2012-07-23 15:13:12 +0000, AlsysQ said:
> 
> > 
> > Thanks Stephen, I guess I am looking for someone who has used AdaProbe 
> > in the past or Alsys.
> 
> Apparently, I was unclear.  You are best looking for somebody that 
> worked on the product back then, or supported it.  Folks that simply 
> used this ICE - as rare as they might be - would likely not know the 
> details of this stackdump, of the innards of the product, and probably 
> wouldn't do much better than pointing you at the prerequsite products 
> and requirements.  Which I've already pointed you at.
> 
> >  I started with this forum. Any suggestions as to a forum where I would 
> > be more successful. This is for folks probably in their 50's, 60's.
> 
> I am aware of how old "The Guy" would have be here.  Apparently rather 
> more than you realize, too. :-)
> 
> The key here is somebody that worked on or that supported this stuff at 
> HP or maybe at Agilient, as the end-users and the system managers that 
> dealt with this ICE (as customers) likely installed and configured the 
> prerequisite products, and probably then never saw this stackdump.
> 
> Or somebody that can reverse-engineer this.
> 
> Or somebody that can scrounge and set up the required environment on 
> VMS here, or (if some of the administrative project shackles can be 
> released) scrounge an alternative environment on another operating 
> system platform that had host support for this ICE.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Unfortunately, I have to use the vax 3100/20, vms 6.2, HP ICE, Alsys compiler, Alsys Adaprobe debugger etc. Yes, previous users would be great. Any ideas on which groups to contact?

On 2012-07-23 15:47:34 +0000, AlsysQ said:

> I used Vax over 20 years ago, but if you have any debugging commands or 
> other vax commands that can help me dig deeper I would appreciate it.

Ever the optimist, looking for the no-effort, no-cost, 
constraints-compliant answer, eh?  The bad news (for you) is that 
you've gotten into something that's somewhere between expensive and 
intractable.

There isn't an easy answer, and even the most straightforward approach 
won't be easy.  Rebuilding whatever environment this package expected 
will likely be a problem what with finding the license keys and the old 
product kits, and the distinct possibility that the V5.3 requirement of 
your MicroVAX 3100 model 20 hardware 
<http://h71000.www7.hp.com/openvms/hw_supportchart.html> won't boot 
with an older VMS version, if that's necessary.  The simh VAX emulator 
is probably the path out of that, but that can introduce other "fun".

As for your question, I'm aware of no VAX/VMS reverse-engineering 
documentation and there's definitely no vendor-provided 
reverse-engineering manual.  What's available here is largely walking 
around inside the heads of a few of the current or ex-VMS engineers, or 
a few of the customers or consultants.

As for finding "The Guy", I'm aware of no contacts at HP (or Agilent) 
that might know the innards of this particular package; that's yours to 
research directly and possibly with a call to Agilent, and see what 
resources that effort might turn up.

I've reverse-engineered VAX executable tools, and that's an effort.  
It's probably not something you'll get somebody to provide for free 
here, either, particularly given they'll need access to whatever 
environment and images you're debugging and reverse-engineering.

If you want a refresher in things VMS, 
<http://www.hp.com/go/openvms/doc> has the manuals.  But again, there's 
no manual for this particular task.  It's a whole lot of experience 
with tools such as PATCH, DEBUG, DUMP and related, and it's a code-slog.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-07-23, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2012-07-23 15:47:34 +0000, AlsysQ said:
>
>> I used Vax over 20 years ago, but if you have any debugging commands or 
>> other vax commands that can help me dig deeper I would appreciate it.
>

I have not yet seen the results of the anal/image which various people
have been requesting posted or the results of searching the binary for
"TWG" which was also requested. (For the latter, you could try transferring
the image in binary mode to a Linux box and run strings on it.)

You could try a variant of the set watch command posted earlier,
"$ set watch file/class=all" may give you more detailed debugging
information. As before, turn it off with "$ set watch file/class=none".

Be warned you may get a significant amount of debugging output.

> Ever the optimist, looking for the no-effort, no-cost, 
> constraints-compliant answer, eh?  The bad news (for you) is that 
> you've gotten into something that's somewhere between expensive and 
> intractable.
>
> There isn't an easy answer, and even the most straightforward approach 
> won't be easy.  Rebuilding whatever environment this package expected 
> will likely be a problem what with finding the license keys and the old 
> product kits, and the distinct possibility that the V5.3 requirement of 
> your MicroVAX 3100 model 20 hardware 
><http://h71000.www7.hp.com/openvms/hw_supportchart.html> won't boot 
> with an older VMS version, if that's necessary.  The simh VAX emulator 
> is probably the path out of that, but that can introduce other "fun".
>

In addition to this, there's still the question of certification.

To the OP: How much freedom do your certification standards allow ?

Is it a safety critical class of certification or a less strict class ?

Are you allowed to rebuild a new development system using different
versions of certified products or was your certification against a
specific set of binary images which would need to be recertified if
you change them ?

IOW, have you made sure before embarking on this rebuild that the
changes you have introduced (new VMS version, etc) have not invalidated
the original certification ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Jul 23, 4:13=A0pm, AlsysQ <blackware...@gmail.com> wrote:
> On Monday, July 23, 2012 10:05:03 AM UTC-5, Stephen Hoffman wrote:
> > On 2012-07-23 14:23:31 +0000, AlsysQ said:
> > &gt;
> > &gt; It is what I am trying to do, which is re-establish the
> > &gt; test/development environment. Some more info: This command (ada_pr=
obe
> > &gt; by Alsys) has two versions, the native and the cross (the vax and =
the
> > &gt; target) The command (ada_probe) on the native side (vax) works. Is
> > &gt; there a way to determine if maybe in fact what I think I am execut=
ing
> > &gt; for the target is actually for the native so ie I am executing a n=
ative
> > &gt; ada_probe in a cross environment. I am aware that ultimately, I mi=
ght
> > &gt; go to management and tell them I need wollongong, but I need so am=
mo.
>
> > That would be information which unfortunately tells me basically
> > nothing. =A0That information makes about as much sense (to me) as would=
 a
> > long and detailed series of postings on reverse-engineering VAX
> > executables using the VAX architecture definition, the VMS image
> > formats, and PATCH, DEBUG, DUMP and related tools, and using those to
> > sort out what&#39;s actually going on underneath this HP/Agilent ICE to=
ol
> > chain (to you).
>
> > Put another way, you&#39;re basically asking for a simple fix, or a
> > advanced course in VAX/VMS historical reverse-engineering. =A0That cour=
se
> > doesn&#39;t exist, though there are folks around which know how to do t=
hat.
> > =A0I&#39;d not expect a simple fix here either, other than recreating t=
he
> > environment.
>
> > You could hope to find &quot;The Guy&quot; that understands all the pie=
ces or
> > manage to get somebody onto the project that can help you
> > reverse-engineer this. =A0 &quot;The Guy&quot; you need here would prob=
ably be in
> > the form of an engineer that might still be working at Agilent or HP,
> > or (more likely) a retiree from either of these organizations. =A0An
> > engineer that actually worked on the VMS version of this ICE package.
> > Assuming anybody from the HP (now Agilent) project team is even still
> > around, obviously; this is old gear.
>
> > In the absence of &quot;The Guy&quot;, you will want to get somebody on=
to this
> > project sort out the VMS environment for you, or to reverse-engineer
> > the environment and the tools, and it&#39;s still going to be an expens=
ive
> > slog if (when) reverse-engineering the non-working code becomes
> > necessary. =A0Particularly given the likelihood that there are
> > dependencies on long-dead products and ancient versions. =A0Or you need
> > to sort out the dependencies and rebuild the lost environment.
>
> > Or you need to move to a different platform with an ICE interface (as
> > described in that Agilent document), and use the ICE tools from there.
>
> > If it&#39;s the network (and whether that&#39;s at fault here or whethe=
r
> > Wollongong is involved at all is not even remotely clear to me), then
> > you might want to see if the serial path into the ICE works better than
> > the network path.
>
> > Whomever sold you on this project to you has handed you a large mess;
> > the conflicting requirements and approved products list and the lack of
> > a preserved VMS environment. =A0But you know that. =A0Whether the ICE s=
tuff
> > is also a mess is another matter.
>
> > --
> > Pure Personal Opinion | HoffmanLabs LLC
>
> Thanks Stephen, I guess I am looking for someone who has used AdaProbe in=
 the past or Alsys. I started with this forum. Any suggestions as to a foru=
m where I would be more successful. This is for folks probably in their 50'=
s, 60's.


The HP 64000 family is a family of twenty-plus year old test gear
which was nice in its day (arguably very nice, at least from the user
point of view, in comparison with the Tek 85xx equivalent). On the
whole, it either works, or it doesn't, and if it demonstrably doesn't
work, you get the broken bits replaced if possible (by an Agilent
service agent or whoever). For a price, obviously. Put the HP64000 to
one side, it's a relatively simple (but presumably essential for
"certification" purposes) part of this picture.

VMS is a widely known (in comparison with Alsys AdaProbe) piece of
software and there are people who will be able to help you with
sorting the VMS and networking end of this mystery. You don't work for
free, they may not either.

There are many different ways of configuring a VMS system for any
given task, some of which may not fit your particular needs,
especially if it is supposed to match some mandatory but not fully
documented "certified" (by who? to what standard?) configuration. VMS
isn't a difficult OS to work with, but your employers may or may not
be wanting to pay you to learn the relevant aspects of VMS at their
expense. Or they may not have the time it would take.

The pure-VMS aspects of this mystery project *might* be amenable to
remote consultancy and support from a VMS-knowledgeable network-
knowledgeable body. These are readily available. The HP64K integration
will probably need a person with those skills, but onsite rather than
remote. This person will also ideally come with embedded systems or
host/target development experience, a combination which is not so
readily available these days.

You still haven't said where you are or what kind of security
clearance may be required for this project. Sooner or later someone
will want to know when the project starts and how long is allocated
for the task.

I'm thinking that the biggest challenge you will have is finding Alsys
Ada expertise. I'm thinking that because I was around the "embedded
meets VMS" world over twenty years ago and I'm still around it right
now (with a bit of a break in between). Sadly I'm not yet retired. Nor
am I an Alsys expert, but count yourself lucky if you find one.

Ada development was and is a small world. I have already pointed out
that the relevant parts of Alsys, if they still exist, are likely now
part of Atego. Have you checked with them yet?

Parlez vous francais? Alsys were French, you might want to see where
the French connection gets you.

If there are still any relevant people around at Atego or elsewhere,
they may not read the various forums where you have been asking for
help - here, and at least two other places I've seen. As has already
been pointed out, there's a fair chance that some of those that did
have the relevant knowledge have retired. That could be convenient -
extra cash for the retiree, near-immediate availability for you?

I would be rather surprised if anybody from the XD Ada team can help,
but can it hurt to give them a call too?

We are told by the marketeers that LinkedIn can be good for finding
obscure professional resources. You're on there aren't you? (I'm not,
but outsiders can see a profile that matches some info you've posted
elsewhere). Now might be a good time to see if it can actually deliver
on the marketing promises. Again, there's the small matter of payment
for services rendered. But does your employer want this job done or
not?

And as Simon and others have pointed out, if the folk in 1992 didn't
leave enough documentation for you to easily and exactly reproduce the
"certified" configuration, how is anybody going to be able to tell
that today's replacement configuration, once it's working, is or isn't
the same as the 1992 config? Does it matter?

This isn't going to be trivial, but it's not impossible either, given
the right resources and approach.

Best of luck.


ps
In case it's not obvious:
TWG =3D "The Wollongong Group"

On 07/23/12 15:51, AlsysQ wrote:

>
> Unfortunately, I have to use the vax 3100/20, vms 6.2, HP ICE, Alsys compiler, Alsys Adaprobe debugger etc. Yes, previous users would be great. Any ideas on which groups to contact?

I can't help with that, but where are you based ?. I used to run a Microvax
II GPX, vms 5.4 with Wollongong networking and I still have the scsi system
disk and qbus (Viking qdt) disk controller. It's not too difficult to 
build a
MVax II and I have enough parts to put the system back together, which 
was why
the disk and controller was kept. None of it has been used since around 
1993,
but only just recently dumped the disk to a Sun system to archive some 
files,
so the disk is still good. I also do embedded systems work (30+ years), so
might appreciate some of the finer points, though it is years since I used
vms on a day to day basis. My guess is, as others have said, that you 
need to
recreate the original environment if you are to have any real chance of 
getting
this working.

This isn't a plug, but if you are in the uk, would it be worth taking this
offline ?...

Regards,

Chris

On 7/23/2012 10:26 AM, Stephen Hoffman wrote:
> On 2012-07-23 14:27:15 +0000, AlsysQ said:
>>
>> Does the trace go bottom to top? ie the shell$match_wild is the start
>> of the trace?
>
> A general explanation of the access violation (ACCVIO) on OpenVMS is
> available here: <http://labs.hoffmanlabs.com/node/800>
>
> The instruction that encountered the error is listed (dumped) first in
> the stackdump, then the last-chance handler walks up the call stack
> (when the call stack is valid), which means that the error is listed at
> the top of the dump and the call stack is listed (dumped) on subsequent
> lines of the stackdump.
>
> The VAX stack builds from high addresses down to lower addresses, which
> means the layout of a stackdump is reversed from the layout in virtual
> memory.  The handler walks up the call stack (from low to high virtual
> addresses), dumping call frames out as it finds them (from top to bottom
> in the dump output).
>
> The shell$match_wild call and related code was packaged very differently
> on old VAX/VMS releases; it was part of a separate layered product known
> as DEC/shell.  In more recent VMS releases, parts of the
> now-long-retired DEC/shell product have been migrated into the C
> run-time library.  (And IIRC, the DEC/shell product will crash VMS, if
> an attempt is made to start it on a too-new version of VMS.)
>
> As for the cause of John's puzzlement, it's comparatively unusual to see
> user code listed "underneath" or "below" a VMS library call in the dump
> of a call stack.  That configuration would usually involve some sort of
> asynchronous activity, or a callback from the particular routine, or
> possibly a stack corruption.  I'm here guessing that there's a callback
> here, but I'd have to dig up and then dig through the DEC/shell
> documentation to be sure.

As near as I can determine, the shell$match_wild call as far as the C 
language is concerned does not have a call back.  There is a macro for 
shell$match_wild in the current VMS C header files that maps it to 
decc$match_wild.

This looks more like someone implemented an RPC library that could be 
linked against by an application that was written for a local system.

> In older VAX/VMS releases, it's also common to see some layered product
> code linked directly into the image.  With "more recent" layered
> products, the developers have tended to provide shareable images, and
> have usually encouraged the use shareable image code, or have only
> provided shareable images.  The code from layered product object
> libraries gets static-linked directly into the application, which means
> the application developer has to relink to load any fixes provided in a
> newer version of layered product.  Properly-constructed shareable images
> don't have the requirement to relink the application code; they are used
> to dynamically activate the most current layered product code.
>
> And what the trigger here for this stackdump might be is wide open. This
> could be a system set-up error, a change in the kernel, a missing
> layered product, or most anything else.

While I could guess as to how this works and such, and might even guess 
correctly, this is clearly a commercial product that needed some 
certification at some point in time and still needs certification.

Which means that duplicating on new hardware or an emulator, in addition 
to acquiring the required software will also require obtaining valid 
licenses for that software, and then the entire setup would probably 
need to be re-certified.

VMS 6.2 is pretty ancient, moving from 5.2 to 6.2 does not really get 
you into a much better position for support.

Regards,
-John

On Monday, July 23, 2012 4:22:25 PM UTC-5, ChrisQ wrote:
> On 07/23/12 15:51, AlsysQ wrote: > > Unfortunately, I have to use the vax=
 3100/20, vms 6.2, HP ICE, Alsys compiler, Alsys Adaprobe debugger etc. Yes=
, previous users would be great. Any ideas on which groups to contact? I ca=
n't help with that, but where are you based ?. I used to run a Microvax II =
GPX, vms 5.4 with Wollongong networking and I still have the scsi system di=
sk and qbus (Viking qdt) disk controller. It's not too difficult to build a=
 MVax II and I have enough parts to put the system back together, which was=
 why the disk and controller was kept. None of it has been used since aroun=
d 1993, but only just recently dumped the disk to a Sun system to archive s=
ome files, so the disk is still good. I also do embedded systems work (30+ =
years), so might appreciate some of the finer points, though it is years si=
nce I used vms on a day to day basis. My guess is, as others have said, tha=
t you need to recreate the original environment if you are to have any real=
 chance of getting this working. This isn't a plug, but if you are in the u=
k, would it be worth taking this offline ?... Regards, Chris

Hi Chris,
Any way to get my hands on a Wollongong. Reply to blackwaresys@gmail.com
Thanks,
Vic

On 07/27/12 20:48, AlsysQ wrote:
> Hi Chris,
> Any way to get my hands on a Wollongong. Reply toblackwaresys@gmail.com
> Thanks,
> Vic

I still have the tk50 distro tape, somewhere, but you would need to sort 
out any
licensing issues and find a drive to read it. To do that on a scsi based
microvax, you need something like a TK50Z drive. I still have one in dry 
store
somewhere, but was last powered up mid nineties to dd NetBSD boot tapes. 
May be
able to dump the tape to a sun or linux machine -> cdrom, but you then have
the problem of getting that back onto the microvax to install it. None 
of this is
straightforward because dec, like many others, used their own standards 
back then
for a whole raft of stuff including tape and disk formats.

Other than that, have you tried getting in touch with Wollongong or their
successors ?. They were somewhere in Oz, fwir...

Regards,

Chris

On 07/27/12 22:50, ChrisQ wrote:
> On 07/27/12 20:48, AlsysQ wrote:
>> Hi Chris,
>> Any way to get my hands on a Wollongong. Reply toblackwaresys@gmail.com
>> Thanks,
>> Vic
>
> I still have the tk50 distro tape, somewhere, but you would need to sort
> out any
> licensing issues and find a drive to read it. To do that on a scsi based
> microvax, you need something like a TK50Z drive. I still have one in dry
> store
> somewhere, but was last powered up mid nineties to dd NetBSD boot tapes.
> May be
> able to dump the tape to a sun or linux machine -> cdrom, but you then have
> the problem of getting that back onto the microvax to install it. None
> of this is
> straightforward because dec, like many others, used their own standards
> back then
> for a whole raft of stuff including tape and disk formats.
>
> Other than that, have you tried getting in touch with Wollongong or their
> successors ?. They were somewhere in Oz, fwir...
>
> Regards,
>
> Chris

BTW, the email address quoted above bounces the message as mailbox not 
known...

Regards,

Chris