SRU FTP Site now HTTP

2007-02-08 Thread Fran Hensler
About a month ago I posted here that updates to CHARLOTTe for HTTPS
were available on my VM FTP site.  That's when I discovered that
there were firewall issues with the VM FTP.

So I have made all of the files available via HTTP.  It is just a CMS
FILELIST with a DOWNLOAD button on each line but it works.

Go to:  http://zvm.sru.edu/~download

The site is running on an 18 MIP FLEX-ES z/VM 3.1 system with Rick
Troth's WEBSHARE, also available on this site.

/Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years
 [EMAIL PROTECTED] +1.724.738.2153
Yes, Virginia, there is a Slippery Rock


Re: Tivoli Business Systems Manager

2007-02-08 Thread David Boyes
Yes. You can trigger a user defined event in TBSM via SNMP traps and/or
via routing NJE messages through a managed z/OS system if you have the
TBSM agent on z/OS. 

Drop me a note offline for more details. 

 One of our operators has asked if there's a way to send alerts from VM
 to Tivoli Business Systems Manager.  I looked at IBM's web site, and
it
 lists products for z/OS and distributed systems that can send alerts,
 but doesn't mention VM.  Is there a product or home-grown solution
that
 will do this?  We're running VM:Operator on VM, but the operators
won't
 watch the consoles.


Re: Tivoli Business Systems Manager

2007-02-08 Thread barton
ESATCP and ESAMON can send SNMP alerts. Alerts can be sent on any 
linux or z/vm variable that esamon supports.




Alan Altmark wrote:

On Wednesday, 02/07/2007 at 06:07 PST, O'Brien, Dennis L 
Dennis.L.O'[EMAIL PROTECTED] wrote:



One of our operators has asked if there's a way to send alerts from VM
to Tivoli Business Systems Manager.  I looked at IBM's web site, and it
lists products for z/OS and distributed systems that can send alerts,
but doesn't mention VM.  Is there a product or home-grown solution that
will do this?



If ITBSM is looking for SNMP traps, then you can compile the DPISAMPL C 
program and use it to send alerts.  If ITBSM uses the Tivoli Framework, 
then you should be able to e-mail a Linux guest to generate the Event for 
you.


Alan Altmark
z/VM Development
IBM Endicott





Re: Tivoli Business Systems Manager

2007-02-08 Thread Thomas Kern
So Tivoli Business Systems Manager (TBSM) doesn't have a straight forward

TCPIP interface like BigBrother and Hobbit? Has Tivoli issued a Statement
 of
Direction about eventually providing a VM/CMS agent and supporting z/VM a
s a
real player in an enterprise network?

/Thomas Kern
/301-903-2211

On Thu, 8 Feb 2007 09:42:17 -0500, David Boyes [EMAIL PROTECTED] wr
ote:
Yes. You can trigger a user defined event in TBSM via SNMP traps and/or
via routing NJE messages through a managed z/OS system if you have the
TBSM agent on z/OS. 

Drop me a note offline for more details. 

 One of our operators has asked if there's a way to send alerts from VM

 to Tivoli Business Systems Manager. I looked at IBM's web site, and it

 lists products for z/OS and distributed systems that can send alerts,
 but doesn't mention VM.  Is there a product or home-grown solution
 that will do this?  
 We're running VM:Operator on VM, but the operators won't
 watch the consoles.

=
===


Re: Tivoli Business Systems Manager

2007-02-08 Thread Adam Thornton

On Feb 8, 2007, at 9:26 AM, Thomas Kern wrote:

Has Tivoli issued a Statement
 of
Direction about eventually providing a VM/CMS agent and supporting  
z/VM a

s a
real player in an enterprise network?


BWAHAHAHAHAHAHA!

Good one!

Adam


Re: Tivoli Business Systems Manager

2007-02-08 Thread Alan Altmark
On Thursday, 02/08/2007 at 09:26 CST, Thomas Kern [EMAIL PROTECTED] 
wrote:
 So Tivoli Business Systems Manager (TBSM) doesn't have a straight 
forward
 TCPIP interface like BigBrother and Hobbit? Has Tivoli issued a 
Statement of
 Direction about eventually providing a VM/CMS agent and supporting z/VM 
as a
 real player in an enterprise network?

