Re: [Simh] Help if possible (concerns RSX11M on PDP11)

[Gary Lee Phillips]

Unfortunately, Earthlink took the unexplained action a couple of months ago
of deleting ALL personal web pages they had formerly supported for their
users. They did issue a warning that it would happen, but never apologized
or told us why. A lot of stuff was lost or at least removed from public
access.

I imagine the information you need is available elsewhere in some form, but
not being an RSX user myself, I can't offer direct help, just an
explanation of why the page you need is no longer there.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Slightly off topic: UNIX for Alpha?

[Gary Lee Phillips]

I had no idea Tru64 was available that way. Thanks for the tip. Does it not
require a key of some sort, though?

Gary, K9NZI


On Thu, Mar 12, 2020, 12:22 Supratim Sanyal  wrote:

> https://archive.org/details/compaqtru64unix51
>
>
>
> ---
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet 
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Slightly off topic: UNIX for Alpha?

[Gary Lee Phillips]

Thanks to everyone who responded to my UNIX question so quickly. Yes, I had
forgotten about the availability of BSD, which probably can meet my
requirements and I will look into both NetBSD and OpenBSD right away. The
PWS is a Miata-GL system with wide SCSI and should perform well with BSD if
I have a graphics card available that is compatible.

Gary, K9NZI

On Thu, Mar 12, 2020 at 11:41 AM Julien Savard 
wrote:

> You might want to take a look here :
>
> http://wiki.netbsd.org/ports/alpha/
> https://www.openbsd.org/alpha.html
>
>
> On Thu, Mar 12, 2020 at 12:23 PM Gary Lee Phillips 
> wrote:
>
>> Not precisely on topic here, I know. But this list shares a lot of
>> relevant knowledge and experience and I have easy access, so I'm asking.
>> Please forgive the distraction.
>>
>> I am a fairly active user of a Digital Personal Work Station (PWS) and
>> generally run OpenVMS on it. I have a body of my own code for amateur radio
>> antenna and signal modeling, etc. written primarily in Fortran. Looking at
>> this unhappy end-of-life situation for hobbyist OpenVMS, I'm wondering if
>> there is a UNIX available for that processor that doesn't require me to
>> purchase an expensive license.
>>
>> Linux would also be acceptable, but the only Linux I found a couple of
>> years ago that supported the Alpha was Gentoo, and that one didn't work all
>> that well. It had no graphical interface, for one thing. I am familiar with
>> UNIX and shell commands, that's not a problem. However, I do make use of
>> graphical output and having no working XWindows is an issue. Debian used to
>> have an Alpha port, but apparently that is no longer supported. There was a
>> Windows NT for Alpha and I even have a copy, but it's very old and limited,
>> and I have no Fortran or C compiler for it.
>>
>> DEC's own Tru64 UNIX would probably be ideal, but I have no idea whether
>> it can be obtained any more or will run without an unobtainable license
>> key. Any UNIX or UNIX-like system that can run GNU compilers or similar
>> will probably work for me.
>>
>> Any thoughts on this? Comments welcome. Thanks.
>>
>> Gary, K9NZI
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Slightly off topic: UNIX for Alpha?

[Gary Lee Phillips]

Not precisely on topic here, I know. But this list shares a lot of relevant
knowledge and experience and I have easy access, so I'm asking. Please
forgive the distraction.

I am a fairly active user of a Digital Personal Work Station (PWS) and
generally run OpenVMS on it. I have a body of my own code for amateur radio
antenna and signal modeling, etc. written primarily in Fortran. Looking at
this unhappy end-of-life situation for hobbyist OpenVMS, I'm wondering if
there is a UNIX available for that processor that doesn't require me to
purchase an expensive license.

Linux would also be acceptable, but the only Linux I found a couple of
years ago that supported the Alpha was Gentoo, and that one didn't work all
that well. It had no graphical interface, for one thing. I am familiar with
UNIX and shell commands, that's not a problem. However, I do make use of
graphical output and having no working XWindows is an issue. Debian used to
have an Alpha port, but apparently that is no longer supported. There was a
Windows NT for Alpha and I even have a copy, but it's very old and limited,
and I have no Fortran or C compiler for it.

DEC's own Tru64 UNIX would probably be ideal, but I have no idea whether it
can be obtained any more or will run without an unobtainable license key.
Any UNIX or UNIX-like system that can run GNU compilers or similar will
probably work for me.

Any thoughts on this? Comments welcome. Thanks.

Gary, K9NZI
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] HPE has started emailing the final hobbyist licenses

[Gary Lee Phillips]

Yes, just received mine from Hari. And yes, the key ends in 301 and does
not contain the hobbyist number.

I'm curious about the possibility of backing down to VMS 5.0 or 4.4 as a
long-term solution. Are there installation files or ISO available
somewhere? I started with VMS back in the 80s using 4.4 on a VAX 8200 and a
MicroVAX II. It seems to me that the system was already pretty serviceable,
aside from the need for third party extensions to get TCP/IP in place of
DECNet.

What is the earliest version of VMS available for the Alpha? Anyone know?

Gary, K9NZI
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] OpenVMS Hobbyist Program

[Gary Lee Phillips]

Yes, quite important seems to be an understatement. HPE is dropping the
program, apparently because the OpenVMS product line is now the
responsibility of VSI. But I can find no sign that VSI will continue the
hobbyist license program in any form. Those of us with actual
Alpha/Itanium/Vax hardware may be completely shut out?

I own two Alphas and also run Vax on Simh. This is not amusing. VSI appears
to be focused on OpenVMS for x86 processors, which is fine if they can do
that. But without a way to renew license keys our Alpha and Vax systems
will be dead silicon. I don't require support or even patches. I just need
to keep my systems running.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Gary Lee Phillips]

It could, but the error message should make that clear. If the compiler
rejects the syntax that's a different message from a linkage error.

I wrote working system code in VAX Pascal but it was back in the 80s. Some
of my work was accepted for publication in fact. I also did some
substantial work in Turbo Pascal at about that time. But to be honest, I
haven't touched Pascal for years now. Even so, I do know that VMS Pascal
will support the language standards just as it always did. The problem with
writeln is likely to be non-standard syntax, as Turbo Pascal accepted a lot
of short cuts. I suspect the big issues with the project in question are
more likely going to be related to graphics.

--Gary


On Thu, Feb 8, 2018 at 7:10 AM, Tim Shoppa  wrote:

> Could the writeln issue, be a link time and not compile time? I remember
> having to specify the Pascal runtime libraries (more than one?) at link
> time.
>
> Tim
>
> > On Feb 8, 2018, at 7:51 AM, Gary Lee Phillips 
> wrote:
> >
> > VMS Pascal conforms to the language standards. So does Turbo Pascal, if
> the code is written to standard.
> >
> > The problem with porting in Pascal comes when language extensions are
> used. These are often proprietary and/or hardware specific. On OpenVMS much
> of the extended capability depends on calling system libraries, all of
> which are supported. Turbo Pascal was designed specifically for the IBM PC
> and "compatible" systems, and contains a lot of proprietary extensions that
> will not be recognized by VMS Pascal's compiler.
> >
> > If your code depends on graphic functions, the ones in Turbo Pascal are
> almost entirely peculiar to that environment and will require a lot of
> rewriting. These use custom libraries that come with the compiler, and
> probably most can be duplicated by using OpenVMS system calls in some
> format. Some analysis will be required to identify the hardware specific
> code and select appropriate substitutions.
> >
> > As for "free pascal" there are several incompatible implementations that
> go by the name, so I'm not sure what you have used. However, all of them
> pretty much support the original language definition and code that stays
> within that standard definition will work without translation. Extensions
> that use library calls or custom units are going to be the area that
> requires (possibly a lot of) work.
> >
> > The full VMS Pascal manuals are available in PDF form online and you
> should begin there.
> >
> > By the way, VMS Pascal definitely supports writeln. It also has record
> structures, etc. Those are all part of the standard language definition.
> We'd need to see a sample of your code that doesn't work in order to figure
> out where your problem comes from.
> >
> > ___
> > Simh mailing list
> > Simh@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] anyone know how to convert/translate turbo pascal to vax pascal?

[Gary Lee Phillips]

VMS Pascal conforms to the language standards. So does Turbo Pascal, if the
code is written to standard.

