Giter VIP home page Giter VIP logo

zoslib's Introduction

ZOSLIB - A z/OS C/C++ Library

Table of Contents

Overview

ZOSLIB is a z/OS C/C++ library. It is an extended implementation of the z/OS LE C Runtime Library.

ZOSLIB implements the following:

  • A subset of POSIX APIs that are not available in the LE C Runtime Library
  • EBCDIC <-> ASCII conversion C APIs
  • APIs for improved diagnostic reporting
  • and more!

System Requirements

ZOSLIB is supported on the following z/OS operating systems with z/OS UNIX System Services enabled:

  • z/OS V2R4 with the following PTFs installed:
    • UI64830
    • UI64837
    • UI64839
    • UI64940
    • UI65567
  • z/OS V2R5
    • UI78912
    • UI81095
    • UI80156
    • UI83424
  • z/OS V3R1

ZOSLIB is supported on the following hardware:

  • IBM z16
  • IBM z15
  • IBM z14/z14 Model ZR1
  • IBM z13/z13s
  • IBM zEnterprise EC12/BC12

Build and Install

Build tool prerequisites

  • CMake 3.24.2-zos+
  • GNU Make 4.3+
  • IBM XL C/C++ V2.3.1 for z/OS V2.3 web deliverable (xlclang/xlcang++) or IBM Open XL C/C++ 2.0 (clang/clang++)
  • Git
  • Ninja (optional)

Clone the ZOSLIB source code using Git into a newly created zoslib directory:

$ git clone [email protected]:ibmruntimes/zoslib.git zoslib

After obtaining the source, cd to the zoslib directory and follow one of the following options to build zoslib and run its tests.

  1. Use the included build.sh to build and optionally run the zoslib tests:
$ ./build.sh -h

which displays flags that you can pass to build.sh to specify a Release build (default is Debug) and whether to build and run the zoslib tests.

Example:

$ ./build.sh -c -r -t

performs a Clean (-c) Release (-r) build that creates both static library libzoslib.a and shared library libzoslib.so and its sidedeck libzoslib.x, then builds and runs the zoslib tests (-t).

build.sh creates directory ./build to hold the build files, and then places the target files under ./install directory.

  1. Use the steps below to build and optionally run the zoslib tests:

Create a build directory to hold your build files and cd to it:

$ mkdir build && cd build

Next, we will configure our build with CMake.

Make sure to export the CC and CXX environment variables to point to the supported C/C++ build compiler, or pass in the CMake options -DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER.

From the directory build, enter the following CMake command (here, .. refers to the ZOSLIB source directory)

$ cmake ..

By default CMake will configure your build as a Debug build. You can configure your build as a Release build with the -DCMAKE_BUILD_TYPE=Release option.

CMake will detect your development environment, perform a series of tests, and generate the files required for building ZOSLIB.

To build the zoslib tests, pass -DBUILD_TESTING=ON to cmake, which creates build/test/cctest that links with libzoslib.a, and also build/test/cctest that links with libzoslib.x. Before running the latter, set your LIBPATH to include the directory containing libzoslib.so, which should be under install/lib.

By default, CMake will generate Makefiles. If you prefer to use Ninja, you can specify -GNinja as an option to CMake.

After CMake has finished with the configuration, start the build from build using CMake:

$ cmake --build .

After ZOSLIB has finished building, install it from build:

$ cmake --build . --target install

Quick Start

Once we have ZOSLIB built and installed, let's attempt to build our first ZOSLIB C++ application. The application will generate a series of random numbers, leveraging the getentropy C API in ZOSLIB.

  1. Create a file named random.cc containing the following contents:
// random.cc

// Include zos.h ZOSLIB header
#include <zos.h>
#include <stdio.h>

// Initialize ZOSLIB class
__init_zoslib __nodezoslib;

int main(int argc, char** argv) {
  printf("ZOSLIB version: %s\n", __zoslib_version);
  if (argc < 1) {
    printf("An argument specifying the number of random "
           " numbers is required\n");
    return 1;
  }

  int num = atoi(argv[1]);
  if (num < 0) {
    printf("The argument should be positive (>0)\n");
    return 2;
  }
  printf("Generating %d random values\n", num);

  char buffer[10];
  for (int i = 0; i < num; i++) {
    printf("Random index: %d\n", i);
    // Call ZOSLIB getentropy C API
    if (!getentropy(buffer, 10)) {
      for (int j = 0; j < 10; j++)
        printf("%2X ", buffer[j]);
      printf("\n");
    }
  }
  return 0;
}

