Response to a PWD command from Unisys Libra host is no longer accepted

[andym147]

In 3.1.3 client I can no longer establish a connection with a Unisys Libra host. This used to work on 3.0.9.2. The issue seems to be that the format of the reponse to a PWD command appears no longer to be accepted. The response will be something like

257 "(MOUNTFORD) ON ERSTE" is the current working directory.

A Filezilla trace shows
Trace: ControlSocket.cpp(356): Failed to parse returned path. caller=0p17025c0

and the connection is broken. Trace of an attempt to connect to a host 'ucscahu' shown below.

15:38:15 Status: Resolving address of ucscahu
15:38:15 Status: Connecting to 192.39.46.230:21...
15:38:15 Status: Connection established, waiting for welcome message...
15:38:25 Trace: CFtpControlSocket::OnReceive()
15:38:25 Response: 220 FTP Services for ClearPath MCP: Server version 52.189.8008
15:38:25 Trace: CFtpControlSocket::SendNextCommand()
15:38:25 Command: USER mountford
15:38:25 Trace: CFtpControlSocket::OnReceive()
15:38:25 Response: 331 UserName received; please send the PassWord.
15:38:25 Trace: CFtpControlSocket::SendNextCommand()
15:38:25 Command: PASS ***********
15:38:25 Trace: CFtpControlSocket::OnReceive()
15:38:25 Response: 230 User MOUNTFORD logged in; you may proceed.
15:38:25 Status: Connected
15:38:25 Trace: CFtpControlSocket::ResetOperation(0)
15:38:25 Trace: CControlSocket::ResetOperation(0)
15:38:25 Status: Retrieving directory listing...
15:38:25 Trace: CFtpControlSocket::SendNextCommand()
15:38:25 Trace: CFtpControlSocket::ChangeDirSend()
15:38:25 Command: PWD
15:38:25 Trace: CFtpControlSocket::OnReceive()
15:38:25 Response: 257 "(MOUNTFORD) ON ERSTE" is the current working directory.
15:38:25 Trace: ControlSocket.cpp(356): Failed to parse returned path. caller=0p17025c0
15:38:25 Trace: CFtpControlSocket::ResetOperation(2)
15:38:25 Trace: CControlSocket::ResetOperation(2)
15:38:25 Trace: CFtpControlSocket::ParseSubcommandResult(2)
15:38:25 Trace: CFtpControlSocket::ListSubcommandResult()
15:38:25 Trace: state = 1
15:38:25 Trace: CFtpControlSocket::ResetOperation(2)
15:38:25 Trace: CControlSocket::ResetOperation(2)
15:38:25 Error: Failed to retrieve directory listing

[codesquid]

I don't think I did ever add support for such an exotic path syntax, any support for it in previous versions must have been a bug.

Do you have a BNF grammar explaining this path syntax?

Furthermore, did you consider upgrading to a modern server supporting the TVFS extension?

[andym147]

Replying to codesquid:

I don't think I did ever add support for such an exotic path syntax, any support for it in previous versions must have been a bug.

Do you have a BNF grammar explaining this path syntax?

Furthermore, did you consider upgrading to a modern server supporting the TVFS extension?

If it was a bug, it was a very useful bug :-)
It must have been a fairly recent change that disallowed it.

Unfortunately I don't have a BNF version of the path syntax but I can attach a snapshot from a manual that describes the fundamental elements using railroad diagrams. Trying to implement something to handle it would be w-a-a-y over the top (in my view).

In essence, a path might start with either an * or the usercode in parentheses, followed by up to eleven "nodes" separated by a "/" character, optionally followed by an "ON <familyname>" (where <familyname> identifies one or more disk drives on the server). [This is a very simplified version and purists will quibble with my terminology but I hope it gives you an idea.]

e.g. *MY/DIRECTORY/FILES ON MYPACK

*SIMPLE
(MOUNTFORD)UCF/FILES ON ICE

The one from the failed example was

(MOUNTFORD) ON ERSTE

(Normally the usercode would match the usercode of the FTP session but it isn't a requirement)

[kwikone]

For your info the * is a usercode (Any User - Not usercoded - global user) on a Unisys Libra system (the precursor was the Unisys A-Series, B5000-6000 series mainframes) with the MCP operating system (I spent many years with Burrough/Unisys working on/supporting them). Your response indicating (MOUNTFORD) ON ERSTEE equates exactly to /. And, (MOUNTFORD)UCF/FILES ON ICE equates to /UCF/FILES (the * or (<usercode>) should be dropped). The 'ON' part (volume name) in this case should be considered irrelevant since there is no FTP syntax for changing volumes. Also, when logging in via FTP (or any other method) to this type of mainframe the user has his 'environment space' allocated and is usually on just 1 volume although it is possible to set up a user to have an alternate volume.

[codesquid]

Can you please attach the format in a truly open file format? I have problems opening unethical proprietary file formats like .doc
I tried converting it but it comes out extremely pixelated, I have to guess what the labels say.

[kwikone]

Unisys Libra (MCP) file name syntax railroad diagram in pdf format

[kwikone]

Unisys Libra (MCP) file name syntax railroad diagram in Open Document format

[kwikone]

I almost forgot to mention that the Unisys Libra (MCP) system IS a modern server. It is a mainframe capable of running multiple OS's simultaneously (MCP, Windows, Netware, etc). Also, the MCP OS is an EBCDIC machine so file names conform to the EBCDIC character set.

[andym147]

Many thanks to Kerry for attaching a .PDF version of the filename syntax. I say again that attempting to handle it in full is, in my view, not necessary.

Kerry is also quite correct in saying that a Libra server is a modern server whose precursor systems go back a long way, to the very roots of computing in fact.

I have been trying (with some success) to promote FileZilla as the FTP client of choice for Libra users and would like to carry on doing so.