The problem with porting in Pascal comes when language extensions are used.
These are often proprietary and/or hardware specific. On OpenVMS much of
the extended capability depends on calling system libraries, all of which
are supported. Turbo Pascal was designed specifically for the IBM PC and
"compatible" systems, and contains a lot of proprietary extensions that
will not be recognized by VMS Pascal's compiler.

If your code depends on graphic functions, the ones in Turbo Pascal are
almost entirely peculiar to that environment and will require a lot of
rewriting. These use custom libraries that come with the compiler, and
probably most can be duplicated by using OpenVMS system calls in some
format. Some analysis will be required to identify the hardware specific
code and select appropriate substitutions.

As for "free pascal" there are several incompatible implementations that go
by the name, so I'm not sure what you have used. However, all of them
pretty much support the original language definition and code that stays
within that standard definition will work without translation. Extensions
that use library calls or custom units are going to be the area that
requires (possibly a lot of) work.

The full VMS Pascal manuals are available in PDF form online and you should
begin there.

By the way, VMS Pascal definitely supports writeln. It also has record
structures, etc. Those are all part of the standard language definition.
We'd need to see a sample of your code that doesn't work in order to figure
out where your problem comes from.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Raspberry Pi 3 with tun/tap causes XQ to fail (Wilm Boerhout)

[Gary Lee Phillips]

I will note that I have been playing with the 4.0 beta simh vax on a Pi
Zero in just the last few days. I have had no errors on the self-test, and
no difficulties with the networking when running OpenVMS. Note that the Pi
Zero has no Ethernet port, but simh works when the XQ device is bridged
with the WiFi on the Raspberry Pi host. It also works (TCP only) when using
"attach XQ nat: ..." as documented.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] OpenBSD on Simh VAX 3.8-1 - Segmentation fault

[Gary Lee Phillips]

Long time ago. It was probably Slackware 9. And as Mark says, the makefile
needed a lot of tweaking and I'm not real proficient at C stuff so it took
me a lot of fumbling around. The simh version was 3.8 or perhaps even
earlier. Slackware didn't have much in the way of precompiled packages at
the time.

When I moved from Slackware to Debian things got a whole lot easier for the
most part. When I was still working I had some forced experience with
RedHat and (eeeww) UnixWare, but I find Debian much more straightforward
and reliable. I use the Mint variant because I like the desktop and user
interfaces.

--Gary




> On Thu, Nov 9, 2017 at 2:00 AM, Mark Pizzolato  wrote:
> > On Wednesday, November 8, 2017 at 9:43 PM, Gregg Levine wrote:
> >> Hello!
> >> Gary which release  of Slackware Linux was this? I've found that SIMH
> >> properly builds on all releases from 7.2 (Which was only released as a
> Snap
> >> Shot Disk from the time of the first shows) all the way the 14.1.
> >> I only needed to figure out how to update the LibCap library so that
> >> networking would work properly once that arrived not too long ago. As an
> >> aside I moved away from trying to build it here on this laptop running
> 14.2
> >> 64bit, because networking requires a fixed connection, not WiFi.
> >
> > His issues might not have much to do with Slackware, but more to do
> > with the version of simh.
> >
> > The github simh code (4.x) has built easily on most systems for a very
> long
> > time.
> >
> > Simh 3.9 was reasonable as well but not as robust as the current code.
> >
> > Simh 3.8-x might have needed local customizations relating to the
> > local system environment.  The folks putting together the debian and
> > other simh packages certainly messed with the makefile.
> >
> > - Mark
> >
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: OpenBSD on Simh VAX 3.8-1 - Segmentation fault

[Gary Lee Phillips]

A short answer to Dave's question. I am running Linux Mint, but not the
very latest version. I imagine the most recent version does have 3.9 in it.
Since 4.0 is still marked "beta" it is probably not included.

Further details: Linux Mint is derived from Ubuntu which in turn is derived
from Debian. If packages are upgraded at the head of the stream, it is at
least supposed to "trickle down" to the dependent distributions. The
differences from Debian to Ubuntu to Mint are largely related to user
interfaces rather than to actual software packages, as I understand it. So
if upgraded versions get into Debian, they will appear in subsequent
releases of the descendents.

I confess I've grown lazy in my old age here. Mint issues LTS (long term
support) versions that are supported for up to five years now. Since most
of what I do is not bleeding edge, I've stopped rushing to upgrade the
entire OS every time a new version comes out. I'm running 17.1 of Mint
here, and I believe they are up to 19.x now.

Including concise "cookbook" style instructions is always useful *if* they
can be counted on to work. That can be the rub. I fully understand that
developers can't always test everything on every possible hardware and
software platform.  Mark's succinct directions are great, but would be even
better if a list of environments in which they have been tested were to be
attached.

As a negative example, I recently tried someone's "concise" instructions
for building an emulated environment to run/test Android apps on Linux. I
know Android developers do this regularly, and often even do their
development on Linux. However, these instructions were a disaster. They may
have worked on some specific system, but they exploded here and I'm still
picking out bits of debris that were left all over the file system.

--Gary

On Wed, Nov 8, 2017 at 10:40 AM, Hittner, David T [US] (MS) <
david.hitt...@ngc.com> wrote:

> So two follow on action items, now that the problem seems to be solved:
>
>
>
> 1) How can we work with this Linux vendor to provide a baseline SIMH 4.0
> package instead of the older SIMH 3.8-1 package?
>
>
>
> 2) Should the instructions for downloading and building the latest SIMH
> that Mark provided be included in the FAQ (under Linux hosts)?
>
>
>
> Dave
>
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] OpenBSD on Simh VAX 3.8-1 - Segmentation fault

[Gary Lee Phillips]

Thanks for the very clear answer, Mark.

I followed your instructions and the 4.0-0 beta built in minutes. Last time
I tried to build Simh myself, it took several frustrating days of patching
the makefile and changing references. That was on Slackware Linux and
several versions back of both the environment and Simh. So thanks ever so
much to the developers who have continued to enhance and tune this package.
It is brilliantly done.

Now the even better news. The vax3900/vax module in 4.0-0 beta does not
have the segmentation fault I encountered with 3.8-1. OpenBSD 5.7 is able
to ftp and sftp transfer in and out without any complaints. So thank you
again to whoever it was that found and fixed that problem.

--Gary


On Wed, Nov 8, 2017 at 1:50 AM, Mark Pizzolato  wrote:

> Hi Gary,
>
> On Tuesday, November 7, 2017 at 5:29 AM, Gary Lee Phillips wrote:
> > I am running VAX 3.8-1 on a 64-bit Linux system. It performs well
> > with OpenVMS as the operating system. But when I try to run it
> > with OpenBSD 5.7 there are issues.
> >
> > The base system installs and boots correctly. But in order to bring
> > in tools such as language compilers or editors, it is necessary to
> > use ftp or sftp. I cannot get these to transfer anything because the
> > moment a transfer starts, no matter which mode or direction or
> > whether the transfer is initiated from within OpenBSD or from the
> > outside, an immediate segmentation fault occurs. This appears to
> > be within the SimH code itself, and not on OpenBSD.
>
> That would certainly seem to be the case.  Simulator crashes
> definitely should be fixed.  3.8-1 was released some 8 years ago,
> and 3.9 was some 6 years ago.  Both are way behind the current
> code base located at https://github.com/simh/simh/ downloadable
> as https://github.com/simh/simh/archive/master.zip
>
> > The same SimH VAX environment running OpenVMS 7.3 can
> > perform transfers over ethernet without any apparent issues.
>
> This is a useful data point.
>
> > I have tried running SimH in supervisor mode or in user mode,
> > same results. Also same results whether the transfer is initiated
> > by root or by a normal user account.
>
> I wouldn't expect you to be able to run the simulator as non-root
> and have Ethernet functionality...
>
> > The ethernet connection itself seems to be working. Telnet
> > connections function normally, and ftp or sftp will pass directory
> > information and accept commands, but file transfers fail.
> >
> > I guess I could try another version of OpenBSD. Upgrading SimH
> > is also possible but a bit more daunting since 3.8 is what is offered
> > as current on my Linux distro. (Linux Mint 18 "Sarah" 64 bit generic
> > 4.4.0-97)
>
> It really isn't particularly daunting:
>
> First, you'll need the following:
>
> $ sudo apt install libpcap-dev
> Then:
> $ wget https://github.com/simh/simh/archive/master.zip
> $ unzip master.zip
> $ cd simh-master
> $ make vax
> $# Start the newly built simulator:
> $ BIN/vax
>
>
> If you see any sort of segmentation fault, there is a problem that needs
> fixing, and I'll be glad to address it.   If you have a problem please
> create
> an issue at https://github.com/simh/simh/issues
>
> - Mark
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] OpenBSD on Simh VAX 3.8-1 - Segmentation fault

