At 12:51 PM +0100 7/3/11, Mark Benson wrote:
I use a Mac OS X machine and the native Terminal.app with telnet or SSH to access my OpenVMS boxen. Fior the most par tit works fine with a VT100 terminal emulation to the VMS terminal. I have a problem with EVE however. Mac's do something silly with the numeric keypad, it's locked to numbers (rather than scroll) and the Numlock key doesn't do anything sensible. As a result using the 'GOLD' key and pretty much all the action keys in EVE becomes impossible. Anyone got any suggestions, or am I just going to have to wing it or use my Linux box?
Use X-Windows and modify your keybindings so that they match what VMS expects. It's a lot harder to do on the Mac, but it is possible.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
On 2011-07-03 11.14, Mark Benson wrote:
On 2 Jul 2011, at 14:19, Johnny Billquist wrote:
Curiousity is good. The thing you emulate is the thing that is visible at the disk contoller layer. So anything beyond that will (probably) be different from the thing you emulate. When you emulate a uVAX with an RA92 disk, simh will present you with a emulated KDA-50, on which there appears to be an RA92 connected. In the real world, the KDA-50 runs some sort of microcode, and communicates with the disk over SDI, which is a serial protocol using four coaxial cables. And the SDI protocol defines how the KDA-50 gets the RA92 to do all kind of operations.
One of these days I want to have a good look at a real VAX, they are such a departure from anything I've used :) Interesting that they use a serial disk communication system - where've I seen that crop up recently? ;)
Yeah, SATA and SAS is just really DECs SDI warmed over, except DEC did it 30 years ago, and did it better. SDI was the low level between disk and controller. The controller in turn talked a very low-level agnostic protocol called MSCP that was designed to handle all kind of disks in the same way, with command queuing, reordering, possible bad block handling for disks that didn't do that, and I don't even know what else. Controllers that talk MSCP to the computer were implemented that has SDI as the back end, but also there are also those with MFM, SCSI, DSSI, CI, networks and probably some other interface used as the low level connection to disks as well. But all that is totally hidden from the computer, who only understands MSCP.
But none of that is emulated, and there is no real point in emulating it.
So essentially you are only emulating the minimum needed to keep the VAX microcode and after that OS happy and working 100%.
Not even that. Why emulate the VAX microcode? Instead you emulate the VAX instructions, with your own "microcode" that does not look like the microcode of any existing VAX, but which works best for the platform where you are running your emulator. Programs running on the VAX are not aware of the microcode either.
(Maybe you are confusing microcode with machine code?)
Good to hear things are working now.
As for telnet vs. ssh. Well, ssh is safer, in that people can't sniff passwords easily over the network. If you worry about people doing that, then you might want to not use it. However, if your network is secure, then telnet isn't really an issue.
Inside my own network that's not an issue. Accessing it from the internet, not such a good idea. I can SSH the NetBSD side though so I may just settle with using the 'local terminal' via screen and ssh when using the internet.
So, you just block telnet traffic from the rest of the world in a firewall, so that you need to ssh to an intermediate box you have control of, and then you can telnet from there to the simh VAX. Good enough.
Johnny
On 2 Jul 2011, at 14:19, Johnny Billquist wrote:
No, they should not. The raw unformatted size is not something that is *ever* visible outside of the disk, and when you emulate the disk, you are not emulating the unformatted magnetic platters, but a block formatted device.
I see.
Curiousity is good. The thing you emulate is the thing that is visible at the disk contoller layer. So anything beyond that will (probably) be different from the thing you emulate. When you emulate a uVAX with an RA92 disk, simh will present you with a emulated KDA-50, on which there appears to be an RA92 connected. In the real world, the KDA-50 runs some sort of microcode, and communicates with the disk over SDI, which is a serial protocol using four coaxial cables. And the SDI protocol defines how the KDA-50 gets the RA92 to do all kind of operations.
One of these days I want to have a good look at a real VAX, they are such a departure from anything I've used :) Interesting that they use a serial disk communication system - where've I seen that crop up recently? ;)
But none of that is emulated, and there is no real point in emulating it.
So essentially you are only emulating the minimum needed to keep the VAX microcode and after that OS happy and working 100%.
Good to hear things are working now.
As for telnet vs. ssh. Well, ssh is safer, in that people can't sniff passwords easily over the network. If you worry about people doing that, then you might want to not use it. However, if your network is secure, then telnet isn't really an issue.
Inside my own network that's not an issue. Accessing it from the internet, not such a good idea. I can SSH the NetBSD side though so I may just settle with using the 'local terminal' via screen and ssh when using the internet.
I don't think that Compaq have any version of SSH for VMS om VAX, but I haven't checked if anything was shipped after 7.3.
There are other options, though. tcpware comes to mine.
I was thinking TCPWare too - seems to be the only reference I can find to SSH on 7.3.
--
Mark Benson
My Blog:
<http://markbenson.org/blog>
Follow me on Twitter:
http://twitter.com/mdbenson
"Never send a human to do a machine's job..."
On 2011-07-02 11.57, Mark Benson wrote:
On 1 Jul 2011, at 17:37, Johnny Billquist wrote:
On 07/01/11 09:33, Mark Benson wrote:
On 1 Jul 2011, at 07:46, Johnny Billquist wrote:
RA92 is 1.4G.
I think 1.6GB is the unformatted size, 1.4GB after initialize.
Well, the unformatted size is actually even bigger, at around 1.9G. But who cares about that? It is not something you can ever see or use.
Is it important for the size of the RAW virtual disk though? I haven't established of the virtual disks in SIMH need to be large enough to contain the unformatted size of the disk they are emulating?
No, they should not. The raw unformatted size is not something that is *ever* visible outside of the disk, and when you emulate the disk, you are not emulating the unformatted magnetic platters, but a block formatted device.
Since SIMH creates standard disk files itself I guess it's not a big issue. I am just curious though.
Curiousity is good. The thing you emulate is the thing that is visible at the disk contoller layer. So anything beyond that will (probably) be different from the thing you emulate. When you emulate a uVAX with an RA92 disk, simh will present you with a emulated KDA-50, on which there appears to be an RA92 connected. In the real world, the KDA-50 runs some sort of microcode, and communicates with the disk over SDI, which is a serial protocol using four coaxial cables. And the SDI protocol defines how the KDA-50 gets the RA92 to do all kind of operations.
But none of that is emulated, and there is no real point in emulating it. From the VAX point of view, you have the MSCP interface, as implemented by the KDA-50. And the emulated KDA-50 also gives you the MSCP interface. What happens beyond that is irrelevant, as far as the VAX is concerned. If it responds like a KDA-50 with an RA92 to the MSCP commands, then the VAX is satisfied.
And at that level, the RA92 is only going to show you 1.4G of disk. Always. Other properties are also true at this level. For instance, there are never any bad blocks.
And it's 1.4G after formatting, not initializing. (Atleast in DEC speak, where formatting is the low level formatting of the device, and initializing is creating a file system.)
Oh, okay. Fair point, I gotten used to stuff coming low-level formatted over the years. It's kind of a non-issue on modern systems! ;)
Not entirely. Sometimes you still want/need to do a low level format, but I agree that it is not as common, perhaps. Not that you needed to do it that much in the past either, but people still sometimes did, for various reasons.
[...]
So, you have a total blocks of 311200, which matches an RD54, yes. If your disk container is much bigger, and you haven't somehow gotten simh to restrict it, the total blocks number should match the hardware, so this would suggest that you got something wrong outside of VMS.
Yes, I agree the screw-up is in the SIMH config. What I'm not sure about is why SIMH, which had the disks configured as RAUSER (i.e. a user-defined size) value of 9600000 blocks (4.8GB at 512bytes per block) then reverted to using RD54 174MB disk sizes... odd. Perhaps I got the SET command wrong in the vax.ini I wrote, or SIMH interpreted the command wrong. I don't know.
It doesn't matter for now, I'm working with 3 RA92 images that do display the right capacity and I am up and rolling. I can telnet to a separate IP at any time and log right into VMS.
I don't know if this is a purely semantic point (i.e. because the security risk is in real terms negligible given it's a hobbyist machine) but should I be concerned about only having TELNET and no SSH? I used the Compaq TCP/IP 5.1 off the 7.3 CD-ROM. Someone mentioned a later version maybe? Does that have SSH?
Good to hear things are working now.
As for telnet vs. ssh. Well, ssh is safer, in that people can't sniff passwords easily over the network. If you worry about people doing that, then you might want to not use it. However, if your network is secure, then telnet isn't really an issue.
I don't think that Compaq have any version of SSH for VMS om VAX, but I haven't checked if anything was shipped after 7.3.
There are other options, though. tcpware comes to mine.
Johnny
On 1 Jul 2011, at 17:37, Johnny Billquist wrote:
On 07/01/11 09:33, Mark Benson wrote:
On 1 Jul 2011, at 07:46, Johnny Billquist wrote:
RA92 is 1.4G.
I think 1.6GB is the unformatted size, 1.4GB after initialize.
Well, the unformatted size is actually even bigger, at around 1.9G. But who cares about that? It is not something you can ever see or use.
Is it important for the size of the RAW virtual disk though? I haven't established of the virtual disks in SIMH need to be large enough to contain the unformatted size of the disk they are emulating?
Since SIMH creates standard disk files itself I guess it's not a big issue. I am just curious though.
And it's 1.4G after formatting, not initializing. (Atleast in DEC speak, where formatting is the low level formatting of the device, and initializing is creating a file system.)
Oh, okay. Fair point, I gotten used to stuff coming low-level formatted over the years. It's kind of a non-issue on modern systems! ;)
[...]
So, you have a total blocks of 311200, which matches an RD54, yes. If your disk container is much bigger, and you haven't somehow gotten simh to restrict it, the total blocks number should match the hardware, so this would suggest that you got something wrong outside of VMS.
Yes, I agree the screw-up is in the SIMH config. What I'm not sure about is why SIMH, which had the disks configured as RAUSER (i.e. a user-defined size) value of 9600000 blocks (4.8GB at 512bytes per block) then reverted to using RD54 174MB disk sizes... odd. Perhaps I got the SET command wrong in the vax.ini I wrote, or SIMH interpreted the command wrong. I don't know.
It doesn't matter for now, I'm working with 3 RA92 images that do display the right capacity and I am up and rolling. I can telnet to a separate IP at any time and log right into VMS.
I don't know if this is a purely semantic point (i.e. because the security risk is in real terms negligible given it's a hobbyist machine) but should I be concerned about only having TELNET and no SSH? I used the Compaq TCP/IP 5.1 off the 7.3 CD-ROM. Someone mentioned a later version maybe? Does that have SSH?
--
Mark Benson
My Blog:
<http://markbenson.org/blog>
Follow me on Twitter:
http://twitter.com/mdbenson
"Never send a human to do a machine's job..."
On 07/01/11 09:33, Mark Benson wrote:
On 1 Jul 2011, at 07:46, Johnny Billquist wrote:
RA92 is 1.4G.
I think 1.6GB is the unformatted size, 1.4GB after initialize.
Well, the unformatted size is actually even bigger, at around 1.9G. But who cares about that? It is not something you can ever see or use. And it's 1.4G after formatting, not initializing. (Atleast in DEC speak, where formatting is the low level formatting of the device, and initializing is creating a file system.)
To check free space on your disks: "SHO DEV D"
Shows only 17865 blocks free :\ That's less than 9 MB? (if my maths works out using 512byte blocks)
I played about and got a better report using SHOW DEV/FULL DUA0 (came back to me - I knew I'd read it in the handbook somewhere) which dumps:
[...]
So, you have a total blocks of 311200, which matches an RD54, yes. If your disk container is much bigger, and you haven't somehow gotten simh to restrict it, the total blocks number should match the hardware, so this would suggest that you got something wrong outside of VMS.
This is fun learning, and annoying at the same time :D
:-)
Johnny
On 1 Jul 2011, at 07:46, Johnny Billquist wrote:
RA92 is 1.4G.
I think 1.6GB is the unformatted size, 1.4GB after initialize.
To check free space on your disks: "SHO DEV D"
Shows only 17865 blocks free :\ That's less than 9 MB? (if my maths works out using 512byte blocks)
I played about and got a better report using SHOW DEV/FULL DUA0 (came back to me - I knew I'd read it in the handbook somewhere) which dumps:
Disk VAX001$DUA0:, device type RD54, is online, mounted, file-oriented device,
shareable, available to cluster, error logging is enabled.
Error count 0 Operations completed 2759
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 42 Default buffer size 512
Total blocks 311200 Sectors per track 17
Total cylinders 1221 Tracks per cylinder 15
Volume label "VAXINE" Relative volume number 0
Cluster size 9 Transaction count 150
Free blocks 17865 Maximum files allowed 15560
Extend quantity 5 Mount count 1
Mount status System Cache name "_VAX001$DUA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 1786
File ID cache size 64 Blocks currently in extent cache 1674
Quota cache size 0 Maximum buffers in FCP cache 1227
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-2, subject to mount verification, protected subsystems
enabled, file high-water marking, write-through caching enabled.
And yes, 4.8GB should be more than enough. Not sure what is going on...
What is going on is SIMH isn't accessing the full size of the files I specified. Even though I used RAUSE R disk types it seem to assume they are RD54s, which are only 172MB (confirmed: I googled RD54s and they are 173MB drives)?!
I have started with another 3-disk system using RA92s. It seems if you use a set disk type and a valid file path it will build a new file for you.
This is fun learning, and annoying at the same time :D
--
Mark Benson
My Blog:
<http://markbenson.org/blog>
Follow me on Twitter:
http://twitter.com/mdbenson
"Never send a human to do a machine's job..."
On 2011-07-01 02:02, Mark Benson wrote:
I have most of the issues with SIMH sorted out apart from one.
I ran up a couple of 4.8GB images using:
dd if=/dev/zero of=vaxvmsssys.iso bs=512 count=9600000
in Net BSD.
I then set the SIMH emulator up with:
set -L rq0 rauser=9600000
attach rq0 /sdcard/d0.dsk
Using info from here: http://labs.hoffmanlabs.com/node/922
Which was a little vague, to say the least.
It all seemed to work fine. The disk works okay. However, it ran out of space by the time I'd installed VMS 7.3 (including DECwindows/MOTIF support, which I wanted for possible future remote graphical access) and tried to install TCP/IP UCX onto the system. I don't know how to check free space on a device, so I can't see the total blocks available compared to the original dd'd file. I wouldn't have thought VMS would fill a 4.8 GB disk though? It's supposed to install comfortable on an RA92 and that was only 1.2 or 1.6 GB IIRC.
RA92 is 1.4G.
To check free space on your disks: "SHO DEV D"
And yes, 4.8GB should be more than enough. Not sure what is going on...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
My startup procedure actually does a redirect to the "5'th" NetBSD terminal. That terminal becomes the console "OPA0:".
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Jason Stevens
Sent: Thursday, June 30, 2011 19:11
To: hecnet at update.uu.se
Subject: Re: [HECnet] SIMH VAX Project
I always like to run them from screen.. Then you can attach to the console etc etc...
On Thu, Jun 30, 2011 at 6:09 PM, Steve Davidson <jeep at scshome.net> wrote:
Mark,
This is a VERY easy setup. Start your SimH process from rc.local. Be sure to put the "&" at the end of the line. I can send you what I have if need be.
Regards,
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Mark Benson
Sent: Thu 6/30/2011 08:57
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH VAX Project
> Security on BSD distributions is tight, you might need to reduce the security policies on the system. Libpcap turns the ethernet device in promiscuous mode and that may be considered harmful.
Figures. You can only run SIMH with networking as root. Might explain it.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 30 Jun 2011, at 10:56, hvlems at zonnet.nl wrote:
>
>
> Hans
> Verzonden vanaf mijn draadloze BlackBerry -toestel
>
> -----Original Message-----
> From: Mark Benson <md.benson at gmail.com>
> Sender: owner-hecnet at Update.UU.SE
> Date: Thu, 30 Jun 2011 10:26:19
> To: hecnet at Update.UU.SE<hecnet at Update.UU.SE>
> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] SIMH VAX Project
>
> "File not found" I think. Like it couldn't pick up the device.
>
> Re: Sharing a port, I don't need to talk to the host OS from the VAX emulation, I just need to access both from a third host.
>
> I will have to compile libpcap from pkgsrc but that shouldn't be an issue unless pcap needs to be present at compile time. If that is the case I just need to recompile SIMH so again no big deal.
>
> FWIW, NetBSD is not a flavour of Linux either ;) ;)
> <this is intended as a lighthearted statement>
>
> It's all good fun!
>
> --
> Mark Benson
>
> http://markbenson.org/blog
> http://twitter.com/MDBenson
>
> On 30 Jun 2011, at 09:53, hvlems at zonnet.nl wrote:
>
>> What error message did you get?
Yeah, the one thing that annoys me about screen with Terminal.app is that the window scrolling no longer works, something to do with how screen reformats the control chars..
sampsa
On 1 Jul 2011, at 01:06, Mark Benson wrote:
On 1 Jul 2011, at 00:28, Sampsa Laine wrote:
Seconded - I run GORVAX's SIMH in a screen..
Tis a good plan, I will do that when I actually get to an established production stage.
I love screen - with the right switched it can be used as a basic serial terminal too which is damned handy on a MacBook Air using a KeySpan adapter and Mac OS X - I did the re-install on my Alpha that way :) Only place it fell over was the character map went to hell when I used EVE. I may not have explicitly done a
'SET TERM/VT100' beforehand though...
--
Mark Benson
My Blog:
<http://markbenson.org/blog>
Follow me on Twitter:
http://twitter.com/mdbenson
"Never send a human to do a machine's job..."
