AW: Re: LE strikes again

[Peter Hunkeler]

>>>You can also use a JCL statement to override (if available) LE Parms.
>>>
>>> https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/ceedd.htm
>>
>>
>>No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and 
>>Norbert Friemel remembered me it's not yet supported at that release.
 >
>From a security point of view, your customer is asking for disaster if
>the system has any direct or indirect connection to the Internet.  The
>lack of integrity fixes alone is a major exposure.


Clark,

I'm missing how your comment is related to this thread, and especially to my 
post.


--
Peter Hunkeler

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

Re: DB2 Ver. 8.1 running on z/OS 2.1?

[Patrick Falcone]

Thanks Tomothy, 

Your below is on target, appreciate your input and will take into consideration 
information provided.  

  From: Timothy Sipples 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Sunday, July 9, 2017 12:40 AM
 Subject: Re: DB2 Ver. 8.1 running on z/OS 2.1?
   
Lucas,

I think Patrick already did that, or the equivalent. And he found (or would
have found) that DB2 Version 8 for z/OS and z/OS Version 2.1 never
overlapped in their support lifecycles. The former fell out of standard
support in 2012, and the latter became generally available in 2013.

So he's looking for anecdotal reports whether that particular combination
works, unsupported of course.

I assume the concern is application compatibility and some problems getting
applications ready/tested on a newer DB2 release. In that event, as a
*temporary* workaround, I have a suggestion. DB2 Version 9 for z/OS and
z/OS 2.1 did overlap in their support lifecycles -- that was a supported
combination. You could run DB2 Version 9 in Conversion Mode until you can
get your applications ready and tested, hopefully soon, quickly. That's
assuming you're already running DB2 Version 8 in New Function Mode. DB2
Conversion Mode is designed as a "don't rock the boat" level of
compatibility for applications.

DB2 Version 9 is also out of support, so it doesn't help in that respect.
But at least that combination was officially supported until June 27, 2014.
DB2 9 also happens to be more efficient than DB2 8, so that's a plus.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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

   

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

Re: DB2 Ver. 8.1 running on z/OS 2.1?

[Patrick Falcone]

Thanks Lucas, I did find this link and also a post from the archives of someone 
running DB2 V8 with z/OS 2.2 this past weekend. 

While the link is very useful I was actually curious if others were running 
similar.

  From: Lucas Rosalen 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Saturday, July 8, 2017 2:42 AM
 Subject: Re: DB2 Ver. 8.1 running on z/OS 2.1?
   
Hello Patrick,

An interesting link to check supported levels is =>
https://www.ibm.com/software/reports/compatibility/clarity/index.jsp
You can report on software, or on Operating System or even cross-ref both.

Have fun,

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2017-07-07 20:42 GMT+02:00 Patrick Falcone <
012526080649-dmarc-requ...@listserv.ua.edu>:

> Anyone running DB2 version 8.1 on z/OS 2.1? I'm looking to verify, any
> links or information would be appreciated. Thank You.
>



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

Performance question #3

[Phil Smith]

>From PofOp:
The set-address-space-control-fast facility consists of the SET ADDRESS SPACE 
CONTROL FAST (SACF) instruction, which possibly can be used instead of the 
previously existing SET ADDRESS SPACE CONTROL (SAC) instruction, depending on 
whether all of the SAC functions are required. SACF, unlike SAC, does not 
perform the serialization and checkpoint-synchronization functions, nor does it 
cause copies of prefetched instructions to be discarded. SACF provides improved 
performance on some models.

OK, so ... "on some models". Is this one of those "It used to matter, but 
doesn't any more" deals, or should we still think about using SACF when 
appropriate? I did find this in an old post to ASM370-L:
As I understand it SACF was only implemented (as different from SAC) on a few 
models. The basic difference in how the instruction prefetch queue is handled. 
If you are not modifying the instruction stream or switching from home to 
primary (which causes instruction fetch to load from a different memory) there 
should not be a difference.

