Re: SMPE -removal of USERMOD ++HOLD created instream

[Bruce Hewson]

Hi Tom,

Which is why I trying to ask if anyone had a solution/bypass to that statement.

I assumed, incorrectly, that since the ++HOLD was instream to the USERMOD, that 
a RESTORE and REJECT of a USERMOD would have also removed the instream ++HOLDs, 
but I am finding that is not true.

Therefore need another WAY!

>>I tried using ++RELEASE but that fails. Something about the ++HOLD being 
>>encoded inside the ++USERMOD.
>
>"++RELEASE statements do not affect ++HOLD statements within a SYSMOD 
>(internal HOLDDATA)."
>- SMP/E Reference. Usage notes for ++RELEASE.
>
>
>-- 
>Tom Marchant

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

Re: CBPDO vs ServerPac

[R.S.]

It not true / no longer true.

You have exact ontrol of every single dataset parameters, every single 
volume occupation.
I don't know what CSI configuration you lack, but there are also some 
knobs and buttons.


Disclaimer: I'm not selling ServerPacs ;-)

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-09-15 o 23:46, CM Poncelet pisze:
From memory (15+ years ago), lack of control over DASD space 
allocation and CSI configuration.


R.S. wrote:


W dniu 2015-09-15 o 20:40, CM Poncelet pisze:

Yes, I would agree. CBPDO and any other native SMP/E installs are 
faster and more user-controllable than 'PAC' ones. CP



What kind of control do you lack in ServerPac???




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

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

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


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

Re: CBPDO vs ServerPac

[R.S.]

Only ServerPac is free of charge (from the *Pac family).

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-09-15 o 23:03, Ed Finnell pisze:

The other option is SystemPAC or CustomPAC. Depending on level sets and
Software releases(down level)
can save considerable conversion time. For the places I've had to use it
IBM will do a deal if you're doing hardware upgrades.
  
  
In a message dated 9/15/2015 3:37:13 P.M. Central Daylight Time,

r.skoru...@bremultibank.com.pl writes:

"Most  customers are using ServerPac to upgrade existing z/OS systems,
rather  than upgrading their systems using CBPDO."

I agree with both  statements.



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





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

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

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


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

Re: RSU or maintenance level on a system

[Jousma, David]

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

RSU or maintenance level on a system

[Lopez, Sharon]

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: SMPE -removal of USERMOD ++HOLD created instream

[Jousma, David]

You can use the SMPE panels to add/remove the hold.  That usually how I add a 
user hold, and then eventually remove them as well.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Wednesday, September 16, 2015 2:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE -removal of USERMOD ++HOLD created instream

Hi Tom,

Which is why I trying to ask if anyone had a solution/bypass to that statement.

I assumed, incorrectly, that since the ++HOLD was instream to the USERMOD, that 
a RESTORE and REJECT of a USERMOD would have also removed the instream ++HOLDs, 
but I am finding that is not true.

Therefore need another WAY!

>>I tried using ++RELEASE but that fails. Something about the ++HOLD being 
>>encoded inside the ++USERMOD.
>
>"++RELEASE statements do not affect ++HOLD statements within a SYSMOD 
>(internal HOLDDATA)."
>- SMP/E Reference. Usage notes for ++RELEASE.
>
>
>--
>Tom Marchant

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

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


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

Re: RSU or maintenance level on a system

[Blake, Daniel J [CTR]]

So give your auditors want they want using your IEASYMxx member.  Add 
"SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the 
"D SYMBOLS" command.  Just make sure nnn is your current RSU number.



;-D an 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, September 16, 2015 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

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

Re: RSU or maintenance level on a system

[van der Grijn, Bart (B)]

There's no way to display it because there's not really such a thing as a 
defined maintenance level for a z/OS system. RSU is a collection of recommended 
PTFs for a selection of products. So what would be the definition of your 
system being at a RSU level? Does it imply all the maintenance? For all the 
components? For just z/OS or also for CICS, DB2, etc? Does it imply all the 
maintenance for the previous RSU levels? 
We don't always install all the RSU PTFs because some might be in error for 
reasons we care about. Does that mean we're not at that RSU level? 
I don't see an easy way to determine it programmatically, even if there was an 
agreed definition. 

I haven't seen that specific question, but have received similar questions (ex: 
'show us you have all security patches installed'). Our reply so far has been 
to explain the RSU process and show evidence of applying the RSU maintenance on 
a regular basis (through our internal change control tool).

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

Re: Concatenated datasets read information.

[Art Celestini]

At 08:44 PM 9/15/2015, Shmuel Metz (Seymour J.) wrote:
 
