• The data is never stored on the Linux system, but instead simply piped by the curl command over a Secure Sockets Layer (SSL)-encrypted File Transfer Protocol (FTP) connection to the remote host.
By itself, however, this first example isn’t compelling; the z/OS Communications Server/FTP product can, with work, be configured to do FTPS (SSL) directly. Consider Figure 2. In this example, a data set with variablelength binary records is sent to a business partner using HTTP. The -b -l ibmrdw options on the fromdsn command create a binary stream with records delimited by IBM-style record descriptor words. This data is piped into the gzip command for compression. The compressed output data is piped into the gpg command to be encrypted. Finally, curl sends the encrypted data using an HTTP URL. This example shows how Linux pipes can be used to quickly connect powerful open source tools with z/OS data sets, offloading much of the processing to an inexpensive hardware platform.
When this job runs, stdout and stderr output from the Linux shell are redirected to the job’s STDOUT and STDERR DDs, which by default are sent to JES SYSOUT files. For this example, the job’s output looks like Figure 3. In this case, gzip and gpg don’t generate any messages, but Figure 3 shows output from fromdsn, todsn, and curl. The condition code from the batch job step is adopted from the Linux shell script exit code (RC=0), so it can be used to influence the flow of subsequent job steps. When using multiple commands connected with pipes, the default behavior is to return the exit code of the last command. The set -o pipefail bash option is used to cause the shell’s exit code to be set to the last non-zero exit code. It’s important to use this option so intermediate errors can be detected.
The previous examples show outbound file transfers. Inbound exchanges can be similarly performed. In Figure 4, curl is used first to download a file using SFTP (SSH). The output is piped into the todsn command, which uses RDWs to separate binary records and write them to a z/OS data set. No extra encryption step is required since SSH has already done that.
You can learn more by visiting these Websites:
• “Curl” http://curl.haxx.se/
• “GnuPG” http://gnupg.org/
• “Gzip” http://www.gnu.org/software/gzip/
• “IBM Ported Tools for z/OS: OpenSSH” www.ibm.com/servers/eserver/zseries/zos/unix/openssh/index.html
• “Co:Z Co-Processing Toolkit for z/OS” http://dovetail.com/coz.
The file transfer gateway shown here is just one example of using Linux to extend z/OS; there are many other possibilities. The ability to leverage the flexibility of Linux and its wealth of open source software under the control of z/OS is a topic that hasn’t received much attention, but is ripe for exploration.