Test results

For our testing, we created two stand-alone dump data sets: a single volume dump data set and a five-volume dump data set. We executed a stand-alone dump using MINASID(ALL) on a z/OS 1.10 system to both dump data sets. We also dumped to a 5-volume data set with MINASD(PHYSIN).

To have a consistent amount of information to dump, we started with a freshly IPLed image, varied the system out of the sysplex, then executed the stand-alone dump. Finally, we did a VARY OFFLINE command with AutoIPL. Figure 5-5 on page 102 shows the results of

Recommendation: In z/OS 1.10 or later, implement AutoIPL, even in installations using an

following three tests of stand-alone dumps. The results clearly show how multiple volumes can reduce the elapsed time of a stand-alone dump:

򐂰 S1: One volume with full data

򐂰 S2: Five volumes with full data

򐂰 S3: Five volumes with minimal data

Figure 5-5 Elapsed stand-alone dump times

To save the stand-alone dump statistics to a data set, we issued the commands under TSO and IPCS, as follows:

1. In TSO (select option 6), enter the following commands:

free ddname(ipcstoc) free ddname(ipcsprnt)

attrib (list1) dsorg(ps) recfm(v b a) lrecl(125) blksize(1254)

alloc ddname(ipcsprnt) dataset('zs9037.sadmttrp') mod keep space(10,5) cyl using(list1)

alloc ddname(ipcstoc) dataset('zs9037.sadmttrt') mod keep space(10,5) tracks using(list1)

2. In IPCS, browse the stand-alone dump data set (option 2), and enter the name of the stand-alone dump data set.

3. Enter the following IPCS commands:

ip open print (file(ipcsprnt) title(‘Test S1’)) ip verbx sadmpmsg ‘stats’ noterm print

ip close print

To determine the timings for the dump, we used the following command:

IP VERBX SADMPMSG ‘STATS’

Figure 5-6 on page 103 shows an extract from the result of that command. From this output, we can determine the elapsed time to complete the dump. In this case, the dump started at 16:21:06.82 (after the operator replied) and ended at 16:22:27.72, for an elapsed time of 20.90 seconds.

E la p s e d S A D M P tim e

0 5 1 0 1 5 2 0 2 5 3 0 3 5 4 0 S 1 S 2 S 3 T e st ru n S eco n d s

Figure 5-6 Message log from stand-alone dump

The ‘STATS’ option on the IPCS VERBX SADMPMSG command is intended for the use of IBM developers. But most of the information is fairly easy to understand. Figure 5-7 on page 104 shows a portion of the information provided by ‘STATS’ option. The headings in blue with an underline show the main sections of dump processing and provide the times, data rates, and other significant information about each section. The very last section provides information about the entire dump processing. This section actually gives us better

information about the elapsed time, the console delay time, and the real elapsed time of the dump than is provided in the message log. The data rate shows that this dump was able to dump an average of 59.3 MB per second. The data rate is dependent on the speed of the devices, the controllers, the connections, and the speed of the processor. The length of the dump is dependent on the data rate, the speed of the processors, and the amount of storage that was dumped.

Note: The multi-volume support in standalone dump is designed to write more data to the

faster devices and connections. In our tests, we used five volumes for our multi-volume tests. As you can see in Figure 5-6, because one of the volumes was on the latest DS8000 model, more data was written to that volume (23%) than to the other volumes, which were on ESS devices. You can determine the distribution among the dump data sets by looking at the end of the SADMP log.

*** STAND-ALONE DUMP MESSAGE LOG *** 16:20:51.37 AMD083I AMDSADMP: STAND-ALONE DUMP INITIALIZED. IPLDEV: D111 16:20:51.40 AMD001A SPECIFY OUTPUT DEVICE ADDRESS (1) 16:21:06.82 -193B

16:21:06.82 AMD114I AMDSADMP INITIATED BY MVS, WAIT STATE CODE = 001840A2

16:21:52.68 AMD094I 193B MTTRD1 SYS1.SADMP

16:21:52.71 IS VALID, HOWEVER, IT MAY ALREADY CONTAIN DATA FROM A PREVIOUS DUMP.

16:21:52.74 THE INSTALLATION CHOSE TO ALWAYS REUSE THE DUMP DATA SET. 16:21:52.94 AMD101I OUTPUT DEVICE: 193B MTTRD1 SYS1.SADMP 16:21:52.97 SENSE ID DATA: FF 3990 E9 3390 0A BLOCKSIZE: 24,960 16:21:53.06 AMD101I OUTPUT DEVICE: 6E20 MTTRD2 SYS1.SADMP 16:21:53.09 SENSE ID DATA: FF 3990 E9 3390 0C BLOCKSIZE: 24,960 . . .