>In

Re: RSU or maintenance level on a system

[Ted MacNEIL]

What would the auditors gain with this knowledge?

-
-teD
-
  Original Message  
From: Jousma, David
Sent: Wednesday, September 16, 2015 08:30
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RSU or maintenance level on a system

IBM is correct. No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system. To my knowledge, there is no way to do that (IBM has also agreed). 
Does anyone know if this is possible and are you getting the same request from 
your auditors.? Keep in mind that our auditors do know z/OS or mainframe. It 
sounds like they are used to seeing displays on other platforms with this 
information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

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

Re: RSU or maintenance level on a system

[Mike Wawiorko]

Or get some auditors who understand what they are auditing.

If they don't understand z/OS they are adding no value to your business by 
pretending to audit z/OS. 
Your management will get a warm or cool feeling from what the auditors say, but 
it will say nothing meaningful about the state of your z/OS systems.
If your systems are configured in a stupidly insecure manner you do want to 
know about it don't you?

Mike Wawiorko
 Please consider the environment before printing this e-mail

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blake, Daniel J [CTR]
Sent: 16 September 2015 14:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

So give your auditors want they want using your IEASYMxx member.  Add 
"SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the 
"D SYMBOLS" command.  Just make sure nnn is your current RSU number.



;-D an 



This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: RSU or maintenance level on a system

[John McKown]

On Wed, Sep 16, 2015 at 8:20 AM, Ted MacNEIL  wrote:

> What would the auditors gain with this knowledge?
>

​Knowledge? It's just _data_. Auditors, in my experience, have very little
_knowledge_. Much like government bureaucrats. ​



>
> -
> -teD
> -
>

-- 

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

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

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: RSU or maintenance level on a system

[Staller, Allan]

Say what you really think John, 




On Wed, Sep 16, 2015 at 8:20 AM, Ted MacNEIL  wrote:

> What would the auditors gain with this knowledge?
>

​Knowledge? It's just _data_. Auditors, in my experience, have very little 
_knowledge_. Much like government bureaucrats. ​



>
> -
> -teD
> -
>

-- 

...  deleted text  


Maranatha! <><
John McKown


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

Re: RSU or maintenance level on a system

[Jousma, David]

Thinking about this some more, we save the apply listings for audit purposes.   
In our case, they want to see the progression of maintenance flowing from TECH 
to DEV, and then DEV to PROD to prove we test our maintenance.   When we do 
maintenance, we usually select RSU* or specific RSU levels amongst other 
sourceID's.I suppose you could show an auditor that information.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, September 16, 2015 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

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: RSU or maintenance level on a system

[Tom Marchant]

On Wed, 16 Sep 2015 12:27:54 +, Lopez, Sharon wrote:

>Our auditors want to be able to display the RSU or maintenance level 
>of our z/OS system.  To my knowledge, there is no way to do that 
>(IBM has also agreed).  Does anyone know if this is possible and are 
>you getting the same request from your auditors.? Keep in mind that 
>our auditors do know z/OS or mainframe.  It sounds like they are used 
>to seeing displays on other platforms with this information with release 
>and fix level.

A single maintenance level for thousands of elements that can all be 
updated independently would not be possible or meaningful. I would ask 
what the auditor was looking for. Perhaps the SMPLOG for the target 
zone would be helpful to them.

-- 
Tom Marchant

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

Re: HSM Error Message

[Staller, Allan]

1) HSM LIST TTOC(408922). Note predecessor or successor volumes
2) HSM LIST TTOC(predecessor) or successor 
3) the listing should show hsm.back, (depending on setting in arccmd00) as 
the (first or last) dataset on 408922. This should be the same dataset as (the 
1st or last) dataset on the predecessor/successor volume.
4) Examine the BCDS and/or DCOLLECT records to find the "English" name of this 
dataset. (e.g. USER.SOURCE.LIB).
5) recall/recover this dataset to dasd
6) HBDEL  'english name'  ALL ( or the specific backup version if desired)
7) perform your recycle
8) re-backup the dataset in question and migrate/delete as needed.

As you can see from the message, connected sets can only be recycled if 40 
volumes or less.
The above may need to be performed several times to break the existing 
connected set into chunks of 40 volumes or less.

HTH,


I am getting the following message trying to recycle a volume:

ARC0445I VOLUME 408922 CANNOT BE RECYCLED, REASON= 0028, EXPLANATION: CONNECTED 
SET TOO LONG

Reason 28:

28CONNECTED SET TOO LONG: DFSMShsm will not recycle connected sets
  exceeding 40 volumes. The volume specified belongs to a
  connected set exceeding this limit.

These are spill volumes. What can I do to fix this ?

The list with DSI options displayed 100's of files on these tapes.

We are z/os v1r13.


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

Re: RSU or maintenance level on a system

[Pommier, Rex]

Devious!  I'll have to put that in my bag of tricks.  :-)  That could have 
easily worked with any auditors I've encountered in the past, but Sharon's 
auditors apparently know z/OS.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blake, Daniel J [CTR]
Sent: Wednesday, September 16, 2015 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

So give your auditors want they want using your IEASYMxx member.  Add 
"SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the 
"D SYMBOLS" command.  Just make sure nnn is your current RSU number.



;-D an 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, September 16, 2015 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: RSU or maintenance level on a system

[Blake, Daniel J [CTR]]

One more thing, IBM supplies the OS information for you using   You 
cannot change it and you don't have to specify it in your IEASYMxx member.  For 
us when we enter D SYMBOLS it's:  = "Z1020100".



;-D an 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blake, Daniel J [CTR]
Sent: Wednesday, September 16, 2015 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

So give your auditors want they want using your IEASYMxx member.  Add 
"SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the 
"D SYMBOLS" command.  Just make sure nnn is your current RSU number.



;-D an 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, September 16, 2015 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

--
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: RSU or maintenance level on a system

[Blake, Daniel J [CTR]]

And since you document your SMP/E work you can back it up.



;-D an


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Wednesday, September 16, 2015 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

Devious!  I'll have to put that in my bag of tricks.  :-)  That could have 
easily worked with any auditors I've encountered in the past, but Sharon's 
auditors apparently know z/OS.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blake, Daniel J [CTR]
Sent: Wednesday, September 16, 2015 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

So give your auditors want they want using your IEASYMxx member.  Add 
"SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the 
"D SYMBOLS" command.  Just make sure nnn is your current RSU number.



;-D an 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, September 16, 2015 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

IBM is correct.  No way to do that.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

--
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: RSU or maintenance level on a system

[Lizette Koehler]

Or another Technique could be to use the CVTUSER field.  Zap it with a Usermod
to include the RSU with your live system
00D4  212 Signed   4 CVTUSER- FIELD AVAILABLE TO USER

Thought I do like the SYMBOLS option, but it is way too easy to change.  Zapping
the CVTUSER would take more effort and the USERMOD would remind you to do it.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> One more thing, IBM supplies the OS information for you using   You
> cannot change it and you don't have to specify it in your IEASYMxx member.
For us
> when we enter D SYMBOLS it's:  = "Z1020100".
> 
> 
> 
> ;-D an
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> So give your auditors want they want using your IEASYMxx member.  Add
> "SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU issue the
> "D SYMBOLS" command.  Just make sure nnn is your current RSU number.
> 
> 
> 
> ;-D an
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: Wednesday, September 16, 2015 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> IBM is correct.  No way to do that.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: Wednesday, September 16, 2015 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RSU or maintenance level on a system
> 
> I already posted this question to IBM but wanted to find out if others are
getting this
> request from their auditors.
> 
> Our auditors want to be able to display the RSU or maintenance level of our
z/OS
> system.  To my knowledge, there is no way to do that (IBM has also agreed).
Does
> anyone know if this is possible and are you getting the same request from your
> auditors.? Keep in mind that our auditors do know z/OS or mainframe.  It
sounds like
> they are used to seeing displays on other platforms with this information with
> release and fix level.
> 
> Thank you in advance.
> 
> 

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

Re: SMPE -removal of USERMOD ++HOLD created instream

[Tom Marchant]

On Wed, 16 Sep 2015 01:08:24 -0500, Bruce Hewson wrote:

>I assumed, incorrectly, that since the ++HOLD was instream to the 
>USERMOD, that a RESTORE and REJECT of a USERMOD would have 
>also removed the instream ++HOLDs, but I am finding that is not true.

Did you specify HOLDDATA on the REJECT command?

-- 
Tom Marchant

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

Re: RSU or maintenance level on a system

[John McKown]

On Wed, Sep 16, 2015 at 7:27 AM, Lopez, Sharon  wrote:

> I already posted this question to IBM but wanted to find out if others are
> getting this request from their auditors.
>
> Our auditors want to be able to display the RSU or maintenance level of
> our z/OS system.  To my knowledge, there is no way to do that (IBM has also
> agreed).  Does anyone know if this is possible and are you getting the same
> request from your auditors.? Keep in mind that our auditors do know z/OS or
> mainframe.  It sounds like they are used to seeing displays on other
> platforms with this information with release and fix level.
>
> Thank you in advance.
>

