Re: LOAD and DELETE macro instructions
In a6b9336cdb62bb46b9f8708e686a7ea0116565f...@nrhmms8p02.uicnrh.dom, on 12/07/2012 at 12:46 PM, McKown, John john.mck...@healthmarkets.com said: Could this be what you are wanting? Close; the text you cited is for storage allocation by the program; I'm talking about sections in a program object whose storage is allocated by Fetch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In cae1xxdhy9jrnlpgyqua9nq_pqbel8oibj-ykwwhr357f9ln...@mail.gmail.com, on 12/08/2012 at 11:39 AM, John Gilmore jwgli...@gmail.com said: I have grown very tired of your absurd, moralistic comments. K3wl; I've grown tired of your lies. You convert all disagreement with you into vice. There you go again; another lie. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In CAE1XxDEJD+VPiOKQWV=pwofs3xsbo2ppmc0n_bu7qko8vy7...@mail.gmail.com, on 12/09/2012 at 08:27 AM, John Gilmore jwgli...@gmail.com said: This view may well be appropriate and adequate to the things Shmuel wants to do with data. My shared-tables system proceeds otherwise. You have not, however, given a reason for it. Two of its principal table types are generated respectively by 242 and 1007 macros. Instances of a table type sometimes include a particular subtable/extension and sometimes do not; and I accordingly make heavy use of V-type ADCONs in generating them. Why? If there's a reason to not use AD(foo), you haven't given it. Moreover, as Shmuel ought properly to have garnered from this thread, As you should have figured out, I used the term A-con to mean, e.g., A, AL3, AD. I suspect Your suspicions are generally either wrong or followed by claims that are wrong; such is the case here. he was, as too often, making a debater's point, Another lie. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In caarmm9tcdidwxyr7mcg003ap8qjrvtbthoc9txte3ed_wqo...@mail.gmail.com, on 12/10/2012 at 07:37 PM, Tony Harminc t...@harminc.net said: Some even older of us will remember that in pre-MVS days those 3-byte values were TTRs in SYS1.SYSJOBQ, and it was a pleasant if short-lived and short-sighted thing to be able to just look at memory instead of scheduling I/O. I generally used standard services rather than doing my own I/O. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
the use of DC A(whatever) instead of DC AD(whatever) does make great trouble above the bar. Of course it does make trouble. But that is an RMODE point, not an AMODE since this is not executable. If this were AMODE 64 RMODE 31 or AMODE 31 RMODE 31 there would be no trouble. Whoever uses your DC AD, if the code were actually above the bar, would of course have to be AMODE 64 to access the located area. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Dec 7, 2012, at 7:22 AM, McKown, John wrote: I'd lay good odds that most of the DCB oriented stuff will stay RMODE(24) until the end of the age of mainframes. So much code is dependent on 3 byte addresses that even if IBM wanted to update it, end users would revolt when their applications which used 3 byte addresses from the 1980s abended. I remember the nastiness when SWA went above the line and what was an address became a token. Everybody had to either keep SWA below the line (an option), or rewrite their code to use the SWAREQ(?) macro instead of chain chasing. John: I was involved in this issue and had opened several problems when various vendors did not support it. One vendor ran with it on the first phone call and had a solution next day. One vendor said well maybe in the next release. The vendor happened to supply the source for the module in question so I went a digging. It took me all of 5 minutes to find it and less that five minutes to code the changes up. I called the vendor and told them not to bother as I fixed it and then they had the gull to ask me for the change. I suggested a free years worth of the use of the product and they wouldn't hear of it. I said good by. I was sick and tired of some vendors attitude on the the SWA issue most did a decent job (except for one). The vendor who was a hold out is a well known vendor who is discussed on this list often (usually in not a complementary tones, this is one of the reasons, IMO). The code change was miniscule and trivial in the case of several vendors. I would not defend them in any case. Ed I wish that IBM would wise up. Guess what I/O interface already allows AMODE(64) callers. The UNIX I/O calls have both AMODE(31) and AMODE(64) variants (BPX1* and BPX4*). I wish that IBM would extend these to allow access to standard z/OS data sets. A PDS could be viewed as a subdirectory, with each member being a file. I've read that PDSE's can even have member names 8 characters, but I've not run across one yet which does. (We're a small shop and don't have much advanced software installed). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, December 06, 2012 6:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LOAD and DELETE macro instructions I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. On Thu, Dec 6, 2012 at 5:19 PM, John Gilmore jwgli...@gmail.com wrote: Shmuel says: | AMODE(64) is not appropriate for a module that is not executable. Peter Relson---I am now wary of paraphrasing him---appears to judge that AMODE is moot for tables. I have said and say that AMODE(64) is not just appropriate but desirable for a read-only module that contains doubleword ADCONs. Take your pick; or consult an augur, who will to wield his lituus in helping you make your choice. 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? - - 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On 7 December 2012 08:22, McKown, John john.mck...@healthmarkets.com wrote: I'd lay good odds that most of the DCB oriented stuff will stay RMODE(24) until the end of the age of mainframes. So much code is dependent on 3 byte addresses that even if IBM wanted to update it, end users would revolt when their applications which used 3 byte addresses from the 1980s abended. I remember the nastiness when SWA went above the line and what was an address became a token. Everybody had to either keep SWA below the line (an option), or rewrite their code to use the SWAREQ(?) macro instead of chain chasing. Some even older of us will remember that in pre-MVS days those 3-byte values were TTRs in SYS1.SYSJOBQ, and it was a pleasant if short-lived and short-sighted thing to be able to just look at memory instead of scheduling I/O. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Shmuel wrote: begin extract Why would AMODE have any efffect on the resolution of address constants? Specifically, why would it have any effect on A-cons (you shouldn't be using V-cons for data)? end extract This view may well be appropriate and adequate to the things Shmuel wants to do with data. My shared-tables system proceeds otherwise. Two of its principal table types are generated respectively by 242 and 1007 macros. Instances of a table type sometimes include a particular subtable/extension and sometimes do not; and I accordingly make heavy use of V-type ADCONs in generating them. (Currently, the HLASM supports an AD but no VD, and this has required be to do things that are less transparent than I should like them to be.) Moreover, as Shmuel ought properly to have garnered from this thread, the use of | DC A(whatever) instead of | DC AD(whatever) does make great trouble abover the bar. I suspect. however, that he did/does know this; he was, as too often, making a debater's point, not a substantive one. JOAT were better rendered JOATAMON. 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: LOAD and DELETE macro instructions
In CAE1XxDF9t6E8=wACU8yPzkUkPpytNAkbeMWGri=tzxvyj1o...@mail.gmail.com, on 12/07/2012 at 11:05 AM, John Gilmore jwgli...@gmail.com said: In my original post I distinguished what Peter recommended and what I recommend sharply, and I gave my reasons for my preference. FSVO original. In Message-ID: CAE1XxDFVXUrY=wjsvapdkhklvzsdhwwqrodfs0gj+kh51yu...@mail.gmail.com you quoted Peter and a few paragraphs later you tried to fob off a totally unrelated statement as a paraphrase. I would rephrase Peter's formulation, (it better not have any 4-byte relocatable adcon's), slightly, changing it to it better be AMODE(64). For once be honest and admit that you messed up. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Shmuel, I have grown very tired of your absurd, moralistic comments. You convert all disagreement with you into vice. NOPOST would be an appropriate fate for you, but I do not believe in censorship of any kind. 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: LOAD and DELETE macro instructions
In p06240808cce73fe76177@[192.168.1.11], on 12/07/2012 at 01:47 AM, Robert A. Rosenberg hal9...@panix.com said: It is if the module contains relocatable doubleword pointers to locations within itself and these would not be resolved correctly if you just coded AMODE(31). Why would AMODE have any efffect on the resolution of address constants? Specifically, why would it have any effect on A-cons (you shouldn't be using V-cons for data)? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
If the tables reside above the bar, the addresses inside the tables need to be 8 bytes long. As long as the tables are not bigger than 2 GB, I would use relative adresses (related to the table origin) instead. This way 4 byte relative addresses are sufficient, and you have to store the table origin only once and you need simply add the table origin every time when you follow such a relative address. And another positive side effect: it is possible to move the tables, if necessary, and you need not relocate the adresses inside the table; the relative addresses are still valid after relocation. Kind regards Bernd Am 07.12.2012 00:35, schrieb John Gilmore: Why put addresses in tables? One of my macros generates a table for glb- and lub-seeking binary-search operations. The lexicographic subscript of a bounding element is often of less interest than its entry sequence or another, arbitrary code value. This macro therefore optionally generates another table containing such values, making it accessible by providing its address. Or again, tabular-function tables are often compound ones containing two atomic tables, one of arguments and another of values, the addresses of both of which are stored in a stub. In general, there are many reasons for wishing to include addresses in generated tables, which can be and often are very much more complex in detail than hand-coded ones. 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: LOAD and DELETE macro instructions
For non-executable, RMODE is what you want, not AMODE. AMODE applies only to code running in the module that identifies the AMODE. And of course there is no such code in a non-executable module. So RMODE 64 would be the right thing. But the binder does not support RMODE 64 at this point. It will some day. I get IEW2618I 4B40 RMODE 64 ESD ATTRIBUTES HAVE BEEN CHANGED TO RMODE ANY. I don't know the reason that the assembler (and binder) have historically chosen not to flag short adcon's. This is demonstrable with a module that is RMODE 31 but has DC AL3(theMod). TEST CSECT TEST RMODE 31 DC AL3(TEST) END Certainly an option could be added to do this sort of validation. A customer requirement for such a thing would always be helpful (perhaps this is one already, I have no idea). And I will re-iterate: LOAD with ADDR (or ADDR64) ignores the RMODE and assumes the user knows what they're doing. That is where my caution came from. The module would be RMODE 31 (so a 4-byte relocatable adcon is nominally fine) but would not survive if placed above 2G it relied upon that adcon. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Bernd's point is, in a certain sense, well taken. Moreover, the constraint that a table not exceed 2 Gib in size is, for now at least, self-enforcing. The Binder will not, currently, produce a program object that is more trhan 1 Gib in size; and the 16-Mib constraint on the size of a traditional load module is of course much more severe. My objection to it is of another kind. Relative addressing using the data type offset is of course easy enough to do in PL/I, but PL/I is the only [at all widely used] statement-level language that does provide such support,. and the expedient of using it to save four bytes in the storage representation of a small number of addresses does not seem to me to be an appropriate design compromise. (Offsets remain useful in other kinds of entities because, as Bernd all but points out, they are invariant not just under storage moves but under I/O too. I use them, for example, in storing segments of binary-search trees in external data sets.) Another argument, an impure one, for the use of AMODE(64) for such tables is that it underlines the ineluctable requirement that executables that access them be AMODE(64). 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: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 10:44:43 -0500, John Gilmore wrote: I take your point, and I of course believe you when you say that you meant what you wrote (ands tghat you object to my faulty paraphrase). Paraphrase? Perhaps there is some meaning of the word with which I am not familiar. Peter's point that a module to be loaded above the bar better not have any 4-byte relocatable adcon's was an important one. The meaning of that caution is not in any way contained in your better be AMODE(64). AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. IBM has an understandably long history of omitting to enforce some eminently reasonable constraint until that point in time at which it judges it appropriate to do so; and marking an object, even a read-only one, that is destined to reside above the bar as AMODE(31) is, I think, an act of hubris. Perhaps. The fear that there might be a problem some day trying to load a non-executable module above the bar if it is not marked AMODE(64) may or may not be justified. I suspect not. Of course, if the tables are generated by macros that use SYSSTATE decide whether to create fullword or doubleword adcons, then the desire to specify AMODE(64) is understandable. I disagree that it is reasonable to distort Peter's caution the way that you did. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Fri, 7 Dec 2012 07:22:56 -0600, McKown, John wrote: I wish that IBM would wise up. Guess what I/O interface already allows AMODE(64) callers. The UNIX I/O calls have both AMODE(31) and AMODE(64) variants (BPX1* and BPX4*). Mac OS X came along recently enough that it supports only one file size model. But this caused me problems when I ported GNU findutils which is old enough that it used 32-bit integers for file sizes. I think it's better nowadays. But ZFS, reportedly 128-bit oriented, looms on the horizon. I wish that IBM would extend these to allow access to standard z/OS data sets. A PDS could be viewed as a subdirectory, with each member being a file. I've read that PDSE's can even have member names 8 characters, but I've not run across one yet which does. (We're a small shop and don't have much advanced software installed). I think base member names are restricted to 8 characters; aliases may be bigger. And the rules for program object libraries may be different from those for other PDSEs. Go figger. As I initially encountered UNIX after too much familiarity with MVS, I quickly came to appreciate the significance of the first 3 characters, UNI. Conventions within an Operating System are not an area where I celebrate diversity. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Fri, 7 Dec 2012 11:16:45 +0100, Bernd Oppolzer wrote: As long as the tables are not bigger than 2 GB, I would use relative adresses (related to the table origin) instead. This way 4 byte relative addresses are sufficient, and you have to store the table origin only once and you need simply add the table origin every time when you follow such a relative address. And these may sometimes be generated in HLASM with constructs such as A(TARGET-*) which contains an abolute address expression; no RLDs are necessary. But if TARGET and * reside in different CSECTS, will HLASM accommodate the doubly-relocatable construct? I think so, but relocation of a module above the bar may create transitory out-of-range values. Should these be reported as errors? The final result is valid when treated modulo 2^32. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In my original post I distinguished what Peter recommended and what I recommend sharply, and I gave my reasons for my preference. There are other reasons, many of them too arcane and detail-ridden for ready discussion here, for my views; but the notion that I somehow misrepresented Peter's position is nomsense. He repudiated by notional paraphrase, which he had every right to do; and I acknowledged his action. What is perhaps more important is that the conventions for marking and processing data-only objects are inadequate. The old name 'load module' had the great merit that it did not implicitly reject the notion that one might wish to LOAD a table. The new one, 'program object', unfortunately does so. As I have already made clear in an earlier post, I make heavy use of composite tables that contain metadata, specifically doubleword relocatable ADCONs. Peter's contention that I can mark a such program object as AMODE(24) and still LOAD it above the bar is entirely correct. I now tested it myself to make sure that it is. The wisdom of making use of the freedom to do so is nevertheless open to question. I think it is hubris. Others do not, and they are free to use AMODE(24) or AMODE(31) in this way. I am not a policeman. I should not wish to enforce a ban on their doing so even if, improbably, I could. 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: LOAD and DELETE macro instructions
In 2848527029300773.wa.paulgboulderaim@listserv.ua.edu, on 12/06/2012 at 03:49 PM, Paul Gilmartin paulgboul...@aim.com said: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on-write for one of the data sections. That's called fork(). No; fork is used to start a child process. What I'm talking about is a module that can be automatically shared between unrelated address spaces, with private copies of the writable data. Look at the linkage segment in Multics for an example of how that works elsewhere, although that particular implementation depends on architectural features missing from z. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On 12/6/2012 10:47 PM, Robert A. Rosenberg wrote: It is if the module contains relocatable doubleword pointers to locations within itself and these would not be resolved correctly if you just coded AMODE(31). Note that I am not sure what resolution would occur with AMODE(31) but the module residing above the bar - I am just suggesting that it is safer to code AMODE(64) even if AMODE(31) would still fill in the high word. AFAIK, program object fetch performs ADCON relocation without caring at all about the module's AMODE. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Could this be what you are wanting? I'm not sure. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/16.4 quote With the IARVSERV macro, you can define multiple types of data sharing and access. As you read this section, use Figure 16-1 in topic 16.1 to see how each IARVSERV parameter acts on the current state of the data. Each type of data sharing access is called a specific view of the source data. A view is the way your program accesses, or sees, the data. You define the view in the TARGET_VIEW parameter on IARVSERV, by specifying one of the following: Read-only view (READONLY value) -- where the target data may not be modified. Shared-write view (SHAREDWRITE value) -- where the target data can be read and modified through the view. Copy-on-write view (UNIQUEWRITE value) -- where the source data modifications are not seen by other source - sharing programs. Any attempt to modify the shared source data in this view causes MVS to create a unique target copy of the affected page for that address or data space. An example of two different cases: If the shared data is modified through a SHAREDWRITE view, the UNIQUEWRITE view gets an unmodified copy of the data. Any remaining views sharing that data see the modified data. If the shared data is modified through a UNIQUEWRITE view, the UNIQUEWRITE view gets the modified copy of the data. Any remaining views sharing that data see the unmodified data. Copy-on-write target view (TARGETWRITE value) -- where the target data may be read and modified through the source view. Any modification of a shared target page causes MVS to create a unique target copy of the affected page for that address or data space. An example for two different cases: If the shared data is modified through a SHAREDWRITE view, the TARGETWRITE view sees the modified data. If the shared data is modified through a TARGETWRITE view, the TARGETWRITE view sees the modified copy of the data. Any remaining views sharing that data see the unmodified data. /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, December 07, 2012 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LOAD and DELETE macro instructions In 2848527029300773.wa.paulgboulderaim@listserv.ua.edu, on 12/06/2012 at 03:49 PM, Paul Gilmartin paulgboul...@aim.com said: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on- write for one of the data sections. That's called fork(). No; fork is used to start a child process. What I'm talking about is a module that can be automatically shared between unrelated address spaces, with private copies of the writable data. Look at the linkage segment in Multics for an example of how that works elsewhere, although that particular implementation depends on architectural features missing from z. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: LOAD and DELETE macro instructions
I would rephrase Peter's formulation, (it better not have any 4-byte relocatable adcon's), slightly, changing it to it better be AMODE(64). I really did mean what I wrote. AMODE is irrelevant. The module is, after all, not executable in the case that is being discussed. And, in fact RMODE also is irrelevant. The module may identify RMODE 31 (or even RMODE 24) but if you provide an area above the bar, the system will happily load it there. It is in such cases that you might erroneously have a 4-byte adcon. (Ignoring of RMODE is an old behavior of LOAD with ADDR, continued onward for LOAD with ADDR64) It's kind of hard to squeeze an 8-byte relocated address above 4G into a 4-byte area. But the system will happily do what it can (just as it will for a 3-byte adcon for a module loaded above 16M). It is up to the user to do the right thing; the system will not protect (i.e., abend) this case, if I remember correctly. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Peter, I take your point, and I of course believe you when you say that you meant what you wrote (ands tghat you object to my faulty paraphrase). Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. IBM has an understandably long history of omitting to enforce some eminently reasonable constraint until that point in time at which it judges it appropriate to do so; and marking an object, even a read-only one, that is destined to reside above the bar as AMODE(31) is, I think, an act of hubris. One may well get away with it for a time, and even take pleasure in having done so; but whom the gods would destroy they first make proud. (Nemesis, In the retelling of the Greek myth by Robert Graves, keeps the list of such acts of hubris, finally meting out mercilous and terrtible punishments for them.) 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: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 10:44:43 -0500, John Gilmore wrote: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. Is there no RMODE(64)? This is complicated because programs may dynamically switch addressing modes in execution, and AMODE(64) with RMODE(31) seems a useful combination for programs which access above-the-bar data but need 4-byte VCONs to invoke existing services. Should there be an exception for paired +/- RLDs? Those should be algebraically valid for any module less than 2 GiB in size. Otherwise I believe such enforcement should be done by the Binder or even by the assembler, not deferred until ABEND at execution. IBM has an understandably long history of omitting to enforce some eminently reasonable constraint until that point in time at which it judges it appropriate to do so; and marking an object, even a read-only one, that is destined to reside above the bar as AMODE(31) is, I think, an act of hubris. And then prolonging the omission for the sake of compatibility with historic customer foolishness. For example, is REFRPROT yet not the default? How do you determine destined to reside? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In 8225406239778525.wa.paulgboulderaim@listserv.ua.edu, on 12/05/2012 at 04:51 PM, Paul Gilmartin paulgboul...@aim.com said: Yes. I can envision read-only data sections I can envision read-only modules containing a data section; I don't see any plausible reason for a split module with both a writable section and a read-only data section. Also the alternative you suggest: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on-write for one of the data sections. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 07:11:01 -0500, Shmuel Metz (Seymour J.) wrote: I can envision read-only modules containing a data section; I don't see any plausible reason for a split module with both a writable section and a read-only data section. Also the alternative you suggest: I wasn't endorsing it, just attempting to clarify what you had in mind. What I really want is a sharable split module with copy-on-write for one of the data sections. That's called fork(). (Well, sort of.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In CAE1XxDEaMWA=aMTmU8QXhzzeLKfPVCJUqgV=w5ycfgn+vz9...@mail.gmail.com, on 12/06/2012 at 10:44 AM, John Gilmore jwgli...@gmail.com said: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. AMODE(64) is not appropriate for a module that is not executable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Shmuel says: | AMODE(64) is not appropriate for a module that is not executable. Peter Relson---I am now wary of paraphrasing him---appears to judge that AMODE is moot for tables. I have said and say that AMODE(64) is not just appropriate but desirable for a read-only module that contains doubleword ADCONs. Take your pick; or consult an augur, who will to wield his lituus in helping you make your choice. 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: LOAD and DELETE macro instructions
Why put addresses in tables? One of my macros generates a table for glb- and lub-seeking binary-search operations. The lexicographic subscript of a bounding element is often of less interest than its entry sequence or another, arbitrary code value. This macro therefore optionally generates another table containing such values, making it accessible by providing its address. Or again, tabular-function tables are often compound ones containing two atomic tables, one of arguments and another of values, the addresses of both of which are stored in a stub. In general, there are many reasons for wishing to include addresses in generated tables, which can be and often are very much more complex in detail than hand-coded ones. 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: LOAD and DELETE macro instructions
I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. On Thu, Dec 6, 2012 at 5:19 PM, John Gilmore jwgli...@gmail.com wrote: Shmuel says: | AMODE(64) is not appropriate for a module that is not executable. Peter Relson---I am now wary of paraphrasing him---appears to judge that AMODE is moot for tables. I have said and say that AMODE(64) is not just appropriate but desirable for a read-only module that contains doubleword ADCONs. Take your pick; or consult an augur, who will to wield his lituus in helping you make your choice. 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Thu, 6 Dec 2012 18:09:37 -0600, Mike Schwab wrote: I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. Ever so slowly. I understand that 1.13 will let code run above the 4GiB (not 2) bar. (How does it get there?) It can even tolerate interrupts and redispatch from them. I suspect that from the developers' point that's a major advance. What goes in the IRB? Where does it keep the Grande OPSW? But no SVCs. Probably no system facilities understand 64-bit addresses. Likely the next step is SVCs, but the arguments will still need to reside below (even like access methods yet). The software bloat juggernaut will force IBM's hand. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
interrupted email resent Paul Gilmartin wrote: | But no SVCs. Probably no system facilities understand | 64-bit addresses. SVCs are at best obsolescent. We all perforce use them, but when I am beginning at square one I implement only PC-based schemes. - Show quoted text - -- John Gilmore, Ashland, MA 01721 - USA On 12/6/12, John Gilmore jwgli...@gmail.com wrote: Paul Gilmartin wrote: | But no SVCs. Probably no system facilities understand | 64-bit addresses. SVCs are obsolescent. We all perforce use them, but when I am beginning at sq On 12/6/12, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 6 Dec 2012 18:09:37 -0600, Mike Schwab wrote: I am wondering if z/OS 2.x will bring 64 bit address constants into the operating system so everything can run above the 2GB bar. Ever so slowly. I understand that 1.13 will let code run above the 4GiB (not 2) bar. (How does it get there?) It can even tolerate interrupts and redispatch from them. I suspect that from the developers' point that's a major advance. What goes in the IRB? Where does it keep the Grande OPSW? But no SVCs. Probably no system facilities understand 64-bit addresses. Likely the next step is SVCs, but the arguments will still need to reside below (even like access methods yet). The software bloat juggernaut will force IBM's hand. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA t. -- John Gilmore, Ashland, MA 01721 - USA t. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
At 17:04 -0500 on 12/06/2012, Shmuel Metz (Seymour J.) wrote about Re: LOAD and DELETE macro instructions: In CAE1XxDEaMWA=aMTmU8QXhzzeLKfPVCJUqgV=w5ycfgn+vz9...@mail.gmail.com, on 12/06/2012 at 10:44 AM, John Gilmore jwgli...@gmail.com said: Let me therefore take full responsibility for that paraphrase myself. AMODE(64) seems to me to be the only appreopiate way to mark an object that is to be resident above the bar, and in particular, one that while refreshable contains metadata, relocatable doubleword pointers to locations within itself. AMODE(64) is not appropriate for a module that is not executable. It is if the module contains relocatable doubleword pointers to locations within itself and these would not be resolved correctly if you just coded AMODE(31). Note that I am not sure what resolution would occur with AMODE(31) but the module residing above the bar - I am just suggesting that it is safer to code AMODE(64) even if AMODE(31) would still fill in the high word. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
All of PLPA is by definition refreshable. It implements exactly what refreshable means -- the storage might be refreshed (from its original state) at any point the system deems it appropriate to do so. If a page backing a PLPA is stolen, it is not at that point written to aux storage; writing of all LPA to aux was done during IPL (or a previous IPL possibly). When that page is needed, it is gotten from that previously-captured aux storage. This is the only part of the operating system that performs something akin to refresh for modules. You might view some control block refresh from a page-protected copy as refresh of data areas. Beyond that, to z/OS, refresh has meaning only to DIAGxx processing where you can ask, for testing purposes, that refreshable modules be page-protected. You cannot write into a refreshable module and get lasting results (as it might be refreshed at any time), so this is intended to stop even key 0 from incorrectly writing into it. Yes, I know that an authorized program can accomplish writing into the module by undoing the page protection, or by using stores using real address. So the question about refreshable modules is kind of moot. Or I am not understanding the intent. You can share modules by having them in common storage. RLDs are resolved at fetch time. End of story. Is there a service that will tell a priori the storage requirement of a load module, or must the programmer simply overrequest; LOAD, and free the excess? BLDL or DESERV, to access the directory entry, as Binyamin wrote. Within there is the information about the length. You use that information to obtain the storage. You then do a LOAD with ADDR and DE. Is there any prospect of above-the-bar LPA? 1.13 allows execution above- the-bar (with severe restrictions), and there should be no obstacle to keeping data above-the-bar beyond mere 64-bit savvy of the users. There is always a prospect, but there is no current likelihood. The obstacle is the cost to resolve the severe restrictions you rightly mention. It doesn't do any good to put code above the bar that wants to run but cannot meet the severe restrictions. It is already supported (z/OS 1.11) to do a LOAD with ADDR64 to an area above the bar for non-executable code if you have a data table module that you know can be above the bar (it better not have any 4-byte relocatable adcon's). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Peter Relson writes: begin extract It is already supported (z/OS 1.11) to do a LOAD with ADDR64 to an area above the bar for non-executable code if you have a data table module that you know can be above the bar (it better not have any 4-byte relocatable adcon's). end extract A number of the tables that I routinely LOAD above the bar are compound ones comprised of several atomic tables, not all of which are always present. The compound table's stub thus contains pointers to these atomic tables, and some of these pointers are sometimes nul. All of this now works for me after much less travail than I had expected. I would rephrase Peter's formulation, (it better not have any 4-byte relocatable adcon's), slightly, changing it to it better be AMODE(64). His point is in a certain sense, or at least ought to be, obvious; but that does not make it less important. Students, mine anyway, often fail to understand that AMODE is relevant for tables too. 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: LOAD and DELETE macro instructions
On Wed, 5 Dec 2012 09:31:03 -0500, John Gilmore wrote: I would rephrase Peter's formulation, (it better not have any 4-byte relocatable adcon's), slightly, changing it to it better be AMODE(64). His point is in a certain sense, or at least ought to be, obvious; but that does not make it less important. Students, mine anyway, often fail to understand that AMODE is relevant for tables too. Are you saying that of a 64-bit ADCON in a module loaded above the bar, only the lower 32 bits will be properly relocated unless the CSECT is declared AMODE(64)? Ouch! Is even a warning issued? Do the declared AMODE and RMODE affect the format of RLD entries output by the assembler? How does this affect compatibility with older products, evel HEWLKED? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Wed, 5 Dec 2012 10:16:46 -0500, John Gilmore wrote: I have been guilty of poking fun at some of the terminology used above the bar, but that should not be misunderstood. I would have named some things differently, but I have nothing but praise for the quality of the things themselves. In particular, they cohere unexpectedly well, making mostly reliable inferences about their behavior easy. It appears that the designers have learned well from experience. I enthusiastically await the day when the bar is erased and programmers can code entirely RMODE(64), oblivious to any antiquated 31-bit and 24-bit constraints. (Yes; imagine 64-bit addressability to PARM.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
Beyond that, to z/OS, refresh has meaning only to DIAGxx processing where you can ask, for testing purposes, that refreshable modules be page-protected. A minor correction: The documented REFRPROT option in PROGxx or SETPROG causes the full pages of REFR modules to be page-protected. This is intended for testing or production use. The undocumented CsvRentProtect trap name in DIAGxx causes the full pages of RENT modules to be page-protected. This is intended only for testing or diagnostic purposes. The undocumented CsvRentSP252 trap name in DIAGxx causes RENT modules to be loaded into subpool 252 (key 0) storage, regardless of whether or not they come from APF-authorized libraries. This is intended only for testing or diagnostic purposes. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In 7745356004468557.wa.paulgboulderaim@listserv.ua.edu, on 12/04/2012 at 08:49 AM, Paul Gilmartin paulgboul...@aim.com said: Does ADDR= require APF authorization? From z/OS MVS Programming: Authorized Assembler Services Reference, Volume 3(LLA-SDU), SA22-7611-11: Minimum authorization: Problem state or supervisor state, and any PSW key. The GLOBAL, EOM, ADDR, ADDR64, ADRNAPF and ADRNAPF64 parameters are restricted to authorized users (APF authorized, PSW key 0-7, or supervisor state). Is there a service that will tell a priori the storage requirement of a load module, BLDL. Can refreshable LOADed data sections be shared among address spaces or must each address space have a private copy? An authorized user can load a refreshable module into the [E]LPA; I don't know of any way to share a split module between address spaces. BTW, did you really mean refreshable *data* sections, as opposed to refreshable code sections with writable data sections?. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Wed, 5 Dec 2012 09:07:25 -0500, Shmuel Metz (Seymour J.) wrote: Does ADDR= require APF authorization? From z/OS MVS Programming: Authorized Assembler Services Reference, Volume 3(LLA-SDU), SA22-7611-11: Minimum authorization: Problem state or supervisor state, and any PSW key. The GLOBAL, EOM, ADDR, ADDR64, ADRNAPF and ADRNAPF64 parameters are restricted to authorized users (APF authorized, PSW key 0-7, or supervisor state). IOW, Yes. (I had checked; my question was largely rhetorical, prefacing my following sentence concerning the limited usefulness of the construct.) BTW, did you really mean refreshable *data* sections, as opposed to refreshable code sections with writable data sections?. Yes. I can envision read-only data sections so frequently used that it's worth avoiding the I/O overhead of loading them for each job that uses them. Also the alternative you suggest: sharable writable data sections. This likely presumes a locking mechanism; perhaps even entitlements, else you're back in the Dark Ages of User Key CSA. There may be a better way. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
In cae1xxdfvwjwpqze8jwh1fuqklsob2mddzvu6xz7puva+maf...@mail.gmail.com, on 12/02/2012 at 10:04 PM, John Gilmore jwgli...@gmail.com said: I concede this, whatever that may mean in this context since I also asserted it. What is important about such matched pairs of LOADs and DELETEs (or terminations) is that they ensure that a single copy of a sharable resource, a table or reentrant executable, can in fact be shared among tasks. No, what is important is that each address space has its own name space for loaded modules. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Mon, 3 Dec 2012 09:06:09 -0500, Peter Relson wrote: If you have data, use LOAD with ADDR having first obtained the storage in whatever subpool meets your needs. Does ADDR= require APF authorization? If so, the feature is of little avail to ordinary programmers? Is there a service that will tell a priori the storage requirement of a load module, or must the programmer simply overrequest; LOAD, and free the excess? Can refreshable LOADed data sections be shared among address spaces or must each address space have a private copy? If they can be so shared, how are RLDs handled? Can refreshable LOADED data sections be placed in LPA, in which case they should be sharable among address spaces? Java byte code might be a candidate for such treatment. With software bloat, is LPA becoming a virtual storage constraint? Is there any prospect of above-the-bar LPA? 1.13 allows execution above- the-bar (with severe restrictions), and there should be no obstacle to keeping data above-the-bar beyond mere 64-bit savvy of the users. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOAD and DELETE macro instructions
On Tue, 4 Dec 2012 08:49:01 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :On Mon, 3 Dec 2012 09:06:09 -0500, Peter Relson wrote: : :If you have data, use LOAD with ADDR having first obtained the storage in :whatever subpool meets your needs. :Does ADDR= require APF authorization? If so, the feature is of little :avail to ordinary programmers? GLOBAL=YES requires the same authorization. :Is there a service that will tell a priori the storage requirement of a :load module, or must the programmer simply overrequest; LOAD, and :free the excess? The directory has the information. :Can refreshable LOADed data sections be shared among address spaces :or must each address space have a private copy? If they can be so :shared, how are RLDs handled? No idea. :Can refreshable LOADED data sections be placed in LPA, in which case :they should be sharable among address spaces? Java byte code might :be a candidate for such treatment. Mo idea. :With software bloat, is LPA becoming a virtual storage constraint? Is :there any prospect of above-the-bar LPA? 1.13 allows execution above- :the-bar (with severe restrictions), and there should be no obstacle to :keeping data above-the-bar beyond mere 64-bit savvy of the users. -- 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: LOAD and DELETE macro instructions
What I did not mention in my reply to Peter Relson--He knows it--is that, while awareness is not automatic, it very easy to make any AS aware that something is in the CSA and to enable that AS to access it. I do, however, want to make it clear that my post was not part of a marketing campaign for GLOBAL=yes. Other techniques are certainly appropriate in many circumstances, perhaps even in most; and those who prefer them should use them. 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
LOAD and DELETE macro instructions
My recent acrimonious dispute with Shmuel here about these macros led me to re-examine and instrument the uses I had made of them in the past. As some regular IBM-MAIN participants know, one of my preoc-cupations for perhaps too many years has been with table generation, table-driven processing, and the shared, concurrent use of single copies of a (static, reassemble-to-change)) table in the same and different address spaces. In my use of them these tables are packaged as refreshable program objects, but they are not executed. They are instead examined. This use of them has made me particularly dependent upon LOAD and DELETE. (Read-only tables cannot be ATTACHed; or, perhaps better, they cannot be ATTACHed successfully; and I mark them OL to ensure that they cannot be.) Options are available for LOADing such tables into the [E]CSA, from which they can be accessed from, in principle, any address space; and I will confine myself here to talking about this case. Looking first at the time line for a single table AS1TL AS2TLAS2TDAS1TD ---|--|---|-|--- t0 t1 t2 t3 makes it clear that the statement in the IBM z/OS MVS Authorized Assembler Services manual) Any module loaded by a task will not be removed from virtual storage unless the task that loaded the module invokes the DELETE macro or terminates. that Shmuel made so much of is for this case a truism. The successive responsibility counts following times t0, t1, t2, t3 are just 1, 2, 1, 0. The scheme of incrementing the responsibility count by one for a LOAD, real or virtual, and decrementing this count by one for a DELETE ensures that no load module or program object LOADED by a task can be physically deleted until that task DELETEs it (or terminates). Consider now a second time line AS1TL AS2TLAS1TDAS2TD ---|--|---|-|--- t0 t1 t2 t3 Here the DELETE for the first, real LOAD precedes that for the second, virtual LOAD. Nevertheless the object is not deleted because there has not yet been a matching DELETE (or termination) for the second, virtual LOAD. For this case too—It is the only other one of interest—the statement quoted above is a truism. What this statement, which Shmuel quoted so vociferously, comes down to is that an object LOADed by a task will remain in storage until either 1) that task DELETEs it or 2) that task terminates. I concede this, whatever that may mean in this context since I also asserted it. What is important about such matched pairs of LOADs and DELETEs (or terminations) is that they ensure that a single copy of a sharable resource, a table or reentrant executable, can in fact be shared among tasks. I have here oversimplified things by talking only about task terminations. For a LOAD macro instructions that specifies GLOBAL=YES, thus targeting the CSA, the value of the EOM= key-word parameter complicates things. For EOM=YES the termination referenced is that of the address space. Only for EOM=NO is this termination task termination. Shmuel is very experienced and knowledgeable, but I have the impression---It is only that---that he no longer actually writes and tests much code. His dependence upon documentation then sometimes puts him at a disadvantage. It may even, as here, lead him astray. RYFM can be a helpful stricture, but what the manuals say needs to be refracted through current practice. 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
