What’s In A Name? – Revisited

(Originally posted 2018-02-24.)

I’ve used a title like this before.

It was in 2011 in What’s In A Name?¹. 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…

PR04.XYZ892.XYZ893.D171130.T1700

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 XYZ892?

That gets us to

PR04.~step name~.XYZ893.D171130.T1700

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 PXYZ8924.

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. ² 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 XYZ893.

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.

For example

SYS17335.T061340.RA000.PXYZ8924.R0492069

from this same job (PXYZ8924).

This did appear in a fair number of permanent data sets, too. For some customers.

Step Name

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.

Creation Date

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 SMOP³. 🙂

In the example the low level qualifier (T1700) might be alluding to a time – 5PM? I haven’t coded for this.

Conclusion

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 what⁴ . 🙂