Your example clarified it for me.
The reason why the input buffer has the subfile (or any display file
output-only) field is that there is a "context switch" in the meaning of output
and output-only. When defining a field in DDS as output-only, you
are saying that it will not accept any input from the keyboard
(output-only). When the program has to display this "output-only" field,
it has to input it from somewhere. That somewhere is the input
buffer, that may or may not share memory space with another variable. You
load the input buffer with the information you want to be displayed, but remain
unchanged.
In a similar manner, the output buffer takes input from the keyboard and
makes it available for manipulation. I would be very surprised it the
output-only-defined fields have a place in the output buffer of the display
file. That's because the program would not be expecting new information
from the program in those fields.
That's my story... I'll stick to this one!
The PUTOVR and OVRDTA comments I made earlier are way off the mark.
Please ignore my momentary lapse... :-)
----- Original Message -----
Sent: Wednesday, July 25, 2001 9:21
PM
Subject: RE: Interesting subfile
"feature"
I'm
not sure I understand your conjecture. Even if PUTOVR and OVRDTA were
specified, there's no reason for these fields to be in the input buffer.
Why would not sending them out have anything to do with reading them back in?
Regardless, that's not the case. Here's the subfile
definition:
A
R
SCR001S1
A
SFL
A
65
SFLNXTCHG
A
FL0001 1 0B
8
2
A
DSPATR(CS)
A
02
DSPATR(UL)
A
COLOR(TRQ)
A
EDTCDE(Z)
A
01
DSPATR(PC)
A
01
DSPATR(RI)
A
XRMDES R O
8 5REFFLD(PRMDES IVPRML01)
A
DLTEDT
A
XRMCPD R O 8
32REFFLD(PRMCPD IVPRML01)
A
DLTEDT
A
XRMNUM R O 8
73REFFLD(PRMNUM IVPRML01)
A
DLTEDT
A
DSPATR(ND)
A
HRC01 9
0H
A
HRMDES R
H REFFLD(PRMDES IVPRML01)
A
ALIAS(ALIAS00001)
A INSAV1 99
H
As
you can see, the record has no PUTOVR, the fields have no OVRDTA or
OVRATR. Yet, here is the buffer from the compiled
program:
INPUT FIELDS FOR RECORD SCR001S1 FILE IV0400D
FORMAT
SCR001S1.
1
10FL0001
2 26 XRMDES
27 51 XRMCPD
52 570XRMNUM
58
660HRC01
67 91 HRMDES
92 190 INSAV1
But
don't take my word for it. Try a sample yourself. Interestingly,
take a look at the excerpted DSPFFD output below:
Data Field Buffer
Input Output Field
Field
Type Length Length
Buffer Buffer Usage
FL0001
ZONED 1
0 1
1 1 Both
XRMDES
CHAR
25
25
2 Output
XRMCPD
CHAR
25
25
27 Output
XRMNUM
ZONED 6
0
6
52 Output
HRC01
ZONED 9
0 9
58 58 Both
HRMDES
CHAR
25 25
67 67 Both
As
you can see, the DSPFFD shows no input buffer position for
the output-only fields, but the first hidden field (HRC01) shows up as input
buffer position 58. The previous field with an input buffer position in
FL0001, so there are 56 buffer positions unaccounted for.
IBM
got sloppy, that's all.
However, I'm not prone to disregarding speculation,
even when I don't understand it. Since you mentioned PUTOVR, just for
the fun of it I went back into the display file. The subfile control
record and one other record did indeed have PUTOVR. I removed them, and
all the OVRATR and OVRDTA for their fields. It didn't change
anything. The fields were still in the input buffer.
Thanks for the thought, though.
Joe
I haven't taken a look at the buffer to verify this (I trust your
observation, Joe), but my first take on this would be that your display file
is set up as OVERLAY PUTOVR and the output only fields have the OVRATR
OVRDTA keywords associated with the fields. This saves the system the
trouble of resending information that is already displayed on the
screen.
I would hypothesize that if these keywords were removed, the output
fields will disappear from the input buffer.
midrange.com
