Re: Display file puzzlement -- MIDRANGE-L

I have several users who set their iSeries Access displays with various foreground and background attributes; one user's is so glaring that I'm surprised she hasn't gone blind yet.

Anyway, when they "stray" outside the "green" screen, all bets are off. I know because I have, upon request, prefixed fields with 5250 attribute bytes such that under special conditions the field will blink or be displayed in red or whatever. Works fine on my session, but some (many?) of those user-defined desktops play havoc with either the colors or some of the notification attributes (RI and HI being the most common problems that I have encountered).

* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>

Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx wrote:

another good source http://wiki.midrange.com/index.php/Program_To_System_Fields

Thanks,
Tommy Holden

From:
Booth Martin <booth@xxxxxxxxxxxx>
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
04/22/2008 12:24 PM
Subject:
Re: Display file puzzlement

Here is a chart I assembled as best I could.

http://www.martinvt.com/Code_Samples/SEU_Colors/seu_colors.html

At the bottom of the page.

Dave McKenzie wrote:

The interaction between colors and attributes in a display file is built
into the 5250 protocol. Three of the bits in the attribute byte (the
non-displayable byte on the screen immediately to the left of a field
that encodes the DSPATRs) are also used to encode color.

Specifically, color is encoded in the CS, BL and HI bits (except that BL
without CS is always red.)

Here's a display file that displays all combinations of the attribute
bits. You can display it with SDA or with a simple RPG pgm. (It will
look familiar to James :-)

A R TESTREC
A 4 18'Hex'
A 4 40'Hex'
A 5 19'20'
A 5 22'GRN '
A 6 19'21'
A 6 22'GRN RI'
A DSPATR( RI)
A 7 19'22'
A 7 22'WHT HI '
A DSPATR( HI )
A 8 19'23'
A 8 22'WHT HI RI'
A DSPATR( HI RI)
A 9 19'24'
A 9 22'GRN UL '
A DSPATR( UL )
A 10 19'25'
A 10 22'GRN UL RI'
A DSPATR( UL RI)
A 11 19'26'
A 11 22'WHT UL HI '
A DSPATR( UL HI )
A 12 19'27'
A 12 22'WHT UL RI RI'
A DSPATR( UL HI RI)
A 13 19'28'
A 13 22'RED BL '
A DSPATR(BL )
A 14 19'29'
A 14 22'RED BL RI'
A DSPATR(BL RI)
A 15 19'2A'
A 15 22'RED BL HI '
A DSPATR(BL HI )
A 16 19'2B'
A 16 22'RED BL HI RI'
A DSPATR(BL HI RI)
A 17 19'2C'
A 17 22'RED BL UL '
A DSPATR(BL UL )
A 18 19'2D'
A 18 22'RED BL UL RI'
A DSPATR(BL UL RI)
A 19 19'2E'
A 19 22'RED BL UL HI '
A DSPATR(BL UL HI )
A 20 19'2F'
A 20 22'RED BL UL HI RI'
A DSPATR(BL UL HI RI)

A 5 41'30'
A 5 44'TRQ CS '
A DSPATR(CS )
A 6 41'31'
A 6 44'TRQ CS RI'
A DSPATR(CS RI)
A 7 41'32'
A 7 44'YLW CS HI '
A DSPATR(CS HI )
A 8 41'33'
A 8 44'YLW CS HI RI'
A DSPATR(CS HI RI)
A 9 41'34'
A 9 44'TRQ CS UL '
A DSPATR(CS UL )
A 10 41'35'
A 10 44'TRQ CS UL RI'
A DSPATR(CS UL RI)
A 11 41'36'
A 11 44'YLW CS UL HI '
A DSPATR(CS UL HI )
A 12 41'37'
A 12 44'YLW CS UL HI RI'
A DSPATR(CS UL HI RI)
A 13 41'38'
A 13 44'PNK CS BL '
A DSPATR(CS BL )
A 14 41'39'
A 14 44'PNK CS BL RI'
A DSPATR(CS BL RI)
A 15 41'3A'
A 15 44'BLU CS BL HI '
A DSPATR(CS BL HI )
A 16 41'3B'
A 16 44'BLU CS BL HI RI'
A DSPATR(CS BL HI RI)
A 17 41'3C'
A 17 44'PNK CS BL UL '
A DSPATR(CS BL UL )
A 18 41'3D'
A 18 44'PNK CS BL UL RI'
A DSPATR(CS BL UL RI)
A 19 41'3E'
A 19 44'BLU CS BL UL HI '
A DSPATR(CS BL UL HI )
A 20 41'3F'
A 20 44'BLU CS BL UL HI RI'
A DSPATR(CS BL UL HI RI)