[Gary Lee Phillips]

I am running VAX 3.8-1 on a 64-bit Linux system. It performs well with
OpenVMS as the operating system. But when I try to run it with OpenBSD 5.7
there are issues.

The base system installs and boots correctly. But in order to bring in
tools such as language compilers or editors, it is necessary to use ftp or
sftp. I cannot get these to transfer anything because the moment a transfer
starts, no matter which mode or direction or whether the transfer is
initiated from within OpenBSD or from the outside, an immediate
segmentation fault occurs. This appears to be within the SimH code itself,
and not on OpenBSD.

The same SimH VAX environment running OpenVMS 7.3 can perform transfers
over ethernet without any apparent issues.

I have tried running SimH in supervisor mode or in user mode, same results.
Also same results whether the transfer is initiated by root or by a normal
user account.

The ethernet connection itself seems to be working. Telnet connections
function normally, and ftp or sftp will pass directory information and
accept commands, but file transfers fail.

I guess I could try another version of OpenBSD. Upgrading SimH is also
possible but a bit more daunting since 3.8 is what is offered as current on
my Linux distro. (Linux Mint 18 "Sarah" 64 bit generic 4.4.0-97)

Anyone using OpenBSD 5.7 successfully?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] OpenVMS 7.3 and Python

[Gary Lee Phillips]

Thanks to Dave L and Dave H for the suggestions.

Yes, I see python 1.4 (or maybe 1.5, the notes are not clear) on the decus
disks. That might do, though I was rather hoping for a 2.x version. Python
2.5 appears on the next decus distribution, but only for Alpha and
Integrity, so that upgrade must have been where the port to VAX failed.

I have two hardware Alphas here, but they are in a closet and not in use
because of the fan noise and high current consumption. As my usage is
purely hobbyist now, I generally use SimH VAX instead.

I'll see if the 1.4 version will work for me.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] OpenVMS 7.3 and Python

[Gary Lee Phillips]

Does anyone know of a version of Python for OpenVMS 7.3 on VAX?

I have seen the versions for Alpha and IA64, and remarks stating that the C
runtime library on the 32 bit version of OpenVMS is "hostile" to Python.
However, I have seen Python (perhaps not the latest and greatest, but
certainly Python) on 32 bit Linux machines. Could the 32 bit open source
Python not be ported to VAX OpenVMS?

I have not personally had much luck with GNV or other porting mechanisms,
but I'm really not a C programmer either. I can work in several languages
but not C.

Thanks for any information.
--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DECserver (terminal server) emulation?

[Gary Lee Phillips]

Surely a SimH PDP or VAX on another host (or even the same one) could
provide a well-featured MOP server?

--Gary

>The DS500 is a PDP-11, true. But it's also the model that don't have any
>local storage, and thus uses MOP in way more ways than any other DS,
>which might be a problem unless you have some machine with a proper MOP
>implementation.
>The MOP server that exists for Unix systems will not do. It only
>supports booting.
>
>Johnny
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX 8200

[Gary Lee Phillips]

Looking at what images I can find on the web, TU-80 seems correct. The one
we had was just generally flaky, I guess. It was 1600 bpi, 2400 foot tapes,
yes.

The MicroVAX we added later came with a TK-50 that never had any problems.
That came in when a second unrelated project was added that required a VAX
because code for it was written by a partner company that used DEC
equipment exclusively.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX 8200

[Gary Lee Phillips]

On Fri, Mar 17, 2017 at 11:05 AM, Paul Koning 
wrote:

>
> FWIW, I just saw a comment that some IBM systems (early 360, perhaps) had
> a habit of inserting short gaps into the middle of tape records because of
> memory latency issues.  Apparently IBM's drives could read such stuff but
> other people's drives would not, fair enough since such tapes are not
> standards-compliant.
>
>
Our IBM stuff was (IIRC) 3084 by that time, or if not, a dual 370 set up. I
don't remember ever trying to do data interchange on tape with the IBM
systems using that particular drive. When that need came up later on we
deliberately avoided DEC hardware for the second tape drive and got a stand
alone drive unit that was vertically mounted with vacuum columns. I don't
remember the maker's name, but it worked as expected, never required a
service call, and read or wrote any brand of media we used.

In any case, the issue I had was that the particular drive on the 8200
would not read back tapes written even by itself. We used it only for
backups from the hard drive. DEC support was called in several times to
adjust, calibrate, test, etc. It worked best only with DEC-branded media
and if the heads were cleaned before every single use, and finally they
just shrugged and said "Use only our media." Of course, theirs cost about
twice what we paid for the large bulk quantities of 9 track tape used in
the IBM center on the floor below. It wasn't my problem at that point, and
my boss just ordered some tapes from DEC.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX 8200

[Gary Lee Phillips]

Ethan Dicks  wrote:

>That's earlier than is possible... the model was introduced in Jan,
>1986.  Don't know date of first ship.

Well I did say "around 1985 or so." After 30+ years, I'd say that was a
pretty close guess.

The tape drive was not TK50. It was standard reel to reel media, horizontal
like an studio audio tape deck, with a cover that had to be lifted in order
to use it. The disk drive was housed in the same cabinet in a drawer below
the tape unit. The tape drive was "finicky" and seemed to work only with
tapes ordered through DEC. The standard tapes our much larger IBM shop used
never read back correctly when written on it.

I was not party to the administrative decision to purchase the VAX, but it
was related to some joint ventures that required a kind of real time
connectivity that IBM equipment could not provide. I enjoyed the
opportunity of learning and working with the hardware and providing system
support but wasn't involved in the application end much. After a couple of
years, the project was terminated without any end result, and I moved to
other employment just before that happened but kept the VMS bug in my blood.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX 8200

[Gary Lee Phillips]

In fact there's very little evidence on the web that the 8200 ever existed.
The first VAX I ever worked with (around 1985 or so) was an 8200 and there
was a point where I was convinced I had remembered the model ID incorrectly
because I could find nothing about it online. Then I found a promotional
button in my desk drawer, rectangular with rounded corners, that had a
photo of the floor-standing unit and the text "VAX 8200" on it. So I knew
it had existed. Must not have been a lot of them sold, though.

Anyway, yes, the console was an oddity. So was the terrible vacuum-less
tape drive built into the cabinet. We eventually purchased a real drive
with vacuum columns because you could never count on reading a backup tape
again after it was written. The system ran VMS 4.4 and performed reliably
otherwise. We eventually added a Microvax II and a PDP-11 to the complex.
The PDP ran RSX and operated as a routing link between the IBM mainframes
with JES2/MVS/TSO and the DECNet nodes. I even published an article about
using a custom symbiont to make the mainframe print queues look like a
regular VMS printer queue on the VAXen.

That was a galaxy long ago and far away. It would be fun to see a working
8200 in SimH, but sounds like a major job reconstructing it.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DECWRITE backup set

[Gary Lee Phillips]

To complete the information for you, Timothe, I did get the VMSINSTAL
to run successfully on two SimH VAX setups. There was a complaint
issued about a missing license for the "lexicon" which suggested to me
that perhaps the spelling checker won't work.

Although DECWrite is installed, and appears on the menus in
DECWindows, it does not run. I remembered that you (or someone else?)
said that a bug in the program means that the CMKRNL privilege is
required to run it, and I did make sure I had that before attempting
it. I also tried running it under the SYSTEM account, which should
sidestep any issues with privilege. From the point of view of the
DECWindows user, nothing happens when the program is launched.

The error message logs, however, do indicate a clear problem. During
initialization, the following error message appears:

%DCL-W-ACTIMAGE, error activating image XDPS$DPSLIBSHR

