As part of my experimentation, the one record I wrote was for sure as small as 80 bytes. That would seem to have been quite "favourable", and no, the remainder of the track was untouched by the data which was MODded to it.
I, weakly, remember there was some apparent "wrinkle" with "end of data" but assumed it was a "normal" thing, rather than anything specific to what I was doing. From memory, of four years ago, with no need of the detail since, when the track was full (could not contain another logical record) there was no "end of file" (file mark). Something like that. I could be wrong, having made the assumption (which seemed to be borne out by the experimentation), I didn't research it. On Fri, 6 Jan 2017 15:41:53 +0000, J R <jayare...@hotmail.com> wrote: >Sent from my iPhone > >> On Jan 6, 2017, at 10:27, Bill Woodger <bill.wood...@gmail.com> wrote: >> >> 1) short or coincidentally-full block, unfilled track; > >So, in the case of a favorable TRKBAL, the access method doesn't back up over >the file mark and write the first new block in its stead? > >It would have to remove the file mark in either eventuality. >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
