Re: Question on PR/SM dispatcher
Mauri Kanter itzuv...@013.net.il wrote in message news:7558267718421282.wa.itzuviem013.net...@bama.ua.edu... Thank you Jim. Crystal Clear. Mauri, I was going to reply, that your view on pr/sm was incorrect: pr/sm does not dispatch entire LPARs, but individual processors, if the LPAR's weight allows it. But I think Jim's answers made that clear also. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
To dispatch entire LPARs would be waiting for 2n ducks to line up in a row: An event with progressively high latency in the n1 case. Which is one reason we don't do it, I guess. (The 2n ducks would be the n logicals and n physicals.) Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
You don't have to wait for it, you can also force it. Amdahl's MDF did it. The main difference was that PR/SM is interrupt driven and MDF was timeslice driven. Therefor it did not have to wait for the ducks to line up, but simply took an entire domain from the processors when its time was up and dispatched a new domain. Both had their pro's and con's and MDF lost the game, but for totally different reasons. Kees. Martin Packer martin_pac...@uk.ibm.com wrote in message news:off8674931.d52d3037-on8025796b.002d3b37-8025796b.002d6...@uk.ibm.c om... To dispatch entire LPARs would be waiting for 2n ducks to line up in a row: An event with progressively high latency in the n1 case. Which is one reason we don't do it, I guess. (The 2n ducks would be the n logicals and n physicals.) Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
(snip, someone wrote) The changeover involved a series of steps: December 31, 1750 was followed by January 1, 1750 (under the Old Style calendar, Dec ember was the 10th month and January the 11th) March 24, 1750 was followed by March 25, 1751 (March 25 was the first day of the Old Style year) December 31, 1751 was followed by January 1, 1752 (the switch from March 25 to January 1 as the first day of the year) September 2, 1752 was followed by September 14, 1752 (drop of 11 days to conform to the Gregorian calendar) Reminds be of discussions about the way OS/360 keeps track of the data. There is a comment in Brooks' Mythical Man Month, something like the waste of 26 bytes required to change the date at the end of the year, something that the operator could do. Well, that is without looking it up. But if I understand it right, the date is computed from the value in the interval timer, along with various offsets, only when it is actually needed. Nothing special actually happens at midnight on Dec. 31st. In the case of a more complicated formula for determining the date, it only needs to be added to the date calculation routine, and runs when one actually needs the date. With a few comparisons and offsets it wouldn't seem so hard. With the TOD clock of S/370, one would just compute the date based on the current value, and again nothing special happens at midnight Dec. 31st. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WAIT ECB WITH 00 First Byte
For normal completion, the resetting of the other ECB's wait bits is done, as Jim Mulder points out. For abnormal completion (i.e., if you were waiting and woke up in your recovery whether due to cancel or some other asynchronous abend), don't count on it Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ASCENV incompatible change in Assembler
While it is admittedly unpleasant to have the system start enforcing requirements that it has documented, and I'll grant that we don't often make such runtime enforcement changes, here we are talking about assembly where it should be fairly easy to address, and might well help avoid a problem (as might happen if your ARs or register high halves contained some unexpected value) I'm curious whether the complaint is: -- My SYSSTATE does not represent my actual ASC environment or AMODE (or ARCHLVL or OSREL for that matter, although ARCHLVL and OSREL are not relevant to the macro changes being discussed) yet I expect macros to generate proper code that I can rely on working and continuing to work -- My SYSSTATE does represent my actual environment and I am invoking a service in an environment it is documented not to support but that I expect to work and continue to work -- Something else Aside from the annoyance, would anyone really defend either of those first two practices? FWIW, it was probably already mentioned that this information was conveyed to ISVs and is present in the migration guide. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
-Original Message- From: IBM Mainframe Discussion List On Behalf Of J R pour people? - what, you mean like bartenders? Must be the same kind of folks who pour over a manual in detail. (What do they pour over the manual, and how does that help discern details?) And loose used as a verb does not have the same meaning as lose, as the context of the sentence seems to require -jc- Date: Fri, 16 Dec 2011 13:20:54 -0600 From: jonathan.goos...@assurant.com Subject: Re: Imagine dealing with THIS in production To: IBM-MAIN@bama.ua.edu And what about the pour people who will loose a birthday? Thank you and have a Terrific day! Jonathan Goossen, ACG, CL For help with communication and leadership skills checkout Woodwinds Toastmasters -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
PR/SM dispatches Logical CPs not Logical Partitions. So Question 1 and 2 get the same answer. Any given Logical partiton can have some logical CPs ready to run, and pther logical CPs in the WAIT state. The ready to run CP will be dispatched on a real CP when it is the highest priority Logical CP ready to run. The other CPs in the partition are not ready to run, and so are not competing for resources. The logical CP priority is the weight divided by the number of Logical CPs in the partition. In most cases PR/SM dynamically determines the run time (a.k.a. time slice) to be 12.5 ms. Most LCPs will enter wait state before the 12.5 ms is reached and will be queued for the event (usually I/O) that will make the LCP ready to run again. Time slices shorter than 12.5 ms usually only occur with very low weighted Logical Partitions, or hard capped partitions, or both. LCPs for these partitions can cause a drastic reduction in MIP rate, because the first few ms after getting dispatched usually involves many cache misses. By the time the real CP has its caches primed with the instructions and data, the short time slice ends and the LCP is returned to a queue waiting for a chance to get dispatched. Other ready to run LCPs with higher priority (Weight) will be queued before it. If a low weighted LCP is the only one ready to run, it can consume more than its weight. I wouldn't call the tracking of consumption averaging, but the accumulation of CPU time and tracking of the entitlement based on the weight is measured in seconds. regards Tom On 2011-12-19 12:00 AM, IBM-MAIN automatic digest system wrote: Date:Sun, 18 Dec 2011 09:50:33 -0600 From:Mauri Kanteritzuv...@013.net.il Subject: Question on PR/SM dispatcher Good day list I would like to understand something that is not still clear to me regarding PR/SM dispatching. Just to be clear I'm asking only about shared processors (not dedicated) and with dynamically determined time slices. I'm interested to understand the LPAR dispatching (before I understand the zVM dispatching and the Linux under VM dispatching;-) I a-priori apologize if I'm asking too many questions together. The questions are: Question 1 == Does PR/SM dispatches an LPAR only when the number of physical processors awaiting allows to dispatch all the logical processors required for an LPAR simultaneously? For example suppose my machine has 3 physical CPUs, and with 3 lpars defined as follows: LPARA 3 logical processors LPARB 2 logical processors LPARC 2 logical processors Option 1 Am I wasting a physical processor when LPARB or LPARC are dispatched? Option 2 - Or can the single physical processor left be dispatched to serve another lpar? If option 2 is the true one, are there spin-lock and loop related problems if only a subset of CPUs is dispatched by PR/SM? Option 3 - Or none of the options 1 and 2 are true and it works differently? Question 2 == Suppose that an LPAR running z/OS with 2 physical processors is dispatched. The first physical processor completed its work. The second physical processor is still burning cycles with for example the CICS QR TCB In other words, my z/OS at some moment got 2 physical CPUs but only one TCB has really work to do. Are both physical processors returned simultaneously to PR/SM or are they returned independently to PR/SM as they become idle? I mean, do the processors return one by one to the pool of available physical processors or simultaneously on an LPAR base? Question 3 == Suppose that I have 2 LPARs, one with weight 20 and the other with weight 80 The one with weight 80 does not consume all its time slice and returns the processor(s) to PR/SM The one with weight 20 finds a way to use those cycles the other left Now the LPAR with weight 80 wants more than its weight Over which time interval are the weights averaged? Once a second? Once a minute? Not averaged at all? Thanks in advance for your help. Mauri. -- Tom Russell “Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear “... and remember to leave good news alone.” — Gracie HeavyHand -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: One Less Mainframe Shop
-Original Message- From: IBM Mainframe Discussion List On Behalf Of DKM Just over seven years ago, I was hired as the Financial System Administrator at my place of emplacement. In my first interview, I was told how they were getting ready to pick a new ERP and get off their “archaic” mainframe. After I was hired, the IT director at the time told me with glee how they would be shutting down the mainframe in six months. This shocked me a bit it was going to take at least a year to go live with the new ERP solution. It turned out maintenance on the 20-year-old software was going to end in six months. The mainframe was actually scheduled for shutdown six months after we went live on the new software and platform. Well we did go live on the new ERP within a year, but the mainframe at one time had run the entire business of the company and while the financial suite was the last large part to go off it, there were still several “smaller” but just as important systems still running on it. Consequently, it took seven years, and two other IT directors, before access to the now 11-year-old System/390 was finally cut this week. At some point after the New Year, a ceremony is being planned to let the Chairman flip the final switch to turn off the system. He has been a “Champion of Modernization” to get us off the mainframe for almost 10 years. I’m sure speeches will be made about how far we have come. Yet, as I look around at the countless servers, real and virtual, and think about the major software platforms hosted by outside vendors, all to replace the one S/390 that was divided in to four virtual systems I can’t help but wonder if we are really better off. Certainly, FSVO better off. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
-Original Message- From: IBM Mainframe Discussion List On Behalf Of David Mierowsky At least they didn't have to deal with this! Thankfully this was sorted out long before computers were around! The Changes of 1752 In accordance with a 1750 act of Parliament, England and its colonies changed calendars in 1752. By that time, the discrepancy between a solar year and the Julian Calendar had grown by an additional day, so that the calendar used in England and its colonies was 11 days out-of-sync with the Gregorian Calendar in use in most other parts of Europe. England's calendar change included three major components. The Julian Calendar was replaced by the Gregorian Calendar, changing the formula for calculating leap years. The beginning of the legal new year was moved from March 25 to January 1. Finally, 11 days were dropped from the month of September 1752. The changeover involved a series of steps: *December 31, 1750 was followed by January 1, 1750 (under the Old Style calendar, December was the 10th month and January the 11th) *March 24, 1750 was followed by March 25, 1751 (March 25 was the first day of the Old Style year) *December 31, 1751 was followed by January 1, 1752 (the switch from March 25 to January 1 as the first day of the year) *September 2, 1752 was followed by September 14, 1752 (drop of 11 days to conform to the Gregorian calendar) Perhaps the world's eventual conversion to Star Date (or similar) will be less confusing and disruptive :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zFS parm sysplex=filesys
From: Lizette Koehler stars...@mindspring.com Subject: Re: zFS parm sysplex=filesys Does this mean with z/OS V1.13 I will have to change to SYSPLEX(YES) in order to have zFS files mounted? Or will zFS still mount even with SYSPLEX(NO) Lizette, With SYSPLEX(NO) zFS address space will mount its zFS datasets, and will will operate the S390 Unix System Services in local mode (as per comment in BPXPRMxx delivered by IBM). SYSPLEX(NO) takes precedence over parameter sysplex=filesys which can be specified in IOEFSPRM. If you want to stick having a non-sharable Unix System Services environment, then SYSPLEX(NO) is all you need to have, even at z/OS 1.13 level. HTH Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
On Mon, 19 Dec 2011 08:44:00 -0600, Chase, John wrote: Perhaps the world's eventual conversion to Star Date (or similar) will be less confusing and disruptive :-) Ummm... NVFL. See: http://en.wikipedia.org/wiki/Stardate -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
On 12/19/2011 4:17 AM, glen herrmannsfeldt wrote: But if I understand it right, the date is computed from the value in the interval timer, along with various offsets, only when it is actually needed. Nothing special actually happens at midnight on Dec. 31st. Which is not how I remember it. The interval timer is set to pop at midnight, and that updates CVTDATE appropriately. I do recall an admonition that near midnight to use SVC 11 for the date, rather than CVTDATE, to get a synchronized value, as there was some latency in the date update. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
How about the Julian Day as used by astronomers? http://en.wikipedia.org/wiki/Julian_day Julian day is used in the Julian date (JD) system of time measurement for scientific use by the astronomy community, presenting the interval of time in days and fractions of a day since January 1, 4713 BC Greenwich noon. Julian date is recommended for astronomical use by the International Astronomical Union. Almost 2.5 million Julian days have elapsed since the initial epoch. JDN 2,400,000 was November 16, 1858. JD 2,500,000.0 will occur on August 31, 2132 at noon UT. (Often .leading 2.4 million is assumed and the low order 5 digits is used.) Time is expressed as a fraction of a day. 0.1 day = 2.4 hours, 0.01 = 14.4 minutes. 0.001 = 1.44 minutes, 0.1 = 0.864 seconds. x.000 is Noon UT 1200Z Modified Julian Date subtracts 0.5 so x.000 is Midnight UT Z. On Mon, Dec 19, 2011 at 10:01 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 19 Dec 2011 08:44:00 -0600, Chase, John wrote: Perhaps the world's eventual conversion to Star Date (or similar) will be less confusing and disruptive :-) Ummm... NVFL. See: http://en.wikipedia.org/wiki/Stardate -- gil -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
Mike Schwab's Wikipedia quote: | Julian day is used in the Julian date (JD) system of time measurement | for scientific use by the astronomy community, presenting the interval | of time in days and fractions of a day since January 1, 4713 BC | Greenwich noon. Julian date is recommended for astronomical use by the | International Astronomical Union. is perhaps a little misleading. The epoch origin specified, noon, January 1, 4713 BCE, is a Julian-calendar date. The correct epoch origin in our now standard calendar, specified as a proleptic Gregorian-calendar date, is noon, November 24, -4713. Moreover, both calendars in this scientific context have a zero-th year. They do not use the traditional sequence . . . , 2BC, 1BC, AD 1, AD 2, . . . because it use would complicate calendrical arithmetic gratuitously. They use the year-number sequence . . . , -2, -1, 0, +1, + 2, . . . instead. In fact day-number epoch-origin choices are unimportant if the one being used is identified unambiguously. To convert a JD, Julian Day, into a GD, Gregorian Day, one simply subtracts 1_721_424.5 from the JD; to convert a GD into an ID, Islamic Day, one subtracts 227_015 (The GD of +622 July 19, the epoch origin of the Islamic lunar calendar) from the GD; etc., etc. The use of day numbers trivializes calendar arithmetic. Computer systems should use only day numbers internally, displaying or printing Gregorian dates , Bahà'i dates, Islamic dates, Mayan dates, and the like externally as appropriate. In this sense, among others, most of the Y2K expenditures of large organizations were botched. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab How about the Julian Day as used by astronomers? http://en.wikipedia.org/wiki/Julian_day Julian day is used in the Julian date (JD) system of time measurement for scientific use by the astronomy community, presenting the interval of time in days and fractions of a day since January 1, 4713 BC Greenwich noon. Julian date is recommended for astronomical use by the International Astronomical Union. What's magic about -4713/01/01? Why not specify the epoch origin as the Big Bang? What would today's Big Bang day number be? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
On Mon, Dec 19, 2011 at 1:47 PM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab How about the Julian Day as used by astronomers? http://en.wikipedia.org/wiki/Julian_day Julian day is used in the Julian date (JD) system of time measurement for scientific use by the astronomy community, presenting the interval of time in days and fractions of a day since January 1, 4713 BC Greenwich noon. Julian date is recommended for astronomical use by the International Astronomical Union. What's magic about -4713/01/01? Why not specify the epoch origin as the Big Bang? What would today's Big Bang day number be? :-) -jc- Add about 15 billion years, or 5,48 Billion days to the front of the Julian Day. Like the Dinosaur skeleton that is 65,000,010 years old. (Tour guide: It was 65 million years old when I got here 10 years ago.) Actually, I think they are going to have to downgrade the Big Bang (creating all matter and the Universe) to a Large Bang (creating known matter withing 15 billion light years but within an existing universe past that point). -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
Multiply approximately 365.25 by approximately 15 (American) billion. The result, 5.47875 times ten to the twelfth power (American trillion) will still fit in a 64-bit register. And there's even room in the register to double it (for plus and minus) and throw in one more for the year zero. Here is the origin of choosing 4713 B.C.: http://curious.astro.cornell.edu/question.php?number=88 Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chase, John Sent: Monday, December 19, 2011 1:47 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Imagine dealing with THIS in production -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab How about the Julian Day as used by astronomers? http://en.wikipedia.org/wiki/Julian_day Julian day is used in the Julian date (JD) system of time measurement for scientific use by the astronomy community, presenting the interval of time in days and fractions of a day since January 1, 4713 BC Greenwich noon. Julian date is recommended for astronomical use by the International Astronomical Union. What's magic about -4713/01/01? Why not specify the epoch origin as the Big Bang? What would today's Big Bang day number be? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Abend in LE - S0C1 at CEEHSFXS+310
Data at PSW is UNEXPECTED RETURN-CODE: 6576 -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
On Mon, Dec 19, 2011 at 1:47 PM, Chase, John jch...@ussco.com wrote: What's magic about -4713/01/01? Why not specify the epoch origin as the Big Bang? What would today's Big Bang day number be? http://www.hebcal.com/ Mon, 19 December 2011 - 23rd of Kislev, 5772 5772 years ago would be 3761 BC. Close, but no cigar. Ah, found it. http://www.tondering.dk/claus/cal/julperiod.php Why 4713 BC and why 7980 years? Well, in 4713 BC the Indiction, the Golden Number and the Solar Number were all 1. The next times this happens is 15×19×28=7980 years later, in AD 3268. Kind of like the Mayan Calendar. One cycle ends Dec 21, 2012 and the next one starts. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend in LE - S0C1 at CEEHSFXS+310
Data at PSW is UNEXPECTED RETURN-CODE: 6576 What level of z/OS? What is this in COBOL, ASSEMBLER, PL1, etc.. What function was involved at the time? Have you looked at the CEEDUMP and determined anything? CEEHSFXS CEL Stack Frame eXit Schedule A COBOL application with a registered condition handler repeatedly calls CEE3ABD to issue user abends. During the abend processing, if the user handler has requested a resume, the stack frame collapsing routine (CEEHTRAV) could potentially update a wrong save area. It could later result in a branch being taken to a free storage instead of a valid stack frame exit code (SFXM), causing an 0C1. Verification Steps: At the time of an 0C1, the PSW will match the R14 in the DSA of the top entry in the traceback, and will point to a free heap element. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
Will CA VTAPE work on regular MF or does it need the DS8800. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Friday, December 16, 2011 8:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless Solutions Hi George, If you want it to, it can 'do' CA1 - with the aid of CA Vtape. That will let you run all or part of your disk space as CA1 managed tape image. You can also back up those tape images to disk, or physical tape, or use replication to another site. HTH, Linda - Original Message - From: George Henke george.he...@hp.com To: IBM-MAIN@bama.ua.edu Sent: Friday, December 16, 2011 4:36:18 PM Subject: Re: Tapeless Solutions Does the DS8800 do tape management (CA-1)? I don't think so. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, December 16, 2011 4:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless Solutions Henke, George george.he...@hp.com wrote in message news:04b3da7b71b3ab408ca62ba6046bcf8f23d485b...@gvw0676exc.americas.hpq corp.net... Does anyone know of an IBM completely tapeless solution and what it might cost? I have heard of the TS7740, but it holds only 6 TB per draw. We have 750 TB on tape. Out of curiosity: why do you want the 750TB stored tapeless? Do you really want the data virtually on tape? What about a DS8800? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
W dniu 2011-12-19 23:02, Henke, George pisze: Will CA VTAPE work on regular MF or does it need the DS8800. What??? CA VTAPE is from software being sold by CA. DS8800 is a DASD box being sold by IBM. CA VTAPE works on any mainframe DASD. I don't know what does it mean work on regular MF. BTW: IMHO it is very expensive solution. It consumes CPU cycles, especially when compression is on (could be offloaded to zIIP), and consumes mainframe DASD, which is usually the most expensive DASD. Exception: FBA DASD connected using magic box like BusTech MDL or Luminex, or other. ...but then you don't need VTAPE - those boxes also emulate tape units. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.346.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
CA VTape is a software solution that uses any disk that you happen to have. The down side of this type of solution is the increased CPU usage due to it being a software solution instead of a hardware solution, like the TS7720, that uses private disk in behind the scenes. Thank you and have a Terrific day! Jonathan Goossen, ACG, CL Tape Specialist ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with communication and leadership skills checkout Woodwinds Toastmasters IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/19/2011 04:02:41 PM: From: Henke, George george.he...@hp.com To: IBM-MAIN@bama.ua.edu Date: 12/19/2011 04:13 PM Subject: Re: Tapeless Solutions Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Will CA VTAPE work on regular MF or does it need the DS8800. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Friday, December 16, 2011 8:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless Solutions Hi George, If you want it to, it can 'do' CA1 - with the aid of CA Vtape. That will let you run all or part of your disk space as CA1 managed tape image. You can also back up those tape images to disk, or physical tape, or use replication to another site. HTH, Linda - Original Message - From: George Henke george.he...@hp.com To: IBM-MAIN@bama.ua.edu Sent: Friday, December 16, 2011 4:36:18 PM Subject: Re: Tapeless Solutions Does the DS8800 do tape management (CA-1)? I don't think so. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, December 16, 2011 4:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless Solutions Henke, George george.he...@hp.com wrote in message news:04b3da7b71b3ab408ca62ba6046bcf8f23d485b...@gvw0676exc.americas.hpq corp.net... Does anyone know of an IBM completely tapeless solution and what it might cost? I have heard of the TS7740, but it holds only 6 TB per draw. We have 750 TB on tape. Out of curiosity: why do you want the 750TB stored tapeless? Do you really want the data virtually on tape? What about a DS8800? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access
Re: Tapeless Solutions
Offloading VTAPE to zIIP would not be so bad, no? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Monday, December 19, 2011 5:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Tapeless Solutions W dniu 2011-12-19 23:02, Henke, George pisze: Will CA VTAPE work on regular MF or does it need the DS8800. What??? CA VTAPE is from software being sold by CA. DS8800 is a DASD box being sold by IBM. CA VTAPE works on any mainframe DASD. I don't know what does it mean work on regular MF. BTW: IMHO it is very expensive solution. It consumes CPU cycles, especially when compression is on (could be offloaded to zIIP), and consumes mainframe DASD, which is usually the most expensive DASD. Exception: FBA DASD connected using magic box like BusTech MDL or Luminex, or other. ...but then you don't need VTAPE - those boxes also emulate tape units. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2011 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.346.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine dealing with THIS in production
On 12/19/2011 11:53 AM, Mike Schwab wrote: How about the Julian Day as used by astronomers? http://en.wikipedia.org/wiki/Julian_day Julian day is used in the Julian date (JD) system of time measurement for scientific use by the astronomy community, presenting the interval of time in days and fractions of a day since January 1, 4713 BC Greenwich noon. Julian date is recommended for astronomical use by the International Astronomical Union. Almost 2.5 million Julian days have elapsed since the initial epoch. JDN 2,400,000 was November 16, 1858. JD 2,500,000.0 will occur on August 31, 2132 at noon UT. (Often .leading 2.4 million is assumed and the low order 5 digits is used.) Time is expressed as a fraction of a day. 0.1 day = 2.4 hours, 0.01 = 14.4 minutes. 0.001 = 1.44 minutes, 0.1 = 0.864 seconds. x.000 is Noon UT 1200Z Modified Julian Date subtracts 0.5 so x.000 is Midnight UT Z. On Mon, Dec 19, 2011 at 10:01 AM, Paul Gilmartinpaulgboul...@aim.com wrote: On Mon, 19 Dec 2011 08:44:00 -0600, Chase, John wrote: Perhaps the world's eventual conversion to Star Date (or similar) will be less confusing and disruptive :-) Ummm... NVFL. See: http://en.wikipedia.org/wiki/Stardate -- gil Usage of Julian Day will never catch on with non-astronomers for one simple reason not yet mentioned - its formal definition requires the date change to occur at noon, not midnight. That makes much sense for astronomers that work through the night and sleep during the day, but is a terrible fit for people and businesses that have to deal with normal work hours and who would never tolerate the same period of daylight being called by two different dates. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine having to deal with THIS in production
Joel C. Ewing writes (of Julian days): | That makes much sense for astronomers that work through | the night and sleep during the day, but is a terrible fit for people | and businesses that have to deal with normal work hours and | who would never tolerate the same period of daylight being | called by two different dates What people find tolerable is a function of their experience. When my wife and I lived in Iran we rapidly came to terms with the convention that the day ends at sundown and even, with only a little more difficulty, with idea that a dinner invitation for Tuesday night was an invitation to have dinner following sundown on Monday. However that may be, this objection has another, much more important defect. It confounds internal representations for machines with external representations for people, which need to be interconvertible but should seldom--I had almost written never--be the same. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
While the cache is MF DASD (which gives it great performance when writing and reading from cache), CA-Vtape now has the ability to be offloaded to cheaper dasd that is attached through an NFS Server (such as NetApp or Data Domain). And you even have the flexability of having the offload copy go through data de-duplication (with Data Domain) and/or having a replicated off-site copy and still have a physical tape copy (or two). It allows for the client to decide which options are best for which types of tape data. For example, backup data kept for DR purposes might be best on an NFS Server that is duplicated off-site at the DR location and kept for 2-4 weeks. But for data that needs to be kept for decades (regulatory requirements) it might be a lot more cost effective to have 2 phsyical high-capacity drives and stack a couple of tera-bytes of data on each cartridge for long-term storage. The nice thing about a software solution such as CA-Vtape is that it gives you many different options. If you want a truely Tapeless Solution and don't mind keeping un-used and un-referenced data on dasd for decades (not very green of you) then something like CA-Vtape with a replicated NFS Server as the backstore might be a very good option. Of course, if you are going tapeless, replication is very-much the recommended method. While the NFS Server itself could be off-site, having only a single copy of all backup data runs the risk of putting all the eggs in a single basket. Which is why tape backups have had a primary and duplex copy for decades. Putting both the primary and duplex copy into the same physical box kind of defeats the whole point of having 2 copies of the backup data. But these are just my opinions. Russell Witt CA 1 L2 Support Manager On 12/19/11, R.S.r.skoru...@bremultibank.com.pl wrote: W dniu 2011-12-19 23:02, Henke, George pisze: Will CA VTAPE work on regular MF or does it need the DS8800. What??? CA VTAPE is from software being sold by CA. DS8800 is a DASD box being sold by IBM. CA VTAPE works on any mainframe DASD. I don't know what does it mean work on regular MF. BTW: IMHO it is very expensive solution. It consumes CPU cycles, especially when compression is on (could be offloaded to zIIP), and consumes mainframe DASD, which is usually the most expensive DASD. Exception: FBA DASD connected using magic box like BusTech MDL or Luminex, or other. ...but then you don't need VTAPE - those boxes also emulate tape units. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on PR/SM dispatcher
On Mon, 19 Dec 2011 09:20:16 -0500 Tom Russell wrote: PR/SM dispatches Logical CPs not Logical Partitions. I wonder if it'd be considered churlish to point out this wasn't always the case. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine having to deal with THIS in production
On 12/19/2011 05:39 PM, John Gilmore wrote: Joel C. Ewing writes (of Julian days): | That makes much sense for astronomers that work through | the night and sleep during the day, but is a terrible fit for people | and businesses that have to deal with normal work hours and | who would never tolerate the same period of daylight being | called by two different dates What people find tolerable is a function of their experience. When my wife and I lived in Iran we rapidly came to terms with the convention that the day ends at sundown and even, with only a little more difficulty, with idea that a dinner invitation for Tuesday night was an invitation to have dinner following sundown on Monday. However that may be, this objection has another, much more important defect. It confounds internal representations for machines with external representations for people, which need to be interconvertible but should seldom--I had almost written never--be the same. John, If you had read all of the included previous thread context in my previous response, the context was the world's eventual conversion to some date format, not a discussion limited to internal date usage by machines. I would say that makes the tolerance of people for the date format highly relevant and an asset to the objection, not a defect. There are of course other strong arguments against universal usage of JD for dates any time in our lifetime. As long as we remain an Earth-centric and not a space-centric culture, that makes it unlikely most people would favor an ordinal-based standard date format like Star Date or Julian Day which has no obvious relationship to Earth's annual seasons, when awareness of those seasons is so important to our physical comfort and survival. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
register Values TCBGRS vs TCBRB-XRBREGS
Hi, Would anyone know what the differences at a point in time between the values in TCBGRS and The Values of the registers in XRBREGS of the RB pointed to by TCBRB I am assuming of course TCBRB is the currently executing RB THANKS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Imagine having to deal with THIS in production
On Mon, Dec 19, 2011 at 11:02 PM, Joel C. Ewing jcew...@acm.org wrote: John, If you had read all of the included previous thread context in my previous response, the context was the world's eventual conversion to some date format, not a discussion limited to internal date usage by machines. I would say that makes the tolerance of people for the date format highly relevant and an asset to the objection, not a defect. There are of course other strong arguments against universal usage of JD for dates any time in our lifetime. As long as we remain an Earth-centric and not a space-centric culture, that makes it unlikely most people would favor an ordinal-based standard date format like Star Date or Julian Day which has no obvious relationship to Earth's annual seasons, when awareness of those seasons is so important to our physical comfort and survival. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org Actually, the Islamic calendar is 12 lunar months of 29.5 days on average. So it is shorter than a solar year by about 11 days and the 1st day of the year cycles through the solar year about every 34 or so years. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
MFNetDisk also support tapeless solution for emulated tapes. MFNetDisk tape emulation let you select MFNetDisk tape manager soultion or CA or IBM or any other tape manager solution. MF only trasfer the data and the CCW commands to PC and by that reduce the CPU utilization in MF. The PC emulates the TAPE and the 3390 DISK emulation. MFNetDisk also have customers which are using the MFNetDisk virtual tape solution in few countries. You can share tape from any number of MF sites without any distance limitation. So, this is very good solution for DR cases. Beside all of this, MFNetDisk is a free product. On Tue, Dec 20, 2011 at 2:30 AM, Russell Witt res09...@verizon.net wrote: While the cache is MF DASD (which gives it great performance when writing and reading from cache), CA-Vtape now has the ability to be offloaded to cheaper dasd that is attached through an NFS Server (such as NetApp or Data Domain). And you even have the flexability of having the offload copy go through data de-duplication (with Data Domain) and/or having a replicated off-site copy and still have a physical tape copy (or two). It allows for the client to decide which options are best for which types of tape data. For example, backup data kept for DR purposes might be best on an NFS Server that is duplicated off-site at the DR location and kept for 2-4 weeks. But for data that needs to be kept for decades (regulatory requirements) it might be a lot more cost effective to have 2 phsyical high-capacity drives and stack a couple of tera-bytes of data on each cartridge for long-term storage. The nice thing about a software solution such as CA-Vtape is that it gives you many different options. If you want a truely Tapeless Solution and don't mind keeping un-used and un-referenced data on dasd for decades (not very green of you) then something like CA-Vtape with a replicated NFS Server as the backstore might be a very good option. Of course, if you are going tapeless, replication is very-much the recommended method. While the NFS Server itself could be off-site, having only a single copy of all backup data runs the risk of putting all the eggs in a single basket. Which is why tape backups have had a primary and duplex copy for decades. Putting both the primary and duplex copy into the same physical box kind of defeats the whole point of having 2 copies of the backup data. But these are just my opinions. Russell Witt CA 1 L2 Support Manager On 12/19/11, R.S.r.skoru...@bremultibank.com.pl wrote: W dniu 2011-12-19 23:02, Henke, George pisze: Will CA VTAPE work on regular MF or does it need the DS8800. What??? CA VTAPE is from software being sold by CA. DS8800 is a DASD box being sold by IBM. CA VTAPE works on any mainframe DASD. I don't know what does it mean work on regular MF. BTW: IMHO it is very expensive solution. It consumes CPU cycles, especially when compression is on (could be offloaded to zIIP), and consumes mainframe DASD, which is usually the most expensive DASD. Exception: FBA DASD connected using magic box like BusTech MDL or Luminex, or other. ...but then you don't need VTAPE - those boxes also emulate tape units. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
