IBM Mainframe Forum

Hi all,

I have 1 input and 1 output file. Length of input file is 11200bytes and output is around 11500.....Both are VB.

I am moving the most of the field of INPUT layout to output layout INDIVIDUALLY.

Now, what I observed is for few records, one of the output field defined as 01 TI-FIELD PIC X(1)........when the input 01 II-FIELD PIC X(1) is "."

After,
MOVE II-FIELD to TI-FIELD.

OUTPUT data is changing to "SPACE" instead of "."(dot) and for other records it is working fine.


So, I used Expeditor and for this record and was little shocked.

AFTER THE MOVE, for one record TI-FIELD was showing ".(dot)". But as soon as it written to file value changed to SPACE.

MOVE is working correct but write. WHY ?



Another observation when I reduce the no. of records in the INPUT file..............output file gives correct value for TI-FIELD i.e dot(.)


Thanks,
Zhinghur

Do the record layouts for the files use OCCURS DEPENDING ON?
If yes, how and when is the length variable set for the output file?

What is the exact code you are using to write the data?

Based upon what you've posted so far, you're not likely to get any good answers -- the more information you give use (cut-and-pasted code), the better the answers you'll get.

Its a huge layout. Not possible to post. There are just OCCURS.

All Input fields are simply moved to Output fields layout....very simple code. This output files has 300 bytes of extra info, like dates etc at the end.

If anyone came across this situation it will be easier to get answer, I guess.

Once you have "written" the record, the record-area in your FD will no longer be pointing to that record, but to an area which the next output record can do what it wants to.

You will, generally, have the 01s under the FD pointing to data within a "buffer" which, once the buffer (or all the buffers for that file) is full will actually be written to whatever output device (dasd, tape, sysout, etc).

Once the buffers are full and "flushed" (written out) then your 01s will probably find themselves pointing back to the start of the first buffer area, which will contain the record which was first written. Thus, when you see a "." it is from an old record.

Compiler option AWO or specifying APPLY WRITE ONLY for VBs can change this process somewhat, as this will use a seperate record area which will be moved to the output-buffer once it is known if it fits. If it does not fit, it will go into the next buffer. When all buffers are full, they will be written and the record which did not fit will become the first one in the first buffer.

So the short answer is, what you are observing is the way it works. After the WRITE you cannot rely on the contents of anything in the output record area. Sometimes they will have the value you expect, but not for the reason you expect - it is just co-incidence from some previous record, written five buffers ago.

Well spotted, but it is not a problem. It is the way it works. If you have some actual problem, it is for a different reason. Let us know.

Thanks BillyBoyo.

I tried with APPLY WRITE ONLY option but it didn't work. So, I wanted to try with AWO with compiler option, but for this we need to request from ADMIN, which ain't possible for us. After compiling the problem is we don't see IGYCTRL code in spool else I could have AWO there. It has been hidden with some other setting.

I am not sure how to get around with this problem.

As I said, it is not a problem, it is how it works.

If you need to preserve the value of somehting after a WRITE, you have to do by putting it in working-storage before the WRITE.

AWO/Apply Write Only only changes what you have acess to under the FD, it is nothing to do with a resolution for your problem. With AWO and APPLY WRITE ONLY you have access to a record-area, which will be moved to a buffer only after it is known whether it fits in the current buffer.

For a VB: without AWO/Apply Write Only you have a buffer-area under your FD; with AWO/Apply Write Only you have a record-area. You should not attempt to rely on the contents of your FD area after a WRITE in either case. Store what you need in working-storage.

Hello,

You might consider changing the code to WRITE FROM working storage instead of writing from the FD record area.

Thanks Billyboyo and Dick Scherrer. It worked.

Thanks for letting us know.