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.