Some 5250 attribute bytes are not preserved

[jkyeung]

I have "Show Seu Colors" disabled. I have a source member with attribute bytes. This is what the member initially looks like in SEU:

This is what it looks like when I open it in VS Code:

Notice especially that X'25' has become a linefeed, and the source has one more line than it started with.

After saving it in VS Code without doing any editing, and reopening it in SEU, it looks like this:

Notice that besides the unwanted linefeed (for X'25'), X'3F' has now become '\Z' (two characters, backslash followed by 'Z').

The expected behavior is that both of those attribute bytes (as well as any others) survive the round trip back to the IBM i.

Extension version: v2.12.1
IBM i OS version: 7.4

[worksofliam]

IMO, not a bug. This has the way it has always been in VS Code. It's the way it gets converted from the server. We always read UTF8 or ASCII from the server and never as EBCDIC (even if EBCDIC is returned). 'SEU Color' mode was a hack to better support SEU users, but actually it was truly a pain to maintain and not something you see outside IDEs.

I need more opinions on this, but I believe we going to leave it as is, and perhaps add a warning if the document contains any of those bytes (if even possible) and offer to clean it up. Offering to clean it up would be nice if we can.

[worksofliam]

@jkyeung I am working on a solution. Is it possible for you to share an SQL statement with me so I can insert rows into a member with that same content you had? Thanks!

[starbuck5250]

`cl: crtsrcpf buck/vscode rcdlen(112) mbr(*none) text('Samples for testing VS Code');
cl: addpfm buck/vscode attributes srctype(RPGLE) text('Attribute byte testing');

insert into buck.vscode (srcseq, srcdat, srcdta)
values
(01.00, 240805, ' // This illustrates 5250 attribute bytes.'),
(02.00, 240805, ' '),
--(05.00, 240805, ' C*' concat x'XX' concat 'X''XX''' concat x'404020' concat 'X''XX'' GRN RI UL BL CS ND'),
(03.00, 240805, ' C*' concat x'20' concat 'X''20''' concat x'404020' concat 'X''20'' GRN '),
(04.00, 240805, ' C*' concat x'24' concat 'X''24''' concat x'404020' concat 'X''24'' GRN UL '),
(05.00, 240805, ' C*' concat x'25' concat 'X''25''' concat x'404020' concat 'X''25'' GRN RI UL '),
(06.00, 240805, ' C*' concat x'2E' concat 'X''2E''' concat x'404020' concat 'X''2E'' RED UL BL '),
(07.00, 240805, ' C*' concat x'2F' concat 'X''2F''' concat x'404020' concat 'X''2F'' RED ND'),
(08.00, 240805, ' C*' concat x'30' concat 'X''30''' concat x'404020' concat 'X''30'' TRQ CS '),
(09.00, 240805, ' C*' concat x'36' concat 'X''36''' concat x'404020' concat 'X''36'' YLW CS '),
(10.00, 240805, ' C*' concat x'37' concat 'X''37''' concat x'404020' concat 'X''37'' YLW CS ND'),
(11.00, 240805, ' C*' concat x'3D' concat 'X''3D''' concat x'404020' concat 'X''3D'' PNK RI UL '),
(12.00, 240805, ' C*' concat x'3E' concat 'X''3E''' concat x'404020' concat 'X''3E'' BLU UL '),
(13.00, 240805, ' C*' concat x'3F' concat 'X''3F''' concat x'404020' concat 'X''3F'' revert to default '),
(14.00, 240805, ' '),
(15.00, 240805, ' *inlr = *on;'),
(16.00, 240805, ' return;')
;`

[jkyeung]

Thanks, Buck!

I specifically left out some of the "working as designed" codes to make the screenshots smaller, but if it were me doing the testing and development, I would include all of them.

[starbuck5250]

Unfortunately, the 'code' tag still stripped out the spaces :-(
Let me try again

insert into buck.vscode (srcseq, srcdat, srcdta)
values 
  (01.00, 240805, '      // This illustrates 5250 attribute bytes.'),
  (02.00, 240805, '     '),
--(05.00, 240805, '     C*' concat x'XX' concat 'X''XX''' concat x'404020' concat  'X''XX'' GRN RI UL BL CS ND'),
  (03.00, 240805, '     C*' concat x'20' concat 'X''20''' concat x'404020' concat  'X''20'' GRN               '),
  (04.00, 240805, '     C*' concat x'24' concat 'X''24''' concat x'404020' concat  'X''24'' GRN    UL         '),
  (05.00, 240805, '     C*' concat x'25' concat 'X''25''' concat x'404020' concat  'X''25'' GRN RI UL         '),
  (06.00, 240805, '     C*' concat x'2E' concat 'X''2E''' concat x'404020' concat  'X''2E'' RED    UL BL      '),
  (07.00, 240805, '     C*' concat x'2F' concat 'X''2F''' concat x'404020' concat  'X''2F'' RED             ND'),
  (08.00, 240805, '     C*' concat x'30' concat 'X''30''' concat x'404020' concat  'X''30'' TRQ          CS   '),
  (09.00, 240805, '     C*' concat x'36' concat 'X''36''' concat x'404020' concat  'X''36'' YLW          CS   '),
  (10.00, 240805, '     C*' concat x'37' concat 'X''37''' concat x'404020' concat  'X''37'' YLW          CS ND'),
  (11.00, 240805, '     C*' concat x'3D' concat 'X''3D''' concat x'404020' concat  'X''3D'' PNK RI UL         '),
  (12.00, 240805, '     C*' concat x'3E' concat 'X''3E''' concat x'404020' concat  'X''3E'' BLU    UL         '),
  (13.00, 240805, '     C*' concat x'3F' concat 'X''3F''' concat x'404020' concat  'X''3F'' revert to default '),
  (14.00, 240805, '     '),
  (15.00, 240805, '       *inlr = *on;'),
  (16.00, 240805, '       return;')
;

The 5250 Functions Reference manual is the canonical reference.
See page 2-142 and 143, Screen Attributes

[jkyeung]

The 5250 Functions Reference manual is the canonical reference. See page 2-142 and 143, Screen Attributes

Nice! I don't think I was aware of that particular manual. I did see someone else's chart online at some point, but it had an error or two.

It was still instructive to try it empirically, and understand the bit patterns, because I have never seen anything (from IBM or otherwise) that talks about two quirks in particular:

1. Nondisplay does not supersede everything. If the bits are such that column separators are on, then the column separators are still visible! This only affects x'37', which has the bit pattern for both CS (4th bit on, 5th bit off) and ND (last 3 bits all on).
2. The case of x'3F' is just plain weird. That manual Buck linked to says it's "nondisplay". And it should be, if it follows the pattern (last 3 bits all on). But you can clearly see in my screenshot that it doesn't behave that way! Wherever it was that I got the "revert to default" from, that source of information was more correct than the IBM manual, for this particular case. But nothing that I've seen anywhere mentions the fact that for x'3F', the attribute byte itself is visible, apparently as reverse image. (So in practice, the best way to "revert to default" is to simply use x'20'.)