Even better if the SMF records were uniformly described by some metadata format (schema) that described the fields in the record. Consider the IBM SMF record DSECTS - one has to look at the field comments to determine not only structure (e.g. triplets) but also whether some C fields are really character or numeric, dates, times, etc, etc.
Much better would be if IBM published some sort of metadata / schema, perhaps in XML, that had all of the information in the DSECT, but also included structure, data types, etc. Utilities could be used to convert these into record / DSECTS in assembler or HLLs. It wouldn't have to be XML so long as there were a defined grammer, standard data types, etc. If done properly so as to include comments for each field, this would also cover 90% of the necessary "documentation" requirements. Currently, the closest thing to SMF schemas are in MXG (SAS). Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jan 3, 2014 at 1:35 PM, Charles Mills <charl...@mcn.org> wrote: > Currently it's kind of the worst of both worlds. Some SMF records formats > are in the SMF manual. Some are in one product-specific manual or another, > with no consistency from product to product. There is a cross-reference in > the SMF manual, but it sometimes lags reality. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Zelden > Sent: Friday, January 03, 2014 11:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF (was: REXX tutorial) > > On Fri, 3 Jan 2014 12:35:44 -0600, Paul Gilmartin <paulgboul...@aim.com> > wrote: > > >On Fri, 3 Jan 2014 12:10:15 -0600, Ed Gould wrote: > >> > >>Interesting thing about SMF... > >>For 20 years IBM documented SMF records in one consolidated place the > >>SMF manual. > >>In the last 5 or so years IBM did an about face and started to scatter > >>them around in unlikely places WHY?????????????????? > >> > >My guess would be that the specification of the formats of SMF records > >is owned not by SMF, but by the various utilities that generate them. > >As such, it would be onerous, untimely, perhaps even error-prone for > >each utility that adds a new SMF record type to require an update of a > >central SMF data areas manual section. > > > > Oh, you mean someone would have to do some work. :-) > > Seriously... I don't like the trend (although it isn't widespread). As > long there is > internal communication within IBM and everyone played by the same rules, > the information could be kept consolidated in a single manual or kept in > sync > with the component / subsystem manuals. Same goes for operator commands > (catalog / DFSMS manuals comes to mind). There is an overall owner of > z/OS, > so I suppose it would be up to them to dictate direction of keeping all > the information in a single manual (or not) or keeping the information > current in multiple manuals (although it would come at a cost as nothing is > free and these decisions > are made with the financial aspects in mind). > > One thing's for sure - complaining on IBM-MAIN won't do anything. > > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > ITIL v3 Foundation Certified > mailto:m...@mzelden.com > Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://search390.techtarget.com/ateExperts/ > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