And do the serialization caveats mean that in cases where we have absolutely no 
expectation of data change in the target address space (as in, "If they do that 
after calling us, all bets are off anyway"), SACF would be appropriate?

Thanks for any insights!
--

...phsiii


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

Re: LE strikes again

[Clark Morris]

[Default] On 10 Jul 2017 12:31:53 -0700, in bit.listserv.ibm-main
p...@gmx.ch (Peter Hunkeler) wrote:

>>You can also use a JCL statement to override (if available) LE Parms. 
> >
>> https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/ceedd.htm
>>  
>
>
>No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and 
>Norbert Friemel remembered me it's not yet supported at that release.

From a security point of view, your customer is asking for disaster if
the system has any direct or indirect connection to the Internet.  The
lack of integrity fixes alone is a major exposure.

Clark Morris
>-- 
>Peter Hunkeler 

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

Re: EAV volumes and SYSRES

[Gibney, Dave]

z/OSMF assumes access to zIIP. Otherwise, the Java CPU load on general CP's 
impacts the SCRT reports, or runs up on the cap.

I have not zIIP on my z9 and we did not include access to them in the MFaaS 
contract we are mobbing to.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Monday, July 10, 2017 10:41 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EAV volumes and SYSRES
> 
> R.S. wrote:
> > W dniu 2017-07-10 o 16:13, John Eells pisze:
> >> [...]
> >>> 4. What about ServerPac Installation Dialog? Does it support EAV yet?
> >>
> >> It does not.  It likely will never do so.  We are moving in a
> >> different direction, with z/OSMF Software Management as our installer
> >> in a few years, I hope.
> >
> > That's bad news for me. I don't like z/OSMF and truly hate its setup.
> > All installations I know do not use it.
> >
> 
> At the last SHARE, the question was asked at the multivendor installation-
> related session about how many in the room were z/OSMF users.  In the past,
> I've seen those raising a hand to be perhaps 25% of a similarly-sized crowd,
> but in March about 2/3 of those present raised a hand (a pleasant surprise).
> Of course, one room at SHARE does not a valid statistical sample make, but
> it's one data point.
> 
> I'll also say that I have personally combed through the z/OSMF setup for
> Software Management and Cloud Provisioning (starting with "no z/OSMF"),
> and it's far better than it used to be.  I think you will see some 
> documentation
> improvements we have been working on fairly soon as well, which should
> also help.
> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: LE strikes again

[Peter Hunkeler]

>You can also use a JCL statement to override (if available) LE Parms.
 >
> https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/ceedd.htm


No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and 
Norbert Friemel remembered me it's not yet supported at that release.
--
Peter Hunkeler


--
Peter Hunkeler

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

Re: Friday question: ISPF Statistics Manipulation

[Paul Gilmartin]

On Mon, 10 Jul 2017 09:27:07 -0500, Walt Farrell wrote:

>On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:
>
>>That's what I mean by 'used as evidence'. And I wondered if it is just my 
>>ignorance or if there really is no way (as I suspected) to 
>>prevent unauthorized changing of the statistics. 
>
>There is no way to do that without installing an add-on product.
> 
Such a product would need to have many tentacles in the system.
I could imagine unloading a PDS with IEBCOPY; tweaking the stats
in the PDSU directory image, and reloading.  It would need to prevent
that.  Where might it intervene to do so?

-- gil

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

Re: DELETING DSN IN A SYSPLEX

[Lizette Koehler]

My favorite GRS command is

D GRS,RES=(*,datasetname)

It will usually show holders

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of esmie moo
> Sent: Monday, July 10, 2017 4:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DELETING DSN IN A SYSPLEX
> 
> Gentle Readers,
> I am trying to delete a dsn which is in a SYSPLEX.  When I attempt to do so
> (via ISPF 3.4) I receive the message that the dsn is in use.I hit PF1 to get
> further information and then type HELP (as per prompt) and it shows that it
> is in use by the folliwng 2 user(s) and/or jobs(s)However when |I check iin
> SDSF niether the job nor the user is displayed.
> Is there a way of deleting the dsn?
> Thanks
> 

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

Re: Friday question: ISPF Statistics Manipulation

[Don Leahy]

I once wrote a blog on this topic on the company's internal social media
site.  I called it "Lies, damned lies and Member List Statistics". :-)

On Mon, Jul 10, 2017 at 10:27 AM Walt Farrell 
wrote:

> On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:
>
> >That's what I mean by 'used as evidence'. And I wondered if it is just my
> ignorance or if there really is no way (as I suspected) to
> >prevent unauthorized changing of the statistics.
>
> There is no way to do that without installing an add-on product.
>
> --
> Walt
>
> --
> 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: EAV volumes and SYSRES

[Lizette Koehler]

@John Eells

We would not consider using z/OSMF for creating SYSRES volumes or rolling out
fixes.  It does not allow for our Naming convention for Datasets to work with
it.

Our naming convention should not be usurped by any vendor to use their tools.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Eells
> Sent: Monday, July 10, 2017 7:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EAV volumes and SYSRES
> 
> R.S. wrote:
> > [...]
> > List -
> >> Just curious if the EAV volumes can be used for SYSRES volumes or if
> >> there are any concerns with using them for SYSRES volumes?
> >>
> >> If they can be used for SYSRES, any considerations with using them?
> >>
> >>
> >>
> >> Just looking for advise.
> >
> > IMHO there are few things to consider:
> >
> > 1. EAV consist of EAS (upper space) and traditional "track-addressable"
> > space. SYSRES and probably everything else can be placed below the
> > line of 65520 cyl, because it is regular "legacy" 3390-54 volume.
> 
> True.
> 
> > 2. What can be placed "above the line" (that means in EAS)? That's the
> > question. I would not try to place there any of operational datasets
> > like RACF db, logrec archive, SYS1.MANx, etc. UNLESS it is clearly
> > documented.
> 
> Right.  Not sure we have documented this well, though, so if you find some
> missing things, please submit RCFs.
> 
> >  From the other hand - SYSRES is NOT the place for operational datasets!
> 
> I certainly agree!
> 
> > This is a room for target libraries. I would not worry about non-LPA
> > and non-LNKLST libraries and non-IPL_LNKLST (dynamically added) libraries.
> > And most non-executable (RECFM=U) libraries.
> 
> For this and #3, see the list I posted in response to Lizette's original
> post.
> 
> > 3. What about ZFS and HFS? I would check it again, but IMHO all of
> > them can be placed in EAS.
> >
> > 4. What about ServerPac Installation Dialog? Does it support EAV yet?
> 
> It does not.  It likely will never do so.  We are moving in a different
> direction, with z/OSMF Software Management as our installer in a few years, I
> hope.
> 
> 
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
> 

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

Re: LE strikes again

[Lizette Koehler]

You can also use a JCL statement to override (if available) LE Parms.

https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea50
0/ceedd.htm



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Monday, July 10, 2017 7:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: LE strikes again
> 
> >The CEEOPTS-DD-statement was new in z/OS 1.7
> 
> 
> Ooops..., I forgot about this fact. Too long ago.
> 
> 
> Can you try the TRAP(OFF) via EXEC PARM? For C, I believe LE PARMs come
> before program options in the PARM and have to end with a slash /
> 
> 
>  --
> Peter Hunkeler
> 
> 

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

Re: EAV volumes and SYSRES

[John Eells]

R.S. wrote:

W dniu 2017-07-10 o 16:13, John Eells pisze:

[...]

4. What about ServerPac Installation Dialog? Does it support EAV yet?


It does not.  It likely will never do so.  We are moving in a
different direction, with z/OSMF Software Management as our installer
in a few years, I hope.


That's bad news for me. I don't like z/OSMF and truly hate its setup.
All installations I know do not use it.



At the last SHARE, the question was asked at the multivendor 
installation-related session about how many in the room were z/OSMF 
users.  In the past, I've seen those raising a hand to be perhaps 25% of 
a similarly-sized crowd, but in March about 2/3 of those present raised 
a hand (a pleasant surprise).  Of course, one room at SHARE does not a 
valid statistical sample make, but it's one data point.


I'll also say that I have personally combed through the z/OSMF setup for 
Software Management and Cloud Provisioning (starting with "no z/OSMF"), 
and it's far better than it used to be.  I think you will see some 
documentation improvements we have been working on fairly soon as well, 
which should also help.


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

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

Re: Question re: MXG-L post "common storage usage question"

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>> Wasn't this asked here recently? Check the archives.

>Sorry, I missed that one. My excuse is: Been on holiday :-)--

But does that discussion started by Rex Pommier relates to that two APARs?

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: EAV volumes and SYSRES

[Elardus Engelbrecht]

Radoslaw Skorupka wrote:

>I don't like z/OSMF and truly hate its setup. All installations I know do not 
>use it.

Welcome in my company, now then you will also really truly fully hate hate HATE 
OMEGAMON and NETVIEW with all its octopus-like children systems with all its 
sucking tentacles...

At least some hurting PITA things are at least shared by different teams. Each 
team is struggling with his own part (RACF, OMVS, Base z/OS, TCP/IP, SMS team)

We discarded NETVIEW because it is a hungry pacman-hog - it ate memory, CPU, 
disk and slowing JES2 by constantly scanning SYSLOG to intercept messages...

Mind you, I'm not blaming big blue, it is just that to get these products 
working, it is a full time project lasting a long time. But, once you get them 
working and in production, they're real marvels.

Now, my RACF part for z/OSMF is finished, it is other teams turn to have this 
nice PITA... ;-[

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: EAV volumes and SYSRES

[R.S.]

W dniu 2017-07-10 o 16:13, John Eells pisze:

[...]

4. What about ServerPac Installation Dialog? Does it support EAV yet?


It does not.  It likely will never do so.  We are moving in a 
different direction, with z/OSMF Software Management as our installer 
in a few years, I hope.


That's bad news for me. I don't like z/OSMF and truly hate its setup. 
All installations I know do not use it.


--
Radoslaw Skorupka
Lodz, Poland




==


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

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: DELETING DSN IN A SYSPLEX

[Elardus Engelbrecht]

esmie moo wrote:

>I was able to delete the dsn by renaming it first and then deleting it because 
>I had the STGADMIN.**. authorization.  The dsn was SYS1.CICS2.MODINTR

Thanks, I'm glad you could resolve your trouble, but your dataset is a SYS1 and 
is looking if it is used by a CICS system...

I hope you are not breaking some bread and butter things, but if that dataset 
is a duplicate of live dataset as per Kees kind suggestion, then your actions 
_may_ look Ok.

Could you discover who or what is holding your dataset with an big iron grip? [ 
pun intended ;-D ]


>Thanks to you and Kees who helped out.

I would also like to thank Kees for reminding me (and you) about that specific 
GRS thing. 

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: Question re: MXG-L post "common storage usage question"

[Peter Hunkeler]

> Wasn't this asked here recently? Check the archives.


Sorry, I missed that one. My excuse is: Been on holiday :-)--
Peter Hunkeler

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

