On 3 Jul 2011, at 21:33, Johnny Billquist wrote:
No need. As soon as you switch to X-windows, you also need to switch to some X-based application. As xterm exists, it should be the obvious choice, and it works correct straight out of the box, even on a Mac.
Weelll... it sorta works.
Most of the keypad keys either do something, make EVE bitch about them being unassigned, or do unexpected things. Also, I'm still not positive that the GOLD key thing is working, nor can I find the Do key in EVE. It's not in either place the OpenVMS manual says it should be.
--
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-03 19.55, Zane H. Healy wrote:
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.
No need. As soon as you switch to X-windows, you also need to switch to some X-based application. As xterm exists, it should be the obvious choice, and it works correct straight out of the box, even on a Mac.
Johnny
On 2011-07-03 13.51, Mark Benson wrote:
Hi,
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?
Skip iTerm, and run xterm instead. You'll get all keys working the way you would expect. (I do this all the time on my Macs.)
Johnny
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..."
