Re: The 64-bit version of LOOK from CBT File 264 is finally out

On Thu, 4 Apr 2019 20:33:36 +0300, Binyamin Dissen wrote: >What does this give over IPCS of ACTIVE? > My question exactly, too. >Joseph Reichmann answered: "Going thru control blocks specially if there is >eyecatcher and it formats it >Makes it real easy to go thru control blocks " Well, IPCS

Re: z114 and z/OS 2.3

That only applies for 2.3 directly on the LPAR, you can run it under z/VM with no issues. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Hillgang - 26 April - Details

http://www.vm.ibm.com/events/hill0419.pdf Neale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

I certainly don't understand all of IBM's Z strategy, but I can tell you pretty good certainty that IBM has zero interest in investing 1¢ in z/OS enhancements to facilitate the use of pre-Z hardware. Heck, V2R3 doesn't even support a z196! Charles -Original Message- From: IBM Mainfram

Hillgang Meeting - 26 April

Mark your calendars for the next Hillgang meeting to be held in the Broadcom offices in Herndon Virginia. Our agenda is chock full of mainframe goodness: * zVPS Version 5 does z/OS and more… – Barton Robinson, Velocity Software * Using Your Performance Monitor to Watch z/VM and Linux on

Re: z114 and z/OS 2.3

Thanks Jim, much appreciated! On Wed, Apr 3, 2019 at 8:53 PM Jim Stefanik wrote: > The documentation is correct. Anything older than EC12 (or BC12) will drop > to a wait state. I've tried it on a z196 and almost instantly get a wait. > > > > --- > > Jim Stefanik > Dallas Vintage Computing Center

Re: AMODE 32

On Thu, 4 Apr 2019 19:32:01 +, Martin Packer wrote: >They will be (running 64-bit). However, apart from Db2*, much of their >virtual storage components can't tolerate being above the bar. Which virtual storage components can't tolerate being above the bar, and why is that and what would nee

Re: AMODE 32

They will be (running 64-bit). However, apart from Db2*, much of their virtual storage components can't tolerate being above the bar. Consider Db2's 64-bit evolution in V8 then V9 then V10. * Even Db2 has some below-the-bar usage. Martin Packer zChampion, Systems Investigator & Performance Tro

Re: The 64-bit version of LOOK from CBT File 264 is finally out

How os the 32-bit version working?? Hi Folks,     It worked out well that we had the previous problem when incorrect ASID's were over-typed in LOOKN.  Turns out that LOOKJ (the 31-bit version) had the same issue, and we just fixed it there, too.     I just reloaded File 264 to the https://n

The 64-bit version of LOOK from CBT File 264 is finally out

Hi Folks,     It worked out well that we had the previous problem when incorrect ASID's were over-typed in LOOKN.  Turns out that LOOKJ (the 31-bit version) had the same issue, and we just fixed it there, too.     I just reloaded File 264 to the www.cbttape.org Updates page, and also File 03

Re: AMODE 32

On Thu, 4 Apr 2019 12:59:03 -0500, Mike Schwab wrote: >A lot of installations run multiple CICS / IMS / DB2 regions because >one or two 2GiB regions is not nearly enough. Why are they not running as 64-bit? BFN. Paul. -- For I

Re: AMODE 32

On Thu, 4 Apr 2019 18:14:48 +, Seymour J Metz wrote: >Existing programs will be using VL, Not always. It is relatively rare to take a variable number of parameters. > so you're talking a total rewrite to exploit AMODE32. No, fairly minor changes, not a rewrite. > How is that short-term fi

Re: AMODE 32

Existing programs will be using VL, so you're talking a total rewrite to exploit AMODE32. How is that short-term fix advantageous? It's just as easy to go directly to 64 bit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe D

Re: AMODE 32

A lot of installations run multiple CICS / IMS / DB2 regions because one or two 2GiB regions is not nearly enough. JAVA does offer an option to run from 2GiB to 8GiB using 4 bit pointers that are shifted 3 bits to a multiple of 8 bytes. Almost no one uses this because the shifting slow down every

Re: AMODE 32

On Thu, 4 Apr 2019 17:45:27 +, Seymour J Metz wrote: >> I don't agree. Existing applications can be >> modified to be 32-bit clean > >Only if the never use storage above the line for parameters. Or they don't use VL, the same requirement that AM64 has. BFN. Paul. --

