On Mon, 5 Dec 2016 14:01:47 -0600, Jerry Callen wrote: >I'm writing a Physical File System (PFS) for USS, and I've >come across an oddity in the interface documentation. The >"Environment for PFS Operations" section of z/OS UNIX >System Services File System Interface Reference says that, >on entry to VFS function routines, R13 is "Save area address, >of a 136-byte save area".
I have never heard of a 136-byte save area either. However, when a service documents its requirements for a save area, the only thing that is expected of the caller is to provide the address of a large enough area. If I was calling these routines, I would provide a 144-byte save area. If it uses only 136 bytes, there is no harm done. It may be that these routines use the save area passed in register 13 in some nonstandard way. In that case, IPCS won't be much help if there is an abend in the service routine. >I don't think there is such a beast. I'm guessing it means that >I should treat this as a 144-byte F4SA, and not chain forward >(using the "next" slot at +136 of the old save area). You don't treat the area that you pass to other programs in any way. If you want to forward chain, you do that in accordance with the save area format that you used to save your caller's registers. If you were passed a 72-byte save area that you used to save your caller's registers in standard 72-byte format, you would use the fullword at offset 8 for the forward chain, regardless of the size of the save area that you pass to other routines. When you provide a save area, you can call one program that requires a 144-byte save area and another that requires a 72-byte save area. You would use the same 144-byte save area for both calls. Each program would use what it needs. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