Without knowing what this image is, I am guessing that something else
had to be installed first. I don't see any suggestion that another
product was needed beyond DECWindows itself, though.

The connection and DECWindows itself do work as expected. I can run
other built-in applications without difficulty. Perhaps someone on the
list has more information about this problem?

I'm still hoping to get hold of the Alpha version of this package to
see if it will work there.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DECWrite for OpenVMS Alpha?

[Gary Lee Phillips]

Thanks, Timothe. Now I'm really impressed that these things are still
hanging around. I believe 3.1 is the last version, and English
language is all I need. Is one of these British and the other
American? Either would do, but the American version is slightly
preferred.

On 17 Feb 2016 17:34:15, Timothe Litt wrote:
>Which of these would you like?
>
>|DECwrite for OpenVMS VAX   3.1VVFAA 1   [DECWRITE031]||
>||DECwrite for OpenVMS VAX   3.1VVFEA 1   [DECWRITE031]||
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DECWrite for OpenVMS Alpha?

[Gary Lee Phillips]

Thank you so much, Jeremy. When you have time, please let me know what
you can find. I really appreciate it.

>I have a collection of installation media, there should be VAX and Alpha
>versions there somewhere.  I'll see what I can find on the weekend.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] DECWrite for OpenVMS Alpha?

[Gary Lee Phillips]

I see that the hobbyist license PAKs include DECWrite. I'm pretty sure
the installation files are not included in the downloads, though.

Does anyone have an installation file or media they could share? Alpha
preferred. I have two Alpha systems (DS-10 and PWS.) Both have CD-ROM
drives but no tape drives, with OpenVMS 8.3 installed and running..

For usability testing and comparisons I could settle for a VAX version
that will run on the SimH MicroVAX 3900 emulation with OpenVMS 7.3, if
necessary.

I assume HP no longer actually supports this software so there's not
much point in trying to buy the media from them.

Thanks for any suggestions.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] loading file

[Gary Lee Phillips]

If you have the PAK file that comes from the hobbyist distribution, it
is in fact written in DCL format so it is executable as a .COM
procedure.

Make sure the file is set executable, then run it from the command
line by putting an @ at the beginning of the file name. If the file is
complete and uncorrupted, it issues all the license updates for you,
and removes any expired licenses at the same time.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] SimH and multi-core host processors

[Gary Lee Phillips]

I just looked through the introductory documents and found no mention
of running SimH emulations on hosts with multi-core processors. Is
SimH aware of the fact that it is running on such a CPU?

I downloaded the OpenBSD for vax CD image yesterday. Having a
Raspberry Pi 2 Model B sitting here and not getting much use, I
decided (probably foolishly) to use it to install OpenBSD to a vax
disk image file. I have SimH 3.8.1 on the Pi, which has an ARM V7 quad
core processor and 1GB of RAM. I had copied my VAX configuration file
over from a single core Linux machine, and modified that to set up for
the OpenBSD install.

Normally on a single core 32-bit machine I use "set throttle 60%" to
avoid overloading the system if the SimH emulated machine becomes
compute bound or starts idle looping.

I was surprised at how slow the OpenBSD installation routine ran. In
fact, once I got it going, it has been running for over 24 hours now
and is still unpacking required system files from the compressed tar
(.tgz) archive files on the CD. Progress is made, but slowly. Tonight
it dawned on me to check the CPU utlization meter on the Linux host.
Sure enough, with only the installation running on SimH, the CPU was
limited at 15% utlization and would not go above that level. If one
core is 25% of the whole CPU capability, and I use only a maximum of
60% of one core, that comes out to 15%, the point at which the system
throttles back whether it is busy or not. So, I'm guessing, if I
remove the "set throttle" statement from the configuration, the
maximum CPU capability SimH will use for a single instance is still
limited to 25% of the machine's total capability. Does that make
sense?

I will test this myself, but can't do so until I finish with
installing OpenBSD.

Is there any way to get a single instance of SimH to run across
multiple cores? Or is it just single threaded so it is limited to
running on a single core at any time?
--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Off topic: ULTRIX question

[Gary Lee Phillips]

>If you want to run on a VAX or Alpha, I don't think Linux even is an
>option. You'll have to go with some BSD. NetBSD and OpenBSD both have
>support, although if we talk VAXen, I think the support is slightly
>better in NetBSD.

There is still Linux for Alpha, Johnny, though it's beginning to age
from lack of supporters. Debian for Alpha exists up through "Sid" I
think. CentOS also had an Alpha version last time I looked. I have run
the Debian versions and they pretty much work as they should. I've
never seen Linux for VAX at all, that's true.

I'm not personally concerned with security patches, as my machines are
not usually on the net at all. I live in a rural area where
connectivity is costly and not to be wasted. I use the machines mostly
for mathematical and engineering experiments and personal amusement.
I'm a radio amateur, and the Alphas are real nice for circuit
simulations and RF modeling, for instance. Fortran does pretty well
there. I raised my question because though the "unsupported
distribution tape" for ULTRIX 4.0 includes Gnu EMACS as a source
archive, it was clearly not actually ported or tested (as in, make
fails immediately despite README claiming otherwise.)

Since downloading large files is next to impossible here, I try to
know what I'm getting into before forking over $60 for a set of
distribution CDs. One of the BSD flavors might suit, but it's very
difficult to be sure from the descriptions that are offered. Clearly
VAX or Alpha aren't exactly high on their priority lists. Current
pages on both BSD sites link to non-existent pages on HP sites, for
instance.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Off topic: ULTRIX question

[Gary Lee Phillips]

Also, no Solaris for the VAX or Alpha at all.

OpenBSD has been on my radar, though I find all their versions and
installation information really confusing. Some sources seem to
indicate that OpenBSD runs and is supported on VAX as well as Alpha,
but the versions referenced in VAX commentary appear to no longer be
available. The Alphas are listed on the current distribution media,
but since my primary installation target would be a Personal
Workstation/Miata box, it's not clear whether the CD images will work
on that as they are not listed as bootable there. Evidently they will
work for the DS10, but I don't usually run that due to power
consumption and fan noise.

Anyway, thanks for the information everyone. I see we've filled up an
entire digest with this now and it's really off topic (I think) for
SimH so I'll continue my quest elsewhere.

--Gary
P.S. I do run SimH, obviously, with OpenVMS and now ULTRIX for what
that's worth.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Off topic: ULTRIX question

[Gary Lee Phillips]

As far as I know, Solaris these days only runs on Intel hardware. I've
tried it there, and it seems to devote way too much processor power
and memory to making pretty windowed screen displays (a weakness it
shares with most Linux distributions.)

I guess I didn't make it clear that I'm looking for UNIX to run on VAX
or Alpha hardware platforms.

On 7/12/15, Jordi Guillaumes i Pons  wrote:
>
>> El 12/07/2015, a les 13:52, Gary Lee Phillips  va
>> escriure:
>>
>>
>> I keep looking for a way to get a "real" UNIX going, hence the ULTRIX
>> experiment. As far as I can tell, neither Tru64 nor HP-UX have any
>
> Wouln’t solaris qualify as a “real” UNIX?
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Off topic: ULTRIX question

[Gary Lee Phillips]

Thanks Clem and Johnny for at least confirming what I suspected. I
worked with VMS on Vaxen in the 80s, At the time I wished for an
opportunity to compare VMS with UNIX on the same hardware. In the 90s
I worked with UNIX, mostly AIX on RS/6000. Today I mostly use Linux,
though I have a couple of Alphas in working order. I run OpenVMS and
Linux on those.

I keep looking for a way to get a "real" UNIX going, hence the ULTRIX
experiment. As far as I can tell, neither Tru64 nor HP-UX have any
kind of hobbyist licensing program available and I am just "playing"
with stuff at this point, I was looking for another way to get at UNIX
here at home. ULTRIX appears feasible, but even the documentation is
less complete than what we have for OpenVMS. Finding installable
versions of tools like EMACS is a real snipe hunt.

Also, thanks to everyone for the discussion on processor history and
development over the last week or so. It has been very interesting.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] Off topic: ULTRIX question

[Gary Lee Phillips]

I have ULTRIX 4.0 working on Simh VAX (the 3900 I think, the default
is) and that's fine. I don't need to worry about which VAX model for
my purposes. Since it's under discussion, though, can anyone point to
a forum or mailing list where ULTRIX is still discussed?