Re: AMODE 32

On Thu, 4 Apr 2019 10:31:16 -0500, Paul Edwards wrote: >Because it invalidates all old hardware. An >AM32 program can still run as AM31 on old >hardware, or even AM24 on very old >hardware. Oh, so you want to enhance the architecture on "very old hardware". And make a corresponding enhancement t

Re: AMODE 32

> It would set the long-term model for the > mainframe, instead of being stuck with > 24/31-bit software for eternity. 32 bit mode would have been a good idea in the initial S/360 design, and IMHO its lack was a serious blunder. Shoehorning it into the existing software at this point in time wou

Re: AMODE 32

I suggest we all stop feeding the Bear! ::DISCLAIMER:: --

Re: The 64-bit version of LOOK from CBT File 264 is finally out

Going thru control blocks specially if there is eyecatcher and it formats it Makes it real easy to go thru control blocks > On Apr 4, 2019, at 1:33 PM, Binyamin Dissen > wrote: > > What does this give over IPCS of ACTIVE? > > On Wed, 3 Apr 2019 16:29:05 -0400 Sam Golob wrote: > > :> I'

Re: AMODE 32

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Binyamin Dissen > Sent: 04 April, 2019 13:43 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: AMODE 32 > > On Thu, 4 Apr 2019 06:19:50 -0500 Paul Edwards > wrote: > > :>On Thu, 4 Apr

Re: The 64-bit version of LOOK from CBT File 264 is finally out

What does this give over IPCS of ACTIVE? On Wed, 3 Apr 2019 16:29:05 -0400 Sam Golob wrote: :>     I'm happy to announce that the 64-bit version of the LOOK program :>from CBT File 264 is finally out, on the Updates page of :>www.cbttape.org.  It has been a long time in coming. :>     Now you

Re: AMODE 32

The question is not what people would like to see, but whether there is a reasonable way to get there. I would have like S/360 to have used 32 bit addresses with a must be zero (MBZ) reqirement on the high bits and a software convention for the end of the parameter list that did not involve turn

Re: AMODE 32

On Thu, 4 Apr 2019 10:31:16 -0500 Paul Edwards wrote: :>On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen wrote: :>>Sounds like a pretty narrow range of applications, where the existing above :>>the line is not enough, but an extra 2G will be enough forever. :>It's sometimes not a matter of

Re: When is an automatic DETACH issued for an IARV64 SHAREMEMOBJ?

Was there a change in 2.3 that incorrectly caused task end to do a DETACH? Please confirm. On Thu, 4 Apr 2019 11:19:56 -0500 Steven Partlow wrote: :>On further investigation, SHAREMEMOBJ is also cleaned up at task term of the task that issued the SHAREMEMOBJ. Therefore, job step end would also

Re: RACROUTE S0C4 abend when using MSGRTRN=YES option

Hi responders, The solution was as simple as using MSGSP=127 instead of the defaulted MSGSP=0. Thanks to all who responded. Cheers SteveB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...

The 64-bit version of LOOK from CBT File 264 is finally out

Hi Folks,     I think we fixed the problem.  We were checking the validity of the over-typed ASID, and when it was wrong, it was possible to feed a wrong ASID into the SRB that gets the data from the other address space.  The fix was, that in the case of an error when the ASID was being over-

Re: When is an automatic DETACH issued for an IARV64 SHAREMEMOBJ?

On further investigation, SHAREMEMOBJ is also cleaned up at task term of the task that issued the SHAREMEMOBJ. Therefore, job step end would also clean it up. We'll fix that. -- For IBM-MAIN subscribe / signoff / archive access

Re: AMODE 32

" As far as I am aware, if you do a: CALL xxx,VL to set the high bit to signify end of parameter list, then if the target is operating in AM64, it will fail with a S0C4." Nope. You will get this error: 12,*** IHB280 VL INVALID WITH 8_BYTE_ENTRY_PLIST Joe On Thu, Apr 4, 2019 at 11:18 AM Paul E

Re: DFSORT ICE085A - Options?

