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.
This is an important concept not available to Cobol or C (on most platforms). MetalC does allow you this option. It is important because shared storage must exist until there is no longer a possibility of it being in use by any task or thread. If the storage is freed, then a storage obtain will allow other tasks to use the storage for a different purpose (this is a true storage overlay situation). Maybe your program terminates because you didn't expect a certain error. A good example is LPA/MLPA where it never free's storage because it does not know when the replaced module is no longer in use. I'm guessing that cobol read places the buffer to the current tasks storage which will get freed when the task terminates regardless that other tasks may still access the record. It appears that SHARED STORAGE is a misleading term. All storage within an address space / appropriate storage key can be accessed by any task / thread.within the address space. The real distinction between global and local variables would be how long they are retained. Remember there is nothing stopping you from forking a process in the same address space and passing the address of a global / local variable and letting the forked process access them except how long they are retained. LE free's local variables at the end of function and global variables at the end of the thread. This is where MetalC option comes in. MetalC allows you to create a separate C environment using __CINIT() and to terminate it using CTERM(). In addition,__CINIT() allows you specify an owning TCB or subpool of your choice and it returns a token that allows you to reference / terminate the environment at the time of your choice (or never terminate it to retain the storage). Any thread or task can use this __CINIT() environment as needed but obviously must serialize it's use. Only one task may access this environment otherwise the environment will get corrupted. As for serialization, this is only necessary if the developer needs it. In most case, resources should be serialized.There are many methods for serialization and it's up to the developer to determine what methods best suit there situation. Within C, you have mutex and semaphore. If these are not sufficient to serialize, then you may use one or more z/OS serailization methods (e.g. enque, locks, PLO or CS) but I think you will need to use MetalC or assembler to access those. Jon Perryman On Monday, May 12, 2014 4:20 PM, Tom Ross <[email protected]> wrote: >The distinction between COBOL's distinction of WORKING-STORAGE and >>LOCAL-STORAGE is essentially the same as the PL/I and then C >>distinction of static and automatic storage. >> >>As far as I can judge from earlier posts in this thread the shared >>facility is not a dynamic shared control block; it is a read-only >>table; and the serialization of accesses to such a table is required >>only if it is replaced from time to time DURING the execution of the >>multithreaded application. >> >>Serialization is possible from, although not within, COBOL. One >>writes a pair of simple COBOL-callable assembly-language to do it; and >>it is also possible and useful to write such a pair of subroutines to >>LOAD and DELETE [load module or program object] tables. > >There is some locking available in COBOL, for I/O. If you have a file that >has one record, you could READ it from the thread that wants a 'lock' on >resources and then CLOSE the file when done. COBOL uses Mutexes internally >to prevent multiple accesses to a file record when compiled with THREAD. >You are right though, there is no explicit Mutex technology accessible >directly with COBOL language. We have not had a request for such a feature, >if anyone wants it...ask for it via the RFE site! > >Cheers, >TomR >> COBOL is the Language of the Future! << > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
