| Previous | \Contents | ^Index |
D If you are creating a bootable CD or DVD media for use with OpenVMS F I64, you will want to specify the SYS$SETBOOT block size of 2048, and H you will also want a disk cluster factor that is a multiple of four via D INITIALIZE/CLUSTER=4 (or 8, or...), or you will want to ensure that # SYS$EFI.SYS and SYS$DIAGNOSTICS.SYS H are aligned to a multiple of four blocks; to a 2048 byte boundary. This H alignment and this blocking is only necessary for OpenVMS I64, and only 7 when creating optical media OpenVMS I64 for bootstraps.
F The default 512-byte block setting used by SYS$SETBOOT is the correct B and expected value for traditional disk bootstraps on OpenVMS I64 systems.
C Once the boot files are loaded, OpenVMS I64 operates with 512-byte > blocks; as is the case with ATAPI disks on OpenVMS Alpha, all C application code will only see 512-byte blocks on optical media on OpenVMS I64.
= OpenVMS I64 V8.2 and later are expected to have a version of G SYS$SETBOOT that will flag a misaligned SYS$EFI.SYS and (if present) a $ misaligned SYS$DIAGNOSTICS.SYS file.
E For information on SYS$SETBOOT and the SET BOOTBLOCK command, please p see Section 14.3.9 and see the OpenVMS documentation. The purpose and E intent of the SYS$SETBOOT.EXE image and the SET BOOTBLOCK command is A analogous to the WRITEBOOT.EXE image on existing OpenVMS VAX and OpenVMS Alpha systems.
F For information on CD and DVD optical media drives on OpenVMS, please 9 see Section 14.30. j 9.8 What I/O transfer size limits exist in OpenVMS?
H The maximum transfer size is an attribute of the particular I/O device, F controller and driver combination; there is no inherent limit imposed F by OpenVMS (other than the fact that, today, byte counts and LBNs are generally limited to 32 bits).
D The maximum size of a device I/O request is limited by the value in B UCB$L_MAXBCNT, which is set by the device driver based on various D factors. (Also check the setting of the MAXBUF system parameter for 6 buffered I/O transfers, and check the process quotas.)
E Currently, SCSI drivers limit I/O transfers to FE00(16) bytes, 65024 C bytes (decimal). The reasons for this transfer size limitation are D largely historical. Similarly, DSSI devices are limited to the same D value, this for hardware-specific reasons. Transfers to HSC and HSJ E device controllers via the CI are limited to 1,048,576 bytes. Client E MSCP-served devices are limited to 65535 bytes---to help ensure that F the I/O fragmentation processing happens on the client and not on the server system.
D Parts of the OpenVMS I/O subsystem are optimized for data transfers < less than 64KB, because (obviously) most I/O operations are H (substantially) less than that. OpenVMS can handle larger transfers, if ( the driver and the device can handle it.
j Also see Section 9.4, Section 9.5. o 9.9 Can I use ODBC to connect to OpenVMS database files?
D Yes, you can use various available third-party packages that permit ? remote ODBC clients to access RMS files and various commercial databases via the network.
? For RMS, consider acquiring one of the packages available from E EasySoft, Attunity Connect (formerly known as ISG Navigator), Oracle D (DB Integrator), SolutionsIQ, OpenLink Software (OpenLink Universal Data Access), and Synergex.
The unixODBC 9 package available at http://www.unixodbc.org 8 has variously been found to operate on OpenVMS, as well.
G For specific commercial databases (other than RMS, of course), contact , the database vendor directly for assistance. w 9.10 If my disks are shown as VIOC Compatible, am I using XFC?
Yes, you are using XFC caching.
D Disks that are using XFC caching use communication and coordination : protocols that are compatible with the older VIOC caching G implementation. With the initial implementation of XFC on OpenVMS, you G can use the command SHOW MEMORY/CACHE to see no disks reported in full XFC mode; C all disks shown will be listed in "VIOC Compatable Mode".
D If you have the OpenVMS system parameter VCC_FLAGS set to 2 and are E using OpenVMS Alpha V7.3-1 or later, or are using OpenVMS Alpha V7.3 F with the VMS73_XFC V2.0 ECO kit or later or with the UPDATE kits, you are using XFC.
F Another confusion: the XFC product version is and remains V1.0 in all H released configurations, please do not confuse the internal XFC product @ version (displayed by various commands) with the version number A associated with the various ECO kit(s). XFC V1.0 does not permit E volumes to enter full XFC caching, as displayed by the "Vols in Full XFC mode" 5 portion of the DCL command SHOW MEMORY/CACHE output. o 9.11 RMS Sequential Files and Platform Portability?
D When working with mixed platforms, you will want to become familiar H with the various RMS sequential record formats, including Variable with C Fixed Control (VFC), stream, stream LF, and stream CR, among other record formats.
F Switching formats uses CONVERT/FDL or SET FILE/ATTRIBUTES. The former C converts files, the latter resets attributes. Text editors tend to C select attributes when creating new files that may or may not meet H requirements. If the default attributes do not match your requirements, F create a stub file, SET FILE/ATTR, then edit the existing file. (Most 6 editors will preserve attributes on an existing file.)
A When working with Windows, stream is usually the best choice for F sequential file operations. Stream LF is most commonly used with UNIX E and C applications. Windows and UNIX tend not to be able to directly 9 read files of "unexpected" sequential RMS record formats.
D VFC is a common OpenVMS format, encoding the record length into the F record. It is this extra data that can cause corruption-like problems B when viewed without RMS; either directly via $qio or via the file F system API on other operating system platforms. You will want to look B at the low-level record formats, and at the RMS and the Files and 2 Applications documentation in the OpenVMS manuals.
H If transfering through other platforms, use of a current version of Zip H (with the "-Vv" or "-Vv9" option) and unzip, or use of a BACKUP saveset C will contain and maintain the RMS file and record attributes. (For F BACKUP and its own attributes requirements, see the restoration tool.)
D Please first review the OpenVMS Programming Concepts Manual and the D Guide to Modular Programming manuals. Both are available within the E OpenVMS documentation set, and provide details of the expected norms for OpenVMS programs.
B OpenVMS provides a registry for facility prefixes and for MESSAGE H message compiler codes. To request a prefix and a message facility code C for a product you distributinng to other customer sites, send your ' request in a mail message addressed to D product[-at-sign-]hylndr.sqp.zko.dec.com, requesting the submission - form and details of the registration process.
H Please do not request facility prefixes for products that local to your C business, your site, or your system. Facility prefixes and message G codes and the facility registration process are intended solely for HP H products and Partner Products (and yes, even OpenVMS Freeware packages) H that will be distributed across multiple OpenVMS customer sites. |
C For a list of common coding bugs, please see the remainder of this k section of the FAQ and specifically Section 10.22, please also see the A Ask The Wizard topic (1661), and for information on debugging an - OpenVMS application, please see topic (7552).
H For additional information on the OpenVMS Ask The Wizard (ATW) area and B for a pointer to the available ATW Wizard.zip archive, please see 0 Section 3.9. k 10.2 Can I have a source code example of calling...?
H Please use the available SEARCH command on OpenVMS, and please remember G to search the available resources, including the support databases and E the newsgroup archives. Please also realize that most OpenVMS system C services use similar calling sequences, meaning that an example of @ calling sys$getjpi can be used as an example for sys$getsyi and > sys$getdvi. Students: please do not expect folks to write your * homework for you. As for search resources:
B OpenVMS programming documentation, including the numerous example A programs found in recent versions of the OpenVMS Programming # Concepts manual, is available:
E As for details of argument passing, most OpenVMS system services and B RTL routines pass string arguments by descriptor. Languages which C support native string data types create descriptors automatically; E those which do not (eg., C) require that you set them up explicitly. D For further details on using descriptors and particularly for using R descriptors from C, please see Section 10.13.
G There is extensive information available on how to call OpenVMS system F services and OpenVMS Run-Time Library routines, including examples in < numerous languages. Among the best available references are:
D In addition, if you are a subscriber to the HP Software Information C Network (available to those with a software support contract), the H support database contains hundreds of worked examples of calling system C services and RTL routines, including the one that seems to trip up ! almost everyone, SMG$CREATE_MENU.
D Arne Vajhøj has put together a collection of OpenVMS example programs. It can be found at:
B Additional information and examples for OpenVMS are available via:
H For additional information on the OpenVMS Ask The Wizard (ATW) area and B for a pointer to the available ATW Wizard.zip archive, please see 0 Section 3.9. and via:
mH If you're writing a program and want to accept arguments from a foreign G command, you can use LIB$GET_FOREIGN to get the command line and parse E it yourself, or if you're programming in C, use the normal argc/argv method.
2 To write an application which uses the normal DCL G verb/qualifier/parameter syntax for invocation, see the description of E the CLI$ routines in the OpenVMS Callable Utility Routines Reference Manual.
G It is possible to write an application which can be used both ways; if F a DCL verb isn't used to invoke the image, the application parses the G command line itself. One way to do this is to call CLI$GET_VALUE for a required < parameter. If it is not present (or you get an error), call @ LIB$GET_FOREIGN to get the command line and do the manual parse.
8 See also Section 8.1. q 10.4 How do I get a formatted error message in a variable?
E Use the SYS$PUTMSG system service with an action routine that stores G the message line(s) in the variable of your choice. Be sure the action A routine returns a "false" (low bit clear) function value so that
SYS$PUTMSG E doesn't then try to display the message (unless you want it to.) See G the description of $PUTMSG in the System Services Reference Manual for & an example of using an action routine. x 10.5 How do I link against SYS$SYSTEM:SYS.STB on an Alpha system?
G LINK/SYSEXE is the OpenVMS Alpha equivalent of linking against SYS.STB. 5 This links against the base image: SYS$BASE_IMAGE.EXE
i Also see Section 10.11, particularly for pointers to the details on . shareable images and shareable image creation. l 10.6 How do I do a SET DEFAULT from inside a program?
E The problem is that SYS$SETDDIR only changes the default directory - D NOT the default disk. The default disk is determined by the logical H SYS$DISK. If you want to change the default disk within a program, then F call LIB$SET_LOGICAL to change the logical SYS$DISK. You will need to F call both LIB$SET_LOGICAL and SYS$SETDDIR to change both default disk and the default directory! | 10.7 How do I turn my Fortran COMMON into a shareable image on Alpha?
B You need to add SYMBOL_VECTOR=(<common-name>=PSECT) to your G options file. On OpenVMS VAX all OVR/REL/GBL psects were automatically D exported into the shareable image's Global Symbol Table. On OpenVMS F Alpha you have to tell the linker that you want this done by means of > the PSECT keyword in the SYMBOL_VECTOR options file statement.
G This has several advantages over OpenVMS VAX. First, you don't have to C worry about the address of the psect when you try to create a new, D upwardly compatible version of the shareable image. Second, you can E control which psects, if any, are made visible outside the shareable image.
F By default, COMMON PSECTs in HP Fortran for OpenVMS Alpha (as well as G most other OpenVMS Alpha compilers) are NOSHR. On VAX, the default was F SHR which required you to change the attribute to NOSHR if you wanted C your COMMON to be in a shareable image but not write-shared by all ; processes on the system. If you do want write-sharing, use:
|
" CDEC$ PSECT common-name=SHR |
F in the Fortran source code (the CDEC$ must be begin in column 1) or a A linker options file PSECT_ATTR statement to set the COMMON PSECT attribute to SHR.
/ For further information, see the Linker manual. p 10.8 How do I convert between IEEE and VAX floating data?
G In OpenVMS V6.1 and later, the routine CVT$CONVERT_FLOAT is documented H in the LIB$ Run-Time Library Reference Manual, and can perform floating G point conversions between any two of the following floating datatypes: E VAX (F,D,G,H), little-endian IEEE (single, double, quad), big-endian : IEEE (single, double, quad), CRAY and IBM System\370, etc.
D HP Fortran (all OpenVMS platforms) has a feature which will perform E automatic conversion of unformatted data during input or output. See D the HP Fortran documentation for information on "non-native data in - I/O" and the CONVERT= OPEN statement keyword.
G There are floating-point conversion source code packages available for various platforms.
4 For further floating-point related information, see:
qF On VAX, many programmers would use a MACRO routine which accessed the AP register D of the caller to get the address of the argument list and hence the D argument count. This was not guaranteed to work on VAX, but usually F did. However, it doesn't work at all on OpenVMS Alpha, as there is no B AP register. On Alpha systems, you must use a language's built-in D function to retrieve the argument count, if any. In Fortran this is A IARGCOUNT, which is also available in DEC Fortran on OpenVMS VAX.
H Note that omitting arguments to Fortran routines is non-standard and is G unsupported. It will work in many cases - read the DEC Fortran release ! notes for additional information. u 10.10 How do I get a unique system ID for licensing purposes?
? Many software developers desire to use a unique hardware ID to E "lock" a given copy of their product to a specific system. = Most VAX and Alpha systems do not have a unique hardware-set D "system ID" that can be used for this purpose. HP OpenVMS C products do not use hardware IDs in the licensing methods, as many @ users consider a hardware-based licensing scheme to be negative . attribute when considering software purchases.
F HP OpenVMS uses a software-based system called the License Management G Facility (LMF). This provides for software keys (Product Authorization F Keys or PAKS) which support capacity and user-based license checking. e HP offers an LMF PAK Generator to CSA members---see Section 2.13.
[ For information on licensing, please see Section 12.5.
H However, if a hardware-based method is required, the most common method E is based on an Ethernet adaptor hardware address. Sample source code & for implementing this is available at:
H For additional information on the OpenVMS Ask The Wizard (ATW) area and B for a pointer to the available ATW Wizard.zip archive, please see 0 Section 3.9. u 10.11 What is an executable, shareable, system or UWSS image?
G Executable code in OpenVMS typically resides in an image---an image is C a file---the file extension is typically .EXE---that contains this B code. Common types of images include executable images, shareable 3 images, system images, and protected (UWSS) images.
D Executable images are programs that can be directly executed. These 5 images can grant enhanced privileges, with an INSTALL J of the image with /PRIVILEGE, or can grant enhanced access with the M specification of a subsystem identifier on the ACL associated with the image.
D Shareable images contain code executed indirectly, these images are F referenced from executable images and/or from other shareable images. E These images can not grant enhanced privileges, even with the use of INSTALL with /PRIVILEGE L or a subsystem identifier. These shareable images can be dynamically : activated (a LINK that occurs at run-time) via the < LIB$FIND_IMAGE_SYMBOL run-time library (RTL) routine. H (See `protected images' for information on `privileged shareable images'.)
? System images are intended to run directly on the VAX or Alpha F hardware---these are normally used for the kernel code that comprises an operating system.
C Protected images---also refered to as User-Written System Services F (UWSS), or as privileged shareable images---are similiar in some ways C to a standard shareable images, but these images include a `change D mode' handler, and execute in an `inner' processor mode (privileged B mode; executive or kernel), and code executing in inner modes has F implicit SETPRV privilege. Must be INSTALLed with /PROTECT. Note that B inner-mode code has restrictions around calling library routines, H around calling various system services, and around calling code located ' in other protected or shareable images.
F Loadable images and device drivers are images that can be used to add G code into the OpenVMS kernel. Pseudo-device drivers are a particularly F convenient way to add executable code, with associated driver-defined H data structures, into the kernel. The pseudo-device driver includes the UCB and DDB data structures, @ and a calling interface with support for both privileged and ? unprivileged access to the driver code via sys$qio[w] calls.
F A cookbook approach to creating OpenVMS shareable images is available at the URL:
H For additional information on the OpenVMS Ask The Wizard (ATW) area and B for a pointer to the available ATW Wizard.zip archive, please see 0 Section 3.9.
| Previous | YNext | \Contents | ^Index |