Home > Archive > Cobol > September 2004 > PowerCOBOL Hint. Hell, REVELATION!
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 |
PowerCOBOL Hint. Hell, REVELATION!
|
|
| JerryMouse 2004-09-09, 3:55 pm |
| Plagued with an intractable error message at the start of debugging "...
error in xxxxx.SVD....," and having exhausted all known "fondle-it-until it
works" techniques, we girded our loins, went not into our wives this night,
and started tearing the son-of-a-XXXXX apart.
Found it!
Before I tell you what the problem was, I've got to tell you there was much
dancing in the street. The vino flowed freely. There was joy throughout the
land! Now I'm going to share with you the disease that generated the above
symptom. Wait for it now....
A superfluous end-of-file smack in the middle of Working-Storage.
This particular EOF was possibly sucked in with a defective #INCLUDE
copy-book, but however the EOF got there it  the hell out of the
debugger.*
Further, the miscreant EOF could not be removed or painted over! It clung
like a barnacle and nothing would dislodge the sucker - normal editing
procedures simply skipped over the damned thing (you evidently can't get rid
of a hole by digging it out).
The fix was to cut all above this errant EOF, pasting same into a dummy
procedure division area, doing the same with the area following the culprit.
Then delete the Working-Storage module, followed by re-creating same with
the stuff formerly saved in a holding area.
I apologize for being so effusive on this matter, but this particular puddle
has occupied the time of one programmer, off and on, for over three w s.
Such a relief. I'm going to go have a lie down.
----
*One of our failed attempts at a solution involved ditching all the
#INCLUDEs and replacing them with the original copy-book texts. This failed,
no doubt, because the copy-book had the extra EOF or the extra EOF was
already firmly ensconced in the PC code.
| |
| Russell Styles 2004-09-09, 3:55 pm |
| Some editors will allow you to see this sort of thing.
EDLIN was one - it required an option that I forget right now.
Of course, who has EDLIN on their pc these days.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:HeudnRQXwZoIt6LcRVn-sA@giganews.com...
> Plagued with an intractable error message at the start of debugging "...
> error in xxxxx.SVD....," and having exhausted all known "fondle-it-until
it
> works" techniques, we girded our loins, went not into our wives this
night,
> and started tearing the son-of-a-XXXXX apart.
>
> Found it!
>
> Before I tell you what the problem was, I've got to tell you there was
much
> dancing in the street. The vino flowed freely. There was joy throughout
the
> land! Now I'm going to share with you the disease that generated the above
> symptom. Wait for it now....
>
> A superfluous end-of-file smack in the middle of Working-Storage.
>
> This particular EOF was possibly sucked in with a defective #INCLUDE
> copy-book, but however the EOF got there it the hell out of the
> debugger.*
>
> Further, the miscreant EOF could not be removed or painted over! It clung
> like a barnacle and nothing would dislodge the sucker - normal editing
> procedures simply skipped over the damned thing (you evidently can't get
rid
> of a hole by digging it out).
>
> The fix was to cut all above this errant EOF, pasting same into a dummy
> procedure division area, doing the same with the area following the
culprit.
> Then delete the Working-Storage module, followed by re-creating same with
> the stuff formerly saved in a holding area.
>
> I apologize for being so effusive on this matter, but this particular
puddle
> has occupied the time of one programmer, off and on, for over three ws.
>
> Such a relief. I'm going to go have a lie down.
>
> ----
> *One of our failed attempts at a solution involved ditching all the
> #INCLUDEs and replacing them with the original copy-book texts. This
failed,
> no doubt, because the copy-book had the extra EOF or the extra EOF was
> already firmly ensconced in the PC code.
>
>
>
| |
| JerryMouse 2004-09-09, 3:55 pm |
| Russell Styles wrote:
> Some editors will allow you to see this sort of thing.
>
> EDLIN was one - it required an option that I forget right now.
>
> Of course, who has EDLIN on their pc these days.
Oh we could SEE it; it was NOTICING it that was our fault. An EOF is shown
as a left-arrow which looks very much like a RETURN (broken left-arrow) and
we just didn't snap.
Then, once we did find the EOF, getting rid of the son-of-a-XXXXX required
jumping through several hoops.
Anyway, this exercise illustrates the maxim: "If you stare at something more
than five minutes, the problem is either trivial to solve or nigh-on
impossible."
| |
| Robert Wagner 2004-09-09, 3:55 pm |
| On Thu, 9 Sep 2004 09:47:42 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:
>Then, once we did find the EOF, getting rid of the son-of-a-XXXXX required
>jumping through several hoops.
Why couldn't you run a hex editor and overtype it?
| |
| Russell Styles 2004-09-09, 3:55 pm |
| To find a cntl/z, just "TYPE" the file.
It will stop at the cntl/z.
This still begs your original question though -
If you go to the trouble of "type"ing your file,
you already know that it has a cnlt/z in it.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:5vGdncb6s4iS8N3cRVn-pA@giganews.com...
> Russell Styles wrote:
>
> Oh we could SEE it; it was NOTICING it that was our fault. An EOF is shown
> as a left-arrow which looks very much like a RETURN (broken left-arrow)
and
> we just didn't snap.
>
> Then, once we did find the EOF, getting rid of the son-of-a-XXXXX required
> jumping through several hoops.
>
> Anyway, this exercise illustrates the maxim: "If you stare at something
more
> than five minutes, the problem is either trivial to solve or nigh-on
> impossible."
>
>
| |
| JerryMouse 2004-09-09, 8:55 pm |
| Robert Wagner wrote:
> On Thu, 9 Sep 2004 09:47:42 -0500, "JerryMouse" <nospam@bisusa.com>
> wrote:
>
>
> Why couldn't you run a hex editor and overtype it?
Because it's part of a 7 meg project file - there's no separate source code
file (except copy books).
The hoops through which we had to jump weren't too bad: couple of
copy/pastes, a delete or two.
| |
| E P Chandler 2004-09-09, 8:55 pm |
| "Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN3cRVn-oQ@giganews.com>...
> To find a cntl/z, just "TYPE" the file.
>
> It will stop at the cntl/z.
>
> This still begs your original question though -
> If you go to the trouble of "type"ing your file,
> you already know that it has a cnlt/z in it.
>
> "JerryMouse" <nospam@bisusa.com> wrote in message
> news:5vGdncb6s4iS8N3cRVn-pA@giganews.com...
[color=darkred]
Two good candidates for removing embedded EOF marks (control-z) or
other unwanted characters from files under Win32 are
1) Unix "tr" - a GNU port can be found at
http://unxutils.sourceforge.net/
eg
tr -d \032 <foo.txt >foo.new
Note that \032 is *octal*.
2) gsar - a dos global search and replace utility - even though it is
restricted to 8.3 filenames, it will handle a group of long file names
via wildcards. gsar110.zip can be found on any one of the SimTel or
Garbo mirrors or through a google search.
eg
gsar -s:x1a -r -o *.cob
Note that :x1a is *hex* and -r means replace with noting, ie delete.
-o is overwrite in place.
3) I've written a debug script (as part of a set of utilities) which
generates a filter program that strips out all control-z characters.
It makes dos calls but since it uses input and output redirection it
will handle long file names. Feel free to e-mail me if interested.
| |
| docdwarf@panix.com 2004-09-09, 8:55 pm |
| In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
E P Chandler <epc8@juno.com> wrote:
>"Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN3cRVn-oQ@giganews.com>...
>
>
>
>
>Two good candidates for removing embedded EOF marks (control-z) or
>other unwanted characters from files under Win32 are
>
>1) Unix "tr" - a GNU port can be found at
>http://unxutils.sourceforge.net/
>eg
> tr -d \032 <foo.txt >foo.new
>
>Note that \032 is *octal*.
A 'good candidate' requires the use of *octal*? (emphasis original)
DD
| |
|
| docdwarf@panix.com wrote:
> In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
> E P Chandler <epc8@juno.com> wrote:
>
>
> A 'good candidate' requires the use of *octal*? (emphasis original)
Some would say it's half as good as hex...
(but yes, a *nix command line tool sounds like just the ticket in this
case... it can even be scripted, so you can keep 'em out.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| E P Chandler 2004-09-10, 3:55 am |
| docdwarf@panix.com wrote in message news:<chqmnc$f2c$1@panix5.panix.com>...
> In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
> E P Chandler <epc8@juno.com> wrote:
>
>
>
> A 'good candidate' requires the use of *octal*? (emphasis original)
>
> DD
It's true that octal is a quirky Unix relic. (Perhaps someone has been
reading too many _dumps_?) However, gsar does accept 3 digit decimal
numbers as parameters:
gsar -s:026 -r -o *.cob
My concern was to find programs that are well known and that actually
handle files containing the MS-DOS EOF mark. (Reading redirected
standard input as binary rather than as a text stream is often a
problem on MS-DOS/Windows.) As obscure as Unix arcana is, I still
prefer it to JCL <grin>.
| |
| docdwarf@panix.com 2004-09-10, 8:55 am |
| In article <7f64e2ff.0409091941.1f45fe51@posting.google.com>,
E P Chandler <epc8@juno.com> wrote:
>docdwarf@panix.com wrote in message news:<chqmnc$f2c$1@panix5.panix.com>...
[snip]
[color=darkred]
>
>It's true that octal is a quirky Unix relic. (Perhaps someone has been
>reading too many _dumps_?) However, gsar does accept 3 digit decimal
>numbers as parameters:
>
>gsar -s:026 -r -o *.cob
O frabjous day! Shall I alert the wire services?
>
>My concern was to find programs that are well known and that actually
>handle files containing the MS-DOS EOF mark.
Ahhhhh... but it seemed that your use of 'good' was an aesthetic
evaluation, not a utilitarian one. My apologies if I misinterpreted your
intent.
>(Reading redirected
>standard input as binary rather than as a text stream is often a
>problem on MS-DOS/Windows.) As obscure as Unix arcana is, I still
>prefer it to JCL <grin>.
I wonder if anyone has ever generated a programming language and named it
'Hobson'.
DD
| |
| JerryMouse 2004-09-12, 3:55 pm |
| Russell Styles wrote:
> Some editors will allow you to see this sort of thing.
>
> EDLIN was one - it required an option that I forget right now.
>
> Of course, who has EDLIN on their pc these days.
Oh we could SEE it; it was NOTICING it that was our fault. An EOF is shown
as a left-arrow which looks very much like a RETURN (broken left-arrow) and
we just didn't snap.
Then, once we did find the EOF, getting rid of the son-of-a-XXXXX required
jumping through several hoops.
Anyway, this exercise illustrates the maxim: "If you stare at something more
than five minutes, the problem is either trivial to solve or nigh-on
impossible."
| |
| JerryMouse 2004-09-12, 3:55 pm |
| Robert Wagner wrote:
> On Thu, 9 Sep 2004 09:47:42 -0500, "JerryMouse" <nospam@bisusa.com>
> wrote:
>
>
> Why couldn't you run a hex editor and overtype it?
Because it's part of a 7 meg project file - there's no separate source code
file (except copy books).
The hoops through which we had to jump weren't too bad: couple of
copy/pastes, a delete or two.
| |
| E P Chandler 2004-09-12, 3:55 pm |
| "Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN3cRVn-oQ@giganews.com>...
> To find a cntl/z, just "TYPE" the file.
>
> It will stop at the cntl/z.
>
> This still begs your original question though -
> If you go to the trouble of "type"ing your file,
> you already know that it has a cnlt/z in it.
>
> "JerryMouse" <nospam@bisusa.com> wrote in message
> news:5vGdncb6s4iS8N3cRVn-pA@giganews.com...
[color=darkred]
Two good candidates for removing embedded EOF marks (control-z) or
other unwanted characters from files under Win32 are
1) Unix "tr" - a GNU port can be found at
http://unxutils.sourceforge.net/
eg
tr -d \032 <foo.txt >foo.new
Note that \032 is *octal*.
2) gsar - a dos global search and replace utility - even though it is
restricted to 8.3 filenames, it will handle a group of long file names
via wildcards. gsar110.zip can be found on any one of the SimTel or
Garbo mirrors or through a google search.
eg
gsar -s:x1a -r -o *.cob
Note that :x1a is *hex* and -r means replace with noting, ie delete.
-o is overwrite in place.
3) I've written a debug script (as part of a set of utilities) which
generates a filter program that strips out all control-z characters.
It makes dos calls but since it uses input and output redirection it
will handle long file names. Feel free to e-mail me if interested.
| |
| docdwarf@panix.com 2004-09-12, 3:55 pm |
| In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
E P Chandler <epc8@juno.com> wrote:
>"Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN3cRVn-oQ@giganews.com>...
>
>
>
>
>Two good candidates for removing embedded EOF marks (control-z) or
>other unwanted characters from files under Win32 are
>
>1) Unix "tr" - a GNU port can be found at
>http://unxutils.sourceforge.net/
>eg
> tr -d \032 <foo.txt >foo.new
>
>Note that \032 is *octal*.
A 'good candidate' requires the use of *octal*? (emphasis original)
DD
| |
| E P Chandler 2004-09-12, 3:55 pm |
| docdwarf@panix.com wrote in message news:<chqmnc$f2c$1@panix5.panix.com>...
> In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
> E P Chandler <epc8@juno.com> wrote:
>
>
>
> A 'good candidate' requires the use of *octal*? (emphasis original)
>
> DD
It's true that octal is a quirky Unix relic. (Perhaps someone has been
reading too many _dumps_?) However, gsar does accept 3 digit decimal
numbers as parameters:
gsar -s:026 -r -o *.cob
My concern was to find programs that are well known and that actually
handle files containing the MS-DOS EOF mark. (Reading redirected
standard input as binary rather than as a text stream is often a
problem on MS-DOS/Windows.) As obscure as Unix arcana is, I still
prefer it to JCL <grin>.
| |
| Robert Wagner 2004-09-13, 3:55 pm |
| On Thu, 9 Sep 2004 09:47:42 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:
>Then, once we did find the EOF, getting rid of the son-of-a-XXXXX required
>jumping through several hoops.
Why couldn't you run a hex editor and overtype it?
| |
| Russell Styles 2004-09-13, 3:55 pm |
| Some editors will allow you to see this sort of thing.
EDLIN was one - it required an option that I forget right now.
Of course, who has EDLIN on their pc these days.
"JerryMouse" <nospam@bisusa.com> wrote in message
news:HeudnRQXwZoIt6LcRVn-sA@giganews.com...
> Plagued with an intractable error message at the start of debugging "...
> error in xxxxx.SVD....," and having exhausted all known "fondle-it-until
it
> works" techniques, we girded our loins, went not into our wives this
night,
> and started tearing the son-of-a-XXXXX apart.
>
> Found it!
>
> Before I tell you what the problem was, I've got to tell you there was
much
> dancing in the street. The vino flowed freely. There was joy throughout
the
> land! Now I'm going to share with you the disease that generated the above
> symptom. Wait for it now....
>
> A superfluous end-of-file smack in the middle of Working-Storage.
>
> This particular EOF was possibly sucked in with a defective #INCLUDE
> copy-book, but however the EOF got there it the hell out of the
> debugger.*
>
> Further, the miscreant EOF could not be removed or painted over! It clung
> like a barnacle and nothing would dislodge the sucker - normal editing
> procedures simply skipped over the damned thing (you evidently can't get
rid
> of a hole by digging it out).
>
> The fix was to cut all above this errant EOF, pasting same into a dummy
> procedure division area, doing the same with the area following the
culprit.
> Then delete the Working-Storage module, followed by re-creating same with
> the stuff formerly saved in a holding area.
>
> I apologize for being so effusive on this matter, but this particular
puddle
> has occupied the time of one programmer, off and on, for over three ws.
>
> Such a relief. I'm going to go have a lie down.
>
> ----
> *One of our failed attempts at a solution involved ditching all the
> #INCLUDEs and replacing them with the original copy-book texts. This
failed,
> no doubt, because the copy-book had the extra EOF or the extra EOF was
> already firmly ensconced in the PC code.
>
>
>
| |
| E P Chandler 2004-09-15, 3:55 pm |
| docdwarf@panix.com wrote in message news:<chqmnc$f2c$1@panix5.panix.com>...
> In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
> E P Chandler <epc8@juno.com> wrote:
>
>
>
> A 'good candidate' requires the use of *octal*? (emphasis original)
>
> DD
It's true that octal is a quirky Unix relic. (Perhaps someone has been
reading too many _dumps_?) However, gsar does accept 3 digit decimal
numbers as parameters:
gsar -s:026 -r -o *.cob
My concern was to find programs that are well known and that actually
handle files containing the MS-DOS EOF mark. (Reading redirected
standard input as binary rather than as a text stream is often a
problem on MS-DOS/Windows.) As obscure as Unix arcana is, I still
prefer it to JCL <grin>.
| |
| E P Chandler 2004-09-16, 3:55 pm |
| "Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN3cRVn-oQ@giganews.com>...
> To find a cntl/z, just "TYPE" the file.
>
> It will stop at the cntl/z.
>
> This still begs your original question though -
> If you go to the trouble of "type"ing your file,
> you already know that it has a cnlt/z in it.
>
> "JerryMouse" <nospam@bisusa.com> wrote in message
> news:5vGdncb6s4iS8N3cRVn-pA@giganews.com...
[color=darkred]
Two good candidates for removing embedded EOF marks (control-z) or
other unwanted characters from files under Win32 are
1) Unix "tr" - a GNU port can be found at
http://unxutils.sourceforge.net/
eg
tr -d \032 <foo.txt >foo.new
Note that \032 is *octal*.
2) gsar - a dos global search and replace utility - even though it is
restricted to 8.3 filenames, it will handle a group of long file names
via wildcards. gsar110.zip can be found on any one of the SimTel or
Garbo mirrors or through a google search.
eg
gsar -s:x1a -r -o *.cob
Note that :x1a is *hex* and -r means replace with noting, ie delete.
-o is overwrite in place.
3) I've written a debug script (as part of a set of utilities) which
generates a filter program that strips out all control-z characters.
It makes dos calls but since it uses input and output redirection it
will handle long file names. Feel free to e-mail me if interested.
| |
|
| docdwarf@panix.com wrote:
> In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
> E P Chandler <epc8@juno.com> wrote:
>
>
> A 'good candidate' requires the use of *octal*? (emphasis original)
Some would say it's half as good as hex...
(but yes, a *nix command line tool sounds like just the ticket in this
case... it can even be scripted, so you can keep 'em out.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|