It's all about the answers!

Ask a question

Why do source files appear to be corrupted in local sandbox workspace?

Frank Myers (291922) | asked Feb 08 '13, 10:48 a.m.
edited Feb 08 '13, 10:59 a.m.

We ran zimport with code page set to 1047(Latin 1).
We load the local workspace, and then open BOTH the file (from RTC) AND the local file loaded into the sandbox workspace.
In the RTC file, we see: if arg2 ¬= '' then do;
In the local file, we see: if arg2 ¬= '' then do;

It Looks like a garbage character was inserted into the local file as part of loading it from the RTC repository into the local sandbox, but when I open local the file outside of RTC (using VI or GEDIT), the garbage character is not there. So the editor invoked by RTC "Open Local File" displays garbage characters...

Anyone have an idea why?

The default editor used by RTC appears to be LPEX. Is there a way to use some other editor?


Ralph Schoon commented Feb 08 '13, 12:00 p.m. | edited Feb 08 '13, 12:00 p.m.

Did you check the encoding of the file before importing it?

You can right click on the file in Eclipse and in the context menu to open with another editor.

You can go to Window>Preferences>General>Editors and change file associations.

Can you check the encoding that the file uses in GEDIT?

Frank Myers commented Feb 08 '13, 1:05 p.m.


The context menu under "repository files" allows "Open File" and "Open Local File". There is no selection that allows opening with another editor in that context menu.

I changed the default editor from LPEX to the PL/I editor, and also tried the "TEXT" editor. The same problem occurs.

So I added gedit as an external editor. I reopened the local file, and no garbage characters.

It's almost like any eclipse based editor inserts garbage, but External editors do not seem to have this problem.

Ralph Schoon commented Feb 08 '13, 1:15 p.m.

You need to load the file on disk and then you can use different editors.
I had a similar situation once and I settled to load the files in question, open them outside of eclipse, fix the encoding (and line ending), save,refresh in Eclipse and then deliver the changes.

I another situation I had to switch the default encoding to UTF-8 in the preferences.

Frank Myers commented Feb 08 '13, 1:37 p.m.


The files are loaded to disk as part of loading the sandbox repository. It's not an encoding issue. The local file is fine. The Eclipse based editors display an additional garbage character preceeding the PL/I "not sign", but the non-eclipse editor do not. No characters are mistranslated. Translation is usually 1 to 1. The problem is that the eclipse editors add a garbage character.

Ralph Schoon commented Feb 08 '13, 1:43 p.m. | edited Feb 08 '13, 1:44 p.m.

Frank, missed you where working on i/z. Thought zimport was a typo. Sorry.

One answer

permanent link
John Riendeau (46626) | answered Feb 08 '13, 1:24 p.m.
From the comment above:
It's almost like any eclipse based editor inserts garbage, but External editors do not seem to have this problem.
An alternative explanation would be that there's actually an incorrect character in the file, placed there during the zimport, and that the Eclipse-based editors are showing it, while the external editors are hiding it.  You could try opening up the local file in a hex editor to see what bytes are actually there.

One thing that makes me suspect that there might truly be incorrect contents in the repo (and thus in your local file after a load) is that the ¬ character is one of those problematic ones that maps to different code points in common EBCDIC encodings (square brackets are others that commonly lead to issues): in 1047, it's 0xB0, while in 037, it's 0x5F.  If you ran the import with an encoding of 1047, but the bytes in the data set member were actually in 037, you'd get incorrect contents in the repo (though since most of 1047 and 037 are the same, most of the file would appear okay).  If you use the ISPF editor, open the original data set member that was zimported, and turn hex mode on, what bytes show up under the ¬ character?

Frank Myers commented Feb 08 '13, 1:47 p.m. | edited Feb 08 '13, 1:59 p.m.


When I used VI as an external editor, it did not show any garbage in the local file. Just the correct text. VI will display almost anything. I also used a command line tool to dump the file in octal. Again, the garbage character is not there.

The garbage character is inserted by the eclipse editors. The ¬ character is always there and displayed correctly regardless of the editor used. So it is not mistranslated.

The garbage character is inserted by the eclipse based editors immediately preceding the ¬ character (not replacing it). 

John Riendeau commented Feb 08 '13, 1:56 p.m.

Okay, thanks for the added info.  The next thing I'd check is the file's encoding settings in Eclipse, like Ralph mentions in one of his comments above.  Right-click on the file, select "Properties" and see what's listed in the "text file encoding" section on the Resource tab of the properties page.

I was actually able to reproduce your exact issue (with a  appearing before the
¬) by doing the following:

  • With Eclipse's text file encoding set to UTF-8, open a file, insert the ¬ character, save the file, and close.
  • Modify the file's encoding to ISO-8859-1 and re-open in the Eclipse editor.
  • I now see the garbage  character before the ¬.
The zimport tool converts from EBCDIC to UTF-8, so if your Eclipse workbench is configured to use a default text encoding other than UTF-8, you could see behavior like this.

Frank Myers commented Feb 08 '13, 2:04 p.m. | edited Feb 08 '13, 2:06 p.m.

The ISPF RTC Client does not show the garbage character. Only the original source: if arg2 ¬= '' then do;
Others on our team see the same garbage character results when using Eclipse/RTC, and no garbage character (the correct source) when using a non-eclipse editor to view the sandbox (loaded local) files.

John Riendeau commented Feb 10 '13, 11:54 a.m.

One additional comment -- if it turns out that this issue is caused by the text file encoding setting in Eclipse (see my previous comment), there's an enhancement that went into 4.0.3 that causes zimport to set a project-level encoding of UTF-8 on any Eclipse project it creates, so you shouldn't experience issues like this in the future, even if your Eclipse workbench's encoding setting isn't UTF-8.

Your answer

Register or to post your answer.