I've written an Assembler and COBOL ADATA to Java or XML utility, but it isn't very useful without lots of manual work on SMF data for the reasons I mentioned above: the DSECT doesn't have complete type or any structure information.
Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jan 3, 2014 at 3:52 PM, Charles Mills <[email protected]> wrote: > Yeah, and world peace, too. <g> > > On a more serious note, you can get from any of the IBM DSECTs to C/C++ > headeers by using the IBM C Compiler-included CDSECT utility. > > I just Googled <convert C struct to perl> and got a number of hits, so I > would guess IBM DSECT to any of the languages you mention is do-able, if > not > pretty. > > You might object that IBM C is a separately charged product, but it uses > the > ADATA output of the assembler, which is documented. I don't think it would > be real hard to write a DSECT to any arbitrary data schema program, > especially if it were for your own use and you could tolerate a 90% job. > > Hey, there's a product for you: a DSECT to XML schema converter. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Kirk Wolf > Sent: Friday, January 03, 2014 12:11 PM > To: [email protected] > Subject: Re: SMF (was: REXX tutorial) > > (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). > > ---------------------------------------------------------------------- > 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