I have questions about compiling/porting BSD programs to ULTRIX.
Thanks for any pointers to knowledgeable folks. I've searched, but
every forum I come up with seems to have been inactive for nine or ten
years.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX XQ and wireless networking

[Gary Lee Phillips]

Well, just to confirm what I thought I remembered:

I tried again to set up bridging, and it is not possible using the
method that works for wired ethernet. That is, I define a bridge br0
using the brctl command (as root of course) and then add interfaces to
the bridge. I can add eth0 without difficulty, just as on other
machines. But if I try to add the wireless interface wlan0, the
command is rejected:

can't add wlan0 to bridge br0: Operation not supported

I have used iptables (and earlier versions of the command, ipchains or
ifwadm) to set up software firewalls before, and even to NAT ip
addresses, but I've never seen a way to make it change a MAC address.
Even if I had, I have no idea how to apply that to the output of the
SIMH XQ device. Are you saying I should create a tun device or
something similar to which XQ0 can be attached, and then re-route
packets from that device to wlan0 by using iptables?

I believe if IP were working, then DECNET can be routed or
encapsulated over IP. But in this particular case, DECNET is
inessential if I have working IP. The working IP tools and clients are
sufficient. And I thought DECNET Plus didn't need to mess with MAC
addresses anyway. Isn't it just DECNET IV that does that?

On 11/17/12, TJ Merritt  wrote:
> The TUN interface will get the packets injected into the system, but
> will not get them bridged across the wireless network which uses the MAC
> address for managing the wireless network.  Since your MAC address for
> the virtual interface is not the same as the mac address for the host,
> reply packets over wireless will get dropped.  The trick is to get the
> packets to go out with the host's MAC address and replies routed back to
> the virtual interface.
>
> VirtualBox does this by sending packets out with the original IP address
> but the MAC address of the host, they then record the virtual interface
> that the IP address came from, when the reply packet comes back, they
> use the IP address to look up the virtual interface associated with that
> IP address and route the packet to that interface.  There are special
> cases of course for things like broadcast, multicast, and IP addresses
> that are shared between multiple VM's.  VirtualBox does not currently
> support IPv6 addresses though. This would also not help for DECnet.
> This is effectively a layer 3 switching capability that works around the
> lack of layer 2 switching in the wireless network.
>
> Another approach would be to setup NAT so that the NAT layer can take
> care of the MAC address rewriting.  It will also rewrite the IP address
> though.  If this is satisfactory, you there should be plenty of NAT
> resources available to you on Mint such that no code writing is
> required.
>
> Adding virutal networking support for wireless networks would be a major
> undertaking for SimH, but if done, could eliminate most of the hiccups
> with virtual networking over wireless networks.
>
> Of course, not of these issues occur over wired netowrks.
>
> -- TJ
>
> On Sat, 2012-11-17 at 15:24 -0500, Dan Gahlinger wrote:
>> It works...
>> use the TUN interface and the bridging, works just fine.
>>
>>
>> Dan.
>>
>>
>> > Date: Sat, 17 Nov 2012 14:14:24 -0600
>> > From: tivo.ov...@gmail.com
>> > To: simh@trailing-edge.com
>> > Subject: [Simh] VAX XQ and wireless networking
>> >
>> > Is this even possible? I have SIMH 3.9 on Linux Mint 12, running the
>> > VAX with OpenVMS 7.3. It works great, except for networking. The
>> > hardware is ASUS EeePC with Atheros AR5001 wireless network adapter
>> > and Atheros L2 Fast Ethernet adapter.
>> >
>> > I have libpcap version 1.1.1 (which is also callable as version 0.8)
>> > installed on Linux. The VAX module was compiled with networking
>> > enabled.
>> >
>> > The configuration file has an "attach xq0 wlan0" or "attach xq0
>> eth0"
>> > depending on which interface I'm trying to use. With the wired
>> > ethernet (eth0) I am able to use both TCP/IP and DECNET Plus. With
>> the
>> > wireless (wlan0) neither one works.
>> >
>> > I've tried disabling the DECNET IV compatibility mode, which was
>> > recommended in one source for wireless compatibility, and also tried
>> > adding "set xq xx-yy-zz-aa-bb-cc" (with the actual MAC address of
>> the
>> > wireless adapter) to the configuration. The first did nothing I
>> could
>> > discern, and the second generated an error message during startup of
>> > the SIMH module, saying that the MAC address was already in use and
>> > could not be assigned.
>> >
>> > Obviously the workaround is to use a cabled connection when the VAX
>> > emulator is needed, but this isn't very practical in most cases. Is
>> > there any other possibility I've overlooked?
>> >
>> > I notice that this is a frequently found question when using Google
>> to
>> > look for answers, but I found no responses other than the two
>> > solutions mentioned above. I suppose a different network card
>> > emulation for VAX could make the wi-fi adapter look like a normal

Re: [Simh] VAX XQ and wireless networking

[Gary Lee Phillips]

Might be some peculiarity of Ubuntu or my two Dell desktop PCs, but
the system logs do in fact show that they are waiting for the tun0
device to close down and that it is "busy". I've waited as long as 30
minutes after the SIMH module was closed, and still no shutdown for
Linux.

The desktop machines have SIMH 3.8 rather than 3.9, which might also
make some difference.

I will try the bridge again, but previous attempts on the laptop
failed to work for either the host or the guest system, using the same
sequence of steps to set up the bridge that work with the desktop
machines and wired ethernet.



On 11/17/12, Dan Gahlinger  wrote:
>
> actually that's exactly what you DO need to do.
> I do this myself with a wireless wlan interface and it works just fine.
> you need the bridge and attach to the TUN/TAP interface.and as the other
> post mentioned bridge the wlan interface
> the unreleased bridge port certainly will not keep the entire host from
> shutting down,I have no idea where you got such a crazy idea.
> it works just fine for the two systems I run this on wireless.
> I think this could even be made to work niceless on a raspberry pi rig.
> imagine that a vax-cluster of wireless embedded systems, very cool.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX XQ and wireless networking

[Gary Lee Phillips]

I should have mentioned that I've tried setting up bridging and taptap
without success when using the wireless interface. I use it on my
desktop PCs (wired ethernet and Ubuntu) where it works OK though it's
very cumbersome to start up and shut down.

I thought the main advantage of a bridge was the fact that it lets the
host and the emulated machine speak directly to one another via
network packets, and that's a feature I don't really need in this
case. Using the serial port emulation with a VT100 emulation over a
tcp/ip socket is adequate and works well.

On the desktop machines, the taptap module seems to have a tendency to
"hang" on shutdown, even though the SIMH emulation has been closed
down normally. The unreleased bridge port will keep the entire host
from shutting down and requires a forced power off, which isn't very
nice.

On 11/17/12, Dan Gahlinger  wrote:
>
> It works...use the TUN interface and the bridging, works just fine.
> Dan.
>
>> Date: Sat, 17 Nov 2012 14:14:24 -0600
>> From: tivo.ov...@gmail.com
>> To: simh@trailing-edge.com
>> Subject: [Simh] VAX XQ and wireless networking
>>
>> Is this even possible? I have SIMH 3.9 on Linux Mint 12, running the
>> VAX with OpenVMS 7.3. It works great, except for networking. The
>> hardware is ASUS EeePC with Atheros AR5001 wireless network adapter
>> and Atheros L2 Fast Ethernet adapter.
>>
>> I have libpcap version 1.1.1 (which is also callable as version 0.8)
>> installed on Linux. The VAX module was compiled with networking
>> enabled.
>>
>> The configuration file has an "attach xq0 wlan0" or "attach xq0 eth0"
>> depending on which interface I'm trying to use. With the wired
>> ethernet (eth0) I am able to use both TCP/IP and DECNET Plus. With the
>> wireless (wlan0) neither one works.
>>
>> I've tried disabling the DECNET IV compatibility mode, which was
>> recommended in one source for wireless compatibility, and also tried
>> adding "set xq xx-yy-zz-aa-bb-cc" (with the actual MAC address of the
>> wireless adapter) to the configuration. The first did nothing I could
>> discern, and the second generated an error message during startup of
>> the SIMH module, saying that the MAC address was already in use and
>> could not be assigned.
>>
>> Obviously the workaround is to use a cabled connection when the VAX
>> emulator is needed, but this isn't very practical in most cases. Is
>> there any other possibility I've overlooked?
>>
>> I notice that this is a frequently found question when using Google to
>> look for answers, but I found no responses other than the two
>> solutions mentioned above. I suppose a different network card
>> emulation for VAX could make the wi-fi adapter look like a normal
>> ethernet interface, but apparently that hasn't been done yet and it's
>> probably beyond my very rudimentary C coding abilities.
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] VAX XQ and wireless networking

