|
I respectfully submit that you are "misinterpreting" input and output
with respect to the file with input and output with respect to the program
I/O. It's kind of like system/34 and /36 programming. The output
buffer of the file is the input buffer to the program.
For example, take your very example, below. If I were
program-describing the file to the program (heaven forbid!), I would determine
the file output buffer (i.e., the result of the DSPFFD, output starting
position) and use that as my I-spec starting position (just like s/36
coding). As you can see, they line up perfectly.
The output buffer for the file is used as input to the input buffer to the
program. Use the analogy of hooking a VCR to the TV. The wire goes
from the video-OUT from the player to the
video-IN on the TV set. You would not
hook the video-IN to video-IN! (Using a DVD in this analogy would not work
because you typically can't write from the TV to the DVD. You can write to
the VCR. And that process would be analogous to using the output buffer
from the program as input to the file input buffer.
I am very surprised that you're only seeing this behavior only with
subfiles. Non-subfile displays and database files work exactly
the same way. (For them to work differently would violate something
related to the file Superclass inheritance mechanism. Oops, there I
go talking over my head again...)
Regarding your test, a field defined as output-only means that the program
will not create an output buffer for it, but the program will create an
input buffer so the program can accept the information from the file (which
presents the information to the program's input buffer from the file's output
buffer.) The field did not change in your program because the program
doesn't create an output buffer for fields defined as output-only, so the field
never was changed.
I never use the same name for device file fields as internal program or
data files for this very reason (though you can get away with it with printer
files, because the data's going out.) Typically, I'll have my display
fields named XFxxx and move information to and from those field
programatically. This way, there is no confusion between the I/O buffers
of the program and of the file.
-ww3
----- Original Message -----
Sent: Wednesday, July 25, 2001 11:29
PM
Subject: RE: Interesting subfile
"feature"
I
still don't think that's quite the story, for two reasons:
1.
The fields don't have an "input buffer position" in the
DSPFFD
2.
This does NOT happen for output-only fields in a non-subfile record
format
I
tested this empirically. I did a WRITE to a non-subfile record, changed
the output-only field in the program, and then did a READ to the same
record. The field did not change in the program. I then did the
same thing, using a READC on a subfile. I wrote a record to a subfile,
changed the output-only field it in the program, then did a READC.
After the READC, the field changed in the program (to the value I had
written to the subfile).
This
is definitely an oddity specific to subfile records.
Joe
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... :-)
*/
William
----- 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
|
midrange.com
