Re: Tape Mount Management

[Vernooij, Kees (ITOP NM) - KLM]

So, the "problem" you try to solve is that you want to charge more data? Why 
don't you just start charging tape data then?
I think you a trying to build a canon just to shoot a mosquito (Dutch 
expression).

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Benik, John E
> Sent: 31 January, 2019 21:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Tape Mount Management
> 
> Thank you for all the feedback.  Even though we are all virtual tape, I
> am under the impression that not all the data residing on tape should
> be.  Yes it's virtual and therefore disk, but many of the JCL used today
> is old and since there is no chargeback for tape, users continue to
> write their data to tape.  I am looking into this to help determine
> where the data should reside.  The best will probably be looking at
> smaller tapes and having those go to disk instead.  I'm thinking
> starting with 50 MB.
> 
> 
> 
> John Benik | Optum
> Senior Systems Management Analyst  – Mainframe Storage, Network Hosting
> Services
> Optum Technology
> 12125 Technology Drive
> Eden Prairie, MN 55344
> 
> O) 1-952-833-7765
> C) 1-612-616-3984
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, January 30, 2019 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Tape Mount Mangement
> 
> On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:
> >
> >My other impression is it's simpler to change gazillion (usually less)
> >of JCL jobs to explicitly point datasets to DASD than using TMM.
> >
> Might a JCLLIB member that SETs a few JCL symbols facilitate this?
> Reduce a gazillion to a handful?  Nowadays JCL symbols can even
> be resolved in SYSIN.
> 
> >Of course virtual tape reliefs many pains of tape, but keeping things
> in
> >old way is not good for the future.
> >
> IBM sometimes seems to have the opposite impression.  "Compatibility".
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the
> intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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



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

Re: ISPCFIGU not being used.

[Mike Schwab]

Double check the Catalog lists and the DSN / VOLSER between the
problem LPAR and the working LPAR.  I suspect it might be a
development LPAR with different DSNs.  Maybe check with IPLINFO too?

On Thu, Jan 31, 2019 at 12:45 PM Shaffer, Terri
<017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:
>
> Ive verified the linklist dataset is where I generated the module, Ive done 
> multiple ISRFIND and ISRDDN just to make sure my concatenations are what I 
> expected.
>
> ,BROWSE   ,SYS2.USERMOD.LINKLIB(ISPCFIGU)
> ,Command ===>,
> * Top of
> .Ø..ISPCFIGU...o
> س...
> Ø..5695PMB01 ..Í-"
> Ø.dØ..569623400 .
>  ..q...q
> ISPCFIGU480R800101/31/19<<< This is what I expect
>
> This is where the utility placed the module with todays date and I can verify 
> that if I load this to an ISPLLIB dataset.
>
> What doesn’t work is if I try to pull the library from LINKLST.  Ive also 
> verified my usermod library is 30cyls and in 1 extent.
>
> Ive tried everything I can think of.. Even increasing the Sitewide Defaults 
> Version Level number and still not pulling the right one.
>
> This is what I get by default.
>
> Current Configuration Table,
> ,,Keyword File :,SYS9.ISPF.KEYWORDS(ACW2)
> ,,Identifier . :,ISPCFIGU,,Level  . . . :,480R8001,
> ,,Compile Date :,2014/11/20,  ,Compile Time :,15:13,
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> terri.shaf...@aciworldwide.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of R.S.
> Sent: Thursday, January 31, 2019 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ISPCFIGU not being used.
>
> External Email
>
>
>
> W dniu 2019-01-31 o 19:18, Shaffer, Terri pisze:
> > Hi,
> >So I know I am missing something here as my predecessors did things 
> > uniquely.  So here my dilemma...
> >
> > I generated a new ISPCFIGU module and put it into my linklst, did the 
> > refresh, etc and its not being picked up.
> >
> > If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute 
> > ISPCCONF, it states that fact with todays date.
> >
> > But if I try to setup for all users, it doesn’t...
> >
> > Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon 
> > and the module is nowhere to be found, except where I generated it too.
> >
> > Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module 
> > from 2014.
> >
> > Ive done this same thing in my 5-way sysplex and everything worked like I 
> > expected, but the lpar off by itself, it doesn’t.
> >
> > Can someone shed light on what I'm missing?
>
> I don't put this module to LNKLST or LPA. I just created small PDS loadlib 
> just for the ISPF members and added this library to ISPLLIB.
> It works. It's simple.
>
> In your case it can be some duplicate member. Use ISRDDN or Mark Zelden's 
> FINDMOD to find it .
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub 
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może 
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia 
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza 
> prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
> Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
> NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
> 01.01.2018 r. wynosi 169.248.488 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have 
> printed out or saved).
> This message may contain legally protected information, which may be used 
> exclusively by the addressee.Please be reminded that anyone who disseminates 
> (copies, distributes) this message or takes any similar action, violates the 
> law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the 
> Capital City of Warsaw, 12th Commercial Division of the National Court 
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital 
> amounting to PLN 169,248,488 as at 1 January 2018.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu 

How can I get reports in the Output Queue in SDSF to print

[McCabe, Ron]

Hello,

How can I get reports that are in the Output Queue in SDSF to be 
re-printed...basically I want them to be processed again.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Cause of CsvdylpaRsnBadVersion?

[Greg Price]

On 2019-02-01 11:59 AM, Charles Mills wrote:

Do others here agree with that advice? Eschew MF=(E,...,COMPLETE) ?


Numerous newer (in geological terms) macros simply define a storage area 
with MF=L. For these I use PLISTVER=MAX with MF=L when it's available, 
and in these cases I also use COMPLETE on the associated MF=E form when 
that is available. I think this maximizes the chances of getting good 
macro plists for these cases. Just IMO. YMMV.


Cheers,
Greg P.

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

Re: Hmc for z as a virtual appliance?

[Timothy Sipples]

>I know power systems has one. Dies system z has such product?

The Hardware Management Console is available in traditional desktop and 1U
rack mounted form factors. The latter form factor can be installed within
the optional "16U Reserved" feature on IBM z14 ZR1 and IBM LinuxONE
Rockhopper II models.

You need not be physically proximate to the HMC. Remote HMC access is
available, and IBM offers HMC Mobile for Apple iOS and Google Android:

https://www.ibm.com/servers/resourcelink/lib03060.nsf/pages/hmcMobileApp?OpenDocument


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

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

Re: Cause of CsvdylpaRsnBadVersion?

[Steve Smith]

Don't know, maybe some do.  I would advise following the book, examining
the code, and maybe experimenting to get the results that seem to work the
best (fsvo best).

Your issue came up from assembling on a higher level than you executed on.
Gotta be careful with that.  I do think IBM might have produced a better
error.  Something that resolved to "I don't support parmlist version > 2,
and you gave me a 3."

sas

On Thu, Jan 31, 2019 at 7:59 PM Charles Mills  wrote:

> Do others here agree with that advice? Eschew MF=(E,...,COMPLETE) ?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Thursday, January 31, 2019 4:10 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cause of CsvdylpaRsnBadVersion?
>
> As a general rule for LIST/EXECUTE form macros, avoid coding anything else
> on the execute call except for E. The reason is that the LIST call
> determines what data needs to be included in the generated code. Once that
> is built, any parm that would require a different size or list format will
> no longer fit properly in the area already generated. Setting flags is
> usually OK on MF=E as long as the flag(s) already exist.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
sas

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

Re: Cause of CsvdylpaRsnBadVersion?

[Charles Mills]

Do others here agree with that advice? Eschew MF=(E,...,COMPLETE) ?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 31, 2019 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cause of CsvdylpaRsnBadVersion?

As a general rule for LIST/EXECUTE form macros, avoid coding anything else on 
the execute call except for E. The reason is that the LIST call determines what 
data needs to be included in the generated code. Once that is built, any parm 
that would require a different size or list format will no longer fit properly 
in the area already generated. Setting flags is usually OK on MF=E as long as 
the flag(s) already exist.  

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

Re: ISPCFIGU not being used.

[Edward Finnell]

If it's not in LPA list  then something is loading it. Could be a command in 
PARMlib or a startup command in tuning software.

In a message dated 1/31/2019 5:51:59 PM Central Standard Time, 
017d5f778222-dmarc-requ...@listserv.ua.edu writes:
I am not sure if CSA means common, or how it got loaded there,  I don’t see it 
in any LPA library.

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

Re: Cause of CsvdylpaRsnBadVersion?

[Jesse 1 Robinson]

As a general rule for LIST/EXECUTE form macros, avoid coding anything else on 
the execute call except for E. The reason is that the LIST call determines what 
data needs to be included in the generated code. Once that is built, any parm 
that would require a different size or list format will no longer fit properly 
in the area already generated. Setting flags is usually OK on MF=E as long as 
the flag(s) already exist.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, January 31, 2019 3:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Cause of CsvdylpaRsnBadVersion?

And the answer is:

1. Don't code PLISTVER=MAX on the MF=E. Code it on the MF=L, but code or allow 
it to default to IMPLIED_VERSION on the MF=E.

2. New environment, and I was confused: I was building on V2R3 and attempting 
to run on V2R2. The format of the CSVDYLPA parameter list has changed between 
V2R2 and V2R3, and PLISTVER=MAX says "give me a V2R3 parm list" which of course 
does not work on V2R2.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, January 31, 2019 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cause of CsvdylpaRsnBadVersion?

I've got CSVDYLPA code that has been working more or less unchanged for eight 
years -- no idea what release of z/OS it was developed on. (The coding has not 
changed but it is re-assembled from time to time -- the most recent object 
module was created on V2R2.)

All of a sudden I am getting return code 080e = CsvdylpaRsnBadVersion. See
here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa100/iea3a1_Description18.htm 

The code consists of

 CSVDYLPA REQUEST=ADD,MODINFOTYPE=MEMBERLIST,  +
   MODINFO=(R2),NUMMOD=1,  +
   DDNAME=KSTEPLIB,+
   REQUESTOR=KCORRELOG,+
   SECMODCHECK=NO, Why bother? +
   MODPROB=STOP,   Make sure get return code   +
   PLISTVER=MAX,   Recommended by IBM  +
   MF=(E,DYLPAL,COMPLETE)

And

 CSVDYLPA PLISTVER=MAX,MF=(L,DYLPAL)

The two macros are in the same source module so always get assembled at the 
same time at the same level.

The suggested "Action" is "Action: Check for possible storage overlay of the 
parameter list."

"Overlay" in the classic sense seems unlikely, but the MF=L area is on the LE 
stack and so contains "random" data. Do I need to XC the MF=L area before I 
issue the CSVDYLPA, even with MF=(...,COMPLETE)?

Any other likely causes I should be looking at?

Charles 

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

Re: ISPCFIGU not being used.

[Shaffer, Terri]

I have to say, I've never seen this before so.

BROWSE   ,ISPCFIGU:18772000:0F98 ,Line,0132,Col,001 080
Command ===>,,Scroll ===>,CSR
-10 (18771FF0)        *  *
 +0 (18772000)   C9E2D7C3 C6C9C7E4 F4F8F0D9 F8F0F0F1  * ISPCFIGU480R8001 *
+10 (18772010)   F1F161F2 F061F1F4 40404040 40404040  * 11/20/14 *

Message,Act,DDname   Data Set Name  ,Actions: B E V M F C I Q,
   ,>, , LINKLIST,SYS1.LINKLIB
   ,>, , ,SYS1.MIGLIB
   ,>, , ,SYS1.CSSLIB
   ,>, , ,SYS1.SIEALNKE
   ,>, , ,SYS1.SIEAMIGE
Member:,ISPCFIGU   ,>, , ,SYS2.USERMOD.LINKLIB< This is the 
library were ISPCCONF placed it from me.

,CSVQUERY Results,,
Command ===>,,
  ,More: +,
Module,ISPCFIGU,was found to be already loaded. Note that
invocations of this program name may pick up another copy from
STEPLIB or a LIBDEF'ed data set or from a tasklib such as ISPLLIB.
Tab to a box and press enter to view the module in storage.
 ,,+-+,, ,,
 ,,|,CSA resident  R,|,   ,
 ,,|,Resident above 16 Meg  ,|,   ,
 ,,|,Module address:18772000,|,   ,
 ,,|,Module size:   0F98,|,   ,
 ,,|,Reentrant  ,|,   ,
 ,,|,Serially reusable  ,|,   ,
 ,,|,Not loadable only  ,|,   ,
 ,,|,AMODE 31   ,|,   ,
 ,,|,Authorized library ,|,   ,
 ,,|,Not Authorized program ,|,   ,
 ,,+-+,   ,

I am not sure if CSA means common, or how it got loaded there,  I don’t see it 
in any LPA library.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, January 31, 2019 6:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



Is there another ISPCFIGU that is ahead of linklist in the search order? 
STEPLIB?
Does ISPLLIB count as a task lib, which would be ahead of STEPLIB?

If you issue M ISPCFIGU from ISRDDN, where is it found?

--
Tom Marchant

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

 [https://www.aciworldwide.com/-/media/aci-footer] 
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

Re: Cause of CsvdylpaRsnBadVersion?

[Charles Mills]

And the answer is:

1. Don't code PLISTVER=MAX on the MF=E. Code it on the MF=L, but code or
allow it to default to IMPLIED_VERSION on the MF=E.

2. New environment, and I was confused: I was building on V2R3 and
attempting to run on V2R2. The format of the CSVDYLPA parameter list has
changed between V2R2 and V2R3, and PLISTVER=MAX says "give me a V2R3 parm
list" which of course does not work on V2R2.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, January 31, 2019 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cause of CsvdylpaRsnBadVersion?

I've got CSVDYLPA code that has been working more or less unchanged for
eight years -- no idea what release of z/OS it was developed on. (The coding
has not changed but it is re-assembled from time to time -- the most recent
object module was created on V2R2.)

All of a sudden I am getting return code 080e = CsvdylpaRsnBadVersion. See
here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa100/iea3a1_Description18.htm 

The code consists of

 CSVDYLPA REQUEST=ADD,MODINFOTYPE=MEMBERLIST,  +
   MODINFO=(R2),NUMMOD=1,  +
   DDNAME=KSTEPLIB,+
   REQUESTOR=KCORRELOG,+
   SECMODCHECK=NO, Why bother? +
   MODPROB=STOP,   Make sure get return code   +
   PLISTVER=MAX,   Recommended by IBM  +
   MF=(E,DYLPAL,COMPLETE)

And

 CSVDYLPA PLISTVER=MAX,MF=(L,DYLPAL)

The two macros are in the same source module so always get assembled at the
same time at the same level.

The suggested "Action" is "Action: Check for possible storage overlay of the
parameter list."

"Overlay" in the classic sense seems unlikely, but the MF=L area is on the
LE stack and so contains "random" data. Do I need to XC the MF=L area before
I issue the CSVDYLPA, even with MF=(...,COMPLETE)?

Any other likely causes I should be looking at?

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: ISPCFIGU not being used.

[Tom Marchant]

Is there another ISPCFIGU that is ahead of linklist in the search order? 
STEPLIB?
Does ISPLLIB count as a task lib, which would be ahead of STEPLIB?

If you issue M ISPCFIGU from ISRDDN, where is it found?

-- 
Tom Marchant

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

Re: BPXPRM00 parmlib

[McCabe, Ron]

Thank you that worked.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Cieri, Anthony
Sent: Thursday, January 31, 2019 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

SETOMVS MAXUIDS=2000

No comma after SETOMVS!!!


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McCabe, Ron
Sent: Thursday, January 31, 2019 5:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


David,

I do have my mount statements split out from other statements.  I must be doing 
something wrong because when I enter "SETOMVS,MAXUIDS=2000" as a command from 
the z/OS console I get an error that the command is invalid.  I tried to issue 
from within OMVS and I also get an error "FSUM7351 not found". Am I entering 
the command from the wrong place?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 31, 2019 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

Ron,  Many individual parms can be set via the SETOMVS console command, and may 
be more along the lines of what you want.   Depending on if you have  your 
MOUNT statements split out from other statements (BPXPRMFS vs BPXPRM00), doing 
a SET OMVS=xx might do more than you anticipate or want.

It would be my recommendation to use SETOMVS.

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Thursday, January 31, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXPRM00 parmlib

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality 
Notice: This e- mail and all attachments may contain CONFIDENTIAL information 
and are meant solely for the intended recipient. It may contain controlled, 
privileged, or proprietary information that is protected under applicable law 
and shall not be disclosed to any unauthorized third party. If you are not the 
intended recipient, you are hereby notified that any unauthorized review, 
action, disclosure, distribution, or reproduction 

Re: BPXPRM00 parmlib

[Cieri, Anthony]

SETOMVS MAXUIDS=2000

No comma after SETOMVS!!!


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McCabe, Ron
Sent: Thursday, January 31, 2019 5:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


David,

I do have my mount statements split out from other statements.  I must be doing 
something wrong because when I enter "SETOMVS,MAXUIDS=2000" as a command from 
the z/OS console I get an error that the command is invalid.  I tried to issue 
from within OMVS and I also get an error "FSUM7351 not found". Am I entering 
the command from the wrong place?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 31, 2019 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

Ron,  Many individual parms can be set via the SETOMVS console command, and may 
be more along the lines of what you want.   Depending on if you have  your 
MOUNT statements split out from other statements (BPXPRMFS vs BPXPRM00), doing 
a SET OMVS=xx might do more than you anticipate or want.

It would be my recommendation to use SETOMVS.

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Thursday, January 31, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXPRM00 parmlib

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this 

Re: ISPCFIGU not being used.

[Shaffer, Terri]

Hi Tom,
  Thanks, your session was the first thing I read after it didn’t work for me.

But  I must be missing something..  I deleted my ISPF.PROF and loaded default 
from SYS1.SISP* libraries.

But I still see the same entries in my variables:

ZCFGCMPD,S,N,2014/11/20
ZCFGCMPT,S,N,15:13
ZCFGKSRC,S,N,SYS9.ISPF.KEYWORDS(ACW2)
ZCFGLVL ,S,N,480R8001
ZCFGMOD ,S,N,ISPCFIGU

So I am not sure what I need to reset to pick up the ISPCCONF member created in 
my linklst member?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Thursday, January 31, 2019 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



On 1/31/2019 1:54 PM, Shaffer, Terri wrote:
> Yes multiple times
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> terri.shaf...@aciworldwide.com
>

Terri,

You're likely not seeing the settings because you're not starting with a clean 
profile.  Some settings can be forced or reset, but most defaults only appear 
with a clean profile.  Google my Configuring ISPF for Fun and Profit session, I 
have a step-by-step for updating ISPCFIGU.

Regards,
Tom Conley

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

 [https://www.aciworldwide.com/-/media/aci-footer] 
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

Re: BPXPRM00 parmlib

[McCabe, Ron]

David,

I do have my mount statements split out from other statements.  I must be doing 
something wrong because when I enter "SETOMVS,MAXUIDS=2000" as a command from 
the z/OS console I get an error that the command is invalid.  I tried to issue 
from within OMVS and I also get an error "FSUM7351 not found". Am I entering 
the command from the wrong place?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 31, 2019 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

Ron,  Many individual parms can be set via the SETOMVS console command, and may 
be more along the lines of what you want.   Depending on if you have  your 
MOUNT statements split out from other statements (BPXPRMFS vs BPXPRM00), doing 
a SET OMVS=xx might do more than you anticipate or want.

It would be my recommendation to use SETOMVS.

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Thursday, January 31, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXPRM00 parmlib

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Tape Mount Management

[Steve Thompson]

An odd thing happened when I was looking at an application that 
was burning CPU. Because they had gone to LBI (Large Block 
Interface) and because we were using a VTS (don't know which 
one), reads and buffer xfer were faster to C-Store (memory) than 
DASD was!! Since they were also doing READ READ CHECK (a BSAM 
thing that allows one to do work and not be waiting on I/O), they 
had basically tuned out I/O waits!!.


IF you know your JOBs are using LBI, the following may not mean 
anything to you:


I had offloaded enough of test DATA for that application to take 
up 2 3390-3 volumes. And then I loaded that much to "tape" using 
LBI. Our system read the same data from the "tape" faster than it 
did the disk drives (back on z12 CECs).


If you haven't verified that their applications can handle LBI, 
you might want to do this. You might cut down on the number of 
tape volumes you have in your VTS as a result of going to LBI.


This may also tell you what "tape" data sets are your low hanging 
fruit for getting back some of your resources.


While what I'm saying may seem to you to go opposite of what you 
are trying to do, you may find this bit of info helps you deal 
with both situations, too much data for DASD staging, and too 
little data to be worth eating up tape.


HTHs,
Steve Thompson


On 1/31/19 3:30 PM, Benik, John E wrote:

Thank you for all the feedback.  Even though we are all virtual tape, I am 
under the impression that not all the data residing on tape should be.  Yes 
it's virtual and therefore disk, but many of the JCL used today is old and 
since there is no chargeback for tape, users continue to write their data to 
tape.  I am looking into this to help determine where the data should reside.  
The best will probably be looking at smaller tapes and having those go to disk 
instead.  I'm thinking starting with 50 MB.



John Benik | Optum
Senior Systems Management Analyst  – Mainframe Storage, Network Hosting Services
Optum Technology
12125 Technology Drive
Eden Prairie, MN 55344

O) 1-952-833-7765
C) 1-612-616-3984



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, January 30, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tape Mount Mangement

