About Paul Gamble

After doing a four month internship with the Canadian Government, Paul was offered the rare opportunity to work in their on-site Data Centre. Starting out as an Operator for four years before becoming a Systems Programmer rolling out different independent software vendors (ISVs) and different IBM Tivoli products for monitoring and automation to the z/OS platform. Paul enjoys the constant learning the z/OS operating system offers in comparison to other platforms. On weekends you’ll find Paul getting his adrenalin fix by instructing and coaching at the local skydiving drop-zone.

Updating Woes

As far as pet peeves go, mine is entering the same commands over and over.

Especially when every few months I’m FTP’ing maintenance for ISV (Independent Software Vendors).

Some companies have pretty slick procedures. COMPUWARE comes to mind as they have a pretty good web based front-end that uploads all the necessary installation DATASETS; allows you to indicate HLQ; the VOLUME SERIAL; etc.

In contrast other companies leave it to the System Programmers to do this on their own.  Sometimes offering a neat JCL job to directly FTP from the company’s FTP site (that’s against security policies at my shop); or simply giving a simple math exercise to remedy the PREALLOCATION.

e.g. VANGUARD probably has the BEST technical support IMO, however quite a bit of their maintenance procedures includes this gem:

Note: The number of cylinders of 3390 DASD required for the FTP can be calculated by dividing the extracted (unzipped)
file size in KB by 675.

For example, if the unzipped file is 174,315KB;
174315/675=258.2, allocate 258 cyls.

Yes, a little math doesn’t kill anyone…but what a pain in the arse!

We had an incident recently where someone did not specify the correct CYLINDERS and we had corruption and confusion before the problem was detected.

.BAT Windows Scripts

Therefore I started making simple batch (.BAT) scripts, since yes we still use Windows XP as our workstations, to automate several FTP commands.

Programming up bat scripts is pretty straightforward, and there’s still plenty of tutorials kicking around.

(Yes, I know PowerShell would have been ideal…maybe in the future.)

vanguard bat script syncsort bat script

The code for both these examples are available HERE.

Until companies provide slick and painless front-ends for their updates I suspect more shops will continue using Productive scripts such as these.




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.


TDSz is not working, keep getting this error.



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.





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:



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…

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,


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…



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:


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

Thank you asciiworld.com for making my Friday!