Re: AW: Re: EAV volumes and SYSRES

[R.S.]

W dniu 2017-07-10 o 18:01, Peter Hunkeler pisze:

I have lost track of this for a few years, but when I last knew, these
things *were* supported in EAS:

  >

- PDS and PDSE (including load modules and program objects)
- Plain vanilla (nonextended format) sequential
- BDAM


But as you wrote, it also depends on the software accessing the data. I was 
involved in installing a new product which abended in a stange way. It turned 
out it was because one of the configuration data set (I think a PS) was  in the 
EAS space, and the software was using some elder C based framework to read the 
data. That framework did not support data sets in EAS.


As always, it depends on the software and the system software was always 
big exception whe compared to regular application software.

There are many of exceptions:
SYS1.MANx dasets shouldn't have secondary extents, also RACF db, JES 
CKPT and SPOOL, etc.

No serialization for RACF db, JES datasets, etc.
No PDSE in LPA

That's why VVDS, ICF BCS (catalogs), LPA, LNKLST, RACF db etc. are 
separatly enumerated, despite it is VSAM, PDS/PDSE, PS.


The rule is quite simple: if given type of dataset cannot be (... - EAS 
is one of examples), then you're 99% sure a system dataset of this type 
also cannot be (...). However this is necessary, but not sufficient 
condition.


--
Radoslaw Skorupka
Lodz, Poland




==


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

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

AW: Re: EAV volumes and SYSRES

[Peter Hunkeler]

> I have lost track of this for a few years, but when I last knew, these
> things *were* supported in EAS:
 >
> - PDS and PDSE (including load modules and program objects)
> - Plain vanilla (nonextended format) sequential
> - BDAM


But as you wrote, it also depends on the software accessing the data. I was 
involved in installing a new product which abended in a stange way. It turned 
out it was because one of the configuration data set (I think a PS) was  in the 
EAS space, and the software was using some elder C based framework to read the 
data. That framework did not support data sets in EAS.


--
Peter Hunkeler



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

Re: Question re: MXG-L post "common storage usage question"

[Tom Marchant]

On Mon, 10 Jul 2017 14:43:00 +0200, Peter Hunkeler wrote:

>Below text was posted on MXG-L recently. It made me curious, so I tired 
>to read the APARs mentioned. Unfortunately, IBM's support site does not 
>have them (for public access) anymore.
>Can someone shed some light on this? What was the original problem? 
>Why did it increase CPU time for many STCs *over time*? What path 
>length was increased. Just curious.

Wasn't this asked here recently? Check the archives.

-- 
Tom Marchant

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

Re: DELETING DSN IN A SYSPLEX

[esmie moo]

Elardus,
I was able to delete the dsn by renaming it first and then deleting it because 
I had the STGADMIN.**. authorization.  The dsn was SYS1.CICS2.MODINTR
Thanks to you and Kees who helped out.

  From: Elardus Engelbrecht 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, July 10, 2017 8:36 AM
 Subject: Re: DELETING DSN IN A SYSPLEX
   
Vernooij, Kees wrote:

"Dsn in use" is not an security issue, it is a GRS issue. 

It is indeed so. Thanks. 


>Datasets are serialized by their dsname only. If you have different datasets 
>on different volumes with the same dsname, they will be serialized. 

Ah, yes, thanks for chiming in. I totally forgot about that part. It is a long 
time ago we have such duplicate names.


>You can delete the dsname by telling GRS to keep this dataset local.

To Esmie, you need to logon on ALL and every LPAR and check it on SDSF.

Or you can run a batch job with DISP=(OLD,DELETE) and then you will see the job 
is standing still. You can then issue a D GRS,C command. Of course, you need to 
cancel that job and then those dsn grabbers too.

Groete / Greetings
Elardus Engelbrecht
 

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

   

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

AW: Re: LE strikes again

[Peter Hunkeler]

>The CEEOPTS-DD-statement was new in z/OS 1.7


Ooops..., I forgot about this fact. Too long ago.


Can you try the TRAP(OFF) via EXEC PARM? For C, I believe LE PARMs come before 
program options in the PARM and have to end with a slash /


 --
Peter Hunkeler



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

Re: Friday question: ISPF Statistics Manipulation

[Walt Farrell]

