IT Management

Nov 1 ’03

SYSTEMS PROGRAMMING

Regardless of whether you are installing VSE, VM, or z/OS, there are a few steps using Unix tools that must be performed for a new operating system level. These steps supplement rather than change any of the systems programming processes that would be employed on a zSeries processor. The first step is to create emulated CKD volumes using a Unix utility. The second step for PWD members is to install the operating system from the Application Development CD (ADCD) CD-ROMs.

Operating under the native Unix environment of the zDev, the contents of the 14 CD-ROMs are unzipped to create a fully integrated IPLable z/OS 1.4 environment with TSO, IMS, CICS, DB2, and language environments preinstalled by IBM. After the system has been copied to disk, the final Unix step is to tailor a FLEX-ES emulator initialization script to point to the new load address. This step can be completed in less than a minute using a text editor. Once completed, you can click on the script icon, IPL the system, and return to the familiar world of S/390 systems programming.

After you have IPLed the system, you will follow exactly the same process you would to customize a new operating system level on a real zSeries system. While I will not discuss these steps in detail, the z/OS customization process includes:

  • Using HCD to define new devices in the event of a new install, or to include devices defined in your prior z/OS level to the new system in the event of an upgrade
  • Tailoring the TCP/IP control members to customize the system’s IP address and to specify the address of the gateway to z/OS to establish connectivity
  • Creation of a user catalog for a new installation or connecting an existing user catalog to the primary catalog of the new z/OS system in the event of an upgrade
  • Activating your customized DFSMS routines
  • Customizing the JES members to include your user PROCLIBs
  • Creating multiple customized IPL PARMnn members for cold start and other recovery purposes
  • Creating your standard TSO logons
  • Deactivating and/or modifying the passwords of the default TSO logons that are included with the system for security purposes.

As is the case on a real zSeries system, several IPLs are required during the customization process. A z/OS IPL takes three to five minutes on one of our zDev servers.

Depending on the nature of your environment, you can minimize the disruption associated with installation and customization of a new z/OS level by using the FLEX-ES resource manager to establish multiple z/OS images. Since Performance Associates is a development rather than a production environment, we have elected to accept the brief outages associated with the installation of new z/OS levels rather than employing the resource manager to avoid them.

OUR ENVIRONMENT

As the photo in Figure 2 shows, our environment is comprised of two zDev servers and three SCSI-interface 3480/3490E tape drives. The two servers provide approximately 60 MIPS of processing power and internally support a total of 480GB of S/390 storage. In addition, each of the servers incorporates a 35/70GB SCSI-interface DLT drive that z/OS supports as a very big 3420. The internal DLT drives are used for our daily DFDSS backup processing. APC Uninterruptible Power Supplies (UPSes) isolate the servers from our local utility power grid. In the event of a persistent power outage, the UPSes communicate with the Unix side of the zDev servers to automatically shut down and quiesce the z/OS environments. While not a high-performance option, several 3390 volumes are shared between the two servers via a 100Mbit LAN connection to facilitate data movement.

The systems are connected to our office LAN environment and are accessible to our external employees and consultants via a virtual private network (VPN) over a 1Mbit business DSL connection. In addition to z/OS access via the VPN, the Unix sides of the zDev servers also have local network and VPN connectivity. Cornerstone employs the VPN connectivity to the Unix side of the two servers to remotely diagnose problems and apply scheduled maintenance to the emulator via the Unix environment.

3 Pages