I'm almost done coding my EOV processing for my DDR based backup system. I, too, stack multiple DDR dumps on tape and never know when I'll hit EOV. I don't have a commercial tape management product at this site, so
I've coded my own specifically to work with DDR's & EOV processing. The long-term key is being able to take the drive away from the userid running DDR when it reaches EOV. I recently openned an APAR with IBM after I got DDR to abend while trying to steal the tape drive at EOV (I issued a HALT I/O in order to allow GIVE or DETACH to succeed). I don't have a VTS or ATL to interface with, but once I can steal the drive without abending DDR,then interfacing to any TLMS should probably be straightforward. In the meantime, I can do it with stand-alone 3590's (telling the operato r what tape to mount, but not yet updating the 3590 operator display panel) and my DDR process interacting with my home grown TLMS. Basically, my DDR process tells my TLMS to start monitoring that userid (via SET OBSERVER). My TLMS runs PROP and watches for the EOV message HCPERP2233I. At EOV my TLMS currently tells the operator what tape to mount. In the future I plan on stealing the drive at EOV to update the 3590 operator display panel, and this would also be the point that commands could be issued to a real TLMS/VTS/ATL to mount a tape. Once th e tape is mounted DDR continues the DUMP. My DDR process examines the DDR output and notices that EOV processing occurred and queries my TLMS to find out what tape number got mounted. My DDR process then continues wit h the remaining volumes it has been requested to DUMP. At completion my DD R process tells my TLMS to stop monitoring it for EOV messages. I still have some major enhancements to make to my DDR process, but it works quite nicely as is - at least for this shop. There are several things I still need to do before others would find it suitable. Brian Nielsen On Fri, 2 Jun 2006 09:51:38 -0500, Tom Duerbusch <[EMAIL PROTECTED]> wrote: >To jump in at the tail end of this discussion..... > >I will be doing DB2/UDB backups, as well as Oracle 10g backups, under >zLinux under z/VM on an IFL. > >Getting messages and routing them to PROP isn't much of a problem. >I'ved had a DDR based backup that used DYNAM/T for VSE as a tape manager >running for over 10 years. The biggest problem is EOV processing. That >ended up being 80% of the code and problems. > >I thought I would eliminate most of the problems by having high >capacity tape drives. However, due to the cost of the media, we are >also looking at stacking via an IBM VTS. Problem is, that the VTS >emulates a 3490 drive and you have 1.2 GB or 2.4 GB emulated tape >volumes. When you fill an emulated volume up, you need to drive EOV >processing. > >Now I haven't filled a volume yet, but it doesn't look like the Linux >world knows much about EOV processing. I've been told TSM understands >the concept, but TSM requires FCP attached tape drives (only uses SCSI >interface for tape), and I'm real hesitant on trying to justify separate >but equal hardware (having two tape subsystems), for a server >consolidation project. > >So, it would be interesting to here, in this discussion, any thoughts >on handliing EOV conditions. > >Thanks > >Tom Duerbusch >THD Consulting > > >>>> [EMAIL PROTECTED] 6/1/2006 4:02 AM >>> >> All you need to do is have VM:Operator send the .MOUNT >Yes indeed, we already needed similar "remote mounts" as the number of >VM >systems was greater that what could be connected with the coax based >3270 >interface to old STK robots. So we intercept VMTAPE manual mount >requests >and ship those to STKACS on another VM system over an RSCS link. >Works >perfectly well. > >> Also, you need to remember to issue [send over to z/OS] the STK >DISMOUNT >> when VM:Operator detects that the end user has DETACHED the tape >drive >Our VMOPER macro even keeps track on who owns a drive, which volser is >mounted, it knows how to handle drives that are GIVEn to other users, >etc. > >> Why not eliminate the linux server, which seems to me to be just ... >I asked that too, answer: this linux server forms some standard >interface on >which you hook other clients, like LMS/VM > >Why does my customer use this LMS/VM SW and the Linux gateway? It all >was >decided by the z/OS folks without really consulting us, the VM group. >As >external advisor, I didn't want to open the discussion again. > >LMS/VM has some other advantages though, mainly the fact that it allows >VM >users to issue more STK commands than just Mount/Dismount. Something >you >probably would not try to create using an RSCS link to the z/OS >console. >======================== ========================= ========================
