Problem with DSPATR P-field Initialization

[Jerry G]

Hi, everyone. I'm using SFLINZ to initialize my (data entry) subfile, which contains P-fields used to set display attributes [e.g. DSPATR(&FLD01P)]. Since P-fields are character fields (1A P), and SFLINZ documentation says that character fields are initialized to blanks, the initial attribute byte value is blank (X'40') ... which I find rather rude of IBM to do to DSPATR P-fields considering that normal text has an attribute byte value of X'20'. ;-)

The fields with these attribute byte values seem to be correctly displayed initially; the fields on the empty lines appear in normal text, unprotected, and underlined -- as if each attribute byte was X'24'. Yet in Debug it appears that the P-fields are still X'40'. (So where do the actual display attributes come from?!) When I try to highlight a field by turning on the reverse-image bit (X'01') with %BITOR, the new P-field value is X'41' (not a legal DSPATR P-field value like X'25') and the field is not displayed in reverse image.

Since different fields could have various combinations of other attributes set (protection, column-separators, red, high-intensity), I just want to set the reverse-image bit on rather than clobber the attribute byte with X'25'.

I could test for a bit configuration like '-1------' and convert it to '-01-----' to make sure my attribute byte contains a legal P-field value (X'2n', X'3n', X'An", or X'Bn', n=0-F). But that's not very pretty! Has anyone dealt with such a situation before, and found a cool way to deal with it?

TIA,
Jerry

[GLS400]

Re: Problem with DSPATR P-field Initialization

Hi Jerry:

I've always used the hex notation instead of bit twiddleing. Nice table here:

http://wiki.midrange.com/index.php/Program_To_System_Fields

D Blue            C                   Const(x'3A')
D Green           C                   Const(x'20')
D Pink            C                   Const(x'38')
      Select                                       ;  
        When Account <> *blanks and                   
             Carrier <> 0                          ;  
              NoteAtr = Yellow                     ;  
        When Account <> *blanks and                   
             Carrier =  0                          ;  
              NoteAtr = Blue                       ;  
         Other                                   ;
             NoteAtr = Turquoise          ;
     EndSl                                   ;

I hope I've answered at least part of your question.

Best of Luck
GLS

[Scott Klement]

Re: Problem with DSPATR P-field Initialization

You may be thinking that a character on your screen is an "attribute with a value of x'40'" but that's not the way the 5250 emulator sees it. The emulator determines whether each character position is an attribute based on whether the first 3 bits are b'001'

Since x'40' does not start with b'001', it's not considered to be an attribute. It's considered to be regular text character (a blank) and is printed on the screen.

So where does the display attribute come from? It comes from the previous field -- or wherever the most recent character that starts with binary b'001' happens to be on the screen.

[y2krush]

Re: Problem with DSPATR P-field Initialization

Hi Scott,

Follow-up question to b'001'. What about the 'protect' counterpart of the attributes? They don't seem to begin with b'001'.

Thanks.

[Scott Klement]

Re: Problem with DSPATR P-field Initialization

That's because "protect" isn't, technically, a 5250 attribute. It's a weird thing that IBM did with P-fields, they added an additional bit to the P-field that means "protect". Before sending that P-field to the terminal, however, they turn the bit off (because the terminal wouldn't see it as an attribute, otherwise) and then send the appropriate field format word (I think it's "bypass", but dont' quote me on that.. I'd have to look back at my code to be sure -- it's been several years.) When a fiedl is marked with "bypass" (or whatever it is) the use can't make changes to it.

So the "protect" bit on a P-field isn't a real 5250 attribute bit, it's stripped off, and the attribute is sent without it. The protect portion is handled separately.

[y2krush]

Re: Problem with DSPATR P-field Initialization

Thanks very much Scott.

[Jerry G]

Re: Problem with DSPATR P-field Initialization

Thanks, GLS, for the suggestion (and link); I _do_ prefer to use such declarations (in a standard %INCLUDE) when possible.

