FW: VMware is looking to buy-out its parent company - EMC
That’s interesting, a few days ago there was a posting that it was going in the opposite direction, that EMC was going to buyout VMWARE -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Itschak Mugzach Sent: Thursday, August 06, 2015 2:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VMware is looking to buy-out it parent company - EMC porsche takeover volkswagen try is the most famous case of downstream takeover try, I think... ITschak ITschak Mugzach Z/OS, ISV Products and Application Security Risk Assessments Professional On Thu, Aug 6, 2015 at 5:20 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On 2015-08-05 19:53, Russell Witt wrote: This is actually weird. Even though EMC owns an 80% stake in VMware, VMware is looking to buy-out EMC. Never heard of a down-stream merger. http://fortune.com/2015/08/05/report-emc-considering-buyout-vmware/?xi d=yahoo_fortune Not too weird. In one case of which I know, a whale with an onerous government charter arranged to be swallowed by a minnow with a much more favorable charter. Of course the acquiring company got the rights to the whale's trademarks and used them. By arrangement, the officers of the vanishing company became officers of the merged company. Etc. And the general public hardly knew. Gulp, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort Join keys
Ron, Since you are using VTOF, I am guessing that your input files are VB and if they are indeed VB pay attention to the matching key field positions you have specified and correct it. You need to realize that for VB files that the actual data starts from position 5. It would be nice if you specify the product(DFSORT/Syncsort) you are using too Thanks, Kolusu DFSORT Development From: Ron Thomas ron5...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/06/2015 01:16 PM Subject:Sort Join keys Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi I have 2 files as below, need to compare them and get all the unmatched records . I used join keys but getting in the output prevoius week records only. Previous Week File |AV012620009 | 0.68| |AV012621410 | 1.09| |AV012621504 | 0.88| Current Week file |AV012620009 | 0.98| |AV012621410 | 1.99| |AV012621504 | 0.98| |AV012621502 | 0.78| Output |AV012620009 | 0.68| |AV012621410 | 1.09| |AV012621504 | 0.88| Desired o/p |AV012620009 | 0.98| |AV012621410 | 1.99| |AV012621504 | 0.98| |AV012621502 | 0.78| Sort card used JOINKEYS F1=SORTIN1,FIELDS=(2,44,A) JOINKEYS F2=SORTIN2,FIELDS=(2,44,A) JOIN UNPAIRED,F1,F2,ONLY OPTION COPY OUTFIL VTOF,BUILD=(5,133) Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort Join keys
Kolusu. The input files are FB only , so and you are right the conversion is not needed. I removed that and still there is no change. We are using Syncsort here. Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
(I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have heard that also about the Beatles on Ed Sullivan, the MASH episode where Col Blake was killed, and the MASH finale itself Chris hoelscher Technology Architect Database Infrastructure Services Technology Solution Services 123 East Main Street Louisville, KY 40202 choelsc...@humana.com Humana.com (502) 714-8615 (502) 476-2538 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Thursday, August 06, 2015 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Limit number of frames of real storage per job (I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
At least recognize it's a tuning opportunity. We lost some granularity going to WLM but there are still knobs in place to effect thruput. Cheryl's Goal Tender (at _www.watsonwalker.com_ (http://www.watsonwalker.com) ) product can tell you if your perceptions are meeting your expectations. Without more information it's difficult to say, more memory, more CPUs, zIIPs or SSD will give the most long term benefit. In a message dated 8/6/2015 1:59:11 P.M. Central Daylight Time, johnmattson...@gmail.com writes: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sort Join keys
Hi I have 2 files as below, need to compare them and get all the unmatched records . I used join keys but getting in the output prevoius week records only. Previous Week File |AV012620009 | 0.68| |AV012621410 | 1.09| |AV012621504 | 0.88| Current Week file |AV012620009 | 0.98| |AV012621410 | 1.99| |AV012621504 | 0.98| |AV012621502 | 0.78| Output |AV012620009 | 0.68| |AV012621410 | 1.09| |AV012621504 | 0.88| Desired o/p |AV012620009 | 0.98| |AV012621410 | 1.99| |AV012621504 | 0.98| |AV012621502 | 0.78| Sort card used JOINKEYS F1=SORTIN1,FIELDS=(2,44,A) JOINKEYS F2=SORTIN2,FIELDS=(2,44,A) JOIN UNPAIRED,F1,F2,ONLY OPTION COPY OUTFIL VTOF,BUILD=(5,133) Thanks Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VMware is looking to buy-out it parent company - EMC
porsche takeover volkswagen try is the most famous case of downstream takeover try, I think... ITschak ITschak Mugzach Z/OS, ISV Products and Application Security Risk Assessments Professional On Thu, Aug 6, 2015 at 5:20 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On 2015-08-05 19:53, Russell Witt wrote: This is actually weird. Even though EMC owns an 80% stake in VMware, VMware is looking to buy-out EMC. Never heard of a down-stream merger. http://fortune.com/2015/08/05/report-emc-considering-buyout-vmware/?xid=yahoo_fortune Not too weird. In one case of which I know, a whale with an onerous government charter arranged to be swallowed by a minnow with a much more favorable charter. Of course the acquiring company got the rights to the whale's trademarks and used them. By arrangement, the officers of the vanishing company became officers of the merged company. Etc. And the general public hardly knew. Gulp, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Well, I can disagree with that on a practical level to some extent. Upgrading memory can sometimes, cost wise, be more like needing so much more electric power that the power company needs to run a higher capacity line to your business and you must then install better / new equipment to support it. It might be cheaper to just find out how to decrease your power (memory) requirements. Perhaps by doing something differently. And I shudder to think what would happen here if every toilet were flushed at the same instant. On Thu, Aug 6, 2015 at 1:58 PM, John Mattson johnmattson...@gmail.com wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Hi John, You might consider changing modifying your stance when it comes to the z13 processors. Although the z13 actually has a slower chip, the processor is faster (partly) because of how they utilize memory. In the z13, IBM has lowered the price of storage so that you can get about three times the amount of storage for the same price as you're spending today. And, in fact, when going to the z13, you should consider doing exactly that! Get triple the memory you're using today (for the same price). The CPU savings will definitely be worth it. I agree with Barry's statement about memory (yes, John, you remembered correctly). And if you study how IBM runs their benchmarks, their results are obtained by running the models with no constraints, such as no paging. So if you want to get similar results, it's worth getting enough memory so that there are no constraints. Best regards, Cheryl Cheryl Watson Watson Walker, Inc. 100 Central Ave, Suite 1013 Sarasota, FL 34236 P-941-924-6565, F-941-924-4892 www.watsonwalker.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, August 6, 2015 3:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job Well, I can disagree with that on a practical level to some extent. Upgrading memory can sometimes, cost wise, be more like needing so much more electric power that the power company needs to run a higher capacity line to your business and you must then install better / new equipment to support it. It might be cheaper to just find out how to decrease your power (memory) requirements. Perhaps by doing something differently. And I shudder to think what would happen here if every toilet were flushed at the same instant. On Thu, Aug 6, 2015 at 1:58 PM, John Mattson johnmattson...@gmail.com wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have not looked at the latest info but I still believe there is a *LIMIT* to the amount of MS that one can buy per box. I also think there is a limit to MVS MS. I don't recall what it is but (they did increase it) there is still a practical limitation as to MVS MS. I am not suggesting that the subject is correct but realistically MVS can only handle so much. Ed On Aug 6, 2015, at 1:58 PM, John Mattson wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. Applications tend to evolve and grow over time. If you deliberately set up your application to avoid GC, you may be in for a rude shock when the application grows and one day GC is triggered. There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. On the other points: Stess testing - memory management is usually an important factor in application performance, so I'm not sure how valid any stress test that avoided garbage collection would be. (Processor cache effects etc. as much as GC overhead). Memory leaks - this applies to any language - if the memory isn't released, of course you need enough virtual storage to support it between restarts. Page outs - paging Java out is very different to other applications due to the GC memory access pattern. Yes, any inactive application will be subject to page out (maybe? I have seen some information about page fixed pages for Java - I don't know anything about it though). What you don't want is portions of the heap paged out from an active application. When Java performs a GC it is going to touch every page in the heap* - so if you have 200MB paged out and an innocent 50 byte memory allocation triggers GC it has to wait for 200MB of pages to be paged in one by one before the allocation completes (assuming Java/zOS don't recognize and optimize this page-in pattern). This is different to other languages where pages will be paged in one at a time as required, and only if they have active data. I'm not saying to economize on real storage, on the contrary. The original poster asked about testing Java applications with a shortage of real storage - my response is that the performance will probably be unacceptable and it's not worth testing - just make sure you DO have enough real storage for the application. On this side track of heap size and garbage collection my advice is: 1) Do not fear garbage collection. It is part of a normal Java application. It does need to be carefully tuned for response time sensitive applications, but for these applications any paging of the Java heap will likely be disastrous. 2) Do not allocate a heap so large that you risk paging instead of GC. Paging is far worse than GC for Java performance. n.b. the definition of a too large heap is a moving target. I would say it is enough storage inactive for long enough that parts of the heap might be paged out. It would be unusual for a few hundred MB in a normal batch job to be an issue. Regards Andrew Rowley Black Hill Software * My understanding of what happens. I'm happy to be corrected by someone with more knowledge of GC strategies and internals. On 6/08/2015 14:49, Timothy Sipples wrote: I agree with Andrew Rowley's advice so long as it's properly understood to be *general* advice -- rules of thumb. There are some very interesting exceptions. (Aren't there always? :-)) Regarding making the Java heap too large, there are some use cases -- Java batch, notably -- where you really do want to make the heap too large, or at least slightly too large. If the JVM is transitory, and if you can avoid any/all garbage collection during the transitory life of the program, that might be a perfectly wonderful, optimal outcome. It depends. Another potential scenario is stress testing, perhaps during the initial phases, when you're trying to understand the performance and scalability characteristics of an application before allowing garbage collection to interfere with your assessments. (Maybe you don't have the best measurement tools?) Or you're simply trying to determine how much is too much, so you start with too much in your testing. Maybe you have a defective application that's got a memory leak, and garbage collection eventually cannot accomplish anything. The application instance then abends. But to avoid restarting the application instance too frequently you throw too much memory at the application instance(s) until you and/or the vendor can fix the leak. (Been there.) (It depends on your point of view what
Re: Limit number of frames of real storage per job
Well, it doesn't break sewers. http://www.snopes.com/sports/football/flush.asp England turns on 1.75 million TEA KETTLES at the end of Eastenders each weekday. FIVE hydroelectric plants go from 0% to 100% in 5 minutes to power them. http://www.geek.com/news/tea-time-in-britain-causes-predictable-massive-surge-in-electricity-demand-1535023/ After Tiny Tim got married on the Tonight Show, so many americans turned of their TVs and lights the power reduction almost tripped off the power grid. http://www.themcdonnellgroup.com/smart-grid-blog/tiptoe-through-the-smart-grid-part-ii.html On Thu, Aug 6, 2015 at 4:42 PM, J O Skip Robinson jo.skip.robin...@sce.com wrote: (I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VMware is looking to buy-out it parent company - EMC
Capital Cities Communications purchased the much larger American Broadcasting Company in 1985. Thank You Dan Blake dbl...@fdic.gov FDIC ISC-3 CSC OM Service Delivery | Room B4072 O: (703) 516-5497 | BB: (703) 314-0501 | M: (703) 946-2967 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Itschak Mugzach Sent: Thursday, August 06, 2015 2:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VMware is looking to buy-out it parent company - EMC porsche takeover volkswagen try is the most famous case of downstream takeover try, I think... ITschak ITschak Mugzach Z/OS, ISV Products and Application Security Risk Assessments Professional On Thu, Aug 6, 2015 at 5:20 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On 2015-08-05 19:53, Russell Witt wrote: This is actually weird. Even though EMC owns an 80% stake in VMware, VMware is looking to buy-out EMC. Never heard of a down-stream merger. http://fortune.com/2015/08/05/report-emc-considering-buyout-vmware/?xi d=yahoo_fortune Not too weird. In one case of which I know, a whale with an onerous government charter arranged to be swallowed by a minnow with a much more favorable charter. Of course the acquiring company got the rights to the whale's trademarks and used them. By arrangement, the officers of the vanishing company became officers of the merged company. Etc. And the general public hardly knew. Gulp, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM OAM and 3494
I have noticed discrepancy between RMM db and OAM + Library Manager db. In RMM I see the tape S1 as SCRATCH, but OAM claims it is PRIVATE. 3494 interface also claims the volume is in PRIVATE category. What should I do to reconcile the status of the tape? The tape should be scratch. Any clue? Details: z/OS 1.13, OAM, 3494, 3592-J1A drives (only), JA carts. -- 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM OAM and 3494
With CA-1 I have the option to synchronize the status of a tape or group of tapes from the CA-1 TMC to the TCDB, which will also update the status in the library database. Does RMM have a similar function? Otherwise you can update the tape in the TCDB with ISMF, by setting it to SCRTCH there. This will also update the library database. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: 06 August, 2015 15:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: RMM OAM and 3494 I have noticed discrepancy between RMM db and OAM + Library Manager db. In RMM I see the tape S1 as SCRATCH, but OAM claims it is PRIVATE. 3494 interface also claims the volume is in PRIVATE category. What should I do to reconcile the status of the tape? The tape should be scratch. Any clue? Details: z/OS 1.13, OAM, 3494, 3592-J1A drives (only), JA carts. -- 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM OAM and 3494
On Thu, 6 Aug 2015 15:24:34 +0200, R.S. wrote: I have noticed discrepancy between RMM db and OAM + Library Manager db. In RMM I see the tape S1 as SCRATCH, but OAM claims it is PRIVATE. 3494 interface also claims the volume is in PRIVATE category. What should I do to reconcile the status of the tape? The tape should be scratch. Any clue? Details: z/OS 1.13, OAM, 3494, 3592-J1A drives (only), JA carts. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2C8A0/17.11.8 http://www-01.ibm.com/support/docview.wss?uid=isg3T1019471 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
