Uninitialized storage (2)

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

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

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:

1. 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.
2. 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..
3. 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.
4. 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

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

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. 

Victorian Internet

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

Rules for young drivers

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!

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

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.

Debugging tools and oncall support

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".

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.

Buffer this!

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?

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.

Practical jokes on the 'frame

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)

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

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

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

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

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)

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

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!

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

1. Mercilessly mock him. It's payback time baby! Or,
2. Tell the sysprog that it is all your fault, that you should have known the answer yourself. Apologize for wasting his time. Or,
3. 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,
4. 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

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

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

What stage is your project in?

SDLC: Production support

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

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

And the survey says.....

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

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

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?

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?

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

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

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

IPT vs ISPF

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

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?

"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!

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

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.