Thanks, Scott. I did note that "normal" is X'20' and IIRC bits 1 & 2 (numbering 0-7, L-to-R) are always 0 and 1 (with bit 0 indicating protection, as y2krush wrote). And I believe the system uses some default attributes for subfiles, such as underscores for usage "I" or "B" fields -- so maybe on initial display of a subfile, field attributes are out of the program's control, unless predefined in DDS other than P-fields.

After more testing, I think what I've learned is this: Even when inactive subfile records become active by way of the user entering something in one of the subfile fields, named P-fields -- including those used as attribute bytes -- retain the values to which they are initialized with the SFLINZ operation (i.e. blanks). And any bit-twiddling which leaves that second bit on (X'40' = b'01000000') is for naught, as the result is invalid as an attribute byte and is therefore ignored.

As far as I can tell, there is no way to force attribute bytes to take on a valid value automatically when a subfile record becomes active. You just have to make sure to do it yourself!

[Scott Klement]

Re: Problem with DSPATR P-field Initialization

hi Jerry,

Sorry, I didn't follow you. More specifically, here's where I got confused:

And I believe the system uses some default attributes for subfiles, such as underscores for usage "I" or "B" fields -- so maybe on initial display of a subfile, field attributes are out of the program's control, unless predefined in DDS other than P-fields.

Huh? Please don't confuse "the system" and "the 5250 emulator". The system generates the codes with a computer program (one that's part of the operating system), It can "default" to anything it likes, or use sophisticated calculations to come up with the proper code.

The 5250 emulator, however, only understands that it has hit an attribute when the first 3 bits are b'001'. So if you don't have an attribute (such as x'40') in front of a field, then it thinks the attribute has changed, and continues drawing text usng the same attributes as the previous field. If nothing else, there's always an attribute byte in the upper-left corner of the screen.

Does that help? I'm not entirely sure that I understand what you're after, here...

After more testing, I think what I've learned is this: Even when inactive subfile records become active by way of the user entering something in one of the subfile fields, named P-fields -- including those used as attribute bytes -- retain the values to which they are initialized with the SFLINZ operation (i.e. blanks). And any bit-twiddling which leaves that second bit on (X'40' = b'01000000') is for naught, as the result is invalid as an attribute byte and is therefore ignored.

Again, no idea what you're saying here. The 5250 emulator has no notion of a "subfile". The system knows there's a subfile, but it doesn't tell the emulator. It just generates one screen full of data, as normal, as sends it to the emulator. The emulator then responds with the user's input (page up, page down, enter, etc) and the system sends another screen to the emulator as appropirate. (Or, if you roll past the start/end, the system retuns control to your RPG, etc)

As far as I can tell, there is no way to force attribute bytes to take on a valid value automatically when a subfile record becomes active. You just have to make sure to do it yourself!

Yes, I think you're right about that. Personally, I don't find SFLINZ to be very valuable -- if I want blank records in my subile, I'll just write them there... it's not hard.

[Jerry G]

Re: Problem with DSPATR P-field Initialization

Hi, Scott.

After re-reading your comments, I've concluded that I was conflating the terms "attribute byte" and "P-field". I've been talking about the bit settings that happen in the P-field, as discussed in the DSPATR section of the Keyword entries chapter of the DDS manual, at times incorrectly referring to that as an attribute byte. As your explanation of protection first suggested, the two are not the same. The bit configurations sent to a 5250 – or any other – device as attribute bytes are determined by the emulator or driver, not by the RPG program (which concerns itself with the P-fields). Apologies to anyone I confused by this!

As for SFLINZ: I originally inherited a program which just wrote two blank subfile records, but thought I'd try SFLINZ with SFLRNA as a way to allow entry of as many new records as the user wanted to enter at once. I'm still undecided as to its overall usefulness. It's probably best when a user may want to enter a lot of new records, but tracking which records are active vs. which are not, when you must update vs. when you must write, and when a record's DSPATR P-field is "legal" (e.g. x'20') vs. when it is not (i.e. blank = x'40'!), adds some overhead and complication which lessens the benefits.

Again, thanks for your time and help!

Jerry