Message in a Bottle

Message in a Bottle

z/OS 1.13 comes with 10 message manuals. That's right, we're in double digits now, plus system codes. And there are 11 more in base elements that have their own manuals (JES2, TSO, USS etc).  I have to wonder, is that really necessary? Can we feed these manuals into a computer like Watson on Jeopardy and have it tell us what percentage of messages in the IBM Messages manuals say 'Contact your system programmer'?  This is information that I would find highly interesting. By my count, Volume 8 has about 250. In fairness, it seems like IBM is now putting in an Application Programmer's response, and a System Programmer's response, which is nice! 

According to a QuickRef presentation at SHARE in Anaheim, There are now 4,428,037 items in the QW database, and the message with the most lines of text is IEC161I – 10804 lines. IDC3009i is close behind at 10802 lines.

I wonder how many employees IBM has on the MVS Messages Manuals team?

Here's a line from the 'Who should use this document' paragraph in the messages manual:

The system messages documents are for people who receive messages from the system.

Wow. Thanks for clearing that up. I'm sorry, I shouldn't be busting on IBM so much. But it's so easy! I guess I really shouldn't be complaining about the volume of messages and lines of text while simultaneously teasing IBM about the content of messages.

The very last MVS message is IZP057i: IZP057I IOCP JOB jobname SUCCESSFUL. LEVEL xxx IOCDS REPLACED.

Which begs the question...why are there no messages past IZP057i?

By way of making everyone else feel as old as I do...The Police song 'Message in a Bottle' is from....1979.

Instead of a link today, you get a mainframe joke:

Q) What's a S0C4?
A) For keeping your toes warm

Till next time,



1 Comment

Messages are a differentiator

September 26, 2012 10:27 AM by Edward Jaffe

Great messages and accompanying documentation help to differentiate our platform from others in areas such as post-mortem analysis, automation, and simply understanding what our systems are doing. When something goes wrong on another platform, you often find yourself staring down some English-text message with no message number and no clearly defined way to diagnose the problem.The top two methods I've employed in those situations are 1) Internet Search and 2) Trial and Error. Such times cause me to reflect and really appreciate the amount of time and effort that software vendors have spent over the years to ensure that messages on our platform are the best in the industry.

Recent Stories
What Would You Do?

Happy 60th Birthday SHARE!

SHARE in Seattle Sights