Lines Matching refs:the

12 This item delivers a new Linux API in the form of a misc char device that is
13 usable from user space and allows read access to the z/VM Monitor Records
14 collected by the *MONITOR System Service of z/VM.
20 order to allow IUCV connections to the *MONITOR service, i.e. it needs the
21 IUCV *MONITOR statement in its user entry. If the monitor DCSS to be used is
22 restricted (likely), you also need the NAMESAVE <DCSS NAME> statement.
23 This item will use the IUCV device driver to access the z/VM services, so you
26 There are two options for being able to load the monitor DCSS (examples assume
27 that the monitor DCSS begins at 144 MB and ends at 152 MB). You can query the
28 location of the monitor DCSS with the Class E privileged CP command Q NSS MAP
29 (the values BEGPAG and ENDPAG are given in units of 4K pages).
32 on the DEF STOR and Q NSS MAP commands, as well as "Saved Segments Planning
37 You can use the CP command DEF STOR CONFIG to define a "memory hole" in your
38 guest virtual storage around the address range of the DCSS.
42 This defines two blocks of storage, the first is 140MB in size an begins at
43 address 0MB, the second is 200MB in size and begins at address 200MB,
44 resulting in a total storage of 340MB. Note that the first block should
49 Your guest virtual storage has to end below the starting address of the DCSS
50 and you have to specify the "mem=" kernel parameter in your parmfile with a
51 value greater than the ending address of the DCSS.
55 This defines 140MB storage size for your guest, the parameter "mem=160M" is
56 added to the parmfile.
62 which can be loaded via the modprobe command, or it can be compiled into the
64 to specify the name of the monitor DCSS. If the module is compiled into the
65 kernel, the kernel parameter "monreader.mondcss=<DCSS NAME>" can be specified
66 in the parmfile.
68 The default name for the DCSS is "MONDCSS" if none is specified. In case that
69 there are other users already connected to the *MONITOR service (e.g.
70 Performance Toolkit), the monitor DCSS is already defined and you have to use
71 the same DCSS. The CP command Q MONITOR (Class E privileged) shows the name
72 of the monitor DCSS, if already defined, and the users connected to the
74 Refer to the "z/VM Performance" book (SC24-6109-00) on how to create a monitor
82 This loads the module and sets the DCSS name to "MYDCSS".
86 This API provides no interface to control the *MONITOR service, e.g. specify
87 which data should be collected. This can be done by the CP command MONITOR
92 After loading the module, a char device will be created along with the device
98 automatically and you have to create it manually after loading the module.
99 Therefore you need to know the major and minor numbers of the device. These
101 Typing cat /sys/class/misc/monreader/dev will give an output of the form
102 <major>:<minor>. The device node can be created via the mknod command, enter
103 mknod <name> c <major> <minor>, where <name> is the name of the device node
113 This loads the module with the default monitor DCSS (MONDCSS) and creates a
125 Reading from the device provides a 12 Byte monitor control element (MCE),
126 followed by a set of one or more contiguous monitor records (similar to the
127 output of the CMS utility MONWRITE without the 4K control blocks). The MCE
128 contains information on the type of the following record set (sample/event
129 data), the monitor domains contained within it and the start and end address
130 of the record set in the monitor DCSS. The start and end address can be used
131 to determine the size of the record set, the end address is the address of the
133 correctly (domain 1, record 13), i.e. it can be used to determine the record
136 See "Appendix A: *MONITOR" in the "z/VM Performance" document for a description
137 of the monitor control element layout. The layout of the monitor records can
140 The layout of the data stream provided by the monreader device is as follows:
152 within one data set and the end of each data set is indicated by a successful
155 read successfully, including the closing 0 byte read. Therefore you should
156 always read the complete set into a buffer before processing the data.
158 The maximum size of a data set can be as large as the size of the
159 monitor DCSS, so design the buffer adequately or use dynamic memory allocation.
160 The size of the monitor DCSS will be printed into syslog after loading the
161 module. You can also use the (Class E privileged) CP command Q NSS MAP to
165 negative value for the number of bytes read. In this case, the errno variable
166 indicates the error condition:
168 EIO: reply failed, read data is invalid and the application
169      should discard the data read since the last successful read with 0 size.
170 EFAULT: copy_to_user failed, read data is invalid and the application should
171         discard the data read since the last successful read with 0 size.
172 EAGAIN: occurs on a non-blocking read if there is no data available at the
175 EOVERFLOW: message limit reached, the data read since the last successful
178 In the last case (EOVERFLOW) there may be missing data, in the first two cases
179 (EIO, EFAULT) there will be missing data. It's up to the application if it will
184 Only one user is allowed to open the char device. If it is already in use, the
186 The open function may also fail if an IUCV connection to the *MONITOR service
189 codes are described in the "z/VM Performance" book, Appendix A.
193 As soon as the device is opened, incoming messages will be accepted and they
194 will account for the message limit, i.e. opening the device without reading
195 from it will provoke the "message limit reached" error (EOVERFLOW error code)