HP 3000 Manuals HP 3000 Manuals
Chapter 6 Application Development Introducing Shared Globals on MPE/iX Loader by Huong Ho and Ed Olander Commercial Systems Division Intended Audience Beginning on Release 5.0, MPE/iX allows program and executable files (XLs) to share data between executable modules. This new functionality is referred to as Shared Globals. It gives HP 3000 users an extended capability of communicating between procedures and functions within a given application. This article is intended for system programmers, system managers, and individuals interested in writing application programs or in porting industry standard applications. The article provides a general overview of Shared Globals along with its features and benefits. Introduction MPE/iX starting on Release 5.0 allows program and executable files (XLs) to share data between load modules. This major enhancement enables System Object Modules (SOMs) to share global data. Traditionally, load modules on MPE/iX could only share code. With this release, they can share both code and data. Shared Globals code is the software mechanism that allows the global data of a load module to be shared with other load modules within a running process. Shared Globals is not shared memory, therefore, it cannot be shared among processes. Unlike shared code on MPE/iX where there is only one copy of the code for all processes on the system, Shared Globals is "shared" data that can be accessed only by the program and libraries within a single process. Shared Globals has been designed to be forward-compatible with future versions of the MPE/iX. Although there are no standards governing this functionality, its feature set and binding rules are closely aligned with the open systems development in this area (namely, HP-UX, System V-SVR and OSF). The MPE/iX implementation is similar to the HP-UX implementation. Prior to this enhancement, MPE/iX could not "share" data outside the load module in which it was defined.
NOTE POSIX or POSIX-related application developers must recompile and link their applications on Release 5.0. And, developers who want to use Shared Globals must relink and/or recompile their applications. If the developers are not POSIX users or do not plan on using Shared Globals, their applications will continue to run on Release 5.0.
Features and Benefits The current application development environment encourages programmers to use libraries for greater flexibility. That way at runtime they can select which libraries to use to share common library code. To have the same flexibility with data, they must also be allowed to share global data. The features and benefits of Shared Globals are described as follows: Features. * Availability - Executable modules are now able to share global data. This feature is particularly useful to C programmers who want to develop products on the HP 3000. * Portability - Sharing data on MPE/iX is similar to HP-UX data sharing. This facilitates and reduces the porting effort of UNIX-based applications to the HP 3000, therefore, increasing the application availability on the HP 3000. * Transparency - The enhancements to MPE/iX are highly transparent to the users. You can still compile, link and run your applications as before. Previously linked executables and compiled scripts continue to work on Release 5.0. * Extensibility - The design goals satisfy not only the semantics defined in UNIX Standards but go beyond these to meet the data properties and attributes specific to MPE/iX, such as privilege levels and memory residency. Benefits. * Resource sharing - The sharing of process resources can be maximized through the usage of Shared Globals. Programs and libraries become smaller and require less memory and disk space. Duplicate code in the application can be minimized or eliminated. * Supportability - Providing Shared Globals at runtime will significantly help increase the supportability of the user applications since data and code binding to resolve all external symbol references will be completely done at runtime. Enhancements and defect repairs made to the XLs would be easier to support because there is no need to modify the applications linked to them. XL changes would immediately affect all the applications that access them. Therefore, patches can be applied instantly to the XLs without requiring the application to be rebuilt. This makes proactive patch delivery easier for HP to accomplish. Third parties (VABs) are able to distribute their product applications with less dependency on HP's code. * Maintainability - On a given system, it is easier to maintain and manage a single version of the XLs rather than multiple versions of relocatable libraries (RLs) (libraries where symbols are resolved and satisfied at link time). You no longer need to track which fixes are compatible with which RL versions. * Flexibility - Shared Globals allow you to be more flexible and creative in organizing or arranging your application modules and control blocks, such as window applications with a data-only module that contains all window default configuration sizes or graphical elements. Please refer to the "MPE/iX Shared Globals Technical Overview" article in the "Technical Articles" chapter of this Communicator for more detailed information about Shared Globals and its related components. Also refer to the article, "POSIX Libraries in XLs" in Chapter 5 of this Communicator, for additional functionality made available because of Shared Globals.