This example will first include the main ZOSLIB header file, zos.h, which subsequently includes all of the ZOSLIB header files. Alternatively, we could have just included zos-base.h, since the prototype for getentropy is defined in zos-base.h.

  1. In order to initialize ZOSLIB, we need to create a static instance of the __init_zoslib class: __init_zoslib zoslib_init;. This initializes the Enhanced ASCII runtime environment, among other things. If your application is C only, you can make use of the init_zoslib function instead.

In the main function, we make use of two ZOSLIB definitions, __zoslib_version to obtain the ZOSLIB version, and getentropy to generate a list of random values.

  1. To compile and link the application, enter the following command:
xlclang++ -qascii -I path/to/zoslib/include -L path/to/build/lib -lzoslib random.cc -o random

or:

clang++ -fzos-le-char-mode=ascii -I path/to/zoslib/include -L path/to/build/lib -lzoslib random.cc -o random
  1. To run the application, enter the following command:
./random 2

You should get an output similar to the following:

ZOSLIB version: v4.0.0
Generating 2 random values
Random index: 0
BC DE CF DE  7 E3 58 3A 4F 22
Random index: 1
5B 30 5A 9C C4 70 94 A6 B6 E5

API Documentation

The ZOSLIB API documentation is available here.

Legalities

ZOSLIB is available under the Apache 2.0 license. See the LICENSE file for details

Copyright

Licensed Materials - Property of IBM
ZOSLIB
(C) Copyright IBM Corp. 2020. All Rights Reserved.
US Government Users Restricted Rights - Use, duplication
or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

zoslib's People

Contributors

alexcfyung avatar bamadhu avatar dougburns avatar eakst7 avatar gabylb avatar harithaibm avatar igortodorovskiibm avatar mfsysprog avatar perry-ca avatar zsw007 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

zoslib's Issues

fails to build

CC: xlclang - v2.4.1 XL C/C++
CXX: xlclang++ - v2.4.1 XL C/C++
LINK xlclang++ - v2.4.1 XL C/C++

cmake is from z/os open tools. version 3.24.2-zos