[Gary Lee Phillips]

Is this even possible? I have SIMH 3.9 on Linux Mint 12, running the
VAX with OpenVMS 7.3. It works great, except for networking. The
hardware is ASUS EeePC with Atheros AR5001 wireless network adapter
and Atheros L2 Fast Ethernet adapter.

I have libpcap version 1.1.1 (which is also callable as version 0.8)
installed on Linux. The VAX module was compiled with networking
enabled.

The configuration file has an "attach xq0 wlan0" or "attach xq0 eth0"
depending on which interface I'm trying to use. With the wired
ethernet (eth0) I am able to use both TCP/IP and DECNET Plus. With the
wireless (wlan0) neither one works.

I've tried disabling the DECNET IV compatibility mode, which was
recommended in one source for wireless compatibility, and also tried
adding "set xq xx-yy-zz-aa-bb-cc" (with the actual MAC address of the
wireless adapter) to the configuration. The first did nothing I could
discern, and the second generated an error message during startup of
the SIMH module, saying that the MAC address was already in use and
could not be assigned.

Obviously the workaround is to use a cabled connection when the VAX
emulator is needed, but this isn't very practical in most cases. Is
there any other possibility I've overlooked?

I notice that this is a frequently found question when using Google to
look for answers, but I found no responses other than the two
solutions mentioned above. I suppose a different network card
emulation for VAX could make the wi-fi adapter look like a normal
ethernet interface, but apparently that hasn't been done yet and it's
probably beyond my very rudimentary C coding abilities.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] what is the recommended way to config network for simh/VAX

[Gary Lee Phillips]

Phil's instructions are still good. I have SIMH VAX running on Ubuntu 10.04
and 10.10 just fine.

The problem, I suspect, is that you installed the SIMH package provided by
Ubuntu. That one does not include network capabilities. It was compiled
without them (and the description does warn of that.) You must compile your
own copy from source and specify that you want ethernet drivers included.
And you must have the libpcap package installed as well.

SIMH VAX with networking works fine then, either with taptap or without it.

--Gary

