date:20190404

"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 those
costs from IBMs point of view... Its not a one man job to allow that to
happen.

Joe

On Wed, Apr 3, 2019 at 7:18 PM 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 AMODE ANY,
> RMODE ANY it could signify that it is
> 32-bit clean. That combination is
> currently not really used, and the linker
> can be updated to accept this combination.
>
> PSW bit 30 can be used to signify that an
> application is running AM32.
>
> The BSM instruction can use bit x'4000 '
> to get/set AM32. This introduces a 1 GiB
> restriction where the module should not
> be loaded above if it needs to switch
> AMODEs to call READ etc. But that's another
> restriction that could be lifted in z/OS.
> z/OS can instead switch to AM31 itself,
> with the READ code being located below 1 GiB.
>
> BFN. Paul.
>
> --
> 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: RACROUTE S0C4 abend when using MSGRTRN=YES option

2019-04-04 Thread Rob Scott

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 
Steve Bagshaw
Sent: Thursday, April 4, 2019 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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,
  LOG=ASIS,
  MSGSUPP=NO,
  MSGRTRN=NO,
  RELEASE=77B0,
  WORKA=DSA_RACROUTE_WA,
  MF=(E,DSA_RACROUTE_PL)
"

which works absolutely fine and shows me the expected result:
"
 ICH408I USER(IBMUSER1) GROUP(TEST) NAME(IBMUSER CLONE #1)  636
   XXX.XXX.U.XXX CL(FACILITY)
   WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED
   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
"

However if I change it to use MSGRTRN=YES then I get this:

"
 ICH408I USER(IBMUSER1) GROUP(TEST) NAME(IBMUSER CLONE #1)  636
   XXX.XXX.U.XXX CL(FACILITY)
   WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED
   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )

 IEA794I SVC DUMP HAS CAPTURED:  639
 DUMPID=012 REQUESTED BY JOB (IBMUSERZ)
 DUMP TITLE=ICHRST00-RACF SVCS,ABEND CODE=0C4-004,SVC=IRRRCK00,U
SER=IBMUSER1,GROUP=TEST
*ICH409I 0C4-004 ABEND DURING RACHECK PROCESSING
"

The ICH408I message is correct, but I cannot understand why the S0C4 occurs .. 
unless there is a known issue with RACF in this area.

This is on a z/OS 2.3 System (our zPDT Develpment System) and the RACF level is 
z/OS 02.03.00.

I have searched the www looking for clues, but found nothing.

Have anyone else had this or know of this issue?

Cheers
Steve Bagshaw

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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:

:>The SHAREMEMOBJ is cleaned up at address space termination (or if explicitly 
detached with AFFINITY=LOCAL). GETSHARED requests are never automatically 
cleaned up and must be explicitly detached with AFFINITY=SYSTEM. The memory is 
finally freed when all local and system requests have detached (explicitly or 
automatically).

--
Binyamin Dissen 
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: 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 AMODE ANY,
:>RMODE ANY it could signify that it is
:>32-bit clean. That combination is
:>currently not really used, and the linker
:>can be updated to accept this combination.

:>PSW bit 30 can be used to signify that an
:>application is running AM32.

:>The BSM instruction can use bit x'4000 '
:>to get/set AM32. This introduces a 1 GiB
:>restriction where the module should not
:>be loaded above if it needs to switch
:>AMODEs to call READ etc. But that's another
:>restriction that could be lifted in z/OS.
:>z/OS can instead switch to AM31 itself,
:>with the READ code being located below 1 GiB.

--
Binyamin Dissen 
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: 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, 
:>  ATTR=READ,   
:>  CLASS=DSA_CLASS, 
:>  ENTITYX=DSA_ENTITYX, 
:>  GENERIC=ASIS,
:>  LOG=ASIS,
:>  MSGSUPP=NO,  
:>  MSGRTRN=NO, 
:>  RELEASE=77B0,
:>  WORKA=DSA_RACROUTE_WA,   
:>  MF=(E,DSA_RACROUTE_PL)   
:>"
:>
:>which works absolutely fine and shows me the expected result:
:>"
:> ICH408I USER(IBMUSER1) GROUP(TEST) NAME(IBMUSER CLONE #1)  636 
:>   XXX.XXX.U.XXX CL(FACILITY)   
:>   WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED   
:>   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )  
:>"
:>
:>However if I change it to use MSGRTRN=YES then I get this:
:>
:>"
:> ICH408I USER(IBMUSER1) GROUP(TEST) NAME(IBMUSER CLONE #1)  636 
:>   XXX.XXX.U.XXX CL(FACILITY)   
:>   WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED   
:>   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )  
:> 
:> IEA794I SVC DUMP HAS CAPTURED:  639
:> DUMPID=012 REQUESTED BY JOB (IBMUSERZ) 
:> DUMP TITLE=ICHRST00-RACF SVCS,ABEND CODE=0C4-004,SVC=IRRRCK00,U
:>SER=IBMUSER1,GROUP=TEST 
:>*ICH409I 0C4-004 ABEND DURING RACHECK PROCESSING
:>"
:>
:>The ICH408I message is correct, but I cannot understand why the S0C4 occurs 
.. unless there is a known issue with RACF in this area.

:>This is on a z/OS 2.3 System (our zPDT Develpment System) and the RACF level 
is z/OS 02.03.00.  

:>I have searched the www looking for clues, but found nothing.

Look at the dump. When your code causes an abend, it is quite likely that you
did something wrong.

:>Have anyone else had this or know of this issue?

--
Binyamin Dissen 
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: 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 can be
modified to be 32-bit clean and have maximum
possible address space as per 32-bit.

> and new applications should simply use 64 bit.

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.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Sam Golob


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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 downward compatibility.

If you need to change application and you need this much storage, go already
to 64bit. You will need it sooner or later.

:>>This would be of zero use for existing applications,

:>I don't agree. Existing applications can be
:>modified to be 32-bit clean and have maximum
:>possible address space as per 32-bit.

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.

:>> and new applications should simply use 64 bit.

:>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.

Why do you feel 64bit is "overkill"?

--
Binyamin Dissen 
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: AMODE 32

2019-04-04 Thread Don Poitras

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.
> >This would be of zero use for existing applications,
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
> > and new applications should simply use 64 bit.
> 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.
> BFN. Paul.

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.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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 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:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> 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 can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> 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.
>
> BFN. Paul.
>
> --
> 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: 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 financials, the IBM Z mainframe business,
listed under its ‘systems segment’ has doubled year-on-year, pulling in a
tidy US$2.2 billion ($2.96 billion)

Overall revenue rose nearly 4 percent to US$20 billion ($26.9 billion),
beating analysts’ average estimate of $19.85 billion ($26.7 billion),
according to Thomson Reuters I/B/E/S."

https://www.itnews.com.au/news/mainframe-sales-double-in-latest-ibm-profit-498679

Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> 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 can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> 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.
>
> BFN. Paul.
>
> --
> 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: 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 trying to add a LOC=32
to GETMAIN for use by AMODE 64 programs.

This time I want to retain normal LOC=ANY
for GETMAIN, and introduce a new AMODE 32.

Previously I didn't have a practical way of
adding AM32. It is only recently that I
realized that bits 1-7 of a 32-bit register
could be used by BSM.

I thought more people would like to see a
long-term z/OS that ran purely 32-bit and
64-bit software like other platforms do.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Martin Packer

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 Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Joe Monk 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 13:40
Subject:Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



" 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 financials, the IBM Z mainframe business,
listed under its ‘systems segment’ has doubled year-on-year, pulling in a
tidy US$2.2 billion ($2.96 billion)

Overall revenue rose nearly 4 percent to US$20 billion ($26.9 billion),
beating analysts’ average estimate of $19.85 billion ($26.7 billion),
according to Thomson Reuters I/B/E/S."

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.itnews.com.au_news_mainframe-2Dsales-2Ddouble-2Din-2Dlatest-2Dibm-2Dprofit-2D498679&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=pgxF-yzofWwOBNCorbSZ62a_LiKMJSrCnFacr93Bx6A&s=HG7JrzodsErEBgjKrvClvXYYI0qF0c1f_5S4P8wCIko&e=


Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> 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 can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> 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.
>
> BFN. Paul.
>
> --
> 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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Martin Packer

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

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Paul Edwards 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 14:12
Subject:Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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
bar to be moved above the 4 GiB new bar,
clearing the 2 GiB - 4 GiB region for
GETMAIN LOC=ANY requests by an AM32
program.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Allan Staller

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@LISTSERV.UA.EDU
Subject: 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 bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Charles Mills

+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
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.
> >This would be of zero use for existing applications,
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
> > and new applications should simply use 64 bit.
> 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.
> BFN. Paul.

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.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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: 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 to 4 byte pointers.

On Thu, 4 Apr 2019 13:27:06 + Allan Staller  wrote:

:>Prepare a business case and submit it to IBM.
:>I dont 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@LISTSERV.UA.EDU
:>Subject: 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 bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.
:>
:>BFN. Paul.

--
Binyamin Dissen 
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: AMODE 32

2019-04-04 Thread Gene Hudders

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 eliminate the X'80'.

Gene
In a message dated 4/4/2019 10:17:07 AM Venezuela Standard Time, 
bdis...@dissensoftware.com writes:

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 to 4 byte pointers.

On Thu, 4 Apr 2019 13:27:06 + Allan Staller  wrote:

:>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@LISTSERV.UA.EDU
:>Subject: 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 bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.
:>
:>BFN. Paul.

--
Binyamin Dissen 
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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread zMan

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.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Tom Marchant

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 this one is a far 
bigger one.

It amounts to a very small enhancement to an old architecture that has already 
been enhanced far beyond what you are asking for. You are asking for a 
significant change to the architecture that provides minimal, if any, benefit. 
It would complicate the architecture, apparently only to the benefit of your 
ego.

>The BSM instruction can use bit x'4000 '
>to get/set AM32.

No, it can't, for compatibility reasons.

>This introduces a 1 GiB
>restriction where the module should not
>be loaded above if it needs to switch
>AMODEs to call READ etc.

Yeah. You want to double the available storage, yet halve the storage available 
to programs.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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 from AM24 to AM31.

There is a set of changes that need to be
done when going from AM31 to AM32.

There is a set of changes that need to be
done when going from AM32 to AM64.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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 not
>>be loaded above if it needs to switch
>>AMODEs to call READ etc.
>
>Yeah. You want to double the available storage,
>yet halve the storage available to programs.

The storage available to programs is
doubled, not halved.

It is just the load module that needs
to reside below 1 GiB, and even then,
that's only if READ hasn't been updated
to be AM32-clean.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Gene Hudders

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 in the code that 
would require eliminating the HO X'80' bit? Maybe that is why IBM from the 
beginning only defined 31 bits instead of 32.
Gene
In a message dated 4/4/2019 10:37:13 AM Venezuela Standard Time, 
mutazi...@gmail.com writes:

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 sameas needs to be done if using AM64.
There is a set of changes that need to bedone when going from AM24 to AM31.
There is a set of changes that need to bedone when going from AM31 to AM32.
There is a set of changes that need to bedone when going from AM32 to AM64.
BFN. Paul.
--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: 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.

If you are changing addressing mode to
31-bit, so that you can cope with the
x'80' bit in a CALL, then you would need
to do the same thing with an AM32
program.

> Do you realize how many user programs that
> have CALLs embedded in the code that would
> require eliminating the HO X'80' bit?

A problem that exists when trying to
convert to pure AM64 too.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Gene Hudders

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  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.
If you are changing addressing mode to31-bit, so that you can cope with 
thex'80' bit in a CALL, then you would needto do the same thing with an 
AM32program.
> Do you realize how many user programs that> have CALLs embedded in the code 
> that would> require eliminating the HO X'80' bit?
A problem that exists when trying toconvert to pure AM64 too.
BFN. Paul.
--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: 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 Hudders  wrote:

>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  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.
>If you are changing addressing mode to31-bit, so that you can cope with 
>thex'80' bit in a CALL, then you would needto do the same thing with an 
>AM32program.
>> Do you realize how many user programs that> have CALLs embedded in the code 
>> that would> require eliminating the HO X'80' bit?
>A problem that exists when trying toconvert to pure AM64 too.
>BFN. Paul.
>--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: 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 capable of editing either 2 GiB or 4 GiB
files, depending on whether it is compiled
AM31 or AM32. If you exceed the capability
you are forced to use your less-preferred
editor. I would like to give users the
maximum capability that 32 bits can give.

>Why do you feel 64bit is "overkill"?

Because it invalidates all old hardware. An
AM32 program can still run as AM31 on old
hardware, or even AM24 on very old
hardware.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFSORT ICE085A - Options?

2019-04-04 Thread Sri h Kolusu

>> 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. :)

Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
04/03/2019 11:14:23 PM:

