Technical Bulletin - GT.M on IBM eServer zSeries z/OS

Copyright © 2010 Fidelity Information Services, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.

GT.M™ is a trademark of Fidelity Information Services, Inc. (FIS).  Other trademarks are the property of their respective owners.


This document contains a description of GT.M and the operating instructions pertaining to the various functions that comprise the system.  This document does not contain any commitment made by FIS.  FIS believes the information in this publication is accurate as of its publication date; such information is subject to change without notice.  FIS is not responsible for any errors or defects.


Revision History

Version
Date
Summary
1.0
July 9, 2009
First published version
1.1 August 25, 2009 Correct zlib version; Specify required hardware for z/OS platform;
Correct typographic errors; Corrections to table on IO conversions; Corrected URL for IBM C/C++ programming guide; Fix internal hyperkinks

GT.M Group

Fidelity National Information Services, Inc.

2 West Liberty Boulevard, Suite 300

Malvern, Pennsylvania 19355

United States of America

GT.M Support for customers: +1 (610) 578-4226 / gtmsupport@fisglobal.com


Switchboard: +1 (610) 296-8877

Website: http://fis-gtm.com


 

Table of Contents

  1. Technical Bulletin - GT.M on IBM eServer zSeries z/OS
    1. Revision History
      1. z/OS for those with knowledge of GT.M
      2. GT.M for those with knowledge of z/OS
        1. Terminal
    2. Platform
      1. Required
        1. zFS
        2. Environment Variables
      2. Optional
        1. zlib 1.1.4
    3. Device Handling
      1. Background
      2. Automatic Conversion
        1. SD and FIFO
        2. PIPE DEVICE
      3. Devices with chset="BINARY"
    4. External Routines
    5. Object files in shared libraries


Overview Effective V5.3-004, GT.M supports the z/OS operating system on IBM eServer zSeries mainframes.

z/OS for those with knowledge of GT.M

IBM eServer zSeries z/OS is different from platforms on which GT.M has previously been deployed in that it can present different environments for applications or users at the same time.  On z/OS, GT.M runs using the POSIX compliant run-time interfaces.  A z/OS userid must have access enabled to POSIX functionality.  Some system administration required for GT.M may need to be performed outside the POSIX environment (e.g., via TSO).  There are file systems and other large sections of z/OS that are inaccessible to GT.M processes.  GT.M provides access to files only on the zFS file system.

Perhaps the most important factor is that z/OS natively uses the EBCDIC character sets, whereas GT.M uses ASCII as specified by the M standard, with support for Unicode (ISO/IEC-10646) in UTF-8 mode.  Metadata for files in the zFS file system allows files to be tagged to specify their encoding.  The tags denote a specific code page for use in automatic conversions between code sets.  Although this is transparent in many cases, it is not in others, especially when GT.M processes operate in UTF-8 mode.  As part of porting an application to GT.M on z/OS from GT.M on another platform, you must review all I/O operations and ensure appropriate tagging / conversion takes place.

A z/OS userid must have access enabled to POSIX functionality by creating an OMVS segment in the native security product (e.g., RACF).  Once configured, GT.M on z/OS provides the same M environment in which a GT.M programmer from any other POSIX compliant platform would feel at home.  While GT.M source code is highly portable between z/OS and GT.M's other POSIX platforms, you may have to update some deviceparameters in order to achieve the desired behavior in the z/OS EBCDIC environment.

While the operation of utility programs MUPIP, DSE, LKE and GDE on z/OS is identical to their operation on other POSIX platforms, there are some operational limitations on this platform.  Specifically:


These limitations arise from current z/OS limitations.  We anticipate removing them in the future when IBM addresses the underlying z/OS limitations.

Return to Table of Contents

GT.M for those with knowledge of z/OS

GT.M provides a schemaless database and application development platform.  It has important differences from traditional database engines and application development platforms:


Databases and journal files are supported only on files in zFS file systems.

In addition to a database engine, GT.M also has a compiler for its scripting language that generates executable code in object files (with a .o file extension) from program code in source files (with a .m extension).  Processes use AMODE 64 addressing.  Object files generated by GT.M can optionally be placed in dynamically linked libraries (DLLs) with the standard ld system utility; when so configured, there is only one copy of a routine shared by hundreds or thousands of processes.

A GT.M process has a native internal character set of either ASCII ("M mode") or Unicode (ISO/IEC-10646; "UTF-8 mode").  GT.M processes can read and write IBM-1047 EBCDIC sequential files.

