Re: IBM C and Cobol Threading question
On Tue, May 13, 2014 at 7:24 AM, Scott Ford scott_j_f...@yahoo.com wrote: John, Are you speaking of Sub Address Space storage ? I've never heard of Sub Address Space storage. I can't figure out what you mean. What I meant was storage which is in a subpool, such as 130, which is automatically owned by the JSTCB (Job Step TCB) of the requesting TCB, and is kept around until that TCB, the JSTCB, goes through termination. This is usually the step (JOB or STC or TSU) ending. Regards, Scott -- 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
Re: IBM C and Cobol Threading question
On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. I have some minimal knowledge of that, thanks to CICS using them. But I don't see where that has much to do with STORAGE OBTAIN, other than complicating things when storage needs to be shared between an key 8 and a key 9 program. I think that IBM is missing out on a possibility, due to TSO being moribund, of using a subspace group the way that CICS does in order to more securely separate the non-APF TSO commands from the APF authorized commands. Run them in separate subspace groups. I wonder what perversions I can get UNIX to perform using them? Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Re: IBM C and Cobol Threading question
From the MVS extended Addressability Manual …SA22-7618-08 A subspace is a specific range of storage in the private area of an address space, designed to limit the storage a program can reference. A program that is associated with a subspace cannot reference some of the private area storage outside of the subspace storage range; the storage is protected from the program. Whether a given range of private area storage is protected from a program associated with a subspace depends on whether the storage is: Eligible to be assigned to a subspace (or “subspace-eligible”) Assigned to a subspace Not eligible to be assigned to a subspace. You control these storage “states” through the IARSUBSP macro. Storage outside of the private area is not affected by subspaces. A program running in an address space can reference all of the storage associated with that address space. In this section, a program's ability to reference all of the storage associated with an address space is called full address space addressability. A program running with full address space addressability can reference storage in any of the three states: eligible to be assigned to a subspace, assigned to a subspace, or not eligible to be assigned to a subspace. A program that runs in an address space that owns subspaces also has full address space addressability. While running in a subspace, a program now has access to 64-bit private and shared storage. It can reference the 64-bit storage while in subspace mode and no longer needs to issue the BSG (Branch in Subspace Group) instruction to switch to the base mode to reference the 64-bit storage. A program running in a subspace can reference storage that is assigned to its own subspace and storage that is not eligible to be assigned to a subspace. It cannot reference storage that is eligible to be assigned to a subspace or storage that is assigned to a subspace other than the one in which the program is running. In other words, a subspace allows a program running in it to reference all of the storage associated with the address space except the private area storage that is eligible to be assigned to a subspace or assigned to another subspace. When storage is not eligible to be assigned to a subspace and not assigned to a subspace, it can be referenced by a program running in a subspace or a program running with full address space addressability. This storage can be referenced by all subspaces as well as by programs running with full address space addressability. An address space that owns subspaces is also called a “base space”. Figure 74 illustrates the concept of creating a subspace in base space ASID 23. From: john.archie.mck...@gmail.com Sent: Wednesday, May 14, 2014 9:09 AM To: IBM Mainframe Discussion List On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. I have some minimal knowledge of that, thanks to CICS using them. But I don't see where that has much to do with STORAGE OBTAIN, other than complicating things when storage needs to be shared between an key 8 and a key 9 program. I think that IBM is missing out on a possibility, due to TSO being moribund, of using a subspace group the way that CICS does in order to more securely separate the non-APF TSO commands from the APF authorized commands. Run them in separate subspace groups. I wonder what perversions I can get UNIX to perform using them? Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Re: IBM C and Cobol Threading question
Subspace groups are not secure. A program can freely reset their subspace group. If you play nicely, the subspace groups help. On Wed, 14 May 2014 08:09:02 -0500 John McKown john.archie.mck...@gmail.com wrote: :On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: : : On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: : : I've never heard of Sub Address Space storage. I can't figure out what : you mean. : : Try subspace group. : : : :I have some minimal knowledge of that, thanks to CICS using them. But I :don't see where that has much to do with STORAGE OBTAIN, other than :complicating things when storage needs to be shared between an key 8 and a :key 9 program. : :I think that IBM is missing out on a possibility, due to TSO being :moribund, of using a subspace group the way that CICS does in order to more :securely separate the non-APF TSO commands from the APF authorized :commands. Run them in separate subspace groups. I wonder what perversions I :can get UNIX to perform using them? : : : : Shane ... : : -- : For IBM-MAIN subscribe / signoff / archive access instructions, : send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN : -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Wed, May 14, 2014 at 8:59 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Subspace groups are not secure. A program can freely reset their subspace group. Another wonderful idea shot down by cruel reality. If you play nicely, the subspace groups help. Just blue skying, but I wonder how much it would cost to use them in a highly multi-threaded server to enhance reliability. Especially if the server, like CICS, ran user supplied transaction code. Or is the UNIX way of using separate processes, in separate address spaces, simply better - FSVO better. I know some UNIX people who are bemoaning the increased use of threads in a UNIX environment due to possible cross task memory corruption. -- 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
Re: IBM C and Cobol Threading question
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
Re: IBM C and Cobol Threading question
John, Are you speaking of Sub Address Space storage ? Regards, Scott From: john.archie.mck...@gmail.com Sent: Tuesday, May 13, 2014 7:33 AM To: IBM Mainframe Discussion List 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
Re: IBM C and Cobol Threading question
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
Re: IBM C and Cobol Threading question
Some comments. The terms 'local' and 'global' have well-established definitions and uses---They specify the scopes of set symbols at assembly time---in the HLASM macro language, and their usurpation for other purposes is ill-advised. '...that way madness lies; let me shun that; No more of that'. Moreover, persistence and scope are very different notions. They are sometimes hard to disentangle; but it is always unwise to confound them. Persistence can be characterized in two ways, in terms of maximal lifetime and dynamism. The obvious maximal lifetimes are termination by o z/OS shutdown/IPL, o jobstep, o task, and o block or routine exit It may or may not be possible to allocate and free a block of storage dynamically. Thus, for example, the automatic/scratch storage of PL/I and then C is allocated when control for a dispatchable unit enters a routine or block and freed when it exits from that routine or block. It cannot, that is, be allocated sooner or freed later. Automatic storage is also LIFO, stack-based storage, allocated from a stack and freed/returned to that stack for reuse. Typically, pools are also stacks, not because FIFO democracy is important for them but because stacks are the easiest constructs to use to manage interchangeable, reusable blocks of storage. Most other storage is non-LIFO, and a block of it is typically called a heap. There are management issues for heaps, but most modern operating systems handle them efficiently. Once allocated from a heap, storage within such a block of can of course be suballocated/managed as a stack or pool. The questions how best to manage heaps and where to put them do not have any generic answers, but the lawyers' de minimis principle is important for them. A system may usefully contain many stacks, but it shouild not usually contain more than a very few heaps. Accesses to heaps must [almost] always be serialized; and adult, asynchronous systems cannot be built without using serialization machinery. Satisfactory systems can be written primarily in some statement-level procedural language (SLPL), but routines written in that SLPL must typically be supplemented by others written in assembly language. The Scots poet Blair described archangelic visits to the earth, necessary to keep things in order here below, as 'short and far between'; and these assembly-language routines can have these two characteristics too. They are, however, necessary 1) to close gaps in the SLPL being used, 2) to avoid really ugly, infelicitous constructs in that SLPL, and to circumvent serious inefficiencies in that SLPL's implementation. For these reasons programmers who do not write assembly language with facility are all but useless. The routines they write always reflect the more or less radical imperfections of the SLPL they use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
John, So what you call setting a token, IEANTCR ..then allocating storage based on the return address ? A block of storage ? Curious ... Scott ford www.identityforge.com from my IPAD On May 13, 2014, at 1:32 PM, John Gilmore jwgli...@gmail.com wrote: Some comments. The terms 'local' and 'global' have well-established definitions and uses---They specify the scopes of set symbols at assembly time---in the HLASM macro language, and their usurpation for other purposes is ill-advised. '...that way madness lies; let me shun that; No more of that'. Moreover, persistence and scope are very different notions. They are sometimes hard to disentangle; but it is always unwise to confound them. Persistence can be characterized in two ways, in terms of maximal lifetime and dynamism. The obvious maximal lifetimes are termination by o z/OS shutdown/IPL, o jobstep, o task, and o block or routine exit It may or may not be possible to allocate and free a block of storage dynamically. Thus, for example, the automatic/scratch storage of PL/I and then C is allocated when control for a dispatchable unit enters a routine or block and freed when it exits from that routine or block. It cannot, that is, be allocated sooner or freed later. Automatic storage is also LIFO, stack-based storage, allocated from a stack and freed/returned to that stack for reuse. Typically, pools are also stacks, not because FIFO democracy is important for them but because stacks are the easiest constructs to use to manage interchangeable, reusable blocks of storage. Most other storage is non-LIFO, and a block of it is typically called a heap. There are management issues for heaps, but most modern operating systems handle them efficiently. Once allocated from a heap, storage within such a block of can of course be suballocated/managed as a stack or pool. The questions how best to manage heaps and where to put them do not have any generic answers, but the lawyers' de minimis principle is important for them. A system may usefully contain many stacks, but it shouild not usually contain more than a very few heaps. Accesses to heaps must [almost] always be serialized; and adult, asynchronous systems cannot be built without using serialization machinery. Satisfactory systems can be written primarily in some statement-level procedural language (SLPL), but routines written in that SLPL must typically be supplemented by others written in assembly language. The Scots poet Blair described archangelic visits to the earth, necessary to keep things in order here below, as 'short and far between'; and these assembly-language routines can have these two characteristics too. They are, however, necessary 1) to close gaps in the SLPL being used, 2) to avoid really ugly, infelicitous constructs in that SLPL, and to circumvent serious inefficiencies in that SLPL's implementation. For these reasons programmers who do not write assembly language with facility are all but useless. The routines they write always reflect the more or less radical imperfections of the SLPL they use. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: IBM C and Cobol Threading question
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
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 tmr...@stlvm20.vnet.ibm.com 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 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
Re: IBM C and Cobol Threading question
All: I am not trying to pour cold water on any ideas or dis-credit anyone, that's not me . I have a weird kinda legacy issue I am trying to solve. Basically, COBOL STC calling Assembler subroutines. The STC(s), are single threaded or single TCB and the real issue is we need them to run multi-threaded (in C terminology ) or multi-tasking . The both use Sockets ..So I was exploring , trying to figure out what the easiest and most supportable way to do this. There is only me doing this …and money is short…same ole same old story. This is why I asked the question. Regards, Scott From: John Gilmore Sent: Thursday, May 8, 2014 11:59 AM To: IBM Mainframe Discussion List 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. In general, then, Mr. Perryman and I disagree, as we often have. His generic strictures, which would interdict all mixed-language applications, are simplistic. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: IBM C and Cobol Threading question
Scott, Is this message table in fact a static one than you change only infrequently, e.g., when you also make changes in the routines that use it? If so, you should consider making it into a load module or, preferably, a program object. It can then be brought into storage using a LOAD or LOADX. You can then, of course, store-protect it, make it unmodifiable while resident. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
John, Yes sir it is static …I like the idea of a load module ..easier for sure..and I can protect it.. A big thanks.. Hey do you know if a Heap can be passed in a C thread ? Regards, Scott From: John Gilmore Sent: Friday, May 9, 2014 11:26 AM To: IBM Mainframe Discussion List Scott, Is this message table in fact a static one than you change only infrequently, e.g., when you also make changes in the routines that use it? If so, you should consider making it into a load module or, preferably, a program object. It can then be brought into storage using a LOAD or LOADX. You can then, of course, store-protect it, make it unmodifiable while resident. John Gilmore, Ashland, MA 01721 - USA -- 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
Re: IBM C and Cobol Threading question
Tom, Thank you very much, I appreciate the clarification, I thought this was how threading worked with Cobol but wanted to make sure. Regards, Scott From: Tom Ross Sent: Thursday, May 8, 2014 2:02 AM To: IBM Mainframe Discussion List I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! Cheers, TomR COBOL is the Language of the Future! -- 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
Re: IBM C and Cobol Threading question
Tom, Looking here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/4.4 quote For the data that you want to isolate to an individual program invocation instance, define the data in the LOCAL-STORAGE SECTION. In general, this choice is appropriate for working data in threaded programs. If you declare data in WORKING-STORAGE and your program changes the contents of the data, you must take one of the following actions: Structure your application so that you do not access data in WORKING-STORAGE simultaneously from multiple threads. If you do access data simultaneously from separate threads, write appropriate serialization code. /quote But there doesn't seem to be any hint of how to write appropriate serialization code. Too bad COBOL can't declare a variable ATOMIC or have some sort serialization primitive like some other languages. I rather like the synchronized in Java. But, of course, COBOL is not really designed for multi-threading. If I want to do heavy duty threading and concurrency, I'd choose Clojure. Why? Because it is designed for it _AND_ it runs on the JVM which means it can run on a zAAP. On Thu, May 8, 2014 at 1:02 AM, Tom Ross tmr...@stlvm20.vnet.ibm.comwrote: I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Re: IBM C and Cobol Threading question
I personally would STRONGLY discourage this implementation. You're not the only one in your environment. Why not do it correctly and allocate from shared storage pool. Use either C's or assemblers implementation. Remember if you do it once, someone else will think this clever and use it without fully understanding why it works. The Cobol guide has a section on multithreading. I've never read it but you should at least follow it's guidelines. Yes it will work but it's not even done this way in C and we should not do this in assembler. Multi-tasking is allowed in assembler (ATTACH) and C (threading) but not in most other languages. By violating C's implementation of global variables, you are doing something they don't expect. Cobol user's don't multi-task so they are not familiar with this. In the best error situation you get an abend. In the worst, some other threads storage will get stomped on and the receivng program will reference bad data. Jon Perryman On Wednesday, May 7, 2014 11:02 PM, Tom Ross tmr...@stlvm20.vnet.ibm.com wrote: I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
John, As always my friend excellent points. I have a follow on question can you pass a created user heap from thread to thread ?? Regards, Scott From: John McKown Sent: Thursday, May 8, 2014 10:04 AM To: IBM Mainframe Discussion List Tom, Looking here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/4.4 quote For the data that you want to isolate to an individual program invocation instance, define the data in the LOCAL-STORAGE SECTION. In general, this choice is appropriate for working data in threaded programs. If you declare data in WORKING-STORAGE and your program changes the contents of the data, you must take one of the following actions: Structure your application so that you do not access data in WORKING-STORAGE simultaneously from multiple threads. If you do access data simultaneously from separate threads, write appropriate serialization code. /quote But there doesn't seem to be any hint of how to write appropriate serialization code. Too bad COBOL can't declare a variable ATOMIC or have some sort serialization primitive like some other languages. I rather like the synchronized in Java. But, of course, COBOL is not really designed for multi-threading. If I want to do heavy duty threading and concurrency, I'd choose Clojure. Why? Because it is designed for it _AND_ it runs on the JVM which means it can run on a zAAP. On Thu, May 8, 2014 at 1:02 AM, Tom Ross tmr...@stlvm20.vnet.ibm.comwrote: I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Re: IBM C and Cobol Threading question
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. In general, then, Mr. Perryman and I disagree, as we often have. His generic strictures, which would interdict all mixed-language applications, are simplistic. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
Jon, Its not my call ….I am only the guy asking the questions. From: Jon Perryman Sent: Thursday, May 8, 2014 10:05 AM To: IBM Mainframe Discussion List I personally would STRONGLY discourage this implementation. You're not the only one in your environment. Why not do it correctly and allocate from shared storage pool. Use either C's or assemblers implementation. Remember if you do it once, someone else will think this clever and use it without fully understanding why it works. The Cobol guide has a section on multithreading. I've never read it but you should at least follow it's guidelines. Yes it will work but it's not even done this way in C and we should not do this in assembler. Multi-tasking is allowed in assembler (ATTACH) and C (threading) but not in most other languages. By violating C's implementation of global variables, you are doing something they don't expect. Cobol user's don't multi-task so they are not familiar with this. In the best error situation you get an abend. In the worst, some other threads storage will get stomped on and the receivng program will reference bad data. Jon Perryman On Wednesday, May 7, 2014 11:02 PM, Tom Ross tmr...@stlvm20.vnet.ibm.com wrote: I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! -- 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
Re: IBM C and Cobol Threading question
Jon, Can you point me to the shared memory you spoke of in C …I would prefer to write this in C / Assembler…get away from Cobol, not that I don't like it. We are a small vendor …. It would be much appreciated From: John McKown Sent: Thursday, May 8, 2014 10:04 AM To: IBM Mainframe Discussion List Tom, Looking here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg31/4.4 quote For the data that you want to isolate to an individual program invocation instance, define the data in the LOCAL-STORAGE SECTION. In general, this choice is appropriate for working data in threaded programs. If you declare data in WORKING-STORAGE and your program changes the contents of the data, you must take one of the following actions: Structure your application so that you do not access data in WORKING-STORAGE simultaneously from multiple threads. If you do access data simultaneously from separate threads, write appropriate serialization code. /quote But there doesn't seem to be any hint of how to write appropriate serialization code. Too bad COBOL can't declare a variable ATOMIC or have some sort serialization primitive like some other languages. I rather like the synchronized in Java. But, of course, COBOL is not really designed for multi-threading. If I want to do heavy duty threading and concurrency, I'd choose Clojure. Why? Because it is designed for it _AND_ it runs on the JVM which means it can run on a zAAP. On Thu, May 8, 2014 at 1:02 AM, Tom Ross tmr...@stlvm20.vnet.ibm.comwrote: I have written a C program using threads and have a question. I have an ext= ernal message table that I need to be persistent between threads. The mess= age table is loaded from an external QSAM file. Program in Cobol loads the = table. I want to be able to use the message table in other threads. Does an= yone know is Working-Storage from one thread available to other threads ?=20 Yes! In fact, all of your COBOL threads would be using a single copy of WORKING-STORAGE, so if one of them wants to do something that does not affect the others then the programs need LOCAL-STORAGE variables. Normally with multi-threading you would not use WORKING-STORAGE because of this. In your case, defining your table in WORKING-STORAGE and your other variables in LOCAL-STORAGE would work great! Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
