Home > Archive > Cobol > October 2005 > [OT] Debugging, Ye Olde-Tyme Waye, Kind Of
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[OT] Debugging, Ye Olde-Tyme Waye, Kind Of
|
|
|
|
I say it is 'olde-tyme' because it deals with batch processing as opposed
to OLTP; in a world where individual transactions fly across the Web so
that a gewgaw purchased in Grenoble causes an inventory-request to appear
in Szhenzhen the concept of doing the same thing to a whole bunch of
transactions at the same time might appear, to some, to be...
e'er-so-quaint.
('The accountants want month-end figures? Why don't they just go online
and get the up-to-the-minute ones? And what's this about 'the law'
requires quarterly reporting?')
(platform is IBM mainframe)
Anyhow... I come in yesterday and get told 'this program blew up... since
the guy who knows it best retired and only comes in two days a w now
and this isn't one of them and you put an error-message into the code last
June you get to deal with it. The dump's in the output queue.'
So I shoot the dump and determine that it blew up with a zero-divide error
on employee 123-45-6789... seems like her data came in with no hours
reported for the period and when the code tried to COMPUTE an hourly rate
by dividing by this it went kerfloo. Since the job had to be run now Now
NOW it was decided to edit out this employee's data, run the rest and deal
with her by the manual correction process.
However... the input file was fair-sized; about 65K employees, each with
multiple record types, for a total of about 2M recs (LRECL=200). When the
Ops crew tried to Edit the file to delete the records it was just too big
and the system defaults brought it up in Browse mode... and FileAid isn't
installed here. I could have coded a SORT to skip over the records... but
just for laughs I used the interactive MAX utility (a kind of hobbled
FileAid) to edit out the records.
The next run blew up again, same error, different employee, 124-45-6790.
So... going back into the data revealed a Curious Coincidence. Data for
the first employee began at record number 415,731 (or something like
that)... and data for the second one, after the first had been deleted,
began also at 415,731. Batch processing... multiple record types... two
folks showing up in the same physical position in the file blow up with
the same error, nothing in the code to indicate that some
debugging-statements got left in when it was implemented to Prod...
.... and so I concluded that it was not the first one who was in error, nor
the second... but the one preceding the first (the 'zeroth', as it were);
*that* was the one coming in with garbage and when the next one showed up
the program's 'you are here' pointers showed who just came in... and then
went back to processing the totals for the previous person.
Not 123-45-6789 or 124-45-6790... but 122-34-5678. I deleted *her* data,
Ops resubmitted and everything ran like a watch.
The Lesson for the Newbies from all this? It is good to pay attention to
where you are, aye... but sometimes the difficulty lies not there but in
where you were.
DD
| |
| Mark Perew 2005-10-20, 6:55 pm |
| docdwarf@panix.com wrote:
> The Lesson for the Newbies from all this? It is good to pay attention to
> where you are, aye... but sometimes the difficulty lies not there but in
> where you were.
One must also be careful to watch for zero relative counters. If the first
record is Record 0, but you don't pay attention to that, then you'll land in
the wrong place.
--
Mark Perew <perew@squeep.com>
To the world you may be just one person,
but to one person you may be the world. (Source Unknown)
| |
|
| In article <dj87sj$1gp@dispatch.concentric.net>,
Mark Perew <perew@bokbok.squeep.com> wrote:
>docdwarf@panix.com wrote:
>
>One must also be careful to watch for zero relative counters. If the first
>record is Record 0, but you don't pay attention to that, then you'll land in
>the wrong place.
I was taught, lo, those many years ago, that 'all good programmers start
counting at zero. COBOL programs start counting at one... draw your own
conclusions.'
DD
| |
| John Culleton 2005-10-20, 6:55 pm |
| docdwarf@panix.com wrote:
> In article <dj87sj$1gp@dispatch.concentric.net>,
> Mark Perew <perew@bokbok.squeep.com> wrote:
>
> I was taught, lo, those many years ago, that 'all good programmers start
> counting at zero. COBOL programs start counting at one... draw your own
> conclusions.'
>
> DD
And I learned the hard way that an error message pointing to line 2001 was
often caused by an error on line 2000---on IBM COBOL D and its progeny.
--
John Culleton
Able Indexers and Typesetters
| |
|
| In article <KM2dndTv5dA0UcreRVn-tw@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
>docdwarf@panix.com wrote:
>
[snip]
[color=darkred]
>
>And I learned the hard way that an error message pointing to line 2001 was
>often caused by an error on line 2000---on IBM COBOL D and its progeny.
Reminds me of my first compile, back in the Oldene Dayse... I was amazed
at how many errors resulted from typo'ing SOURCE-COMPPUTER.
DD
| |
| John Culleton 2005-10-20, 6:55 pm |
| docdwarf@panix.com wrote:
> In article <KM2dndTv5dA0UcreRVn-tw@adelphia.com>,
> John Culleton <john@wexfordpress.com> wrote:
>
> [snip]
>
>
> Reminds me of my first compile, back in the Oldene Dayse... I was amazed
> at how many errors resulted from typo'ing SOURCE-COMPPUTER.
>
> DD
This could become a long thread :< ). One day in 360-land an upgraded
compiler suddenly caused well-tested programs to blow up when recompiled.
It seems a lazy programmer hadn't bothered to end the last statement of
some paragraphs with a period. And a 370-era COBOL program wouldn't even
start to compile on a HP 3000. It seems the first statement was
ID DIVISION.
That one was easy to miss. Gotta watch those vendor-specific extensions!
--
John Culleton
Able Indexers and Typesetters
| |
| Peter Lacey 2005-10-20, 6:55 pm |
| John Culleton wrote:
> This could become a long thread :< ). One day in 360-land an upgraded
> compiler suddenly caused well-tested programs to blow up when recompiled.
> It seems a lazy programmer hadn't bothered to end the last statement of
> some paragraphs with a period. And a 370-era COBOL program wouldn't even
> start to compile on a HP 3000. It seems the first statement was
>
> ID DIVISION.
>
> That one was easy to miss. Gotta watch those vendor-specific extensions!
>
Also how faithful the vendor was to the standard. (This will date me!)
We upgraded from a UNIVAC 9480 to an 1100/20. A number of our programs
compiled ok on the 1100 but blew up on execution. The cause was that,
at that time, SORT input & output procedures had to be sections; the
programs were written that way but the program flow didn't have a
specific end-of-job procedure after the sort statement. On the 9480 the
program fell off the end of the output procedure section and terminated
apparently normally; on the 1100 this was an abnormal thing and crashed
accordingly.
Fortunately that was the sort of thing that only needed to be identified
once; plus it was just one programmer's work.
PL
| |
|
| In article <F8-dncPmxvxMcMreRVn-tw@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:
>docdwarf@panix.com wrote:
>
[snip]
[color=darkred]
>
>This could become a long thread :< ).
Sure, it'll be easy, swapping Tales of the Trenches... and it'll go on as
long as the codgers and old coots manage to stay awa.... zzzzzzzz...
DD
| |
| Mark Perew 2005-10-21, 6:55 pm |
| docdwarf@panix.com wrote:
> In article <dj87sj$1gp@dispatch.concentric.net>,
> Mark Perew <perew@bokbok.squeep.com> wrote:
>
> I was taught, lo, those many years ago, that 'all good programmers start
> counting at zero. COBOL programs start counting at one... draw your own
> conclusions.'
COBOL programs start counting at one? Sayeth who?
--
Mark Perew <perew@squeep.com>
To the world you may be just one person,
but to one person you may be the world. (Source Unknown)
| |
|
| In article <djaq4o$pmo@dispatch.concentric.net>,
Mark Perew <perew@bokbok.squeep.com> wrote:
>docdwarf@panix.com wrote:
>
>COBOL programs start counting at one? Sayeth who?
My error and apologies for the sloppy terminology; what I intended to
convey was that in COBOL the initial element of a table is referred to
with a subscript of one.
DD
| |
| HeyBub 2005-10-22, 6:55 pm |
| docdwarf@panix.com wrote:
>
> My error and apologies for the sloppy terminology; what I intended to
> convey was that in COBOL the initial element of a table is referred to
> with a subscript of one.
Izallright. COBOL was invented before zero.
| |
|
| In article <11ll4rmtknttq6e@news.supernews.com>,
HeyBub <heybubNOSPAM@gmail.com> wrote:
>docdwarf@panix.com wrote:
>
>Izallright. COBOL was invented before zero.
'Her name was Vickie... she was named after Queen Victoria... and by the
looks of her, not very long after.' - Benny Hill
DD
| |
| Defaultuser 2005-10-23, 3:55 am |
| DD
I read a somewhat different set of conclusions
> So I shoot the dump and determine that it blew up with a zero-divide error
> on employee 123-45-6789...
You then say it wasn't this employee record. Conclusion. Don't assume you
know what the problem is until you know what the problem is.
> ... and so I concluded that it was not the first one who was in error, nor
> the second... but the one preceding the first (the 'zeroth', as it were);
Conclusion. You can in practice ignore the prior conclusion because
sometimes you're lucky.
> Not 123-45-6789 or 124-45-6790... but 122-34-5678. I deleted *her* data,
> Ops resubmitted and everything ran like a watch.
Conclusion. It's *always* the womyn's fault.
Two further conclusion.
It is might fair to say that one should know where they've been, but they
should not forget where they are going.
Ye New-Tyme waye of debugging is easier - you should try it one day ;-)
I am not going to mention the fact that an operations team that cannot do
anything is worth, oh I don't know - nothing and no more than *ten* nothings
of years past.
D
| |
|
| In article <S3G6f.166137$xl6.105538@tornado.tampabay.rr.com>,
Defaultuser <Defaultuser@hotmail.com> wrote:
>DD
>
>I read a somewhat different set of conclusions
>
>You then say it wasn't this employee record. Conclusion. Don't assume you
>know what the problem is until you know what the problem is.
'Don't assume you know what the problem is until you know what the problem
is?' If one knows what the problem is then it might be concluded that
assuming what the problem is is a... curious way to spend one's time.
'I knew what the problem was... but I decided to take a while to assume
it, too.'
>
>Conclusion. You can in practice ignore the prior conclusion because
>sometimes you're lucky.
.... instead, of course, of determing conditions, arriving at an
hypothesis, testing the hypothesis, examining the results of the test,
generating a different hypothesis depending on the data which result from
the test... no, that sounds too much like it is trying to be similar to
Science, aye.
>
>Conclusion. It's *always* the womyn's fault.
Once is '*always*'? For a discrete, atomic universe, perhaps... and even
in such a place it might be wise to recall that the representation is not
the object and the data are not the person.
>
>Two further conclusion.
>It is might fair to say that one should know where they've been, but they
>should not forget where they are going.
>Ye New-Tyme waye of debugging is easier - you should try it one day ;-)
Ahhhhh... were I to have done so I would have earned less gratitude;
handling the situation in this manner not only got the problem solved
within the window available but it also took *just* long enough so that a
meeting was cancelled... and many were grateful to me for that, as well.
>
>I am not going to mention the fact that an operations team that cannot do
>anything is worth, oh I don't know - nothing and no more than *ten* nothings
>of years past.
The Zen of Programming offered me by my first programming instructor
fortunately allowed for such situations to be covered, both then and
now... but he was an instructor of the Oldene Dayse, and such as *ten*
instructors are not, today!
DD
|
|
|
|
|