Just practicing for Friday, eh?  :-)  I think that Tivoli is moving away 
from the Framework and more to standards-based communications.  That means 
Tivoli doesn't have to build it.  We have an open requirement to provide a 
CMS command interfaces to generate SNMP traps.  That is, to ship DPISAMPL 
pre-built and supported.

Alan Altmark
z/VM Development
IBM Endicott


Re: SRU FTP Site now HTTP

2007-02-08 Thread StephenPFrazieVM
This is a nice web site. What software do you use to drive it? I would like to set up something like 
it on my z/VM 3.1 system.


[EMAIL PROTECTED] wrote:

About a month ago I posted here that updates to CHARLOTTe for HTTPS
were available on my VM FTP site.  That's when I discovered that
there were firewall issues with the VM FTP.

So I have made all of the files available via HTTP.  It is just a CMS
FILELIST with a DOWNLOAD button on each line but it works.

Go to:  http://zvm.sru.edu/~download

The site is running on an 18 MIP FLEX-ES z/VM 3.1 system with Rick
Troth's WEBSHARE, also available on this site.

/Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years
 [EMAIL PROTECTED] +1.724.738.2153
Yes, Virginia, there is a Slippery Rock


Re: SRU FTP Site now HTTP

2007-02-08 Thread Stephen Frazier

This is a nice web site. What software do you use to drive it? I would like to 
set up something like
it on my z/VM 3.1 system.

[EMAIL PROTECTED] wrote:

About a month ago I posted here that updates to CHARLOTTe for HTTPS
were available on my VM FTP site.  That's when I discovered that
there were firewall issues with the VM FTP.

So I have made all of the files available via HTTP.  It is just a CMS
FILELIST with a DOWNLOAD button on each line but it works.

Go to:  http://zvm.sru.edu/~download

The site is running on an 18 MIP FLEX-ES z/VM 3.1 system with Rick
Troth's WEBSHARE, also available on this site.

/Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years
 [EMAIL PROTECTED] +1.724.738.2153
Yes, Virginia, there is a Slippery Rock




--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email:  stevef%doc.state.ok.us


backup prior to maintenance

2007-02-08 Thread Anne Crabtree
I would like to know what the recommended procedure is for backing up the 
system prior to applying maintenance (and how to restore if there is a 
problem!!).  The last time I did maintenance, I backed up 510RES with DDRXA and 
when PUT2PROD had errors, restored 510RES from that tape.  To make a long story 
short, it really messed up the spool and I ended up on the phone for hours with 
IBM.  I need to put maintenance on again and want to make sure and do it right 
this time.  


Re: Tivoli Business Systems Manager

2007-02-08 Thread David Boyes
 So Tivoli Business Systems Manager (TBSM) doesn't have a straight
forward
 TCPIP interface like BigBrother and Hobbit? 

*Nothing* about TBSM is straightforward. 8-)

Few (if any) of the enterprise management tools like this have simple
interfaces. SNMP tends to be the only supported method for dealing with
unsupported systems, usually via a undefined trap that takes a text
string as an argument. 

 Has Tivoli issued a Statement of
 Direction about eventually providing a VM/CMS agent 
 and supporting z/VM as a
 real player in an enterprise network?

I'll leave it to Alan or one of the IBMers to make an official comment,
but the Tivoli people I've spoken to don't seem to understand that
end-to-end control and monitoring requires monitoring of all the layers
in a solution, and that z/VM is one of those layers, just as LPAR is. If
you draw the picture of LPAR -- VM -- Linux guests and say what do
you do about controlling that critical resource allocation layer between
the LPAR and the Linux guest it gets very, very quiet. 


Re: SRU FTP Site now HTTP

2007-02-08 Thread Fran Hensler
Stephen -

I am using Rick Troth's WEBSHARE that he wrote for VM back at the
dawn of the Internet.  The WEBSHARE package is available on my
web site:  http://zvm.sru.edu/~download

/Fran

On Thu, 8 Feb 2007 10:01:34 -0600 StephenPFrazieVM said:
This is a nice web site. What software do you use to drive it? I would like to 
set up something like
it on my z/VM 3.1 system.

[EMAIL PROTECTED] wrote:
 About a month ago I posted here that updates to CHARLOTTe for HTTPS
 were available on my VM FTP site.  That's when I discovered that
 there were firewall issues with the VM FTP.

 So I have made all of the files available via HTTP.  It is just a CMS
 FILELIST with a DOWNLOAD button on each line but it works.

 Go to:  http://zvm.sru.edu/~download

 The site is running on an 18 MIP FLEX-ES z/VM 3.1 system with Rick
 Troth's WEBSHARE, also available on this site.

 /Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years
  [EMAIL PROTECTED] +1.724.738.2153
 Yes, Virginia, there is a Slippery Rock


Re: SRU FTP Site now HTTP

2007-02-08 Thread Thomas Kern
Down near the bottom of the website is a line for WEBSHARE VMARC. Click o
n
the 'Download' button at the right side of that line. Download the packag
e.
Upload the package to your system. Unpack it and read all the documentati
on.
 Webshare is an excellent webserver for a small site.

As our webserving workload on VM decreases, I will be looking at going ba
ck
to this free program for our web services.

/Thomas Kern
/301-903-2211

On Thu, 8 Feb 2007 10:02:49 -0600, Stephen Frazier [EMAIL PROTECTED]
s
wrote:
This is a nice web site. What software do you use to drive it? I would l
ike
to set up something like
it on my z/VM 3.1 system.

[EMAIL PROTECTED] wrote:
 About a month ago I posted here that updates to CHARLOTTe for HTTPS
 were available on my VM FTP site.  That's when I discovered that
 there were firewall issues with the VM FTP.

 So I have made all of the files available via HTTP.  It is just a CMS
 FILELIST with a DOWNLOAD button on each line but it works.

 Go to:  http://zvm.sru.edu/~download

 The site is running on an 18 MIP FLEX-ES z/VM 3.1 system with Rick
 Troth's WEBSHARE, also available on this site.


Re: SRU FTP Site now HTTP

2007-02-08 Thread David Boyes
  Webshare is an excellent webserver for a small site.

And positive proof that really useful tools can be written in hours
using REXX and CMS pipelines. Especially when beer is at stake...8-)

-- db


Re: backup prior to maintenance

2007-02-08 Thread Anne Crabtree
I would be applying on a first level system.  I have no idea what minidisks are 
affected.  I've only done maintenance twice, once the long way (with IBM here 
and it was no picnic) and the second time where it was a complete mess.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good enough?  
If there are problems, can I restore both and be ok?  Sorry, I guess I wasn't 
clear enough!

 [EMAIL PROTECTED] 2/8/2007 11:23 AM 
If you are running a second-level guest to do your maintenance in, then t=
he
best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from=

the first level MAINT userid. Then bring up your second-level guest, appl=
y
and test the maintenance (shutting down and restoring as necessary). Then=

migrate the good maintenance to your first-level production system. 

If you are applying your maintenance to minidisks on a first-level system=
,
then you need to backup the individual minidisks used in the maintenance
process. Then if something goes wrong in your VMSES processing, you can
restore the affected minidisks. This will keep you from stomping on SPOOL=
 or
user minidisks.

/Tom Kern
/301-903-2211

On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] =
wrote:
I would like to know what the recommended procedure is for backing up th=
e
system prior to applying maintenance (and how to restore if there is a
problem!!).  The last time I did maintenance, I backed up 510RES with DDR=
XA
and when PUT2PROD had errors, restored 510RES from that tape.  To make a
long story short, it really messed up the spool and I ended up on the pho=
ne
for hours with IBM.  I need to put maintenance on again and want to make
sure and do it right this time.  
=
==
===


Re: backup prior to maintenance

2007-02-08 Thread Huegel, Thomas
Anne,
I would use DDRXA to backup 510res, 510w01, 510w02 then use SPXTAPE to
backup the spool files.

Tom

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Anne Crabtree
Sent: Thursday, February 08, 2007 10:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: backup prior to maintenance


I would be applying on a first level system.  I have no idea what minidisks
are affected.  I've only done maintenance twice, once the long way (with IBM
here and it was no picnic) and the second time where it was a complete mess.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!

 [EMAIL PROTECTED] 2/8/2007 11:23 AM 
If you are running a second-level guest to do your maintenance in, then t=
he
best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from=

the first level MAINT userid. Then bring up your second-level guest, appl=
y
and test the maintenance (shutting down and restoring as necessary). Then=

