Kirk:
OK but IBM would have to maintain it. It wouldn't be easy and
everyone would have to follow the rules. Good luck on getting IBM to
do it. They can't maintain a central depository for SMF records, let
alone describing them correctly.
\The people at SAS or MXG would probably be the logical ones, IMO.
Ed
On Jan 3, 2014, at 5:15 PM, Kirk Wolf wrote:
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:IBM-
[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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
