Why?

[Kenneth Brody]

George Simon wrote:
> 
> As I said, I'll help in anyway I _can_, but that excludes sending fp support
> the files.  I _can't_ do that.
> I've explained why to Ken.  His response to me was to do something that
> would take me days to do (if I understood him correctly) and I do not have
> the time right now.
> You are right, though, I've already spent so much time on this that I'd hate
> to see it go to waste.
[...]

Well, the question comes down to "how much can we eliminate from the
testbed while still causing the crash and not violating any NDAs?"

Does it crash on the first output record?

Your command line shows you running sort/select processing.  If you
replace it with:

      If:  @RN = "nnnn"  ' nnnn == the record that crashes
    Then:  select

Does it still crash?

You say that it crashes when called from automatic, so can you eliminate
the output processing, which will not yet have been executed for this
record, and have it still crash?

If you can eliminate these processing tables, then there are only two
left -- automatic and the called table.  If you cannot eliminate them,
then obviously you'll need to keep one or both of them.

How many lookups are in the processing tables that are left?

My suggestion was to replace all of the lookups here with lookups that
use R=("1") rather than whatever you're currently using.

Does it still crash?

If we've gotten this far, then all you need is a very minimal set of
files to send -- the main file map, output format, the processing tables
that are actually still being used, and a 1-record key file, plus the
maps and 1-record keys for any lookups.

Of course, at some point in the above sequence, you may not be able to
get the crash anymore, in which case some other plan of attack may be
needed to continue eliminating NDA-covered stuff that may remain.

You say the entire file set takes 600MB.  Does it really need that much
data to duplicate the crash?

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody at spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+