migrate the good maintenance to your first-level production system. 

If you are applying your maintenance to minidisks on a first-level system=
,
then you need to backup the individual minidisks used in the maintenance
process. Then if something goes wrong in your VMSES processing, you can
restore the affected minidisks. This will keep you from stomping on SPOOL=
 or
user minidisks.

/Tom Kern
/301-903-2211

On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] =
wrote:
I would like to know what the recommended procedure is for backing up th=
e
system prior to applying maintenance (and how to restore if there is a
problem!!).  The last time I did maintenance, I backed up 510RES with DDR=
XA
and when PUT2PROD had errors, restored 510RES from that tape.  To make a
long story short, it really messed up the spool and I ended up on the pho=
ne
for hours with IBM.  I need to put maintenance on again and want to make
sure and do it right this time.  
=
==
===


__
 ella for Spam Control  has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com


Re: backup prior to maintenance

2007-02-08 Thread StephenPFrazieVM

Your first message was clear. The answer is still the same.

If you are applying your maintenance to minidisks on a first-level system, then you need to backup 
the individual minidisks used in the maintenance process. Then if something goes wrong in your VMSES 
processing, you can restore the affected minidisks. This will keep you from stomping on SPOOL or 
user minidisks.


[EMAIL PROTECTED] wrote:

I would be applying on a first level system.  I have no idea what minidisks are 
affected.  I've only done maintenance twice, once the long way (with IBM here 
and it was no picnic) and the second time where it was a complete mess.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good enough?  
If there are problems, can I restore both and be ok?  Sorry, I guess I wasn't 
clear enough!


[EMAIL PROTECTED] 2/8/2007 11:23 AM 

If you are running a second-level guest to do your maintenance in, then t=
he
best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from=

the first level MAINT userid. Then bring up your second-level guest, appl=
y
and test the maintenance (shutting down and restoring as necessary). Then=

migrate the good maintenance to your first-level production system. 


If you are applying your maintenance to minidisks on a first-level system=
,
then you need to backup the individual minidisks used in the maintenance
process. Then if something goes wrong in your VMSES processing, you can
restore the affected minidisks. This will keep you from stomping on SPOOL=
 or
user minidisks.

/Tom Kern
/301-903-2211

On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] =
wrote:

I would like to know what the recommended procedure is for backing up th=

e
system prior to applying maintenance (and how to restore if there is a
problem!!).  The last time I did maintenance, I backed up 510RES with DDR=
XA
and when PUT2PROD had errors, restored 510RES from that tape.  To make a
long story short, it really messed up the spool and I ended up on the pho=
ne
for hours with IBM.  I need to put maintenance on again and want to make
sure and do it right this time.  

=

==
===


Re: backup prior to maintenance

2007-02-08 Thread Schuh, Richard
Anne,

We do our maintenance on the first level system. We rely on our daily
backup process as our safety net. Since we keep backups for several
months, we can go back to any prior day's image. Because we don't do
maintenance every day, the MAINT disks are reasonably stable and this
type of backup is, we feel, sufficient. 

Regards, 
Richard Schuh 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of StephenPFrazieVM
Sent: Thursday, February 08, 2007 8:44 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: backup prior to maintenance

Your first message was clear. The answer is still the same.

If you are applying your maintenance to minidisks on a first-level
system, then you need to backup 
the individual minidisks used in the maintenance process. Then if
something goes wrong in your VMSES 
processing, you can restore the affected minidisks. This will keep you
from stomping on SPOOL or 
user minidisks.

[EMAIL PROTECTED] wrote:
 I would be applying on a first level system.  I have no idea what
minidisks are affected.  I've only done maintenance twice, once the long
way (with IBM here and it was no picnic) and the second time where it
was a complete mess.
 Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!
 
 [EMAIL PROTECTED] 2/8/2007 11:23 AM 
 If you are running a second-level guest to do your maintenance in,
then t=
 he
 best way is to shutdown the SECOND-LEVEL guest and dump it using DDR
from=
 
 the first level MAINT userid. Then bring up your second-level guest,
appl=
 y
 and test the maintenance (shutting down and restoring as necessary).
Then=
 
 migrate the good maintenance to your first-level production system. 
 
 If you are applying your maintenance to minidisks on a first-level
