Browse Prior Art Database

Z++APAR build/Packaging Process automation inside IBM

IP.com Disclosure Number: IPCOM000200012D
Publication Date: 2010-Sep-23
Document File: 2 page(s) / 34K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a Build/Packaging Process automation.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 2

Z++APAR build/Packaging Process automation inside IBM

When a customer encounters issues with our products they can open APAR requests. Those requests then get routed to the appropriate people to get a fix. When a fix is ready they need to be packaged as an APAR. In most platforms automating the packaging process is trivial. This is not so on the z/OS environment due to key restraints such as the lack of an API and the inherent architecture which requires automation developers to deal with the different interfaces of z/OS.

A request page form has been developed to simplify the process. The user enters the apar name, base build info, parts name and path in GSA, prereq PTFs and APARs name. Then it generates an xml file which contains the request info. It also kicks off a StAX job, read in the generated xml file and use a data dictionary as the whole process. Then StAX jobs kicks of Java program to download part in GSA, The StAX job then kicks off commands remotely on telnet session on aqts, creates data sets, xmit parts to VM. Then it starts a costumed build STAF service to receive parts, do all SPA navigation to build and package APAR, rename and send the package back to VM. The StAX job then modifies the package in the necessary part, then kick off the command to install and test in VICOM and EZWAS. If during the process anything goes wrong, it will send email to the requesters and z++APAR team to check.

Every small job in the stax will update the status xml file so that people can use a browser and start to check the real time status by looking at the status of the xml file w...