Re: Dynamic Steplib and z/OS 2.3?

[Ed Jaffe]

On 9/21/2017 5:56 AM, Dyck, Lionel B. (TRA) wrote:

I have no problems with DYNA-STEP having used it in a prior life but I fail to 
see how either of the other two solutions will fail with z/OS 2.3 as I don't 
recall anything in the announcement or presentations that would imply changes 
to the z/OS internals that would affect them.


There were numerous changes to support RMODE(64) programs. Could that be it?

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Dynamic Steplib and z/OS 2.3?

[Paul Gilmartin]

On 2017-09-23, at 16:39, Jesse 1 Robinson wrote:
> 
> LLA/VLF members cannot be updated without a corresponding refresh. It's fine 
> to know this in principle, but I've seen programmers get very frustrated 
> trying to update a program or exec without a refresh. The larger the 
> organization, the more chance that someone will overlook this step and waste 
> significant time trying to figure out why their one-line fix is having no 
> effect on the problem they're tackling. An hour of programmer time is hard to 
> recoup a few milliseconds at a time in improved fetch. ;-(
>  
How does LLA play with PDSE:
o If you do LLA Refresh?
o If you fail to do LLA Refresh?

-- gil

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

Re: Dynamic Steplib and z/OS 2.3?

[Jesse 1 Robinson]

I don't advocate doing it for reasons discussed below, but you can mitigate the 
performance problems (are they even noticeable with modern RAID DASD over 
FICON) by putting TSO STEPLIBs in LLA/VLF. Likewise for CLIST/REXX libraries if 
you're willing to put up with...

LLA/VLF members cannot be updated without a corresponding refresh. It's fine to 
know this in principle, but I've seen programmers get very frustrated trying to 
update a program or exec without a refresh. The larger the organization, the 
more chance that someone will overlook this step and waste significant time 
trying to figure out why their one-line fix is having no effect on the problem 
they're tackling. An hour of programmer time is hard to recoup a few 
milliseconds at a time in improved fetch. ;-(


.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Saturday, September 23, 2017 8:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Dynamic Steplib and z/OS 2.3?

On 9/22/2017 4:55 PM, Walt Farrell wrote:
> On Fri, 22 Sep 2017 16:43:43 -0400, Tom Conley <pinnc...@rochester.rr.com> 
> wrote:
> 
>> Dynamic STEPLIB is designed to run under TSO.  It provides the 
>> ability to satisfy CALL/LINK/ATTACH modules in ISPF for testing, 
>> multiple releases, etc.  Some ill-behaved ISPF apps don't use SELECT 
>> PGM, so they have to be available in the standard search order.
> 
> You don't need dynamic STEPLIB for that; simply allocate your library to DD 
> ISPLLIB before you start ISPF, and ISPF will use it as a tasklib for all its 
> subtasks. It will apply to all module loads, whether they use SELECT PGM or 
> not.
> 

Walt,

The problem with both TSOLIB and ISPLLIB at READY is that those DD's are 
searched every time you hit enter.  They're nearly as bad for performance as 
STEPLIB in the TSO proc.  It also doesn't address when you have to run multiple 
releases of an ISPF app with CALL/LINK/ATTACH dependencies.  With dynamic 
STEPLIB, you only take the performance hit while you're actually using that 
app, and you can safely run multiple releases.

Regards,
Tom Conley


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

Re: Dynamic Steplib and z/OS 2.3?

[Tom Conley]

On 9/22/2017 4:55 PM, Walt Farrell wrote:

On Fri, 22 Sep 2017 16:43:43 -0400, Tom Conley  
wrote:


Dynamic STEPLIB is designed to run under TSO.  It provides the ability
to satisfy CALL/LINK/ATTACH modules in ISPF for testing, multiple
releases, etc.  Some ill-behaved ISPF apps don't use SELECT PGM, so they
have to be available in the standard search order.


You don't need dynamic STEPLIB for that; simply allocate your library to DD 
ISPLLIB before you start ISPF, and ISPF will use it as a tasklib for all its 
subtasks. It will apply to all module loads, whether they use SELECT PGM or not.



Walt,

The problem with both TSOLIB and ISPLLIB at READY is that those DD's are 
searched every time you hit enter.  They're nearly as bad for 
performance as STEPLIB in the TSO proc.  It also doesn't address when 
you have to run multiple releases of an ISPF app with CALL/LINK/ATTACH 
dependencies.  With dynamic STEPLIB, you only take the performance hit 
while you're actually using that app, and you can safely run multiple 
releases.


Regards,
Tom Conley

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

Re: Dynamic Steplib and z/OS 2.3?

[Dan D]

Jim & Peter make good points as to why IBM won't ever provide this function.

STEPLIB is a "tool" that was originally created pre TSOLIB for system 
programmers to do testing.

If used as intended, allocate STEPLIB when logging on and never change it 
unless you re-logon you shouldn't have any integrity issues.   Changing STEPLIB 
while a task is running (split screen) is just asking for trouble.
Yes, I know that's not how sysprogs or developers are going to work so they can 
take their chances.

STEPLIB is that simple.  Allocate the new libraries, under an SRB close the old 
STEPLIB and open the new one then update TCBJLB.  If all libraries are 
authorized you'll have an authorized STEPLIB just as if it was coded in JCL.  
One library that is NOT authorized and you have a non-authorized STEPLIB.

Do many shops actually put CBT tools into "production"?

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

Re: Dynamic Steplib and z/OS 2.3?

[Peter Relson]

Jim Mulder is perfectly correct.

We will never provide such a function. 

There are assumptions made within the system based on things it knows 
about how steplib and joblib are created.
If the CBT tape program does not happen to meet all of those assumptions, 
I have no idea what will happen. Nor do I particularly care, because it is 
clearly not supported to muck with this sort of thing, so I hope that no 
one would try to call IBM service if something went noticeably wrong. 

Simply doing new allocations from the jobstep program and changing TCBJLB 
for that task is likely not sufficient. So maybe that's not what the CBT 
tape program does.

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: Dynamic Steplib and z/OS 2.3?

[Edward Gould]

> On Sep 22, 2017, at 4:01 PM, Walt Farrell  wrote:
> 
> On Fri, 22 Sep 2017 15:38:33 -0500, John McKown  > wrote:
> 
>> Could someone tell me of some of the "real life" uses of this capability?
>> Why can't I just do a DYNALLOC on the libraries, OPEN them, then
>> LINKX/ATTACHX DCB= whatever it is I need? The only thing that I can think
>> of where this would be a problem is if the code doing so is APF authorized
>> and the program to be run is in a nonAPF library.
>> 
> 
> Yes, you as a programmer could do that.
> 
> However, consider a TSO user who wants to run a TSO command from READY, which 
> is comprised of multiple load modules, and which lives in a library that is 
> neither in the linklist nor in the STEPLIB for the user's TSO logon proc.
> 
> How does he do that, given that he cannot change the logon proc?
> 
> (Note that if the module were a "normal" program rather than a TSO command he 
> could use the CALL command, but that won't work for TSO commands. Note, too, 
> that if he wanted to run it under ISPF he could use ISPF facilities to handle 
> it. But he can't run it from READY without some kind of dynamic STEPLIB or 
> tasklib capability.)
> 
> — 

Walt, 
Way back in the 70’ and early 80’s the applications people had a plethora of 
loadlibs and each loadlib was a different areas responsibility.
We had a request for steplibs in the logon proc. We shut that down real fast.
Out of the blue we got a request for a program that attached the first program 
and then it meandered off in all sort of directions and we couldn’t figure out 
what they were asking for.
We asked the programmer in simple english what was needed.
He said they needed to have a list of libraries that were allocated with one 
allocate command and then a TSO command that would attach Program a from the 
list of libraries and all subsequent requests for programs came from the same 
list. ex alloc fi(q) disp(shr) da(‘test.a.loadlib’ ‘test.b.loadlib’ 
‘Test.c.loadlib’ etc etc) then a two command that would invoke the first 
program and use the file(q) as a list of libraries that the system would fetch 
from. I hope I explained the situation. We came up with a two command called 
$call program FI(Q)  the tso command would attach the first program and 
essentially create a task lib of all the libraries in File(q).
We came up with a simple solution and it worked as we never heard a complaint 
about it not working.
Ed
> Walt


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

Re: Dynamic Steplib and z/OS 2.3?

[Steve Smith]

Jim Mulder mentioned the TSOLIB command (which I'd forgotten about,
although I depend on it continuously), and it should come close to
solving most of the issues so far discussed.

As for REXX, it's extendable, if you're so inclined.  I'm passionately
ambivalent about REXX, so, not inclined myself.

-- 
sas

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

Re: Dynamic Steplib and z/OS 2.3?

[Paul Gilmartin]

On Fri, 22 Sep 2017 18:39:57 -0500, John McKown wrote:
>>
>> (Note that if the module were a "normal" program rather than a TSO command
>> he could use the CALL command, ... )
>>
It would be useful if there were a variant of the CALL COMMAND:
CALL DD:ddname(member) as well as
CALL 'data.set.name(member)'
 
And I wish Rexx CALL:
o Supported fully qualified ddname(member)
  (CMS Pipelines REXX stage has something similar.)

And I wish Rexx address ATTCHMVS:
o Supported concurrency, rather than WAITing for task completion.

And I wish Rexx provided:
address SYSCALL fork

-- gil

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

Re: Dynamic Steplib and z/OS 2.3?

[John McKown]

On Fri, Sep 22, 2017 at 4:01 PM, Walt Farrell 
wrote:

> On Fri, 22 Sep 2017 15:38:33 -0500, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> >Could someone tell me of some of the "real life" uses of this capability?
> >Why can't I just do a DYNALLOC on the libraries, OPEN them, then
> >LINKX/ATTACHX DCB= whatever it is I need? The only thing that I can think
> >of where this would be a problem is if the code doing so is APF authorized
> >and the program to be run is in a nonAPF library.
> >
>
> Yes, you as a programmer could do that.
>
> However, consider a TSO user who wants to run a TSO command from READY,
> which is comprised of multiple load modules, and which lives in a library
> that is neither in the linklist nor in the STEPLIB for the user's TSO logon
> proc.
>
> How does he do that, given that he cannot change the logon proc?
>
> (Note that if the module were a "normal" program rather than a TSO command
> he could use the CALL command, but that won't work for TSO commands. Note,
> too, that if he wanted to run it under ISPF he could use ISPF facilities to
> handle it. But he can't run it from READY without some kind of dynamic
> STEPLIB or tasklib capability.)
>

​Right. Use a TASKLIB. How? Well write a TSO CP which sets up the TASKLIB,
then creates the appropriate CPPL based on what is in the new CP's command,
and does an ATTACHX​ with the DCB= of actual TSO CP which was desired. I
don't have any code to share, but what the user might type in could look
something like:

ALLOC DDN(TASKLIB) DSN(...) SHR REUSE
DOCP REALCP PARAMETERS TO (REAL CP

The DOCP command would OPEN the DD of TASKLIB (hard coded DD name for
simplicity). It would then do the ATTACHX of REALCP passing a created CPPL
so that REALCP "sees" the command, properly TSO parsed, as

REALCP PARAMETERS TO (REAL CP

​But I will have to admit that I am not overly knowledgeable in writing a
TSO command processor so I may be overlooking some weird TSO thing about
problems using TSO service routines in a program which is ATTACH'd from the
actual CP program. I.e. TSO doesn't really support multi-tasking. Hum,
perhaps I could mess around with something like this for the CBT.​

​A truly advanced DOCP command would either accept the DSNs for the TASKLIB
or the DD name to use, instead of just using the name TASKLIB.​



> --
> Walt
>
>

-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

Re: Dynamic Steplib and z/OS 2.3?

[David W Noon]

On Fri, 22 Sep 2017 15:43:18 -0500, Walt Farrell
(walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?"
(in <1942473900671448.wa.walt.farrellgmail@listserv.ua.edu>):

> On Fri, 22 Sep 2017 20:53:10 +0100, David W Noon 
> <david.w.n...@googlemail.com> wrote:
> 
>> It is up to the site's programmers to ensure that the load libraries in
>> use in a job step are mutually compatible.
> 
> Unfortunately, the site's programmers are not in control of the libraries 
> used in a jobstep. The creator of the JCL has that control, or in the case of 
> something like a dynamic STEPLIB command, the TSO user who runs the command 
> has it. 

When I was a lad, the JCL was written by programmers. I certainly had to
write the JCL for my programs to run; sometimes I even had to punch the
cards myself.

The use of dynamic STEPLIB is something of a corner case in program
execution. I'm not suggesting that an ALLOC command, SVC 99 or IKJDAIR
should allow STEPLIB/JOBLIB as a target. It should be managed by a well
controlled facility that is custom built for this and with associated
security rules. As part of this, if JSCBAUTH is already set, the dynamic
STEPLIB should also be checked for presence in the current APF list.--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: Dynamic Steplib and z/OS 2.3?

[Paul Gilmartin]

On 2017-09-22, at 15:26, Jim Mulder wrote:

>  The issue is not foreground vs background.  The issue is that
> MVS and its predecessors have  never provided a service to change 
> TCBJLB after a task has been attached, so there may be ways in which 
> programs assume that such a change will not occur.  We believe 
> that it would be dangerous to change this paradigm, so IBM does not, and 
> will not, provide such a capability.
>  
Short form for CBT and ISV customers:  Caveat emptor.

>   IBM does provide products which use TASKLIB on ATTACH, such as
> ISPF, and TSO commands issued from READY after a TSOLIB command. 


>> From: Jesse 1 Robinson
>> Date: 09/22/2017 05:14 PM
>> 
>> Since I was a wee programmer trainee, I've wondered why such a fuss 
>> is made about TSO execution when almost anyone who can logon to TSO 
>> can concoct a random set of JCL cards and SUBMIT them. Including 
>> STEPLIB to any library the user has SAF access to. Why do we worry 
>> so much more about 'foreground' than 'background' processes? Could 
>> it be a fuddy-duddy holdover from the days when our forefathers were
>> dragged kicking and screaming from the environment of punch cards 
>> into wild world of glass and pixels? 
>>  
Or, any job can fork() (BPX1FRK) a number of child processes, giving each
a different STEPLIB concatenation, ...

Restriction: those STEPLIB data sets must be catalogued.

... each can allocate DDNAMEs with BPXWDYN, ...

Restriction: this forgoes the benefits of initiator SYSDSN ENQs.

... and LINK or ATTACH whatever program it wants.

>> Or maybe there's a good reason I'm missing. 
>>  

I believe many programmers want old problems solved without using new 
technology.

-- gil

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

Re: Dynamic Steplib and z/OS 2.3?

[Jim Mulder]

  The issue is not foreground vs background.  The issue is that
MVS and its predecessors have  never provided a service to change 
TCBJLB after a task has been attached, so there may be ways in which 
programs assume that such a change will not occur.  We believe 
that it would be dangerous to change this paradigm, so IBM does not, and 
will not, provide such a capability.

  IBM does provide products which use TASKLIB on ATTACH, such as
ISPF, and TSO commands issued from READY after a TSOLIB command. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 
09/22/2017 05:06:31 PM:

> From: Jesse 1 Robinson <jesse1.robin...@sce.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/22/2017 05:14 PM
> Subject: Re: Dynamic Steplib and z/OS 2.3?
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> Since I was a wee programmer trainee, I've wondered why such a fuss 
> is made about TSO execution when almost anyone who can logon to TSO 
> can concoct a random set of JCL cards and SUBMIT them. Including 
> STEPLIB to any library the user has SAF access to. Why do we worry 
> so much more about 'foreground' than 'background' processes? Could 
> it be a fuddy-duddy holdover from the days when our forefathers were
> dragged kicking and screaming from the environment of punch cards 
> into wild world of glass and pixels? 
> 
> Or maybe there's a good reason I'm missing. 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com



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

Re: Dynamic Steplib and z/OS 2.3?

[Jesse 1 Robinson]

Since I was a wee programmer trainee, I've wondered why such a fuss is made 
about TSO execution when almost anyone who can logon to TSO can concoct a 
random set of JCL cards and SUBMIT them. Including STEPLIB to any library the 
user has SAF access to. Why do we worry so much more about 'foreground' than 
'background' processes? Could it be a fuddy-duddy holdover from the days when 
our forefathers were dragged kicking and screaming from the environment of 
punch cards into wild world of glass and pixels?  

Or maybe there's a good reason I'm missing. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Friday, September 22, 2017 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Dynamic Steplib and z/OS 2.3?

On 9/22/2017 4:19 PM, Rob Schramm wrote:
> Possible is in the eye of the coder.  Most everything "can" be done.
> Whether it is a good idea or not is another discussion ( i.e. Walt's 
> comment ).
> 
> I can break MVS integrity, security etc etc.  Just look at 
> www.krisecurity.com for examples found on how to break integrity.  
> There are loads of ways to do it.
> 
> I can't help but agree with Walt that without very careful 
> consideration, dynamic STEPLIBs might be a terrible thing.
> 
> Rob
> 
> On Fri, Sep 22, 2017 at 4:11 PM Blaicher, Christopher Y. < 
> cblaic...@syncsort.com> wrote:
> 
>> I think you are a little off.  A static concatenation cannot result 
>> in a mix of authorized and unauthorized libraries and the program 
>> running authorized.
>>
>> Contents supervisor, when it goes to load the first module from EXEC 
>> PGM= checks the JOBLIB or STEPLIB for all libraries to be authorized, 
>> else the program while still being loaded will not run authorized.  
>> If the program is being loaded from the LINKLST, it checks that the 
>> library it is being loaded from is authorized, otherwise it once again runs 
>> as unauthorized.
>>
>> If at some later point a load of a module from a library in the 
>> LINKLST that is not authorized, or a directed LOAD/LINK/ATTACH/XCTL 
>> with a non-authorized library specified, will result in an ABEND.
>>
>> I hope the writers of the STEPLIB concatenation routine were through 
>> enough to check the current authorization status of the job step and, 
>> if it is running authorized, validated that the library being added 
>> is also authorized.  Otherwise the concatenation should fail.
>>
>> If your shop has this function, I would verify that you cannot add an 
>> unauthorized library to a STEPLIB or JOBLIB.  If you can, you have 
>> just left a hole the size of the Lincoln Tunnel in your system.
>>
>> Chris Blaicher
>> Technical Architect
>> Mainframe Development
>> P: 201-930-8234 <(201)%20930-8234>  |  M: 512-627-3803 
>> <(512)%20627-3803>
>> E: cblaic...@syncsort.com
>>
>> Syncsort Incorporated
>> 2 Blue Hill Plaza #1563
>> Pearl River, NY 10965
>> www.syncsort.com

Dynamic STEPLIB is designed to run under TSO.  It provides the ability to 
satisfy CALL/LINK/ATTACH modules in ISPF for testing, multiple releases, etc.  
Some ill-behaved ISPF apps don't use SELECT PGM, so they have to be available 
in the standard search order.  Nice apps like QMF provide a DD like DSQLLIB and 
then load from there.  For those that don't, we need Dynamic STEPLIB.  APF 
authorization should not be an issue, because if you trying to run TSO 
authorized, you've already lost.

Regards,
Tom Conley


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

Re: Dynamic Steplib and z/OS 2.3?

[Walt Farrell]

On Fri, 22 Sep 2017 15:38:33 -0500, John McKown  
wrote:

>Could someone tell me of some of the "real life" uses of this capability?
>Why can't I just do a DYNALLOC on the libraries, OPEN them, then
>LINKX/ATTACHX DCB= whatever it is I need? The only thing that I can think
>of where this would be a problem is if the code doing so is APF authorized
>and the program to be run is in a nonAPF library.
>

Yes, you as a programmer could do that.

However, consider a TSO user who wants to run a TSO command from READY, which 
is comprised of multiple load modules, and which lives in a library that is 
neither in the linklist nor in the STEPLIB for the user's TSO logon proc.

How does he do that, given that he cannot change the logon proc?

(Note that if the module were a "normal" program rather than a TSO command he 
could use the CALL command, but that won't work for TSO commands. Note, too, 
that if he wanted to run it under ISPF he could use ISPF facilities to handle 
it. But he can't run it from READY without some kind of dynamic STEPLIB or 
tasklib capability.)

-- 
Walt

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

Re: Dynamic Steplib and z/OS 2.3?

[Walt Farrell]

On Fri, 22 Sep 2017 16:43:43 -0400, Tom Conley  
wrote:

>Dynamic STEPLIB is designed to run under TSO.  It provides the ability
>to satisfy CALL/LINK/ATTACH modules in ISPF for testing, multiple
>releases, etc.  Some ill-behaved ISPF apps don't use SELECT PGM, so they
>have to be available in the standard search order.

You don't need dynamic STEPLIB for that; simply allocate your library to DD 
ISPLLIB before you start ISPF, and ISPF will use it as a tasklib for all its 
subtasks. It will apply to all module loads, whether they use SELECT PGM or not.

-- 
Walt

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

Re: Dynamic Steplib and z/OS 2.3?

[Tom Conley]

On 9/22/2017 4:19 PM, Rob Schramm wrote:

Possible is in the eye of the coder.  Most everything "can" be done.
Whether it is a good idea or not is another discussion ( i.e. Walt's
comment ).

I can break MVS integrity, security etc etc.  Just look at
www.krisecurity.com for examples found on how to break integrity.  There
are loads of ways to do it.

I can't help but agree with Walt that without very careful consideration,
dynamic STEPLIBs might be a terrible thing.

Rob

On Fri, Sep 22, 2017 at 4:11 PM Blaicher, Christopher Y. <
cblaic...@syncsort.com> wrote:


I think you are a little off.  A static concatenation cannot result in a
mix of authorized and unauthorized libraries and the program running
authorized.

Contents supervisor, when it goes to load the first module from EXEC PGM=
checks the JOBLIB or STEPLIB for all libraries to be authorized, else the
program while still being loaded will not run authorized.  If the program
is being loaded from the LINKLST, it checks that the library it is being
loaded from is authorized, otherwise it once again runs as unauthorized.

If at some later point a load of a module from a library in the LINKLST
that is not authorized, or a directed LOAD/LINK/ATTACH/XCTL with a
non-authorized library specified, will result in an ABEND.

I hope the writers of the STEPLIB concatenation routine were through
enough to check the current authorization status of the job step and, if it
is running authorized, validated that the library being added is also
authorized.  Otherwise the concatenation should fail.

If your shop has this function, I would verify that you cannot add an
unauthorized library to a STEPLIB or JOBLIB.  If you can, you have just
left a hole the size of the Lincoln Tunnel in your system.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234 <(201)%20930-8234>  |  M: 512-627-3803 <(512)%20627-3803>
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com


Dynamic STEPLIB is designed to run under TSO.  It provides the ability 
to satisfy CALL/LINK/ATTACH modules in ISPF for testing, multiple 
releases, etc.  Some ill-behaved ISPF apps don't use SELECT PGM, so they 
have to be available in the standard search order.  Nice apps like QMF 
provide a DD like DSQLLIB and then load from there.  For those that 
don't, we need Dynamic STEPLIB.  APF authorization should not be an 
issue, because if you trying to run TSO authorized, you've already lost.


Regards,
Tom Conley

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

Re: Dynamic Steplib and z/OS 2.3?

[Walt Farrell]

On Fri, 22 Sep 2017 20:53:10 +0100, David W Noon  
wrote:

>It is up to the site's programmers to ensure that the load libraries in
>use in a job step are mutually compatible.

Unfortunately, the site's programmers are not in control of the libraries used 
in a jobstep. The creator of the JCL has that control, or in the case of 
something like a dynamic STEPLIB command, the TSO user who runs the command has 
it. 

-- 
Walt

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

Re: Dynamic Steplib and z/OS 2.3?

[John McKown]

On Fri, Sep 22, 2017 at 3:20 PM, Rob Schramm  wrote:

> Possible is in the eye of the coder.  Most everything "can" be done.
> Whether it is a good idea or not is another discussion ( i.e. Walt's
> comment ).
>
> I can break MVS integrity, security etc etc.  Just look at
> www.krisecurity.com for examples found on how to break integrity.  There
> are loads of ways to do it.
>
> I can't help but agree with Walt that without very careful consideration,
> dynamic STEPLIBs might be a terrible thing.
>
> Rob
>
>
Could someone tell me of some of the "real life" uses of this capability?
Why can't I just do a DYNALLOC on the libraries, OPEN them, then
LINKX/ATTACHX DCB= whatever it is I need? The only thing that I can think
of where this would be a problem is if the code doing so is APF authorized
and the program to be run is in a nonAPF library.


-- 
*L'Shanah Tovah Tikatevu*

Maranatha! <><
John McKown

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

Re: Dynamic Steplib and z/OS 2.3?

[Rob Schramm]

Possible is in the eye of the coder.  Most everything "can" be done.
Whether it is a good idea or not is another discussion ( i.e. Walt's
comment ).

I can break MVS integrity, security etc etc.  Just look at
www.krisecurity.com for examples found on how to break integrity.  There
are loads of ways to do it.

I can't help but agree with Walt that without very careful consideration,
dynamic STEPLIBs might be a terrible thing.

Rob

On Fri, Sep 22, 2017 at 4:11 PM Blaicher, Christopher Y. <
cblaic...@syncsort.com> wrote:

> I think you are a little off.  A static concatenation cannot result in a
> mix of authorized and unauthorized libraries and the program running
> authorized.
>
> Contents supervisor, when it goes to load the first module from EXEC PGM=
> checks the JOBLIB or STEPLIB for all libraries to be authorized, else the
> program while still being loaded will not run authorized.  If the program
> is being loaded from the LINKLST, it checks that the library it is being
> loaded from is authorized, otherwise it once again runs as unauthorized.
>
> If at some later point a load of a module from a library in the LINKLST
> that is not authorized, or a directed LOAD/LINK/ATTACH/XCTL with a
> non-authorized library specified, will result in an ABEND.
>
> I hope the writers of the STEPLIB concatenation routine were through
> enough to check the current authorization status of the job step and, if it
> is running authorized, validated that the library being added is also
> authorized.  Otherwise the concatenation should fail.
>
> If your shop has this function, I would verify that you cannot add an
> unauthorized library to a STEPLIB or JOBLIB.  If you can, you have just
> left a hole the size of the Lincoln Tunnel in your system.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234 <(201)%20930-8234>  |  M: 512-627-3803 <(512)%20627-3803>
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David W Noon
> Sent: Friday, September 22, 2017 3:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dynamic Steplib and z/OS 2.3?
>
> On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell
> (walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?"
> (in <4974758334821366.wa.walt.farrellgmail@listserv.ua.edu>):
>
> > On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com>
> wrote:
> >
> >> Dynamic STEPLIB has been discussed in these fora so often that I
> >> suspect it's the subject of numerous RFEs.  I suspect there are
> >> technical reasons that IBM has not rushed to provide the function.
> >> Is the design of OS/360 such that any dynamic STEPLIB would be
> >> incomplete or have unintended consequences?
> >
> > Any dynamic STEPLIB functionality introduces potential System
> > Integrity> exposures, because some parts (modules) of a program may
> > have been
> loaded> from one library and others from a different, incompatible library.
> Such an exposure can just as easily occur from a static concatenation for
> STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant
> increase in such exposure.
>
> It is up to the site's programmers to ensure that the load libraries in
> use in a job step are mutually compatible.
> --
> Regards,
>
> Dave  [RLU #314465]
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> david.w.n...@googlemail.com (David W Noon)
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
>
>
> ATTENTION: -
>
> The information contained in this message (including any files transmitted
> with this message) may contain proprietary, trade secret or other
> confidential and/or legally privileged information. Any pricing information
> contained in this message or in any files transmitted with this message is
> always confidential and cannot be shared with any third parties without
> prior written approval from Syncsort. This message is intended to be read
> only by the individual or entity to whom it is addressed or by their
> designee. If the reader of this message is not the intended recipient, you
> 

Re: Dynamic Steplib and z/OS 2.3?

[Blaicher, Christopher Y.]

I think you are a little off.  A static concatenation cannot result in a mix of 
authorized and unauthorized libraries and the program running authorized.

Contents supervisor, when it goes to load the first module from EXEC PGM= 
checks the JOBLIB or STEPLIB for all libraries to be authorized, else the 
program while still being loaded will not run authorized.  If the program is 
being loaded from the LINKLST, it checks that the library it is being loaded 
from is authorized, otherwise it once again runs as unauthorized.

If at some later point a load of a module from a library in the LINKLST that is 
not authorized, or a directed LOAD/LINK/ATTACH/XCTL with a non-authorized 
library specified, will result in an ABEND.

I hope the writers of the STEPLIB concatenation routine were through enough to 
check the current authorization status of the job step and, if it is running 
authorized, validated that the library being added is also authorized.  
Otherwise the concatenation should fail.

If your shop has this function, I would verify that you cannot add an 
unauthorized library to a STEPLIB or JOBLIB.  If you can, you have just left a 
hole the size of the Lincoln Tunnel in your system.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Friday, September 22, 2017 3:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dynamic Steplib and z/OS 2.3?

On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell
(walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?"
(in <4974758334821366.wa.walt.farrellgmail@listserv.ua.edu>):

> On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com> 
> wrote:
>
>> Dynamic STEPLIB has been discussed in these fora so often that I
>> suspect it's the subject of numerous RFEs.  I suspect there are
>> technical reasons that IBM has not rushed to provide the function.
>> Is the design of OS/360 such that any dynamic STEPLIB would be
>> incomplete or have unintended consequences?
>
> Any dynamic STEPLIB functionality introduces potential System
> Integrity> exposures, because some parts (modules) of a program may
> have been
loaded> from one library and others from a different, incompatible library.
Such an exposure can just as easily occur from a static concatenation for 
STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant increase in 
such exposure.

It is up to the site's programmers to ensure that the load libraries in use in 
a job step are mutually compatible.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: Dynamic Steplib and z/OS 2.3?

[Rob Schramm]

I am probably veering the topic.. or into oncoming traffic.. but.. why let
that dissuade me? 

STEPLIB/JOBLIB is marked as being APF or not-APF when it is referenced (my
understanding... I am sure there is a more accurate description ).

I am assuming that to maintain integrity, the dynamic STEPLIB would have to
(I think my mind just exploded for a moment)
1) lookup whether it was eligible for dynamic STEPLIB
2) muck with the DEB to mark it non-APF if any of the dynamic STEPLIBs were
not APF
3) at least verify that if the JCL STEPLIB were APF, that the dynamic
portion would have to match

ugh.. and then what if you wanted it to be Special and do something with a
little less integrity?  Security check first?

Can't this just be accomplished via JES2 exit and just modify the JCL thus
leaving the normal STEPLIB integrity alone?

Or am I just being a bit dull on this Friday and cannot see a use-case?

Rob Schramm

On Fri, Sep 22, 2017 at 3:53 PM David W Noon <
013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell
> (walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?"
> (in <4974758334821366.wa.walt.farrellgmail@listserv.ua.edu>):
>
> > On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com>
> wrote:
> >
> >> Dynamic STEPLIB has been discussed in these fora so often that I suspect
> >> it's the subject of numerous RFEs.  I suspect there are technical
> reasons
> >> that IBM has not rushed to provide the function.  Is the design of
> OS/360
> >> such that any dynamic STEPLIB would be incomplete or have unintended
> >> consequences?
> >
> > Any dynamic STEPLIB functionality introduces potential System Integrity>
> exposures, because some parts (modules) of a program may have been
> loaded> from one library and others from a different, incompatible library.
> Such an exposure can just as easily occur from a static concatenation
> for STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant
> increase in such exposure.
>
> It is up to the site's programmers to ensure that the load libraries in
> use in a job step are mutually compatible.
> --
> Regards,
>
> Dave  [RLU #314465]
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> david.w.n...@googlemail.com (David W Noon)
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Dynamic Steplib and z/OS 2.3?

[David W Noon]

On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell
(walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?"
(in <4974758334821366.wa.walt.farrellgmail@listserv.ua.edu>):

> On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com> 
> wrote:
> 
>> Dynamic STEPLIB has been discussed in these fora so often that I suspect
>> it's the subject of numerous RFEs.  I suspect there are technical reasons
>> that IBM has not rushed to provide the function.  Is the design of OS/360
>> such that any dynamic STEPLIB would be incomplete or have unintended
>> consequences?
> 
> Any dynamic STEPLIB functionality introduces potential System Integrity> 
> exposures, because some parts (modules) of a program may have been
loaded> from one library and others from a different, incompatible library.
Such an exposure can just as easily occur from a static concatenation
for STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant
increase in such exposure.

It is up to the site's programmers to ensure that the load libraries in
use in a job step are mutually compatible.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: Dynamic Steplib and z/OS 2.3?

[Walt Farrell]

On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin  wrote:

>Dynamic STEPLIB has been discussed in these fora so often that I suspect
>it's the subject of numerous RFEs.  I suspect there are technical reasons
>that IBM has not rushed to provide the function.  Is the design of OS/360
>such that any dynamic STEPLIB would be incomplete or have unintended
>consequences?

Any dynamic STEPLIB functionality introduces potential System Integrity 
exposures, because some parts (modules) of a program may have been loaded from 
one library and others from a different, incompatible library. As IBM takes the 
System Integrity of z/OS very seriously, it is very unlikely that IBM will 
officially support that function, in my opinion as a former z/OS developer.

z/OS provides tasklibs, and some functions within TSO/E and ISPF to manage 
dynamic tasklibs, which do not introduce such exposures.

-- 
Walt

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

Re: Dynamic Steplib and z/OS 2.3?

[Paul Gilmartin]

On Thu, 21 Sep 2017 10:25:34 -0400, John Eells wrote:
>
>> Is IBM under any obligation to announce changes to the z/OS internals which 
>> do
>> not affect supported (GUPI) user interfaces?
>
>
>I'm not sure this has ever come up exactly this way before, so here is
>an overview of what I think we do today in these cases: ...
>
Thanks.  Treat my question as rhetorical.  I see your answer as, "No, but
we try to be nice."

Dynamic STEPLIB has been discussed in these fora so often that I suspect
it's the subject of numerous RFEs.  I suspect there are technical reasons
that IBM has not rushed to provide the function.  Is the design of OS/360
such that any dynamic STEPLIB would be incomplete or have unintended
consequences?

So cbttape.org fills the void.  WAD.  If it breaks you get your money back;
no coverage for consequential damages.  ISVs with similar conditions: If
you don't like it, just cancel your contract.

I understand TSO CALL ALLOCATEs a TASKLIB and does an ATTACH.
Numerous sites have coded similar for use outside TSO.  That works
(with side effects) for ATTACH, probably not for LOAD/LINK.

-- gil

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

Re: [EXTERNAL] Re: Dynamic Steplib and z/OS 2.3?

[Charles Mills]

Right. I was not criticizing the CBT. My point was just that Tone is stating as 
though novel what has been obvious for forty (?) years. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Thursday, September 21, 2017 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Dynamic Steplib and z/OS 2.3?

The ad strongly implies that it would impact a successful z/OS 2.3 migration.

I agree there is no formal support. That is also true for a lot of open source 
software but because it is open source it is probably better supported than 
some vendor software.

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

Re: Dynamic Steplib and z/OS 2.3?

[Nims,Alva John (Al)]

Yes, if I remember my timelines from when I was a contractor to the z/PET 
group, the BETA testers for z/OS would have had z/OS 2.3 for a couple of months 
by now and if the vendor signed up as a BETA tester, yes they would have z/OS 
2.3 before GA.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, September 21, 2017 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dynamic Steplib and z/OS 2.3?

Daniel S. Dalby wrote:

>I can tell you that the CBT Steplib (file 452) works flawlessly on zOS 2.3.
>I happen to work for a vendor and we have an early release and we use it daily 
>since we installed 2.3.

Before z/OS v2.3 is GA on 2017-09-29?

Groete / Greetings
Elardus Engelbrecht

--
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: Dynamic Steplib and z/OS 2.3?

[Elardus Engelbrecht]

Daniel S. Dalby wrote:

>I can tell you that the CBT Steplib (file 452) works flawlessly on zOS 2.3.
>I happen to work for a vendor and we have an early release and we use it daily 
>since we installed 2.3.

Before z/OS v2.3 is GA on 2017-09-29?

Groete / Greetings
Elardus Engelbrecht

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

Re: Dynamic Steplib and z/OS 2.3?

[Daniel S. Dalby]

Sorry to be late for the party ...

I can tell you that the CBT Steplib (file 452) works flawlessly on zOS 2.3.
I happen to work for a vendor and we have an early release and we use it daily 
since we installed 2.3.

Dan D

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

Re: [EXTERNAL] Re: Dynamic Steplib and z/OS 2.3?

[Dyck, Lionel B. (TRA)]

The ad strongly implies that it would impact a successful z/OS 2.3 migration.

I agree there is no formal support. That is also true for a lot of open source 
software but because it is open source it is probably better supported than 
some vendor software.

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, September 21, 2017 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Dynamic Steplib and z/OS 2.3?

The ad does not say they won't work anymore; just that they are unsupported. 
That is certainly a truism in any event for CBT software.


   





  If  you're planning a z/OS migration, your CBT STEPLIB facility and CA 
TSOPLUS  STEPLIB software  is not supported, and won't easily transition to the 
latest z/OS  operating systems.

CharlesSent from a mobile; please excuse the brevity.
 Original message From: Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> Date: 9/21/17  6:28 PM  
(GMT+01:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic Steplib and z/OS 
2.3? 
On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. wrote:

>Tone software in an advertisement from Enterprise Systems Media just 
>claimed that the CBT STEPLIB command and CA's TSOPLUS STEPLIB will not 
>work with z/OS 2.3 in a move to sell their DYNA-STEP.

I don't know the answer, but I did notice that there is additional support for 
RMODE(64) in z/OS 2.3. It is likely that some control blocks have changes to 
allow for 64-bit addresses. It is possible that such changes could cause 
problems.

--
Tom Marchant

--
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: Dynamic Steplib and z/OS 2.3?

[Charles Mills]

The ad does not say they won't work anymore; just that they are unsupported. 
That is certainly a truism in any event for CBT software.


   





  If  you're planning a z/OS migration, your CBT STEPLIB facility and CA 
TSOPLUS  STEPLIB software  is not supported, and won't easily transition to the 
latest z/OS  operating systems.

CharlesSent from a mobile; please excuse the brevity.
 Original message From: Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> Date: 9/21/17  6:28 PM  
(GMT+01:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamic Steplib and z/OS 
2.3? 
On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. wrote:

>Tone software in an advertisement from Enterprise Systems Media 
>just claimed that the CBT STEPLIB command and CA's TSOPLUS STEPLIB 
>will not work with z/OS 2.3 in a move to sell their DYNA-STEP.

I don't know the answer, but I did notice that there is additional support 
for RMODE(64) in z/OS 2.3. It is likely that some control blocks have 
changes to allow for 64-bit addresses. It is possible that such changes 
could cause problems.

-- 
Tom Marchant

--
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: Dynamic Steplib and z/OS 2.3?

[Tom Marchant]

On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. wrote:

>Tone software in an advertisement from Enterprise Systems Media 
>just claimed that the CBT STEPLIB command and CA's TSOPLUS STEPLIB 
>will not work with z/OS 2.3 in a move to sell their DYNA-STEP.

I don't know the answer, but I did notice that there is additional support 
for RMODE(64) in z/OS 2.3. It is likely that some control blocks have 
changes to allow for 64-bit addresses. It is possible that such changes 
could cause problems.

-- 
Tom Marchant

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

Re: Dynamic Steplib and z/OS 2.3?

[John Eells]

Paul Gilmartin wrote:

On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. (TRA) wrote:


Tone software in an advertisement from Enterprise Systems Media just claimed 
that the CBT STEPLIB command and CA's TSOPLUS STEPLIB will not work with z/OS 
2.3 in a move to sell their DYNA-STEP.

I have no problems with DYNA-STEP having used it in a prior life but I fail to 
see how either of the other two solutions will fail with z/OS 2.3 as I don't 
recall anything in the announcement or presentations that would imply changes 
to the z/OS internals that would affect them.


Is IBM under any obligation to announce changes to the z/OS internals which do
not affect supported (GUPI) user interfaces?



I'm not sure this has ever come up exactly this way before, so here is 
an overview of what I think we do today in these cases:


If a code change does not affect the behavior of the system's externals 
(including APIs), we feel free to change it at will without saying 
anything externally.  For example, on every new machine (it seems) we 
need to keep HiperDispatch's topology view up to date and account for 
other changes internal to the new processor.  Except when we announced 
HD to begin with I don't think we've mentioned any of these updates.


When we change the behavior of an external and you need to make a 
corresponding change or use a parameter to keep the old behavior, we 
think of that as a migration action, and put it in the book.  (Marna is 
the Keeper of the Migration Book.  If you don't know Marna, go look up 
the word "conscientious.")  Sometimes the migration actions are "good" 
migration actions, as for actions you will no longer need to take 
because the system will do them for you.


When we remove an entire function, we generally announce it and try to 
leave enough lead time for people to cope.


Outside public view, we have a program for telling other software 
vendors about changes if they are members of PartnerWorld, which several 
people have mentioned here in the past.  When we suspect or know that 
one or more vendors relies on something internal, we often notify them 
of such a change.  This is in addition to externals changes that are not 
yet announced, but for which we believe they need some lead time.  (When 
we get that wrong, they are not usually shy about letting us know!)


The CBT tools are potentially affected by new releases, but there is 
really no way to notify authors of upcoming changes in advance.  Some of 
those tools historically rely on internals, and they are most at risk. 
Those written to APIs are less so but could be affected by a migration 
action.  (I'll note that I think it's really cool that many authors 
update their tools and that others fix them up, all on a volunteer basis 
and that Sam and Sam maintain the collection and the site.)


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Dynamic Steplib and z/OS 2.3?

[Paul Gilmartin]

On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. (TRA) wrote:

>Tone software in an advertisement from Enterprise Systems Media just claimed 
>that the CBT STEPLIB command and CA's TSOPLUS STEPLIB will not work with z/OS 
>2.3 in a move to sell their DYNA-STEP.
>
>I have no problems with DYNA-STEP having used it in a prior life but I fail to 
>see how either of the other two solutions will fail with z/OS 2.3 as I don't 
>recall anything in the announcement or presentations that would imply changes 
>to the z/OS internals that would affect them.
> 
Is IBM under any obligation to announce changes to the z/OS internals which do
not affect supported (GUPI) user interfaces?

>Can anyone confirm this claim about the CBT STEPLIB command or CA's TSOPLUS?

-- gil

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

Re: Dynamic Steplib and z/OS 2.3?

[Doug Henry]

On Thu, 21 Sep 2017 12:56:22 +, Dyck, Lionel B. (TRA)  
wrote:

Hi Lionel,
CA has withdrawn TSOPLUS from support and marketing before z/OS V2r2. It has a 
check in it for the operating system level. For a while we ran it on z/OS V2R2 
and I zapped  it prevent it from checking the z/OS level. They would have that 
check because when they supported it they would reassemble for the highest z/OS 
level. So if you have the product and wanted to zap it would it work on z/OS 
V2R3?.  

Doug

>Tone software in an advertisement from Enterprise Systems Media just claimed 
>that the CBT STEPLIB command and CA's TSOPLUS STEPLIB will not work with z/OS 
>2.3 in a move to sell their DYNA-STEP.
>
>I have no problems with DYNA-STEP having used it in a prior life but I fail to 
>see how either of the other two solutions will fail with z/OS 2.3 as I don't 
>recall anything in the announcement or presentations that would imply changes 
>to the z/OS internals that would affect them.
>
>Can anyone confirm this claim about the CBT STEPLIB command or CA's TSOPLUS?
>
>
>--
>Lionel B. Dyck
>Mainframe Systems Programmer - TRA
>

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

Re: Dynamic Steplib and z/OS 2.3?

[Martin Packer]

Lionel, you asked ALMOST the same question as I wanted to - when I read 
the Ad.

The question I would ask is "was there a change in 2.3 that killed these 
tools. And, if so, what was it?"

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, 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



From:   "Dyck, Lionel B. (TRA)" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   21/09/2017 13:56
Subject:Dynamic Steplib and z/OS 2.3?
Sent by:IBM Mainframe Discussion List 



Tone software in an advertisement from Enterprise Systems Media just 
claimed that the CBT STEPLIB command and CA's TSOPLUS STEPLIB will not 
work with z/OS 2.3 in a move to sell their DYNA-STEP.

I have no problems with DYNA-STEP having used it in a prior life but I 
fail to see how either of the other two solutions will fail with z/OS 2.3 
as I don't recall anything in the announcement or presentations that would 
imply changes to the z/OS internals that would affect them.

Can anyone confirm this claim about the CBT STEPLIB command or CA's 
TSOPLUS?


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA


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