How should we maintain application ISPF Panel members in RTC?

Frank Myers (29●19●22) | asked Feb 11 '13, 4:51 p.m.

We used zimport to import z/OS PDS members into RTC.

Out of several PDSs loaded, we found that the ISPF Panels (alone) contain a mixture of Binary and EBCDIC text. The binary (non-EBCDIC) characters are used to mark "field attributes" in the ISPF Panels.

This can cause zimport errors if (as an example) any panel marks a field using 0x0d. Otherwise, it loads fine (but still contains non-EBCDIC characters).

When they are displayed/edited using ISPF the nonEBCDIC characters cause no problems, but when displayed by Eclipse/RTC they are marked by an odd symbol ( which looks like a small box containing small numbers).

The problem is that while we can "turn hex on" in ISPF to maintain the non-EBCDIC characters, we don't know how to do this in Eclipse/RTC.

Is there a way to maintain mixed data using RTC?

Frank

Accepted answer

permanent link

Liam Doherty (231●2) | answered Feb 14 '13, 5:09 p.m.
JAZZ DEVELOPER

Hi Frank

unfortunately we are currently investigating this behavior and have an open enhancement to cover it, Allow RTC to handle non-roundtrippable MVS characters such as 0x0D (239144).

What I would like to know is which hex characters specifically are you having problems with, other than x'0D'.

I have some additional information, which, while it won't solve this problem may provide you with a workaround. ISPF provides an edit macro called ISRDTLCV which is used to convert the non-displayable characters in panel output to editable characters. If you only have a small number of panels maybe you can use this edit macro to convert the problem files.

For our RTC ISPF panels we use DTL to generate them, so the source we store in RTC is not affected.

If you can let me know the specific characters you are having problems with I can do some more testing.

Frank Myers selected this answer as the correct answer

Comments

Frank Myers commented Feb 14 '13, 5:22 p.m.

Liam,

The Attribute markers are usually assigned starting at 0x01 and proceeding upwards. So 0x0D is reached at the thirteenth unique attribute marker.

I've never seen a panel member with more than 60 unique attributes. If it gets even half that far, the panel starts looking like a circus show.

On the application I'm working on, the worse panel has 16 markers, so 0x01 through 0x0f.

I hope this helps. By the way, I found that I can edit (including all the weird hex characters) the line using the LPEX Editor, If I select a line, and right click on it, and select "edit line in hex".

Thank you for your response.

Frank

It's all about the answers!

Related questions

How should we maintain application ISPF Panel members in RTC?

Accepted answer

Your answer