Why do source files appear to be corrupted in local sandbox workspace?
Hi,
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? Frank |
One answer
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? Comments John,
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.
The ISPF RTC Client does not show the garbage character. Only the original source: if arg2 ¬= '' then do;
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
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?
Ralph,
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.
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.
Ralph,
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.
Frank, missed you where working on i/z. Thought zimport was a typo. Sorry.