Re: IBM SSI Function Codes 16 and 17
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= keyword option on the DD statement in JCL (and associated SVC 99 TU keys). Not sure what you expecting; but these function are NOT 'exit' points in open/close processing nor are they any kind of 'notification' function (like the console command interface SSI #10). Have you checked out: "MVS Using the Subsystem Interface"?? (the z/OS 1.13 level of the manual is: SA22-7642-12) Bill. IBM z/OS System Software Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Log streams, ENF 48
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 (any) Logstream status changes. The action taken by the exit when invoked is totally up to the exit coder. General thoughts ……….. first off check if the LOGGER event is for address space unavailable and act accordingly; then check for Logstream name that is provided on the parmlist passed to the exit when invoked (probably IGNORE any non-interesting name). Yes, your logstream code (in general) has to have a design on how to deal with BOTH a 'global' event and a logstream-specific event. Finally; yes, there are NOT a lot of Logger-issued ENF's on a "normal" running system - the events are mostly exceptions. -Regards, Bill …. IBM z/OS System Software Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Log streams, ENF 48
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 SYS1.MACLIB is quite useful. Basically - the ENF 48 is most useful for owners of logstreams so that they can be notified of logger/logstream functions and updates. -Regards, Bill z/OS System Software Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to setup a new SMF Dump dataset
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 job with a DD that specifies the proper characteristics. Quick follow-on .. if you are going to be running a "future" job to 'MOD' data onto the end of this dataset you COULD even SKIP the above create step and just let the "MOD" operation create the dataet for you (that is, DISP=MOD ... means add to the end of the existing dataset -or- create a NEW one and put the data there). Be really careful with the DISP=MOD that you don't end up with a partial record at the "end" of the dataset and then when additional data is added to the dataset that partial record causes the follow-on data becomes in-accessible resulting in future attempts to read the dataset to fail. There are 'manual' steps and I think there are tool available that can be used to correct the issue in the event that this happens. One other thing .. be really careful about doing the "IFASMFDP with output TYPEs" because IFASMFDP will NOT generate an "empty" / null dataset but rather one that has at a minimum the 'first' and 'last' records (which are "throw-aways) BUT if you specify any other record types (like you noted in your original message) then you could end up with DUPLICATE records Bill . IBM z/OS System Software Development and Service (past "SMF" Component owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 90 question
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 use for the session. - As previously noted, some of these Type 90's contain information about the responses specified during the processing of the SMF parmlib option (IPL "reason", etc) but these prompts are controlled by the (NO)PROMPT option specification and can be (are probably I suspect but can not confirm) avoided. Side note: The SMFPRMxx "PROMPT" option setting also controls the availability of the SETSMF console command. - In addition to the SMF 90-9 record for "IPL" of SMF there's also the Type '0' IPL record which has some different parms. In general .. these record are generated BY the SMF address space itself during initialization and there are others (as you pointed out) that are generated by other address spaces and probably lots of others that could be "used" to signal the event -- based on the data being collected in general. Just some general thoughts for you. Bill IBM z/OS System Software Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF 90 question
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' in the SMFPRMxx Parmlib Member. The "difference" is that each field is used as the header for a subsection of the record. The SMF90WKN field reports on the TYPE options that are coded for the "SUBSYS" The SMF90ASN field in ONLY going to be present for SUBSYS in the SMFPRMxx parmlib member that includes a SUBPARM option specified (which is fairly rare). > - What SET or SET command takes a subsystem parameter or an > accounting parameter (that would then be recorded in AMF90ASN and SMF90APM)? See the list at the top of this note. Bill .. z/OS System Software Development and Service (former SMF Component Owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to speed up IFASMFDP SMF Dump process
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 for the CLEAR). "SORT" programs (in general) are much more efficient in doing this type of I/O processing; potentially multi-task or multi-threading the work. Of course the down side of this is having to translate the SMF defined control card "terms" into offsets (ie. 'Type' is at offset "x" and is of length "1") and taking into account the RDW; the good thing would be this conversion is probably already in use in other jobs that are sorting SMF data. NOTE: This is just MY personal observation based on my knowledge of the processing and NOT a formal recommendation by the current SMF team or anything official. Thanks, Bill.. z/OS System Software Development (former SMF Component Owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to speed up IFASMFDP SMF Dump process
>>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 to the MANx dataset done by the SMF "writer". (HALF Track is the best in terms of "head movement" in spinning DASD) and Yes the down side is that the SMF writer does NOT include proper post record "spanning" (or packing). Bill . IBM z/OS System Software Development (and former SMF Component owner at the time the above was done) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System REXX AXRCMD not returning all the output of a display command
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 FIRST few lines are flagged with: PROCLIB(PROC00) while the last / missing part with: PROCLIB(PROC01) (also note that the last entry you get / that is before PROC01 does NOT end with a ',' I am not sure how this is handled in the REXX process that you are using; nor how the message(s) are handled by JES (you might want to check the control info on the harcopy log for these lines). Thanks, Bill . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOGSTREAM data set RM.METADATA
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 to be defined IF you are running an RM that uses it (their set up / installation materials should! point this out explicitly). If you are just starting out then the other OPTIONAL logstream is the 'Archive' one - which is intended for use the by the installation itself to track completed transactions. IF you decide NOT to create either one of these OPTIONAL logstreams - please be aware that when you start RRS you will get a message indicating there is an OPTIONAL logstream was NOT found (that is expected in this case but we just need to make sure of that). Good Luck, Bill IBM z/OS RRS Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXCP Counts in SMF Exit
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 during step and job term to format the data in question or just an SMF Type 30 analysis program ??? In either case your exit needs to be able to handle (as noted previously) Chained SMF type 30 records and especially if you are interested in detailed EXCP data (each entry represents the counts and dev connect time for A DEVICE associated with each DD used in the reporting period) AND since there can be LOTS of them (more than can fit on a 32K byte record) this data can span multiple physical records. This is where the triplet (or in some cases the quadlet??) comes in as you reported on your original note. Specificity, SMF30EON is he number of EXCP sections on the CURRENT record and SMF30EOS (the additional/new 4 byte field) reports the number of EXCP sections on subsequent records. To see and process ALL the EXCP entries you MUST take into account BOTH numbers; and note that the first SMF Type 30 record might actually have '0' EXCP entries (SMF30EON) BUT there is EXCP data on the 'subsequent' records for the job/sytep (NON-ZERO SMF30EOS). Background: SMF 30 Record Structure: - Standard Header - Triplets Section (watch for Quads) - ID Section - FIXED Section-S (ie. Performance, etc) - Variable/Repeating Sections(s) . including EXCP (but there are others!) The 'first' SMF 30 record has all the section (but maybe not ALL variable) and the subsequent ONLY has 'Header', Triplets, ID section and needed variable sections. You have to IGNORE fixed (data) sections on 'chained' records because they don't exist (their 'number' triplet field is '0'). There are a number of possible reasons (specifics are not really important) that an SMF Type 30 first record has NO EXCP sections but does have EXCP entries on subsequent (ie. Chained records). Hope that helps clarify things a bit . as noted by other there are a multitude of ways to view/process this data post-real time to check this out. There are many SMF 30 processing functions/exits that do not totally handle this and can get weird results if not properly prepare when this event (ie. multiple 30's for an event) occurs!!! Bill IBM z/OS System Software development (Former SMF Component Owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXGBRWSE - SMF Logstream
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 you 'record' level access to the data via basic (old fashioned) QSAM or BSAM OPEN/GET/CLOSE level interfaces. IF you want to get close-to-real time access to the data in the logstream then you are correct that you have to build an application from the ground up using LOGGER IXG* services - the only SMF specific thing in the application is the data itself (and the format of the blocks). Which is back to your original point about the mapping of these BLOCKS. More to your actual point (I think) ... IF you want REAL time access to the data being written to SMF (DASD or LOGSTREAM) you have to use the SMF provided SMF interface exits (IEFU83/4/5) to capture and process the data AS IT is passed to SMF to be written. That answer hasn't changed since SMF was originally shipped (but it was made a whole lot simpler with the implementation of 'Dynamic Exits' back in 1992). Bill (former SMF Component owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXGBRWSE - SMF Logstream
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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IXGBRWSE - SMF Logstream
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 application using standard QSAM/BSAM methods). NOTE: The section of the documentation referenced above is written and based on EREP's use of LOGGER but has the SMF details included. The logger 'block' that you are trying to deal with is just like a 'block' on a regular DASD dataset (can be thought of as). Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Longer SMFWAIT during IPL MSI
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 invoked could come from a variety of sources (IBM, in-house, vendor). The other thing to note is that for many year now the SMF exits are actually being managed by the CSV Dynamic Exist function so you also need to check the PROGxx parmlib member(s) on the system and look for EXITNAMEs values that include the string 'IEFU84'. By default the IEFU84 module is located in LPA storage (so if you are NOT using dynamic exits it should be fairly easy to locate in a dump and check the eyecatcher which would lead you to the next step in the investigation. NOTE: In general the SMF record exit points (IEFu83/4/5) are really intended to just be a quick peak and out thing but there are some pretty complicated exit modules out there!!! Good Luck; Bill (Former SMF Component Owner) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Dataset CLOSE PENDING ISSUE
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 data to the 'next' dataset (which in this case there is none - which I suspect might have been the source of the issue). Second note .. you really should have procedures in place on the system to dump and CLEAR SMF datasets as soon they become FULL - you should never really have SMF datasets that are in dump required state. That's system data that has been collected and is just sitting there not being used for its intended purpose. IF for some reason there is no actual need for the data then just make sure to CLEAR the datasets as they become FULL. Third general thing . Close Pending is USUALLY an indication of a thru-put performance iusse with SMF - that is, the data is being collected as a FASTER rate than it is being physically written out to the SMF dataset. In most cases there might be a data spike that causes this sort of behavior instead of a sustained data rate issue; the other possiblity to consider is an I/O (performance) issue with the physical SMF dataset itself. Finally, as has already been noted if the problems persists then contact IBM Service. Thanks, Bill z/OS Development and Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
