Keeping it light today (it’s likely I’m going to get in trouble for my tongue in cheek humor) but it was a fantastic opportunity to create a lesson for someone and an article for MM.

Today I received an email from a user.

Paul,

TDSz is not working, keep getting this error.

faux_error

 -User

A pet peeve of mine, but common knowledge at our shop is that our default HLQ (high level qualifier) for all of our datasets is our USERID.

For example if my USERID was PAULY123, then the HLQ would default to this in several places in ISPF and TSO, unless I indicate otherwise with single quotes(‘) around the dataset.

e.g.

THISDATA.SET456 -> PAULY123.THISDATA.SET456

‘THISDATA.SET456’ -> THISDATA.SET456

 

Documentation from several ISV products, and IBM as well indicate this is the default.

 

From IBM’s “DFSMShsm Managing Your Own Data” manual:

———————————————

Specifying Data Set Names

When you specify a data set name with a DFSMShsm user command, the data set name must conform to TSO data set naming conventions. The qualified name consists of the following fields:

  • Your user prefix (required); defaults to user ID can be redefined by using the TSO PROFILE command
  • A user-supplied name (required)
  • A descriptive qualifier (optional)

The following example shows all three fields:

                USER.PART.DATA

———————————————

Therefore often when installing new products, receiving files, etc. you have to be conscious of this fact.

In addition to our USERID being the default for out HLQ, our Storage Administrators have define datasets that begin with our USERID, magically using SMS with their LOTR Elf magic storage ways, as temporary storage class. Meaning at the end of the day they’re often deleted (unless specified otherwise).

As a workaround for running Tivoli Decision Support z/OS with a local profile dataset that by default uses the USERID as the HLQ, I created a small REXX EXEC to copy when needed as described here in my post to developerWorks.

I’ve received some great solutions commented on this post, which I haven’t implemented yet because we’re still testing.

Hence, why this user sent me the email with that error.

Their PROFILE dataset, which was their USERID as the HLQ, was being deleted EVERY day and they were confused as to why they kept getting this message.

This portion of the message:

**************************************************
Initial startup for the day…
...
..
.
Creating temporary profile…
...
..
.
COPYING “Some.DATASET.PROF” to USER.PROF
**************************************************

That “error message” using a simple REXX EXEC was my contribution.  However it was obviously not a clear message to users what was happening.

TDSz was trying to ALLOCATE USER.PROF which was not there…and my REXX EXEC was copying over “SOME.DATASET.PROF” to fix the problem.

HOWEVER as soon as someone saw that MISSING DATASET error at the beginning of the screen they would stop reading the rest of the information that followed and I’d receive an email or phone call.

I could have… maybe should have… just accepted the fact  I would have to explain what the issue was each and every time, as that WOULD BE the mature and professional thing to do.

Although on this Friday I thought I would have some fun with them!

———————————————

Dear User,

Whoa!

That’s pretty serious!!!!

Looks like the BLT might be corrupted and went AWOL.

Here’s how to fix it….

Go in and DELETE….yes DELETE any datasets that have your USERID.DRL*

That [USERID].DSQPRINTcan cause issues as well, so better delete that one as well.

And try again…

-Paul

———————————————

This would make sure that copied PROF dataset was deleted and they would receive the error again.

Before I sent this email I changed the REXX exec:

My REXX EXEC example is available here.

Now they will be greeted with this message next time they start TDSz:

smiley_msgr

Now they’ll STOP, READ, and REALIZE…everything is working.

Thank you asciiworld.com for making my Friday!

</AS YOU WERE>

Less than 24 hours ago (as I write this), IBM announced an agreement to sell its entire X86-based server business to Lenovo pending regulatory approvals. IBM will receive $2 billion in cash and $0.3 billion in Lenovo stock in the deal.

The deal, first rumored about 9 months ago, makes a great deal of sense for both companies and for customers as well. IBM has recently poured a great deal of investment into its X86 server line, including especially its PureFlex products, to create truly innovative X86 products. So IBM is divesting a technically superior set of products, much like the 2005 sale of IBM’s PC division (and its famous ThinkPad line) to Lenovo.

Lenovo, in turn, has been an excellent steward of IBM’s former PC division including the ThinkPads. Lenovo has steadily gained marketshare despite a tough competitive environment, and I expect that Lenovo will also be an excellent steward of IBM’s X86 servers going forward. Based on that track record it’s a great time to buy IBM X86 servers if you’re in the market. Lenovo is buying IBM’s X86 server unit to grow it, and that only happens if customers come first.

OK, so what does this news mean for zEnterprise mainframes? On the surface, not so much. That said, this news only reinforces long running market trends that have consistently favored the major part of IBM’s server strategy. Fundamentally IBM has a high value enterprise server strategy, one that focuses on intensely workload-optimized and service quality-optimized offerings with the most advanced technologies and capabilities. IBM is the only significant remaining high value enterprise server vendor, which is really quite astonishing. Sun, HP, and several other server vendors before them are, for all intents and purposes, defunct.

One might (briefly) question whether there’s a ongoing market for high-end servers. So far, and for the foreseeable future, the answer is an emphatic “Yes.” IBM is extremely happy with its zEnterprise business performance, and it should be. There are also strong industry trends that continue to favor high service quality, highly differentiated, workload-optimized computing, notably Big Data, analytics (particularly real-time and near real-time), secure clouds, mobile everywhere, and cognitive computing. The limitations of physics in microelectronics also will tend to favor IBM, its leading R&D, and its business models. More simply, there will be a market for the best, and if you’re the only one offering the best, that ought to be a very good business.

It’s important, though, that IBM not get complacent and that IBM always anticipate customer needs. This X86 server unit sale to Lenovo is at least somewhat positive in that respect, I would argue. It means IBM will, if anything, increase its focus on its core competencies, from its leading microprocessors (not someone else’s) all the way up through the complete business solution and the quality of that solution. Which reminds me of another successful technology company that has taken a similar approach in a completely different market segment: Apple.

By the way, I’m happy to be joining the Millennial Mainframer blogging team to share my thoughts and analysis, and to learn more about what you’re thinking and experiencing in the world of mainframe computing. After a brief hiatus and many years editing The Mainframe Blog, I like my new home here where it’s much easier to exchange ideas. If something’s on your mind, be sure to speak up.

Posted in IBM.

Check out the 1Q2014 edition of the zEnterprise Newsletter.

Content includes:

  • Clothespins and Keys: Now what could they have in common? by Maura Schoonmaker and John Dayka
  • IBM Content Manager OnDemand by Rick Gawronski
  • Linux on System z Management with CSL-WAVE by Frank Heimes
  • A New Wave of Information Protection by Mark Simmonds
  • 2014 Education by Kurt Acker

zEnterprise Newsletter 1Q2014