​z/OS is composed of many parts. What I might do would be to look at the
SOURCEID list for your z/OS target zone. And say something like: "We are on
z/OS 1.12 RSU 9912, plus a few (thousand) special patches"



>
>
>
>
> 
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

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

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

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

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: Concatenated datasets read information.

[Charles Mills]

> Depending on how often you want to do this (every record?)

Couldn't you just save off DCBTIOT and compare it before (after?) every GET?
If DCBTIOT changed then go through the whole drill below, else not?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Art Celestini
Sent: Wednesday, September 16, 2015 6:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatenated datasets read information.

At 08:44 PM 9/15/2015, Shmuel Metz (Seymour J.) wrote:
 
>In

Re: RSU or maintenance level on a system

[Bob Shannon]

We apply PUT maintenance, not RSU, but we have a usermod to update CVTVERID 
with maintenance level. If you did that you could give the auditors some Rexx 
code to display the value.

Bob Shannon
Rocket Software

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


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

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

Re: RSU or maintenance level on a system

[J O Skip Robinson]

I have pitched this idea before. In a process that predates me in this shop, it 
was recognized that quite apart from auditors' poking around, we sysprogs 
needed a way to track a 'system package' at it migrated from one system to the 
next throughout the enterprise. The choice was to attach an arbitrary label to 
identify a particular *bundle* of maintenance that we would migrate stepwise 
from sandbox to production. The label looks like this

R##@

R is a constant, ## represents the OS release, and @ is letter that starts with 
A and get incremented for each new maintenance bundle. Currently we have R13@ 
for z/OS 1.13 and R21@ for z/OS 2.1. This label shows us at a glance which OS 
release a system is running, while the suffix allows us to track the migration 
of a particular bundle. We can easily tell which systems are at the same level, 
or which are up or down level if they're not the same. 

Once a bundle is ready for migration, we ZAP the new level into the nucleus in 
the user area. This is supported by a program/command that displays the level. 
Furthermore, we create members in text files like ISPF and OMVS that are easily 
viewed. The level can also be embedded in dataset names used for migration. 
Before we IPL a system at a new level, we run a Rexx that checks consistency 
among various components to verify that all relevant pieces have been migrated 
properly.  

This process has worked extremely well since the 1980s, before 'OS390' or 
'z/OS'. If you want something like this, you can start with the label. Then 
write some code to display it. Then build the label into a migration process. 
You can take it as far as you want.

As for auditors, they seem fixated on RACF and OMVS APARs. Something they must 
be taught in summer camp. The level strategy is really for us.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, September 16, 2015 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

Or another Technique could be to use the CVTUSER field.  Zap it with a Usermod 
to include the RSU with your live system
00D4  212 Signed   4 CVTUSER- FIELD AVAILABLE TO USER

Thought I do like the SYMBOLS option, but it is way too easy to change.  
Zapping the CVTUSER would take more effort and the USERMOD would remind you to 
do it.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> One more thing, IBM supplies the OS information for you using 
>   You cannot change it and you don't have to specify it in your 
> IEASYMxx member.
For us
> when we enter D SYMBOLS it's:  = "Z1020100".
> 
> 
> 
> ;-D an
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> So give your auditors want they want using your IEASYMxx member.  Add 
> "SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU 
> issue the "D SYMBOLS" command.  Just make sure nnn is your current RSU number.
> 
> 
> 
> ;-D an
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Wednesday, September 16, 2015 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> IBM is correct.  No way to do that.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lopez, Sharon
> Sent: Wednesday, September 16, 2015 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RSU or maintenance level on a system
> 
> I already posted this question to IBM but wanted to find out if others 
> are
getting this
> request from their auditors.
> 
> Our auditors want to be able to display the RSU or maintenance level 
> of our
z/OS
> system.  To my knowledge, there is no way to do that (IBM has also agreed).
Does
> anyone know if this is possible and are you getting the same request 
> from your auditors.? Keep in mind that our auditors do know z/OS or 
> mainframe.  It
sounds like
> they are used to seeing displays on other platforms with this 
> information with release and fix 

Re: RSU or maintenance level on a system

[Chris Hoelscher]

And having INSTALLED (even all) PTFs at a given RSU attribute does not mean 
they have been copied to a RUNTIME environment

So is there anything you COULD do?

Run AMBLIST against all runtime load modules - looking for PTF eyecatches in 
IDR if they exist - go to CSI - get the RSU attribute from the SYSMOD entry for 
those PTFd (ef they exist) - find the highest RSU and  there ya go ... (if your 
job depends upon providing this information) - I have never had this kind of 
auditor request for any products that I am responsible for ...  

Chris hoelscher
Technology Architect 
Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 714-8615
(502) 476-2538


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of van der Grijn, Bart (B)
Sent: Wednesday, September 16, 2015 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] RSU or maintenance level on a system

There's no way to display it because there's not really such a thing as a 
defined maintenance level for a z/OS system. RSU is a collection of recommended 
PTFs for a selection of products. So what would be the definition of your 
system being at a RSU level? Does it imply all the maintenance? For all the 
components? For just z/OS or also for CICS, DB2, etc? Does it imply all the 
maintenance for the previous RSU levels? 
We don't always install all the RSU PTFs because some might be in error for 
reasons we care about. Does that mean we're not at that RSU level? 
I don't see an easy way to determine it programmatically, even if there was an 
agreed definition. 

I haven't seen that specific question, but have received similar questions (ex: 
'show us you have all security patches installed'). Our reply so far has been 
to explain the RSU process and show evidence of applying the RSU maintenance on 
a regular basis (through our internal change control tool).

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system.  To my knowledge, there is no way to do that (IBM has also 
agreed).  Does anyone know if this is possible and are you getting the same 
request from your auditors.? Keep in mind that our auditors do know z/OS or 
mainframe.  It sounds like they are used to seeing displays on other platforms 
with this information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

Re: RSU or maintenance level on a system

[Mark Zelden]

On Wed, 16 Sep 2015 15:50:20 +, Bob Shannon  
wrote:

>We apply PUT maintenance, not RSU, but we have a usermod to update CVTVERID 
>with maintenance level. If you did that you could give the auditors some Rexx 
>code
> to display the value. 

My last post mentioned IPLINFO for displaying what Skip was referring to.  This 
is
actually what IPLINFO will display if present.  

Mark
Best Regards / Mit freundlichen Grüßen,

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/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU or maintenance level on a system

[Mark Zelden]

On Wed, 16 Sep 2015 15:42:19 +, J O Skip Robinson 
 wrote:

>I have pitched this idea before. In a process that predates me in this shop, 
>it was recognized that quite apart from auditors' poking around, we sysprogs 
>needed a way to track a 'system package' at it migrated from one system to the 
>next throughout the enterprise. The choice was to attach an arbitrary label to 
>identify a particular *bundle* of maintenance that we would migrate stepwise 
>from sandbox to production. The label looks like this
>
>R##@
>
>R is a constant, ## represents the OS release, and @ is letter that starts 
>with A and get incremented for each new maintenance bundle. Currently we have 
>R13@ for z/OS 1.13 and R21@ for z/OS 2.1. This label shows us at a glance 
>which OS release a system is running, while the suffix allows us to track the 
>migration of a particular bundle. We can easily tell which systems are at the 
>same level, or which are up or down level if they're not the same. 
>
>Once a bundle is ready for migration, we ZAP the new level into the nucleus in 
>the user area. This is supported by a program/command that displays the level. 
>Furthermore, we create members in text files like ISPF and OMVS that are 
>easily viewed. The level can also be embedded in dataset names used for 
>migration. Before we IPL a system at a new level, we run a Rexx that checks 
>consistency among various components to verify that all relevant pieces have 
>been migrated properly.  


My IPLINFO exec will display that information if present.   I added it years 
ago based on a user
that did what you do.   

Here is what I do:   For my IBM sysres (there is also an "ISV sysres" part of 
the complete sysres set), 
there is an uncataloged data set that we update.   A change log:


 BROWSE$$INFO.MAINT.HISTORY   Line  Col 0
 Command ===>  Scroll ===
* Top of Data ***
DATE  WHO  WHAT WAS CHANGED ON THE Z/OS 2.1 MAINTENANCE SYSRES   
  ---  - 
08/04/15  MSZ  Applied RSU maint up to RSU1506. About 245 PTFs went on.  
07/07/15  MSZ  Applied 32 additional z13 PTFs.   
04/22/15  MSZ  Applied RSU maint up to RSU1503. About 230 PTFs went on.  

Someone can look at the current / live sysres on any system and browse the data 
set to see
what is actually on that sysres.   As others do, we clone the SMP/E target zone 
along with
a sysres set, so if exact PTF details are needed one has to do an SMP/E query 
to find
out what sets the PTF is actually running on.   

My (maintenance) ISV sysres has something similar to the OS, but it is a PDS. 
There is a change log member ($$HIST) for anything touched on the maintenance 
ISV sysres and also a PDS member for every product whos name matches the
same identifier that is used in our data set naming convention:

