Previous | Contents | Index |
If you are interested in accessing the native Intel Itanium assembler within the OpenVMS I64 GNV environment---and since the iasi64 assembler is a Unix program and GNV is a Unix environment for OpenVMS I64---you can simply copy iasi64.ext into your gnu:[bin] directory in place of "as.", and of "AS.EXE".
Alternately and probably also better, you can write an "as." script to invoke the iasi64.exe image from its particular prefered location on the local system.
A typical "as." script looks like this:
path/iasi64.exe $1 $2 $3 $4 $5 |
Floating point is prohibited in OpenVMS Alpha inner-mode (privileged) code, and within any process or other execution context that does not have floating point enabled and available.
Programmers developing and working with OpenVMS Alpha high-IPL kernel-mode code, such as device drivers, will further want to become familiar with the floating-point processing and the instruction set emulation available in the particular target environment (if any). When working with C, inner-mode programmers will want to become familiar with the C compiler qualifier /INSTRUCTION_SET=[NO]FLOATING_POINT.
Device drivers and other similar kernel-mode C code must be compiled with /INSTRUCTION_SET=FLOATING_POINT and /EXTERN_MODEL=STRICT_REFDEF.
Additionally, inner-mode code cannot call out to the user-mode language run-time libraries nor to any of the OpenVMS system run-time libraries. In particular, this prohibition prevents pages of inner-mode-protected memory from being allocated and interspersed within the user-mode heap or other such user-mode data structures.
The prohibtion on user libraries also generally means that such code must be linked with LINK /NOSYSLIB, and quite probably also with /SYSEXE. The former causes the linker to avoid searching the system shareable image libraries (via IMAGELIB.OLB), while the latter brings in symbols typically only known to or otherwise accessable from the OpenVMS executuve.
To include kernel-mode C programming definitions, macros and system constants within a C compilation, include SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY on the C compilation. (Constructs defined within the system macro library LIB.MLB or within its C equivalent SYS$LIB_C.TLB tend to be version-dependent, or undocumented, or both.) As an example of the compilation, the following is a typical C device driver compilation command:
$ CC /STANDARD=RELAXED_ANSI89/INSTRUCTION=NOFLOATING_POINT/EXTERN=STRICT - 'DEBUG_CC_DQ_OPT' 'ARCH_CC_OPT' 'CHECK_CC_OPT' 'SHOW_CC_OPT' - /LIS=LIS$:xxDRIVER/MACHINE_CODE/OBJ=OBJ$:xxDRIVER - SRC$:xxDRIVER.C+SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY |
Additionally, code running in executive mode in an AST or in kernel mode cannot call RMS services, or routines which directly or indirectly call RMS.
For related kernel-mode programming materials and driver documentation,
please see the Writing OpenVMS Alpha Device Driversin C book,
ISBN 1-55558-133-1.
10.28 Decoding an Access Violation (ACCVIO) Error?
To decode the virtual addresses returned by an access violation or by another similar OpenVMS display, you need to have created and retained a listings file---preferably one with machine code generation enabled---and a full link map.
Starting with the virtual address reported by the error, use the link map to find the module that contributed the code that contains the virtual address range. Calculate the offset from the base of the range, by subtracting the base of the range from teh failing virtual address. Then use the compiler listings for the particular component that contributed the code to locate the offset of the failing instruction.
If the map and listings information was not maintained, working backwards is far more difficult---you are left to use the binary instruction data around the failure to locate the associated source code, and this process is far more involved. This usually involves matching up blocks of decoded instructions around the failing code, or the direct analog involving matching up ranges of decoded instructions. Keep the maps and listing files around, in other words.
Rather easier than an approach based on virtual address arithmetic and far easier than working backwards from the instruction stream is to use integrated debugging---this inclusion is arguably an essential component of any non-trivial application---and to use the OpenVMS Debugger.
The OpenVMS Debugger in particular can be used to examine the source code, to examine the stack, and can even be programmed to wait patiently for the incidence of a particular value or failure or condition, and this is far easier than working backwards from the instruction stream is to use integrated debugging---this inclusion is arguably an essential component of any non-trivial application---and to use the OpenVMS Debugger. The debugger can also be activated from within a signal handler, and commands to generate a traceback can be generated directly, or through the invocation of a procedure containing a series of debugger commands.
Details on the debugger are in the OpenVMS Debugger Manual, and also
see the discussion of dyanmically activating the Debugger in
Section 10.19.
10.29 Generating an AUTODIN-II CRC32?
The following code can be used to generate an AUTODIN-II 32-bit Cyclic Redundency Check (CRC32) value from an input string descriptor, similar to that used by the HP C compiler for its /NAMES=SHORTENED mechanism, and by various other applications requiring a CRC32.
The routine uses the OpenVMS library routine lib$crc_table to generate a sixteen longword array of data from the specified encoded polynomial coefficient (AUTODIN-II, in this case), and then lib$crc to generate the CRC32 value from the array and the input data.
static int CreateCRC32( struct dsc$descriptor *InputDataDesc ) { uint32 AUTODIN2; uint32 Seed = ~0UL; uint32 Coefficient = 0x0EDB88320UL; uint32 CRCArray[16]; lib$establish( lib$sig_to_ret ); lib$crc_table( (void *) &Coefficient, (void *) CRCArray ); AUTODIN2 = lib$crc( (void *) CRCArray, (void *) &Seed, InputDataDesc ); AUTODIN2 ^= Seed; return AUTODIN2; } |
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SYS_LOAD ADD TR$DEBUG TR$DEBUG/LOAD_STEP=INIT/LOG SYSMAN> Exit $ @SYS$UPDATE:VMS$SYSTEM_IMAGES.COM |
To stop it from loading early in boot
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SYS_LOAD REMOVE TR$DEBUG TR$DEBUG/LOG SYSMAN> Exit $ @SYS$UPDATE:VMS$SYSTEM_IMAGES.COM |
The first occurance of the name TR$DEBUG within the command is considered the "product" and the second is considered the "image" that should exist within SYS$LOADABLE_IMAGES.
When TR$DEBUG loads in the init phase, it will automatically turn on tracing.
Also see the SDA TR extension.
On a workstation, you will want to use the "Customize" menu of the session manager utility and select "Security". When the pop-up box appears, you can select the host node, username, and tranport that will allow you to launch an application that targets the workstation display.
If this does not provide you with access to the display, You need a checklist of sorts:
Shell | Command |
---|---|
csh | |
# setenv DISPLAY vms.domain:0.0 | |
sh and ksh | |
# $ DISPLAY=vms.domain:0.0 ; export DISPLAY | |
DCL | |
$ SET DISPLAY/CREATE/NODE=vms.domain -
/TRANSPORT=TCPIP/SERVER=server/SCREEN=screen |
To create a display from an OpenVMS host to a remote X Windows display, use one of the following DCL commands:
$ SET DISPLAY /CREATE /TRANSPORT=net_transport /NODE=remote_node $ SET DISPLAY /CREATE /TRANSPORT=LAT /NODE=remote_node $ SET DISPLAY /CREATE /TRANSPORT=DECnet /NODE=remote_node $ SET DISPLAY /CREATE /TRANSPORT=TCPIP /NODE=remote_node |
Note that LAT is typically used only for the VXT series X Windows terminals, but it can also be used from OpenVMS to OpenVMS systems on various OpenVMS releases, such as on OpenVMS Alpha V6.1 and later. For details on configuring the TCP/IP transport, see Section 11.14.
If you are interested in X Windows terminals and have an older
VAXstation system around, please see the EWS package on Freeware V5.0.
11.3 How can I get the information from SHOW DISPLAY into a symbol?
Use the undocumented SHOW DISPLAY/SYMBOL, and then reference the symbols DECW$DISPLAY_NODE, DECW$DISPLAY_SCREEN, DECW$DISPLAY_SERVER and/or DECW$DISPLAY_TRANSPORT.
An example of calling the underlying (and also undocumented) sys$qio programming interface for the WSDRIVER (WSAn:) is available at:
http://www.hp.com/go/openvms/freeware/ |
If you are working from a DECwindows DECterm terminal emulator, you can use the AutoPrint feature. Choose the "Printer..." menu item from the "Options" menu, set the printing destination to the name of the file you want, and set "Auto Print Mode". You are now free to continue.
It should be noted that all of the characters and escape sequences are captured, but if you display the resulting log file on a DECterm, then you will see exactly what was originally displayed.
You can also use the "Print Screen" screen capture available in the DECwindows session manager menus, if you simply wish to snapshot a particular portion of the X Windows display.
If you are using the Freeware
VTstar terminal emulator package, you will find a similar logging
mechanism is available in the menus.
11.5 Why is DECwindows Motif not starting?
First check to see if there is a graphics device, usually a G* device. (eg: On a DEC 2000 model 300, use the command SHOW DEVICE GQ) If you do not find a graphics device:
If there is a G* graphics device present:
$ DEFINE/SYSTEM/EXEC DECW$IGNORE_WORKSTATION TRUE |
$ LICENSE LIST DW-MOTIF/FULL $ LICENSE LIST NET-APP-SUP*/FULL |
$ DECW$XSIZE_IN_PIXELS == xvalue $ DECW$YSIZE_IN_PIXELS == yvalue $ DEFINE/SYSTEM DECW$SERVER_REFRESH_RATE rate_in_Hz |
If you are creating a new DECterm window, check
$ HELP CREATE /TERMINAL /WINDOW_ATTRIBUTES |
If you want to change the title of an existing window, use the following control sequences, where [esc] is the ANSI escape code, value decimal 27, and "text label" is what you want to display:
To set the DECterm title, send the escape character, then the characters "]21;", then the text label string, and then an escape character followed by a backslash character.
To set the icon label, send the escape character, then the characters "]2L;", then the icon label string, and then an escape character followed by a backslash character.
To set both the DECterm title and icon to the full device name, you can use the following DCL commands:
$ esc[0,7] = 27 $ fulldevnam = F$Edit(F$GetDVI("TT","FULLDEVNAM"),"UPCASE,COLLAPSE") $ write sys$output esc+ "]21;" + fulldevnam + esc + "\" $ write sys$output esc+ "]2L;" + fulldevnam + esc + "\" |
You can also change the title and the icon using the Options-Window... menu.
Also see Section 12.1 and Section 8.13.
11.7 How do I customize DECwindows, including the login screen?
To customize various DECwindows Motif characteristics including the defaults used by the SET DISPLAY command, the DECwindows login screen background logo used (the default is the DIGITAL, Compaq, or HP logo), various keymaps (also see Section 11.7.2 and Section 11.7.1), the FileView defaults, session manager defaults, the DECwindows login processing, DECwindows log file processing, and various other DECwindows attributes, see the example file:
$ SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.TEMPLATE |
This example template file is typically copied over to the filename SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM and then modified to meet site-specific requirements.
Additionally, various X tools such as xsetroot, bitmap and xrdb---some these can be useful in customizing the appearance of an application or of the DECwindows Motif display---are provided in the DECW$UTILS: area.
When using DECwindows V1.2-4 and later on OpenVMS Alpha, the default desktop is the Common Desktop Environment (CDE). You can select your preferred desktop (CDE or DECwindows Motif) when logging in, or you can change the default to the DECwindows Motif desktop using the DCL symbol decw$start_new_desktop in the DECwindows private application setup command procedure. See SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.TEMPLATE for further details, and how to create DECW$PRIVATE_APPS_SETUP.COM.
Note that with DECwindows CDE, the root window is no longer visible by default. The root window is hidden behind the "backdrop" window of the current CDE workspace. To make the root window visible, use the CDE style manager selection "backdrop none", and use information such as that in the OpenVMS FAQ to set the root window.
To add a new backdrop to the DECwindows CDE environment, the backdrop must first be in or be converted into X11 pixmap format. (This conversion is often possible using tools such as xv.) Then (if necessary) create the default backdrop directory SYS$COMMON:[CDE$DEFAULTS.USER.BACKDROPS]. Place the X11 pixmap file containing the desired image into the backdrops directory, ensure that it has a filename extension of .PM. (The xv default filename extension for the X11 pixmap file is .XPM, while CDE expects only to see files with .PM.) Now invoke the CDE style manager and select a new backdrop. You will find your image will be placed at the end of the list of backdrops available.
If you require a message be included on the initial display---where the start session display and the logo appears---you can use either of the following approaches:
SYS$SYSDEVICE:[VMS$COMMON.CDE$DEFAULTS.SYSTEM.CONFIG.C] |
SYS$SYSDEVICE:[VMS$COMMON.CDE$DEFAULTS.USER.CONFIG.C] |
Dtlogin*greeting.labelString: |
Welcome to %localhost% |
Dtlogin*greeting.labelString: Welcome to Heck \n\ This is a Trusted System owned by the Rulers of the planet Zark\n\ \n\ We Come In Peace\n\ \n If you want Privacy, you've come to the wrong place\n\ \n |
The login logo is stored as an XPM bitmap image in the text file SYS$SYSROOT:[SYSCOMMON.CDE$DEFAULTS.SYSTEM.APPCONFIG.ICONS.C]DECDTLOGO.P M, and it can be changed. Copy the file to SYS$SYSROOT:[SYSCOMMON.CDE$DEFAULTS.USER.APPCONFIG.ICONS.C]DECDTLOGO.PM, as DECwindows upgrades can replace the system version of this file.
On DECwindows V1.3-1 and later (and possibly on V1.3), both DECwindows CDE and DECwindows Motif displays use this logo file. On older releases, only the DECwindows CDE displays used this logo file, while the logo used for the Motif login display was hard-coded into the package and the only available override is the DECW$LOGINLOGO command procedure mechanism within the customized, site-specific DECW$PRIVATE_APPS_SETUP.COM file.
Look at the contents of the DECDTLOGO.PM file and at other *.XPM files and tools for additional details.
Previous | Next | Contents | Index |