John McKee wrote:

Interesting....your example works exactly as you describe. BUT, when I
add

COLOR(YLW) or COLOR(BLU) to the first data field, that field does not
dp RI.

We don't use PC5250. My computer has Reflection 7.0. Shop standard is
that

input fields use COLOR(YLW). Having only tried two colors on the first
field,

it may be inaccurate to make a definitive statement, but it appears
that COLOR

messes things up in this case. But, the application package we use has
a

multitude of screens where fields are sent as RI when they were coded as YLW. Just scanned the vendor display file sources. Out of a couple of jundred
screens, one once is ERRSFL used. I am not familiar with the program that uses
the screen with ERRSFL. Possibly, it does not work "properly" either.

At least, I now have a better understanding of why some keywords might
not be

used. No matter how practical and nice the intended results might normally be.

I am wondering, however, if this behavior is specific to Reflection 7.0

or if it
applies to othre versions or emulators.

John McKee

Quoting Simon Coulter <shc@xxxxxxxxxxxxxxxxx>:

On 22/04/2008, at 4:02 AM, John McKee wrote:

I removed PUTOVR, OVRATR, and OVRDTA. Still no RI capability. With
the ERRSFL,
though, I guess I can live with it.

You can have these keywords in the file as long as they are not
active at the same time as ERRMSG. It appears that ERRMSG takes
precedence. In all these cases the correct analysis is to create a
test-case that does what you want to determine exactly where the
problem lies without all the application rubbish getting in the way.

Try the following:

DSPF TSTERRSFLD
*************** Beginning of data
********************************************
A DSPSIZ(24 80 *DS3)
A CA03(03 'Exit')
A ERRSFL
A R THEFORMAT
A 1 35'Test ERRSFL'
A DSPATR(HI)
A 3 2'Type bad data, press
Enter.'
A COLOR(BLU)
A 5 5'Have a go ya
mug . . . . . . .'
A DATA1 10 B 5 37
A 98 ERRMSG('Bzzt! Wrong
answer!' 98)
A 7 5'Have another
go . . . . . . .'
A DATA2 10 B 7 37
A 99 ERRMSG('Bzzt! Wrong
again!' 99)
A 23 2'F3=Exit'
A COLOR(BLU)
****************** End of data
***************************************************

RPGLE TSTERRSFLR
*************** Beginning of data ***********************************
FTSTERRSFLDCF E WORKSTN
C EXFMT THEFORMAT
C SETON 9899
C DOU *IN03 = *ON
C EXFMT THEFORMAT
C ENDDO
C SETON LR
****************** End of data **************************************

Compile the display file and the RPG. Call the RPG. Press Enter. You
should see both input fields reverse-imaged, the cursor should be in
the first field, both error messages should be displayed in the error
sub-file at the bottom of the screen.

If this is not happening for you then:
1) Check the settings in your emulator--it is possible
that RI is

mapped to something else
2) If not using PC5250 then start using it
3) Check the parameters on the CRTDSPF command are the
IBM-shipped ones

4) Check the device type being emulated--it is possible
that you are

emulating a device without RI capability (though unlikely)
5) Check for PTFs--perhaps the 5250 data stream is wrong
(again

unlikely)

I expect that my example code will work correctly indicating the
problem is in your application display file or code.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------