Re: Internal Coupling Channel on z13

[Ed Jaffe]

On 1/29/2019 10:07 PM, Brian Westerman wrote:

No, just one single CP, no specialty processors are available.



We have two CF LPARs (CF01 and CF02) sharing a single ICF engine. From 
both CF consoles I see:



2019029 22:56:50 => display dyndisp
2019029 22:56:50 CF0512I Dynamic CF Dispatching is THINinterrupts.

Right now things are pretty quiet on the system and from my z13s 
monitoring dashboard, I am seeing our ICF only 1% utilized with THIN 
interrupts.


When I change to DYNDISP ON instead of DYNDISP THIN, I still see only 1% 
utilized.


Of course, when I switch to DYNDISP OFF utilization jumps to 100%.

DYNDISP THIN should be more responsive and less CPU hungry than DYNDISP 
ON, but I can't really tell the difference with my simple test. Both 
seem pretty thrifty.



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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Internal Coupling Channel on z13

[Mike Schwab]

What is the percent busy at peak times?  How big a percent do you
need?  10% for the ICF partition?  Would you save that much by
converting Ring to Star?

On Wed, Jan 30, 2019 at 12:07 AM Brian Westerman
 wrote:
>
> No, just one single CP, no specialty processors are available.
>
> Brian
>
> --
> 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: Internal Coupling Channel on z13

[Ed Jaffe]

On 1/29/2019 10:17 PM, Brian Westerman wrote:

This particular box has just a single CP, no specialty processors, 3 LPARs, one 
of them production, one application programmer test, and the other a sandbox 
that is extremely low use and in any case shares only the res volume.

They "need" to run GRS because it's not really safe to run without it 
(especially since there is nothing to keep a lockout from occurring but to be careful), 
but they can't afford to add a specialty processor, at least not at this time.

I'm trying to find out if they can install the microcode CF and assuming that the CPU use 
for the CF is now "low" if they could use it for DASD sharing only.  There is 
no real data sharing involved (no DB2, no CICS).  So we are just talking about GRS 
shipping the ENQs around.


In theory, coupling facility thin interrupts is faster than previous CF 
technologies on shared CPs: 
https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102400


ICF specialty engines are ridiculously priced (i.e., wy too high). 
If they can't afford a second CP, they can't afford an ICF. Too bad, 
because that would make all the difference.


Is it no longer possible to use "old school" shared DASD RESERVE/RELEASE 
to protect data? I know it won't work for sharing PDSE, but for 
old-school PDS and sequential, it should still work.



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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Using IPCS ACTIVE and alt ASID to display extended private storage

[Binyamin Dissen]

You have failed to answer as to what you see when you try to display x'5000'
in the target address space.

On Tue, 29 Jan 2019 11:28:24 -0600 Wendell Lovewell
<01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote:

:>Thanks for your replies.  I had done a REFRESH in RACF for the FACILITY 
profile changes. 

:>If I start IPCS in an alternate session and then allow the application to 
abend, I can still view memory areas after the abend via ACTIVE in the 
alternate session, but not from a second TSO user.  (But viewing from a split 
screen affects the getmain'd addresses I'm trying to view.)

:>Could there be something about storage keys that I'm missing?  The 
application does run from an APF authorized library, but AC=0.  

--
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: Internal Coupling Channel on z13

[Brian Westerman]

This particular box has just a single CP, no specialty processors, 3 LPARs, one 
of them production, one application programmer test, and the other a sandbox 
that is extremely low use and in any case shares only the res volume.

They "need" to run GRS because it's not really safe to run without it 
(especially since there is nothing to keep a lockout from occurring but to be 
careful), but they can't afford to add a specialty processor, at least not at 
this time.  

I'm trying to find out if they can install the microcode CF and assuming that 
the CPU use for the CF is now "low" if they could use it for DASD sharing only. 
 There is no real data sharing involved (no DB2, no CICS).  So we are just 
talking about GRS shipping the ENQs around.

Has anyone tried this yet?

Brian

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

Re: Internal Coupling Channel on z13

[Brian Westerman]

I agree that before the current CF20 implementation of the micocode only 
version, it was supposed ot be almost fatal to try it, but with the new z13s 
and z14 it's "supposed" to be "low" impact, but it doesn't really talk about 
how low the impact is, and if it can be done with a single CP and no specialty 
processors.

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

Re: Internal Coupling Channel on z13

[Brian Westerman]

Do you have any figures for how much "more" friendly the CPU usage is?

This box is a single CPU, no ICF, Zipp or zapp.

Brian

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

Re: Internal Coupling Channel on z13

[Brian Westerman]

NO, I'm trying to use the Microcode Implementation, it has no CTC, and is just 
memory to memory between LPARs on the same physical box.

Brian

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

Re: Internal Coupling Channel on z13

[Brian Westerman]

No, just one single CP, no specialty processors are available.

Brian

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

Re: Newbie SMP/E questions

[Mike Schwab]

I think you can REJECT specific PTFs.

On Tue, Jan 29, 2019 at 10:07 AM Bob Bridges  wrote:
>
> I'm the Top-Secret admin for a client whose system programmer retired a 
> couple years ago.  The client tapped another employee to take his place, and 
> she's learning the job with frantic haste but insists with some justification 
> that she's not a system programmer yet.  Me, I came into security through the 
> applications-development side so I'm not even close.
>
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
> can apply some TSS-related PTFs, but really, it's become clear to me that we 
> need no excuses to make it a priority; SMP/E is kind of important.
>
> I have embarked on a serious reading of the SMP/E User's Guide, but I still 
> need help.  I'll limit myself to a handful of questions to start with:
>
> Question #1) We started by applying a PTF - call it A for simplicity - and 
> its prerequisite B.  We did that last August and then the project languished 
> for the sake of other priorities.  Now we're working on it again and we want 
> to restore those two PTFs and do the APPLY again.  Why?  Well, partly because 
> it was 'way back in August and we're uncertain about exactly how we did it 
> back then.  We know more now.  Partly because we know more now and we want to 
> practice it better.  I dunno, partly because we just want to.  I think maybe 
> we bypassed some HOLDs back then too.
>
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
> saying we need to include other PTFs in the RESTORE.  Some of these have an 
> indirect connection to A and B; B superceded at least three of them, for 
> example, which I can see were applied some years ago.  Others have no 
> relation to our PTFs that I can discern.  I haven't yet found the place in 
> the User's Guide that explains these relationship and their relevance.  Can 
> someone give a helpful explanation?
>
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this thing in the past never did any ACCEPT, ever, except for the original 
> function code.  I see at least 11 PTFs that were applied (including our two), 
> but the distribution library shows no PTFs for any module I've yet LISTed.  
> If true, does that mean that to do a RESTORE of our two PTFs we'll have to 
> RESTORE everything back to the plain-vanilla base?
>
> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside this CSI (which is dedicated to Top Secret) and create another one 
> starting with the base software and build up from there.  I didn't realize 
> this could be done, but she thinks she can do it.  If it'll work, I like it; 
> we'll know in that case what we have, which we do not at present.  Anyone 
> have any thoughts on this plan?
>
> Question #4) This is a less-important add-on:  In both the online 
> documentation and the User's Guide, I read if I'm doing a RESTORE and name 
> PTFs A and B, including the GROUP operand causes SMP/E to add whatever other 
> PTFs are required for various reasons.  It doesn't seem to, though; it names 
> them and complains about them, but doesn't add them to the list.  Have I 
> misunderstood something?  I'm loathe to believe the documentation is flat 
> wrong.
>
> If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 
> UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
>
> ---
> Bob Bridges, cell 336 382-7313
>   robhbrid...@gmail.com
>   rbrid...@infosecinc.com
>
> /* Anyone can do any amount of work, provided it isn't the work he is 
> supposed be doing at that moment.  -Robert Benchley */
>
> --
> 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: Internal Coupling Channel on z13

[Timothy Sipples]

I agree with the recommendation to get a CF engine as the best/first choice
all around. I also agree to proceed with caution if you're going to share
one or more CPs between the Coupling Facility Control Code (CFCC) and z/OS
and/or other operating systems. "Proceed with caution" is not the same
thing as "don't." You just want to be extra careful, test well, and back
off the idea if it's not suitable in your environment since there are some
potential issues that could surface.

However, if you have one or more CPs (general purpose processors) that
you're willing to *dedicate* to a CFCC LPAR, this caution doesn't apply. In
this case you're using a dedicated CP as if it were a CF engine, and that's
perfectly fine. You might be dedicating a sub-capacity CP (or more than
one) with different capacity characteristics than a CF engine, but there's
no particular issue with that as long as you have sufficient capacity for
your needs.

Or, if you have some "trivial" z/OS workload sharing that CP with the CFCC,
such as a "sandbox" z/OS LPAR for system programmers that sees little
activity, that might be fine.

There are certain upgrade scenarios when it can make a great deal of sense
to use one or more CPs for the CFCC for relatively brief periods of time.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com

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

ARC1139I RC39 RSB08

[Munif Sadek]

Dear listers

we are SNSPLex and common recall queue between our Production and test LPAR

ARC1500I PLEXNAME=ARCPLEX0,PROMOTE PRIMARYHOST=NO,PROMOTE SSM=NO,COMMON RECALL 
ARC1500I (CONT.) QUEUE BASE NAME=HSMPLEX,COMMON RECALL QUEUE

Problem is a valid user with valid access recalling a dataset in Production but 
recall request is getting processed on Test LPAR where userid dose not exist. 
Dataset profile does exist as we share all the  DASDs and other infrastructure.

In Production SYSTEM   
ARC1001I XXX.YY.ZZ  RECALL FAILED, RC=0039, REAS=0008  
ARC1139I ERROR PROCESSING RACF PROTECTED DATA SET, RECOVERY/RECALL/DELETE   
ARC1139I (CONT.) TERMINATED  

In Test SYSTEM we get  
ICH408I USER(USERID ) GROUP(@@ACTIVE) NAME(USER NAME) LOGON/JOB 
INITIATION REVOKED USER ACCESS ATTEMPT 

Is there a PATCH / SURROGATE / HSM SAF facility that can fix this *generic* 
error.

regards
Munif

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

Re: Newbie SMP/E questions

[Tony Harminc]

On Tue, 29 Jan 2019 at 11:07, Bob Bridges  wrote:
>
> I'm the Top-Secret admin for a client whose system programmer retired a 
> couple years ago.  The client tapped another employee to take his place, and 
> she's learning the job with frantic haste but insists with some justification 
> that she's not a system programmer yet.  Me, I came into security through the 
> applications-development side so I'm not even close.
>
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
> can apply some TSS-related PTFs, but really, it's become clear to me that we 
> need no excuses to make it a priority; SMP/E is kind of important.

Lots of good info already. I have just a comment or two, more in
passing than specifically answering your questions.

> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this thing in the past never did any ACCEPT, ever, except for the original 
> function code.

Your use of LIST XREF is Very Good. As an ISV we are forever asking
customers to send us the result of SMP/E LIST . commands, and half the
time we get the output from LIST SYSMODS or LIST PTFS or the like,
which doesn't tell us everything.

You can always ask SMP/E something specific, or you can say "tell me
everything you know", and save that large chunk of output and then
search it with ISPF or on your desktop or wherever you like to do that
kind of thing. If you want to document the situation at a given time,
I highly recommend storing the result from a LIST ALLZONES XREF. Then
you can do simple find commands on PTF IDs or module names or even
things like the comments in PTFs that you no longer can find the
source for.

The earlier suggestion to use the z/OS UNIX interface is an
alternative if you are comfortable with UNIXy line commands. You could
probably send its output to your favorite tool(s) which could even be
a desktop spreadsheet.

> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside this CSI (which is dedicated to Top Secret) and create another one 
> starting with the base software and build up from there.  I didn't realize 
> this could be done, but she thinks she can do it.  If it'll work, I like it; 
> we'll know in that case what we have, which we do not at present.  Anyone 
> have any thoughts on this plan?

If you are in any doubt as to what you have, then it's a good idea. It
may be obvious, but let me say it: the SMP/E CSI is a bit like the
catalog on z/OS. It has all kinds of information about what's where,
and so on, but the actual datasets as defined by the DDDEF entries are
definitive as to what the data *is*. If you update one or the other
independently, then you are likely to be in big trouble, just as you
would be if you restored a catalog from a backup independent of the
datasets it points to, or the other way around. So treat the CSI and
the datasets it points to as a unit when it comes to backup/restore
operations. It's not impossible to manage the pieces independently,
but it's usually a bad idea.

Also, it is certainly possible for someone to have updated a target or
DLIB dataset known to SMP/E outside SMP/E using the Binder or IEBCOPY
etc, and then you have no reliable way of knowing what your state of
affairs is. This is perhaps unlikely if your predecessor was a wise
and experienced person, but it happens. Someone needs to bang on a
quick fix or apply a ZAP in a rush, and then the "paperwork" (CSI)
doesn't get updated to match.

Simple, standalone products maintained by SMP/E are, well - simple and
standalone. Typically the target zone's LOAD dataset is used as the
production STEPLIB'd load library. Or a promote to production or
staging through test layers scheme that is outside of SMP/E is used to
make an exact copy of that module data to one or more production
datasets.

But something like TSS, and certainly some of the z/OS components,
have specific requirements as to where the modules live, such as
LPALIB or Linklist datasets. The promotion process in this case can be
more complex, and with any system-level product you run the risk of
breaking the system if you get it wrong. SMP/E will do its best (for
example, recovering from an out of space condition while building a
load module), but it can't fix what it doesn't know about. Any such
product will come with detailed instructions for initial installation
and ongoing maintenance, which you need to follow carefully. Again,
this may be obvious, but if you are both new to sysprogging, I think
it can't hurt to sayit.

Best of luck in learning about and using what you have inherited!

Tony H.

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

Re: Internal Coupling Channel on z13

[Jesse 1 Robinson]

We've used ICF on pretty much every model of hardware since z10. We're 
currently on z14 and z13s. We use internal coupling links with external links 
to another CEC. 

We do have--and always have--CF engines shared among non-prod LPARs using thin 
interrupt protocol. I would hesitate to suggest buying CFs just for GRS star, 
but if you already have them, star so far outperforms ring that there should be 
no hesitation in moving there. I also would not consider using regular CPs. 
They would work, but poorly. 

.
.
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 Dana Mitchell
Sent: Tuesday, January 29, 2019 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Internal Coupling Channel on z13

Brian,

We've actually been thinking about this too, as we evaluate moving to z14's. We 
currently have a 5 member GRS ring that could really benefit moving to GRS 
Star,  but nobody want's to spend any $ for an ICF.

As of BC12 generation IBM was still recommending against using GPs for CF 
processors:

According to an IBM paper titled:  Coupling Thin Interrupts and CF Performance 
in Shared Processor Environments

While it is possible to use general purpose processors, CPs, as CF processors 
and share the CPs with z/OS and other similarly defined CFs, this is not a 
recommended configuration. Using CPs as CF processors creates interaction 
between z/OS and the CF in terms of cache reuse and other factors that may 
impact performance. 

Dana


On Tue, 29 Jan 2019 00:23:56 -0600, Brian Westerman 
 wrote:

>Hi,
>
>Has anyone had any experience with using the internal coupling channels on a 
>z13.  "supposedly" IBM has removed the active wait problems (where the CF lpar 
>would try to use 100% of whatever it gets from PR/SM), but I was wondering if 
>it's ready for prime time yet.  I have a z13s (single CPU) with 3 LPARs on it, 
>they are fairly low use, but I think it'a about time the started to use GRS 
>since they share DASD (it was small, but now more and more as time goes on).  
>They have been lucky so far, but I would rather not rely on luck.  They don't 
>have the cash to add a specialty processor, and if IBM has really reduced the 
>overhead of ICF, then it might be a good fit for them.

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

Re: External dsect

[scott Ford]

Yeah, guys this what I thought ECVT entry was the way to go..Rob I agree
very 80s. We have a ECVT table entry, so this much better way to go.
I wanted to make sure i know my options before I try to design it. Thanks
one and all, it’s very much appreciated.



On Tue, Jan 29, 2019 at 3:18 PM Charles Mills  wrote:

> Let me recommend that vendor word approach. We use it and it works well.
> You just want to define the structure that the word will point to in such a
> way that you do not paint yourself into an upward compatibility corner. The
> word is zero if you have not initialized it.
>
> Access could not be easier:
>
>  L  R1,FLCCVT-PSA(,0)  Point to CVT
>  L  R1,CVTECVT-CVT(,R1) Point to ECVT
>  L  R8,ECVTCTBL-ECVT(,R1)   Point to Cust Anchor Table
>  L  R7,CZ_from_CTBL(,R8)Load our word
>  LTRR7,R7  Is it there?
>
> I believe our own @Peter Relson is the custodian of the word assignments.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Christopher Y. Blaicher
> Sent: Tuesday, January 29, 2019 10:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: External dsect
>
> If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL
> word assigned to your company.  That word can be used to point to a CSA
> structure of your own making.  You can have a program that reads a parm
> file and sets appropriate values.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: External dsect

[Charles Mills]