Date: Wed, 07 Sep 2011 22:26:29 -0700
> From: Ron Young 
> To: simh@trailing-edge.com
> Subject: [Simh] what is the recommended way to config network for
>simh/VAX
> Message-ID: <20110908052629.82C53A031@ron-amd64.localdomain>
>
>
> Hi All:
>
>   I recently upgraded my ubuntu box to version 10.10 and I'm trying to
>   get openvms/vax (hobbyist 7.2 CD) to use networking with simh
>   3.8.2-rc2. Since I haven't played with vms for many years, I'm using
>   Phillip Wherry's web page as an installation guide
>   (http://www.wherry.com/gadgets/retrocomputing/vax-simh.html)
>
>   I'm confused on what is the correct method to configure the
>   network. I've tried several different approaches with no success
>   (and some like bridging with taptap as described at
>   http://www.retrocomputinggeek.com/retrowiki/SIMHNetworking/ ended
>   up "hanging" the interface -- no fun when working remotely).
>
>   Does anyone have a straight-forward procedure (config files, specific
>   packages, etc) that is known to work?
>
>   my setup is:
>
>  ubuntu 10.10 (32bit) Linux 2.6.32-33-generic-pae
>  simh-3.8.2-rc2 (from the downloaded zip file simhv38-2-rc2.zip)
>  wired ethernet interface (eth1 ip: 192.168.2.xx/24).
>
>  Downloading the taptap.c version referenced on the
>  retrocomputinggeek.com webpage results in an empty file/blank page
>  in browser).
>
>  I tried two different versions of taptap: taptap-1.0.tar.bz2
>  (http://www.munted.org.uk/programming/taptap/) and taptap-modified.c
>  (http://www.itsecuritygeek.com/files/taptap-modified.c)
>
>   Any help would be greatly appreciated,
>
>   thanks
>
>   -ron
>
>
> ===
> Ron Young   r...@embarqmail.com
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 90, Issue 16

[Gary Lee Phillips]

Thanks for the detailed explanations. I do have access to much of the
standard VMS documentation, though most of what I have is for version
5.x. Knowing what the parameters on SET TERM should mean is not
usually the problem, though occasionally the manuals will be overly
terse. (As in "Set the XYZ parameter to turn on XYZ" without any
explanation of just what XYZ meant to VMS.) Much of the OpenVMS 7.3
documentation was available on the HP support site until recently, but
now it seems to have disappeared or at least to have been moved so
that all I am finding is for the Alpha 8.3 version. Most, but not all,
of that should still apply I think.

My comment about secrets and hints was more related to the behavior of
SIMH and the VAX emulations based on it. What I have seen for the DZ
(DH11) and VH (DHV11) emulated devices is extremely terse and doesn't
really tell you what signals will be sent or honored between OPENVMS
and the virtual device, or how those are translated into TELNET
protocol. Hence my careful testing of each possible parameter in as
many combinations as possible. That is faster, in my case, than trying
to read the source code to puzzle it out.

I did report earlier in the thread that the Operator log records a
"timeout waiting for input" when using the DZ virtual device for any
session after the very first one. This is what the 20-30 second delay
is. At the terminal window in telnet, however, it appears that input
is just not being accepted. The keyboard is dead for that 20-30 second
interval, and no prompt has yet appeared on the screen. Somewhere in
the handshake between VMS, the VAX emulation, and the device
emulation, there is a mismatch so that VMS seems to think it has sent
a prompt but the telnet screen doesn't display one, and telnet input
is apparently not getting through to VMS. After the timeout takes
place, then you get a login prompt by pressing enter and everything
proceeds as it should. When you logout, the timeout issue returns for
the next session. I would expect that setting the -am options on the
pseudodevice in vax.ini should take care of this by making all lines
act like modem connections, but it seems to make little difference.

The VH virtual device does not suffer from this apparent bug. However,
it seems to have no way to limit the number of terminal lines it
activates, and always generates a full 32 terminals as if four DHV11
cards were installed.

In all cases with both devices, whether the terminal is set AUTOBAUD
or NOAUTOBAUD, it still does not prompt for login until the enter key
has been pressed (and actually received, in the case of DZ, which is
"deaf" during the timeout period.)

--Gary

On Mon, May 23, 2011 at 1:05 PM, Timothe Litt  wrote:
>
> VMS is actually pretty well documented; this stuff isn't as mysterious as
> folks seem to think.
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problems compling SIMH

[Gary Lee Phillips]

Looks like you're missing the header files for libpcap. I don't run
RedHat so I have no idea where they may have stashed them. You may
have to add a separate "developer" package to get them, or they may be
already there, just not where the compiler is looking.

Check /usr/local/include and if there's no pcap.h or pcap subdirectory
there, then check /usr/include for the same. If they are in
/usr/include then change the "/usr/local/include" in the makefile to
"/usr/include" instead.

If the files aren't there, you'll have to find out where they are.
Something like

find  /usr  -name pcap.h  -print

And if that finds nothing, then you'll need to consult a RedHat
expert, as I'm out of ideas.

--Gary

On Mon, May 23, 2011 at 10:22 AM, Joe Ambrose  wrote:
> Gary,
>
> Libpcap was installed, the libpcap.a file is in /usr/lib not usr/local/lib.
>
> I'm adjusting the makefile and.
>
> It still bombs out
> The command used for the network is
>
> NETWORK_OPT = -DUSE_NETWORK -isystem /usr/local/include /usr/lib/libpcap.a
>
> The error I'm getting.
>
> sim_ether.c: In function `eth_write':
> sim_ether.c:1070: warning: implicit declaration of function
> `pcap_sendpacket'
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problems compling SIMH

[Gary Lee Phillips]

The BIN directory has to exist before you can "make" though I'm not
sure it has to be that way. I'm no wiz on makefiles, but I'm sure the
directory could be created if it didn't already exist.

Your other problem with libpcap is a bit more complicated. On Ubuntu,
and presumably Debian as well since they are so closely related, you
need to install the development package of libpcap, not just the
shared libraries. That would be something like libpcap-dev or
libpcap0.8-dev.

Also, once this is installed, you need to find out where it put the
file libpcap.a (not libpcap.so) and make sure that path will be
searched in the makefile.

The default location searched is /usr/local/lib but Debian and Ubuntu
put the file in /usr/lib instead. I just edited the makefile to change
that location to the correct one. Then everything was fine.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

Amusingly enough, when I disable the DZ, then the VAX has 32 TXnn
terminals. But after setting the four VH units to MODEM and HANGUP in
SIMH, performance is much better.

It seems there are a lot of undocumented hints, kinks, and pitfalls.
But at least it's now functional for my current purposes, so thanks to
everyone who helped.

--Gary

On Sat, May 21, 2011 at 12:38 PM, Mark Pizzolato - Info Comm
 wrote:
> On Saturday, May 21, 2011 at 8:29 AM, Gary Lee Phillips  wrote:
>> OK, interesting. Here's what I learned by trying the "VH" device
> (that's a
>> DHV11, right?)
>>
>> Though it is supposed to represent 8 lines, it created 16 terminal
> devices in
>> VMS. There are 8 TTnn devices and 8 TXnn devices. I believe these are
> all
>> programmed I/O, so the load on the processor increases as it has to
> poll all
>> those ports. There does seem to be a noticeable slowdown in response.
>
> The TTnn devices are the DZ devices which are enabled by default.
> Use:
>
>    Sim> set dz disabled
>
> To turn them off...
>
> While you are disabling the DZ devices, you can also disable any other
> devices you aren't using...
>
> - Mark
>
>
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

OK, interesting. Here's what I learned by trying the "VH" device
(that's a DHV11, right?)

Though it is supposed to represent 8 lines, it created 16 terminal
devices in VMS. There are 8 TTnn devices and 8 TXnn devices. I believe
these are all programmed I/O, so the load on the processor increases
as it has to poll all those ports. There does seem to be a noticeable
slowdown in response.

However, with default terminal settings it does work much more
sensibly. Telnet to the designated port brings up a login prompt
immediately upon pressing ENTER. After a logout, the telnet session is
not disconnected unless you close the telnet application. However, you
can reuse that same telnet session without closing it, by just
pressing ENTER again to bring up a new login prompt. In other words,
the telnet client looks like a dedicated serial terminal and behaves
accordingly.

I see the VH device allows individual lines to be programmed as
"modem" and "disconnect" which probably means that if those options
are combined with SET TERM/MODEM on the VAX itself, the sessions will
actually disconnect on logout more like a normal telnet session. I'll
have to try that. The main drawback to VH is the fact that it creates
way more virtual terminals than I need and seems to have an impact on
VMS performance. As a workaround, though, it certainly is better than
the way DZ seems to operate at the moment.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

Thanks, Mark. I was planning to try the VH emulation this weekend, in
fact. I'd held off because I wasn't sure I could use a Qbus device
with the Microvax emulator, and thought I might have to build the
11/780 emulation instead.

I have more information on the DZ, too. After much blind and random
experimenting, I found that using this command on the VAX side will
make the TTAx ports behave in a somewhat more predictable manner:

SET TERM TTAx -
  /MODEM -
  /DIALUP -
  /HANGUP -
  /DISCONNECT -
  /NOAUTOBAUD -
  /PERMANENT

Note that these settings go away when the VAX is rebooted, so they
probably should be added to SYSTARTUP_VMS.COM or some other script
that will reset them after a boot.

By setting those flags for each of the ports on the DZ, I get a
consistent result. The telnet session is completely disconnected on
logout, closing the telnet window, and no _TTAx process is left
hanging around on the VAX side. The remaining issue is some slowness
in getting up a prompt when first connecting, and that may be related
to what you've described here. I find that it takes 20 to 30 seconds
for the login prompt to appear after pressing the ENTER key, but after
that everything works well.

I'll give the VH a try, possibly today.

--Gary

On Sat, May 21, 2011 at 8:40 AM, Mark Pizzolato - Info Comm
 wrote:
> Hi Gary,
>
> The strange behavior with the delays is due to the "_TTAx" processes
> which are running.  I recall seeing these types of issues when we
> connected real VAX terminal ports to each other (for purposed of serial
> networking and/or simple Kermit or other access with there weren't
> working network connections).  The "_TTAx:" processes where created when
> one side started sending something and a login process got started.  We
> called the phenomena the "Who-Huh" problem.  Each computer was sending a
> "Username" prompt (aka "who") at each other and ultimately the other
> system didn't recognize the "Username:" prompt as a username on its
> system so it rejected the login attempt (aka "Huh").
>
> In any case, this certainly shouldn't be happening on DZ ports.  I am
> exploring the precise cause in the DZ emulation and will eventually have
> a fix.
>
> Meanwhile, the absolutely easiest "work around" to achieve your goal of
> host to VAX login access is to use DH Ports instead of DZ ports.  The DH
> emulation does not have this bug.  This would be achieved by:
>   sim> set vh enable
>   sim> attach vh 8501
>
> - Mark Pizzolato
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

On Fri, May 20, 2011 at 1:20 PM, Phil Mendelsohn  wrote:
> On 11-05-20 01:11 PM, Gary Lee Phillips wrote:
>
> This smells like the right area to be poking around in, but I seem to recall
> an awful lot of VTs that were wired just TX, RX, and ground and they just
> worked.  The handshaking lines were never sufficient and often not even
> necessary to make things play nice, IIRC.
>
If I remember correctly, you had the usual configuration options on
the terminal port. That means if you told the VAX (or the DZ) to
ignore hardware handshaking and use only XON/XOFF, it would do so.
Serial connections were the rule rather than the exception back in the
70s and 80s, so I'm sure it worked as specified back then with the
real hardware.

The only terminals we ever had attached to serial ports on our VAXen
were the operator consoles, though. The programmer and user terminals
were several floors away and used short serial links to a terminal
server that then connected to the hosts using LAT over a thick
Ethernet backbone.

At home I do have a real VT220 and an Alpha workstation. The VT220 is
connected to a serial port on the Alpha and operates as a console and
a user terminal, but I'm using a cable with all the handshake signals
intact. It works well enough.

I can also use that to telnet to the virtual VAX running on a separate
Linux box, and it operates as a proper VT220 there. Fun and great for
nostalgia, but pretty cumbersome to boot another computer up just to
use it as a character cell terminal. The Alpha and its disk tower use
a fair amount of extra electricity, too.

At work I also have an Alpha running, but it has been pressed into
"temporary" service as a proxy server (temporary now starting to look
indefinite after 7 months) and even though I own that hardware myself,
I can't easily mess with it for my own purposes right now. Hence the
current sticking point with DZ, since I'm running both Linux and SIMH
on my desktop workstation. I could (can, I've tested) ssh to the
Alpha, which is also running Linux now rather than OpenVMS, and then
telnet back to the emulated VAX, but something else that worked more
elegantly within the desktop PC itself would certainly be preferable.
;p

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

On Thu, May 19, 2011 at 6:37 PM, David Holland
 wrote:
>
> Bridge devices, and veth type devices will work wonders to get the VAX on
> the LAN.
>
The virtual interface and bridge trick ought to work, but I first
rejected it as unnecessarily complicated. Last night I tried to get it
working, but without success. After creating a br0 "device" and the
two linked "veth" interfaces, and connecting eth0 to veth0 through the
bridge, and making sure all of them were "up" I still ended up with
the same situation as before. Both the virtual VAX and the real Linux
box have access to the LAN and internet under separate IP and MAC
addresses but using the same NIC. Neither is able to see or
communicate with the other.

The virtual VAX is connected to veth1, and the link to veth0 and br0
must be working because the VAX still has connectivity. It just can't
connect to the Linux system, nor the Linux system to it.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

On Fri, May 20, 2011 at 12:43 PM, Bucher, Andreas (Andreas)** CTR **
 wrote:

> Nevertheless, this is a crude workaround only, there should be either some 
> settings in VMS to change that behaviour, or something in SIMH is not 
> behaving correctly, hiding the disconnected state of the terminal and making 
> VMS thing that nothing changed.
>

I did discover this approach last night. It's crude, but it works. I
agree that the problem could be VMS itself, or maybe the hardware
being emulated really misbehaved this way (though I doubt that.) I
think it more likely to be an oversight (bug) in the design of the DZ
interface emulation. The original hardware connected to serial lines,
and no doubt understood DTR, RTS, DSR, etc. So if you really
disconnected your terminal, by dropping the DTR, the interface should
have cleared immediately. Since the emulation is using a TCP link, it
may not translate the disconnect into a signal that the VMS system
recognizes as a disconnect, hence we get the timeout period instead.

Thanks for going to the trouble of confirming the behavior, though. At
least that lets me know it isn't peculiar just to my setup, and that's
useful information.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

On Thu, May 19, 2011 at 6:37 PM, David Holland
 wrote:
> If all you're wanting to do is simply telnet into the VAX...
>
> Assuming a recent Linux kernel
>
> Bridge devices, and veth type devices will work wonders to get the VAX on
> the LAN.
>
> See:
>
> http://comments.gmane.org/gmane.comp.emulators.simh/420  (or search the
> archives)
>
> As a good starting point  Obviously, I've used them at one point..
>

Thanks, but the VAX is already on the LAN. That isn't the issue. I
compiled with network support, and the XQ device is attached and
working. The thing is, the host machine has only one NIC. The VAX and
the Linux system share the NIC well enough, each with its own IP
address and MAC address. Connecting from an outside, independent
machine is fine and works for both systems just as if they were
separate, real machines. Both can also originate connections to other
points on the LAN or the Internet. The problem comes when I want to
connect to the virtual VAX from the host Linux system. That cannot be
accomplished by a normal LAN connection because they can't see each
other: when one has control of the NIC, the other does not. I thought
this was the main use of the DZ emulator, as I read the description.
It makes a telnet connection to a port on the host operating system
look like a serial port connection on the VAX side. Thus it allows
direct terminal access from the host machine to the virtualized guest
system. It also works even if the SIMH-VAX module was compiled WITHOUT
actual network support, and I've used it that way in the past.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

On Thu, May 19, 2011 at 12:03 PM, Jason Stevens  wrote:
> I'd try the 'modem' setup for the DZ ... I recall something similar
> with Unix/32v
>
> set dz lines=16
> att dz -m 2311
>

Well, that sounded promising, but as far as I can tell, it made no
difference at all.

After a telnet session to the DZ port 8501, no matter how it
terminates, the unit remains locked up for several minutes and cannot
connect to the VAX emulation again. Eventually a security error is
reported to the OPA0 terminal, saying that no input could be obtained
from TTA0 and the connection has timed out. Then it is possible once
again to connect through port 8501 for another session.

Sessions work fine while they are connected. The issue is
disconnecting and being able to reconnect. There appears to be some
failure in handshake between the DZ emulation and the VAX driver, such
that the closed telnet session, even if a hangup was sent, remains
active (virtual DSR asserted, maybe?) for some length of time. This
would be OK if the DZ emulation itself rotated through the available
lines, sending the next connect request to line 2, and the next to
line 3, and so forth, but it doesn't do that. As far as it is
concerned, line 0 is now clear and the next SYNC results in a new
connection to line 0. But the VAX driver isn't accepting that
connection, or so it seems.

The timeout seems to vary, anywhere from five minutes to fifteen or
more. In one case the line was still tied up after sitting unused
overnight.

Just to clarify, as there seems to be some confusion, I want to use
the DZ emulation to allow terminal sessions that originate on the same
host box that runs the SIMH software to connect to the emulated VAX.
This is not possible if the emulation and the host share the same NIC,
but it can be done by going through the DZ, which provides a
host-based port number. I am not trying to connect an actual VT
terminal, and I don't see that the DZ emulation is really intended to
do that. As for LAT, I found it cumbersome to use even when I had a
real VAX and a real terminal server. It doesn't seem appropriate to
this particular situation at all.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] VAX DZ terminal controller unit?

[Gary Lee Phillips]

I'm running SIMH 3.8 on Ubuntu 10.04 with OpenVMS 7.3 from the OpenVMS
Hobbyist CD.

The emulation seems to be working well for almost everything I've
tried, except that using the DZ device causes some odd behavior.

In my vax.ini file I have:

SET DZ LINES=8
ATTACH DZ 8501

When the VAX emulation is booted, it is possible to "telnet localhost
8501" (or use a telnet client from another machine to port 8501 on the
emulation host) and get a login prompt. This works as expected for one
session. However, after logging out it is no longer possible to
connect again. When I try, I get as far as

Connected to the VAX simulator DZ device, line 0

But pressing ENTER or CTRL-P or any other key never brings up a login
prompt. Sometimes after a few minutes it will work again, but not
always. If I leave the "dead" session connected and try to start
another instance of the telnet client, that connects to "line 1" and
works, but once it is logged out, line 1 is no longer usable. And so
forth...

Something is not being reinitialized. I've tried "logout/hangup" and
"logout/nohangup" and using the telnet client to send break signals
and other out-of-band communications, but nothing seems to revive the
line.

I may well be missing something here. Any advice?

Note that with TCP/IP installed and working on the OpenVMS system, a
standard telnet connection to the emulator still works correctly, but
this doesn't allow a terminal connection from the emulator host
machine itself. It only works from another machine since both IP
addresses are hosted on a single NIC in the emulator host.

Thanks for any help you might offer.

Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] LK keyboards, anyone?

