![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
ATM is a switched, connection-oriented mode of transfer, unlike Ethernet which is a shared, connectionless protocol medium.
The ATM protocol communicates by first establishing between two computers, or end points, a virtual circuit (VC) through one or more ATM switches. ATM then provides a physical path for data flow between the end points by either a permanent virtual circuit (PVC) or a switched virtual circuit (SVC).
Permanent Virtual Circuits (PVCs)
Permanent virtual circuits are established and removed by prior arrangement. They are established manually by an operator before sending any data between end points on a network. Some PVCs are defined directly on the switch; others are predefined for use in managing switched virtual circuits (SVCs).
Switched Virtual Circuits (SVC)
Switched virtual circuits require no operator interaction to create and manage connections between end points. Software dynamically establishes and removes connections as they are needed through the request of an end point.
LAN emulation over an ATM network permits a group of ATM stations to perform as though they were connected to an ordinary local area network. With LAN emulation, existing applications can run unchanged on computers directly connected to the ATM network. The LAN emulation hides the underlying ATM network at the media access control (MAC) layer, which provides device driver interfaces.
Table 4-1 shows the four components that make up a LAN emulation over an ATM network. OpenVMS Version 7.1 supports only the LAN emulation client (LEC). Digital's GIGAswitch/ATM provides support for the LAN emulation server (LES), broadcast and unknown server (BUS), and LAN emulation configuration server (LECS).
| Component | Function |
|---|---|
| LAN emulation client (LEC) | Provides a software driver that runs on a network client and enables LAN client applications to connect to an ATM network. |
| LAN emulation server (LES) | Maintains a mapping between LAN and ATM addresses by resolving LAN media access control (MAC) addresses with ATM addresses. |
| Broadcast and unknown server (BUS) | Maintains sessions with every LAN emulation client (LEC) in the network. For broadcast messages, the BUS sends messages to every attached LEC. The LECs then forward the message to their respectively attached LANs. For multicast messages, the BUS sends messages to only those LECs that have devices in the multicast group. For an LEC that wants to send a regular message whose destination MAC address is unknown, the BUS can be used to determine this address. |
| LAN emulation configuration server (LECS) | Provides a service for LAN emulation clients by helping to determine which emulated LAN each of the LEC's registered users should join, since each client can specify which emulated LAN to join. |
The LEC exists on all ATM-attached computers that participate in the LAN emulation configuration. LEC provides the ATM MAC-layer connectionless function that is transparent to the LAN-type applications. The LEC, LES, and BUS can exist on one ATM-attached computer or on separate computers. Alternatively, the server functions could reside inside an ATM switch, and in fact, do exist in the GIGAswitch/ATM.
Table 4-2 shows the adapters that OpenVMS Version 7.1 supports for LAN emulation over ATM networks.
| Adapter | System Type |
|---|---|
| ATMWORKS 350 | All PCI-based systems with the exception of the AlphaStation 200 and 400 series |
| ATMWORKS 750 | All TURBOchannel-based systems with the exception of the DEC 3000-300 |
For more detailed information, see Section 4.9.4 and the OpenVMS I/O User's Reference Manual.
For information about using LANCP and system manager commands with new qualifiers for LAN emulation over ATM networks, see OpenVMS System Management Utilities Reference Manual: A--L, and OpenVMS System Manager's Manual.
Figure 4-1 shows the topography of a typical ATM emulated LAN.
Figure 4-1 Emulated LAN Topography
OpenVMS Version 7.1 provides LAN Emulation Client (LEC) support over the two new ATM LAN devices: ATMWORKS 350 and ATMWORKS 750. The LAN Emulation Client software supports a single IEEE/802.3 Emulated LAN per adapter, and UNI 3.0 or UNI 3.1. It also supports the maximum frame sizes of 1516, 4544, and 9234 bytes.
The ATMWORKS 350 is a 155 megabits per second (Mb/s) ATM device for PCI-bus Alpha systems with the exception of the AlphaStation 200 series, the AlphaStation 400 and the AlphaServer 400. SYS$HWDRIVER.EXE provides support for this adapter.
The ATMWORKS 750 is a 155 Mb/s ATM device for TURBOchannel Alpha systems with the exception of the DEC 3000-300. SYS$HCDRIVER.EXE provides support for this adapter.
SYS$ELDRIVER.EXE provides the Emulated LAN support, and it provides the means for communicating over the LAN ATM. The QIO and VCI interface to the Emulated LAN is the same as that described for the DESVA in the OpenVMS I/O User's Reference Manual, except that the device type for ELDRIVER is DT$_EL_ELAN.
The device name for the Emulated LAN is:
ELcu
where c is the controller and u is the unit number (for example, ELA0).
The ATM drivers have the capability of operating with either SONET or SDH framing. Setting the new SYSGEN parameter, LAN_FLAGS, to 1 enables SDH framing. Setting the SYSGEN parameter, LAN_FLAGS, to 0 enables SONET framing (default). For this to take effect, the SYSGEN parameter must be specified correctly before the ATM adapter driver (HCDRIVER/HWDRIVER) is loaded.
OpenVMS Version 7.1 does not support the ATM adapters ATMWORKS 350 and ATMWORKS 750 as boot devices. LANCP/LANACP and DECnet software does support MOP booting over the emulated LAN devices.
The LANCP program is used to set up and verify an ELAN. If the commands are defined in the permanent database, these settings will take effect at boot time. The LANCP SET commands can be issued to start up an ELAN after the system is booted.
The following example shows the commands required for setting up an ELAN with the desired parameters. Note that some of the commands generate a console message.
ALPHA1> mcr lancp
LANCP> set dev ela0/elan=create
%%%%%%%%%%% OPCOM 26-MAR-1996 16:57:12.89 %%%%%%%%%%%
Message from user SYSTEM on ALPHA1
LANACP LAN Services
Found LAN device ELA0, hardware address 00-00-00-00-00-00
LANCP> set dev ela0/elan=(parent=hwa0,type=csmacd,size=1516)
LANCP> set dev ela0/elan=(descr="An ATM ELAN")
LANCP> set dev ela0/elan=enable=startup
%ELDRIVER, LAN Emulation event at 26-MAR-1996 16:57:28.78
%ELDRIVER, LAN Emulation startup: Emulated LAN 1 on device ELA0
LANCP> sho dev ela/char
Device Characteristics ELA0:
Value Characteristic
----- --------------
Normal Controller mode
External Internal loopback mode
CSMA/CD Communication medium
16 Minimum receive buffers
32 Maximum receive buffers
No Full duplex enable
No Full duplex operational
Unspecified Line media
10 Line speed (megabits/second)
CSMA/CD Communication medium
"HWA0" Parent ATM Device
"An ATM ELAN" Emulated LAN Description
3999990000000008002B LAN Emulation Server ATM Address
A57E80AA000302FF1300
Enabled Emulated LAN State
LANCP> exit
ALPHA1>
The following is a specific example of setting up the Digital GIGAswitch/ATM for emulated LAN (ELAN). The OpenVMS LAN Emulation Client (LEC) software adheres to the ATM Forum's LANE Version 1.0 specification. Hence, it works with any ATM switch that supports the ELAN server software of the LAN emulation server (LES), broadcast and unknown server (BUS), and LAN emulation configuration server (LECS).
The GIGAswitch firmware requires Version 1.4.3, and the GIGAswitch must
also have its ELAN services enabled before the OpenVMS host can join an
ELAN. A LECS, a BUS, and a LES must all be started on the
GIGAswitch/ATM. By using the console of the GIGAswitch/ATM, you can log
in and verify if the services are enabled, which they are in the
following example:
GIGAswitch/ATM login: user
Password:
GIGAswitch/ATM-> bus
Broadcast and Unknown Server Summary
BUS Number Status Description
1 enabled
GIGAswitch/ATM-> les
LAN Emulation Server Summary
LES Number Status Description
1 enabled
GIGAswitch/ATM-> elan
LECS Emulated LAN Summary
Number Status Name Default Type Size
1 enabled * 802.3 1516
GIGAswitch/ATM->
If the services were not enabled, start by enabling the BUS. The following commands create BUS 1, set the frame size and the ELAN name, and enable BUS 1.
GIGAswitch/ATM-> bus 1 GIGAswitch/ATM-> bus 1 +f 1516 GIGAswitch/ATM-> bus 1 -e
This following set of commands creates LES 1, sets the frame size and the ELAN name, assigns BUS 1 to LES 1, and enables BUS 1.
GIGAswitch/ATM-> les 1 GIGAswitch/ATM-> les 1 +f 1516 GIGAswitch/ATM-> les 1 +bus bus1 GIGAswitch/ATM-> les 1 -e
Finally, the LECS is given knowledge of LES 1, the ELAN frame size, the ELAN name, and ELAN 1 is enabled.
GIGAswitch/ATM-> elan 1 +f 1516 GIGAswitch/ATM-> elan 1 +les les1 GIGAswitch/ATM-> elan 1 +u 10 ! max unknown frame count GIGAswitch/ATM-> elan 1 +tu 60 ! max unknown frame time GIGAswitch/ATM-> elan 1 +tf 4 ! flush time-out GIGAswitch/ATM-> elan 1 -e
The following commands must be executed each time the GIGAswitch/ATM is rebooted unless you store the configuration in NVRAM.
GIGAswitch/ATM-> bus 1 +nv GIGAswitch/ATM-> les 1 +nv GIGAswitch/ATM-> elan 1 +nv
The Emulated LAN is a new network device that is not recognized by the current version of Digital TCP/IP Services for OpenVMS. For this software to communicate over the Emulated LAN, the device EL must be defined by the following command:
UCX> DEFINE COMMUNICATION_CONTROLLER Elc0/
TYPE=(ETHERNET)/INTERNET_INTERFACE=L
where c is the controller letter (for example, ELA0).
For more information, see the Digital TCP/IP Services for OpenVMS Management manual.
To use PATHWORKS with the Emulated LAN on OpenVMS Version 7.1, a logical must be defined before invoking PATHWORKS. This logical must be defined once per system boot before any invocation of PATHWORKS. The following DCL command can be used to define the required logical:
$ DEFINE/SYSTEM NETBIOS$DEVICE ELc0
where c is the controller letter (for example, ELA0).
New built-ins that allow the inclusion of the newly-designed byte and word instructions are included with this release of the MACRO--32 Compiler for OpenVMS Alpha. This section describes these new built-ins and a previously undocumented built-in, EVAX_SEXTL.
These byte and word instructions are implemented in some of the newest Alpha systems. They are also emulated in OpenVMS software.
The new built-ins and EVAX_SEXTL are shown in Table 4-3.
| Built-In | Operands | Description |
|---|---|---|
| EVAX_LDBU | <WQ,AB> | Load zero-extended byte from memory to register |
| EVAX_LDWU | <WQ,AQ> | Load zero-extended word from memory to register |
| EVAX_STB | <RQ,AB> | Store byte from register to memory |
| EVAX_STW | <RQ,AW> | Store word from register to memory |
| EVAX_SEXTB | <RQ,WB> | Sign extend byte |
| EVAX_SEXTW | <RQ,WW> | Sign extend word |
| EVAX_SEXTL | <RQ,WL> | Sign extend longword |
Note
Memory references in the MACRO-32 compiler built-ins are always assumed to be quadword aligned except in EVAX_SEXTB, EVAX_SEXTW, EVAX_LDBU, EVAX_LDWU, EVAX_STB, EVAX_STW, EVAX_LDQU, and EVAX_STQU.
The best environment in which to run code that contains the byte and word built-ins is on an Alpha computer that implements these instructions in hardware. If you run such code on an OpenVMS Alpha system that implements them by software emulation, the following limitations exist:
%SYSTEM-I-EMULATED, an instruction not implemented on this processor was emulated
Furthermore, if the code with these built-ins executes on a system without either the byte and word software emulator or a processor that implements the byte and word instructions in hardware, it will incur a fatal exception, such as the following:
%SYSTEM-F-OPCDEC, opcode reserved to Digital fault at PC=00000000000020068,PS=0000001B
For more information about the MACRO--32 compiler, see the Porting VAX MACRO Code to OpenVMS Alpha.
This section describes the following new OpenVMS Debugger features:
For more information, see the OpenVMS Debugger Manual.
To improve startup time, the debugger no longer processes the Debug Fixup Table (DFT) when first invoked. The debugger now processes the DFT when a module is "set."
The following sections describe the new and modified OpenVMS Debugger commands for OpenVMS Version 7.1.
The SET BREAK command has a new /SYSEMULATE qualifier that allows you to set a breakpoint to cause the debugger to suspend program execution whenever an instruction in a specified class is emulated. An optional mask allows you to specify the class of emulated instructions that triggers the breakpoint. The only class of emulated instructions currently defined consists of the BYTE and WORD instructions, defined in the mask by bit 0.
The OpenVMS Debugger has a new DUMP command to display the contents of memory in a format similar to the OpenVMS DUMP command. The new DUMP command displays the contents of memory, including registers, variables, and arrays. It accepts the following qualifiers:
When the current language is C or C++, the CALL command by default now passes arguments by value rather than by reference. In addition, you can now pass the following arguments without using a passing mechanism lexical (such as %REF or %VAL):
The debugger SET BREAK command has a new /HANDLER qualifier that causes the debugger to scan the call stack and attempt to set a breakpoint on every established frame-based handler whenever the program being debugged has an exception. The debugger does not discriminate between standard run-time library (RTL) handlers and user-defined handlers.
On Alpha systems, many RTLs establish a jacket RTL handler on a frame where the user program has defined its own handler. This RTL jacket does some setup and argument manipulation before actually calling the handler defined by the user. When processing the exception, the debugger sets the breakpoint on the jacket RTL jacket handler, because that is the address on the call stack. If the debugger suspends program execution at a jacket RTL handler, you can usually reach the user-defined handler by entering a STEP/CALL command followed by a STEP/IN command. Some cases might require that you enter additional sequences of STEP/CALL and STEP/IN commands.
If the jacket RTL handler is part of an installed shared image such as ALPHA LIBOTS, the debugger cannot set a breakpoint on it. In this case, activate the RTL as a private image by defining the RTL as a logical name. For example:
DEFINE LIBOTS SYS$SHARE:LIBOTS.EXE;
This technique bypasses the installed image lookup procedure. Note that the semicolon that follows the .EXE file extension is required.
In screen mode, the SET TERMINAL command has a new /WRAP qualifier to control where the debugger inserts a carriage return and linefeed to format an output message in the message output display. The /WRAP qualifier sets the wrap column at the current value established by the /WIDTH qualifier. For example:
SET TERM/WIDTH:20/WRAP
The DECwindows Motif interface to the debugger now has two different wait cursors that indicate wait states. One wait cursor is the standard clock cursor. This cursor indicates that the debugger is performing an action as a result of a user command. The second wait cursor is a spider. This cursor indicates that the program being debugged is executing.
On Alpha systems, you can now debug programs that have been linked with the /NODEBUG/DSF=filespec qualifiers. You must be running in a configuration in which DBG$PROCESS is defined as DEFAULT or MULTIPROCESS, and you must define DBG$IMAGE_DSF_PATH to point to the directory where the required .DSF files reside. Note that the only .DSF files in this directory must be those required to debug the target image.
The debugger now supports the following Fortran operators:
| Operator | Meaning |
|---|---|
| :=,= | equal to |
| /= | not equal to |
| < | less than |
| > | greater than |
| <= | less than or equal to |
| >= | greater than or equal to |
| % | field delimiter |
The debugger also supports typed pointer type variables in Fortran. This allows users to manipulate Fortran pointer variables.
On Alpha systems, the new predefined display REG contains, in hexadecimal format, general-purpose registers R0 to R28, FP (R29), SP (R30), R31, PC, PS, floating-point registers F0 to F31, and as many of the top call-stack values as will fit in the display.
On Alpha systems, the new predefined display IREG contains, in hexadecimal format, general-purpose registers R0 to R28, FP (R29), SP (R30), R31, PC, PS, and as many of the top call stack values as can be displayed in the window.
On Alpha systems, the new predefined display FREG contains floating-point registers F0 to F31, displayed in floating-point format, FPCR, SFPCR, and as many of the top call stack values (in hexadecimal format) as can be displayed in the window.
On VAX systems, the new predefined display IREG contains the same information as the predefined REG display, but the display window is configured differently. Display IREG is included in the VAX implementation to allow debugger .COM and .INI files to be ported more easily between VAX and Alpha debugging applications.
OpenVMS SCSI device drivers have been enhanced significantly for OpenVMS Version 7.1. These enhancements allow OpenVMS SCSI device drivers to work with a wider range of non-Digital SCSI devices, while taking advantage of as much SCSI functionality as the devices offer. In most cases, the OpenVMS Version 7.1 SCSI driver enhancements eliminate the errors that occurred when some non-Digital devices were mounted after booting Version 6.2 of the OpenVMS operating system.
As of OpenVMS Version 7.1, a new modifier (IO$M_ALLOWFAST) can be used with the IO$_SKIPFILE function to provide better performance on SCSI tape drives that support the SCSI space-by-file-marks command and the SCSI read position command. OpenVMS ignores the new modifier for nonSCSI tape drives.
The IO$M_ALLOWFAST modifier allows a SCSI tape subsystem to use the optimized IO$_SKIPFILE if it is capable. If a specific tape device does not adequately support the optimized IO$_SKIPFILE that uses the SCSI space-by-file-marks command, the tape subsystem will use the standard space-by-records algorithm.
The new optimized IO$_SKIPFILE mechanism requires tape drives that support the SCSI Space command, with the filemarks code, and the SCSI Read Position command. The following tape drives that do not support the new IO$_SKIPFILE mechanism include the following: TSZ05, TSZ07, TZK10, TKZ60, TKZ09, TZ30.
The new IO$M_ALLOWFAST modifier provides slightly different semantics for IO$_SKIPFILE operations (refer to OpenVMS I/O User's Reference Manual). The MTAACP and Backup utilities are compatible with the new behavior and have been modified to use the new IO$M_ALLOWFAST modifier. Other tape applications should be examined to determine whether they are compatible with the new semantics. If an application is compatible, or if it can be made compatible, the application should be modified to use the IO$M_ALLOWFAST modifier with the IO$_SKIPFILE function. If you have an application that is compatible with the new semantics, but it can not be modified to use the IO$M_ALLOWFAST modifier, refer to the documentation in SYS$ETC:MKSET.TXT.
For more information about how to use the IO$M_ALLOWFAST modifier with the IO$_SKIPFILE function, see the OpenVMS I/O User's Reference Manual.
The following sections describe the new OpenVMS Alpha SDA commands and their parameters and qualifiers.
The SET ERASE_SCREEN command enables or disables the automatic clearing of the screen before each new page of SDA output. It has two parameters and no qualifiers. Table 4-4 shows the two parameters and their meanings.
| Parameter | Meaning |
|---|---|
| off | Disables the usual clear screen action and replaces it with a blank line. With SDA's usual behavior, SDA clears the screen and then shows the data. This action does not affect what is written to a file where the SET LOG or SET OUTPUT is used. This command affects only the screen. |
| on | Enables the automatic clearing of the screen before each new page of SDA output. |
6480P005.HTM OSSG Documentation 5-DEC-1996 13:50:07.26
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.