Since M source programs should contain only ASCII characters, they should be tagged as ASCII.  Note that the GT.M compiler tolerates certain byte sequences (e.g., those representing valid UTF-8 characters) inside string literals and comments.  FIS does not recommend this practice because it can result in different string literals between M mode compilation and UTF-8 mode compilation.  If your application needs literal strings with non-ASCII characters (those with either byte values or Unicode character values greater than 127), you can use $Char() or $ZChar().  For example, the FIS Profile application schema uses $ZChar(254) in cross references to represent a null subscript in the primary reference.  To create a string literal with this byte value in a portable manner, use a construct such as: "ABC|"_$ZChar(254)_"|DEF".  As the GT.M compiler pre-computes such string literals at compile time, this usage incurs no run-time penalty.

Return to Table of Contents

Terminal

GT.M treats terminals as full duplex devices supporting either ASCII or UTF-8.  FIS has only tested access via ssh (see below).  If you want cursor addressing to work correctly, you must ensure that your TERMINFO settings match your terminal emulation software.

Return to Table of Contents

Platform

Required

GT.M requires a minimum architecture level of z9 and a minimum z/OS release level of V1R10 with the latest POSIX compliant runtime interfaces and the performant zFS file system.  Supported hardware includes:


To use encryption with GT.M requires the addition of the Crypto Express2 card and the ICSF (Integrated Cryptographic Service Facility) software stack.  Database users must also have read access to the CSFRNG (random number generate service) in the RACF(R) CSFSERV class.


GT.M may well run on other compatible hardware, but as of this date has only been validated on the listed configurations.

Please ensure that your system is current with APARs.  The following are definitely required:


In addition, there are some issues with diagnostic tools which do not affect production operation, but can impact troubleshooting any problems that may arise.  IBM is working with FIS to address these issues - contact either for a current set of APARs.

GT.M uses a character mode interface.  FIS has only tested access with OpenSSH, which can be found in IBM Ported Tools for z/OS.

GT.M requires a shell for the ZSYSTEM command and for I/O to a PIPE device.  The GT.M development group at FIS uses an updated version of tcsh distributed by IBM for z/OS.  Use of GT.M's ZEDIT command requires an editor.

For Unicode support, the GT.M installation script requires an installed en_US.UTF-8 locale.  Subsequent use of GT.M in UTF-8 mode requires only the locale(s) of your choice.

If the system log daemon (syslogd) is not operating, GT.M processes, including gtmsecshr, will terminate when they attempt to record information in the system log.  If you see disappearing processes, and gtmsechsr processes that fail to start when expected, verify that syslogd is operational.

Return to Table of Contents

zFS

zFS is the only file system supported.  If the IPL of z/OS does not automatically start zFS, you must explicitly start it before you run GT.M.

FIS recommends you benchmark your application and configuration prior to production deployment.  As a starting point, you can consider the following tuning parameters used for one benchmark of the FIS Profile real-time core banking application:

adm_threads 10
aggrgrow
ON
auto_attach
ON
cmd_trace
OFF
convert_auditfid OFF
log_cache_size 16M
meta_cache_size 32M
nbs ON
romount_recovery OFF
sync_interval 11
sysplex_state 0
tran_cache_size 2000
user_cache_readahead ON
user_cache_size 1024M
vnode_cache_limit 500000
vnode_cache_size 32768

Since GT.M accesses databases randomly, you should determine whether NOREADAHEAD for database file systems gives your workloads better performance.  As journal files are normally appended to and not read from, the [NO]READAHEAD setting should not affect journal file performance for normal operation.  Since journal files are read sequentially when they are read - during system recovery, and when a catching up a replicating secondary instance - you should determine whether a setting of READAHEAD for file systems used for journal files gives better performance.

zFS supports file system cloning.  This can be a quick way to take a backup.  If you wish to use zFS cloning to take a backup, you must first freeze the database with MUPIP; otherwise, the dirty database blocks in GT.M's global buffers are not flushed to disk and the backup copy of the database is likely to be structurally unsound:

  1. Freeze updates to the database with MUPIP, e.g.: mupip freeze -on "*"
  2. Create new journal files with MUPIP, e.g.: mupip set -journal="before" -region "*"
  3. Clone the database file system(s).  If you have multiple database files on different zFS file systems, clone all of them at this time in order to get a snapshot of the database consistent across all the database files that together make up the logical database.
  4. Release the freeze with with MUPIP, e.g.: mupip freeze -off "*"

