Re: PSP bucket site
Sent this to the wrong listserv to start with...lol Meant to send to IBM-MAIN. I had mail turned off on VM listserv. Wondered why no one responded! I did have the slash instead of the period after techsupport. It's working now. Thanks!
Re: hate to harp on SET SHARE but...
In original post, the figures reported on ESALNXP for CPU percent showed 95.3 percent for wvlnx2 at 8:39 this morning... Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 8/8/2007 10:19 AM >>> You have many users on your system. Why do you think WVLNX2 is getting more than 50% of one IFL? Maybe it is getting 50% and WVLNX4 is also getting 50% that would cause the HMC System Activity display to show about 100%. Maybe WVLNX4, WVLNX5, WVLNX6, and WVLNX8 are all getting about 25% each and WVLNX2 is getting about 1%. Lots of other possibilities. What evidence do you have that it is WVLNX2 that is the problem? [EMAIL PROTECTED] wrote: > On the HMC, we have a System Activity display that shows our 2 CPs and > the 1 SP. Normally the IFL is really low, but occassionally, like right > now, it shows around 100% usage. > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-1494 > Fax 304-558-1441 > [EMAIL PROTECTED] 8/8/2007 9:53 AM >>> > What make you think that WVLNX2 is getting more than 50% of your one > IFL? > -- 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
Re: hate to harp on SET SHARE but...
On the HMC, we have a System Activity display that shows our 2 CPs and the 1 SP. Normally the IFL is really low, but occassionally, like right now, it shows around 100% usage. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 8/8/2007 9:53 AM >>> What make you think that WVLNX2 is getting more than 50% of your one IFL? [EMAIL PROTECTED] wrote: > On ESAUSRC screen of ESAMON, it shows this: > > <-SHARE---> > > Account ACI Grp <-Maximum> # of VM > Stor > UserID ClassID Code NameRel Abs Type Share Limit CPUs > Mode Mode > -- --- - - > > VMSERVU *Linuxen 1 1500 . Rel 0.0 Soft1 > XC V=V > WVLNX2 *Linuxen WVLNX2 100 . Abs 50.0 Hard1 > ESA V=V > WVLNX4 *Linuxen WVLNX4 100 . Rel 0.0 Soft1 > ESA V=V > WVLNX5 *Linuxen WVLNX5 100 . Rel 0.0 Soft1 > ESA V=V > WVLNX6 *Linuxen WVLNX6 100 . Rel 0.0 Soft1 > ESA V=V > WVLNX8 *Linuxen WVLNX8 100 . Rel 0.0 Soft1 > ESA V=V > - > > ESALNXP screen shows this: > > Screen: ESALNXP State of West Virginia ESAMON 3.7.0 08/08 > 08:26-08:41 > 1 of 3 LINUX VSI Process Statistics Report NODE * LIMIT 500 > 2086 3E1FE > > > <-Process Ident-> <-CPU Percents-> > nice > Time Node Name IDPPID GRP Tot sys user syst usrt > valu > - - - - > > 08:39:00 wvlnx2 oracle19524 1 19524 0.4 0.4 0.1 0.0 0.0 > 0 > oracle19520 1 19520 0.4 0.3 0.1 0.0 0.0 > 0 > oracle19518 1 19518 0.2 0.1 0.0 0.0 0.0 > 0 > oracle19501 1 19501 20.2 15.9 4.3 0.0 0.0 > 0 > oracle19499 1 19499 20.7 17.1 3.6 0.0 0.0 > 0 > oracle19485 1 19485 27.1 21.6 5.5 0.0 0.0 > 0 > oracle19478 1 19478 1.8 1.4 0.5 0.0 0.0 > 0 > oracle19367 1 19367 6.1 4.5 1.7 0.0 0.0 > 0 > oracle19336 1 19336 1.1 0.8 0.3 0.0 0.0 > 0 > snmpd 5460 1 5459 0.5 0.2 0.3 0.0 0.0 > 10 > cron570 1 570 0.3 0.0 0.0 0.3 0.0 > 0 > tnslsnr 505 1 505 1.0 0.6 0.0 0.3 0.0 > 0 > *Totals* 0 0 0 95.3 74.4 20.2 0.6 0.0 > 0 > > My understanding is that the LIMITHARD should prevent it from taking > more than 50% of my one IFL. (We only have 1!) Did I misunderstand? > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-1494 > Fax 304-558-1441 -- 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
hate to harp on SET SHARE but...
On ESAUSRC screen of ESAMON, it shows this:
<-SHARE--->
Account ACI Grp <-Maximum> # of VM
Stor
UserID ClassID Code NameRel Abs Type Share Limit CPUs
Mode Mode
-- --- - -
VMSERVU *Linuxen 1 1500 . Rel 0.0 Soft1
XC V=V
WVLNX2 *Linuxen WVLNX2 100 . Abs 50.0 Hard1
ESA V=V
WVLNX4 *Linuxen WVLNX4 100 . Rel 0.0 Soft1
ESA V=V
WVLNX5 *Linuxen WVLNX5 100 . Rel 0.0 Soft1
ESA V=V
WVLNX6 *Linuxen WVLNX6 100 . Rel 0.0 Soft1
ESA V=V
WVLNX8 *Linuxen WVLNX8 100 . Rel 0.0 Soft1
ESA V=V
-
ESALNXP screen shows this:
Screen: ESALNXP State of West Virginia ESAMON 3.7.0 08/08
08:26-08:41
1 of 3 LINUX VSI Process Statistics Report NODE * LIMIT 500
2086 3E1FE
<-Process Ident-> <-CPU Percents->
nice
Time Node Name IDPPID GRP Tot sys user syst usrt
valu
- - - -
08:39:00 wvlnx2 oracle19524 1 19524 0.4 0.4 0.1 0.0 0.0
0
oracle19520 1 19520 0.4 0.3 0.1 0.0 0.0
0
oracle19518 1 19518 0.2 0.1 0.0 0.0 0.0
0
oracle19501 1 19501 20.2 15.9 4.3 0.0 0.0
0
oracle19499 1 19499 20.7 17.1 3.6 0.0 0.0
0
oracle19485 1 19485 27.1 21.6 5.5 0.0 0.0
0
oracle19478 1 19478 1.8 1.4 0.5 0.0 0.0
0
oracle19367 1 19367 6.1 4.5 1.7 0.0 0.0
0
oracle19336 1 19336 1.1 0.8 0.3 0.0 0.0
0
snmpd 5460 1 5459 0.5 0.2 0.3 0.0 0.0
10
cron570 1 570 0.3 0.0 0.0 0.3 0.0
0
tnslsnr 505 1 505 1.0 0.6 0.0 0.3 0.0
0
*Totals* 0 0 0 95.3 74.4 20.2 0.6 0.0
0
My understanding is that the LIMITHARD should prevent it from taking
more than 50% of my one IFL. (We only have 1!) Did I misunderstand?
Anne D. Crabtree
System Programmer
WV Dept of Administration - OT
304-558-1494
Fax 304-558-1441
Re: SET SHARE RELATIVE
I think I'll try this and see how it goes... thanks ! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 8/2/2007 9:12 AM >>> I use a combination of relative and absolute for some of my servers such as this: SET SHARE LNXWEB RELATIVE 100 ABSOLUTE 50% LIMITHARD This should let LNXWEB use the processor at the same relative share as th e other servers, but not let it use more than 50% of the processor. /Tom Kern /301-903-2211 On Thu, 2 Aug 2007 08:56:16 -0400, Anne Crabtree <[EMAIL PROTECTED]> wrote: >We have five linux instances running, two of which aren't really being >used, two are production and one is test. In the test linux instance, >they are running a web app (which I know nothing about). At certain >times during the day, this test instance will take close to 100% of the >IFL. We want to back it off so that it can take no more than 50% to see >how that affects them. Would it be logical to issue SET SHARE linux >RELATIVE 50 since it is defaulting to REL 100? Will that do what I >think and limit it to half of what the other virtual machines "get"? > >Anne D. Crabtree >System Programmer >WV Dept of Administration - OT >304-558-1494 >Fax 304-558-1441 > =
SET SHARE RELATIVE
We have five linux instances running, two of which aren't really being used, two are production and one is test. In the test linux instance, they are running a web app (which I know nothing about). At certain times during the day, this test instance will take close to 100% of the IFL. We want to back it off so that it can take no more than 50% to see how that affects them. Would it be logical to issue SET SHARE linux RELATIVE 50 since it is defaulting to REL 100? Will that do what I think and limit it to half of what the other virtual machines "get"? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441
Re: TCPIP under z/VM problem
I would think you want to look at the last reader file for TCPMAINT. It might show why TCPIP was lost... sign on as TCPMAINT rl Peek at TCPIP from last time it went down Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 8/1/2007 11:32 AM >>> I did a Q PRINT and there is a file called TCPIP. I have done a quick review of CMS Primer and CMS User Guide. We do not have a printer. How do I look at the file ? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Wednesday, August 01, 2007 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCPIP under z/VM problem This is not normal. Pls check the console log of TCPIP or TCPMAINT. Terminating the connection could be related to a bunch of things, some debugging is required. David -Original Message- From: The IBM z/VM Operating System on behalf of Daniel Allen Sent: Wed 8/1/2007 11:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] TCPIP under z/VM problem Recently our z/VM 5.2 system is losing connectivity to TCPIP. I force TCPIP and xautolog TCPIP. Everything is fine again. This has happened twice within two days. The z/OS system running under z/VM was okay. Has anyone seen this behavior ? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: z/vm 5.1 to 5.3 question
yup, when I released it, it said "update inhibited" or something similar. guess i worried for no reason. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 2:03 PM >>> > OK, I did that but it was scary...lol On query, 1913 > showed as R/W. How can I force it R/O? Ann, If the original LINK at the first level was R/O, then you only have a R/O dasd. I don't remember why the 2nd level system tells you it is R/W, but it is not. I believe you can prove this to yourself by attaching the disk to a user (such as ESAMON), doing an ACC for 1913 (ACC 1913 E), then release E (REL E). VM should complain that it can't write to the disk (it is trying to update the file status table since it thought it was a R/W disk.) Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . 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: z/vm 5.1 to 5.3 question
sweet! thanks for your help ;) Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 1:56 PM >>> Hi Anne, 2nd level CP thinks it is R/W because it looks like a "real" DASD device to it, but you linked it R/O so don't worry about it. If you attempt to write to it you'll get an INPUT INHIBITED condition IIRC. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Thursday, July 26, 2007 1:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm 5.1 to 5.3 question OK, I did that but it was scary...lol On query, 1913 showed as R/W. How can I force it R/O? I have to do a whole bunch more of this schtuff... and I'd prefer not to accidentally write over first level! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 1:34 PM >>> Hi Anne, You are worrying too much about this. IPL your second level system. Execute "CP QUERY 1913". See it? It appears as a REAL DASD device (it's really a link to a VM minidisk). You can "use" that DASD device like any other device. So log on to your ESAMON userid second level, ATTACH 1913 to ESAMON. On ESAMON ACCESS 1913 X and voila, you have the "minidisk" accessed and can copy it's contents. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Thursday, July 26, 2007 1:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm 5.1 to 5.3 question I have a feeling I'm going about this the wrong way! If I attach 1913 on second level, how do I access it, with a file mode? Can I even do what I'm trying to do? I'm also wondering if the fact that disk on first level and second level are labelled the same (MON191) will cause a problem? What I want is to see is Q DISK: LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MON191 191 A R/W20 3390 40960 7-00 3593 3600 MON191 1913 X R/O20 3390 4096 52 1769-49 1831 3600 and be able to copy * * A = = X Can I do this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 12:36 PM >>> > LINK ESAMON 191 1913 RR > > When I sign on to VMTEST53 prior to ipl and > do 'Q V ALL', I can see 1913, but when I ipl, > I can't access 1913...it doesn't exist. I know > that I am missing part of the puzzle. I want to > copy the contents of ESAMON 191 from first to > second level. Do I need a minidisk in VMTEST53 > for 510RES (where ESAMON 191 disk is)? Ann, Are you attaching the minidisk to the second level SYSTEM? Just a link is not enough. For example, from the second level system OPERATOR: ATT 1913 SYSTEM Then a Q DASD on the second level system should show you this disk. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . 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: z/vm 5.1 to 5.3 question
OK, I did that but it was scary...lol On query, 1913 showed as R/W. How can I force it R/O? I have to do a whole bunch more of this schtuff... and I'd prefer not to accidentally write over first level! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 1:34 PM >>> Hi Anne, You are worrying too much about this. IPL your second level system. Execute "CP QUERY 1913". See it? It appears as a REAL DASD device (it's really a link to a VM minidisk). You can "use" that DASD device like any other device. So log on to your ESAMON userid second level, ATTACH 1913 to ESAMON. On ESAMON ACCESS 1913 X and voila, you have the "minidisk" accessed and can copy it's contents. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Thursday, July 26, 2007 1:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/vm 5.1 to 5.3 question I have a feeling I'm going about this the wrong way! If I attach 1913 on second level, how do I access it, with a file mode? Can I even do what I'm trying to do? I'm also wondering if the fact that disk on first level and second level are labelled the same (MON191) will cause a problem? What I want is to see is Q DISK: LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MON191 191 A R/W20 3390 40960 7-00 3593 3600 MON191 1913 X R/O20 3390 4096 52 1769-49 1831 3600 and be able to copy * * A = = X Can I do this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 12:36 PM >>> > LINK ESAMON 191 1913 RR > > When I sign on to VMTEST53 prior to ipl and > do 'Q V ALL', I can see 1913, but when I ipl, > I can't access 1913...it doesn't exist. I know > that I am missing part of the puzzle. I want to > copy the contents of ESAMON 191 from first to > second level. Do I need a minidisk in VMTEST53 > for 510RES (where ESAMON 191 disk is)? Ann, Are you attaching the minidisk to the second level SYSTEM? Just a link is not enough. For example, from the second level system OPERATOR: ATT 1913 SYSTEM Then a Q DASD on the second level system should show you this disk. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . 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: z/vm 5.1 to 5.3 question
I have a feeling I'm going about this the wrong way! If I attach 1913 on second level, how do I access it, with a file mode? Can I even do what I'm trying to do? I'm also wondering if the fact that disk on first level and second level are labelled the same (MON191) will cause a problem? What I want is to see is Q DISK: LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MON191 191 A R/W20 3390 40960 7-00 3593 3600 MON191 1913 X R/O20 3390 4096 52 1769-49 1831 3600 and be able to copy * * A = = X Can I do this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441 >>> [EMAIL PROTECTED] 7/26/2007 12:36 PM >>> > LINK ESAMON 191 1913 RR > > When I sign on to VMTEST53 prior to ipl and > do 'Q V ALL', I can see 1913, but when I ipl, > I can't access 1913...it doesn't exist. I know > that I am missing part of the puzzle. I want to > copy the contents of ESAMON 191 from first to > second level. Do I need a minidisk in VMTEST53 > for 510RES (where ESAMON 191 disk is)? Ann, Are you attaching the minidisk to the second level SYSTEM? Just a link is not enough. For example, from the second level system OPERATOR: ATT 1913 SYSTEM Then a Q DASD on the second level system should show you this disk. Ed Zell Illinois Mutual Life (309) 674-8255 x-107 . 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.
z/vm 5.1 to 5.3 question
I have successfully installed, ipl'd, etc z/vm 5.3 second level on a z/vm 5.1 system... Am now trying to customize the USER DIRECT to match current. (for instance, velocity software users!) I do not have tape drives at my disposal during the week. I put links in the USER DIRECT for VMTEST53 on first level, for instance: LINK ESAMON 191 1913 RR When I sign on to VMTEST53 prior to ipl and do 'Q V ALL', I can see 1913, but when I ipl, I can't access 1913...it doesn't exist. I know that I am missing part of the puzzle. I want to copy the contents of ESAMON 191 from first to second level. Do I need a minidisk in VMTEST53 for 510RES (where ESAMON 191 disk is)? I was nervouse to refer to 510RES at all even though it would be RR... Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-1494 Fax 304-558-1441
Re: HELP on z/vm 5.3 install!
Well, it just so happenend, not sure how, that my VM session went from "running" to "vm read" and then the ftp server timed out. I don't know if I hit enter or what? Anyway, I just logged off. Will check the ftp server software for transmission speed or whatever... it was freeware I downloaded... may hav to try a different one. No big deal I guess. I can always start over.. :) Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 07/24/07 4:55 PM >>> On Tuesday, 07/24/2007 at 04:07 EDT, Ray Mansell <[EMAIL PROTECTED]> wrote: > Hmmm... I can't help, though I suspect a simple HX would do the trick. > However, you might want to do some investigation, since I also did an > FTP install last week, and it took less than an hour. > > Or, just leave it running overnight. Is there any reason you can't do that? I think you were right to suggest something is wrong. No way it should take that long. Oversimplifying, at 10 disks every 3 hours it would take 84 hours to download 280 disks. Alan Altmark z/VM Development IBM Endicott
HELP on z/vm 5.3 install!
I am installing z/vm 5.3 from an ftp server... Was really proud of myself until I realized after starting the instdvd and 1 1/2 hours have gone by and I am on disk 5 of 280 that it might not have been prudent to start it this late in the day! Is there a graceful way to interrupt the install so that I'm not here all night? I see instructions about restarting instdvd with restart option which I'm perfectly willing to do... in the morning.. Any suggestions? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: DASD second level
how about i just say END! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/25/2007 1:04 PM >>> Yes, to 3338 is 3339 but MDISK 3338 is for 3338. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Macioce, Larry Sent: Monday, June 25, 2007 12:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD second level I'm coming in a bit late but from what I see, if you go from to 3338 that IS 3339 cyls. Did I miss something? mace -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Monday, June 25, 2007 11:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD second level Unless the Linux admin takes specific action to label the disk with the current label, it will be overwritten with the Linux volume name, and will then not be available the next time the userid is logged out and back in. Two courses of action: Either change the minidisk to exclude cylinder zero, making it begin on 001 and run for 3338, or have the Linux admin use the current label when he formats the disk (I don't remember seeing this as an option in the install process, but I wasn't looking for it, either), or let him format the disk, then discover the new label, and change all your references to match it. Note that it may not be unique if you have several Linux guests using the same virtual disk addresses. But at least you're in control of what addresses you present to the Linux guest... Option one is the simplest and most reliable, if you intend to run Linux as a guest only, and never try to boot it in a bare LPAR. You lose a cylinder per disk, but you keep control over the volumes. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 6/25/07 9:35 AM, "Anne Crabtree" <[EMAIL PROTECTED]> wrote: > Yes, I guess that should be 3339. I have 3338 all over the place.. even > on first level. I changed the MDISK statements for the LX packs to be > 000 3339. Linux person hasn't really tried to use them yet so I don't > know if the 000 will be a problem or not. It seems to know that it is > labelled LX163C,etc. I formatted it on z/os and I don't know if he does > something to format it for linux or not. Guess I'll find out..lol > > We are only doing the third level to make sure that the VM maintenance > I put on second level is ok for linux. It really won't be used as > production type system. It's just to play with. > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: DASD second level
omg i should just go home... it's a wonder i'm getting anything accomplished today... Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/25/2007 12:49 PM >>> I'm coming in a bit late but from what I see, if you go from to 3338 that IS 3339 cyls. Did I miss something? mace -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Monday, June 25, 2007 11:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DASD second level Unless the Linux admin takes specific action to label the disk with the current label, it will be overwritten with the Linux volume name, and will then not be available the next time the userid is logged out and back in. Two courses of action: Either change the minidisk to exclude cylinder zero, making it begin on 001 and run for 3338, or have the Linux admin use the current label when he formats the disk (I don't remember seeing this as an option in the install process, but I wasn't looking for it, either), or let him format the disk, then discover the new label, and change all your references to match it. Note that it may not be unique if you have several Linux guests using the same virtual disk addresses. But at least you're in control of what addresses you present to the Linux guest... Option one is the simplest and most reliable, if you intend to run Linux as a guest only, and never try to boot it in a bare LPAR. You lose a cylinder per disk, but you keep control over the volumes. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 6/25/07 9:35 AM, "Anne Crabtree" <[EMAIL PROTECTED]> wrote: > Yes, I guess that should be 3339. I have 3338 all over the place.. even > on first level. I changed the MDISK statements for the LX packs to be > 000 3339. Linux person hasn't really tried to use them yet so I don't > know if the 000 will be a problem or not. It seems to know that it is > labelled LX163C,etc. I formatted it on z/os and I don't know if he does > something to format it for linux or not. Guess I'll find out..lol > > We are only doing the third level to make sure that the VM maintenance > I put on second level is ok for linux. It really won't be used as > production type system. It's just to play with. > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: DASD second level
Yes, I guess that should be 3339. I have 3338 all over the place.. even on first level. I changed the MDISK statements for the LX packs to be 000 3339. Linux person hasn't really tried to use them yet so I don't know if the 000 will be a problem or not. It seems to know that it is labelled LX163C,etc. I formatted it on z/os and I don't know if he does something to format it for linux or not. Guess I'll find out..lol We are only doing the third level to make sure that the VM maintenance I put on second level is ok for linux. It really won't be used as production type system. It's just to play with. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 6:29 PM >>> Hello Anne, Just some things that popped into my mind. >VMTEST 191 and looks like this: >USER WVLNX30 WVLNX30 512M 1024M G ..snip.. >DEDICATE 0A81 163C >DEDICATE 067E 165F > >VMTEST's USER DIRECT on first level: ..snip.. > MDISK 163C 3390 000 10017 LX163C MR > MDISK 165F 3390 000 3338 LX165F MR The guest VM has a minidisk of 3338 cylinders. Shouldn't that be 3339 cylinders? A 3390-3 has 3339 cylinders. I would guess to have either 001 3338 as a minidisk or 000 3339 for a full pack disk. Secondly, in this case you dedicate the 165F to the linux machine, so fro m cylinder 0 through 3338. Wouldn't that overwrite cylinder 0, thus replaci ng the CP volume information with whatever linux would like to see? Our zLin ux guests format the volume with a label something like 0x0200. Should that label be placed on cylinder 0 the hosting VM (either host or second level VM) we wouldn't be able to find LX165F afterwards. And the last point, perhaps not applicable, beware of running 3rd-level guests. They don't perform as well as second level guests. The CPU overhe ad in 3rd level is very large due to the fact that SIE assist doesn't work a t that level. (Assuming you run in LPAR mode, which is the only way on z-series today) We had an issue when we ran VSE guests on a guest VM. It turned out the VSE had on overhead ratio 1:2 or worse because all CPU had to be emulated by the host. The VSE couldn't use SIE assist in this configuration. SIE assist works only two levels deep, LPAR mode being one of them. Regards, Berry.
Re: DASD second level
What I have done is after IPLing second level, I issued 'ATT 163C to VMTEST' and that seemed to work and now on second level OPERATOR, it shows: 11:01:27 Q 163C 11:01:27 DASD 163C ATTACHED TO WVLNX30 0A81 R/W LX163C So, I think that's what I want, but I don't think I have definitions quite right. Seems like I shouldn't have to do that everytime I ipl. Anyway, it got me where I needed to be for now. THANKS Everyone for the help! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 10:50 AM >>> In the second level system, do a "Q DASD ALL" and look at the results; Do you see your disks there, and what is their state? In the first level system, do a "Q DASD label" for the two disks in question, and see what their state is there. There has to be a reason that the disk isn't finding its way into the second level system as a usable device Just need to figure out what that is. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 6/22/07 9:15 AM, "Anne Crabtree" <[EMAIL PROTECTED]> wrote: > In VMTEST, I was only using DEDICATE for hipersocket devices??? not for > any volumes.. > The MDISK was the only way I could think to make VMTEST see that dasd. > I don't understand why the User_Volume_Include * doesn't allow me to see > all dasd. > > After I IPL VMTEST, I did 'ATT 163C TO VMTEST' from MAINT 1st level and > that seemed to work. At least it exists on 2ndlevel anyway. > > Thanks for the info...I'm hoping to learn a lot at SHARE! >>> >>> User_Volume_Include * >>> >>> in your SYSTEM CONFIG of your 2nd level system, then all the > available >> >>> volumes will be attached to system at IPL time. >>> >>> Ronald van der Laan >>> >> >> >
Re: DASD second level
In VMTEST, I was only using DEDICATE for hipersocket devices??? not for any volumes.. The MDISK was the only way I could think to make VMTEST see that dasd. I don't understand why the User_Volume_Include * doesn't allow me to see all dasd. After I IPL VMTEST, I did 'ATT 163C TO VMTEST' from MAINT 1st level and that seemed to work. At least it exists on 2ndlevel anyway. Thanks for the info...I'm hoping to learn a lot at SHARE! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 9:25 AM >>> I see a mix in the directory entry for VMTEST: - you seem to use DEDICATE to pass the VM volumes to VMTEST - but use MDISK to pass the Linux volumes You could use DEDUCATE for all of them A lesson about devices (something I explained several times when teaching. At the time there was not a single exception, now there are some)). The rule: A device can be given to 1 "person" only at a time. "person" can be CP itself or a virtual machine, never both. - When you give the device to CP itself, it can maybe be shared, depending on the device type - for a disk, it can then host minidisks. Command: ATTACH xx SYSTEM, or via SYSTEM CONFIG (CPOWNED or USER_VOLUME_INCLUDE) - for a 3270 terminal: you can then logon/loggoff. Command: ENABLE rdev - ... - To give a device to a virtual machine: ATTACH or DEDICATE is used. 2007/6/22, Stracka, James (GTI) <[EMAIL PROTECTED]>: > > Or LINK fullpack ucb ucb M (MW or RR) on in the PROFILE EXEC of VMTEST > if you have a fullpack minidisk holder id. > > We LINK RR for 1st level volumes that VMTEST is to have READ only. > VMTEST volumes all start VM2 (for VM 2nd Level) and LINK them MW. > > Each to his own. > > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Munson > Sent: Friday, June 22, 2007 9:03 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: DASD second level > > > Anne, > > You need to detach the volumes from SYSTEM on the 1st level VM That way > they can be attached to VMTEST to be used 2nd level. > > good luck > > Bill Munson > IT Specialist > VM System Programmer > Office of Information Technology > State of New Jersey > (609) 984-4065 > > President MVMUA > http://www.marist.edu/~mvmua > > > > Anne Crabtree wrote: > > tried that... > > seems no matter what i do, second level just says they don't exist! > > > > Anne D. Crabtree > > System Programmer > > WV Dept of Administration - OT > > 304-558-5914 ext 8885 > > Fax 304-558-1351 > > > >>>> [EMAIL PROTECTED] 6/22/2007 8:58 AM >>> > > Anne, > > > > If you put: > > > > User_Volume_Include * > > > > in your SYSTEM CONFIG of your 2nd level system, then all the available > > > volumes will be attached to system at IPL time. > > > > Ronald van der Laan > > > > -- Kris Buelens, IBM Belgium, VM customer support
Re: DASD second level
det 163c from system HCPDTS121E DASD 163C not attached to system Ready(00121); T=0.01/0.01 09:10:47 det 163c from all HCPDTG1119E Device 163C was not detached. Detach with the ALL option is not val id for devices attached to SYSTEM. Ready(01119); T=0.01/0.01 09:10:57 I just LOVE this. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 9:03 AM >>> Anne, You need to detach the volumes from SYSTEM on the 1st level VM That way they can be attached to VMTEST to be used 2nd level. good luck Bill Munson IT Specialist VM System Programmer Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Anne Crabtree wrote: > tried that... > seems no matter what i do, second level just says they don't exist! > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > >>>> [EMAIL PROTECTED] 6/22/2007 8:58 AM >>> > Anne, > > If you put: > > User_Volume_Include * > > in your SYSTEM CONFIG of your 2nd level system, then all the available > volumes will be attached to system at IPL time. > > Ronald van der Laan >
Re: DASD second level
I didn't quite state that right. I'm signed onto VMTEST on first level when I did the queries. Linux directory entry is in USER DIRECT on VMTEST 191 and looks like this: USER WVLNX30 WVLNX30 512M 1024M G IPL CMS PARM AUTOCR IUCV ANY IUCV ALLOW MACHINE ESA SPECIAL 3000 HIPERS 3 CONSOLE 009 3215 T SPOOL 00C 2540 READER * SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK MAINT 190 190 RR LINK MAINT 19E 19E RR LINK MAINT 19F 19F RR LINK MAINT 19D 19D RR LINK TCPMAINT 198 198 RR LINK TCPMAINT 592 592 RR MDISK 191 3390 7981 050 510RST MR READWRITEMULTIPLE DEDICATE 0A81 163C DEDICATE 067E 165F VMTEST's USER DIRECT on first level: USER VMTEST VMTEST 64M 128M BG MACHINE ESA 2 OPTION TODENABLE ACCOUNT 1 VMTEST IPL CMS *HIPERSOCKETS DEDICATE 3000 920 DEDICATE 3001 921 DEDICATE 3002 922 DEDICATE 3004 980 DEDICATE 3005 981 DEDICATE 3006 982 * CTC TO 2ND LEVEL SPECIAL 2000 CTCA TCPIP SPECIAL 2001 CTCA TCPIP SPECIAL 400 3270 SPECIAL 401 3270 SPECIAL 402 3270 SPECIAL 403 3270 SPECIAL 404 3270 SPECIAL 405 3270 CONSOLE 009 3215 T SPOOL 00C 2540 READER * SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 191 3390 217 0070 510W01 MR MDISK 163C 3390 000 10017 LX163C MR MDISK 165F 3390 000 3338 LX165F MR . . . Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 8:44 AM >>> Based on the messages "not linked" it would seem you are not using DEDICATE statements in the Linux directory entries, but LINK statements. You would either need to change those statements, or attach those volumes to SYSTEM so that the link statements can work. David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Friday, June 22, 2007 8:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DASD second level I have a directory entry VMTEST for a second level VM. (z/vm v5r1) I am trying to put a Linux guest on second level. I have DEDICATE statements for the dasd it needs but second level does not "see" this dasd: HCPLNM108E VMTEST 163C not linked; volid LX163C not mounted HCPLNM108E VMTEST 165F not linked; volid LX165F not mounted I've tried putting a MDISK statement for these in VMTEST directory entry and I've tried adding them to the User_Volume_List on second level. Neither has seemed to resolve the problem. On second level, if I 'q dasd' I don't see these volumes. However, if I do 'q 163c' I get this: q 163c Ready; T=0.01/0.01 08:34:02 DASD 163C LX163C So, my question is: What is the correct way to "define" dasd so that second level VM can see it and Linux can "own" it? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: DASD second level
tried that... seems no matter what i do, second level just says they don't exist! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 6/22/2007 8:58 AM >>> Anne, If you put: User_Volume_Include * in your SYSTEM CONFIG of your 2nd level system, then all the available volumes will be attached to system at IPL time. Ronald van der Laan
DASD second level
I have a directory entry VMTEST for a second level VM. (z/vm v5r1) I am trying to put a Linux guest on second level. I have DEDICATE statements for the dasd it needs but second level does not "see" this dasd: HCPLNM108E VMTEST 163C not linked; volid LX163C not mounted HCPLNM108E VMTEST 165F not linked; volid LX165F not mounted I've tried putting a MDISK statement for these in VMTEST directory entry and I've tried adding them to the User_Volume_List on second level. Neither has seemed to resolve the problem. On second level, if I 'q dasd' I don't see these volumes. However, if I do 'q 163c' I get this: q 163c Ready; T=0.01/0.01 08:34:02 DASD 163C LX163C So, my question is: What is the correct way to "define" dasd so that second level VM can see it and Linux can "own" it? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: CTC again
OK, I apologize for being so dumb about this but it's really confusing! I am trying to set up a connection from 2nd level VM to first level VM and was using the virtual CTC to do so. The reason I am doing this is so that I can try to start TCPIP on 2nd level which I have not done yet. Once TCPIP on 2nd level is running, I wanted to start a Linux guest. On 2nd level TCPIP, I was going to define another vctc to connect to the linux on second level. All this is to verify that maintenance I put on 2nd Level VM will not affect Linux before moving that maintenance to first level where there are productional linuxes running... So now, I'm not exactly sure where I am in that process even after all this advice. I detached the vctc from an linux guest on first level that is not being used. I think it has been defined on 1st level to my second level VM (VMTEST). I just IPL'd VMTEST and issued the CP SEND CP VMTEST DEF CTCA 2030 (and same for 2031) If I query 2030 it says: CTCA 2030 FREE TCPIP is not running on 2nd level. I've never even tried to start it because I'm still trying to get verification from someone who knows TCP/IP (although he doesn't know VM) that I coded the IP addresses for 2nd level correctly. When you said : CP SEND CP VMTEST COUPLE 2030 guest2 vaddr2 I have no idea what to put for guest2 or even if I need it! And I can't attach to TCPIP there since it's not even running yet. I'm assuming what I've done so far means 2nd level is attached to 1st level though that virtual ctc but I wouldn't swear on it. I'm sure you can see my confusion. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 5/23/2007 8:07 AM >>> So, this was a virtual CTC, not a real one. As said in my other extra info post: you will need to handle virtual things, so use CP SEND CP SEND CP VMTEST DEF CTCA 2030 CP SEND CP VMTEST DEF CTCA 2031 You also need a COUPLE command to virtually wire this virtual CTC to a virtual CTC in the other guest. Something like: CP SEND CP VMTEST COUPLE 2030 guest2 vaddr2 As I didn't follow this whole thread, I can't fill in the variables above. Then to CP in your VMTEST machine, this virtual CTC looks like a real one, so you ATTACH it to TCPIP there. What means LOGON MAINT in VMTEST and ATTACH 2030 TCPIP vaddr 2007/5/23, Anne Crabtree <[EMAIL PROTECTED]>: > > Tried that and it says: > HCPATR040E Device 2030 does not exist > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > >
Re: CTC again
It's virtual and that worked. THANK YOU! I was unsure as to how to do the DEFINE. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 5/23/2007 8:04 AM >>> Are you dealing with a VIRTUAL CTC, or a real device? If virtual, then your SEND CP TCPIP DET 2030 took it completely out of existence. You'd need to redefine it and couple it to the other virtual machine: SEND CP TCPIP DEFINE CTC 2030 USER VMTEST Then: SEND CP TCPIP COUPLE 2030 TO VMTEST 2000 If this was a real CTC, any you're trying to remove it from TCPIP and attach it to VMTEST, to connect to some other physical machine, then you'd do the attach from MAINT, as TCPIP may not have the necessary privs. -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." On 5/23/07 6:58 AM, "Anne Crabtree" <[EMAIL PROTECTED]> wrote: > Tried that and it says: > HCPATR040E Device 2030 does not exist > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > >>>> [EMAIL PROTECTED] 5/23/2007 7:56 AM >>> > You use the CP SEND CP TCPIP to execute something in the TCPIP machine. > To > attach the CTC to another guest, no need to do it in the TCPIP user. > Simply > use MAINT > > CP ATT 2030 TO VMTEST AS 2000
Re: CTC again
Tried that and it says: HCPATR040E Device 2030 does not exist Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 5/23/2007 7:56 AM >>> You use the CP SEND CP TCPIP to execute something in the TCPIP machine. To attach the CTC to another guest, no need to do it in the TCPIP user. Simply use MAINT CP ATT 2030 TO VMTEST AS 2000 -- Kris Buelens, IBM Belgium, VM customer support P.S. even the DETACH of the CTC from TCPIP could have been done by a simple DETACH in MAINT: CP DET 2030-2031 TCPIP 2007/5/23, Anne Crabtree <[EMAIL PROTECTED]>: > > OK, I'm stuck. Detached an existing CTC from TCPIP but can't see to get > it reattached/redefined... It was defined as a CTC for a linux guest > and now I'm trying to connect it to a second level VM. I did this as > suggested yesterday: > > SET SECUSER TCPIP MAINT > SEND CP TCPIP DET 2030 > SEND CP TCPIP DET 2031 > > Thought I could do this: > SEND CP TCPIP ATT 2030 TO VMTEST AS 2000 > but obviously, that isn't right. So, how do I get 2030 reattached to > TCPIP for VMTEST??? > > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 >
CTC again
OK, I'm stuck. Detached an existing CTC from TCPIP but can't see to get it reattached/redefined... It was defined as a CTC for a linux guest and now I'm trying to connect it to a second level VM. I did this as suggested yesterday: SET SECUSER TCPIP MAINT SEND CP TCPIP DET 2030 SEND CP TCPIP DET 2031 Thought I could do this: SEND CP TCPIP ATT 2030 TO VMTEST AS 2000 but obviously, that isn't right. So, how do I get 2030 reattached to TCPIP for VMTEST??? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: CTC change
Do I have to logon TCPIP to detach it or can I do it from, say, MAINT? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 5/21/2007 3:26 PM >>> On Monday, 05/21/2007 at 10:04 AST, Anne Crabtree <[EMAIL PROTECTED]> wrote: > What about the SPECIAL statement in USER TCPIP? If I change it from > WVLNX5 to VMTEST, will it "know" about it without recycling TCPIP or > doing OBEY or something? No. In fact, you will need to logoff/logon or DETACH the vctc and DEFINE it anew. Changing the configuration in the directory never changes the active configuration. Alan Altmark z/VM Development IBM Endicott
Re: CTC change
What about the SPECIAL statement in USER TCPIP? If I change it from WVLNX5 to VMTEST, will it "know" about it without recycling TCPIP or doing OBEY or something? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 5/21/2007 9:31 AM >>> That will work. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Monday, May 21, 2007 9:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: CTC change I have a CTC defined to TCPIP for a linux guest we are not using. If I want to change that CTC to be used by my second level VM, can I just make the change in the USER DIRECT (comment out SPECIAL stmt in linux guest and add the SPECIAL statement to my 2nd level VM guest) and then install the USER DIRECT...? I don't want to mess up anything on first level that is running. I am trying to run a second level VM and, eventually,want to start TCPIP and a linux guest on 2nd level so I am trying to duplicate first level as much as possible. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
CTC change
I have a CTC defined to TCPIP for a linux guest we are not using. If I want to change that CTC to be used by my second level VM, can I just make the change in the USER DIRECT (comment out SPECIAL stmt in linux guest and add the SPECIAL statement to my 2nd level VM guest) and then install the USER DIRECT...? I don't want to mess up anything on first level that is running. I am trying to run a second level VM and, eventually,want to start TCPIP and a linux guest on 2nd level so I am trying to duplicate first level as much as possible. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: service on tcpip?
I am not using SERVICE and PUT2PROD, I am doing it the long way. This is so I can learn what the heck service actually does. In the Service Guide, it does not address TCPIP.. So you are saying you basically do the same steps as any other component and the order in which you service TCPIP is not important? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 4/30/2007 9:28 AM >>> I'd say that SERVICE would do what is required. The service manual should document the RSU install steps. Diehards like me: 1. map the RSU (tape or enveloppe file) so you know which products have service. VMFINS INSTALL INFO <(ENV fn> 2. VMFSETUP 5VMCTP10 TCPIP <(LINK> (LINK if from MAINT for example) 3. VMFPSU 5VMTCP10 TCPIP (to compare your fixes with the RSU) 4. VMFMRDSK 5VMTCP10 TCPIP APPLY(create a fallback level) 5. VMFINS INSTALL PPF 5VMTCP10 TCPIP (NOMEMO OVERRIDE NO Required if you'd have service not on the RSU (else it will not harm): 6. VMFAPPLY PPF 5VMTCP10 TCPIP 7. VMFBLD PPF 5VMTCP10 TCPIP (serviced 2007/4/30, Anne Crabtree <[EMAIL PROTECTED]>: > > RSU5105 indicates TCP/IP at service level 0502, which is my current > service level. Suppose it was at a higher level. Where are the > instructions for applying service to TCP/IP? I don't see them in the > Service Guide unless I'm missing something. > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > -- Kris Buelens, IBM Belgium, VM customer support
service on tcpip?
RSU5105 indicates TCP/IP at service level 0502, which is my current service level. Suppose it was at a higher level. Where are the instructions for applying service to TCP/IP? I don't see them in the Service Guide unless I'm missing something. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: Service 2nd level
I did do vmfsetup first, but it redid it automatically in the vmfins install... so it wasn't there. I finally made 500 A and that worked. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 4/27/2007 1:53 PM >>> Hello Ann, I would suggest doing the VMSETUP first. Find the highest mode available and use that as your 500 drive. But (IIRC) I made 500 my A and made my 191 the next available highest. That way I kept all the files and things created during the service on 500. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441
Re: another service question
Gotcha! Since I barely know what I'm doing, I certainly didn't create
anything more. Thanks for the help.
Anne D. Crabtree
System Programmer
WV Dept of Administration - OT
304-558-5914 ext 8885
Fax 304-558-1351
>>> [EMAIL PROTECTED] 4/27/2007 9:43 AM >>>
I think that the message means"if you would have created more than one
GCS
system, what means you created your own GCS load list, you need to
build
these other GCSes with
vmfbld ppf zvm {gcs|gcssfs} myExtraGcsBldlist (all
2007/4/27, Anne Crabtree <[EMAIL PROTECTED]>:
>
> I am working on service and have reached the gcs component. I have
> completed the build step. A note in service guide says "If the
results of
> the VMFVIEW command show that the GCTLOAD build list was serviced (it
does)
> , then any new GCS nucleus build list(s) that you added will need to
be
> built. After issuing the VMFBLD command during step 1 in "Build
Serviced
> Objects" issue the following VMFBLD command:
> vmfbld ppf zvm {gcs|gcssfs} newbldlist (all
>
> I am not sure what to put as "newbldlist" . Where do I find that
name?
>
> Anne D. Crabtree
> System Programmer
> WV Dept of Administration - OT
> 304-558-5914 ext 8885
> Fax 304-558-1351
>
--
Kris Buelens,
IBM Belgium, VM customer support
another service question
I am working on service and have reached the gcs component. I have completed
the build step. A note in service guide says "If the results of the VMFVIEW
command show that the GCTLOAD build list was serviced (it does) , then any new
GCS nucleus build list(s) that you added will need to be built. After issuing
the VMFBLD command during step 1 in “Build Serviced Objects” issue the
following VMFBLD command:
vmfbld ppf zvm {gcs|gcssfs} newbldlist (all
I am not sure what to put as "newbldlist" . Where do I find that name?
Anne D. Crabtree
System Programmer
WV Dept of Administration - OT
304-558-5914 ext 8885
Fax 304-558-1351
Service 2nd level
I have a 2nd level z/vm 5.1 system that I am trying to put service on. LE is the first component with PTFs to be applied. I downloaded 5105RSU onto MAINT's 500 disk (3 files: 5105RSU1, 5105RSU2, and 5105RSU3 with SERVLINK as type) When I attempt to do the receive of ptfs for LE (following Chapter 2 in Service Guide "Receive a component from the RSU"): vmfins install ppf zvm le (nomemo nolink override no env 5105RSU1 it does a vmfsetup and I "lose" access to 500 and, therefore, it cannot find the envelope named 5105RSU1. My 191 disk is not big enough to hold the files (500 disk has 600 cyinders). Not sure what to do now... As I recall, the download instructed me to put the envelopes on 500. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
IODF
I recently converted our IODF file via z/os to V5 format. Z/VM has not been IPL'd since the change. Is there any reason I should be concerned about this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: VM second level
Yes, I'm having a real hard time with the virtual world but I'm progressing... Thanks for all the help from everyone. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 3/8/2007 12:27 PM >>> The simple answer is that, once your virtual machine is set up, everything you¹re interested in are the virtual components; You no longer need to deal with the ³real² devices. In your virtual machine, all you get to see is the 12FF disk; the real DASD it resides on doesn¹t exist in your virtual world. The same can be said for your virtual NIC; you don¹t care what the real OSA card is at that point. Your terminal? It¹s whatever the virtual machine¹s console address was defined as. It doesn¹t matter what real terminal you¹re sitting at. For DASD, you¹re going to label your minidisk, so you¹d use whatever label you initialized with. It doesn¹t matter what the label of the real DASD is, and you can use it, or some other label, based on your current needs. You¹ve got to think ³virtually². -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13 200 First Street SW / ( ) \ 507-284-0844 Rochester, MN 55905 ^^-^^ - "In theory, theory and practice are the same, but in practice, theory and practice are different." > From: Fran Hensler <[EMAIL PROTECTED]> > > You could restore yoour original install tapes to you 2nd level > machine and then apply maintenance. > > /Fran > ----- > On Thu, 8 Mar 2007 08:32:58 -0500 Anne Crabtree said: >> That's probably what I want to do eventually. I'm trying to learn how >> to do this so I can test maintenance somewhere before putting it on >> production (which is my only option at the moment). >> >>>>> [EMAIL PROTECTED] 3/8/2007 8:11 AM >>> >> You could put 510W01 in your 2nd level directory but it would be a >> minidisk on the real 510W01 volume. >> >> On Thu, 8 Mar 2007 08:06:24 -0500 Anne Crabtree said: >>> I was confused as to whether I should put VM2CKP in the DIRECTORY >> stmt >>> as opposed to 510W01. I'm just not sure I set everything up right. >>> >>> >>>>>> [EMAIL PROTECTED] 3/8/2007 7:49 AM >>> >>> Anne - >>> >>> You would use the 12FF disk for your 2nd level directory. >>> >>> In fact you could not write the directory to 510W01 even if you >>> wanted to. 510W01 is not defined in your 2nd level machine. >>> >>> /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" >>> >>> On Thu, 8 Mar 2007 07:36:28 -0500 Anne Crabtree said: >>>> I'm trying to set up a second level vm system following directions >> in >>>> "Z/VM Running Guest Operating Systems" Chapters 6 and 7. Here's my >>>> directory entry on first level: >>>> >>>> USER VMTEST VMTEST 64M 128M BG >>>> MACHINE ESA 2 >>>> OPTION TODENABLE >>>> ACCOUNT 1 VMTEST >>>> IPL CMS >>>> SPECIAL 400 3270 >>>> CONSOLE 009 3215 T >>>> SPOOL 00C 2540 READER * >>>> SPOOL 00D 2540 PUNCH A >>>> SPOOL 00E 1403 A >>>> LINK MAINT 0190 0190 RR >>>> LINK MAINT 019D 019D RR >>>> LINK MAINT 019E 019E RR >>>> MDISK 191 3390 217 0070 510W01 MR >>>> MDISK 1000 3390 287 0035 510W01 MR >>>> MDISK 12FF 3390 322 0070 510W01 MR >>>> >>>> I'm confused when I logon as VMTEST and create the USER DIRECT. >>>> In DIRECTORY stmt, should it be: >>>> DIRECTORY 12FF 3390 VM2CKP or do I have to use 510W01 since that's >>>> the real volid where 12FF is? User OPERATOR looks like this: >>>> USER OPERATOR AB12CD 32M 64M ABCDEFG >>>> IPL 190 PARM AUTOCR >>>> MACHINE ESA 4 >>>> ACCOUNT DEPT0001 BIN001 >>>> SPOOL00C RDR A >>>> SPOOL00D PUN A >>>> SPOOL00E 4248 A >>>> CONSOLE 01F 3270 T >>>> * R/W disks >>>> MDISK 191 3390 000 END VMT191 WR ALL >>>> MDISK 1000 3390 000 END IPLDSK WR ALL >>>> MDISK 12FF 3390 000 END VM2CKP WR ALL >>>> * R/O disks >>>> MDISK 190 3390 000 END MNT190 RR ALL >>>> MDISK 19D 3390 000 END MNT19D RR ALL >>>> MDISK 19E 3390 000 END MNT19E RR ALL >>>> >>>> In SYSTEM CONFIG, I have: >>>> Checkpoint Volid VM2CKP From Cylinder 1 for 2, >>>> Warmstart Volid VM2CKP From Cylinder 3 for 2 >>>> CP_Owned Slot 1 VM2CKP >>>> >>>> but since VM2CKP is a label not an actual volume, I'm not sure if I >>> did >>>> it right. >>>> >>>> I was trying to send this question to my buddy Phil at Velocity, but >>> it >>>> keeps coming back as undeliverable so I thought someone else could >>>> probably clear this up for me. >>>> Thanks! >>>> >>>> >>>> >>>> >>>> Anne D. Crabtree >>>> System Programmer >>>> WV Dept of Administration - OT >>>> 304-558-5914 ext 8885 >>>> Fax 304-558-1351
Re: TIMEZONE
Timezone_boundary on 2007-03-11 at 02:00:00 to EDT Timezone_boundary on 2007-11-04 at 02:00:00 to EST Timezone_boundary on 2008-03-09 at 02:00:00 to EDT Timezone_boundary on 2008-11-02 at 02:00:00 to EST Timezone_boundary on 2009-03-08 at 02:00:00 to EDT Timezone_boundary on 2009-11-01 at 02:00:00 to EST Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 3/8/2007 11:50 AM >>> Can somebody cut-n-paste their SYSTEM CONFIG USA Timezone_boundary statements for the next few years. I thought I had updated it, but when I double checked, they are not updated. :-( -- Tony Thigpen
Re: VM second level
OK good. That's the way I did it! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 3/8/2007 10:13 AM >>> Hi Anne, The way you have defined things, you would need to use CPFMTXA or ICKDSF to format your 12FF minidisk first, at which time you would write the label VM2CKP on the volume. This virtual volume's cylinder zero would be what your second level OPERATOR and directory would see. It is real cylinder 322 on real volume 510W01, but once you "pass through the wardrobe" :-) it looks to your second level like a 70 cylinder volume called VM2CKP because you made it that way. On 3/8/07, Anne Crabtree <[EMAIL PROTECTED]> wrote: > I was confused as to whether I should put VM2CKP in the DIRECTORY stmt > as opposed to 510W01. I'm just not sure I set everything up right. > > Anne D. Crabtree > System Programmer > WV Dept of Administration - OT > 304-558-5914 ext 8885 > Fax 304-558-1351 > > >>> [EMAIL PROTECTED] 3/8/2007 7:49 AM >>> > Anne - > > You would use the 12FF disk for your 2nd level directory. > > In fact you could not write the directory to 510W01 even if you > wanted to. 510W01 is not defined in your 2nd level machine. > > /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" > > On Thu, 8 Mar 2007 07:36:28 -0500 Anne Crabtree said: > >I'm trying to set up a second level vm system following directions in > >"Z/VM Running Guest Operating Systems" Chapters 6 and 7. Here's my > >directory entry on first level: > > > >USER VMTEST VMTEST 64M 128M BG > > MACHINE ESA 2 > > OPTION TODENABLE > > ACCOUNT 1 VMTEST > > IPL CMS > > SPECIAL 400 3270 > > CONSOLE 009 3215 T > > SPOOL 00C 2540 READER * > > SPOOL 00D 2540 PUNCH A > > SPOOL 00E 1403 A > > LINK MAINT 0190 0190 RR > > LINK MAINT 019D 019D RR > > LINK MAINT 019E 019E RR > > MDISK 191 3390 217 0070 510W01 MR > > MDISK 1000 3390 287 0035 510W01 MR > > MDISK 12FF 3390 322 0070 510W01 MR > > > >I'm confused when I logon as VMTEST and create the USER DIRECT. > >In DIRECTORY stmt, should it be: > >DIRECTORY 12FF 3390 VM2CKP or do I have to use 510W01 since that's > >the real volid where 12FF is? User OPERATOR looks like this: > >USER OPERATOR AB12CD 32M 64M ABCDEFG > > IPL 190 PARM AUTOCR > > MACHINE ESA 4 > > ACCOUNT DEPT0001 BIN001 > > SPOOL00C RDR A > > SPOOL00D PUN A > > SPOOL00E 4248 A > > CONSOLE 01F 3270 T > > * R/W disks > > MDISK 191 3390 000 END VMT191 WR ALL > > MDISK 1000 3390 000 END IPLDSK WR ALL > > MDISK 12FF 3390 000 END VM2CKP WR ALL > > * R/O disks > > MDISK 190 3390 000 END MNT190 RR ALL > > MDISK 19D 3390 000 END MNT19D RR ALL > > MDISK 19E 3390 000 END MNT19E RR ALL > > > >In SYSTEM CONFIG, I have: > >Checkpoint Volid VM2CKP From Cylinder 1 for 2, > >Warmstart Volid VM2CKP From Cylinder 3 for 2 > >CP_Owned Slot 1 VM2CKP > > > >but since VM2CKP is a label not an actual volume, I'm not sure if I > did > >it right. > > > >I was trying to send this question to my buddy Phil at Velocity, but > it > >keeps coming back as undeliverable so I thought someone else could > >probably clear this up for me. > >Thanks! > > > > > > > > > >Anne D. Crabtree > >System Programmer > >WV Dept of Administration - OT > >304-558-5914 ext 8885 > >Fax 304-558-1351 >
Re: VM second level
That's probably what I want to do eventually. I'm trying to learn how to do this so I can test maintenance somewhere before putting it on production (which is my only option at the moment). Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 3/8/2007 8:11 AM >>> You could put 510W01 in your 2nd level directory but it would be a minidisk on the real 510W01 volume. If you have enough DASD you could define minidisks on your 1st level machine from cylinder 1 to END for 510RES & 510W01. Then logon on to your 2nd level machine and restore DDR backups from your real 510RES & 510W01. This way you could have a complete running 2nd level system with little effort. /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" On Thu, 8 Mar 2007 08:06:24 -0500 Anne Crabtree said: >I was confused as to whether I should put VM2CKP in the DIRECTORY stmt >as opposed to 510W01. I'm just not sure I set everything up right. > >Anne D. Crabtree >System Programmer >WV Dept of Administration - OT >304-558-5914 ext 8885 >Fax 304-558-1351 > >>>> [EMAIL PROTECTED] 3/8/2007 7:49 AM >>> >Anne - > >You would use the 12FF disk for your 2nd level directory. > >In fact you could not write the directory to 510W01 even if you >wanted to. 510W01 is not defined in your 2nd level machine. > >/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" > >On Thu, 8 Mar 2007 07:36:28 -0500 Anne Crabtree said: >>I'm trying to set up a second level vm system following directions in >>"Z/VM Running Guest Operating Systems" Chapters 6 and 7. Here's my >>directory entry on first level: >> >>USER VMTEST VMTEST 64M 128M BG >> MACHINE ESA 2 >> OPTION TODENABLE >> ACCOUNT 1 VMTEST >> IPL CMS >> SPECIAL 400 3270 >> CONSOLE 009 3215 T >> SPOOL 00C 2540 READER * >> SPOOL 00D 2540 PUNCH A >> SPOOL 00E 1403 A >> LINK MAINT 0190 0190 RR >> LINK MAINT 019D 019D RR >> LINK MAINT 019E 019E RR >> MDISK 191 3390 217 0070 510W01 MR >> MDISK 1000 3390 287 0035 510W01 MR >> MDISK 12FF 3390 322 0070 510W01 MR >> >>I'm confused when I logon as VMTEST and create the USER DIRECT. >>In DIRECTORY stmt, should it be: >>DIRECTORY 12FF 3390 VM2CKP or do I have to use 510W01 since that's >>the real volid where 12FF is? User OPERATOR looks like this: >>USER OPERATOR AB12CD 32M 64M ABCDEFG >> IPL 190 PARM AUTOCR >> MACHINE ESA 4 >> ACCOUNT DEPT0001 BIN001 >> SPOOL00C RDR A >> SPOOL00D PUN A >> SPOOL00E 4248 A >> CONSOLE 01F 3270 T >> * R/W disks >> MDISK 191 3390 000 END VMT191 WR ALL >> MDISK 1000 3390 000 END IPLDSK WR ALL >> MDISK 12FF 3390 000 END VM2CKP WR ALL >> * R/O disks >> MDISK 190 3390 000 END MNT190 RR ALL >> MDISK 19D 3390 000 END MNT19D RR ALL >> MDISK 19E 3390 000 END MNT19E RR ALL >> >>In SYSTEM CONFIG, I have: >>Checkpoint Volid VM2CKP From Cylinder 1 for 2, >>Warmstart Volid VM2CKP From Cylinder 3 for 2 >>CP_Owned Slot 1 VM2CKP >> >>but since VM2CKP is a label not an actual volume, I'm not sure if I >did >>it right. >> >>I was trying to send this question to my buddy Phil at Velocity, but >it >>keeps coming back as undeliverable so I thought someone else could >>probably clear this up for me. >>Thanks! >> >> >> >> >>Anne D. Crabtree >>System Programmer >>WV Dept of Administration - OT >>304-558-5914 ext 8885 >>Fax 304-558-1351
Re: VM second level
I was confused as to whether I should put VM2CKP in the DIRECTORY stmt as opposed to 510W01. I'm just not sure I set everything up right. Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351 >>> [EMAIL PROTECTED] 3/8/2007 7:49 AM >>> Anne - You would use the 12FF disk for your 2nd level directory. In fact you could not write the directory to 510W01 even if you wanted to. 510W01 is not defined in your 2nd level machine. /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" On Thu, 8 Mar 2007 07:36:28 -0500 Anne Crabtree said: >I'm trying to set up a second level vm system following directions in >"Z/VM Running Guest Operating Systems" Chapters 6 and 7. Here's my >directory entry on first level: > >USER VMTEST VMTEST 64M 128M BG > MACHINE ESA 2 > OPTION TODENABLE > ACCOUNT 1 VMTEST > IPL CMS > SPECIAL 400 3270 > CONSOLE 009 3215 T > SPOOL 00C 2540 READER * > SPOOL 00D 2540 PUNCH A > SPOOL 00E 1403 A > LINK MAINT 0190 0190 RR > LINK MAINT 019D 019D RR > LINK MAINT 019E 019E RR > MDISK 191 3390 217 0070 510W01 MR > MDISK 1000 3390 287 0035 510W01 MR > MDISK 12FF 3390 322 0070 510W01 MR > >I'm confused when I logon as VMTEST and create the USER DIRECT. >In DIRECTORY stmt, should it be: >DIRECTORY 12FF 3390 VM2CKP or do I have to use 510W01 since that's >the real volid where 12FF is? User OPERATOR looks like this: >USER OPERATOR AB12CD 32M 64M ABCDEFG > IPL 190 PARM AUTOCR > MACHINE ESA 4 > ACCOUNT DEPT0001 BIN001 > SPOOL00C RDR A > SPOOL00D PUN A > SPOOL00E 4248 A > CONSOLE 01F 3270 T > * R/W disks > MDISK 191 3390 000 END VMT191 WR ALL > MDISK 1000 3390 000 END IPLDSK WR ALL > MDISK 12FF 3390 000 END VM2CKP WR ALL > * R/O disks > MDISK 190 3390 000 END MNT190 RR ALL > MDISK 19D 3390 000 END MNT19D RR ALL > MDISK 19E 3390 000 END MNT19E RR ALL > >In SYSTEM CONFIG, I have: >Checkpoint Volid VM2CKP From Cylinder 1 for 2, >Warmstart Volid VM2CKP From Cylinder 3 for 2 >CP_Owned Slot 1 VM2CKP > >but since VM2CKP is a label not an actual volume, I'm not sure if I did >it right. > >I was trying to send this question to my buddy Phil at Velocity, but it >keeps coming back as undeliverable so I thought someone else could >probably clear this up for me. >Thanks! > > > > >Anne D. Crabtree >System Programmer >WV Dept of Administration - OT >304-558-5914 ext 8885 >Fax 304-558-1351
VM second level
I'm trying to set up a second level vm system following directions in "Z/VM Running Guest Operating Systems" Chapters 6 and 7. Here's my directory entry on first level: USER VMTEST VMTEST 64M 128M BG MACHINE ESA 2 OPTION TODENABLE ACCOUNT 1 VMTEST IPL CMS SPECIAL 400 3270 CONSOLE 009 3215 T SPOOL 00C 2540 READER * SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 191 3390 217 0070 510W01 MR MDISK 1000 3390 287 0035 510W01 MR MDISK 12FF 3390 322 0070 510W01 MR I'm confused when I logon as VMTEST and create the USER DIRECT. In DIRECTORY stmt, should it be: DIRECTORY 12FF 3390 VM2CKP or do I have to use 510W01 since that's the real volid where 12FF is? User OPERATOR looks like this: USER OPERATOR AB12CD 32M 64M ABCDEFG IPL 190 PARM AUTOCR MACHINE ESA 4 ACCOUNT DEPT0001 BIN001 SPOOL00C RDR A SPOOL00D PUN A SPOOL00E 4248 A CONSOLE 01F 3270 T * R/W disks MDISK 191 3390 000 END VMT191 WR ALL MDISK 1000 3390 000 END IPLDSK WR ALL MDISK 12FF 3390 000 END VM2CKP WR ALL * R/O disks MDISK 190 3390 000 END MNT190 RR ALL MDISK 19D 3390 000 END MNT19D RR ALL MDISK 19E 3390 000 END MNT19E RR ALL In SYSTEM CONFIG, I have: Checkpoint Volid VM2CKP From Cylinder 1 for 2, Warmstart Volid VM2CKP From Cylinder 3 for 2 CP_Owned Slot 1 VM2CKP but since VM2CKP is a label not an actual volume, I'm not sure if I did it right. I was trying to send this question to my buddy Phil at Velocity, but it keeps coming back as undeliverable so I thought someone else could probably clear this up for me. Thanks! Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: zSeries Linux - How Many Users?
We have two production systems on zserier Linux (Dept of Corrections and Board of Review). A potential large tax system thinking about moving there.. plus thinking about moving Tivoli there... >>> [EMAIL PROTECTED] 2/12/2007 7:04 AM >>> Does anyone happen to know a ballpark figure of how many companies are using zSeries Linux?? My reason for asking is I am working on trying to convince the management here that we could save tons of money by consolidating a lot of the easier workloads (ie- print servers) to zSeries Linux. One of the things I get back is "no one is doing it", although I have to think there is a lot of it being used, especially with todays economy as it is. I think IBM has not done a very good job of promoting zSeries Linux, although from a marketing standpoint they undoubtedly make more money with a room full of p-boxes than one or two z-boxes running the same workload. Thanks, Paul Adrian.
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. >>> [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
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. >> = > == > ===
Re: backup prior to maintenance
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
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. >= == ===
backup prior to maintenance
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: Year end cleanup of diskacnt and accsrv
duh.. don't know why I didn't think of changing the sort order in existing routine.. I think I just need to go home ;) >>> [EMAIL PROTECTED] 1/23/2007 12:57 PM >>> Try doing: SET DATEF FULL then sorting on mmdd -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Tuesday, January 23, 2007 12:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Year end cleanup of diskacnt and accsrv Does anyone have a routine (pipe or otherwise) that will clean up records for diskacnt and accsrv on January 1 of each year? I usually keep 7 days worth of accounting records and each night old files are deleted. However, on January 1, the routine fails to work because the files are sorted in mmddyy order, thereby, putting the December files before the January files. It keeps the last 7 days of December and deletes new January files each night. I need something that will recognize it as first day of the year and kick off yearend cleanup routine to get rid of all files prior to the January 1 file being created. Cannot figure out a way to "automate" this! If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Year end cleanup of diskacnt and accsrv
Does anyone have a routine (pipe or otherwise) that will clean up records for diskacnt and accsrv on January 1 of each year? I usually keep 7 days worth of accounting records and each night old files are deleted. However, on January 1, the routine fails to work because the files are sorted in mmddyy order, thereby, putting the December files before the January files. It keeps the last 7 days of December and deletes new January files each night. I need something that will recognize it as first day of the year and kick off yearend cleanup routine to get rid of all files prior to the January 1 file being created. Cannot figure out a way to "automate" this!
Re: PERM space
ok, well thanks for everyone's help.. i think i got it added ok. >>> [EMAIL PROTECTED] 11/30/2006 5:02 PM >>> > Well, the reason I'm doing it is because the 510RES has very little space > left. I almost couldn't get the maintenance to fit on the 500 disk and I > didn't have many cylinders left vacant. Since, on our previous release of > z/vm which was v4r3, we had a 430RES and a 430W01 and they were both CP > OWNED, I figured that was the way to go. That was because in earlier releases of VM the starter system had page/spool space on those volumes. You can safely move the 500 disk to a non-CP owned volume without concern.
Re: PERM space
OK, so what if I wanted to put MAINT's 500 disk on there.. that's how this whole thing got started in my mind. I do have reserved slots which follow the ones that are cpowned. I was just going to change the 7th (which is RESERVED) to 510W01... >>> [EMAIL PROTECTED] 11/30/2006 4:24 PM >>> As mentioned, there i sno need to make a volume CPOWNED when it does not contain space for CP use. And, you only need to format the area's CP will use with ICKDSF: cylinder ranges you later devote the CMS minidisks will be formatted by the CMS FORMAT command later on, so CPVOL format UNIT(1748) RANGE(,) TYPE(PERM,,3338) VFY(510W01) can save quite some formatting time. If the slots displayed below truely reflect the contents of your SYSTEM CONFIG, I'd suggest to add some RESERVED slots. Then you can define extra CP owned volumes without IPL Kris, IBM Belgium, VM customer support The IBM z/VM Operating System wrote on 2006-11-30 21:59:33: > I need to add a 510W01 volume to z/vm as PERM space and I already > have the following defined in SYSTEM CONFIG: > CP_Owned Slot 1 510RES > CP_Owned Slot 2 510SPL > CP_Owned Slot 3 510PAG > CP_Owned Slot 4 510PG1 > CP_Owned Slot 5 510PG2 > CP_Owned Slot 6 510PG3 > Any problem with just adding it as Slot 7? > Was planning on do this under MAINT on the fly: > CPVOL FMT UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) > DEFINE CPOWNED SLOT 7 510W01 > ATT 1748 MAINT > CPVOL ALLOC UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) > DET 1748 MAINT > ATT 1748 SYSTEM > Just want to make sure this scenario will work and not hurt anything...
Re: PERM space
Well, the reason I'm doing it is because the 510RES has very little space left. I almost couldn't get the maintenance to fit on the 500 disk and I didn't have many cylinders left vacant. Since, on our previous release of z/vm which was v4r3, we had a 430RES and a 430W01 and they were both CP OWNED, I figured that was the way to go. >>> [EMAIL PROTECTED] 11/30/2006 4:07 PM >>> If it's all perm space as you suggest you could just put it as User_Volume_List 510W01 in system config it should not be defined as cp_owned, just a user_volume. Try using Cpfmtxa (help to see the usage). Page, spool, tdisk, parm, for cp_owned, slotted, everything else can be user volumes. Regards, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Thursday, November 30, 2006 2:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: PERM space I need to add a 510W01 volume to z/vm as PERM space and I already have the following defined in SYSTEM CONFIG: CP_Owned Slot 1 510RES CP_Owned Slot 2 510SPL CP_Owned Slot 3 510PAG CP_Owned Slot 4 510PG1 CP_Owned Slot 5 510PG2 CP_Owned Slot 6 510PG3 Any problem with just adding it as Slot 7? Was planning on do this under MAINT on the fly: CPVOL FMT UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) DEFINE CPOWNED SLOT 7 510W01 ATT 1748 MAINT CPVOL ALLOC UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) DET 1748 MAINT ATT 1748 SYSTEM Just want to make sure this scenario will work and not hurt anything...
PERM space
I need to add a 510W01 volume to z/vm as PERM space and I already have the following defined in SYSTEM CONFIG: CP_Owned Slot 1 510RES CP_Owned Slot 2 510SPL CP_Owned Slot 3 510PAG CP_Owned Slot 4 510PG1 CP_Owned Slot 5 510PG2 CP_Owned Slot 6 510PG3 Any problem with just adding it as Slot 7? Was planning on do this under MAINT on the fly: CPVOL FMT UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) DEFINE CPOWNED SLOT 7 510W01 ATT 1748 MAINT CPVOL ALLOC UNIT(1748) RANGE(,3338) TYPE(PERM,,3338) VFY(510W01) DET 1748 MAINT ATT 1748 SYSTEM Just want to make sure this scenario will work and not hurt anything...
Re: DISKACNT problem
I just gave up on this approach and changed it to use a mod 3 I had labelled as VMACCT and had used for V4.3. Now, I have the DISKACNT 100 cyl on that volume instead of 510RES and it seems to be ok... Yes, the Q DISK showed 400 ,but Q V 501 showed 100... >>> [EMAIL PROTECTED] 4/6/2006 12:07 PM >>> Hello Anne, Yes that sound right. I take it that you did not CMS FORMAT the new Mdisk. You should be able to do a Q V and see the 100 cyl, but when you do a Q DISK it shows the 400 right? Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 >> -Original Message- >> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On >> Behalf Of Anne Crabtree >> Sent: Thursday, April 06, 2006 11:47 AM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: DISKACNT problem >> >> Well, the stuff was from a product we demo'd a while back and I don't >> need it. However, it seems like even though I put 100 cyl in DISKACNT's >> 191 A disk, it shows 400 cyl when I query the disk from MAINT. I assume >> this is because this particular bit of space was allocated as 400 cyl for >> that old product. Does that seem right? >> >> >>> [EMAIL PROTECTED] 4/6/2006 10:57 AM >>> >> You need to run DIRMAP from the CMS 190 disk to make certain that you >> don't >> have an overlap somewhere. The easiest way to have DISKACNT "see" the >> new >> disk is to log it off and then after the directory change is done, log >> back >> on to it. >> >> Be very careful. You could be writing on top of something else. >> Jim >> >> At 09:52 AM 4/6/2006, you wrote: >> >I tried to move the DISKACNT A disk to a bigger slot. That area had >> >previously been used by something else. I issued the FORMAT 191 A >> command >> >and discarded the old stuff. The 'area' still has the old label so I >> did >> >FORMAT 191 A (label) and gave it the DSK191 label. I must need to do >> >something else, because when I logon as DISKACNT and q disk, it shows >> much >> >more space than I put in the user directory. Do I have to do a CPFMTXA? >> >> Jim Bohnsack >> Cornell Univ. >> (607) 255-1760
Re: DISKACNT problem
This is how it was when I had original problem: USER DISKACNT DISKACNT 32M 32M BG INCLUDE IBMDFLT AUTOLOG AUTOLOG1 OP1 MAINT ACCOUNT 10 ACCNTNG MACH XA IPL 190 IUCV *ACCOUNT MDISK 191 3390 2709 001 510RES MR READ WRITEMULTIPLE This is what I tried to change it to: USER DISKACNT DISKACNT 32M 32M BG INCLUDE IBMDFLT AUTOLOG AUTOLOG1 OP1 MAINT ACCOUNT 10 ACCNTNG MACH XA IPL 190 IUCV *ACCOUNT MDISK 191 3390 8331 100 510RES MR READ WRITEMULTIPLE But after linking to it via MAINT and Q DISK, it showed 400 cylinders not 100. >>> [EMAIL PROTECTED] 4/6/2006 11:50 AM >>> Anne, Could you post a copy of your directory entry for DISKACNT ? at least the MDISK statements? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Anne Crabtree Sent: Thursday, April 06, 2006 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DISKACNT problem Well, the stuff was from a product we demo'd a while back and I don't need it. However, it seems like even though I put 100 cyl in DISKACNT's 191 A disk, it shows 400 cyl when I query the disk from MAINT. I assume this is because this particular bit of space was allocated as 400 cyl for that old product. Does that seem right? >>> [EMAIL PROTECTED] 4/6/2006 10:57 AM >>> You need to run DIRMAP from the CMS 190 disk to make certain that you don't have an overlap somewhere. The easiest way to have DISKACNT "see" the new disk is to log it off and then after the directory change is done, log back on to it. Be very careful. You could be writing on top of something else. Jim At 09:52 AM 4/6/2006, you wrote: >I tried to move the DISKACNT A disk to a bigger slot. That area had >previously been used by something else. I issued the FORMAT 191 A command >and discarded the old stuff. The 'area' still has the old label so I did >FORMAT 191 A (label) and gave it the DSK191 label. I must need to do >something else, because when I logon as DISKACNT and q disk, it shows much >more space than I put in the user directory. Do I have to do a CPFMTXA? Jim Bohnsack Cornell Univ. (607) 255-1760 __ << 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: DISKACNT problem
Well, the stuff was from a product we demo'd a while back and I don't need it. However, it seems like even though I put 100 cyl in DISKACNT's 191 A disk, it shows 400 cyl when I query the disk from MAINT. I assume this is because this particular bit of space was allocated as 400 cyl for that old product. Does that seem right? >>> [EMAIL PROTECTED] 4/6/2006 10:57 AM >>> You need to run DIRMAP from the CMS 190 disk to make certain that you don't have an overlap somewhere. The easiest way to have DISKACNT "see" the new disk is to log it off and then after the directory change is done, log back on to it. Be very careful. You could be writing on top of something else. Jim At 09:52 AM 4/6/2006, you wrote: >I tried to move the DISKACNT A disk to a bigger slot. That area had >previously been used by something else. I issued the FORMAT 191 A command >and discarded the old stuff. The 'area' still has the old label so I did >FORMAT 191 A (label) and gave it the DSK191 label. I must need to do >something else, because when I logon as DISKACNT and q disk, it shows much >more space than I put in the user directory. Do I have to do a CPFMTXA? Jim Bohnsack Cornell Univ. (607) 255-1760
Re: DISKACNT problem
I tried to move the DISKACNT A disk to a bigger slot. That area had previously been used by something else. I issued the FORMAT 191 A command and discarded the old stuff. The 'area' still has the old label so I did FORMAT 191 A (label) and gave it the DSK191 label. I must need to do something else, because when I logon as DISKACNT and q disk, it shows much more space than I put in the user directory. Do I have to do a CPFMTXA? >>> [EMAIL PROTECTED] 4/6/2006 9:07 AM >>> 02 records are 'Dedicated Devices'. I believe that also include 'ATTACHed' devices. cc 1-8 is the userid of the owner. cc 17-28 is mmddyyhhmmss when the record was created when the device was released. You'll need to dig in Appendix F of Planning and Admin to see what the device it is. That info is recorded in cc 33-36. (Must be giving away my age when I am referring to card column. Of course, I have 5081 cards in my shirt pocket.) Jim At 08:57 AM 4/6/2006, you wrote: >I believe I have the cleanup situation in hand. > >When I look at the $ACCOUNT $A040506, there are a lot of type 02 >records. I really only need the type 01 to show how much cpu the linux >machines are using. I swear the only thing I changed was taking the >WAKEUP out of the profile exec for DISKACNT. I just issue the retrieve >account command and that's it. It didn't appear to be "waking" up anyway >because the date in WAKEUP TIMES file never changed. > >I guess I can make the A disk big so that it will hold a week's worth of >data, it just seems odd that it is recording so much more >now. Unfortunately, to get out of the problem, I deleted the old ACCOUNT >files, so I'm not sure what types were in there when I was only getting 50 >or so records. > > >>> [EMAIL PROTECTED] 4/6/2006 8:37 AM >>> >Anne--Accounting records are created entirely by activity on the >system. You will see a record for every user session, for LINK commands, >TDISK usage, another type can be created by RSCS for file transfers and so >on. Some of this can be somewhat controlled by entries in SYSTEM >CONFIG. You can take a look at the records that are created, using the >record layouts in the Planning and Administration manual. If you were only >creating 51 records per day previously and now 4000, something changed. > >As far as how you get rid of old files, probably everyone has their own >methods. Personally, I set an id up to be the SECUSER for DISKACNT. With >that in place, I temporarily stop recording by sending a CP EXT >command. With recording stopped, I send that day's file to wherever I >process the records (MVS in my case), run an exec to clean up old >accounting files, and restart recording and record retrieval. I can send >you the code if you want. > >A 1 cyl collection disk is pretty small even for a system that doesn't do >much in the way of account record generation. Why don't you splurge and >give it a few more cylinders. > >Jim > >At 08:09 AM 4/6/2006, you wrote: > >I'm not sure if anyone can help me, but am asking anyway! I'm having > >problems with the DISKACNT machine. I had a routine set up with DISKACNT > >and ACCSRV to collect accounting records. Everything was going fine > >except that the DISKACNT A disk was filling up about every 30 days or > >so. I had DISKACNT set up with a PROFILE EXEC similar to ACCSRV with a > >WAKEUP that retrieved account and then tried to clean. I've come to the > >conclusion that once the RETRIEVE ACCOUNT command is entered, that is all > >DISKACNT does and it was not recognizing any commands afterwards thereby > >not cleaning the disk. So, I changed DISKACNT PROFILE EXEC to just issue > >RETRIEVE ACCOUNT and created a batch job to run weekly to clean up the A > >disk for DISKACNT using ftp with MAINT forcing DISKACNT off, doing a clean > >routine and then logging DISKACNT back on. My problem? All of a sudden > >DISKACNT appears to be writing records every 15 minutes or so causing the > >A disk to fill up in a little over 24 hours (I still have the A disk as 1 > >cylinder). Before it would write about 51 records for a day and now it is > >writing 4000! I do not understand how my change could have done > >this. Any ideas? > >Jim Bohnsack >Cornell Univ. >(607) 255-1760 Jim Bohnsack Cornell Univ. (607) 255-1760
Re: DISKACNT problem
I believe I have the cleanup situation in hand. When I look at the $ACCOUNT $A040506, there are a lot of type 02 records. I really only need the type 01 to show how much cpu the linux machines are using. I swear the only thing I changed was taking the WAKEUP out of the profile exec for DISKACNT. I just issue the retrieve account command and that's it. It didn't appear to be "waking" up anyway because the date in WAKEUP TIMES file never changed. I guess I can make the A disk big so that it will hold a week's worth of data, it just seems odd that it is recording so much more now. Unfortunately, to get out of the problem, I deleted the old ACCOUNT files, so I'm not sure what types were in there when I was only getting 50 or so records. >>> [EMAIL PROTECTED] 4/6/2006 8:37 AM >>> Anne--Accounting records are created entirely by activity on the system. You will see a record for every user session, for LINK commands, TDISK usage, another type can be created by RSCS for file transfers and so on. Some of this can be somewhat controlled by entries in SYSTEM CONFIG. You can take a look at the records that are created, using the record layouts in the Planning and Administration manual. If you were only creating 51 records per day previously and now 4000, something changed. As far as how you get rid of old files, probably everyone has their own methods. Personally, I set an id up to be the SECUSER for DISKACNT. With that in place, I temporarily stop recording by sending a CP EXT command. With recording stopped, I send that day's file to wherever I process the records (MVS in my case), run an exec to clean up old accounting files, and restart recording and record retrieval. I can send you the code if you want. A 1 cyl collection disk is pretty small even for a system that doesn't do much in the way of account record generation. Why don't you splurge and give it a few more cylinders. Jim At 08:09 AM 4/6/2006, you wrote: >I'm not sure if anyone can help me, but am asking anyway! I'm having >problems with the DISKACNT machine. I had a routine set up with DISKACNT >and ACCSRV to collect accounting records. Everything was going fine >except that the DISKACNT A disk was filling up about every 30 days or >so. I had DISKACNT set up with a PROFILE EXEC similar to ACCSRV with a >WAKEUP that retrieved account and then tried to clean. I've come to the >conclusion that once the RETRIEVE ACCOUNT command is entered, that is all >DISKACNT does and it was not recognizing any commands afterwards thereby >not cleaning the disk. So, I changed DISKACNT PROFILE EXEC to just issue >RETRIEVE ACCOUNT and created a batch job to run weekly to clean up the A >disk for DISKACNT using ftp with MAINT forcing DISKACNT off, doing a clean >routine and then logging DISKACNT back on. My problem? All of a sudden >DISKACNT appears to be writing records every 15 minutes or so causing the >A disk to fill up in a little over 24 hours (I still have the A disk as 1 >cylinder). Before it would write about 51 records for a day and now it is >writing 4000! I do not understand how my change could have done >this. Any ideas? Jim Bohnsack Cornell Univ. (607) 255-1760
DISKACNT problem
I'm not sure if anyone can help me, but am asking anyway! I'm having problems with the DISKACNT machine. I had a routine set up with DISKACNT and ACCSRV to collect accounting records. Everything was going fine except that the DISKACNT A disk was filling up about every 30 days or so. I had DISKACNT set up with a PROFILE EXEC similar to ACCSRV with a WAKEUP that retrieved account and then tried to clean. I've come to the conclusion that once the RETRIEVE ACCOUNT command is entered, that is all DISKACNT does and it was not recognizing any commands afterwards thereby not cleaning the disk. So, I changed DISKACNT PROFILE EXEC to just issue RETRIEVE ACCOUNT and created a batch job to run weekly to clean up the A disk for DISKACNT using ftp with MAINT forcing DISKACNT off, doing a clean routine and then logging DISKACNT back on. My problem? All of a sudden DISKACNT appears to be writing records every 15 minutes or so causing the A disk to fill up in a little over 24 hours (I still have the A disk as 1 cylinder). Before it would write about 51 records for a day and now it is writing 4000! I do not understand how my change could have done this. Any ideas?