$ rm build.cache
$ ./build.sh
-- The CXX compiler identification is zOS 420.3.1
-- The C compiler identification is zOS 420.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /bin/xlclang
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /bin/xlclang++
-- Check for working CXX compiler: /bin/xlclang++ - broken
CMake Error at /z/xxxx/zopen/prod/CMake-heads.v3.24.2/share/cmake-3.24/Modules/CMakeTestCXXCompiler.cmake:62 (message):
  The C++ compiler

    "/bin/xlclang++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /z/xxxx/zopen/dev/try2/xxx/zoslib/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/z/JD895801/zopen/boot/make/bin/make -f Makefile cmTC_3da59/fast && /z/JD895801/zopen/boot/make/bin/make  -f CMakeFiles/cmTC_3da59.dir/build.make CMakeFiles/cmTC_3da59.dir/build
    make[1]: Entering directory '/z/xxxx/zopen/dev/try2/xxx/zoslib/build/CMakeFiles/CMakeTmp'
    Building CXX object CMakeFiles/cmTC_3da59.dir/testCXXCompiler.cxx.o
    /bin/xlclang++    -o CMakeFiles/cmTC_3da59.dir/testCXXCompiler.cxx.o -c /z/xxxx/zopen/dev/try2/xxxx/zoslib/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
    Linking CXX executable cmTC_3da59
    /z/xxxx/zopen/prod/CMake-heads.v3.24.2/bin/cmake -E cmake_link_script CMakeFiles/cmTC_3da59.dir/link.txt --verbose=1
    /bin/xlclang++ CMakeFiles/cmTC_3da59.dir/testCXXCompiler.cxx.o -o cmTC_3da59
    FSUM3010 Specify a file with the correct suffix (.C, .hh, .i, .c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o./cmTC_3da59.
    make[1]: *** [CMakeFiles/cmTC_3da59.dir/build.make:99: cmTC_3da59] Error 1
    make[1]: Leaving directory '/z/Jxxxxx/zopen/dev/try2/xxxx/zoslib/build/CMakeFiles/CMakeTmp'
    make: *** [Makefile:127: cmTC_3da59/fast] Error 2

Add information so that people can determine what functions are extended and what additional functions are provided

I went to the docs and couldn't figure out if a function was available or not. 3 Examples came up that I tried to find:

  • tempnam (which I don't think is supported)
  • freopen (which I don't think is supported)
  • open and fopen (which were supported but I couldn't find them)

This would seem the most common case someone would go to the docs for and yet I gave up and grep'ed the code.

A simple solution would be to just have a list of functions that extend the core z/OS functions. A link would be great, but even the name of the file would be ok to start.
Also the services you provide would be handy to show too (e.g. __setdcssid).

Documentation is incomplete on how to build with zoslib

I wasn't able to compile using the options specified for C. I haven't whittled it to the minimum but found that:

-fzos-le-char-mode=ascii -D_XOPEN_SOURCE=600 -D_ALL_SOURCE -D_OPEN_SYS_FILE_EXT=1 -D_AE_BIMODAL=1 -D_ENHANCED_ASCII_EXT=0xFFFFFFFF  -DZOSLIB_OVERRIDE_CLIB=1 -DZOSLIB_OVERRIDE_CLIB_GETENV=1

worked.
Without at least some of those additional options, the header files spit out numerous errors.

@IgorTodorovskiIBM fyi

Implement chdir_long

Originally posted by @MikeFultonDev in #25 (review)

Currently, chdir_long calls chdir, but according to glibc's comment it should do the following:

/* This is a function much like chdir, but without the PATH_MAX limitation
94 : on the length of the directory name. A significant difference is that
95 : it must be able to modify (albeit only temporarily) the directory
96 : name. It handles an arbitrarily long directory name by operating
97 : on manageable portions of the name. On systems without the openat
98 : syscall, this means changing the working directory to more and more
99 : `distant' points along the long directory name and then restoring
100 : the working directory. If any of those attempts to save or restore
101 : the working directory fails, this function exits nonzero.
102 :
103 : Note that this function may still fail with errno == ENAMETOOLONG, but
104 : only if the specified directory name contains a component that is long
105 : enough to provoke such a failure all by itself (e.g. if the component
106 : has length PATH_MAX or greater on systems that define PATH_MAX). */

Test MountTest.GetMntInfo fails with "Expected: (onlen) >= (1), actual: 0 vs 1"

Running the test suite results in a test failure because getmntinfo returns an element with a zero length value in f_mntonname.

From the documentation for the w_getmntent function, I suspect this is because the userid running the tests does not have access to all of the mount points:

"If the caller of w_getmntent() lacks search authorization to one or more of the directories in the mount point pathname, mnt_mountpoint is returned empty. That is, mnt_pathlen is zero and mnt_mountpoint contains a NULL as the first character."

I don't know whether this should be handled in the function or requires a modification to the test.

strnlen doesn't work for long strings

strnlen's use of inline assembler for SRST doesn't seem to calculate the right value when the buffer to search is large.
In tests with a 100000 byte string, the function returns a value of 160.
Using the same string with a limit of 99999 gives a return value of 159.

__loadmod, __callmod and __unloadmod are not part of the public API

It's clear that my inquiry is a question, not a bug report. Nonetheless, I found the __loadmod, __callmod, and __unloadmod functions to be very practical. Nevertheless, these functions are not included in the public API. Is there a particular reason for this? Are they still being developed or subject to modifications?

call to 'cpp_nanosleep' is ambiguous

When building a project using zopen and the oelcpp clang, with a dependency on zoslib, I get the following.
/usr/lpp/IBM/oelcpp/v2r0/bin/ is in $PATH.

Is this a known problem, and is there a work-around, wherein I use the headers from zoslib, rather than oelcpp?

[1/287] Building CXX object src/execution/operator/join/CMakeFiles/duckdb_operator_join.dir/ub_duckdb_operator_join.cpp.o
FAILED: src/execution/operator/join/CMakeFiles/duckdb_operator_join.dir/ub_duckdb_operator_join.cpp.o 
/usr/lpp/IBM/oelcpp/v2r0/bin/clang++ -DDUCKDB -DDUCKDB_BUILD_LIBRARY -DDUCKDB_MAIN_LIBRARY -I/v1g/zopen/dev/duckdbport/duckdb/src/include -I/v1g/zopen/dev/duckdbport/duckdb/third_party/fsst -I/v1g/zopen/dev/duckdbport/duckdb/third_party/fmt/include -I/v1g/zopen/dev/duckdbport/duckdb/third_party/hyperloglog -I/v1g/zopen/dev/duckdbport/duckdb/third_party/fastpforlib -I/v1g/zopen/dev/duckdbport/duckdb/third_party/fast_float -I/v1g/zopen/dev/duckdbport/duckdb/third_party/re2 -I/v1g/zopen/dev/duckdbport/duckdb/third_party/miniz -I/v1g/zopen/dev/duckdbport/duckdb/third_party/utf8proc/include -I/v1g/zopen/dev/duckdbport/duckdb/third_party/miniparquet -I/v1g/zopen/dev/duckdbport/duckdb/third_party/concurrentqueue -I/v1g/zopen/dev/duckdbport/duckdb/third_party/pcg -I/v1g/zopen/dev/duckdbport/duckdb/third_party/tdigest -I/v1g/zopen/dev/duckdbport/duckdb/third_party/mbedtls/include -I/v1g/zopen/dev/duckdbport/duckdb/third_party/jaro_winkler -fzos-le-char-mode=ascii -mnocsect -fno-short-enums -O3  -fgnu-keywords -I/v1g/zopen/prod/zoslib-zopen/include -O3 -DNDEBUG -O3 -DNDEBUG   -fPIC -fcolor-diagnostics -std=c++11 -MD -MT src/execution/operator/join/CMakeFiles/duckdb_operator_join.dir/ub_duckdb_operator_join.cpp.o -MF src/execution/operator/join/CMakeFiles/duckdb_operator_join.dir/ub_duckdb_operator_join.cpp.o.d -o src/execution/operator/join/CMakeFiles/duckdb_operator_join.dir/ub_duckdb_operator_join.cpp.o -c /v1g/zopen/dev/duckdbport/duckdb/build/release/src/execution/operator/join/ub_duckdb_operator_join.cpp
In file included from /v1g/zopen/dev/duckdbport/duckdb/build/release/src/execution/operator/join/ub_duckdb_operator_join.cpp:2:
In file included from /v1g/zopen/dev/duckdbport/duckdb/src/execution/operator/join/outer_join_marker.cpp:1:
In file included from /v1g/zopen/dev/duckdbport/duckdb/src/include/duckdb/execution/operator/join/outer_join_marker.hpp:11:
In file included from /v1g/zopen/dev/duckdbport/duckdb/src/include/duckdb/common/mutex.hpp:11:
In file included from /usr/lpp/IBM/oelcpp/v2r0/bin/../include/c++/v1/mutex:190:
In file included from /usr/lpp/IBM/oelcpp/v2r0/bin/../include/c++/v1/__mutex_base:14:
In file included from /v1g/zopen/prod/zoslib-zopen/include/__threading_support:15:
/usr/lpp/IBM/oelcpp/v2r0/bin/../include/c++/v1/__threading_support:420:11: error: call to 'cpp_nanosleep' is ambiguous
   while (nanosleep(&__ts, &__ts) == -1 && errno == EINTR);
          ^~~~~~~~~
/v1g/zopen/prod/zoslib-zopen/include/__threading_support:14:19: note: expanded from macro 'nanosleep'
#define nanosleep cpp_nanosleep
                  ^~~~~~~~~~~~~
/v1g/zopen/prod/zoslib-zopen/include/time.h:64:16: note: candidate function
__Z_EXPORT int nanosleep(const struct timespec*, struct timespec*);
               ^
/v1g/zopen/prod/zoslib-zopen/include/__threading_support:14:19: note: expanded from macro 'nanosleep'
#define nanosleep cpp_nanosleep
                  ^
/usr/lpp/IBM/oelcpp/v2r0/bin/../include/c++/v1/__support/ibm/nanosleep.h:17:22: note: candidate function
_LIBCPP_FUNC_VIS int nanosleep(const struct timespec* , struct timespec* );
                     ^
/v1g/zopen/prod/zoslib-zopen/include/__threading_support:14:19: note: expanded from macro 'nanosleep'
#define nanosleep cpp_nanosleep
                  ^
1 error generated.

Build of shared libraries is broken

I ran the build.sh script to build a zoslib shared library. The build incorrectly creates the shared object and side file with a double lib prefix resulting in artifacts with the name liblibzoslib.

> ./build.sh -c -r -s                       -s
~/git/zoslib/build ~/git/zoslib
-- The CXX compiler identification is zOS 2.4.1
-- The C compiler identification is zOS 2.4.1
-- The ASM compiler identification is GNU
-- Found assembler: /bin/xlclang
-- Check for working CXX compiler: /bin/xlclang++
-- Check for working CXX compiler: /bin/xlclang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /bin/xlclang
-- Check for working C compiler: /bin/xlclang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /u/ts8004/git/zoslib/build
Scanning dependencies of target zoslib
[  5%] Building CXX object src/CMakeFiles/zoslib.dir/zos-bpx.cc.o
[ 11%] Building CXX object src/CMakeFiles/zoslib.dir/zos-char-util.cc.o
[ 17%] Building CXX object src/CMakeFiles/zoslib.dir/zos-getentropy.cc.o
[ 23%] Building CXX object src/CMakeFiles/zoslib.dir/zos-io.cc.o
[ 29%] Building CXX object src/CMakeFiles/zoslib.dir/zos-semaphore.cc.o
[ 35%] Building CXX object src/CMakeFiles/zoslib.dir/zos-sys-info.cc.o
[ 41%] Building CXX object src/CMakeFiles/zoslib.dir/zos-tls.cc.o
[ 47%] Building CXX object src/CMakeFiles/zoslib.dir/zos.cc.o
[ 52%] Building ASM object src/CMakeFiles/zoslib.dir/celquopt.s.o
[ 58%] Linking CXX shared library ../lib/liblibzoslib.so
[ 58%] Built target zoslib
Scanning dependencies of target cctest
[ 64%] Building CXX object test/CMakeFiles/cctest.dir/gtest_main.cc.o
[ 70%] Building CXX object test/CMakeFiles/cctest.dir/gtest/gtest-all.cc.o
 WARNING CLC1145: The function "std::__1::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_traits<char>, std::__1::allocator<char> > const&> const>::__enable_weak_this(...)" could not be inlined into "std::__1::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_traits<char>, std::__1::allocator<char> > const&> const>::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_tr
 WARNING CLC1145: The function "std::__1::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_traits<char>, std::__1::allocator<char> > const&> const>::__enable_weak_this(...)" could not be inlined into "std::__1::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_traits<char>, std::__1::allocator<char> > const&> const>::shared_ptr<testing::MatcherInterface<std::__1::_ASCII::basic_string<char, std::__1::_ASCII::char_tr
[ 76%] Building CXX object test/CMakeFiles/cctest.dir/test-args.cc.o
[ 82%] Building CXX object test/CMakeFiles/cctest.dir/test-bitset.cc.o
[ 88%] Building CXX object test/CMakeFiles/cctest.dir/test-convert.cc.o
[ 94%] Building CXX object test/CMakeFiles/cctest.dir/test-sys-info.cc.o
gmake[2]: *** No rule to make target 'lib/libzoslib.x', needed by 'test/cctest_so'.  Stop.
CMakeFiles/Makefile2:140: recipe for target 'test/CMakeFiles/cctest.dir/all' failed
gmake[1]: *** [test/CMakeFiles/cctest.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
gmake: *** [all] Error 2

To work around this I changed the CMakeLists.txt file to remove the lib prefix which is being add implicitly. I'm sure this is not optimal but I'm not cmake expert.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f4760e0..c1bf1d6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -21,7 +21,7 @@ if(NOT CMAKE_BUILD_TYPE)
 endif()

 if(NOT ${BUILD_SHARED_LIBS} MATCHES "OFF")
-  set_target_properties(zoslib PROPERTIES OUTPUT_NAME "libzoslib")
+  set_target_properties(zoslib PROPERTIES OUTPUT_NAME "zoslib")
   set_target_properties(zoslib PROPERTIES SUFFIX ".so")
 endif()

Add support for tmpfile

It would be nice to support tmpfile being ASCII aware. This is used in the c3270 port.
It isn't completely straight-forward because the file is supposed to be opened wb+ but perhaps if some env var was specified it could be exposed for use if people want? In my case it's actually used for text, not binary data.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.