Re: UpperCase ONLY?

On 16 Jan 2013 09:12, Thomas Garvey wrote:

This is a green screen RPG program with a display file having an
entry field. That field allows lowercase entry. There's nothing wrong
with the program. It's more than ten years old and works for dozens
of clients, except this one.

I would send a saved copy of the DSPF from a system where there is no problem. Then restore that DSPF into an alternate library on the system where there is the problem. Have someone issue a request to override the display file [being sure to specify proper scoping] to the alternate\restored copy before starting a new test of the program on that system; verify that having used that other DSPF, the problem was resolved. If the problem is resolved by that test, then first collect some docs about the file [noted later] and then switch the two files to effect recovery. That allows for some investigation of an apparent corruption of the original DSPF on that other system to be done; i.e. keep the problematic file rather than DLTF. For the docs get DSPOBJD for *FULL and *SERVICE, DSPFD, and DSPFFD; the "changed date" is important to get before a MOVOBJ or RNMOBJ because those operations will change the last changed timestamp.

Or send a saved copy of the DSPF from the system with the problem, then perform the STRSDA test [as suggested by Eric] on your own system; or an actual use of the program with DSPF. This test should be as definitive to conclude the same effect; i.e. if the test of the field in the format shows typed input is forced to upper case, then surely the shifting must be implied by the field attributes.

But in either case, sending a new DSPF to replace the problematic file would be required for recovery, *if* it is determined that the existing DSPF was somehow corrupted. Thus I would tend to start with sending that direction first.