Return to Table of Contents

Environment Variables

Each GT.M process requires several environment variables to have appropriate values. To turn on automatic conversion when GT.M reads from and writes to sequential files:


If you use the /bin/sh or the tcsh shell , set the following additional environment variables:


If you want to enable GT.M's UTF-8 mode, the locale should be specified using the gtm_chset_locale environment variable instead of the LC_CTYPE variable since the shells require locales with 31-bit addressing, which are not compatible with GT.M.  When specifying the locale, omit the suffix (.xplink or .lp64) as show below:

$ locale -a |grep en_US.UTF-8
en_US.UTF-8.xplink
en_US.UTF-8.lp64
$ export gtm_chset_locale=en_US.UTF-8

Return to Table of Contents

Optional

For some of its functionality, GT.M has a plug-in architecture that uses external libraries: zlib for compression of the replication stream, ICU for Unicode support, as well as packages such as GPG for encryption.  These are not part of GT.M, but must be separately installed by you.


Return to Table of Contents

zlib 1.1.4

Download the zlib 1.1.41 from the libpng project's download page on SourceForge.com.  Use a transfer mechanism that does not perform automatic conversion to download a source tarball.  If pax cannot read the archive, it is a sign that the download mangled the archive.  Use pax to unpack the tarball, converting files from ASCII to EBCDIC.

pax -r -o setfiletag -ofrom=ISO8859-1,to=IBM-1047 -f zlib-1.1.4.tar.gz

Apply the following patch to the zlib 1.1.4 sources:

---------------------------------- zlib_1.1.4_zos.patch --------------------------------------------------diff -purN downloads/zlib/src.orig/configure downloads/zlib/src/configure--- downloads/zlib/src.orig/configure Tue Dec 16 14:09:57 2008+++ downloads/zlib/src/configure Mon Feb 9 14:30:49 2009@@ -116,6 +116,11 @@ else SFLAGS=${CFLAGS-"-Kconform_pic -O"} CFLAGS=${CFLAGS-"-O"} LDSHARED=${LDSHARED-"cc -G"};;+ OS/390*)+ CC=xlc+ SFLAGS=${CFLAGS-"-qascii -q64 -Wc,DLL,LP64,XPLINK,EXPORTALL -D_ALL_SOURCE_NOTHREADS"}+ CFLAGS=${CFLAGS-"-qascii -q64 -Wc,DLL,LP64,XPLINK,EXPORTALL -D_ALL_SOURCE_NOTHREADS"}+ LDSHARED=${LDSHARED-"xlc -qascii -q64 -Wl,dll,LP64,XPLINK "};; # send working options for other systems to support@gzip.org *) SFLAGS=${CFLAGS-"-O"} CFLAGS=${CFLAGS-"-O"}


Build and install the zlib DLL, placing the xlc compilers in compatibility to mode by setting the environment variable C89_CCMODE to 1.  When not in compatibility mode, xlc follows strict placement of command line options.  Configure and build the zlib software with ./configure --shared && make.  By default, the configure script places zlib in /usr/local/lib.  Install the software with make install.  To ensure that GT.M finds zlib, include /usr/local/lib in LIBPATH, the environment variable that provides a search path for processes to use when they link DLLs.

Return to Table of Contents

Device Handling

Background

This section applies to GT.M device I/O operations, but not to database I/O.  GT.M implicitly manages all database I/O, so the application code never needs to deal with any character representation issues associated with database files.  GT.M performs and tags all I/O not under explicit application control as either ASCII or BINARY except for output to log files, for which GT.M uses EBCDIC to conform to the native environment.

The following discussion of I/O controlled by M program source pertains to the following GT.M device types: FIFO (also known as named pipes), PIPEs, and Sequential Disk (SD) files.  SOCKET devices operate as byte steams - typically ASCII or UTF-8 and need no z/OS-specific discussion.2

Internally a GT.M process has only two character representations: in M mode as single 8 bit bytes (GT.M only associates meaning to the characters with byte values 0 through 127 - 0x00 through 0x7F - but performs IO on characters with byte values 128 through 255 - 0x80 through 0xFF - without assuming any representation or meaning for them) and in UTF-8 mode as multi-byte Unicode characters encoded in UTF-8.  In either mode, GT.M can handle binary data with arbitrary byte values.  A GT.M process in M mode conceptually performs I/O on devices one byte at a time with no conversion.  A GT.M process in UTF-8 mode conceptually performs I/O one Unicode  character at a time.  Using the chset deviceparameter, application code can open a device with the following character sets "M", "UTF-8", "UTF-16", "UTF-16BE", or "UTF-16LE".  GT.M enables z/OS' automatic conversion between the internal UTF-8 representation and the external representation as appropriate.  On z/OS, GT.M provides the following additional chset options: "ASCII", "BINARY", and "EBCDIC".  In the context of GT.M, EBCDIC means codeset IBM-1047.

