Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: OpenVMS to Windows Transfer stripping carriage returns

stevenmcgraw wrote:

I understand that winscp does not support the vms directory structure however as you can see from my previous post the SFTP log in supports it just fine however the FTP gives a completely different structure with no change in settings except moving from SFTP to FTP.

Because SFTP protocol specification mandates that the server have to present the directory structure in Unix-like manner to ease interoperability. FTP does not have such requirement. Though most FTP servers actually do this anyway. Your FTP server does not. I believe there's some command you can use to switch the VMS FTP server to Unix compatibility. But I do not remember what it is.
stevenmcgraw

Re: OpenVMS to Windows Transfer stripping carriage returns

Sir,

Well that is the anomaly in this. The above "log" is from the log in of both SFTP and FTP using the same log-in.
I can access properly from both VMS/FTP and Filezilla. The VMS server allows me to log in using multiple programs on both sides FTP/SFTP using the upibilling login as well as move files accordingly.

True, the Filezilla and WinScp SFTP will not allow me to move the file as it strips out the carriage returns because of the SFTP Binary limitation.

***The issue I have now is still related to the carriage returns being stripped but how is it I can log into the VMS Server as an SFTP client and get a proper directory structure but when I log into the same server via FTP I get a VMS directory structure.

I understand that winscp does not support the vms directory structure however as you can see from my previous post the SFTP log in supports it just fine however the FTP gives a completely different structure with no change in settings except moving from SFTP to FTP.

On a completely side note but related. I have been doing my testing via command line instead of GUI because you usually have to define your connection and initialization criteria through command line and these have been raw setting with out the aid of an INI or script file.

Thoughts?
martin

Re: OpenVMS to Windows Transfer stripping carriage returns

WinSCP does not support VMS-style paths.

So with SFTP is actually not working, even with FileZilla, right?
Guest

Re: OpenVMS to Windows Transfer stripping carriage returns

Of all the things I figured out why it's happening but I do not know how to fix it. The file is on an OPEN VMS server but the file cannot be transferred over via SFTP because it has to be transferred over as an ASCII file. Binary rips the CRLF returns out of the file.

The issue I have is now is that when I log in via SFTP the directory structure works like a charm showing "/root/sub/sub" however when I log in via FTP I get a directory structure that looks like native VMS "root:[sub.sub]" This is preventing me from reading the directory.

Thoughts?

winscp> open sftp://IDXPRD
Searching for host...
Connecting to host...
Authenticating...
Username: upibilling
Password:
Authenticated.
Starting the session...
Reading remote directory...
Session started.
Active session: [1] IDXPRD
winscp> pwd
/IDX19/upibilling
winscp> close
Session 'IDXPRD' closed.
No session.
winscp> open ftp://IDXPRD
Prompting for credentials...
Username: upibilling
Connecting to IDXPRD ...
Connected with IDXPRD. Waiting for welcome message...
Password:
Connected
Starting the session...
Reading remote directory...
Session started.
Active session: [1] IDXPRD
winscp> pwd
IDX19:[UPIBILLING.CLAIMS]
winscp>
stevenmcgraw

Re: OpenVMS to Windows Transfer stripping carriage returns

Sir,

True, I was using Filezilla as FTP with VMS as the server type so I could remove the ";1" from the end of the file at transfer. The server is internal to our network so it would allow this configuration.

I did switch Filezilla to SFTP with auto-detect as the server selection and connected perfectly and still the file transferred over properly though I did have to remove the ";1" extension from the file.

I remember the article you mentioned so I know it transferred in Filezilla as Binary in SFTP. So the question remains that both programs are congruent in basic settings but WinScp will strip the 'lf cr' from the file while Filezilla transfers over properly to windows from VMS with out the removal of 'lf cr' from the file.

As I mentioned earlier I am looking to replace filezilla completely and script everything through WinScp ... this is my only roadblock which is this file.

Thanks,

Steve
martin

Re: OpenVMS to Windows Transfer stripping carriage returns

You are using FTP (not SFTP) protocol with FileZilla. So it's not comparable. Still, I can see you use binary transfer with WinSCP. Chances are that your SFTP server tried to be smart and translates the line endings transparently, despite the binary transfer mode. Try to switch to SFTP protocol in FileZilla to verify.
stevenmcgraw

Re: OpenVMS to Windows Transfer stripping carriage returns

Sir,

Have you found anything out yet? Seems a few people are interested but no feedback from anyone.

Thanks,

Steve
stevenmcgraw

OpenVMS to Windows Transfer stripping carriage returns

Sir,

First thanks for reviewing my post and providing input. Also thank you for the heads up on the ascii / SFTP issue as that has been a question of mine for a while now.

To answer your question I would like to transfer the file intact with the carriage returns in the file "just like Filezilla"

I would much rather use WinScp as it has much greater functionality and the ability to script rather easily.

I have attached a log file from Filezilla doing the same transfers as would have been in WinScp GUI for both a .txt file and a .tra file both the same data content just one I renamed in case the extension was the issue.

I cannot however perform a log function for the OpenVMS server as I do not have CLI access to generate the log file. I would need mumps programmer access and that's only given out to a select few people.

Hope this helps and thanks for the update. I look forward to resolving this issue and breaking away from Filezilla all together in the very near future.
martin

Re: OpenVMS to Windows Transfer stripping carriage returns

I'm not sure what you want WinSCP to do. Do you want it to add the CR to every LF in the file? Or do you want it to transfer the file intact?

I assume the second, i.e. binary mode, because FileZilla does not support ASCII mode with SFTP: https://trac.filezilla-project.org/ticket/868

In binary mode WinSCP does not modify the file in any way. I.e. it behaves identically to FileZilla.

Can you attach a log file from FileZilla?
stevenmcgraw

OpenVMS to Windows Transfer stripping carriage returns

Hello,

Newbie kind of sort of yes I need a little guidance guy here....



I am attempting to script a file movement for a text file with a .tra file extension (requester spec)from an openvms version 8 server to a windows xp sp3 computer using an sftp protocol.

The file has carriage returns in the file that are being removed even before transfer. The files usually start around 31k variable and after download are around 30k variable. If properly downloaded from the server the text would be single lines stacked in line however the text shows as a single line of data.

I initially believed that the issue resided on the openvms server however I have used filezilla and openvms both and they are able to transfer the file with the carriage returns in place.

I have attempted to use both the gui as well as the command line to no avail. I have even went as far as to change the extension of the file name from .tra to .txt and still no carriage returns within the file. I have also attempted to use both ascii as well as binary in both gui and cli also with the same results.

I have attatched a log file for your viewing pleasure and would welcome any feedback.