The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Поиск:  Каталог документации | DEC

OpenVMS Frequently Asked Questions (FAQ), Part 5/5

This posting contains answers to frequently asked questions about the OpenVMS operating system from Compaq Computer Corporation, and the computer systems on which it runs.
Archive-name: dec-faq/vms/part5
Posting-Frequency: quarterly
Last-modified: 2 Oct 2001
Version: VMS-FAQ-5.TXT(7)

This is the OpenVMS Frequently Asked Questions Part 5/5. 
Please see Part 1/5 for administrivia, indexing, archiving, etc.


------------------------------------------------------------
ALPHA1.   What do the letters AXP stand for?

While there are many fanciful "definitions" which have circulated widely,
the truth is that AXP is not an abbreviation nor an acronym; the letters
do not mean anything.  They are just three letters chosen to form a
trademark.

When it came time to chose a "marketing name" for the Alpha AXP line,
the company was in a quandary.  The internal "code name" for the project,
Alpha, was widely known and would seem the ideal choice, but it was already
in common use by a number of other companies and could not be trademarked.
A well-known "name search" firm was hired and was asked to come up with
two lists of possible names.  The first list was intended to evoke the
feeling of "extension to VAX", while the second list was to suggest
"not a VAX".  Unfortunately, none of the choices offered were any good;
for example, "VAX 2000" was found on the first list while the second list
contained "MONDO" (later to be used for a kids' soft drink).

Shortly before announcement, a decision was made to name the new line ARA,
for Advanced RISC Architecture.  However, an employee in Israel quickly 
pointed out that this name, if pronounced in the "obvious" manner, sounded 
very much like an Arabic word with decidely unfortunate connotations.
Eventually, AXP was selected; the architecture would be referred to as
"Alpha AXP" whereas products themselves would use just "AXP".

Use of the AXP term has been phased out in favour of using Alpha.  For 
example, "OpenVMS AXP" is now officially refered to as "OpenVMS Alpha".

------------------------------------------------------------
ALPHA2.   What are the OpenVMS differences between VAX and Alpha?

Very few.  As of OpenVMS V6.1, the VAX and Alpha platforms are very close
to "feature parity".  Most applications can just be recompiled and
run.  Some differences to be aware of:

    - The default double-precision floating type on OpenVMS Alpha
      is VAX G_float, whereas on VAX it is usually D_float.  D_float
      is available on Alpha, but D_float values are converted to
      G_float for computations and then converted back to D_float
      when stored.  Because the G_float type has three fewer fraction
      bits than D_float, some applications may get different results.
      IEEE float types are also available on OpenVMS Alpha.

    - Data alignment is extremely important for best performance on
      Alpha.  This means that data items should be allocated at
      addresses which are exact multiples of their sizes.  Quadword
      alignment will offer the best performance, especially for
      character values and those smaller than 32 bits.  Compilers
      will naturally align variables where they can and will issue
      warnings if they detect unaligned data items.

    - Compaq C is the only C compiler Compaq offers on OpenVMS Alpha.
      It is compatible with DEC C on OpenVMS VAX, but is somewhat
      different from the older VAX C compiler most people are familiar with.
      Read up on the /EXTERN_MODEL and /STANDARD qualifiers to avoid
      the most common problems.

    - The page size on Alpha systems is variable, but is at least 8K bytes.
      This can have some effect on applications which use the $CRMPSC
      system service as well as on the display of available memory
      pages.  The page size is available from $GETSYI(SYI$_PAGE_SIZE).

There are also a number of manuals which discuss migration to OpenVMS Alpha
available on the documentation CD-ROM media, both in the main documentation
and in the archived documentation section.

On more recent OpenVMS Alpha versions, OpenVMS Alpha has begun to add 
features and support not available on OpenVMS VAX.  Salient new areas 
include the following:

    - 64-bit addressing in OpenVMS Alpha V7.0 and later
    - Multi-host SCSI support (SCSI TCQ) in V6.2 and later
    - PCI support (platform-dependent)
    - OpenVMS Galaxy support in V7.2 and later

------------------------------------------------------------
[ALPHA3 removed, information obsolete]

------------------------------------------------------------
[ALPHA4 relocated to VMS16, and out of Alpha hardware section]

------------------------------------------------------------
ALPHA5.   Seeking performance information for Alpha (and VAX) systems?

  Compaq makes a wide range of performance documents available through
  its FTP and WWW Internet servers (see DOC2).

  The following contain information on current Alpha and VAX products:

    http://www.compaq.com/alphaserver/servers.html
    http://www.compaq.com/alphaserver/vax/index.html

  The following sites contain information on various retired VAX and
  Alpha products:

    http://www.compaq.com/alphaserver/archive/index.html
    http://www.compaq.com/alphaserver/performance/perf_tps.html

  Also see CPU2000:

    http://www.spec.org/osg/cpu2000/
    http://www.spec.org/osg/cpu2000/results/cpu2000.html


------------------------------------------------------------
ALPHA6.  Where can I get updated console firmware for Alpha systems?


Firmware updates for Compaq Alpha systems are available from:

    ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html
    ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
    ftp://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html

The latest and greatest firmware -- if updated firmware has been released 
after the most recent firmware CD was distributed -- is located at:

    ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/

Please send your comments and feedback to [email protected]

For information on creating bootable floppies containing the firmware,
and for related tools, please see the following areas:

  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt
  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt
  ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt

The SROM firmware loader expects an ODS-2 formatted floppy, see mkboot.
As for which image to use, the ROM image uses a header and the file 
extension .ROM, and the SROM bootable floppy cannot use the .ROM file.

                                          [Stephen Hoffman]

To check the firmware loaded on recent OpenVMS Alpha systems, use
the command:

  $ write sys$output f$getsyi("console_version")
  $ write sys$output f$getsyi("palcode_version")
  SDA> CLUE CONFIG
                                          [Clair Grant]


Also see ALPHA14.


------------------------------------------------------------
ALPHA7.   How do I boot an AlphaStation without monitor or keyboard?

The AlphaStation series will boot without a keyboard attached.  To use a
serial terminal as the console, issue the console command SET CONSOLE SERIAL -
after that, it will use the terminal.  The DEC 3000 model 300 series has
a jumper on the motherboard for this purpose.  Various older Alpha 
workstations generally will not (automatically) bootstrap without a 
keyboard connected, due to the self-test failure that arises when the 
(missing) keyboard test fails.

The usual settings for the console serial terminal (or PC terminal emulator
acting as a serial console are:

  9600 baud, 8 bits, no parity, one stop bit (9600 baud, 8N1).

AlphaServer 4100 and derivative series platforms, and AlphaServer GS80, 
GS160, and GS320 series system consoles are capable of 57600 baud.
See the COM2_BAUD console environment variable, and ensure that you 
have current SRM firmware version loaded.

The AlphaStation and AlphaServer series use the PC DIN serial connector for
the "COM1" and "COM2" serial lines, see WIRES1 for details and pinout.

------------------------------------------------------------
ALPHA8.  Will OpenVMS run on a Multia? AlphaPC 164LX? 164SX?

Yes, there are a set of unsupported images that permit recent OpenVMS 
Alpha versions to bootstrap on the Multia UDB system.  These images and 
the associated instructions are available at the OpenVMS Freeware website:

  http://www.openvms.compaq.com/freeware/freeware50/multia/

Instructions are included IN the kits.  READ THE INSTRUCTIONS.

Some of the restrictions involved when running OpenVMS on the Multia 
system include (but may well not be limited to) the following:

  o The PCMCIA support was completely removed, because the Intel 
    chip on the Multia was not compatable with the Cirrus chip on 
    the Alphabook.

    This means, of course, that you will not see and cannot use 
    any PCMCIA cards on a Multia.

  o The Multia uses shared interrupts, and as a result, a special 
    ZLXp-E series graphics device driver -- one that does not use 
    interrupts -- is needed.  This driver is provided in the kit.

  o The serial lines don't work.

  o If you have a Multia with a PCI slot, you can't use any PCI
    card that requires interrupts.

  o The SRM console on this system is very old and very fragile.
    (This SRM console was designed only and strictly for diagnostic 
    use, and was not particularly tested or used with OpenVMS.)

  o If things don't work for you, don't expect to see any OpenVMS 
    updates, nor SRM console updates, nor any support.
  
The Multia images are not included on the OpenVMS Freeware V4.0 CD-ROM
kit, the kit that was distributed with OpenVMS V7.2.  (These images 
became available after Freeware V4.0 shipped.)

Other sources of information for OpenVMS on Multia include:

  http://www.djesys.com/vms/hobbyist/multia.html
  http://www.djesys.com/vms/hobbyist/mltianot.html
  http://www.djesys.com/vms/hobbyist/support.html
  http://www.netbsd.org/Ports/alpha/multiafaq.html
  http://www.brouhaha.com/~eric/computers/udb.html

					[Stephen Hoffman]
                                        [David J. Dachtera]

OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX series,
though there are folks that have gotten certain of the LX series to
load SRM and bootstrap OpenVMS.  (The Aspen Durango II variant.)
One problem was reported: IDE bootstraps fail; SCSI is required.

Also see ALPHA13.

------------------------------------------------------------
ALPHA9.  What is the least expensive system that will run OpenVMS?

The cheapest systems presently offered by Compaq that will run 
OpenVMS are the AlphaServer DS10 server and the AlphaStation XP900 
workstation.  Other companies sell Alpha-powered systems and Alpha
motherboards, some of which will run (and can be purchased with) 
OpenVMS -- see the OpenVMS Software Product Description (SPD) for 
details on the supported systems and configurations.  There are also 
many used AlphaStation, AlphaServer, and DEC 3000 models available 
which are quite suitable.  For more experienced OpenVMS system 
managers, the (unsupported) Multia can bootstrap OpenVMS -- see 
ALPHA8 for details.

Depending on the OpenVMS version and configuration, the OpenVMS 
Software Product Description (SPD) is available at:

  http://www.compaq.com/info/spd/
  OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.

When purchasing a system, ensure that the system itself is supported, 
that the system disk drive is supported or closely compatible, that 
the CD-ROM drive is supported or is closely compatable and that it
also specifically supports 512 byte block transfers, and particularly 
ensure that video controller is supported.  Use of supported Compaq 
hardware will generally reduce the level of integration effort involved.

A CD-ROM drive is required for OpenVMS Alpha installations.

CD-ROM drive compatibility information is available at:
  http://sites.inka.de/pcde/dec-cdrom-list.txt
					[Stephen Hoffman]

------------------------------------------------------------
ALPHA10.  Where can I get more information on Alpha systems?

Compaq operates an AlphaServer information center at:

  http://www.compaq.com/alphaserver/

Alpha Technical information and documentation is available at:

  http://www.support.compaq.com/alpha-tools/
     documentation/current/chip-docs.html

  ftp://ftp.compaq.com/pub/products/alphaCPUdocs/

  ftp://ftp.digital.com/pub/DEC/Alpha/systems/

  http://ftp.digital.com/pub/Digital/info/
     semiconductor/literature/dsc-library.html

  Platform product documentation:  
    http://www.compaq.com/info/spd/

  Alpha Systems Update:
    http://www.compaq.com/alphaserver/fb_acu.html

Information on Multia hardware is available at:

  http://www.netbsd.org/Ports/alpha/multiafaq.html

					[Stephen Hoffman]

Information on current and future Alpha microprocessor designs is
also available from AlphaPowered at:

  http://www.alphapowered.com/alpha_tomorrow.html
  http://www.alphapowered.com/timeline.html
  http://www.alphapowered.com/ev7-and-ev8.html

The NetBSD folks maintain some Alpha hardware information at:

  http://www.netbsd.org/Ports/alpha/models.html


------------------------------------------------------------
ALPHA11.  What are the APB boot flag values?

The following flags are passed (via register R5) to the OpenVMS
Alpha primary bootstrap image APB.EXE.  These flags control the 
particular behaviour of the bootstrap:

  >>> BOOT -FL root,flags

     bit      description
     ---   ----------------------------------------------

      0    CONV      Conversational bootstrap
      1    DEBUG     Load SYSTEM_DEBUG.EXE (XDELTA)
      2    INIBPT    Stop at initial system breakpoints if bit 1 set (EXEC_INIT)
      3    DIAG      Diagnostic bootstrap (loads diagboot.exe)
      4    BOOBPT    Stop at bootstrap breakpoints (APB and Sysboot)
      5    NOHEADER  Secondary bootstrap does not have an image header
      6    NOTEST    Inhibit memory test
      7    SOLICIT   Prompt for secondary bootstrap file
      8    HALT      Halt before transfer to secondary bootstrap
      9    SHADOW    Boot from shadow set
      10   ISL       LAD/LAST bootstrap
      11   PALCHECK    Disable PAL rev check halt
      12   DEBUG_BOOT  Transfer to intermediate primary bootstrap
      13   CRDFAIL       Mark CRD pages bad
      14   ALIGN_FAULTS  Report unaligned data traps in bootstrap
      15   REM_DEBUG   Allow remote high-level language debugger
      16   DBG_INIT    Enable verbose boot messages in EXEC_INIT
      17   USER_MSGS   Enable subset of verbose boot messages (user messages)
      18   RSM         Boot is controlled by RSM
      19   FOREIGN     Boot involves a "foreign" disk

  If you want to set the boot flags "permanently" use the SET BOOT_FLAGS
  command, e.g.

        >>> SET BOOT_OSFLAGS 0,1


------------------------------------------------------------
ALPHA12.  What are Alpha console environment variables?

Alpha systems have a variety of variables with values set up 
within the SRM system console.  These environment variables
control the particular behaviour of the console program and
the system hardware, the particular console interface presented
to the operating system, various default values for the operating 
system bootstrap, and related control mechanisms -- in other
words, "the environment variables provide an easily extensible
mechanism for managing complex console state."

The specific environment variables differ by platform and by
firmware version -- the baseline set is established by the
Alpha Architecture:

  AUTO_ACTION ("BOOT", "HALT", "RESTART", any other value 
  assumed to be HALT),  BOOT_DEV, BOOTDEF_DEV, BOOTED_DEV, 
  BOOT_FILE, BOOTED_FILE, BOOT_OSFLAGS, BOOTED_OSFLAGS, 
  BOOT_RESET ("ON", "OFF"), DUMP_DEV, ENABLE_AUDIT ("ON", 
  "OFF"), LICENSE, CHAR_SET, LANGUAGE, TTY_DEV.  

OpenVMS Galaxy firmware can add console environment variables
beginning with such strings as LP_* and HP_*, and each particular 
console implementation can (and often does) have various sorts
of platform-specific extensions beyond these variables...

The contents of a core set of environment variables are accessable 
from OpenVMS using the f$getenv lexical and the sys$getenv system 
service. (These calls are first documented in V7.2, but have been 
around for quite a while.)  Access to arbitary console environment
variables is rather more involved, and not directly available.
                                        [Stephen Hoffman]

------------------------------------------------------------
ALPHA13.  Will OpenVMS run on a NoName AXPpci33?

Information on bootstrapping OpenVMS (using Multia files) on
the (unsupported) NoName AXPpci33 module is available at:

  http://www.jyu.fi/~kujala/vms-in-axppci33.txt

Tips for using the Multia files with the AXPpci33:

  o You have to use the Multia kit and follow the directions in
    ALPHA8, but do *not* load the Multia SRM firmware into the 
    AXPpci33.  Rather, download and use the latest firmware for 
    the AXPpci33 from the Compaq firmware website instead.

  o 64 MB memory is generally necessary.

  o you cannot use any PCI cards, and if you plan on networking, 
    you need to find an ISA Ethernet card supported by OpenVMS.

  o When the AXPpci33 board bootstraps, it will dump some stuff 
    like a crash dump, but it will continue and -- so far -- this
    hasn't caused any particular hassles.

  o The system shutdown and reboot procedures do not work properly.

  o The serial console is reported to not work, though the serial
    ports apparently do work.  The status of the parallel port is 
    unknown.

  o Rumour has it that you have one of the AXPpci33 motherboards 
    with the PS/2 mouse and keyboard connectors and a VGA card 
    (one that will work under DECwindows) and you can run DECwindows 
    on the system. 
                                      [Robert Alan Byer]

------------------------------------------------------------
ALPHA14.  How do I reload SRM firmware on a half-flash Alpha system?

  Some of the AlphaStation series systems are "half-flash" boxes, meaning
  only one set of firmware (SRM or AlphaBIOS) can be loaded in flash at
  a time.  Getting back to the SRM firmware when AlphaBIOS (or ARC) is 
  loaded can be a little interesting...

  That said, this usually involves shuffling some files, and then getting
  into the AlphaBIOS firmware update sequence, and then entering "update
  srm" at the apu-> prompt.

  To shuffle the files, copy the target SRM firmware file (as200_v7_0.exe
  is current) to a blank, initialized, FAT-format floppy under the filename
  A:\FWUPDATE.EXE

  From the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option.
  Once the firmware update utility gets going, enter:

     Apu-> update srm

           Answer "y" to the "Are you ready...?"

     Apu-> quit

  You've reloaded the flash.  Now powercycle the box to finish the process.

  Also see ALPHA6.

------------------------------------------------------------
ALPHA15.  Will OpenVMS run on the Alpha XL series?

  No.  OpenVMS does not support the Alpha XL series.

  OpenVMS can not, will not, and does not bootstrap on the Alpha XL 
  series.  The Alpha XL series was targeted for use (only) with the
  Microsoft Windows NT operating system.═

  For the list of boxes officially supported by OpenVMS, please see 
  the OpenVMS Software Product Description (SPD).

    http://www.compaq.com/info/spd/
    OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.

  If you are very lucky, sometimes a particular unsupported Alpha box or 
  motherboard will resemble a supported box sufficiently closely and can
  thus mimic that system and bootstrap.  (No such family resemblances
  exist for the XL.)  If you are  exceedingly lucky, somebody here in 
  OpenVMS Engineering will have put together a bootstrap kit -- such as 
  that for the Multia.  (No Miata-like OpenVMS bootstrap kit exists for 
  the XL.)

------------------------------------------------------------
ALPHA16.  Describe Alpha instruction emulation and instruction subsets?

  The Alpha architecture is upward- and downward-compatible, and newer 
  instructions are emulated on older platforms, for those cases where
  the compiler is explicitly requested to generate the newer Alpha
  instructions.

  In particular, OpenVMS Alpha V7.1 and later include the instruction 
  emulation capabilities necessary for the execution of newer Alpha
  instructions on older Alpha microprocessors.

  Alpha instructions are available in groups (or subsets).  Obviously, 
  there is the base instruction set that is available on all Alpha 
  microprocessors.   Then, the following are the current instruction 
  extension groups (or subsets) that are available on some of various
  recent Alpha microprocessors:

    byte/word extension (BWX):
      LDBU, LDWU, SEXTB, SEXTW, STB, and STW.

    floating-point and square root extension (FIX):
      FTOIS, FTOIT, ITOFF, ITOFS, ITOFT, SQRTF, SQRTG, SQRTS, and SQRTT.

    count extension (CIX):
      CTLZ, CTPOP, and  CTTZ.

    multi-media extension (MVI):
      MAXSB8, MAXSW4, MAXUB8, MAXUW4, MINSB8, MINSW4, MINUB8, MINUW4, 
      PERR, PKLB, PKWB, UNPKBL, and UNPKBW.

  The typical instruction subset that provides the biggest win -- and of
  course, your mileage may vary -- is typically the instruction set that
  is provided by the EV56 and later; specifically, the byte-word instruction 
  subset.  To select this subset, use the following:


     /ARCHITECTURE=EV56/OPTIMIZE=TUNE=GENERIC


  The /ARCHITECTURE controls the maximum instruction subset that the
  compiler will generally use, while the /OPTIMIZE=TUNE controls both 
  the instruction-level scheduling and also the instructions generated 
  inside loops -- any code resulting from /OPTIMIZE=TUNE that is specific 
  to an instruction subset will be generated only inside loops and will 
  also be "protected" by an AMASK-based tesst that permits the execution 
  of the proper code for the particular current Alpha microprocessor.
   
  Typically /OPTIMIZE=TUNE=GENERIC is the appropriate choice for tuning, 
  and the /ARCHITECTURE selects the minimum target architecture for
  general use throughout the generated code.

  Code generated for later architectures and instruction subsets will run 
  on older Alpha systems due to the emulation, but if /ARCHITECTURE is a 
  significant benefit, then the emulation might be a performance penalty.

  Please see the OpenVMS Ask The Wizard area for the source code of a 
  (non-privileged) tool that looks at the instruction subsets available 
  on the particular Alpha microprocessor that the tool is run on.  This 
  tool demonstrates the use of the Alpha AMASK and IMPLVER instructions.

------------------------------------------------------------
ALPHA17.  What is the Accuracy of the Alpha Time of Year (BB_WATCH) Clock?

  The specification for maximum clock drift in the Alpha hardware clock is
  50 ppm, that's less than +/-.000050 seconds of drift per second, less than
  +/-.000050 days of drift per day, or less than +/-.000050 years of drift
  per year, etc.   (eg: An error of one second over a day-long interval is
  roughly 11ppm, or 1000000/(24*60*60).)   Put another way, this is .005%,
  which is around 130 seconds per month or 26 minutes per year.

  The software-maintained system time can drift more, primarily due to other 
  system activity.  Typical causes of drift include extensive high-IPL code
  (soft memory errors, heavy activity at device IPLs, etc) that are causing
  the processing of the clock interrupts to be blocked.

  Also see VAX8, TIME6.

------------------------------------------------------------
ALPHA18.  So how do I open up the DEC 3000 chassis?

After removing those two little screws, tilt the back end of the
top shell upwards -- then you can remove the lid.

                                           [Felix Kreisel]

------------------------------------------------------------
ALPHA19.  What is byte swizzling?

"Swizzling" is the term used to describe the operation needed to do partial
longword (i.e. byte or word) accesses to I/O space on those systems that don't
support it directly. It involved shifting the offset into an address space by 
5 (or 7 for one older system), and ORing this into the base address. It then
required the size of the operation to be ORed into the low order bits.

That is, because the EV4 and EV5 CPUs did not bring bits 0 and 1 off the chip,
to do programmed I/O for bytes/words, the information on the size/offset of the
transfer was encoded into the address data. The data itself then had to be
shifted into the correct "byte lane" (i.e. its actual position within a
longword).

The EV56 CPU supports the byte/word instructions however only some EV56 systems
support byte/word accesses to I/O space. Even on an EV56 system that supports
byte/word accesses to I/O space, the relevant OpenVMS routines do not support
byte/word access to I/O space.

EV6 systems (with the exception of the AlphaServer GS60 and AlphaServer GS140
series, for reasons of platform compatability) support a flat, byte addressable
I/O space.

If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_IO, then OpenVMS will do
the right thing without changing the driver - OpenVMS will swizzle and
unswizzle as needed.

To use byte/word operations on MEMORY, you need to tell the compiler to use the
EV56 or EV6 architecture (/ARCHITECTURE=EV56). Memory operations did not
swizzle, but the compiler would do long/quad access, and extract/insert bytes
as needed. Using /ARCHITECTURE=EV56 allows smaller, more efficient byte/word
access logic to memory.

If the application is directly doing I/O space access across a range of Alpha
systems (like the graphics servers), then the driver will need to know how to
do swizzling for old platforms, and byte access for new platforms.

                                        [Fred Kleinsorge, Derek Garson]

------------------------------------------------------------
ALPHA20.  What commands are available in the Alpha SRM console?

In addition to the normal BOOT commands and such (see ALPHA11 for some
details) and the normal contents of the console HELP text, operations
such as I/O redirection and floppy disk access are possible at the SRM 
console prompt:

1. Format a FAT floppy, and insert it into the AlphaStation floppy drive.

2. Perform the following at AlphaStation SRM Console :

   >>> show * > env.dat
   >>> show conf > conf.dat
   >>> cat env.dat > fat:env.dat/dva0
   >>> cat conf.dat > fat:conf.dat/dva0

3. You may use the SRM "ls" to display the contents of the floppy.

   >>> ls fat:env.dat/dva0
   >>> ls fat:conf.dat/dva0

4. You can now transfer the FAT-format floppy to another system.

------------------------------------------------------------
ALPHA21. How do I switch between AlphaBIOS/ARC and SRM consoles?

The specific steps required vary by system.  You must first ensure that
the particular Alpha system is supported by OpenVMS (see the SPD), that
all core I/O components (graphics, disk controllers, etc) in the system
are supported by OpenVMS (see the SPD), and that you have an OpenVMS
distribution, that you have the necessary license keys (PAKs), and that
you have the necessary SRM firmware loaded.

A typical sequence used for switching over from the AlphaBIOS graphics
console to the SRM console follows:

  1. Press <F2> to get to the AlphaBIOS setup menu.

  2. Pick the "CMOS Setup..." item.

  3. Press <F6> to get to the "Advanced CMOS Setup" menu.

  4. Change the "Console Selection" to "OpenVMS Console (SRM)".

  5. Press <F10>, <F10>, then <Enter> to save your changes.

  6. Power-cycle the system.

Most Alpha systems support loading both the AlphaBIOS/ARC console and the
SRM console at the same time, but systems such as the AlphaStation 255
are "half-flash" systems and do not support the presence of both the
AlphaBIOS/ARC and SRM console firmware at the same time.  If you have
a "half-flash" system, you must load the SRM firmware from floppy, from
a network download, or from a firmware CD-ROM.  Following the normal
AlphaBIOS or ARC firmware update sequence to the APU prompt, and then
explictly select the target console.  In other words, power up the
system to the AlphaBIOS or ARC console, use the supplementary options
to select the installation of new firmware (typically from CD-ROM),
and then rather than using a sequence which updates the current
firmware:

    Apu-> update
      -or-
    Apu-> update ARC
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Use the following sequence to specifically update (and load) SRM
from AlphaBIOS/ARC on a "half-flash" system:

    Apu-> update SRM
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Use the following sequence to specifically update (and load) the
AlphaBIOS/ARC console from SRM on a "half-flash" system:

    >>> b -fl 0,A0 ddcu
    BOOTFILE: firmware_boot_file.exe

    Apu-> update ARC
    Apu-> verify
    Apu-> quit
    Power-cycle the system

Once you have the SRM loaded, you can directly install OpenVMS or
Tru64 UNIX on the system.  Do not allow Windows NT to write a
"harmless" signature to any disk used by OpenVMS, Tru64 UNIX, or
Linux, as this will clobber a key part of the disk.  (On OpenVMS,
you can generally recover from this "harmless" action by using the
WRITEBOOT tool.)

If you have a "full-flash" system and want to select the SRM console
from the AlphaBIOS or ARC console environment, select the "Switch to
OpenVMS or Tru64 UNIX console" item from the "set up the system" submenu.
Then power-cycle the system.  If you have a "full-flash" system with
the SRM console and want to select AlphaBIOS/ARC, use the command:

   >>> set os_type NT

and power-cycle the system.

For information on acquiring firmware, see ALPHA6.  For information
on OpenVMS license PAKs (for hobbyist use) see VMS9.  For information
on the Multia, see ALPHA8.

Information on enabling and using the failsafe firmware loader for 
various systems -- this tool is available only on some of the various
Alpha platforms -- is available in the hardware documentation for the 
system.  This tool is used/needed when the firmware has been corrupted,
and cannot load new firmware.

The full list of AlphaBIOS key sequences -- these sequences are needed
when using an LK-series keyboard with AlphaBIOS, as AlphaBIOS expects
a PC-style keyboard:

         F1   Ctrl/A
         F2   Ctrl/B
         F3   Ctrl/C
         F4   Ctrl/D
         F5   Ctrl/E
         F6   Ctrl/F
         F7   Ctrl/P
         F8   Ctrl/R
         F9   Ctrl/T
        F10   Ctrl/U
     Insert   Ctrl/V
     Delete   Ctrl/W
  Backspace   Ctrl/H
     Escape   Ctrl/[
     Return   Ctrl/M
   LineFeed   Ctrl/J
   (Plus) +   upselect (some systems)
  (Minus) -   downselect (some systems)
        TAB   down arrow
   SHIFT+TAB  up arrow

------------------------------------------------------------
ALPHA22.  OpenVMS on the Personal Workstation -a and -au series?

Though OpenVMS is not supported on the Personal Workstation -a series 
platforms, OpenVMS might or might not bootstrap on the platform.  (If 
you attempt this, you must ensure that all graphics and I/O controllers 
in the system are supported by OpenVMS.)

------------------------------------------------------------
ALPHA23.  OpenVMS and Personal Workstation IDE bootstrap?

OpenVMS will boot and is supported on the Personal Workstation -au 
series platforms, though OpenVMS will require a SCSI CD-ROM if the 
Intel Saturn I/O (SIO) IDE chip is present in the configuration -- 
only the Cypress IDE controller chip is supported by OpenVMS for IDE 
bootstraps.

If you have an -au series system, you can determine which IDE
chip you have using the SRM console command:

  SHOW CONFIGURATION

If you see "Cypress PCI Peripheral Controller", you can bootstrap 
OpenVMS from IDE storage.  If you see "Intel SIO 82378", you will
need to use and bootstrap from SCSI.  (A procedure to load DQDRIVER
on the Intel SIO -- once the system has bootstrapped from a SCSI
device -- is expected to be included as part of the contents of the
DQDRIVER directory on Freeware V5.0 and later.)

------------------------------------------------------------
ALPHA24.  Which terminal device name is assigned to the COM ports?

  COM2 is normally TTA0:.  COM1 is normally TTB0: if the Alpha
  workstation is booted with the SRM console environment variable
  set to graphics, and is OPA0: if the console is set to serial.

------------------------------------------------------------
VAX1.   Please explain the back panel of the MicroVAX II

The MicroVAX-series console bulkhead was used with the KA630, KA650, KA655
processors.

There are three controls on the console bulkhead of these systems:

  Triangle-in-circle-paddle: halt enable. 
    dot-in-circle: halt (<break>) is enabled,
                   and auto-boot is disabled.
    dot-not-in-circle: halt (<break>) is disabled,
                   and auto-boot is enabled.

  Three-position-rotary: power-up bootstrap behaviour
    arrow: normal operation.
    face: language inquiry mode.
    t-in-circle: infinite self-test loop.

  Eight-position-rotary: console baud rate selection
    select the required baud rate; read at power-up.
 
There are several different bulkheads involved, including one for the BA23
and BA123 enclosures, and one for the S-box (BA2xx) series enclosure.
The console bulkheads typically used either the MMJ serial line connection, 
or the MicroVAX DB9 (not the PC DB9 pinout), please see the descriptions
of these in section WIRES1.  For available adapters, see WIRES2.

Also present on the console bulkhead is a self-test indicator: a single-digit
LED display. This matches the final part of the countdown displayed on the 
console or workstation, and can be used by a service organization to determine
the nature of a processor problem.  The particular countdown sequence varies 
by processor type, consult the hardware or owner's manual for the processor, 
or contact the local hardware service organization for information the 
self-test sequence for a particular processor module. Note that self-tests 2,
1 and 0 are associated with the transfer of control from the console program 
to the (booting) operating system.
                                        [Stephen Hoffman]

------------------------------------------------------------
VAX2.   What is the layout of the VAX floating point format?

The VAX floating point format is derived from one of the PDP-11 FP formats,
which helps explain its strange layout.  There are four formats defined:
F 32-bit single-precision, D and G 64-bit double-precision and H 128-bit
quadruple precision.  For all formats, the lowest addressed 16-bit "word"
contains the sign and exponent (and for other than H, some of the most
significant fraction bits).  Each successive higher-addressed word contains
the next 16 lesser-significant fraction bits.  Bit 15 of the first word is the
sign, 1 for negative, 0 for positive.  Zero is represented by a biased
exponent value of zero and a sign of zero; the fraction bits are ignored (but
on Alpha, non-zero fraction bits in a zero value cause an error.)  A value
with biased exponent zero and sign bit 1 is a "reserved operand" - touching
it causes an error - fraction bits are ignored.  There are no minus zero,
infinity, denormalized or NaN values.

For all formats, the fraction is normalized and the radix point assumed to be
to the left of the MSB, hence 0.5 <= f < 1.0.  The MSB, always being 1, is
not stored.  The binary exponent is stored with a bias varying with type in
bits 14:n of the lowest-addressed word.

  Type    Exponent bits    Exponent bias    Fraction bits (including hidden)
  ==========================================================================
   F           8                128               24
   D           8                128               56
   G          11               1024               53
   H          15              16384              113

The layout for D is identical to that for F except for 32 additional
fraction bits.

Example:  +1.5 in F float is hex 000040C0 (fraction of .11[base 2], biased
exponent of 129)
					[Steve Lionel]

------------------------------------------------------------
VAX3.   Where can I find more info about VAX systems?

Compaq runs a VAX "InfoCenter" at:

  http://www.compaq.com/alphaserver/vax/

Jim Agnew maintains a MicroVAX/VAXstation FAQ at:

  http://anacin.nsc.vcu.edu/~jim/mvax/mvax_faq.html

The VAXstation 3100 Owner's Guide:

  http://www.whiteice.com/~williamwebb/intro/DOC-i.html

A field guide to PDP-11 (and VAX) Q-bus and UNIBUS modules 
can be found at:

  http://metalab.unc.edu//pub/academic/computer-science/
    history/pdp-11/hardware/field-guide.txt

Various VAX historical information (also see VMS1) can be
found at:

  http://telnet.hu/hamster/vax/e_index.html

------------------------------------------------------------
VAX4.   Where can I find information on NetBSD for VAX systems?

Gunnar Helliesen maintains a NetBSD VAX FAQ at:
  http://vaxine.bitcon.no/

------------------------------------------------------------
VAX5.   What system disk size limit on the MicroVAX and VAXstation 3100?

System disks larger than 1.073 gigabytes (GB) -- 1fffff hexidecimal blocks --
are not supported on any member of the VAXstation 3100 series and on certain
older members of the MicroVAX 3100 series, and are not reliable on these
affected systems.  (See below to identify the affected systems -- the more
recent members of the MicroVAX 3100 series systems are NOT affected.)

Various of the SCSI commands used by the boot drivers imbedded in the console
PROM on all members of the VAXstation 3100 series use "Group 0" commands,
which allow a 21 bit block number field, which allows access to the first
1fffff hexidecimal blocks of a disk.  Any disk references past 1fffff will
wrap -- this wrapping behaviour can be of particular interest when writing a
system crashdump file, as this can potentially lead to system disk corruptions
should any part of the crashdump file be located beyond 1.073 GB.

More recent systems and console PROMs use "Group 1" SCSI commands, which allow
a 32 bit block number field.

There was a similar limitation among the oldest of the MicroVAX 3100 series,
but a console boot PROM was phased into production and was made available for
field retrofits -- this PROM upgrade allows the use of the "Group 1" SCSI
commands, and thus larger system disks.  There was no similar PROM upgrade for
the VAXstation 3100 series.

Systems that are affected by this limit:
  o VAXstation 3100 series, all members.  No PROM upgrade is available.
  o MicroVAX 3100 models 10 and 20.  No PROM upgrade is available.
  o MicroVAX 3100 models 10e and 20e.  Only systems with console VMB 
    versions prior to V6.4 are affected.  A PROM upgrade for these
    specific systems is (was once) available.

Also see:
  http://www.whiteice.com/~williamwebb/intro/DOC-i.html

Also see FILE5.
						[Stephen Hoffman]

------------------------------------------------------------
VAX6.  replaced by TIME section.

------------------------------------------------------------
VAX7.  What are the VMB boot flag values?

The following flags are passed (via register R5) to the OpenVMS
VAX primary bootstrap image VMB.EXE.  These flags control the 
particular behaviour of the bootstrap:

The exact syntax is console-specific, recent VAX consoles tend
to use the following:

  >>> BOOT/R5:flags

  Bit     Meaning                                               
  ---     -------                                               
                                                                              
   0      RPB$V_CONV                                            
          Conversational boot. At various points in the         
          system boot procedure, the bootstrap code             
          solicits parameter and other input from the           
          console terminal.  If the DIAG is also on then        
          the diagnostic supervisor should enter "MENU"         
          mode and prompt user for the devices to test.         

   1      RPB$V_DEBUG                                           
          Debug.  If this flag is set, VMS maps the code        
          for the XDELTA debugger into the system page          
          tables of the running system.                         
                                                                
   2      RPB$V_INIBPT                                          
          Initial breakpoint. If RPB$V_DEBUG is set, VMS        
          executes a BPT instruction immediately after          
          enabling mapping.                                     
                                                               
   3      RPB$V_BBLOCK                                          
          Secondary boot from the boot block.  Secondary        
          bootstrap is a single 512-byte block, whose LBN       
          is specified in R4.                                   
                                                                
   4      RPB$V_DIAG                                            
          Diagnostic boot.  Secondary bootstrap is image        
          called [SYSMAINT]DIAGBOOT.EXE.                        
                                                                
   5      RPB$V_BOOBPT                                          
          Bootstrap breakpoint. Stops the primary and           
          secondary bootstraps with a breakpoint                
          instruction before testing memory.                    

   6      RPB$V_HEADER                                          
          Image header. Takes the transfer address of the       
          secondary bootstrap image from that file's            
          image header.  If RPB$V_HEADER is not set,            
          transfers control to the first byte of the            
          secondary boot file.                                  
                                                                
   7      RPB$V_NOTEST                                          
          Memory test inhibit. Sets a bit in the PFN bit        
          map for each page of memory present.  Does not        
          test the memory.                                      
                                                                
   8      RPB$V_SOLICT                                          
          File name. VMB prompts for the name of a              
          secondary bootstrap file.                             
                                                                
   9      RPB$V_HALT                                            
          Halt before transfer.  Executes a HALT                
          instruction before transferring control               
          to the secondary bootstrap.                           
                                                                
  10      RPB$V_NOPFND                                          
          No PFN deletion (not implemented; intended to         
          tell VMB not to read a file from the boot device      
          that identifies bad or reserved memory pages,         
          so that VMB does not mark these pages as valid        
          in the PFN bitmap).                                   
                                                                
  11      RPB$V_MPM                                             
          Specifies that multi-port memory is to be used        
          for the total EXEC memory requirement.  No local      
          memory is to be used.  This is for tightly-coupled    
          multi-processing.  If the DIAG is also on, then       
          the diagnostic supervisor enters "AUTOTEST" mode.     
                                                                
  12      RPB$V_USEMPM                                          
          Specifies that multi-port memory should be used in    
          addition to local memory, as though both were one     
          single pool of pages.                                 
                                                                
  13      RPB$V_MEMTEST                                         
          Specifies that a more extensive algorithm be used     
          when testing main memory for hardware                 
          uncorrectable (RDS) errors.                           
                                                                
  14      RPB$V_FINDMEM                                         
          Requests use of MA780 memory if MS780 is              
          insufficient for booting.  Used for 11/782            
          installations.                                        
                                                                
  <31:28> RPB$V_TOPSYS                                          
          Specifies the top level directory number for          
          system disks with multiple systems.                   
 
------------------------------------------------------------
VAX8.   What is the Accuracy of VAX the Time of Year (TOY) Clock?

  The VAX Time-Of-Year (TOY) clock (used to save the time over a 
  reboot or power failure) is specified as having an accuracy of 
  .0025%.  This is a drift of roughly 65 seconds per month.

  The VAX Interval Time is used to keep the running time, and this 
  has a specified accuracy of .01%.  This is a drift of approximately 
  8.64 seconds per day.

  Any high-IPL activity can interfere with the IPL 22 or IPL 24 (this
  depends on the VAX implementation) clock interrupts -- activities 
  such as extensive device driver interrupts or memory errors are 
  known to slow the clock.

  Also see ALPHA17, TIME6.

------------------------------------------------------------
VAX9.   Which serial port is the console on the MicroVAX 3100?

Just to keep life interesting, the MicroVAX 3100 has some "interesting"
console ports behaviours based on the setting of the BREAK enable
switch.  When the console is not enabled to respond to BREAK, MMJ-1
is the console port.  MMJ-3 will (confusingly) output the results of
the selftest in parallel with MMJ-1. When the console is enabled to
respond to BREAK, MMJ-3 becomes the console port, and MMJ-1 will
(confusingly) output the results of selftest in parallel with MMJ-3.

------------------------------------------------------------
VAX10.  How can I set up an alternate console on a VAXstation?

Most VAXstation systems have a switch -- often labeled S3 -- that
enables one of the serial lines as the system console.  

Various members of the DEC 3000 series Alpha systems also have a 
similarly-labled S3 switch for selection of the alternate console.


Also see ALPHA7, DECW13, and MGMT22.

------------------------------------------------------------
VAX11.  What are the VAX processor (CPU) codes?

   CPU:    Platform:
   -----   ---------
   KA41-A : MicroVAX 3100 Model 10 and 20
   KA41-B : VAXserver 3100 Model 10 and 20
   KA41-C : InfoServer
   KA41-D : MicroVAX 3100 Model 10e and 20e
   KA41-E : VAXserver 3100 Model 10e and 20e
   KA42-A : VAXstation 3100 Model 30 and 40
   KA42-B : VAXstation 3100 Model 38 and 48
   KA43-A : VAXstation 3100 Model 76
   KA45   : MicroVAX 3100 Model 30 and 40
   KA46   : VAXstation 4000 Model 60
   KA47   : MicroVAX 3100 Model 80
   KA48   : VAXstation 4000 VLC
   KA49-A : VAXstation 4000 Model 90/90A
   KA49-B : VAXstation 4000 Model 95
   KA49-C : VAXstation 4000 Model 96
   KA50   : MicroVAX 3100 Model 90
   KA51   : MicroVAX 3100 Model 95
   KA52   : VAX 4000 Model 100
   KA53   : VAX 4000 Model 105
   KA54   : VAX 4000 Model 106
   KA55   : MicroVAX 3100 Model 85
   KA56   : MicroVAX 3100 Model 96
   KA57   : VAX 4000 Model 108
   KA58   : MicroVAX 3100 Model 88
   KA59   : MicroVAX 3100 Model 98
   KA85   : VAX 8500
   KA86   : VAX 8600
   KA88   : VAX 8800
   KA600  : VAX 4000-50 (aka VAXbrick)
   KA610  : MicroVAX I, VAXstation I (aka KD32)
   KA620  : rtVAX (VAXeln)
   KA62A  : VAX 6000-200
   KA62B  : VAX 6000-300
   KA630  : MicroVAX II, VAXstation II
   KA640  : MicroVAX 3300, MicroVAX 3400
   KA650  : VAXstation 3200, MicroVAX 3500, MicroVAX 3600, MicroVAX III
   KA64A  : VAX 6000-400
   KA655  : MicroVAX 3800, MicroVAX 3900, MicroVAX III+
   KA65A  : VAX 6000-500
   KA660  : VAX 4000-200, VAX 4 upgrade
   KA66A  : VAX 6000-600
   KA670  : VAX 4000-300
   KA675  : VAX 4000-400
   KA680  : VAX 4000-500
   KA681  : VAX 4000-500A
   KA690  : VAX 4000-600
   KA691  : VAX 4000-605A
   KA692  : VAX 4000-700A
   KA693  : VAX 4000-605A
   KA694  : VAX 4000-705A
   KA730  : VAX-11/730
   KA750  : VAX-11/750
   KA780  : VAX-11/780, VAX-11/782
   KA785  : VAX-11/785
   KA7AA  : VAX 7000-600
   KA7AB  : VAX 7000-700
   KA7AC  : VAX 7000-800
   KA800  : VAXrta
   KA820  : VAX 8200, VAX 8300
   KA825  : VAX 8250, VAX 8350
   KA865  : VAX 8650
                                     [Antonio Carlini]

------------------------------------------------------------
ITAN1.  OpenVMS is porting to Intel IA-64?

Yes, OpenVMS is being ported to the Intel IA-64 architecture; to
systems based on the Intel Itanium Processor Family.

------------------------------------------------------------
ITAN2.  Where can I get Intel Itanium information?

Intel Itanium Processor Family Architecture, Hardware, software,
and related materials are available at:

    ftp://download.intel.com/design/IA-64/manuals/
    ftp://download.intel.com/design/IA-64/Downloads/

    See:
      ftp://download.intel.com/design/IA-64/Downloads/archSysSoftware.pdf
      ftp://download.intel.com/design/IA-64/Downloads/24870101.pdf

  The Intel Extensible Firmware Interface (EFI) console documentation:
    http://www.pentium.de/technology/efi/index.htm

    
------------------------------------------------------------
SUPP1.  Where can I get software and hardware support information?

Contact Compaq Customer Support.  Services and information, manuals,
guides, downloads, and various other information is available at:

  http://www.compaq.com/support/

Various hardware and system documentation is available at:

  http://www.compaq.com/support/techpubs/user_reference_guides/
  http://www.adenzel.demon.nl/vaxes/microvax3100/
  http://www.adenzel.demon.nl/vaxes/infoserver150/

TSM (Terminal Server Manager), DEChub, DECserver, etc. information:

  http://www.compaq.com/support/digital_networks_archive/



------------------------------------------------------------
SUPP2.  Where can I get hardware self-maintenance support assistance?

The Compaq Assisted Services (CAS) program (a direct descendent of the
program once known as DECmailer) is available to customers that wish to 
maintain their own system(s) (self-maintenance), but that wish some level
of assistance in acquiring hardware diagnostics and hardware manuals for
the system(s), and that wish to have access to spares and module-level
repairs for customer-performed hardware module swaps:

  http://www.compaq.com/CAS-Catalog/

------------------------------------------------------------
SUPP3. Why does my system halt when I power-cycle the console terminal?

  Various VAX and Alpha consoles are designed to process the
  BREAK signal, treating it as a HALT request.

  A BREAK is a deliberately-generated serial line framing error.

  When a serial line device such as a terminal powers up (or sometimes
  when powering down) it can generate framing errors.  These framing
  errors are indistingushable from a BREAK signal.

  When a BREAK is received on a serial line console for various
  VAX systems -- including most VAXstation, MicroVAX, and VAX 4000
  series -- it is typically interpreted as a HALT.  Alpha systems
  will also often process a BREAK in a similar fashion, halting the
  system.

  There is no uniform or generally-available way to disable this
  behaviour on every VAX or Alpha system.  On some systems, BREAK
  processing can be disabled in favor of [CTRL/P], or [CTRL/P] is
  the only way to halt the processor.

  The most common way to avoid these halts is to disable the serial
  line console or to simply not power-cycle the console terminal.
  There is certain important system state information that is displayed
  only on the console, OpenVMS expects to always have access to the
  system console.

  Also see MGMT5.

------------------------------------------------------------
SUPP4.  Can I reuse old keyboards, mice and monitors with a PC?

Older Compaq keyboards (those with the DIGITAL logo and the RJ modular
jacks), older Compaq mice (those with the DIGITAL logo and with the RJ
modular jacks, or with a DIN connector with pins in a configuration other
than the PC-standard DIN connector pin orientation), and older video
monitors (with RGB synch-on-green video signaling) all use signaling
formats and/or communications protocols that differ from the PC standards,
and are not (easily) interchangable nor (easily) compatible with typical
PC peripheral device controllers.  LK201, LK401, VSXXX, VR260, VR290, etc.,
are incompatible with most PC systems.

Newer Compaq keyboards (those with with PC-style DIN plugs, and Compaq
or DIGITAL logo), newer Compaq mice (with PC-pin DIN plugs, and Compaq
or DIGITAL logo), and newer video monitors (multi-synch) are often
interchangeable with "industry standard" PC systems, and can often be
used with most PC peripheral device controllers. LK461, LK471, PC7XS-CA,
VRC16, VRC21, etc., are compatible with most PC systems.

Rule of thumb: if the peripheral device component was sold for use with the
DEC 2000 (DECpc 150 AXP), an AlphaServer series, an AlphaStation series, or
more recent Alpha system, it will probably  work with a PC peripheral
controller.  If the peripheral device component was sold for use with an
VT420 or older terminal, most VAX, most VAXstation, and most Alpha systems
with names in the format `DEC <four-digit-number>', it probably won't work
on a PC.

Note that the above is a general guideline, and should not be read to indicate
that any particular peripheral device will or will not work in any particular
configuration, save for those specific configurations the device is explicitly
supported in.
                                        [Stephen Hoffman]


Software Integrators sells a video adapter card called Gemini P1 which will
drive many of the older Compaq (DIGITAL-logo) fixed-frequency monitors on
a PC system:

  http://www.si87.com/


The Digital part number 29-32540-01 converts the output from the RGB cable
(3 BNC, synch-on-green) that comes with the VAXstation 3100 and VAXstation
4000 series to a female SVGA D connector.

This will allow PC Multisync monitors with the needed frequency
specifications to be used with the VAXstations.  It may work with a
VAXstation 2000 series, but I have not tried that combination.
                                          [John E. Malmberg]

The protocol definition for the old DIGITAL keyboard and mouse interfaces
is buried at the back of the QDSS section in the old VAXstation II manual,
specifically, in the back of the VCB02 Video Subsystem Technical Manual
(EK-104AA-TM).  The keyboard wiring and protocol is in appendix B, and
occupies circa 44 pages.  The mouse is in appendix C, circa 12 pages.


Also see SUPP5

------------------------------------------------------------
SUPP5.  Which video monitor works with which graphics controller?

  To determine the answer to the "will this video monitor or this LCD panel
  work with this graphics controller?" question, please first locate the 
  resolution(s) and the frequencies that are possible/supported at both 
  ends of the video cable (on the display and on the graphics controller, 
  in other words), and then determine if there are any matching settings 
  available.  If there are multiple matches, you will need to determine 
  which one is most appropriate for your needs.

  You will also need to determine if the video monitor or graphics controller
  requires the 3 BNC signaling with the synchronization signals on the green
  wire, or the 5 BNC signalling common on many PCs, or other connections such
  as the DB15 video connector or USB connector used on various systems.

  If there are no matches, you will likely need to change the hardware at
  one or both ends of the "video cable".

  The refresh frequencies for many devices have been posted to comp.os.vms
  and/or other newsgroups.  Search the archives for details.  Also see:

    http://www.repairfaq.org/
    http://www.mirage-mmc.com/faq/
    http://www.geocities.com/SiliconValley/Foothills/4467/fixedsync.html
    http://saturn.tlug.org/sunstuff/ffmonitor.html
    http://hawks.ha.md.us/hardware/monitor.html

  Also see SUPP4.

------------------------------------------------------------
SUPP6.  Where can I get information on storage hardware?

Information on various Compaq OpenVMS and other disk storage
hardware and controllers, and related technical information
on SCSI, device jumpers, etc., is available at:

  http://theref.aquascape.com/

------------------------------------------------------------
SUPP7.  Problem - My LK401 keyboard unexpectedly autorepeats

There are several modes of failure:

a) Pressing 2 and 3 keys at the same time causes one key to autorepeat when
   released.  Check the hardware revision level printed on the bottom of the
   keyboard.  If the revision level is C01, the keyboard firmware is broken.
   Call field service to replace the keyboard with any revision level other
   than C01.

b) Pressing certain keys is always broken.  Typical sympypoms are: delete
   always causes a autorepeat, return needs to be pressed twice, etc.  This is
   frequently caused by having keys depressed while the keyboard is being
   initialized.  Pressing ^F2 several times or unplugging and replugging the
   keyboard frequently fix this problem.  There is a patch available to fix
   this problem [contact the CSC for information - a CSCPAT number will be
   included here when available. - Ed.]

c) A key that was working spontaneously stops working correctly. This may be
   either (a) or (b) or it may be bad firmware.  Ensure that you have the most
   recent firmware installed on your CPU.  An old version of the DEC 3000
   firmware had a bug that could cause this symptom.
                                        [Fred Kleinsorge]

------------------------------------------------------------
SUPP8.  Problem - My LK411 sends the wrong keycodes or some keys are dead

Check the firmware revision on the keyboard.  Hardware revision B01 introduced
an incompatability with the device driver which causes the keyboard to not be
recognized correctly.  There is a patch available to fix this problem:
[AXPDRIV06_061] - the fix is also included in OpenVMS V6.2.  The rev A01
keyboard, and the LK450 should work without problems.
                                        [Fred Kleinsorge]
                                        [inazu_k]

------------------------------------------------------------
SUPP9.  Which DE500 variant works with which OpenVMS version?

  Ensure you have a version of the Alpha SRM console with support for
  the DE500 series device.  Apply ALL mandatory ECO kits for the OpenVMS
  version in use, and also apply the CLUSIO, ALPBOOT, and ALPLAN kits,
  and apply any available ALPCPU ECO kit for the platform.

  DE500-XA
   auto-detection, no auto-negotiation,
   OpenVMS V6.2-1H1 and ALPBOOT ECO, also V7.0 and later and ECO
   Device hardware id 02000011 and 02000012.
   Component part number 54-24187-01

  DE500-AA
   auto-detection, auto-negotiation,
   OpenVMS V6.2 and ALPBOOT and ALPLAN ECOs, or V7.1 and later and ECO
   Device hardware id 02000020 and 20000022.
   Component part number 54-24502-01

  DE500-BA
   auto-detection, auto-negotiation,
   OpenVMS V6.2-1H3 and CLUSIO, ALPBOOT, ALPLAN and ALPCPU ECOs, or
     V7.1-1H1 or later and ECO.
   Device hardware id 02000030 (check connector, vs DE500-FA)
     (other values on old Alpha SRM firmware)
   Component part number 54-24602-01

  DE500-FA (100 megabit fibre optic Ethernet)
    OpenVMS V7.1-1H1 and later
    Device hardware id 02000030 (check connector, vs DE500-BA)
      (other values possible on old Alpha SRM firmware)
    Component part number 54-24899-01

  To check the DE500 device hardware id from OpenVMS, use the following
  command:

    $ ANALYZE/SYSTEM
    SDA> SHOW LAN/DEVICE=EWcu:

  The "hardware id" will be displayed.

  To set the DE500 speed via the Alpha SRM console environment variable:

   EWx0_MODE setting           Meaning
   --------------------------  --------------------------------
   Twisted-Pair                10 Mbit/sec, nofull_duplex
   Full Duplex, Twisted-Pair   10 Mbit/sec, full_duplex
   AUI                         10 Mbit/sec, nofull_duplex
   BNC                         10 Mbit/sec, nofull_duplex
   Fast                        100 Mbit/sec, nofull_duplex
   FastFD (Full Duplex)        100 Mbit/sec, full_duplex
   Auto-Negotiate              Negotiation with remote device

  To override the console setting and use LANCP:

    $ RUN SYS$SYSTEM:LANCP
    LANCP> SET DEV EWA0/SPEED=10
    LANCP> SET DEV EWA0/SPEED=100/full_duplex

  Fast Ethernet (100Base, 100 megabit) controllers such as the DE500 series
  have a pair of connections available -- while traditional Ethernet (10Base,
  10 megabit) is inherently a half-duplex protocol, Fast Ethernet can be
  configured to use one or both of the available connections, depending on
  the controller.  Fast Ethernet can thus be half- or full-duplex depending
  on the configuration and the capabilities of the network controller and
  the Ethernet network plant.  Some Fast Ethernet controllers can also
  operate at traditional Ethernet speeds, these controllers are thus often
  refered to as 10/100 Ethernet controllers.


------------------------------------------------------------
SCSI1.  Are the 2X-KZPCA-AA and SN-KZPCA-AA LVD Ultra2 SCSI?

  Both of these controllers are Ultra2 low-voltage 
  differential (LVD) SCSI controllers.

------------------------------------------------------------
SCSI2.  Resolving DRVERR fatal device error?

  If this is on an OpenVMS version prior to V6.2, please see 
  the AWRE and ARRE information included in section MISC21.


------------------------------------------------------------
WIRES1. Looking for connector wiring pinouts?

DECconnect DEC-423 MMJ pinout:

  1: Data Terminal Ready (DTR)
  2: Transmit (TXD)
  3: Transmit Ground (TXD-)
  4: Receive Ground (RXD-)
  5: Receive (RXD)
  6: Data Set Ready (DSR)

   +------------------+
   | 1  2  3  4  5  6 |
   +------------+    ++
                +____+


The PC-compatible DB9 connector pinout follows:

  1: Data Carrier Detect (DCD)
  2: Received Data
  3: Transmit Data
  4: Data Terminal Ready (DTR)
  5: Ground
  6: Data Set Ready (DSR)
  7: Request To Send (RTS)
  8: Clear To Send
  9: floating

The MicroVAX DB9 console connector pinout predates the PC-style DB9
pinout, and uses a then-common (older) standard pinout, and uses the
following EIA-232-standard signals:

  1: Protective Ground
  2: Transmited Data
  3: Received Data
  4: Request To Send (RTS)
  5: Data Terminal Ready (DTR)
  6: Data Set Ready (DSR)
  7: Signal Ground
  8: Shorted to pin 9 on MicroVAX and VAXstation 2000...
  9:    ...series systems, otherwise left floating.

  When pin 8 is shorted to pin 9, this is a BCC08 (or variant) cable.

The BC16E-nn (where -nn indicates the cable length) cable key
impliicitly "flips over" (crosses-over) the signal wires, so
all DECconnect MMJ connectors are wired the same.

           //
           ----                                       ----
           |  |---------------------------------------|  |
           ----                                       ----
                                                        \\

The BC16-E-nn cross-over wiring looks like this:

            Terminal                                   Host
            MMJ                                        MMJ

         DTR 1 --->-------------->----------------->--- 6 DSR
         TXD 2 --->-------------->----------------->--- 5 RXD
             3 ---------------------------------------- 4
             4 ---------------------------------------- 3
         RXD 5 ---<--------------<-----------------<--- 2 TXD
         DSR 6 ---<--------------<-----------------<--- 1 DTR


The BN24H looks like this:

         MMJ       RJ45

          1---------8
          2---------2
          3---------1
          4---------3
          5---------6
          6---------7

The BN24J looks like this:

         MMJ       RJ45

          1---------7
          2---------6
          3---------3
          4---------1
          5---------2
          6---------8

Also see:

 http://www.openvms.compaq.com/wizard/padapters.html
 http://www.airborn.com.au/rs232.html
 http://www.stanq.com/cable.html
 For adapters and connectors, see WIRES2.

                                        [Stephen Hoffman]
                                        [Mike Thompson]
                                        [William Webb]

------------------------------------------------------------
WIRES2. What connectors and wiring adapters are available?


The H8571-B converts the (non-2000-series) MicroVAX DB9 to MMJ DECconnect.
The MicroVAX 2000 and VAXstation 2000 requires a BCC08 cable (which has
the 8-9 short, see WIRES1) and the H8571-D for use with DECconnect.

More recent Compaq (Compaq or DIGITAL logo) systems will use either the
DECconnect MMJ wiring or (on all recent system designs) the PC-compatible
DB9 pinout.

DECconnect MMJ adapters:

    Part:      Converts BC16E MMJ male to fit into:

    H8571-C  25 pin DSUB Female to MMJ, Unfiltered
    H8571-D  EIA232 25 pin male (modem-wired) 
    H8571-E  25 pin DSUB Female to MMJ, Filtered
    H8571-J  PC/AT 9 pin male (PC serial port) 
    H8572-0  BC16E MMJ double-female (MMJ extender) 
    H8575-A  EIA232 25 pin female (common) 
    H8575-B  EIA232 9 pin male (MicroVAX II console) 
    H8575-D  25 Pin to MMJ W/EOS and ESD Protection 
    H8577-AA 6 pin Female MMJ to 8 pin MJ 
    BC16E-** MMJ cable, available in various lengths


Numerous additional adapters and cables are available from the _OPEN
DECconnect Building Wiring Components and Applications Catalog_, as well as
descriptions of the above-listed parts.

The H8571-A and H8575-A are MMJ to DB25 (female) and are wired as follows:

Also see:
 http://www.openvms.compaq.com/wizard/padapters.html

Jameco offers a USB-A to PS/2 Mini DIN 6 Adapter (as part 168751), for those
folks wishing to (try to) use PS/2 Keyboards via USB-A connections.

                                        [Stephen Hoffman]
                                        [Eric Dittman]

------------------------------------------------------------
WIRES3. What is flow control and how does it work?

XON/XOFF is one kind of flow control.

In ASCII, XON is the [CTRL/Q] character, and XOFF is the [CTRL/S].

XON/XOFF flow control is typically associated with asynchronous serial
line communications.  XON/XOFF is an in-band flow control, meaning that
the flow control is mixed in with the data.

CTS/RTS is another type of flow control, and is sometimes called hardware
flow control.  Out-of-band means that seperate lines/pins from the data
lines (pins) are used to carry the CTS/RTS signals.

Both kinds of flow control are triggered when a threshold is reached in
the incoming buffer.  The flow control is suppose to reach the transmitter
in time to have it stop transmitting before the receiver buffer is full
and data is lost.  Later, after a sufficient amount of the receiver's
buffer is freed up, the resume flow control signal is sent to get the
transmitter going again.

DECnet Phase IV on OpenVMS VAX supports the use of asynchronous serial
communications as a network line.  The communication devices (eg. modems,
and drivers) *must not* be configured for XON/XOFF flow control.  The
incidence of these (unexpected) in-band characters will corrupt data
packets.  Further, the serial line device drivers might normally remove
the XON and XOFF characters from the stream for terminal applications,
but DECnet configures the driver to pass *all* characters through and
requires that all characters be permitted.  (The communication devices
must pass through not only the XON and XOFF characters, they must pass
*all* characters including the 8-bit characters.  If data compression
is happening, it must reproduce the source stream exactly.  No addition
or elimination of null characters, and full data transparency.

An Ethernet network is rather different than an asynchronous serial line.
Ethernet specifies the control of data flow on a shared segment using
CSMA/CD (Carrier Sense Multiple Access, with Collision Detect)  An
Ethernet station that is ready to transmit listens for a clear channel
(Carrier Sense).  When the channel is clear, the station begins to transmit
by asserting a carrier and encoding the packet appropriately.  The station
concurrently listens to its own signal, to permit the station to detect
if another station began to transmit at the same time -- this is called
collision detection.  (The collision corrupts the signal in a way that can
reliably be detected.)  Upon detecting the collision, both stations will
stop transmitting, and will back off and try again a little later.
(You can see a log of this activity in the DECnet NCP network counters.)

DECnet provides its own flow control, above and beyond the flow control
of the physical layer (if any).  The end nodes handshake at the beginning
to establish a transmit window size -- and a transmitter will only send
that much data before stopping and waiting for an acknowledgement.  The
acknowledgement is only sent when the receiver has confirmed the packet
is valid.  (A well-configured DECnet generally avoids triggering any
underlying (out-of-band) flow control mechanism.)
                                               [David Rabahy]

------------------------------------------------------------
NET1.  How to connect OpenVMS to the Internet?

Some tutorial information and tips for connecting OpenVMS systems
to the Internet are available at:

  http://www.tmesis.com/internet/

------------------------------------------------------------
NET2.  How to connect OpenVMS to a Modem?

  http://www.openvms.compaq.com/wizard/ topics (81), (1839),
  (2177), (3605), etc

[End of Part 5/5]

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру