Re: IXFP No Longer Supported
Bruno, Sorry mate, but with PPRC the Device End will come back to the Host whether the write to the Site B Bay succeeds or fails. This means lost data, even with PPRC Synchronous Remote Copy. Same is true for Synchronous Remote Copy using SRDF and TrueCopy. You have to be running PPRC with CRITICAL(YES), SRDF DOMINO, or TRUECOPY FENCELEVEL(DATA) to have the scenario you describe. Ron PS Glad to see this terrific thread is still running while I was away. If a plane strikes ( forget the laser beam :-) ) one of my bay,i am OK,i still have my site B with proper data because device end comes back only once secondary is written . -- 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: IXFP No Longer Supported
--- snip --- In my case ,I run a // sysplex on 2 distant sites I have protected my environment against hardware failure by PPRCing (synchronous) the entire siteA DASD bay on siteB bay . If a plane strikes ( forget the laser beam :-) ) one of my bay,i am OK,i still have my site B with proper data because device end comes back only once secondary is written . --- snip --- A disaster rarely happens in an instant, most likely it is spread out over some finite time. It could be that one of your DASD boxes has failed in site A, but others in site A are still working. PPRC (I'm only talking about native PPRC) for the working DASD will continue to transfer the data to site B. Is this what you really want? 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: IXFP No Longer Supported
John Ticic wrote: --- snip --- In my case ,I run a // sysplex on 2 distant sites I have protected my environment against hardware failure by PPRCing (synchronous) the entire siteA DASD bay on siteB bay . If a plane strikes ( forget the laser beam :-) ) one of my bay,i am OK,i still have my site B with proper data because device end comes back only once secondary is written . --- snip --- A disaster rarely happens in an instant, most likely it is spread out over some finite time. It could be that one of your DASD boxes has failed in site A, but others in site A are still working. PPRC (I'm only talking about native PPRC) for the working DASD will continue to transfer the data to site B. Is this what you really want? That's why proper planning is important in DR scenario. Sometimes it is necessary to put all the data on one DASD controller, however not always. You can also use HDS boxes, which has a feature to coordinate PPRC consistency across boxes. You can divide your data (depend on application(s)) across controllers to have consistent copy, even in rolling disaster scenario. You can use GDPS, asynchronous copy, -- Radoslaw Skorupka Lodz, Poland -- 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: IXFP No Longer Supported
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Bruno Sugliani On Sat, 11 Mar 2006 14:13:23 -0600, Ed Gould [EMAIL PROTECTED] wrote: I would not want to be responsible to management if a disaster struck after you initiated the snap short Its just like any other backup procedure it has to fully complete before you have a real copy. Ed and Ron you guys are speaking about 2 different matters : Ed's concern is about running a production and assuming the risks : You start an instant copy of your drives at 03.00.00 AM . One second later at 03:00.01 all your source drives are destroyed by some alien high power laser beam ! do you have a valid copy ? AFAIK : NO you are dead So at 03:00.00 you start a conventional backup process, and at 03:00.01 the same disaster occurs. Are you not in the same boat?? -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
Re: IXFP No Longer Supported
I would, however, concur that the copy is not instantaneous. Establishing the FlashCopy relationship for 300 - 400 drives takes us somewhere on the order of a minute, so you must, for example, suspend DB2 updates and some other update activities during the establishment process to be sure that you have consistent volume backups that will actually be usable for a Disaster Recovery. Flashcopy has a consistent flash mode that makes it unnecessary to suspend application updates, as long as the application is a logged system doing dependant writes (such as DB2). Although the consistent mode was available with Flashcopy V2, the z/OS support for it only became available recently. It will be in the next release of FDRINSTANT (due out in April). -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
On Mon, 13 Mar 2006 07:55:52 -0600, Chase, John [EMAIL PROTECTED] wrote: So at 03:00.00 you start a conventional backup process, and at 03:00.01 the same disaster occurs. Are you not in the same boat?? -jc- Yes John ,but somehow no :-)) But as i said it was for the sake of the argument . In my case ,I run a // sysplex on 2 distant sites I have protected my environment against hardware failure by PPRCing (synchronous) the entire siteA DASD bay on siteB bay . If a plane strikes ( forget the laser beam :-) ) one of my bay,i am OK,i still have my site B with proper data because device end comes back only once secondary is written . If some human/application/whatever accident erases my data , i am dead . For these reasons i need some DR backup , and some legal rules oblige me to have these cartridges externalised . To do that , i need a mean , and the easiest way is Db2 log suspend followed by flashcopy and Db2 log resume then dump my flashcopied disks . ( Joel C. Ewing gave a vey nice description of why we cannot make it without log suspend) But as Ron said , Disks are pretty strong these days , raid 5 and 6 are nice securities , etc etc ... Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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: IXFP No Longer Supported
If a plane strikes ( forget the laser beam :-) ) one of my bay,i am OK,i still have my site B with proper data because device end comes back only once secondary is written . If some human/application/whatever accident erases my data , i am dead . For these reasons i need some DR backup , and some legal rules oblige me to have these cartridges externalised . Bruno, you make an excellent point about remote mirrors. Some people seem to think that this replaces backups, but the reality is that if your data is corrupted in some way, then you just have TWO copies of the corrupted data, not much use. There is still a place for backups and I am glad to see you have a good solution. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
You start an instant copy of your drives at 03.00.00 AM . One second later at 03:00.01 all your source drives are destroyed by some alien high power laser beam ! The instant technologies we are speaking of all work within a single disk subsystem, copying from one logical disk to another. Your scenario of the source disks being put out of commission while the target disks are still working, within the same physical disk subsystem, is pretty far-fetched. It would have to be a very precise alien laser beam. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
In a message dated 3/12/2006 12:19:13 P.M. Central Standard Time, [EMAIL PROTECTED] writes: It would have to be a very precise alien laser beam. Murphy is an awfully good shot! Spent many hours recovering disk failures in dual copy/PPRC where the primary failed during the process. -- 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: IXFP No Longer Supported
On Sun, 12 Mar 2006 13:18:54 -0500, Bruce Black [EMAIL PROTECTED] wrote: The instant technologies we are speaking of all work within a single disk subsystem, copying from one logical disk to another. Your scenario of the source disks being put out of commission while the target disks are still working, within the same physical disk subsystem, is pretty far-fetched. It would have to be a very precise alien laser beam. Yes Bruce I know how Flashcopy works . It was for the sake of arguments because everybody is right . And our job is also to foresee whatever may happen to our data center . Mind you ..i've been hit by Murphy too often for my own taste , but he never came with a laser beam On the other hand , many many years ago he came with a boat radar cleaning ( not the proper word ... messing up perhaps ? in english ? )part of the real storage of a CPU located in a north of France harbour . He did it every morning at 06.32 am for a few days before someone figured that it was the departure time of the ferry to UK. This Murphy has resources at his disposal you can't believe :-)) Bruno -- 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: IXFP No Longer Supported
This Murphy has resources at his disposal you can't believe And, on the 8th day God said: OK, Murphy. You take over! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Ed, That's a straw man! How many decades has it been since anyone made a box with Dual Copy? We are talking about instant split capabilities of In system replication - Shadowimage, Flashcopy, Timefinder and Snapshot. We are not talking about alien laser beams - we are talking Disaster Tolerant Storage (that's a RAID Advisory Board specification). Are we serious? For more than ten years we have been buying storage that takes our mainframe data and cuts it up onto millions, billions and trillions of FBA blocks, which are then striped, chunked and copied all over significantly less disk drives than MVS thinks it has. And how do we access this stew of data? Through maps and pointers. That's how. And because a copy is created through maps and pointers we are debating that this is some sort of additional risk from a disk drive failure? Well get it right - in the same parity group it has to be two disk drive failures for RAID-1 and RAID-5 (HDS, IBM and EMC), and three disk drive failures for RAID-6 (HDS and SUN/STK). Instead of talking about alien laser beams, do your homework with MTBF and MTTR (sparing time) to figure out those probabilities. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Monday, 13 March 2006 2:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported In a message dated 3/12/2006 12:19:13 P.M. Central Standard Time, [EMAIL PROTECTED] writes: It would have to be a very precise alien laser beam. Murphy is an awfully good shot! Spent many hours recovering disk failures in dual copy/PPRC where the primary failed during the process. -- 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: IXFP No Longer Supported
Well get it right Ed, I have made this comment before! Things have changed since you retired! Some things you may have right. But, in general, the world has moved on. Array technology has improved. Copy services have improved. LE/COBOL has improved. Either keep up with the technology, or sound like you're talking out of the wrong orifice. I found, with 5 months (involuntary) off, I missed some advances. And, coming back to work at a shop that was less sophisticated than the one I left, I missed a few more. Keep up, or shut up. Talking about the problems from 'my day' is just a trip down Nastalgia Lane. And, it is not a productive use of anybody's time! And, the laser beam argument is way over the top! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
In a message dated 3/12/2006 3:13:24 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Instead of talking about alien laser beams, do your homework with MTBF and MTTR (sparing time) to figure out those probabilities. Think you're missing the point again. _http://www.storkeyandco.com/Tools/Risk_Management/risk_management.html_ (http://www.storkeyandco.com/Tools/Risk_Management/risk_management.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: IXFP No Longer Supported
Ted MacNEIL wrote: I don't claim to speak for Ted, but I took his comments as being along the lines of what I mentioned earlier - that the tasks of setting up the environment after the snaps are done isn't an immediate thing. Exactly. As I said, How soon can I use the snap'd data? That is the key! Is a snap IPLable? Yes, as other answered, it is IPLable, it is backup-able, copy-able, etc. Just like any other volume. Immediately. No wait for anything. There's also some disadvantage, not mentioned here: That copy could kill your performance. Could kill doesn't mean always kill. It depends. Snapshot, when is done, cost nothing (in terms of performance). However if you plan to write the copy extensively, it can hurt. FlashCopy has two flavors, one of them copy tracks in the background, so, it hurts even if you don't do anything with the copy. MMV, etc. I described my observations. -- Radoslaw Skorupka Lodz, Poland -- 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: IXFP No Longer Supported
[EMAIL PROTECTED] wrote: In a message dated 3/12/2006 12:19:13 P.M. Central Standard Time, [EMAIL PROTECTED] writes: It would have to be a very precise alien laser beam. Murphy is an awfully good shot! Spent many hours recovering disk failures in dual copy/PPRC where the primary failed during the process. ... Dual copy and PPRC are both distinctly different from FlashCopy. Both require physical movement of data for the copy to be valid and usable and thus have a window that is orders of magnitude larger for Murphy to hit. FlashCopy is only within the same DASD Subsystem, and creating the virtual copy (which may eventually become a physical copy) only requires building some internal bit table in the subsystem controller to indicate which tracks have been copied and must be read from the target device (none initially) versus those that must be read from the source device and flagging the devices as being in a FlashCopy relationship. Any physical movement of data occurs later, if at all. I would, however, concur that the copy is not instantaneous. Establishing the FlashCopy relationship for 300 - 400 drives takes us somewhere on the order of a minute, so you must, for example, suspend DB2 updates and some other update activities during the establishment process to be sure that you have consistent volume backups that will actually be usable for a Disaster Recovery. The establishment time is short enough that this appears to affected users as a short-term period of bad response rather than a system outage, and users that only need read access to data shouldn't even see an interruption. If you incorrectly assume that multi-volume FlashCopy is instantaneous and take no precautionary actions to insure data consistency, you are likely to end up with inconsistencies in your DB2 tables, catalogs out of sync with datasets on other volumes, etc., etc. Just initiating FlashCopy is obviously only part of a DR solution. To have the data usable for an actual Disaster Recovery after loss of your computer facility obviously requires that some physical movement of data to an offsite location must have completed. Any disaster that intervenes before this has occurred means you must recover from the previous DR backups with potential loss of intervening transactions. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: IXFP No Longer Supported
suspend DB2 updates and some other update activities during the establishment process to be sure that you have consistent volume backups that will actually be usable for a Disaster Recovery. Not if you are also copying journals. In-flights are handled by that. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Ed, I really don't see your point - do I need a secret decoder ring or something? The website you sent is talking about DR - we are talking about IN SYSTEM REPLICATION!!! Is an instant backup copy instant - well if you can use it instantly it must be. Will the pointer based copy survive a disk failure or two - damn right it well. It will survive power failure, cache board failure, FC-AL path failure, Microprocessor failures, Host Channel failures and myriad other failures. Can you use it to make off-site back-ups - yeah sure, that's probably what 30-50% of instant copies get used for. Can you create instant copies in off-site vaults - of course not. The copy of the data has to exist there. That's called Remote Copy and it's not instant. Can you create instant copies of Remote Copied data - sure thing. That's what Storage based Consistency Groups are for. I haven't missed the point 'cause I'm sticking with the topic. If you want to talk DR then start another thread. The website you referenced does raise points about protection against virus. We have many sites that are using instant split technology to mitigate risk against problems such as virus by snapping their core business data at regular intervals. Some shops every hour, and some shops every eight hours and some shops somewhere in between, The point is the INSTANT COPY creates a recovery point instantly! Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Monday, 13 March 2006 6:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported In a message dated 3/12/2006 3:13:24 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Instead of talking about alien laser beams, do your homework with MTBF and MTTR (sparing time) to figure out those probabilities. Think you're missing the point again. _http://www.storkeyandco.com/Tools/Risk_Management/risk_management.html_ (http://www.storkeyandco.com/Tools/Risk_Management/risk_management.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: IXFP No Longer Supported
Joel, If you are using At-Time split with Shadowimage then you don't have to do anything from the Host side except tell the Storage Controller(s) what time the Point in Time should be. It is instant and consistent. If you're splitting Shadowimage Volumes using the archaic PPRC commands then the time to issue the commands can be lengthy, but that has more to do with ANTRQST then the storage. BCM has substantially greater parallelism. Ron I would, however, concur that the copy is not instantaneous. Establishing the FlashCopy relationship for 300 - 400 drives takes us somewhere on the order of a minute, so you must, for example, suspend DB2 updates and some other update activities during the establishment process to be sure that you have consistent volume backups that will actually be usable for a Disaster Recovery. The establishment time is short enough that this appears to affected users as a short-term period of bad response rather than a system outage, and users that only need read access to data shouldn't even see an interruption. If you incorrectly assume that multi-volume FlashCopy is instantaneous and take no precautionary actions to insure data consistency, you are likely to end up with inconsistencies in your DB2 tables, catalogs out of sync with datasets on other volumes, etc., etc. -- 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: IXFP No Longer Supported
Ted, At The last place I worked they were mirroring 160+ volumes of work. I did not design it but I sure as hell wouldn't have sent the data line to NY via Denver (we were in Chicago). The discrepancy I am (and have had others confirm it on here) concerned about that there is some time before the copy is done, it is done under the covers in the control unit. It may also involve some cpu activity to accomplish this. Has this changed? I don't think so, as people on here talk about it. Right now all I hear on here (except from 1 or 2 people) is that it is instant. I disagree, the control unit may move some pointers around but there still has to be some data movement and with the amounts of data that are being talked about there is no way (short of breaking the rules of physics) that this can be done *INSTANTLY*. Moving pointers around takes *SOME* time (albeit small) data movement takes some time either small or large (depending on amount). Now if you want to say the duplication is fast, I will agree but instant? No sorry. We are not talking about instant mash potatoes here. We are talking reality and in my universe saying something is instant means less than 1 second. As to my retirement you bring this up like you bring your ex up. Why bother, get over them. Ed On Mar 12, 2006, at 12:00 AM, Ted MacNEIL wrote: Well get it right Ed, I have made this comment before! Things have changed since you retired! Some things you may have right. But, in general, the world has moved on. Array technology has improved. Copy services have improved. LE/COBOL has improved. Either keep up with the technology, or sound like you're talking out of the wrong orifice. I found, with 5 months (involuntary) off, I missed some advances. And, coming back to work at a shop that was less sophisticated than the one I left, I missed a few more. Keep up, or shut up. Talking about the problems from 'my day' is just a trip down Nastalgia Lane. And, it is not a productive use of anybody's time! And, the laser beam argument is way over the top! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Ted, I don't think you're right about this. Copying the DB2 archive log journal volumes doesn't prevent the problem if the tables and journals are on separate volumes and the volume copies are done by any process that is not exactly time-synchronized across all volumes. If the copies are offset by even a few milliseconds you have the potential for a later copy of the active log volume to indicate a successful table update has occurred, while the volume copy of the volume containing the actual table may have occurred prior to the physical update and not contain the update. Similarly, if the journal volume is copied earlier, it may not reflect updates that could need to be backed out while the updated tables on a volume copied later may have been updated by the time that volume copy is made. DB2 journaling is designed to guarantee a known state of affairs on system DASD in the event of catastrophic failure. DB2 does this by using synchronous writes to guarantee that physical changes on DASD occur in the order (1)write table row pre-image to archive log, (2)update table row, (3)write updated image to archive log. Once you introduce asynchronous volume copy operations into the picture and different volumes are involved, depending on the order of the copies you introduce the possibility that your volume copies may contain (1) and (3) without containing the effect of (2)(loss of update); or perhaps the effect of (2) without (1) and (3) (a problem if DB2 recovery during DR needs to back the change out, or should forward recovery be needed after initial DR). You may not necessarily get an error out of DB2 during DB2 recovery using a system built from the copied volumes: if DB2 doesn't see archive log entries corresponding to (1), it has no way of knowing that the update was in-flight; and if DB2 sees both (1) and (3), it will assume update (2) must be present since it must have been successfully written prior to (3). Last time we checked, prior use of DB2 SUSPEND to freeze further table updates is the technique advised in the IBM manuals (Redbook?) to avoid DB2 data corruption in copies created through use of FlashCopy to copy multiple volumes containing DB2 tables and logs. Ted MacNEIL wrote: suspend DB2 updates and some other update activities during the establishment process to be sure that you have consistent volume backups that will actually be usable for a Disaster Recovery. Not if you are also copying journals. In-flights are handled by that. -teD ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: IXFP No Longer Supported
Ed Ted, At The last place I worked they were mirroring 160+ volumes of work. I did not design it but I sure as hell wouldn't have sent the data line to NY via Denver (we were in Chicago). Well that would be Remote Copy Ed, and not In System Replication. No-one is disputing that Copying and resynching with Remote Copy software is not instant. Ron -- 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: IXFP No Longer Supported
Ed, Ed. Ed. what are you amazed about exactly? The instant snap is still an instant snap - nothing in this thread changes that. In fact it reinforces the concept with the statement copy is immediately available before the physical tracks are copied. You really don't understand this stuff, do you. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Saturday, 11 March 2006 1:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported On Mar 8, 2006, at 9:42 AM, Bruce Black wrote: I understand the idea that the copy is immediately available before the physical tracks are copied and was just wondering what kind of impact the background copy would have on the foreground tasks running against the same physical disks. Rex, that is an interesting question on which I have seen very little data. All of the replication technologies which depend on a background copy (almost all of them) have to have some impact on performance. I am told that the background copies are generally lower priority than host-initiated I/Os, but I have to believe that they have some impact. If you start the copies for hundreds of volumes simultaneously (such as when you are initiating point-in- time backups) all that I/O has to have an impact on normal I/O. But I have never seen any vendor or user speak of it. Hopefully that means that it is just not noticeable. Call me amazed... but not long ago on here.. this was instantaneous.. now its some amount of time.. Did there just happen to by a hole in the space time continuum (and only for certain people?). Ed -- 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: IXFP No Longer Supported
On Mar 11, 2006, at 1:48 PM, Ron and Jenny Hawkins wrote: Ed, Ed. Ed. what are you amazed about exactly? The instant snap is still an instant snap - nothing in this thread changes that. In fact it reinforces the concept with the statement copy is immediately available before the physical tracks are copied. You really don't understand this stuff, do you. Ron --SNIP I am pretty sure I understand it in my frame of reference. I think the instant is flat out *WRONG*. As Bruce and others indicate the data can take some time to completely copy. Leaving your instant somewhere yesterday that started and may take X amount of time to *FULLY* complete . I contend that the copy is not fully complete until the last byte has been transferred from the primary. If I understand your view as soon as the process (starts) its complete, no? I would not want to be responsible to management if a disaster struck after you initiated the snap short Its just like any other backup procedure it has to fully complete before you have a real copy. Ed -- 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: IXFP No Longer Supported
On Sat, 11 Mar 2006 14:13:23 -0600, Ed Gould [EMAIL PROTECTED] wrote: I would not want to be responsible to management if a disaster struck after you initiated the snap short Its just like any other backup procedure it has to fully complete before you have a real copy. Ed and Ron you guys are speaking about 2 different matters : Ed's concern is about running a production and assuming the risks : You start an instant copy of your drives at 03.00.00 AM . One second later at 03:00.01 all your source drives are destroyed by some alien high power laser beam ! do you have a valid copy ? AFAIK : NO you are dead Ron's line is He starts an instant copy at 03.00.00 at 03.00.01 he wants tu use it for some backup process or whatever , Can he do it ? Yes he can But these are 2 different things . I understand Ed because like him i am also running a shop ,and can't rely on such theory , although i know i can use it immediately to create backup and ship it somewhere . but that is not an immediate copy , it is just a make believe copy my 2 cents worth Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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: IXFP No Longer Supported
I understand Ed because like him i am also running a shop ,and can't rely on such theory Ed is NOT running a shop! Ed is retired. Unfortunately, technology has moved since. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
On Sat, 11 Mar 2006 16:06:49 -0500, Bruce Black [EMAIL PROTECTED] wrote: Ed, let me have Scotty beam you up and explain it... Sorry, Scottie is not available (actually he's dead) so let me try again. Right So he cannot destroy the source copies after one second yeah .. it's weekend grin Bruno -- 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: IXFP No Longer Supported
In a message dated 3/11/2006 1:51:16 P.M. Central Standard Time, [EMAIL PROTECTED] writes: copy is immediately available before the physical tracks are copied. I can tell you how the IBM ESS (aka 2105) FlashCopy does it. At 03:00:00:00 you execute a TSO command (or use some other means to send the I/O request to the 2105) to establish a FlashCopy relationship between volume X and volume Y with the NOCOPY option specified. At 03:00:00:10 (or thereabouts) the 2105 has set enough information inside its control storage so that the net effect is that volume Y now looks exactly like volume X from the point of view of software that tries to access volume Y. The reason you specified the NOCOPY option is so that there will never be any copy of volume x moved onto volume Y. The details are in the devil: Whenever some software (any software - could be a backup job or something else) attempts to read track Z on volume Y, the 2105 checks to see if track Z on volume X was altered at any time after 03:00:00:10. If it has not been so altered, then the 2105 redirects the I/O aimed at volume Y onto volume X instead but just for track Z. Next part of the microcode: whenever any software writes onto track W on volume X after Y was declared to be a mirror of X, then the 2105 first copies track W from volume X onto its corresponding (same CCHH) location on volume Y before allowing the write operation to proceed onto track W on volume X. So if software attempts to read track W from volume Y, then the 2105 allows the I/O to go to volume Y, as Y now contains a valid copy of track W from volume X as that track was at 03:00:00:10. The only tracks on volume Y that will ever contain valid copies of their corresponding tracks on X are those tracks on X that are altered with some kind of write operation after the FlashCopy relationship was established. The intent is for backup software to read all the tracks that it wants to back up from what it thinks is volume Y. Presumably most of the read requests will end up going to volume X if those tracks were never altered since the FlashCopy relationship was established hours earlier. Some small fraction of the read requests will end up going to volume Y for the tracks on X that were altered after the FlashCopy relationship was established. The NOCOPY option allows you to make valid point-in-time backup copies of data from volume X with the minimum amount of controller overhead (i.e., having to copy tracks from X to Y). Only the tracks that are about to be changed are first copied to Y and then the write is allowed to go through to X. Once track W on volume X has been copied, it is never copied again. The 2105 is smart enough to remember which tracks it has copied. Is the copy instantaneous? Yes and no. First define copy and then we can answer. The backup copy on tape which you remove from the data center and ship to the vault is not finished until all 10,000 cylinders on volume X have been read by the backup process. The data still has to be read by software and transferred to the output file (either tape or another DASD). You can't copy 10,000 cylinders of data in 1/10 of one second. Unless the data center is hit by a space alien's laser bomb before the backup job finishes, then you have a good backup copy available for whenever you feel like finally getting around to running the backup job (hours or days later if you like). At some time after your backup copy process is complete, you execute another FlashCopy command, this time to break the relationship. And after that you can use volume Y again for any purpose. But please be aware that almost never will volume Y be an exact, full copy of volume X. Do not use it as a copy of X. The intent of FlashCopy is very different. IBM has several different hardware copy options from which to choose now: XRC, PPRC, FlashCopy, Dual Copy, Snapshot, and Concurrent Copy. They work differently from each other. Bill Fairchild -- 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: IXFP No Longer Supported
Rex, Glad the thread was useful. Now the sales guys have to step up to the plate and make sure you save some money... Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Wednesday, 8 March 2006 7:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported Thanks, Ron. I spent a couple minutes on the HDS web site and somehow missed the fact that the NSC55 supports ESCON. Also, my tongue was firmly in cheek when I suggested the idea of plugging a FICON device into an ESCON cable. :-) I didn't realize that once the initial copy was done, that subsequent copies would only recopy the changed tracks (even tho it makes perfect sense). My thought behind asking the wall clock involved was just curiosity and wondering what the actual impact was to the box to be doing the data movement in the background. I understand the idea that the copy is immediately available before the physical tracks are copied and was just wondering what kind of impact the background copy would have on the foreground tasks running against the same physical disks. Thanks for the info. Rex -- 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: IXFP No Longer Supported
I understand the idea that the copy is immediately available before the physical tracks are copied and was just wondering what kind of impact the background copy would have on the foreground tasks running against the same physical disks. Rex, that is an interesting question on which I have seen very little data. All of the replication technologies which depend on a background copy (almost all of them) have to have some impact on performance. I am told that the background copies are generally lower priority than host-initiated I/Os, but I have to believe that they have some impact. If you start the copies for hundreds of volumes simultaneously (such as when you are initiating point-in-time backups) all that I/O has to have an impact on normal I/O. But I have never seen any vendor or user speak of it. Hopefully that means that it is just not noticeable. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
Ted, How long is a piece of string? The volumes are available instantly. The time to IPL would depend on the tailoring required by your particular site - that is an issue the storage cannot address. How soon can you move the data offsite? As quickly as you can start your backup jobs. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, 6 March 2006 8:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported Ted, I didn't search the archives, but I believe we clarified that when using Snap, Flash, etc, access to the copied data IS immediate, even if the vendor's implementation requires that the data be copied in the background.Depending on the circumstances, the housekeeping tasks which are NOT part of copying the data may take a noticeable time How soon after I snap can I IPL? How soon can I move the data offsite? - -teD -- 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: IXFP No Longer Supported
As I said, How soon can I use the snap'd data? That is the key! Is a snap IPLable? From the perspective of Snap/Flash/etc, yes, the copied data is immediately usable, even for IPL. If you need to do additional things to make the copy IPLable, that is outside this discussion. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
I don't know how to plug the FICON into my existing ESCON cables Don't use them myself, but FICON to ESCON converters? McData Intrepid? Jeffrey Deaver, Senior Analyst, Systems Engineering 651-665-4231 -- 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: FICON ESCON (was: IXFP No Longer Supported)
I don't know how to plug the FICON into my existing ESCON cables They are different jacks. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Rex, With the NSC55 I would suggest ordering ESCON channels to solve your plug problem - you can have up to 16 ESCON channels :) Shadowimage doesn't up and start copying 200 volumes in one hit. There is a maximum number of Logical Devices (volumes) that are being copied at any one time, and this can change with model and microcode. The copies always queue behind host requests to the disks (cache misses), and any potential impact can be further reduced by reducing the number of tracks used in each copy IO. The impact is really quite low, and after the first copy you will be refreshing the volumes, not copying. This means changed data only. The wall clock time depends on how much other activity is taking place, but as we discussed in another thread you don't have to wait for Shadowimage, Flashcopy or Timefinder to move the data - the copies can be used immediately. I don't have times for the NSC55, but I've had an inactive 9960 complete full copies at 6GB/minute - I expect the NSC55 is faster. Depending on your needs you can also use the Flashcopy Compatible add-on to Shadowimage and use FCNOCOPY with DFDSS which causes the copy to operate as a Copy-On-Write, where only changed data is written to the target. BTW something you may like with latest generation software is you can get an IO Consistent Point-in-Time across the snapped volumes without stopping your applications on the Primary LPAR. I don't think the Snapshot you are running supported this. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Tuesday, 7 March 2006 11:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported Ron and Timothy, First of all a caveat - I would love to look at either/both the NSC55 and the DS6800 but unfortunately I don't know how to plug the FICON into my existing ESCON cables (7060 with only ESCON and -horrors- parallel channels). (Will be trying to talk mgmt into a new box in the next week or so) That being said, if I were to use shadowimage or IBM's flavor of instant replication where the actual copy of the volumes occurs in the background, what kind of performance impact does the actual copy have on the array if for example 200 3390-3 volumes are snapped? In addition to that, what is the typical wall clock time for copying a full 3390-3 volume in the background? I am sure both software products use some kind of I/O queuing algorithm to do the copies at a lower priority than real I/Os but they have to have some kind of impact, don't they? Rex -- 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: IXFP No Longer Supported
Thanks, Ron. I spent a couple minutes on the HDS web site and somehow missed the fact that the NSC55 supports ESCON. Also, my tongue was firmly in cheek when I suggested the idea of plugging a FICON device into an ESCON cable. :-) I didn't realize that once the initial copy was done, that subsequent copies would only recopy the changed tracks (even tho it makes perfect sense). My thought behind asking the wall clock involved was just curiosity and wondering what the actual impact was to the box to be doing the data movement in the background. I understand the idea that the copy is immediately available before the physical tracks are copied and was just wondering what kind of impact the background copy would have on the foreground tasks running against the same physical disks. Thanks for the info. Rex Rex, With the NSC55 I would suggest ordering ESCON channels to solve your plug problem - you can have up to 16 ESCON channels :) Shadowimage doesn't up and start copying 200 volumes in one hit. There is a maximum number of Logical Devices (volumes) that are being copied at any one time, and this can change with model and microcode. The copies always queue behind host requests to the disks (cache misses), and any potential impact can be further reduced by reducing the number of tracks used in each copy IO. The impact is really quite low, and after the first copy you will be refreshing the volumes, not copying. This means changed data only. The wall clock time depends on how much other activity is taking place, but as we discussed in another thread you don't have to wait for Shadowimage, Flashcopy or Timefinder to move the data - the copies can be used immediately. I don't have times for the NSC55, but I've had an inactive 9960 complete full copies at 6GB/minute - I expect the NSC55 is faster. Depending on your needs you can also use the Flashcopy Compatible add-on to Shadowimage and use FCNOCOPY with DFDSS which causes the copy to operate as a Copy-On-Write, where only changed data is written to the target. BTW something you may like with latest generation software is you can get an IO Consistent Point-in-Time across the snapped volumes without stopping your applications on the Primary LPAR. I don't think the Snapshot you are running supported this. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Tuesday, 7 March 2006 11:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported Ron and Timothy, First of all a caveat - I would love to look at either/both the NSC55 and the DS6800 but unfortunately I don't know how to plug the FICON into my existing ESCON cables (7060 with only ESCON and -horrors- parallel channels). (Will be trying to talk mgmt into a new box in the next week or so) That being said, if I were to use shadowimage or IBM's flavor of instant replication where the actual copy of the volumes occurs in the background, what kind of performance impact does the actual copy have on the array if for example 200 3390-3 volumes are snapped? In addition to that, what is the typical wall clock time for copying a full 3390-3 volume in the background? I am sure both software products use some kind of I/O queuing algorithm to do the copies at a lower priority than real I/Os but they have to have some kind of impact, don't they? Rex -- 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: IXFP No Longer Supported
I don't know how to plug the FICON into my existing ESCON cables (7060 with only ESCON and -horrors- parallel channels) Will the 7060 be around? There's a March 31, 2007, impending end of service date for z/OS 1.4 and 1.5, and these are the last z/OS releases to run on 31-bit hardware. I think you're a z/OS shop, right? I don't know of a 3U (or anything except bigger U) storage product with ESCON connection built in. So it'd be an ESCON-FICON converter box as someone mentioned, but I'm not too familiar with those. Hope that helps! - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
I agree with what you say, but Rex specifically said rebuilding a test system which to me implied refreshing a set of volumes rather than a dataset level operation. I think you could read it either way, depending on the type of test system. For example, rebuilding test data bases might be at the dataset level. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
Ron and Bruce, Actual SnapShotting (is that a word?) of the 150 volumes takes seconds to run. The rest of the time is involved in running the cleanup jobs (modifying system datasets, bringing volumes online/offline, IPLing the test LPAR, etc. Ron, You said Perhaps you're looking for the specific technology, rather than how other ways, means and costs meet your process requirement.. I would be interested in looking at other ways of being able to do this, but unfortunately cost is slightly prohibitive. The viewpoint I'm looking at is that the RVA is bought and paid for, and I would need to buy 3 TB of disk to replace it. With the mainframe is going away so don't spend any money on it mentality at my shop, I'm pretty much stuck where I'm at. That is unless somebody can convince me that for the maintenance costs on my RVA I can get 3 TB of disk along with near-instantaneous dataset and volume level replication software. If you can do that, I'm all ears! :-) -- 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: IXFP No Longer Supported
The rest of the time is involved in running the cleanup jobs (modifying system datasets, bringing volumes online/offline, IPLing the test LPAR, etc. This has been discussed recently, here. Snapshots are fast. Being able to use the data is not immediate. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Rex, If you followed the friendly rivalry of Tim and I you'll see that 3TB of Mainframe disk is pretty small in today's form factors. All you need is 16x300GB spindles in RAID-6 config behind an NSC55 and you have your 3TB. And as for Maint vs new price, well replacing old disk on this basis makes the storage world go round. Set your price and see if HDS, IBM or EMC will step up to the plate with 3TB and Shadowimage. You can also go to Sun and HP if your company has a stronger relationship with them. You can also carve 3TB out of an existing storage controller being used for the Open Systems servers, which would be even cheaper again. Ron I would be interested in looking at other ways of being able to do this, but unfortunately cost is slightly prohibitive. The viewpoint I'm looking at is that the RVA is bought and paid for, and I would need to buy 3 TB of disk to replace it. With the mainframe is going away so don't spend any money on it mentality at my shop, I'm pretty much stuck where I'm at. That is unless somebody can convince me that for the maintenance costs on my RVA I can get 3 TB of disk along with near-instantaneous dataset and volume level replication software. If you can do that, I'm all ears! :-) -- 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: IXFP No Longer Supported
This has been discussed recently, here. Snapshots are fast. Being able to use the data is not immediate. Ted, I didn't search the archives, but I believe we clarified that when using Snap, Flash, etc, access to the copied data IS immediate, even if the vendor's implementation requires that the data be copied in the background.Depending on the circumstances, the housekeeping tasks which are NOT part of copying the data may take a noticeable time, but if you are copying to preallocated target datasets even this can be eliminated. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
Ted, I didn't search the archives, but I believe we clarified that when using Snap, Flash, etc, access to the copied data IS immediate, even if the vendor's implementation requires that the data be copied in the background.Depending on the circumstances, the housekeeping tasks which are NOT part of copying the data may take a noticeable time How soon after I snap can I IPL? How soon can I move the data offsite? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Bruce, I don't claim to speak for Ted, but I took his comments as being along the lines of what I mentioned earlier - that the tasks of setting up the environment after the snaps are done isn't an immediate thing. Rex snip This has been discussed recently, here. Snapshots are fast. Being able to use the data is not immediate. Ted, I didn't search the archives, but I believe we clarified that when using Snap, Flash, etc, access to the copied data IS immediate, even if the vendor's implementation requires that the data be copied in the background.Depending on the circumstances, the housekeeping tasks which are NOT part of copying the data may take a noticeable time, but if you are copying to preallocated target datasets even this can be eliminated. /snip -- 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: IXFP No Longer Supported
Mainframe disk is pretty small in today's form factors. I'm somehow behind in terminology. I've seen a few posts that state something is #U. EG: 3U. What does that mean? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
I don't claim to speak for Ted, but I took his comments as being along the lines of what I mentioned earlier - that the tasks of setting up the environment after the snaps are done isn't an immediate thing. Exactly. As I said, How soon can I use the snap'd data? That is the key! Is a snap IPLable? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
I'm somehow behind in terminology. I've seen a few posts that state something is #U. EG: 3U. What does that mean? 1U = 1.75 inches in height, and is the U from RU or rack unit. Its a measurement of space for something to take in the standard 19 inch racks used for everything these days. Used to also be called 1 pizza box, although I don't hear that much anymore. I do believe the measurements are all left over from the old telephone company days... and looking in Wikipedia I see that's right. Want to read more? http://en.wikipedia.org/wiki/19-inch_rack Jeffrey Deaver, Senior Analyst, Systems Engineering 651-665-4231 -- 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: IXFP No Longer Supported
As I said, How soon can I use the snap'd data? That is the key! Is a snap IPLable? We snap our entire production environment and can IPL immediately after the snap. Seperate LPAR definition with different IPL address and parmlibs for the test environment are maintained from production environment and available for IPL immediately after snap. Its all STK V2X hardware. We also take another, seperate, snap instance for BCP backups. Again, the backups to tape start immediately after the snaps are complete. Jeffrey Deaver, Senior Analyst, Systems Engineering 651-665-4231 -- 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: IXFP No Longer Supported
1U is 1.75 inches of height in a standard rack. Therefore a 3U device only takes up 5.25 inches - not a lot of space when compared to an RVA! Mainframe disk is pretty small in today's form factors. I'm somehow behind in terminology. I've seen a few posts that state something is #U. EG: 3U. What does that mean? And I suppose I should fill out what I was thinking here. There are plenty of environments (including Multiprise 3000 environments with built-in storage) in which a whole cabinet (or rack) is a lot of physical space, in reality and/or in management psychology. Mainframe storage is tiny now, at least in the IBM DS6800 case (perhaps others, too). That 3U height holds up to a few terabytes, and those terabytes can be split among multiple types of servers. You can expand in 3U increments if you need more than a few terabytes. That's what enterprise-class storage has become: tiny. (That 3U is also very fast. Not as fast as the big cabinets, but fast.) And tiny investments are quite often easier investments. Funny how people are that way, but there it is. If somebody looks at the thing he/she can't help saying, That's it? That's all you want? Did I mention it's tiny? - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
Timothy, I don't get a commission either... I mentioned the DS6800 because it's tiny, and I don't think the NSC55 is. Is there any other enterprise FICON storage in a 3U package? I'm a software person, so I really don't know, but I find the idea intriguing because a lot of people think of mainframe storage as being massive (at least one cabinet). The NSC55 is just small, not tiny. You can put it in the same 19 rack as the DS6800 if you want :) Ron -- 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: IXFP No Longer Supported
In a message dated 3/5/2006 1:52:08 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I mentioned the DS6800 because it's tiny, and I don't think the NSC55 is. Is there any other enterprise FICON storage in a 3U package? I'm a software person, so I really don't know, but I find the idea intriguing Guess I would like to see it expanded to support all the vendors but there's a Comparison and Advisor at the following link: _http://www-03.ibm.com/servers/storage/disk/product-compare.html_ (http://www-03.ibm.com/servers/storage/disk/product-compare.html) Commensurate with the DR550/DR550 Express rollout. Supports up to 89 Tbytes. -- 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: IXFP No Longer Supported
Rex, The other thing is that we make *extensive* use of the snapshot capabilities and I haven't seen much in the way of other software giving me the capabilities I have with it. Perhaps you're looking for the specific technology, rather than how other ways, means and costs meet your process requirement. Where else can I have 700 volumes of 3390 disk physically sitting on about 200 GB physical and be able to rebuild a test system in about 15 minutes start to finish? Where else do you compress data onto to disk and pay the uncompressed purchase price? Imagine if EMC IBM or HDS asked you to pay for another 600GB because you compressed your datasets with SMS ? And 15 minutes start to finish - it takes that long??? Ron -- 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: IXFP No Longer Supported
Tim, If we're going to do free plugs here, how about comparing the DS6800 to the HDS NSC55. Smells like a USP; goes like a USP; has all the functions of a USP; but comes in a rack and stack kit. (and it can virtualise a DS6800 or a FAS-T for mainframe :)) Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Thursday, 2 March 2006 1:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported How IBM's DS6800 line of storage? It's tiny (3U), reasonably priced, and does support intermixing FCP and FICON on a single unit. (You can have two to eight ports, and each type comes in pairs. So for both FCP and FICON you'd have at least four ports going.) One unit (without expansion) ranges from 0.5 TB to almost 5 TB depending on configuration. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
And 15 minutes start to finish - it takes that long??? We find that when using the various instant replication technologies (FlashCopy, SnapShot, etc), the time to allocate and catalog the output datasets (if they don't already exist) is far longer than the copy time, especially for a large number of datasets. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
Bruce, I agree with what you say, but Rex specifically said rebuilding a test system which to me implied refreshing a set of volumes rather than a dataset level operation. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Sunday, 5 March 2006 3:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported And 15 minutes start to finish - it takes that long??? We find that when using the various instant replication technologies (FlashCopy, SnapShot, etc), the time to allocate and catalog the output datasets (if they don't already exist) is far longer than the copy time, especially for a large number of datasets. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: IXFP No Longer Supported
If we're going to do free plugs here, how about comparing the DS6800 to the HDS NSC55. Sadly, I don't get commissions on either one. In fact, I don't get commissions on anything. I mentioned the DS6800 because it's tiny, and I don't think the NSC55 is. Is there any other enterprise FICON storage in a 3U package? I'm a software person, so I really don't know, but I find the idea intriguing because a lot of people think of mainframe storage as being massive (at least one cabinet). It seemed an appropriate idea for this particular situation -- a very little bit of modern storage that also happens to be shared if you want. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
Pommier, Rex R. wrote: If it's no longer supported does that mean I can quit paying for it? Well, in this case OTC (One Time Charge, typical to open systems) sounds much more reasonable than MLC (monthly LC). It could be even fair to stop receiving fee from *existing* customers. They still support the hardware, though. What sense does it make to support the hardware but not the software that makes it usable? It doesn't make any sense. BTW: What sense does it make to use 6+ year old hardware with capacity comparable to single PC disk ? OK, some smaller (and poor) shops see the sense. In this case I would recommend other vendors storage (second hand). Really cheap, faster, more capacity. -- Radoslaw Skorupka Lodz, Poland -- 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: IXFP No Longer Supported
Part of the problem is that like many others out there, we are getting off the mainframe (and have been for almost 5 years now) and finally pulled the first piece of code off it. Management doesn't want to spend the money on something that's going away. The other thing is that we make *extensive* use of the snapshot capabilities and I haven't seen much in the way of other software giving me the capabilities I have with it. Where else can I have 700 volumes of 3390 disk physically sitting on about 200 GB physical and be able to rebuild a test system in about 15 minutes start to finish? Pommier, Rex R. wrote: If it's no longer supported does that mean I can quit paying for it? Well, in this case OTC (One Time Charge, typical to open systems) sounds much more reasonable than MLC (monthly LC). It could be even fair to stop receiving fee from *existing* customers. They still support the hardware, though. What sense does it make to support the hardware but not the software that makes it usable? It doesn't make any sense. BTW: What sense does it make to use 6+ year old hardware with capacity comparable to single PC disk ? OK, some smaller (and poor) shops see the sense. In this case I would recommend other vendors storage (second hand). Really cheap, faster, more capacity. -- Radoslaw Skorupka Lodz, Poland -- 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: IXFP No Longer Supported
Pommier, Rex R. wrote: Part of the problem is that like many others out there, we are getting off the mainframe (and have been for almost 5 years now) and finally pulled the first piece of code off it. Management doesn't want to spend the money on something that's going away. The other thing is that we make *extensive* use of the snapshot capabilities and I haven't seen much in the way of other software giving me the capabilities I have with it. Where else can I have 700 volumes of 3390 disk physically sitting on about 200 GB physical and be able to rebuild a test system in about 15 minutes start to finish? Sun/STK products (SVA V2X2). You can also convince mgmt that machine can be later used in open systems (my assumption). BTW: mainframe going away seems to be big part of IT industry. It coulb be good business to sell products and services for going away mainframes. IMHO it is also very stable market - a lot of datacenters have been getting rid of mainframes for years. g -- Radoslaw Skorupka Lodz, Poland -- 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: IXFP No Longer Supported
Sun/STK products (SVA V2X2). You can also convince mgmt that machine can be later used in open systems (my assumption). Yes, with a limitation: last time I enquired you couldn't have both fiber channel and FICON on the same V2X2. But Fibre and ESCON was an option. Have heard of shops sharing the device between MF and open, but very few. http://www.sannow.net/products/product_page9.html#specifications ESCON/Fibre Channel mixed ports (V2X2): Minumum 4 ESCON ports and 2 Fibre Channel ports to a maximum of 28 ports, increments of 2 or 4 ESCON ports or 2 or 4 Fibre Channel ports. Jeffrey Deaver, Senior Analyst, Systems Engineering 651-665-4231 -- 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: IXFP No Longer Supported
On Wed, 2006-03-01 at 16:12 +0100, R.S. wrote: Sun/STK products (SVA V2X2). You can also convince mgmt that machine can be later used in open systems (my assumption). Yes, with a limitation: last time I enquired you couldn't have both fiber channel and FICON on the same V2X2. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
How IBM's DS6800 line of storage? It's tiny (3U), reasonably priced, and does support intermixing FCP and FICON on a single unit. (You can have two to eight ports, and each type comes in pairs. So for both FCP and FICON you'd have at least four ports going.) One unit (without expansion) ranges from 0.5 TB to almost 5 TB depending on configuration. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- 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: IXFP No Longer Supported
Well. We are still using an old RAMAC and use IXFP. I do have a question on IXFP Can a pack name be renamed on the fly? Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -Original Message- From: Jim Marshall [mailto:[EMAIL PROTECTED] Sent: Friday, February 11, 2005 3:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IXFP No Longer Supported I reported two problems with IBM's IXFP software last week and Level 2 support called to remind us that as of Saturday, 02/12/2005, IXFP is no longer supported by IBM (SAY WHAT!). I checked with my IBM reps and they tell me this is true. Bottom line is anyone who is running IBM RVA DASD is now no longer supported. Maybe IBM thinks we will all be rushing out to buy new SHARKS. I do not think this was widely publicized and I know it will cause us concern for a while. Is anyone addressing this with IBM and are you finding the same story. JimUS Office of Personnel 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 -- 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: IXFP No Longer Supported
I do not think this was widely publicized and I know it will cause us concern for a while. Is anyone addressing this with IBM and are you finding the same story. IBM has a life-cycle site. They DO announce at least three years before support is dropped. I remember hearing about IXFP a long time ago. It was widely publicised; I'm sorry you didn't hear about. But, it's gone! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
If it's no longer supported does that mean I can quit paying for it? They still support the hardware, though. What sense does it make to support the hardware but not the software that makes it usable? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, February 27, 2006 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IXFP No Longer Supported I do not think this was widely publicized and I know it will cause us concern for a while. Is anyone addressing this with IBM and are you finding the same story. IBM has a life-cycle site. They DO announce at least three years before support is dropped. I remember hearing about IXFP a long time ago. It was widely publicised; I'm sorry you didn't hear about. But, it's gone! - -teD I'm an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
I can't find the announcement that shows where IXFP is withdrawn. Can somebody point me to it? Thanks. Rex -- 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: IXFP No Longer Supported
They still support the hardware, though. What sense does it make to support the hardware but not the software that makes it usable? THAT does not make sense! I missed that because we got off of RAMAC ICEBERG aeons ago. We were on ESS (Shark) in September 2000. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
I can't find the announcement that shows where IXFP is withdrawn. Can somebody point me to it? I am not at work, but I can give you the steps I used to find it. Go to www.IBM.com Enter ILC on the search tab (Information Life Cycle) [If my memory has not failed me, you will see a list of all the software IBM supports, PLUS a row of each letter of the alphabet]. Click on `I`, and page down until you find IXFP. OR, You can wait until I get back to work, tomorrow, and I will cut and paste the main link. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: IXFP No Longer Supported
Hi Jim, You may want to call STK ( Sun ). They have a product called: SVAA ( Shared Virtual Array Administrator ). According to their website, the supported storage systems are: V-Series (SVA) or RVA, any model. HTH Glenn Miller --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V, which has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587, including its group companies, shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- -- 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
