RE: Interesting subfile "feature"

I respectfully disagree with your position, and your analogy.  I believe
that the input specifications should not include output-only fields; they
are in effect a "logical view" over the display file including only fields
of usage I, B or H, not those of type O.  This is how non-subfile records
work.  Subfile records work differently.

The same program has a non-subfile record with two output-only fields and
one field defined as type both.  Only the input-capable field shows up in
the input specification.  This is how I expect it to work.  The subfile is
an anomaly.  I don't like anomalies <grin>.

Regardless of conjecture, the fact of the matter is that the subfile records
DO act differently than non-subfile records.  SInce my revitalization
product emulates a display file, I needed to understand the difference.  I
just thoguht I would share it.

Joe


-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of William Washington III
Sent: Thursday, July 26, 2001 12:54 AM
To: Joe Pluta; MIDRANGE-L@midrange.com
Subject: Re: Interesting subfile "feature"


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

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---