Re: Thank you to LRS and to BIS

2021-02-01 Thread Radoslaw Skorupka

Amen to that.
And to complement - when plans do not materialize, they do not stop the 
madness, they increase spendings to make it ...more mad. And more. And 
even more. And they start to looking for those to blame. Like mainframe 
folks who take care about the system.

(can't say more)

--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland


 


W dniu 01.02.2021 o 23:02, Ramsey Hallman pisze:

Dave, I regret to hear of another mainframe shutting down.  It's a shame
many companies do not realize exactly what they are doing until it is too
late.  I don't know about WSU, but the companies I've been involved with
who migrated off of IBM mainframes were surprised to find how much it cost
to "replace" the horsepower of a mainframe.

On a spreadsheet, mainframes look ugly in cost, both iron and software.  In
actuality, the power produced by that iron and software FAR outperforms any
other platform.  My most recent shop (that migrated) thought they could
replace a z10 with a quad-core Intel system, or so new management said.
100+ quad-core systems later and 100+ software licenses and they still
could not meet the published response times the company guaranteed to
users.  Of course, they were too far down the road to back out at that
point, but the migration to a "cheaper platform" ended up costing them
about $1.2M/yr more than the mainframe and software licenses.  I was quite
pleased to see the manager who thought this was such a great idea be fired
after completion of the project when the true costs, hardware, software,
and response began coming in.

JR


On Mon, Feb 1, 2021 at 2:11 PM Gibney, Dave  wrote:


I wish this wasn't true,  but we continue to move towards shutting down
or z/OS systems. Last night I shutdown VPS and DRS from Levi, Ray and
Shoup. I wish to thank LRS for the one month license extension they granted
us at no charge. Our employees did get W2 forms :)
I also shut down our session manager, Netpass from BIS. Bis also
granted us a one month, no charge extension.
I was very please by the support we received from both companies over
the last more than 30 years.

Dave Gibney
Information Technology Services
Washington State University


--
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: Rexx stem variable question

2021-02-01 Thread Charles Mills
Thanks all. I am getting it now. I had the wrong mental model of how Rexx
stems work (and I suspect some others may also.)

I pictured it kind of like C or COBOL multi-dimensional arrays. I pictured
Rexx A.B.C.D being essentially analogous to C language A[B,C,D] or COBOL
A(B, C, D) albeit with "associative subscripts."

But it really is more like a one-dimensional array than an n-dimensional
array. A.B.C.D is kind of the same thing as A.ValueOfB_ValueOfC_ValueOfD.
The periods just separate the different variable names, making A.B.C.D
distinct from A.BCD. B.C.D is one "subscript," not three. There is only one
tail, a series of values essentially concatenated with periods, not a
hierarchy of tails.

The fact that it is one-dimensional explains why A.B. has no special
significance. 

A. is special; it is "all the possible tails of A" but A.B. is just "A.B
plus a period."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Saturday, January 30, 2021 7:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx stem variable question

https://ia801609.us.archive.org/14/items/REXXLanguage2ndEdition/REXX%20Langu
age%20-%202nd%20Edition.pdf

"The name begins with a stem (that part of the symbol up to and including
the first period)."

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


DE entry on Load Link XCTL and ATTACH

2021-02-01 Thread Joseph Reichman
When you have DE entry on any of these macros  I assume the system just
checks the first name ?

 

thanks 

 


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


Re: STORAGE KEY of loaded executable

2021-02-01 Thread Thomas David Rivers

Peter Relson wrote:


.


May I ask why you need to switch to key 9? That is very atypical. I 
believe that the Storage Protect Override facility, as implemented in z/OS 
with Key 9, was created so that CICS transactions could avoid accidental 
overlays of CICS key 8 storage.  So unless you're trying super-hard to 
prevent yourself from overlaying your own key 8 storage, you would not 
typically get into key 9.


Peter Relson
z/OS Core Technology Design


 


Hi Peter!

I'm playing around with some tests and was switching keys,
and didn't want to mess with authorized code. So I just picked
the next one up to 8.  There was nothing "special" in my choice
of 9.

Same kind of idea - trying to just switch to key 9 and make sure
things don't blow up, or accidently reference the previously allocated
key 8 memory.

But I bumped into some references to the previous memory that
are intentional/needed... so it's a bit of a squirrely mess at this point.

  - Dave R. -



--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


Re: Thank you to LRS and to BIS

