Browse Prior Art Database

Controlling PC Workloads from z/OS Disclosure Number: IPCOM000012890D
Original Publication Date: 2003-Jun-06
Included in the Prior Art Database: 2003-Jun-06
Document File: 2 page(s) / 6K

Publishing Venue



This disclosure publication explains an invention created for the CS SVT test group to control PC based workloads from z/OS. It uses a series of Netview command lists, jobs, and rexec commands to start, monitor and stop workloads on personal computers from z/OS.

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

Page 1 of 2

Controlling PC Workloads from z/OS

When testing Ethical Hacking, it was quickly realized that the majority of nasty things out there to attack our systems were written to run on Linux. Running workloads directly from PCs is not optimal for SVT long stress runs for a couple of reasons. One, it requires the tester to either be physically sitting at the PC or telnetted into it which can be difficult depending on the amount of traffic running on the network. Two, testers like to start and monitor workloads from z/OS. SVT has certain conventions (log files, CPU monitoring tools, storage monitoring tools, etc..) used to streamline the longrun process.

A process was created in which a tester could run and monitor the executables on the Linux PC from z/OS. It conforms to the SVT workload conventions by using a netview command list from the console to start the workload. From there it uses a series of jobs, tso clists, rexec commands and log files to run and monitor the workload. In short, a tester can start and monitor the entire workload from z/OS sdsf without ever going to the Linux PC, providing there is connectivity from the z/OS machine to the PC. This makes it a lot easier for others who might be working the longrun to monitor workloads and since the creation of this process, it has been adopted by many testers.

Here is an example of how a tester would use this process to start a workload running a shell script on a linux PC called "" In the past, a tester would have to either be physically sitting at this PC or telnetted into it to start, monitor and stop this workload. Obviously sitting at the PC is a hindrance since these runs...