-
BROWSE$$INFO.PRODUCTS
Command ===> 
   Name Prompt   
_ MIM
_ OMEGAMON   
_ PANSQL 
_ PSYNCH 
_ PWX


The individual product members are in addition to our other software doc we 
keep 
to simply identify what versionand maintenance level of a product is on a given 
sysres 
set (some times other relevant notes are added).   This is desired because 
during
roll out of maintenance or upgrades (done via rolling IPLs), some LPARs can be 
running
on a different maintenance level or release level of any given product just 
like operating
system maintenance.  This gives the team an easy way to identify
what is actually being used in the live environment for any given LPAR. 


  BROWSE$$INFO.PRODUCTS(MIM) - 11.17 
  Command ===>   
 * Top of Data **
 CA MIM: Release 12.1 SP0 + all PTFs a/o 07/07/2015  
  Bottom of Data 

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/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Concatenated datasets read information.

[Shmuel Metz (Seymour J.)]

In <039701d0f08d$2138cd10$63aa6730$@mcn.org>, on 09/16/2015
   at 07:36 AM, Charles Mills  said:

>Couldn't you just save off DCBTIOT and compare it before (after?)
>every GET?

Yes if you've set unlike attributes, not otherwise. Curse OCO!
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Restore time question

[Tony Thigpen]

Backing up and restoring a Dasd.

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15, but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?

--
Tony Thigpen

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

Re: RSU or maintenance level on a system

[Shmuel Metz (Seymour J.)]

In
,
on 09/16/2015
   at 12:27 PM, "Lopez, Sharon"  said:

>Our auditors want to be able to display the RSU or maintenance level
>of our z/OS system. 

Why? It won't tell the what service is applied.

>Keep in mind that our auditors do know z/OS or mainframe.

ITYM do NOT know.

>It sounds like they are used to seeing displays on other platforms
>with this information with release and fix level.

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

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

Re: Concatenated datasets read information.

[Shmuel Metz (Seymour J.)]

In <20150916131602.7f3503e0...@listserv01.ua.edu>, on 09/16/2015
   at 09:15 AM, Art Celestini  said:

>As Chris Blaicher indicated, find the TIOT entry using DCBTIOT and
>TIOEJFCB will contain an SVA for the JFCB. 

In a concatenation there are multipkle TIOT entries; you need to fiind
the right one. Unless you are using the unlike attributes option,
DCBTIOT points to the first entry. In the general case you need to
know the control block structure, which is no longer available to
normal users.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

z/OS V2.2 IBM Education Assistance

[Marna WALLE]

We've recently placed on the web ( 
http://www.redbooks.ibm.com/redbooks.nsf/pages/IBMIEAV22avail?Open ) new 
materials associated with z/OS V2.2.  If you're not familiar with IBM Education 
Assistance (not to be confused with IBM Education Assistant), these are modules 
that can give you "soup to nuts" information on a specific new function in 
z/OS.  Or, it might contain all the enhancements in a specific component for 
z/OS V2.2.  

It's a great place to go shopping for new functions that might interest you in 
z/OS V2.2.  All enhancements are sorted by interest area to help you find an 
enhancement that may appeal to you:  Availability, Scalability & Performance, 
Usability & z/OSMF, Industry & Open Standards, Security, Networking, and 
Installation & Migration.  We've got approximately 100 modules available, so 
there's something for everyone.

The modules are usually provided in PDF format.  They all follow a template to 
make them easily understood.  The template looks like:
Overview,  Usage & Invocation,  Interactions & Dependencies,  Migration & 
Coexistence Considerations, and Installation.

We hope that this material will help you discover and use new z/OS functions in 
a easy way.  Of course, this information is supplemental to the official 
publications, but with this information sliced "horizontally" across books, it 
may be able to see the larger picture from these modules than reading in just 
one book.

I welcome any feedback on the IBM Education Assistance for z/OS!
-Marna WALLE
z/OS System Installation, IBM Poughkeepsie

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

Re: Restore time question

[Tony Thigpen]

No hardware changes.
We restored our system to our dr box using our recovery system. Took 
5:08. Brought up our system, then did a backup. Took 1:15 (and some 
other stuff was running).


Tony Thigpen

Rob Schramm wrote on 09/16/2015 03:29 PM:

Same tape subsystem?

Rob Schramm

On Wed, Sep 16, 2015, 3:21 PM Tony Thigpen  wrote:


Backing up and restoring a Dasd.

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15, but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?

--
Tony Thigpen

--
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: AMASPZAP to C main marked as $private

[Barry Lichtenstein]