system=
 ,
 then you need to backup the individual minidisks used in the
maintenance
 process. Then if something goes wrong in your VMSES processing, you
can
 restore the affected minidisks. This will keep you from stomping on
SPOOL=
  or
 user minidisks.
 
 /Tom Kern
 /301-903-2211
 
 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree
[EMAIL PROTECTED] =
 wrote:
 I would like to know what the recommended procedure is for backing up
th=
 e
 system prior to applying maintenance (and how to restore if there is a
 problem!!).  The last time I did maintenance, I backed up 510RES with
DDR=
 XA
 and when PUT2PROD had errors, restored 510RES from that tape.  To make
a
 long story short, it really messed up the spool and I ended up on the
pho=
 ne
 for hours with IBM.  I need to put maintenance on again and want to
make
 sure and do it right this time.  
 =
 ==
 ===


Re: backup prior to maintenance

2007-02-08 Thread Thomas Kern
Don't worry about the clarity of your postings, we all need to refine our

descriptions through repetition. Okay, you are running maintenance on
first-level and you do not have a CMS or minidisk level product to backup

your  allocations. Figuring out what minidisks VMSES will use for any
particular component is possible via the PPF and the user directory, but 
is
too detailed for what you want to do. You want to run one quick process t
o
backup everything, then apply maintenance and if necessary run one proces
s
to restore everything. 

We can't quite give you that yet. But Tom Huegel has it right. A two part

process, one part to backup your entire DASD subsystem (510RES, 510W01,
510W02, 510Wxx, etc). Do not backup the page or spool volumes with DDR. T
he
second part is to backup all of the SPOOL files using the SPXTAPE command
.
When you do have to restore back to this point-in-time, you can use DDR
standalone to restore the DASD, then IPL and do a CLEAN NOAUTOLOG start. 
At
this point, you can be on OPERATOR, mount the tape containing your SPXTAP
E
backup and use SPXTAPE LOAD to restore all the files, and then shutdown
reipl to restart your restored system. 

/Tom Kern
/301-903-2211


On Thu, 8 Feb 2007 11:33:58 -0500, Anne Crabtree [EMAIL PROTECTED] 
wrote:
I would be applying on a first level system.  I have no idea what minidi
sks
are affected.  I've only done maintenance twice, once the long way (with 
IBM
here and it was no picnic) and the second time where it was a complete me
ss.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!


Re: backup prior to maintenance

2007-02-08 Thread Anne Crabtree
ok thanks will try that... 

 [EMAIL PROTECTED] 2/8/2007 11:39 AM 
Anne,
I would use DDRXA to backup 510res, 510w01, 510w02 then use SPXTAPE to
backup the spool files.

Tom

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
Behalf Of Anne Crabtree
Sent: Thursday, February 08, 2007 10:34 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: backup prior to maintenance


I would be applying on a first level system.  I have no idea what minidisks
are affected.  I've only done maintenance twice, once the long way (with IBM
here and it was no picnic) and the second time where it was a complete mess.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!

 [EMAIL PROTECTED] 2/8/2007 11:23 AM 
If you are running a second-level guest to do your maintenance in, then t=
he
best way is to shutdown the SECOND-LEVEL guest and dump it using DDR from=

the first level MAINT userid. Then bring up your second-level guest, appl=
y
and test the maintenance (shutting down and restoring as necessary). Then=

migrate the good maintenance to your first-level production system. 

If you are applying your maintenance to minidisks on a first-level system=
,
then you need to backup the individual minidisks used in the maintenance
process. Then if something goes wrong in your VMSES processing, you can
restore the affected minidisks. This will keep you from stomping on SPOOL=
 or
user minidisks.

/Tom Kern
/301-903-2211

On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree [EMAIL PROTECTED] =
wrote:
I would like to know what the recommended procedure is for backing up th=
e
system prior to applying maintenance (and how to restore if there is a
problem!!).  The last time I did maintenance, I backed up 510RES with DDR=
XA
and when PUT2PROD had errors, restored 510RES from that tape.  To make a
long story short, it really messed up the spool and I ended up on the pho=
ne
for hours with IBM.  I need to put maintenance on again and want to make
sure and do it right this time.  
=
==
===


