>
> Hi KO
>
> I am working with Rob to see when this happens. Right now he can't
> tell me if it is happening during the save or when he tries to execute
> his REXX command.
>
> David
>

KO

I received this from Rob.

I have tried to recreate the problem again this afternoon. First I did
the usual cycle: edit rexx script - save it - type it - execute it -
type it - etc. (the type command is executed in another commandline
session).
After about half an hour I got a hit. I'm afraid my routine became too
much of a reflex and I'm not 100% sure if it happened after the save
of after the execute.... I thought it was after the save. Chkdsk
recovered 1 file of which the contents (first part at least) was
identical to what was successfully typed last. I may have to repeat
this exercise. And to be sure it is not Fat32.ifs I may have to repeat
it on a HPFS or JFS volume too! .....argggghhhhh.

Then I thought of a variant: I made a Rexx script on a JFS volume for
this cycle. This script works as follows: it creates a Rexx script on
a FAT32 volume - types it - executes it - checks for returncode -
types it - erases it - etc. I started it before dinner, and when I
came back it had run for 4500 cycles without a problem. So it looks
like Rexx is not causing the corruption, consequently it is probably
the T editor.

I may use a slightly modified version of this script and involve the
T-editor in stead of letting Rexx create a script file.

(to be continued!)

Regards, Rob.