> From: Martin Packer 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/03/2019 11:17 PM
> Subject: Re: DFSORT ICE085A - Options?
> Sent by: IBM Mainframe Discussion List 
>
>
> Was it a single IFTHEN?
>
> Also, I suppose that IFTHEN, being relatively new, might’ve had a
different
> implementation. But I don’t know and I doubt this kind of internal is
> something Sri Hari would feel free to talk about.
>
> Sent from my iPad
>
> > On 4 Apr 2019, at 00:08, van der Grijn, Bart (B) 
> wrote:
> >
> > Thanks all for the comments and advice. My issue is resolved, but I
don't
> yet understand why.
> >
> > A big thanks to Kolusu. I took him up on his offer and sent him the
> relevant data offline. He produced a solution that looks as follows
> (apologies if the formatting gets messed up):
> >
> > My original control cards:
> >  OPTION COPY,NOVLSHRT,
> >  OUTFIL FNAMES=OUT,VTOF,OUTREC=(ASEGAR,
> >  C'|',
> > ...
> > 
> > ...
> >  C'|',
> >  AFRE98)
> >
> > Kolusu's solution:
> >  OPTION COPY
> >  INREC IFTHEN=(WHEN=INIT,
> >BUILD=(RDW,
> >   ASEGAR,
> > C'|',
> > ...
> > 
> > ...
> > C'|',
> > AFRE98))
> >  OUTFIL VTOF,BUILD=(5,5090)
> >
> > This solved my problem and was a simple fix to implement in the REXX
that
> generates the control cards.
> >
> > In addition he pointed out that my edit masks needed some work as I had
a
> lot of
> > EDIT=(I.II)
> > types of masks that should have been
> > EDIT=(T.TT)
> >
> > So while my issue is resolved, I do wonder what the magic here is.
> Reviewing the manual on INREC IFTHEN(WHEN=INIT it suggests there's no
> actual functionality to this for the sort statement I have. However,
> removing this and just using INREC BUILD resulted in the same ICE085A
> problem.
> > So what's the logic here with regards to IFTHEN and memory usage?
> >
> > Thanks,
> > Bart
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of Sri h Kolusu
> > Sent: Tuesday, April 02, 2019 1:57 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFSORT ICE085A - Options?
> >
> >>> There are 473 input fields that are copied over, some of them
> converted,
> > with '|' inserted as separator.
> > Bart,
> >
> > That is one too many edit fields.  Looks like you have an input file
and
> > want to convert it to pipe delimited file. If you can send me a sample
> > input file and the symbol mapping along with control cards, then I
> probably
> > might be able to come up with something ( No promises though)
> >
> > Thanks,
> > Kolusu
> > DFSORT Development
> > IBM Corporation
> >
> > --
> > 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
> >Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
> --
> 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: 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 Edwards  wrote:

> 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 Hudders  wrote:
>
> >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 
> 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.
> >If you are changing addressing mode to31-bit, so that you can cope with
> thex'80' bit in a CALL, then you would needto do the same thing with an
> AM32program.
> >> Do you realize how many user programs that> have CALLs embedded in the
> code that would> require eliminating the HO X'80' bit?
> >A problem that exists when trying toconvert to pure AM64 too.
> >BFN. Paul.
> >--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
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Steven Partlow

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 instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Sam Golob


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-typed, we now always feed our own ASID into the SRB, to guarantee 
that the SRB won't run in error.  Then, when we try to over-type the 
ASID again, we'll have another chance to get it right.


    I think you can now safely beat up LOOKN, and see if you can find 
other issues, or else you can just enjoy it.


    Thanks very much for bearing with us.

Sincerely,    Sam and Joe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACROUTE S0C4 abend when using MSGRTRN=YES option

2019-04-04 Thread Steve Bagshaw

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...@listserv.ua.edu with the message: INFO IBM-MAIN

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 clean it 
up.

:>We'll fix that.

--
Binyamin Dissen 
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: 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 "not enough"
:>so much as "capability". E.g. a 32-bit editor
:>is capable of editing either 2 GiB or 4 GiB
:>files, depending on whether it is compiled
:>AM31 or AM32. If you exceed the capability
:>you are forced to use your less-preferred
:>editor. I would like to give users the
:>maximum capability that 32 bits can give.

What hardware is this hypothetical end-user using, that does not support 64
bit?

:>>Why do you feel 64bit is "overkill"?

:>Because it invalidates all old hardware. An
:>AM32 program can still run as AM31 on old
:>hardware, or even AM24 on very old
:>hardware.

Well, you make it optional. Path1=24 bit. Path2=31bit. Path3=64bit.

I fail to see how your proposal would help IBM sell anything.

--
Binyamin Dissen 
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: 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 can browse virtual storage and and navigate control blocks 
:>in all three:  64-bit, 31-bit, and 24-bit storage, and in ANY ADDRESS SPACE.

:>     I know that many of you have other ways of doing this, but the 
:>64-bit LOOK command, named LOOKN to distinguish it from the 31-bit 
:>version, has been a mainstay for many programmers, and for me.

:>     My friend Joe Reichman did most of the development, and he 
:>modernized many parts of the program:  SCHEDULE was replaced by IEAMSCHD 
:>in synchronous mode, and much more was revamped by Joe, including recovery.

:>     Right now I think that LOOKN works very nicely, switching back and 
:>forth between 64-bit and 31-bit storage and so forth. But I'd like the 
:>people to use it, beat it up, and report any problems to me, so we can 
:>fix them.  LOOK does not change storage.  It gives you the opportunity 
:>to see the data you're programming for.

:>     The old versions of LOOK are still around on File 264, so that 
:>folks using pre-z/OS systems can still have a their source codes.

--
Binyamin Dissen 
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: AMODE 32

2019-04-04 Thread Seymour J Metz

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 turning on a 
high bit. Well, IBM didn't do it that way, and there is far to much invested in 
code to change it now. That bridge was burned half a century ago.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 trying to add a LOC=32
to GETMAIN for use by AMODE 64 programs.

This time I want to retain normal LOC=ANY
for GETMAIN, and introduce a new AMODE 32.

Previously I didn't have a practical way of
adding AM32. It is only recently that I
realized that bits 1-7 of a 32-bit register
could be used by BSM.

I thought more people would like to see a
long-term z/OS that ran purely 32-bit and
64-bit software like other platforms do.

BFN. Paul.

--
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: AMODE 32

2019-04-04 Thread Vernooij, Kees (ITOP NM) - KLM

> -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 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 downward compatibility.
> 

I would even like to formulate it stronger: it is not a disadvantage to be 
stuck with 24/31-bit software, it is an advantage to be compatible with 
24/31-bit software (for eternity). 
You might bring IBM on the idea to phase out all techniques that are more than 
a decade old.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Joseph Reichman

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'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 can browse virtual storage and and navigate control blocks 
> :>in all three:  64-bit, 31-bit, and 24-bit storage, and in ANY ADDRESS SPACE.
> 
> :> I know that many of you have other ways of doing this, but the 
> :>64-bit LOOK command, named LOOKN to distinguish it from the 31-bit 
> :>version, has been a mainstay for many programmers, and for me.
> 
> :> My friend Joe Reichman did most of the development, and he 
> :>modernized many parts of the program:  SCHEDULE was replaced by IEAMSCHD 
> :>in synchronous mode, and much more was revamped by Joe, including recovery.
> 
> :> Right now I think that LOOKN works very nicely, switching back and 
> :>forth between 64-bit and 31-bit storage and so forth. But I'd like the 
> :>people to use it, beat it up, and report any problems to me, so we can 
> :>fix them.  LOOK does not change storage.  It gives you the opportunity 
> :>to see the data you're programming for.
> 
> :> The old versions of LOOK are still around on File 264, so that 
> :>folks using pre-z/OS systems can still have a their source codes.
> 
> --
> Binyamin Dissen 
> 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Allan Staller

I suggest we all stop feeding the Bear!


::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Seymour J Metz

> 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 would be a kludge and a short term one at that. The long 
term model is 64 bits unless memory and DASD prices go down drastically.

> 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.

> 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.

31 bit/2 GiB should be enough for almost all commercial applications. Those 
that need more will need lots more, and it is a pipe dream to believe that 
doubling the size of the address space will be enough for long.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 can be
modified to be 32-bit clean and have maximum
possible address space as per 32-bit.

> and new applications should simply use 64 bit.

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.

BFN. Paul.

--
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: AMODE 32

2019-04-04 Thread Tom Marchant

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 to z/OS in such a way that it 
will run on hardware that does not support z/Architecture.

That's absurd.

I'm done with you.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Mike Schwab

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 memory access, much cheaper to use more
memory for 64 bit pointers.

On Thu, Apr 4, 2019 at 10:31 AM 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 "not enough"
> so much as "capability". E.g. a 32-bit editor
> is capable of editing either 2 GiB or 4 GiB
> files, depending on whether it is compiled
> AM31 or AM32. If you exceed the capability
> you are forced to use your less-preferred
> editor. I would like to give users the
> maximum capability that 32 bits can give.
>
> >Why do you feel 64bit is "overkill"?
>
> Because it invalidates all old hardware. An
> AM32 program can still run as AM31 on old
> hardware, or even AM24 on very old
> hardware.
>
> BFN. Paul.
>
> --
> 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: AMODE 32

2019-04-04 Thread Seymour J Metz

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 Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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.

--
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: 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 fix advantageous?

It allows the full 32-bit capability to be exploited.

> It's just as easy to go directly to 64 bit.

No, THAT is what requires a complete rewrite.
AND, that rules out running on older hardware,
or even newer hardware if someone comes
out with a cheap 32-bit S/390 chip.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Sam Golob


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 035, which contains load modules for LOOK. All should be fine, 
hopefully.  Please download the newest copies, if you downloaded between 
yesterday and today.


    Again, thanks for your forbearance.  We're trying to bring you the 
best product we can.


    All the best of everything to all of you...

Sincerely,    Sam and Joe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

2019-04-04 Thread Chris Hoelscher

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://nam03.safelinks.protection.outlook.com/?url=www.cbttape.org&data=02%7C01%7Cchoelscher%40humana.com%7C56c06d7a65534be5d21a08d6b9305bc4%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C1%7C636900014698173812&sdata=gDcFP9TYaqmd%2B43I9u4f3BUa%2BwLky524OIdQdLkqZ18%3D&reserved=0
Updates page, and also File 035, which contains load modules for LOOK. All
should be fine, hopefully. Please download the newest copies, if you
downloaded between yesterday and today.

Again, thanks for your forbearance. We're trying to bring you the best
product we can.

All the best of everything to all of you...

Sincerely, Sam and Joe

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

The information transmitted is intended only for the person or entity to which
it is addressed
and may contain CONFIDENTIAL material. If you receive this
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights
laws and
do not discriminate on the basis of race, color, national origin, age,
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its
subsidiaries do not
exclude people or treat them differently because of race, color, national
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services,
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

2019-04-04 Thread Martin Packer

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 Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Paul Edwards 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 19:37
Subject:Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32