How to size the port

Having the correct skills before starting a porting project is essential. C programming and debugging skills are critical. When source code needs to be modified to get an application or tool running on another platform, it helps if the programmer doing the port also knows the application (and, even better, has experience porting this code to other platforms).

Size the port in advance.

General UNIX Porting Considerations

Requisite knowledge and skills

• Experience with C programming
• Facility with the POSIX shell and utilities
• Understanding of the POSIX API
• Familiarity with the source program
• Facility with debugging

Common problems

• Differences in the programming environment
  • Non-standard header file names and contents
  • Platform-specific APIs
• Differences in the development environment
  • Language extensions and compiler leniency
  • Compiler parameterization
  • Make file semantics
• Few applications are strictly POSIX compliant

How portable is the code?

How much of the code will need to be rewritten? A code checker tool can be used in advance of a porting project to identify code that will need to be changed. Code Integrity, a tool from Mortice Kern Systems of Waterloo, Canada, analyzes an application to determine if there are non-portable functions used. It has specific information for OpenExtensions. Code checkers can provide a useful checklist if no one with porting experience of application knowledge is available.

In many cases, however, the reason that a particular piece of code does not port to a new environment has more to do with the way that a function has been used rather than the function itself.

How much effort is involved?

1. Make a list of all system calls that the application makes. Compare this list with the OpenExtensions-supplied C functions. Any functions that OpenExtensions does not supply will have to be addressed during the port.

   To help make a list of system calls, you might try using the nm utility on the platform where the executable(s) are already built. While the list may not be perfect, it can often point out trends in API usage.

2. Also, you will uncover header files that cannot be ported. For some of these missing headers, there are workarounds.

3. Analyze the code for ASCII dependencies to determine how much work this may involve.

Challenges of Porting to OpenExtensions for z/VM

• fork() and spawn()
• ASCII and EBCDIC
• Floating point
• Interactive terminal connection
• Header files
• Missing functions
• Compiler idiosyncracies
• make utility differences

fork() and spawn()

• Original UNIX version
  • First program forks
  • Parent process continues or waits
  • Child process alters its environment
    • File descriptors
    • Signal mask
    • Process group
    • Controlling terminal
  • Child process execs second program
• Ported VM version
  • First program spawns second program, specifying environment alterations

Floating point

• IEEE binary vs. IBM hexadecimal format
• Subtleties at the machine instruction level - IBM floating point truncates least significant digits. IEEE rounds the least significant digits.

Interactive terminal connections

• VM provides canonical mode only; no character mode on 3270 based terminals

Missing functions

• OpenExtensions for z/VM contains a subset of XPG4.2 and Universal UNIX level functions. Refer to the list of OpenExtensions-supplied C functions. for the POSIX.1, XPG4, and XPG4.2 functions and commands supported in OpenExtensions for z/VM.

Compiler idiosyncracies

• Prototyping
• External identifiers - you need to "pragma map" external identifiers
• C for MVS and VM is relatively strict - enforces many more compiler rules

make utility differences

• POSIX compliant VM make is intolerant of common extensions
• Consider porting Waterloo dmake or GNU make