I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

Previously I didn't actually try to GET something with FtpWorkFromCwd=on. It turns out this fails.

Attached is a log using the development version. At the end, when I try the GET, it tries to do CWD ''PEW3H.MMM.IMSLIB'', which fails with server error 501 A qualifier in "'PEW3H.MMM.IMSLIB'" begins with an invalid character. The correct syntax is CWD 'PEW3H.MMM.IMSLIB', as is done earlier.

Thanks, will test it. And I'd better test accessing the HFS/zFS filesystem in the same session.

Thanks for your feedback.
The next version of WinSCP will automatically employ the compatibility mode, when connected to MVS systems.
Issue 2069 – Improve compatibility with MVS systems

I've also fixed the stray warning:
Issue 2070 – Misplaced warning about unused scripting parameters when /rawsettings command-line switch is used

I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

Sorry, as a programmer I would normally think of a scripting mode as not necessarily the same syntax. Kind of like using the macOS terminal to do file operations vs. an AppleScript: you can do some of the same things but it isn't the same syntax.

Anyway... using the -rawsettings FtpWorkFromCwd=on setting, directory traversal works as expected. Attached is a log.

I'm not sure what you mean by "command-line FTP", in contrast to "scripting". I believe we talk about the same thing.

Is this what you want?

Or if you want to stick with your deprecated syntax:

results in

Note: I'm not trying to use scripting. I'm trying to use command-line FTP.

Ok, first the error message is misleading. I'll look into that.

But indeed, it should be FtpWorkFromCwd, my mistake.

But in any case, recommended way to open a session in scripting is using open command.

How do you set WorkFromCwd in a command-line session?

I tried

and

but in both cases it gave error

Scripting does not use standalone parameters. The parameters you have specified on command-line will not be used. Your command-line syntax is probably wrong.

WinSCP has a compatibility mode, which is automatically used for VMS system, which might help even here. Can you please test it? To manually enable the mode add FtpWorkFromCwd=on:
https://winscp.net/eng/docs/rawsettings
https://winscp.net/eng/docs/ui_login_raw

Please post a new log file with the mode on, no matter is it helps or not.

WinSCP version: 5.19.6
Windows version: Windows 10 Enterprise 20H2
Transfer protocol: FTP

When I first started trying to use WinSCP to access a z/OS FTP server (MVS side), I was getting baffling results. At first it seemed to work, but when I tried the same server again later, I couldn't get it to read directories. It kept saying "No such file or directory" even for directories that existed. The same command sequence that worked the first time would fail the second time.

If I switched to a different server name, it would work at first but then start failing again. And, it would work if I tried it with completely different directories, at first, but then they too would be become poisoned.

I finally realized that if I manually deleted the registry entries where WinSCP was caching directories, the problem would be fixed, temporarily.

Attached is a log of an attempt to recreate this issue. I'm trying a number of things until I finally figured it out, including switching from the MVS side to the z/OS Unix side.

What I think the problem is this:

• The first time you enter a CD command, it issues the CWD command exactly as the user enters it. This works.
  
• If WinSCP has cached the directory, then when you later enter the same CD command, WinSCP doesn't do the CWD as the user entered it. Instead, it submits it Unix-style, with a preceding slash. This is not valid syntax, so it fails.
  
• And then it might be caching that it failed. I'm not sure about that part.

First, an explanation of the FTP server syntax when accessing MVS (not Unix) files. When you enter CD directory, the directory can be either by itself or enclosed in single quotes.

If you enter the directory unquoted, it means that it is appended to the current working directory, i.e. it goes down one level.

If you enter the directory quoted, then it means that it overrides the current working directory. On a Unix system it would be equivalent to entering /directory.

In the log, my working directory always starts as TTPJMSS. There also exists a data set PECML.I1R00.LANLOAD.D220320, so I can navigate down that path: start at 'PECML', then cd I1R00, cd LANLOAD, etc.

In the log this works at first. But notice what happened at the end of the log: I entered cd 'pecml', but the command generated was CWD /'PECML.'. This is not valid on the MVS side.

Note: When I talk about MVS vs Unix side, I'm being inaccurate. Really it is that there are two file systems on the server, with different naming syntax. So I can connect with FTP to the z/OS system, and access an MVS data set PECML.I1R00.LANLOAD, but also access in the same session a Unix directory /u/ttpjmss. In the log when I FTP to the server it sets the working directory to the MVS data set node TTPJMSS, but when I don't enter the protocol then it defaults the working directory to /u/ttpjmss.

The point here is that you can't mix and match the syntax. A file in the Unix file system is a strict Unix style naming, e.g. /dir1/dir2/etc. A file in the MVS file system will never have a /, that's not a valid character in the directory & file names.

So what needs to be cached and re-entered as commands is how the server returns back the PWD results. A result like would mean that the path 'PECML' > I1R00 > LANLOAD is valid, but it would have to be CWD'd later enclosed in single quotes, no slash.