SSI Function code 16 and 17 are part of the set of functions that one can use
to create a full function "I/O" subsystem; specifically providing the 'open'
and 'close' capabilities for said I/O Subsystem (along with several others).
This type of function is usually externalized using the SUBSYS=
Pierre;
ENF's (in general, for the most part and, Logger-based ones specifically) are
single (current) MVS system based.
ENF exits (in general) are targets FOR notification of events from various
system components; in the Logger case there are "global" Logger status change
notifications and
Simple response .….. check out the 'Writing an ENF event 48 listen exit'
section in the 'z/OS MVS Programming: Authorized Assembler Services Guide'
(see: Using system logger services / Setting up the system logger configuration)
Also ….. the description of the fields in the IXGENF macro in
Lizette;
There's nothing "magical" or special about an SMF dump (output) dataset such
that you have to go to such extreme lengths to create one; its just a simple
physical sequential dataset with a 32K record length and either V or VBS record
format -- you can just create it using an IEFBR14
Martin;
To follow up on the previous response to your query I would point out a couple
of general things...
- The SMF 90, "Subtype" 9 is really the initialization (during system IPL) of
SMF (as opposed to the Restart of SMF - "Subtype" 15) and contains information
about the SMF parms in
The noted fields are ONLY on the records being produced for/by "SMF" itself
(IPL event, SET SMF=xx command, SETSMF xxx command).
> What is the difference between the two "subsystem" fields? (SMF90WKN,
> SMF90ASN)
There is no real difference ... each one contains the "name" of a 'SUBSYS'
One thing to consider is the number, type and complexity of the control cards
being used in the dump utility request itself;
if you are using a "lot" of output targets you might consider using a "SORT"
type program instead of the IFASMFDP utility itself for the dump process (you
still need it
>>Set MANx CISIZE to half track (26624).
> Interesting. Why half track? Is it documented that it will help? Just curious
> if you don't mind, please.
Short answer ... 26K (or even 16K) of data written per I/O is much better
than the default of 4K (CI Size).
It really speeds up the writes
I have a problem with AXRCMD returning not all the lines of a JES2 display
command.
Hello;
I am not an expert on just about all the topics in your reference (nor do I
play one on TV)
BUT .
Did you notice that the SDSF output display includes MULTIPLE outputs /
objects ???
ie... the
Fred,
In addition to the doc link reference to the RRS manual that was already
provided; please note that the specific logstream that you referenced (the RRS
'RM.METAdata' logstream) is OPTIONAL and is ONLY used by RRS at the direction
of an external RM (Resource Manager) and really only needs
Skip,
Sorry for the delayed response (I am using the Summary 'Digest' notification
here); a couple of general questions about your original note on this thread
.. your note refers to using an 'exit' are you actually referring to an SMF
IEFACTRT Step/Job Termination exit that gets control
Jose,
The LOGGER provided SUBSYS DD interface (using IFASEXIT for SMF records)
gives you direct access to the data in the logstream and is essentially a
'well-behaved logger' aplication that is doing the IXGCONN and IXGBRWSE (and
dealing with the multiplicity of error codes) for you and giving
Jose (and others dealing with this specific question);
Quick update ... please use the 'Obtaining SMF data from Logstream' section
in the SMF at the z/OS 2.1 level
(it was drastically re-written and much improved at that level)
Bill
Jose,
Please check out the section Obtaining records from SMF log streams in the
'SMF' manual to see how to do exactly what you are trying to do; specifically
the part related to the 'IFASEXIT' interface provided by the LOGGER SUBSYS
(which will de-block the records and present them to the
IEFU84 is an exit point provided by the operating system (yes - which gets
invoked prior to the writing of MANY, but NOT ALL, SMF records) but the
performance question is really a question of what the version of IEFU84 on this
system is doing when it gets invoked. The actrual code being
General note . Close Pending status for an SMF dataset is actually fairly
normal but should NOT persist for very long. It basically means that SMF is
still writing data out to that physical dataset but has logically reached the
end of the file and is collecting/targetting its current input
16 matches
Mail list logo
