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
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:
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?
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
Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 08 '13, 12:00 p.m.Frank Myers
Feb 08 '13, 1:05 p.m.Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 08 '13, 1:15 p.m.Frank Myers
Feb 08 '13, 1:37 p.m.Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 08 '13, 1:44 p.m.