Re: FRR Parameter Area too small

2014-12-17 Thread Binyamin Dissen
On Wed, 17 Dec 2014 17:56:38 -0600 John Sullivan 
wrote:

:>I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR 
A,PARMAD= is too small!  
:>I am having to re-work some code to support 64-bit (and prior 31-bit) callers 
in SRB mode and am curious what others do in this situation.  

:>The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 
64-bit support.  
:>The thought of getting storage and later freeing it seems expensive, just to 
have an "Extended FRR Parameter Area". 

:>FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR 
requests) and chaining them is likely to run out and lead to disaster.  
:>Also probably frowned upon, i.e. it is both ugly and asking for problems, 
especially if there is recursion (occasionally can happen).

:>Anyone else hit this?
:>And what have you done to get around it?

I am sure that most have found even the 24 bytes to be insufficient in most
cases and thus save a pointer to the real recovery stuff. I guess you were
lucky to only require 24 bytes.

You must certainly hate PC-ARRs, where you only have eight bytes of data  to
save for the recovery routine.

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


AW: publibz->infocenter->knowledgecenter

2014-12-17 Thread Peter Hunkeler
>What's a quick link to this week's z/OS v2r1 software shelflist?
 >
> Bring back LOOKAT!


...and bring back BookMaster and BookServer as well.


--
Peter Hunkeler



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


AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Peter Hunkeler

> Yeah but that's only as of z/OS 2.1 ?.as a ISV we support backlevel versions 
> also ?so one has to come up with two solutions ?

If you need the symbol substitution, then yes, this requires z/OS V2.1. The 
STDPARM has been there at least in V1.13.


--


Peter Hunkeler



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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Linda Hagedorn
The bad SQL is usually tablespace scans, and/or Cartesian product.  They are 
relatively easy to identify and cancel.  

MVS reports the stress in prod, the high CPU use on the dev lpar, and I find 
the misbehaving thread and cancel it.  Mvs reports things then return to 
normal.  

The perplexing part is the bad SQL running on LPARA is affecting its own lpar 
and the major lpar on the CEC.  It's own lpar I can understand, but the other 
one too? 

The prefetches - dynamic, list, and sequential are ziip eligible in DB2 V10, so 
the comment about the bad SQL taking the ziips from prod is possible.  I'm 
adding that to my list as something to check.  

The I/o comment is interesting. I'll add it to my list to watch for also.  

I'm hitting the books tonight.  Thanks for all the ideas and references. 

Sent from my iPad

>> On Dec 17, 2014, at 9:48 PM, Clark Morris  wrote:
>> 
>> On 17 Dec 2014 14:13:46 -0800, in bit.listserv.ibm-main you wrote:
>> 
>> In pretty good with DB2, and Craig is wonderful.  
>> 
>> It's the intricacies of MVS performance I need to bring in focus.  I have a 
>> lot of reading and research to do so I can collect appropriate doc the next 
>> time one of these hits.  
> 
> After reading most of this thread, two things hit this retired systems
> programmer.  The first is that with all DASD shared, runaway bad SQL
> may be doing a number on your disk performance due to contention and I
> would look at I-O on both production and test.  DB2 and other experts
> who are more familiar with current DASD technology and contention can
> give more help.  The other is the role played on both LPARs by the use
> of zAAP and zIIP processors which run hecat full speed and reduced cost
> for selected work loads.  The bad SQL may be eligible to run on those
> processors and taking away the availability from production.  This is
> just a guess based on a dangerous (inadequate) amount of knowledge.
> 
> Clark Morris
>> 
>> Linda 
>> Sent from my iPhone
>> 
>>> On Dec 17, 2014, at 2:34 PM, Ed Finnell 
>>> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> Craig Mullin's DB/2 books are really educational in scope and insight(and  
>>> heavy). Fundamental understanding of the interoperation is key to 
>>> identifying  and tuning  problems. He was with Platinum  when he first 
>>> began the  
>>> series and moved on after the acquisition by CA.(He and other vendors were
>>> presenting at our ADUG conference on 9/11/01. Haven't seen him since but  
>>> still get the updates.)
>>> 
>>> The CA tools are really good at pinpointing problems. Detector and Log  
>>> Analyzer are key. For SQL there's the SQL analyzer(priced) component. 
>>> Sometimes 
>>> if it's third party software there may be a known issues with certain  
>>> transactions or areas of interactions.
>>> 
>>> For continual knowledge _www.share.org_ (http://www.share.org)  is a good 
>>> source. Developers  and installations give current and timely advice on 
>>> fitting metrics to machines.  The proceedings for the last three Events are 
>>> kept 
>>> online
>>> without signup. The new RMF stuff for EC12 and Flash drives is pretty  
>>> awesome. 
>>> 
>>> 
>>> In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time,  
>>> linda.haged...@gmail.com writes:
>>> 
>>> I lurk  on IBM-Main, and I'm always awed by the knowledge here.   
>>> 
>>> 
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: JCLLIB in started proc?

2014-12-17 Thread Lizette Koehler
I did a quick internet search usingibm stc jcl with jobcard

  I found this

Job Cards for Started Tasks
Sometime around MVS/ESA V5.1, IBM introduced job card support for started
tasks. To use this feature, the started task JCL must reside in a dataset
specified in either the IEFJOBS or IEFPDSI DD statements of the master
scheduler JCL (MSTJCLxx PARMLIB member). Refer to "MVS Initialization and
Tuning Reference" for some suggestions on how to set this up. 
For the purpose of the following examples, I will presume that a separate
IEFJOBS dataset has been allocated. 
Adding Accounting Information

A typical member in IEFJOBS could look like this: 

//JES2  JOB  (8022,BX00)  JOB CARD SUPPORT
//IEFPROC   EXEC JES2
 The JCL for JES2 will be picked up from the IEFPDSI concatenation. The
resulting started task JCL could look something like: 

//JES2  JOB (8022,BX00),
// MSGLEVEL=1
//IEFPROC   EXEC JES2
 At this point, we have added some accounting information to the started
task. 
Additional Features
Now, you are able to add other features to the started task JCL. For
instance, say you wished to change the output characteristics for the
started task. You could do something like this: 

//INIT  JOB  (8024,BX00)  JOB CARD SUPPORT
//DFLT  OUTPUT JESDS=ALL,CLASS=Z
//IEFPROC   EXEC INIT
 So this started task can have a different sysout class than others. Another
new capability is getting the started task JCL from somewhere else: 

//TAPEINI  JOB  (8100,BX01)  JOB CARD SUPPORT
//STCJCL  JCLLIB ORDER=(TAPELIB.STCJCL)
//TPINIT   EXEC TAPEINI
 The JCL for TAPEINI will be picked up from TAPELIB.STCJCL. 
Notes
If you specify the PARM option on the MVS START command; for example, 

S JES2,PARM='WARM,NOREQ'
the specified PARM value will not be used if you are using job cards. An
alternative method of accomplishing the same result, is to set up a symbolic
parameter PRM in the PROC for JES2 which will be substituted into the PARM
value of the EXEC statement and use the command 

S JES2,PRM='WARM,NOREQ'
instead. Your JES2 PROC (in IEFPDSI) would look like: 

//JES2 PROC PRM='WARM,NOREQ' 
//IEFPROC  EXEC PGM=HASJES20,PARM='&PRM',
 . etc 
 
If a job card member is not present in the IEFJOBS dataset, then the started
task JCL will be built and work as before. 
I have only scratched the surface on this subject. Refer to the chapter on
"Started Tasks" in "MVS JCL Reference" for more information. Go to the links
page to find OS/390 books on the Web. 


Check what libraries are in your MSTJCLxx member in SYS1.PARMLIB


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Wednesday, December 17, 2014 6:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: JCLLIB in started proc?
> 
> I just added a JCLLIB statement to a cataloged  procedure that I start
with a Start
> command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I
> infer that JCLLIB is not allowed in a started PROC, or should I be looking
for a fat-
> finger coding error? (I want the JCLLIB for INCLUDE, not EXEC
> PROC=.) I RTFM but don't see anything explicit.
> 
> It does refer to "in a job" at several points. Is JCLLIB allowed in a
started PROC if
> the PROC has a JOB statement? I know I can do that but I've never done it.
Where
> is that documented?
> 
> Thanks,
> 
> Charles
> 

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


Fwd: FC0994 authServer: secure_socket_init failed with rc = 428 (Key entry does not contain a private key)

2014-12-17 Thread John Mattson
-- Forwarded message --
From: John Mattson 
Date: Wed, Dec 17, 2014 at 5:41 PM
Subject: FC0994 authServer: secure_socket_init failed with rc = 428 (Key
entry does not contain a private key)
To: RACF Discussion List ,
ibm-m...@listserve.ua.edu

Cross post RACF-L and IBM-MAIN
Getting the error trying to do TLS FTP from zOS 1.11 to a Unix server.
Hoping someone has seen this before.  FC0994 authServer: secure_socket_init
failed with rc = 428 (Key entry does not contain a private key)  I have
checked and re-checked that our SelfSigned cert is the private one, and
that we have the vendors CERTAUTH and SITE certs in place.  I did find an
old entry from Hal Merritt back in 2009, but no resolution.

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Clark Morris
On 17 Dec 2014 14:13:46 -0800, in bit.listserv.ibm-main you wrote:

>In pretty good with DB2, and Craig is wonderful.  
>
>It's the intricacies of MVS performance I need to bring in focus.  I have a 
>lot of reading and research to do so I can collect appropriate doc the next 
>time one of these hits.  

After reading most of this thread, two things hit this retired systems
programmer.  The first is that with all DASD shared, runaway bad SQL
may be doing a number on your disk performance due to contention and I
would look at I-O on both production and test.  DB2 and other experts
who are more familiar with current DASD technology and contention can
give more help.  The other is the role played on both LPARs by the use
of zAAP and zIIP processors which run at full speed and reduced cost
for selected work loads.  The bad SQL may be eligible to run on those
processors and taking away the availability from production.  This is
just a guess based on a dangerous (inadequate) amount of knowledge.

Clark Morris
>
>Linda 
>Sent from my iPhone
>
>On Dec 17, 2014, at 2:34 PM, Ed Finnell 
><000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Craig Mullin's DB/2 books are really educational in scope and insight(and  
>> heavy). Fundamental understanding of the interoperation is key to 
>> identifying  and tuning  problems. He was with Platinum  when he first began 
>> the  
>> series and moved on after the acquisition by CA.(He and other vendors were
>> presenting at our ADUG conference on 9/11/01. Haven't seen him since but  
>> still get the updates.)
>> 
>> The CA tools are really good at pinpointing problems. Detector and Log  
>> Analyzer are key. For SQL there's the SQL analyzer(priced) component. 
>> Sometimes 
>> if it's third party software there may be a known issues with certain  
>> transactions or areas of interactions.
>> 
>> For continual knowledge _www.share.org_ (http://www.share.org)  is a good 
>> source. Developers  and installations give current and timely advice on 
>> fitting metrics to machines.  The proceedings for the last three Events are 
>> kept 
>> online
>> without signup. The new RMF stuff for EC12 and Flash drives is pretty  
>> awesome. 
>> 
>> 
>> In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time,  
>> linda.haged...@gmail.com writes:
>> 
>> I lurk  on IBM-Main, and I'm always awed by the knowledge here.   
>> 
>> 
>> 
>> --
>> 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: ftp rdw

2014-12-17 Thread Paul Edwards
Thanks for the pointer Kirk.

I have submitted it:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=63596

BFN. Paul.

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


Re: ftp rdw

2014-12-17 Thread Paul Edwards
> And he wants to be
> able to read the envelope file on a PC, but he hasn't mentioned the
> EBCDIC<-->ASCII problem.  Perhaps it's considered a given; SMoP again.

That's fine. It's well-defined that the binary file is in
EBCDIC, uses big-endian 4-byte integers etc. Thus
any EBCDIC text will be run through this code:

http://mvs380.cvs.sourceforge.net/viewvc/mvs380/mvssrc/ozpd/c/febc.c?view=markup

in order to be portable.

BFN. Paul.

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


Re: ftp rdw

2014-12-17 Thread Paul Gilmartin
On Tue, 16 Dec 2014 09:46:30 -0600, John McKown wrote:
>
>STRU F / SITE RDW - usable. Each VBS segment​ read separately and
>correctly. The code on the PC must reassemble segmented records.
> 
Where'd you get a VBS file to test?  Did you make one?  I'm testing
with an IEBCOPY PDSU; RECFM=VS.  I'd like to experiment with one
that is actually Blocked (multiple segments in a block) and Spanned
(multiple segments per logical record).

I find that with BINARY; TYPE E; MODE B; I can FTP PUT my VB file intact.
The SENDSITE helps a lot.  And I can FTP GET it with the same options
*provided* I first copy the SENDSITE echoed on the PUT and issue it
as a LOCSITE command.

I believe (but where's my PoC?) that I could synthesize on a desktop,
non-z, non MVS/380 system a binary file that I could PUT and reconstruct
a RECFM=VB data set (with either STRU R or TYPE E, MODE B) or RECFM=VBS
(only with TYPE E, mode B).

But the OP seems more intent on whining about the failure of the technique
he's fixated on than switching to an effective technique.  It's more complex
than he'd like, but things are tough all over.  SMoP.  And he wants to be
able to read the envelope file on a PC, but he hasn't mentioned the
EBCDIC<-->ASCII problem.  Perhaps it's considered a given; SMoP again.

-- gil

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


Re: Utility to replace occurrences of string in PDS?

2014-12-17 Thread David Price
PDS or STARTOOL Usage

The PDS package (free from CBT file 182) and Serena's STARTOOL product were 
mentioned earlier.  Here's a note about their syntax.

The TSO command  PDS  pdsname  REPL  :  !stringA!stringB!  WRITE  is all you 
need.  As a TSO command it is easy to put in a batch job.  [Use the STARTOOL 
command instead of PDS if you have the Serena product.]

The  !  character is a delimiter.  It can be any character that is not in 
either of the strings.
People often use  /  as the delimiter, but avoid  /  if using it as a line 
command in ISPF option 3.4 since / of course substitutes to the dataset name in 
the ISPF 3.4 dataset list.

Omit the  WRITE  keyword to get a simulated replacement run without any actual 
updates.

PDS  pdsname  FIND  :  !stringA!   is the command to do a FIND across the PDS 
(useful prior to REPLacement).

Interactively you can use the   "PDS pdsname"   TSO command to get into PDS (or 
STARTOOL) and then use the REPL or FIND subcommands from there.  From within 
ISPF you get nice panels showing the member list.  From true READY mode you get 
the TSO line mode experience.

The colon character  :  specifies ALL members.  You can instead specify a 
subset of members such as  ABC:DEF (all members beginning with ABC through to 
those beginning with DEF) or throw some * wildcards into the mix.


Edit Macro Across All Members

Edit Macros were also mentioned earlier in the thread as an alternative.  
Consider the ISPF sample edit macro ISRMBRS which is both documented and 
shipped with ISPF.  Mainly for interactive use.  If you edit a non-existent 
member in your PDS, for example TEMPXYZ, and then invoke the edit macro as  
ISRMBRS MYMACRO  then your edit macro MYMACRO will be applied to every member 
(except the member you are editing from).  However, make sure your edit macro 
has the ISPF 'END' command in it, or you will be pressing PF3 for every member.

Hope that helps, dap

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


Re: JCLLIB in started proc?

2014-12-17 Thread Charles Mills
Here's the first few lines -- includes all of the error lines. &FMID is or
would be set if the INCLUDE worked.

//USERIDAX JOB ,' Test Job',MSGCLASS=A,NOTIFY=&SYSUID,CLASS=A   
//*   
//*  Pick up correct load libarary
//JCLLIB  ORDER=USERID.COMPANY.CNTL  
//INCLUDE MEMBER=SETPACKG 
//*   
//MYTEST  PROC RUNMODE=,INSTALL=,VERBOSE=,TRACE=,   
//   INSTANCE=1,  
//   LOADLIB=USERID.&FMID..LOADPDSE  

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Scott Ford
Sent: Wednesday, December 17, 2014 5:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCLLIB in started proc?

Charles,
Can we see you job stream ?

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


Re: FRR Parameter Area too small

2014-12-17 Thread Jim Mulder
> I have a problem in that the FRR Parameter Area (24 bytes) returned 
> in SETFRR A,PARMAD= is too small! 
> I am having to re-work some code to support 64-bit (and prior 31-
> bit) callers in SRB mode and am curious what others do in this 
situation. 
> 
> The 24 byte FRR Parameter area used to hold 6 registers but now only
> 3 for 64-bit support. 
> The thought of getting storage and later freeing it seems expensive,
> just to have an "Extended FRR Parameter Area". 
> 
> FRR STACK size is fairly small, so not sure if getting 2 areas (2 
> SETFRR requests) and chaining them is likely to run out and lead to 
> disaster. 
> Also probably frowned upon, i.e. it is both ugly and asking for 
> problems, especially if there is recursion (occasionally can happen).

  The FRR stack is limited to 32 entries, so unless you 
are in control of how many entries are on the stack when you
are invoked, and how many entries are used by things that
you invoke,  it may be inadvisable to use SETFRR as 
a method for acquiring a small amount of storage. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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


Re: JCLLIB in started proc?

2014-12-17 Thread Charles Mills
I added a JOB statement and now I get an error on that also: IEFC019I MISPLACED 
JOB STATEMENT

The documentation seems to me to be contradictory. 

In the JCL Reference: " A cataloged procedure may consist of these JCL 
statements: CNTL, command, DD, ENDCNTL, EXEC, IF/THEN/ELSE/ENDIF, INCLUDE, 
OUTPUT JCL, and SET. Optionally, a cataloged procedure can begin with a PROC 
statement and end with a PEND statement. If coded, PROC must be the first 
statement in the procedure." -- No "JOB" in there.

In System Commands under Start: " The job name for a given started task can be 
assigned based on a variety of inputs. ... 2. The job name specified on the JOB 
JCL statement within the member."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs
Sent: Wednesday, December 17, 2014 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCLLIB in started proc?

I use something like this in the STCJOBS dataset that's allocated in MSTJCL00.

//MYSTC JOB
// JCLLIB ORDER=(TECHSVC.PROCLIB)
//MYSTC EXEC MYSTC

Mark Jacobs

Charles Mills wrote:
>
> I just added a JCLLIB statement to a cataloged procedure that I start 
> with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT.
> Should I
> infer that JCLLIB is not allowed in a started PROC, or should I be 
> looking for a fat-finger coding error? (I want the JCLLIB for INCLUDE, 
> not EXEC
> PROC=.) I RTFM but don't see anything explicit.
>
> It does refer to "in a job" at several points. Is JCLLIB allowed in a 
> started PROC if the PROC has a JOB statement? I know I can do that but 
> I've never done it. Where is that documented?
>
> Thanks,
>
> Charles
>
> --
> 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: JCLLIB in started proc?

2014-12-17 Thread Scott Ford
Charles, 
Can we see you job stream ?

Scott ford
www.identityforge.com
from my IPAD




> On Dec 17, 2014, at 8:05 PM, Charles Mills  wrote:
> 
> I just added a JCLLIB statement to a cataloged  procedure that I start with
> a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I
> infer that JCLLIB is not allowed in a started PROC, or should I be looking
> for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC
> PROC=.) I RTFM but don't see anything explicit.
> 
> It does refer to "in a job" at several points. Is JCLLIB allowed in a
> started PROC if the PROC has a JOB statement? I know I can do that but I've
> never done it. Where is that documented?
> 
> Thanks,
> 
> Charles 
> 
> --
> 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: JCLLIB in started proc?

2014-12-17 Thread Mark Jacobs
I use something like this in the STCJOBS dataset that's allocated in 
MSTJCL00.


//MYSTC JOB
// JCLLIB ORDER=(TECHSVC.PROCLIB)
//MYSTC EXEC MYSTC

Mark Jacobs

Charles Mills wrote:


I just added a JCLLIB statement to a cataloged procedure that I start with
a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. 
Should I

infer that JCLLIB is not allowed in a started PROC, or should I be looking
for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC
PROC=.) I RTFM but don't see anything explicit.

It does refer to "in a job" at several points. Is JCLLIB allowed in a
started PROC if the PROC has a JOB statement? I know I can do that but 
I've

never done it. Where is that documented?

Thanks,

Charles

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


JCLLIB in started proc?

2014-12-17 Thread Charles Mills
I just added a JCLLIB statement to a cataloged  procedure that I start with
a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I
infer that JCLLIB is not allowed in a started PROC, or should I be looking
for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC
PROC=.) I RTFM but don't see anything explicit.

It does refer to "in a job" at several points. Is JCLLIB allowed in a
started PROC if the PROC has a JOB statement? I know I can do that but I've
never done it. Where is that documented?

Thanks,

Charles 

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


FRR Parameter Area too small

2014-12-17 Thread John Sullivan
I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR 
A,PARMAD= is too small!  
I am having to re-work some code to support 64-bit (and prior 31-bit) callers 
in SRB mode and am curious what others do in this situation.  

The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 
64-bit support.  
The thought of getting storage and later freeing it seems expensive, just to 
have an "Extended FRR Parameter Area". 

FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR 
requests) and chaining them is likely to run out and lead to disaster.  
Also probably frowned upon, i.e. it is both ugly and asking for problems, 
especially if there is recursion (occasionally can happen).

Anyone else hit this?
And what have you done to get around it?
Thanks,
John

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


Re: Trouble with IARV64 GETCOMMON

2014-12-17 Thread Jim Mulder
> The default setting for IARV64 FPROT is YES meaning that the program
> accessing the storage must have a PSW key that matches the storage 
> key of the memobj (or PSW key 0).
> 
> I believe that IPCS storage browse ACTIVE runs in problem state and 
> key8 - therefore you will not see the storage.
> 
> If you want all address spaces to see your common memobj, try using 
> FPROT=NO on the IARV64 macro.
> 
> Rob Scott
> Lead Developer
> Rocket Software
> 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
> Tel: +1.781.684.2305
> Email: rsc...@rs.com
> Web: www.rocketsoftware.com
> 
> -Original Message-
> I issue the following macro:
> IARV64 REQUEST=GETCOMMON,
>   COND=YES,
>   SEGMENTS=SBS01, <=== Value is 1.
>   MOTKNSOURCE=SYSTEM,OUTMOTKN=SBITKN,
>   TYPE=PAGEABLE,
>   OWNERCOM=SYSTEM,
>   ORIGIN=SBILOC,
>   DUMP=LIKECSA,
>   RSNCODE=SBIRSN
> 
> I display the address obtained.
> 
> When I look at this address in IPCS looking at the ACTIVE address 
> space, I do not see my storage.
> 
> When I take a dump of my address space, I see my storage.
> 
> What am I doing wrong?

Active Storage Processing

 z/OS MVS IPCS User's Guide
 SA23-1384-00 

IPCS can process as a dump the central storage for the 
address space in which IPCS is currently running, 
private storage, and any common storage accessible by 
an unauthorized problem state program. Users running 
z/OS® R2 IPCS on a z/OS R2 system who have been authorized 
READ access to facility class resource BLSACTV.ADDRSPAC 
may view storage that is fetch-protected from application code.


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
Sent from my iPhone

On Dec 17, 2014, at 12:38 PM, Lizette Koehler  wrote:

> How is the dasd handled? Is it separate between Prd and other LPARs?  Or do
> you share your dasd.

Dasd is shared.  

> 
> In other words any LPAR can see any dasd for any other LPAR or is it PRD
> dasd is only on prd and not accessible by the other LPARS?

Its all shared.  


> How does Operation identify the issue?  Are they looking at an alert? Or  a
> Monitor (Tivoli Omegamon, other?) 

That's one of the outstanding questions.

> How is the network during this time?  Is connectivity optimal or slowed
> down?

Operations is adept at monitoring.  They do not identify any network issues.  
I'll ask them specifically next time.  


> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of L Hagedorn
>> Sent: Wednesday, December 17, 2014 9:09 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
>> 
>> MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting
>> LPAR B.  I didn't ask them for doc, but will next time.
>> 
>> This is a runtime issue, unrelated to reported changes.  That being said,
> I'm aware
>> WLM is changed frequently and without broadcast notification.
>> 
>> This appears from time to time.  I am new here (couple of months) so
> cannot
>> determine how long its been happening - could be months, could be years.
>> 
>> I need to understand the interworkings of prism, WLM, and the LPARs, and
> from the
>> postings today, more about soft and hard capping.
>> 
>> All input is appreciated.  I have a learning curve in this area, so
> telling me to look for
>> something in RMF is welcome, along with any display commands where I can
> see
>> the caps.  I have Mainview.
>> 
>> Sent from my iPhone
>> 
>> On Dec 17, 2014, at 8:35 AM, Lizette Koehler 
>> wrote:
>> 
>>> I would ask first, how do  you know it is affecting the Prod LPAR.
>>> 
>>> What evidence, RMF Reports, Performance monitors, etc. ?
>>> 
>>> There should be, I think, so data that could explicitly show that is
>>> what is happening.
>>> 
>>> Is it all the time, some of the time?  Is it a specific time when the
>>> prod LPAR is affected?  How long has it been going on?  Is there a
>>> point in time when this started?  If so, what changes occurred at that
> point?
>>> 
>>> Lizette
>>> 
>>> 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of L Hagedorn
 Sent: Wednesday, December 17, 2014 5:44 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: MIPS, CEC, LPARs, PRISM, WLM
 
 Hi IBM-MAIN,
 
 We have a situation with multiple LPARS on a CEC, running DB2 asids
 prod,
>>> test,
 dev.
 
 It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU
 and stealing MIPS from the PROD LPAR and affecting production.
 
 Others claim this is not possible due to Prism.
 
 Will someone provide an overview of how Prism influences or controls
 MIPS
>>> usage
 (CPU) across LPARs sharing the same CEC, what are the limiting or
>>> controlling
 factors (if any), and how can the behavior be measured or reported
 upon so
>>> I can
 explain this with supporting doc?   Does WLM play a part in sharing CPU
>>> across
 LPARs?
 
 Any information or referrals to doc is appreciated.
 
 Thanks, Linda
> 
> --
> 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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
In pretty good with DB2, and Craig is wonderful.  

It's the intricacies of MVS performance I need to bring in focus.  I have a lot 
of reading and research to do so I can collect appropriate doc the next time 
one of these hits.  

Linda 
Sent from my iPhone

On Dec 17, 2014, at 2:34 PM, Ed Finnell 
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Craig Mullin's DB/2 books are really educational in scope and insight(and  
> heavy). Fundamental understanding of the interoperation is key to 
> identifying  and tuning  problems. He was with Platinum  when he first began 
> the  
> series and moved on after the acquisition by CA.(He and other vendors were
> presenting at our ADUG conference on 9/11/01. Haven't seen him since but  
> still get the updates.)
> 
> The CA tools are really good at pinpointing problems. Detector and Log  
> Analyzer are key. For SQL there's the SQL analyzer(priced) component. 
> Sometimes 
> if it's third party software there may be a known issues with certain  
> transactions or areas of interactions.
> 
> For continual knowledge _www.share.org_ (http://www.share.org)  is a good 
> source. Developers  and installations give current and timely advice on 
> fitting metrics to machines.  The proceedings for the last three Events are 
> kept 
> online
> without signup. The new RMF stuff for EC12 and Flash drives is pretty  
> awesome. 
> 
> 
> In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time,  
> linda.haged...@gmail.com writes:
> 
> I lurk  on IBM-Main, and I'm always awed by the knowledge here.   
> 
> 
> 
> --
> 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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Doug Henry
On Wed, 17 Dec 2014 11:08:31 -0500, L Hagedorn  wrote:

>MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting 
>LPAR B.  I didn't ask them for doc, but will next time.  
>
>All input is appreciated.  I have a learning curve in this area, so telling me 
>to look for something in RMF is welcome, along with any display commands where 
>I can see the caps.  I have Mainview. 

In Mainview put LPARTOTZ on the command line and it shows for each partition 
the weight, relative shr, share used in interval and long term.

In RMF III the 1.3 CPC "CPC Capacity" also shows this kind of information.

Doug

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Ed Finnell
Craig Mullin's DB/2 books are really educational in scope and insight(and  
heavy). Fundamental understanding of the interoperation is key to 
identifying  and tuning  problems. He was with Platinum  when he first began 
the  
series and moved on after the acquisition by CA.(He and other vendors were
presenting at our ADUG conference on 9/11/01. Haven't seen him since but  
still get the updates.)
 
The CA tools are really good at pinpointing problems. Detector and Log  
Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes 
 if it's third party software there may be a known issues with certain  
transactions or areas of interactions.
 
For continual knowledge _www.share.org_ (http://www.share.org)  is a good 
source. Developers  and installations give current and timely advice on 
fitting metrics to machines.  The proceedings for the last three Events are 
kept 
online
without signup. The new RMF stuff for EC12 and Flash drives is pretty  
awesome. 
 
 
In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time,  
linda.haged...@gmail.com writes:

I lurk  on IBM-Main, and I'm always awed by the knowledge here.   



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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-17 Thread Peter Relson
>we've run into health checks that are not compatible 
>with what we believe are reasonable settings

Whenever any HC creator interacts with the HC team it is always suggested 
to them that they provide a parameter by which the customer can indicate 
the value to check for, because even though something might be recommended 
it might not meet the business needs of some customers, and those 
customers want a way to indicate "check for the state I need, to help make 
sure that no one accidentally changes it even to the state that would 
normally be recommended".

For those sort of cases, we really want customers to "tune" the check, not 
deactivate/delete it.

For example, the GRS mode check can be tuned to check for STAR or RING.

If the checks that you refer to do not have such parameterization, 
requesting it would be a great first step.

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: Trouble with IARV64 GETCOMMON

2014-12-17 Thread Peter Relson
I suspect that access to some common storage areas via IPCS ACTIVE 
requires RACF authorization (as does access to other address space's 
storage). 

That's not to say that it couldn't have been implemented differently for 
this case to need no such authorization and instead just to pay attention 
to the TCB key.

(This is just a guess; I do not know how IPCS ACTIVE is implemented for 
common storage above 2G, let alone common storage below 2G).

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: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Charles Mills
I figured that // generally introduces a new line of JCL. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Wednesday, December 17, 2014 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

> THAT IS AWESOME! Wow! Thanks,

You're welcome.




I recognize from seeming my onw post that it has been reformatted in a bad
way. A couple of line feeds have been dropped. Hope you can decifer the
samples anyway. If not, tell me and I will try reposting them.


--


Peter Hunkeler



--
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: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Charles Mills
Fortunately this particular problem is internal use only and so V2R1-only is a 
minor issue only.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Wednesday, December 17, 2014 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IKJ56500I COMMAND OPUTX NOT FOUND

Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions 
also …so one has to come up with two solutions …

ith 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: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Scott Ford
Gil:


That was what I was trying to say and didn't do it very well. Love the new JCL 
changes is Z/OS 2.1






Scott





From: Paul Gilmartin
Sent: ‎Wednesday‎, ‎December‎ ‎17‎, ‎2014 ‎11‎:‎43‎ ‎AM
To: IBM-MAIN@LISTSERV.UA.EDU





On 2014-12-17, at 09:31, Scott Ford wrote:

> Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions 
> also …so one has to come up with two solutions …
>  
No, you need to come up with only the solution for the backlevel
version, then rely on upward compatibility.  (But it may be
suboptimal.)

It's a design blunder that STDPARM is mutex with EXEC PARM= rather
than being appended.  If it had been appended the programmer might
assign a few variables in the EXEC PARM= using JCL symbol values,
then exploit them in the script in STDPARM.

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Jerry Whitteridge
Linda

This may just be as simple as the Prod LPAR normally uses more than its defined 
weight and Ops/Users have become used to that level of throughput. When the Dev 
LPAR starts using  more CPU and the box goes to 100% busy the weights are 
enforced. This may drive the Prod LPAR to a smaller share of the box than 
normal, and you get complaints.

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of L Hagedorn
Sent: Wednesday, December 17, 2014 4:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MIPS, CEC, LPARs, PRISM, WLM

Hi IBM-MAIN,

We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, 
dev.  

It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
stealing MIPS from the PROD LPAR and affecting production.  

Others claim this is not possible due to Prism.  

Will someone provide an overview of how Prism influences or controls MIPS usage 
(CPU) across LPARs sharing the same CEC, what are the limiting or controlling 
factors (if any), and how can the behavior be measured or reported upon so I 
can explain this with supporting doc?   Does WLM play a part in sharing CPU 
across LPARs?

Any information or referrals to doc is appreciated.  

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


"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Lizette Koehler
How is the dasd handled? Is it separate between Prd and other LPARs?  Or do
you share your dasd.

In other words any LPAR can see any dasd for any other LPAR or is it PRD
dasd is only on prd and not accessible by the other LPARS?

How does Operation identify the issue?  Are they looking at an alert? Or  a
Monitor (Tivoli Omegamon, other?) 

How is the network during this time?  Is connectivity optimal or slowed
down?



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of L Hagedorn
> Sent: Wednesday, December 17, 2014 9:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
> 
> MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting
> LPAR B.  I didn't ask them for doc, but will next time.
> 
> This is a runtime issue, unrelated to reported changes.  That being said,
I'm aware
> WLM is changed frequently and without broadcast notification.
> 
> This appears from time to time.  I am new here (couple of months) so
cannot
> determine how long its been happening - could be months, could be years.
> 
> I need to understand the interworkings of prism, WLM, and the LPARs, and
from the
> postings today, more about soft and hard capping.
> 
> All input is appreciated.  I have a learning curve in this area, so
telling me to look for
> something in RMF is welcome, along with any display commands where I can
see
> the caps.  I have Mainview.
> 
> Sent from my iPhone
> 
> On Dec 17, 2014, at 8:35 AM, Lizette Koehler 
> wrote:
> 
> > I would ask first, how do  you know it is affecting the Prod LPAR.
> >
> > What evidence, RMF Reports, Performance monitors, etc. ?
> >
> > There should be, I think, so data that could explicitly show that is
> > what is happening.
> >
> > Is it all the time, some of the time?  Is it a specific time when the
> > prod LPAR is affected?  How long has it been going on?  Is there a
> > point in time when this started?  If so, what changes occurred at that
point?
> >
> > Lizette
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >> On Behalf Of L Hagedorn
> >> Sent: Wednesday, December 17, 2014 5:44 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: MIPS, CEC, LPARs, PRISM, WLM
> >>
> >> Hi IBM-MAIN,
> >>
> >> We have a situation with multiple LPARS on a CEC, running DB2 asids
> >> prod,
> > test,
> >> dev.
> >>
> >> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU
> >> and stealing MIPS from the PROD LPAR and affecting production.
> >>
> >> Others claim this is not possible due to Prism.
> >>
> >> Will someone provide an overview of how Prism influences or controls
> >> MIPS
> > usage
> >> (CPU) across LPARs sharing the same CEC, what are the limiting or
> > controlling
> >> factors (if any), and how can the behavior be measured or reported
> >> upon so
> > I can
> >> explain this with supporting doc?   Does WLM play a part in sharing CPU
> > across
> >> LPARs?
> >>
> >> Any information or referrals to doc is appreciated.
> >>
> >> Thanks, Linda
> >

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Lizette Koehler
You might also want to join the DB2 List.  Go to IDUG.ORG to join, it is
free.

There you can ask about the DIST and how it might impact other LPARs.,

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of L Hagedorn
> Sent: Wednesday, December 17, 2014 10:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
> 
> Thank you.
> 
> Sent from my iPhone
> 
> On Dec 17, 2014, at 11:36 AM, Ted MacNEIL  wrote:
> 
> > PR/SM (LPAR) doesn't know PROD from TEST.
> > It only knows weight.
> > If you have set it up for LPAR to have 80% and LPARB to have 20%, that's
what
> they get in times of contention. No more, no less.
> > 20% is one's allotment so it's okay. 85% is above the allotment so it's
scaled back
> to 80%.
> > This is how it's always worked.
> >
> >
> > -
> > -teD
> > -
> >   Original Message
> > From: L Hagedorn
> > Sent: Wednesday, December 17, 2014 11:15
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Reply To: IBM Mainframe Discussion List
> > Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
> >
> > Thank you for the extensive information and examples.
> >
> > I will be hitting the books.
> >
> > Can you expand on this example:
> >
> > If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20%
and
> LPARA will be squeezed to 80%.
> >
> > It seems counter intuitive to me and I'd like to understand. Lets say
LPARA is prod
> - they should get most of the resources. Why would LPARA be squeezed
instead of
> LPARB?
> >
> > Sent from my iPhone
> >
> > On Dec 17, 2014, at 9:07 AM, "Staller, Allan" 
> wrote:
> >
> >> The answer is, "it depends".
> >>
> >> First, there is no "priority" across LPARS. All LPARS are dispatched
"equally"
> according to the LPAR weights.
> >>
> >> For example, if LPARA is weighted are 80 and LPARB is weighted at 20,
the
> following occurs:
> >>
> >> If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy
> and goes on their merry way.
> >>
> >> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20%
> and LPARA will be squeezed to 80%.
> >>
> >> If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy
> and goes on their merry way.
> >>
> >> The LPARA weight represents a "guaranteed minimum" proportion (note:
> >> LPAR weights need not total to 100. The proportion is relative.)
> >>
> >> All of the above occurs when capping (either hard or soft) is not
present.
> >>
> >> Software capping can occur with resource groups.
> >> Hardware capping can occur with group capacity limits.
> >>
> >> This is a complex subject and much more than can be covered in a short
e-mail.
> >>
> >> If you have not already done so, I suggest you obtain a copy of and
read the
> PR/SM Planning Guide. The most recent version I can find is SB10-7155-01
and is
> located here:
> >> https://www-
> 304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570
> &aid=1 (watch the wrap).
> >>
> >> RMF Monitor I (batch) has an excellent CPU report. This will also
> >> include the "PARTITION DATA REPORT". I will refer you to the fine
> >> manuals for details/
> >>
> >> WLM *may* reach across LPAR Boundaries. If fact, it is designed to do
this.
> However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a
factor.
> >>
> >> As others have pointed out, what evidence is there that the "runaway"
task is
> affecting "production" (factual, not conjecture!)?
> >>
> >> HTH,
> >>
> >> 
> >> We have a situation with multiple LPARS on a CEC, running DB2 asids
prod,
> test, dev.
> >>
> >> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU
and
> stealing MIPS from the PROD LPAR and affecting production.
> >>
> >> Others claim this is not possible due to Prism.
> >>
> >> Will someone provide an overview of how Prism influences or controls
MIPS
> usage (CPU) across LPARs sharing the same CEC, what are the limiting or
> controlling factors (if any), and how can the behavior be measured or
reported upon
> so I can explain this with supporting doc? Does WLM play a part in sharing
CPU
> across LPARs?
> >> 

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Staller, Allan
Any LPAR can exceed their proportion if there is available resource. 
If there is insufficient resource, LPARS will be forced to their proportion, as 
defined by the LPAR weights (unless another LPAR is not consuming "its share").

Remember, PR/SM does not know LPARA is "production" and should be favored. It 
just knows LPARA is assigned weight x.

For example there is  CEC with LPARS(weights)  LPARA(60%) LPARB(20%) and 
LPARC(20%).
If all LPARS demand their weight, the CPU will be distributed according to the 
weights defined (barring soft/hard capping).

Now, assume LPARC only wants 5%.

LPARA and LPARB can now consume the 15% that LPARC does not want.

In the example from my previous post, the total demand is 105%. 
LPARB has a defined weight of 20% and is guaranteed this value.
LPARA is guaranteed its weight of 80%. (total of 100).
The additional 5% exceeds the available capacity and will be presented as 
"latent demand".

IF LPARB were to drop to only requiring 10%, LPAR would then be allowed to 
exceed the defined proportion because the total demand is now 90%.

There are man7y "tricks of the trade" to "cap" the non-production LPARs. The 
only question is the granularity appropriate.

Another good source would be the CMG archives (www.cmg.org) and Cheryl Watsons 
Tuning Letters.

Hopefully, Cheryl will spot this thread and chime in.

HTH,



Can you expand on this example:  

 If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
LPARA will be squeezed to 80%.

It seems counter intuitive to me and I'd like to understand.  Lets say LPARA is 
prod - they should get most of the resources.   Why would LPARA be squeezed 
instead of LPARB? 


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


Re: ftp rdw

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 10:33:18 -0600, Paul Gilmartin wrote:

>On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote:
>
>z/OS Communications Server: IP User's Guide and Commands
>SC27-3662-00 
>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/site.htm
>z/OS V2R1>z/OS Communications Server>z/OS Communications Server: IP User's 
>Guide and Commands>FTP subcommands>SIte subcommand-Send site-specific 
>information to a host
>
>I find:
>length
>Specifies the logical record length of a newly allocated data set. The 
> valid range is
>0—32760. A special value of x (LRecl=x) is also supported to indicate that 
> a logical
>record length can exceed 32760 for variable-length spanned records. 
>
>So apparently FTP supports transfer of RECFM=VBS,LRECL=X.  I'll need to try
>it.  And maybe submit an RCF requesting an example.
> 
OK.  I tried it:

put unloaded unld3
SITE VARrecfm LRECL=6016 RECFM=VS BLKSIZE=6020 
200 SITE command was accepted
PORT 10,80,63,53,166,91 
200 Port request OK.
STOR unld3 
125 Storing data set User.TEMP.UNLD3
250 Transfer completed successfully.
332072 bytes transferred in 0.040 seconds.  Transfer rate 8301.80 Kbytes/sec.
Command:
get unld3 unld4
PORT 10,80,63,53,166,92 
200 Port request OK.
RETR unld3 
125 Sending data set User.TEMP.UNLD3
250 Transfer completed successfully.
331947 bytes transferred in 0.040 seconds.  Transfer rate 8298.67 Kbytes/sec.
Data was truncated.
Command:

PUT works better than get, probably because of SENDSITE.  Is there
a reverse SENDSITE?  Something that would extract the characteristics
of a file and issue a LOCSITE?  (I could copy and paste into LOCSITE.

-- gil

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
Thank you. 

Sent from my iPhone

On Dec 17, 2014, at 11:36 AM, Ted MacNEIL  wrote:

> PR/SM (LPAR) doesn't know PROD from TEST.
> It only knows weight.
> If you have set it up for LPAR to have 80% and LPARB to have 20%, that's what 
> they get in times of contention. No more, no less.
> 20% is one's allotment so it's okay. 85% is above the allotment so it's 
> scaled back to 80%.
> This is how it's always worked.
> 
> 
> -
> -teD
> -
>   Original Message  
> From: L Hagedorn
> Sent: Wednesday, December 17, 2014 11:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
> 
> Thank you for the extensive information and examples. 
> 
> I will be hitting the books. 
> 
> Can you expand on this example: 
> 
> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
> LPARA will be squeezed to 80%.
> 
> It seems counter intuitive to me and I'd like to understand. Lets say LPARA 
> is prod - they should get most of the resources. Why would LPARA be squeezed 
> instead of LPARB? 
> 
> Sent from my iPhone
> 
> On Dec 17, 2014, at 9:07 AM, "Staller, Allan"  wrote:
> 
>> The answer is, "it depends".
>> 
>> First, there is no "priority" across LPARS. All LPARS are dispatched 
>> "equally" according to the LPAR weights. 
>> 
>> For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the 
>> following occurs:
>> 
>> If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and 
>> goes on their merry way.
>> 
>> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
>> LPARA will be squeezed to 80%.
>> 
>> If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and 
>> goes on their merry way.
>> 
>> The LPARA weight represents a "guaranteed minimum" proportion (note: LPAR 
>> weights need not total to 100. The proportion is relative.)
>> 
>> All of the above occurs when capping (either hard or soft) is not present.
>> 
>> Software capping can occur with resource groups.
>> Hardware capping can occur with group capacity limits.
>> 
>> This is a complex subject and much more than can be covered in a short 
>> e-mail. 
>> 
>> If you have not already done so, I suggest you obtain a copy of and read the 
>> PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and 
>> is located here:
>> https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1
>>  (watch the wrap).
>> 
>> RMF Monitor I (batch) has an excellent CPU report. This will also include 
>> the "PARTITION DATA REPORT". I will refer you to the fine manuals for 
>> details/
>> 
>> WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. 
>> However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor.
>> 
>> As others have pointed out, what evidence is there that the "runaway" task 
>> is affecting "production" (factual, not conjecture!)?
>> 
>> HTH,
>> 
>> 
>> We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
>> test, dev. 
>> 
>> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
>> stealing MIPS from the PROD LPAR and affecting production. 
>> 
>> Others claim this is not possible due to Prism. 
>> 
>> Will someone provide an overview of how Prism influences or controls MIPS 
>> usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
>> controlling factors (if any), and how can the behavior be measured or 
>> reported upon so I can explain this with supporting doc? Does WLM play a 
>> part in sharing CPU across LPARs?
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
I lurk on IBM-Main, and I'm always awed by the knowledge here.  

You are treasure.  

Sent from my iPhone

On Dec 17, 2014, at 10:02 AM, Martin Packer  wrote:

> I don't see the DIST ADDRESS SPACE going runaway. What is feasible is DDF 
> work - separately WLM classified as it should be - taking a big chunk of 
> CPU. (And that work runs IN the DIST address space but hopefully not at 
> its dispatching priority.) DIST address space itself going rogue would 
> sound like a bug.
> 
> Lots of things determine whether this would lead to a separate Production 
> LPAR being impacted, most notably whether Prod LPAR is above its share (as 
> determined by weights). With DDF work this could affect either the GCP 
> pool or the zIIP pool.
> 
> There ARE interactions between WLM and PR/SM but generally not. Such 
> interactions include if IRD Weight Management is active.
> 
> And I see you already have several other answers - so it looks like you 
> came to the right place. :-)
> 
> Cheers, Martin
> 
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Banking Center of Excellence, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> Blog: 
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> 
> 
> From:   L Hagedorn 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   17/12/2014 12:54
> Subject:MIPS, CEC, LPARs, PRISM, WLM
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Hi IBM-MAIN,
> 
> We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
> test, dev. 
> 
> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
> stealing MIPS from the PROD LPAR and affecting production. 
> 
> Others claim this is not possible due to Prism. 
> 
> Will someone provide an overview of how Prism influences or controls MIPS 
> usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
> controlling factors (if any), and how can the behavior be measured or 
> reported upon so I can explain this with supporting doc?   Does WLM play a 
> part in sharing CPU across LPARs?
> 
> Any information or referrals to doc is appreciated. 
> 
> Thanks, Linda 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Suggestion for the ICETOOL SUBSET operator

2014-12-17 Thread Thomas Berg
Using the ICETTOOL SUBSET operator I missed a position subselection option for 
the FIRST/LAST/RRN parms. 
I can of course use other DFSORT operators for this purpose, but felt that this 
possibility would fit well in the SUBSET function.

Example: 

RRN(3,12,(31:22,71:10))or   RRN(3,12,31:22,71:10)  

Here only the parts from position 31, length 22, and position 71, length 10, is 
selected for the  
output record.  (The record will contain selected parts concatenated from pos 
1, length 32.)   

Padding spec may also be added.



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
Sent from my iPhone

On Dec 17, 2014, at 8:26 AM, Elardus Engelbrecht 
 wrote:

> Linda Hagedorn wrote:
> 
>> We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
>> test, dev.  
> 
> What z/OS levels? What levels of DB2 on all those LPARS?

Z is 2.1.  DB2s are V10 Put1308

> 
>> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
>> stealing MIPS from the PROD LPAR and affecting production.  
> 
> Based on what were those claims made? I would like to see for example, RMF or 
> SMF data/reports or some other tools used to prove that claims.
> 
> Are you having response time problems?

Operations is reporting the situation.  I can confirm the presence of bad SQL 
in the dev system, and the operations say things return to normal after its 
cancelled.  Again, I don't have doc to indicate normal, so I'll ask that also.  

My questions are to understand how LPARA is causing a problem in LPARB.  
Operations management says this true, but the sysprog says it can't happen.  

Doc will be requested next time.  Any particular advice on what should be asked 
is appreciated.  I'll ask what they see, screen shots, source, etc.  

Thank you.  Linda 


>> Others claim this is not possible due to Prism.  
>> Will someone provide an overview of how Prism influences or controls MIPS 
>> usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
>> controlling factors (if any), and how can the behavior be measured or 
>> reported upon so I can explain this with supporting doc?   Does WLM play a 
>> part in sharing CPU across LPARs?
> 
> Are your LPARS hard or soft capped? What are the CPU and MSU allocations to 
> your LPARS?

I don't know.  Is there a display command that would show the status and 
limits? 


>> Any information or referrals to doc is appreciated.  
> 
> I'll leave that to the real performance gurus on IBM-MAIN. 
> 
> 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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Martin Packer
Sounds like you also need to familiarise yourself with how DIST works - 
meaning enclaves that run the actual DDF SQL. As I say, unlikely DIST 
itself but rather more likely the DDF is "in play".

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

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



From:   L Hagedorn 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   17/12/2014 16:08
Subject:Re: MIPS, CEC, LPARs, PRISM, WLM
Sent by:IBM Mainframe Discussion List 



MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting 
LPAR B.  I didn't ask them for doc, but will next time. 

This is a runtime issue, unrelated to reported changes.  That being said, 
I'm aware WLM is changed frequently and without broadcast notification.

This appears from time to time.  I am new here (couple of months) so 
cannot determine how long its been happening - could be months, could be 
years. 

I need to understand the interworkings of prism, WLM, and the LPARs, and 
from the postings today, more about soft and hard capping. 

All input is appreciated.  I have a learning curve in this area, so 
telling me to look for something in RMF is welcome, along with any display 
commands where I can see the caps.  I have Mainview. 

Sent from my iPhone

On Dec 17, 2014, at 8:35 AM, Lizette Koehler  
wrote:

> I would ask first, how do  you know it is affecting the Prod LPAR.
> 
> What evidence, RMF Reports, Performance monitors, etc. ?
> 
> There should be, I think, so data that could explicitly show that is 
what is
> happening.
> 
> Is it all the time, some of the time?  Is it a specific time when the 
prod
> LPAR is affected?  How long has it been going on?  Is there a point in 
time
> when this started?  If so, what changes occurred at that point?
> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On
>> Behalf Of L Hagedorn
>> Sent: Wednesday, December 17, 2014 5:44 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: MIPS, CEC, LPARs, PRISM, WLM
>> 
>> Hi IBM-MAIN,
>> 
>> We have a situation with multiple LPARS on a CEC, running DB2 asids 
prod,
> test,
>> dev.
>> 
>> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU 
and
>> stealing MIPS from the PROD LPAR and affecting production.
>> 
>> Others claim this is not possible due to Prism.
>> 
>> Will someone provide an overview of how Prism influences or controls 
MIPS
> usage
>> (CPU) across LPARs sharing the same CEC, what are the limiting or
> controlling
>> factors (if any), and how can the behavior be measured or reported upon 
so
> I can
>> explain this with supporting doc?   Does WLM play a part in sharing CPU
> across
>> LPARs?
>> 
>> Any information or referrals to doc is appreciated.
>> 
>> Thanks, Linda
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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



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

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Mark Pace
You may ask IBM or your Business Partner to do a CP3000 study.  This can
uncover issues with WLM.

On Wed, Dec 17, 2014 at 11:36 AM, Ted MacNEIL  wrote:
>
> PR/SM (LPAR) doesn't know PROD from TEST.
> It only knows weight.
> If you have set it up for LPAR to have 80% and LPARB to have 20%, that's
> what they get in times of contention. No more, no less.
> 20% is one's allotment so it's okay. 85% is above the allotment so it's
> scaled back to 80%.
> This is how it's always worked.
>
>
> -
> -teD
> -
>   Original Message
> From: L Hagedorn
> Sent: Wednesday, December 17, 2014 11:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: MIPS, CEC, LPARs, PRISM, WLM
>
> Thank you for the extensive information and examples.
>
> I will be hitting the books.
>
> Can you expand on this example:
>
> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and
> LPARA will be squeezed to 80%.
>
> It seems counter intuitive to me and I'd like to understand. Lets say
> LPARA is prod - they should get most of the resources. Why would LPARA be
> squeezed instead of LPARB?
>
> Sent from my iPhone
>
> On Dec 17, 2014, at 9:07 AM, "Staller, Allan" 
> wrote:
>
> > The answer is, "it depends".
> >
> > First, there is no "priority" across LPARS. All LPARS are dispatched
> "equally" according to the LPAR weights.
> >
> > For example, if LPARA is weighted are 80 and LPARB is weighted at 20,
> the following occurs:
> >
> > If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy
> and goes on their merry way.
> >
> > If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20%
> and LPARA will be squeezed to 80%.
> >
> > If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy
> and goes on their merry way.
> >
> > The LPARA weight represents a "guaranteed minimum" proportion (note:
> LPAR weights need not total to 100. The proportion is relative.)
> >
> > All of the above occurs when capping (either hard or soft) is not
> present.
> >
> > Software capping can occur with resource groups.
> > Hardware capping can occur with group capacity limits.
> >
> > This is a complex subject and much more than can be covered in a short
> e-mail.
> >
> > If you have not already done so, I suggest you obtain a copy of and read
> the PR/SM Planning Guide. The most recent version I can find is
> SB10-7155-01 and is located here:
> >
> https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1
> (watch the wrap).
> >
> > RMF Monitor I (batch) has an excellent CPU report. This will also
> include the "PARTITION DATA REPORT". I will refer you to the fine manuals
> for details/
> >
> > WLM *may* reach across LPAR Boundaries. If fact, it is designed to do
> this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a
> factor.
> >
> > As others have pointed out, what evidence is there that the "runaway"
> task is affecting "production" (factual, not conjecture!)?
> >
> > HTH,
> >
> > 
> > We have a situation with multiple LPARS on a CEC, running DB2 asids
> prod, test, dev.
> >
> > It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU
> and stealing MIPS from the PROD LPAR and affecting production.
> >
> > Others claim this is not possible due to Prism.
> >
> > Will someone provide an overview of how Prism influences or controls
> MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting
> or controlling factors (if any), and how can the behavior be measured or
> reported upon so I can explain this with supporting doc? Does WLM play a
> part in sharing CPU across LPARs?
> > 
> >
> > --
> > 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
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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


Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Paul Gilmartin
On 2014-12-17, at 09:31, Scott Ford wrote:

> Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions 
> also …so one has to come up with two solutions …
>  
No, you need to come up with only the solution for the backlevel
version, then rely on upward compatibility.  (But it may be
suboptimal.)

It's a design blunder that STDPARM is mutex with EXEC PARM= rather
than being appended.  If it had been appended the programmer might
assign a few variables in the EXEC PARM= using JCL symbol values,
then exploit them in the script in STDPARM.

-- gil

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Ted MacNEIL
PR/SM (LPAR) doesn't know PROD from TEST.
It only knows weight.
If you have set it up for LPAR to have 80% and LPARB to have 20%, that's what 
they get in times of contention. No more, no less.
20% is one's allotment so it's okay. 85% is above the allotment so it's scaled 
back to 80%.
This is how it's always worked.


-
-teD
-
  Original Message  
From: L Hagedorn
Sent: Wednesday, December 17, 2014 11:15
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: MIPS, CEC, LPARs, PRISM, WLM

Thank you for the extensive information and examples. 

I will be hitting the books. 

Can you expand on this example: 

If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA 
will be squeezed to 80%.

It seems counter intuitive to me and I'd like to understand. Lets say LPARA is 
prod - they should get most of the resources. Why would LPARA be squeezed 
instead of LPARB? 

Sent from my iPhone

On Dec 17, 2014, at 9:07 AM, "Staller, Allan"  wrote:

> The answer is, "it depends".
> 
> First, there is no "priority" across LPARS. All LPARS are dispatched 
> "equally" according to the LPAR weights. 
> 
> For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the 
> following occurs:
> 
> If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and 
> goes on their merry way.
> 
> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
> LPARA will be squeezed to 80%.
> 
> If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and 
> goes on their merry way.
> 
> The LPARA weight represents a "guaranteed minimum" proportion (note: LPAR 
> weights need not total to 100. The proportion is relative.)
> 
> All of the above occurs when capping (either hard or soft) is not present.
> 
> Software capping can occur with resource groups.
> Hardware capping can occur with group capacity limits.
> 
> This is a complex subject and much more than can be covered in a short 
> e-mail. 
> 
> If you have not already done so, I suggest you obtain a copy of and read the 
> PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and 
> is located here:
> https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1
>  (watch the wrap).
> 
> RMF Monitor I (batch) has an excellent CPU report. This will also include the 
> "PARTITION DATA REPORT". I will refer you to the fine manuals for details/
> 
> WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. 
> However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor.
> 
> As others have pointed out, what evidence is there that the "runaway" task is 
> affecting "production" (factual, not conjecture!)?
> 
> HTH,
> 
> 
> We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
> test, dev. 
> 
> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
> stealing MIPS from the PROD LPAR and affecting production. 
> 
> Others claim this is not possible due to Prism. 
> 
> Will someone provide an overview of how Prism influences or controls MIPS 
> usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
> controlling factors (if any), and how can the behavior be measured or 
> reported upon so I can explain this with supporting doc? Does WLM play a part 
> in sharing CPU across LPARs?
> 
> 
> --
> 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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Martin Packer
I don't see the DIST ADDRESS SPACE going runaway. What is feasible is DDF 
work - separately WLM classified as it should be - taking a big chunk of 
CPU. (And that work runs IN the DIST address space but hopefully not at 
its dispatching priority.) DIST address space itself going rogue would 
sound like a bug.

Lots of things determine whether this would lead to a separate Production 
LPAR being impacted, most notably whether Prod LPAR is above its share (as 
determined by weights). With DDF work this could affect either the GCP 
pool or the zIIP pool.

There ARE interactions between WLM and PR/SM but generally not. Such 
interactions include if IRD Weight Management is active.

And I see you already have several other answers - so it looks like you 
came to the right place. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

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



From:   L Hagedorn 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   17/12/2014 12:54
Subject:MIPS, CEC, LPARs, PRISM, WLM
Sent by:IBM Mainframe Discussion List 



Hi IBM-MAIN,

We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
test, dev. 

It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
stealing MIPS from the PROD LPAR and affecting production. 

Others claim this is not possible due to Prism. 

Will someone provide an overview of how Prism influences or controls MIPS 
usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
controlling factors (if any), and how can the behavior be measured or 
reported upon so I can explain this with supporting doc?   Does WLM play a 
part in sharing CPU across LPARs?

Any information or referrals to doc is appreciated. 

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



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

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


Re: ftp rdw

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote:

>Yes, you can do it yourself.
>https://www.ibm.com/developerworks/rfe
> 
In the description of the FTP SITE subcommand in:

z/OS Communications Server: IP User's Guide and Commands
SC27-3662-00 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/site.htm
z/OS V2R1>z/OS Communications Server>z/OS Communications Server: IP User's 
Guide and Commands>FTP subcommands>SIte subcommand-Send site-specific 
information to a host

I find:
length
Specifies the logical record length of a newly allocated data set. The 
valid range is
0—32760. A special value of x (LRecl=x) is also supported to indicate that 
a logical
record length can exceed 32760 for variable-length spanned records. 

So apparently FTP supports transfer of RECFM=VBS,LRECL=X.  I'll need to try
it.  And maybe submit an RCF requesting an example.

IBM's implementation of FTP is horrendously complicated.  Kinda like z/OS
data management.

-- gil

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


Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Scott Ford
Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions 
also …so one has to come up with two solutions …


Regards,

Scott





From: Charles Mills
Sent: ‎Wednesday‎, ‎December‎ ‎17‎, ‎2014 ‎10‎:‎17‎ ‎AM
To: IBM-MAIN@LISTSERV.UA.EDU





THAT IS AWESOME! Wow! Thanks,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Wednesday, December 17, 2014 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX
commands. Here are two JCL's I'm using to run UNIX commands in batch:
//  EXPORT SYMLIST=*//  SET  DIR='newdir'//UNIXCMDS   EXEC
PGM=BPXBATCH
//STDINDD  DUMMY
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*
//SYMRESDD DD  SYSOUT=*
//STDPARM  DD  *,SYMBOLS=(JCLONLY)
SH
  cd /some/directory ;
  ls -l ;  mkdir -m 700  &DIR./*

Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them.
You start with the usual "SH" to tell BPXBATCH to run a shell. All the rest
of STDPARM is input to that shell, so you need to adhere to shell command
line syntax. Chain multiple commands with the ";". Note also that you must
not try to insert comment, because the first # will start a comment that
goes to the end of STDPARM.
Advantage: You can user JCL symbols (and if your jobclass allows it, also
system symbols) in the UNIX commands.


The second job is solving the problem of running commands via "su" in batch.
Its not perfect, but mostly does the trick for me. First, there is a JCL
procedure:


//BPXSU   PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job' 
//INPUT   EXEC PGM=IEBGENER   
//SYSPRINT  DD DUMMY 
//SYSIN DD DUMMY 
//SYSUT1DD DDNAME=COMMANDS   
//SYSUT2DD PATH='/tmp/&SYSUID-&TMP', 
// PATHDISP=(KEEP,DELETE),   
// PATHOPTS=(OWRONLY,OCREAT,OEXCL),   
// PATHMODE=(SIRUSR,SIWUSR)   
//EXECUSS EXEC PGM=BPXBATCH,PARM='SH su' 
//STDOUTDD SYSOUT=&SOUT. 
//STDERRDD SYSOUT=&SOUT. 
//STDIN DD PATH='/tmp/&SYSUID-&TMP', 
// PATHDISP=(DELETE,DELETE)   
//STDPARM   DD DUMMY 

Second, here is how to use it:
//  EXPORT SYMLIST=*//  SET
FILE='somefile'//UNIXCMDS EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l
; chown foo:bar &FILE./*

The rules for COMMANDS are similar to the above. Note that this is STDIN,
not STDPARM, so the "SH" is not need.
Also, fi system symbols are allowed, the you can make the temp file name
more unique using date, time or other system symbols.

--
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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
Thank you for the extensive information and examples.  

I will be hitting the books.  

Can you expand on this example:  

 If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
LPARA will be squeezed to 80%.

It seems counter intuitive to me and I'd like to understand.  Lets say LPARA is 
prod - they should get most of the resources.   Why would LPARA be squeezed 
instead of LPARB? 

Sent from my iPhone

On Dec 17, 2014, at 9:07 AM, "Staller, Allan"  wrote:

> The answer is, "it depends".
> 
> First, there is no "priority" across LPARS. All LPARS are dispatched 
> "equally" according to the LPAR weights.  
> 
> For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the 
> following occurs:
> 
> If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and 
> goes on their merry way.
> 
> If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and 
> LPARA will be squeezed to 80%.
> 
> If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and 
> goes on their merry way.
> 
> The LPARA weight represents a "guaranteed minimum" proportion (note: LPAR 
> weights need not total to 100. The proportion is relative.)
> 
> All of the above occurs when capping (either hard or soft) is not present.
> 
> Software capping can occur with resource groups.
> Hardware capping can occur with group capacity limits.
> 
> This is a complex subject and much more than can be covered in a short 
> e-mail. 
> 
> If you have not already done so, I suggest you obtain a copy of and read the 
> PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and 
> is located here:
> https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1
>  (watch the wrap).
> 
> RMF Monitor I (batch) has an excellent CPU report. This will also include the 
> "PARTITION DATA REPORT". I will refer you to the fine manuals for details/
> 
> WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. 
> However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor.
> 
> As others have pointed out, what evidence is there that the "runaway" task is 
> affecting "production"  (factual, not conjecture!)?
> 
> HTH,
> 
> 
> We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
> test, dev.  
> 
> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
> stealing MIPS from the PROD LPAR and affecting production.  
> 
> Others claim this is not possible due to Prism.  
> 
> Will someone provide an overview of how Prism influences or controls MIPS 
> usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
> controlling factors (if any), and how can the behavior be measured or 
> reported upon so I can explain this with supporting doc?   Does WLM play a 
> part in sharing CPU across LPARs?
> 
> 
> --
> 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: publibz->infocenter->knowledgecenter

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 09:56:22 -0600, Paul Gilmartin wrote:

>Curse you, Red Baron!
>
Seriously.

Under the nav frame in http://www-01.ibm.com/support/knowledgecenter/
I find TOC->IBM Operating Systems->System z Operating Systems->z/OS->2.1.0
so buried in Javascript that I don't know what it's trying to do.  It 404s.

This sort of thing could erode my respect for IBM.

(Actually, I just found on the error page a link that seems to work.  But, 
still, ...)

>Bring back LOOKAT!

-- gil

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting LPAR 
B.  I didn't ask them for doc, but will next time.  

This is a runtime issue, unrelated to reported changes.  That being said, I'm 
aware WLM is changed frequently and without broadcast notification.

This appears from time to time.  I am new here (couple of months) so cannot 
determine how long its been happening - could be months, could be years.  

I need to understand the interworkings of prism, WLM, and the LPARs, and from 
the postings today, more about soft and hard capping.  

All input is appreciated.  I have a learning curve in this area, so telling me 
to look for something in RMF is welcome, along with any display commands where 
I can see the caps.  I have Mainview. 

Sent from my iPhone

On Dec 17, 2014, at 8:35 AM, Lizette Koehler  wrote:

> I would ask first, how do  you know it is affecting the Prod LPAR.
> 
> What evidence, RMF Reports, Performance monitors, etc. ?
> 
> There should be, I think, so data that could explicitly show that is what is
> happening.
> 
> Is it all the time, some of the time?  Is it a specific time when the prod
> LPAR is affected?  How long has it been going on?  Is there a point in time
> when this started?  If so, what changes occurred at that point?
> 
> Lizette
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of L Hagedorn
>> Sent: Wednesday, December 17, 2014 5:44 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: MIPS, CEC, LPARs, PRISM, WLM
>> 
>> Hi IBM-MAIN,
>> 
>> We have a situation with multiple LPARS on a CEC, running DB2 asids prod,
> test,
>> dev.
>> 
>> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and
>> stealing MIPS from the PROD LPAR and affecting production.
>> 
>> Others claim this is not possible due to Prism.
>> 
>> Will someone provide an overview of how Prism influences or controls MIPS
> usage
>> (CPU) across LPARs sharing the same CEC, what are the limiting or
> controlling
>> factors (if any), and how can the behavior be measured or reported upon so
> I can
>> explain this with supporting doc?   Does WLM play a part in sharing CPU
> across
>> LPARs?
>> 
>> Any information or referrals to doc is appreciated.
>> 
>> Thanks, Linda
> 
> --
> 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


publibz->infocenter->knowledgecenter

2014-12-17 Thread Paul Gilmartin
Curse you, Red Baron!

My bookmark to publibz/z/OS documentation redirected for a
while to a similar infocenter shelf list; later to a knowledgecenter
shelflist.  Now it redirects to the knowledgecenter storefront.

What's a quick link to this week's z/OS v2r1 software shelflist?

(was: http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp )

Bring back LOOKAT!

Thanks,
gil

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


Re: AW: Re: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 16:32:33 +0100, Peter Hunkeler  wrote:
>
>>> Advantage: You can user JCL symbols (and if your jobclass allows it, also 
>>> system symbols) in the UNIX commands.
>>>
>> With z/OS 2.1 and higher.
>> Jobclass?
>> Are system symbols considered secret/sensitive?
>
>I guess, no. I imagine this is more to be able to selectively switch this 
>feature on to protect from side effects in existing JCL.
> 
Dammit!  As I said before, ab ovo an apparent reference to an undefined symbol
such as:

//SYSUT2  DD  DISP=(,PASS),DSN=&SYSUT2

... should have been treated as a syntax error.

(Shmuel has pointed out that the behavior can't be introduced now;
it would break vast amounts of existing JCL.)

-- gil

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


AW: Re: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Peter Hunkeler
>You might bootleg a comment in with such as: [snip]
Thanks for this hint.

: ' -
This serves as a comment.
I have not tested it on z/OS BPXBATCH.
It must contain no apostrophes.
- '

>> Advantage: You can user JCL symbols (and if your jobclass allows it, also 
>> system symbols) in the UNIX commands.
>>
> With z/OS 2.1 and higher.
> Jobclass?
> Are system symbols considered secret/sensitive?




I guess, no. I imagine this is more to be able to selectively switch this 
feature on to protect from side effects in existing JCL.


--


Peter Hunkeler





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


AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Peter Hunkeler
> THAT IS AWESOME! Wow! Thanks,

You're welcome.




I recognize from seeming my onw post that it has been reformatted in a bad way. 
A couple of line feeds have been dropped. Hope you can decifer the samples 
anyway. If not, tell me and I will try reposting them.


--


Peter Hunkeler



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


Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Charles Mills
THAT IS AWESOME! Wow! Thanks,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Wednesday, December 17, 2014 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX
commands. Here are two JCL's I'm using to run UNIX commands in batch:
//  EXPORT SYMLIST=*//  SET  DIR='newdir'//UNIXCMDS   EXEC
PGM=BPXBATCH
//STDINDD  DUMMY
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*
//SYMRESDD DD  SYSOUT=*
//STDPARM  DD  *,SYMBOLS=(JCLONLY)
SH
  cd /some/directory ;
  ls -l ;  mkdir -m 700  &DIR./*

Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them.
You start with the usual "SH" to tell BPXBATCH to run a shell. All the rest
of STDPARM is input to that shell, so you need to adhere to shell command
line syntax. Chain multiple commands with the ";". Note also that you must
not try to insert comment, because the first # will start a comment that
goes to the end of STDPARM.
Advantage: You can user JCL symbols (and if your jobclass allows it, also
system symbols) in the UNIX commands.


The second job is solving the problem of running commands via "su" in batch.
Its not perfect, but mostly does the trick for me. First, there is a JCL
procedure:


//BPXSU   PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job' 
//INPUT   EXEC PGM=IEBGENER   
//SYSPRINT  DD DUMMY 
//SYSIN DD DUMMY 
//SYSUT1DD DDNAME=COMMANDS   
//SYSUT2DD PATH='/tmp/&SYSUID-&TMP', 
// PATHDISP=(KEEP,DELETE),   
// PATHOPTS=(OWRONLY,OCREAT,OEXCL),   
// PATHMODE=(SIRUSR,SIWUSR)   
//EXECUSS EXEC PGM=BPXBATCH,PARM='SH su' 
//STDOUTDD SYSOUT=&SOUT. 
//STDERRDD SYSOUT=&SOUT. 
//STDIN DD PATH='/tmp/&SYSUID-&TMP', 
// PATHDISP=(DELETE,DELETE)   
//STDPARM   DD DUMMY 

Second, here is how to use it:
//  EXPORT SYMLIST=*//  SET
FILE='somefile'//UNIXCMDS EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l
; chown foo:bar &FILE./*

The rules for COMMANDS are similar to the above. Note that this is STDIN,
not STDPARM, so the "SH" is not need.
Also, fi system symbols are allowed, the you can make the temp file name
more unique using date, time or other system symbols.

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


Re: ftp rdw

2014-12-17 Thread John McKown
On Wed, Dec 17, 2014 at 8:47 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote:
>
> >Yes, you can do it yourself.
> >https://www.ibm.com/developerworks/rfe
> >
> Is DeveloperWorks membership required?  $$$?
>

​You need to register, but it is at no cost. I just now registered my own
personal registration.

https://www.ibm.com/developerworks/dwwi/jsp/Register.jsp?lang=en&appl=&d=http%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2F
​



>
> >Kirk Wolf
> >Dovetailed Technologies
> >http://dovetail.com
> >
> >On Tue, Dec 16, 2014 at 9:38 PM, Paul Edwards wrote:
> >
> >> > You should submit an RFE for FTP to IBM.
> >>
> >> Hi Kirk. I am not an IBM customer. Is this something
> >> you could do yourself? Or will anyone else volunteer?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

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: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 09:48:45 +0100, Peter Hunkeler wrote:

>Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX 
>commands.  ...
>
>Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them.  
>You start with the usual "SH" to tell BPXBATCH to run a shell. All the rest of 
>STDPARM is input to that shell, so you need to adhere to shell command line 
>syntax. Chain multiple commands with the ";". Note also that you must not try 
>to insert comment, because the first # will start a comment that goes to the 
>end of STDPARM.
>
You might bootleg a comment in with such as:

: ' -
This serves as a comment.
I have not tested it on z/OS BPXBATCH.
It must contain no apostrophes.
- '

>Advantage: You can user JCL symbols (and if your jobclass allows it, also 
>system symbols) in the UNIX commands.
>
With z/OS 2.1 and higher.
Jobclass?  Are system symbols considered secret/sensitive?

-- gil

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


Re: ftp rdw

2014-12-17 Thread Paul Gilmartin
On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote:

>Yes, you can do it yourself.
>https://www.ibm.com/developerworks/rfe
> 
Is DeveloperWorks membership required?  $$$?

>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>
>On Tue, Dec 16, 2014 at 9:38 PM, Paul Edwards wrote:
>
>> > You should submit an RFE for FTP to IBM.
>>
>> Hi Kirk. I am not an IBM customer. Is this something
>> you could do yourself? Or will anyone else volunteer?

-- gil

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Staller, Allan
The answer is, "it depends".

First, there is no "priority" across LPARS. All LPARS are dispatched "equally" 
according to the LPAR weights.  

For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the 
following occurs:

If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and goes 
on their merry way.

If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA 
will be squeezed to 80%.

If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and goes 
on their merry way.

The LPARA weight represents a "guaranteed minimum" proportion (note: LPAR 
weights need not total to 100. The proportion is relative.)

All of the above occurs when capping (either hard or soft) is not present.

Software capping can occur with resource groups.
Hardware capping can occur with group capacity limits.

This is a complex subject and much more than can be covered in a short e-mail. 

If you have not already done so, I suggest you obtain a copy of and read the 
PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and is 
located here:
https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570&aid=1
 (watch the wrap).

RMF Monitor I (batch) has an excellent CPU report. This will also include the 
"PARTITION DATA REPORT". I will refer you to the fine manuals for details/

WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. 
However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor.

As others have pointed out, what evidence is there that the "runaway" task is 
affecting "production"  (factual, not conjecture!)?

HTH,


We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, 
dev.  

It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
stealing MIPS from the PROD LPAR and affecting production.  

Others claim this is not possible due to Prism.  

Will someone provide an overview of how Prism influences or controls MIPS usage 
(CPU) across LPARs sharing the same CEC, what are the limiting or controlling 
factors (if any), and how can the behavior be measured or reported upon so I 
can explain this with supporting doc?   Does WLM play a part in sharing CPU 
across LPARs?


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


Re: ftp rdw

2014-12-17 Thread Kirk Wolf
Yes, you can do it yourself.
https://www.ibm.com/developerworks/rfe

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Dec 16, 2014 at 9:38 PM, Paul Edwards  wrote:

> > You should submit an RFE for FTP to IBM.
>
> Hi Kirk. I am not an IBM customer. Is this something
> you could do yourself? Or will anyone else volunteer?
>
> Thanks. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Lizette Koehler
I would ask first, how do  you know it is affecting the Prod LPAR.

What evidence, RMF Reports, Performance monitors, etc. ?

There should be, I think, so data that could explicitly show that is what is
happening.

Is it all the time, some of the time?  Is it a specific time when the prod
LPAR is affected?  How long has it been going on?  Is there a point in time
when this started?  If so, what changes occurred at that point?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of L Hagedorn
> Sent: Wednesday, December 17, 2014 5:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: MIPS, CEC, LPARs, PRISM, WLM
> 
> Hi IBM-MAIN,
> 
> We have a situation with multiple LPARS on a CEC, running DB2 asids prod,
test,
> dev.
> 
> It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and
> stealing MIPS from the PROD LPAR and affecting production.
> 
> Others claim this is not possible due to Prism.
> 
> Will someone provide an overview of how Prism influences or controls MIPS
usage
> (CPU) across LPARs sharing the same CEC, what are the limiting or
controlling
> factors (if any), and how can the behavior be measured or reported upon so
I can
> explain this with supporting doc?   Does WLM play a part in sharing CPU
across
> LPARs?
> 
> Any information or referrals to doc is appreciated.
> 
> Thanks, Linda

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


Re: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread Elardus Engelbrecht
Linda Hagedorn wrote:

>We have a situation with multiple LPARS on a CEC, running DB2 asids prod, 
>test, dev.  

What z/OS levels? What levels of DB2 on all those LPARS?

>It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
>stealing MIPS from the PROD LPAR and affecting production.  

Based on what were those claims made? I would like to see for example, RMF or 
SMF data/reports or some other tools used to prove that claims.

Are you having response time problems?

>Others claim this is not possible due to Prism.  
>Will someone provide an overview of how Prism influences or controls MIPS 
>usage (CPU) across LPARs sharing the same CEC, what are the limiting or 
>controlling factors (if any), and how can the behavior be measured or reported 
>upon so I can explain this with supporting doc?   Does WLM play a part in 
>sharing CPU across LPARs?

Are your LPARS hard or soft capped? What are the CPU and MSU allocations to 
your LPARS?

>Any information or referrals to doc is appreciated.  

I'll leave that to the real performance gurus on IBM-MAIN. 

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: MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread R.S.

W dniu 2014-12-17 o 13:44, L Hagedorn pisze:

Hi IBM-MAIN,

We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, 
dev.

It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
stealing MIPS from the PROD LPAR and affecting production.

Others claim this is not possible due to Prism.

Will someone provide an overview of how Prism influences or controls MIPS usage 
(CPU) across LPARs sharing the same CEC, what are the limiting or controlling 
factors (if any), and how can the behavior be measured or reported upon so I 
can explain this with supporting doc?   Does WLM play a part in sharing CPU 
across LPARs?

Any information or referrals to doc is appreciated.

(some simlifications done)
First, it's easier to talkt about system A in LPAR A and system B in 
LPAR B. Nevermind what applications are running under given system.


You decide how much percentage of total CPU power is assigned to the 
LPARs, i.e. 70% for LPAR A and 20% for LPAR B and 10% for LPAR C.
However when LPAR A is not busy but LPAR B is busy it can happen LPAR B 
will consume more than you assigned. It's OK because stealing LPAR will 
consume only spare CPU cycles. You can prevent it (why? ) by using capping.
In fact the weights are in use when all LPARs want do consume more than 
assigned.



HTH

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote.



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


MIPS, CEC, LPARs, PRISM, WLM

2014-12-17 Thread L Hagedorn
Hi IBM-MAIN,

We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, 
dev.  

It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and 
stealing MIPS from the PROD LPAR and affecting production.  

Others claim this is not possible due to Prism.  

Will someone provide an overview of how Prism influences or controls MIPS usage 
(CPU) across LPARs sharing the same CEC, what are the limiting or controlling 
factors (if any), and how can the behavior be measured or reported upon so I 
can explain this with supporting doc?   Does WLM play a part in sharing CPU 
across LPARs?

Any information or referrals to doc is appreciated.  

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


Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)

2014-12-17 Thread R.S.

W dniu 2014-12-16 o 22:11, J O Skip Robinson pisze:

My complaints focus on those HCs that don't really make sense any more. For 
example, in 1984 it would have been a cogent warning that the Product X master 
file and its backup/alternate are located behind the same DASD control unit. If 
you lost the control unit, you'd lose both copies. In 2014 with array 
technology, there is no longer a physical control unit. You have a big box with 
hundreds of logical volumes. If you lose the whole box, you're in a world of 
hurt so egregious that the demise of a master file is just noise. Yet I get 
constant warnings about a configuration oversight for which there is no 
feasible remedy. Sure I can turn the HC off, but shouldn't common sense (and a 
bit of extra coding) turn it off for me?


Well, I'm not going to invent some check which can be senseless for me 
but reasonable for you. Sometimes the check itself can check whether 
configuration is applicable, in some other cases it is up to 
administrator to decide.



Now, Health Checker has its own configuration member in parmlib, you can 
easily (and dynamically of course) disable unneeded checks.


Theoretical example: on system ABC I have one library with more>1 extent 
on LNKLST. I'm aware of it, I cannot change it now, the planned outage 
will be in March, so I don't want to be warned about it verey 4 hours.



Regards

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

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, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



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


Re: Problem defining LU Range

2014-12-17 Thread גדי בן אבי
Here are the complete definitions:
LUGROUP  HAR1LU
  BIH10001..BIH10256
ENDLUGROUP
IPGROUP  HAR1IP
  255.255.255.0:10.100.2.0
  255.255.255.0:10.100.12.0
  255.255.255.0:10.100.13.0
  255.255.255.0:10.100.14.0
  255.255.255.0:10.100.15.0
  255.255.255.0:10.100.16.0
  255.255.255.0:10.100.17.0
  255.255.255.0:10.100.18.0
  255.255.255.0:10.100.19.0
ENDIPGROUP

LUMAP HAR1LU HAR1IP

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, December 17, 2014 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem defining LU Range

WARNING: I'm not working with TCP/IP these days anymore, but ... ;-)

Gadi wrote:

>I defined the following statement in the TCP/IP Profile

>LUGROUP HAR1LU
>   BIH1001A..BIH1256A
>ENDLUGROUP

>When I try to activate it I get the message:
>EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED

All our LU groups are all numeric in the last few (usually 4) characters, in 
case this could be the reason. Perhaps you could try it out, but yes, I saw 
Juergen Keller's excellent replies and I cannot find any problem with that.

Or ... your group is already defined before that statement.

>This is running on OS/390 v.28 (Groan).

Yeah...

>What is wrong here?

Show us the LUMAP for HAR1LU and IPGROUP too.

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

לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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


Re: Trouble with IARV64 GETCOMMON

2014-12-17 Thread Rob Scott
The default setting for IARV64 FPROT is YES meaning that the program accessing 
the storage must have a PSW key that matches the storage key of the memobj (or 
PSW key 0).

I believe that IPCS storage browse ACTIVE runs in problem state and key8 - 
therefore you will not see the storage.

If you want all address spaces to see your common memobj, try using FPROT=NO on 
the IARV64 macro.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald Likens
Sent: 16 December 2014 20:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Trouble with IARV64 GETCOMMON

I issue the following macro:
IARV64 REQUEST=GETCOMMON,
  COND=YES,
  SEGMENTS=SBS01, <=== Value is 1.
  MOTKNSOURCE=SYSTEM,OUTMOTKN=SBITKN,
  TYPE=PAGEABLE,
  OWNERCOM=SYSTEM,
  ORIGIN=SBILOC,
  DUMP=LIKECSA,
  RSNCODE=SBIRSN

I display the address obtained.

When I look at this address in IPCS looking at the ACTIVE address space, I do 
not see my storage.

When I take a dump of my address space, I see my storage.

What am I doing wrong?

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


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

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


Re: Problem defining LU Range

2014-12-17 Thread Klaus Stanislawiak
Back then the LU names had to consist of the LU base name and the range 
specification (i.e. at the end).
So a definition like BIHA1001..BIHA1256 should work.
Regards and good luck,
Klaus Stanislawiak

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


Re: Problem defining LU Range

2014-12-17 Thread Elardus Engelbrecht
WARNING: I'm not working with TCP/IP these days anymore, but ... ;-)

Gadi wrote:

>I defined the following statement in the TCP/IP Profile

>LUGROUP HAR1LU
>   BIH1001A..BIH1256A
>ENDLUGROUP

>When I try to activate it I get the message:
>EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED

All our LU groups are all numeric in the last few (usually 4) characters, in 
case this could be the reason. Perhaps you could try it out, but yes, I saw 
Juergen Keller's excellent replies and I cannot find any problem with that.

Or ... your group is already defined before that statement.

>This is running on OS/390 v.28 (Groan).

Yeah...

>What is wrong here?

Show us the LUMAP for HAR1LU and IPGROUP too.

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: Problem defining LU Range

2014-12-17 Thread גדי בן אבי
Hi Juergen,

Unfortunatly, the third parameter was intorduced sometime after OS/390 v2.8, so 
I cannot use it.

Gadi

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
Juergen Keller [keller-ibmm...@web.de]
Sent: 17 December 2014 10:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem defining LU Range

try this:
LUGROUP HAR1LU
   BIH1001A..BIH1256A..NNNF
ENDLUGROUP

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

לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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


AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND

2014-12-17 Thread Peter Hunkeler
Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX 
commands. Here are two JCL's I'm using to run UNIX commands in batch:
//  EXPORT SYMLIST=*//  SET  DIR='newdir'//UNIXCMDS   EXEC 
PGM=BPXBATCH
//STDINDD  DUMMY
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*
//SYMRESDD DD  SYSOUT=*
//STDPARM  DD  *,SYMBOLS=(JCLONLY)
SH
  cd /some/directory ;
  ls -l ;  mkdir -m 700  &DIR./*

Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them. 
You start with the usual "SH" to tell BPXBATCH to run a shell. All the rest of 
STDPARM is input to that shell, so you need to adhere to shell command line 
syntax. Chain multiple commands with the ";". Note also that you must not try 
to insert comment, because the first # will start a comment that goes to the 
end of STDPARM.
Advantage: You can user JCL symbols (and if your jobclass allows it, also 
system symbols) in the UNIX commands.


The second job is solving the problem of running commands via "su" in batch. 
Its not perfect, but mostly does the trick for me. First, there is a JCL 
procedure:


//BPXSU   PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job'
//INPUT   EXEC PGM=IEBGENER
//SYSPRINT  DD DUMMY
//SYSIN DD DUMMY
//SYSUT1DD DDNAME=COMMANDS
//SYSUT2DD PATH='/tmp/&SYSUID-&TMP',
// PATHDISP=(KEEP,DELETE),
// PATHOPTS=(OWRONLY,OCREAT,OEXCL),
// PATHMODE=(SIRUSR,SIWUSR)
//EXECUSS EXEC PGM=BPXBATCH,PARM='SH su'
//STDOUTDD SYSOUT=&SOUT.
//STDERRDD SYSOUT=&SOUT.
//STDIN DD PATH='/tmp/&SYSUID-&TMP',
// PATHDISP=(DELETE,DELETE)
//STDPARM   DD DUMMY

Second, here is how to use it:
//  EXPORT SYMLIST=*//  SET FILE='somefile'//UNIXCMDS 
EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l ; chown foo:bar &FILE./*

The rules for COMMANDS are similar to the above. Note that this is STDIN, not 
STDPARM, so the "SH" is not need.
Also, fi system symbols are allowed, the you can make the temp file name more 
unique using date, time or other system symbols.

--
Peter Hunkeler



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


Re: Problem defining LU Range

2014-12-17 Thread Juergen Keller
try this:
LUGROUP HAR1LU
   BIH1001A..BIH1256A..NNNF
ENDLUGROUP

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


Re: Problem defining LU Range

2014-12-17 Thread Juergen Keller
Hi Gadi,
I think you must specify how to determine new LUs. We do it this way. Please 
have a look at "IP Configuration Guide". There you will find:
LU range specification: Telnet LU range rules allow for almost any type of LU
range needed. Ranges can be alphabetic (A), numeric (N), alphanumeric (B),
hexadecimal (X), or a complete wildcard (?), which includes alphanumeric and the
three national characters (@,#,$). The range type can be different for each 
character
position. Within the LU range, any character position can be fixed (F). To 
conform
with VTAM LU naming convention, the first character must be alphabetic or a
national character. If the first character is a range, only the alphabetic 
range can be
used.
An LU range is created by specifying a starting LU name, an ending LU name, and
the range rules to be used. For example, the following statement creates a range
from TCPM1000 to TCPM1100.
TCPM1000..TCPM1100..FNNN
etc ..
regards Juergen

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


Problem defining LU Range

2014-12-17 Thread גדי בן אבי
Hi,

I defined the following statement in the TCP/IP Profile

LUGROUP HAR1LU
   BIH1001A..BIH1256A
ENDLUGROUP

When I try to activate it I get the message:
EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED

This is running on OS/390 v.28 (Groan).

I looked at the OS/390 V2.8 IP Configuration manual, and it seems to be ok.

What is wrong here?

Gadi

לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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