On Mon, 10 Jul 2017 00:49:13 -0500, Barbara Nitz  wrote:

>That's what I mean by 'used as evidence'. And I wondered if it is just my 
>ignorance or if there really is no way (as I suspected) to 
>prevent unauthorized changing of the statistics. 

There is no way to do that without installing an add-on product.

-- 
Walt

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

Re: Orhan control block in a FIFO chain

[Donald Likens]

Ed... You may have found the problem... I had defined the PLT in CSA but never 
set R1. Changed the programs and testing (but of course if it works it really 
will not show anything because testing in our environment always worked).

I have asked for more CPs on our VM system.

Testing with multiple inputs did not show the problem.

THANKS!

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

Re: EAV volumes and SYSRES

[John Eells]

R.S. wrote:

[...]
List -

Just curious if the EAV volumes can be used for SYSRES volumes or if
there are any concerns with using them for SYSRES volumes?

If they can be used for SYSRES, any considerations with using them?



Just looking for advise.


IMHO there are few things to consider:

1. EAV consist of EAS (upper space) and traditional "track-addressable"
space. SYSRES and probably everything else can be placed below the line
of 65520 cyl, because it is regular "legacy" 3390-54 volume.


True.


2. What can be placed "above the line" (that means in EAS)? That's the
question. I would not try to place there any of operational datasets
like RACF db, logrec archive, SYS1.MANx, etc. UNLESS it is clearly
documented.


Right.  Not sure we have documented this well, though, so if you find 
some missing things, please submit RCFs.



 From the other hand - SYSRES is NOT the place for operational datasets!


I certainly agree!


This is a room for target libraries. I would not worry about non-LPA and
non-LNKLST libraries and non-IPL_LNKLST (dynamically added) libraries.
And most non-executable (RECFM=U) libraries.


For this and #3, see the list I posted in response to Lizette's original 
post.



3. What about ZFS and HFS? I would check it again, but IMHO all of them
can be placed in EAS.

4. What about ServerPac Installation Dialog? Does it support EAV yet?


It does not.  It likely will never do so.  We are moving in a different 
direction, with z/OSMF Software Management as our installer in a few 
years, I hope.



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

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

Re: EAV volumes and SYSRES

[John Eells]

Lizette Koehler wrote:

List -

Just curious if the EAV volumes can be used for SYSRES volumes or if there are 
any concerns with using them for SYSRES volumes?

If they can be used for SYSRES, any considerations with using them?


Well, yes.  Every data set type we use to distribute software is, I 
believe, supported above the line (i.e., in the EAS).  But that does not 
mean that all the users of all those data sets tolerate the different 
format of the cylinder address.


It's certainly safest to put any system software run-time (target 
library or file system) for which we do not explicitly document support 
in the EAS below the line on an EAV.  This is what I'd recommend for 
now.  However, I am not sure we actually put this information into the 
books (vs. only adding it to the announcements).


I have lost track of this for a few years, but when I last knew, these 
things *were* supported in EAS:


- PDS and PDSE (including load modules and program objects)
- Plain vanilla (nonextended format) sequential
- BDAM
- GDG
- LPALIB
- LPA list data sets
- Link list data sets
- SYSn.IPLPARM
- Catalogs
- VVDSs
- JES2 and JES3 spool and checkpoint, JES3 JCT
- DFSMSrmm data sets
- DFSMShsm data sets
- Standalone Dump data sets
- VSAM

...and these things *were not* supported in EAS:

- Imbed and Keyrange attributes, incompatible CA sizes for VSAM
- NUCLEUS
- SVCLIB
- LOGREC
- VTOC and VTOCIX,
- RACF databases
- Page data sets
- HFS data sets
- Parmlib concatenation data sets
- XRC Control, Master, or Cluster non-VSAM data sets

Some of the things on the second list could have migrated to the first 
while I wasn't looking specifically at these lists.  However, from my 
memory of release plans since z/OS V1.12 (when I last updated the lists 
above), I am moderately confident that none of them have, with the 
possible exception of SVCLIB, which I found on both lists (oops).


Obviously, at least to me, some of the things on the first list do not 
*belong* on the IPL volume, including any operational data set.


You can also put all the DLIBs above the line, since they are processed 
by system utilities that understand how to address data in the EAS.  The 
same goes for SMP/E CSI data sets and volume-specific user catalogs, 
which can live on the volumes they represent.


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

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

Re: LE strikes again

[Norbert Friemel]

On Mon, 10 Jul 2017 14:49:10 +0200, Peter Hunkeler wrote:

>
>Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin 
>data to that.This will turn off LE's ESTAE and ESPIE routines, so you should 
>get a dump of the original problem.
>

The CEEOPTS-DD-statement was new in z/OS 1.7

On Mon, 10 Jul 2017 18:20:16 +0700, Robin Atwood wrote:

>
>z/OS 1.4 on a z850 so when I received the dump I confidently expected the
>PSW to be pointing at an unsupported
>

Norbert Friemel

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

Re: LE strikes again

[Robin Atwood]

We tried that and it didn't make any difference. Using the IPCS LEDATA exit
with CEEDUMP tells us there there is no LE environment, which is strange
since the main module is XL/C.

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: 10 July 2017 19:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: LE strikes again

> logs at job end, so the only way I could get any kind of dump was to ask
them to set a SLIP trap. So why don't I get a dump of the original 0C1?
Looking at the system trace produces: 


Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin
data to that.This will turn off LE's ESTAE and ESPIE routines, so you should
get a dump of the original problem.

-- 
Peter Hunkeler






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

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

Re: Question re: MXG-L post "common storage usage question"

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>Below text was posted on MXG-L recently. It made me curious, so I tired (sic) 
>to read the APARs mentioned. Unfortunately, IBM's support site does not have 
>them (for public access) anymore. Can someone shed some light on this? What 
>was the original problem? Why did it increase CPU time for many STCs *over 
>time*? What path length was increased.

I looked around in IBM 'My Support' pages, and find this snippet from z/OS 
Parallel Sysplex Configuration Overview (SG24-6485-00) 

I see this:

"Note: The WLM service that added dynamic application environments is a 
prerequisite for WebSphere Application Server for z/OS Version 6.0.1. See SPE 
(APAR OW54622, included in z/OS Version 1.5 and above), which is described at:

http://www-1.ibm.com/support/docview.wss?uid=isg1OW54622;

I just get a 'Our apologies...' statement.


I see other references, but they are about WebSphere which requires that WLM 
APAR, like thise RedBook 'Problem Avoidance for WebSphere Application Server 
for z/OS.' (First Edition (March 2006))

It states:

"The dynamic WLM application environment is a function of WLM that became 
available when APAR OW54622 was made available for Workload Manager. It is 
incorporated into z/OS Version 1.5 and later. With the new WLM function, 
programs can dynamically create application environments on the fly."

Sorry, Nothing more information. Perhaps you need a formal request to IBM?

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

AW: LE strikes again

[Peter Hunkeler]

> logs at job end, so the only way I could get any kind of dump was to ask them 
> to set a SLIP trap. So why don't I get a dump of the original 0C1? Looking at 
> the system trace produces:


Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin 
data to that.This will turn off LE's ESTAE and ESPIE routines, so you should 
get a dump of the original problem.

--
Peter Hunkeler






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

Question re: MXG-L post "common storage usage question"

[Peter Hunkeler]

Below text was posted on MXG-L recently. It made me curious, so I tired to read 
the APARs mentioned. Unfortunately, IBM's support site does not have them (for 
public access) anymore.
Can someone shed some light on this? What was the original problem? Why did it 
increase CPU time for many STCs *over time*? What path length was increased. 
Just curious.
Peter



Posted on MXG-L
My 2003 Newsletter has this note:

29. APAR OW54622 introduced an SQA overflow into CSA condition that
increased CPU time for many STCs over time; the new GETMAIN larger
than FREEMAIN was corrected by APAR OW55360.  It has long been known
that when SQA is too small and expands into the CSA area, path
lengths are dramatically increased; you can detect this condition in
MXG dataset TYPE78VS variables SQAEXPNx.


Unfortunately, I do NOT know if that statement with regard to increased
CPU time due to path length when there is an overflow is still true, and
I can't find the "long known" source.


--
Peter Hunkeler



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

Re: DB2 Ver. 8.1 running on z/OS 2.1?

[Avram Friedman]

DB2 V8 and z/OS 2.2 is a hopeful combination.
Disregard the vendor support experts
And look at it this way

DB2 V10 allowed for skip migration from V8
V10 CM mode is 100% compatable with V8
V10 is supported today and run with z/OS 2.2

So
Thank you for being a long term DB2 customer.
If you are not paying continues maintsnce fees
Congrats on your frugle and effective choice in these hard times
If you hold a paid up license I suggest ordering V10 asap
V10 is a couple months from EOS and you need V10 if you ever expect to gget to 
newer versions

Should you choose to do the upgrade the specialized contractor skills for a 
work from home contractor will run from 
250K to 500K at this point.

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

Re: DELETING DSN IN A SYSPLEX

[Elardus Engelbrecht]

Vernooij, Kees wrote:

"Dsn in use" is not an security issue, it is a GRS issue. 

It is indeed so. Thanks. 


>Datasets are serialized by their dsname only. If you have different datasets 
>on different volumes with the same dsname, they will be serialized. 

Ah, yes, thanks for chiming in. I totally forgot about that part. It is a long 
time ago we have such duplicate names.


>You can delete the dsname by telling GRS to keep this dataset local.

To Esmie, you need to logon on ALL and every LPAR and check it on SDSF.