>> Was it a single IFTHEN? Martin, Yes. A Single IFTHEN=(WHEN=INIT >> Also, I suppose that IFTHEN, being relatively new, might’ve had a different implementation. True. >>But I don’t know and I doubt this kind of internal is something Sri Hari would feel free to talk about. You read my mind.

Re: AMODE 32

On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen wrote: >Sounds like a pretty narrow range of applications, where the existing above >the line is not enough, but an extra 2G will be enough forever. It's sometimes not a matter of "not enough" so much as "capability". E.g. a 32-bit editor is ca

Re: AMODE 32

I'm sorry I don't understand your technical point. Could you rephrase? As far as I am aware, if you do a: CALL xxx,VL to set the high bit to signify end of parameter list, then if the target is operating in AM64, it will fail with a S0C4. BFN. Paul. On Thu, 4 Apr 2019 15:12:24 +, Gene Hu

Re: AMODE 32

Again I am sorry but at this point I believe you cannot issue a CALL for a program in 64 bits. I do nothing when switching back and forth with my CALLs. In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time, mutazi...@gmail.com writes: On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders

Re: AMODE 32

On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders wrote: > I'm sorry, but I don't have to make any changes > to my 31 bit programs using CALLs and using > 64-bit addressing. We have lots of programs > doing both AM31 and AM64 with the only change > is the instructions to change the addressing mode.

Re: AMODE 32

I'm sorry, but I don't have to make any changes to my 31 bit programs using CALLs and using 64-bit addressing. We have lots of programs doing both AM31 and AM64 with the only change is the instructions to change the addressing mode. Do you realize how many user programs that have CALLs embedded

Re: AMODE 32

On Thu, 4 Apr 2019 09:33:46 -0500, Tom Marchant wrote: >>The BSM instruction can use bit x'4000 ' >>to get/set AM32. > >No, it can't, for compatibility reasons. What are you referring to? I don't see any compatibility problem. >>This introduces a 1 GiB >>restriction where the module should

Re: AMODE 32

On Thu, 4 Apr 2019 14:22:16 +, Gene Hudders wrote: > How is the system going to interpret the X'80' > used to indicate the end of a CALL parameter list. This is one of the 32-bit changes, the same as needs to be done if using AM64. There is a set of changes that need to be done when going f

Re: AMODE 32

On Wed, 3 Apr 2019 18:17:46 -0500, Paul Edwards wrote: >I was thinking that z/Arch and z/OS could >be updated to support AMODE 32. Not again. You brought up something similar last year. It was a ridiculous idea then and it still is. You were told then that your proposal would be rejected, and

Re: AMODE 32

On Thu, Apr 4, 2019 at 10:17 AM Binyamin Dissen wrote: > My guess is the OP is married to 4 byte pointers. You've met his wife? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv

Re: AMODE 32

How is the system going to interpret the X'80' used to indicate the end of a CALL parameter list. Today you just load it into a register and use it because it is interpreted as a 31 bit address. If you are using AM32, this address is not the one you want. and would require adding code to elimina

Re: AMODE 32

The issue is not the likeliness of it happening. I don't really see a business case for this. If a program already needs 12.G of data, why do special development which will have a hard cap of 3.2G especially when the availability of much more is commonly available? My guess is the OP is married t

Re: AMODE 32

+1 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv..ua.edu] On Behalf Of Don Poitras Sent: Thursday, April 4, 2019 4:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AMODE 32 In article <8891162166296907.wa.mutazilahgmail@listserv.ua.edu> you

Re: AMODE 32

Prepare a business case and submit it to IBM. I don’t think this list wants to spend a lot of time on something extremely unlikely to happen. Cheers, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Edwards Sent: Thursday, April 4, 2019 8:23 AM To: IBM-MAIN@LIST

Re: AMODE 32

On Thu, 4 Apr 2019 13:19:03 +, Martin Packer wrote: >OK, I'll try... > >... Presumably you'd want this putative 32-bit address space to have >access to all the stuff other address spaces have access to, such as >Shared/Common areas above the bar. No, I'd like current data above the 2 GiB ba

Re: AMODE 32

OK, I'll try... ... Presumably you'd want this putative 32-bit address space to have access to all the stuff other address spaces have access to, such as Shared/Common areas above the bar. Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 emai

Re: AMODE 32

On Thu, 4 Apr 2019 12:54:28 +, Martin Packer wrote: > Plus, how would you map Shared or > Common/System 64-Bit objects into such > an address space? I don't understand this technical question. Can you rephrase? BFN. Paul. --

Re: AMODE 32

