Re: Geoplex performance considerations
--- snip --- To all who have helped with our research into GDPS with SRDF/A, THANKS! What we've found is that virtually no one is running a GDPS with syncronous data replication, and we fould only one instance of active data sharing across sites. -- snip -- Since I'm curious, I took a look at the EMC Web site to see what information I could find about GDPS and SRDF. Apparently it is supported (in synchronous mode). A Hyperwsap equivalent (Autoswap) is also available. Why is it that almost no-one is running GDPS (synchronous)? IMHO that is where GDPS gets you the most. I know of numerous installations (here in Germany) with IBM or HDS Storage running GDPS with PPRC. Just wondering why? John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3390-81
-- snip -- >I've come across a couple of references to a 3390-81. Now, we have -27 and >-54 devices. >Have I missed some announcement? > Never heard of it, and in our business we certainly would have. Don't forget that 3390-27 and -54 are fictional names, not official ones. Although IBM occasionally uses them, they are not actual designations. The large disks are identified internally as 3390-9 disks with an appropriate number of cylinders. However, many users and ISVs, including Innovation, use the designations for convenience. BTW, the numbers are the approproximate number of GB on the disk when it is defined as the maximum number of cylinders. -- snip -- I found the references in various CA Brightstore PTFs. Like Ed, we also don't (no longer anyway) use the maximum number of cylinders. The architecture dictates the optimal definition. It isn't necessarily the maximum. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPAR utilization more important than MVS utilization?
--- snip --- In LPAR mode, if a Logical Processor is not dispatched by PR/SM then it does not accumulate wait time even though it is actually waiting. This means that MVS % Busy is greater than actual time that LP within the LPAR were dispatched by PR/SM and busy. LPAR busy is the right number, though a large difference between MVS % Busy and LPAR busy is indication of a saturated LPAR. --- snip --- What does SDSF show me? I often see a large difference between LPAR% and MVS% in RMF. I don't have the RMF data in front of me now to confirm that this only happens when the CPC is maxed out. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Backup of Offline Data (at a remote site)
-- snip -- Run z/os.e on a very small CPU with upgrade on demand at your BR site. The backup steps don't need a lot of CPU power, and z/os.e is cheap. Very cheap. Once you pull your DR trigger, upgrade the box and start recovering your LPARS. The z/os.e LPAR can remain active to assist as a 'floor' system. -- snip -- Interesting. I'm assuming that one could set up a z/OS.e system(s) running XRC to take care of mirroring the secondary data. Is this in the 'spirit' of z/OS.e? John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CFW and DFSORT
> Hi all > because of GDPS Hyperswap-Tests we want to disable Cache Fast Write. We > were wondering which jobs would be affected by this change and we found > out that DFSORT has an option CFW=Y, which is our default. > 1. how will DFSORT react if option CFW=Y is used and on the HW it is > disabled ? > 2. Is this feature actually still used by DFSORT ? I am asking because > CFW rate is 0.1 in our RMF report. I can't answer for DFSORT, but we had no problem with Syncsort with turning off CFW. (If the software is smart - it would check the hardware status first!) The same restrictions appear for Concurrent copy. John. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Allocation request for a DB2 dump wants more than a MOD-3
-- snip -- > When DB2 wants to dump, specifically where do I get to specify the > primary and secondary space allocations for that dump? This part is well documented. Issue: DD ADD,SMS=(DATA=dataclas,STOR=storclas,MGMT=mgmtclas) to set the SMS classes that control dump data set size, placement, and management. -- snip -- If you really want to optimise Dump processing, take a look at using Extented format SMS Datasets with striping (and maybe even compression). All nicely documented in MVS Diagnosis : Tools and Service Aids GA22-7589 John. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HDS backup process
-- snip -- John, Not actually true. There is a bitmap merge as part of the resynch. Ron > > If you CLIP the secondary DASD, just remember that a subsequent RESYNC > will > not copy the label since that wasn't changed on the primary subsystem. You > may want to CLIP it back. > > John > -- snip -- Ron, I assume that if both bitmaps indicated that the same track was changed that the latest timestamp wins. If I remember correctly, the timestamps are sourced via the MVS I/O (typically from a SYSPLEX timer). Since the primary and secondary may not be attached to the same time source, don't you see this as being a little risky! John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HDS backup process
--- snip --- The fact that ickdsf cannot clip the volser is because the hardware knows that this secondary disk is part of a suspended pair . When you suspend , ickdsf will tell you ICK30111I DEVICE SPECIFIED IS THE SECONDARY OF A DUPLEX OR PPRC PAIR ICK31024I UNABLE TO OPEN VOLUME. ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12 ( this is happening on IBM dasd and is Zaromil description ) AFAIK this is just because of pure hardware behaviour .( shutting down your entire GDPS will not clear the condition . Hardware will remember it is part of a suspended pair . So when you say it is possible to clip the volumes , do you mean you can do it only on other hardware ? (like HDS) or is it just because your BCM software is manipulating some hardware bits in the controller , in order to fool ickdsf ? ( i was thinking of a scenario with db2 log suspend , csuspend ,db2 log resume, dump the secondary volumes on cartridges, and cestpair resynch ) --- snip --- Does the DUMPCOND(SET) parameter of ICKDSF REFORMAT get you anything? I've never tried it with a suspended Duplex secondary. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RMF Data & RMF Spreadsheet Reporter
--- snip --- Hi, I am just starting to get to grips with the RMF Spreadsheet Reporter. I need to do some analysis of some historical data that was created on a zOS 1.4 system on my current zOS 1.6 system. However, the RMF Post Processor is complaining about differing levels of Code & data. Is their a way to transform the zOS 1.4 data into something that RMFPP can process? --- snip --- You need to modify the PP JCL that is being generated. I believe that it is in RMFPPL.JCL. Add a Steplib to point to your z/OS 1.4 RMF Loadlib. Take a look at RMF Users Guide (SC33-7994). John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z800-002 compared to 9672-R36 with 2 SAPs
-- snip -- >SAP (now called IOP) History: 308x -- XDC: External Data Controller 3090 -- IOP: I/O Processor 9021 -- IOP: Integrated Offload Processor 9672 -- SAP: Service Assist Processor z800, z890, z900, z990, & z9 -- SAP: still the same. I do not believe IBM changed the name, again. But, I could be wrong (unlikely as that may be). -- snip -- RMF reports refer to them (on a z9) as IOPs. John (could also be wrong - just quoting RMF) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Back Doors (was: EXCP with a DEB)
-- snip -- > The presence of bank vaults in the world means that there must also be > locksmiths in it who can open them, and I suppose that there is a similar > rationale for the skills needed to breach z/OS, but this is a public forum > in which I for one do not think we should facilitate such operations by > unknown people. > Certainly any system is breachable by: o Brute force attack on a password. -- snip -- A properly customised RACF (or similar) in z/OS certainly makes a brute force attack on a password futile. 3 guesses and you're revoked doesn't get you system access. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Power 6 and other new hardware
Good evening (at least here in Europe). The German 'Computerwoche' has a couple of interesting articles this week. IBM announced the Power 6 processor. http://www-03.ibm.com/press/us/en/pressrelease/21580.wss Hitachi announced the successor to the Tagmastor. Universal Storage Platform V. http://www.hds.com/products/storage-systems/universal-storage-platform-v.html I'm wondering when IBM will announce the successor to the DS8000 family of storage hardware. I believe that the DS8000 uses power 5 processors. It will be interesting to see what comes next. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
BRLM and GRS (from z/OS Hot Topics)
Thank you Birger for the link to the new z/OS Hot Topics newsletter. I have a question concerning the byte range lock manager article. After reading about the various evolutions of the BRLM (single environment, shared, recovery considerations within a sysplex), I was wondering why the locking mechanism was redeveloped! It seems to me that GRS is the perfect server (or manager - if we can call it that) to maintain any locks that the z/OS UNIX environment needs to serialize its resources. Could someone maybe fill me in on what I am obviously missing! Thanks John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Virtual tape limits (Was: OEM software electronic download report card)
> >>> It's one reason to try to keep all your tapes virtual. > > >> It's a small trade off for simplifying the > >> management of the environment (which is very large) and guaranteeing > >> to the business that we will have all the tape data in a disaster. > > >Well, it's safe, convenient, error-proof, but EXPENSIVE. > > It doesn't have to be expensive. Seen this? > http://www.luminex.com/products/channel_gateway/firex4500.htm > Or this? > http://www.bustech.com/products/mainframe-data-library.asp > > Both will mirror the data on the back end for BCP purposes. Why even keep > the RTDs? This stuff is inexpensive enough to keep all the tape data on > spinning disk and fully mirrored. We're seriously thinking about it. > Probably works for us better than most, however, since we made a concerted > effort over the last decade to keep people from using tape. So its mainly > just HSM and DB images at this point and its under 25TB of data. This customer has around 5 Petabytes of tape data. That's a lot of DASD - even with todays price per gigabyte. Some data typically needs to be kept for 10 years (or longer). I think tapes will still be around for a while yet. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