16:21:53.50 AMD011A TITLE= 16:22:11.85 -S1 16:22:11.94 AMD005I DUMPING OF REAL STORAGE NOW IN PROGRESS. 16:22:13.27 AMD005I DUMPING OF PAGE FRAME TABLE COMPLETED. 16:22:13.73 AMD010I PROCESSING ASID=0001 ASCB=00FDC800 JOBNAME=*MASTER* 16:22:14.06 AMD076I PROCESSING DATA SPACE SYSDS000, OWNED BY ASID 0003. . . .

16:22:27.52 AMD005I DUMPING OF REAL STORAGE COMPLETED. 16:22:27.57 AMD104I DEVICE VOLUME USED DATA SET NAME 16:22:27.60 1 193B MTTRD1 4% SYS1.SADMP 16:22:27.63 2 6E20 MTTRD2 4% SYS1.SADMP 16:22:27.66 3 8407 MTTRD3 7% SYS1.SADMP 16:22:27.69 4 C425 MTTRD4 4% SYS1.SADMP

16:22:27.72 5 D50D MTTRD5 23% SYS1.SADMP

Figure 5-7 Output from STATS parameter

Restriction: Stand-alone dumps use a single CPU for processing the dump. The practical

limit for the speed of any stand-alone dump is the speed of the CPU. In test environments, the SADMP seems to max out at about 80% busy of a single processor. Adding additional data sets at that point does not provide any added benefit.

IARPFT Data Space Dump Statistics

Start time 05/29/2009 16:20:51.373440 Stop time 05/29/2009 16:22:13.736530 Elapsed time 00:01:22.36 Elapsed dumping time 00:00:03.58 Console reply wait time 00:01:18.77 . . .

Average output data rate 37.31 megabytes per second

Page buffers 888 SVC Frequency 0 8,724 3 43 . . . 120 224 252 67,642

In Real Virtual Dump Statistics

Start time 05/29/2009 16:22:13.736538 Stop time 05/29/2009 16:22:17.644181 Elapsed time 00:00:03.90 . . .

In Use Real Dump Statistics

Start time 05/29/2009 16:22:17.644192 Stop time 05/29/2009 16:22:17.872555 Elapsed time 00:00:00.22 . . .

Paged Out Virtual Dump Statistics

Start time 05/29/2009 16:22:17.872567 Stop time 05/29/2009 16:22:18.558727 Elapsed time 00:00:00.68 . . .

Available Real Dump Statistics

Start time 05/29/2009 16:22:18.558909 Stop time 05/29/2009 16:22:27.550227 Elapsed time 00:00:08.99

. . .

Total Dump Statistics

Start time 05/29/2009 16:20:51.373440 Stop time 05/29/2009 16:22:27.550227 Elapsed time 00:01:36.17 Elapsed dumping time 00:00:17.40 Console reply wait time 00:01:18.77

Logical records dumped 263,381 . . .

Additional recommendations for stand-alone dumps:

򐂰 Keep the control statements for AMDSADDD and AMDSADMP in a JCL library so that you can use them as a pattern for the next dumps.

򐂰 Use the MINASID(PHYSIN) option for the shortest dumps, although the dump may not contain all the information you need to debug the problem. In that situation, you might have to wait for a repeat of the problem, in which case you would get a full dump.

򐂰 Use IPCS to gather information about stand-alone dumps, such as the usage of the multiple volumes.

򐂰 Use multi-volume dumps. Although the Best Practices guidelines say that you can use up to 32 volumes, 16 seems to be the maximum based on the speed of the current processors.

Chapter 6.

CICS considerations

This chapter concentrates on the startup and shutdown times of CICS regions. It does not cover the performance for transactions running in a fully-initialized CICS region. For more information about the performance of a CICS region, see CICS Transaction Server for z/OS V3R2 Performance Guide, SC34-6833.

The startup times for your CICS regions only become a major issue when your users do not have access to the applications that run in your CICS regions. If you have a High Availability setup that allows the applications to be spread across a number of regions (which in turn are spread over a number of z/OS systems), providing continued access to your applications, even if one or more CICS regions are down, MTTR should be less of an issue.

This chapter explores options that might help reduce CICS startup times, from a configuration with just a single CICS region, up to a CICSplex with over 100 regions, spread over three z/OS systems. It also shows the results of various measurements to give an indication of where savings can occur.

In document System z Mean Time to Recovery Best Practices (Page 115-122)