|
HP OpenVMS Systems Documentation |
|
OpenVMS Programming Concepts Manual
1.5.2 Creating Object FilesOpenVMS supports a variety of optional language compilers, interpreters, and assemblers that translate source code to object code (in the form of object modules). These language implementations adhere to industry standards, including ISO, ANSI, X/Open standards as well as U.S. Federal Information Processing Standards (FIPS) and Military Standards (MIL-STD), as applicable. Table 1-3 lists language compilers, interpreters, and assemblers supported in the OpenVMS VAX and OpenVMS Alpha environments. Names that begin with DEC refer to software available on Alpha and VAX platforms unless otherwise indicated.
1.5.3 Creating Runnable ProgramsAfter a program source file is coded, it must be compiled or assembled into object modules by a language processor and then linked. The OpenVMS Linker binds the object modules into an image that can be executed on the OpenVMS operating system. The linker processes object modules and shareable image files, as well as symbol table files, library files, and options files (used to manage the linking operation and simplify the use of complex, repetitious linker operations). The most common output of the linker is an executable image of the program. The linker can also produce a shareable image, a system image, an image map, or a symbol table file to be used by other programs being linked. Certain linking tasks, such as creating shareable images, are performed differently on OpenVMS VAX and OpenVMS Alpha systems.
The Librarian utility provides for efficient storage in central, easily
accessible files of object modules, image files, macros, help text, or
other record-oriented information.
The debugger allows users to trace program execution and to display and modify register contents using the same symbols as are in the source code. The following debugger utilities available on both the OpenVMS VAX and OpenVMS Alpha operating systems contain some system-specific features related to the platform architecture:
The OpenVMS symbolic debugger is more useful than DELTA/XDELTA for most programs: the symbolic commands entered using different interfaces (keypad, command line, or file of commands), display source code lines on the screen, have more descriptive error messages, and provides help information. The debugger command language specified in the OpenVMS Debugger Manual provides more than 100 commands to control a debugging session, including these tasks:
The OpenVMS symbolic debugger provides enhanced support for programs that have multiple threads of execution within an OpenVMS process, including any program that uses Compaq POSIX Threads Library for developing real-time applications. The debugger has been modified to support debugging of programs that contain 64-bit data addresses. An additional debugger utility is available only on an OpenVMS Alpha system: the OpenVMS Alpha System-Code Debugger, which can be used to debug non-pageable system code and device drivers. The system-code debugger is a symbolic debugger that lets the user employ the familiar OpenVMS Debugger interface to observe and manipulate system code interactively as it executes. The system-code debugger can display the source code where the software is executing and allows the user to advance by source line. Users can perform the following tasks using the system-code debugger:
You can use the OpenVMS Alpha System-Code Debugger to debug code
written in the following languages: C, BLISS, and MACRO. Information
about using the system-code debugger and how it differs from the
OpenVMS Debugger is given in Writing OpenVMS Alpha Device Drivers in C.
The OpenVMS operating system has a number of special modes of operation designed to aid in debugging complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by the following system parameters:
MULTIPROCESSING is useful for debugging privileged code that uses spinlocks, such as device driver code. POOLCHECK is useful for investigating frequent and inexplicable failures in a system. When POOLCHECK is enabled, pool-checking routines execute whenever pool is deallocated or allocated. BUGCHECKFATAL is useful for debugging the executive. SYSTEM_CHECK turns on the previous three system parameters and also activates other software that aids in detecting problems. It enables a number of run-time consistency checks on system operation and records some trace information. If you are using one of these special modes, for example, to debug a device driver or other complex application, under certain conditions generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. To prevent a CPUSPINWAIT bugcheck, use either the system default settings for these system parameters, or reduce the loading of the system.
If you have reason to change the default settings, you can reduce the
likelihood of encountering a problem by setting the SMP_LNGSPINWAIT
system parameter to a value of 9000000.
Other OpenVMS utility programs used for program development are listed in Table 1-4. RMS utilities, which permit file analysis and tuning, are covered in Section 1.10.2.
1VAX specific. 2Different versions run on the VAX and Alpha platforms. 1.5.6 Managing Software Development TasksYou can use optional products that run on OpenVMS systems to manage the complexity of software development tasks:
1.6 Using Callable System Routines
OpenVMS provides extensive libraries of prewritten and debugged
routines that can be accessed by programs. Libraries specific to
OpenVMS VAX and OpenVMS Alpha systems supply commonly needed routines
optimized for the OpenVMS environment; these libraries include run-time
library routines, system services, utility routines, and RMS services.
These libraries are described in this section.
The POSIX Threads Library, previously known as DECthreads, routine library provides a set of portable services that support concurrent programming by creating and controlling multiple threads of execution within the address space provided by a single process on an OpenVMS system. POSIX threads services are based on the IEEE POSIX standard 1003.1c and are compliant with OSF Distributed Computing Environment (DCE) standards. On OpenVMS Alpha systems, POSIX threads are layered over kernel threads. POSIX threads run-time library services provide an application programming interface usable from all OpenVMS languages and an open C-only POSIX interface that adheres to the POSIX threads standard. On OpenVMS Alpha systems, POSIX threads provide support to accept 64-bit parameters. The highly portable POSIX threads interface contains routines grouped in the following functional categories:
For more information about threads, see the Guide to POSIX Threads Library.
The OpenVMS Run-Time Library (RTL) is a set of language-independent procedures for programs to be run specifically in the OpenVMS environment. RTL routines establish a common run-time environment for application programs written in any language supported in the OpenVMS common language environment. RTL procedures adhere to the OpenVMS calling standard and can be called from any program or program module in a language supported by OpenVMS (see Section 1.5.2). The run-time library provides general-purpose functions for application programs. Table 1-5 summarizes the groups of RTL routines.
1VAX specific 2Alpha specific In addition, language-specific RTL routines support procedures in Ada, BASIC, C, COBOL, Fortran, Pascal, and PL/I as well as in POSIX C. Compaq C RTL routines support 64-bit programming on OpenVMS Alpha systems.
The Digital Extended Math Library (DXML) for OpenVMS is a set of
libraries of mathematical subroutines that are optimized for Compaq
platforms. DXML includes four libraries covering the areas of basic
linear algebra, linear system and eigenproblem solvers, sparse linear
system solvers, and signal processing. DXML offers development and
run-time options and is suitable for high-performance applications such
as seismic analysis, signal and image processing, and antenna design.
OpenVMS system services are procedures that control resources available to processes, provide for communication among processes, and perform basic operating system functions such as I/O coordination. Application programs can call OpenVMS system services to perform the same operations that the system services provide for the OpenVMS operating system (for example, creating a process or subprocess). At run time, an application program calls a system service and passes control of the process to it. After execution of the system service, the service returns control to the program and also returns a condition value. The program analyzes the condition value, determines the success or failure of the system service call, and alters program execution flow as required. OpenVMS system services are divided into functional groups, as shown in Table 1-6. System services can be used to protect and fine-tune the security of the OpenVMS environment, handle event flags and system interrupts, designate condition handlers, and provide logical name services and timer services to the application. Other system services control and provide information about processes, manage virtual memory use, and synchronize access to shared resources.
1Alpha specific OpenVMS I/O system services perform logical, physical, and virtual I/O and network operations, and queue messages to system processes. The $QIO system service provides a direct interface to the operating system's I/O routines. These services are available from within most programming languages supported by OpenVMS and can be used to perform low-level I/O operations efficiently with a minimal amount of system overhead for time-critical applications. On OpenVMS Alpha systems, new system services provide access to 64-bit virtual address space for process private use. Additionally, new system services are available to provide high CPU performance and improved symmetric multiprocessing (SMP) scaling of I/O operations. These services exhibit high-performance gains over the $QIO service. DECdtm services ensure consistent execution of applications on the OpenVMS operating system. In transaction processing applications, many users may be simultaneously making inquiries and updating a database. The distributed transaction processing environment typically involves communication between networked systems at different locations. DECdtm services coordinate distributed transactions by using the two-phase commit protocol and implementing special logging and communication techniques. DECdtm services ensure that all parts of a transaction are completed or the transaction is aborted.
|