Re: Managing system logger data
- Original Message - From: "Edward Jaffe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Friday, February 01, 2008 8:26 AM Subject: Re: Managing system logger data Skip Robinson wrote: Here's the problem. IFASMFDL does most of what IFASMFDP does (and more), but what it *doesn't* do is clear out the dumped SMF data. You might recall, during a certain period of singing and drinking in which you were present, this issue being pointed out to Mr. Jones as he presented this (then) new function. It was also brought up each time Mr. Jones presented at a certain TDM I regularly attend. Notes were taken. But, each new iteration of the presentation seemed to confirm that no change was ever made. Now that it's GA, perhaps someone will take an APAR? What I did was take an IXGSLOGR exit we already had with the DELETE function implemented), and modified it to handle the SMF buffer format. The format isn't difficult. Writing the exit is an interesting exercise (they convert all abends to a S001, I ended up debugging my usual 0C4 abends from the MVS trace table entry.) Deleting data using the logger macros is easy, IXGBRWSE will return the blockid for each block read, pass the blockid to IXGDELET to delete everything less than the blockid. The blockid appears to be an RBA (or something very similar). I had written an etr about IFASMFDL reading the entire logstream. The eventual response was that I was in error. Having unwisely deleted the doc, I carefully reran my testing and was unable to recreate the problem. Hate it when that happens. The rest of this is some logger stuff I've learned. If you already know, or don't care, this is a good place to punch out. We have a policy of DASD changeout every five years, so every few months I get a call because a staging dataset won't move from an otherwise cleaned off volume. This normally involves me cycling an address space I wrote. But for SMF, that isn't going to be an option. Right now it looks like doing a switch back to MAN dataset recording, and then switching back to logstream. If you do it too quickly, logger may not have gotten around to deleting the old staging dataset, and will go to using the old one all over again. So it needs to be a "stop the logstream"; "check if the staging dataset is gone", "start the logstream" sort of activity. System REXX comes to mind. If you don't code DSEXTENTS in the logger couple dataset definition, then you can have 168 log datasets. LS_SIZE is in 4K blocks, so 4K * 168 * LS_SIZE minus a fudge factor [1] is how much data you can get into the logstream. Once the logstream is full, a return/reason code goes back to the invoker of IXGWRITE. So the results will depend on the invoker. In the case of SMF, I would expect the same results as if the MAN datasets were full. If you do code DSEXTENTS then sizing becomes a sysplex wide activity. Once the 168 dataset slots dedicated to a logstream become filled, the logstream can then use slots from the DSEXTENTS. Each slot is another 168 datasets, but the DSEXTENTS are shared among all the logstreams defined in the couple dataset. So, even if you define each system in the sysplex as DASD-ONLY, once you exceed 168 log datasets, you are now using slots from a sysplex wide pool. Any logstream defined as GROUP(PRODUCTION) can use at least 75% of this pool. Any logstream defined as GROUP(TEST) can use at most 25% of this pool. The only way to change DSEXTENTS is to format a new logger couple dataset and do the switching thing. Since LS_SIZE will control the actual size of a dataset out in SMS land, there is a reason to keep it relatively small (about 75 cylinders in our shop.) Having a small dataset size will cause the number of datasets to go up for any given amount of data. Which will then be a cause for coding DSEXTENTS. Without DSEXTENTS, you can limit problems to whatever logstream that may exceed data expectations. With DSEXTENTS, you can happily propagate logstream capacity issues around your sysplex. Given the SMF spikes I've seen when somebody makes a booboo, I would want a lockdown method of getting data out of the SMF logstream now [2]. [1] Fudge factor is a scientific term meaning "I don't know" [2] Now is a management term meaning "Is it done yet?" Lance -- 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: CA SMF Director
I tested SMF Logstream during ESP and would describe it: PROs: 1. Eliminates a lot of fiddle-faddle with getting MAN datasets sized and dumped. 2. Will write to multiple logstreams, so "interesting" data can be isolated and/or Duplicated into its own logstream. 3. The IFASEXIT is very nice, and allows one to read "up to current" SMF data into any QSAM program without any of the MAN dataset hassles. 4. The report out of IFASMFDL is almost identical to the report out of IFASMFDP 5. The recommended block size for the logsteam is 64K, if you've ever tried to find the optimum blocksize for a MAN dataset, this is a genuine relief. (I did some stats one day and found that because of record spanning, we got actual MAN dataset usage of about 60% during our peak period.) 6. Did I mention that MAN datasets are a hassle? CONs: 1. IFASMFDL had a design point of giving results like IFASMFDP, therefore: a. IFASMFDL reads the entire logstream regardless of what the control cards ask for B. IFASMFDL does not have a CLEAR option. When this was pointed out on ibm-main a rather stuffy pontification about "new paradigm" was the result. See CON 1.a c. IFASMFDL will have an initial date/time value that is the oldest data in the logstream, regardless of the DATE control card. See CON 1.a 2. IFASEXIT does not have a DELETE option analogous to the logrec IFBSEXIT routine. 3. Any storage medium is finite, including logstreams. SMF can be a lot of data, especially if, say, a server gets into a loop invoking FTP for a revoked userid . You will want to be aware of Logstream DSEXTENTS, and the fact that SMF will be sharing these with all other Logstream users. 4. IFASMFDL still does VBS without any option to override to VB. This Can be another hassle if you MOD onto the monthly. If something happens To the job that is MODing onto a tape, say, an overly busy operator IPLs Over the job, then you have a broken spanned record and a S002 abend. This doesn't happen with VB, you just get duplicated data, which is pretty normal for SMF. And you can't use IFASEXIT to read the logstream into IFASMFDL. IFASMFDL gets the willies over the RECFM=VB that the subsystem interface generates. SSI doesn't do VBS, IFASMFDL doesn't do VB. That being said, I will push for SMF logstreams when we go production with 1.9 Like anything else, planning and foresight. One other small point, looking at the raw logstream, it looks like they build an extra header for each SMF record. Among other things, it appears that there is a GMT timestamp that the record was moved into the buffer. There isn't a way to Externalize that now, unless you read the logstream directly, but it may be useful for some shops. I deleted the legal disclaimer below, if this gives your corporate lawyer heartburn good Lance "Ron Wells" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Tad off subject... > > Anyone look at the smf logger facility or try using it yet?? > > pro's/con's or what to watch for would be helpful .. > -- 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: IECIOSxx HOTIO settings
We did a study some years ago and now have an IECIOS00 of: HOTIO DFLT110=(CHPK,CHPF) HOTIO DFLT111=(CHPK,CHPF) HOTIO DFLT112=(CHPK,CHPF) HOTIO DFLT110=(CUK,BOX) HOTIO DFLT111=(CUK,BOX) HOTIO DFLT112=(CUK,CHPF) I don't remember the reasoning very well, except that asking the operator seemed like a good way to slow recovery down to a dead stop. Even the most excellent and experienced operator probably hasn't seen a HOTIO in many years. Our operators are trained to page the MVS oncall if there is any doubt. And we haven't seen HOTIO either. So even the most extreme reaction seemed better than asking the operator to send a page and spread the confusion. Better to box and recover from that. Lance - Original Message - From: "Knutson, Sam" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Wednesday, December 12, 2007 9:21 AM Subject: IECIOSxx HOTIO settings Hi, I am reviewing our settings for HOTIO in IECIOSxx SYS1.PARMLIB(IECIOS00) IBM default if different HOTIO DFLT110=(OPER,OPER) BOX,BOX HOTIO DFLT111=(CHPK,OPER) CHPX,BOX HOTIO DFLT112=(OPER,OPER) CHPK,BOX was CHPK,OPER HOTIO SDFT110=(OPER,OPER) BOX,BOX HOTIO SDFT111=(CUK,OPER) CUK,BOX HOTIO SDFT112=(CUK,OPER) CUK,BOX IBM changed the default for DFLT112 from CHPK,OPER to CHPK,BOX in z/OS 1.8 and it prompted me to review these. I cannot remember an instance of HOTIO in many years but I do think that OPER as the first action as we have in many cases is probably unwise. Curious if anyone else has changed the IBM defaults or if anyone has some insights on what was the motivation for the change in 1.8 to DFLT112? This specifies the recovery action to be taken for a DASD or a dynamic pathing device that is not reserved or assigned. My guess is that IBM must have seen some cases where OPER resulted in prompts incorrectly or not replied to and it caused an outage. My current thinking is to propose we at least remove OPER as the first action in this case and possibly for all the cases. Anyone have any comments? Best Regards, Sam Knutson, GEICO Performance and Availability Management -- 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: SLIP sliding away
ENABLED(INACTIVE) means that there is already a PER type slip active in the system. Disable or delete it. Lance - Original Message - From: "Support, DUNNIT SYSTEMS LTD." <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Monday, October 08, 2007 5:18 AM Subject: SLIP sliding away Here's the SLIP I set, as displayed on console: ID=DB2A,PER-IF,ENABLED(INACTIVE) ACTION=SYNCSVCD,SET BY CONS USERJLE,PRCNTLIM=10,00 MATCHLIM=1,0,PVTMOD=DSNXGRDS,00B02000,00B02180,MODE=ANY,ALL ASID=0047,0052 SDATA=SQA,LSQA,RGN,LPA,CSA,SWA,SUMDUMP -- 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: Migration from z/800-0B1 to z9BC-703
- Original Message - From: "Gibney, Dave" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Tuesday, June 19, 2007 11:24 PM Subject: Re: Migration from z/800-0B1 to z9BC-703 I might have to look at capping if we go further down the SCRT and perhaps zNALC route, but for now, no hard capping. Rehosing fees are likely to cost one ISV with only one JCL related product at our site a customer. "Rehosing fees" is very similar to the term: "Rehosting fees" but more accurate. Thanks, you made my day. Lance -- 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: Time Change at IPL
Am interested in knowing if most people still IPL for time change - spring and fall - and if anyone does not, how they handle this. Thanks, Tom We did something interesting, and had an interesting problem as a result. Because of data center consolidation we had mainframes in the same room running in different time zones. In years past, this caused confusion among operators, and various systems got set to various times on more than one occasion. This problem was solved by writing automation that would, on operator command, get the current time, perform the proper arithmetic on the hour, and issue a set clock command. Which worked wonderfully, except... For whatever reason, it took OPS/MVS about 2.6 seconds to do all this. So the MVS clock was actually set back by one hour and 2.6 seconds. This wouldn't matter really, except... It appears that OMVS works out the time of day at bring up, and just goes from there. So, in the end, various OMVS apps were getting to midnight about 2.6 seconds before MVS. Therefore, CRON ran, invoked a REXX exec to create a new HFS file for todays FTP log, REXX queried MVS for the time of day, decided it wasn't tomorrow yet, and we got a sev 4 PMR because the FTP log was in yesterdays file. I've recommended that the automation be changed to use set timezone, but first there are some management issues to be addressed. For us at least, daylight savings time is not a technical issue, it is an emotional issue. The amount of meeting time spent to talk about all this is growing at an exponential rate, with no end in sight. Lance -- 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: z/OS System Cmd Characters
- Original Message - From: ""Mark Zelden"" <[EMAIL PROTECTED]> Mark, Do you have a REXX Exec in your bag of tricks that lists out the other CMD characters in use on a system, like in 'D OPDATA'?? Or does such code exist on the CBT tape somewhere? No can do. If it was that easy, don't you think D OPDATA would do it and products wouldn't need to register their command character usage using a formal interface? Actually, I put together a rexx exec that works out what command reference characters are being used (it goes through JES3 DLOG, so only commands actually used can be found). Also, it expects that you define the ones you know about, or else the report gets redundant. It would take some work to make this "JES2 ready", but it does work, and ignores typos, which really helps the length of the report. This came about because the IMS folks added about 70 of 'em (nothing like being a good sized shop), and managed to step all over one poor support guy. He had to make changes in 26 environments because supporting one product was nothing compared to IMS type momentum. Anyway, there is also a little web app to keep track of all this. You can bring up a web page and display the whole list, or search for the string you would like to use, or register your string. It even detects partials, in the case above, the '#' was used for some product, and IMS defined many of the form '#xx'. So this page detects those kinds of conflicts also. We run the web page from our MVS http server. If anyone is interested, it's free for the asking. Lance Keep good doc. Anything "new" you define, use more than a single character to avoid conflicts (and use D OPDATA). If you really want to use a single character or don't have a choice and aren't sure if it is currently used, just type that character at the console. If you see "IEE305I ? COMMAND INVALID" (where ? = the character) then it should mean that character is not in use. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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 -- 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: SHARE Forcast
From: "Pommier, Rex R." South Dakota here, Wayne, you didn't mention whether the "double digits" had a minus sign in front of them. :-) Hmmm. Depends on what part of South Dakota. It's 10 degrees Fahrenheit here in the Banana Belt (Piedmont). And snowing. Again. Lance Looking at the 10 day forcast for Tampa Florida, I see that the SHARE jinx is at work again. It looks like Sunday and Monday will be OK, but rain is forecast for Tuesday, Wednesday and Thursday. Might want to pack an umbrella. But then again, temps will be in the 70's, so it will be a blessing for those of us from the upper midwest, where double digits are a heat wave lately. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -- 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: Space limit for SMF datasets?
Size isn't the issue, it's being able to dump them quicker than they fill up. Indeed. Doesn't SMF support use of the logger? Does anyone have experience using the logger for SMF? SMF doesn't write to logger (out of the box). We do write SMF to logger, but I wrote the code to do it. Pretty interesting project really. Getting back to the subject of MAN datasets, we had an issue on one system in a previous century, an application decided to do excessive DB2 stuff. We got up to 12 or 16 MAN datasets and still had issues. The primary thing we did to resolve the problem was to improve service to the dump process. Obviously, the dump process needs to run at least as well as the creating process. Then we changed it so that each dump process created a unique dataset name, so multiple dump processes could run in parallel. That required a little rexx code to query the catalog and build the JCL for the daily job. But now we can run parallel dump processes and we can run the dump processes in parallel with the daily accumulation job. We run three MAN datasets, 70 - 75 cylinders each. Only time we use the third MAN is when the onlines come down and batch starts up. This technique has worked for several processor generations on 38 LPARs (down from 64). Lance -- Shmuel (Seymour J.) Metz, SysProg and JOAT -- 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: MEMLIMIT and IEFUSI
- Original Message - From: "Craddock, Chris" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Wednesday, November 02, 2005 10:04 PM Subject: RE: MEMLIMIT and IEFUSI /snippage/ So you're going to modify the IEFUSI exit for each needed change, reassemble it and activate it dynamically? Yeah right. And what happens when you're out on a smoke break when that SOX-compliance job just has to run right now and it keeps failing for lack of region? That's not exactly a responsive way to run a system. What we did was decide that we needed to set reasonable limits, and allow people to specify in JCL what they needed, when our reasonable proved to be not reasonable. We did this by assuming that only the first characters in ACCT= would be meaningful account information. So we have a lot of JCL that looks something like: // EXEC PGM=DFSRRC0,ACCT=(,REGION,6M,128M) Where anyone can specify what they need below the line, above the line and so on. We actually support all the values that can be changed in IEFUSI. Except MEMLIMIT. It's in the todo list somewhere. Lance -- 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: GDG allocation
- Original Message - From: "Mark Steely" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Thursday, October 06, 2005 2:05 PM Subject: GDG allocation We are z/OS v1r4. We have a started task which creates a GDG file. This started task stays ups unless it abends or an IPL happens. This GDG is SMS controlled. There are several files which will not migrate because the GDG index is enqueued. Is there a way to get around this so the files will be migrated. We do something very similar to this. We have a started task that reads syslog off spool and writes it into a GDG, beginning a new GDG at midnight each night. The way this is coded is to do a dynamic allocation of the +1 generation, which would be exclusive and should ENQ on the GDG base. After the dataset is actually created, it is then deallocated (via dynamic allocation) and then allocated again with DISP=SHR. The DISP=SHR does not ENQ on the GDG base. Then the output dataset, allocated DISP=SHR as it is, is opened for output with EXTEND and data is written to it every minute or so. So it ends up being one writer and many readers. I've often wondered why nobody ever sees garbage at the end of the dataset, but it doesn't happen. Probably using up all my luck that doesn't show up in the lottery. Lance Any help would be appreciated. Thank You -- 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 -- 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: Merging SYSPLEXes
Dear Mr Chase, My intention in the original post was to assist George in his Bronzeplex project. If you have something to say on that subject, you should do so. Sincerely, Lance - Original Message - From: "Chase, John" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Monday, August 29, 2005 1:32 PM Subject: Re: Merging SYSPLEXes -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lance Kopplin - Original Message - From: "Ted MacNEIL" <[EMAIL PROTECTED]> >I don't like this one. Oh dear > Why should I request permission from another poster to post messages? You didn't post a message, you sent an email to my ID. It has the usual Earthlink spam blocking on it. Deal with it. Perhaps Mr. Kopplin would consider not specifying his own email address in the "Reply-To" field of his outgoing emails or posts to IBM-MAIN? I believe IBM-MAIN's listserv is configured to "honor" any "Reply-To" it finds in messages it receives for distribution, as the post to which I am replying inserted Mr. Kopplin's email address instead of IBM-MAIN's address when I clicked the "Reply" button. I had to "manually" insert the IBM-MAIN address to ensure that Mr. Kopplin sees this reply, because I, like teD (and no doubt others), generally refuse to "seek permission from another poster to post". -jc- -- 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 -- 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: Merging SYSPLEXes
- Original Message - From: "Ted MacNEIL" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Saturday, August 27, 2005 6:00 PM Subject: Fw: Re: Merging SYSPLEXes I don't like this one. Oh dear Why should I request permission from another poster to post messages? You didn't post a message, you sent an email to my ID. It has the usual Earthlink spam blocking on it. Deal with it. If you want to subscribe to the list don't send out this garbage! Spam blocking on my personal ID is against the IBM-Main rules? Most curious. Love and kisses, Lance -Original Message- From: [EMAIL PROTECTED] Date: Sun, 28 Aug 2005 12:21:47 To:[EMAIL PROTECTED] Subject: Re: Re: Merging SYSPLEXes I apologize for this automatic reply to your email. To control spam, I now allow incoming messages only from senders I have approved beforehand. If you would like to be added to my list of approved senders, please fill out the short request form (see link below). Once I approve you, I will receive your original message in my inbox. You do not need to resend your message. I apologize for this one-time inconvenience. Click the link below to fill out the request: https://webmail.pas.earthlink.net/wam/[EMAIL PROTECTED]&id=1e9pUK4BE3Nl34f0 -teD In God we Trust! All others bring data! -- W. Edwards Deming -- 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 -- 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: Merging SYSPLEXes
We have implemented a Bronzeplex that sounds like the same thing you are thinking of. We wrote an ISGNQXIT routine that has worked without trouble for a couple of years now. There are several considerations in ISGNQXIT that I can help you with, if you're interested we can do that in email. If you are on or considering 1.6, we found a couple of GRS bugs, one is a new APAR, I can look up the number. And the other is an 0C4 in an FRR, they haven't gotten far enough to assign an APAR number yet. A couple of our people transferred to the IBM testing organization. They looked at what we had done with ISGNQXIT, and what was found with the APAR, and they decided that a Bronzeplex configuration was too far outside a normal configuration to include in their testing. Which was interesting, but if you're considering Bronzeplex, you ought to be aware. Lance - Original Message - From: <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main Sent: Thursday, August 25, 2005 3:25 PM Subject: Merging SYSPLEXes We are looking at merging 2 SYSPLEXes which are 20 KMs apart. Our first step is to create a Bronze-PLEX as described in SG26-6818 Merging Systems into a SYSPLEX. The driver is to achieve single SYSPLEX pricing. We want to create on SYSPLEX where all systems would share the same ISGLOCK structure and SYSPLEX CDS datasets but the 2 original SYSPLEXes would continue to use their own set of DASD volumes. The systems of each original SYSPLEX would continue to use separate control datasets for products like HSM, ACF2, CA1, CA-Solve etc. We understand that there will be issues related to duplicate dataset names and volsers and that there will be some performance impact. What we are most interested in is advise on potential enqueue deadlocks that may be introduced for products which share a control dataset. We would have 2 copies of the control dataset (one for each of the original SYSPLEXes) but the enqueues would be seen by all systems in the new merged SYSPLEX. The products that this applies to are DFHSM, SMS, ACF2, CA1, Control-M, Control-D, CA-Solve, HSC. We are also looking at ISGNQXIT as it can modify resource names which may be useful in specific cases. Anybody used that? Another idea is to capture the enqueue workload from SYSPLEX A and redrive it on SYSPLEX B. Anyone done this? Any comments, recommendations or details of problems experienced would be greatly appreciated. -- 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
