E-partition is a reduced logical partition in the cpc, f. e. no environment for classical applications like ims, cics etc., ask your ibm/tsm reppresentative for the $goodies to running tsm in this kind of lpar, i'm not familiar with the billing side, buth i now the license model is mutch cheaper then in the 'classical' lpar. regards joachim
-----Ursprüngliche Nachricht----- Von: Kraan, Helge van de [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 10. Februar 2003 13:01 An: [EMAIL PROTECTED] Betreff: AW: Future of mainframe TSM Hi Joachim what is new license model E-PART ? regards Helge -----Ursprüngliche Nachricht----- Von: Schaub Joachim Paul ABX-SECE-ZH [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 10. Februar 2003 12:23 An: [EMAIL PROTECTED] Betreff: AW: Future of mainframe TSM i made an isolated lpar (EPAR) for the tsm servers with the new license model for E-PAR, also you can make an lpar with linux? regards joachim -----Ursprüngliche Nachricht----- Von: Kraan, Helge van de [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 10. Februar 2003 11:37 An: [EMAIL PROTECTED] Betreff: Re: Future of mainframe TSM Hi Thomas, in time we have 7 TSM Servers (4.2.3.0) at z/OS 1.2. We backup 2800 clients (SAP-machines,Oracle,Exchange, ...) every night and get 6 TB each night. The problem we have in time are the software licensing by IBM (for DB2/IMS,CICS) and the thirdparty software, because our TSM servers are running at the same lpar systems. So we must pay for the TSM-MIPS by DB/2 IMS CICS ... software. So it is perhaps better to install a own mainframe for TSM !? Helge van de Kraan IS-Rechnersysteme Volkswagen AG Brieffach 1883 38436 Wolfsburg Telefon +49 (5361)9-73711 Telefax +49 (5361)9-29289 http://www.volkswagen.de Hello, Thomas. We run a 4.2.3.2 TSM under OS/390 2.10, also. We run it on a tiny little 7060-H50 (Multiprise 3000) and have an approximately 110mb/sec network connection (that's a bandwidth measurement - not a theoretical number). Furthermore, we run our OS/390 in a V=R virtual machine under z/VM, with 768MB of "central" storage dedicated to it and 192MB of expanded. We also run several Oracle address spaces and not much else. We have 12 3590's (E1A) in a 3994 ATL, a 42 GB database, about 300 GB of disk storage pools, and manage a total (primary and offsite copy stgpools) of about 20 terabytes of data, consisting of 79+ million files/copies. We are at our limit on the traffic during the evening hours, at this point. We are able to backup about 150 nodes and I'm not sure about the evening data volume by itself, but on daily basis, for all 24 hours, we backup anywhere from 250 to 350 GB. Most of it must be during the evening, because the only nodes we backup during the day are workstations, and our servers contain more data volume than our workstations. If you can get away from MVS (OS/390, z/OS) you'll probably save GOBs on the software licensing - IBM really does make you pay "big time" for MVS licensing (for the OS - not necessarily TSM). It seems like they're trying to eliminate the platform, doesn't it? However, I believe in the platform, because of its absolutely rock-solid qualities. I guess we pay for what we get - it's still too steep to justify, in my mind, and certainly not justifiable to most upper-level management. Anyway, please feel free to call off-line to get any details you may wish... By the way, I'll bet your workload quadruples, or more, over the next year! Regards, Mark Darby U. S. DOE Germantown, MD (301) 903-5229 -----Original Message----- From: Thomas Denier To: [EMAIL PROTECTED] Sent: 2/7/03 3:45 PM Subject: Future of mainframe TSM We run a 4.2.3.2 TSM server under OS/390. We have about 110 active client systems, sending about 300,000 files and about 70 gigabytes to the server each night. Our best estimate is that this workload will double in the next two years. Is it reasonable to stay with an OS/390 or zOS server in the face of the projected growth? If so, how do we prove that the mainframe is up to the task? Most IT managers around here want to believe that the mainframe is the wrong choice for TSM or anything else.