Having the job step TCB own the storage is the best default for shared storage but it is not always correct. As I said before, shared storage really means when do I free the storage if not specifically freed.
Lets use UNIX processes as an example. It is the UNIX equivalent of an MVS job but since there can be thousands, IBM allows multiple processes in a single address space. Terminating a process must free storage that was not specifically freed (e.g. global storage used by threads (TCB) in the process). If all processes use the same job step TCB, then storage for terminated processes would still be allocated. By the way, I suspect (but don't know) that IBM actually has a separate job step TCB for each process. On the ATTACH for a task, you can specify shared user subpools and you can specify SP0 is not shared. SP0 is by default shared. All storage allocated to a shared subpool will assign a storage owner of the first TCB issusing ATTACH with the shared pool (for children/grandchildren TCB's also passing the shared subpool). Using shared subpools is the best method for assigning storage ownership but not always possible. For example an SRB runs without a TCB so it does not have the shared subpools nor a TCB to assign ownership. In this case, you need to specify STORAGE OBTAIN and RELEASE with the TCB you want as owner. I've never allocated / freed storage in an SRB so I can't tell you what if any default TCB is used. Jon Perryman On Tuesday, May 13, 2014 4:33 AM, John McKown <john.archie.mck...@gmail.com> wrote: On Mon, May 12, 2014 at 10:11 PM, Jon Perryman <jperr...@pacbell.net> wrote: > >> In assembler, we usually do this by allocating the storage to a shared >> subpool or allocating the storage to a TCB that we know is the last TCB to >> terminate. This allows assembler programmers to choose the time that the >> storage will be automatically freed if recovery / termination occurs for >> our task. >> > >Why not just use "Job Step" storage, such as SP=130 or 131? From my >reading, a non-privileged program is allowed to request either of those >subpools, so long as it requests it in a key allowed by the PKM (or just >use key 8). Is this how you are doing it? Or do you use the "input TCB" >parameter of the STORAGE OBTAIN macro? Or do you just have a TCB which does >all the STORAGE OBTAINs. Or, perhaps weirdest, do you schedule an IRB from >the "requesting" TCB to run a subroutine on the "owning" TCB which does the >STORAGE OBTAIN and then returns the address to the original TCB somehow >(such as WAIT / POST)? > >Inquiring minds want to know. <grin/> I am just curious. > >-- >There is nothing more pleasant than traveling and meeting new people! >Genghis Khan > >Maranatha! <>< >John McKown > > >---------------------------------------------------------------------- >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