__
 ella for Spam Control  has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com


Re: backup prior to maintenance

2007-02-08 Thread Huegel, Thomas
Anne,
Just a quick FYI about SPXTAPE you want to be sure to backup the system data
files, (IMG, NLS, NSS, TRFILES, and UCR)I think the option is SDF. These are
the spool files you would want to restore.

Tom   

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Anne Crabtree
Sent: Thursday, February 08, 2007 11:17 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: backup prior to maintenance


The only backups we do are full volume backups once a week on z/os, but I
want to go back to prior to maintenance if I have a problem.  So, gonna try
to do what Tom suggested.

 [EMAIL PROTECTED] 2/8/2007 12:04 PM 
Anne,

We do our maintenance on the first level system. We rely on our daily
backup process as our safety net. Since we keep backups for several
months, we can go back to any prior day's image. Because we don't do
maintenance every day, the MAINT disks are reasonably stable and this
type of backup is, we feel, sufficient. 

Regards, 
Richard Schuh 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of StephenPFrazieVM
Sent: Thursday, February 08, 2007 8:44 AM
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: backup prior to maintenance

Your first message was clear. The answer is still the same.

If you are applying your maintenance to minidisks on a first-level
system, then you need to backup 
the individual minidisks used in the maintenance process. Then if
something goes wrong in your VMSES 
processing, you can restore the affected minidisks. This will keep you
from stomping on SPOOL or 
user minidisks.

[EMAIL PROTECTED] wrote:
 I would be applying on a first level system.  I have no idea what
minidisks are affected.  I've only done maintenance twice, once the long
way (with IBM here and it was no picnic) and the second time where it
was a complete mess.
 Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!
 
 [EMAIL PROTECTED] 2/8/2007 11:23 AM 
 If you are running a second-level guest to do your maintenance in,
then t=
 he
 best way is to shutdown the SECOND-LEVEL guest and dump it using DDR
from=
 
 the first level MAINT userid. Then bring up your second-level guest,
appl=
 y
 and test the maintenance (shutting down and restoring as necessary).
Then=
 
 migrate the good maintenance to your first-level production system. 
 
 If you are applying your maintenance to minidisks on a first-level
system=
 ,
 then you need to backup the individual minidisks used in the
maintenance
 process. Then if something goes wrong in your VMSES processing, you
can
 restore the affected minidisks. This will keep you from stomping on
SPOOL=
  or
 user minidisks.
 
 /Tom Kern
 /301-903-2211
 
 On Thu, 8 Feb 2007 11:10:50 -0500, Anne Crabtree
[EMAIL PROTECTED] =
 wrote:
 I would like to know what the recommended procedure is for backing up
th=
 e
 system prior to applying maintenance (and how to restore if there is a
 problem!!).  The last time I did maintenance, I backed up 510RES with
DDR=
 XA
 and when PUT2PROD had errors, restored 510RES from that tape.  To make
a
 long story short, it really messed up the spool and I ended up on the
pho=
 ne
 for hours with IBM.  I need to put maintenance on again and want to
make
 sure and do it right this time.  
 =
 ==
 ===


__
 ella for Spam Control  has removed VSE-List messages and set aside
VM-List for me
You can use it too - and it's FREE!  http://www.ellaforspam.com


Re: backup prior to maintenance

2007-02-08 Thread Anne Crabtree
OK, have never used SPXTAPE so after looking at manual, is this right?

SPX DUMP 181 SPOOL ALL  

and this will get all standard spool files and system files.

 [EMAIL PROTECTED] 2/8/2007 12:10 PM 
Don't worry about the clarity of your postings, we all need to refine our=

descriptions through repetition. Okay, you are running maintenance on
first-level and you do not have a CMS or minidisk level product to backup=

your  allocations. Figuring out what minidisks VMSES will use for any
particular component is possible via the PPF and the user directory, but =
is
too detailed for what you want to do. You want to run one quick process t=
o
backup everything, then apply maintenance and if necessary run one proces=
s
to restore everything. 

We can't quite give you that yet. But Tom Huegel has it right. A two part=

