Boss talk

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

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.

Cruelty to Mainframers

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. 

5 more ways to start a war on a mainframe forum

1. Say something positive about Windows.
2. Declare that the 'frame is dead and squatty boxen rule.  Don't forget the "boxen" part.
3. Opine that RAS is overrated; the future belongs to Wintel because it's cheaper.
4. 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.
5. Mention Hercules. 

5 ways to start a war on a mainframe forum

Too cool for the room?

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.

The Project

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?

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.

Nostalgia: program flow charts

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.

5 ways to start a war on a mainframe forum

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

5 more ways to start a war on a mainframe forum

Application entropy

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.

Some recent Dilberts

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

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

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):

1. Don't screw up
2. Deliver it on time
   
3. Deliver what the user wants
   

From the users, they get the following objectives:

1. Don't screw up
2. Deliver what I want
3. 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. 

RTFM

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

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

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.

RTFC

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?

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.

Who do you believe, the programmer or the code?

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

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.