|
Hi Charles, I use this method for a short time (one month) now. It's just like you described, only I have: 1) used the keyword CHGINPDFT instead of DSPATR(UL) with indicator. It does exactly the same. 2) the output DS defined as based, and the basing pointer is initialized with the adress of the input DS. Best regards, Arco Simonse > -----Oorspronkelijk bericht----- > Van: rpg400-l-bounces@xxxxxxxxxxxx > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Namens Charles Wilt > Verzonden: maandag 11 juli 2005 23:31 > Aan: RPG-L Mailing List > Onderwerp: Display file I/O to and from results data structures > > All, > > I've been using results data structures to physical and > logical files with little trouble. Thought I'd see how they > worked with display files and in particular subfiles. > > Got bit by a couple of things: > > 1) When reading a subfile, you often access fields defined > normally defined as output only. Since you specify > LIKEREC(xxxx:*INPUT) you don't get those fields. > > 2) Unlike physical/logical files, you can't read using a DS defined > LIKEREC(xxxx:*INPUT) then do an UPDATE using the same DS. > > My solutions: > 1) Change all fields to be Input/Output. Use DSPATR(PR) and > a "never on" > conditioned DSPATR(UL) so the fields look like Output only. > > 2) Define another DS as LIKEREC(xxxx:*OUTPUT), since all > fields are defined Input/Output, I can move the Input DS to > the output DS and update via the output DS. > > All and all, it works, but seems kind of messy. > > Am I missing something that would make this better? > > Is anybody actually doing this all the time? > > What's the most popular way to make a field defined as > Input/Output look like an output only to the user? > > Thanks, > Charles Wilt > DISCLAIMER: This message contains information that may be privileged or confidential and is the property of C.Meijer B.V. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy,disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. This footnote also confirms that this email message has been swept by the presence of computer viruses
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.