|
Hi, TTBOMK output fields in subfiles have always acted this way. EG when you have the typical work with style of screen a la PDM with an input field for an option and the rest output fields. You could always READC and have available the output only fields to CHAIN (or whatever) as long as they were all the key fields needed to access the file being worked with. Some people kept the RRN as a hidden field for efficiency. I believe Cobolers have trouble with this feature for some reason and so use protected both input and output fields in subfiles. I have no explanation as to why it is so. I just know it is. Regards, Kevin Wright ----- Original Message ----- From: Joe Pluta To: William Washington III 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 -----Original Message----- From: William Washington III [mailto:w.washington3@starband.net] Sent: Wednesday, July 25, 2001 11:33 PM To: Joe Pluta; MIDRANGE-L@midrange.com Subject: Re: Interesting subfile "feature" 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 ----- From: Joe Pluta To: William Washington III 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 <<snip>> +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