process, one part to backup your entire DASD subsystem (510RES, 510W01,
510W02, 510Wxx, etc). Do not backup the page or spool volumes with DDR. T=
he
second part is to backup all of the SPOOL files using the SPXTAPE command=
.
When you do have to restore back to this point-in-time, you can use DDR
standalone to restore the DASD, then IPL and do a CLEAN NOAUTOLOG start. =
At
this point, you can be on OPERATOR, mount the tape containing your SPXTAP=
E
backup and use SPXTAPE LOAD to restore all the files, and then shutdown
reipl to restart your restored system. 

/Tom Kern
/301-903-2211


On Thu, 8 Feb 2007 11:33:58 -0500, Anne Crabtree [EMAIL PROTECTED] =
wrote:
I would be applying on a first level system.  I have no idea what minidi=
sks
are affected.  I've only done maintenance twice, once the long way (with =
IBM
here and it was no picnic) and the second time where it was a complete me=
ss.
Can I use DDRXA and just backup 510RES and 510SPL?  Will that be good
enough?  If there are problems, can I restore both and be ok?  Sorry, I
guess I wasn't clear enough!


Re: backup prior to maintenance

2007-02-08 Thread Neubert, Kevin (DIS)
I would use:

spxtape dump 181 sdf all run

See Chapter 4 Step 6 of the Guide for Automated Installation and Service
(GC24-6099-03) for examples.  Also Step 7 covers the system backup
aspects.

Regards,

Kevin

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Anne Crabtree
Sent: Thursday, February 08, 2007 9:57 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: backup prior to maintenance

OK, have never used SPXTAPE so after looking at manual, is this right?

SPX DUMP 181 SPOOL ALL  

and this will get all standard spool files and system files.


Re: backup prior to maintenance

2007-02-08 Thread Thomas Kern
Yes. When I am at risk of damaging all of spool, like restoring the sysre
s
volume, I backup SPOOL ALL. If I am just risking a system data file, like

redefining/resaving a DCSS or NSS then I backup SDF ALL, because I don't
have to restore sysres before restoring just the DCSS/NSS that got mangle
d.

/Tom Kern
/301-903-2211 

On Thu, 8 Feb 2007 12:56:38 -0500, Anne Crabtree [EMAIL PROTECTED] 
wrote:
OK, have never used SPXTAPE so after looking at manual, is this right?

SPX DUMP 181 SPOOL ALL  

and this will get all standard spool files and system files.



spare 3270 terminals for consoles

2007-02-08 Thread phillip
We are nursing along a 3174 controller for our consoles 
and need a few spare 3270 consoles.

Anyone have any that we could buy, beg, borrow, or...
- well we probably couldn't steal them?

Or can you recommend a dealer?

prg

Phillip Gramly
p h i l l i p  at  c d g  dot  w s 
Systems Programmer
Communications Data Group
Champaign, IL

Re: spare 3270 terminals for consoles

2007-02-08 Thread Edward M. Martin
Hello Phillip,
 
Global Hardware Suppliers, Inc.
7595 Mariner Point North, Suite 101
 
Maple Grove, MN 55311
E-Mail: [EMAIL PROTECTED]
Alternate E-Mail: [EMAIL PROTECTED]
Direct Phone: (763) 494-3559
E-Fax: (801) 730-5352
 
 
 
Ed Martin
Aultman Health Foundation
330-588-4723
[EMAIL PROTECTED]
ext. 40441


From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 1:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: spare 3270 terminals for consoles
 

We are nursing along a 3174 controller for our consoles 
and need a few spare 3270 consoles. 

Anyone have any that we could buy, beg, borrow, or... 
- well we probably couldn't steal them? 

Or can you recommend a dealer? 

prg

Phillip Gramly 
p h i l l i p  at  c d g  dot  w s 
Systems Programmer
Communications Data Group
Champaign, IL


Re: backup prior to maintenance

2007-02-08 Thread Kris Buelens

I still use the MAINT 490/190; 493/193 as alternate disks (all products have
two copies of runtime disks).
Fixes land on 490/493.  When I place it in production, I swap the minidisk
addresses in the CP directory.
When it is not OK, swap again and you're done.  (I also added a 49E)

But, PUT2PROD makes this impossible, it overwrites the backup copies.  But,
what prevents you from adding yet another copy, for example MAINT 1190 and
1193.  Then you can either use my swap address technique, or use DDR to copy
190 onto 1190 etc.