Or you can run a batch job with DISP=(OLD,DELETE) and then you will see the job 
is standing still. You can then issue a D GRS,C command. Of course, you need to 
cancel that job and then those dsn grabbers too.

Groete / Greetings
Elardus Engelbrecht
 

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

Re: DELETING DSN IN A SYSPLEX

[Elardus Engelbrecht]

esmie moo wrote:

>I am still unable to delete it.  I think I will need specific security 
>clearance.

Careful, perhaps you should post the name of that dataset(s) and what 
users/jobs are grabbing it in a secure hold.

Perhaps, with FACILITY Class profile STGADMIN.DPDSRN.** you can try to RENAME 
it.

I'm still looking for that profile which enable you to DELETE it while in use...

But, perhaps, please post that datasetname and who/what is using it. There 
could be another reason why your request is denied in the first place.

Also, please post the full message(s) why your attempt failed.

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: DELETING DSN IN A SYSPLEX

[Vernooij, Kees (ITOPT1) - KLM]

"Dsn in use" is not an security issue, it is a GRS issue. Datasets are 
serialized by their dsname only. If you have different datasets on different 
volumes with the same dsname, they will be serialized.

You can delete the dsname by telling GRS to keep this dataset local.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of esmie moo
> Sent: 10 July, 2017 14:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DELETING DSN IN A SYSPLEX
> 
> Elardus,
> Thanks for the info on checking on the dsn.  However, I am still unable
> to delete it.  I think I will need specific security clearance.
> 
>   From: Elardus Engelbrecht 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Monday, July 10, 2017 8:01 AM
>  Subject: Re: DELETING DSN IN A SYSPLEX
> 
> esmie moo wrote:
> 
> >I am trying to delete a dsn which is in a SYSPLEX.  When I attempt to
> do so (via ISPF 3.4) I receive the message that the dsn is in use.I hit
> PF1 to get further information and then type HELP (as per prompt) and it
> shows that it is in use by the folliwng 2 user(s) and/or jobs(s)However
> when |I check iin SDSF niether the job nor the user is displayed.
> 
> Try these commands in SDSF:
> 
> SYSNAME *
> 
> PRE
> or
> PRE  
> 
> OWNER
> 
> and then also check that you turned off any filtering and destination
> filtering.
> 
> then use command DA ALL - you should see all and everything on this
> planet...
> 
> 
> >Is there a way of deleting the dsn?
> 
> There is a RACF profile which you can use to bypass normal checks to do
> a deletion.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For 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: DELETING DSN IN A SYSPLEX

[esmie moo]

Elardus,
Thanks for the info on checking on the dsn.  However, I am still unable to 
delete it.  I think I will need specific security clearance.

  From: Elardus Engelbrecht 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, July 10, 2017 8:01 AM
 Subject: Re: DELETING DSN IN A SYSPLEX
   
esmie moo wrote:

>I am trying to delete a dsn which is in a SYSPLEX.  When I attempt to do so 
>(via ISPF 3.4) I receive the message that the dsn is in use.I hit PF1 to get 
>further information and then type HELP (as per prompt) and it shows that it is 
>in use by the folliwng 2 user(s) and/or jobs(s)However when |I check iin SDSF 
>niether the job nor the user is displayed.

Try these commands in SDSF:

SYSNAME * 

PRE 
or 
PRE  

OWNER

and then also check that you turned off any filtering and destination filtering.

then use command DA ALL - you should see all and everything on this planet...


>Is there a way of deleting the dsn?  

There is a RACF profile which you can use to bypass normal checks to do a 
deletion.

Groete / Greetings
Elardus Engelbrecht

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

   

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

Re: LE strikes again

[Robin Atwood]

Don-
Thanks for that, will do. 

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: 10 July 2017 18:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LE strikes again

IPCS needs to be run with a MIGLIB from z/OS 1.4. IBM seems to be reluctant
to just provide these, so if you haven't saved one, you need to have the
customer run systrace and send you the output.

In article <00c401d2f96e$84910120$8db30360$@gmail.com> you wrote:
> A customer has installed one of our products and gets an immediate 0C1 
> when it is started. The customer is running z/OS 1.4 on a z850 so when 
> I received the dump I confidently expected the PSW to be pointing at 
> an unsupported instruction; what I saw was 0A0D with R1=040C1000 in 
> module CEEBTERM. So it looks like LE trapped an 0C1 and then reissued 
> it (TRAP(OFF) in CEEOPTS make no difference). The customer suppresses 
> all dumps, purges all STC logs at job end, so the only way I could get 
> any kind of dump was to ask them to set a SLIP trap. So why don't I 
> get a dump of the original 0C1? Looking at the system trace produces:
>  
>   INVALID CONTROL BLOCK  TOB /03 AT 0181B640 = E3D6C240/01.   
>   Invalid control block  TTCH/05 at 7F6DF000 = /00. 
>  System Trace processing is terminated.   
>  
> so that is also suppressed. Anyone any idea how I can help these people? 
>  
> Thanks
> Robin

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

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

