We have communication scripts that open a file containing an
up/download path for our application.
Our script opens the file, reads in the path (which always has an
'\' at the end)into a string, concatenates this path string to a
filename to create a complete path-and-file-name string.
This complete filename is then used in XMODEM sendfile or getfile
statement.
While testing our scripts, I would (out of habit) use the msdos editor
edit.exe to create this file containing the path, and the scripts
worked perfectly!
Another group was reponsible for installing the application and the
scripts at a client site. When they created the file that was
to contain the up/download path, they used NOTEPAD.EXE.
What they didn't know was that NOTEPAD.EXE would add a second line
to the file, and this line contained a black square (garbage character).
We think it is a NULL character.
When our script opened the file (hoping to find ONE line of data) before
the EOF, it found the GOOD first line, it wasn't EOF, so it read
the next line which contained the garbage, and then after found the EOF.
Our script concatenated garbage (NULL) with a valid filename. When
XMODEM got this sucker, it went looking for "DTI.TRN" in the same
directory as the scripts which were in c:\pcplus\aspect. There
was no such file there, so Procomm checked in
c:\pcplus\upload\ for DTI.TRN. When it didn't find it, the upload
terminated with an error.
Had edit.exe been used to create the file, the extra black square
NULL character wouldn't have been there and communication would've
succeeded.
I hope this helps someone out there!!
Dominique
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.