If you are in this situation, and you do not have the source to recompile, but 
you are able to rebind the module, you can use the binder control statement 
CHANGE (or REPLACE) to turn the private section name into an actual name.  This 
capability was introduced in z/OS V1R13.

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

NFS Client implementation query

[RCG]

Dear Listers,

Need expert advise here on the NFS Client implementation on zOS platform

- I've configured the parms in BPXPRMxx.
- Had set-up the STC proc in the active proclib
- Had made necessary Security definitions (STC ID, definition to STARTED
CLASS, dataset access)

However, When I start the task, It starts and ends in less than minute
although with CC = 0.

Any recommendation why here ?

Highly appreciate the pointers what is missing here please.

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

Re: Restore time question

[Rob Schramm]

Same tape subsystem?

Rob Schramm

On Wed, Sep 16, 2015, 3:21 PM Tony Thigpen  wrote:

> Backing up and restoring a Dasd.
>
> Using ADRDSSU:
> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
> RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN
>
> All the dasd can be backed up in 1:15, but restore takes 5:08.
>
> Are we doing something wrong, or is this 4.5x longer normal?
>
> --
> Tony Thigpen
>
> --
> 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: Restore time question

[Porowski, Ken]

So the cache was loaded when you did the backup ...



CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Wednesday, September 16, 2015 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Restore time question

No hardware changes.
We restored our system to our dr box using our recovery system. Took 5:08. 
Brought up our system, then did a backup. Took 1:15 (and some other stuff was 
running).

Tony Thigpen

Rob Schramm wrote on 09/16/2015 03:29 PM:
> Same tape subsystem?
>
> Rob Schramm
>
> On Wed, Sep 16, 2015, 3:21 PM Tony Thigpen  wrote:
>
>> Backing up and restoring a Dasd.
>>
>> Using ADRDSSU:
>> DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
>> RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN
>>
>> All the dasd can be backed up in 1:15, but restore takes 5:08.
>>
>> Are we doing something wrong, or is this 4.5x longer normal?
>>
>> --
>> Tony Thigpen
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

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


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

Re: Restore time question

[Tony Thigpen]

I would also think that working with 500+ mostly full 3390-3 and 100+ 
mostly full 3390-9 volumes would have flushed the cache.


Tony Thigpen

Porowski, Ken wrote on 09/16/2015 05:09 PM:

So the cache was loaded when you did the backup ...



CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sen

t from or received at this email address.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Wednesday, September 16, 2015 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Restore time question

No hardware changes.
We restored our system to our dr box using our recovery system. Took 5:08. 
Brought up our system, then did a backup. Took 1:15 (and some other stuff was 
running).

Tony Thigpen

Rob Schramm wrote on 09/16/2015 03:29 PM:

Same tape subsystem?

Rob Schramm

On Wed, Sep 16, 2015, 3:21 PM Tony Thigpen  wrote:


Backing up and restoring a Dasd.

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15, but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?

--
Tony Thigpen

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



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




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


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




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

Re: Restore time question

[Tony Thigpen]

With the method mentioned, what is happening, in the area of 
reorganization, during the restore?


If reorganization is occurring, is there a method to stop the reorg?

Tony Thigpen

Tony Thigpen wrote on 09/16/2015 03:20 PM:

Backing up and restoring a Dasd.

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15, but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?



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

Re: RSU or maintenance level on a system

[J O Skip Robinson]

We may be zapping our label in NUC at an unconventional spot. IPLINFO does not 
show it. Here's what we see at IPL time. 

   IEA008I R13V   PARMS FOLLOW FOR z/OS 01.13.00 HBB7780

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Wednesday, September 16, 2015 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

On Wed, 16 Sep 2015 15:50:20 +, Bob Shannon  
wrote:

>We apply PUT maintenance, not RSU, but we have a usermod to update 
>CVTVERID with maintenance level. If you did that you could give the 
>auditors some Rexx code  to display the value.

My last post mentioned IPLINFO for displaying what Skip was referring to.  This 
is actually what IPLINFO will display if present.  

Mark
Best Regards / Mit freundlichen Grüßen,

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/


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

Re: NFS Client implementation query

[Scott Ford]

You mentioned client? Where's the server located ?

On Wednesday, September 16, 2015, RCG  wrote:

> Dear Listers,
>
> Need expert advise here on the NFS Client implementation on zOS platform
>
> - I've configured the parms in BPXPRMxx.
> - Had set-up the STC proc in the active proclib
> - Had made necessary Security definitions (STC ID, definition to STARTED
> CLASS, dataset access)
>
> However, When I start the task, It starts and ends in less than minute
> although with CC = 0.
>
> Any recommendation why here ?
>
> Highly appreciate the pointers what is missing here please.
>
> --
> 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: IPL Shutdown Problem

