Using PersonalAlpha, Charon, and other container files

PersonalAlpha and Charon container files will work just fine with FreeAXP, as will container files created for SimH VAX or for the VMS LDDRIVER.

If you are attempting to boot a PersonalAlpha or CHARON-AXP system container file using FreeAXP, you may need to make the following changes to achieve a successful boot:

• Disable any CHARON utilities like the Idle Loop or Accelerator. As with real Alpha hardware, these extensions will cause a boot check in OpenVMS.

• PersonalAlpha's NIC device shows up as ESA0. FreeAXP's NIC device shows up as EWA0. If booting from a PersonalAlpha image, you may need to reconfigure Ethernet, LAT, and DECnet.

Don't forget when moving container files between emulators, that Tru64 UNIX V4 and V5 use different formats for AdvFs domains. An AdvFs domain created under V5.X as type '4' can't be read under V4.0x which only understands type '3' domains. If you are unsure of which AdVfs domain type you have, showfdmn( will tell you.

If you need 'small' legacy disks less than 1G in capacity, such as the RZ24, RZ24L, RZ25, RZ25M or RZ35, you'll need to create the containers manually and disklabel them appropriately.

For example, to create an RZ24 sized container: From within Unix create a file exactly 209813504 bytes long (that is 409792 * 512 byte sectors, ~204Mb), then export (copy/ftp) it to the host where the emulator runs. Configure the emulator to see your 'RZ24' as one of its containers, start the emulator and boot Tru64, then find the disk (scu or hwmgr), and disklabel it as an RZ24 something like this :

# disklabel -rw rz2 RZ24
or
# disklabel -rw dsk5 RZ24

John M

SimH is another good way to create container files of any desired size. Review the SET and ATTACH commands in the SimH documentation.

simh.trailing-edge.com/

< class='quote'>[b:]Bruce Claremont wrote:[/b:]
• Disable any CHARON utilities like the Idle Loop or Accelerator. As with real Alpha hardware, these extensions will cause a boot check in OpenVMS.

To be a little bit more specific here:

If the Stromasys IDLE tool (V1.1 or V1.2) is installed on the system disk, which is being booted by FreeAXP, the following will happen:

&gt;&gt;&gt; B DKA0

OpenVMS (TM) Alpha Operating System, Version V7.3-2
© Copyright 1976-2003 Hewlett-Packard Development Company,L.P.

halted CPU 0
halt code = 7
machine check while in PAL mode
PC = ede0
&gt;&gt;&gt;

If the SRM environment variable AUTO_ACTION is defined as RESTART, a MCHECKPAL crash will be written and the system will try to reboot.

This happens when the special SYS$IDLE.EXE execlet is being loaded by SYSINIT. It seems to issue the WTINT PAL code instruction, which seems to not be supported by FreeAXP.

The easiest way to prevent SYS$IDLE from being loaded is by clearing bit 0 (SGN$V_LOAD_SYS_IMAGES) in the SYSGEN parameter LOAD_SYS_IMAGES during a conversational boot:

&gt;&gt;&gt; B -fl 0,1 DKA0
SYSBOOT&gt; SHOW LOAD_SYS_IMAGES ! default is 7
SYSBOOT&gt; SET . 6
SYSBOOT&gt; C

This allows the IDLE tool to be easily turned off and on, if you switch the system disk between PersonalAlpha/CHARON and FreeAXP. Note that clearing bit 0 of LOAD_SYS_IMAGES may also disable other alternate execlets specified in VMS$SYSTEM_IMAGES.DATA from being loaded.

If you want to permanently switch to using FreeAXP, you could also completely remove the IDLE tool using: PRODUCT REMOVE IDLE. For additional information, please see SYS$HELP:IDLE*.RELEASE_NOTES

Volker.

I have just completed my first install of FreeAXP (Beta 271) on a new Core i3 laptop. The laptop is running Win 7 Home premium 64 bit. This is the first emulator installation I have performed on this machine.

Up until now, I have been using PersonalAlpha from Stromasys and have installed PersonalAlpha on several Windows computers under XP, Vista 32 and Win7 32 bit versions.

Not wishing to perform a fresh OpenVMS installation and configuration from scratch for my FreeAXP evaluation, I had used a copy of my existing PersonalAlpha 4gb disk container file (dka0.vdisk). The FreeAXP installation was problem free and I was subsequently able to boot OpenVMS using this container file. I was also able to login using the console and used TCPIP$CONFIG.COM to recognise EWA0 as the NIC device. This allowed me to telnet into the system from another Windows computer on my home network. So far so good..... until I ran into an application I/O related failure.

I have now moved further details on this problem to another thread entitled "%BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP"<hr>