On Dec 22, 2011, at 08:13, McKown, John wrote: > <snip> >> An off-list discussion has prompted a question: How does BPAM >> implement NOTE and POINT for UNIX files? If we create copybook >> members with vi, emacs, nedit, jedit, ... and allocate SYSLIB >> with FILEDATA=TEXT,RECFM=FB,LRECL=80,PATH=..., the (emulated) >> BPAM will pad lines with 0x40 to 80 byte records. Then a nested >> COPY causes a NOTE; copies in the nested member and POINTs back >> to the previous position. I'd expect POINT to use fseek() >> internally. But how does it calculate the fseek() argument, >> not knowing how many padding bytes were added previously? >> Or does BPAM keep a journal? > > Why wouldn't it just use ftell() to record the actual position in the UNIX > file, independant of its reformatting of the data placed into the user's > buffer? Then fseek() back to that. > The token returned by NOTE for a legacy PDS contains:
o the catenand number o TTR within the catenand, which serves to identify both the member and the block. For a UNIX directory, it would need to identify: o the catenand number o the member within the directory o the relative byte address within that member. Is a NOTE token sufficiently large to contain all this information? Particularly given that a concurrent process may be adding or deleting members from the same directory. -- gil
