(Originally posted 2018-02-24.)
I’ve used a title like this before.
It was in 2011 in What’s In A Name?1. But this post bears only a slightly resemblance to that one.
This post is about gleaning information from names, specifically data set names.
Consider this one…
So what are we to make of this data set name?
It’s a real data set name, by the way, with only one obvious substitution.
What if I tell you the step name is
That gets us to
where I’m using the convention
~...~ to denote something that’s been decoded.
What if I tell you this data set appears in a job that is part of a stream that kicked off on 30 November, 2017?
Then, and you probably guessed this,
D171130 probably refers to a specific iteration of the job, namely the one that started on 30 November, 2017.
That gets us to
PR04.~step name~.XYZ893.~run date~.T1700
and the data set name makes a lot of sense.
Now, it turns out that the
XYZ892 step name is also the main DB2 package name, with a launcher program as the actual job step name. This is encoded in the job name
From SMF 30 I know that this job is one of a set of clones, being from Stream 4.
So you might fairly conclude the
4 is significant.
So we could now decode the job as
PR~stream number~.~step name~.XYZ893.~run date~.T1700
Now, using the Life Of A Data Set (LOADS) technique we can glean a little more. 2 I last mentioned LOADS in A Record Of Sorts.
You might’ve guessed that there would be a job called
PXYZ8934 – and indeed there is. LOADS tells us that our job (
PXYZ8924) creates and writes the data set (SMF 15 record) and
PXYZ8934 reads it (SMF 14 record). Unsurprisingly it reads it in a step called
So we reasonably decode the data set further:
PR~stream number~.~step name~.~other job step name~.~run date~.T1700
This pattern is quite common in this batch application – where the data set name contains the writing program’s name and the reading program’s name. And the job names reflect their main program.
I think this takes us a long way further than just seeing the data set name raw.
So what does our code do?
What It Used To Do
It used to just recognise a job name in a data set name. This was most likely to occur in a temporary data set name.
from this same job (
This did appear in a fair number of permanent data sets, too. For some customers.
Now, this is new. If the code sees a step name in one of its data sets it bolds it.
What it can’t see is a different step from a different job.
If the creation date is like ‘D171130’ and it’s a data set qualifier it’s bolded.
If might be possible to detect other forms of date. For example,
DG113017 is a qualifier. But I don’t think it’s reasonable to hunt for arbitrary date formats with arbitrary prefixes. Of course, it’s just a SMOP3. 🙂
In the example the low level qualifier (
T1700) might be alluding to a time – 5PM? I haven’t coded for this.
As this example shows, there’s value in decoding data set names. Having code do it, spotting patterns for you, is the smarter way. And, in our case, bolding the detected pieces brings the reporting to life.
There are most certainly further insights that can be gained, such as when the SMFID is part of the name, or the previously-mentioned program name. Perhaps by the time you read this I’ll’ve added them.
This machine is learning. 🙂 But, as with ML, nobody’s quite sure what4 . 🙂
Queen fans will note “In The Lap Of The Gods” and “In The Lap Of The Gods – Revisited” are two completely different songs, though on the same side of the Sheer Heart Attack album. ↩
Using SMF 14 and 15 for non-VSAM Read and Write OPENs, respectively. ↩
“Simple” Matter Of Programming ↩
In an early, classic, AI experiment the machine was taught to spot when trees concealed tanks. In fact it had learnt to detect sunny days versus cloudy ones instead. Citation, anyone? ↩
2 thoughts on “What’s In A Name? – Revisited”