IBM s/390 manual Here is an example that uses all three options

￿Use the writethroughcache parameter to force a different operation of the cache (on a device or control unit level). The default operation uses a writeback cache technique.

Here is an example that uses all three options:

(resources	definitions)
....
c3990A: cu	3390
interface local(1)
options ‘trackcachesize=150’
device(00)	3390-3 /usr/flexes/links/A3s1
device(01)	3390-3 /usr/flexes/links/B3s1 devopt ‘trackcachesize=5’
device(02)	3390-3	/usr/flexes/links/C3s1 devopt ‘trackcachesize=45’
device(03)	3390-3	/usr/flexes/links/D3s1 devopt ‘trackcachesize=30,writethroughcache’
device(04)	3390-1	OFFLINE devopt ‘trackcachesize=0’
end c3990A

This is a bit complex. The five devices defined will ask for (15 + 5 + 45 + 30 + 0 =) 95 tracks of cache. (Device (00) does not specify a cache size and defaults to 15 tracks.) The control unit definition specifies 150 tracks of cache. This is (150 - 95 =) 55 more tracks than needed by individual device caches, and the 55 tracks will be a floating cache. The floating cache is managed by internal FLEX-ES logic. Each 3390 track is about 57 KB, so the 150 tracks of cache will require about 8.3 MB of Server storage.

Cache is normally allocated for an offline device, since you might perform a FLEX-ES mount command to use the device. If you are certain you will not use the device (or you really want no cache for some reason), you can specify a cache of zero tracks.

If you specify a control unit cache size of less than the sum of the individual device caches, the specified control unit cache size is ignored.

FLEX-ES defaults to writeback cache operation. This allows the S/390 disk write channel operation to complete when the data is in the FLEX-ES cache. The data will be flushed to the Server disk at an indeterminate time in the future.10 An exposure exists if the system fails after a S/390 channel program thinks it completed a disk write, but the cache buffer has not really been written to disk. In this case, the S/390 program may have wrong state information. Such failures are extremely rare and the performance advantage of writeback is so great that this default operation is almost always used.

A writethrough operation means that the S/390 channel operation for a disk write is not complete until the data is actually written to the Server disk.11 A copy of the data is retained in the FLEX-ES cache for possible future use. A writethrough cache provides considerably lower performance than a writeback cache, but it provides higher integrity. It might be considered for a S/390 volume containing DB2 log data, for example.

If you have enough Server memory, you can specify large disk caches for better overall system performance. There is obviously room for considerable tuning here, by manipulating cache sizes at the device and control unit level. You can use the d ckdcachestats cuu command to monitor cache effectiveness:

flexes> d ckdcachestats A80
ADDRESS	READS	WRITES	CACHE HITS		DEDICATED LINES	LINES USED
A80	2880	182	1811	(97%)	15	15	(0%)
A81	2880	182	1811	(97%)	15	15	(0%)
A82	2880	182	1811	(97%)	15	15	(0%)

10This should be a familiar concept. The typical UNIX operation involves writeback caches, where the disk cache buffers are synched (flushed) to disk every 10 seconds or so.

11This is not quite correct, because the RAID adapter also has a cache and the individual disk drives often have a buffer that performs a temporary cache function. We ignore these points in the current discussion.

Chapter 5. Additional Topics 51