Special characters in mainframe filenames

[misi01]

Working in Sweden, it's inevitable that mainframe filenames can have special Swedish characters in their names . For example, W06MÅ006 where MÅ (characters 4 & 5) are short for Månad with is month.

I'm sure I reported this some time ago and at the time the reply was "that's the way things work at the moment". Fair enough. Now I'm on 3.2.3, build 13046 and am still seeing the following screen capture.

Can we hope for a fix some time in the reasonably near future ?

[Zoë]

Go into your FTP Profile (Tools->FTP Profiles) and change the Server->Encoding option on the "General" tab. "ANSI" and "UTF-8" are the best options, but if your server is returning something else you'll need to change to it explicitly.

My guess is "28591 ISO 8859-1". Other likely candidates are "1252 ANSI Latin 1", "850 OEM Latin 1", or "20107 IA5 Swedish".

Past that, this is a limitation of older FTP servers, so no, we can't "fix" it. If you want BC to handle the server automatically contact your vendor and ask them to support the UTF-8 Option for FTP draft spec.

[misi01]

Thanks Craig

850 OEM Latin 1 did the trick

[misi01]

almost ....

I've just discovered another problem with special characters. I refer to the problem I'm having in http://www.scootersoftware.com/vbull...ead.php?t=7212. In this case, I'm not the only one having the problem.

I have defined an exit conversion routine to kick in for a specific file format. This isn't a problem as long the mainframe PDS members don't contain special characters (the conversion program runs to completion as expected).

However, if the member contains a special character, those characters are shown in the list of members/files, but as soon as I select any member with the special character, I get a message on the next panel of

Invalid data set name "A73X#007" Use MVS Dsname conventions

(where # is a square "box" and should be the character Å) and I never even enter my conversion program

[Zoë]

Unless your conversion program runs on the mainframe I don't think it's related. I'm guessing it will give the same error regardless of file format you're using.

I don't think I can diagnose this any further without logs. In the Tweaks dialog (Ctrl+Shift+T) turn on "Include debug messages in log" on the "Folder Views" tab, then connect to the FTP server and try to download a file. Either post that here or email it to [email protected] with a link back to this thread. I'd suggest trying another FTP client too, but I couldn't find a single one that supported OEM 850.

If you're feeling really ambitious Wireshark logs would show the raw bytes, so they would be better, but I remember it being fairly complicated to set up.

[misi01]

Tried doing that

and ran into a couple of problems.

First of all, tweaking "Include debug messages in log" from the main BC panel resulted in BC hanging after entering my password (removing this tweak and running again produced the the expected results - with or without a name filter). The red crossed circle flashed a long time, but I assume that's BC possibly writing the log (I aborted BC after a long while on the assumption it'd hung)

I then removed the logging until I'd received the list of members that were failing. I then turned on logging via C+S+T and selected one member from only one side. Received the message Invalid data set name "A73X#007" Use MVS Dsname conventions.

Question is - where is a possible log file created/written ?

[Zoë]

By default it isn't written anywhere. You can right click on it to save it to a file or copy it to the clipboard.

I don't know why that would have caused a hang, but I really need the initial directory listing too. Try logging in, turning on the logging, then doing a fast refresh (F5) before trying to open the file.

[misi01]

I have a suspicion we're going to go back and forth on this one

I'll send the log file to you offline. Basically, I started BC with a folder compare and received (correctly) a list of mainframe PDS members where soe of the members contained the character Å.

I then selected one of them and received the error message mentioned above.
Is this description and the log file what you're after ????

[misi01]

Update on this

To begin with, support started by saying that the fault was in BC. Then they tried to prove this by getting me to FTP to the mainframe using IBM's Host on-demand whereupon that fell flat on its face as well. Hmmm - egg on their faces - it was nothing to do with BC.

Long and the short of it. The changes they made were as follows (hope I get this right)

From support

The changes made for the FTP-servers were for the parameters in the server's FTPDATA dataset:

CCXLATE ISO8859N - a table that converts between iso8859-1 and IBM-278, with regard to the ftp-control-session.
SBDATACONN (IBM-278,iso8859-1) - same conversion parms for the ftp-data-session.

The last parm can be changed by the client using the SITE command whereas the CCXLATE option can't be changed by the client

Now to something worse.

After the changes above, everything was working fine, I could see the Swedish characters ÅÄÖ in filenames, and I could also open them.

Then I updated to the latest build (13298). Now, specifying any filenames on the mainframe results in the following log messages (where the values after MDTM are the members in the mainframe PDS (and this is indenpendent of whether the filenames contain ÅÄÖ)

2011-02-08 14:48:46 Sent> MDTM FETCHOLD
2011-02-08 14:48:46 Recv> 501 command aborted -- FTP server not configured for MDTM
2011-02-08 14:48:46 Sent> MDTM GTDB2DRV
2011-02-08 14:48:46 Recv> 501 command aborted -- FTP server not configured for MDTM
2011-02-08 14:48:46 Sent> MDTM GTFILDRV
2011-02-08 14:48:46 Recv> 501 command aborted -- FTP server not configured for MDTM
2011-02-08 14:48:46 Sent> MDTM KEMI2420
2011-02-08 14:48:46 Recv> 501 command aborted -- FTP server not configured for MDTM

Back off on the MDTM problem above for the time being. I'm making the same mistake as support. Tried connecting via IBM's on-demand myself - miserable failure

[Zoë]

I forgot to update the "Notable Changes" bit in the changelog, but 3.2.4 improved support for auto-detecting the server timezone, and this is a side effect of that. It should have stopped after the first failure, and I'll fix that for the next release. Aside from the fact that the excess commands will slow down the connection it won't actually cause any problems. You can disable it by changing your FTP Profile's "Time zone" setting; you'll probably need "(UTC) Coordinated Universal Time", though your local timezone is a possibility too.

[misi01]

Thanks Craig

Changing to UTC did the trick