On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:


My other impression is it's simpler to change gazillion (usually less)
of JCL jobs to explicitly point datasets to DASD than using TMM.


Might a JCLLIB member that SETs a few JCL symbols facilitate this?
Reduce a gazillion to a handful?  Nowadays JCL symbols can even
be resolved in SYSIN.


Of course virtual tape reliefs many pains of tape, but keeping things in
old way is not good for the future.


IBM sometimes seems to have the opposite impression.  "Compatibility".

-- gil

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

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


--
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: BPXPRM00 parmlib

[McCabe, Ron]

Sorry about the delayed response but I was out for a very important 
appointment.  Anyway this is the first couple of lines from the D OMVS,O 
command and based on what I am seeing I must be using 00, CI, and FS.  I'm 
going to do a test in my RESCUE system to see what it does.

D OMVS,O
BPXO043I 13.19.30 DISPLAY OMVS 539
OMVS 000F ACTIVE OMVS=(00,CI,FS)

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: Thursday, January 31, 2019 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPXPRM00 parmlib

I would do a D OMVS and see if 00 is the only thing used.

Some shops have multiple BPXPRM members and concatenate them together.

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Burrell, Todd
> Sent: Thursday, January 31, 2019 11:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BPXPRM00 parmlib
>
> For most everything you should be able to update it and then do T OMVS=00.
> I believe there are a couple of limitations.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of McCabe, Ron
> Sent: Thursday, January 31, 2019 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BPXPRM00 parmlib
>
> Hello,
>
> If I need to make a change to my BPXPRM00 parmlib member can I get the
> change in while everything is running or does it have to done via an IPL?
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
>
> Confidentiality Notice: This e- mail and all attachments may contain
> CONFIDENTIAL information and are meant solely for the intended
> recipient. It may contain controlled, privileged, or proprietary
> information that is protected under applicable law and shall not be
> disclosed to any unauthorized third party. If you are not the intended
> recipient, you are hereby notified that any unauthorized review,
> action, disclosure, distribution, or reproduction of any information
> contained in this e- mail and any attachments is strictly PROHIBITED.
> If you received this e- mail in error, please reply to the sender
> immediately stating that this transmission was misdirected, and delete
> or destroy all electronic and paper copies of this e-mail and
> attachments without disclosing the contents. This e- mail does not
> grant or assign rights of ownership in the proprietary subject matter
> herein, nor shall it be construed as a joint venture, partnership, teaming 
> agreement, or any other formal business relationship.
>
> --
> 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
Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: Tape Mount Management

[Benik, John E]

Thank you for all the feedback.  Even though we are all virtual tape, I am 
under the impression that not all the data residing on tape should be.  Yes 
it's virtual and therefore disk, but many of the JCL used today is old and 
since there is no chargeback for tape, users continue to write their data to 
tape.  I am looking into this to help determine where the data should reside.  
The best will probably be looking at smaller tapes and having those go to disk 
instead.  I'm thinking starting with 50 MB.  



John Benik | Optum
Senior Systems Management Analyst  – Mainframe Storage, Network Hosting Services
Optum Technology
12125 Technology Drive 
Eden Prairie, MN 55344

O) 1-952-833-7765
C) 1-612-616-3984



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, January 30, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tape Mount Mangement

On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:
>
>My other impression is it's simpler to change gazillion (usually less)
>of JCL jobs to explicitly point datasets to DASD than using TMM.
>
Might a JCLLIB member that SETs a few JCL symbols facilitate this?
Reduce a gazillion to a handful?  Nowadays JCL symbols can even
be resolved in SYSIN.

>Of course virtual tape reliefs many pains of tape, but keeping things in
>old way is not good for the future.
> 
IBM sometimes seems to have the opposite impression.  "Compatibility".

-- gil

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

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


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

Re: Internal Coupling Channel on z13

[Martin Packer]

I would form a view as to how important CF request performance is for Dev. 
If it's important I'd be tempted to turn DYNDISP off for Dev and let 
Sandbox suffer.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Jesse 1 Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   31/01/2019 18:44
Subject:Re: Internal Coupling Channel on z13
Sent by:IBM Mainframe Discussion List 



We share CFs between Sandbox and Dev. The latter is not classified here as 
Prod, though its usage is a lot more prod-ish than is Sandbox. We 
currently set all the shared-CP LPARs to THIN based on some Q in a SHARE 
session. Should we revisit that question?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Martin Packer
Sent: Thursday, January 31, 2019 1:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Internal Coupling Channel on z13

(This thread has got quite long so pardon me if I repeat something someone 
else said.)

If you must run a PRODUCTION Coupling Facility LPAR on SHARED engines I 
would generally recommend turning DYNDISP off for that one LPAR. Set it to 
THIN for the non-Production ones it's forced to share with.

The reason is you don't want the Production CF to give up the engine in a 
particularly timely fashion - because another request might come in soon 
after the last one. For the Non-Prod ones you want THIN because you want 
them to get out of the way ASAP. However, the fact of sharing at all is 
the major destructive factor. THIN just mitigates it.

(The instrumentation to guide you on this is SMF74INT, R744PBSY and 
R744PWAI - which can be examined down to the engine level. Sometimes with
value.)

But, as always, actual mainframe estate shape governs the decisions.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 

 
https://urldefense.proofpoint.com/v2/url?u=https-3A__itunes.apple.com_gb_podcast_mainframe-2Dperformance-2Dtopics_id1127943573-3Fmt-3D2=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=Kc_UcJWF9tIwa5POuK33JinEdDOOQUM6djqCZa7uYTo=72EebpfuqG6c8aHIvYYSvia9yw4fcOi8awkWGDnFY6o=



Youtube channel: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCu-5F65HaYgksbF6Q8SQ4oOvA=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=Kc_UcJWF9tIwa5POuK33JinEdDOOQUM6djqCZa7uYTo=NMd8FE00CVO_bO7Ac23QRR1b8oyZSR2vWQwPLwwXG9I=




From:   Ravi Gaur 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   31/01/2019 08:46
Subject:Re: Internal Coupling Channel on z13
Sent by:IBM Mainframe Discussion List 



DYNDISP is recommended with THIN INTERRUPT for Non dedicated CF CPU 
...like for our sandbox/dev systems we have non dedicated and we keep it 
thin for them while for production which has CF CPU dedicated it's good 
idea to keep it OFF ...You may like to look at Z14 Configuration setup 
guide which well explained it and obviously to make these changes you will 
have to do it from HMC . 


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




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: ISPCFIGU not being used.

[Tom Conley]

On 1/31/2019 1:54 PM, Shaffer, Terri wrote:

Yes multiple times

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com



Terri,

You're likely not seeing the settings because you're not starting with a 
clean profile.  Some settings can be forced or reset, but most defaults 
only appear with a clean profile.  Google my Configuring ISPF for Fun 
and Profit session, I have a step-by-step for updating ISPCFIGU.


Regards,
Tom Conley

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

Re: zOSMF - how to enable plugins?

[Ronald Kristel]

Afaik, The standard plugins delivered with z/OSMF need to be started with the 
associated plugin statement in IZUPRMxx. I don't think you can even install 
them with the Import Manager.
Now, there are optional plugin's like the CDP Configuration Tool and SDSF that 
can be installed with the Import Manager, and I don't remember me recycling 
z/OSMF after Importing them to get them working.

Ronald Kristel

From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Thursday, January 31, 2019 19:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF - how to enable plugins?

Thank everyone who helped.

The trick was that IZUPRMxx was NOT READ during startup.
I had IZUPRM='PREV', but no IZU= entry in IEASYS.
In effect IZUPRM00 member existed, I added PLUGINS entry, but it was not
read during IZUSVR1 startup.
I fixed it. Now the icons are not gray, but I lack some RACF ZMFAPLA
resources, which I'm going to fix.

Another question: is it possible to enable such plugins without zOSMF
recycle?
I'm curious about Import Manager features.

--
Radoslaw Skorupka
Lodz, Poland





W dniu 2019-01-31 o 16:27, R.S. pisze:
> I just started (first time) zOSMF.
> I want to use Network Configuration Assistant, however the icon is
> gray and plugin unavailable. Uninstalled task - IUZG437I.
> I tried to use Import Manager to import this plugin. It ask me about
> property file. I have no idea what to provide.
> Neither online help, nor RTFM helped me.
>
> Any clue?
>


==

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

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

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

If you are not the addressee of this message:

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

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

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

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

Re: Cause of CsvdylpaRsnBadVersion?

[Charles Mills]

Well, we can rule out the need for an XC -- I see that that is what the MF=E
macro starts out with, an LA 1 of the area followed by XC 0(116,1),0(1).

So, what could cause an 080E?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, January 31, 2019 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cause of CsvdylpaRsnBadVersion?

I've got CSVDYLPA code that has been working more or less unchanged for
eight years -- no idea what release of z/OS it was developed on. (The coding
has not changed but it is re-assembled from time to time -- the most recent
object module was created on V2R2.)

All of a sudden I am getting return code 080e = CsvdylpaRsnBadVersion. See
here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa100/iea3a1_Description18.htm 

The code consists of

 CSVDYLPA REQUEST=ADD,MODINFOTYPE=MEMBERLIST,  +
   MODINFO=(R2),NUMMOD=1,  +
   DDNAME=KSTEPLIB,+
   REQUESTOR=KCORRELOG,+
   SECMODCHECK=NO, Why bother? +
   MODPROB=STOP,   Make sure get return code   +
   PLISTVER=MAX,   Recommended by IBM  +
   MF=(E,DYLPAL,COMPLETE)

And

 CSVDYLPA PLISTVER=MAX,MF=(L,DYLPAL)

The two macros are in the same source module so always get assembled at the
same time at the same level.

The suggested "Action" is "Action: Check for possible storage overlay of the
parameter list."

"Overlay" in the classic sense seems unlikely, but the MF=L area is on the
LE stack and so contains "random" data. Do I need to XC the MF=L area before
I issue the CSVDYLPA, even with MF=(...,COMPLETE)?

Any other likely causes I should be looking at?

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: BPXPRM00 parmlib

[Jousma, David]

Ron,  Many individual parms can be set via the SETOMVS console command, and may 
be more along the lines of what you want.   Depending on if you have  your 
MOUNT statements split out from other statements (BPXPRMFS vs BPXPRM00), doing 
a SET OMVS=xx might do more than you anticipate or want.

It would be my recommendation to use SETOMVS.

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Thursday, January 31, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXPRM00 parmlib

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

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

Re: BPXPRM00 parmlib

[Lizette Koehler]

I would do a D OMVS and see if 00 is the only thing used.

Some shops have multiple BPXPRM members and concatenate them together.

Lizette




> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Burrell, Todd
> Sent: Thursday, January 31, 2019 11:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: BPXPRM00 parmlib
> 
> For most everything you should be able to update it and then do T OMVS=00.
> I believe there are a couple of limitations.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of McCabe, Ron
> Sent: Thursday, January 31, 2019 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: BPXPRM00 parmlib
> 
> Hello,
> 
> If I need to make a change to my BPXPRM00 parmlib member can I get the change
> in while everything is running or does it have to done via an IPL?
> 
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
> 
> 
> Confidentiality Notice: This e- mail and all attachments may contain
> CONFIDENTIAL information and are meant solely for the intended recipient. It
> may contain controlled, privileged, or proprietary information that is
> protected under applicable law and shall not be disclosed to any unauthorized
> third party. If you are not the intended recipient, you are hereby notified
> that any unauthorized review, action, disclosure, distribution, or
> reproduction of any information contained in this e- mail and any attachments
> is strictly PROHIBITED. If you received this e- mail in error, please reply
> to the sender immediately stating that this transmission was misdirected, and
> delete or destroy all electronic and paper copies of this e-mail and
> attachments without disclosing the contents. This e- mail does not grant or
> assign rights of ownership in the proprietary subject matter herein, nor
> shall it be construed as a joint venture, partnership, teaming agreement, or
> any other formal business relationship.
> 
> --
> 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

Cause of CsvdylpaRsnBadVersion?

[Charles Mills]

I've got CSVDYLPA code that has been working more or less unchanged for
eight years -- no idea what release of z/OS it was developed on. (The coding
has not changed but it is re-assembled from time to time -- the most recent
object module was created on V2R2.)

All of a sudden I am getting return code 080e = CsvdylpaRsnBadVersion. See
here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa100/iea3a1_Description18.htm 

The code consists of

 CSVDYLPA REQUEST=ADD,MODINFOTYPE=MEMBERLIST,  +
   MODINFO=(R2),NUMMOD=1,  +
   DDNAME=KSTEPLIB,+
   REQUESTOR=KCORRELOG,+
   SECMODCHECK=NO, Why bother? +
   MODPROB=STOP,   Make sure get return code   +
   PLISTVER=MAX,   Recommended by IBM  +
   MF=(E,DYLPAL,COMPLETE)

And

 CSVDYLPA PLISTVER=MAX,MF=(L,DYLPAL)

The two macros are in the same source module so always get assembled at the
same time at the same level.

The suggested "Action" is "Action: Check for possible storage overlay of the
parameter list."

"Overlay" in the classic sense seems unlikely, but the MF=L area is on the
LE stack and so contains "random" data. Do I need to XC the MF=L area before
I issue the CSVDYLPA, even with MF=(...,COMPLETE)?

Any other likely causes I should be looking at?

Charles 

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

Re: ISPCFIGU not being used.

[Shaffer, Terri]

Yes multiple times

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, January 31, 2019 1:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



I hate to ask, but you did do a F LLA,REFRESH, right?

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Thursday, January 31, 2019 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Ive verified the linklist dataset is where I generated the module, Ive done 
multiple ISRFIND and ISRDDN just to make sure my concatenations are what I 
expected.

,BROWSE   ,SYS2.USERMOD.LINKLIB(ISPCFIGU)
,Command ===>,
* Top of .Ø..ISPCFIGU...o 
س...
Ø..5695PMB01 ..Í-"
Ø.dØ..569623400 .
 ..q...q
ISPCFIGU480R800101/31/19<<< This is what I expect

This is where the utility placed the module with todays date and I can verify 
that if I load this to an ISPLLIB dataset.

What doesn’t work is if I try to pull the library from LINKLST.  Ive also 
verified my usermod library is 30cyls and in 1 extent.

Ive tried everything I can think of.. Even increasing the Sitewide Defaults 
Version Level number and still not pulling the right one.

This is what I get by default.

Current Configuration Table,
,,Keyword File :,SYS9.ISPF.KEYWORDS(ACW2)
,,Identifier . :,ISPCFIGU,,Level  . . . :,480R8001,
,,Compile Date :,2014/11/20,  ,Compile Time :,15:13,

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, January 31, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



W dniu 2019-01-31 o 19:18, Shaffer, Terri pisze:
> Hi,
>So I know I am missing something here as my predecessors did things 
> uniquely.  So here my dilemma...
>
> I generated a new ISPCFIGU module and put it into my linklst, did the 
> refresh, etc and its not being picked up.
>
> If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute 
> ISPCCONF, it states that fact with todays date.
>
> But if I try to setup for all users, it doesn’t...
>
> Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon 
> and the module is nowhere to be found, except where I generated it too.
>
> Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module 
> from 2014.
>
> Ive done this same thing in my 5-way sysplex and everything worked like I 
> expected, but the lpar off by itself, it doesn’t.
>
> Can someone shed light on what I'm missing?

I don't put this module to LNKLST or LPA. I just created small PDS loadlib just 
for the ISPF members and added this library to ISPLLIB.
It works. It's simple.

In your case it can be some duplicate member. Use ISRDDN or Mark Zelden's 
FINDMOD to find it .


--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

mBank S.A. with its 

Re: ISPCFIGU not being used.

[Jousma, David]

I hate to ask, but you did do a F LLA,REFRESH, right?

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Thursday, January 31, 2019 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Ive verified the linklist dataset is where I generated the module, Ive done 
multiple ISRFIND and ISRDDN just to make sure my concatenations are what I 
expected.

,BROWSE   ,SYS2.USERMOD.LINKLIB(ISPCFIGU)
,Command ===>,
* Top of .Ø..ISPCFIGU...o 
س...
Ø..5695PMB01 ..Í-"
Ø.dØ..569623400 .
 ..q...q
ISPCFIGU480R800101/31/19<<< This is what I expect

This is where the utility placed the module with todays date and I can verify 
that if I load this to an ISPLLIB dataset.

What doesn’t work is if I try to pull the library from LINKLST.  Ive also 
verified my usermod library is 30cyls and in 1 extent.

Ive tried everything I can think of.. Even increasing the Sitewide Defaults 
Version Level number and still not pulling the right one.

This is what I get by default.

Current Configuration Table,
,,Keyword File :,SYS9.ISPF.KEYWORDS(ACW2)
,,Identifier . :,ISPCFIGU,,Level  . . . :,480R8001,
,,Compile Date :,2014/11/20,  ,Compile Time :,15:13,

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, January 31, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



W dniu 2019-01-31 o 19:18, Shaffer, Terri pisze:
> Hi,
>So I know I am missing something here as my predecessors did things 
> uniquely.  So here my dilemma...
>
> I generated a new ISPCFIGU module and put it into my linklst, did the 
> refresh, etc and its not being picked up.
>
> If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute 
> ISPCCONF, it states that fact with todays date.
>
> But if I try to setup for all users, it doesn’t...
>
> Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon 
> and the module is nowhere to be found, except where I generated it too.
>
> Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module 
> from 2014.
>
> Ive done this same thing in my 5-way sysplex and everything worked like I 
> expected, but the lpar off by itself, it doesn’t.
>
> Can someone shed light on what I'm missing?

I don't put this module to LNKLST or LPA. I just created small PDS loadlib just 
for the ISPF members and added this library to ISPLLIB.
It works. It's simple.

In your case it can be some duplicate member. Use ISRDDN or Mark Zelden's 
FINDMOD to find it .


--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

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

--
For IBM-MAIN subscribe 

Re: BPXPRM00 parmlib

[Burrell, Todd]

For most everything you should be able to update it and then do T OMVS=00.   I 
believe there are a couple of limitations.  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McCabe, Ron
Sent: Thursday, January 31, 2019 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BPXPRM00 parmlib

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

[Jesse 1 Robinson]

We share CFs between Sandbox and Dev. The latter is not classified here as 
Prod, though its usage is a lot more prod-ish than is Sandbox. We currently set 
all the shared-CP LPARs to THIN based on some Q in a SHARE session. Should we 
revisit that question?

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, January 31, 2019 1:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Internal Coupling Channel on z13

(This thread has got quite long so pardon me if I repeat something someone else 
said.)

If you must run a PRODUCTION Coupling Facility LPAR on SHARED engines I would 
generally recommend turning DYNDISP off for that one LPAR. Set it to THIN for 
the non-Production ones it's forced to share with.

The reason is you don't want the Production CF to give up the engine in a 
particularly timely fashion - because another request might come in soon after 
the last one. For the Non-Prod ones you want THIN because you want them to get 
out of the way ASAP. However, the fact of sharing at all is the major 
destructive factor. THIN just mitigates it.

(The instrumentation to guide you on this is SMF74INT, R744PBSY and R744PWAI - 
which can be examined down to the engine level. Sometimes with
value.)

But, as always, actual mainframe estate shape governs the decisions.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Ravi Gaur 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   31/01/2019 08:46
Subject:Re: Internal Coupling Channel on z13
Sent by:IBM Mainframe Discussion List 



DYNDISP is recommended with THIN INTERRUPT for Non dedicated CF CPU ...like for 
our sandbox/dev systems we have non dedicated and we keep it thin for them 
while for production which has CF CPU dedicated it's good idea to keep it OFF 
...You may like to look at Z14 Configuration setup guide which well explained 
it and obviously to make these changes you will have to do it from HMC . 


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: ISPCFIGU not being used.

[R.S.]

W dniu 2019-01-31 o 19:18, Shaffer, Terri pisze:

Hi,
   So I know I am missing something here as my predecessors did things 
uniquely.  So here my dilemma...

I generated a new ISPCFIGU module and put it into my linklst, did the refresh, 
etc and its not being picked up.

If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute ISPCCONF, 
it states that fact with todays date.

But if I try to setup for all users, it doesn’t...

Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon and 
the module is nowhere to be found, except where I generated it too.

Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module from 
2014.

Ive done this same thing in my 5-way sysplex and everything worked like I 
expected, but the lpar off by itself, it doesn’t.

Can someone shed light on what I'm missing?


I don't put this module to LNKLST or LPA. I just created small PDS 
loadlib just for the ISPF members and added this library to ISPLLIB.

It works. It's simple.

In your case it can be some duplicate member. Use ISRDDN or Mark 
Zelden's FINDMOD to find it .



--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

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

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

Re: ISPCFIGU not being used.

[Shaffer, Terri]

Ive verified the linklist dataset is where I generated the module, Ive done 
multiple ISRFIND and ISRDDN just to make sure my concatenations are what I 
expected.

,BROWSE   ,SYS2.USERMOD.LINKLIB(ISPCFIGU)
,Command ===>,
* Top of
.Ø..ISPCFIGU...o
س...
Ø..5695PMB01 ..Í-"
Ø.dØ..569623400 .
 ..q...q
ISPCFIGU480R800101/31/19<<< This is what I expect

This is where the utility placed the module with todays date and I can verify 
that if I load this to an ISPLLIB dataset.

What doesn’t work is if I try to pull the library from LINKLST.  Ive also 
verified my usermod library is 30cyls and in 1 extent.

Ive tried everything I can think of.. Even increasing the Sitewide Defaults 
Version Level number and still not pulling the right one.

This is what I get by default.

Current Configuration Table,
,,Keyword File :,SYS9.ISPF.KEYWORDS(ACW2)
,,Identifier . :,ISPCFIGU,,Level  . . . :,480R8001,
,,Compile Date :,2014/11/20,  ,Compile Time :,15:13,

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, January 31, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPCFIGU not being used.

External Email



W dniu 2019-01-31 o 19:18, Shaffer, Terri pisze:
> Hi,
>So I know I am missing something here as my predecessors did things 
> uniquely.  So here my dilemma...
>
> I generated a new ISPCFIGU module and put it into my linklst, did the 
> refresh, etc and its not being picked up.
>
> If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute 
> ISPCCONF, it states that fact with todays date.
>
> But if I try to setup for all users, it doesn’t...
>
> Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon 
> and the module is nowhere to be found, except where I generated it too.
>
> Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module 
> from 2014.
>
> Ive done this same thing in my 5-way sysplex and everything worked like I 
> expected, but the lpar off by itself, it doesn’t.
>
> Can someone shed light on what I'm missing?

I don't put this module to LNKLST or LPA. I just created small PDS loadlib just 
for the ISPF members and added this library to ISPLLIB.
It works. It's simple.

In your case it can be some duplicate member. Use ISRDDN or Mark Zelden's 
FINDMOD to find it .


--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

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

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

 [https://www.aciworldwide.com/-/media/aci-footer] 
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by 

[SPAM] Hmc for z as a virtual appliance?

[ITschak Mugzach]

I know power systems has one. Dies system z has such product?

ITschak

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

BPXPRM00 parmlib

[McCabe, Ron]

Hello,

If I need to make a change to my BPXPRM00 parmlib member can I get the change 
in while everything is running or does it have to done via an IPL?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw


Confidentiality Notice: This e- mail and all attachments may contain 
CONFIDENTIAL information and are meant solely for the intended recipient. It 
may contain controlled, privileged, or proprietary information that is 
protected under applicable law and shall not be disclosed to any unauthorized 
third party. If you are not the intended recipient, you are hereby notified 
that any unauthorized review, action, disclosure, distribution, or reproduction 
of any information contained in this e- mail and any attachments is strictly 
PROHIBITED. If you received this e- mail in error, please reply to the sender 
immediately stating that this transmission was misdirected, and delete or 
destroy all electronic and paper copies of this e-mail and attachments without 
disclosing the contents. This e- mail does not grant or assign rights of 
ownership in the proprietary subject matter herein, nor shall it be construed 
as a joint venture, partnership, teaming agreement, or any other formal 
business relationship.

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

Re: ISPCFIGU not being used.

[John Kelly]

Does sound like it could be a secondary extent in the link list lib

On Thu, Jan 31, 2019 at 1:18 PM Shaffer, Terri <
017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:

> Hi,
>   So I know I am missing something here as my predecessors did things
> uniquely.  So here my dilemma...
>
> I generated a new ISPCFIGU module and put it into my linklst, did the
> refresh, etc and its not being picked up.
>
> If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute
> ISPCCONF, it states that fact with todays date.
>
> But if I try to setup for all users, it doesn’t...
>
> Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon
> and the module is nowhere to be found, except where I generated it too.
>
> Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module
> from 2014.
>
> Ive done this same thing in my 5-way sysplex and everything worked like I
> expected, but the lpar off by itself, it doesn’t.
>
> Can someone shed light on what I'm missing?
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> terri.shaf...@aciworldwide.com
>
> 
>  [https://www.aciworldwide.com/-/media/aci-footer] <
> http://www.aciworldwide.com>
> This email message and any attachments may contain confidential,
> proprietary or non-public information. The information is intended solely
> for the designated recipient(s). If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email. Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited. Any opinions expressed
> in this email are those of the author personally.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Kelly

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

Re: Internal Coupling Channel on z13

[Jesse 1 Robinson]

Issuing DYNDISP THIN command on a CF with no shared CF engines gets

CF0505I DYNDISP command cancelled 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ravi Gaur
Sent: Thursday, January 31, 2019 12:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Internal Coupling Channel on z13

DYNDISP is recommended with THIN INTERRUPT for Non dedicated CF CPU ...like for 
our sandbox/dev systems we have non dedicated and we keep it thin for them 
while for production which has CF CPU dedicated it's good idea to keep it OFF 
...You may like to look at Z14 Configuration setup guide which well explained 
it and obviously to make these changes you will have to do it from HMC . 


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

Re: ISPCFIGU not being used.

[Edward Finnell]

===>isrddn m ispcconf

and ispcfigu
Have to look at the SEL panel and see what it is invoking and where it is 
invoking it from.
===>panelid on
In a message dated 1/31/2019 12:24:13 PM Central Standard Time, 
01a0403c5dc1-dmarc-requ...@listserv.ua.edu writes:
What library are you loading it to?

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

Re: zOSMF - how to enable plugins?

[R.S.]

Thank everyone who helped.

The trick was that IZUPRMxx was NOT READ during startup.
I had IZUPRM='PREV', but no IZU= entry in IEASYS.
In effect IZUPRM00 member existed, I added PLUGINS entry, but it was not 
read during IZUSVR1 startup.
I fixed it. Now the icons are not gray, but I lack some RACF ZMFAPLA 
resources, which I'm going to fix.


Another question: is it possible to enable such plugins without zOSMF 
recycle?

I'm curious about Import Manager features.

--
Radoslaw Skorupka
Lodz, Poland





W dniu 2019-01-31 o 16:27, R.S. pisze:

I just started (first time) zOSMF.
I want to use Network Configuration Assistant, however the icon is 
gray and plugin unavailable. Uninstalled task - IUZG437I.
I tried to use Import Manager to import this plugin. It ask me about 
property file. I have no idea what to provide.

Neither online help, nor RTFM helped me.

Any clue?




==

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

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

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

If you are not the addressee of this message:

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

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

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

Re: ISPCFIGU not being used.

[Jousma, David]

What library are you loading it to?   Out of that utility, I tell it to make a 
usermod, which I then apply, and the load module ends up in SISPLOAD.

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Thursday, January 31, 2019 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPCFIGU not being used.

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi,
  So I know I am missing something here as my predecessors did things uniquely. 
 So here my dilemma...

I generated a new ISPCFIGU module and put it into my linklst, did the refresh, 
etc and its not being picked up.

If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute ISPCCONF, 
it states that fact with todays date.

But if I try to setup for all users, it doesn’t...

Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon and 
the module is nowhere to be found, except where I generated it too.

Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module from 
2014.

Ive done this same thing in my 5-way sysplex and everything worked like I 
expected, but the lpar off by itself, it doesn’t.

Can someone shed light on what I'm missing?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://www.aciworldwide.com/-/media/aci-footer] 
 This email message and any attachments may 
contain confidential, proprietary or non-public information. The information is 
intended solely for the designated recipient(s). If an addressing or 
transmission error has misdirected this email, please notify the sender 
immediately and destroy this email. Any review, dissemination, use or reliance 
upon this information by unintended recipients is prohibited. Any opinions 
expressed in this email are those of the author personally.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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


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

ISPCFIGU not being used.

[Shaffer, Terri]

Hi,
  So I know I am missing something here as my predecessors did things uniquely. 
 So here my dilemma...

I generated a new ISPCFIGU module and put it into my linklst, did the refresh, 
etc and its not being picked up.

If I add the ISPCFIGU to my ISPLLIB, it works just fine.  And execute ISPCCONF, 
it states that fact with todays date.

But if I try to setup for all users, it doesn’t...

Ive searched all the LPA, LINKLST and other libraries in my TSO/ISPF logon and 
the module is nowhere to be found, except where I generated it too.

Yet when I execute the ISPCCONF  command, it tells me its ISPCFIGU module from 
2014.

Ive done this same thing in my 5-way sysplex and everything worked like I 
expected, but the lpar off by itself, it doesn’t.

Can someone shed light on what I'm missing?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://www.aciworldwide.com/-/media/aci-footer] 
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

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

Re: zOSMF - how to enable plugins?

[Dana Mitchell]

As I posted about several months ago,  do not try to use the Workflow 
'Customization for z/OSMF Plugins'   as it has the annoying habit of 
translating your entire IZUPRMxx  members to UPPER CASE!My PMR is still 
open,  they have recreated this phenomenon in the lab,  but they are still hard 
at work on it.  I am thinking of offering to tell them which PULL statements in 
the REXX is doing it...

Dana

On Thu, 31 Jan 2019 15:35:08 +, Jousma, David  wrote:

>Radoslaw,
>
>In SYS1.PARMLIB(or wherever you keep your IZUPRMxx members), update the 
>PLUGIN's statement.
>
>PLUGINS(INCIDENT_LOG, 
>COMMSERVER_CFG,   
>WORKLOAD_MGMT,
>RESOURCE_MON, 
>CAPACITY_PROV,
>SYSPLEX_MGMT, 
>ISPF) 
>

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

Re: Newbie SMP/E questions

[Bob Bridges]

Many, many thanks to all of you for your comments.  I've made a long list of 
quotes pulled from your emails and plan to go over them with the sysprog in 
tomorrow's meeting.  Then she goes away on vacation for a month, so I'll have 
lots of time to think, reread, ask more questions and peruse the documentation. 
 You probably won't hear many more questions from me for a while, therefore, 
but I'm certain to be back eventually.

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

/* A fanatic is someone who does what he knows God would do if God knew the 
facts of the case.  -found at http://www.algonet.se/~parlei/quotes.html */

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

Re: SYSAFF and SCHENV

[Anthony Hirst]

Looks like that got added in 2.1, we've been using SCHENV much longer than
that, but good to know, thank you.

On Thu, Jan 31, 2019 at 9:42 AM ITURIEL DO NASCIMENTO NETO <
ituriel.nascime...@bradesco.com.br> wrote:

> Not necessarily.
> If your JOBDEF is defined with CNVT_SCHENV=HONOR, convertion phase will be
> done at desired Lpar.
>
> Can be changed by $TJOBDEF, CNVT_SCHENV=HONOR or CNVT_SCHENV=IGNORE
>
> Atenciosamente / Regards / Saludos
>
> Ituriel do Nascimento Neto
> BANCO BRADESCO S.A.
> 4250 / DITI Engenharia de Software
> Sistemas Operacionais Mainframes
> Tel: +55 11 3684-9602 R: 49602 3-1404
> Fax: +55 11 3684-4427
>
>
>
> -Mensagem original-
> De: IBM Mainframe Discussion List  Em nome de
> Anthony Hirst
> Enviada em: domingo, 27 de janeiro de 2019 22:12
> Para: IBM-MAIN@LISTSERV.UA.EDU
> Assunto: Re: SYSAFF and SCHENV
>
> One difference that I haven't seen be mentioned is that SYSAFF controls
> all stages of JES2 processing, while the SCHED only controls execution
> phase, we've run into issues where subsystems aren't active on some LPARs
> and a job with a SCHED setting gets interpreted on that system you get a
> JCL error, only way to avoid that we've found is to code SYSAFF.  We keep
> the SCHED to because it points to the actual resource requirement adding
> documentation.
>
> On Sat, Jan 26, 2019 at 8:53 PM Peter  wrote:
>
> > Hi
> >
> > It is just general question
> >
> > I was going through the manual.
> >
> > Does SCHENV perform the same function as SYSAFF ? Or it does more than
> > that ?
> >
> > Peter
> >
> > --
> > 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
>
> AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s)
> pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou
> legalmente privilegiada. Se você não for destinatário desta mensagem, desde
> já fica notificado de abster-se a divulgar, copiar, distribuir, examinar
> ou, de qualquer forma, utilizar a informação contida nesta mensagem, por
> ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que
> nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu
> conteúdo em sua base de dados, registros ou sistema de controle. Fica
> desprovida de eficácia e validade a mensagem que contiver vínculos
> obrigacionais, expedida por quem não detenha poderes de representação.
> LEGAL ADVICE...This message is exclusively destined for the people to
> whom it is directed, and it can bear private and/or legally exceptional
> information. If you are not addressee of this message, since now you are
> advised to not release, copy, distribute, check or, otherwise, use the
> information contained in this message, because it is illegal. If you
> received this message by mistake, we ask you to return this email, making
> possible, as soon as possible, the elimination of its contents of your
> database, registrations or controls system. The message that bears any
> mandatory links, issued by someone who has no representation powers, shall
> be null or void.
>
> --
> 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

RES: SYSAFF and SCHENV

[ITURIEL DO NASCIMENTO NETO]

Not necessarily.
If your JOBDEF is defined with CNVT_SCHENV=HONOR, convertion phase will be done 
at desired Lpar.

Can be changed by $TJOBDEF, CNVT_SCHENV=HONOR or CNVT_SCHENV=IGNORE

Atenciosamente / Regards / Saludos

Ituriel do Nascimento Neto
BANCO BRADESCO S.A. 
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-9602 R: 49602 3-1404   
Fax: +55 11 3684-4427 



-Mensagem original-
De: IBM Mainframe Discussion List  Em nome de Anthony 
Hirst
Enviada em: domingo, 27 de janeiro de 2019 22:12
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: Re: SYSAFF and SCHENV

One difference that I haven't seen be mentioned is that SYSAFF controls all 
stages of JES2 processing, while the SCHED only controls execution phase, we've 
run into issues where subsystems aren't active on some LPARs and a job with a 
SCHED setting gets interpreted on that system you get a JCL error, only way to 
avoid that we've found is to code SYSAFF.  We keep the SCHED to because it 
points to the actual resource requirement adding documentation.

On Sat, Jan 26, 2019 at 8:53 PM Peter  wrote:

> Hi
>
> It is just general question
>
> I was going through the manual.
>
> Does SCHENV perform the same function as SYSAFF ? Or it does more than 
> that ?
>
> Peter
>
> --
> 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

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

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

Re: Delay for IP consoles after POR, but not IPL

[Nightwatch RenBand]

Brian and Ravi Thank-you. What you describe does indeed seem to be what I
am seeing.

On Thu, Jan 31, 2019 at 12:42 AM Ravi Gaur  wrote:

> We have seen this while z13 migration to z14 specially with the cable swa=
> ps for OSA ICC weren't showing active with SE and eventually with the POR=
>  (activate) for CEC brought them back online . It wasn't in the list as a=
>  activity to do but now with every cable swap we added POR activity ...no=
> t preferred but it bring all clean in one go instead of back and forth do=
> ing investigation on reasons...
>
> --
> 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: zOSMF - how to enable plugins?

[Jousma, David]

Radoslaw,

In SYS1.PARMLIB(or wherever you keep your IZUPRMxx members), update the 
PLUGIN's statement.

PLUGINS(INCIDENT_LOG, 
COMMSERVER_CFG,   
WORKLOAD_MGMT,
RESOURCE_MON, 
CAPACITY_PROV,
SYSPLEX_MGMT, 
ISPF) 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Thursday, January 31, 2019 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSMF - how to enable plugins?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I just started (first time) zOSMF.
I want to use Network Configuration Assistant, however the icon is gray and 
plugin unavailable. Uninstalled task - IUZG437I.
I tried to use Import Manager to import this plugin. It ask me about property 
file. I have no idea what to provide.
Neither online help, nor RTFM helped me.

Any clue?

--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

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

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

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

Re: zOSMF - how to enable plugins?

[Carmen Vitullo]

I had the same issues @ 2.1 - it's a little easier with 2.2 and parameter 
driven 
IIRC you can use the install process to add plugin if your 2.1 
with 2.2 and using the IZUPRMxx member I just added 

PLUGINS(COMMSERVER_CFG 
WORKLOAD_MGMT 
RESOURCE_MON 
CAPACITY_PROV 
SOFTWARE_MGMT 
ISPF) 



Carmen Vitullo 

- Original Message -

From: "R.S."  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, January 31, 2019 9:27:38 AM 
Subject: zOSMF - how to enable plugins? 

I just started (first time) zOSMF. 
I want to use Network Configuration Assistant, however the icon is gray 
and plugin unavailable. Uninstalled task - IUZG437I. 
I tried to use Import Manager to import this plugin. It ask me about 
property file. I have no idea what to provide. 
Neither online help, nor RTFM helped me. 

Any clue? 

-- 
Radoslaw Skorupka 
Lodz, Poland 




== 

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

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

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

If you are not the addressee of this message: 

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

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

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


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

zOSMF - how to enable plugins?

[R.S.]

I just started (first time) zOSMF.
I want to use Network Configuration Assistant, however the icon is gray 
and plugin unavailable. Uninstalled task - IUZG437I.
I tried to use Import Manager to import this plugin. It ask me about 
property file. I have no idea what to provide.

Neither online help, nor RTFM helped me.

Any clue?

--
Radoslaw Skorupka
Lodz, Poland




==

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

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

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

If you are not the addressee of this message:

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

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

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

Re: External dsect

[scott Ford]

I want to say thanks to everyone. My experience / knowledge has gaps so
when I have doubts or questions i come to this great repository of
experience to ask the questions.

Scott

On Wed, Jan 30, 2019 at 4:17 PM scott Ford  wrote:

> Don exactly.  I am having to reverse engineer a situation that was out of
> my control.
> I read what everyone said and i think the ECVT customer slot is much
> better.
> We dont provide our exit source, but we do provide framework in HLASM that
> includes a
> call to our actual code.
> Many years ago in a past life, we had external tables, tables that could
> be built and updated separate from
> the calling code. This was in a CICS program , i *think* because this was
> about 25+ yrs ago we had a
> CSECT and DSECT for the actual table. I dont feel sometime the older ways
> are so bad, but this is
> am opinion of course.
>
> Scott
>
> On Wed, Jan 30, 2019 at 9:14 AM Don Poitras  wrote:
>
>> In article <
>> of19ca4142.d70dd9b8-on85258392.0047a325-85258392.00483...@notes.na.collabserv.com>
>> you wrote:
>> > I do agree with all the posts that you should not do a LOAD in an exit.
>> > I'll quibble about the very title of this post. I'd say that there is
>> no
>> > such thing as an external dsect.
>>
>> Well, there is such a thing, but it's not what this thread is discussing.
>> A dsect is "external" if it is used like a DXD. i.e. the target of a
>> qcon.
>>
>> > A dsect is just a mapping. What you are talking about is simply an
>> > external CSECT of  DC's for which you provide a DSECT to map.
>> > The OP of course knows how to initialize a csect.
>> > A DSECT could be used to help guide where the DC's go if wanted (such
>> as
>> > by using ORG the_start+the_field_in_the_dsect). And of course the DSECT
>> > would be used to interpret the CSECT.
>> > If you're going to go the route of an initialized CSECT that a customer
>> > assembles, then you should probably provide a macro within the CSECT so
>> > that the customer is updating the macro (and the macro knows how to set
>> > the fields).
>> > Once the CSECT is initialized, there is only the question of whether it
>> is
>> > bound with your code (and thus addressable by v-con) or is located
>> > dynamically by your code.
>> > Peter Relson
>> > z/OS Core Technology Design
>>
>> --
>> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
>> sas...@sas.com   (919) 531-5637Cary, NC 27513
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
>
>
>
> *IDMWORKS *
>
> Scott Ford
>
> z/OS Dev.
>
>
>
>
> “By elevating a friend or Collegue you elevate yourself, by demeaning a
> friend or collegue you demean yourself”
>
>
>
> www.idmworks.com
>
> scott.f...@idmworks.com
>
> Blog: www.idmworks.com/blog
>
>
>
>
>
> *The information contained in this email message and any attachment may be
> privileged, confidential, proprietary or otherwise protected from
> disclosure. If the reader of this message is not the intended recipient,
> you are hereby notified that any dissemination, distribution, copying or
> use of this message and any attachment is strictly prohibited. If you have
> received this message in error, please notify us immediately by replying to
> the message and permanently delete it from your computer and destroy any
> printout thereof.*
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




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



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





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

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

Re: So long, farewell,Auf wiedersehen, goodbye

[Carmen Vitullo]

can't find Mark's original post...but, when I was laid off in 09 I found it 
difficult to find anything until I was contacted by IBM Global Services, at the 
time it was strictly work from home, communications was via email and 
conference calls, and a laptop provided by global services. my team and boss 
was great, although I never met anyone IRL. 


Carmen Vitullo 

- Original Message -

From: "Chris Hoelscher"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, January 31, 2019 8:34:23 AM 
Subject: Re: So long, farewell,Auf wiedersehen, goodbye 

Difficulties looking for a new employer?? Just give it ... time .. oh wait 

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


-Original Message- 
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht 
Sent: Thursday, January 31, 2019 7:04 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [IBM-MAIN] So long, farewell,Auf wiedersehen, goodbye 

Mark Jacobs wrote: 

>Tomorrow marks my last day at Time Customer Service as the closing of the 
>division is completed. 

Oh, this is bad! 


>After 8573 days, what a long strange trip its been. 

That is about 23 years and 6 months! With or without leap days? ;-) 


>I've close to retirement, but would like a few more years. Looking for remote 
>z/OS System Programmer positions seems to be harder than I initially thought 
>it would be, but I'm looking everyday. I subscribed to this mailing list (in 
>digest form) under my personal email address, so I'll be lurking around. 

Good luck and all of the very best to you. Please continue sharing your wisdom 
while you search for a position. 

I will miss you. 

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 

