StephenCuppett.com

November 12, 2006

3 years at IBM!

Filed under: Personal — scuppett @ 12:41 pm

In addition to the 11 months I worked as co-op during my last two years of College, I have been in Research Triangle Park, NC working for IBM for 3 years now. For the last 3 years I have been working as part of the System Verification Test team for z/OS Communications Server. The releases I have participated in include V1R6 – V1R8 with V1R9 just getting started from an SVT perspective.

Here is a link to the V1R8 z/OS Communications Server New Function Summary

It contains a listing of things that have changed in all three of those releases. The new function lineitems I was responsible and/or involved for testing include:

V1R8

  • IPv6 IPSec support
  • In this release, support was added to the IPSec support from V1R7 to include IPv6 targets. This testing again required extensive z/OS to z/OS stress and configuration testing as well as interoperable platform testing including Linux, AIX and AS/400 or iSeries. Windows XP & 2003 was useless during this testing as they don’t even provide compliant support for manual tunnel definitions. Support for IPv6 is promised in Windows Vista; however, I have yet to do that follow-on work and will make some attempts during V1R9 testing as time permits.
  • This test required evolving my IPv6 knowledge in general on some of the more fine-grained differences between it and IPv4.
  • IPSec NAPT (Network Address Port Translation Support)
    • When IPSec endpoints behind a NAT may also be sharing the same IP address, chances are they will access the same remote server and service and be attempting to do so on the same client side ports. When this happens, you have a significant amount of packet altering that can happen on the NAT router. It can be especially problematic when you have IPSec in the picture as in a lot of NAT cases, UDP encapsulation of all services happens on the same set of ports for all clients involved, the router is oblivious and just starts changing ports for clients! This lineitem increased the capabilities of the IPSec daemon implementation on z/OS to detect the existence of a NAPT device and react accordingly.
    • During testing of this item, understanding and ensuring NAPT translations were occuring in our sophisticated testing environment was paramount. In addition, I had to learn more security configuration on our routing platform (Cisco).
  • FTP Client API support for the REXX language
    • In V1R6 we introduced FTP Client API support for callable languages. In V1R8, we utilized that support once again to create a REXX function package that can exploit that support from the REXX programming language using stem variables.
    • Over the course of the previous two releases, my experience with the API and my REXX skills to this point made me a candidate to oversee this testing effort with a new hire in our area. I worked with this person to develop workloads and REXX scripts in the various supported environments to exploit this function. I also did some additional investigation/self-training into how I could build REXX function packages to enable support for other SVT tooling that has grown over the years.

    V1R7

    • Policy-based IP Security
    • In this release, Communications Server introduced a replacement for an aging IP Security and firewall product, Firewall Technologies. This new support was based on new, policy-based definitions. It included support for NAT Traversal and Sysplex Wide Security Associations (SWSA).
    • I learned several new things in testing this lineitem including IP Security as a protocol, as a whole, and it’s role in partner and cross-datacenter communications. I also gained a firm grasp in Cisco-based security configuration, Linux Openswan configuration, Windows IP Security configuration, z/OS sysplex concepts as well as experience configuring both the new policy-based IP security function and the outgoing z/OS Firewall Technologies product. In addition, one particular use case of this test was protecting EE (SNA Enterprise Extender) traffic between business partners whether separated by a NAT or not and I picked up several basics of the SNA side of our enterprise networking stack as well during the testing of this lineitem.
  • FTP Client API for C/C++
    • In V1R6, Communications Server for z/OS introduced FTP Client API support for callable languages. In this release, we extended that support to the C/C++ programming language.
    • I built on my compiler and platform C/C++ knowledge from the prior release to develop tooling and workloads exploiting this function. I also extended my C/C++ workload requirements to include support for the XML toolkit for z/OS to create intuitive workload drivers in this area.

    V1R6

    • Update to XWindows 6.6 and Motif 2.1
    • This function included upgraded libraries for XWindows and Motif. Not only that, but the new libraries shipped both 31 bit and 64 bit versions meaning an even more complicated test in that they had to coexist with each other, but also the prior versions of XWindows and Motif. This lineitem was necessary to support 64-bit Java on the platform.
    • I learned quite a bit about windowing in general as well as C/C++ development, compilation and libraries on the z/OS platform in testing this lineitem.
  • FTP Client API for Callable Languages (ASM, COBOL, PL/I)
    • This function allows programmatic access from callable languages to drive the extremely robust z/OS FTP client. It includes complete control flow manipulation as well as allows asynchronous execution of FTP subcommands with the rest of your program.
    • In testing this lineitem, I learned COBOL, JCL and FTP internals. I would say it was quite more than I had anticipated learning on such a low level.
  • Sendmail enablement for MLS (Multi-Level Security)
    • z/OS support sendmail in the USS environment. This mailer is packaged as part of its compliance with the Unix standard. The release sought to update the support for the advanced functions of the platform by allowing sendmail to be bound to a single networking stack as well as to allow systems participating in multiple security environments to isolate multiple sendmail instances on the system and provide true data isolation for highly secure computing environments.
    • I had prior understanding of Sendmail on Linux platforms, but this lineitem made me extremely aware of the inner workings of Sendmail as well as the theoretical and practical implications of advanced z/OS security functions such as multi-level security and multiple, discrete networking stacks on a single operating system. Other concepts came into play regarding mailers such as DNS MX and z/OS sysplex functions and its capabilities.

    Powered by WordPress