Tracker for z/OS LE/USS/Linker/Compiler limitations and their workarounds

[IgorTodorovskiIBM]

Use the following format:

• Issue: description of issue
• Workaround: description of workaround
• Affected Project:
• Long-term Ideas: Express any ideas on how to resolve this long term

---

[MikeFultonDev]

@IgorTodorovskiIBM where do you want people to open these issues?

[IgorTodorovskiIBM]

I was thinking we can add them here as comments to keep them under one umbrella? I'm open to other suggestions as well

[IgorTodorovskiIBM]

Issue: S_TYPEIS* macros are defined to null:

/usr/include/sys/modes.h:         #define S_TYPEISMQ  (0)         /* Test for a message queue */
/usr/include/sys/modes.h:         #define S_TYPEISSEM (0)         /* Test for a semaphore     */
/usr/include/sys/modes.h:         #define S_TYPEISSHM (0)         /* Test for a shared memory */

Workaround: Currently, we must guard all cases where S_TYPEIS* are used
Affected project: Coreutils
Long-term Ideas: LE or additional library to implement missing macros

[s66perry]

Macros like these have functions that return these values or take them as args. Is this just turning these into no-ops so basically these aren't supported or assumed can never happen?

[IgorTodorovskiIBM]

I think the issue with this one is that S_TYPEISSEM should take in an argument, but the macro stub doesn't allow for arguments to be passed. So a call like:

S_TYPEISSEM(statfs);

After preprocessing would look like:

0(statp);

[s66perry]

Why didn't you implement them as #define S_TYPEISSEM(__x) (0) if they are meant to have an argument? I guess you defined them on the command line. I suggest creating a sys/stat.h:

#ifndef H2_SYS_STAT_H
#include_next <sys/stat.h>
#ifndef S_TYPISMQ
#define S_TYPISMQ(__x) (0)
#define S_TYPEISSEM(__x) (0)
#define S_TYPEISSHM(__x) (0)
#endif  
#endif 

[IgorTodorovskiIBM]

They're defined incorrectly in /usr/include/sys/modes.h. We can probably override them in a library

[IgorTodorovskiIBM]

Issue: Copy implementation doesn't copy file tags. Projects that include an implementation of copy that copies two file descriptors or named files do not copy the source file's filetag attributes to the destination file.
Workaround: Add extra code to copy the cssid from the source file to the destination file: https://github.com/ZOSOpenTools/perlport/blob/main/patches/PR1/consolidate_os390_changes.patch#L180
Affected project: Perl, Coreutils, potentially others
Ideas: LE or additional library to implement https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html and copy tags

[IgorTodorovskiIBM]

Issue: New file descriptors created with open/pipe/socketpair are untagged and as such autoconversion doesn't work on these files.
Workaround: Add extra code after each open/pipe/socketpair to tag the newly created file descriptor or if possible, add overrides to open/pipe/socketpair as in https://github.com/ZOSOpenTools/perlport/blob/main/patches/PR1/consolidate_os390_changes.patch#L98
Affected project: Perl, Make, many others
Ideas: LE or additional library to implement an environment variable to control the file tag of newly created file descriptors

[IgorTodorovskiIBM]

Issue: stpcpy not implemented
Workaround: Implement stpcpy in project
Affected project: Make
Ideas: LE or additional library to implement stpcpy

[IgorTodorovskiIBM]

Issue: z/OS default environment differs from Linux.
Workaround: Set environment variable _EDC_SIG_DFLT (https://www.ibm.com/docs/kk/zos/2.3.0?topic=library-edc-sig-dflt) to suppress signals from emitting in stderr and set environment variable _EDC_SUSV3 (https://www.ibm.com/docs/en/zos/2.1.0?topic=library-edc-susv3) to match setenv behaviour in Linux.
Affected project: Most projects
Ideas: Additional library that all projects statically link to to set these environment variable by default

[s66perry]

Are these macros or env vars? If macros which header?

[IgorTodorovskiIBM]

They are environment variables, edited the above description with links

[v1gnesh]

Issue: _SC_PHYS_PAGES not available in zOS's sysconf. Can't get amount of free memory.
Affected project: duckdb
Workaround: ???
Ideas: Create a new function in ZOSLIB to get the default memory allocation from IEFUSI/REGION/MEMLIMIT/MAXASSIZE.
This function (hopefully a sample in both C and C++) can then be used through a pre-processor block (or whatever #ifdef is) here -
https://github.com/duckdb/duckdb/blob/e466d90508a4422179068bb3a94c0c44f239155e/src/common/file_system.cpp#L71

[ 19%] Building CXX object src/common/CMakeFiles/duckdb_common.dir/ub_duckdb_common.cpp.o
In file included from /v1g/zopen/dev/duckdb/build/release/src/common/ub_duckdb_common.cpp:14:
/v1g/zopen/dev/duckdb/src/common/file_system.cpp:73:52: error: use of undeclared identifier '_SC_PHYS_PAGES'
        idx_t max_memory = MinValue<idx_t>((idx_t)sysconf(_SC_PHYS_PAGES) * (idx_t)sysconf(_SC_PAGESIZE), UINTPTR_MAX);
                                                          ^
/v1g/zopen/dev/duckdb/src/common/file_system.cpp:81:40: error: use of undeclared identifier 'PATH_MAX'
        auto buffer = make_unsafe_array<char>(PATH_MAX);
                                              ^
/v1g/zopen/dev/duckdb/src/common/file_system.cpp:82:35: error: use of undeclared identifier 'PATH_MAX'
        char *ret = getcwd(buffer.get(), PATH_MAX);
                                         ^
3 errors generated.

No idea what PATH_MAX is on about...

git cloned repo is at /v1g/zopen/dev/duckdb and the whole log at /v1g/zopen/dev/duckdb-make.txt.
Needed to update CMakeCache.txt to use clang and clang++ instead of /bin/cc and /bin/c++.

[MikeFultonDev]

@IgorTodorovskiIBM I am thinking this might be better as a reference somewhere? Or maybe just roll up the issues somehow into a document somewhere? Anyone interested in taking that on? Is there an 'ideas' area we could use in z/OS and then perhaps reference it? @lbdyck I know you are comfortable with that process - could we somehow then label the ideas and have a query to see what the current state of the requests are?