2021-02-01 Thread Ramsey Hallman
Dave, I regret to hear of another mainframe shutting down.  It's a shame
many companies do not realize exactly what they are doing until it is too
late.  I don't know about WSU, but the companies I've been involved with
who migrated off of IBM mainframes were surprised to find how much it cost
to "replace" the horsepower of a mainframe.

On a spreadsheet, mainframes look ugly in cost, both iron and software.  In
actuality, the power produced by that iron and software FAR outperforms any
other platform.  My most recent shop (that migrated) thought they could
replace a z10 with a quad-core Intel system, or so new management said.
100+ quad-core systems later and 100+ software licenses and they still
could not meet the published response times the company guaranteed to
users.  Of course, they were too far down the road to back out at that
point, but the migration to a "cheaper platform" ended up costing them
about $1.2M/yr more than the mainframe and software licenses.  I was quite
pleased to see the manager who thought this was such a great idea be fired
after completion of the project when the true costs, hardware, software,
and response began coming in.

JR


On Mon, Feb 1, 2021 at 2:11 PM Gibney, Dave  wrote:

>I wish this wasn't true,  but we continue to move towards shutting down
> or z/OS systems. Last night I shutdown VPS and DRS from Levi, Ray and
> Shoup. I wish to thank LRS for the one month license extension they granted
> us at no charge. Our employees did get W2 forms :)
>I also shut down our session manager, Netpass from BIS. Bis also
> granted us a one month, no charge extension.
>I was very please by the support we received from both companies over
> the last more than 30 years.
>
> Dave Gibney
> Information Technology Services
> Washington State University
>
>
> --
> 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: Thank you to LRS and to BIS

2021-02-01 Thread Ron Wells
Stupidity runs wild...politics and corp. rule

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Monday, February 01, 2021 2:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Thank you to LRS and to BIS

** EXTERNAL EMAIL - USE CAUTION **


   I wish this wasn't true,  but we continue to move towards shutting down or 
z/OS systems. Last night I shutdown VPS and DRS from Levi, Ray and Shoup. I 
wish to thank LRS for the one month license extension they granted us at no 
charge. Our employees did get W2 forms :)
   I also shut down our session manager, Netpass from BIS. Bis also granted us 
a one month, no charge extension.
   I was very please by the support we received from both companies over the 
last more than 30 years.

Dave Gibney
Information Technology Services
Washington State University


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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

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


Thank you to LRS and to BIS

2021-02-01 Thread Gibney, Dave
   I wish this wasn't true,  but we continue to move towards shutting down or 
z/OS systems. Last night I shutdown VPS and DRS from Levi, Ray and Shoup. I 
wish to thank LRS for the one month license extension they granted us at no 
charge. Our employees did get W2 forms :)
   I also shut down our session manager, Netpass from BIS. Bis also granted us 
a one month, no charge extension.
   I was very please by the support we received from both companies over the 
last more than 30 years.

Dave Gibney
Information Technology Services
Washington State University


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


Re: STORAGE KEY of loaded executable

2021-02-01 Thread Peter Relson
Shmuel posted the relevant section.

The really relevant point is that subpool 251 is fetch-protected (and 
subpool 252 is not)
If you switch out of the subpool 251 key (and the module is in subpool 251 
storage, not subpool 252), then you have no access to the storage of your 
program and thus, yes, you will program check attempting to fetch the 
instruction.

If your program is loaded into subpool 252 (key 0, not fetch protected) 
any key can read it.


when a blob of AUTHORIZED code loads something, say, some system exit or 
something; what
is the STORAGE KEY of the memory that code is loaded in.  That
program may get entered with a KEY=0, but will need access to its own 
CSECT.

The same rules apply.


May I ask why you need to switch to key 9? That is very atypical. I 
believe that the Storage Protect Override facility, as implemented in z/OS 
with Key 9, was created so that CICS transactions could avoid accidental 
overlays of CICS key 8 storage.  So unless you're trying super-hard to 
prevent yourself from overlaying your own key 8 storage, you would not 
typically get into key 9.

Peter Relson
z/OS Core Technology Design


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


Re: STORAGE KEY of loaded executable

2021-02-01 Thread Seymour J Metz
The behavior for REFR is subject to operator and parmlib control. RENT goes 
into key 0 if the library concatenation is APF.

There's no reason to flush the cache, and doing so would be a major performance 
hit. With luck there an IBM Systems Journal article or redbook on the I-unit of 
current processors; if not, there should be.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Binyamin Dissen [bdis...@dissensoftware.com]
Sent: Monday, February 1, 2021 6:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable

On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers 
wrote:

:>I have a situation where I LOAD a program, with a PSW KEY of 8,
:>then branch to it.

:>The program switches to KEY 9, but wants to reference some
:>data in the loaded CSECT (say, for example, a =F constant in the
:>literal area.)

:>This blows up, I'm guessing because the key isn't the same as the
:>loaded module's memory (the address appears to be fine.)

:>This brings up a couple of questions:

:>   When you LOAD a program, how do you control the KEY
:>  for the memory the LOAD'd program occupies?  Can you, or
:>  does z/OS always LOAD (non-auth) programs in KEY=8?

If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected.

:>   When you switch KEYs, how do you retain access to the
:> program's memory for constants and things?

IF the program is in fetch protected storage, you do not (as you saw).

:>And - to get more complicated - when a blob of AUTHORIZED
:> code loads something, say, some system exit or something; what
:> is the STORAGE KEY of the memory that code is loaded in.  That
:> program may get entered with a KEY=0, but will need access to
:> it's own CSECT.

Well, there MVS acts as a sort of nanny and if you ask for SP=0 when in key
zero it really gives you SP=252. You need to specify SP=250 if you want task
zero.

But the STORAGE macro certainly allows you to allocate storage that you do not
have current access to, such as a supervisor state program in key 1 can
allocate key 3 or key 8, and should it make an improper reference to the
storage it will PIC-4.

:>   And - It's not quite clear to me, but does the STORAGE KEY
:> get examined during the fetch-execute cycle of program
:> execution.  If my module is in memory with KEY=8, and I change
:> the key with an SPKA instruction; can I actually retrieve the
:> next instruction to execute?   Just where does the key-check occur?

I notice that the POPs does not say that it causes a flush of the instruction
cache but it would have to do something similar for integrity. Changing the
PSW key to something that does not have the ability to fetch from the PSW
location should cause a PIC-4.

--
Binyamin Dissen 
http://secure-web.cisco.com/1rk1kzDQ1dsQLEjbFIOdTLgfWKkMk_vMLQiQ6XbnsMve7RFps3Az-Pvi4Ha4_hhLa58Bzcqo3XlG-W4hVLLUB3ZQa1if0tXXo1yla2P3yhSSIYHKPbxfM4X4GeupcpCBAHhazrlRh9D_qk0pV21XDo9ZZypKN_56nB7leTnW_YhTD1ZSoHHcAsN2SX4U4ppIoQtsvEfQgYUs7sqaQXlLrFSwLvpG-a0Y6j_Ki2pog7LntjtEqUi_Hz0-ry0_Xu_zBCRC7mcBJLBp-7k4wBcuax_tDlfokH9M4LwOmIanp541XIxipkGLJEhyC3mY_Xo8aX3T4JKW88vZ_cb6NHHLV4d70zPgf9t0zFFv87-RLIU6-DBAF2XuDLlLdH1t4HKttl5ebSFWJVNifKH-KB65KoACP6YVEDl-DuOsK0-BIFPcysrLi3oRlSOUvXrzhMOJg/http%3A%2F%2Fwww.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: STORAGE KEY of loaded executable

2021-02-01 Thread Seymour J Metz
Using the REFRPROT statement
 Use the REFRPROT statement type to specify that REFR programs are
protected from modification by placing them in key 0, non-fetch protected 
storage,
and page protecting the full pages.
Therefore, any parts of the program that are on partial pages are not 
page-protected.
For more information on protectionof REFR programs, see 
z/OS MVS Program Management: User's Guide and Reference

That's Shmuel



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Thomas David Rivers [riv...@dignus.com]
Sent: Monday, February 1, 2021 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE KEY of loaded executable

Binyamin Dissen wrote:

>On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers 
>wrote:
>
>
>:>   When you LOAD a program, how do you control the KEY
>:>  for the memory the LOAD'd program occupies?  Can you, or
>:>  does z/OS always LOAD (non-auth) programs in KEY=8?
>
>If you mark the module refreshable it should nowadays be loaded into SP=252
>which is not fetch protected.
>
>

I have to admit to not looking for it yet - but do you have
a pointer to the doc for this?  Schmuel described the various
Subpools and fetchability attributes which I was able to find
via a google text search.  These seem to be described in the
ATTACHX documentation... but that must also apply to LOAD
(I suppose???)