Re: DELETING DSN IN A SYSPLEX

[Elardus Engelbrecht]

esmie moo wrote:

>I am trying to delete a dsn which is in a SYSPLEX.  When I attempt to do so 
>(via ISPF 3.4) I receive the message that the dsn is in use.I hit PF1 to get 
>further information and then type HELP (as per prompt) and it shows that it is 
>in use by the folliwng 2 user(s) and/or jobs(s)However when |I check iin SDSF 
>niether the job nor the user is displayed.

Try these commands in SDSF:

SYSNAME * 

PRE 
or 
PRE   

OWNER

and then also check that you turned off any filtering and destination filtering.

then use command DA ALL - you should see all and everything on this planet...


>Is there a way of deleting the dsn?  

There is a RACF profile which you can use to bypass normal checks to do a 
deletion.

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

DELETING DSN IN A SYSPLEX

[esmie moo]

Gentle Readers,
I am trying to delete a dsn which is in a SYSPLEX.  When I attempt to do so 
(via ISPF 3.4) I receive the message that the dsn is in use.I hit PF1 to get 
further information and then type HELP (as per prompt) and it shows that it is 
in use by the folliwng 2 user(s) and/or jobs(s)However when |I check iin SDSF 
niether the job nor the user is displayed.
Is there a way of deleting the dsn?  
Thanks

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

Re: LE strikes again

[Don Poitras]

IPCS needs to be run with a MIGLIB from z/OS 1.4. IBM seems to be
reluctant to just provide these, so if you haven't saved one, you
need to have the customer run systrace and send you the output.

In article <00c401d2f96e$84910120$8db30360$@gmail.com> you wrote:
> A customer has installed one of our products and gets an immediate 0C1 when
> it is started. The customer is running
> z/OS 1.4 on a z850 so when I received the dump I confidently expected the
> PSW to be pointing at an unsupported
> instruction; what I saw was 0A0D with R1=040C1000 in module CEEBTERM. So it
> looks like LE trapped an 0C1 and then reissued it (TRAP(OFF) in CEEOPTS make
> no difference). The customer suppresses all dumps, purges all STC 
> logs at job end, so the only way I could get any kind of dump was to ask
> them to set a SLIP trap. So why don't I get 
> a dump of the original 0C1? Looking at the system trace produces:
>  
>   INVALID CONTROL BLOCK  TOB /03 AT 0181B640 = E3D6C240/01.   
>   Invalid control block  TTCH/05 at 7F6DF000 = /00. 
>  System Trace processing is terminated.   
>  
> so that is also suppressed. Anyone any idea how I can help these people? 
>  
> Thanks
> Robin

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

LE strikes again

[Robin Atwood]

A customer has installed one of our products and gets an immediate 0C1 when
it is started. The customer is running

z/OS 1.4 on a z850 so when I received the dump I confidently expected the
PSW to be pointing at an unsupported

instruction; what I saw was 0A0D with R1=040C1000 in module CEEBTERM. So it
looks like LE trapped an 0C1 and then reissued it (TRAP(OFF) in CEEOPTS make
no difference). The customer suppresses all dumps, purges all STC 

logs at job end, so the only way I could get any kind of dump was to ask
them to set a SLIP trap. So why don't I get 

a dump of the original 0C1? Looking at the system trace produces:

 

  INVALID CONTROL BLOCK  TOB /03 AT 0181B640 = E3D6C240/01.   

  Invalid control block  TTCH/05 at 7F6DF000 = /00. 

 System Trace processing is terminated.   

 

so that is also suppressed. Anyone any idea how I can help these people? 

 

Thanks

Robin

 


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

Re: Z performancequestion #2 - key 9

[Binyamin Dissen]

As it is controlled by a CR bit, I thought that perhaps microcode was
involved.

On Sun, 9 Jul 2017 21:08:21 +0200 Peter Hunkeler  wrote:

:>Out of curiosity, why have you thought there might be one?
:>-- 
:>Peter Hunkeler
:>
:>
:> Von: Binyamin Dissen  An:   
IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Z performancequestion #2 - key 9 Datum: 
08.07.17, 20:37
:>
:> 
:>Thank you. 
:> 
:>On Fri, 7 Jul 2017 13:28:51 -0400 Jim Mulder  wrote: 
:> 
:>:>  There should be no performance cost. 
:>:> 
:>:>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.  
:>:>Poughkeepsie NY 
:>:> 
:>:>> Subject: Z performancequestion #2 - key 9 
:>:>> Sent by: IBM Mainframe Discussion List  
:>:>>  
:>:>> What is the performance cost of using key 9 storage when the PSW is not  
:>:>in key 
:>:>> 9? 
:> 

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