IBM Mainframe Forum

haneef wrote:FILE AMZ6P VS UPDATE

If your task is putting headers and trailers onto a file, we'd have to know if there is other data already on the file. If the VSAM file is a KSDS, already populated, to get your header at the front of the file, you'd need to use WRITE ADD, not PUT, and the same with the trailer (unless you sequentially read all the records on the file until EOF, then the PUT would work for the trailer).

Of course, you could delete/define the file before your ETP runs, but then the file should be defined as VS CREATE, not VS UPDATE.

The unwanted data in your file could simply be from previous runs of your program. We'd need to know how your VSAM file is defined. I really don't know what a PUT would do on a KSDS without some other IO function first (READ, POINT, GET).

marta.doural wrote:I'm not sure if this is what you need, but before writing a VB record, you have to tell Easytrieve how long is the record you are going to write:

Yes, except Haneef's file is a VSAM file, not VB.

Hello,

VSAM files may be variable. . .

Sorry, having missed the point of these forums earlier, I read the rules and stuff. They say try to keep it short, something at times I'm not good at.

If you have a "flat" or "SAM", variable length-record file (VB or V) then you have to give a record-length to the file before writing it. If you have a VSAM file, what happens with these PUTs depends on how the output file is defined in the first instance. We don't even know what sort of file it is. We can suspect, from the original code, that they are indeed fixed records of 102 bytes. In which case, if that is how the file is defined, with IDCAMS, then there is no necessity to amend the record-length.