Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
athulvijay wrote:
This info was a real help. It is the problem with default beffer size.
No, it is NOT. You are not listening to the advice you have been given.
Here's another bit of advice that I am sure you will ignore: STRING is not the same as MOVE. An alphanumeric MOVE pads the receiving field with spaces; STRING does not.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
If you refuse to find out what the problem is yourself, and refuse to let anyone see your code, all I can suggest is this: settle on a particular blocksize. Calculate how many records your glitch-free code can write before somehow causing an error. Make a new version of your program, which takes a parameter. In the parameter, tell your program how many records to read before it starts writing. Write the number-of-records-calculated minus one. Close up and stop. Execute the program, with different parameters each time, until your input is processed. Concatenate the output files as input to the next task.
If you don't fancy that, show us the code that you think is relevant, and any other code that we ask for, and answer any questions we ask. Show us your compile options.
Or, sort it out yourself. But you can't, becuase you don't accept the possibility that the error can be yours. So, go back to the above, or discover a business reason for a smaller input file.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
From an earlier comment, no, I can't really think of a normal way to do anything too clever with Cobol writing a sequential fixed-length file.
The record shown is not a complete header. It means that the "header" data was either put there, sourced from the normal fields, or not all the data in the record-area was overwritten.
Don's point about the STRING could be relevant, but the TS has already failed to provide the code for the creation of the data records on the file as requested. If using STRING to create the data records, I also suspect the problem will be there. Reference-modification would be the other lazy way to possibly screw it up.
It is probably no co-incidence that the single data record shown has hyphens in the positions that are alleged to be part of the header on the record prior to it.
It is possible that TS feels he is initialising the record, but is not. If using STRING or reference modification only to populate, the defintion could be this:
Code:
01 backout-record.
05 filler pic x(128).
In which case the INITIALIZE will do diddly-squat.
Perhaps the "header" data is in fields defined as FILLER.
To my mind INITIALIZE is a horrible, lazy thing, invented for people who couldn't code an initialisation of a table correctly. What would have been wrong with
Code:
MOVE SPACE TO backout-record
Extra typing? Doesn't look as cool? What?
Anyway, TS only came here for for confirmation that his code was fine. Everyone disagreed, but TS still managed to use something to prove his code "glitch free". I suspect TS's code is a potential "bug heaven". This needn't be a terminal problem for an 8-month starter, as long as they can realise they've made errors, and learn from them. However, "glitch free" is someone heading for failure.
TS is happy, and it is a bit of a wasted topic for anyone else.