|
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] Cobol, RPG, and all AS/400 languages have separate input and output buffers. It is not a language-dependent issue. The 5250 data stream protocol outputs one set of fields, and receives a [normally] smaller set of fields back. In RPG, the programmer never sees the input and output buffers - the RPG data handler moves fields from the buffers to fields that are mapped from the buffers. Cobol can probably simulate RPG - simply code a file layout record into working storage. For reads, Read into the buffer, then move corr into working storage. For writes, move corr to the buffer, then write from the buffer. I think it would be a similar effect. -----Original Message----- From: Ravi Prasanna Annasagara Nagarajan [mailto:ravi.annasagara@wipro.com] Sent: Tuesday, August 13, 2002 7:25 AM To: cobol400-l@midrange.com Subject: RE: Need for separate Input and Output Areas in Display File This is a multi-part message in MIME format. -- Terry, Thanks for the reply. I know it is not necessary to define separate Input and Output areas. I refer to the case that is shown below. WORKING-STORAGE SECTION. 01 HEADER-OUTPUT. COPY DDS-HEADER-O OF PAD0137NW. 01 HEADER-INPUT. COPY DDS-HEADER-I OF PAD0137NW. In this case, the HEADER record format has seperate as Input and Output Areas. What is the need for this? As you said it is easier to code without seperating the two areas and also eliminates the need for qualification. But what do you think is the purpose of seperating the I-O area? I have been blinding doing this from a long time, but have not understood the reason for seperating the I-O area, hence the question. I would be grateful for any inputs on this issue. Thanks and Regards, Ravi Prasanna A.N. mailto:ravi.annasagara@wipro.com -----Original Message----- From: cobol400-l-admin@midrange.com [mailto:cobol400-l-admin@midrange.com] On Behalf Of Winchester Terry Sent: Tuesday, August 13, 2002 4:37 PM To: 'cobol400-l@midrange.com' Subject: RE: Need for separate Input and Output Areas in Display File Ravi, You're not required to have separate I-O areas in your program for a display file. There may be a slight performance advantage for sending a smaller amount of data to the display but I have never noticed it. Generally, I code all of my fields as B (input/output) and then use the DSPATR(PR) and CHGINPDFT keywords on those fields that are only required for output. This allows you to copy only the *output* (-O) records into your program. This eliminates the need for qualification and allows a single record structure to work with. I believe it makes the code easier to understand. Its also easier on my brain :) Terry > -----Original Message----- > From: Ravi Prasanna Annasagara Nagarajan > [mailto:ravi.annasagara@wipro.com] > Sent: Tuesday, August 13, 2002 6:13 AM > To: cobol400-l@midrange.com > Subject: Need for separate Input and Output Areas in Display File > > > This is a multi-part message in MIME format. > -- > -- > [ Picked text/plain from multipart/alternative ] > Hello > > This is a pretty basic question. Why do we need to separate Input and > Output Areas in display file? Is there any advantage in that? The > reason I am asking this question is because we do not do any such > thing in RPG programs. So why is it required in Cobol programs? Does > it provide any performance enhancements? > > Many thanks in advance. > > Regards, > Ravi Prasanna A.N. > mailto:ravi.annasagara@wipro.com > > -- > > > -- > **************************Disclaimer************************** > ********** > > Information contained in this E-MAIL being proprietary to Wipro > Limited is 'privileged' and 'confidential' and intended for use only > by the individual > or entity to which it is addressed. You are notified that > any use, copying > or dissemination of the information contained in the E-MAIL > in any manner > whatsoever is strictly prohibited. > > ************************************************************** > ************* > -- > > _______________________________________________ > This is the COBOL Programming on the iSeries/AS400 > (COBOL400-L) mailing list > To post a message email: COBOL400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l > or email: COBOL400-L-request@midrange.com > Before posting, please take a moment to review the archives at > http://archive.midrange.com/cobol400-l. > _______________________________________________ This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list To post a message email: COBOL400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l or email: COBOL400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/cobol400-l. -- **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *************************************************************************** _______________________________________________ This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list To post a message email: COBOL400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/cobol400-l or email: COBOL400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/cobol400-l.
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.