Other POSIX platforms simply treat files as ordered arrays of bytes.  z/OS additionally provides the ability to tag a file with metadata, which can be used in automatically converting between the encoding used by the file and that expected by a program, as well as by a program to detect when an input file has the wrong format.  The metadata consists of two tags, a numeric Coded Character Set ID (CCSID) and a Text flag.  The following sets of values are pertinent to GT.M:

Type
CCSID
Text Flag
ASCII (ISO/IEC 8859 variants)
819
1
Binary
65535
0
EBCDIC Latin 1 / Open Systems
1047
1
UTF-8
01208
1
UTF-16
01204
1
UTF-16LE
01202
1
UTF-16BE
01200
1

Use the iconv utility program to convert files between different encodings.  For example, to convert a file from EBCDIC to ASCII and tag it as ASCII you can use:


iconv -T -f IBM-1047 -t ISO8859-1 inputfile >outputfile


The z/OS chtag utility program modifes tag metadata.  For example, to tag a file as ASCII, you can use:


chtag -t -c ISO8859-1 asciifile

 

Unlike iconv, chtag changes only the metadata tag, leaving the file contents unchanged.

Return to Table of Contents

Automatic Conversion

Only devices for which automatic conversion is provided by GT.M on z/OS are discussed below.  Other devices, that behave on z/OS as they do on other POSIX platforms, and for which no automatic conversion exists on z/OS, are not mentioned.

Return to Table of Contents

SD and FIFO

With appropriate values for environment variables, as discussed in the Environment Variables section above, GT.M and z/OS together perform automatic conversion subject to certain restrictions.

For input to a GT.M process, the table below specifies conversions.  Cells with a grey background are meaningful only for processes in UTF-8 mode and are errors in M mode.

OPEN deviceparameter ichset (or simply chset if ichset is not explicitly specified)
Existing file, tagged 819 (ISO/IEC 8859-1)
Existing file, tagged 1047 (EBCDIC) Existing file, tagged 65535 (Binary) Existing file, other ASCII tag Existing file, other EBCDIC tag Existing file, tagged 1208 (UTF-8) Existing file, tagged 1200, 1202 or 1204 (UTF-16 variants) Existing file, untagged
"ASCII" No conversion Error
Error
Error
Error
Error
Error
No conversion
"BINARY" No conversion
No conversion No conversion No conversion No conversion No conversion No conversion No conversion
"EBCDIC" Error
Conversion from EBCDIC to ISO/IEC 8859-1 by z/OS Error
Error
Error
Error
Error
Conversion from EBCDIC to ISO/IEC 8859-1 by z/OS
"M" No conversion
Conversion from EBCDIC to ISO/IEC 8859-1 by z/OS No conversion
No conversion
Error
No conversion (read one byte at a time)
No conversion (read one byte at a time) No conversion (read one byte at a time)
"UTF-8" Parsed for UTF-8 per ICU Error
Error
Error
Error
Parsed for UTF-8 per ICU Error
Parsed for UTF-8 per ICU
"UTF-16", "UTF-16BE" or "UTF-16LE" Error
Error
Error
Error
Error
Error
Parsed for appropriate UTF-16 variant per ICU Parsed for appropriate UTF-16 (as if it were tagged 1204)
Not specified
No conversion in M mode; parsed for UTF-8 per ICU in UTF-8 mode
In M mode conversion from EBCDIC to ISO/IEC 8859-1 by z/OS; error in UTF-8 mode
No conversion in M mode; error in UTF-8 mode
No conversion in M mode; error in UTF- mode
Error
No conversion in M mode; parsed for UTF-8 per ICU in UTF-8 mode Parsed for appropriate UTF-16 variant per ICU No conversion in M mode; parsed for UTF-8 per ICU in UTF-8 mode

For output from a GT.M, the table below specifies conversions.  Cells with a grey background are meaningful only for processes in UTF-8 mode, and are errors in M mode.

