FTP/s and ASCII transfers

, ,
1

Hi everyone,

We currently have an FTP/s listening port configured in IS 6.5 using SSL certificates.

The connection works fine, except that we’ve noticed that when doing an ASCII push of a file (from the client into IS), IS seems to ignore the fact that an ASCII transfer was requested and doesn’t do any conversion of the file format, as would be expected with an ASCII transfer to other FTP/s servers.

For example, normally a DOS file (carriage return + linefeed) sent from a Windows system to a UNIX system using an ASCII mode transfer, would result in a UNIX formatted file (carriage returns removed) arriving on the UNIX system.

But the same transfer to IS does not do this conversion!

I thought perhaps that IS acts like a Windows service, irrespective of platform, so I also sent a UNIX file in ASCII mode, expecting in this case that the file would arrive in DOS format. But no, again no change in format was made.

It’s basically as if IS always does a BINARY transfer, even if you tell it to specifically use ASCII mode.

Here’s a log from the FTP client end, confirming the ASCII mode being excepted by IS:

STOR 000000000000011383.dos
150 ASCII mode SSL  data connection for 000000000000011383.dos (nn.nn.nn.nn,4511).
Send Buffer size: 65535
226 ASCII transfer complete.
transferred 1090788 bytes in 5.484 seconds, 1553.829 Kbps ( 194.229 Kbps), transfer succeeded.
Transfer request completed with status: Finished

Within IS, DOS and UNIX formats don’t seem to be an issue, but many of our front and back-end systems do need to be in a specific format, usually UNIX, so having IS convert from DOS to UNIX as the files come in would be very useful (and also match how all our other FTP processes work and other integration systems (not wM)).

So just wanting to know is this a bug, by design, or some issue with our local system? (It’s the same on all our installations, three of them).

Any one any thoughts?

The system:[INDENT]OS is AIX 5.3
webMethods Integration Server 6.5 SP2 (build 394)
Java is 1.4.2 (48.0) (the one supplied with IS)
Using a standard ‘webMethods/FTPS’ port configured from the ‘Security > Ports’ page.
[/INDENT]Just in case it makes any difference, we use the FTP put complete Notification method to receive the files:, (‘pub.client.ftp:putCompletedNotification’) and a single trigger to monitor this Notification. The trigger then runs a single generic flow service, that then works out what to do with the files (based on file name/path/sender etc.).

Thanks in advance for any help.

Mark

2

Great info.

This seems like it may be a bug in the FTP listener/handling code. Probably best to open a service request with tech support and provide them with the same information you provide above. They should be able to readily duplicate the issue if it is indeed a bug.