And please don't tell me you'd want Db2, IMS, CICS, MQ, Websphere Application Server to have been 32-bit. Many other things want scalability beyond 4GB (minus "common"). Plus, how would you map Shared or Common/System 64-Bit objects into such an address space? Martin Packer zChampion, Systems

Re: AMODE 32

On Thu, 4 Apr 2019 07:46:59 -0400, Don Poitras wrote: > When you brought this up a year ago, I don't think you convinced anyone > that this was a useful change or that IBM should reasonably spend > dollars doing it. I doubt much has changed since then to improve your > chances. Last time I was t

Re: AMODE 32

" I don't agree that all new applications should be 64 bit. That is overkill. 32-bit/4 GiB should be enough for almost all commercial applications." "According to the analyst deck circulated with the latest set of quarterly financ

Re: AMODE 32

" I don't agree that all new applications should be 64 bit. That is overkill. 32-bit/4 GiB should be enough for almost all commercial applications." The market disagrees with you, as shown by 64-bit z/arch sales. Joe On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards wrote: > On Thu, 4 Apr 2019 13:55

Re: AMODE 32

In article <8891162166296907.wa.mutazilahgmail@listserv.ua.edu> you wrote: > On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen > wrote: > >What problem would this solve? > It would set the long-term model for the > mainframe, instead of being stuck with > 24/31-bit software for eternity. > >

Re: AMODE 32

On Thu, 4 Apr 2019 06:19:50 -0500 Paul Edwards wrote: :>On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen wrote: :>>What problem would this solve? :>It would set the long-term model for the :>mainframe, instead of being stuck with :>24/31-bit software for eternity. 24/31 is required for dow

The 64-bit version of LOOK from CBT File 264 is finally out

Hi Folks,     For now, LOOKN is in Beta status.  It seems to work fine in regular operation, but for now, don't try to switch to an invalid or inactive ASID.  We'll try and fix the issue as soon as we can.     Thanks for bearing with us. Sincerely,   Sam

Re: AMODE 32

On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen wrote: >What problem would this solve? It would set the long-term model for the mainframe, instead of being stuck with 24/31-bit software for eternity. >This would be of zero use for existing applications, I don't agree. Existing applications

Re: RACROUTE S0C4 abend when using MSGRTRN=YES option

RACF was kind enough to provide you with a dump. Why not examine it to see what caused the abend? BTW, I have used MSGRTRN for years. On Thu, 4 Apr 2019 03:02:36 -0500 Steve Bagshaw wrote: :>Hi Team :> :>I have this RACROUTE definition in my code: :>" :>RACROUTE REQUEST=AUTH,

Re: AMODE 32

What problem would this solve? This would be of zero use for existing applications, and new applications should simply use 64 bit. On Wed, 3 Apr 2019 18:17:46 -0500 Paul Edwards wrote: :>I was thinking that z/Arch and z/OS could :>be updated to support AMODE 32. :>If a load module is marked AM

Re: When is an automatic DETACH issued for an IARV64 SHAREMEMOBJ?

Thus if a TSO user or STC does a SHAREMEMOBJ to a memory object owned by an STC, the DETACH would automatically be done by MEMTERM while if a batch job when the initiator is returned to, i.e., step end? Just want to confirm my understanding. On Wed, 3 Apr 2019 16:27:53 -0500 Steve Partlow wrote:

Re: RACROUTE S0C4 abend when using MSGRTRN=YES option

Steve, I looks like you have omitted the MSGSP parameter, which means you have defaulted to subpool 0. What PSW key is your program executing in? Do you have the output from IPCS STATUS ? Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of S

Re: AMODE 32

"PSW bit 30 can be used to signify that an application is running AM32." Whats the ROI to the customer for IBM spending the $$$ to research and modify all of the micro/macro/OS code to allow bit 30 to be anything other than 0? You have to realize that the prices are going to increase to cover tho

RACROUTE S0C4 abend when using MSGRTRN=YES option

Hi Team I have this RACROUTE definition in my code: " RACROUTE REQUEST=AUTH, ATTR=READ, CLASS=DSA_CLASS, ENTITYX=DSA_ENTITYX, GENERIC=ASIS,

VSMLIST in a PC-ss routine

I'm hoping to use the VSMLIST service in a PC-ss routine running in primary mode to get the unallocated private areas of the secondary address space. Is this possible, or will the call below just give me the private areas of the primary? Thanks Steve VSMLIST SP=PVT,WKAREA=((R2),(R3)),SPACE=U