Re: IBM VTFM and Bus-tech virtual tape appliance
Thanks for your response and for the others I received offline. I should add that we are a small shop, 225 MIPS, z9 2096-s01, Monoplex. -- 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
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
Re: MVS 4 minute 'outage'
We also run on a z9BC uni, 30 MSUs. We run Siemens applications and they still recommend a uni for their CICS-based workload. Do you get any missing interrupts with these hangs? -- 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
Re: z800 to z9
Our shop is running 180 MIPS and using them all (!) between 10 and 3 everyday. There are times when we see CICS spike to 80 and even 90%. The same is true for VPS/DRS--it does this forms translation from .tif files that can eat up 8 cpu seconds for a single form. We use WLM to favor CICS over the print. We did do some modeling for this box (I don't recall exactly what), but it was inconclusive, and couched in mileage may vary and that depends. I think that were we to replace the UP with an MP of similar MIPS rating, overall things would run better, but there would be times that would be slower. Would it be a good tradeoff? Maybe, but I can't conscientously push for it without being more certain.However, Siemens continues to recommend the UP, so that is the way we are going. -- 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: z800 to z9
Hi, Yes, I remember the zjournal with the red sports car on the cover. I think I may have said something immature (like See I told you!) when it arrived in my office. Possible. Anyway, good points all. Our print conversion and DB2 workload could take advantage of a second cp even if CICS is still single threading. However, it's hard to take a risk like that with a critical app (Siemens Invision Patient Care, Patient Accounting and Practioner Order Entry). -- 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
z800 to z9
Greetings esteemed posters, I read the z800-z9 questions with interest because we are on the verge (!) of making an upgrade from a 2066-001 to a 2096-S01. Our primary application vendor believes their workload runs best on a UP, so we went again with that configuration. Our zOS version is 1.7, workload CICS and DB2. We are going to implement ICC. Any advice, caveats or war stories? Also we have a DS6800 and will be implementing MIDAW. Any advice there? Thanks! Patty -- 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: z800 to z9
We have discussed the validity of the UP recommendation around our shop for years. One former employee indicated that although CICS has multiple TCBs, it really only uses one. I found that curious as well. We only run the one suite of applications, one production CICS. It is an old app and does a lot of batch to CICS to access VSAM files along with DB2. It does hit some very high CPU running these processes and some of the online transactions are pretty ugly, too. We run a lot of print conversion stuff and some distributed DB2 which would surely benefit from additional CPs, but hard to say what the overall effect would be. -- 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: Flashcopy on DS6800
Hi Guys, We are due for a tape upgrade -- we have 3590-B1A drives, and the tape backup starts after batch. It's slow enough that it doesn't finish in time for us to bring test up until noon or so, thus the double flash. Your input is interesting. I think we have a configuration issue which we need to fix and then we are going to go to flashcopy=nocopy also. Regards Patty -- 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
Flashcopy on DS6800
We installed a DS6800 to replace our Shark F20 a few weeks ago. We are happy with the change overall and have seen good improvements in batch times. However, we do have an issue with the Flashcopy. On the F20 we did a nightly FDRABR flashcopy with parameter FCOPY=COPY of about 64 3390-9 and about 15 3390-3 volumes. Our tapes are old and slow, and it was time consuming to back this all up for DR, so we did a second flash copy using DFDSS that would invoke flash copy services. Those volumes would remain offline, only being used for backups. We we then did FDRBACKUP of the flashed volumes, and brought them online for our TESTLPAR. We now do a similar process on the DS6800. We do 2 flashes, 1 using FDRFLASH with FCOPY=COPY to make full copies to be used by our TESTLPAR. The second is FDRABR with the FCOPY=COPY and these are used for our FDR disaster backups. The # of drives that are being copied with FCOPY=COPY are equal or less on the DS6800. We saw no performance hit when doing this on the SHARK F20. We are having terrible response on the DS6800 for about 2 hours after the flashcopy completes. After reviewing with IBM, we made a few adjustments when we learned about half the volumes were being copied to targets in the same extent pool as the source. We switched our target volumes to extent pools different from the source volumes, and also validated that the target and source for each flashed volume are managed by the same controller. This seemed to have little effect. What are considering switching to this process: Do 2 flash copies, 1 with FDRFLASH with FCOPY=NOCOPY and a second with FDRABR with FCOPY=NOCOPY. We will then bring the first copy online to the test LPAR and the second will be used just for FDR disaster backups. The first copy will be repeated once a week (or on demnad), all other days during the week we will do just the FDRABR copy for disaster purposes. We are wondering if the same process works differently on the Shark v. the 6800. Does anyone else use flashcopy for TESTLPAR data? If so, are you using FULLCOPY, NOCOPY or incremental flashing. Any comments on the process we are using or the one we propose to change to? Is there any issue in maintaining a flash pair for a week or to without using FCOPY=COPY ? Would appreciate any comments. -- 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: Flashcopy on DS6800
Correction: 4th paragraph should read:We do 2 flashes, 1 using FDRFLASH with FCOPY=COPY to make full copies to be used by our TESTLPAR. The second is FDRABR with the FCOPY=NOCOPY and these are used for our FDR disaster backups. -- 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: Damaged Catalog Alert
Hi Alan, We went to zOS 1.7 a couple of weeks ago, and don't have this fix on, so it's possible we have been exposed. As I display ECS, its status is inactive, but the catalogs do AUTOTUNE. You indicated that you have turned off ECS to avoid a recurrance until you get the fix on, but the APAR sounds as if they don't know the cause. Can you clarify--will we still be exposed without ECS, with AUTOTUNE on? We are in a monoplex environment. Thanks Patty -- 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: report excps by job step
Thanks, guys, I'll check these out. -- 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
report excps by job step
Does anyone know of a report that will show job stats, and in particular excps by job step? We don't have SAS. I have scoured the CBT files but haven't located one. Any help or advice on sources is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
