Ed: One possibility: an XML document with a grammar that included elements for each data type used by SMF records, including dates, timestamps, triplet defined structures, etc. You could then have utilities or XSL style sheets that generated language specific bindings. Anyone could write a new binding (record) generator for their favorite language.
Another possibility: add comment meta-tags hints to the existing SMF DSECTs so that an ADATA processor could get the real type and structure information. Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jan 3, 2014 at 4:21 PM, Ed Gould <[email protected]> wrote: > Kirk: > > Its a start but how would you inter connect other languages ie assembler > or easytrieve etc... > > Ed > > > On Jan 3, 2014, at 2:11 PM, Kirk Wolf wrote: > > (on SMF "schemas") >> >> I think that it would be useful to consider processing SMF data in other >> languages, like Perl, Python, System/R, C, etc. If you had record >> schemas >> you could generate the language bindings. Although not readily available >> on z/OS, any of these languages/tools could be run on z Linux, which also >> has the advantage moving general processor usage. >> >> Kirk Wolf >> Dovetailed Technologies >> http://dovetail.com >> >> >> On Fri, Jan 3, 2014 at 2:04 PM, Kirk Wolf <[email protected]> wrote: >> >> 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 <[email protected]> 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:[email protected]] >>>> On >>>> Behalf Of Mark Zelden >>>> Sent: Friday, January 03, 2014 11:09 AM >>>> To: [email protected] >>>> Subject: Re: SMF (was: REXX tutorial) >>>> >>>> On Fri, 3 Jan 2014 12:35:44 -0600, Paul Gilmartin <[email protected] >>>> > >>>> 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:[email protected] >>>> 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 [email protected] with the message: INFO IBM-MAIN >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to [email protected] with the message: INFO IBM-MAIN >>>> >>>> >>> >>> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
