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.

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)


Topic review


Unable to delete Mainframe Datasets

this doesn't help, because we can't access the Mainframe Filesystem from our ssh daemon (so neither SFTP nor SCP would be of any help).

It seems that, sadly, WINSCP is not for us...

Unable to delete Mainframe Datasets

while trying to use WinScp to not only read (which works), but also to delete mainframe datasets (we're using z/OS here, IBM's mostly used OS), we run into problems because of the way WinScp deals with z/OS's dataset names.
Nb.: when I switch to Unix System Services (a Unix personality within IBM's z/OS featuring bsd-style file lists) everything works as it should...
z/OS datasets don't have a folder concept, instead they use so-called qualifiers (which are chunks of text from 1 Byte to max. 8 bytes, separated by '.', up to 44 Bytes in length).
For instance:
is a valid data set name comprised of 3 qualifiers.
A typical Session would consist of, eg., commands like
cd 'USER01'
(WinScp answers with /'USER01', which may already be an indicator of the problem, because the '/' should not be assumed in this environment.)
If the dataset list would show something like
---------- 0 100 Aug 5 2019 DEL02
---------- 0 100 Aug 5 2019 DEL03
(which is an actual example, at least in part, what the dataset list would look like, either from CLI or GUI) an attempt to delete one of these datasets would result in:
Error deleting file 'DEL02'.
Command DELE fails: /'USER01.'/DEL02 does not exist.
And there you have it. While reading (get) works fine under the exact same circumstances, deleting fails as shown - meaning: the way datasets are processed seems to depend on the operation. We need a fix for that, please.

Still there's one more detail to consider:
When referencing a z/OS dataset there's a little quirk in z/OS's user interface (TSO).
The first qualifier has a special meaning, because it establishes the 'ownership' of the dataset - that's why, from a user perspective, the first qualifier is often, but not always(!), assumed to be the userid. Thus, to reduce the need to type it every time, TSO inserts the userid as an additional qualifier - meaning: if the userid is USER01 and I reference the dataset from the example above as it is written, TSO assumes that it should put the userid (or, to be precise, a PREFIX stored in the USERID's profile, which defaults to the USERID) as first qualifier before that, resulting in the dataset name being processed as
USER01.AGMV800.ZRK.DEL03 (or rather, 'USER01.AGMV800.ZRK.DEL03', see below)
To prevent that from happening I need to specifiy the dataset in single quotes like this:
'AGMV800.ZRK.DEL03'. Whether this quirk would apply to an ftp or ftps session opened via WinScp us unclear as of now but should be taken into consideration when addressing any data set.