The information transmitted is intended only for the person or entity to which 
it is addressed 
and may contain CONFIDENTIAL material. If you receive this material/information 
in error, 
please contact the sender and delete or destroy the material/information. 

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and 
do not discriminate on the basis of race, color, national origin, age, 
disability, sex, 
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not 
exclude people or treat them differently because of race, color, national 
origin, age, 
disability, sex, sexual orientation, gender identity, or religion. 

English: ATTENTION: If you do not speak English, language assistance services, 
free 
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). 

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios 
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 
服務。請致電 1‐877‐320‐1235 (TTY: 711)。 

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd 
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). 

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej 
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. 


-- 
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: So long, farewell,Auf wiedersehen, goodbye

[Chris Hoelscher]

Difficulties looking for a new employer?? Just give it  ... time .. oh wait

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


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Thursday, January 31, 2019 7:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] So long, farewell,Auf wiedersehen, goodbye

Mark Jacobs wrote:

>Tomorrow marks my last day at Time Customer Service as the closing of the 
>division is completed.

Oh, this is bad!


>After 8573 days, what a long strange trip its been. 

That is about 23 years and 6 months! With or without leap days? ;-)


>I've close to retirement, but would like a few more years. Looking for remote 
>z/OS System Programmer positions seems to be harder than I initially thought 
>it would be, but I'm looking everyday. I subscribed to this mailing list (in 
>digest form) under my personal email address, so I'll be lurking around.

Good luck and all of the very best to you. Please continue sharing your wisdom 
while you search for a position.

I will miss you.

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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

Re: So long, farewell,Auf wiedersehen, goodbye

[Cameron Conacher]

Marc,
Good Luck. I am certain you will find what you are looking for.
Never Give Up.

On Wed, Jan 30, 2019 at 8:33 AM Mark Jacobs - Listserv <
mark.jac...@custserv.com> wrote:

> Tomorrow marks my last day at Time Customer Service as the closing of the
> division is completed. After 8573 days, what a long strange trip its been.
> I've close to retirement, but would like a few more years. Looking for
> remote z/OS System Programmer positions seems to be harder than I initially
> thought it would be, but I'm looking everyday. I subscribed to this mailing
> list (in digest form) under my personal email address, so I'll be lurking
> around.
>
> It's been a great experience talking to my peers over the years here and
> elsewhere.
> --
>
> Mark Jacobs
> Time Customer Service
> Global Technology Services
>
> The standard you walk past is the standard you accept.
> Lt. Gen. David Morrison
>
>
> This electronic message, including any attachments, may contain
> proprietary, confidential or privileged information for the sole use of the
> intended recipient(s). You are hereby notified that any unauthorized
> disclosure, copying, distribution, or use of this message is prohibited. If
> you have received this message in error, please immediately notify the
> sender by reply e-mail and delete it.
>
> --
> 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: So long, farewell,Auf wiedersehen, goodbye

[Elardus Engelbrecht]

Mark Jacobs wrote:

>Tomorrow marks my last day at Time Customer Service as the closing of the 
>division is completed.

Oh, this is bad!


>After 8573 days, what a long strange trip its been. 

That is about 23 years and 6 months! With or without leap days? ;-)


>I've close to retirement, but would like a few more years. Looking for remote 
>z/OS System Programmer positions seems to be harder than I initially thought 
>it would be, but I'm looking everyday. I subscribed to this mailing list (in 
>digest form) under my personal email address, so I'll be lurking around.

Good luck and all of the very best to you. Please continue sharing your wisdom 
while you search for a position.

I will miss you.

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

[Martin Packer]

(This thread has got quite long so pardon me if I repeat something someone 
else said.)

If you must run a PRODUCTION Coupling Facility LPAR on SHARED engines I 
would generally recommend turning DYNDISP off for that one LPAR. Set it to 
THIN for the non-Production ones it's forced to share with.

The reason is you don't want the Production CF to give up the engine in a 
particularly timely fashion - because another request might come in soon 
after the last one. For the Non-Prod ones you want THIN because you want 
them to get out of the way ASAP. However, the fact of sharing at all is 
the major destructive factor. THIN just mitigates it.

(The instrumentation to guide you on this is SMF74INT, R744PBSY and 
R744PWAI - which can be examined down to the engine level. Sometimes with 
value.)

But, as always, actual mainframe estate shape governs the decisions.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Ravi Gaur 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   31/01/2019 08:46
Subject:Re: Internal Coupling Channel on z13
Sent by:IBM Mainframe Discussion List 



DYNDISP is recommended with THIN INTERRUPT for Non dedicated CF CPU 
...like for our sandbox/dev systems we have non dedicated and we keep it 
thin for them while for production which has CF CPU dedicated it's good 
idea to keep it OFF ...You may like to look at Z14 Configuration setup 
guide which well explained it and obviously to make these changes you will 
have to do it from HMC . 

--
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: Using IPCS ACTIVE and alt ASID to display extended private storage

[Binyamin Dissen]

What it means is that the storage was in a task that went away. When you
split, it is using the storage again.

IPCS does not display unallocated virtual pages (as they do not really exist).

On Wed, 30 Jan 2019 16:14:37 -0600 Wendell Lovewell
<01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote:

:>The location I need to check (1B12D080) is also not in the SVC dump:
:>
:>BLSPDISD 62') ADDRESS(1B127C20.) STORAGE -
:>Command ===>  SCROLL ===> CSR
:>1B127C20   C500   001B1271   B004   F50103D4   | E...5..M |
:>1B127C30   D6C4C9C9   C9D540E3   D9C1D3FF   FF00   | ODIIIN TRAL. |
:>1B127C40.:1B127FFF.--All bytes contain X'00'
:>1B128000.:1B12.--Storage not available
:>1B13   F3F5   0051C4E2   D7C7C3D6   D940C7C3   | 35DSPGCOR GC |
:>1B130010   D9F1         2000   | R0.. |
:>1B130020   001E   206C1AD2   5000      | .%.K&... |
:>
:>(I specified ASID=62,SDATA=RGN for the DUMP options.)
:>
:>However, if I issue an ISPF START command from the TSO userid running the 
application, and use IPCS from there to display ACTIVE storage (for that user's 
ASID--62), the memory is still allocated:
:>
:> BLSPDISD 62') ADDRESS(1B12D080.) STORAGE --
:> Command ===>  SCROLL ===> CSR
:> 1B12D080   00516000   00516000   011E   1B53A000   | ..-...-. |
:> 1B12D090   1B12D078         1B12D078   | ..}...}. |
:> 1B12D0A0   00D9   00D9   1B12D0F0      | ...R...R..}0 |
:> 1B12D0B0   1B12D3C0   1B12C808         | ..L{..H. |
:> 1B12D0C0   1B12B498   0007         | ...q |
:> 1B12D0D0.:1B12D0DF.--All bytes contain X'00'
:>
:>I don't know how to explain this mystery, but I think I can manage by using 
IPCS in the second session.  I appreciate your help Benjamin--thanks for all 
your help. 

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: IZUSVR1 failed after new PTFs applied

[Ravi Gaur]

Not sure if you have message seen as "+IZUG019E The AUTOSTART_GROUP NONE 
doesn't match the one x specified for AUTOSTART in IPL." 
if you have IZU=(00,xx) specified in the IEASYSxx member where some of the 
parms you are overriding...if so look at the very recent APAR opened "PH07842" 
after we saw it in our environment .

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

Re: A new LPAR entry in a existing IODF

[Ravi Gaur]

As illustrated you can't touch the PROD iodf since as soon as you try to make 
any changes HCD will force you to create WORK IODF . same goes with the IOCDS 
Slot which won't let you override the existing active iocds slotanyway so 
your question regarding creating a duplicate(with different partition name) you 
 can use "Repeat (copy) partitions " which underline let you carry 
chip/cu/dev/osa/ica etc. configuration obviously you will have to retune the 
configuration on the new partition as per your requirement.

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

Re: Internal Coupling Channel on z13

[Ravi Gaur]

DYNDISP is recommended with THIN INTERRUPT for Non dedicated CF CPU ...like for 
our sandbox/dev systems we have non dedicated and we keep it thin for them 
while for production which has CF CPU dedicated it's good idea to keep it OFF 
...You may like to look at Z14 Configuration setup guide which well explained 
it and obviously to make these changes you will have to do it from HMC .

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

Re: Delay for IP consoles after POR, but not IPL

[Ravi Gaur]

We have seen this while z13 migration to z14 specially with the cable swaps for 
OSA ICC weren't showing active with SE and eventually with the POR (activate) 
for CEC brought them back online . It wasn't in the list as a activity to do 
but now with every cable swap we added POR activity ...not preferred but it 
bring all clean in one go instead of back and forth doing investigation on 
reasons...

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

Re: Tape Mount Mangement

[Vernooij, Kees (ITOP NM) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 30 January, 2019 20:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Tape Mount Mangement
> 
> On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:
> >
> >My other impression is it's simpler to change gazillion (usually less)
> >of JCL jobs to explicitly point datasets to DASD than using TMM.
> >
> Might a JCLLIB member that SETs a few JCL symbols facilitate this?
> Reduce a gazillion to a handful?  Nowadays JCL symbols can even
> be resolved in SYSIN.

That would require changing a gazillion jobs to insert symbols. Intercepting 
them in the ACS routines is much easier.
For that reason I have stopped educating customers, I inforce in my ACS 
routines what I want.

Kees.

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

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



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