Re: ** ASMA030E Invalid literal usage - =CL8'MARTINWH'
http://www-01.ibm.com/support/docview.wss?uid=isg1PK87960 From: Walt Farrell walt.farr...@gmail.com To: ASSEMBLER-LIST@listserv.uga.edu Date: 07/02/2012 07:44 AM Subject:Re: ** ASMA030E Invalid literal usage - =CL8'MARTINWH' Sent by:IBM Mainframe Assembler List ASSEMBLER-LIST@listserv.uga.edu Where are the LPP and HIS instructions described? I don't see them in the latest PoPs (-08) that I have. Thanks. -- Walt
Re: ** ASMA030E Invalid literal usage - =CL8'MARTINWH'
Walt, Where are the LPP described? I don't see them in the latest PoPs (-08) that I have. David Stokes posted the link to the documentation of these instructions. I haven't checked them en detail- they look like the ones I am using ...and HIS instructions HIS is hardware instrumentation service - a name picked for the z/OS part (it may be picked up for the VM part as well- I haven't checked that. Linux uses a different name). There are various SHARE presentations, redbooks and TC000-books (what they called?). I used TC66 and and the Share presentations from March 2012. The piece that good me intensive into this is the the fact that it does work now (with an APAR since August) for guests on VM as well. -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Detecting RMODE at assembly time
Perhaps some mainframe customer could prepare a business case why IBM should address the 24-bit VSCR issue. A SHARE requirement, anyone? Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore Sent: Saturday, June 30, 2012 4:20 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Detecting RMODE at assembly time My point was and is that a narrow notion of business case is what I called it, a self-defeating and crackpot-realist one. There were no insults, no ad hominem ones at least. The platform and the resources it makes available are superb. The uses that have been made of these new resources in the old systems under discussion are exiguous. The simplistic sundowner notion that all business systems should be rebuilt ab initio every five years would be a better and, yes, more economic one than the current, if it ain't broke don't fix it, doctrine. But enough. The problem is a self-correcting one. The shops running trailing-edge AMODE(24) applications and the like are the ones that are disappearing; and they are the ones that deserve to disappear, although they are usually being replaced only by something different, not better. --jg
Re: Detecting RMODE at assembly time
On Jul 2, 2012, at 07:35, McKown, John wrote: I truly wish that the DFSMS people had the justification they needed to take the time to extend ACB mode processing to sequential datasets (QSAM/BSAM) and BPAM. But I guess there are a lot of 3-byte addresses still existing behind-the-sceens (such as the DEB to DCB pointer). Wouldn't a wholehearted extension of ACB mode processing entirely bypass the DCB and its 24-bit strictures? But wouldn't existing QSAM/BSAM/BPAM programs require massive modifications to exploit this? Regardless, nowadays, any 24-31 bit conversion is underreaching; shortsighted; mostly wasted resource. Go for 64! Even while RMODE 64 execution is mostly unsupported, the 64-bit interfaces can be coded and the code run AMODE 64 below the bar in the interim. If we had some ham we could have ham and eggs, if we had some eggs. -- gil
Re: Detecting RMODE at assembly time
For one thing, if a page has not been modified since it was paged in, and it's slot on backing store has not been reused, it can be assigned to another address space without first writing it to disk. I believe this is called page-stealing. On Mon, Jul 2, 2012 at 10:14 AM, Edward Jaffe edja...@phoenixsoftware.comwrote: On 7/1/2012 7:03 PM, Alex Kodat wrote: Sorry but I don't understand what re-entrancy has to do with how storage is backed. Care to explain? I was referring to the practice of using GETMAIN to acquire working storage areas. This technique is most often employed by RENT programs. Also, I assume by have no control over the backing of storage you meant that most older programs don't specify the required backing for their GETMAIN? No. I meant that programs don't have control over where the storage, into which they are loaded by the contents supervisor, is backed. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.**com/ http://www.phoenixsoftware.com/ -- OREXXMan
Re: Detecting RMODE at assembly time
Paul Gilmartin wrote begin extract Regardless, nowadays, any 24-31 bit conversion is underreaching; shortsighted; mostly wasted resource. Go for 64! Even while RMODE 64 execution is mostly unsupported, the 64-bit interfaces can be coded and the code run AMODE 64 below the bar in the interim. /end extract This is a sentiment that I agree with strongly. It is, moreover, my own practice. Why then didn't I advocate it in my earlier posts in this thread? I took the temporizing position that AMODE(24) routines should be converted to AMODE(31) ones instead. Cowardice? Perhaps in some measure, but I had the strong sense that it would be a futile gesture to recommend AMODE(64). It often seems to me---Witness the neanderthal reactions to even that recommendation---that trailing-edge shops are emotionally unprepared to respond to technical imperatives. At most and not always they may be willing to take faltering baby steps in one of the right directions. I did learn something from this experience. I shall do no more temporizing. John Gilmore, Ashland, MA 01721 - USA
Re: Detecting RMODE at assembly time
-Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore Sent: Monday, July 02, 2012 9:37 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Detecting RMODE at assembly time Paul Gilmartin wrote begin extract Regardless, nowadays, any 24-31 bit conversion is underreaching; shortsighted; mostly wasted resource. Go for 64! Even while RMODE 64 execution is mostly unsupported, the 64-bit interfaces can be coded and the code run AMODE 64 below the bar in the interim. /end extract This is a sentiment that I agree with strongly. It is, moreover, my own practice. Why then didn't I advocate it in my earlier posts in this thread? I took the temporizing position that AMODE(24) routines should be converted to AMODE(31) ones instead. Cowardice? Perhaps in some measure, but I had the strong sense that it would be a futile gesture to recommend AMODE(64). It often seems to me---Witness the neanderthal reactions to even that recommendation---that trailing-edge shops are emotionally unprepared to respond to technical imperatives. At most and not always they may be willing to take faltering baby steps in one of the right directions. I did learn something from this experience. I shall do no more temporizing. John Gilmore, Ashland, MA 01721 - USA I will say that my shop, which is small and shrinking, is mainly AMODE(31). Of course, that's because 95+% of all applications are COBOL based. 4+% of the remainder are EasyTrieve Plus, and I think we have maybe 10 HLASM subroutines. And we will become AMODE(64) when: (1) COBOL supported and (2) we are __forced__ to upgrade the compiler. The __forced__ in the previous is because we are on 3.4 and won't go to 4.1 due to the price increase. I, personally, use AMODE(31)/RMODE(ANY) for most of my code, except for that which RMODE(24) is required. Which I bundle into a subroutine. Some would say this proves that using an HLL is inherently superior than HLASM. I would likely agree for business applications. Definitely not true if we were capable of real time processing. -- 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
Re: Detecting RMODE at assembly time
On 7/1/2012 7:03 PM, Alex Kodat wrote: As far as requiring smarts to see out eligible GETMAINs, my point was that it shouldn't require any. Heck, even I was able to change all our storage allocations years ago to use 64-bit backing and haven't ever had a problem resulting from that. I can assure you that I don't have the smarts to look for eligible GETMAINs as I wouldn't even know what to look for. What would I look for? As part of our RSCR effort many years ago, we changed all of our GETMAIN and STORAGE OBTAIN requests to back everything in 64-bit real. Everything seemed to work fine at first, but eventually failed when some of the code was executed in an LPAR with 2G of real. We found numerous occurrences of code that needed to be enhanced to use LRAG instead of LRA. (IIRC, some were real-mode channel programs, some were PR/SM DIAGNOSE, some were VM DIAGNOSE. There may have been others.) This had to be done conditionally, since at the time we still supported ESA/390 architecture. This is why I mentioned 'eligible' GETMAINs. Naturally, I highly recommend LOC=(xx,64) be specified whenever possible. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
Re: DS 0H
Looks like ORG's alignment is unconditional so it may generate different offsets from CNOP when the location counter is already correct. D-LocObject Code Addr1Addr2Stmt Source Statement 0010 1 TEST1DSECT 2 BEFORE1 DSXL10 000A 3 CNOP 2,8 000A 4 RNAME1 DS0CL6 000A 5 ASID1DSH 000C 6 ADDR1DSF 7 * 0018 8 TEST2DSECT 9 BEFORE2 DSXL10 000A000A 0012 10 ORG *,8,2 0012 11 RNAME2 DS0CL6 0012 12 ASID2DSH 0014 13 ADDR2DSF 14 * 0010 15 TEST3DSECT 16 BEFORE3 DSXL10 000A000A 000A 17 ORG *,8,-6 000A 18 RNAME3 DS0CL6 000A 19 ASID3DSH 000C 20 ADDR3DSF 21 * 0010 22 TEST4DSECT 23 BEFORE4 DSXL11 000B000B 000A 24 ORG *,8,-6 000A 25 RNAME4 DS0CL6 000A 26 ASID4DSH 000C 27 ADDR4DSF 28 END Robert Ngan CSC Financial Services Group From: John Ehrman ehr...@us.ibm.com To: ASSEMBLER-LIST@listserv.uga.edu Date: 2012/06/14 13:01 Subject:Re: DS 0H Sent by:IBM Mainframe Assembler List ASSEMBLER-LIST@listserv.uga.edu Tom Marchant included this code fragment: CNOP 2,8 RNAMEDS0CL6 ASID DSH ADDR DSF Since this is defining data fields, ORG may be more appropriate than CNOP (which is intended for instruction streams): ORG *,8,2 RNAMEDS0CL6 ASID DSH ADDR DSF John Ehrman
Re: Detecting RMODE at assembly time
As Tom Marchant has already pointed out, Hobart Spitz's view of page stealing is mistaken. Perhaps even more important his view of how the ASM [Auxiliary Storage Manager] works is also mistaken. No page that has not been modified is paged out. (One of the minor but important merits of reentrant coding is/was that by segregating never paged-out code pages and frequently paged-out data pages it reduces paging overheads significantly.) His post did have the virtue of reviving the [predominantly British] term 'backing store' which has always seemed to be to be a very good, self-descriptive one, the wider of which is now unfortunately all but precluded by other, different and preemptive, uses of the too similar term 'backing storage'. John Gilmore, Ashland, MA 01721 - USA
Re: Detecting RMODE at assembly time
Thanks for the corrections. On Mon, Jul 2, 2012 at 2:29 PM, John Gilmore jwgli...@gmail.com wrote: As Tom Marchant has already pointed out, Hobart Spitz's view of page stealing is mistaken. Perhaps even more important his view of how the ASM [Auxiliary Storage Manager] works is also mistaken. No page that has not been modified is paged out. (One of the minor but important merits of reentrant coding is/was that by segregating never paged-out code pages and frequently paged-out data pages it reduces paging overheads significantly.) His post did have the virtue of reviving the [predominantly British] term 'backing store' which has always seemed to be to be a very good, self-descriptive one, the wider of which is now unfortunately all but precluded by other, different and preemptive, uses of the too similar term 'backing storage'. John Gilmore, Ashland, MA 01721 - USA -- OREXXMan