OPEN deviceparameter ochset (or simply chset if ochset is not explicitly specified)
New file or NEWVERSION specified
Existing file, tagged 819 (ISO/IEC-8859-1)
Existing file, tagged 1047 (EBCDIC)
Existing file, tagged 65535 (Binary)
Existing file, other ASCII tag
Existing file, other EBCDIC tag
Existing file, tagged 1208 (UTF-8)
Existing file, tagged 1200, 1202 or 1204 (UTF-16 variants)
Existing file, untagged
"ASCII"
Tagged as ISO/IEC 819 with no conversion No conversion
Error
Error
Error
Error
Error Error No conversion
"BINARY"
Tagged as 65535 with no conversion
No conversion
No conversion
No conversion
No conversion
No conversion
No conversion No conversion No conversion
"EBCDIC"
Tagged as 1047 with conversion from ISO/IEC 8859-1 to EBCDIC by z/OS Error
Conversion from ISO/IEC 8859-1 to EBCDIC by z/OS
Error
Error
Error
Error Error Conversion from ISO/IEC 8859-1 to EBCDIC by z/OS
"M", or not specified in M mode
Tagged as 819 with no conversion
No conversion
Automatic conversion from ISO/IEC 8859-1 to EBCDIC by z/OS No conversion
No conversion
Error
No conversion Conversion from UTF-8 to specified UTF-16 encoding per ICU No conversion
"UTF-8", or not specified in UTF-8 mode
Tagged as 1208 with no conversion
No conversion
Error
Error
Error
Error
No conversion
Error
Error
"UTF-16", "UTF-16BE" or "UTF-16LE"
Tagged as 1200, 1202 or 1204, as appropriate, with conversion from UTF-8 to specified UTF-16 encoding per ICU Error Error Error Error Error Error Conversion from UTF-8 to specified UTF-16 encoding per ICU Error

Notes:

  1. The GT.M device $Principal internally maps to two operating system file descriptors, one for STDIN and another for STDOUT (GT.M does not at present provide the ability to write to STDERR).  Since STDIN and STDOUT can be tagged differently, the GT.M runtime system potentially enables different conversions, for READ from $Principal and WRITE to $Principal.
  2. MUPIP extracts in ZWR or GO format always contain only ASCII characters, and are tagged as ASCII - ZWR uses $CHAR() representation of non-ASCII characters.  MUPIP extracts in BIN format are tagged as binary.  Extract files imported into a z/OS environment from other environments must be converted with iconv or tagged with chtag before they are loaded.

Return to Table of Contents

PIPE DEVICE

OPEN of a GT.M PIPE device creates a shell and feeds it a command.  The GT.M process can then WRITE to and/or READ from the device. With the deviceparameter CHSET, the OPEN command can specify the same character set for both input and output, or it can specify different character sets by specifying both ICHSET and OCHSET deviceparamters.  When the process specifies the CHSET, GT.M enforces the selection with conversion as appropriate using the same rules above for SD and FIFO (as you would expect, BINARY passes the data unaltered).  When the OPEN does not specify the CHSET, the PIPE handling depends on the process character set representation, which can be M mode or UTF-8 mode.  When using an EBCDIC character set other than IBM-1047, specify the ASCII character set and pipe the information through iconv to create or consume the appropriate character set.

In M mode, GT.M READ and WRITE operations to a PIPE device default to tagged IBM-1047 with conversion enabled.  Tagged with conversion turned on means either ASCII or EBCDIC (IBM-1047) programs on the other side of the PIPE device (initiated by the invoked shell) read GT.M's output in their native format.  Anything those programs write in ASCII or IBM-1047 EBCDIC, GT.M reads as ASCII.

In UTF-8 mode GT.M READ and WRITE operations to a PIPE device default to tagged ASCII with conversion enabled.  When using the environment variable gtm_dont_tag_UTF8_ASCII is defined to 1, "TRUE" or "YES" (independent of case), GT.M tags the device as UTF-8 and disables conversion.  Note that z/OS shell utility programs and TSO programs do not recognize or convert data with the UTF-8 CCSID.

READ of the STDERR port of the PIPE has conversion enabled and typically expects IBM-1047 EBCDIC, but ASCII works as well.  The application program cannot specify the character set for the stderr port.

Return to Table of Contents

Devices with chset="BINARY"

