Re: R: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE

["Dennis Lovelady" <dlovelady@xxxxxxxx>]

Hi, Domenico:

Well, I was being a little fascitious there (thanks for catching it).  OK,
follow this, and you'll hopefully see where I am coming from:
    o We cannot make any assumptions about how the compiler will act
    o The manual does not expressly state that a file will remain valid and
useable in any way after a WRITE
    Therefore, we have no guarantee that data we write will not be usable
(the first statement being the overriding factor, we cannot assume it to
be).

It's kind of like that old joke about some computer manufacturer coming up
with WRITE-ONLY memory... which is memory that you can write to but never
read.  Equally useful.  OK, my humor is in need of work.  It's Wednesday.
(Whatever that means.)

Now, we know this to be ridiculous although we don't necessarily have that
guarantee in the document.  (What good would it be otherwise?)  But, to me,
it is equally ridiculous that a data area - ANY data area will be impacted
outside of our program control as a *SIDE EFFECT* of ANY operation.
(Unless documented, of course.)

Dennis





Finucci Domenico <Domenico.Finucci@Fiditalia.it>@midrange.com on 12/11/2002
09:29:23 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:    R: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE


Hello, Dennis, most problably i've read in some old manual, may be IBM. It
has been very long time ago.
I really don't know if this behaviour is indicated in ANSI std.

What do you exactly mean with " the file will remain valid after a WRITE" ?

Domenico Finucci
Fiditalia , Milano, 02- 4301-2494


-----Messaggio originale-----
Da: Dennis Lovelady [mailto:dlovelady@dtcc.com]
Inviato: mercoledì 11 dicembre 2002 15.08
A: cobol400-l@midrange.com
Oggetto: RE: COBOL WRITE after OPEN EXTEND results in CLEAR-AFTER-WRITE
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.





_______________________________________________
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.