Let me recommend that vendor word approach. We use it and it works well. You 
just want to define the structure that the word will point to in such a way 
that you do not paint yourself into an upward compatibility corner. The word is 
zero if you have not initialized it.

Access could not be easier:

 L  R1,FLCCVT-PSA(,0)  Point to CVT
 L  R1,CVTECVT-CVT(,R1) Point to ECVT
 L  R8,ECVTCTBL-ECVT(,R1)   Point to Cust Anchor Table
 L  R7,CZ_from_CTBL(,R8)Load our word
 LTRR7,R7  Is it there?

I believe our own @Peter Relson is the custodian of the word assignments.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 29, 2019 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
assigned to your company.  That word can be used to point to a CSA structure of 
your own making.  You can have a program that reads a parm file and sets 
appropriate values.

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

Re: External dsect

[Matt Hogstrom]

The approach would work but I think even a LOAD in a system exit is not a good 
idea.  As Chris said, if you are an ISV you may already have an ECVT entry.  
Today I’d almost expect that someone would update a dataset with the changes 
and then issue a MODIFY urApp,NEWPARMS=xxx and urApp would read the dataset, 
update the in-memory copy and manage all the serialization so your exit could 
just operate on what was in memory and not have to manage it at that level.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270

"Aut Inveniam Viam Aut Faciam" translated -
"I shall either find a way or make one."

The phrase has been attributed to Hannibal 
; when his generals told him it was 
impossible to cross the Alps by elephant 
,

> On Jan 29, 2019, at 1:52 PM, Christopher Y. Blaicher  
> wrote:
> 
> If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
> assigned to your company.  That word can be used to point to a CSA structure 
> of your own making.  You can have a program that reads a parm file and sets 
> appropriate values.
> PS - Most system exits don't behave well with real I/O because they take too 
> long.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Rob Schramm
> Sent: Tuesday, January 29, 2019 1:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: External dsect
> 
> Scott,
> 
> Not to be overly critical, but isn't this scheme a little 1980's?  I had 
> thought most products had moved away from this and moved to parm-driven with 
> some sort of refresh or command driven override.
> 
> Not saying it won't work.. because it will.
> 
> I will let others comment on the specifics.
> 
> Rob Schramm
> 
> 
> 
> Sent from my BlackBerry - the most secure mobile device
> 
>   Original Message
> From: idfli...@gmail.com
> Sent: January 29, 2019 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply-to: IBM-MAIN@LISTSERV.UA.EDU
> Subject: External dsect
> 
> All:
> 
> I want to be able to have an options program for our product that the 
> customer updates.
> Then they would assemble/bind it and we can call it to pass options to our 
> exits. The exits are system type exits, so i know I/O is limited or not 
> existent. My question is if i want a program to build the dsect i need to see 
> an example i assume , please correct me if I am wrong, that i would have:
> 
> CSECT ...
> .
> DSECT
> 
> Below is a sample if found.
> 
> PRMDSECT DSECTPARM-DSECT (R7)
> 
>  USING *,R7   INFORM ASSEMBLER
> 
> PRMTRGT  DSCL8TARGET-PGM
> 
> PRMADDR  DSXL4TARGET-PGM LOAD-ADDRESS
> 
> PRMERRCD DSXL4TARGET-PGM ERROR-CODE
> 
> PRMRSA  EQU   *  BEGIN PARM-RSA
> 
> LOADPGM   CSECT
> 
>   USING *,R3   INFORM ASSEMBLER
> 
>   LAR3,0(,R15) CSECT ADDRESSABILITY
> 
>   L R7,0(,R1)  PARMAREA ADDRESSABILITY
> 
>   LAR9,PRMRSA  POINT TO OUR RSA
> 
>   XC0(72,R9),0(R9) ENSURE X'00'S
> 
>   LAR15,0(,R9) LOAD WITH OUR RSA-ADDRESS
> 
>   STR13,4(,R15)BACKWARD-CHAIN
> 
>   STR15,8(,R13)FORWARD-CHAIN
> 
>   LRR13,R15LOAD WITH OUR RSA-ADDRESS
> 
>  XCPRMADDR,PRMADDRENSURE X'00'S
> 
>  LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD
> 
>  STCM  R0,B'',PRMADDR STORE IN PARM-FWORD
> 
>   XRR1,R1  ENSURE X'00'S
> 
> BADLOAD  EQU   *
> 
>   STCM  R1,B'',PRMERRCD
> 
> RTN2CLLR EQU   *
> 
>  L R13,4(,R13)RESTORE CALLERS R13
> 
>  XC0(72,R9),0(R9) ENSURE X'00'S
> 
> *
> 
>  RETURN (14,12),RC=(15)   RESTORE AND RETURN
> 
> *
> 
>  LTORG ,
> 
>  YREGS ,  MVS REGISTER-MACRO
> 
> LOADPGM  AMODE 31  ,
> 
> LOADPGM  RMODE ANY ,
> 
>  END   ,
> 
> 
> I am think my exit could issue a LOAD for a program similar to above with 
> something like this:
> 
> OPTSPARM DSECT
> 
> OPTTBL   DS0F
> 
> LOGMSGS  DCC'P',H'5',C'LOG=Y'
> 
> TRACEDCC'P',H'7',C'TRACE=N'
> 
> TBLEND   DCX'FF',H'0',C' '
> 
> 
> 
> Then the exit would take action based on the options passed. It would have to 
> be re-entrant of course.  Is my thinking right all ?
> 
> 
> Scott
> 
> 
> *IDMWORKS *
> 
> Scott Ford
> 
> z/OS Dev.
> 
> 
> 
> 
> “By elevating a friend or Collegue you elevate yourself, by demeaning a 
> friend or collegue you demean yourself”
> 
> 
> 
> www.idmworks.com
> 
> scott.f...@idmworks.com
> 
> Blog: 

Re: D U, , ALLOC GIVES MSGIEE106I *UNKNOWN (UNKNOWN) MVS DISPLAY ALLOCATED UNITS COMMAND

[Stone, Marshall]

There is a VARY command that uses UNCOND - vary online unconditional sometimes 
can override a BOXED device

MS
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, January 29, 2019 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: D U, , ALLOC GIVES MSGIEE106I *UNKNOWN (UNKNOWN) MVS DISPLAY 
ALLOCATED UNITS COMMAND

What happens if you box a device offline?

Can you bring it back online?

Rob Schramm

On Tue, Jan 29, 2019, 2:19 AM Mehrshad Manshadi <
0056e0e17177-dmarc-requ...@listserv.ua.edu wrote:

> In response to a  D U,,ALLOC command, msgIEE106I is issued
> indicating a jobname of *UNKNOWN for certain DASD units.  It is
> also not possible to Vary the unit(s) offline (unable to vary).
>This problem was traced to an OEM product changing the UCB
> in a job's TIOT without incrementing the new UCB's UCBUSER
> (Number of Current Users use-count) field.  When the new UCB
> was subsequently de-allocated, MVS Allocation code decremented
> UCBUSER, causing it to become negative.  Since UCBUSER was then
> not zero, the device appeared to be allocated even though there
> was no address space known to be allocated to it.  As a result,
> UCBALOC was never turned off and the device could not be
> varied OFFLINE.
>
>  See Scratch Pad for OEM information.
> Please help me to solve the problem. from where i can find scratch pad for
> OEM? in OS configuration or hardware?!How can I turned off UCBALOC ?
> For your information we changed the number of aliases in IODF and just
> activate it without IPL or power on reset the machine.
> Thanks
>
> --
> 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
The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: External dsect

[Christopher Y. Blaicher]

If you are an ISV, then I would contact IBM and ask to get an ECVTCTBL word 
assigned to your company.  That word can be used to point to a CSA structure of 
your own making.  You can have a program that reads a parm file and sets 
appropriate values.
PS - Most system exits don't behave well with real I/O because they take too 
long.

Chris Blaicher
Technical Architect
Syncsort, Inc.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Tuesday, January 29, 2019 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External dsect

Scott,

Not to be overly critical, but isn't this scheme a little 1980's?  I had 
thought most products had moved away from this and moved to parm-driven with 
some sort of refresh or command driven override.

Not saying it won't work.. because it will.

I will let others comment on the specifics.

Rob Schramm



Sent from my BlackBerry - the most secure mobile device

  Original Message
From: idfli...@gmail.com
Sent: January 29, 2019 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-to: IBM-MAIN@LISTSERV.UA.EDU
Subject: External dsect

All:

I want to be able to have an options program for our product that the customer 
updates.
Then they would assemble/bind it and we can call it to pass options to our 
exits. The exits are system type exits, so i know I/O is limited or not 
existent. My question is if i want a program to build the dsect i need to see 
an example i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECT    PARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DS    CL8    TARGET-PGM

PRMADDR  DS    XL4    TARGET-PGM LOAD-ADDRESS

PRMERRCD DS    XL4    TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LA    R3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LA    R9,PRMRSA  POINT TO OUR RSA

  XC    0(72,R9),0(R9) ENSURE X'00'S

  LA    R15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  ST    R13,4(,R15)    BACKWARD-CHAIN

  ST    R15,8(,R13)    FORWARD-CHAIN

  LR    R13,R15    LOAD WITH OUR RSA-ADDRESS

 XC    PRMADDR,PRMADDR    ENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XR    R1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)    RESTORE CALLERS R13

 XC    0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


I am think my exit could issue a LOAD for a program similar to above with 
something like this:

OPTSPARM DSECT

OPTTBL   DS    0F

LOGMSGS  DC    C'P',H'5',C'LOG=Y'

TRACE    DC    C'P',H'7',C'TRACE=N'

TBLEND   DC    X'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have to 
be re-entrant of course.  Is my thinking right all ?


Scott


*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a friend 
or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog






*The information contained in this email message and any attachment may be 
privileged, confidential, proprietary or otherwise protected from disclosure. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution, copying or use of this message 
and any attachment is strictly prohibited. If you have received this message in 
error, please notify us immediately by replying to the message and permanently 
delete it from your computer and destroy any printout thereof.*

--
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: Newbie SMP/E questions

[Jerry Callen]

> The other option is to see if the ISPF environment has the ISPF SMP/E panels 
> available.

If you are coming from a Unix background, are comfortable with the USS command 
line and scripting, and have the xlc compiler available (a lot of "ifs"...), 
you might want to try this:

https://github.com/zorts/smpapi

It's a little C program that uses the SMP query API to dig information out of 
the SMPCSI. I personally find it easier to use than the ISPF panels.

-- Jerry

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

Re: D U,,ALLOC GIVES MSGIEE106I *UNKNOWN (UNKNOWN) MVS DISPLAY ALLOCATED UNITS COMMAND

[Rob Schramm]

What happens if you box a device offline?

Can you bring it back online?

Rob Schramm

On Tue, Jan 29, 2019, 2:19 AM Mehrshad Manshadi <
0056e0e17177-dmarc-requ...@listserv.ua.edu wrote:

> In response to a  D U,,ALLOC command, msgIEE106I is issued
> indicating a jobname of *UNKNOWN for certain DASD units.  It is
> also not possible to Vary the unit(s) offline (unable to vary).
>This problem was traced to an OEM product changing the UCB
> in a job's TIOT without incrementing the new UCB's UCBUSER
> (Number of Current Users use-count) field.  When the new UCB
> was subsequently de-allocated, MVS Allocation code decremented
> UCBUSER, causing it to become negative.  Since UCBUSER was then
> not zero, the device appeared to be allocated even though there
> was no address space known to be allocated to it.  As a result,
> UCBALOC was never turned off and the device could not be
> varied OFFLINE.
>
>  See Scratch Pad for OEM information.
> Please help me to solve the problem. from where i can find scratch pad for
> OEM? in OS configuration or hardware?!How can I turned off UCBALOC ?
> For your information we changed the number of aliases in IODF and just
> activate it without IPL or power on reset the machine.
> Thanks
>
> --
> 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: External dsect

[Rob Schramm]

Scott,

Not to be overly critical, but isn't this scheme a little 1980's?  I had 
thought most products had moved away from this and moved to parm-driven with 
some sort of refresh or command driven override.

Not saying it won't work.. because it will.

I will let others comment on the specifics.

Rob Schramm



Sent from my BlackBerry - the most secure mobile device

  Original Message  
From: idfli...@gmail.com
Sent: January 29, 2019 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-to: IBM-MAIN@LISTSERV.UA.EDU
Subject: External dsect

All:

I want to be able to have an options program for our product that the
customer updates.
Then they would assemble/bind it and we can call it to pass options to our
exits. The exits
are system type exits, so i know I/O is limited or not existent. My
question is if i want a program to build the dsect i need to see an example
i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECT    PARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DS    CL8    TARGET-PGM

PRMADDR  DS    XL4    TARGET-PGM LOAD-ADDRESS

PRMERRCD DS    XL4    TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LA    R3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LA    R9,PRMRSA  POINT TO OUR RSA

  XC    0(72,R9),0(R9) ENSURE X'00'S

  LA    R15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  ST    R13,4(,R15)    BACKWARD-CHAIN

  ST    R15,8(,R13)    FORWARD-CHAIN

  LR    R13,R15    LOAD WITH OUR RSA-ADDRESS

 XC    PRMADDR,PRMADDR    ENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XR    R1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)    RESTORE CALLERS R13

 XC    0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


I am think my exit could issue a LOAD for a program similar to above with
something like this:

OPTSPARM DSECT

OPTTBL   DS    0F

LOGMSGS  DC    C'P',H'5',C'LOG=Y'

TRACE    DC    C'P',H'7',C'TRACE=N'

TBLEND   DC    X'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have
to be re-entrant of course.  Is my thinking right all ?


Scott


*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog






*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

--
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: IKJEFT1B program name SMF

[Charles Mills]

"Programs" do not get to write or directly control the contents of SMF 30 
records. IRXJCL would have no way to "record the member" (in the SMF 30).

IBM would of course be free to add the PARM= information to the SMF 30 record, 
or to create a new record type for PARM= data, or a new record type for IRXJCL 
options and results.

I have no idea of the efficacy of an RFE, but snowflakes and Avernus come to 
mind. 

I do not disagree with the assertion that PARM= data would be useful. As a guy 
who has spent the past 8 years trying to populate organizational security 
threat repositories from the contents of SMF records I can tell you that there 
is a lot of additional data that would be useful in SMF records. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, January 29, 2019 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IKJEFT1B program name SMF

On Tue, 29 Jan 2019 09:08:07 -0800, Charles Mills wrote:

>To the best of my (possibly faulty, of course) recollection SMF does not 
>record PARM= anywhere under any circumstances -- other than if it somehow gets 
>used in a way that ends up in SMF, e.g. a program that takes PARM=ddname and 
>then opens that DD name. (You would get an SMF 14, 15, 42 or 6x for that OPEN 
>or CLOSE, or an SMF 80 or 230 if the OPEN failed for security reasons.)
> 
This feels like cause fo RFE that IRXJCL itself should record in SMF the member 
called.
Most readers would find the "%SOMETHING"  more informative than "IRXJCL".

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

Re: Newbie SMP/E questions

[Chris Hoelscher]

Just a few thoughts from my vast (well, half-vast) SMP/E experience


Always receive HOLDDATA before doing anything - it may alert you to previously 
received fixes that are now marked PE (PROGRAM IN ERROR)
Holddata can also inform you of previously-PE ptf that are now resolved

The REPORT ERRSYSMODS COMMAQND IS YOUR FRIEND
 
Accept the base (fmid) - never ACCEPT a ptf until/unless you are damned sure 
you will never need to remove it (that could mean NEVER )
After EVERY smp/e modification, backup (dfdss/favr/whatever) your entire smp/e 
environment - and keep many many generations - you can use these to do an end 
run around the need to RESTORE

How far back do you need to go in a restore - until you are clean or pre-and 
co-requisite PTFs (could be many iterations)

If all else fails, start over with a new CSI 


Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Tuesday, January 29, 2019 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Newbie SMP/E questions

Never heard of CA-MSM, but I'll look into it.  (I've been in contact with Bob 
Boerum at CA, but he's never mentioned it.)

We've been using the SMP/E panels, and, as you say, letting them construct the 
JCL.

---
Bob Bridges, cell 336 382-7313
  robhbrid...@gmail.com
  rbrid...@infosecinc.com

/* In its state of nature [a dog] has a smell, and habits, which frustrate 
man's love; he washes it, house-trains it, teaches it not to steal, and is so 
enabled to love it completely.  To the puppy, the whole proceeding would seem, 
if it were a theologian, to cast grave doubts on the "goodness" of man; but the 
full-grown and full-trained dog, larger, healthier and longer-lived than the 
wild dog, and admitted, as it were by Grace, to a whole world of affections, 
loyalties, interests and comforts entirely beyond its animal destiny, would 
have no such doubt.  -C S Lewis, _The Problem of Pain_ */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, January 29, 2019 11:17

The other option is to see if the ISPF environment has the ISPF SMP/E panels 
available.  That also can help reduce the stress of using SMP/E.  
REC/APP/REST/REJ/ACC are pretty easy to do.  Try not to get lost in the 
details.  The panels will wrap JCL around what you are going to do.  I save 
that off to a dataset and then I have a sample of how to do each.

> -Original Message-
> From: > Lizette Koehler
> Sent: Tuesday, January 29, 2019 9:15 AM
> 
> For supporting any CA Product, you should be using if possible, CA MSM. 
> This is a gui interface that makes CA SMP/E maintenance easier. It 
> pulls the fixes, and you just select what you want it does the rest. 
> Do you have CAMSM available to you?
> 
> > -Original Message-
> > From: Bob Bridges
> > Sent: Tuesday, January 29, 2019 9:07 AM
> >
> > I'm the Top-Secret admin for a client whose system programmer 
> > retired a couple years ago.  The client tapped another employee to 
> > take his place, and she's learning the job with frantic haste but 
> > insists with some justification that she's not a system programmer 
> > yet.  Me, I came into security through the applications-development 
> > side so I'm not even close.
> >
> > Together she and I are trying to learn SMP/E.  The immediate purpose 
> > is so we can apply some TSS-related PTFs, but really, it's become 
> > clear to me that we need no excuses to make it a priority; SMP/E is 
> > kind of important.
> >
> > I have embarked on a serious reading of the SMP/E User's Guide, but 
> > I still need help.  I'll limit myself to a handful of questions to 
> > start
> > with:
> >
> > Question #1) We started by applying a PTF - call it A for simplicity 
> > - and its prerequisite B.  We did that last August and then the 
> > project languished for the sake of other priorities.  Now we're 
> > working on it again and we want to restore those two PTFs and do the APPLY 
> > again.
> > Why?  Well, partly because it was 'way back in August and we're 
> > uncertain about exactly how we did it back then.  We know more now.
> > Partly because we know more now and we want to practice it better.  
> > I dunno, partly because we just want to.  I think maybe we bypassed 
> > some HOLDs back then too.
> >
> > Anyway, we attempted the RESTORE, but we got lots and lots of error 
> > messages saying we need to include other PTFs in the RESTORE.  Some 
> > of these have an indirect connection to A and B; B superceded at 
> > least three of them, for example, which I can see were applied some 
> > years ago.  Others have no relation to our PTFs that I can discern.  
> > I haven't yet found the place in the User's Guide that explains 
> > these 

Re: Newbie SMP/E questions

[Tom Marchant]

If PTF A has PTF B as a prerequisite, and both have been applied, but neither 
has been accepted, then in order to restore A, you must also restore B. GROUP 
will not help you here. IIRC, if you restore B and specify GROUP, SMP/E will 
restore both A and B, but I'm not at all sure about this.

SMPLOG is your friend for determining what has been done and how. Each zone 
should have a DDDEF for its own SMPLOG with DISP=MOD. The content is 
essentially everything from the SMPOUT output for each run with a date and time 
in the first few bytes of each record in packed decimal format.

You can list the SMPLOG for a range of dates/times, but I usually just use VIEW 
to look at it, with the occasional HX line command to see the date and time.

If you install Top Secret from scratch, you will have an isolated environment 
to play with and you can do so without worrying, as long as you define all new 
data sets, including for the global zone, with different names. You can even 
use your userid as the high level qualifier for everything. I do this 
frequently to test SMP/E environments.

Having created this environment, you can experiment and will find it very 
instructive.

You can also clone your target and distribution zones. That would involve using 
ZONECOPY to copy the zones, copy all of the target and distribution data sets, 
keeping the low level qualifiers, and changing all the DDDEFs ZONEEDIT can help 
with this.

I would actually suggest that you do both of these things. Install Top Secret 
(or any other product) in an isolated environment, then clone the target and 
distribution zone within that environment.

IIRC, CA-MSM is now called Opera. I disagree with Lizette, though. I do not 
recommend that you use it.

-- 
Tom Marchant

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

Re: IKJEFT1B program name SMF

[Paul Gilmartin]

On Tue, 29 Jan 2019 09:08:07 -0800, Charles Mills wrote:

>To the best of my (possibly faulty, of course) recollection SMF does not 
>record PARM= anywhere under any circumstances -- other than if it somehow gets 
>used in a way that ends up in SMF, e.g. a program that takes PARM=ddname and 
>then opens that DD name. (You would get an SMF 14, 15, 42 or 6x for that OPEN 
>or CLOSE, or an SMF 80 or 230 if the OPEN failed for security reasons.)
> 
This feels like cause fo RFE that IRXJCL itself should record in SMF the member 
called.
Most readers would find the "%SOMETHING"  more informative than "IRXJCL".

>On Tue, 29 Jan 2019 14:19:07 +, Sankaranarayanan, Vignesh wrote:
>>
>>Let's say there's a REXX program being run in batch with 
>>PGM=IKJEFB1B,PARM='%SOMETHING'.
>> ...

-- gil

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

Re: Using IPCS ACTIVE and alt ASID to display extended private storage

[Wendell Lovewell]

Thanks for your replies.  I had done a REFRESH in RACF for the FACILITY profile 
changes. 

If I start IPCS in an alternate session and then allow the application to 
abend, I can still view memory areas after the abend via ACTIVE in the 
alternate session, but not from a second TSO user.  (But viewing from a split 
screen affects the getmain'd addresses I'm trying to view.)

Could there be something about storage keys that I'm missing?  The application 
does run from an APF authorized library, but AC=0.  

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

Re: Internal Coupling Channel on z13

[Dana Mitchell]

Brian,

We've actually been thinking about this too, as we evaluate moving to z14's. We 
currently have a 5 member GRS ring that could really benefit moving to GRS 
Star,  but nobody want's to spend any $ for an ICF.

As of BC12 generation IBM was still recommending against using GPs for CF 
processors:

According to an IBM paper titled:  Coupling Thin Interrupts and CF Performance 
in Shared Processor Environments

While it is possible to use general purpose processors, CPs, as CF processors
and share the CPs with z/OS and other similarly defined CFs, this is not a
recommended configuration. Using CPs as CF processors creates interaction
between z/OS and the CF in terms of cache reuse and other factors that may
impact performance. 

Dana


On Tue, 29 Jan 2019 00:23:56 -0600, Brian Westerman 
 wrote:

>Hi,
>
>Has anyone had any experience with using the internal coupling channels on a 
>z13.  "supposedly" IBM has removed the active wait problems (where the CF lpar 
>would try to use 100% of whatever it gets from PR/SM), but I was wondering if 
>it's ready for prime time yet.  I have a z13s (single CPU) with 3 LPARs on it, 
>they are fairly low use, but I think it'a about time the started to use GRS 
>since they share DASD (it was small, but now more and more as time goes on).  
>They have been lucky so far, but I would rather not rely on luck.  They don't 
>have the cash to add a specialty processor, and if IBM has really reduced the 
>overhead of ICF, then it might be a good fit for them.
>

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

Re: Style (was: Newbie SMP/E questions)

[Bob Bridges]

BB5> My best friend and I developed a protocol when our long, long debates
started going electronic back in the '80s.  (He abandoned his Catholic
upbringing just about the time I was baptized in the Holy Spirit, so we've
been merrily arguing over it ever since.)  The initials and numbers are
slightly more work but For multiple contributors and especially for multiple
iterations they add a great deal to clarity; see below.

---
Bob Bridges, cell 336 382-7313
  robhbrid...@gmail.com
  rbrid...@infosecinc.com

/* Law #31 of combat operations:  If the enemy is within range, so are you.
*/

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Allan Staller
Sent: Tuesday, January 29, 2019 12:09

AS4> They were indented when I sent it.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Paul Gilmartin
Sent: Tuesday, January 29, 2019 11:06 AM

--- On 2019-01-29, at 09:52:18, Allan Staller wrote:
AS2> Comments interspersed.

PG3> Thanks.  It would further be useful if you distinguished quoted
material with the customary ">" prefix.

> -Original Message-
> From: Bob Bridges
> Sent: Tuesday, January 29, 2019 10:07 AM

BB1> I'm the Top-Secret admin for a client whose system programmer retired a
couple years ago.  The client tapped another employee to take his place, and
she's learning the job with frantic haste but insists with some
justification that she's not a system programmer yet.  Me, I came into
security through the applications-development side so I'm not even close.

Together she and I are trying to learn SMP/E.  The immediate purpose is so
we can apply some TSS-related PTFs, but really, it's become clear to me that
we need no excuses to make it a priority; SMP/E is kind of important.

I have embarked on a serious reading of the SMP/E User's Guide, but I still
need help.  I'll limit myself to a handful of questions to start with:

Question #1) We started by applying a PTF - call it A for simplicity - and
its prerequisite B.  We did that last August and then the project languished
for the sake of other priorities.  Now we're working on it again and we want
to restore those two PTFs and do the APPLY again.  Why?  Well, partly
because it was 'way back in August and we're uncertain about exactly how we
did it back then.  We know more now.  Partly because we know more now and we
want to practice it better.  I dunno, partly because we just want to.  I
think maybe we bypassed some HOLDs back then too.

Anyway, we attempted the RESTORE, but we got lots and lots of error messages
saying we need to include other PTFs in the RESTORE.  Some of these have an
indirect connection to A and B; B superceded at least three of them, for
example, which I can see were applied some years ago.  Others have no
relation to our PTFs that I can discern.  I haven't yet found the place in
the User's Guide that explains these relationship and their relevance.  Can
someone give a helpful explanation?

AS2> SMPE has 2 basic zones TARGET and DLIB (everything else just supports
these 2 zones.). APPLY/ACCEPT processing installs maintenance into the
TARGET/DLIB zones respectively. Once accepted, the only fallback is dfDSS
restore (if you have backups).

Restore processing returns the environment to the last ACCEPTed level. In
order to complete this process, all maintenance from the accepted level to
the current code level must be restored.

BB1> Question #2) So far as we can tell by issuing LIST XREF commands,
whoever ran this thing in the past never did any ACCEPT, ever, except for
the original function code.  I see at least 11 PTFs that were applied
(including our two), but the distribution library shows no PTFs for any
module I've yet LISTed.  If true, does that mean that to do a RESTORE of our
two PTFs we'll have to RESTORE everything back to the plain-vanilla base?
> It is a common practice not to accept maintenance for 3rd party products.
I will not say it is good or bad, but it is common. In to restore to the
environment "before the 2 PTFs", all non-accept PTFs must be restored and
then re-applied (minus the two PTFS).

AS2> This will accomplish what is desired in #1 above.

BB1> Question #3) My partner the not-sysprog has in mind that maybe we need
to set aside this CSI (which is dedicated to Top Secret) and create another
one starting with the base software and build up from there.  I didn't
realize this could be done, but she thinks she can do it.  If it'll work, I
like it; we'll know in that case what we have, which we do not at present.
Anyone have any thoughts on this plan?

AS2> A re-install of the product into separate zones is certainly practical.
IMO, less work, but also less of a learning experience

BB1> Question #4) This is a less-important add-on:  In both the online
documentation and the User's Guide, I read if I'm doing a RESTORE and name
PTFs A and B, including the GROUP operand causes SMP/E to add whatever other
PTFs are required 

External dsect

[scott Ford]

All:

I want to be able to have an options program for our product that the
customer updates.
Then they would assemble/bind it and we can call it to pass options to our
exits. The exits
are system type exits, so i know I/O is limited or not existent. My
question is if i want a program to build the dsect i need to see an example
i assume , please correct me if I am wrong, that i would have:

CSECT ...
.
DSECT

Below is a sample if found.

PRMDSECT DSECTPARM-DSECT (R7)

 USING *,R7   INFORM ASSEMBLER

PRMTRGT  DSCL8TARGET-PGM

PRMADDR  DSXL4TARGET-PGM LOAD-ADDRESS

PRMERRCD DSXL4TARGET-PGM ERROR-CODE

PRMRSA  EQU   *  BEGIN PARM-RSA

LOADPGM   CSECT

  USING *,R3   INFORM ASSEMBLER

  LAR3,0(,R15) CSECT ADDRESSABILITY

  L R7,0(,R1)  PARMAREA ADDRESSABILITY

  LAR9,PRMRSA  POINT TO OUR RSA

  XC0(72,R9),0(R9) ENSURE X'00'S

  LAR15,0(,R9) LOAD WITH OUR RSA-ADDRESS

  STR13,4(,R15)BACKWARD-CHAIN

  STR15,8(,R13)FORWARD-CHAIN

  LRR13,R15LOAD WITH OUR RSA-ADDRESS

 XCPRMADDR,PRMADDRENSURE X'00'S

 LOAD  EPLOC=PRMTRGT,ERRET=BADLOAD

 STCM  R0,B'',PRMADDR STORE IN PARM-FWORD

  XRR1,R1  ENSURE X'00'S

BADLOAD  EQU   *

  STCM  R1,B'',PRMERRCD

RTN2CLLR EQU   *

 L R13,4(,R13)RESTORE CALLERS R13

 XC0(72,R9),0(R9) ENSURE X'00'S

*

 RETURN (14,12),RC=(15)   RESTORE AND RETURN

*

 LTORG ,

 YREGS ,  MVS REGISTER-MACRO

LOADPGM  AMODE 31  ,

LOADPGM  RMODE ANY ,

 END   ,


 I am think my exit could issue a LOAD for a program similar to above with
something like this:

OPTSPARM DSECT

OPTTBL   DS0F

LOGMSGS  DCC'P',H'5',C'LOG=Y'

TRACEDCC'P',H'7',C'TRACE=N'

TBLEND   DCX'FF',H'0',C' '



Then the exit would take action based on the options passed. It would have
to be re-entrant of course.  Is my thinking right all ?


Scott


*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog






*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: Style (was: Newbie SMP/E questions)

[Paul Gilmartin]

On 2019-01-29, at 10:09:25, Allan Staller wrote:

> They were indented when I sent it.
>  
Thanks.  I blame much misbehavior on hypermodern mailer software
(You appear to be using MS-Exchange) that aggressively reformats
to optimize for handheld devices where character cells are precious.

Too much misguided DWIM.

> -Original Message-
> From: Paul Gilmartin
> Sent: Tuesday, January 29, 2019 11:06 AM
> 
> On 2019-01-29, at 09:52:18, Allan Staller wrote:
> 
>> Comments interspersed.
>> 
>> HTH,
>> 
> Thanks.  It would further be useful if you distinguished quoted material with 
> the customary ">" prefix.

-- gil

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

Re: Newbie SMP/E questions

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Tuesday, January 29, 2019 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Newbie SMP/E questions
> 
> Question #1) We started by applying a PTF - call it A for simplicity - and its
> prerequisite B.  We did that last August and then the project languished for 
> the sake of
> other priorities.  Now we're working on it again and we want to restore those 
> two PTFs
> and do the APPLY again.  Why?  Well, partly because it was 'way back in 
> August and
> we're uncertain about exactly how we did it back then.  We know more now.  
> Partly

My solution to this problem is to save the complete listing (everything SDSF 
would give me) of every SMPE run in a PDS and with a member name that reflects 
the chronology.  For example: $0001R and $0002R for the receives, $0003P for 
the apply check, $0004P for the apply and $0005C for the accept check, etc.  
Many jobs had to be run more than once and they are all there for later review.

> because we know more now and we want to practice it better.  I dunno, partly 
> because
> we just want to.  I think maybe we bypassed some HOLDs back then too.
> 
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages
> saying we need to include other PTFs in the RESTORE.  Some of these have an

This is caused by the lack of accepts you describe below.  One solution might 
be to accept the ones that were applied years ago since you are not likely to 
restore any of them.

> indirect connection to A and B; B superceded at least three of them, for 
> example,
> which I can see were applied some years ago.  Others have no relation to our 
> PTFs that
> I can discern.  I haven't yet found the place in the User's Guide that 
> explains these
> relationship and their relevance.  Can someone give a helpful explanation?

The LIST SYSMODS command is your friend.
 
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this
> thing in the past never did any ACCEPT, ever, except for the original 
> function code.  I
> see at least 11 PTFs that were applied (including our two), but the 
> distribution library
> shows no PTFs for any module I've yet LISTed.  If true, does that mean that 
> to do a
> RESTORE of our two PTFs we'll have to RESTORE everything back to the plain-
> vanilla base?

The basic function of the restore command is to replace "updated" but not 
accepted data in your target libraries with the "original" data in the 
distribution library.  Since the related PTFs don't exist in the DLIB, there 
are only two choices.  Put them there by accepting them as described above or 
include them in the restore.  If you choose the latter, you don't need to 
manually include them.  You can use the GROUP operand to have SMPE do it for 
you.

My preference while learning SMPE is to use the CHECK operand on every command 
before firing for effect.
 
> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside
> this CSI (which is dedicated to Top Secret) and create another one starting 
> with the
> base software and build up from there.  I didn't realize this could be done, 
> but she
> thinks she can do it.  If it'll work, I like it; we'll know in that case what 
> we have, which
> we do not at present.  Anyone have any thoughts on this plan?

If you do this, make sure you specify different target and distribution 
libraries.  You don't want your testing to step on production.  On the other 
hand, LIST is still your friend.

> Question #4) This is a less-important add-on:  In both the online 
> documentation and
> the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, 
> including
> the GROUP operand causes SMP/E to add whatever other PTFs are required for 
> various
> reasons.  It doesn't seem to, though; it names them and complains about them, 
> but
> doesn't add them to the list.  Have I misunderstood something?  I'm loathe to 
> believe
> the documentation is flat wrong.

Use the CHECK operand to test.  Look at the third and fourth paragraphs in the 
description of the GROUP operand in the SMPE Commands manual

If you still have questions, show us the exact command you issue and a sample 
of the error messages.
 

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

Re: Style (was: Newbie SMP/E questions)

[Allan Staller]

They were indented when I sent it.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, January 29, 2019 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Style (was: Newbie SMP/E questions)

On 2019-01-29, at 09:52:18, Allan Staller wrote:

> Comments interspersed.
>
> HTH,
>
Thanks.  It would further be useful if you distinguished quoted material with 
the customary ">" prefix.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Bob Bridges
> Sent: Tuesday, January 29, 2019 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Newbie SMP/E questions
>
> I'm the Top-Secret admin for a client whose system programmer retired a 
> couple years ago.  The client tapped another employee to take his place, and 
> she's learning the job with frantic haste but insists with some justification 
> that she's not a system programmer yet.  Me, I came into security through the 
> applications-development side so I'm not even close.
>
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
> can apply some TSS-related PTFs, but really, it's become clear to me that we 
> need no excuses to make it a priority; SMP/E is kind of important.
>
> I have embarked on a serious reading of the SMP/E User's Guide, but I still 
> need help.  I'll limit myself to a handful of questions to start with:
>
> Question #1) We started by applying a PTF - call it A for simplicity - and 
> its prerequisite B.  We did that last August and then the project languished 
> for the sake of other priorities.  Now we're working on it again and we want 
> to restore those two PTFs and do the APPLY again.  Why?  Well, partly because 
> it was 'way back in August and we're uncertain about exactly how we did it 
> back then.  We know more now.  Partly because we know more now and we want to 
> practice it better.  I dunno, partly because we just want to.  I think maybe 
> we bypassed some HOLDs back then too.
>
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
> saying we need to include other PTFs in the RESTORE.  Some of these have an 
> indirect connection to A and B; B superceded at least three of them, for 
> example, which I can see were applied some years ago.  Others have no 
> relation to our PTFs that I can discern.  I haven't yet found the place in 
> the User's Guide that explains these relationship and their relevance.  Can 
> someone give a helpful explanation?
> SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 
> zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB 
> zones respectively. Once accepted, the only fallback is dfDSS restore (if you 
> have backups).
> Restore processing returns the environment to the last ACCEPTed level. In 
> order to complete this process, all maintenance from the accepted level to 
> the current code level must be restored.
>
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this thing in the past never did any ACCEPT, ever, except for the original 
> function code.  I see at least 11 PTFs that were applied (including our two), 
> but the distribution library shows no PTFs for any module I've yet LISTed.  
> If true, does that mean that to do a RESTORE of our two PTFs we'll have to 
> RESTORE everything back to the plain-vanilla base?
> It is a common practice not to accept maintenance for 3rd party products. I 
> will not say it is good or bad, but it is common. In to restore to the 
> environment "before the 2 PTFs", all non-accept PTFs must be restored and 
> then re-applied (minus the two PTFS).
> This will accomplish what is desired in #1 above.
>
> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside this CSI (which is dedicated to Top Secret) and create another one 
> starting with the base software and build up from there.  I didn't realize 
> this could be done, but she thinks she can do it.  If it'll work, I like it; 
> we'll know in that case what we have, which we do not at present.  Anyone 
> have any thoughts on this plan?
> A re-install of the product into separate zones is certainly
> practical. IMO, less work, but also less of a learning experience
>
> Question #4) This is a less-important add-on:  In both the online 
> documentation and the User's Guide, I read if I'm doing a RESTORE and name 
> PTFs A and B, including the GROUP operand causes SMP/E to add whatever other 
> PTFs are required for various reasons.  It doesn't seem to, though; it names 
> them and complains about them, but doesn't add them to the list.  Have I 
> misunderstood something?  I'm loathe to believe the documentation is flat 
> wrong.
> RESTORE S(A,B) GROUPEXTEND will sometimes miss some items. Include them 
> manually. E.g .  RESTORE S(A,B,C) GROUPEXTEND will sometimes miss some items.
>
> If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 

Re: IKJEFT1B program name SMF

[Charles Mills]

To the best of my (possibly faulty, of course) recollection SMF does not record 
PARM= anywhere under any circumstances -- other than if it somehow gets used in 
a way that ends up in SMF, e.g. a program that takes PARM=ddname and then opens 
that DD name. (You would get an SMF 14, 15, 42 or 6x for that OPEN or CLOSE, or 
an SMF 80 or 230 if the OPEN failed for security reasons.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, January 29, 2019 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IKJEFT1B program name SMF

On Tue, 29 Jan 2019 14:19:07 +, Sankaranarayanan, Vignesh wrote:
>
>Let's say there's a REXX program being run in batch with 
>PGM=IKJEFB1B,PARM='%SOMETHING'.
>I'm sure SMF records program names.. but is there any field that also captures 
>the REXX that's being run via IKJEFT01 or IKJEFT1B?
> 
Is this recorded if you use PGM=IRXJCL,PARM='%SOMETHING'?

-- gil

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

Style (was: Newbie SMP/E questions)

[Paul Gilmartin]

On 2019-01-29, at 09:52:18, Allan Staller wrote:

> Comments interspersed.
> 
> HTH,
>  
Thanks.  It would further be useful if you distinguished quoted material
with the customary ">" prefix.

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Bob Bridges
> Sent: Tuesday, January 29, 2019 10:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Newbie SMP/E questions
> 
> I'm the Top-Secret admin for a client whose system programmer retired a 
> couple years ago.  The client tapped another employee to take his place, and 
> she's learning the job with frantic haste but insists with some justification 
> that she's not a system programmer yet.  Me, I came into security through the 
> applications-development side so I'm not even close.
> 
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
> can apply some TSS-related PTFs, but really, it's become clear to me that we 
> need no excuses to make it a priority; SMP/E is kind of important.
> 
> I have embarked on a serious reading of the SMP/E User's Guide, but I still 
> need help.  I'll limit myself to a handful of questions to start with:
> 
> Question #1) We started by applying a PTF - call it A for simplicity - and 
> its prerequisite B.  We did that last August and then the project languished 
> for the sake of other priorities.  Now we're working on it again and we want 
> to restore those two PTFs and do the APPLY again.  Why?  Well, partly because 
> it was 'way back in August and we're uncertain about exactly how we did it 
> back then.  We know more now.  Partly because we know more now and we want to 
> practice it better.  I dunno, partly because we just want to.  I think maybe 
> we bypassed some HOLDs back then too.
> 
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
> saying we need to include other PTFs in the RESTORE.  Some of these have an 
> indirect connection to A and B; B superceded at least three of them, for 
> example, which I can see were applied some years ago.  Others have no 
> relation to our PTFs that I can discern.  I haven't yet found the place in 
> the User's Guide that explains these relationship and their relevance.  Can 
> someone give a helpful explanation?
> SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 
> zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB 
> zones respectively. Once accepted, the only fallback is dfDSS restore (if you 
> have backups).
> Restore processing returns the environment to the last ACCEPTed level. In 
> order to complete this process, all maintenance from the accepted level to 
> the current code level must be restored.
> 
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this thing in the past never did any ACCEPT, ever, except for the original 
> function code.  I see at least 11 PTFs that were applied (including our two), 
> but the distribution library shows no PTFs for any module I've yet LISTed.  
> If true, does that mean that to do a RESTORE of our two PTFs we'll have to 
> RESTORE everything back to the plain-vanilla base?
> It is a common practice not to accept maintenance for 3rd party products. I 
> will not say it is good or bad, but it is common. In to restore to the 
> environment "before the 2 PTFs", all non-accept PTFs must be restored and 
> then re-applied (minus the two PTFS).
> This will accomplish what is desired in #1 above.
> 
> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside this CSI (which is dedicated to Top Secret) and create another one 
> starting with the base software and build up from there.  I didn't realize 
> this could be done, but she thinks she can do it.  If it'll work, I like it; 
> we'll know in that case what we have, which we do not at present.  Anyone 
> have any thoughts on this plan?
> A re-install of the product into separate zones is certainly practical. IMO, 
> less work, but also less of a learning experience
> 
> Question #4) This is a less-important add-on:  In both the online 
> documentation and the User's Guide, I read if I'm doing a RESTORE and name 
> PTFs A and B, including the GROUP operand causes SMP/E to add whatever other 
> PTFs are required for various reasons.  It doesn't seem to, though; it names 
> them and complains about them, but doesn't add them to the list.  Have I 
> misunderstood something?  I'm loathe to believe the documentation is flat 
> wrong.
> RESTORE S(A,B) GROUPEXTEND will sometimes miss some items. Include them 
> manually. E.g .  RESTORE S(A,B,C) GROUPEXTEND will sometimes miss some items.
> 
> If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 
> UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Newbie SMP/E questions

[Binyamin Dissen]

Well, the messages from the RESTORE indicate that SMP/E thinks that they are
applied.

If you want to re-APPLY them, merely add the keyword REDO to the APPLY
statement.

But you also need to know the procedures that were followed at your shop. It
is very rare that APPLY goes to a live system. It usually goes to the "next"
sysres which will be clip'ed over when ready. 

Many shops have a standard of never accepting PTFs. 

If you start a new CSI, you will also need new target libraries etc. Not for
the beginner (IMHO).

There is no reason to RESTORE these PTFs just to reapply them. You may have a
procedure to emergency apply PTFs (without the new SYSRES process)  but you
need to know what you are doing.

Is your shop dropping the mainframe? If not, how to they plan on going
forwards without a sysprog?

On Tue, 29 Jan 2019 11:06:51 -0500 Bob Bridges  wrote:

:>I'm the Top-Secret admin for a client whose system programmer retired a 
couple years ago.  The client tapped another employee to take his place, and 
she's learning the job with frantic haste but insists with some justification 
that she's not a system programmer yet.  Me, I came into security through the 
applications-development side so I'm not even close.
:>
:>Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
can apply some TSS-related PTFs, but really, it's become clear to me that we 
need no excuses to make it a priority; SMP/E is kind of important.
:>
:>I have embarked on a serious reading of the SMP/E User's Guide, but I still 
need help.  I'll limit myself to a handful of questions to start with:
:>
:>Question #1) We started by applying a PTF - call it A for simplicity - and 
its prerequisite B.  We did that last August and then the project languished 
for the sake of other priorities.  Now we're working on it again and we want to 
restore those two PTFs and do the APPLY again.  Why?  Well, partly because it 
was 'way back in August and we're uncertain about exactly how we did it back 
then.  We know more now.  Partly because we know more now and we want to 
practice it better.  I dunno, partly because we just want to.  I think maybe we 
bypassed some HOLDs back then too.
:>
:>Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
saying we need to include other PTFs in the RESTORE.  Some of these have an 
indirect connection to A and B; B superceded at least three of them, for 
example, which I can see were applied some years ago.  Others have no relation 
to our PTFs that I can discern.  I haven't yet found the place in the User's 
Guide that explains these relationship and their relevance.  Can someone give a 
helpful explanation?
:>
:>Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
this thing in the past never did any ACCEPT, ever, except for the original 
function code.  I see at least 11 PTFs that were applied (including our two), 
but the distribution library shows no PTFs for any module I've yet LISTed.  If 
true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE 
everything back to the plain-vanilla base?
:>
:>Question #3) My partner the not-sysprog has in mind that maybe we need to set 
aside this CSI (which is dedicated to Top Secret) and create another one 
starting with the base software and build up from there.  I didn't realize this 
could be done, but she thinks she can do it.  If it'll work, I like it; we'll 
know in that case what we have, which we do not at present.  Anyone have any 
thoughts on this plan?
:>
:>Question #4) This is a less-important add-on:  In both the online 
documentation and the User's Guide, I read if I'm doing a RESTORE and name PTFs 
A and B, including the GROUP operand causes SMP/E to add whatever other PTFs 
are required for various reasons.  It doesn't seem to, though; it names them 
and complains about them, but doesn't add them to the list.  Have I 
misunderstood something?  I'm loathe to believe the documentation is flat wrong.
:>
:>If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 
UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
:>
:>---
:>Bob Bridges, cell 336 382-7313
:>  robhbrid...@gmail.com
:>  rbrid...@infosecinc.com
:>
:>/* Anyone can do any amount of work, provided it isn't the work he is 
supposed be doing at that moment.  -Robert Benchley */
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Newbie SMP/E questions

[Paul Gilmartin]

On Tue, 29 Jan 2019 11:46:39 -0500, Bob Bridges  wrote:

>Never heard of CA-MSM, but I'll look into it.  (I've been in contact with Bob 
>Boerum at CA, but he's never mentioned it.)
>
>We've been using the SMP/E panels, and, as you say, letting them construct the 
>JCL.
> 
Yes.  And I always save the constructed JCL so I can tweak it rather than 
starting afresh.

-- gil

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

Re: Newbie SMP/E questions

[PINION, RICHARD W.]

And on top of that, backup, ACCEPT, backup, RECEIVE, backup, APPLY

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rugen, Len
Sent: Tuesday, January 29, 2019 11:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Newbie SMP/E questions

[External Email]

Some of us developed a maintenance cycle of ACCEPT, RECEIVE, APPLY.  :-)

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: Newbie SMP/E questions

[Allan Staller]

Comments interspersed.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Tuesday, January 29, 2019 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Newbie SMP/E questions

I'm the Top-Secret admin for a client whose system programmer retired a couple 
years ago.  The client tapped another employee to take his place, and she's 
learning the job with frantic haste but insists with some justification that 
she's not a system programmer yet.  Me, I came into security through the 
applications-development side so I'm not even close.

Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
can apply some TSS-related PTFs, but really, it's become clear to me that we 
need no excuses to make it a priority; SMP/E is kind of important.

I have embarked on a serious reading of the SMP/E User's Guide, but I still 
need help.  I'll limit myself to a handful of questions to start with:

Question #1) We started by applying a PTF - call it A for simplicity - and its 
prerequisite B.  We did that last August and then the project languished for 
the sake of other priorities.  Now we're working on it again and we want to 
restore those two PTFs and do the APPLY again.  Why?  Well, partly because it 
was 'way back in August and we're uncertain about exactly how we did it back 
then.  We know more now.  Partly because we know more now and we want to 
practice it better.  I dunno, partly because we just want to.  I think maybe we 
bypassed some HOLDs back then too.

Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
saying we need to include other PTFs in the RESTORE.  Some of these have an 
indirect connection to A and B; B superceded at least three of them, for 
example, which I can see were applied some years ago.  Others have no relation 
to our PTFs that I can discern.  I haven't yet found the place in the User's 
Guide that explains these relationship and their relevance.  Can someone give a 
helpful explanation?
 SMPE has 2 basic zones TARGET and DLIB (everything else just supports these 2 
zones.). APPLY/ACCEPT processing installs maintenance into the TARGET/DLIB 
zones respectively. Once accepted, the only fallback is dfDSS restore (if you 
have backups).
Restore processing returns the environment to the last ACCEPTed level. In order 
to complete this process, all maintenance from the accepted level to the 
current code level must be restored.

Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
this thing in the past never did any ACCEPT, ever, except for the original 
function code.  I see at least 11 PTFs that were applied (including our two), 
but the distribution library shows no PTFs for any module I've yet LISTed.  If 
true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE 
everything back to the plain-vanilla base?
It is a common practice not to accept maintenance for 3rd party products. I 
will not say it is good or bad, but it is common. In to restore to the 
environment "before the 2 PTFs", all non-accept PTFs must be restored and then 
re-applied (minus the two PTFS).
This will accomplish what is desired in #1 above.

Question #3) My partner the not-sysprog has in mind that maybe we need to set 
aside this CSI (which is dedicated to Top Secret) and create another one 
starting with the base software and build up from there.  I didn't realize this 
could be done, but she thinks she can do it.  If it'll work, I like it; we'll 
know in that case what we have, which we do not at present.  Anyone have any 
thoughts on this plan?
A re-install of the product into separate zones is certainly practical. IMO, 
less work, but also less of a learning experience

Question #4) This is a less-important add-on:  In both the online documentation 
and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, 
including the GROUP operand causes SMP/E to add whatever other PTFs are 
required for various reasons.  It doesn't seem to, though; it names them and 
complains about them, but doesn't add them to the list.  Have I misunderstood 
something?  I'm loathe to believe the documentation is flat wrong.
RESTORE S(A,B) GROUPEXTEND will sometimes miss some items. Include them 
manually. E.g .  RESTORE S(A,B,C) GROUPEXTEND will sometimes miss some items.

If you're getting ready to send rushed messages saying "DON'T DO ANYTHING UNTIL 
YOU'VE CHECKED...", relax; we're planning to go slow.

---
Bob Bridges, cell 336 382-7313
  robhbrid...@gmail.com
  rbrid...@infosecinc.com

/* Anyone can do any amount of work, provided it isn't the work he is supposed 
be doing at that moment.  -Robert Benchley */

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

Style (was: Newbie SMP/E questions)

[Paul Gilmartin]

On Tue, 29 Jan 2019 16:23:06 +, David Spiegel wrote:

>Hi Bob,
>2) Yes for the current situation. If, however, PTFs between base and 
>your new PTFs are ACCEPTd, no.
>>  ... [about 20 lines skipped]
>> Question #2) ...

What ever became of the venerable practice of interleaving replies close to
the paragraphs to which they refer so the reader doesn't need to hop up and
down in the page?  Top-posting is execrable.  It's harder for both the poster
and the reader.

(Of course it helps if the depth of quoted text is clearly identified -- that 
was
not a problem in this thread.)

-- gil

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

Re: Newbie SMP/E questions

[Rugen, Len]

Some of us developed a maintenance cycle of ACCEPT, RECEIVE, APPLY.  :-) 

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

Re: Newbie SMP/E questions

[Bob Bridges]

Never heard of CA-MSM, but I'll look into it.  (I've been in contact with Bob 
Boerum at CA, but he's never mentioned it.)

We've been using the SMP/E panels, and, as you say, letting them construct the 
JCL.

---
Bob Bridges, cell 336 382-7313
  robhbrid...@gmail.com
  rbrid...@infosecinc.com

/* In its state of nature [a dog] has a smell, and habits, which frustrate 
man's love; he washes it, house-trains it, teaches it not to steal, and is so 
enabled to love it completely.  To the puppy, the whole proceeding would seem, 
if it were a theologian, to cast grave doubts on the "goodness" of man; but the 
full-grown and full-trained dog, larger, healthier and longer-lived than the 
wild dog, and admitted, as it were by Grace, to a whole world of affections, 
loyalties, interests and comforts entirely beyond its animal destiny, would 
have no such doubt.  -C S Lewis, _The Problem of Pain_ */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, January 29, 2019 11:17

The other option is to see if the ISPF environment has the ISPF SMP/E panels 
available.  That also can help reduce the stress of using SMP/E.  
REC/APP/REST/REJ/ACC are pretty easy to do.  Try not to get lost in the 
details.  The panels will wrap JCL around what you are going to do.  I save 
that off to a dataset and then I have a sample of how to do each.

> -Original Message-
> From: > Lizette Koehler
> Sent: Tuesday, January 29, 2019 9:15 AM
> 
> For supporting any CA Product, you should be using if possible, CA MSM. 
> This is a gui interface that makes CA SMP/E maintenance easier. It pulls
> the fixes, and you just select what you want it does the rest. Do you have
> CAMSM available to you?
> 
> > -Original Message-
> > From: Bob Bridges
> > Sent: Tuesday, January 29, 2019 9:07 AM
> >
> > I'm the Top-Secret admin for a client whose system programmer retired
> > a couple years ago.  The client tapped another employee to take his
> > place, and she's learning the job with frantic haste but insists with
> > some justification that she's not a system programmer yet.  Me, I came
> > into security through the applications-development side so I'm not even
> > close.
> >
> > Together she and I are trying to learn SMP/E.  The immediate purpose
> > is so we can apply some TSS-related PTFs, but really, it's become
> > clear to me that we need no excuses to make it a priority; SMP/E is kind of
> > important.
> >
> > I have embarked on a serious reading of the SMP/E User's Guide, but I
> > still need help.  I'll limit myself to a handful of questions to start
> > with:
> >
> > Question #1) We started by applying a PTF - call it A for simplicity -
> > and its prerequisite B.  We did that last August and then the project
> > languished for the sake of other priorities.  Now we're working on it
> > again and we want to restore those two PTFs and do the APPLY again.
> > Why?  Well, partly because it was 'way back in August and we're
> > uncertain about exactly how we did it back then.  We know more now.
> > Partly because we know more now and we want to practice it better.  I
> > dunno, partly because we just want to.  I think maybe we bypassed some
> > HOLDs back then too.
> >
> > Anyway, we attempted the RESTORE, but we got lots and lots of error
> > messages saying we need to include other PTFs in the RESTORE.  Some of
> > these have an indirect connection to A and B; B superceded at least
> > three of them, for example, which I can see were applied some years
> > ago.  Others have no relation to our PTFs that I can discern.  I
> > haven't yet found the place in the User's Guide that explains these
> > relationship and their relevance.  Can someone give a helpful explanation?
> >
> > Question #2) So far as we can tell by issuing LIST XREF commands,
> > whoever ran this thing in the past never did any ACCEPT, ever, except
> > for the original function code.  I see at least 11 PTFs that were
> > applied (including our two), but the distribution library shows no PTFs for
> > any module I've yet LISTed.  If true, does that mean that to do a RESTORE
> > of our two PTFs we'll have to RESTORE everything back to the plain-vanilla
> > base?
> >
> > Question #3) My partner the not-sysprog has in mind that maybe we need
> > to set aside this CSI (which is dedicated to Top Secret) and create
> > another one starting with the base software and build up from there.
> > I didn't realize this could be done, but she thinks she can do it.  If
> > it'll work, I like it; we'll know in that case what we have, which we
> > do not at present.  Anyone have any thoughts on this plan?
> >
> > Question #4) This is a less-important add-on:  In both the online
> > documentation and the User's Guide, I read if I'm doing a RESTORE and
> > name PTFs A and B, including the GROUP operand causes SMP/E to add
> > whatever other PTFs are required for various reasons.  It doesn't seem

Re: Newbie SMP/E questions

[Paul Gilmartin]

On Tue, 29 Jan 2019 11:06:51 -0500, Bob Bridges wrote:
>...
>Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
>saying we need to include other PTFs in the RESTORE.  Some of these have an 
>indirect connection to A and B; B superceded at least three of them, for 
>example, which I can see were applied some years ago.  Others have no relation 
>to our PTFs that I can discern.  I haven't yet found the place in the User's 
>Guide that explains these relationship and their relevance.  Can someone give 
>a helpful explanation?
>
>Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
>this thing in the past never did any ACCEPT, ever, except for the original 
>function code.  I see at least 11 PTFs that were applied (including our two), 
>but the distribution library shows no PTFs for any module I've yet LISTed.  If 
>true, does that mean that to do a RESTORE of our two PTFs we'll have to 
>RESTORE everything back to the plain-vanilla base?
> 
Either that, or ACCEPT everything up to exactly the level you want to fall back 
to.
RESTORE will revert only to an ACCEPTed service level.

>Question #3) My partner the not-sysprog has in mind that maybe we need to set 
>aside this CSI (which is dedicated to Top Secret) and create another one 
>starting with the base software and build up from there.  I didn't realize 
>this could be done, but she thinks she can do it.  If it'll work, I like it; 
>we'll know in that case what we have, which we do not at present.  Anyone have 
>any thoughts on this plan?
>
Good idea.  Or, even, copy the CSI (SMP/E has commands for this) and experiment
on the copy.

>Question #4) This is a less-important add-on:  In both the online 
>documentation and the User's Guide, I read if I'm doing a RESTORE and name 
>PTFs A and B, including the GROUP operand causes SMP/E to add whatever other 
>PTFs are required for various reasons.  It doesn't seem to, though; it names 
>them and complains about them, but doesn't add them to the list.  Have I 
>misunderstood something?  I'm loathe to believe the documentation is flat 
>wrong.
>
>If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 
>UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
> 
Unfortunately ACCEPT CHECK does not set things up properly for a RESTORE CHECK.

SMP/E sorely needs an "UNDO" command (and associated UNDO CHECK) to revert
the state exactly to an earlier service level.  ACCEPT-RESTORE doesn't come 
close.
The alternative is to HSM restore from an HSM backup.

-- gil

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

Re: Newbie SMP/E questions

[Carmen Vitullo]

I will second what Lizette said, but also, I have to ask, the 'other' person 
tapped to take over, was she a sysprog ? new to SMP/E? seems 2 years is a long 
time for any maint not applied to any security product. 
you should concentrate on your current situation, research the use of APPLY/ 
RESTORE with group or groupextend, research why a PTF will not apply or 
restore, it may be a valid reason, not all PTF's will apply or restore. I 
suggest an SMP/E course sooner than later 


Carmen Vitullo 

- Original Message -

From: "Lizette Koehler"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, January 29, 2019 10:17:17 AM 
Subject: Re: Newbie SMP/E questions 

The other option is to see if the ISPF environment has the ISPF SMP/E panels 
available. 

That also can help reduce the stress of using SMP/E 

REC/APP/REST/REJ/ACC are pretty easy to do. Try not to get lost in the details. 

The panels will wrap JCL around what you are going to do. I save that off to a 
dataset and then I have a sample of how to do each. 

Lizette 


> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf Of 
> Lizette Koehler 
> Sent: Tuesday, January 29, 2019 9:15 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: Newbie SMP/E questions 
> 
> For supporting any CA Product, you should be using if possible, CA MSM. 
> 
> This is a gui interface that makes CA SMP/E maintenance easier 
> 
> It pulls the fixes, and you just select what you want it does the rest. 
> 
> Do you have CAMSM available to you? 
> 
> Lizette 
> 
> 
> > -Original Message- 
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Bob Bridges 
> > Sent: Tuesday, January 29, 2019 9:07 AM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Newbie SMP/E questions 
> > 
> > I'm the Top-Secret admin for a client whose system programmer retired 
> > a couple years ago. The client tapped another employee to take his 
> > place, and she's learning the job with frantic haste but insists with 
> > some justification that she's not a system programmer yet. Me, I came 
> > into security through the applications-development side so I'm not even 
> close. 
> > 
> > Together she and I are trying to learn SMP/E. The immediate purpose 
> > is so we can apply some TSS-related PTFs, but really, it's become 
> > clear to me that we need no excuses to make it a priority; SMP/E is kind of 
> important. 
> > 
> > I have embarked on a serious reading of the SMP/E User's Guide, but I 
> > still need help. I'll limit myself to a handful of questions to start 
> with: 
> > 
> > Question #1) We started by applying a PTF - call it A for simplicity - 
> > and its prerequisite B. We did that last August and then the project 
> > languished for the sake of other priorities. Now we're working on it 
> > again and we want to restore those two PTFs and do the APPLY again. 
> > Why? Well, partly because it was 'way back in August and we're 
> > uncertain about exactly how we did it back then. We know more now. 
> > Partly because we know more now and we want to practice it better. I 
> > dunno, partly because we just want to. I think maybe we bypassed some 
> HOLDs back then too. 
> > 
> > Anyway, we attempted the RESTORE, but we got lots and lots of error 
> > messages saying we need to include other PTFs in the RESTORE. Some of 
> > these have an indirect connection to A and B; B superceded at least 
> > three of them, for example, which I can see were applied some years 
> > ago. Others have no relation to our PTFs that I can discern. I 
> > haven't yet found the place in the User's Guide that explains these 
> > relationship and their relevance. Can someone give a helpful explanation? 
> > 
> > Question #2) So far as we can tell by issuing LIST XREF commands, 
> > whoever ran this thing in the past never did any ACCEPT, ever, except 
> > for the original function code. I see at least 11 PTFs that were 
> > applied (including our two), but the distribution library shows no PTFs for 
> any module I've yet LISTed. 
> > If true, does that mean that to do a RESTORE of our two PTFs we'll 
> > have to RESTORE everything back to the plain-vanilla base? 
> > 
> > Question #3) My partner the not-sysprog has in mind that maybe we need 
> > to set aside this CSI (which is dedicated to Top Secret) and create 
> > another one starting with the base software and build up from there. 
> > I didn't realize this could be done, but she thinks she can do it. If 
> > it'll work, I like it; we'll know in that case what we have, which we 
> > do not at present. Anyone have any thoughts on this plan? 
> > 
> > Question #4) This is a less-important add-on: In both the online 
> > documentation and the User's Guide, I read if I'm doing a RESTORE and 
> > name PTFs A and B, including the GROUP operand causes SMP/E to add 
> > whatever other PTFs are required for various reasons. It doesn't seem 
> > to, though; it names them and complains about them, but doesn't add 
> > them to the 

Re: Newbie SMP/E questions

[David Spiegel]

Hi Bob,
2) Yes for the current situation. If, however, PTFs between base and 
your new PTFs are ACCEPTd, no.

Regards,
David

On 2019-01-29 11:06, Bob Bridges wrote:
> I'm the Top-Secret admin for a client whose system programmer retired a 
> couple years ago.  The client tapped another employee to take his place, and 
> she's learning the job with frantic haste but insists with some justification 
> that she's not a system programmer yet.  Me, I came into security through the 
> applications-development side so I'm not even close.
>
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
> can apply some TSS-related PTFs, but really, it's become clear to me that we 
> need no excuses to make it a priority; SMP/E is kind of important.
>
> I have embarked on a serious reading of the SMP/E User's Guide, but I still 
> need help.  I'll limit myself to a handful of questions to start with:
>
> Question #1) We started by applying a PTF - call it A for simplicity - and 
> its prerequisite B.  We did that last August and then the project languished 
> for the sake of other priorities.  Now we're working on it again and we want 
> to restore those two PTFs and do the APPLY again.  Why?  Well, partly because 
> it was 'way back in August and we're uncertain about exactly how we did it 
> back then.  We know more now.  Partly because we know more now and we want to 
> practice it better.  I dunno, partly because we just want to.  I think maybe 
> we bypassed some HOLDs back then too.
>
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
> saying we need to include other PTFs in the RESTORE.  Some of these have an 
> indirect connection to A and B; B superceded at least three of them, for 
> example, which I can see were applied some years ago.  Others have no 
> relation to our PTFs that I can discern.  I haven't yet found the place in 
> the User's Guide that explains these relationship and their relevance.  Can 
> someone give a helpful explanation?
>
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
> this thing in the past never did any ACCEPT, ever, except for the original 
> function code.  I see at least 11 PTFs that were applied (including our two), 
> but the distribution library shows no PTFs for any module I've yet LISTed.  
> If true, does that mean that to do a RESTORE of our two PTFs we'll have to 
> RESTORE everything back to the plain-vanilla base?
>
> Question #3) My partner the not-sysprog has in mind that maybe we need to set 
> aside this CSI (which is dedicated to Top Secret) and create another one 
> starting with the base software and build up from there.  I didn't realize 
> this could be done, but she thinks she can do it.  If it'll work, I like it; 
> we'll know in that case what we have, which we do not at present.  Anyone 
> have any thoughts on this plan?
>
> Question #4) This is a less-important add-on:  In both the online 
> documentation and the User's Guide, I read if I'm doing a RESTORE and name 
> PTFs A and B, including the GROUP operand causes SMP/E to add whatever other 
> PTFs are required for various reasons.  It doesn't seem to, though; it names 
> them and complains about them, but doesn't add them to the list.  Have I 
> misunderstood something?  I'm loathe to believe the documentation is flat 
> wrong.
>
> If you're getting ready to send rushed messages saying "DON'T DO ANYTHING 
> UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
>
> ---
> Bob Bridges, cell 336 382-7313
>robhbrid...@gmail.com
>rbrid...@infosecinc.com
>
> /* Anyone can do any amount of work, provided it isn't the work he is 
> supposed be doing at that moment.  -Robert Benchley */
>
> --
> 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: Newbie SMP/E questions

[Lizette Koehler]

The other option is to see if the ISPF environment has the ISPF SMP/E panels 
available.

That also can help reduce the stress of using SMP/E

REC/APP/REST/REJ/ACC   are pretty easy to do.  Try not to get lost in the 
details.  

The panels will wrap JCL around what you are going to do.  I save that off to a 
dataset and then I have a sample of how to do each.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Lizette Koehler
> Sent: Tuesday, January 29, 2019 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Newbie SMP/E questions
> 
> For supporting any CA Product, you should be using if possible, CA MSM.
> 
> This is a gui interface that makes CA SMP/E maintenance easier
> 
> It pulls the fixes, and you just select what you want it does the rest.
> 
> Do you have CAMSM available to you?
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Bob Bridges
> > Sent: Tuesday, January 29, 2019 9:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Newbie SMP/E questions
> >
> > I'm the Top-Secret admin for a client whose system programmer retired
> > a couple years ago.  The client tapped another employee to take his
> > place, and she's learning the job with frantic haste but insists with
> > some justification that she's not a system programmer yet.  Me, I came
> > into security through the applications-development side so I'm not even
> close.
> >
> > Together she and I are trying to learn SMP/E.  The immediate purpose
> > is so we can apply some TSS-related PTFs, but really, it's become
> > clear to me that we need no excuses to make it a priority; SMP/E is kind of
> important.
> >
> > I have embarked on a serious reading of the SMP/E User's Guide, but I
> > still need help.  I'll limit myself to a handful of questions to start
> with:
> >
> > Question #1) We started by applying a PTF - call it A for simplicity -
> > and its prerequisite B.  We did that last August and then the project
> > languished for the sake of other priorities.  Now we're working on it
> > again and we want to restore those two PTFs and do the APPLY again.
> > Why?  Well, partly because it was 'way back in August and we're
> > uncertain about exactly how we did it back then.  We know more now.
> > Partly because we know more now and we want to practice it better.  I
> > dunno, partly because we just want to.  I think maybe we bypassed some
> HOLDs back then too.
> >
> > Anyway, we attempted the RESTORE, but we got lots and lots of error
> > messages saying we need to include other PTFs in the RESTORE.  Some of
> > these have an indirect connection to A and B; B superceded at least
> > three of them, for example, which I can see were applied some years
> > ago.  Others have no relation to our PTFs that I can discern.  I
> > haven't yet found the place in the User's Guide that explains these
> > relationship and their relevance.  Can someone give a helpful explanation?
> >
> > Question #2) So far as we can tell by issuing LIST XREF commands,
> > whoever ran this thing in the past never did any ACCEPT, ever, except
> > for the original function code.  I see at least 11 PTFs that were
> > applied (including our two), but the distribution library shows no PTFs for
> any module I've yet LISTed.
> > If true, does that mean that to do a RESTORE of our two PTFs we'll
> > have to RESTORE everything back to the plain-vanilla base?
> >
> > Question #3) My partner the not-sysprog has in mind that maybe we need
> > to set aside this CSI (which is dedicated to Top Secret) and create
> > another one starting with the base software and build up from there.
> > I didn't realize this could be done, but she thinks she can do it.  If
> > it'll work, I like it; we'll know in that case what we have, which we
> > do not at present.  Anyone have any thoughts on this plan?
> >
> > Question #4) This is a less-important add-on:  In both the online
> > documentation and the User's Guide, I read if I'm doing a RESTORE and
> > name PTFs A and B, including the GROUP operand causes SMP/E to add
> > whatever other PTFs are required for various reasons.  It doesn't seem
> > to, though; it names them and complains about them, but doesn't add
> > them to the list.  Have I misunderstood something?  I'm loathe to
> > believe the documentation is flat wrong.
> >
> > If you're getting ready to send rushed messages saying "DON'T DO
> > ANYTHING UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
> >
> > ---
> > Bob Bridges, cell 336 382-7313
> >   robhbrid...@gmail.com
> >   rbrid...@infosecinc.com
> >
> > /* Anyone can do any amount of work, provided it isn't the work he is
> > supposed be doing at that moment.  -Robert Benchley */
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 

Re: Newbie SMP/E questions

[Lizette Koehler]

For supporting any CA Product, you should be using if possible, CA MSM.

This is a gui interface that makes CA SMP/E maintenance easier

It pulls the fixes, and you just select what you want it does the rest.

Do you have CAMSM available to you?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Bob Bridges
> Sent: Tuesday, January 29, 2019 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Newbie SMP/E questions
> 
> I'm the Top-Secret admin for a client whose system programmer retired a
> couple years ago.  The client tapped another employee to take his place, and
> she's learning the job with frantic haste but insists with some justification
> that she's not a system programmer yet.  Me, I came into security through the
> applications-development side so I'm not even close.
> 
> Together she and I are trying to learn SMP/E.  The immediate purpose is so we
> can apply some TSS-related PTFs, but really, it's become clear to me that we
> need no excuses to make it a priority; SMP/E is kind of important.
> 
> I have embarked on a serious reading of the SMP/E User's Guide, but I still
> need help.  I'll limit myself to a handful of questions to start with:
> 
> Question #1) We started by applying a PTF - call it A for simplicity - and
> its prerequisite B.  We did that last August and then the project languished
> for the sake of other priorities.  Now we're working on it again and we want
> to restore those two PTFs and do the APPLY again.  Why?  Well, partly because
> it was 'way back in August and we're uncertain about exactly how we did it
> back then.  We know more now.  Partly because we know more now and we want to
> practice it better.  I dunno, partly because we just want to.  I think maybe
> we bypassed some HOLDs back then too.
> 
> Anyway, we attempted the RESTORE, but we got lots and lots of error messages
> saying we need to include other PTFs in the RESTORE.  Some of these have an
> indirect connection to A and B; B superceded at least three of them, for
> example, which I can see were applied some years ago.  Others have no
> relation to our PTFs that I can discern.  I haven't yet found the place in
> the User's Guide that explains these relationship and their relevance.  Can
> someone give a helpful explanation?
> 
> Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran
> this thing in the past never did any ACCEPT, ever, except for the original
> function code.  I see at least 11 PTFs that were applied (including our two),
> but the distribution library shows no PTFs for any module I've yet LISTed.
> If true, does that mean that to do a RESTORE of our two PTFs we'll have to
> RESTORE everything back to the plain-vanilla base?
> 
> Question #3) My partner the not-sysprog has in mind that maybe we need to set
> aside this CSI (which is dedicated to Top Secret) and create another one
> starting with the base software and build up from there.  I didn't realize
> this could be done, but she thinks she can do it.  If it'll work, I like it;
> we'll know in that case what we have, which we do not at present.  Anyone
> have any thoughts on this plan?
> 
> Question #4) This is a less-important add-on:  In both the online
> documentation and the User's Guide, I read if I'm doing a RESTORE and name
> PTFs A and B, including the GROUP operand causes SMP/E to add whatever other
> PTFs are required for various reasons.  It doesn't seem to, though; it names
> them and complains about them, but doesn't add them to the list.  Have I
> misunderstood something?  I'm loathe to believe the documentation is flat
> wrong.
> 
> If you're getting ready to send rushed messages saying "DON'T DO ANYTHING
> UNTIL YOU'VE CHECKED...", relax; we're planning to go slow.
> 
> ---
> Bob Bridges, cell 336 382-7313
>   robhbrid...@gmail.com
>   rbrid...@infosecinc.com
> 
> /* Anyone can do any amount of work, provided it isn't the work he is
> supposed be doing at that moment.  -Robert Benchley */
> 
> --
> 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

Newbie SMP/E questions

[Bob Bridges]

I'm the Top-Secret admin for a client whose system programmer retired a couple 
years ago.  The client tapped another employee to take his place, and she's 
learning the job with frantic haste but insists with some justification that 
she's not a system programmer yet.  Me, I came into security through the 
applications-development side so I'm not even close.

Together she and I are trying to learn SMP/E.  The immediate purpose is so we 
can apply some TSS-related PTFs, but really, it's become clear to me that we 
need no excuses to make it a priority; SMP/E is kind of important.

I have embarked on a serious reading of the SMP/E User's Guide, but I still 
need help.  I'll limit myself to a handful of questions to start with:

Question #1) We started by applying a PTF - call it A for simplicity - and its 
prerequisite B.  We did that last August and then the project languished for 
the sake of other priorities.  Now we're working on it again and we want to 
restore those two PTFs and do the APPLY again.  Why?  Well, partly because it 
was 'way back in August and we're uncertain about exactly how we did it back 
then.  We know more now.  Partly because we know more now and we want to 
practice it better.  I dunno, partly because we just want to.  I think maybe we 
bypassed some HOLDs back then too.

Anyway, we attempted the RESTORE, but we got lots and lots of error messages 
saying we need to include other PTFs in the RESTORE.  Some of these have an 
indirect connection to A and B; B superceded at least three of them, for 
example, which I can see were applied some years ago.  Others have no relation 
to our PTFs that I can discern.  I haven't yet found the place in the User's 
Guide that explains these relationship and their relevance.  Can someone give a 
helpful explanation?

Question #2) So far as we can tell by issuing LIST XREF commands, whoever ran 
this thing in the past never did any ACCEPT, ever, except for the original 
function code.  I see at least 11 PTFs that were applied (including our two), 
but the distribution library shows no PTFs for any module I've yet LISTed.  If 
true, does that mean that to do a RESTORE of our two PTFs we'll have to RESTORE 
everything back to the plain-vanilla base?

Question #3) My partner the not-sysprog has in mind that maybe we need to set 
aside this CSI (which is dedicated to Top Secret) and create another one 
starting with the base software and build up from there.  I didn't realize this 
could be done, but she thinks she can do it.  If it'll work, I like it; we'll 
know in that case what we have, which we do not at present.  Anyone have any 
thoughts on this plan?

Question #4) This is a less-important add-on:  In both the online documentation 
and the User's Guide, I read if I'm doing a RESTORE and name PTFs A and B, 
including the GROUP operand causes SMP/E to add whatever other PTFs are 
required for various reasons.  It doesn't seem to, though; it names them and 
complains about them, but doesn't add them to the list.  Have I misunderstood 
something?  I'm loathe to believe the documentation is flat wrong.

If you're getting ready to send rushed messages saying "DON'T DO ANYTHING UNTIL 
YOU'VE CHECKED...", relax; we're planning to go slow.

---
Bob Bridges, cell 336 382-7313
  robhbrid...@gmail.com
  rbrid...@infosecinc.com

/* Anyone can do any amount of work, provided it isn't the work he is supposed 
be doing at that moment.  -Robert Benchley */

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

Re: IKJEFT1B program name SMF

[Paul Gilmartin]

On Tue, 29 Jan 2019 14:19:07 +, Sankaranarayanan, Vignesh wrote:
>
>Let's say there's a REXX program being run in batch with 
>PGM=IKJEFB1B,PARM='%SOMETHING'.
>I'm sure SMF records program names.. but is there any field that also captures 
>the REXX that's being run via IKJEFT01 or IKJEFT1B?
> 
Is this recorded if you use PGM=IRXJCL,PARM='%SOMETHING'?

-- 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: IKJEFT1B program name SMF

[Carmen Vitullo]

The DDnames are available on the 30_4 I believe but SYSIN, or SYSTSIN if used 
can tell you the dataset used if -- invocation via SYSTSIN was used, most 
likely the PARM is used 


Carmen Vitullo 

- Original Message -

From: "Vignesh Sankaranarayanan" 
 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, January 29, 2019 9:33:47 AM 
Subject: Re: [EXTERNAL] Re: IKJEFT1B program name SMF 

How about the SYSIN, is that available in any SMF, if I were to look at records 
related to the ones with PGM=IKJEFT1B... ? 

– Vignesh 
Mainframe Infrastructure 

On 29-Jan-2019, at 20:44, Charles Mills  wrote: 

I have a lot of SMF record field experience and I do not recall the PARM= 
data being recorded anywhere, not in SMF 30, nor elsewhere. 

SMF 14 should record the SYSLIB dataset being closed but that is about it. 

Charles 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Sankaranarayanan, Vignesh 
Sent: Tuesday, January 29, 2019 6:19 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: IKJEFT1B program name SMF 

Hello List! 

Let's say there's a REXX program being run in batch with 
PGM=IKJEFB1B,PARM='%SOMETHING'. 
I'm sure SMF records program names.. but is there any field that also 
captures the REXX that's being run via IKJEFT01 or IKJEFT1B? 

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

MARKSANDSPENCER.COM 
 
Unless otherwise stated above: 
Marks and Spencer plc 
Registered Office: 
Waterside House 
35 North Wharf Road 
London 
W2 1NW 

Registered No. 214436 in England and Wales. 

Telephone (020) 7935 4422 
Facsimile (020) 7487 2670 

www.marksandspencer.com 

Please note that electronic mail may be monitored. 

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful. 

-- 
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: [EXTERNAL] Re: IKJEFT1B program name SMF

[Sankaranarayanan, Vignesh]

How about the SYSIN, is that available in any SMF, if I were to look at records 
related to the ones with PGM=IKJEFT1B... ?

– Vignesh
Mainframe Infrastructure

On 29-Jan-2019, at 20:44, Charles Mills  wrote:

I have a lot of SMF record field experience and I do not recall the PARM=
data being recorded anywhere, not in SMF 30, nor elsewhere.

SMF 14 should record the SYSLIB dataset being closed but that is about it.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, January 29, 2019 6:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IKJEFT1B program name SMF

Hello List!

Let's say there's a REXX program being run in batch with
PGM=IKJEFB1B,PARM='%SOMETHING'.
I'm sure SMF records program names.. but is there any field that also
captures the REXX that's being run via IKJEFT01 or IKJEFT1B?

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Suggestions on SMS options for DB2 VSAM Datasets

[Lizette Koehler]

Cross posting to IBMMAIN and DB2-L



Just looking to see if there are any suggestions on how to set up a Dataclas in
ISMF for DB2 tables?

With V2.2 or V2.3 the following entries are new or some or older and maybe need
adjustments.


Space Constraint Relief

Reduce Space Up to (%)

Guaranteed Space Reduction

RMODE31 allows you to specify whether or not to allocate the buffers and control
blocks in 31-bit addressable storage.

Extended constraint removal - allows extents to go beyond 255 if set.



Any guidance appreciated.




Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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

Re: IKJEFT1B program name SMF

[Charles Mills]

I have a lot of SMF record field experience and I do not recall the PARM=
data being recorded anywhere, not in SMF 30, nor elsewhere.

SMF 14 should record the SYSLIB dataset being closed but that is about it.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, January 29, 2019 6:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IKJEFT1B program name SMF

Hello List!

Let's say there's a REXX program being run in batch with
PGM=IKJEFB1B,PARM='%SOMETHING'.
I'm sure SMF records program names.. but is there any field that also
captures the REXX that's being run via IKJEFT01 or IKJEFT1B?

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

Re: IKJEFT1B program name SMF

[Carmen Vitullo]

I've never seen the CLIST or REXX EXEC being recorded in the SMF 30 record, but 
I've never had a need to look. I think a product like TSOMON had that ability 
IIRC. 



Carmen Vitullo 

- Original Message -

From: "Vignesh Sankaranarayanan" 
 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, January 29, 2019 8:19:07 AM 
Subject: IKJEFT1B program name SMF 

Hello List! 

Let's say there's a REXX program being run in batch with 
PGM=IKJEFB1B,PARM='%SOMETHING'. 
I'm sure SMF records program names.. but is there any field that also captures 
the REXX that's being run via IKJEFT01 or IKJEFT1B? 

Thanks in advance! 

- Vignesh 
Mainframe Infrastructure 


MARKSANDSPENCER.COM 
 
Unless otherwise stated above: 
Marks and Spencer plc 
Registered Office: 
Waterside House 
35 North Wharf Road 
London 
W2 1NW 

Registered No. 214436 in England and Wales. 

Telephone (020) 7935 4422 
Facsimile (020) 7487 2670 

www.marksandspencer.com 

Please note that electronic mail may be monitored. 

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful. 

-- 
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 syscalls and the dirty bit

[Steve Austin]

Thanks. As the culprit program was not apparent I got around this by writing my 
own version of the REXX storage function and added a profile for it to the 
PROGRAM class. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, January 24, 2019 5:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX syscalls and the dirty bit

On 1/24/2019 7:25 AM, Steve Austin wrote:
> Hi, I'm using the 'shmat' syscall to attach a shared memory object, but using 
> the REXX storage function to alter it causes the dirty bit to be set. Any 
> idea why this is or how to prevent it?

That means you've loaded a module from a library that isn't program controlled.

If you're a RACF shop, issue the "RLIST PROGRAM *" command to see your current 
definitions.


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



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: Internal Coupling Channel on z13 [EXTERNAL]

[Feller, Paul]

If the lpars are in a base sysplex you can use XCF to carry the GRS traffic and 
still be in a RING setup.  GRS using XCF is better than letting GRS try to 
handle things.

We have been using both an internal and external CF for years.  Currently the 
internal is on a z13.  All the lpars on that CEC talk to the CF over internal 
links.  Just for completeness our external CF is sitting on a z13s.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Tuesday, January 29, 2019 7:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Internal Coupling Channel on z13 [EXTERNAL]

GRS RING can/will run over CTC's. Not sure I would want to do that in a 3 
member ring. It was bad enough in a 2 member ring.

I am currently using an ICF on a z/12 BC w/no issue. Howerr,  I am not sure an 
ICF is the same thing you are describing.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Tuesday, January 29, 2019 12:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Internal Coupling Channel on z13

Hi,

Has anyone had any experience with using the internal coupling channels on a 
z13.  "supposedly" IBM has removed the active wait problems (where the CF lpar 
would try to use 100% of whatever it gets from PR/SM), but I was wondering if 
it's ready for prime time yet.  I have a z13s (single CPU) with 3 LPARs on it, 
they are fairly low use, but I think it'a about time the started to use GRS 
since they share DASD (it was small, but now more and more as time goes on).  
They have been lucky so far, but I would rather not rely on luck.  They don't 
have the cash to add a specialty processor, and if IBM has really reduced the 
overhead of ICF, then it might be a good fit for them.

Anyone using the microcode ICF on a z13 or z14?  If so, does it play well with 
everyone else?

Brian

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

--
Please note:  This message originated outside your organization. Please use 
caution when opening links or attachments.

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

Re: SYSAFF and SCHENV [EXTERNAL]

[Carmen Vitullo]

Sorry Kees, I got a bit off track, the outsourcer I worked at used a number of 
JES2 exits to add SCHENV dependant on the specific client, it was pretty cool 
because all batch, unless your ID was entered into a table, ran via the 
scheduler, the schedulers resources + SCHENV and WLM resources managed all 
batch controls. at the transportation company I worked at the users with the 
direction of operations/production control added the required SCHENV 



Carmen Vitullo 

- Original Message -

From: "Kees Vernooij (ITOP NM) - KLM"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, January 29, 2019 8:09:44 AM 
Subject: Re: SYSAFF and SCHENV [EXTERNAL] 

Allen, Carmen, 

I know how SCHENVs work, we used them for limited purposes. 
My question to Paul was, how does he get the right SCHENV added to a job. 

With our 'dependencies' we moved almost all handling to Exit60, require users 
to use standard PROCs and put the info for the 'dependencies' in the PROCs. 
Exit60 will then see all job requirements and compose the dependencies-set, 
like Paul does to determine the SCHENV. 

The purpose of my question was to find out which other smart techniques were 
available. Apparently none since the last 30 years. 

Kees. 

> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Allan Staller 
> Sent: 29 January, 2019 14:44 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> 
> How do you add a SCHENV to a job? Does the user/submittor do this 
> or is it done automatically? 
> 
> 1) JES can assign a default SCHENV on the JOBDEF/JOBCLASS(n) init parms 
> 2) Modern schedulers (CA7, CTL-M) allow this to be added to the job as 
> part of their processing. 
> 3) SCHENV= on Job Card. 
> 
> There are probably others, but they don't come readily to mind. 
> 
> HTH, 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List  On Behalf 
> Of Vernooij, Kees (ITOP NM) - KLM 
> Sent: Tuesday, January 29, 2019 1:22 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> 
> We have a home written utility that does this. 
> 
> We are looking at replacing this by standard features and besides 
> SCHENVs, the SCHEDULE parameter WITH is a good new candidate. 
> 
> How do you add a SCHENV to a job? Does the user/submittor do this or is 
> it done automatically? 
> 
> Kees. 
> 
> 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > On Behalf Of Feller, Paul 
> > Sent: 29 January, 2019 5:04 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> > 
> > We use SCHENV to direct jobs to different lpars related to MQ, DB2, 
> > IMS, SAS, Connect Direct and other miscellaneous resources. 
> > 
> > Thanks.. 
> > 
> > Paul Feller 
> > AGT Mainframe Technical Support 
> > 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > On Behalf Of Jesse 1 Robinson 
> > Sent: Monday, January 28, 2019 4:13 PM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> > 
> > SCHENV is 20 years old. I'm curious how many other shops have taken 
> > the plunge. 
> > 
> > . 
> > . 
> > 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 Mike Shorkend 
> > Sent: Sunday, January 27, 2019 10:45 PM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: (External):Re: SYSAFF and SCHENV 
> > 
> > I used SCHENV several years ago to direct workload to a CEC that had 
> > a ZIIP installed. Another use is for EXCI - switch the SCHENV on and 
> > off according to the availability of the CICS region. 
> > 
> > On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson 
> >  
> > wrote: 
> > 
> > > Before we implemented SCHENV control, we depended on SYSAFF to 
> > > direct a job toward the member running a suitable Db2 subsystem. 
> > > Then we had a couple of instances where the target Db2 abended and 
> > > would not restart on the 'normal' LPAR, but would run a different 
> > > LPAR. The task of directing a slew of batch jobs containing SYSAFF 
> > > to another LPAR was laborious and time consuming. Or else IPL. 
> > > 
> > > With SCHENV, we could issue a few WLM commands to disable resources 
> > > on the broken LPAR and enable them on the other one. No change to 
> > > automation, no change to JCL. And most all, no unscheduled IPL. 
> > > 
> > > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF 
> > > and SCHENV conflicted, a job would just hang. So part of the 
> > > supporting SCHENV code was to nullify any SYSAFF if SCHENV was also 
> > > specified. If that has changed, we never revisited the 

Re: Internal Coupling Channel on z13

[R.S.]

W dniu 2019-01-29 o 07:23, Brian Westerman pisze:

Hi,

Has anyone had any experience with using the internal coupling channels on a z13.  
"supposedly" IBM has removed the active wait problems (where the CF lpar would 
try to use 100% of whatever it gets from PR/SM), but I was wondering if it's ready for 
prime time yet.  I have a z13s (single CPU) with 3 LPARs on it, they are fairly low use, 
but I think it'a about time the started to use GRS since they share DASD (it was small, 
but now more and more as time goes on).  They have been lucky so far, but I would rather 
not rely on luck.  They don't have the cash to add a specialty processor, and if IBM has 
really reduced the overhead of ICF, then it might be a good fit for them.

Anyone using the microcode ICF on a z13 or z14?  If so, does it play well with 
everyone else?


Few remarks:
1. Internal channels (ICP) have *nothing to do* with CPU consumption of 
internal CF.
2. Internal CF is just CF. There is no difference between them, except 
failure domain.
3. Yes, IBM changed way how CFCC use processor. Instead of legacy 
"active wait" (means 100% CPU all the time, even not serving anything) 
there more CPU friendly mode.


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

IKJEFT1B program name SMF

[Sankaranarayanan, Vignesh]

Hello List!

Let's say there's a REXX program being run in batch with 
PGM=IKJEFB1B,PARM='%SOMETHING'.
I'm sure SMF records program names.. but is there any field that also captures 
the REXX that's being run via IKJEFT01 or IKJEFT1B?

Thanks in advance!

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM

Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: SYSAFF and SCHENV [EXTERNAL]

[Feller, Paul]

Kees, yes we do run into from time to time someone who wants to run a job that 
might have conflicting resources.  An example might be MQ and SAS.  If there is 
not an MQ task running on the same lpar as SAS then the user needs to rethink 
how they have the job set up.  They may have to break the job up.  For things 
like DB2 we do data sharing so there is an image of DB2 on each lpar.  It all 
comes down to how you have your environment set up.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, January 29, 2019 7:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSAFF and SCHENV [EXTERNAL]

Paul,

Thanks. That is similar to we do with our 'Dependencies'. 
The difference is that our jobs can have several 'dependencies'. Jobs can have 
only 1 SCHENV and 1 WITH. This gives less flexibility, e.g. for jobs that need 
IMS or DB2 or IMS+DB2.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Feller, Paul
> Sent: 29 January, 2019 13:50
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> Kees, we do this several ways.  Users can add the SCHENV to their jobs 
> if they know what resource they will need.  As an example if they know 
> they are using MQ in their job they will add the needed SCHENV to 
> their job.  We also add SCHENV during processing in JES2 exit 60.  An 
> example we will look at the user ID the job was submitted under and 
> assign a default SCHENV to the job if none was set in the JCL.  Now 
> this default SCHENV might get overwritten if we find the job also has SAS in 
> it.
> 
> Thanks..
> 
> Paul Feller
> AGT Mainframe Technical Support
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Tuesday, January 29, 2019 1:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> We have a home written utility that does this.
> 
> We are looking at replacing this by standard features and besides 
> SCHENVs, the SCHEDULE parameter WITH is a good new candidate.
> 
> How do you add a SCHENV to a job? Does the user/submittor do this or 
> is it done automatically?
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Feller, Paul
> > Sent: 29 January, 2019 5:04
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > We use SCHENV to direct jobs to different lpars related to MQ, DB2, 
> > IMS, SAS, Connect Direct and other miscellaneous resources.
> >
> > Thanks..
> >
> > Paul Feller
> > AGT Mainframe Technical Support
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
> > Sent: Monday, January 28, 2019 4:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > SCHENV is 20 years old. I'm curious how many other shops have taken 
> > the plunge.
> >
> > .
> > .
> > 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 Mike Shorkend
> > Sent: Sunday, January 27, 2019 10:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: SYSAFF and SCHENV
> >
> > I  used SCHENV several years ago to direct workload to a CEC that 
> > had a ZIIP installed. Another use is for EXCI - switch the SCHENV on 
> > and off according to the availability of the CICS region.
> >
> > On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson 
> > 
> > wrote:
> >
> > > Before we implemented SCHENV control, we depended on SYSAFF to 
> > > direct a job toward the member running a suitable Db2 subsystem.
> > > Then we had a couple of instances where the target Db2 abended and 
> > > would not restart on the 'normal' LPAR, but would run a different 
> > > LPAR. The task of directing a slew of batch jobs containing SYSAFF 
> > > to another LPAR was laborious and time consuming. Or else IPL.
> > >
> > > With SCHENV, we could issue a few WLM commands to disable 
> > > resources on the broken LPAR and enable them on the other one. No 
> > > change to automation, no change to JCL. And most all, no unscheduled IPL.
> > >
> > > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF 
> > > and SCHENV conflicted, a job would just hang. So part of the 
> > > supporting SCHENV code was to nullify any SYSAFF if SCHENV was 
> > > also specified. If that has changed, we never revisited the issue.
> > >
> > > .
> > > .
> > > J.O.Skip Robinson

Re: SYSAFF and SCHENV [EXTERNAL]

[Vernooij, Kees (ITOP NM) - KLM]

Allen, Carmen,

I know how SCHENVs work, we used them for limited purposes.
My question to Paul was, how does he get the right SCHENV added to a job.

With our 'dependencies' we moved almost all handling to Exit60, require users 
to use standard PROCs and put the info for the 'dependencies' in the PROCs. 
Exit60 will then see all job requirements and compose the dependencies-set, 
like Paul does to determine the SCHENV.

The purpose of my question was to find out which other smart techniques were 
available. Apparently none since the last 30 years.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 29 January, 2019 14:44
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> How do you add a SCHENV to a job? Does the user/submittor do this
> or is it done automatically?
> 
> 1) JES can assign a default SCHENV on the JOBDEF/JOBCLASS(n) init parms
> 2) Modern schedulers (CA7, CTL-M) allow this to be added to the job as
> part of their processing.
> 3) SCHENV= on Job Card.
> 
> There are probably others, but they don't come readily to mind.
> 
> HTH,
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Tuesday, January 29, 2019 1:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> We have a home written utility that does this.
> 
> We are looking at replacing this by standard features and besides
> SCHENVs, the SCHEDULE parameter WITH is a good new candidate.
> 
> How do you add a SCHENV to a job? Does the user/submittor do this or is
> it done automatically?
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Feller, Paul
> > Sent: 29 January, 2019 5:04
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > We use SCHENV to direct jobs to different lpars related to MQ, DB2,
> > IMS, SAS, Connect Direct and other miscellaneous resources.
> >
> > Thanks..
> >
> > Paul Feller
> > AGT Mainframe Technical Support
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > Sent: Monday, January 28, 2019 4:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > SCHENV is 20 years old. I'm curious how many other shops have taken
> > the plunge.
> >
> > .
> > .
> > 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 Mike Shorkend
> > Sent: Sunday, January 27, 2019 10:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: SYSAFF and SCHENV
> >
> > I  used SCHENV several years ago to direct workload to a CEC that had
> > a ZIIP installed. Another use is for EXCI - switch the SCHENV on and
> > off according to the availability of the CICS region.
> >
> > On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson
> > 
> > wrote:
> >
> > > Before we implemented SCHENV control, we depended on SYSAFF to
> > > direct a job toward the member running a suitable Db2 subsystem.
> > > Then we had a couple of instances where the target Db2 abended and
> > > would not restart on the 'normal' LPAR, but would run a different
> > > LPAR. The task of directing a slew of batch jobs containing SYSAFF
> > > to another LPAR was laborious and time consuming. Or else IPL.
> > >
> > > With SCHENV, we could issue a few WLM commands to disable resources
> > > on the broken LPAR and enable them on the other one. No change to
> > > automation, no change to JCL. And most all, no unscheduled IPL.
> > >
> > > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF
> > > and SCHENV conflicted, a job would just hang. So part of the
> > > supporting SCHENV code was to nullify any SYSAFF if SCHENV was also
> > > specified. If that has changed, we never revisited the issue.
> > >
> > > .
> > > .
> > > 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 Anthony Hirst
> > > Sent: Sunday, January 27, 2019 4:12 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: (External):Re: SYSAFF and SCHENV
> > >
> > > One difference that I haven't seen be mentioned is that SYSAFF
> > > controls all stages of JES2 processing, while the SCHED only
> > > controls execution phase, we've run into issues where subsystems
> > > aren't 

Re: SYSAFF and SCHENV [EXTERNAL]

[Carmen Vitullo]

There are so many options with WLM and SCHDENV and WLM resources, you can get 
real sophisticated. at a very low level at the outsources we used SCHDENV to 
ensure the correct client ran on the correct LPAR in the PLEX, in one place I 
worked, SCHDENV and WLM resources were used to AID in moving workloads, or 
ensuring onlines were up or down depending on the need before some batch 
processing. 
So, COSMOS ot your favorite automation product can shutdown DB2 for instance, 
change the DB2 (subsystem) WLM resource to down so image copies or reorgs can 
be done with DB2 down. same as required resources, if a batch process needs 
CICS (exci) we used SCHENV + the WLM resource to ensure the batch ran where it 
needed to. works well for weekend processing also when you just need to reset a 
WLM resource so you can perform needed maint. a very simple explanation for a 
very cool way, other than jobclass(es) only to manage workloads. 
example: 
on a jobcard where your batch needs to run where, for example CHANGMAN is up 
SCHENV='CHANGEMAN_JOBS' 
if it's not up the jobs wait until automation brings it up and changes the WLM 
resource to up 


Carmen Vitullo 

- Original Message -

From: "Kees Vernooij (ITOP NM) - KLM"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, January 29, 2019 6:59:30 AM 
Subject: Re: SYSAFF and SCHENV [EXTERNAL] 

Paul, 

Thanks. That is similar to we do with our 'Dependencies'. 
The difference is that our jobs can have several 'dependencies'. Jobs can have 
only 1 SCHENV and 1 WITH. This gives less flexibility, e.g. for jobs that need 
IMS or DB2 or IMS+DB2. 

Kees. 

> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Feller, Paul 
> Sent: 29 January, 2019 13:50 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> 
> Kees, we do this several ways. Users can add the SCHENV to their jobs 
> if they know what resource they will need. As an example if they know 
> they are using MQ in their job they will add the needed SCHENV to their 
> job. We also add SCHENV during processing in JES2 exit 60. An example 
> we will look at the user ID the job was submitted under and assign a 
> default SCHENV to the job if none was set in the JCL. Now this default 
> SCHENV might get overwritten if we find the job also has SAS in it. 
> 
> Thanks.. 
> 
> Paul Feller 
> AGT Mainframe Technical Support 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM 
> Sent: Tuesday, January 29, 2019 1:22 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> 
> We have a home written utility that does this. 
> 
> We are looking at replacing this by standard features and besides 
> SCHENVs, the SCHEDULE parameter WITH is a good new candidate. 
> 
> How do you add a SCHENV to a job? Does the user/submittor do this or is 
> it done automatically? 
> 
> Kees. 
> 
> 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > On Behalf Of Feller, Paul 
> > Sent: 29 January, 2019 5:04 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> > 
> > We use SCHENV to direct jobs to different lpars related to MQ, DB2, 
> > IMS, SAS, Connect Direct and other miscellaneous resources. 
> > 
> > Thanks.. 
> > 
> > Paul Feller 
> > AGT Mainframe Technical Support 
> > 
> > -Original Message- 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> > On Behalf Of Jesse 1 Robinson 
> > Sent: Monday, January 28, 2019 4:13 PM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL] 
> > 
> > SCHENV is 20 years old. I'm curious how many other shops have taken 
> > the plunge. 
> > 
> > . 
> > . 
> > 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 Mike Shorkend 
> > Sent: Sunday, January 27, 2019 10:45 PM 
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: (External):Re: SYSAFF and SCHENV 
> > 
> > I used SCHENV several years ago to direct workload to a CEC that had 
> > a ZIIP installed. Another use is for EXCI - switch the SCHENV on and 
> > off according to the availability of the CICS region. 
> > 
> > On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson 
> >  
> > wrote: 
> > 
> > > Before we implemented SCHENV control, we depended on SYSAFF to 
> > > direct a job toward the member running a suitable Db2 subsystem. 
> > > Then we had a couple of instances where the target Db2 abended and 
> > > would not restart on the 'normal' LPAR, but would run a different 
> > > LPAR. The task of directing a slew of batch 

Re: SYSAFF and SCHENV [EXTERNAL]

[Allan Staller]

How do you add a SCHENV to a job? Does the user/submittor do this or is 
it done automatically?

1) JES can assign a default SCHENV on the JOBDEF/JOBCLASS(n) init parms
2) Modern schedulers (CA7, CTL-M) allow this to be added to the job as part of 
their processing.
3) SCHENV= on Job Card.

There are probably others, but they don't come readily to mind.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, January 29, 2019 1:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSAFF and SCHENV [EXTERNAL]

We have a home written utility that does this.

We are looking at replacing this by standard features and besides SCHENVs, the 
SCHEDULE parameter WITH is a good new candidate.

