>>>>Well, I can't offer any specific help, but taking the large view it looks like:
>>>>
>>>>- System was stable for a long time
>>>>- Software and/or configuration haven't changed
>>>>- Hardware hasn't changed
>>>>
>>>>If you're really certain about point #2, then I'd start looking at hardware. Maybe you have a bad network card, hub, etc. Can you swap out components and retry?
>>>
>>>
>>>Hi Al:
>>>
>>>Thanx for your suggestion. Actually, we did configure a completely different PC running on a different node of the network and had the same problems. Obviously, we can't change out components on the HP Unix host or network hubs/routers/etc. so easily or cheaply, and we will really need to come up with a specific suspicion before that would be entertained... Regarding your point #2 - No, I am NOT fully convinced that some configuration hasn't changed outside of the PC workstation itself. We often have network changes being done behind the scenes with no notice to anyone, and Unix box changes without notice to others. But, those guys all claim that no changes connected with our setup have been made. So, whether I believe them or not, I have to proceed on the basis that that is correct info.
>>>
>>>Further to that: We even went back to the current version of source code and re-compiled it, just in case the FXP itself got corrupted. Today we have also had the problem resurface in as little as 2 min. (or as long as over an hour or more) between good and bad transfers, and have had the ability to manually MDELETE files from FTP on the same machine where the problem occurred -- so some of the patterns that we thought were happening yesterday turn out to not be the case. IOW no change in the ability to identify the source of the problem or lack thereof. So, we're still looking at it, and may be forced into making source code changes on the FP side based strictly on a "try-this, hopefully it'll work..." basis -- not what I want to do...
>>>
>>>Anyone else have any ideas?
>>>
>>>TIA
>>>
>>>Rob
>>
>>1. A search on www.novell.com, using the File Finder feature looking for "ftp", brings up a bunch of downloadable files for NW4.x/5. Don't know if they require a Win32 platform, but it might be a good idea to test the process on a Win32 platform anyways.
>>
>>2. Can you set up a looping batch file to see if the problem eventually arises under plain DOS?
>>
>>3. Is there any way to do a MOVE function instead of a COPY followed by delete? I know this can be inherently unsafe but maybe the FTP program has some built-in safeguards i.e. won't delete the source until it has been successfully transferred.
>>
>>4. This may be WAY out in left field, but is there a RENAME function? Just maybe, it acts like the Fox RENAME command, where if you rename to a filename in a different folder, the file is MOVED.
>>
>>5. Are any of the files larger than anything you've ever transferred before? Could there be host-side settings timing out on long transfers? Could the transferred file(s) contain unusual characters like CHR(0)?
>>
>>6. General health of PCs: are temp directories clean, do they have adequate free disk space, etc. Have you run a recent virus scanner? You know, the kind of stuff you smack yourself on the forehead for if you miss it.
>>
>>Good luck.
>
>Hi Al:
>
>More good ideas, but not much we haven't discussed ourselves:
>1. Yup, got a reference to the latest FTP s/w from Novell, and passed it along to our network guys. Don't know if they will try to purchase it or not...
>
>2. We discussed the looping DOS batch file and may try it on a temporary basis, but it eliminates the logging we have set up under FP and makes us even more 'blind' than we are now. This is in the list if we can't come up with anything better...
>
>3. No MOVE function in this bare-bones version of FTP.EXE. Would be nice...
>
>4. There is a RENAME function, but it only works on the same machine where the file resides, so I can't cheat like in FP.
>
>5. These files are all exactly 1590 bytes, far smaller than the largest ones we normally transfer. And the MGET isn't the problem -- its the MDELETE!
>
>6. We did verify all this: Temp directories are empty, 2 GB free disk space on the local PC and 8+ GB on the target server directory, plenty of free RAM prior and after loading FP-DOS. Haven't done a specific virus scan, but this is all inside our firewall and the servers themselves are scanned, so this is not likely. I will pass that suggestion on to the network guys...
>
>I'm on a day off today, so I guess I'll just have to wait until I get back into the office to see what they want to do. Thanx again for your suggestions.
>
>Anyone else have any?
>
>TIA
>
>Rob

Rob,

Only one more SWAG. The file size 1590 bytes rings an extremely faint bell - could that be anything like the default frame size for your network e.g. Ethernet 802.2 or 802.3? Maybe the Novell FTP software has a bug trying to deal with files exactly the size of a frame.