I've got a COPYDDR EXEC that makes copying a minidisk as easy as COPYFILE.
For example
  COPYDDR MAINT 190 = 1190

Part of my swap address technique is also that I use the 3 Minidisk password
fields in the directory as description (these passwords are not used if
you've got RACF);  Example
 MDISK 190 3390 nnn sss  RR ALL ZVM520 DEC2006

Another change -that I already explained once here- is that the MDISK label
on MAINT 190/490/x90 tells which CMS must be IPLed, so I've got CMS20A,
CMS22B, and things alike.  The other CMS segments get similary named, eg
CMS20FA and CMS22FB (corresponds to CMSFILES segment).  One needs a change
in SYSPROF and some small program that is saved as system CMS.  Your users
IPL that, it reads the 190 disk label and IPLs a CMS named like that.  Refer
to IPLER on the VM download lib, it contains all what is required.

--
Kris Buelens,
IBM Belgium, VM customer support


Re: spare 3270 terminals for consoles

2007-02-08 Thread Ed Zell
 We are nursing along a 3174 controller for our consoles 
 and need a few spare 3270 consoles. 

 Anyone have any that we could buy, beg, borrow, or... 
 - well we probably couldn't steal them? 

 


Phillip,

  I have a bunch of 3270 terminals that you could have and
  you only have to come to Peoria to get them.  Give me a 
  call and we can work something out.


Ed Zell
(309) 674-8255 x-107
[EMAIL PROTECTED]
.


CONFIDENTIAL NOTICE:  This communication, including any attachments, is 
intended only for the use of the individual or entity to which it is addressed 
and contains information which may be confidential.  If you are not the 
intended recipient, any distribution or copying of this communication is 
strictly prohibited.  If you have received this communication in error, notify 
the sender immediately, delete the communication and destroy all copies. Thank 
you for your compliance.


Re: spare 3270 terminals for consoles

2007-02-08 Thread McKown, John
Replied off-line. But we have 6 here in Texas. You pay for shipping, of
course.
 
 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
  

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 12:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: spare 3270 terminals for consoles



We are nursing along a 3174 controller for our consoles 
and need a few spare 3270 consoles. 

Anyone have any that we could buy, beg, borrow, or... 
- well we probably couldn't steal them? 

Or can you recommend a dealer? 

prg

Phillip Gramly 
p h i l l i p  at  c d g  dot  w s 
Systems Programmer
Communications Data Group
Champaign, IL



Re: z/VM 5.3

2007-02-08 Thread Bob Heerdink
IBM pumps up Linux virtual machines on mainframe OS

In internal tests, IBM says, z/VM 5.3 was able to host more than 1,000 

virtual images on a single copy of the operating system.
http://cwflyris.computerworld.com/t/1252380/38944906/50617/2/


Re: z/VM 5.3

2007-02-08 Thread Adam Thornton

On Feb 8, 2007, at 2:50 PM, Bob Heerdink wrote:


IBM pumps up Linux virtual machines on mainframe OS

In internal tests, IBM says, z/VM 5.3 was able to host more than 1,000

virtual images on a single copy of the operating system.
http://cwflyris.computerworld.com/t/1252380/38944906/50617/2/



Bummer.  That's a 97.5% reduction.

Adam


Does Xen run on zSeries?

2007-02-08 Thread Alan Ackerman
I found this on the web (which does not, of course, make it true) at Linu
x-
Watch at http://www.linux-watch.com/news/NS9118634698.html:

Even now, Jaffe continued, insurance giant Nationwise is using Novell SLE
S 
and Xen in production IBM zSeries mainframes to improve their system 
utilization and save money.

When needs VM?

I like the spelling of Nationwise.

Alan Ackerman
alan(dot)ackerman(at)bank of america(dot)com


Re: Does Xen run on zSeries?

2007-02-08 Thread Jim Elliott [EMAIL PROTECTED]
 I found this on the web (which does not, of course, make it
 true) at Linux-Watch at
 http://www.linux-watch.com/news/NS9118634698.html:

 Even now, Jaffe continued, insurance giant Nationwise is using
 Novell SLES and Xen in production IBM zSeries mainframes to
 improve their system utilization and save money.

 When needs VM?

 I like the spelling of Nationwise.

I have pretty much given up on this reporter getting things
right.

JIM