Peter Hicks' Blog

Last week, CIO Magazine reported on the shortfall in mainframe skills.

It reminded me of a situation I faced a couple of years ago. My team was preparing to write software which integrated with an IBM z/OS system, and we knew literally nothing about it. I didn’t need to know all the details, but I wanted to be able to talk to the system programmers coherently and be taken seriously. I didn’t know much about CICS, nor RACF, and I’d not even heard of RACF. I wanted to learn.

I am a self-starter, and I want to get my hands on the technology I’m going to use in my work life. From learning perl, PHP and SQL in the late 1990s so I could capture ISDN call log data over RADIUS, to buying a bunch of older Cisco equipment to bring me up to speed on VoIP, it’s worked stunningly well. I wanted to do the same with z/OS – not to become an overnight expert, but to be able to bridge the gap between Java developers and the people who ran the mainframe we were going to be using. It would make the whole project happen with much less friction.

After no more than an hour or so’s research, I found IBM wanted $900-or-so a year, on top of buying dedicated PC hardware just so I could run z/OS and spend a bit of time becoming familiar with it. But why? I can download any number of GNU/Linux distributions without charge, or evaluate most Microsoft products for several months without any hassle. Why can’t I do that with z/OS? There were several sites offering TSO and CICS access, but that was only from a user’s perspective. I wanted to peer inside and see what made it tick.

Luckily, the project succeeded and I learnt a fair amount about z/OS in the process, but it wasn’t as quick or easy as if I’d been able to spend some of my own time learning. In fact, when I was given access to a non-production CICS region with the software on the other side of our interface, I spent several hours of after-work time getting to know it, and came away being able to help our developers write an even better product than if I’d stayed in my pure consultancy role.

If IBM want to change the perception that mainframes are an enigma understood only by the balding and bearded stalwarts at large companies, they need to get people hooked. Make the latest release of z/OS and a suitable emulator available for download, and let the world see how great your software is.

I’ve worked at many organisations, from educational establishments up to multinational banks and corporations. My gripe with all of them is they never make the Enterprise IT on-boarding process slick.

Some of the smaller companies I’ve worked for are different. I had to wait a week to get a building pass once because the only badge printer was faulty, and at another company, they’d actually run out of access cards and simply stuck a white sticker over somebody else’s card and told me to use that. Security let me through and in to the building with a quick flash of a piece of plastic with the company’s logo on it and nothing more.

That’s small companies – but in large companies, people join all the time and it really should be a business-as-usual (BAU) process.

Last week, I went to a new a customer site last week to collect a building access card and get set up on their email system.  I was in and out of the building within 30 minutes.  I had an ID card and building access sorted immediately by the security team, which let me go up to the floor I’d be working on and get email access.

My manager gave me a piece of paper with my username and temporary password, and on logging on to the nearest thin client, I had access to everything I needed. Remote access was a breeze – the first email in my Inbox contained instructions on how to get access to my virtual desktop remotely using Citrix and Google Authenticator.

Why can’t everyone’s on-boarding process be like this slick?

In a previous post, I documented the “>steps to install IBM WebSphere MQ on Ubuntu. Now, more generically (and mostly for my own reference), here’s how to set up a queue manager and queues.
You’ll need the WebSphere MQ installation packages – if you’re only evaluating WMQ at the moment, try the WebSphere MQ 90-day trial. Also, you’ll need to read the previous blog post and set your sysctl settings appropriately.
First off, install the MQSeriesRuntime and MQSeriesServer packages – they’re the only ones you’ll need. After installation, run the following command:
/opt/mqm/bin/setmqinst -i -p /opt/mqm
This will set your default MQ installation path.
Next, ‘su’ to ‘mqm’, then create a broker by running the really simple command:
crtmqm MQSVR1
Before doing anything else, you’ll need to start the queue manager:
strmqm MQSVR1
You will also need to start a listener to be able to connect, so use the ‘runmqsc’ command to submit commands to create a listener on TCP port 1414, and also create a server connection channel called ‘SYSTEM.ADMIN.SVRCONN’:
runmqsc MQSVR1
DEFINE LISTENER(MQSVR1.LISTENER) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)
START LISTENER (MQSVR1.LISTENER)
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
^D
The statement ‘CONTROL(QMGR)’ is important here – this will start and stop the listener with the queue manager. If you don’t include this, you’ll need to start the listener every time you bring up the queue manager.
At this point, you have the barest of bare WebSphere MQ server setups. I’ll cover authentication for WMQ 7.5 and higher in another blog post.