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 / \
--------------------------------------------------------------------






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.