[Gary Lee Phillips]

You can find LK keyboards on Ebay pretty regularly, though I consider
the prices too high most of the time ($50 and up once you pay
shipping.) I have also been told that any of the keyboards with PS/2
or USB connectors will work, including LK411 as well as the ones you
mention.

Since I also have an actual Alpha desktop workstation, I attached a
real VT220 terminal to it and will often use that to get a standard
keyboard.

I'm not sure what the options are with Windows unless you use Cygwin
to get Linux/UNIX type code running.

On Linux, you can start with an xterm window and telnet or ssh from
there. The xterm software has a VT220 keyboard compatibility that maps
the standard PC keyboard to provide the missing keys with ALT or SHIFT
combinations. Another option is a script called "vmsterm" that can be
found in various places on the web. This calls xterm for you, feeding
in the keymap changes as command line parameters. I use that with SimH
and it's pretty handy. The default mapping setup does map NumLck to
the GOLD/PF1 key, though, so on most keyboards the num lock light will
go on and off. I just ignore it.

You can set your editors on VMS to use the WPS keypad rather than the
EDT version. That's the EVE default, actually, though probably most
users override to get EDT. With WPS you don't need a GOLD key, or you
can map the GOLD key somewhere else.

The bigger problem with mapping a PC type keyboard to use DEC coding
is the "missing" key in the keypad. It has to be mapped to something
else. (PC numeric keypads have 17 keys, while DEC terminals have 18.)
The vmsterm script moves the "keypad minus" to the PC "Pause/Break"
key. Most VT220 emulations will let you choose whether to map the
"PgUp" and "PgDn" keys to match the PC keyboard labels or to match the
DEC key positions (which makes "End" the DEC "PgUp" key.)

Hope this helps,
--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Batch vs interactive

[Gary Lee Phillips]

The answer depends on what machine you are emulating and with what
operating system. Something like a VAX with OpenVMS has a lot of
tuning parameters within the operating system for balancing batch and
foreground priorities. Most systems that had simultaneous batch and
interactive operation were set up in this way. But the controls are
internal to the operating system software, not to the hardware itself
and therefore not in the purview of SIMH settings.

Or did you mean that you are letting something run on a SIMH emulation
and it gets in the way of doing other things on your host machine?
There is a setting to control the percentage of the host CPU that is
used by most SIMH emulators I've tried, though I don't know whether it
is active in all of them:

SET THROTTLE xx%

This command given at the SIMH command prompt limits the amount of CPU
that can be taken up by the SIMH emulation at any time to xx% of the
whole.

It will not, however, balance between batch and interactive processes
running within the emulation. Those will both be slowed down by an
equal amount. Tuning that balance requires internal settings in the
emulated environment.

--Gary
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh