Re: Coupling Facility Structure Re-sizing

[nitz-ibm]

> 1) Should INITSIZE and MINSIZE always be specified?
I have always specified both, and I have always made them equal. I had some 
unpleasant surprises when MINSIZE was smaller than INITSIZE. And I have always 
set INITSIZE to half of SIZE.

> 2) Are all structures 'eligible' to be defined with these parameters?
IIRC yes. If not, IXCMIAPU will tell you.

> 3) Besides the ratio specified above, are their any guidelines for the
> definitions?
Check 'Setting up a sysplex' for general guidelines, considerations for 
individual structures are usually found where the product documentation is. 
Don't bother going to the PRISM guide (if that is still referenced in sysplex 
setup) - the CFSizer is pretty good instead.

> 4) The sizer tool is based on current allocation which may not be ideal. Is
> there a way to confirm if I have the best fit?
Check the SMF records once things are set and change as needed.

Barbara

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

zEC12 Upgrade

[venkat kulkarni]

Hello,
 We are planning to upgrade our z9 to zEC12 Mainframe and currently
we are running with z/OS 1.13 and z/OS 2.1  operating system.  How can we
find list of task need to be performed on z/OS side for this
upgrade. Currently I reviewed all PTF required using PSP bucket.
But from z/Os side, I still need to find required changes.


Regards
Venkat

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

Re: What CPU capacity does WLM look at when deciding to start more batch initiators?

[Vernooij, CP (ITOPT1) - KLM]

There are a few publications of Horst Sinram on how this works and what has 
been enhanced in the latest z/OS versions.

Google for:
Share Session 9968, from slide 33.


Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: 17 December, 2015 17:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: What CPU capacity does WLM look at when deciding to start more 
batch initiators?

 
> Here is the original document 
 
Thanks. I was reading a document from John Arwe about goal-based initiator 
management and then the part on WLM inititors in the system programmer's guide 
to: workload management, which explains the new introdice with z/OS V1.8. 
Thanks for this pointer. I'll read that document, too.


>From this I think I've got a good understanding how this works, except from 
>the point about the free capacity of the system when WLM has do decide to 
>start or not to start more initiators.


--
Peter Hunkeler




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

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

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



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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Nathan Astle wrote:

>The 'a' is invalid in the slip trap

Please show the full error message(s) why the 'a' is invalid. Perhaps Barbara 
and your z/OS systesm are on different versions.

Groete / Greetings
Elardus Engelbrecht

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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Barbara Nitz wrote:

>> Please show the full error message(s) why the 'a' is invalid. Perhaps 
>> Barbara and your z/OS systesm are on different versions.

>As I said, I did not test this for syntactical correctness. 

I know, many IBM-MAIN members post sample syntax, sometimes omitting crucial 
info for brevity, but it is up to the actual user to verify/modify the command 
and all its parameters for accuracy.

Similar with the other thread where I said, use a program, I did not say how 
the JCL + input should look like. It is up to the OP to figure that out.

>Check the manuals ...

That's it! Good homework before the weekend! ;-D

Groete / Greetings
Elardus Engelbrecht

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

Re: Delete part of spool for active job

[nitz-ibm]

> In a case # 2 situation, you could force the job to be swapped out 
> unconditionally by quiescing it: E jobname,QUIESCE. This might give you some 
> time to purge enough unneeded output to be able to login to TSO and perform 
> further actions. Actions might be to save the output to a data set then 
> cancel the job or allocate new spool space and let the job continue (E 
> jobname,RESET), or whatever suits your needs.

Good idea, but have you had only a z/OS console in a 100% spool shortage 
recently? Problems I encountered in that situation:
- Logon not possible
- The system's console had an American keyboard layout (on a really stupid 3270 
emulation that doesn't know the difference between ctrl and enter, remote 
login) and my actual keyboard is German: Just issuing the JES2 commands with 
all its special characters to determine *which* was the offending job became a 
nightmare.
- Cancel command of offending job got accepted, but the job did not terminate 
(because it needs spool space to terminate - TGSs were at 100%)
- Job had to get forced (force arm also didn't work).
- I am used to using SDSF, so using the JES2 commands (aside from the keyboard 
issue) to purge the offending job was a real challenge.

The first time I hit these problems, I learned my lesson:
1. Always keep a spare spool volume (or two) around and have written notes on 
how to activate that. Also, keep in mind that some JES shortages (I forgot 
which) prevent the addition of new volumes, IIRC because that also needs *some* 
spool space. (An ADCD system comes with a minuscule spool, and I went through 
some iterations for increasing check point sizes, too, to accomodate the larger 
spool.)
2. Always keep some older output around that can be purged so that the TSO 
logon can succeed (even if I understand the zeal to have the JES2 spool as 
empty as possible). Always attempt to logon before purging anything. If you're 
able to logon, first save the offending output (even if it gets a B37) so you 
have some chance of problem determination.
3. All else failing, have an established procedure for a JES2 cold start, 
*especially* if you run a monoplex.
4. Have automation procedures in place to cancel a job consuming more than 50% 
of spool space (I had to change the JES init parms to accomplish that).
5. Have automation procedures in place to report shortages before they hit 100% 
(jobs are not executed anymore or new address spaces started once you're in 
100%).

The primary goal in this situation is always to logon to TSO again. Some 
installations have a local non-SNA TSO user that is always running and never 
logs off. At least that allows for easier problem analysis (aside from the 
keyboard issue), but I was unlucky enough having to purge a job that the 
logged-on userid didn't have RACF access to, and the userid didn't have RACF 
SPECIAL, either. 

I firmly believe that Murphy's law applies in any JES2 shortage! :-)


Barbara

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

Re: S00C Slip trap for any Stc

[nitz-ibm]

abend00C always means some problem with coupling services. If you don't know 
which connector will be hit for which structure/group, I suggest to set the 
slip trap rather generically as 

sl set,c=00c,a=(cu,h,s),dspname=('xcfas'.*),id=s00C,e

Not having tested this for correctness, the a=(cu,h,p,s) should ensure that the 
current address space along with any home or secondary address space get 
dumped. And you may want to include XCFs data spaces, and maybe other data 
spaces (depending on the problem). Just make sure that your maxspace is large 
enough, especially if you're dealing with DB2. Maxspace needs to get set 
beforehand.

Barbara

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

Re: S00C Slip trap for any Stc

[Nathan Astle]

Hi


The 'a' is invalid in the slip trap

On Friday 18 December 2015, nitz-ibm  wrote:

> abend00C always means some problem with coupling services. If you don't
> know which connector will be hit for which structure/group, I suggest to
> set the slip trap rather generically as
>
> sl set,c=00c,a=(cu,h,s),dspname=('xcfas'.*),id=s00C,e
>
> Not having tested this for correctness, the a=(cu,h,p,s) should ensure
> that the current address space along with any home or secondary address
> space get dumped. And you may want to include XCFs data spaces, and maybe
> other data spaces (depending on the problem). Just make sure that your
> maxspace is large enough, especially if you're dealing with DB2. Maxspace
> needs to get set beforehand.
>
> 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: S00C Slip trap for any Stc

[nitz-ibm]

> Please show the full error message(s) why the 'a' is invalid. Perhaps Barbara 
> and your z/OS systesm are on different versions.
As I said, I did not test this for syntactical correctness. The a should stand 
for asid, and I am sure that the (cu,h,s) are correct. Check the manuals for 
what the actual filter keyword is, it may be j (for jobname to be dumped).

Barbara

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

Re: zEC12 Upgrade

[Huckert, James]

You can use FIXCAT in SMP/e to find what will be needed from a z/OS 
perspective. 

Thank you 
James H. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Friday, December 18, 2015 2:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEC12 Upgrade

Hello,
 We are planning to upgrade our z9 to zEC12 Mainframe and currently we 
are running with z/OS 1.13 and z/OS 2.1  operating system.  How can we find 
list of task need to be performed on z/OS side for this upgrade. Currently I 
reviewed all PTF required using PSP bucket.
But from z/Os side, I still need to find required changes.


Regards
Venkat

--
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: Coupling Facility Structure Re-sizing

[Richards, Robert B.]

Phil,

Since no one else has asked, why are you going from internal to external CFs? 
What is the hardware involved for both your regular lpars and your CF lpars?

The last thing you want is for your CFs to be slower than the CPs. BTDTGTS

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of phil yogendran
Sent: Thursday, December 17, 2015 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Coupling Facility Structure Re-sizing

Hello,

I am in the middle of attempting to go from internal to external CFs. I ran the 
sizer tool and have the info for the new sizes. However, the INITSIZE and 
MINSIZE values have me challenged.
For most structures, the  current allocation doesn't specify a value for either 
parameter or the specified value appears to be a poor choice. For instance, the 
book says that SIZE should be no more than 1.5 - 2.0 times INITSIZE but we have 
some where SIZE is 30 times INITSIZE. My questions are;

1) Should INITSIZE and MINSIZE always be specified?
2) Are all structures 'eligible' to be defined with these parameters?
3) Besides the ratio specified above, are their any guidelines for the 
definitions?
4) The sizer tool is based on current allocation which may not be ideal. Is 
there a way to confirm if I have the best fit?
5) Besides the manual "Setting up a Sysplex" is there more doc where I can find 
additional info?

Any suggestions or thoughts will be appreciated. Thanks.

Phil

--
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: Delete part of spool for active job

[Jousma, David]

Skip,

Here is what I devised, and has worked pretty well.  We use netview/SA390 for 
our automation.  The following rules get tripped at 80% or 85% utilization.

SPOOLSHORT :  
   CMD=(,,'MVS $D JOBQ,SPOOL=(%>01)')  
   CMD=(PASS1,,'MVS $CJ(E*,T*),SPOOL=(%>10),PURGE')   << in our shop E* and T* 
are non-prod jobs, and this usually kills the culprit
   CMD=(PASS2,,'MVS $PJ(E*,T*),SPOOL=(%>5)')  
   CMD=(PASS3,,'MVS $PJ(E*,T*),SPOOL=(%>2)')  
   CMD=(PASS4,,'MVS $PO JOBQ,READY,A>14')  
   CMD=(PASS5,,'MVS $PO TSU(*),ALL,A>1')   
   CMD=(PASS6,,'MVS $PO STC(*),ALL,A>10')  
   CMD=(PASS7,,'MVS $PO JOBQ,Q=D,A>1') 
   CMD=(PASS8,,'MVS $PO JOBQ,ALL,A>10')

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Thursday, December 17, 2015 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete part of spool for active job

(I could start a new thread if needed.) 

We are reviewing our automated response to 'full spool' condition because it's 
very disruptive and not always recognized right away. I'd like to purge an 
offending job. $DSPL,JOBS=nn will report jobs using more than nn per cent of 
spool. Problem is that the response to a REXX CONSOLE command does not include 
job number. If more than one job of the same name is found, $PJ will not work 
without the number. Any advice?

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, December 17, 2015 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: Delete part of spool for active job

Skip Robinson wrote:

>There are two distinct conditions that must be considered.

>1. A large output needs to be managed but is not causing a spool problem.
>2. An ginormous output--together with benign output--has pushed spool 
>utilization to 100%.

>In the case of #1, others have suggested ways to preserve at least some of the 
>output. Basically, assuming that the JCL was not coded to anticipate this 
>situation, you need to copy some portion of the output to another class or 
>destination. You could also save output to a data set. All spool management 
>tools I know of have this capability. Once desired output has been preserved 
>outside the jumbo job, El Gordo can be purged.

True. That is if the output is deallocated or freed by the offending program in 
the first place while that program is running.


>In the case of #2, your options are limited. If spool shortage cannot be 
>relieved, you may not even be able to logon to the MAS because even a TSO 
>address space needs some spool space.

True. I still have the scars of that, luckily I have a spare TSO session where 
I could fix those guzzling jobs properly. (and also sorted out an El Gordo XMIT 
data on the JES2 SPOOL, which guzzled up the whole spool. I deleted that and 
showed that grumbling XMITter how to do FTP instead of XMIT.)

And trained that submitter of those jobs to insert a SYSOUT 
FREE=CLOSE,SPIN=UNALLOC before re-submitting that offending job.

Or teach them to redirect the output to a dataset.

Hard work to train those dummies... ;-D


>I don't believe that you can purge an individual segment while a job is still 
>writing to it.

True. Also while that step is still writing to it. Wait for the step to free or 
deallocate the output and then you can purge it.


>When spool-full condition has hit us, the offending job is usually still 
>running, so that space recovered by purging some disposable output is 
>immediately filled up again by the same job. If this situation occurs, you 
>have little choice but to cancel *and purge* the offending job, which 
>unfortunately means losing all the output.

Sometimes the only option. Just preserve the 'x millions lines written' in the 
SYSLOG to pacify the angry submitter...

I sometimes threatened to write that JES2 exit to limit/crush those spool 
eating jobs outputs, but my users cancelled my obsession to keep the JES2 spool 
empty... ;-)

Groete / Greetings
Elardus Engelbrecht

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it 

Re: Delete part of spool for active job

[Elardus Engelbrecht]

Jousma, David wrote:

>Here is what I devised, and has worked pretty well.  We use netview/SA390 for 
>our automation.  The following rules get tripped at 80% or 85% utilization. 

Good solution, but Skip still wants the job number. Can your Netview solution 
also handle jobnumber?
 
CMD=(,,'MVS $D JOBQ,SPOOL=(%>01)')   

Hmmm. It differs from Skip's command $DSPL,JOBS=nn, but job numbers are also 
shown on the SYSLOG together with the other details. It should help Skip very 
much.

I prefer this one $D JOBQ,SPOOL=(TGS>) because some of our jobs with say 
TGS = large are only occupying TGS% < 1. (I know you can do this $D 
JOBQ,SPOOL=(%>0.5) for % smaller than 1.)

Just a little sample on my SDSF showing my spool eaters: 

TGNum  TGPct
 4925   0.43
 6673   0.58
 7294   0.63


>   CMD=(PASS1,,'MVS $CJ(E*,T*),SPOOL=(%>10),PURGE')   << in our shop E* and T* 
> are non-prod jobs, and this usually kills the culprit 

Excellent! I will tell my z/OS team about this killer! ;-D

Granted, also no job numbers, but they want a solution based on job name.

Thanks!

Groete / Greetings
Elardus Engelbrecht

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

Re: Coupling Facility Structure Re-sizing

[Elardus Engelbrecht]

Richards, Robert B. wrote:

>The last thing you want is for your CFs to be slower than the CPs. BTDTGTS 

Ouch. Could you be kind to tell us about it? Are there any manuals stating that 
trouble? Any configuration changes to avoid? Or is it about the sizes or 
quantity of LPARs involved? 

TIA!

Groete / Greetings
Elardus Engelbrecht

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

Re: Coupling Facility Structure Re-sizing

[Richards, Robert B.]

The archives probably have it, but simply put and if IIRC, there was an old 
9674 being used with z990s. Waiting on CF structure response was horrific as 
compared to the speed of the z990 processor response. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, December 18, 2015 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Coupling Facility Structure Re-sizing

Richards, Robert B. wrote:

>The last thing you want is for your CFs to be slower than the CPs. 
>BTDTGTS

Ouch. Could you be kind to tell us about it? Are there any manuals stating that 
trouble? Any configuration changes to avoid? Or is it about the sizes or 
quantity of LPARs involved? 

TIA!

Groete / Greetings
Elardus Engelbrecht

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

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

OT, but too funny to not share

[John McKown]

http://www.businessinsider.com/netflix-socks-turn-off-the-show-when-you-fall-asleep-2015-12


...
Fortunately Netflix has a cheeky solution to your problems: "Netflix
socks." Netflix has built socks that read your body to understand when you
fall asleep, and then automatically pause your Netflix show.
...


​The _perfect_ gift!​


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

S00C Slip trap for any Stc

[Peter Relson]

>Can I set slip trap for abend s00c for any failing Address space ?

To be unhelpful, the answer is "yes", you can set it as long as you have 
the authority to set it. The real question is whether you can set such a 
trap and have it match.

Towards the end of having it match, we'd need to ask "what do you mean by 
failing Address space?" and what filters would be needed if you wanted to 
differentiate between "failing" and "non-failing" address space. We'd also 
need to ask if your subject of "any Stc" really meant "any STC (but not a 
non-STC)" in which case a further filter would be needed.

And there is always the underlying question of did you literally mean 
"abend s00C" (as in, abend with a code of system 00C) as opposed to 
"system completion code 00C". If the completion code is achieved by the 
abend (or CALLRTM TYPE=ABTERM) macro then SLIp will match it. But in some 
cases completion codes are set (changed) by recovery routines such as by 
SETRP COMPCOD=n after the initial abend or program check. In those cases, 
you need to trap on the code for the initial entry to recovery (whatever 
that is). That is why, for example, for some POST completion codes you 
have to trap on the 0C4 that initiated the recovery processing. I don't 
know how system completion code 00C comes about (other than that it is by 
the XCF component). And the answer might vary depending on the reason 
code.

Peter Relson
z/OS Core Technology Design


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

Re: OT, but too funny to not share

[Elardus Engelbrecht]

John McKown wrote:

>Fortunately Netflix has a cheeky solution to your problems: "Netflix socks." 
>Netflix has built socks that read your body to understand when you fall 
>asleep, and then automatically pause your Netflix show.

It socks! Sorry, it sucks! 

Zzzz.
 ;-D

>​The _perfect_ gift!​

Indeed. Now, are there any socks which BURN or shock your legs when you go 
z ??? ;-D

If my partner goes asleep during a movie, can you zap them awake via a remote 
and shocker socks? 

Groete / Greetings
Elardus Engelbrecht

How do blonde braincells die? Very alone.

Why did the blonde drown? Someone left a scratch & sniff sticker at the bottom 
of the pool.

Why did the blonde buy a brown cow? To get chocolate milk.

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

Re: slight reprieve on the z.

[Ted MacNEIL]

Obviously misinformed!

-
-teD
-
  Original Message  
From: Mike Schwab
Sent: Friday, December 18, 2015 05:21
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: slight reprieve on the z.

They are running the LAST IMS MAINFRAME in North America in 2003?

Why does IBM keep churning out new versions of IMS?

On Thu, Dec 17, 2015 at 6:06 PM, Gary Jacek  wrote:
> Hi Bob
>
> I just have to share this classic from 2003.
>
> https://www.youtube.com/watch?v=tKgl6e31R50
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bob Shannon
> Sent: December 17, 2015 09:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: slight reprieve on the z.
>
>> it has now been decided that the z will be kept (greatly reduced in
>> MSU & usage) until 4Q2016
>
> Circa 1999 I exchanged emails with someone on this list who was in the 12th 
> year of a five year migration off the mainframe. Y2K extended the migration 
> even farther. Hopefully you will have similar misfortune ;-)
>
> Bob Shannon
> Rocket Software
>
> --
> 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

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

Re: zEC12 Upgrade

[Kurt Quackenbush]

On 12/18/2015 3:19 AM, venkat kulkarni wrote:

  We are planning to upgrade our z9 to zEC12 Mainframe and currently
we are running with z/OS 1.13 and z/OS 2.1  operating system.  How can we
find list of task need to be performed on z/OS side for this
upgrade. Currently I reviewed all PTF required using PSP bucket.
But from z/Os side, I still need to find required changes.


Check out the z/OS V2.1 Migration guide (watch the wrap):
http://www-03.ibm.com/systems/z/os/zos/installation/zOS_V2R1_Install_Migrate.html

Specifically, review Chapter 2, the "Hardware migration actions" topic.

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: zEC12 Upgrade

[Anderson Bassani]

Hello

You can use the z/OS Migration Manuals (z/OS 1.13 and z/OS 2.1) for this 
task.
For z/OS 1.13 look at - 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/e0z2m192/CCONTENTS?SHELF=all13be9=GA22-7499-21=20120814132840
For z/OS 2.1 look at GA32-0889-04 z/OS Migration - 
http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r1pdf/
Look for hardware migration actions inside the manuals.

As initial step buy step procedure (Procedure for Report Missing Fix, 
Coexistence and Toleration PTFs).
1. Go to http://service.software.ibm.com/holdata/390holddata.html
2. Download the full.bin file
3. Allocate a data set on z/OS as described
4. Upload the full.bin file to the host
5. Unterse the data set
6. Execute the RECEIVE HOLDDATA job
7. Choose the necessary fixcategory for your environment at 
http://www-03.ibm.com/systems/z/os/zos/features/smpe/fix-category.html
8. Execute the REPORT MISSING FIX job
9 The output of the job is a list with PTF (status = NO) that you have to 
obtain through IBM Shopz - 
https://www-304.ibm.com/software/shopzseries/ShopzSeries_public.wss

10. Check for web deliverables (e.g. Cryptographic support).

Best Regards,

Anderson Weber Bassani
IBM - Technical Specialist - Mainframe - z Systems
Phone: 55-11-2132-2826 / Mobile: 55-11-9-7159-5102 / Tie-Line: 842-2826
E-mail: abass...@br.ibm.com

LinkedIn: https://br.linkedin.com/in/andersonbassani
Twitter: https://twitter.com/andersonbassani
SlideShare: http://pt.slideshare.net/abassani







From:   "Huckert, James" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   18/12/2015 09:16
Subject:Re: zEC12 Upgrade
Sent by:IBM Mainframe Discussion List 



You can use FIXCAT in SMP/e to find what will be needed from a z/OS 
perspective. 

Thank you 
James H. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of venkat kulkarni
Sent: Friday, December 18, 2015 2:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zEC12 Upgrade

Hello,
 We are planning to upgrade our z9 to zEC12 Mainframe and 
currently we are running with z/OS 1.13 and z/OS 2.1  operating system. 
How can we find list of task need to be performed on z/OS side for this 
upgrade. Currently I reviewed all PTF required using PSP bucket.
But from z/Os side, I still need to find required changes.


Regards
Venkat

--
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: Coupling Facility Structure Re-sizing

[phil yogendran]

Thank you all for your replies. I will take your suggestions into
consideration going forward. We are in the process of upgrading from z10 -
> z12 -> z13 over the next few months. The CF upgrade is a part of this
project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15.

I expect to see better structure response with these changes and will be
surprised to see anything otherwise. Will keep you posted. Thanks again.

On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. <
robert.richa...@opm.gov> wrote:

> The archives probably have it, but simply put and if IIRC, there was an
> old 9674 being used with z990s. Waiting on CF structure response was
> horrific as compared to the speed of the z990 processor response.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: Friday, December 18, 2015 7:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Coupling Facility Structure Re-sizing
>
> Richards, Robert B. wrote:
>
> >The last thing you want is for your CFs to be slower than the CPs.
> >BTDTGTS
>
> Ouch. Could you be kind to tell us about it? Are there any manuals stating
> that trouble? Any configuration changes to avoid? Or is it about the sizes
> or quantity of LPARs involved?
>
> TIA!
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Any Git compliant Client for OMVS

[Bigendian Smalls]

Working on a git compilation - but it isn’t ready for prime time yet.  I’ll let 
you know when it is.

I haven’t seen any commercial or non-commercial version that work out of the 
box.  I’m compiling from source.  Slowly.
Very Slowly.



> On Dec 18, 2015, at 1:46 AM, Munif Sadek  wrote:
> 
> Dear Listers
> 
> I am trying to find any Git client to run under OMVS (z/OS 2.1) to automate 
> couple of Java objects deployment. I have tried 
> https://eclipse.org/jgit/download/ but not able to make it work.
> 
> regards 
> Munif  
> 
> --
> 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: S00C Slip trap for any Stc

[Shane Ginnane]

On Fri, 18 Dec 2015 08:51:08 -0500, Peter Relson wrote:

>>Can I set slip trap for abend s00c for any failing Address space ?
>
>To be unhelpful, the answer is "yes"

Peter, I can not (ever) recall an unhelpful answer from you - or Jim.
Some other respondents - now, that's a whole 'nuther kettle of fish.

Shane ...

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

Re: slight reprieve on the z.

[Grinsell, Don]

Cute.  The problem is there's nobody there to call bull$h!t or do a fact check. 
 We see this sort of testimony here as well often implying that we are still 
running an antiquated s/360 that absolutely nobody knows anything about 
anymore. 

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"Hell is other people."
~ Jean-Paul Sartre



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

Re: slight reprieve on the z.

[Sam Siegel]

it is all about the agenda they are driving.  Or the agenda of the
subordinate preparing the talking points.

On Fri, Dec 18, 2015 at 9:06 AM, Walter Davies 
wrote:

> Our board of supervisors like to say the mainframe is running on DOS. One
> is an ex intel management employee.
>
> On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:
>
> > Cute.  The problem is there's nobody there to call bull$h!t or do a fact
> > check.  We see this sort of testimony here as well often implying that we
> > are still running an antiquated s/360 that absolutely nobody knows
> anything
> > about anymore.
> >
> > --
> >
> > Donald Grinsell
> > State of Montana
> > 406-444-2983
> > dgrins...@mt.gov
> >
> > "Hell is other people."
> > ~ Jean-Paul Sartre
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
>
>
>
> Walter Davies
> Supervising IT Analyst
> walter.dav...@edcgov.us
> (530) 621-5420
>
> --
> 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: TAR Files:" Extracting" on a IBM Mainframe

[Ted MacNEIL]

