Working title

Boss talk

2011-12-16T10:38:00.000-05:00

What he says: "How is it going?"
What he means: "Why aren't you finished yet?"

What he says: "This is a challenging task."
What he means: "I don't know how to do it either."

Artifacts

2011-06-29T18:47:00.001-04:00

I have to fight to suppress a smile whenever I hear people talk about the "artifacts" that have to be produced as part of any modern systems development methodology. As far as I can tell, the term "artifact" has replaced the more descriptive "deliverable", but that's not what I find amusing.

To me the word "artifact" has always meant something like: "An man-made object of historical or scientific value that has no practical use." Or, in another sense, "data corruption produced by an error in the process that measures the data". To those of us in the trenches who are required to create "artifacts" in addition to executable code, both of these definitions seem apt.

Ergonomic impact of full screen debugging tools

2011-06-29T18:38:00.001-04:00

Speaking of RDz, as I was in my last post, full screen debugging tools can have an unexpected ergonomic impact, at least on my decrepit old frame.

When writing code, launching and monitoring batch jobs, or testing an online screen the old fashioned way, I tend to sit back in my chair in a fairly relaxed posture. Debugging interactively, whether using RDz or another tool, tends to change that. I lean forward in my chair intently focused on the screen in front of me as I watch the code execute. I feel poised, ready to pounce when the next breakpoint comes up or when the execution flow appears to go awry.

All this is good fun (I love debugging), but it gets physically wearisome when you do it continuously for 8 hours or so.

Cruelty to Mainframers

2011-06-29T18:21:00.002-04:00

Was IBM deliberately cruel to us old mainframers when they designed RDz? Why else would they assign F8 to "Run until next breakpoint"? I cannot tell you how many RDz debugging sessions I've ruined by hitting F8 in the source window when all I meant to do was scroll down.

Social media inside the company firewall

2011-05-30T17:32:00.000-04:00

After the first kneejerk reaction to ban social media sites from the workplace, companies are now beginning to explore ways to exploit them. In some quarters social media are touted as a way to spur productivity by encouraging employees to share ideas.

I have a few concerns about this trend.

1. It is based on the perhaps dubious assumption that 1000 average people are wiser than one wise man.
2. In any group collaboration only a few voices will be heard. Ask anyone who's been on a committee and they will tell you that a vocal minority tends to dominate.
3. The Man is watching. Will people be willing to put forward unconventional ideas knowing that the Boss is watching? No one wants to look stupid, so the less confident individuals will hold their peace.

It will be interesting to see how it plays out.

2011-04-02T17:27:00.000-04:00

I live in Canada, and I have a question for my fellow Canadians. With people all over the world dying in the streets for the right to vote why do less than 60% of us bother to show up at the polls? The numbers are truly dismaying.

Honour their sacrifice by voting on May 2. It's more than a right, it's a duty.

Down with periods!

2011-02-18T17:29:00.001-05:00

I still see recently written Cobol programs where the author uses a period after virtually every Procedure Division statement.

I find this puzzling.

The introduction of END-IF over 20 years ago has made periods unnecessary in the Procedure Division except for the end of a paragraph and paragraph names. When maintaining a period-infested program I like to remove all unnecessary periods in the paragraph I am working on. If I have time, I change the necessary periods to END-IF and NEXT SENTENCE to CONTINUE. If you are careful, there is very little risk in doing this, and you will leave the program a little better than you found it. Make it Right!

Rant: Cobol line numbers

2011-01-20T22:14:00.004-05:00

Why on God's green earth do so many programmers continue to use sequence numbers in their Cobol programs?

Come on guys, when was the last time you even saw a card deck, never mind dropped one?

Ditto for the numbers in columns 73-80. If you have a source management system, you don't need to use these numbers to track changes, the source manager will do it for you. If you don't have a source management system, a source comparison tool (SUPERC works just fine, and it's free with ISPF) will tell you all you need to know.

Modern banking

2011-01-18T20:26:00.002-05:00

I was in the car with my son when he reminded me that he needed some money for school. With a theatrical flourish I whipped out my Blackberry and transferred the funds right on the spot using my bank's app. (Don't worry, he was the one driving).

He was suitably impressed. So am I... when I started my career you had to plan your whole day around getting to the bank before the branch closed. We have indeed come a long way.

Mixed case on MFS screens

2011-01-15T01:27:00.006-05:00

There is no reason why MFS literals cannot be in mixed case. Try it. You will be surprised at how much this small change improves a screen's readability. Your users will see it as a more "modern" look and will sing your praises.

