Re: IBM VTFM and Bus-tech virtual tape appliance
Hello We recently implemented the Diligent VTFM virtual tape solution. The VTFM product is something of a mixed bag of worms. While it is performing very well, when the cycles are available, it is not what I would consider a good fit for DR. Since this software has NO standalone compoent and requires a current version of the VDB (Virtual Tape Dababase, a VSAM cluster) to access the virtual volumes, I am having to circumvent these DR issues through other facilities. If you consider that it demands mainframe processor cycles to perform the I/O as well as compression I do not consider this a good tradeoff unless you have 30-40 % of your processor available for Virtual Tape processing. An additional issue we encountered, is the inability to share virtual tapes across systems unless you maintain a common VDB 'and' Tape Catalog (such as CA-1 TMC). We have seperate TMC for each sysplex member and I installed a common VDB, the first time I ran scratch and clean it deleted the virtual tape datasets for the other systems - not good. We are now using a seperate VDB for each sysplex member which means that a virtual tape created on system A is not accessible from any other system than the creator. I do not recommend this product based on my experience with the product. Prior to acquiring VTFM I reviewed the Bus-Tech product, this was about 2 to 3 years ago. This product simply does not have the I/O capacity needed for tape. We were running one (1) bank of 16 3490 drives on two (2) ESCON channels. Our converstions with the vendor indicated that it 'might' be able to equivalent throughput depending on the data. Unless you have a very light tape environment the Bus-Tech solution would not meet your processing requirements. The thing you need to keep in mind is that any mainframe software based Virtual Tape appliance will have to spend processor cycles to not only perform the I/O but to perform the compression we take for granted in the 'traditional' IBM tape hardware. This will take cycles away from 'productive' work for overhead processing. Be very careful when choosing a mainframe Virtual Tape appliance. I do not believe that the technology available today is able to meet tape processing requirements without an abundance of processor. Please feel free to contact me off-list and I will be happy to discuss this environment with you. Robert Rankin MVS Systems Programmer bran...@ci.portland.or.us 503-823-6913 ; 503-984-1384(mobile) 1120 SW 5th Ave Room 450 Portland, Oregon 97204 -Original Message- From: Patty Mabie [mailto:mab...@upstate.edu] Sent: Tuesday, March 03, 2009 9:46 AM To: IBM-MAIN@bama.ua.edu Subject: IBM VTFM and Bus-tech virtual tape appliance Hi, We have an ancient Magstar with A50 controller and 4 B1A drives. Needless to say, it is a bottleneck and we have done what we can to ameliorate. I'm interested in replacing the tapes with one of these virtual tape solutions. I wonder if anyone is using them and, if so, what kind of experience you've had? Also, the VTFM software indicates you can FTP your DR backups off site. Is anyone doing this and recovering at Sungard? Would like your comments on that as well. Thanks, Patty -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OS/390 V2R10 on z9/BC
Is anyone out there running OS/390 V2R10 native (without zVM) on a z9BC processor? With/without compatibility/exploitation ptf's? Robert Rankin MVS Systems Programmer [EMAIL PROTECTED] 503-823-6913 ; 503-984-1384(mobile) 1120 SW 5th Ave Room 450 Portland, Oregon 97204 -- 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
OS/390 V2R4 on Z9
Our production environment is running OS390 V2R4 (9708 PUT). My management wants to purchase a Z9 to replace our aging Multiprise 2003-125 and move our existing OS to run on the Z9. While we know that OS390 V2R4 has not been certified to run on the Z9, my management thinks it possible that it might work anyway. Personally I don't think this is feasible but IBM has done stranger things in the past. Can anyone out there provide more specific information regarding this topic. While I know that there are significant instruction set differences, perhaps V2R4 may not encounter them, I don't know. Has anyone done this? Does anyone know what will happen if we attempt to do this? Bob Rankin City of Portland, Oregon -- 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: Is anyone still running..........................
Here at the City of Portland in Oregon, USA we have OS/390 V2R4 in production on a Multiprise 2003-125 (G3) processor. I am preparing for the installation of a z890 with an implementation of OS390 V2R10 in about 4-6 months. Regards Bob Rankin -Original Message- From: james smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 9:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Is anyone still running.. Given the global nature of this list I was curious if any list members were aware of any financial organization(s) still running Os/390 V2.10 and/or still running on G5/G6 processors. Nice to hear all comments but mainly interested in the financial sector. Regards James F. Smith -- 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
HSM Backup to DASD
Can anyone answer the question : If I were to implement HSM BACKUP to DASD instead of TAPE, can I still enable 'DUPLEX' to send alternate version of backup to another location? In other words, if I change [SETSYS BACKUP(TAPE(3480)) ] to [ SETSYS BACKUP(DASD) ] can I also say [ SETSYS DUPLEX(BACKUP(Y)) ] ? If this is feasible am I able to direct the alternate copy to a specific location? e.g. by volser or storage group if I use SMS. -- 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: DSS RESTORE - how to enforce CONTIG
My experience is that if the IODF is allocated in more than one extent it is unusuable for system IPL/Dynamic Acitivation. This my be different on more current levels of the operating system, we are OS/390 2.4/2.10. Bob Rankin -Original Message- From: Eric N. Bielefeld [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 20, 2006 3:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DSS RESTORE - how to enforce CONTIG Radoslaw, I see no one answered your post from 9-18. Unfortuneatly, I won't either. I did have a question though. Does the IODF have to be in one extent? I don't recall hearing that rule. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - Original Message - From: R.S. [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, September 18, 2006 12:24 PM Subject: DSS RESTORE - how to enforce CONTIG I just encountered the following problem: Restored production IODF from DSS dump and got two-extents file. For obvious reason I didn't want more than 1 extent. g The primary reason was near-full, fragmented volume, which shouldn't have place, however it had place. Q: how can I prevent such multi-extent allocation ? I'd like to have something a'la CONTIG: single extent file or failure. -- 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: Why No S0C7?
The source data contains a valid sign. You will only get a S0C7 abend for an invalid sign. Source data field contains characters 'ABC' this is represented in hex as x'C1C2C3'. The low order byte contains a sign of 'C' which is interpreted as a valid sign (positive). COBOL will pack the field prior to performing the arithmetic. The result of the pack operations will be x'00123C'. The result of the add-packed would be x'00124C'. So, working as designed. -Original Message- From: JONES, CHARLIE [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 10:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Why No S0C7? We are on Z 1.4 and COBOL Rel 3.2.0 The Simple Compile and Go below Allows me to add 1 to 'ABC' and get 124 with no S0C7. Is this normal? Did this test with NUMPROC(NOPFD), NUMPROC(PFD), and NUMPROC(MIG). All were successful. //ZCRSCEJA JOB (DAZC1130,ZCRSCEJ),'COBOL4MVS IVP', // CLASS=A,MSGCLASS=X,NOTIFY=ZCRSCEJ //* //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=1400K, // PARM.LKED='LIST,XREF,LET,MAP', // GOPGM=USECDE //COBOL.SYSIN DD * PROCESS NUMPROC(MIG) 000100 IDENTIFICATION DIVISION. 000200 PROGRAM-ID. USECDE. 003200 ENVIRONMENT DIVISION. 005000 DATA DIVISION. 008400 WORKING-STORAGE SECTION. 77 COUNTERX PIC 999 VALUE 0. 01 BAD-NUMBERPIC 999. 01 BAD-SPACE REDEFINES BAD-NUMBER PIC XXX. 011800 PROCEDURE DIVISION. 013200 001-INITIALIZE. *THIS STATEMENT WILL CAUSE AN LE-SOC7 PERFORM 010-LOOPIT UNTIL COUNTERX EQUAL 100. 034200 601-END-RTN. DISPLAY 'TESTIT EXECUTED WITH NO S0C7 SUCCESSFULY'. GOBACK. 013200 010-LOOPIT. MOVE 'ABC' TO BAD-SPACE. ADD 1 TO BAD-NUMBER. DISPLAY ' BAD-NUMBER: 'BAD-NUMBER ADD 1 TO COUNTERX. 999-END-RTN. EXIT. //LKED.SYSLIB DD //GO.SYSOUT DD SYSOUT=* -- 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
