Re: z/OS Symbols Question

2017-09-28 Thread Peter Relson
>we need to query these symbolic names from an exit.

really? care to share why? It is quite unusual to have to "query" a system 
symbol.

The case I usually think of is "I have a string, I support symbolics, I 
call the symbol substitution service to do whatever it, according to its 
documentation, chooses to do".
And if the customer used a symbol that they had failed to define, then 
they get what they get, which is usually something that has bad syntax 
because "" is not usually what a parser would be looking for.

Peter Relson
z/OS Core Technology Design


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


Re: DLIB volume for SAD

2017-09-28 Thread Anthony Thompson
Your question implies confusion.

It is the Stand-Alone Dump program that scans and saves a broken LPAR's memory, 
which you IPL on top of a broken LPAR. I imagine you can scan a broken LPAR's 
memory using HMC/SE facilities, but I doubt many people can "PEEK/POKE" a 
busted-arse LPAR to fix it on the fly successfully.  Generally you want the 
system back up as soon as possible (take SAD and re-boot).

The fact that you SAD program has been installed on the volume that contains 
your DLIB's is irrelevant. There are no DLIB's or programs from DLIB's involved 
in the process of a stand-alone dump. It is the installation of the SAD program 
that generates all the necessary components, on whatever tape or DASD volume 
you specify (excluding any DASD sysres volumes of course, you don't want to 
overwrite the IPL text stored in cyl 0,0 that brings up your system).

Refer to the MVS Diagnosis and Service Aids manual for whichever version of 
z/OS you are using.

Ant.
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Friday, 29 September 2017 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DLIB volume for SAD

Is there a scanning mechanism within Distribution library dataset to scan the 
memory of frozen Lpar ?

On 29-Sep-2017 7:11 AM, "Ed Jaffe"  wrote:

> On 9/27/2017 2:16 PM, Steely.Mark wrote:
>
>> A little off topic - when is the last time anyone  had  to perform a 
>> SAD ?  I haven’t done one in 20+ years.
>>
>
> We take a SAD every time any of our systems go south.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.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

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


Re: SYS3 datasets

2017-09-28 Thread Ed Jaffe

On 9/24/2017 7:18 PM, Tony Thigpen wrote:

We have a staff z/OS systems programmer who claims that:
"Almost all shops use the SYS3. HLQ to indicate third party software."


Don't think I've *ever* seen the SYS3 HLQ used by our customers for our 
software. That doesn't mean nobody does it, just that I can't remember 
having seen it done. (They normally use 'SYS2' or some non-SYS HLQ 
altogether such as 'EJES' or 'ZHISR').


We use the SYSn (1-4) HLQs thusly:

 * SYS1 - IBM data sets (e.g., SYS1.PARMLIB)
 o Master catalog. Non-SMS
 * SYS2 - PSI-maintained analogs to IBM's (e.g., SYS2.PARMLIB), usually
   concatenated in front of IBM's
 o Master catalog. Non-SMS
 * SYS3 - System data sets (dynamic SVC dumps, etc)
 o User catalog. SMS-managed
 * SYS4 - System data sets (e.g., IPLPARM)
 o User catalog. Non-SMS


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

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


Re: DLIB volume for SAD

2017-09-28 Thread Peter
Is there a scanning mechanism within Distribution library dataset to scan
the memory of frozen Lpar ?

On 29-Sep-2017 7:11 AM, "Ed Jaffe"  wrote:

> On 9/27/2017 2:16 PM, Steely.Mark wrote:
>
>> A little off topic - when is the last time anyone  had  to perform a SAD
>> ?  I haven’t done one in 20+ years.
>>
>
> We take a SAD every time any of our systems go south.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.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: DLIB volume for SAD

2017-09-28 Thread Ed Jaffe

On 9/27/2017 2:16 PM, Steely.Mark wrote:

A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
haven’t done one in 20+ years.


We take a SAD every time any of our systems go south.

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

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


Re: DLIB volume for SAD

2017-09-28 Thread Mark Jacobs - Listserv
I understand. Building of the SAD was a just another step in the sysres 
build process. Easy enough and harmless to set and forget it. It was 
always done, always up to date and I didn't have to worry about it.


Mark Jacobs


Edward Gould 
September 28, 2017 at 7:47 PM


Mark,
I guess I am different and trust IBM more than you do.
If there isn’t a ++HOLD for recreation of the SA dump, then I don’t do so.
The only exception is if I am bringing up a new system, then its 
always done. By new system, I mean a complete system received from IBM.
I have never run into an instance where doing a lot of maintenance 
there isn’t a ++HOLD for a new SADUMP.


The worst number of years of maintenance was 5 (don’t ask).

Its been 25+ years since I have gotten a complete system build from 
IBM, so my memory might be faulty.


Essentially anytime I have to do a system load From IBM, I have always 
done one as stuff like that will bite you in your a** if you don’t.


A few years ago I was doing some work as a true contractor and I was 
amazed that the people who were to maintain the system after I left 
did not do a SADUMP redo.
I told the manager as I was leaving that he should get some 
experienced MVS people as the ones he had were not all that competent. 
He looked at me like I was trying to stay and I repeated to him that 
he needed to hire a experienced person that knew what they were doing. 
He said something like my people are experienced. I looked at him and 
said then you need to hire better people to make sure their manager 
doesn’t get bitten. Sure enough, I found out that they did not do a 
rebuild and it messed up the dump. I created a phony yahoo ID and 
emailed him and told him one last time that he needed to hire someone 
competent. I found out he finally hired a good person.


Ed

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



Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Mark Jacobs - Listserv 
September 28, 2017 at 12:56 PM


Mr. Murphy taught me a very long time ago that I should always ensure 
I have

a working SADUMP that matches the OS level requiring it.



Agree. That's why I always rebuilt it after every zOS maintenance 
cycle, cause' ya never know.


Mark Jacobs


Mark Zelden 
September 28, 2017 at 12:27 PM
I didn't respond to the "last time you took an SAD". It has been 
probably 1.5
years at least since a prod / dev LPAR crashed and took an SAD via 
AUTOIPL,

but it does happen every few years it seems.

The other 2 times were more recent and involved sandbox LPARs. One was 
just

a week ago when someone had removed a data set from LPA involving
CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't been
IPLed in over a month and the person who removed it didn't think that 
was the
reason for the wait state at IPL time. I was able to look at the 
SADUMP and

figure it out. IBM supplies SYS1.SDWWDLPA with a dummy CICSVR module that
NIP looks for at IPL time and I had to add that back into LPA.

Mr. Murphy taught me a very long time ago that I should always ensure 
I have

a working SADUMP that matches the OS level requiring it.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 

Systems Programming expert at 
http://search390.techtarget.com/ateExperts/ 






On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden  wrote:

>I always put SADUMP for each OS release on the 2nd volume of my 
maintenance

>sysres for each OS release (still using 3390-9s). I create an HMC
>profile on each CPC for SADUMP at that time. If I was using a mod-27 
or anything
>large enough where I didn't have a multi-volume sysres set, I would 
just put it on

>the dlib volume instead (this is what I did years ago).
>
>Part of my migration / cut over plan for after a "GO" decision when 
migrating

>releases is to update the HMC SADUMP profile for that LPAR and to verify
>AUTOIPL SADMP has been updated in DIAGxx to point to that proper
>volume as well (this is staged already in a "migration parmlib" 
concatenated ahead
>of the normal parmlib concatenation. So at any given time during OS 
upgrade

>migration, some LPARs are pointing to one level of SADUMP and other LPARs
>pointing to another level. It always matches the SADUMP for the OS 
version.

>
>Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consulting 

Re: Last SAD (was: DLIB volume for SAD)

2017-09-28 Thread Edward Gould
> On Sep 28, 2017, at 1:01 PM, Art Gutowski  wrote:
> 
> "Steely.Mark"  asked:
> 
>> A little off topic - when is the last time anyone  had  to perform a SAD ?  
>> I haven’t done one in 20+ years.  
> 
> We've taken at least a couple in the last 4 years.  I don't recall the exact 
> circumstances (lots of brush fires early in the transition), but on at least 
> one occasion, IIRC, we were still working through firewall issues and had a 
> hard time getting the dump to IBM.
> 
> Art Gutowski
> General Motors, LLC

Mark,
Although its gotten a *LOT* better, I would guess maybe 1 a year is an average. 
When MVS first came out we were doing at least 1 every two days.

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


Re: DLIB volume for SAD

2017-09-28 Thread Edward Gould
> On Sep 28, 2017, at 11:56 AM, Mark Jacobs - Listserv 
>  wrote:
> 
> 
> 
> Mr. Murphy taught me a very long time ago that I should always ensure I have
> a working SADUMP that matches the OS level requiring it.
> 
> 
> 
> Agree. That's why I always rebuilt it after every zOS maintenance cycle, 
> cause' ya never know.
> 
> Mark Jacobs


Mark,
I guess I am different and trust IBM more than you do.
If there isn’t a ++HOLD for recreation of the SA dump, then I don’t do so.
The only exception is if I am bringing up a new system, then its always done. 
By new system, I mean a complete system received from IBM.
I have never run into an instance where doing a lot of maintenance there isn’t 
a ++HOLD for a new SADUMP.

The worst number of years of maintenance was 5 (don’t ask).

Its been 25+ years since I have gotten a complete system build from IBM, so my 
memory might be faulty.

Essentially anytime I have to do a system load From IBM, I have always done one 
as stuff like that will bite you in your a** if you don’t. 

A few years ago I was doing some work as a true contractor and I was amazed 
that the people who were to maintain the system after I left did not do a 
SADUMP redo.
I told the manager as I was leaving that he should get some experienced MVS 
people as the ones he had were not all that competent. He looked at me like I 
was trying to stay and I repeated to him that he needed to hire a experienced 
person that knew what they were doing. He said something like my people are 
experienced. I looked at him and said then you need to hire better people to 
make sure their manager doesn’t get bitten. Sure enough, I found out that they 
did not do a rebuild and it messed up the dump. I created a phony yahoo ID and 
emailed him and told him one last time that he needed to hire someone 
competent. I found out he finally hired a good person.

Ed

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


Re: z/OS Symbols Question

2017-09-28 Thread scott Ford
Gil,

That is what I need, I need to know if  is defined , we need to
query these symbolic names from an exist.
So I am trying cut down on overhead ...thank you Gil I missed that in the
macro. A new adventure is system's development.

Scott

On Thu, Sep 28, 2017 at 1:58 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 27 Sep 2017 17:47:43 -0500, Kirk Wol wrote:
>
> >Looking up the value of a symbol with ASASYMBM is a degenerate case:
> >
> >just give it an input pattern of:   ""
> >and the output buffer will contain the value.
> >
> Does the OP need a definite indication of whether "" is
> defined?  Looking at the doc for ASASYMBM, I see no return code
> with that meaning.  (There is, however, RC=0C to indicate that
> "" is defined as the null string.  Why?)
>
> And a warning about the performance of LINK.
>
> >On Wed, Sep 27, 2017 at 5:28 PM, scott Ford wrote:
> >>
> >> I need to scan the symbol table for an assigned symbolic , I looked at
> >> sys1.samplib  -- IEASYMCK and macro ASASYMBM and i see that I can
> replace s
> >> symbolic and its value. What I need to do is scan though the table to
> find
> >> a symbol.  I need some pointer to give me a helping hand.
> >>
> >> I read through ASASYMBM and it seems you can pass a value and length
> but I
> >> dont want to replace a symbol...
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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


Re: Last SAD (was: DLIB volume for SAD)

2017-09-28 Thread Art Gutowski
"Steely.Mark"  asked:

>A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
>haven’t done one in 20+ years.  
 
We've taken at least a couple in the last 4 years.  I don't recall the exact 
circumstances (lots of brush fires early in the transition), but on at least 
one occasion, IIRC, we were still working through firewall issues and had a 
hard time getting the dump to IBM.

Art Gutowski
General Motors, LLC

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


Re: z/OS Symbols Question

2017-09-28 Thread Paul Gilmartin
On Wed, 27 Sep 2017 17:47:43 -0500, Kirk Wol wrote:

>Looking up the value of a symbol with ASASYMBM is a degenerate case:
>
>just give it an input pattern of:   ""
>and the output buffer will contain the value.
>
Does the OP need a definite indication of whether "" is
defined?  Looking at the doc for ASASYMBM, I see no return code
with that meaning.  (There is, however, RC=0C to indicate that
"" is defined as the null string.  Why?)

And a warning about the performance of LINK.

>On Wed, Sep 27, 2017 at 5:28 PM, scott Ford wrote:
>>
>> I need to scan the symbol table for an assigned symbolic , I looked at
>> sys1.samplib  -- IEASYMCK and macro ASASYMBM and i see that I can replace s
>> symbolic and its value. What I need to do is scan though the table to find
>> a symbol.  I need some pointer to give me a helping hand.
>>
>> I read through ASASYMBM and it seems you can pass a value and length but I
>> dont want to replace a symbol...

-- gil

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


Re: z/OS Symbols Question

2017-09-28 Thread Tom Marchant
On Wed, 27 Sep 2017 18:28:59 -0400, scott Ford wrote:

>I need to scan the symbol table for an assigned symbolic...

ITYM you need to scan for an assigned symbol. 

"Symbol" is a noun.
"Symbolic" is an adjective, as in "symbolic substitution".



-- 
Tom Marchant

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


Re: DLIB volume for SAD

2017-09-28 Thread Mark Jacobs - Listserv



Mr. Murphy taught me a very long time ago that I should always ensure I have
a working SADUMP that matches the OS level requiring it.



Agree. That's why I always rebuilt it after every zOS maintenance cycle, 
cause' ya never know.


Mark Jacobs


Mark Zelden 
September 28, 2017 at 12:27 PM
I didn't respond to the "last time you took an SAD". It has been 
probably 1.5
years at least since a prod / dev LPAR crashed and took an SAD via 
AUTOIPL,

but it does happen every few years it seems.

The other 2 times were more recent and involved sandbox LPARs. One was 
just

a week ago when someone had removed a data set from LPA involving
CICS VR because the sandbox LPAR did not run CICS. The LPAR hadn't been
IPLed in over a month and the person who removed it didn't think that 
was the
reason for the wait state at IPL time. I was able to look at the 
SADUMP and

figure it out. IBM supplies SYS1.SDWWDLPA with a dummy CICSVR module that
NIP looks for at IPL time and I had to add that back into LPA.

Mr. Murphy taught me a very long time ago that I should always ensure 
I have

a working SADUMP that matches the OS level requiring it.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 

Systems Programming expert at 
http://search390.techtarget.com/ateExperts/ 






On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden  wrote:

>I always put SADUMP for each OS release on the 2nd volume of my 
maintenance

>sysres for each OS release (still using 3390-9s). I create an HMC
>profile on each CPC for SADUMP at that time. If I was using a mod-27 
or anything
>large enough where I didn't have a multi-volume sysres set, I would 
just put it on

>the dlib volume instead (this is what I did years ago).
>
>Part of my migration / cut over plan for after a "GO" decision when 
migrating

>releases is to update the HMC SADUMP profile for that LPAR and to verify
>AUTOIPL SADMP has been updated in DIAGxx to point to that proper
>volume as well (this is staged already in a "migration parmlib" 
concatenated ahead
>of the normal parmlib concatenation. So at any given time during OS 
upgrade

>migration, some LPARs are pointing to one level of SADUMP and other LPARs
>pointing to another level. It always matches the SADUMP for the OS 
version.

>
>Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>ITIL v3 Foundation Certified
>mailto:m...@mzelden.com
>Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 

>Systems Programming expert at 
http://search390.techtarget.com/ateExperts/ 


>
>
>
>
>
>==
>
>On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson 
 wrote:

>
>Invitation for early Friday war stories.
>
>When implementing (OS-moniker-du-jour) 1.6, we had several 
catastrophic failures that required back out to previous level. We 
took some SADs during that stormy period.

>
>When implementing z/OS 1.13, we had several instances of running 
clean out of real storage! System hit a wait state, took SAD 
automatically, then re-IPLed itself. That was entertaining.

>
>We more recently (under 2.1) took SAD and re-IPLed a hung system that 
would probably have recovered if we had held off a bit longer. Heck, 
Game of Thrones was on. How long were we supposed to wait? ;-)

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

>Sent: Wednesday, September 27, 2017 2:16 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: DLIB volume for SAD
>
>A little off topic - when is the last time anyone had to perform a 
SAD ? I haven’t done one in 20+ years.

>
>Thanks
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Jesse 1 Robinson

>Sent: Wednesday, September 27, 2017 4:11 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DLIB volume for SAD
>
>My comment was meant more for z/OS release upgrades. In some of our 
sysplexes, we run both old and new releases for some period before 
full migration. I guess it's somewhat risky, but we generally rebuild 
SAD when the first member gets upgraded. If we were shot at, we were 
missed. ;-)

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

Re: DLIB volume for SAD

2017-09-28 Thread Mark Zelden
I didn't respond to the "last time you took an SAD".  It has been probably 1.5
years at least since a prod / dev LPAR crashed and took an SAD via AUTOIPL,
but it does happen every few years it seems.

The other 2 times were more recent and involved sandbox LPARs.  One was just
a week ago when someone had removed a data set from LPA involving
CICS VR because the sandbox LPAR did not run CICS.  The LPAR hadn't been
IPLed in over a month and the person who removed it didn't think that was the
reason for the wait state at IPL time.  I was able to look at the SADUMP and
figure it out.   IBM supplies SYS1.SDWWDLPA with a dummy CICSVR module that 
NIP looks for at IPL time and I had to add that back into LPA.

Mr. Murphy taught me a very long time ago that I should always ensure I have
a working SADUMP that matches the OS level requiring it.  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/




On Thu, 28 Sep 2017 11:16:47 -0500, Mark Zelden  wrote:

>I always put SADUMP for each OS release on the 2nd volume of my maintenance
>sysres for each OS release (still using 3390-9s).   I create an HMC 
>profile on each CPC for SADUMP at that time.   If I was using a mod-27 or 
>anything
>large enough where I didn't have a multi-volume sysres set, I would just put 
>it on
>the dlib volume instead (this is what I did years ago).  
>
>Part of my migration / cut over plan for after a "GO" decision when migrating
>releases is to update the HMC SADUMP profile for that LPAR and to verify
>AUTOIPL SADMP has been updated in DIAGxx to point to that proper 
>volume as well (this is staged already in a "migration parmlib" concatenated 
>ahead
>of the normal parmlib concatenation.  So at any given time during OS upgrade
>migration, some LPARs are pointing to one level of SADUMP and other LPARs
>pointing to another level.  It always matches the SADUMP for the OS version.
>
>Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>ITIL v3 Foundation Certified
>mailto:m...@mzelden.com
>Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
>
>
>
>==
>
>On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson  
>wrote:
>
>Invitation for early Friday war stories.  
> 
>When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic 
>failures that required back out to previous level. We took some SADs during 
>that stormy period. 
> 
>When implementing z/OS 1.13, we had several instances of running clean out of 
>real storage! System hit a wait state, took SAD automatically, then re-IPLed 
>itself. That was entertaining.  
> 
>We more recently (under 2.1) took SAD and re-IPLed a hung system that would 
>probably have recovered if we had held off a bit longer. Heck, Game of Thrones 
>was on. How long were we supposed to wait? ;-) 
> 
>. 
>. 
>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 Steely.Mark 
>Sent: Wednesday, September 27, 2017 2:16 PM 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Subject: (External):Re: DLIB volume for SAD 
> 
>A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
>haven’t done one in 20+ years.  
> 
>Thanks 
> 
>-Original Message- 
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Jesse 1 Robinson 
>Sent: Wednesday, September 27, 2017 4:11 PM 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Subject: Re: DLIB volume for SAD 
> 
>My comment was meant more for z/OS release upgrades. In some of our sysplexes, 
>we run both old and new releases for some period before full migration. I 
>guess it's somewhat risky, but we generally rebuild SAD when the first member 
>gets upgraded. If we were shot at, we were missed. ;-) 
> 
>. 
>. 
>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 Jim Mulder 
>Sent: Wednesday, September 27, 2017 12:42 PM 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Subject: (External):Re: DLIB volume for SAD 
> 
>  I don't know of any SADMP PTFs that were not downward compatible within the 
> same release of z/OS, and we would certainly try to avoid creating that 
> scenario. 
> 
>Jim Mulder z/OS Diagnosis, Design, Development, 

Re: DLIB volume for SAD

2017-09-28 Thread Mark Zelden
I always put SADUMP for each OS release on the 2nd volume of my maintenance
sysres for each OS release (still using 3390-9s).   I create an HMC 
profile on each CPC for SADUMP at that time.   If I was using a mod-27 or 
anything
large enough where I didn't have a multi-volume sysres set, I would just put it 
on
the dlib volume instead (this is what I did years ago).  

Part of my migration / cut over plan for after a "GO" decision when migrating
releases is to update the HMC SADUMP profile for that LPAR and to verify
AUTOIPL SADMP has been updated in DIAGxx to point to that proper 
volume as well (this is staged already in a "migration parmlib" concatenated 
ahead
of the normal parmlib concatenation.  So at any given time during OS upgrade
migration, some LPARs are pointing to one level of SADUMP and other LPARs
pointing to another level.  It always matches the SADUMP for the OS version.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/





==

On Wed, 27 Sep 2017 22:11:33 +, Jesse 1 Robinson  
wrote:

Invitation for early Friday war stories.  
 
When implementing (OS-moniker-du-jour) 1.6, we had several catastrophic 
failures that required back out to previous level. We took some SADs during 
that stormy period. 
 
When implementing z/OS 1.13, we had several instances of running clean out of 
real storage! System hit a wait state, took SAD automatically, then re-IPLed 
itself. That was entertaining.  
 
We more recently (under 2.1) took SAD and re-IPLed a hung system that would 
probably have recovered if we had held off a bit longer. Heck, Game of Thrones 
was on. How long were we supposed to wait? ;-) 
 
. 
. 
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 Steely.Mark 
Sent: Wednesday, September 27, 2017 2:16 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: (External):Re: DLIB volume for SAD 
 
A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
haven’t done one in 20+ years.  
 
Thanks 
 
-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson 
Sent: Wednesday, September 27, 2017 4:11 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: DLIB volume for SAD 
 
My comment was meant more for z/OS release upgrades. In some of our sysplexes, 
we run both old and new releases for some period before full migration. I guess 
it's somewhat risky, but we generally rebuild SAD when the first member gets 
upgraded. If we were shot at, we were missed. ;-) 
 
. 
. 
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 Jim Mulder 
Sent: Wednesday, September 27, 2017 12:42 PM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: (External):Re: DLIB volume for SAD 
 
  I don't know of any SADMP PTFs that were not downward compatible within the 
same release of z/OS, and we would certainly try to avoid creating that 
scenario. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.  
Poughkeepsie NY 
 
> In addition the SAD IPL volume should in principle be compatible with  
> the level of z/OS that might use it. Periodically changes are made to  
> SAD by a PTF whose ++HOLD instructs you to rebuild SAD. It could  
> conceivably happen that an older level of z/OS might have trouble with  
> a higher level SAD IPL volume, but I've never seen it. 


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


Re: a volser id in a system-manage library(TS7700) is the same as a volser id in DS8800

2017-09-28 Thread Tim Deller
If you have authority to use bypass label processing; you may be able to read 
the tape with JCL parameters like:
//TAPEIN   DD DSN=bogus dsn with your HLQ,UNIT=3490,VOL=SER=bogus volser,
//LABEL=(2,BLP,EXPDT=98000),DISP=(OLD,KEEP),
//DCB=(appropriate RECFM,LRECL,ETC because you are no longer 
standard label)

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


Re: Is the AFP control bit (big #13 in CR0) testable in an application?

2017-09-28 Thread Peter Relson
>I guess it's stuck at always saving/restoring the AFP regs if the
>CVTBFPH flag

not true.

You do not have to save/restore if the registers are not currently being 
saved/restored (because upon their first use, their value will be 0). 
.
IHASTCB byte STCBFPFL bit STCBBFP is on if and only if the AFPRs are being 
used.
IHAPSA byte PSAFPFL bit PSABFP is similarly on (I need to, and will do so 
going forward, update IHAPSA to indicate that PSAFPFL is an interface, 
which, as the commentary indicates, is the case for PSABFP and PSAVSS).

And, FWIW, there is no reason to check CVTBFPH if running on any support 
z/OS release.

If you happened to have control over the usage "beneath you", then you 
could take advantage of that knowledge: the requirement is to preserve 
which could either by by not using or by save/restore.

Peter Relson
z/OS Core Technology Design


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