How do you add a SCHENV to a job? Does the user/submittor do this or is it done 
automatically?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Feller, Paul
> Sent: 29 January, 2019 5:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
>
> We use SCHENV to direct jobs to different lpars related to MQ, DB2,
> IMS, SAS, Connect Direct and other miscellaneous resources.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, January 28, 2019 4:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
>
> SCHENV is 20 years old. I'm curious how many other shops have taken
> the plunge.
>
> .
> .
> 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 Mike Shorkend
> Sent: Sunday, January 27, 2019 10:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: SYSAFF and SCHENV
>
> I  used SCHENV several years ago to direct workload to a CEC that had
> a ZIIP installed. Another use is for EXCI - switch the SCHENV on and
> off according to the availability of the CICS region.
>
> On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson
> 
> wrote:
>
> > Before we implemented SCHENV control, we depended on SYSAFF to
> > direct a job toward the member running a suitable Db2 subsystem.
> > Then we had a couple of instances where the target Db2 abended and
> > would not restart on the 'normal' LPAR, but would run a different
> > LPAR. The task of directing a slew of batch jobs containing SYSAFF
> > to another LPAR was laborious and time consuming. Or else IPL.
> >
> > With SCHENV, we could issue a few WLM commands to disable resources
> > on the broken LPAR and enable them on the other one. No change to
> > automation, no change to JCL. And most all, no unscheduled IPL.
> >
> > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF
> > and SCHENV conflicted, a job would just hang. So part of the
> > supporting SCHENV code was to nullify any SYSAFF if SCHENV was also
> > specified. If that has changed, we never revisited the issue.
> >
> > .
> > .
> > 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 Anthony Hirst
> > Sent: Sunday, January 27, 2019 4:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: SYSAFF and SCHENV
> >
> > One difference that I haven't seen be mentioned is that SYSAFF
> > controls all stages of JES2 processing, while the SCHED only
> > controls execution phase, we've run into issues where subsystems
> > aren't active on some LPARs and a job with a SCHED setting gets
> > interpreted on that system you get a JCL error, only way to avoid
> > that we've found is to code SYSAFF.  We keep the SCHED to because it
> > points to the actual resource requirement adding documentation.
> >
> > On Sat, Jan 26, 2019 at 8:53 PM Peter  wrote:
> >
> > > Hi
> > >
> > > It is just general question
> > >
> > > I was going through the manual.
> > >
> > > Does SCHENV perform the same function as SYSAFF ? Or it does more
> > > than that ?
> > >
> > > Peter
> --
> Mike Shorkend
> m...@shorkend.com
> https://apac01.safelinks.protection.outlook.com/?url=www.shorkend.com;
> amp;data=02%7C01%7Callan.staller%40HCL.COM%7C61667a905ce04bcb4d8f08d68
> 5bb16c4%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C63684343595125325
> 3sdata=bNT7kKcwEMFqt1WyYyJLCQUJzc35L1hmtAK8OrW636U%3Dreserve
> d=0
> Tel: +972524208743
> Fax: +97239772196
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access 

Re: Internal Coupling Channel on z13

[Allan Staller]

GRS RING can/will run over CTC's. Not sure I would want to do that in a 3 
member ring. It was bad enough in a 2 member ring.

I am currently using an ICF on a z/12 BC w/no issue. Howerr,  I am not sure an 
ICF is the same thing you are describing.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Tuesday, January 29, 2019 12:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Internal Coupling Channel on z13

Hi,

Has anyone had any experience with using the internal coupling channels on a 
z13.  "supposedly" IBM has removed the active wait problems (where the CF lpar 
would try to use 100% of whatever it gets from PR/SM), but I was wondering if 
it's ready for prime time yet.  I have a z13s (single CPU) with 3 LPARs on it, 
they are fairly low use, but I think it'a about time the started to use GRS 
since they share DASD (it was small, but now more and more as time goes on).  
They have been lucky so far, but I would rather not rely on luck.  They don't 
have the cash to add a specialty processor, and if IBM has really reduced the 
overhead of ICF, then it might be a good fit for them.

Anyone using the microcode ICF on a z13 or z14?  If so, does it play well with 
everyone else?

Brian

--
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: SYSAFF and SCHENV [EXTERNAL]

[Vernooij, Kees (ITOP NM) - KLM]

Paul,

Thanks. That is similar to we do with our 'Dependencies'. 
The difference is that our jobs can have several 'dependencies'. Jobs can have 
only 1 SCHENV and 1 WITH. This gives less flexibility, e.g. for jobs that need 
IMS or DB2 or IMS+DB2.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Feller, Paul
> Sent: 29 January, 2019 13:50
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> Kees, we do this several ways.  Users can add the SCHENV to their jobs
> if they know what resource they will need.  As an example if they know
> they are using MQ in their job they will add the needed SCHENV to their
> job.  We also add SCHENV during processing in JES2 exit 60.  An example
> we will look at the user ID the job was submitted under and assign a
> default SCHENV to the job if none was set in the JCL.  Now this default
> SCHENV might get overwritten if we find the job also has SAS in it.
> 
> Thanks..
> 
> Paul Feller
> AGT Mainframe Technical Support
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Tuesday, January 29, 2019 1:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> We have a home written utility that does this.
> 
> We are looking at replacing this by standard features and besides
> SCHENVs, the SCHEDULE parameter WITH is a good new candidate.
> 
> How do you add a SCHENV to a job? Does the user/submittor do this or is
> it done automatically?
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Feller, Paul
> > Sent: 29 January, 2019 5:04
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > We use SCHENV to direct jobs to different lpars related to MQ, DB2,
> > IMS, SAS, Connect Direct and other miscellaneous resources.
> >
> > Thanks..
> >
> > Paul Feller
> > AGT Mainframe Technical Support
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > Sent: Monday, January 28, 2019 4:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> >
> > SCHENV is 20 years old. I'm curious how many other shops have taken
> > the plunge.
> >
> > .
> > .
> > 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 Mike Shorkend
> > Sent: Sunday, January 27, 2019 10:45 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: SYSAFF and SCHENV
> >
> > I  used SCHENV several years ago to direct workload to a CEC that had
> > a ZIIP installed. Another use is for EXCI - switch the SCHENV on and
> > off according to the availability of the CICS region.
> >
> > On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson
> > 
> > wrote:
> >
> > > Before we implemented SCHENV control, we depended on SYSAFF to
> > > direct a job toward the member running a suitable Db2 subsystem.
> > > Then we had a couple of instances where the target Db2 abended and
> > > would not restart on the 'normal' LPAR, but would run a different
> > > LPAR. The task of directing a slew of batch jobs containing SYSAFF
> > > to another LPAR was laborious and time consuming. Or else IPL.
> > >
> > > With SCHENV, we could issue a few WLM commands to disable resources
> > > on the broken LPAR and enable them on the other one. No change to
> > > automation, no change to JCL. And most all, no unscheduled IPL.
> > >
> > > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF
> > > and SCHENV conflicted, a job would just hang. So part of the
> > > supporting SCHENV code was to nullify any SYSAFF if SCHENV was also
> > > specified. If that has changed, we never revisited the issue.
> > >
> > > .
> > > .
> > > 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 Anthony Hirst
> > > Sent: Sunday, January 27, 2019 4:12 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: (External):Re: SYSAFF and SCHENV
> > >
> > > One difference that I haven't seen be mentioned is that SYSAFF
> > > controls all stages of JES2 processing, while the SCHED only
> > > controls execution phase, we've run into issues where subsystems
> > > aren't active on some LPARs and a job with a SCHED setting gets
> > > interpreted on that 

Z/os Work load Management (WLM)

[Mehrshad Manshadi]

There was a sample WLM(z/os work load management ) setting in the internet 
which i downloaded long time ago. 
Anybody have that internet address?
Thanks
 

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

Re: SYSAFF and SCHENV [EXTERNAL]

[Feller, Paul]

Kees, we do this several ways.  Users can add the SCHENV to their jobs if they 
know what resource they will need.  As an example if they know they are using 
MQ in their job they will add the needed SCHENV to their job.  We also add 
SCHENV during processing in JES2 exit 60.  An example we will look at the user 
ID the job was submitted under and assign a default SCHENV to the job if none 
was set in the JCL.  Now this default SCHENV might get overwritten if we find 
the job also has SAS in it.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Tuesday, January 29, 2019 1:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYSAFF and SCHENV [EXTERNAL]

We have a home written utility that does this. 

We are looking at replacing this by standard features and besides SCHENVs, the 
SCHEDULE parameter WITH is a good new candidate.

How do you add a SCHENV to a job? Does the user/submittor do this or is it done 
automatically?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Feller, Paul
> Sent: 29 January, 2019 5:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> We use SCHENV to direct jobs to different lpars related to MQ, DB2, 
> IMS, SAS, Connect Direct and other miscellaneous resources.
> 
> Thanks..
> 
> Paul Feller
> AGT Mainframe Technical Support
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, January 28, 2019 4:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYSAFF and SCHENV [EXTERNAL]
> 
> SCHENV is 20 years old. I'm curious how many other shops have taken 
> the plunge.
> 
> .
> .
> 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 Mike Shorkend
> Sent: Sunday, January 27, 2019 10:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: SYSAFF and SCHENV
> 
> I  used SCHENV several years ago to direct workload to a CEC that had 
> a ZIIP installed. Another use is for EXCI - switch the SCHENV on and 
> off according to the availability of the CICS region.
> 
> On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson 
> 
> wrote:
> 
> > Before we implemented SCHENV control, we depended on SYSAFF to 
> > direct a job toward the member running a suitable Db2 subsystem. 
> > Then we had a couple of instances where the target Db2 abended and 
> > would not restart on the 'normal' LPAR, but would run a different 
> > LPAR. The task of directing a slew of batch jobs containing SYSAFF 
> > to another LPAR was laborious and time consuming. Or else IPL.
> >
> > With SCHENV, we could issue a few WLM commands to disable resources 
> > on the broken LPAR and enable them on the other one. No change to 
> > automation, no change to JCL. And most all, no unscheduled IPL.
> >
> > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF 
> > and SCHENV conflicted, a job would just hang. So part of the 
> > supporting SCHENV code was to nullify any SYSAFF if SCHENV was also 
> > specified. If that has changed, we never revisited the issue.
> >
> > .
> > .
> > 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 Anthony Hirst
> > Sent: Sunday, January 27, 2019 4:12 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: SYSAFF and SCHENV
> >
> > One difference that I haven't seen be mentioned is that SYSAFF 
> > controls all stages of JES2 processing, while the SCHED only 
> > controls execution phase, we've run into issues where subsystems 
> > aren't active on some LPARs and a job with a SCHED setting gets 
> > interpreted on that system you get a JCL error, only way to avoid 
> > that we've found is to code SYSAFF.  We keep the SCHED to because it 
> > points to the actual resource requirement adding documentation.
> >
> > On Sat, Jan 26, 2019 at 8:53 PM Peter  wrote:
> >
> > > Hi
> > >
> > > It is just general question
> > >
> > > I was going through the manual.
> > >
> > > Does SCHENV perform the same function as SYSAFF ? Or it does more 
> > > than that ?
> > >
> > > Peter
> --
> Mike Shorkend
> m...@shorkend.com
> www.shorkend.com
> Tel: +972524208743
> Fax: +97239772196
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 

Re: Strange issue with SDSF main panel

[Barbara Nitz]

>How many lines in your ISFPCU41?
541 :-) with the copyright by Rocket Software. But then, the primary panel is 
one column only these days (which took some getting-used-to).

>Ungodly? :-)   I have 153 entries and almost never issue =blah.blah.blah.blah
The problem is that many of the entries we have are probably obsolete, but 
cleaning it up has been a low priority issue (as in: it may or may not get 
done).

Barbara

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

Re: IARV64 - why ABEND rather than return with reason code?

[David Crayford]

On 28/01/2019 12:47 pm, Jim Mulder wrote:

   It is unfortunate that IBM does not make PL/X (which
has object-oriented capabilities) available
to ISVs.
Is OO PL/X still being used for active development at IBM? I can 
remember a conversation I had with a guy from Hursley who told me OO 
PL/X was
buggy and inefficient. With typical British humour they had renamed it 
"ooh ooh" PL/X! It may have been fixed since then but the complaints
were many. Code quality/bloat was a problem as was "Is-A" hell which 
resulted in difficult to understand code. Bugs were not fixed promptly 
so they ditched

it and used vanilla PL/X.

Overuse of inheritance has been a big problem with OO code for decades 
which is why it's avoided these days unless it really is "Is-A" and not just

code reuse using the wrong tool for the job.

C++ is not suitable for low-level code on z/OS because of LE. The 
debugging aids like the traceback are fantastic for fixing easy problems 
but when it gets
tricky IPCS is still the go and the LE condition handlers get in the 
way. But IMO it's a fantastic language for writing problem state ISV 
applications.


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

Re: Strange issue with SDSF main panel

[Richards, Robert B.]

How many lines in your ISFPCU41?

I just noticed a major drop in the number of lines from 2.2 to 2.3 (768 down to 
541)

Ungodly? :-)   I have 153 entries and almost never issue =blah.blah.blah.blah

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Tuesday, January 29, 2019 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strange issue with SDSF main panel

>Are you using the default panel ISFPCU41? Has anyone modified it?
Vanilla ISPF/SDSF, no usermods, and the panel is always named ISFPCU41.

>How are you invoking it?  Like this?PGM(ISFISP) NOCHECK NEWAPPL(ISF) 
>SCRNAME(SDSF)
Exactly like this: PGM(ISFISP) NEWAPPL(ISF) SCRNAME(SDSF) NOCHECK

>I skip the SDSF primary most of the time by adding command table entries like 
>these:

We already have an ungodly number of direct calls for a lot of (ISPF) panels, 
sometimes interfering with isrddsn commands,  mostly because the panels 
sysprogs need are buried much too deep within layer upon layer of panels built 
on top. I just don't want to deal with even more direct calls. So it is 's', 
and then whatever command is needed next.

Barbara

--
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: Strange issue with SDSF main panel

[Barbara Nitz]

>Are you using the default panel ISFPCU41? Has anyone modified it?
Vanilla ISPF/SDSF, no usermods, and the panel is always named ISFPCU41.

>How are you invoking it?  Like this?PGM(ISFISP) NOCHECK NEWAPPL(ISF) 
>SCRNAME(SDSF)
Exactly like this: PGM(ISFISP) NEWAPPL(ISF) SCRNAME(SDSF) NOCHECK

>I skip the SDSF primary most of the time by adding command table entries like 
>these:

We already have an ungodly number of direct calls for a lot of (ISPF) panels, 
sometimes interfering with isrddsn commands,  mostly because the panels 
sysprogs need are buried much too deep within layer upon layer of panels built 
on top. I just don't want to deal with even more direct calls. So it is 's', 
and then whatever command is needed next.

Barbara

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

Re: Strange issue with SDSF main panel

[Richards, Robert B.]

Barbara,

Are you using the default panel ISFPCU41? Has anyone modified it?
Use ISRDDN to see if there is another copy somewhere:  M ISFPCU41
How are you invoking it?  Like this?PGM(ISFISP) NOCHECK NEWAPPL(ISF) 
SCRNAME(SDSF)
I skip the SDSF primary most of the time by adding command table entries like 
these:

APF   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(APF) SCRNAME(APF)

As a matter of fact, I created these as it makes life easier when you can 
invoke them from anywhere:

SYS   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(SYS) SCRNAME(SYS)
PARM  0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(PARM) SCRNAME(PARM)
PAGE  3  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(PAGE) SCRNAME(PAGE)
LNK   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(LNK) SCRNAME(LNK)
LPA   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(LPA) SCRNAME(LPA)
APF   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(APF) SCRNAME(APF)
SYM   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(SYM) SCRNAME(SYM)
ENQ   0  SELECT PGM(ISFISP) NOCHECK NEWAPPL(ISF) PARM(ENQ) SCRNAME(ENQ)

Sorry that I am not more helpful in diagnosing your actual issue.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: Tuesday, January 29, 2019 4:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Strange issue with SDSF main panel

Again: The APF command is NOT failing, it 'just' does not show on the main 
panel! It only shows *after* the APF command was *successfully* executed! And 
then only for as long as I stay within that session.

With the exception of 4 userids, *everybody* is in ISFUSER, which doesn't mean 
anything because the authorized functions are explicitly enabled via RACF. The 
LNK command shows up just fine. GROUP.ISFUSER.** and ISF.CONNECT.**  are 
enabled/defined for the group in question.

I just defined a new (test) user and connected it to a group known to work, and 
the APF command is executable there without problem, but also does not show up 
on the primary panel until the command has been successfully executed once in 
that SDSF session. Again, the LNK command shows up fine before and after 
execution.

If I permit the group to the LINE command (just to test something else), it 
also shows up on the primary panel.

Barbara

--
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: Strange issue with SDSF main panel

[Barbara Nitz]

Again: The APF command is NOT failing, it 'just' does not show on the main 
panel! It only shows *after* the APF command was *successfully* executed! And 
then only for as long as I stay within that session.

With the exception of 4 userids, *everybody* is in ISFUSER, which doesn't mean 
anything because the authorized functions are explicitly enabled via RACF. The 
LNK command shows up just fine. GROUP.ISFUSER.** and ISF.CONNECT.**  are 
enabled/defined for the group in question.

I just defined a new (test) user and connected it to a group known to work, and 
the APF command is executable there without problem, but also does not show up 
on the primary panel until the command has been successfully executed once in 
that SDSF session. Again, the LNK command shows up fine before and after 
execution.

If I permit the group to the LINE command (just to test something else), it 
also shows up on the primary panel.

Barbara

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