A deviceparameter CHSET of "BINARY" is incompatible with the VARIABLE, STREAM and WRAP deviceparameters.  If the deviceparameters specify BINARY as well as either VARIABLE or STREAM, GT.M uses the last deviceparamter specified and ignores those that conflict.  WRAP by itself is insufficient to override BINARY.

With a BINARY file, GT.M cannot deduce how much data to return for a READ command (unlike a text file, for example, where a line terminator can provide a natural boundary).  Therefore, for a READ with no length specified, GT.M treats the file as having a FIXED format, and returns RECORDSIZE bytes of data (unless the end of file is encountered first).  A BINARY file has no record format so unlike FIXED, no padding is added when writing.

A file tagged as binary can only be opened by GT.M with a CHSET of either "M" or "BINARY".

Return to Table of Contents

External Routines

GT.M operates as an AMODE 64 ASCII application using POSIX APIs on z/OS.  It has the ability to call out to and be called from external routines written in C.  The z/OS XL C/C++ compiler with the -q64 compiler option is the IBM Language Environment conforming language compiler currently supporting development for GT.M interfaces.  The -qascii compiler option changes the characteristics of a program from EBCDIC to ASCII.  Character strings within these applications are represented as ASCII and not EBCDIC.

When building a shared library for use with GT.M it must be compiled as AMODE 64 and ASCII.  In addition to those requirements, software linking to GT.M might need to define MACROs to use advanced POSIX features.  Place xlc into compatibility mode by setting the environment variable _C89_CCMODE to 1.  Compatibility mode increases the flexibility of command line argument placement for xlc which simplifies porting existing software builds to z/OS.

Compile and Link in one step:
  1. xlc -q64 -qascii -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -W c,DLL,XPLINK,EXPORTALL,RENT,NOANSIALIAS,LANGLVL(EXTENDED),ARCH(7) -W l,DLL,XPLINK,REUS=RENT $gtm_exe/libgtmshr.x source files

Comple and Link in two steps:
  1. Compile source files into object files
    xlc -c  -q64 -qascii -D_ENHANCED_ASCII_EXT=0xFFFFFFFF -W c,DLL,XPLINK,EXPORTALL,RENT,NOANSIALIAS,LANGLVL(EXTENDED),ARCH(7) -W l,DLL,XPLINK source files
  2. Link object files into an executable or shared library
    xlc -q64 -W l,DLL,XPLINK,REUS=RENT -o dll name object files $gtm_exe/libgtmshr.x

Depending on the features needed for a shared library the following compile line options may be needed:
  1. -D_ALL_SOURCE_NO_THREADS
    enables POSIX.1, POSIX.1a, POSIX.2, XPG4.2, and XPG4.2 Ext, DISABLES THREADING
  2. -D_XOPEN_SOURCE_EXTENDED=1
    enables POSIX.1, POSIX.2, XPG4.2, and XPG4.2 Ext., this should be redundant to -D_ALL_SOURCE_NO_THREADS, but it enables other feature test macros
  3. -D_UNIX03_SOURCE
    exposes a few of the SUSv3 options, for exmaple dlclose(), dlerror(), dlopen(), dlsym()
  4. -D_IEEEV1_COMPATIBILITY
    enable IEEE math compatibility

Please reference IBM's documentation in the z/OS V1R10.0 XL C/C++ Programming Guide [Online Dohttp://publib.boulder.ibm.com/infocenter/zos/v1r10/topic/com.ibm.zos.r10.cee/cee.htmcumentation] [PDF] for more information on feature test macros and compiling DLLs.

Return to Table of Contents

Object files in shared libraries

As on other 64-bit platforms, GT.M object files can be placed in dynamically linked shared libraries.  This allows one copy of each object file in a shared library to be shared by all processes using it.

The DLL binding options for building a shared library for Mumps routines are the same binding options for external calls and call ins.  Here is an example of how build a shared library of M routines:
  1. Compile your M sources to object files, e.g.: mumps a.m b.m c.m
  2. Link the object files into one DLL, e.g.: xlc -q64 -W c,DLL,XPLINK,EXPORTFULL -W l,DLL,XPLINK -o my.dll a.o b.o c.o
  3. Include the DLL in the gtmroutines search path, e.g.: export gtmroutines=". my.dll $gtm_dist"

Return to Table of Contents






notes



1 As of this date, the current version of zlib is 1.2.3.  We used the older version because, when we built the newer version on z/OS, it failed its own internal tests.

2 Two device types are deprecated and no longer maintained: Magnetic Tapes (MT) and TCP; they are not supported on z/OS.