PowerCOBOL Hint. Hell, REVELATION!

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.

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

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

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?

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

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.

"Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouADN
3cRVn-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...
 

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.

In article <7f64e2ff.0409091438.29df59ba@posting.google.com>,
E P Chandler <epc8@juno.com> wrote:
>"Russell Styles" <rws0203@comcast.net> wrote in message news:<nbudnZmLCouAD
N3cRVn-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++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

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