Hi Joe
I have another DSPF where there's a CHECK(LC) and the next field isn't
conditioned by indicators and that works as expected which tells me that the
emulator/keyboard/PC are all okay.
All of the evidence points to it being related to the conditioning of the
next field, I just don't see why unless it's an OS/400 bug that hasn't been
picked up before.
I suppose I should do it properly and either condition a DSPATR(ND) on the
field or drop the MSGID keyword and populate the field from within the
program. That way I won't have a need for the "dummy" blank.
Thanks
Jonathan
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: 10 July 2007 16:36
To: 'Midrange Systems Technical Discussion'
Subject: RE: Strange effect of conditioning DSPF fields
From: Jonathan Mason
Hi Joe
The TEXT field is defined in the field reference file as:
A TEXT 50A TEXT('Text')
A COLHDG('Text')
In the display file DDS I tried coding COMMENT as 50 and 50A, but neither
made any difference.
Okay, it seems broke to me, Jonathon. I can't see anything you've done
wrong. But just to weed out the REALLY extraneous possibilities, have you:
1. Tried this on a dumb green screen terminal (to factor out the emulator).
2. Tried this on another PC (to factor out the keyboard).
3. Added a second LC field with no conditioning. (Not even sure what this
would weed out, but if you can enter LC on one field and NOT on another
field in the same screen, then that would seem to point quite definitively
at IBM).
And of course, the old standby: are you sure you're using the right display
file from the right library compiled from the correct source. (Silly, I
know, but you have to check.)
Joe
midrange.com