[Anthony Thompson]

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

--
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: IPL Shutdown Problem

[J O Skip Robinson]

The problem is OP's shutdown logic. Not all tasks need to be shut down, and 
those that do not run under JES2 cannot be shut down using JES2 commands. The 
message 

   IEE707I $DA,XNOT EXECUTED

indicates that JES2 itself has already terminated and therefore cannot be 
called upon to shut down any other task. Since JES2 has already terminated, any 
tasks still running either do not need to be terminated (RACF task is one), or 
run SUB=MSTR and must be terminated via commands directly to the task itself.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, September 16, 2015 8:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M


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

Re: SMPE -removal of USERMOD ++HOLD created instream

[Bruce Hewson]

Thank you Tom,

> Did you specify HOLDDATA on the REJECT command?

And simply adding HOLDDATA to my REJECT command solved all these problems.

Thanks again
Bruce Hewson

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

Re: IPL Shutdown Problem

[Meenakshi, Vinoth - CW]

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

--
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: IPL Shutdown Problem

[Anthony Thompson]

ROUTE command not working is a completely separate issue. It won't happen if 
that LPAR is outside of the sysplex. You'll need a console on that system. Use 
the HMC if you need to, assuming you have one. 

Try the F OMVS, STOPPFS=FZS command on a SYS9 console. F 
BPXOINIT,SHUTDOWN=FORKINIT should bring down both ZFS and OMVS.

$PJES2,ABEND if you absolutely have to.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

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

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

Re: IPL Shutdown Problem

[Meenakshi, Vinoth - CW]

Hi Ant,

We couldn't able to access commands from master console or HMC, since the 
system went onto wait-state.

Central processor (CP) 0 is in a nonrestartable stopped state due to a System 
Control Program (SCP) initiated reset of the I/O interface for partition LPAR4. 
The disabled wait program status word (PSW) is 0002800040a2.

Could you assist how we move forward from here. Thanks

Regards,
Vinoth M

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

ROUTE command not working is a completely separate issue. It won't happen if 
that LPAR is outside of the sysplex. You'll need a console on that system. Use 
the HMC if you need to, assuming you have one. 

Try the F OMVS, STOPPFS=FZS command on a SYS9 console. F 
BPXOINIT,SHUTDOWN=FORKINIT should bring down both ZFS and OMVS.

$PJES2,ABEND if you absolutely have to.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

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

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

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

Re: IPL Shutdown Problem

[Anthony Thompson]

Most typically, that wait state is entered when the system has been 
deliberately shut down by operators.

Re-IPL.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Hi Ant,

We couldn't able to access commands from master console or HMC, since the 
system went onto wait-state.

Central processor (CP) 0 is in a nonrestartable stopped state due to a System 
Control Program (SCP) initiated reset of the I/O interface for partition LPAR4. 
The disabled wait program status word (PSW) is 0002800040a2.

Could you assist how we move forward from here. Thanks

Regards,
Vinoth M

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

ROUTE command not working is a completely separate issue. It won't happen if 
that LPAR is outside of the sysplex. You'll need a console on that system. Use 
the HMC if you need to, assuming you have one. 

Try the F OMVS, STOPPFS=FZS command on a SYS9 console. F 
BPXOINIT,SHUTDOWN=FORKINIT should bring down both ZFS and OMVS.

$PJES2,ABEND if you absolutely have to.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Meenakshi, Vinoth - CW
Sent: Thursday, 17 September 2015 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Thanks Ant & Lizette.

F OMVS,STOPPFS=ZFS command worked and we were able to bring down ZFS for one 
systemSYS3 and for other system SYS9 we are facing an issue.

OMVS is down and we tried to issue STOPPFS=ZFS command and it's not allowing.

RESPONSE=SYS1  IEE618I  ROUTE   COMMAND REJECTED.  SYS9

I think the system is out of sysplex now and still the below STC are running in 
SYS9.

  ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Regards,
Vinoth M


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, September 17, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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

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

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

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

IPL Shutdown Problem

[Meenakshi, Vinoth - CW]

Hi All,

We are having issue with bringing down the JES2,two of the STC are running and 
it's not coming down. Even Purge command is not working.

   ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
  SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9

Even we can't able issue command from other systems.

RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED

Kindly guide us on this.

Thanks.
Vinoth M

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

Re: IPL Shutdown Problem

[Lizette Koehler]

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are running 
> and it's
> not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M

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