It was converted from PASCAL for OS/390 1.7 (1990's). So, any doc would be of 
that vintage


-
-teD
-
  Original Message  
From: Elardus Engelbrecht
Sent: Friday, December 18, 2015 06:21
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: TAR Files:" Extracting" on a IBM Mainframe

Tony Harminc wrote:

> Shmuel Metz (Seymour J.) wrote:
>> No TCP/IP? Or is the old Pascal version still supported?

>No.

Hmmm, I know Pascal was used first [1] as source for TCP/IP and some modules 
were later rewritten in other languages.

Where is it documented that Pascal is not used as source for those [ IBM - z/OS 
] TCP/IP modules?

Groete / Greetings
Elardus Engelbrecht

[1] - based on what I remember (hey, my last remaining brain cells don't like 
exercises... ;-D) on IBM-MAIN when Pascal and TCP/IP was discussed in the past.

--
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: slight reprieve on the z.

[william janulin]

Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
 

On Friday, December 18, 2015 12:42 PM, Walter Davies 
 wrote:
 

 Our board of supervisors like to say the mainframe is running on DOS. One
is an ex intel management employee.

On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:

> Cute.  The problem is there's nobody there to call bull$h!t or do a fact
> check.  We see this sort of testimony here as well often implying that we
> are still running an antiquated s/360 that absolutely nobody knows anything
> about anymore.
>
> --
>
> Donald Grinsell
> State of Montana
> 406-444-2983
> dgrins...@mt.gov
>
> "Hell is other people."
> ~ Jean-Paul Sartre
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



Walter Davies
Supervising IT Analyst
walter.dav...@edcgov.us
(530) 621-5420

--
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: slight reprieve on the z.

[Walter Davies]

Our board of supervisors like to say the mainframe is running on DOS. One
is an ex intel management employee.

On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:

> Cute.  The problem is there's nobody there to call bull$h!t or do a fact
> check.  We see this sort of testimony here as well often implying that we
> are still running an antiquated s/360 that absolutely nobody knows anything
> about anymore.
>
> --
>
> Donald Grinsell
> State of Montana
> 406-444-2983
> dgrins...@mt.gov
>
> "Hell is other people."
> ~ Jean-Paul Sartre
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



Walter Davies
Supervising IT Analyst
walter.dav...@edcgov.us
(530) 621-5420

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

Re: slight reprieve on the z.

[Charles Mills]

"My mind is made up -- don't confuse me with facts."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of william janulin
Sent: Friday, December 18, 2015 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: slight reprieve on the z.

Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
 

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

Re: slight reprieve on the z.

[John McKown]

On Fri, Dec 18, 2015 at 11:57 AM, Charles Mills  wrote:

> "My mind is made up -- don't confuse me with facts."
>

​When I got my first job, that was the basic reason. The director of I.T.
decided to convert from DOS/VS to OS/VS1 because he was "ashamed" to admit
to other directors that his shop was DOS and not OS. It was a very well run
DOS shop, with some really good, smart, people. I was hired simply because
I new the basics of assembler and OS JCL. Straight of out college.​ Didn't
know CICS, or VSAM, or even way "systems programming" was. I was applying
for an applications job. And watching the apps manager's eyes glaze over.



>
> Charles
>
> --
Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: Delete part of spool for active job

[Shmuel Metz (Seymour J.)]

In
<4ee2851a2279b94cb70cd69b174106090149664...@s1flokydce2kx01.dm0001.info53.com>,
on 12/18/2015
   at 06:41 PM, "Jousma, David"  said:

>Yea, really don t care what the job numbers is in my case.

You don't care if you purge the wrong job?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: S00C Slip trap for any Stc

[Shmuel Metz (Seymour J.)]

In
<0601332775752188.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 12/18/2015
   at 03:23 AM, Elardus Engelbrecht 
said:

>I know, many IBM-MAIN members post sample syntax, sometimes 
>omitting crucial info for brevity, but it is up to the actual user 
>to verify/modify the command and all its parameters for accuracy.

And for relevance; even if the command is correct for the responders
installation it may not be quite what you need.

>Similar with the other thread where I said, use a program, I did 
>not say how the JCL + input should look like.

That's better than a lot of IBM manuals that spell out how to code JCL
and REXX, incorrectly. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: S00C Slip trap for any Stc

[Shmuel Metz (Seymour J.)]

In <20151218092003.952fe4e53c2ab28a6061e...@gmx.net>, on 12/18/2015
   at 09:20 AM, nitz-ibm  said:

>abend00C always means some problem with coupling services.

Shirley other programs get underflow.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

AW: Re: What CPU capacity does WLM look at when deciding to start more batch initiators?

[Peter Hunkeler]

Thanks, Kees
I've had a look at a couple of presentaions already, but not this one. Thanks 
for the pointer.

--
Peter Hunkeler



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

Re: Delete part of spool for active job

[Jousma, David]

Yea, really don’t care what the job numbers is in my case.  I care that a job 
is eating more spool than it should, and want to kill it.  Not sure why getting 
the job number is a requirement I guess.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, December 18, 2015 7:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Delete part of spool for active job

Jousma, David wrote:

>Here is what I devised, and has worked pretty well.  We use netview/SA390 for 
>our automation.  The following rules get tripped at 80% or 85% utilization. 

Good solution, but Skip still wants the job number. Can your Netview solution 
also handle jobnumber?
 
CMD=(,,'MVS $D JOBQ,SPOOL=(%>01)')   

Hmmm. It differs from Skip's command $DSPL,JOBS=nn, but job numbers are also 
shown on the SYSLOG together with the other details. It should help Skip very 
much.

I prefer this one $D JOBQ,SPOOL=(TGS>) because some of our jobs with say 
TGS = large are only occupying TGS% < 1. (I know you can do this $D 
JOBQ,SPOOL=(%>0.5) for % smaller than 1.)

Just a little sample on my SDSF showing my spool eaters: 

TGNum  TGPct
 4925   0.43
 6673   0.58
 7294   0.63


>   CMD=(PASS1,,'MVS $CJ(E*,T*),SPOOL=(%>10),PURGE')   << in our shop E* and T* 
> are non-prod jobs, and this usually kills the culprit 

Excellent! I will tell my z/OS team about this killer! ;-D

Granted, also no job numbers, but they want a solution based on job name.

Thanks!

Groete / Greetings
Elardus Engelbrecht

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Coupling Facility Structure Re-sizing

[phil yogendran]

The increases recommended by the CF Sizer is marginal. Our structures in
production are generously sized and we have lots of storage in the new CFs
so that's not a concern. I will however lookout for messages as suggested.

Most of our structures are duplexed. Some like the structure for the IRLM
lock are not. I have a note to investigate the product specific doc to
understand this better.

I also need to check on the performance of CF links as we're going to ICB
links now.

Thanks for the info.




On Fri, Dec 18, 2015 at 12:42 PM, Skip Robinson 
wrote:

> In case you're  curious, the parameters 'missing' from your old
> definitions were added over the years since the advent of coupling
> facility. The new parameters all have defaults such that they do not
> actually require specification, but using them may give you better control
> over structure sizes. Some additional points:
>
> -- At any time, the CF Sizer makes recommendations based on the latest
> hardware with the latest microcode. Newer hardware or newer microcode
> typically requires larger structures to accomplish the same work even with
> no changes to the exploiters.
>
> -- In my experience, CF Sizer makes very generous recommendations. Memory
> is cheaper now than ever, but watch out for gratuitous over allocation.
> Especially on an external CF, you might be constrained.
>
> -- Several structures require that you input data to CF Sizer on how busy
> you expect the structure to be. For most, this has less to do with the
> number of sysplex members than the amount of data the structure has to
> handle. This is seldom easy to determine. Make your best SWAG and monitor
> the results.
>
> -- The worst case is when a structure is too small for the exploiter to
> initialize. I have not seen this for some time; maybe the big exploiters
> have been (re)designed to come up regardless. But watch for messages
> indicating that a structure needed more than the specified minimum size at
> the outset.
>
> -- A parameter you did not ask about is DUPLEX. Even if you have only one
> box for CF use, I recommend two CF LPARs on that box with duplexing for
> relevant structures. Better of course would be two boxes. The best thing
> about sysplex is its ability to survive disruptions. Over the years we have
> had two CEC failures. In both cases, the second CF allowed all applications
> to resume with zero data recovery efforts. Note that some structures do not
> require duplexing, notably GRS. If a host dies, so do all of its enqueues.
>
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> jo.skip.robin...@gmail.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of phil yogendran
> Sent: Friday, December 18, 2015 07:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Coupling Facility Structure Re-sizing
>
> Thank you all for your replies. I will take your suggestions into
> consideration going forward. We are in the process of upgrading from z10 -
> > z12 -> z13 over the next few months. The CF upgrade is a part of this
> project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15.
>
> I expect to see better structure response with these changes and will be
> surprised to see anything otherwise. Will keep you posted. Thanks again.
>
> On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. <
> robert.richa...@opm.gov> wrote:
>
> > The archives probably have it, but simply put and if IIRC, there was
> > an old 9674 being used with z990s. Waiting on CF structure response
> > was horrific as compared to the speed of the z990 processor response.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Elardus Engelbrecht
> > Sent: Friday, December 18, 2015 7:55 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Coupling Facility Structure Re-sizing
> >
> > Richards, Robert B. wrote:
> >
> > >The last thing you want is for your CFs to be slower than the CPs.
> > >BTDTGTS
> >
> > Ouch. Could you be kind to tell us about it? Are there any manuals
> > stating that trouble? Any configuration changes to avoid? Or is it
> > about the sizes or quantity of LPARs involved?
> >
> > TIA!
> >
> > Groete / Greetings
> > Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: TAR Files:" Extracting" on a IBM Mainframe

[Charles Mills]

Trying to be helpful rather than smart*ss here, if you mean "I would prefer
a JCL-/batch-based solution to a UNIX command line solution" -- and if so I
am sympathetic -- then you should be aware that you can run a UNIX utility
from JCL. Here is an example. You should be able to run UXIX tar this way in
a job if you prefer.

//BPXARCH  EXEC PGM=BPXBATCH,COND=(4,LT),   
//PARM='SH cd /Object;ar -rvc Object.a *.o'   
//STDINDD   DUMMY   
//STDOUT   DD   SYSOUT=*
//STDERR   DD   SYSOUT=*

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonard Sasso
Sent: Thursday, December 17, 2015 9:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TAR Files:" Extracting" on a IBM Mainframe

Our management does allow the use of UNIX System Services, but I would
prefer not to.

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

DOS descendant still lives was Re: slight reprieve on the z.

[Clark Morris]

On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:

>Nice, maybe someone should introduce them to the Mainframe Basics Redbook.
> 
>
>On Friday, December 18, 2015 12:42 PM, Walter Davies 
>  wrote:
> 
>
> Our board of supervisors like to say the mainframe is running on DOS. One
>is an ex intel management employee.

Since VSE (DOS descendant) is still supported and upgraded (I suspect
mostly under VM), the statement could be accurate.  Are there any
current IBM references to DOS/VSE?  Does anyone run VSE on the bare
metal?

Clark Morris
>
>On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:
>
>> Cute.  The problem is there's nobody there to call bull$h!t or do a fact
>> check.  We see this sort of testimony here as well often implying that we
>> are still running an antiquated s/360 that absolutely nobody knows anything
>> about anymore.
>>
>> --
>>
>> Donald Grinsell
>> State of Montana
>> 406-444-2983
>> dgrins...@mt.gov
>>
>> "Hell is other people."
>> ~ Jean-Paul Sartre
>>
>>
>>
>> --
>> 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: DOS descendant still lives was Re: slight reprieve on the z.

[Tony Thigpen]

There are a bunch of us z/VSE customers. Many on bare iron. Many on z/VM.

Tony Thigpen

Clark Morris wrote on 12/18/2015 07:31 PM:

On 18 Dec 2015 09:44:15 -0800, in bit.listserv.ibm-main you wrote:


Nice, maybe someone should introduce them to the Mainframe Basics Redbook.


On Friday, December 18, 2015 12:42 PM, Walter Davies 
 wrote:


Our board of supervisors like to say the mainframe is running on DOS. One
is an ex intel management employee.


Since VSE (DOS descendant) is still supported and upgraded (I suspect
mostly under VM), the statement could be accurate.  Are there any
current IBM references to DOS/VSE?  Does anyone run VSE on the bare
metal?

Clark Morris


On Fri, Dec 18, 2015 at 8:40 AM, Grinsell, Don  wrote:


Cute.  The problem is there's nobody there to call bull$h!t or do a fact
check.  We see this sort of testimony here as well often implying that we
are still running an antiquated s/360 that absolutely nobody knows anything
about anymore.

--

Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"Hell is other people."
~ Jean-Paul Sartre



--
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: TAR Files:" Extracting" on a IBM Mainframe

[Charles Mills]

I resemble that remark!

Different people are comfortable with different things. I happen to be 
comfortable with PDSs of JCL and not terribly comfortable with shell scripts. 
So shoot me. I plead guilty. I was suggesting that the OP might possibly be in 
the same boat.

> isn't this really just writing the dreaded shell script in the PARM?

Of course! OTOH it is embedded in an environment with which the OP may be more 
comfortable. If the remainder of the OP's process is JCL-based then this may be 
a better solution than running one job, getting over to a UNIX prompt and 
running one command, and then running a second batch job.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, December 18, 2015 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TAR Files:" Extracting" on a IBM Mainframe

On Fri, 18 Dec 2015 12:43:33 -0800, Charles Mills wrote:

>Trying to be helpful rather than smart*ss here, if you mean "I would 
>prefer a JCL-/batch-based solution to a UNIX command line solution" -- 
>and if so I
>
Being a smartass here, this reminds me of trying to make a C library with JCL 
instead of OMVS make.

>am sympathetic -- then you should be aware that you can run a UNIX 
>utility from JCL. Here is an example. You should be able to run UXIX 
>tar this way in a job if you prefer.
>
Here's a tested example:
//*
//*  Symbolics to obfuscate DSNAMEs and meet JCL LRECL limit.
//*  Archive is in legacy data set;  "pax" prefixes like TSO.
//*
//*  pax extracts to UNIX directory hierarchy.
//*OGETX could copy to PDS(E).  I don't know whether
//*"Data21's ZIP/390 Product" might eliminate a step.
//*In either case a multilevel hierarchy makes it harder.
//*
//BPXARCH  EXEC PGM=BPXBATCH,COND=(4,LT), //  PARM='SH set -x; cd /tmp/ 
pax -rvf //'
//*
//STDINDD   DUMMY
//STDOUT   DD   SYSOUT=*
//STDERR   DD   SYSOUT=*
//
(But isn't this really just writing the dreaded shell script in the PARM?)

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

Re: AW: Re: What CPU capacity does WLM look at when deciding to start more ba...

[Ed Finnell]

_www.watsonwalker.com_ (http://www.watsonwalker.com)  is a good  resource. 
It gives an overview of what they do and what they offer. There are  also 
links to presentations they have given and articles of interest. In the  free 
tools there's a policy agent.
Even if you don't implement it's a good learning experience.
 
 
In a message dated 12/18/2015 2:12:03 P.M. Central Standard Time,  
p...@gmx.ch writes:

I've had  a look at a couple of presentations already, but not this one. 
Thanks for the  pointer.



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

Re: TAR Files:" Extracting" on a IBM Mainframe

[Paul Gilmartin]

On Fri, 18 Dec 2015 12:43:33 -0800, Charles Mills wrote:

>Trying to be helpful rather than smart*ss here, if you mean "I would prefer
>a JCL-/batch-based solution to a UNIX command line solution" -- and if so I
>
Being a smartass here, this reminds me of trying to make a C library with
JCL instead of OMVS make.

>am sympathetic -- then you should be aware that you can run a UNIX utility
>from JCL. Here is an example. You should be able to run UXIX tar this way in
>a job if you prefer.
>
Here's a tested example:
//*
//*  Symbolics to obfuscate DSNAMEs and meet JCL LRECL limit.
//*  Archive is in legacy data set;  "pax" prefixes like TSO.
//*
//*  pax extracts to UNIX directory hierarchy.
//*OGETX could copy to PDS(E).  I don't know whether
//*"Data21's ZIP/390 Product" might eliminate a step.
//*In either case a multilevel hierarchy makes it harder.
//*
//BPXARCH  EXEC PGM=BPXBATCH,COND=(4,LT),
//  PARM='SH set -x; cd /tmp/ pax -rvf //'
//*
//STDINDD   DUMMY
//STDOUT   DD   SYSOUT=*
//STDERR   DD   SYSOUT=*
//
(But isn't this really just writing the dreaded shell script in the PARM?)

-- gil

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

Re: Coupling Facility Structure Re-sizing

[Skip Robinson]

Wow, I feel so ancient. In the History of the World Part II, there are two 
kinds of duplexing. The late comer is System Managed Duplexing, which is 
provided by z/OS - XCF - XES. The exploiter does not need to participate in SMD 
(my acronym); he just reaps the benefits. But SMD for customer use was delayed 
for quite a while because IBM could not get it working. (More history.)

Meanwhile DB2 could not wait for SMD and developed their own duplexing 
mechanism. Hence DB2/IRLM does not need/use SMD. I forgot that when I mentioned 
DB2 recovery. So I recommend that DUPLEX be specified for all other structures 
that need SMD. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of phil yogendran
Sent: Friday, December 18, 2015 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: Coupling Facility Structure Re-sizing

The increases recommended by the CF Sizer is marginal. Our structures in 
production are generously sized and we have lots of storage in the new CFs so 
that's not a concern. I will however lookout for messages as suggested.

Most of our structures are duplexed. Some like the structure for the IRLM lock 
are not. I have a note to investigate the product specific doc to understand 
this better.

I also need to check on the performance of CF links as we're going to ICB links 
now.

Thanks for the info.




On Fri, Dec 18, 2015 at 12:42 PM, Skip Robinson 
wrote:

> In case you're  curious, the parameters 'missing' from your old 
> definitions were added over the years since the advent of coupling 
> facility. The new parameters all have defaults such that they do not 
> actually require specification, but using them may give you better 
> control over structure sizes. Some additional points:
>
> -- At any time, the CF Sizer makes recommendations based on the latest 
> hardware with the latest microcode. Newer hardware or newer microcode 
> typically requires larger structures to accomplish the same work even 
> with no changes to the exploiters.
>
> -- In my experience, CF Sizer makes very generous recommendations. 
> Memory is cheaper now than ever, but watch out for gratuitous over allocation.
> Especially on an external CF, you might be constrained.
>
> -- Several structures require that you input data to CF Sizer on how 
> busy you expect the structure to be. For most, this has less to do 
> with the number of sysplex members than the amount of data the 
> structure has to handle. This is seldom easy to determine. Make your 
> best SWAG and monitor the results.
>
> -- The worst case is when a structure is too small for the exploiter 
> to initialize. I have not seen this for some time; maybe the big 
> exploiters have been (re)designed to come up regardless. But watch for 
> messages indicating that a structure needed more than the specified 
> minimum size at the outset.
>
> -- A parameter you did not ask about is DUPLEX. Even if you have only 
> one box for CF use, I recommend two CF LPARs on that box with 
> duplexing for relevant structures. Better of course would be two 
> boxes. The best thing about sysplex is its ability to survive 
> disruptions. Over the years we have had two CEC failures. In both 
> cases, the second CF allowed all applications to resume with zero data 
> recovery efforts. Note that some structures do not require duplexing, notably 
> GRS. If a host dies, so do all of its enqueues.
>
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> jo.skip.robin...@gmail.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of phil yogendran
> Sent: Friday, December 18, 2015 07:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Coupling Facility Structure Re-sizing
>
> Thank you all for your replies. I will take your suggestions into 
> consideration going forward. We are in the process of upgrading from 
> z10 -
> > z12 -> z13 over the next few months. The CF upgrade is a part of 
> > this
> project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15.
>
> I expect to see better structure response with these changes and will 
> be surprised to see anything otherwise. Will keep you posted. Thanks again.
>
> On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. < 
> robert.richa...@opm.gov> wrote:
>
> > The archives probably have it, but simply put and if IIRC, there was 
> > an old 9674 being used with z990s. Waiting on CF structure response 
> > was horrific as compared to the speed of the z990 processor response.
> >
> > -Original Message-
> > From: IBM Mainframe 

Re: S00C Slip trap for any Stc

[Nathan Astle]

Hi Group

Basically I am trying to capture the SLIP for the XCF signal failure in our
base sysplex environment.

Our SMF logstream has been defined in IXGLOGR with dasdonly. Does that mean
IXGLOGR will Buffer SMF records in memory if it cannot write to DASD ?

What might be happening here, is that the S00C abend affects XCF services,
which in turn effect the users of XCF which are: WLM, JES2, GRS, and
MASTER. At this point GRS becomes unresponsive, and won’t permit the ENQ of
a dataset, if that dataset is the IFASMF logstream, the records start to
backup, where does IXGLOGR put them.  Would allowing IXGLOGR to use
structures in the CF help prevent IXGLOGR from stealing real storage to
buffer SYS EVENTs in the event of the S00C abend of XCF?

Any suggestions ?

Regards
Nathan



On Saturday 19 December 2015, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> <0601332775752188.wa.elardus.engelbrechtsita.co...@listserv.ua.edu
> >,
> on 12/18/2015
>at 03:23 AM, Elardus Engelbrecht  >
> said:
>
> >I know, many IBM-MAIN members post sample syntax, sometimes
> >omitting crucial info for brevity, but it is up to the actual user
> >to verify/modify the command and all its parameters for accuracy.
>
> And for relevance; even if the command is correct for the responders
> installation it may not be quite what you need.
>
> >Similar with the other thread where I said, use a program, I did
> >not say how the JCL + input should look like.
>
> That's better than a lot of IBM manuals that spell out how to code JCL
> and REXX, incorrectly.
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> 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: Delete part of spool for active job

[Skip Robinson]

Purging the wrong job would be sad, but alas, if you try to purge a job by
name only, and there is more than one match in spool, JES2 will do nothing
other than tell you what a doofus you are for being so vague. I think I have
the answer thanks to IBM-Main advice on and off list. $D SPOOL is the wrong
command. What's needed is $D JOBQ, which returns job number(s) that can then
be acted on properly. Thanks to all who contributed to this denouement. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Friday, December 18, 2015 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] Re: Delete part of spool for active job

In
<4ee2851a2279b94cb70cd69b174106090149664...@s1flokydce2kx01.dm0001.info53.co
m>,
on 12/18/2015
   at 06:41 PM, "Jousma, David"  said:

>Yea, really don t care what the job numbers is in my case.

You don't care if you purge the wrong job?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT

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