Yeah, I was all set to modify DDR - until I got to the point of re- assembling it and found out that we don't have HLASM. I'm evaluating whether it's worth getting a license for it, and in the meantime I'm exploring other no-cost solutions.
I've built a decent DDR based solution (which we successfully used at our recent DR test) and I'm working to improve the tape management aspect of it. Thanks for the reference to SafeDR. I went to your website and read the info. For what this shop needs most stuff is overkill, although I do admit to missing some of my favorite 3rd party software tools. Brian Nielsen On Tue, 23 May 2006 08:38:32 -0400, John Hall <[EMAIL PROTECTED]> wrote: >On 5/22/06, Brian Nielsen <[EMAIL PROTECTED]> wrote: >> >> I'm trying to use PROP to do some tape EOV processing for DDR. I >> intercept the HCPERP2233I TAPE NOT READY message generated when DDR >> reaches EOV and PROP starts my action routine. So far, so good. >> >> What I want to do is use the GIVE command to transfer the the real tap e >> >> drive from the service machine that's running the DDR to another useri d s >> o >> that I can update the message display on the 3590 tape drive operator >> panel. However, the GIVE command gets message HCPGIV1120E because th e >> >> GIVE command does not complete in a reasonable amount of time. Queryi ng >> >> the tape drive shows there is intervention required on the tape drive (as >> >> expected). Doing a HALT to the real device doesn't help. >> >> I think I'm at a dead end with this approach, but maybe someone knows a >> >> way around this. > > > >We ran into this with our use of DDR in SafeDR. What I found is that DD R >issues the "MOUNT NEXT TAPE" message and then issues a a TAPE RUN follow ed >by another tape command (can't recall which anymore). This has the effe ct >of placing the drive into "Intervention Required". The userid with the tape >drive is effectively hung until the drive is reset (usually by loading a >tape). This means that you can't use the CP SEND command to issue commands >on the server (with the tape drive). (If that's what you're doing.) > >We studying a number of different ways to get around this, finally deciding >that making changes to DDR was in order (along with the associated headache >of supporting them). > >Please allow me to put on my marketing hat and offer some advice regardi ng >backup/restore/DR on VM: Take a look at our SafeDR offering ( >www.SafeSoftware.com). We have "really good pricing". We cost justify this >product in terms of a few days pay. Perhaps even better than this is ou r >SafeDR trial policy. We'll let you trial SafeDR for the duration of you r >POC. This eliminates the need to cobble together a "short term" >backup/restore & DR solution for the POC. Best of all, it makes it really >easy to let us worry about your backup/restore/DR needs and let you worr y >about solving your business needs. > >I'll remove the hat now (ohh, that hat is powerful). > >Thanks, >John > >-- >John Hall (+1) 727-397-6373 Safe Software, Inc. >JohnHall (at) SafeSoftware.Com http://www.SafeSoftware.Com >
