|
Thank you, Domenico. Ah... here's the crux: > The reason for the initialize is that COBOL does not > guarantee that the contents of the 01 will be intact after a write. Is that stated somewhere, or just assumed? In fact, poring through the documentation, I don't see any guarantee that the "sending" field on a MOVE statement will remain intact. Does that mean that, since it's not explicitly stated otherwise, we should also save fields that we use as "senders?" Where will THAT end? I see no guarantee that the file will remain valid after a WRITE, but we assume it to be so. Is that also not a valid assumption? We make SO MANY assumptions about how the compiler's going to act, and the system, and all-things-computer in the final analysis. If something's affected, that must be documented somewhere, else we cannot be effective programmers. Following that logic, the fact that the manual doesn't state that the record area becomes unreliable after a write, surely indicates that it won't. Doesn't it? Dennis "Weatherly, Howard (Contractor) (DLIS)" <Howard.Weatherly@dlis.dla.mil> @midrange.com on 12/11/2002 08:43:51 AM Please respond to cobol400-l@midrange.com Sent by: cobol400-l-admin@midrange.com To: "'cobol400-l@midrange.com'" <cobol400-l@midrange.com> cc: Subject: RE: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE 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 ] Finucci, Maybe others have said this, but the actual record buffer is destroyed after a write. The EXTEND has nothing to do with it. So if you are going to work in the actual record area assigned under the FD, you will need to repopulate the fields each time, however as someone else mentioned you can also keep data in WS that will be used for each write and have "SOME-FIELD" defined there, then use WRITE DETAIL-RECORD from SOME-RECORD INITIALIZE DETAIL-RECORD. The reason for the initialize is that COBOL does not guarantee that the contents of the 01 will be intact after a write. -----Original Message----- From: Finucci Domenico [mailto:Domenico.Finucci@Fiditalia.it] Sent: Wednesday, December 11, 2002 3:12 AM To: 'cobol400-l@midrange.com' Subject: R: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE Hello, Dennis, I don't know if i may be considered an expert, but i anyway try to answer. As far as i know, the content of a buffer area is not guaranteed to be retained after an i-o operation; that's why normally you need to save a buffer BEFORE a write (i.e. if you need to write 2 identical files). I think this behaviour is normal, at least included in some IBM manual. Sincerely Domenico Finucci Fiditalia , Milano, 02- 4301-2494 -----Messaggio originale----- Da: Dennis Lovelady [mailto:dlovelady@dtcc.com] Inviato: marted́ 10 dicembre 2002 21.15 A: COBOL400-L@midrange.com Oggetto: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE Howdee! I just debugged a strange situation, I thought I'd get the take of you experts on it. A COBOL400 (not ILE) program that's been working for years just showed a deficiency, so I started debugging it. OK, that's not too weird so far, but it got interesting. :) One of the files is OPEN EXTEND within the program, and that file started receiving blanks in some fields that we initialized only at the beginning of the program. So we have: 0100-INIT. ... MOVE 'XYZ' TO SOME-FIELD ... 2100-PROCESS. ... PERFORM 4200-WRITE-RECORD .... 4200-WRITE-RECORD. >>> WRITE DETAIL-RECORD >>> ADD 1 TO RECS-WRITTEN Using STRDBG ... OPMSRC(*YES), a breakpoint was set at the two lines indicated by >>> What I found was that just before the WRITE statement executed, everything was cool. SOME-FIELD had the "XYZ" in it that I expected. Pressed F10 to proceed to the next statement, and entered EVAL SOME-FIELD again. I found that SOME-FIELD contained blanks. In fact, the whole record contained blanks. Now maybe I'm confused, but my understanding of COBOL says that this should not be. I triple checked my results and found that this is consistantly happening. I don't know why. We recently upgraded the OS from V4R5 to V5R1, but that was a few weeks ago, and we've not seen this problem until today. Anyone out here who can explain this to me? Thanks, Dennis _______________________________________________ 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. _______________________________________________ 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.