Re: Temp SFS environment
I don't know about detach, but re-link definitely happens. File pool minidisks can be defined in the directory with linkmode R and they still become linked R/W when the server starts and remain R/W after the server terminates. Ivica Brodaric BNZ
Re: SFS question
Stephen, Do I understand the formula and definitions correctly? You do, but that's just to get you started. It really all depends on how many objects are going to be created in that file pool. So, take that formula as an attempt to predict the future. MAXUSERS determines the logical size of the catalog and that formula is MAXUSERS * 85 (and that's a real formula). Half of that goes to data blocks and half to index blocks. The physical size of the catalog (number of blocks in group 1) can initially be much smaller than that. That smaller space would again be divided equally to data and index blocks. It is much easier to add another minidisk to group 1 (when you hit physical limit) than to do regenerate file pool (when you hit logical limit). Therefore, allocate MAXUSERS generously, so that you don't have to do this again soon. In your case, you have 640 cylinders in group 1 (16 * 40 cyl), which equates to 115200 blocks. You may have over-allocated group 1, but to decrease that now would be a pain, so leave it. To be able to use all that space, the logical size of the catalog has to be at least that much, so MAXUSERS must be at least 1356, which is 115200 / 85, rounded up. I would suggest that you use at least 5000 if not 1 for MAXUSERS. Over-allocating MAXUSERS is not harmful, it just takes a bit of space in control minidisk. Size of control minidisk (or of the rest of it) determines the number of potentially addressable blocks in the file pool (maximum size to which the file pool can grow to). You can see that number if you do QUERY FILEPOOL OVERVIEW, but roughly, it is a bit less than one million addressable blocks for each control disk cylinder. There is no formula for this, because other things go to control disk as well (MAXDISKS has a hand in it too), but for example (roughly again), with a 50-cylinder control disk you will be left with at least 45 million potentially addressable blocks, which equates to around 75 3390 mod3's. That's the maximum size of disk space that you will ever be able to have in the file pool before having to regenerate it. While regenerating file pool, you will have to increase the size of the control disk. You have to do this to allow for the increase of MAXUSERS in order to maintain at least the same number of potentially addressable blocks. Increase it by 25-33% to be sure, but do *not* over-allocate control disk. Whenever the file pool server performs control data backup (and it does it automatically when log disks fill up more than 80%), the file pool will be unavailable to end users for the duration of the backup. You want that backup to be quick especially if your log disks are small and the backup is run often. Control data backup backs up *entire* control disk and *used* blocks in group 1 (catalog). Therefore, over-allocating group 1 is OK, but over-allocating control disk is not. Follow the procedure to regenerate a repository file pool to which you have been pointed to already and you'll be fine. One final word of advice though: before doing anything like this, make sure that you also have a reliable backup of the whole file pool (storage groups 2 and above) handy. Ivica Brodaric BNZ
Re: Virtual Lock File
Another way would be to define a VDISK in the PROFILE EXEC of the VDISKS machine (instead of VM directory definition) and check the return code of CP DEFINE (if it's 0, initialise it). I forgot to say that in this case you would have to add 'CP LINK VDISKS 222 vaddr MW' a second or two after 'CP XAUTOLOG VDISKS' in VSE machines' PROFILE EXECs. Also, you may choose to add COMMAND XAUTOLOG VDISKS directory control statement for all VSE machines, which would work even if you IPL VSE straight from directory by using IPL sysres_addr directory control statement, and then you don't even have to worry about VSE machines' privilege class to be able to run XAUTOLOG CP command. Ivica Brodaric BNZ
Re: SFS question
Do QUERY FILEPOOL CATALOG to see the amount of catalog data blocks and catalog index blocks used. Total number of catalog space blocks (data+index) is MAXUSERS*85. Maybe your MAXUSERS value is too small? Ivica Brodaric BNZ
Re: Virtual Lock File
If your VSE machines are being IPLed by first IPL-ing CMS and then IPLing VSE from their PROFILE EXEC, then you may do the following: 1. Include 'CP XAUTOLOG VDISKS' in all VSE machines' PROFILE EXECs anywhere before IPL command. (Make sure all your VSE machines are properly authorised to XAUTOLOG VDISKS machine.) 2. Modify PROFILE EXEC in your VDISKS machine to include the check wether the virtual disk is already initialised (check the label or try ACCESSing it) and then don't initialise it if it is. Another way would be to define a VDISK in the PROFILE EXEC of the VDISKS machine (instead of VM directory definition) and check the return code of CP DEFINE (if it's 0, initialise it). If you want to keep a VDISK alive for reasons other than having to manually autolog VDISKS before you IPL the first VSE machine, then take one of the other good suggestions. Ivica Brodaric BNZ
Re: Xedit question
Mark, C/$/CP QUERY DASD $/* Alas, testing revealed that the trailing quote doesn't get inserted. How come? Your trailing doublequote got truncated but XEDIT remained silent, right? That's one tiny quirk you've got to remember (or it gets etched into your mind anyway) when using the arbchar. Since your first $ is not followed by anything, it represents the whole line including all the trailing blanks up to zone2 column. If you have SET ZONE 1 * and you're making the line longer with your change, the trailing doublequote in your example will get truncated but XEDIT will *not* tell you that. Also, the line will *not* spill even if SPILL is ON. There may be a reason why the designer decided to do it this way, but I cannot think of one. To drop the first word and surround the result with doublequotes by using only CHANGE command, you'd have to use at least two, eg: c/$ /CP QUERY DASD /* c/ //* 1 4 -or- c/DASD $ /DASD $/* Ivica Brodaric BNZ
Re: Curiousity question - Changing the status area
Another way of changing CMS Ready message (does not require R/W disk):
/* Display Userid; instead of Ready; */
parse value userid() with 1 initial 2 rest
name = initial || translate(rest, xrange('a', 'z'), xrange('A', 'Z'))
parse value diag(8, 'DISPLAY 634') with . addr .
call diag 8, 'STORE S'd2x(x2d(addr) + 3) right(length(name), 2, '0')
call diag 8, 'STORE S'd2x(x2d(addr) + 4) c2x(name)
Ivica Brodaric
BNZ
Re: Moving on (please don't panic)
Congratulations, Alan! Good luck in your new job!
Re: New Job
Great news, Tom! Congratulations! You'll be all right, don't worry. On Tue, Aug 3, 2010 at 1:23 AM, Tom Huegel tehue...@gmail.com wrote: Today I start my new job. It has been eight months in the making.. I sure hope I still remember my z/VM stuff... If I forgot anything, there is always this list for help.
Re: LINUX on IFL
Yes. Do CP DEDICATE USER userid CPU cpuaddr. Or add DEDICATE to the CPU directory statement. On Tue, Apr 13, 2010 at 2:36 PM, Anson yeal_c...@yahoo.com.cn wrote: Hi All, I have question about Linux on IFL. If there is a zVM LPAR with both CPs and 1 IFL. Is it possible to let one Linux guest to excluded use this IFL and only use this IFL? (We assume this IFL is dedicated on this LPAR) Thanks! Best Regards Anson Y
Moving On
I am glad to announce that after long holidays I started a new job at BNZ (formerly known as Bank of New Zealand), Auckland. New job, new city, new country. z/VM, RHEL, z10 EC's, a fairly new installation and a lot of interesting work to be done. It was too late to join my new colleagues for a trip to Seattle, but I'm sure those of you who are at SHARE will treat them well. Long live VM! Ivica Brodaric Technical Services BNZ
Re: Automated DDR funny - has anyone got any ideas
I like to use the line delete symbol as a way to add comments to my DDR control files. So, we will all now suffer a brand new control statement because of you. ;-)
Re: TCPIP-CTC Error
Did you COUPLE send port with receive port of the other side, ie TCPIP 840 - ZVSE42 841, TCPIP 841 - ZVSE42 840? Ivica
Re: An SFS aid
IPL (no abbreviation and no operands) executes the last IPL. Abbreviate it, and you have to specify system name or device address at least. On Fri, Feb 26, 2010 at 9:48 PM, Ian S. Worthington ianworthing...@usa.netwrote: Wasn't aware of this. What's the difference between IPL long and short? i -- Original Message -- Received: 11:00 PM COT, 02/25/2010 From: Phil Smith III li...@akphs.com To: IBMVM@LISTSERV.UARK.EDU Subject: Re: An SFS aid I'm trying to remember if there are CP commands besides IPL whose behavior varies depending on whether they're abbreviated or not; I can't think of any. Anyone? ..phsiii
Re: An SFS aid
years ago. There was no better option. Ivica Brodaric
Re: An SFS aid
I understand, Ray. I just tried to prevent those who read this list and who may be new to REXX from thinking that Signal is widely accepted in constructing loops. Ivica On Thu, Feb 25, 2010 at 5:30 AM, Mrohs, Ray ray.mr...@usdoj.gov wrote: My posting was the result of frustration with SFS. I wasn't thinking about perfect code structure. Frankly, at a certain age you care less about those things, as long as it works and the boss is happy. :-) But I understand your criticism. Ray -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Ivica Brodaric *Sent:* Wednesday, February 24, 2010 10:46 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: An SFS aid May I suggest that you also see call, return, do forever and leave in REXX manual? You can easily implement those in your program. Please don't use signal unless you are handling an error and/or about to leave the program. I hope I've put this nicely... Ivica
Re: z/VM backuprestore procedure
Ivica 2010/2/26 Pluzhnikov Vsevolod vpluzhni...@croc.ru Hello, All! Help me please in understanding the correct way of backup/restore z/VM system (on CKD dasd). I’ll need to perform this because of disruptive upgrade of our DS8300. I’m testing now ddrxa. Is it possible to define all 3390 mod9 (540RES, 540SPL, 540PAG, USER…) dasd to maint as full-pack minidisks and just backup all of them on tape? You can, but I suggest a separate user, call it SYSDASD, SYSDISK, or whatever, with password NOLOG. Let that user own all full pack minidisks. You don't need any other statements in that user's directory except USER and MDISK for each full pack. Then link from a worker machine to perform backups. Can I perform a restore with IPL from tape and just typing new dasd in output command for restore or it can be done only from z/VM ? You can restore by IPLing the tape with DDRXA program on it first, and then mounting data tapes. To create the tape with ICKDSF, DDRXA and DIRECTXA on it, do UTILITY UTILTAPE ALL or UTILITY UTILTAPE DDR for just DDR after accessing MAINT 193. Tape needs to be attached as 181 for this. You may also put the DDR program at the start of your first backup tape using MOVEFILE: 1. Mount scratch tape and attach it to your machine as 181 2. Do the following commands: REW 181 FILEDEF IN DISK IPL DDRXA S FILEDEF OUT TAP1 (RECF F LRECL 80 BLOCK 80 MOVEFILE IN OUT You may then IPL this tape in your virtual machine for practice or on a real processor. Ivica
Re: PIPE FOR TAKE 3 SPOOL IDS
Or perhaps a JOIN in front of the VAR if you want them all in one variable for displaying purposes.
Re: z/VM RL
Another quick and dirty way to see one spoolid is to enter 'q' (QUERY) command against a spool member. Spoolids and device addresses are both 4 digits long and CP will respond with a device address (spoolid) in a message, wether the device exists or not. Ivica
Re: VM Best Practices
Gary, You can *ask* about best practice, but in this case no one can say what's universally best, not to mention what's best for you. I still think you got some answers and a few examples of what people are doing. It depends on what events do you want to protect yourself against, how quickly do you want your system or its parts back online, how much of the most recent data are you prepared to lose, and how much can you pay. Answers to these questions can lead to DR strategies ranging from a crumpled piece of paper in your pocket to a spare HAL in the orbit (I'm sure he'd support z/VM if asked politely). With the prices of disk storage and comms channels going down, mirroring to another site gained in popularity, but that's certainly not an answer for everyone. With modern disk systems and their fancy features you can make snapshots during the day and be happy with that. All these things said above are, admittedly, as much of an answer for z/VM as for any other operating system. If you are concerned about software failures or failures of z/VM features, then you first need to know the administrative processes of each feature, and that will give you an idea about a recovery process. In general, tape or virtual tape or disk-to-disk backups are your best friends. If you are concerned about CMS application recovery, then checkpoints are your better friends. Nothing new here. Depending on the amount and type of checkpoint data, you may use GLOBALV command, TDISKs, VDISKs, dataspaces, spool files, messages to master virtual machines with databases, and many other ways to achieve this. I, and more knowledgeable people on this list, would really need more specific info from you. Ivica
Re: Old question
If the file went to userid MYID on the second level, then card one is
OK. Maybe it's format of the files? Try using DISK DUMP instead of
second PUNCH or try this:
/* send file(s) to the second level vm */
arg fn ft fm userid . '(' option
if userid = ''
then userid = 'MAINT'
'CP SP PU VM2 CLASS X CONT NOH NAME VM2 PUNCH'
'EXECIO 1 PUNCH (STRING ID' userid
if abbrev('FILELIST', option, 1)
then 'PIPE ' fn ft fm '| SPECS /DISK DUMP/ 1 W1-3 NW | CMS'
else 'DISK DUMP' fn ft fm
'CP SP PU CLOSE'
'CP SP PU OFF CLASS A NOCONT NON'
Ivica
On Fri, Dec 18, 2009 at 9:30 AM, Bob Bates robert.ba...@wellsfargo.com wrote:
Hi all,
I know there are other ways of doing this, but I can't let go of
this now that I've thought about it.
I have a simple 2nd level test system running. I want to send a file
from 1st level to a user on the 2nd level system. I'm trying to use a
process from the dark ages of VM/370.
SPOOL D LEVEL2
SPOOL D CONT
PUNCH PUNCH HEADER A ( NOH
PUNCH THIS FILE A ( NOH
SPOOL D NOCONT
CLOSE D
On 2nd level do a START C and the file goes where it needs. The
question comes about the contents of PUNCH HEADER file:
USERID MYID
:READ THIS FILE
Card one is wrong and I can't remember/find the correct format.
HCPRSR431E says it should be ID MYID or USERID MYID but neither works.
Ideas?
Bob Bates
Enterprise Hosting Services
w. (469)892-6660
c. (214) 907-5071
“This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message. Thank you for your cooperation.
Re: VM Best Practices
Mirroring does not replace good backup tapes: an accidental ERASE or FORMAT is mirrored perfectly well to your DR site. Yes. Mirroring does not make any tape backups redundant, but they do drop to plan B in case of disaster. They remain plan A if you lose a file or a disk and even then FlashCopy and its brothers may give you a quicker solution. They (tapes) are the only plan if you lose both sites. Now, *that* would be a DR test, if someone would pay for it. Secondly: if you simply have a two copy mirror, performing DR tests means you break the mirroring during the test and at that time you no longer have a mirror. Yep. During the test and a few hours after the test until re-sync is done. But those tape backups are still there. Ivica
Re: VM Best Practices
Mike, I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Of course, mirroring makes that much easier, because your DR system is just waiting to be IPLed. You have to send less stuff off-site, a lot of it can be kept on disks. Anything that you may need *before* you bring up VM, and that answers questions where is...? has to be either in the DR manual or in the hardcopy report on the DR site. My recent experience is also with mirroring - two sites running half of production load each, disk mirroring each way. LPAR configs were identical between sites and DR meant logging on one second level VM on each surviving VM(*) and PROFILE and other EXECs would take care of the rest. But I still miss the good ol' days of walking into a DR site and actually *doing something* to restore the system. Oh, wait, maybe I don't. It's just nostalgia. I was just much younger then. :-) Ivica (*) I don't suggest this setup unless you have plenty of storage and zero paging in production LPARs. At least that.
Re: Rookie question z/VM Linux vol and z/OS backup
On Thu, Dec 3, 2009 at 1:48 AM, Scott Rohling scott.rohl...@gmail.comwrote: My experience is that unless you actually do the FORMAT of cylinder 0 -- you 'may' end up with the VTOC issue described. We had a new volume - and just did a LABEL on it -- and had the same issue. We then did the FORMAT of cylinder 0 - and did not. So ever since -- my 'clip' script does a FORMAT rather than just a LABEL - and the issue disappeared. While z/VM seems happy enough just doing the LABEL and using it -- z/OS did not. ICKDSF CPVOLUME LABEL, as well as CPFMTXA ... LABEL, rewrites the volume label *only* and leaves the rest of the label record unchanged. These two commands should be used only on volumes that are already formatted. If the volume was previously initialised for z/OS with ICKDSF INIT, record 3 will be there and you may just update the label, but your VTOC will stay where it is and it can be anywhere. Ownerid surely won't be CPVOL and allocation map won't be there. If you later decide to make such volume CPOWNED without formatting cyl 0, but just doing ALLOCATE, results will still be unpredictable. CPVOLUME FORMAT writes six records into cyl 0, trk 0: IPL, checkpoint, label, allocation, and two VTOC records. IPL record will put the system into a wait state if this volume is IPL-ed and there's no CP; checkpoint record is all zeros and may be used by CP for a warm start; label record will have a pointer to the first VTOC record and CPVOL in the ownerid field, letting CP look for a checkpoint record if it wants to; allocation record will be all PERM; VTOC will look full. CPVOLUME LABEL doesn't do any of this. If you want to use the disk in VM, you should format cylinder 0. If you then copy that disk to a disk of a different size, then you may use LABEL to relabel it, ALLOCATE to update the allocation record, and REFVTOC to refresh the VTOC records with a new disk size (so that z/OS doesn't cry). Ivica
Re: Rookie question z/VM Linux vol and z/OS backup
Sorry for duplicating. I see Alan's and Scott's last e-mails only now. Weird...
Re: What is $$$$$$ and $$$lnx on dirmap
There are also decoder forms on the net, e.g: http://www.motobit.com/util/base64-decoder-encoder.asp On Thu, Nov 26, 2009 at 2:24 AM, P S zosw...@gmail.com wrote: On Wed, Nov 25, 2009 at 12:51 AM, Ivica Brodaric ivica.broda...@gmail.com wrote: Jim, It's text encoding I think. From David's e-mail: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Try to change to Unicode (UTF-8). It shows OK in Gmail with Safari browser set to Western (ISO Latin 1). It's Base64, all right, but it's not something Jim can control. But here's a tip: if you ever really, really want to read a note that's been misinterpreted by your mailer, and you can get the note with all the headers, save them into a file with extension .mm and open it with WinZip. It will un-MIME it. The only thing you won't be able to read (again, assuming you have all the headers) is Microsoft TNEF (which usually appears as winmail.dat). For that, use Fentun (www.fentun.com). Actually Fentun may be able to read the note as well as WinZip does; I haven't messed with it in years.
Re: What is $$$$$$ and $$$lnx on dirmap
Jim, It's text encoding I think. From David's e-mail: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Try to change to Unicode (UTF-8). It shows OK in Gmail with Safari browser set to Western (ISO Latin 1). Ivica On Wed, Nov 25, 2009 at 3:13 PM, Jim Bohnsack jab...@cornell.edu wrote: I use Mozilla Thunderbird as my email program and David's email below is greek to me. If you are seeing it in readable text, let me know what kind of font or viewing option you use. I see a string of mixed case alpha and numeric characters, right and left aligned. Jim David Boyes wrote: DQo+IEkgc3RpbGwgZGlkbid0IGdldCBteSBhbnN3ZXIuIEFyZSB0aGV5IHRlbXBvcmFyeSBkYXNk ID8gDQoNCk9oLCB5b3Ugd2FudGVkICphbnN3ZXJzKi4gVGhhdOKAmXMgZG9vciAxMmIgZG93biB0 aGUgaGFsbC4gVGhpcyBpcyBhcmd1bWVudHPigKY4LSkNCg0KU29ycnkg4oCTIGl04oCZcyBiZWVu IG9uZSBvZiB0aG9zZSBkYXlzLiANCg0KQXMgb3RoZXJzIG5vdGVkLCB0aGV54oCZcmUgcGxhY2Vo b2xkZXJzIHRoYXQgc29tZSBtYWdpYyBjb2RlIGluIHRoZSB0d28gcHJvZHVjdHMgbWVudGlvbmVk IHVzZSB0byBhY2Nlc3MgdmFyaW91cyB0aGluZ3MgaW4gdGhlIENQIGRpcmVjdG9yeSBhbmQgb3Ro ZXJ3aXNlIGRvIHRoaW5ncyB0aGF0IE1hbiBXYXMgTm90IE1lYW50IFRvIEtub3cuIEl04oCZcyBz YWZlIHRvIGxlYXZlIHRoZW0gYXMgdGhleSBhcmUgYW5kIGdvIG9uIGFib3V0IHlvdXIgbWVycnkg d2F5LiANCg0K -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Z/VM 5.4 and VM:Secure running a CLOSED security system
Now that thare's more info, that looks to me like a bug in VM:Secure. If VM:Secure was running without error messages and was never brought down and if it correctly resolved the rules for a user that is a member of a security group only after it left/rejoined the same group, then that is a bug. Changing NORULE in SECURITY CONFIG should work on the fly. I would report it to CA. Ivica
Re: Z/VM 5.4 and VM:Secure running a CLOSED security system
That's correct, and should be investigated, but if there are any other rules that allow this link, then VMSECURE QRULES JHUG LINK MAINT 123 should not tell you that the LINK would be rejected via NORULE DEFAULT. I agree, but if it says that the link would be rejected, then it should be rejected. Something is very wrong somewhere. I see one possible scenario: 1. 'CPACTION * ACCEPT' record in VMXRPI CONFIG (used to generate HCPRPx modules) telling CP to allow everything if the rules facility is not running and 2. Rules facility is not running. If rules are not running, would QRULES command tell you that? Or would it just check the rules database? I would: 1. Run VMSECURE QCPCFG from authorised user (VMRMAINT should be) to verify all CPACTION settings in the currently running CP. 2. Check that VMSECURE userid's directory entry has IUCV *RPI MSGLIMIT 65535 3. Check the VMSECURE console messages and make sure that rules facility initialises correctly. 4. Run VMSECURE RULEMAP USER userid to display all rules that apply to that userid. Run other RULEMAP commands 5. Check all system, group, and user rule files to know what should be happening. 6. Call CA support. Ivica
Re: Z/VM 5.4 and VM:Secure running a CLOSED security system
I may have discovered something regarding a GROUP rule. There are also explicit and default rules for system and groups. Check them all. The rules hierarchy is: 1. Systems rules 2. Group rules 3. User rules 4. Group default rules 5. System default rules 6. NORULE ACCEPT | REJECT in SECURITY CONFIG file NORULE record is processed only if applicable rule is not found in any of the 1-5 above (in that order). Ivica
Re: SFS information
SC24-6074-01 CMS File Pool Planning, Administration, and Operation On Sat, Oct 31, 2009 at 12:51 PM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Hi I want to start using SFS what manuals best describe how to configure and implement SFS fro z/VM 5.3? *Thank You,* *Terry Martin* *Lockheed Martin - Information Technology* *z/OS z/VM Systems - Performance and Tuning* *Cell - 443 632-4191* *Work - 410 786-0386* *terry.mar...@cms.hhs.gov* *WFH on Tuesdays and Fridays*
Re: Modify Command question
You're welcome, Marcy! Yes, it is unintuitive (a lot), but at least you can use one command to change the privilege classes, since it's the only one with IBMCLASS B under QUERY VIRTUAL. If it was put under general QUERY, then using SUBCMD * IBMCLASS B would change more than one subcommand and you'd have to save the status before the change, and undo the collateral damage after. However, that's exactly what you'd have to do now if you wanted to change privilege classes for querying *virtual* addresses. It would be good to name the currently nameless subcommands that represent addresses so that they can be easily selected with SUBCMD, and then put the one representing real addresses under general QUERY, where it belongs. But what do you call real/virtual/logical device address in one name without suggesting it's a name of the operand of QUERY command? Maybe DEVICE? Ivica On Sat, Aug 15, 2009 at 12:53 AM, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Thank you, Ivica! That works. And the help kinda does kinda say to do that. But using the word VIRTUAL to change the REAL rdev command threw me. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivica Brodaric Sent: Thursday, August 13, 2009 9:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Modify Command question cp modify command query virtual subcmd * ibmclass b privclasses bq You have to say VIRTUAL and IBMCLASS B. To check before and after, do CP LOCATE CMDBK QUERY VIRTUAL SUBCMD * and look for two lines with blank as subcommand name (after XSTORE). You're changing one with ibmclass B. Ivica
Re: Console spool?
You make it sound so grandiose. :-) Hmm, yes I went on for a while didn't I? I hope my story was illustrative and easy to remember at least.
Re: Console spool?
q v cons CONS 0009 ON GRAF 6F01 TERM START 0009 CL T CONT NOHOLD COPY 001READY FORM STANDARD 0009 TO LOGARCH RDR DIST HOBBITVM FLASHC 000 DEST OFF 0009 FLASH CHAR MDFY 0 FCB LPP OFF 0009 3215 NOEOF OPEN 0044 NOKEEP NOMSG NAME CONLOG 20090810 0009 SUBCHANNEL = 0003 As Alan already correctly predicted, you have your console spooled CONT (continuous). That means that you want to append multiple files to the same output spool file. It's useful, for example, if you want to print or punch multiple files as one spool member. In the case of console output, CP CLOSE CONSOLE closes one output console file and, since console is still STARTed, a new console file is immediately opened in the same spool member. Spool member will be closed when you issue CP SPOOL CONSOLE CLOSE, and a new spool member will be opened and a first console file in it until you issue CP SPOOL CONSOLE STOP. Ivica
Re: Clean Linux Guest Shutdown
When I issue the shutdown, vm shuts down before most if not all linux guests have responded or completed shutdown; always within a minute or two. Are you using IMMEDIATE operand of SHUTDOWN command? IMMEDIATE doesn't mean now, it means without sending any signals. Ivica Brodaric
Re: Packing Methods
If your main concern is impact on users and you have a speedy link between the sites, then by all means use hardware compression only. If your link is slow or there is other traffic on it, you may consider software compression and then muzzle the backup application using priorities etc. I personally prefer hardware only, wherever possible. Although software+hardware compression produces less tapes, both backups and restores may still take longer regardless of CPU availability (YMMV). Also, if you are prepared to waste CPU cycles just because you can (e.g. nothing else is running), be mindful that job schedules may change... Ivica
Re: Dirmaint Broken?
Valerie, How did you update the size of MAINT 123? Using GET/REPLACE or using DMDISK/AMDISK? If you used the latter, then maybe you forgot to use KEEPLINKS operand of DMDISK. Without that, a LINK to MAINT 123 in DIRMAINT's (and any other) directory entry would be deleted when you delete MAINT 123. Ivica Brodaric
Re: Private Subnet for Hipersocket connections
All I know is that my network folks tell me they can't give me anything more than a few class 'C' subnets and those require justification. Sounds like a standard, prudent, response from the Networking People - never give away too much of what you have too easily and never give an impression of having too much of something to give in the first place. :-) How many hipersockets do you have? You'll probably want one class C subnet per hipersocket, but depending on the number of hosts connected to the hipersocket, that might be a waste of addresses. Even if they give you only one class C subnet, you'll get 256 addresses which you can then divide into smaller subnets and use each of those for a particular hipersocket. Ivica Brodaric
Re: Is there a usable XEDIT FIND ?
Use LOCATE as previously mentioned, or just a forward slash followed by a search string. Also look at ALL, which would show you all lines containing a search string. Check out SET ZONE as well. Ivica Brodaric
Re: IPGATE not creating CONNECTion to a DB2/VM server
Try increasing MAXCONN value in CSIDB202's directory entry. 48 can be enough for a DB2 server. However, by introducing IPGATE and its APPC/VM connections, you might just be unlucky to hit that limit. For a SFS server, you'd monitor the high watermark for the number of connections with QUERY FILEPOOL OVERVIEW, but I don't know which DB2/VM command would reveal this. Ivica
Re: Shark Retiring
To speed things up, you may also define primary and secondary pairs before you run ICKDSF with ERASEDATA. That will ease the load on the channels (or halve the time required to erase everything) and make the subsystem do extra work for you. Then maybe break the pairs, swap the primaries and secondaries and rerun the erase. You may even define multiple secondaries for the same primary, but I'm not sure if you can do it on the Shark. Ivica
Re: Shark Retiring
Then maybe break the pairs, swap the primaries and secondaries and rerun the erase. To be clear, break the pairs only after they are fully synced. Ivica
Re: Shark Retiring
A process like rewriting data with different patterns is modeled after traditional technology. We know at least of some DASD subsystems where the remaining 24 rewrites would not cause writing at the same location on a disk, and thus not achieve what you meant to do. Those funny patterns tend to compress very well and thus may postpone rewriting the actual data for quite some time. These devices also implement different RAID levels which may have implications w.r.t. traces of data remaining in the subsystem. If you have a modern DASD subsystem and you want to throw it away, then you may want to remove the disk drives and destroy them or have them destroyed. It's quick and easy to verify. If you want to get a good price on the second hand market for your subsystem, then obviously you will include the drives, but then you first have to do whatever *you* can to destroy the data before trusting somebody else with it. SE will tell you that (s)he can delete the LUNs (maybe you can do that too), RAID groups etc. and that it is impossible to recreate them by avoiding the format function and in a way so that they point to the same bits of data scattered in random locations on hard drives and cache in exactly the same sequence so that they resemble your DASDs in the end. And (s)he is probably right, but the bottom line is your data is still there unless you wipe it off and SE will be reluctant to spend hours running some low level utility (which I'm sure they have) to erase the disks, especially if they are not paid to do so. So, run your ICKDSF's as many times as you can from as many worker machines as your channels permit and then convince the SE to do everything (s)he can to destroy the data. Other than that, and since the original question was about Shark, use IBM's service mentioned above if you can afford it. Ivica
Re: Shark Retiring
On Mac OS X's Disk Utility there are Secure Erase Options and under a 7-Pass Erase it says that it meets the US Department of Defense 5220-22 M standard for securely erasing magnetic media. There is also a 35-Pass Erase option with no standard attached to it. I always wondered why is it there... Hmmm... But let me get a calculator to find out how long would that take... Umm, no, I'll need a calendar. A 10mm drill bit cuts through the plates like a butter. 10 seconds tops. Easy to verify too. They can look through my data now! I guess a bullet would be ever faster, but a bit harder to implement on site. Collateral damage might not be acceptable to the neighbours. And it's a piece of technology after all - drilling it is like an euthanasia... When is Friday??? Ivica
Re: MAXCONN
It depends on the application. The fact that you can is no guarantee the application will. Understood. I mentioned IPGATE only as a way to prove the idea in case if Richard is still in the planning stage only and doesn't have his own application ready for testing yet. As he said that he has the control of the EXEC that creates the sockets, I presume that he would know how those sockets are opened. IPGATE does open an IUCV connection for each local resource, but those connections count towards IPGATE server machine's MAXCONN number, not the TCPIP machine's MAXCONN, which is what Richard is concerned about. IPGATE does only one socket initialize, and then uses one additional socket for each active remote user/local resource pair and one additional socket for every defined remote resource, if I understand it correctly. I just thought that this could be used as a test case. Ivica
Re: MAXCONN
If you are worried about MAXCONN in general, RSCS LPR links use one IUCV
link to the stack each.
For applications, check IPGATE if you have it. It does only one
socket('INITIALIZE') in the top level routine, but creates new sockets for
each userid/APPC resource pair. According to previous post, it should use
only one IUCV link to the stack.
Ivica
On Fri, Oct 3, 2008 at 2:08 AM, Schuh, Richard [EMAIL PROTECTED] wrote:
What consumes the connections specified in the MAXCONN option of the
TCPIP machine's directory? Does each open socket consume 1 connection, or is
it 1 connection for each guest that opens 1 or more sockets?
Regards,
Richard Schuh
Re: LOGONBY
So if I understand LOGONBY it simply allows a user to logon to lets say TCPMAINT using the user's own PASSWORD. Does this mean you still use TCPMAINT as the userid? That's correct. LOGONBY will let a user logon to TCPMAINT using his own userid and password of his own userid (the command will be LOGON TCPMAINT BY userid). That will leave an audit trail of *who* logged on to TCPMAINT and when. But the main advantage of LOGONBY is that user does not need to know TCPMAINT's password. That also means that you can change it without having to tell anyone about it. If you set *yourself* with LOGONBY to all system-type userids, you will not have to remember multiple passwords, just your own. Then, you can even let your ESM generate random passwords for userids like TCPMAINT, because you don't really have to know it either. NB, don't do this (random passwords) until you are comfortable with LOGONBY. Just don't tell anyone about the passwords. Ivica Brodaric
Re: Network-SLES10
it is about the only place where the real and virtaul nomenclature goes backwards. Weird. We always used to speculate that the DEDICATE statement was written by a Waterloo co-op on a work term. Long ago and far away. David Let me guess - they first wrote DEDICATE and tried to conform to the rule of having the virtual address as a first parameter, but after they heard the roar of sysprogs, they left the LINK the way it is. :-) Ivica
Re: WAIT STATE
CMS knows about the formatted section of the disk, as Alan explained above. However, don't get cocooned into thinking that CMS knows everything. It certainly doesn't know that you made an error. If you went to reformat that disk with CMS's FORMAT command, you would have destroyed not only the intended portion (in your case 120 cylinders) but all 158 cylinders that you defined as a size. That means that you would have reformatted the first 38 cylinders of a minidisk that follows MAINT CF1 (which is probably MAINT CF2) and you would not know it until you IPL that system and try to access the MAINT CF2 or do QUERY CPDISK and see that MAINT CF2 is not on the list. So, in this respect, you *were* lucky. Ivica Brodaric
Re: Partially Successful: OpenVMS on System z
**grin** Anybody interested? It could get me my job back! :-) I was dumped together with the IBM boxes (well, not at the same time, to save me from the impact) when my employer was taken over by another company which ran similar applications on OpenVMS. Sadly, they then outsourced the operations to EDS (HP), so I don't think there could be an IBM sale there. But you never know... Ivica
Re: VMFTP Return Code -5
OK, so you are running active FTP, no firewalls, your macros always get the connection and successfully do CWD. In that case, apart from looking at the FTP server's log (a good suggestion I sadly didn't think of), you may also setup a packet sniffer and filter all traffic between server's ports 20-21 and client's IP address. Find a failing session and a working one by timestamp. Compare the results. Look for the order of the packets before the first data block is sent. Check that the ACK's are in proper place, etc. This is a bit laborious, so start with the server log. Packet trace may come handy if you open a PMR. Ivica Brodaric
Re: VMFTP Return Code -5
I mean, if you don't get a connection, then RC -5 on PUT would be correct. Could this be the case? Ivica
Re: Dirmaint Mdisk Allocation
Maybe you have them as 3390-03 in REGIONS section and 3390-3 (no leading zero) in DEFAULTS? I think they must match exactly or it will take the size of 3390 as defined in DEFAULTS. Try changing the default size for 3390 to 3339. Ivica
Re: Portable z/VM help?
And I did get used to the improved layout of the PDF books. -Rob I use PDF format for longer reading, BookManager format for quick search. If you download whole bookshelves, they come with bookshelf indexes which let you search even multiple bookshelves pretty quickly. Mind you, I just went to open a PDF file from within Softcopy Reader and it resorts to command window both on Win XP and Vista. Obviously, something is broken there (it used to work, scout's honor!). Maybe no support for Acrobat 9? Ivica
Re: Portable z/VM help?
Have a look at IBM Softcopy Librarian and IBM Softcopy Reader (both free): http://www-306.ibm.com/software/applications/office/bkmgr/librarian.html http://www-306.ibm.com/software/applications/office/bkmgr/softcopyread.html You need Windows with Java for both. The Librarian lets you download (or import from CDs) and maintain the manuals in repository on your PC (and copy or sync that repository to a network location), while Reader lets you search and, well, read them. Both support manuals in BookManager and PDF format. I keep everything I might ever want for multiple releases of operating systems and accompanying products on my laptop and it's indeed well worth the space. BTW and OT, both these products being in Java and Softcopy Reader having a Linux version as well, one might hope there would be a Mac version at some time in the not too distant future. But then again, one may always be hopelessly naive and optimistic... Ivica
Re: cp_owned .v. user_volume
CP will, mercifully, not allow you to DETACH the CP OWNED volumes from SYSTEM. You can DETACH all other volumes if there are no active links to them. Also, if you have a guest that wants to attach some disks by virtue of DEDICATE directory statement, that guest will like those disks FREE, so you may want to exclude them from the user volume list or detach them from SYSTEM by some other means before the said guest comes up. If you want to keep your user volume list simple, you can do the detach work in AUTOLOGx user for example. Ivica
Re: HiperSockets
You can use the same address triplets in all LPARs. In other words, you can use all 24 addresses in every LPAR. If you have more than one connection to the CHPID from within the *same* LPAR (e.g. VM's TCPIP stack and LINUX guests), then, of course, you must use different triplets there. In z/VM, you can still attach, for example, E000-E002 to TCPIP and then other triplets (E003-E005, E006-E008, ...) to LINUX guests always as virtual E000-E002. That may make LINUX duplication easier. Ivica
Re: z/VM IPL
What did you put in Operator_consoles in SYSTEM CONFIG? That defines where will you get the first messages after the IPL. You have to give us a bit more than it doesn't come up. There are many things in VM that may or may not come up depending on how you configure it. When you say remotely I assume you mean that you are accessing VM through TCPIP and you are not getting a signon screen. Did you put 'XAUTOLOG TCPIP' in PROFILE EXEC of AUTOLOG1 user? If you didn't, TCPIP stack will not come up. That's just one thing that may not come up. Which reader files were you going through? How can you possibly go through reader files if the system didn't come up? Ivica
Re: z/VM IPL
Are you sitting in front of a PC with terminal emulator or a local terminal? If you are using a local terminal, put 'CP ENABLE ALL' in PROFILE EXEC of AUTOLOG1. But, in any case, describe us the problem a bit more. Plain words are fine. And don't worry, no problem is too big or too small for us. :-) Ivica
Re: z/VM IPL
OK, so TCPIP didn't come up? Logon to TCPMAINT user and inspect its reader files. That's where the TCPIP's console goes by default.
Re: Adding Paging Dynamically
WARM start will be fine as long as you didn't change the order of disks that contain spool areas. To get the list of all disks that contain spool areas the way the running system sees them, do CP Q ALLOC SPOOL. If you changed the order of disks that contain spool areas, the safest way to go is to backup the spool with SPXTAPE DUMP, do CLEAN start, restore the spool with SPXTAPE LOAD and re-IPL the system. COLD start erases all ordinary spool files but leaves SDF files which you don't want to lose. If you change the order of the spool packs, doing COLD start may not save you - you can still lose some SDF files and Murphy's law says that CMS NSS will be one of them. CLEAN start erases everything and, if you are in a hurry, you *have* to restore at least SDF files (use SDF option of SPXTAPE LOAD) and re-IPL to have the system the way you know it. You can then restore the rest of the spool (RDR, PRT and PUN files) at your leisure. One more word of warning: immediately after CLEAN start, you will not have CMS NSS, so you will not be able to IPL CMS anywhere. Use IPL 190 instead. Ivica
Re: Question on how RSU maintenance is being handled with DIRMAINT and RACF in the picture
In order to be more democratic and accommodating, we could have a CANCEL button that said: CANCEL not allowed. You must press OK. Press CANCEL to press OK. Press OK to CANCEL the CANCEL and then press OK. Maybe expand the choice with one more option: If you still wish to press CANCEL to NOT press OK which cancels the CANCEL and presses OK, contact your Systems Programmer. :-)
Re: Presenting Additional ECKD devices to Linux Guest Dynamically
You cannot LINK real DASD but you can ATTACH real DASD as a virtual address to your Linux guest. You can run LINK command from your guest and ATTACH command from any authorised user (normally a user with a privilege class B; MAINT normally has that authorisation). Both LINK and ATTACH commands will survive Linux re-boot but not LOGOFF of your guest virtual machine. To make things permanent, you have to add a LINK directory control statement (to make LINK command permanent) and DEDICATE directory control statement (to make ATTACH command permanent) to the user directory entry for that guest and then compile the directory and bring it online using a method implemented on your site (DIRECTXA, DIRMAINT, VM:Secure, ...). Be mindful of the order of operands for DEDICATE - it's DEDICATE vdev rdev, i.e. the reverse of what you specify for ATTACH. Ivica On Sun, Jun 1, 2008 at 1:56 PM, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: Hi Alan, Thanks for the info. One other question. Can I LINK the real DASD device address AS a virtual address? LINK * 513D 800. I asked this because up to this point I have presented the DASD to the Linux guest via the USER DIRECTORY entry as VIRTUAL addresses so I would like to stay consistent when I LINK them dynamically while the guest is active. If the guest is re-booted will the LINKED DASD is be there after the re-boot or would I need to re-LINK? Does it matter whether I issue the LINK via the MAINT user or does it have to be done from the guest itself? This is my first attempt at z/VM and z/Linux so if the questions sound elementary until I sort this all out, I apologize. Thanks, Terry -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Saturday, May 31, 2008 10:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Presenting Additional ECKD devices to Linux Guest Dynamically On Sat, 31 May 2008 15:29:56 -0400, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: Hi I am running z/VM 5.3 with a RedHat 4.6 z/Linux (Kernel level 2.6.9-67) guest. I need to give this guest some more ECKD DASD. I want to do this dynamically. As far as I knew to accomplish this I should only need to add the devices to the User Directory bring that new Directory online (DIRECTXA USER). At this point on the Linux side they need to do some things to see the new device. Updating the directory for a virtual machine has no effect on the virtual= machine, until the virtual machine is next logged on. For a virtual machine that is already logged o= n, you will have to log off and log back on again. If you want the virtual machine to stay logged on, you can either ATTACH = the device to the virtual machine, or ATTACH it to SYSTEM and then LINK to it from the virtual mach= ine. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Presenting Additional ECKD devices to Linux Guest Dynamically
There is another way of making things permanent - through PROFILE EXEC, but I suggest you stick with the directory for these commands. Also, if you are new to VM, I suggest you stick with minidisks - they are so much more convenient that you have to have a good reason to use dedicated DASD. When you attach a real DASD to a user, then only that user can use it and it doesn't appear in DIRMAP listing, so you'll have to remember that that disk belongs to a Linux guest. There are however some performance benefits in using dedicated DASD (no cylinder address translation plus I/O assist), but if you have fast DASDs with lots of cache in the controller, which is common these days, you won't see the difference, especially if you use minidisk caching on top of that. Dedicating DASD can still make sense for a large production z/OS or z/VSE guests where you want to extract the last drop of performance, but for Linux guests, IMHO, there's not much point unless you have a huge (multi-disk) database or something like that. If you want to give a Linux guest a whole-DASD worth of space, I suggest you attach it to SYSTEM, define the cylinder 0 as a minidisk belonging to $ALLOC$ user (to avoid accidental overwriting of DASD volume label) and the rest of the DASD as a minidisk belonging to the Linux guest. To attach the DASD to SYSTEM at VM IPL time, the DASD volume label has to be included in user volume list in SYSTEM CONFIG. Cheers, Ivica
Re: Real device number assignments
2 CECs, both having their local DASD addresses in 6000-6FFF range, and remote (the other CEC's) ones in 7000-7FFF range. Ivica
Re: Console Messages Problem
I think it was related to a problem we are having with the operator terminal. I am having the terminal replaces. Try PROP (Programmable Operator). It runs disconnected (and collects all messages and may automatically act upon them). Ivica
Re: Hipersockets - xposted to VM-L IBM-Main
Maybe you are not even using port name on z/OS. I don't know much about z/OS, so I cannot help you find it, but even if you are not using port name in z/OS, you have to be sure that nothing else comes up before the z/OS guest, connects to the hipersocket and changes port name from nothing into something.(1) Did you check your z/VSE stack for a port name? (2) Did you have a chance to reset the hipersocket CHPID (vary off the CHPID from all LPARs *at the same time*, then vary it on to all)? I remember that on z800 hardware port names could differ in one character out of eight (but one only), and microcode check would pass. Eg, port names HSOA1 and HSOB1 were OK, but not HSOB2. Later on I found out that this is in fact how it worked. This applied both to hipersockets and OSA's. From z990 onwards, this slack was removed and from then on all port names must be identical or not used at all. So, if you don't really need port names (and z/VM allows you to not use them from release 4.4 onwards), this exercise of removing them is well worth your while. And if you do (1) and (2) above, you will at least be sure that port name is *not* your problem. Then, we'll dig deeper. Ivica On Tue, May 27, 2008 at 10:28 PM, Mark Pace [EMAIL PROTECTED] wrote: Sorry for the late reply, I've been on vacation. (some of you may remember those). I do not see where you would specify a port name on z/OS. I've tried to remove the port names from the z/VM definitions, but thus far it has not made a difference. On Tue, May 13, 2008 at 3:32 AM, Alan Altmark [EMAIL PROTECTED] wrote: On Monday, 05/12/2008 at 01:53 EDT, Stephen Frazier [EMAIL PROTECTED] wrote: My recollection is that the port name must be the same everywhere or absent everywhere. Try removing your port names and see if that works. Port names are meaningful to z/OS, not Linux or z/VM. It is ok if some are using port names and others are not. If you are using port names, then all users must have the same port name. First one in wins. Alan Altmark z/VM Development IBM Endicott -- Mark Pace Mainline Information Systems
Re: Hipersockets
Alan, A mismatched port name on an OSA creates an initialization error. Correct, but with a caveat explained in the other thread (yes for z990 onwards, before z990 one character could mismatch. I know it sounds weird, but that's the way it worked) In any case, HiperSockets do not have port names. Ummm, no. They can be specified for HiperSocket connection in DEVICE statement in VM and in DEFINE LINK statement in VSE. And after peeking into some z/OS manuals, I found that even z/OS is not oblivious to port names. From z/OS V1R9.0 Communications Server IP Configuration Guide: quote Therefore, there are two types of HiperSockets devices: - DYNAMICXCF HiperSockets device or interface (TRLE IUTIQDIO and an MPC group of subchannel devices). The PORTNAME will be IUTIQDxx, where xx = the IQD CHPID that VTAM(R) uses (for example, IUTIQDFD when using IQD CHPID x'FD'). - A user-defined HiperSockets device or interface (TRLE IUTIQDxx and an MPC group of subchannel devices). The PORTNAME is not applicable for this TRLE. In both cases, the TRLE is dynamically built by VTAM. end quote I presume that we have a user-defined HiperSocket here, but in the response to Q LAN DETAILS command for the virtual LAN that Mark defined to test the connection to the VM stack via virtual HiperSocket there is a following line: Adapter Owner: ZOS19NIC: 0724 Name: *IUTIQDFF* That Name: at the end is port name (not device name). If the portname was not used by z/OS, it should've said Name: UNASSIGNED. So which one is it? DYNAMICXCF or user-defined? And why did it work anyway? Maybe virtual HiperSocket is more lax towards the port names than real HiperSocket, because Mark says that the connection over the virtual HiperSocket worked. I also do not want to overly emphasize this port name thing, but I still think that it is worth while clearing. I think Mark said that he copied z/OS from the LPAR to a guest on VM, changed the home IP address and attached the real HiperSocket device trio to z/OS guest as the same addresses that z/OS expects. So I don't think that we will get any further by doing that again, except that this new copy of z/OS will be unmodified. Maybe still worth a try... Your point 1 seems to be in contradiction with the quote above, but I'll believe you have your reasons. Your point about MFS and MTU is great. I can't see nothing wrong in NETSTAT HOME and NETSTAT GATE responses provided in the other thread, but I noticed there that packet size is 57344 (56K) for IUTLNK1 link. How does that work? Does z/OS automatically adjust the MTU of the interface when the device is activated? This would indicate that CHPID is defined with OS=C0 (64K MFS). Mark, when you defined a virtual HiperSocket, you used default MFS of 16K as I see in QUERY LAN response. Try with MFS 64K operand in DEFINE LAN. Just to remove any difference between the real and virtual HiperSocket... Ivica Brodaric
Re: Hipersockets - xposted to VM-L IBM-Main
On Tue, May 13, 2008 at 5:32 PM, Alan Altmark [EMAIL PROTECTED] wrote: Port names are meaningful to z/OS, not Linux or z/VM. It is ok if some are using port names and others are not. If you are using port names, then all users must have the same port name. First one in wins. Which means - if z/OS LPAR connects to hipersocket first (not using port name), then z/VM connects next (using port name XYZ), then z/OS guest (which may be an image copy of z/OS in LPAR) will have to use portname XYZ. Right? There is also z/VSE guest on the diagram provided in another thread. z/VSE's stack (at least if it is a CSI stack) can also optionally specify port name on the DEFINE LINK statement. AFAIK, there is no way to query the current port name for the real hipersocket and no way to reset it to nothing. So, to clear this, detach all connections from the hipersocket, define them all without port name (or with the same port name if you insist), vary off the hipersocket CHPID from all LPARs, vary it on to all LPARs and reconnect all stacks.
Re: Hipersockets - xposted to VM-L IBM-Main
Does anything that connects to hipersocket (or your OSA, which you say has a similar problem) set a portname through DEVICE statement? PORTNAME is not required since z/VM 4.4 (or 4.3 with a PTF and a certain microcode level), and I see you are on z/VM 5.2 and you don't use it on DEVICE statement in z/OS, but maybe something else sets it? If it does, I *think* you still have to use same portname with any subsequently activated connection to that shared adapter (hipersocket or OSA). That said, the fact that hipersocket device *does* initialise in the guest z/OS is confusing, but I don't know much about z/OS. Ivica Brodaric
Re: The list it to quiet, here's something to work on.
The statement if m d=2*2*2 3*3*3 then do; works because multiplication is higher priority than concatenation which in turn is higher than comparison. And, of course, multiple blanks between two expressions evaluate as concatenation with a single blank between. Order of precedence in REXX is: prefix, power, multiply/divide, add/subtract, concatenation, comparison, and, or/xor. Ivica Brodaric
Re: Impromptu XEDIT Survey
I like it on the right. I can concentrate easier that way. And the command line on top... :-) Ivica Brodaric
Re: How comments treated by DIRMAINT
DIRMAINT groups all LINKs first, MDISKs next. What makes it do it and can this be disabled, I can't remember. Possibly SORT_BY_DEVICE_ADDRESS in CONFIG DATADVH. I found the following in DIRMAINT's Tailoring and Administration Guide (SC24-6135), chapter 3.13 (this is how it treats USER INPUT file. Read Note 1): --- Comments in a non-System Affinity source directory (a directory that does not use the SYSAFFIN keyword in its internal form) must follow the directory statement to which they apply. DirMaint will re-order the sequence in which directory statements are placed, keeping comments associated with the previous real statement. For example, given the following directory segment: MDISK 0197 3380 DEVNO 00AF . * This comment is associated with the MDISK 0197 statement. * So is this comment. MDISK 0191 3380 DEVNO 00AA . * This comment is associated with the MDISK 0191 statement. * So is THIS comment. After the directory is manipulated and sorted by address (a selectable option) the same directory segment will appear as follows: MDISK 0191 3380 DEVNO 00AA . * This comment is associated with the MDISK 0191 statement. * So is THIS comment. MDISK 0197 3380 DEVNO 00AF . * This comment is associated with the MDISK 0197 statement. * So is this comment. Notes: 1. When DirMaint removes any directory statement, the comments that follow that statement are not removed. This may be of particular interest when processing a CMDISK command, as the MDISK is transferred to the DATAMOVE machine (removing it from the user's directory) and then transferred back to the user (but not associating it with any set of comments). 2. Blank lines are treated as comments and follow all the same rules. Ivica Brodaric On 16/02/2008, Horlick, Michael [EMAIL PROTECTED] wrote: Ok, will do. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: February 15, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: How comments treated by DIRMAINT On Friday, 02/15/2008 at 10:10 EST, Horlick, Michael [EMAIL PROTECTED] wrote: The line ?LINK QALPCS 0500 0500 MW? has been shuffled after the comment line ?* 360 - ZYZMGH (Master Catalog, Power, Hardcopy,Recorder,etc...)? So what?s the secret here? I would suggest opening a PMR and getting people In The Know to help you. Alan Altmark z/VM Development IBM Endicott
Re: wakeup (iucvmsg never receives output
Try 'WAKEUP +00:00 (IUCVMSG' just before 'CP SPXTAPE...' That sets the diversion as Rob already suggested. Add 'WAKEUP RESET' after the end of loop. Ivica
Re: wakeup (iucvmsg never receives output
Yes, thank you Ron, 'WAKEUP +0 (IUCVMSG' just does CP SET MSG IUCV and WAKEUP RESET puts it back to ON. To trap other stuff, you do need to explicitly set it (and maybe IMSG/EMSG would be enough in this case). But Phillip has to set those traps before the SPXTAPE command. And BTW, Phillip, WAKEUP always returns one message at a time, so there's no need for queued(). Also, you may want to do 'CP SP CON * CL x' and 'CP SP RDR CL x' and then instruct WAKEUP to wait for reader files as well. SPXTAPE's log files have distinctive filenames and go to wherever your console is spooled. Ivica On 14/02/2008, Ron Schmiedge [EMAIL PROTECTED] wrote: I wrote an exec to run on a disconnected service machine to dump the VM spool. It was a while ago, but I see I did a CP SET CPCONIO IUCV before the wakeup (iucvmsg loop. And a CP SET CPCONIO OFF before the wakeup (reset at the end of the loop. I am sure I read about this technique somewhere, perhaps in the wakeup documentation. But it was written quite a while ago and I tend to remember less these days On 2/13/08, Ivica Brodaric [EMAIL PROTECTED] wrote: Try 'WAKEUP +00:00 (IUCVMSG' just before 'CP SPXTAPE...' That sets the diversion as Rob already suggested. Add 'WAKEUP RESET' after the end of loop. Ivica
Re: PUT2PROD Error
Your problem is here: ST:BLDSEG : DMSGEN1279E Error(s) occurred during SEGGEN processing. ST:BLDSEG : VMFBDS1965E The command, SEGGEN HELPSEG PSEG A SYSTEM SEGID ST:D2 ( NOTYPE, failed ST:BLDSEG : with return code 32 Return code 32 from SEGGEN is not very helpful (and neither is NOTYPE option). It could be many things, but my first guess would be that you don't have current SYSTEM SEGID file on MAINT 490. If you rearrange segments, you must always copy SYSTEM SEGID file to *both* MAINT 190 and MAINT 490. Second guess is that 'HELPSEG PSEG A' file is not on BLDSEG's A disk (is it full?). Ivica
Re: How comments treated by DIRMAINT
On 13/02/2008, Huegel, Thomas [EMAIL PROTECTED] wrote: I am amazed that so many people here still use 80 column '3270's.. My diopter is -4.25. What's yours?
Re: How comments treated by DIRMAINT
All in all, maybe the 80-col 3270 **isn't** such a bad thing. No, it's not. I find it hard to read anything on model 5. My weary eyes go slowly from right to left and often hit the wrong spot. And having XEDIT prefix area on my preferred right side, it's just too far away. Model 3 is to my liking. And hallelujah to the good old 3278's (although you had to keep typing while lying on the floor if you dropped them). :-) Ivica
Re: How comments treated by DIRMAINT
And when entering XEDIT ALL commands, the comments appear with the displayed statements, rather than being on a hidden line before or after the displayed record. (Personally, MINIOPT has always bugged me). Me too. The cure: Z 1 1#ALL /M/ Granted, the comments can be a little far to the right of an 80-byte wide the screen, but XEDIT's SET VERIFY 1 * takes care of that pretty easily. Hmmm, followed by SET TRUNC, SET ZONE (even SET LRECL) if XEDIT PROFILE doesn't take care of that correctly. I personally dislike lines spilling on to the next line on screen given that SCALE doesn't spill. I hate when my text gets cut off in that hard-to-calculate column in the second line. F 80 is just fine for me. Ivica
Re: How comments treated by DIRMAINT
I never meant this to be top of the list for IBM Development. There are more pressing issues, of course. But it just annoys me that in this day and age (yes, I'll use that phrase) all we have to describe a minidisk using whatever we want to put in there is a minidisk label (apart from address, of course). Not to mention other devices that don't have that 6-character luxury. Sooo 1960's, which may be a good thing (but so was Y2K, for my back pocket). I mean, what does TCP191 tell you? Is it TCPIP or TCPMAINT? I won't even go to TC0191. And how many times did we forget to change the label after changing the minidisk address? Q MDISK was invented because Q DISK couldn't tell you enough and was possibly telling you the wrong thing. So why not give us a bit more that we can change *at the same time* when we change something in the directory? I don't care if that comment or device name is in the directory or CP gets it from somewhere else (but where else?). Not putting rubbish in those comments would be just a matter of common sense which you can't rely on, but if one wants to put something stupid like a URL of MP3 of disk spinning in that field, so what? The advantage of being able to name a disk CMS Apply Level n to a newbie (and even to me, considering a rate of my brain cell depletion) overweighs that. And I can think of much worse ways of bloating the directory like not using profiles where you can. I would also like to see it added in CP DEFINE. Call it DEVDESC or DEVNAME, or whatever. One has to be careful though not to introduce an ambiguity in design, so that applications and guest OSs of the future don't hijack it for their own selfish purpose (you can put anything in this field unless you use XXX, in which case it has to be structured). I'd hate to see /LINUX SWAPFILE MAKEONCE or ;TCPIP MAILME WHEN DEAD as device description. But that could even be a feature, depending on your view. We already have RSCS... Again, this is not very important, but could open some new doors in the future and make our VM a bit more modern and palatable to newbies. Ivica Brodaric
Re: How comments treated by DIRMAINT
5. Make the syntax similar to the one in SYSTEM CONFIG6. Integrate it into SYSTEM CONFIG via INCLUDE and keep the source directory on PARM disks. 7. Define the DRCT space in SYSTEM CONFIG the way warmstart and checkpoint areas are 8. Provide compile/nocompile option or a checkpointing system that would not compile the directory at every IPL but would if the system is brought up on a disaster recovery site. I could go on. That would be NICE. But that would be quite a sweeping change. I was arguing for a special comment statement just for MDISK because I think that is the statement that cries for comment option the most. If I ever put any comment into the directory, then if it is not to do with the userid itself (which is already catered for by *) it is most likely to do with MDISK. I would also like the minidisk comment statement to immediately precede MDISK, not follow it. Plus your ideas 2 and 3. I would like the comment to be query-able. I can imagine many situations where it would be very useful and reassuring. Ivica Brodaric On 11/02/2008, Alan Altmark [EMAIL PROTECTED] wrote: On Saturday, 02/09/2008 at 01:15 EST, Ivica Brodaric [EMAIL PROTECTED] wrote: How about adding COMMENT parameter in MDISKOPT? Or even MDISKC statement? Yes, it would reduce vertical readability, but there is not much space in the MDISK statement and if you introduce asterisk, semicolon, or any other character as a start of comment, you'd have to make sure you don't have any passwords that look just like that. And if you use ESM that does password encryption, you might have a password that in encrypted form looks like asterisk. If you're going to propose changes in directory syntax, why not go all the way? 1. Add a COMMENT statement that applies to the most-recently encountered non-COMMENT statement 2. Compile it into the object directory 3. Provide a way to extract the comment (e.g. QUERY VIRT 190 DETAILS) 4. Eliminate the F 80 requirement. Alan Altmark z/VM Development IBM Endicott
Re: How comments treated by DIRMAINT
Then you have never set up guest crypto. :-) I no speak English. :-) Unlike you, I have tended to have far more comments on LINKs than on MDISKs, since I care more about *why* a user is linking rather than *what* is on the disk. OK, LINK is crying too, but less so because it has more free space than MDISK MINIOPT already established the precedent of a statement that adds information to the previous statement. It was my intent to keep that model, but provide a more generally useful function. Further, I most especially didn't want to compromise the syntactical integrity of existing statements. I agree. I suggested preceeding to visually distinguish it from MINIOPT, but if you want to provide a general COMMENT statement tied to any preceeding statement, I'm all for it. As to QUERY MDISK, it could be done of course, but QUERY VIRTUAL has the advantage of being able to handle all virtual devices, not just MDISKS. Again, I'm all for it. I was (maybe naively) going for a minimum effort, and response to QUERY MDISK has a lot of free space. Ivica Brodaric
Re: How comments treated by DIRMAINT
How about adding COMMENT parameter in MDISKOPT? Or even MDISKC statement? Yes, it would reduce vertical readability, but there is not much space in the MDISK statement and if you introduce asterisk, semicolon, or any other character as a start of comment, you'd have to make sure you don't have any passwords that look just like that. And if you use ESM that does password encryption, you might have a password that in encrypted form looks like asterisk. Ivica Brodaric
Re: z/VM Installation from DVD
I KNEW someone's going to say that and I do use address COMMAND, but -
obviously not in this exec. I was going to insert it now to prevent the
backlash, but since I don't have a system anymore to test the exec, I
decided against it.
Ivica Brodaric
On 08/02/2008, Kris Buelens [EMAIL PROTECTED] wrote:
Nicely formatted REXX, quoted what need to be, CP commands targeted
directly to CP. But. Where is the ADDRESS COMMAND? And why use
PIPE CMS instead of PIPE COMMAND? Running with ADDRESS CMS and PIPE
CMS are two loaded guns too.
Why: read our free Telecourse
http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1
--
Kris Buelens,
IBM Belgium, VM customer support
2008/2/7, Ivica Brodaric [EMAIL PROTECTED]:
Chris,
Since you are a VM newbie (welcome!) I thought I might give you a simple
DDRCOPY EXEC so that you are all set. I found one in my archive. Exec
doesn't use minidisk passwords in LINK commands, so put OPTION LNKNOPAS in
SYSDMPPR profile or work around it (depends on your security requirements).
This exec uses another disk for backup. If you want to use a tape as output,
you need to replace the second LINK command with ATTACH command for the tape
drive, modify OUTPUT subcommand of DDR and replace 'COPY ALL' with 'DUMP
ALL'.
One warning: This is a loaded gun. Please be careful with those
target_addr parameters in DMPn EXECs previously mentioned. Maybe tell
your co-worker to read them aloud for you in a melodic voice after you did
the same. ;-)
/**
*** Function: Copy a minidisk with DDR
**/
arg userin addrin userout addrout disktype rest
if rest ^= ''
then do
say 'Invalid parameter:' rest'.'
exit 3
end
if disktype = ''
then disktype = '3390'
if addrout = ''
then do
say 'Missing parameters.'
say 'Format: DDRCOPY userin addrin userout addrout disktype'
say '3390 '
exit 4
end
'CLRSCRN'
'MAKEBUF'
'GETFMADR'
if rc ^= 0 then exit rc
pull . fm1 addr1
'DROPBUF'
parse value diagrc(8, 'LINK' userin addrin addr1 'RR') with rc .
if rc ^= 0 then exit rc
'ACCESS' addr1 fm1
'MAKEBUF'
'GETFMADR'
pull . fm2 addr2
'DROPBUF'
parse value diagrc(8, 'LINK' userout addrout addr2 'M') with rc .
if rc ^= 0 then exit rc
'MAKEBUF'
queue 'SYSPRINT CONS'
queue 'INPUT' addr1 disktype
queue 'OUTPUT' addr2 disktype
queue 'COPY ALL'
queue 'YES'
queue 'YES'
queue
call time 'R'
'DDR'
src = rc
'DROPBUF'
'ACCESS' addr1 fm1
'ACCESS' addr2 fm2
'PIPE CMS Q DISK' fm1'|CONS'
'PIPE CMS Q DISK' fm2'|TAKE LAST|CONS'
'RELEASE' fm1
'RELEASE' fm2
call diag 8, 'DETACH' addr1
call diag 8, 'DETACH' addr2
say 'Elapsed time:' time('E')
'CP SLEEP 1 SEC'
exit src
Ivica Brodaric
Not with Tabcorp anymore
(not because of this exec - mainframe is not with Tabcorp anymore
either)
On 08/02/2008, Ivica Brodaric [EMAIL PROTECTED] wrote:
If you create a PROFILE EXEC on 191 that checks who's running and
invokes another exec if it's a dumper machine, e.g.:
if userid() /= 'DMPADMIN' then do
'CP SP CON DMPADMIN'
'EXEC' userid()
'CP LOGOFF'
end
and create userid EXEC for every dumper machine that you are
actually going to use and that contains something simple (you are going to
maintain this), e.g.:
' EXEC DDRCOPY $VOLS$ source_addr $VOLS$ target_addr'
then you only need to write a DDRCOPY EXEC that will link source and
target minidisks and invoke DDR program.
From here you only need to maintain userid EXEC's from dump
maintenance machine and autolog dumper machines to do the work.
On 08/02/2008, Ivica Brodaric [EMAIL PROTECTED] wrote:
And if you move 191 minidisk from dumper machines to maintenance
userid, and add a link to that minidisk as 191 RR to SYSDMPPR profile, you
can define a pool of dumper machines, e.g.:
USER DMP password 5M 25M G
POOL LOW 0 HIGH 99 PROFILE SYSDMPPR
On 08/02/2008, RPN01 [EMAIL PROTECTED] wrote:
If you can get them to use a common profile, and possibly run
a script or
control file that matches the userid, then there'd really be no
need for the
writable 191 in each dumper virtual machine. You could place the
191 under
either $VOLS$ or some other maintenance user, and have the
profile just
link it rr as well.
We do this with all our Linux guests; they share a single 191
minidisk, and
the profile accounts for any differences that may be required.
--
.~.Robert P. Nix Mayo Foundation
/V\RO-OE-5-55200 First Street SW
/( )\ 507-284-0844
Re: How comments treated by DIRMAINT
Not that I know. If you have a comment line about a minidisk in from of a MDISK statement, then if you move or change a minidisk allocation using DATAMOVE, DIRMAINT will insert a new MDISK statement not following your visual connection with the comment line, so don't use that technique. On 08/02/2008, Horlick, Michael [EMAIL PROTECTED] wrote: Greetings, We have a situation that has been annoying us for quite awhile now with regards to DIRMAINT. When we add MDISKs for a user (especially for a VSE user) we usually add comment statements just before the new MDISK. No problem, except when we later GET the directory entry the comments are in the wrong place. Example: I created a dummy user: USER TEST1 X1X2X 32M 128M G 01300910 INCLUDE CMSSTD 01300910 LINK RSCS 0191 0192 RR 01300910 * THIS IS A COMMENT * MDISK 0191 3380 1548 3 ST160D MR ALL 01300910 When I do a DIRM FOR TEST1 GET, I get back in my reader: USER TEST1 X1X2X 32M 128M G 02071121 INCLUDE CMSSTD 02071121 * THIS IS A COMMENT 02071121 * MDISK 0191 3380 1548 3 ST160D MR ALL 02071121 LINK RSCS 0191 0192 RR 02071121 *DVHOPT LNK0 LOG1 RCM1 SMS0 NPW1 LNGAMENG PWC20080207 CRCæE Why and how does DIRMAINT shuffle the directory entry sent to it and is there a way to stop it from doing so? Thanks, Mike
Re: FTP - how can I preserve date time?
For a utility to list/view/extract VMARC archives FTP-ed to other platforms in binary see here: http://www.homerow.net/zvm/vma.htm On 08/02/2008, Bob Henry [EMAIL PROTECTED] wrote: Does VMARC come as part of VM or does it have to be ordered/downloaded fr om IBM?
Re: FTP - how can I preserve date time?
http://www.vm.ibm.com/download/ On 08/02/2008, Bob Henry [EMAIL PROTECTED] wrote: Does VMARC come as part of VM or does it have to be ordered/downloaded fr om IBM?
Re: z/VM Installation from DVD
And if you move 191 minidisk from dumper machines to maintenance userid, and add a link to that minidisk as 191 RR to SYSDMPPR profile, you can define a pool of dumper machines, e.g.: USER DMP password 5M 25M G POOL LOW 0 HIGH 99 PROFILE SYSDMPPR On 08/02/2008, RPN01 [EMAIL PROTECTED] wrote: If you can get them to use a common profile, and possibly run a script or control file that matches the userid, then there'd really be no need for the writable 191 in each dumper virtual machine. You could place the 191 under either $VOLS$ or some other maintenance user, and have the profile just link it rr as well. We do this with all our Linux guests; they share a single 191 minidisk, and the profile accounts for any differences that may be required. -- .~.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 2/6/08 3:25 PM, Aria Bamdad [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2008 12:44:02 -0500 Hilliard, Chris said: I need a short lesson on backing up DASD volumes using DDR. snip Chris, Others have made good suggestions. Over time, you may have more DASD that you want to dump or use multiple virtual machines that you want to use simultaniously to dump from. Here is one way to address that: Define one dummy user that owns a full pack minidisk on each volume: USER $VOLS$ NOLOG ACCOUNT SYSTEM SYSTEM MDISK A00 3390 3339 VOLA00 RR MDISK A01 3390 3339 VOLA01 RR MDISK A02 3390 3339 VOLA02 RR MDISK A03 3390 3339 VOLA03 RR MDISK A04 3390 3339 VOLA04 RR Now define multiple dump users that do the dumping to tape. These users will have access to the dummy account disks above. To make it simpler, just define a user profile first then use that in each dump account: PROFILE SYSDMPPR * Profile for SYSDUMP users ACCOUNT SYSUTIL SYSTEM MACHINE XC IPL CMS PARM AUTOCR CONSOLE 009 3215 SPOOL 00C 2540 READER * SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK MAINT 190 190 RR LINK MAINT 19E 19E RR LINK $VOLS$ A00 A00 RR LINK $VOLS$ A01 A01 RR LINK $VOLS$ A02 A02 RR LINK $VOLS$ A03 A03 RR LINK $VOLS$ A04 A04 RR Now each new dump account can be define using: USER SYSDUMP PASSWORD 5M 25M G INCLUDE SYSDMPPR MDISK 191 3390 zz W * USER SYSDUMP2 PASSWORD 5M 25M G INCLUDE SYSDMPPR MDISK 191 3390 zz W Now each dump account has a virtual address that matches the real address of a real DASD. You can then do a DDR with input statements that point to the virtual address. Remember to never make this LINK or MDISK statements in write mode. Everything should be in read only mode. Aria
Re: z/VM Installation from DVD
If you create a PROFILE EXEC on 191 that checks who's running and invokes another exec if it's a dumper machine, e.g.: if userid() /= 'DMPADMIN' then do 'CP SP CON DMPADMIN' 'EXEC' userid() 'CP LOGOFF' end and create userid EXEC for every dumper machine that you are actually going to use and that contains something simple (you are going to maintain this), e.g.: ' EXEC DDRCOPY $VOLS$ source_addr $VOLS$ target_addr' then you only need to write a DDRCOPY EXEC that will link source and target minidisks and invoke DDR program. From here you only need to maintain userid EXEC's from dump maintenance machine and autolog dumper machines to do the work. On 08/02/2008, Ivica Brodaric [EMAIL PROTECTED] wrote: And if you move 191 minidisk from dumper machines to maintenance userid, and add a link to that minidisk as 191 RR to SYSDMPPR profile, you can define a pool of dumper machines, e.g.: USER DMP password 5M 25M G POOL LOW 0 HIGH 99 PROFILE SYSDMPPR On 08/02/2008, RPN01 [EMAIL PROTECTED] wrote: If you can get them to use a common profile, and possibly run a script or control file that matches the userid, then there'd really be no need for the writable 191 in each dumper virtual machine. You could place the 191 under either $VOLS$ or some other maintenance user, and have the profile just link it rr as well. We do this with all our Linux guests; they share a single 191 minidisk, and the profile accounts for any differences that may be required. -- .~.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 2/6/08 3:25 PM, Aria Bamdad [EMAIL PROTECTED] wrote: On Wed, 6 Feb 2008 12:44:02 -0500 Hilliard, Chris said: I need a short lesson on backing up DASD volumes using DDR. snip Chris, Others have made good suggestions. Over time, you may have more DASD that you want to dump or use multiple virtual machines that you want to use simultaniously to dump from. Here is one way to address that: Define one dummy user that owns a full pack minidisk on each volume: USER $VOLS$ NOLOG ACCOUNT SYSTEM SYSTEM MDISK A00 3390 3339 VOLA00 RR MDISK A01 3390 3339 VOLA01 RR MDISK A02 3390 3339 VOLA02 RR MDISK A03 3390 3339 VOLA03 RR MDISK A04 3390 3339 VOLA04 RR Now define multiple dump users that do the dumping to tape. These users will have access to the dummy account disks above. To make it simpler, just define a user profile first then use that in each dump account: PROFILE SYSDMPPR * Profile for SYSDUMP users ACCOUNT SYSUTIL SYSTEM MACHINE XC IPL CMS PARM AUTOCR CONSOLE 009 3215 SPOOL 00C 2540 READER * SPOOL 00D 2540 PUNCH A SPOOL 00E 1403 A LINK MAINT 190 190 RR LINK MAINT 19E 19E RR LINK $VOLS$ A00 A00 RR LINK $VOLS$ A01 A01 RR LINK $VOLS$ A02 A02 RR LINK $VOLS$ A03 A03 RR LINK $VOLS$ A04 A04 RR Now each new dump account can be define using: USER SYSDUMP PASSWORD 5M 25M G INCLUDE SYSDMPPR MDISK 191 3390 zz W * USER SYSDUMP2 PASSWORD 5M 25M G INCLUDE SYSDMPPR MDISK 191 3390 zz W Now each dump account has a virtual address that matches the real address of a real DASD. You can then do a DDR with input statements that point to the virtual address. Remember to never make this LINK or MDISK statements in write mode. Everything should be in read only mode. Aria
Re: Old LOCK FILE problem.
Entries in your $ASIPROC.PROC should have a format of: CPU=FFss,IPL=iplproc,JCL=jclproc ss is a virtual CPUID (from 'CP SET CPUID ss' or from directory) and is a model number. If your virtual CPUID is not found in the list of CPU statements in $ASIPROC.PROC, the default IPL and JCL procs are used.
Re: z/VM 5.2 ICC console connection problems
Did you vary it offline from all LPARs at the same time? On 11/09/2007, James M [EMAIL PROTECTED] wrote: I did try toggling the chpid off/on in each of the lpars but I'm not sure it worked properly. it went from online/online to online/standby. I never did see the current state go to offline! On 9/10/07, Rich Smrcina [EMAIL PROTECTED] wrote: Resetting the ICC port will only affect the ICC users, if most of your users are coming in through VM's TCP/IP stack, it's not using the ICC. If only your console or datacenter users use the ICC, you can reset it without affecting your users. James M wrote: device shows enabled. I cannot reset the port on the hmc since it's a dual port card (icc tcpip) and that would mean dropping many vm os telnet clients. On 9/10/07, David Kreuter [EMAIL PROTECTED] wrote: from the hmc try resetting the OSA port at the chpid level. David From: The IBM z/VM Operating System on behalf of James M Sent: Mon 9/10/2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM 5.2 ICC console connection problems Over the weekend an operator I did something..I don't know what that has rendered the ICC vm console unusable. I tried disable/enable cuu, vary off/on path to cuu and dropping the session from the HMC ICC utilities menu all to no avail. Can someone please suggest other possible solutions. Thanks -Jim -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: z/VM 5.2 ICC console connection problems
Yes. It has to be offline to all LPARs in order to reset itself. On 11/09/2007, James M [EMAIL PROTECTED] wrote: maybe we're getting someplace. are you suggesting that I have to config path off in all the lpars and then config it on in all? what I did was off/on in lpar 1 - off/on lpar2 and so on. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Did you vary it offline from all LPARs at the same time? On 11/09/2007, James M [EMAIL PROTECTED] wrote: I did try toggling the chpid off/on in each of the lpars but I'm not sure it worked properly. it went from online/online to online/standby. I never did see the current state go to offline! On 9/10/07, Rich Smrcina [EMAIL PROTECTED] wrote: Resetting the ICC port will only affect the ICC users, if most of your users are coming in through VM's TCP/IP stack, it's not using the ICC. If only your console or datacenter users use the ICC, you can reset it without affecting your users. James M wrote: device shows enabled. I cannot reset the port on the hmc since it's a dual port card (icc tcpip) and that would mean dropping many vm os telnet clients. On 9/10/07, David Kreuter [EMAIL PROTECTED] wrote: from the hmc try resetting the OSA port at the chpid level. David From: The IBM z/VM Operating System on behalf of James M Sent: Mon 9/10/2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM 5.2 ICC console connection problems Over the weekend an operator I did something..I don't know what that has rendered the ICC vm console unusable. I tried disable/enable cuu, vary off/on path to cuu and dropping the session from the HMC ICC utilities menu all to no avail. Can someone please suggest other possible solutions. Thanks -Jim -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: z/VM 5.2 ICC console connection problems
Let's be clear. On all LPARs: CP VARY OFF PATH xx FROM ALL CP VARY OFF CHPID xx Then on each LPAR: CP VARY ON CHPID xx Did you do that? On 11/09/2007, James M [EMAIL PROTECTED] wrote: OK thanks. I varied all off first and the all on. I saw all the devices go off and come back online on operx. ...but it didn't help - I still cannot connect from the pc to the icc port. I did enable the console cuu before trying. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Yes. It has to be offline to all LPARs in order to reset itself. On 11/09/2007, James M [EMAIL PROTECTED] wrote: maybe we're getting someplace. are you suggesting that I have to config path off in all the lpars and then config it on in all? what I did was off/on in lpar 1 - off/on lpar2 and so on. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Did you vary it offline from all LPARs at the same time? On 11/09/2007, James M [EMAIL PROTECTED] wrote: I did try toggling the chpid off/on in each of the lpars but I'm not sure it worked properly. it went from online/online to online/standby. I never did see the current state go to offline! On 9/10/07, Rich Smrcina [EMAIL PROTECTED] wrote: Resetting the ICC port will only affect the ICC users, if most of your users are coming in through VM's TCP/IP stack, it's not using the ICC. If only your console or datacenter users use the ICC, you can reset it without affecting your users. James M wrote: device shows enabled. I cannot reset the port on the hmc since it's a dual port card (icc tcpip) and that would mean dropping many vm os telnet clients. On 9/10/07, David Kreuter [EMAIL PROTECTED] wrote: from the hmc try resetting the OSA port at the chpid level. David __ __ From: The IBM z/VM Operating System on behalf of James M Sent: Mon 9/10/2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM 5.2 ICC console connection problems Over the weekend an operator I did something..I don't know what that has rendered the ICC vm console unusable. I tried disable/enable cuu, vary off/on path to cuu and dropping the session from the HMC ICC utilities menu all to no avail. Can someone please suggest other possible solutions. Thanks -Jim -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: z/VM 5.2 ICC console connection problems
That should be OK. Try to ping the IP address from the PC. Do traceroute if you can't ping. On 11/09/2007, James M [EMAIL PROTECTED] wrote: I do not have access to all the os's that run in each lpar so I did everything from the HMC. I higlighted each image one by one and configured the channel path off. I again highlighted each image and this time configured the channel online. FYI - the only image that is actually using the ICC chpid is the vm 5.2 system which I do have access to. -jim On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Let's be clear. On all LPARs: CP VARY OFF PATH xx FROM ALL CP VARY OFF CHPID xx Then on each LPAR: CP VARY ON CHPID xx Did you do that? On 11/09/2007, James M [EMAIL PROTECTED] wrote: OK thanks. I varied all off first and the all on. I saw all the devices go off and come back online on operx. ...but it didn't help - I still cannot connect from the pc to the icc port. I did enable the console cuu before trying. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Yes. It has to be offline to all LPARs in order to reset itself. On 11/09/2007, James M [EMAIL PROTECTED] wrote: maybe we're getting someplace. are you suggesting that I have to config path off in all the lpars and then config it on in all? what I did was off/on in lpar 1 - off/on lpar2 and so on. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Did you vary it offline from all LPARs at the same time? On 11/09/2007, James M [EMAIL PROTECTED] wrote: I did try toggling the chpid off/on in each of the lpars but I'm not sure it worked properly. it went from online/online to online/standby. I never did see the current state go to offline! On 9/10/07, Rich Smrcina [EMAIL PROTECTED] wrote: Resetting the ICC port will only affect the ICC users, if most of your users are coming in through VM's TCP/IP stack, it's not using the ICC. If only your console or datacenter users use the ICC, you can reset it without affecting your users. James M wrote: device shows enabled. I cannot reset the port on the hmc since it's a dual port card (icc tcpip) and that would mean dropping many vm os telnet clients. On 9/10/07, David Kreuter [EMAIL PROTECTED] wrote: from the hmc try resetting the OSA port at the chpid level. David __ __ From: The IBM z/VM Operating System on behalf of James M Sent: Mon 9/10/2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM 5.2 ICC console connection problems Over the weekend an operator I did something..I don't know what that has rendered the ICC vm console unusable. I tried disable/enable cuu, vary off/on path to cuu and dropping the session from the HMC ICC utilities menu all to no avail. Can someone please suggest other possible solutions. Thanks -Jim -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: z/VM 5.2 ICC console connection problems
Then it's likely not a card but a network problem. Asymmetric routing maybe? Do you get any errors when you try to connect? On 11/09/2007, James M [EMAIL PROTECTED] wrote: ping works! On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: That should be OK. Try to ping the IP address from the PC. Do traceroute if you can't ping. On 11/09/2007, James M [EMAIL PROTECTED] wrote: I do not have access to all the os's that run in each lpar so I did everything from the HMC. I higlighted each image one by one and configured the channel path off. I again highlighted each image and this time configured the channel online. FYI - the only image that is actually using the ICC chpid is the vm 5.2 system which I do have access to. -jim On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Let's be clear. On all LPARs: CP VARY OFF PATH xx FROM ALL CP VARY OFF CHPID xx Then on each LPAR: CP VARY ON CHPID xx Did you do that? On 11/09/2007, James M [EMAIL PROTECTED] wrote: OK thanks. I varied all off first and the all on. I saw all the devices go off and come back online on operx. ...but it didn't help - I still cannot connect from the pc to the icc port. I did enable the console cuu before trying. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Yes. It has to be offline to all LPARs in order to reset itself. On 11/09/2007, James M [EMAIL PROTECTED] wrote: maybe we're getting someplace. are you suggesting that I have to config path off in all the lpars and then config it on in all? what I did was off/on in lpar 1 - off/on lpar2 and so on. On 9/10/07, Ivica Brodaric [EMAIL PROTECTED] wrote: Did you vary it offline from all LPARs at the same time? On 11/09/2007, James M [EMAIL PROTECTED] wrote: I did try toggling the chpid off/on in each of the lpars but I'm not sure it worked properly. it went from online/online to online/standby. I never did see the current state go to offline! On 9/10/07, Rich Smrcina [EMAIL PROTECTED] wrote: Resetting the ICC port will only affect the ICC users, if most of your users are coming in through VM's TCP/IP stack, it's not using the ICC. If only your console or datacenter users use the ICC, you can reset it without affecting your users. James M wrote: device shows enabled. I cannot reset the port on the hmc since it's a dual port card (icc tcpip) and that would mean dropping many vm os telnet clients. On 9/10/07, David Kreuter [EMAIL PROTECTED] wrote: from the hmc try resetting the OSA port at the chpid level. David __ __ From: The IBM z/VM Operating System on behalf of James M Sent: Mon 9/10/2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM 5.2 ICC console connection problems Over the weekend an operator I did something..I don't know what that has rendered the ICC vm console unusable. I tried disable/enable cuu, vary off/on path to cuu and dropping the session from the HMC ICC utilities menu all to no avail. Can someone please suggest other possible solutions. Thanks -Jim -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: MAINTENANCE
We have SHUTDOWN command in a privilege class of its own and only one ops userid has that class. That user has a SHUTDOWN EXEC on its A disk. Not to prevent the shutdown but to actually do it. It first checks that it's being run from that particular user and then asks a are-you-shure-type question. That pretty much eliminates the possibility of an accidental shutdown of the first level. I mean, you can still add that shutdown-only privilege class to your user and and then have an oops! moment, but then it's not an _accident_. It's not a death wish either. It's an intention to kill.
Fwd: FW: Stuff
Re: System utiliization
Do 'q rec' and check for a large amount of queued records. Maybe something stopped collecting? That could eat up your storage too, making things even worse for not so obvious a reason. Just a stab in the dark...
Re: SPOOL volume disk error
Mikhael, Listen to Alan and call in the Support Centre. While you wait... What did the hardware guys do? Did they replace a drive in a Symmetrix's RAID group? If they did, I would also check any other DASD that may be affected (e.g. other DASD on the same stripe in the same RAID-5/S group as 440E). Any chance that one of those is a paging volume? Also check 'q pinned 440e' and 'q pinned subsys 440e'.
Re: SPOOL volume disk error
What was the abend code when the system restarted? What kind of disk is it? Check the allocation map of the volume against the real size of the pack. Was the pack initially formated or DDR-copied from somewhere else?