Handling mixed case data is another story, but using mixed case MFS literals is a no-brainer. (You don't have to tell your users that part).

ISPF rants

2011-01-13T18:00:00.022-05:00

Here is a list of a few of the things that bug me about working with ISPF on the mainframe:

People who haven't used a new ISPF feature since 3.4 came out. Come on guys, it's been 20 years!
People who don't use Edit HILITE command. Yes, green is a lovely colour, but it is surprising how much more productive you are when your source code is intelligently colour coded. You'll never forget an END-IF again.
People who are still using 24x80 to do everything. No wonder people think that the mainframe sucks!
Vendor panels that don't support large screen sizes.
People who use Extra!'s default colour scheme. Yecchh!!
Companies that force you to use inferior emulators because that's the one they've always used. There are many excellent and inexpensive emulators out there. Vista 3270 for example.
People who don't know about the Edit COMPARE command and still do their code retrofits manually.
Systems programmers who fail to activate SITECMDS and USERCMDS.
Systems programmers who fail to include new products on the local panels. I hate having to remember startup commands.
Panels with the command line at the bottom.
Dialog Tag Language. A solution in search of a problem.
Local ISPF panels that point to obsolete products and functions.
Non-modifiable KEYLISTs. The "P" in PFK stands for "Programmable", dammit, so let me program my function keys!!
Missing HELP panels. ISPF has a lot of very nice features to help the dialog developer create context-sensitive help dialogs. Why aren't they used more often?
Panels that are all in CAPITALS. Why do so many panels SHOUT at me?
People who don't know how to use the HELP key.
Dialog programmers who don't know how to use the MODEL command.

5 more ways to start a war on a mainframe forum

2011-01-13T17:00:00.006-05:00

Say something positive about Windows.
Declare that the 'frame is dead and squatty boxen rule. Don't forget the "boxen" part.
Opine that RAS is overrated; the future belongs to Wintel because it's cheaper.
Brag about how long you've been in the computer business. Even if you worked on ENIAC someone will claim to have worked with Ada and Babbage.
Mention Hercules.

5 ways to start a war on a mainframe forum

Attack of the turbines

2011-01-08T16:18:00.002-05:00

This is the funniest cartoon I have seen in a while.

This one's good too. (thanks Terry).

Too cool for the room?

2011-01-05T20:15:00.001-05:00

Santa brought me an iPad for christmas. Does that make me one of the 'cool crowd'?

Not according to my eldest son: "Dad, it'll take a lot more than an iPad to do that".

Perhaps so, but I am having a lot of fun playing with my shiny new toy. I've never owned a laptop (though everyone else in the family has one) and until recently my smart phone wasn't very smart because I was too cheap to pay for a data plan. I am a late-comer to the portable computing party.

Down in the Dumps

2010-11-25T18:18:00.002-05:00

I found myself with some spare cycles at work the other day, so I spent some time reading a few dumps created by our online production regions.

Does that make me weird?

There was a time that I found dumps to be both tedious and intimidating, but modern dump formatters have made it much easier to figure out what happened. For example, except in very rare cases, a Cobol programmer reading a dump no longer needs to know the register contents or indeed, what a register is. Nor does the programmer have to know how to determine the instruction in error or how to find the program's BLW and BLL cells. The dump formatter lays it all out for you.

I must hasten to add that interpreting a dump is still a challenging intellectual exercise because you need the ability to understand the application logic and have enough imagination to figure out how your data got into the state it is in. In many cases you also require an intimate understanding of how your application interacts with its execution environment.

Thanks to the dump formatter, it only took me a few hours to diagnose a handful of problems that were responsible for about half of the abends in our application's online regions. Were it not for the formatter, I probably would not have volunteered for the job.

The Project

2010-11-17T23:15:00.001-05:00

My wife and I both work in the IT business, so we sometimes tend to view things through the lens of our profession.

When our first child was born, we referred to him as "the Project". The objective of this multi-year endeavor was to raise a fully functional human being and good citizen who would eventually become a middle class taxpayer. Is that not the duty of every parent?

Less than two years later we were affected by "scope creep" when our second child came along. As Bill Cosby once said, you do not become a real parent until you have more than one child. "Why? Because if you have only one child, and something is broken in your house, you know who did it!"

Additional funding was not forthcoming as a result of this change. We found the money by reducing other expenses such as dining out, exotic vacations, and by eliminating most adult social activities.

Current Status: Green. We anticipate a +15% variance due to unplanned educational expenses.

RUT?

2010-11-12T08:35:00.003-05:00

Like many parents, I used to cluck disapprovingly when I saw the silly short forms and tangled syntax used by my kids as they chatted with their friends. "What a waste of time!" I thought. But I never hassled them about it because I knew there were much worse things that they could have been doing on the Internet. And besides, if they didn't have chat they'd be tying up my phone line or running up their cell phone bills.

I had zero (0) interest in using chat for myself. After all, grown ups communicate in full sentences and we try to get our spelling and grammar correct. (With varying degrees of success, as any reader of this blog can attest).

Email is a much more refined method of communication; it is both fast and thoughtful. I've been using it for many years, even in prehistoric times when the corporate email system ran on an IBM mainframe. I am no Luddite pining for the days of typed memoranda* and carbon paper. I was quite happy when all of that stuff moved into the electronic age.

But chat was for kids. It was easy to avoid; every company I worked for forbade the use of chat anyway.

I recently joined a company that not only allows chat, it encourages you to use it to talk to co-workers. At first I ignored it, figuring that the only reason they allowed chat was to allow the under-30 crowd to coordinate their lunch plans. Or perhaps to save money on phone expenses for its geographically dispersed work force.

What I didn't realize is how productive chat can be when you are closely collaborating with others on a complex task. Chat eliminates a lot of phone calls and greatly reduces the amount of shouting over cubicle walls in the office. And, if you can't remember what somebody said 10 minutes ago, you can look it up.

Call me a convert. (It's okay, I've been called far worse).

* This word is so outdated that my spell checker flags it as an error.

I love bugs

2010-11-11T21:26:00.001-05:00

Like most programmers, every now and then one of my programs works correctly the first time. Most programmers are thrilled when that happens. Personally, I feel a pang of regret.

Hunting for bugs is what I like best about this business. To me, a perfectly working program may be admirable, but it's boring.

The mainframe strikes back

2010-08-25T17:35:00.001-04:00

I attended an interesting IBM presentation today on the topic of zIIPs, zAAPs and IFLs.

These specialty z processors are designed to support "new" workloads that were formerly the domain of Java, Linux, and *ix. After spending the past two decades losing workloads to the other platforms, the mainframe is finally* winning some of it back.

*Actually these processors have been around for the past decade or so, so it's not that recent a development.

Nostalgia: program flow charts

2010-08-19T18:48:00.001-04:00

Junior programmers were once required to produce a flow chart of their program before beginning to code. They were told that it would help them work out their logic so that their coding and testing would go more smoothly.

I think it was a scam.

The real purpose of a Program flow-chart was to slow down the coding process in order to ease the workload of the keypunch department.

Full disclosure: When I started my career there was no keypunch department where I worked. We shared terminals; one for every two people. Yes kiddies, I said terminals not PCs emulating terminals.

Those were not the good old days.

Checkpoint

2010-08-19T17:48:00.001-04:00

You may have noticed that I haven't posted anything since January 2010. There is no deep dark reason for this; just the usual combination of laziness and busy-ness.

Most of the posts prior to this point represent a collection of stuff that I've posted on the Internet over the past several years. A "best of" collection, I suppose.

I've recently started a new job, and that is always a good way to find some inspiration.

In my first IT job, I was well indoctrinated (brainwashed) in the procedures and processes demanded by that company. The procedure and processes were (mostly) reasonable, and what the hell, I didn't know any better anyway.

The problem came on my second career stop. I thought the new shop was idiotic for doing things differently than my old one. It was quite an adjustment, but eventually I realized that there were some interesting ideas there that I have since incorporated into my own work.

Now, many years later, I find myself back at the original company, older, wiser, and with a broader perspective.

5 ways to start a war on a mainframe forum

2010-01-15T10:18:00.003-05:00

Use the acronym "USS" to refer to z/OS Unix features.
Propose the elimination of the 100 byte limit on PARM length in JCL.
Complain about the limitations on the use of System Symbols in JCL.
In a COBOL forum, declare that coding is Paragraphs is better than coding in Sections. Or vice-versa.
Praise Oracle on a DB2 forum.

5 more ways to start a war on a mainframe forum

Uninitialized storage (2)

2009-12-15T17:24:00.004-05:00

It is generally a Very Bad Idea to make any assumptions about the contents of uninitialized storage.

What might work today may fail miserably tomorrow, without warning and without apparent cause.

If you care about it, then initialize it.

Application entropy

2009-12-15T07:35:00.001-05:00

If you wait long enough, people will start treating a bug as a feature. Then you can't fix it because you'll break their application. Sigh. I have seen this type of application entropy many times.

Business programmers

2009-12-14T19:37:00.004-05:00

At the risk of stating the obvious, COBOL programmers work in a business environment, and in that environment people are rewarded more for their business acumen than their facility with nested IF statements. If you can charm the user and convince him that you understand his needs and that you know how to meet them, then it doesn't matter if you go back to your desk and write crappy code. As long as you deliver something that more-or-less works in a more-or-less timely manner, you will be well regarded and rewarded.

Many (perhaps most) programmers in a business environment are not there for the long haul. Programming is merely a phase they have to go through at the entry level.

Business programmers fall into the following groups:

Managers in waiting. To this group, programming is just a step on the career ladder. This is a large group (maybe 25%). This group cares little about the code they develop, other than it meets company standards and is delivered on time.
Business analysts in training. This group cares more about the company's business than about the programs that support it. This is the largest group, and they eventually abandon programming to become full-time business analysts or end users (about 50%). This group regards programming as utter drudgery, and tend to delegate it to junior team members whenever they can..
Clerks in training. This group does what they're told to do, no more no less. A smaller group (about 15%). This group is capable of producing good code, if they're given detailed specifications and good sample code to work from.
Technicians. This group see programming as a profession (or at least a skilled trade) that they can take pride in. A small group (10%), they tend not to care much about the business they are supporting. Even though they work with COBOL and can use it creatively, many of them have bought into the myth that it is a Creaky Obsolescent Boring Old Language and yearn to move on to other technologies.

ISPF productivity

2009-12-14T14:50:00.000-05:00

I love ISPF, I really do. The Editor in particular is a brilliant piece of work, and in my opinion represents the gold standard for text-based editors. ISPF also provides a very rich API so those that are conversant with ISPF dialog progamming can create useful and sometimes very complex applications. Yeah, those applications are text-based, but since most mainframe programming is done in a text-based world that doesn't matter.

I have written many such applications, and truth be told, it's a lot more fun to write ISPF Dialogs than to write Cobol code.

Still, ISPF has its shortcomings. The product uses hierarchical menus that require skill and experience to navigate. To be sure, there are many short cuts, but it takes time to learn them. Also, it does not provide a convenient mechanism for organizing the myriad of data sets, DB2 tables, IMS data bases and TSO commands that the programmer has to cope with every day.

I once wrote an ISPF Dialog application that helped me manage all of that stuff, and I was amazed how much time you could save if you aren't constantly searching for half-remembered data set names. I've used such a tool for many years now, but more recently I've been relying on a commercial product called Simplist, which is way better than anything I've been able to write for myself. It's not free, but it's not expensive either. I highly recommend it.

Don't believe me? This guy likes it too.

Disclaimer: I have written about SimpList on several occasions. I would like to point out that I have no financial interest in SimpList or any other commercial software product. My opinion is that of an experienced mainframe developer and consultant, not a product shill. My product review was originally published in Technical Support, the official journal of the Network and Systems Professionals Association (NaSPA).

Some recent Dilberts

2009-12-14T08:55:00.000-05:00

Like many in the IT business, I am a big fan of Dilbert, not just because it's funny, but because it sometimes hits close to home.

Here are a couple of recent strips that I've enjoyed:

Guesstimating

Skills utilization

ISPF weirdness

2009-12-12T21:27:00.000-05:00

It's not a bad idea to add an explanatory line near the top of each scrollable HELP panel:

"Press LEFT and RIGHT to scroll up and down"

Or, depending on your audience:

"Press LEFT and RIGHT to scroll up and down. No, I am not kidding."

Risk-averse programming

2009-12-03T19:23:00.003-05:00

In my experience, there are a lot of COBOL programmers who don't give a damn about programming either as an art form or as scientific discipline (take your pick). They spend their days attending endless meetings with business users trying to tease out system requirements from endless discussions that go round and round forever.... At the end of each day, they don't sign on to comp.lang.cobol to debate the merits of Sections vs Paragraphs. To them, programming is a just a chore that they have to do in order to get the end result the user wants.

Generally, business programmers are given the following objectives from their manager (in order of importance):

Don't screw up
Deliver it on time
Deliver what the user wants

From the users, they get the following objectives:

Don't screw up
Deliver what I want
Deliver it on time

I think this breeds a very conservative, risk-averse programmer, for whom avoidance of error is the primary concern. Don't tell him/her about EVALUATE, he/she knows that nested IFs work.

Victorian Internet

2009-12-03T14:20:00.000-05:00

There are some fascinating parallels between the 19th century telegraph system and the 21st century Internet.

Rules for young drivers

2009-12-02T10:15:00.000-05:00

Ontario has a graduated licensing system. The initial stage is G1, where the new driver must be accompanied by fully licensed driver. G2 is the next level, where the driver is allowed most of the privileges of a fully licensed driver, with some restrictions.

We've had two sons go through this process, and I'd like to share some of the rules that we imposed, above and beyond what the law says.

Here are Mom and Dad's G2 rules:

No solo highway driving (ie freeways and other major highways)
No solo night driving (not very practical in the winter, but workable in the summer. We eased this restriction after a month or two)
No passengers other than family members and a few trusted friends. In the case of trusted friends, only one of them at a time.
The 'Trusted friends list' is subject to parental approval.
All passengers MUST WEAR SEAT BELTS. No excuses, no exceptions. Anyone who refuses to co-operate must be refused a ride, and will be dropped from the 'trusted friends' list.
Passengers must also have 0% blood alcohol. A young G2 driver is not ready to be a designated driver.
Never, ever, take the car without permission.
We reserve the right to veto time, destination, and passengers.
You will run errands when requested. This includes driving siblings and getting gas.
At our discretion, you will check in with us when you arrive at your destination. (This is a good time to get him a cell phone, if he doesn't already have one)
Any ticket, no matter how trivial, will result in the suspension of driving privileges. No excuses, no exceptions, no appeal.
Ditto for accidents. (We never had to put this one to the test...thank goodness. This may seem unreasonable, but the rule reminds them that they have had defensive driving training and should know how to avoid accidents, even if they technically are not at fault.)
No eating or drinking while driving. Young drivers need to pay attention to the road at all times.
No cell phone usage while driving. (Now illegal in Ontario).

Maintenance: Make it Right!

2009-12-02T09:56:00.000-05:00

When faced with doing program maintenance, my personal philosophy is to try to leave the code a little better than I found it.

This goes beyond merely making the requested changes. Maintenance is a good time to beef up the program comments, untangle twisted logic (be careful with that one!) and change cryptic paragraph and variable names.

And, most importantly, take the time to review the error and exception handling. If inadequate, don't just ignore it and move on, make it right!*

A wise man once said to me: "Don't tell me how it works, tell me how it fails."

* Apologies to Mike Holmes

RTFM

2009-11-30T10:23:00.000-05:00

Although the acronym "RTFM" may be of (relatively) recent origin, the issue that prompted its creation goes back many years.

Back in the olden days when all manuals were on hard copy only, many programmers were too lazy to walk to the rack and look up the information for themselves. They would show up at my desk, demanding that I help them solve their problem.

Being young and anxious to show off my recently acquired knowledge, I would give them the answer and then try to explain the reasoning process that I went through to get there. It was at that point their eyes would start to glaze over, and I could tell they didn't want to learn anything...they just wanted to get past an obstacle so that they could finish their task.

What has changed since those days? Nowadays, with email and the Internet, you don't get to actually see their eyes glaze over.

You can't do that with SQL

2009-11-27T21:13:00.001-05:00

A long time ago I led a DB2 pilot project for one of IBM's earliest DB2 customers in Canada. By default, that made me one of the most experienced DB2 users, outside of IBM, in the country.

It wasn't long before it all went to my head, and I found myself making authoritative pronouncements on all things DB2 related. Why not? I was qualified; I had a whole 3 months of DB2 experience to draw on.

One of the challenges was learning how to use SQL when our only reference materials came from a 5 day IBM course. As you might expect, we ran into one obstacle after another. And it wasn't just SQL, we had to figure out how to Bind PLANs (there were no Packages in those days) and how to set up and use a DB2 test environment.

My programmers would ask me for advice on how to code an SQL statement and most of the time I could help them, but once in a while I had to declare: "You can't do that with SQL." I was the DB2 ghuru after all, so if I couldn't figure out how to do it, then obviously it was impossible.

Well, there was this very bright young trainee who, after hearing me say "You can't do that with SQL", came back 30 minutes later with an SQL statement that did exactly what I said couldn't be done.

I took it with good humour, not at all irritated to be corrected by a mere trainee. (Well, not for the first few times anyway). It eventually became a sort of game: every time I used the words "can't" and "SQL" in the same sentence, he would (almost) always prove me wrong.

That was an important lesson for me: whenever you think you're the smartest guy in the room, take another look, you may have missed someone.

HELP

2009-11-27T21:03:00.001-05:00

If I had a nickel for every time I've seen a blank look after asking "Did you try the HELP key?", I could have retired years ago.

Debugging tools and oncall support

2009-11-27T20:54:00.000-05:00

Debugging tools can require a fair amount of effort to set up, which sometimes earns them the reputation of being a waste of time. "Just put a DISPLAY message in the code, for God's sake!"says the project leader whose programming days are long behind him.

If a debugging tool is seen as a "waste of time" it is usually because the installation hasn't put enough effort into tailoring it for local use.

When we installed IBM Debug Tool in our shop, we altered all of our standard compile procs to support the TEST option and to link in the CEEUOPT module when needed. All the programmer has to do is select the TEST option on a panel and provide the VTAM LU of his debug terminal.

We never use the IBM supplied ISPF dialog to set up our debug sessions. I am not knocking IBM, but their dialog, of necessity, has to be generic, and like all generic tools requires a fair amount of effort to use. (This is where the "waste of time" perception comes into play).

We also provided each developer with a private DB2 data base for unit testing/debugging, and developed some in house tools to help them maintain them. This addresses data base contention concerns cause by people sitting at a breakpoint.

Finally, we renovated our once rarely used BTS environment to accommodate all of these changes.

It is the programmer who puts Display messages in the code that is "wasting time".

Having said that, a well-placed Display message is a useful thing to have in a production program when it blows up in the middle of the night.

After copying the data to a test environment, recompiling the program with TEST options turned on, you may be able to re-create the problem using a debugging tool. Of course, by then the batch window will be long over and you'll be too busy updating your resume to care about the problem any more.

On call support is not the time to exercise your debugging skills. Finding the logic error and fixing the program is #4 on my list of priorities at a time like this.

1. Bypass the failing job.
2. Bypass the failing step and proceed with the rest of the job.
3. Pull record from input file or take some other action to bypass the problem record.
4. Fix the offending program.
5. Recover the data base and abandon the entire batch run. Update resume.

A well chosen DISPLAY message can make #3 very easy to do.

RTFC

2009-11-27T20:39:00.000-05:00

Why do some programmers prefer to spend hours yakking about what a program might be doing, or what it ought to be doing, rather than actually reading the code? I may be old-fashioned, but I think that it is the programmer's job to RTFC. Many of them ("us", actually, since I still do a lot of programming) are too lazy, especially if the code in question was written by someone else.

I think that is why some systems programmers seek to induce fear in the hearts of application programmers. I used to think that this was merely a form of torture for the sysprog's amusement, but I believe this is actually a type of training.

The sysprog's hope is that if he consistently ridicules them for asking stupid questions, eventually the questions will get better. Maybe even to the point that the programmer will start to RTFC (and RTFM!) before asking for help. A forlorn hope perhaps.

Clockwise?

2009-11-27T20:21:00.000-05:00

I remember when I first taught my son how to use a wrench. I had to explain to him the difference between "clockwise" and "counter-clockwise". It was not obvious to him because of digital clocks.

He must have understood the lesson because he is an engineer now.

Buffer this!

2009-11-27T20:16:00.000-05:00

A learned colleague of mine coded a process that attempted to access the same row on a DB2 table 375 million times per run. (It was a code lookup). When I pointed this out he dismissed my advice by insisting that it didn't matter because the data would be sitting in a DB2 buffer anyway so there would be no I/O cost.

What he didn't reckon on was the CPU path length of the DB2 SELECT statement he was using. It is a long way from Cobol to DB2 and back again even when DB2 doesn't do any I/O. When we changed the process to use an in-core table, the CPU usage dropped from several hours to several minutes.

The moral is: sometimes a little knowledge is more dangerous than no knowledge at all.

Who do you believe, the programmer or the code?

2009-11-27T19:36:00.000-05:00

When asking for advice, Programmers will tell you what they coded, but what they really mean is:

"This is what I think I coded" or "This is what I meant to code".

RTFC is the only way to be sure.

Another reason not to share your password

2009-11-27T19:30:00.000-05:00

When I was a junior programmer I was loaned out to another project for half a day. The PL didn't want to bother setting up my RACF access for such a short assignment, so he just gave me his password (which was against the rules, even in those days) and let me use his TSO userid.

The PL had PFK10 set up as CANCEL. This screwed me up because my own userid had PFK10 set up as SAVE. After losing several rounds of changes by hitting CANCEL when I meant SAVE, I changed the PL's PFK10 setting to match the one I was accustomed to.

This would have been fine except that I forgot to change it back again when I finished using his userid.

I heard some colourful language the next day when the PL SAVE'd some changes he'd meant to CANCEL.

He couldn't very well report me to Security, since he shouldn't have let me use his userid in the first place.

Practical jokes on the 'frame

2009-11-27T19:27:00.000-05:00

I know 'someone' who once wrote a clist that displayed an exact replica of the TSO logon screen that was in use at the time.

The clist was named after a commonly used local function, so when the poor victim used it, he would think that he'd been booted off the system. He'd scratch his head, and try to log on again, but the "logon" screen would ignore his password. It was programmed to unlock itself after about 10 attempts.

Uninitialized storage (1)

2009-11-27T17:23:00.002-05:00

Assumptions about the state of uninitialized storage can bite the best of us. Last year we ran into a problem with the Cobol code generated by the SQL Coprocessor using Enterprise Cobol 3.3 under DB2 V8.

In the SQL---PLIST it was generating the following FILLER area:

02 SQL---STMT-NUM PIC S9(9) COMP-5.
02 FILLER PIC X(20).

Apparently the FILLER area is used by DB2 to store some bit switches and its logic assumes that initially the FILLER contains x'00'. *Usually* this is true, but we ran into some very weird application abends in a production IMS MPR.

It turned out that we were a bit behind in our Cobol maintenance. After the maintenance was applied the generated code changed to:

02 SQL---STMT-NUM PIC S9(9) COMP-5.
02 FILLER PIC X(20) VALUE IS
X'0000000000000000000000000000000000000000.

In my experience this is one of the very few times which a programmer's protest that "It's not my fault!" turned out to be true.

Masking test data

2009-11-27T17:12:00.001-05:00

Many organizations demand that all identifying personal information be scrambled when a copy of production data is used for system testing. The idea is to limit the damage if the data is accidentally released to the outside world. Printing a test version of a client statement that accidentally gets routed to the mail room, for example.

As we found out a couple of years ago, masking can bite you in ways that you might not expect.

We were testing a new release of a recently developed system using data where the client's name was scrambled to a bunch of random characters. The testing went smoothly, and the new release went into production.

It was not until we were running in production that we realized that one of the screens was transposing the client's first name and surname on the data base. The error had gone unnoticed by the programmer and the testing / QA teams simply because the scrambled names lacked the visual cues that made the problem obvious once real names were used.

Field Name Prefix on DCLGEN command

2009-11-27T15:51:00.000-05:00

I strongly advise using the "Field Name Prefix" feature of the DCLGEN command. This causes each Cobol field in the DCLGEN to have the same prefix. This makes coding much easier, as it can eliminate the need to code Cobol "OF"s when referring to a field.

How many of your tables contain an account number field? A good many of them, probably. It is easier to code

MOVE WS-TEMP-ACCT-NUM TO VIFCACCT-ACCT-NUM

than

MOVE WS-TEMP-ACCT-NUM TO ACCT-NUM OF ACCT-TABLE.

Using prefixes, the programmer can tell at a glance which ACCT-NUM is being referred to.

The prefix name should be related to the table name. Our shop adopted a procedure in which we establish an 8 character 'short name' for each table. The short name is used as the prefix name, and is also used to build the table space name.

I feel so strongly about this that, years ago, before DCLGEN even had a "Field Name Prefix" feature, I wrote an edit macro that added a field name prefix to the DCLGEN output. It is still in use today.

ISPF survey

2009-11-27T15:38:00.000-05:00

Asked on ISPF-L:

Who uses the panels you develop and support?

Other programmers, mostly.

Do you continue to create new panels or is your panel library fairly static?

I create new ones on a regular basis.

Are you a private company or a government agency?

I am a self-employed consultant, currently working for a government agency.

Is there any other product you use to generate panels in ISPF?

No. I have never felt the need for one.

Do you think it wise to migrate to DTL or would that be akin to walking to the edge of mount doom with my precious?

No. I would rather put my command line at the bottom of the screen than use DTL.

Advice

2009-11-26T23:12:00.002-05:00

Here is a list of some dubious career advice that I've been given over the years. The degree of dubiousness varies.

1981 : "Stay away from COBOL...it's a dead language."

1982: "Structured analysis, structured design, structured code...everything else is crap"

1983: "There won't be any more batch processing within 5 years, everything will be online"

1984: "Find another line of work. 4GLs will make programmers obsolete."

1985: "What, you're still using VSAM? Get a database!"

1986: "Hierarchical data bases are obsolete. If you're not relational, you're not in the game!"

1987: "*Still* using COBOL? You dumb #$@!"

1988: "CASE tools will solve the application backlog"

1989: "Code reuse will solve the application backlog"

1990: "Forget CASE tools. Desktop development is much faster!"

1991: "The mainframe is dead. Go client server"

1992: "Find another line of work. Overseas outsourcing will put you out of a job"

1993: "OO analysis, design and development will solve the application backlog"

1994: "What? You're still using IMS??"

1995: "Forget Cobol. Learn C".

1996: "Forget C. Learn C++".

1997: "Y2K will be the end of the world as we know it"

1998: "Okay, maybe COBOL isn't dead....but it will be after Y2K is finished"

1999: "All future application development will be in JAVA"

2000: "The mainframe is the best platform for e-business"

2001-present: I stopped listening to advice. :-)

The jury is still out on some of these items.....

Whose default is it? (sorry)

2009-11-17T19:13:00.001-05:00

The LE run time parameter CBLQDA can bite the unwary. It doesn't help that IBM has changed the default value over the years. I was just recently able to convince our local sysprogs to change it to OFF. Their first reaction was that there had been no change, that the system had always behaved that way, and OFF was the default.

The story I heard was that IBM originally delivered CBLQDA(ON) as the default, with a recommendation to turn it OFF. This was to comply with some ANSI COBOL standard. Our local sysprogs accepted IBM's recommendation and set it to OFF. A few years later, IBM changed the default to 'OFF'. The local sysprogs knew that in the past they didn't use the default value, so, by reflex, they switched it to 'ON'. And for a long time no one complained.

(For those not intimately familiar with IBM's Language Environment, the CBLQDA setting controls the behaviour of COBOL programs that fail to assign a dd name to an output file. CBLQDA(OFF) means that an error is thrown, CBLQDA(ON) means that the problem is ignored.)

I was remined of this when I was approached by a desperate colleague who had been banging his head against the wall for two days, trying to figure out why, no matter what he did, his output file remained empty. He could see the EXCP counts, so he knew data was being written somewhere. It turned out he had a misspelled ddname, and because CBLQDA(ON) was in effect, z/OS was writing to output to an uncataloged temporary file instead of the one that was intended.

Ouch.

Standards are forever

2009-11-14T18:59:00.000-05:00

I am presently working at a shop where static linked modules are the standard practice. Much to my dismay, convincing them to change to DYNAM is proving to be more difficult than I expected. Change is a constant in this business, except where Standards are concerned.

Fortunately, the chief defender of the standard retired recently, so there is now some hope that it will change.

Oops!

2009-11-06T14:23:00.001-05:00

So what is a mere developer to do when he catches his DBA or sysprog in an error?

Mercilessly mock him. It's payback time baby! Or,
Tell the sysprog that it is all your fault, that you should have known the answer yourself. Apologize for wasting his time. Or,
Express your astonishment that the laws of physics were changed in the last release, and there is no way on earth that anyone could have known the answer. Or,
Take him out for a beer. With any luck, he'll offer to pay for it. This time. The other 99% of the time the beer is on you.

Do I need to tell you what the best option is?

Disclaimer: this post is an attempt at humour. Some of my best friends are DBAs and systems programmers.

SDLC: system testing

2009-11-06T13:58:00.000-05:00

You won't find these in any methodology textbook. Here are the 10 stages of system testing:

Unwarranted optimism: "Everything will be fine....it says so in the Plan"
Denial: "It must have worked...look at the results again"
Bewilderment: "What do you mean, it didn't work?"
Confusion: "That didn't work either!?"
Panic: "Nothing is working!!!"
Despair: "We're doomed...nothing will ever work"
Desperation: "Maybe if we call it an 'original bug' no one will blame us!"
Bargaining: "Maybe if we defer some more requirements to phase 2 we can get this phase finished"
Hope: "It's working now?"
Smugness: "I told you it would work. Just like we Planned it."

What stage is your project in?

SDLC: Production support

2009-11-06T13:57:00.000-05:00

Ah, the forgotten phase of every project. Production Support never gets the respect that it deserves. It too goes though phases:

Disbelief: "But it worked during UAT!"
Denial: "It must be an implementation problem...not our fault"
Dodging: "Prod support can deal with it". And now the Prod support team takes a look at it...
Anger: "Those idiots on the project team couldn't have tested this"
Confusion: "What the hell is this anyway?"
Dismay: "Oh crap....there's no way that we can fix this"
Bargaining: "Wait a minute...isn't it still under Warranty?"
Glee: "It's screwed up, and it's not *our* fault!" Now it is sent back to the Project team....
Disgust: "Those idiots in Prod support couldn't find their butts with both hands"
...there is no end to this list

And the survey says.....

2009-11-06T13:49:00.004-05:00

Questions originally posted on comp.lang.cobol by Pete Dashwood. Answers are mine.

1. What is your personal attitude to your management? Do you see them as a bunch of wankers who have no idea what's going on or is required, no understanding of the problems you have to grapple with every day, and just an unnecessary departmental overhead because a trained monkey could do their job?

As a species Managers are wonderful. They give direction and comfort to those who need it the most.

2. Do you have any aspirations to ever be management? Why? Why not?

It is something that I aspire to. With the right mentor it might be possible.

3. Could your attitude affect your management? (d'you think...?)

Definitely. It is important to try to see the big picture...when you look at things that way your manager is always right.

4. Would you do exactly what is specified in say, a program spec., even if you knew it was wrong, and would cause major disruption to downstream processing? How would you deal with this situation (if at all)?

My manager has an open mind as well as an open door. He would listen to my concerns, and then share his wisdom with me. I would soon realize that I am mistaken and he is correct.

5. In meetings, do you speak your mind and to Hell with them if they don't like it, or do you tend to pussyfoot for the sake of annual review? Would you modify your language depending on the level of management present? Why? Why not?

Managers are always open to honest feedback. I see no reason why they would be offended by such.

6. Are you gleeful when your manager is in trouble?

Not at all. I fret over it, and do whatever I can to help him overcome it.

7. Does your manager socialise with you on occasion? Is it comfortable or would you rather they didn't?

I am not worthy.

8. If you screwed up, would you look for support from your manager or would you make every effort to hide your blunder or divert attention from it until you could fix it, if you could fix it?

I would admit my guilt immediately and work whatever overtime was necessary to correct my error.

In conclusion, my manager is a wise and powerful leader. And he monitors my blog postings.

Mythbusting: DB2 results table

2009-11-06T11:14:00.000-05:00

DB2 does not always create a results table. This is a common misunderstanding because programmers are taught to code their cursors as if the results have already been materialized.

We had a case in our shop, shortly after migrating to DB2 V8, of recently inserted rows suddenly appearing within a cursor. The programmer was indignant, insisting that since the program hadn't been changed, this must be a DB2 V8 issue. Well, DB2 has never guaranteed that this would not happen in an ambiguous cursor. It was therefore not a bug in DB2 V8, we'd just been lucky for the previous several years.

More recent versions of DB2 allow much more control over this situation than in the past.

Adding INSENSITIVE SCROLL solved the problem for us. It was an easier alternative than changing the application to ignore recently (within the same unit of work) inserted rows.

Even a very experienced and expert programmer (ahem) can trip over this one. I once changed an online program to insert rows into the same table that was the subject of a cursor. The rows were inserted after the current row, so the FETCH loop just kept running, endlessly chasing EOF without ever getting there. Doh!

Fortunately, the problem was caught during unit testing.

Using I/O subroutines to access DB2 tables

2009-11-06T11:04:00.002-05:00

DB2 shops have been debating this one for years.

One problem with using subroutines for all I/O is that you lose DB2's ability to fetch just the column(s) you are interested in. I/O subroutines are usually pretty generic, essentially doing a SELECT * on the requested table. *

Performance geeks will complain about the CPU cost of fetching more columns than you really need. DBAs will complain that you are using DB2 as if it was IMS. And your data modelers, well, they'll just complain, as they always do, that you didn't implement their model properly.

The only one who won't complain will be your project manager, because the I/O routines save you coding time. (Assuming that the poor sap coding the I/O routine isn't working for him too.)

* I once saw an application where an attempt was made to mitigate this problem by requiring the calling program to pass an array of flags, each one corresponding to a column that was to be retrieved. As you can imagine, this bloated the code (no dynamic SQL allowed!) in the I/O subroutine to the point that the cure was worse than the disease.

So you want to do a 7 table join?

2009-11-06T10:50:00.002-05:00

My usual advice when faced with a query like this is to break it up into simpler parts. Just because you can do something with a single query, doesn't mean that you should. Temporary tables (or QMF's SAVE DATA) are an excellent way to achieve this.

Why FTP?

2009-11-06T10:48:00.003-05:00

I have never understood the fascination with FTP. If all you want to do is transfer files between z/OS and a Windows workstation, then ISPF's Work Station Agent (WSA) works great. It's simple to use, fast and secure. Best of all, you can automate it using Rexx or any other language that supports ISPF dialog services.

See this link if you want to learn more about WSA.

Still not convinced? See this one too.

Cobol scope terminators

2009-11-06T10:44:00.000-05:00

All the scope terminators are great, but I especially like END-IF because it allows you to avoid programming in SENTENCES. IMO, the designers of Cobol took the natural language metaphor a bit too far when they introduced the concept of logic flow delimited by periods (aka "full stops").

IMO the lack of END-IF in early versions of Cobol severely damaged the reputation of the language. I think that is the reason why Dijsktra said:

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

END-IF is easily the most important innovation ever made to the language in the 28 years that I've been working with it.

Some of my best friends are DBAs

2009-11-06T10:42:00.001-05:00

Don't judge DBA's too harshly. They're not programmers, and may never have actually coded a cursor themselves.

IPT vs ISPF

2009-11-06T10:36:00.002-05:00

I find this link interesting because IBM appears to be rubbishing ISPF in order to promote IPT

ftp://ftp.software.ibm.com/software/...Comparison.pdf

Straw men walking!

Feeling young

2009-11-06T10:35:00.002-05:00

Hearing old timers talk about TSO edit makes me feel young. (A rare pleasure that is getting rarer).

I was one of the first generation of programmers to have the privilege of using SPF right at the start of my career. During my entry level training, the topic of TSO was glossed over; I never even had to learn TSO Edit.

This was back in 1981, when it was called SPF (Structured Programming Facility). A few years later it was re-branded as ISPF (Interactive Structured Programming Facility...."Interactive" being the buzzword of the day).

Then, sometime in the late 1980s ISPF became "Integrated Systems Productivity Facility". "Integrated" was a fashionable buzzword at the time, and IBM decided that ISPF wasn't just for "Programming" any more.

Nowadays the official name of the product is "Interactive System Productivity Facility". Whatever happened to "Integrated"? Perhaps I have my chronology wrong.

Your memories may vary. (Mine vary from day to day).

I think I first saw option 3.4 in 1986 +- 1 year or so. I didn't like it very much...real programmers knew all of their data set names, so who needs 3.4? (Twenty years later, I am hooked on SimpList, a product which is like 3.4 on steroids).

I remember when you had to hit RETURN rather than ENTER in order to use a Jump function. I also remember complaining when they changed that, but I soon got used to it.

How long should a process take?

2009-11-06T10:29:00.002-05:00

"How long is a piece of string?" may be the flippant answer, but it's not a very useful one.

It is possible to predict, with a fair amount of accuracy, how long a process will take if you know how many records must be processed, what is being done to them, what type of machine it is running on, how many i/o buffers are available etc etc

Or, you can run the input file through DFSORT or other high performance utility.

If DFSORT can process a file in 10 minutes (even if it's not doing exactly the same processing...most business applications are I/O bound) and my Cobol program can do it in 15, then I don't spend much time tuning the Cobol because it is probably about as good as it is going to get.

That is just a rule of thumb of course. Your mileage will vary.

Don't mess with my PFKeys!

2009-09-15T09:30:00.001-04:00

You can count me in the "keylist loathing" category. I put a lot of thought into my PFKEY definitions and I hate it when dialog developers try to override my wishes.

For example, I used to have VCURSOR set up as my PFK13. VCURSOR (thank you Mr. Nadel!) allows you to place the cursor on a data set name on any ISPF panel and Browse the data set. This is an extremely useful function and I want to be able to use it everywhere without interference from dialog developers.

*I no longer have VCURSOR mapped to my PFK13 because we have a commercial product that performs the same function as VCURSOR, plus a lot more.

Open Cursor

2009-03-12T18:13:00.001-04:00

Figures that I'd get into blogging long after the rest of the world. Well, I work as a mainframe programmer, so everyone expects me to be behind the curve anyway.