Re: REENTRANT vs THREADSAFE

2011-07-24 Thread Shmuel Metz (Seymour J.)
In 4e29ebb7.3000...@ync.net, on 07/22/2011 at 04:29 PM, Rick Fochtman rfocht...@ync.net said: But you must admit that sometimes they're mildly amusing. In rare instances, they're downright hilarious. :-) Only if I don't have to clean up after people who listened to them :-( But, yes, when

Re: REENTRANT vs THREADSAFE

2011-07-22 Thread Shmuel Metz (Seymour J.)
In snt113-w585822f589ad61188d3f50c6...@phx.gbl, on 07/21/2011 at 05:19 PM, john gilmore john_w_gilm...@msn.com said: Samuel is useful and even diverting when someone else's ox is being gored. If Jane can't even get names right, it's no wonder that he missed the point. in the MVS-specific

Re: REENTRANT vs THREADSAFE

2011-07-22 Thread Shmuel Metz (Seymour J.)
In of9f21e079.799a0575-on852578d4.0057e593-862578d4.00582...@csc.com, on 07/21/2011 at 11:02 AM, John P Kalinich jkali...@csc.com said: IIRC, the technique recommended by IBM was to use the ENQ macro before modifying RENT code. That works well for large blocks of code, but CS is useful for

Re: REENTRANT vs THREADSAFE

2011-07-22 Thread Rick Fochtman
snip-- You're right, I don't suffer fools gladly. -unsnip But you must admit that sometimes they're mildly amusing. In rare instances, they're

Re: REENTRANT vs THREADSAFE

2011-07-21 Thread Shmuel Metz (Seymour J.)
In snt113-w225ae423b76930781f515c6...@phx.gbl, on 07/20/2011 at 07:52 PM, john gilmore john_w_gilm...@msn.com said: Initially in an IBM mainframe environment a reentrant program could modify itself, usually at initial-load time, if it held a global lock while it did so; and this is the chief

Re: REENTRANT vs THREADSAFE

2011-07-21 Thread Tony Harminc
On 21 July 2011 11:45, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In snt113-w225ae423b76930781f515c6...@phx.gbl, on 07/20/2011   at 07:52 PM, john gilmore john_w_gilm...@msn.com said: Initially in an IBM mainframe environment a reentrant program could modify itself, usually at

Re: REENTRANT vs THREADSAFE

2011-07-21 Thread John P Kalinich
Subject:Re: REENTRANT vs THREADSAFE

REENTRANT vs THREADSAFE

2011-07-21 Thread john gilmore
Samuel is useful and even diverting when someone else's ox is being gored. This time I find his reminder that there were no locks, in the MVS-specific sense, in OS/360 tedious at best; my usage was ironic and ought to have been obvious in context; but Samuel is a natural force; no rhetoric

Reentrant vs Threadsafe (was RE: Re-entrant module stores into itself with no 0C4)

2011-07-20 Thread Chase, John
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Just to be my usual self. In general in CS, reentrant does not mean non-self modifying. Many programs which do not modify themselves are still not reentrant due to uncoordinated updating of shared

Re: Reentrant vs Threadsafe (was RE: Re-entrant module stores into itself with no 0C4)

2011-07-20 Thread McKown, John
Answered in the Wikipedia article. quote Relation to thread safety It must not be confused with thread-safe. A function can be thread-safe and still not reentrant. For example, a function could be wrapped all around with a mutex which avoids problems in multi-threading environments, and if that

REENTRANT vs THREADSAFE

2011-07-20 Thread john gilmore
Worth noting explicitly is that the CICS alternatives are o THREADSAFE and o QUASIRENT. Long before IBM COBOL compilers could generate reentrant code COBOL was made usable for CICS APs by trickery. The pointer to working storage--There was as yet no stack-based local storage, and COBOL