Thanks for the pointer about REFRESH (REFR option on binder),
I'll look for more info.

The downside of REFR is it defeats the use of debuggers which
modify the code-stream to insert break-points... but, it is what it is...

  - Thanks -
- Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at 
http://secure-web.cisco.com/1Fca2f4IZyQDVYdr-tstJBM0QiKvOzgzg94WT2h048B5kcwGwpOyiewu9F8yc-DmUE5IxyEX1shdLcwKPemLt6F9sCyPfueLpjDx_8DxXMbGz9S-e_C70qlP4OQjP3eYcoaQoC_iERsWYwJDrhfxOUh1J8gFjYF9kMnNKgf8Nrj8yK4Xb4Ge0Reg3P-yKKCVRlaQztNOgDRtszxarzAZobwBPk07aruzQDx89h57i2M96Hbq9jVg_wS7-tHzzf9H5dtt5uvH51UVkSr6kOGU0WalGJCuZYzWtJ7t2-Sb1QarOI8Mlzh40ZvO2iGhVnKMwICQMQ_BqdW2QV9I8IamrAtmJuB_-kGFQeGa-nCbuqB5vlLyh5T_sR5IZbV4twskfvJf-TmGDMkKun49waLNkEgbHfD3iep5-o0pMk0wwfoP_1ZZ4Rd5AJXk4o8wjmpoo/http%3A%2F%2Fwww.dignus.com

--
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: STORAGE KEY of loaded executable

2021-02-01 Thread Thomas David Rivers

Binyamin Dissen wrote:


On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers 
wrote:


:>   When you LOAD a program, how do you control the KEY
:>  for the memory the LOAD'd program occupies?  Can you, or
:>  does z/OS always LOAD (non-auth) programs in KEY=8?

If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected. 
 



I have to admit to not looking for it yet - but do you have
a pointer to the doc for this?  Schmuel described the various
Subpools and fetchability attributes which I was able to find
via a google text search.  These seem to be described in the
ATTACHX documentation... but that must also apply to LOAD
(I suppose???)

Thanks for the pointer about REFRESH (REFR option on binder),
I'll look for more info. 


The downside of REFR is it defeats the use of debuggers which
modify the code-stream to insert break-points... but, it is what it is...

 - Thanks -
- Dave R. -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


Re: STORAGE KEY of loaded executable

2021-02-01 Thread Binyamin Dissen
On Sun, 31 Jan 2021 18:34:11 -0500 Thomas David Rivers 
wrote:

:>I have a situation where I LOAD a program, with a PSW KEY of 8,
:>then branch to it.

:>The program switches to KEY 9, but wants to reference some
:>data in the loaded CSECT (say, for example, a =F constant in the
:>literal area.)

:>This blows up, I'm guessing because the key isn't the same as the
:>loaded module's memory (the address appears to be fine.)

:>This brings up a couple of questions:

:>   When you LOAD a program, how do you control the KEY
:>  for the memory the LOAD'd program occupies?  Can you, or
:>  does z/OS always LOAD (non-auth) programs in KEY=8?

If you mark the module refreshable it should nowadays be loaded into SP=252
which is not fetch protected. 

:>   When you switch KEYs, how do you retain access to the
:> program's memory for constants and things?

IF the program is in fetch protected storage, you do not (as you saw).

:>And - to get more complicated - when a blob of AUTHORIZED
:> code loads something, say, some system exit or something; what
:> is the STORAGE KEY of the memory that code is loaded in.  That
:> program may get entered with a KEY=0, but will need access to
:> it's own CSECT.

Well, there MVS acts as a sort of nanny and if you ask for SP=0 when in key
zero it really gives you SP=252. You need to specify SP=250 if you want task
zero.

But the STORAGE macro certainly allows you to allocate storage that you do not
have current access to, such as a supervisor state program in key 1 can
allocate key 3 or key 8, and should it make an improper reference to the
storage it will PIC-4.

:>   And - It's not quite clear to me, but does the STORAGE KEY
:> get examined during the fetch-execute cycle of program
:> execution.  If my module is in memory with KEY=8, and I change
:> the key with an SPKA instruction; can I actually retrieve the
:> next instruction to execute?   Just where does the key-check occur?

I notice that the POPs does not say that it causes a flush of the instruction
cache but it would have to do something similar for integrity. Changing the
PSW key to something that does not have the ability to fetch from the PSW
location should cause a PIC-4.

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