Re: Is there an SPF setting to turn CAPS ON like keyboard key?
In 1852985180391854.wa.paulgboulderaim@bama.ua.edu, on 12/16/2011 at 04:29 PM, Paul Gilmartin paulgboul...@aim.com said: On Fri, 16 Dec 2011 15:18:02 -0500, Shmuel Metz (Seymour J.) wrote: [1] Anybody know whether Stretch had code points for lower case? Yes. This guy: http://www.bobbemer.com/P-BIT.HTM He may have known, but that paper refers to unrelated events that came much later. Stretch was a radically different machine from the S/360 and in some respects more sophisticated. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY in z/OS 1.13
In fa4b9472-7337-4ad5-a094-0458df706...@comcast.net, on 12/17/2011 at 12:59 AM, Ed Gould edgould1...@comcast.net said: I was remembering MVS. A 64 KiB region sounds very small for MVS. Could that have been OS/360 but the conditional GETMAIN for 1 MiB been MVS? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
In aqupe7tkrl3dubl5s9g40tobnka4j35...@4ax.com, on 12/17/2011 at 10:30 PM, Binyamin Dissen bdis...@dissensoftware.com said: That was my point. If the ECBLIST has 5 ECBs and the wait count is 1, posting one of the ECBs causes the task to be dispatched without resetting the wait bit in the other ECBs. Your point is in error. POST resets all of the ECB's in the list that previously had bit 0 set. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
In 04b3da7b71b3ab408ca62ba6046bcf8f23d485b...@gvw0676exc.americas.hpqcorp.net, on 12/16/2011 at 08:35 PM, Henke, George george.he...@hp.com said: Does anyone know of an IBM completely tapeless solution Solution to what? Hot backup is a tapeless solution to off-site backup, but I have no idea whether that's what you have in mind. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Heads up APAR OA35970 CA-Top Secret
Yes, that is correct. They have just come out with the hiper for Top secret as well.We were early testers.There is actually a later hiper that removes the need to have the few definitions added if there is no intention of securing via this new facility. The problem is that the issue arose at IPL, and caused mounts and other tasks to fail, yet you need a system up with the enabling PTF to actually define the few definitions.The latest hiper now checks to see if the new FSACCESS is active first, and if not, then automatically does NO checking. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Joe D'Alessandro Sent: Friday, December 16, 2011 2:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads up APAR OA35970 CA-Top Secret The ACF2 folks sent out a HIPER warning to all subscribers about this issue already. The APAR applies to zOS v1.12 and v1.13 according to them. The informational APAR is RI38633 for ACF2 v14 but the solution applies to v15 as well. There are a few definitions that need to be made to ensure that the SAF call is approved. regards, Joe D'Alessandro This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
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. -- 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
Great questions. I have no idea of the answers, but will be very interested to see them! On Sun, Dec 18, 2011 at 10:50 AM, Mauri Kanter itzuv...@013.net.il wrote: 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 2 STC running on different GMT zones
On Sat, 2011-12-17 at 10:04 -0600, Paul Gilmartin wrote: On Sat, 17 Dec 2011 08:20:44 -0600, John McKown wrote: 00 21 * * 1-6 echo some_command | TZ=Australia/Canberra at midnight Could you use a UNIX crontab entry to nudge your STCs? -- gil You'd still have the problem of the timezone for jobs submitted by the STC. z/OS non-UNIX does not have a way to inherit the TZ offset. It should. Simply, if the STC process is dubbed and the TZ environment variable is set, TIME TZ=LOCAL should honor it. You're talking UNIX. I'm talking batch job submission. The TZ is inherited only if the originator does a fork() or spawn(). Which is not how, in general, z/OS job schedulers work. They submit JCL through the internal reader to run in an initiator. The TZ, if any, set in the process doing the submit is not inherited by submitted job. CA-7, our scheduling package, doesn't even use UNIX services. It's not dubbed as best as I can tell from looking at the SDSF PS screen. Our batch jobs aren't UNIX either. Just plain old COBOL batch. The only things we really use UNIX for is the TCPIP stack for TN3270 and ftp. Oh, and sending SNMP messages to our automated ticketing system if a production job has a problem. There are more than the two time zones TIME supports. OS X has 440; Solaris 453; Ubuntu 879 (after filtering out multiply-linked). Adapt or die. (Echoing a theme many of us know well in our workplaces. See DKM's posting 18 hours ago; don't give the airline magazines ammunition.) IBM has chosen to sacrifice z/OS. At least as far as smaller shops go. I guess the large multinationals may continue to use it. But where I work? No. We just aren't profitable enough to IBM. We're not large enough to succeed, in their play book. z/OS is the Bentley of operating systems. http://www.bentleymotors.com/ . The lowest priced Bently that I found was over US $180,000. They go up rapidly from there. Windows has won the lower and mid range war, as best as I can tell. -- gil -- John McKown Maranatha! -- 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
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? No. 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 2, and yes, there can be cases where a dispatched logical processor can be spinning for a resource held by a logical processor which is not dispatched. z/OS detects this situation and informs LPAR. 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? Logical processors are dispatched and returned independently. 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? LPAR calculates the share for each partition based on the weights of all of the active partitions. For a partition which is not in hiperdispatch mode, the share is distributed evenly among its logical processors. A logical processor which has not used its share is given some amount of dispatching preference over logical processors which have used more than their share. I don't know the time intervals over which the calculations are made. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
On Sun, 18 Dec 2011 01:24:40 -0500 Jim Mulder d10j...@us.ibm.com wrote: : :My understanding, which might be incorrect or incomplete, is that WAIT :sets : :the wait bits, stores the RB address in the ECBs, sets the wait : count in the : :RB and puts the task in a wait state. At that point, isn't WAIT :finished? : :POST sets the post bit, clears the wait bit, decrements the wait : count if it : :is greater than zero, then if it is zero, makes the task dispatchable. : :The ECBs are not reset. : That was my point. If the ECBLIST has 5 ECBs and the wait count is 1, :posting : one of the ECBs causes the task to be dispatched without resetting the :wait : bit in the other ECBs. : Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years :before it became OCO in MVS/ESA SP3.1.0, so some of you :probably have this on microfiche that you have squirreled away :somewhere): :* WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST :* OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE :* LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS :* WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING :* POSTED) ARE RESET TO ZERO. : SPACE 1 :*/* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/ : TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET : BZTCBREADY NO, BRANCH :*/*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/ : L R10ECBP,TCBGRS1ASSUME REGS IN TCB : CLR5RB,TCBRBPECB'S RB TOP OF QUEUE : BERESETWTYES, BRANCH : L R3WORK,TCBRBP GET ADDRESS OF TOP RB :* NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP :LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1 : ICM R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR :* (HIGH BYTE ALREADY CLEARED) : CLR R3WORK,R5RBFOUND WAITING RB : BNE LOOP3 NO, BRANCH : I could not find anything in the manuals which says this, but :it has worked this way for at least 30 years. Very interesting. So I have useless logic after ECBLIST waits, resetting the non-posted ECBs to zero. The status will either be posted or zero. -- 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: Question on PR/SM dispatcher
Thank you Jim. Crystal Clear. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
I know it's not IBM, but FYI, we converted earlier this year to a DataDomain DD510 (now EMC) data deplucation system with a Luminex gateway (tape emulation). We have 21.3 TB stored on a 3.6 tb box (actual utiization is 2.9 tb (7.4x compression/dedup). There where no JCL changes, new tapes are still managed by CA1. No problems/complications. DR is over IP to another DD610 and Luminex gateway at the DR site. As for cost, I cannot say because it was part of a much bigger deal with EMC. The DD610 is one of the smaller boxes. I think it (and other models) scale into petabytes of storage... Regards, Silvio Camplani zSeries Sr. Analyst, Systems Support Bombardier On Fri, Dec 16, 2011, at 08:35 PM, Henke, George wrote: 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. -- 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: zFS parm sysplex=filesys
Hello Lizette and All, Just to re-iterate what others had said (which has been correct)... This sysplex=filesystem migration action is applicable if you use zFS *AND* if you are in a shared file system environment. If you don't meet both of these criteria, then you do not need to do this migration action. A shared file system environment means (among other things) that you've set in your BPXPRMxx SYSPLEX(YES). If you do not have SYSPLEX(YES) in your BPXPRMxx, you are not running in a shared file system environment and therefore this migration action is not applicable to you. btw, SYSPLEX(NO) is the default. If you are using shared file system, I'd suspect you'd be aware of it because of the setup work involved. -Marna WALLE z/OS System Install IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Calling all crypto gurus
On Fri, 16 Dec 2011 20:13:06 +, David Booher david.boo...@quest.com wrote: But I think I found my answer ( I have NO AES or 3DES): z/OS only offers low-grade encryption (56 bit DES etc) unless you have ordered and installed the level 3 security features. If z/OS does not offer higher-grade encryption then some (most?) non-z/OS clients will refuse to connect. For z/OS 1.12 the FMIDs you need to install are: JCRY741 OCSF Security Level 3 JIP61CK Comm Srvr Sec Lvl 3 JCPT3C1 System SSL Security Lvl 3 JSWK3C1 Network Auth Service Lvl 3 There are similar FMIDs for earlier z/OS releases. These are no charge features but you have to order them. Regards, Roger Bowler Hercules the people's mainframe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Calling all crypto gurus
W dniu 2011-12-17 19:04, Phil Smith pisze: Steve Finch wrote: From info we have gotten, I believe that the z800 does not have it's CCF (Feature code 800) enabled (configured). CCFs were no cost features but you could order a z800 without it. Ah. So it's (sort of) like CPACF. It's NOT. I made the assumption that CCF meant the 4764 or whatever it was back then. Yeah, if that's not turned on, it definitely sounds like you'd be crippled by lack of non-exportable algorithms. Thanks for clarifying! Main difference: CPACF does not support secure key operations. So, for clear key operations CPACF is similar to CCF, but for secure key operations CCF is similar to ...nothing. Crypto cards (PCICC, PCIXCC, CE2X, CEX3) provide support for secure key, but their performance is different. Different means usually worse, but it's not so simple, because the performance depends on block size, algorithm used, # of concurrent jobs, etc. etc. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc 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 Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- 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
At 01:24 -0500 on 12/18/2011, Jim Mulder wrote about Re: WAIT ECB WITH 00 First Byte: Quoting from the MVS/XA SP2.1.0 version of IEAVEPST (5 years before it became OCO in MVS/ESA SP3.1.0, so some of you probably have this on microfiche that you have squirreled away somewhere): * WHEN THE WAIT COUNT BECOMES ZERO, THIS CHECKS IF THERE WAS A LIST * OF ECB'S BEING WAITED ON BIGGER THAN THE WAIT COUNT. IF SO, THE * LIST ADDRESS IS FOUND (GETTING REG 1 FROM WHERE THE RB'S REGISTERS * WERE SAVED). ALL OF THE ECB'S WAIT FLAGS (EXCEPT FOR THE ECB BEING * POSTED) ARE RESET TO ZERO. SPACE 1 */* D (NO,TCBREADY,YES,) RB SEARCH BIT IS ON*/ TMRBSTAB2,RBECBWTECB'S SEARCH FLAG SET BZTCBREADY NO, BRANCH */*LOOP3: P FIND TCB- GET SAVED ECBLIST ADDRESS*/ L R10ECBP,TCBGRS1ASSUME REGS IN TCB CLR5RB,TCBRBPECB'S RB TOP OF QUEUE BERESETWTYES, BRANCH L R3WORK,TCBRBP GET ADDRESS OF TOP RB * NOTE -- HIGH BYTE OF R3 MUST REMAIN ZERO THROUGH LOOP LOOP3L R10ECBP,RBGRS1-RBSECT(,R3WORK) LOAD RB REG 1 ICM R3WORK,M0111,RBLINKB-RBSECT(R3WORK) GET NEXT RB ADDR * (HIGH BYTE ALREADY CLEARED) CLR R3WORK,R5RBFOUND WAITING RB BNE LOOP3 NO, BRANCH I could not find anything in the manuals which says this, but it has worked this way for at least 30 years. Does this apply not only to a WAIT call using ECBLIST but also to the EVENTS call? It has been a while since I coded but I have the impression that once issued the interface would handle each ECB as a separate event and that there was no need to issue the call more than once (and that in fact if not all the ECBs were handled, it was needed to issue a EVENTS call to cancel the wait on any non-yet-posted ECBs. -- 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
The actual start of the migration off the mainframe started shortly after the current one was purchased. It replaced two older systems was meant to be the last one. Still this was more than just a get off the mainframe push, this was a complete change in culture and philosophy. Up until 1999 almost all software was homegrown and maintained. Only the financial system was from an outside vendor and the reports from it were heavily customized. The company wanted to shift from homegrown to vendor provided and in some cases even vendor hosted solutions. There was no way this was going to be done quickly due to cost alone, but the 5 year plan took twice as long because not everything was looked. Still, top management placed a guy with an accounting background over IT. In his view, shared by top management, the mainframe and its green screen was old out of date technology and the world was moving to Microsoft Windows. They really did not want to hear or understand anything else. -- 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
Mike Schwab wrote: On Fri, Dec 16, 2011 at 4:06 PM, DKM dkmf...@sbcglobal.net wrote: 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. DKM That sounds like enough hosts that they should be able to save a lot of power by rehosting on z/VM z/Linux. http://www.youtube.com/watch?v=4xL8s8WZUxo Sure does, Mike. But first you've got to dig their noses out of the airline magazines. Those young folks THINK us old fogies are fools; us old fogies KNOW the young folks are fools. Rick -- 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
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) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tapeless Solutions
So you want tapes, but not real(ly)? What are you trying to achieve, what does a TS7400 not deliver, that you are looking for? Kees. Henke, George george.he...@hp.com wrote in message news:04b3da7b71b3ab408ca62ba6046bcf8f23d485b...@gvw0676exc.americas.hpq corp.net... 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 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
