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.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
2010-11-25
Down in the Dumps
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.
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.
2010-11-11
I love bugs
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.
Hunting for bugs is what I like best about this business. To me, a perfectly working program may be admirable, but it's boring.
2009-12-15
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.
What might work today may fail miserably tomorrow, without warning and without apparent cause.
If you care about it, then initialize it.
2009-12-02
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
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
2009-11-30
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.
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.
2009-11-27
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".
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.
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.
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.
"This is what I think I coded" or "This is what I meant to code".
RTFC is the only way to be sure.
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.
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.
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.
2009-11-06
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.
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.
Subscribe to:
Posts (Atom)
