Re: Do not FTP DFDSS dump files without tersing them first
On Fri, 2 May 2014 20:48:49 -0500, John McKown wrote: >I agree that is the best. I have, so far, been successful simply by using >the STRU R command. That is not a SITE option, but a z/OS ftp server >command. > But it's easy to break STRU R. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Do not FTP DFDSS dump files without tersing them first
On Fri, 2 May 2014 18:37:13 -0400, Pinnacle wrote: >To those who have advocated sending DFDSS dumps in FTP with block mode >and EBCDIC, it works great, except when it doesn't. Got an I/O error >today during a restore. DFDSS level 2 said to terse it first, and >viola! It worked. So I'm done with block mode FTP for DFDSS dump >files. Keep using it at your own risk. You're on borrowed time. > o Was this transferred directly from z/OS to z/OS? (I suspect so, since I know no other OS that supports TYPE E, MODE B). o What were the attributes of the DFDSS dump (RECFM, LRECL, BLKSIZE)? o Were the data set attributes communicated to the recipient (z/OS FTP automates most, but perhaps not all of these)? o Is DFDSS sensitive to block boundaries? Does FTP with TYPE E MODE B preserve these? (I suspect not,) o Is there an APARable failure here (data corruption)? o Did FTP report a transmission error? Is failure to report such an error APARable? What TYPE and MODE did you use when you successfully transferred the TERSEd dump? I know (but have not reported) that the similar STRU R has one (at least) specific repeatable instance of corruption: empty records are padded with one blank. Really, really, it's a design deficiency of FTP that it can't reliably and reproducibly from one z/OS system to another, nor even from a z/OS system to a foreign OS waystation, thence to another z/OS system replicating the original z/OS data set. Adding QUOTE SITE TERSE and LOCSITE TERSE to FTP's repertoire would be a significant step toward this objective, and eliminate an error-prone additional step at each end. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change tape block size
SMF record 21 is error statistics by volume. Did you mean record 15 which deals with output activity. If you dump the SMF records, you can analyze the contents in your language of choice. I expect the most common are assembler and REXX. There are several programs on the CBT tape (cbttape.org) which process SMF data. DAF is one that is frequently recommended. :>: -Original Message- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of Victor Zhang :>: Sent: Friday, May 02, 2014 6:47 PM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: Re: Change tape block size :>: :>: If without SAS, can I format SMF 21 to get block size written to tape? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Do not FTP DFDSS dump files without tersing them first
I agree that is the best. I have, so far, been successful simply by using the STRU R command. That is not a SITE option, but a z/OS ftp server command. On May 2, 2014 5:37 PM, "Pinnacle" wrote: > To those who have advocated sending DFDSS dumps in FTP with block mode and > EBCDIC, it works great, except when it doesn't. Got an I/O error today > during a restore. DFDSS level 2 said to terse it first, and viola! It > worked. So I'm done with block mode FTP for DFDSS dump files. Keep using > it at your own risk. You're on borrowed time. > > Regards, > Tom Conley > > -- > > > -- > 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: Change tape block size
If without SAS, can I format SMF 21 to get block size written to tape? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Do not FTP DFDSS dump files without tersing them first
To those who have advocated sending DFDSS dumps in FTP with block mode and EBCDIC, it works great, except when it doesn't. Got an I/O error today during a restore. DFDSS level 2 said to terse it first, and viola! It worked. So I'm done with block mode FTP for DFDSS dump files. Keep using it at your own risk. You're on borrowed time. Regards, Tom Conley -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic TSO Submit Exit
A TSO/E exit can be localized to a single person or group for testing. Put it in an APF STEPLIB and only folks who have it their logon PROC will run the code. I stumbled on that a long time ago when I took a problem to Level 2 only to discover that I was using some ancient version of it in my STEPLIB. (Assuming that has not changed...) . . 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 From: Jon Perryman To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/02/2014 09:48 AM Subject:Re: Dynamic TSO Submit Exit Sent by:IBM Mainframe Discussion List I opted not to suggest LINKLST. Some companies use LLA refresh for production move process. Others propogate LLA refresh to all system. I suggested using MLPA because it's not a permanent change so an IPL will revert back to the original (if not in real LPA/LINKLST dataset). Jon Perryman. > > From: John McKown > > >Our IKJEFF10 (TSO submit exit) exists in LINKLIST. As I recall, in the >past, I have simply replaced the module in the proper library and did an F >LLA,REFRESH to start using the new version. Again, IIRC, this exit is >invoked by the TMP using a simple LINK (or something like LINK) >instruction. It may be necessary to have your TSO users logoff and back on >to pick up the new copy of the exit. > -- 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
PFA
So, I am looking at all this nice new stuff :) Which since I have no zIIP/zAAP will run more Java on my CP :( The installation (and SERVPAC) says to allocate a new zfs container for the /pfapath. Is there any reason not to make this /u/pfa? I have /u configured for automount and it would be "automatic" :) Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
l...@garlic.com (Anne & Lynn Wheeler) writes: > 9May2011 ... TS1140, 250MB/sec physical transfer, up to 650MB/sec compressed > transfer ... also no mention of mainfame > http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=872&letternum=ENUSAG11-0093 > also > http://en.wikipedia.org/wiki/IBM_3592 re: http://www.garlic.com/~lynn/2014f.html#64 non-IBM: SONY new tape storage - 185 Terabytes on a tape. TS1140 mentions 8Gbps fibre channel interface ... which potentially could run nearly 1gbyte/sec sustained ... which could get to terabyte in around 1000 secs. Fibre Channel will come with 32-Gigabit, 128-Gigabit speeds in 2016 http://www.pcworld.com/article/2096980/fibre-channel-will-come-with-32gigabit-128gigabit-speeds-in-2016.html 32-gigabit/sec could then get to terabyte in 250 secs and 128-gigabyte/sec could get down to terabyte in almost a minute. I've mentioned before doing channel-extender support for STL (now silicon valley lab) in 1980 (moving 300 people from the IMS group to offsite building with service back to STL datacenter ... allowing for "local" channel attached controllers at remote site). Part of it was downloading channel programs to the remote channel emulator ... to compensate for the significant channel program protocol chatter, overhead, and latency. some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender At the time, I ran into opposition to releasing it from a group in POK playing around with some fiber stuff ... they were afraid it might get in the way of eventually being able to release their stuff. In 1988, I was asked to help LLNL standardize some serial stuff they had which morphs into the fibre channel standard (includes download of i/o programs to remote ends to help compensate for latency). Finally the POK people get their fibre stuff out in 1990 with es/9000 as escon ... but it is already obsolete. Then some of the POK channel engineers get involved in fibre channel meetings and define an enormously heavy-weight protocol that drastically cuts the native throughput that eventually morphs into FICON ... some past posts http://www.garlic.com/~lynn/submisc.html#ficon as i've periodically pointed out the z196 "peak i/o" benchmark achieved 2M IOPS using 104 FICON (running on 104 fibre channel standard) about the same time there was announce of a single fibre channel for e5-2600 claiming over million IOPS (aka two @million+/sec would beat 104 FICON). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Need DB2 Administrator in Lexington KY
Hi Gang: I'm looking for DB2 Administrator - OS/390 Immediate interview & hire. If anyone interested get back to me ASAP DB2 Administrator - OS/390 Location: Georgetown, KY Duration: 13+ Months (could go very long term) Role Description: Setup and administration of mainframe OS/390 system, disk (DASD) allocation, and security administration Desired Experience: 5yrs minimum General Description : DB2 Systems Programmer who is fluent in DB2 Installation, implementation, migration between DB2 versions, implementation of New Function mode, and problem resolution processes, and provides 24x7 support in a largely batch processing environment across eight production LPARs. This person will also provide technical support to Application Developers in three geographical locations. Individual will also have installation and support requirements for IMS and associated IMS and DB2 Tools. Requirements/Must Have : Working knowledge of at least 5 years on the following products: > IBM DB2 Version 10, with New Function Mode >IBM DB2 Tools (SQL Analyzer, Log Analysis, SQL Performance Monitor, DB2 Administration Tool) > IBM Tools (Debug Tool, Fault Analyzer, File Manager, Application Performance Analyzer) >IMS >z/OS, ISPF, TSO, JCL >DFSMS >OEM Products (CA Jobtrac, Endevor, OpsMVS) Skills & Qualification : >DB2 v10 programming knowledge and experience - minimum of 5 years >DB2 upgrade experience from one version to another > DB2 implementation of New Function Mode > IMS support - performance, troubleshooting, application support experience, installation, and maintenance. > RacF security experience including generating SOX reports >Endeavor support and troubleshooting skills. > IMS support - performance, troubleshooting and application support experience > RacF security experience including generating SOX reports >Endeavor support and troubleshooting skills. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
On Fri, 2 May 2014 07:48:29 -0500, Tom Marchant wrote: >On Fri, 2 May 2014 06:38:25 -0500, Elardus Engelbrecht wrote: > >>John McKown wrote: >> >>>http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges >> >>I quickly looked at Sony's LTO tape drives (PetaSite) which uses IBM >>LTO specifications. Nice expensive things, but nothing, absolute >>nothing is written about transfer rates unless I missed it somewhere. > >IBM announced two new LTO tape drives on Monday. One is Ultrium 6: >http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-088 >http://preview.tinyurl.com/omxzxfj > >Maximum 160 MB/second media transfer rate. Native cartridge >capacity is 2.5 TB. >If I did the arithmetic correctly, that's 4.34 hours. > So, Fermi Estimate: Assuming IBM's transfer rate is approximate for Sony's cartridge, about 10**6 seconds to write a cartridge. One year is about π * 10**7 seconds, so, 0.03 years; about 12 days. >And a lower performance Ultrium 5 drive: >http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-036 >http://preview.tinyurl.com/kgxgufy > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AT-TLS question
On 2 May 2014 03:40, Peter Hunkeler wrote: >>Yes - this is probably the classic use case for AT-TLS. > > Wouldn't this only encrypt the path from ip to ip. ip would decrypt and send > plain text to WebSphere? > > I understand "application transparent" to say that the traffic is enctrypted > "on the wire" (only) without the help of applications. Am I mixing up things? Yes, it does the encryption (and more important - the negotiation) without the z/OS application having to be aware, though the app can be if it wants to. So you can configure AT-TLS via Policy Agent to do all this TLSy stuff while talking to a TLS app at the other end on any platform. If your z/OS app is the client (specified in the Policy Agent config), then if you connect from that app using ordinary TCP/IP sockets calls, AT-TLS will start with a TLS handshake, negotiate cipher suites and all the other TLS options, send and/or receive certificates as necessary, and the other end knows nothing about AT-TLS. > Are you saying that the certificate dance is not required in this scenario ? >Jim Mc. No - TLS always involves at least a server certificate, but things can be set up so that the validation is very slack indeed. The AT-TLS app does need access to a RACF keyring, but if the app is acting as a client, and the server sends a cert that is signed by a well-known CA, then you may need little more than enabling TRUST for the appropriate CA cert that's already in RACF. There is lots more you may have to do, but the idea as a whole is sound. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBUPDTE alternatives
As for your question, my suggestion is to instead of using IEBUPDTE statements, is to copy the entire source program, and make a SMPE usermod out of it with your changes added to it(sufficiently documented, of course).We already do this with a few IBM supplied source programs for TWS. It's not too bad to manage, you just run the compare against your modified usermod with the new source to see whats changed, and then reapply your local modifications to the new version of the source in your usermod. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Sidler Sent: Friday, May 02, 2014 12:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IEBUPDTE alternatives At one time I set up IEBUPDTE (or SMP/E USERMOD ++MACUPD) jobs to update some IBM sample programs before I used them to make it easier to tell what was updated from the supplied source and possible make migration to new releases easier. Now, going to a new CICS release, the sample programs no longer have sequence numbers. This breaks my IEBUPDTE process for sure. (It also breaks ISPF COMPARE to see what has changed!) Perhaps someone can save me some time and tell me what they're doing for this? TIA,... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBUPDTE alternatives
On Fri, 2 May 2014 10:18:08 -0700, Jon Perryman wrote: >Both SUPERC & SUPERCE support SEQ. For edit command COMP, you'll need to >allocate DD SYSIN to a dataset containing�the SEQ option and specify the SYSIN >option on COMP. It's silly that IBM ignores the edit bounds but such is life. Aha! I see. Using SYSIN(/) on the COMPARE command allows you to specify a dataset member with SuperC process statements. So, a statement of CMPCOLM 1:72 does the trick as far as ignoring the sequence numbers. Not SEQ as you say, since that is a process option not a process statement (as I read it). But, still this is a digression to having an IEBUPDTE alternative. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBUPDTE alternatives
SuperC & SuperCE are ISPF "Utilities" (Under Option 3) from the primary panel. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Sidler Sent: Friday, May 02, 2014 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEBUPDTE alternatives On Fri, 2 May 2014 09:35:35 -0700, Jon Perryman wrote: >It doesn't break compare. Just tell compare to ignore the sequence numbers >(SEQ). That's SuperC? I don't see that option in the ISPF EDIT/VIEW COMPARE command. -- 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: IEBUPDTE alternatives
Both SUPERC & SUPERCE support SEQ. For edit command COMP, you'll need to allocate DD SYSIN to a dataset containing the SEQ option and specify the SYSIN option on COMP. It's silly that IBM ignores the edit bounds but such is life. Jon Perryman. > > From: Phil Sidler > > > >>It doesn't break compare. Just tell compare to ignore the sequence numbers >>(SEQ). > >That's SuperC? I don't see that option in the ISPF EDIT/VIEW COMPARE command. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic TSO Submit Exit
I opted not to suggest LINKLST. Some companies use LLA refresh for production move process. Others propogate LLA refresh to all system. I suggested using MLPA because it's not a permanent change so an IPL will revert back to the original (if not in real LPA/LINKLST dataset). Jon Perryman. > > From: John McKown > > >Our IKJEFF10 (TSO submit exit) exists in LINKLIST. As I recall, in the >past, I have simply replaced the module in the proper library and did an F >LLA,REFRESH to start using the new version. Again, IIRC, this exit is >invoked by the TMP using a simple LINK (or something like LINK) >instruction. It may be necessary to have your TSO users logoff and back on >to pick up the new copy of the exit. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBUPDTE alternatives
On Fri, 2 May 2014 09:35:35 -0700, Jon Perryman wrote: >It doesn't break compare. Just tell compare to ignore the sequence numbers >(SEQ). That's SuperC? I don't see that option in the ISPF EDIT/VIEW COMPARE command. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBUPDTE alternatives
It doesn't break compare. Just tell compare to ignore the sequence numbers (SEQ). Jon Perryman. > > From: Phil Sidler > > >At one time I set up IEBUPDTE (or SMP/E USERMOD ++MACUPD) jobs to update some >IBM sample programs before I used them to make it easier to tell what was >updated from the supplied source and possible make migration to new releases >easier. Now, going to a new CICS release, the sample programs no longer have >sequence numbers. This breaks my IEBUPDTE process for sure. (It also breaks >ISPF COMPARE to see what has changed!) Perhaps someone can save me some time >and tell me what they're doing for this. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEBUPDTE alternatives
At one time I set up IEBUPDTE (or SMP/E USERMOD ++MACUPD) jobs to update some IBM sample programs before I used them to make it easier to tell what was updated from the supplied source and possible make migration to new releases easier. Now, going to a new CICS release, the sample programs no longer have sequence numbers. This breaks my IEBUPDTE process for sure. (It also breaks ISPF COMPARE to see what has changed!) Perhaps someone can save me some time and tell me what they're doing for this? TIA,... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: AW: RAS Guidelines
Sure, here you go: http://www-03.ibm.com/systems/power/hardware/whitepapers/ras.html and http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CFcQFjAF&url=http%3A%2F%2Fpublic.dhe.ibm.com%2Fcommon%2Fssi%2Fecm%2Fen%2Fpow03003usen%2FPOW03003USEN.PDF&ei=6rZjU-H0MKu6ygPp3oHYBw&usg=AFQjCNGXI_NDP06kB2-8i-j27FEwh-GDnQ&bvm=bv.65788261,d.bGQ Enough reading for the weekend Greetings from lower Bavaria Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Dave Cole Gesendet: Freitag, 2. Mai 2014 17:14 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: AW: RAS Guidelines Yeah, thanks Chris. I'll download it for bedtime reading. Still, I'm wondering if there is anything else. Thanks, Dave At 5/2/2014 10:02 AM, Christian Birr wrote: >David, >there is a good paper at >http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC4QFjAA&url=http%3A%2F%2Fwww-03.ibm.com%2Fsystems%2Fresources%2Fservers_eserver_zseries_zos_unix_pdf_docs_ras.pdf&ei=PKVjU8uBLujk4QSUkoDYCA&usg=AFQjCNEslpIWIMEIysIor4AAG594rw1j7w&bvm=bv.65788261,d.bGQ >from Bob Abrams. >Hope this helps >Christian > >-Ursprüngliche Nachricht- >>Von: IBM Mainframe Discussion List >>[mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von David Cole >>Gesendet: Freitag, 2. Mai 2014 15:48 >>An: IBM-MAIN@LISTSERV.UA.EDU >>Betreff: RAS Guidelines >> >>Does anyone know of any formal documentation from IBM providing >>guidelines for (or at least a discussion of) developing RAS-compliant code? >> >>TIA >> >>Dave Cole >>ColeSoft Marketing >>414 Third Street, NE >>Charlottesville, VA 22902 >>EADDRESS: dbc...@colesoft.com >> >>Home page: www.colesoft.com >>Facebook:www.facebook.com/colesoftware >>YouTube: www.youtube.com/user/colesoftware -- 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
But can it still read/write at 6250BPI CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | ken.porow...@cit.com This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, May 02, 2014 7:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] non-IBM: SONY new tape storage - 185 Terabytes on a tape. http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges Just how long would it take to _find and restore_ an individual file backed up on such a monster? Or even just do a backup to it? What good is it, unless there is some I/O channel fast enough to do backup and restores which utilize at least most of the tape? Or am I, once again, missing something? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: AW: RAS Guidelines
Yeah, thanks Chris. I'll download it for bedtime reading. Still, I'm wondering if there is anything else. Thanks, Dave At 5/2/2014 10:02 AM, Christian Birr wrote: David, there is a good paper at http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC4QFjAA&url=http%3A%2F%2Fwww-03.ibm.com%2Fsystems%2Fresources%2Fservers_eserver_zseries_zos_unix_pdf_docs_ras.pdf&ei=PKVjU8uBLujk4QSUkoDYCA&usg=AFQjCNEslpIWIMEIysIor4AAG594rw1j7w&bvm=bv.65788261,d.bGQ from Bob Abrams. Hope this helps Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von David Cole Gesendet: Freitag, 2. Mai 2014 15:48 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: RAS Guidelines Does anyone know of any formal documentation from IBM providing guidelines for (or at least a discussion of) developing RAS-compliant code? TIA Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS: dbc...@colesoft.com Home page: www.colesoft.com Facebook:www.facebook.com/colesoftware YouTube: www.youtube.com/user/colesoftware -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
m42tom-ibmm...@yahoo.com (Tom Marchant) writes: > Maybe because they are not mainframe tape drives. 9May2011 ... TS1140, 250MB/sec physical transfer, up to 650MB/sec compressed transfer ... also no mention of mainfame http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=872&letternum=ENUSAG11-0093 also http://en.wikipedia.org/wiki/IBM_3592 up to 4TB/tape ... 4secs/gbyte (@250MB/sec) ... 4000secs/tbyte (thousand gigabytes, 67mins) 28Apr2014 TS2260 ... only 160MB/sec http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-088 -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Test
Test Ituriel do Nascimento Neto Banco Bradesco S/A 4250 / DPCD - Engenharia de Software 910 / Sistemas Operacionais Mainframe Tel. : 55 11 3684-2177 Agora é BRA. BRA de Brasil. BRA de Bradesco. Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICE...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change tape block size
The original post was rejected because it looked like a LISTSERV command so I spaced the / / to hopefully get this example thru: / / EXEC SAS / / TAPE DD DSN=TAPE,DISP=SHR,RECFM=U,BLKSIZE=32760; DATA BLKSIZE; INFILE TAPE LENGTH=LEN; INPUT; LENGTH=LEN; PROC FREQ; TABLES LENGTH; will show the tabulation of how many blocks at what blksize exist on a tape. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Change tape block size
To check the result blksize, can I trust what's recorded in TMS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: RAS Guidelines
David, there is a good paper at http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CC4QFjAA&url=http%3A%2F%2Fwww-03.ibm.com%2Fsystems%2Fresources%2Fservers_eserver_zseries_zos_unix_pdf_docs_ras.pdf&ei=PKVjU8uBLujk4QSUkoDYCA&usg=AFQjCNEslpIWIMEIysIor4AAG594rw1j7w&bvm=bv.65788261,d.bGQ from Bob Abrams. Hope this helps Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von David Cole Gesendet: Freitag, 2. Mai 2014 15:48 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: RAS Guidelines Does anyone know of any formal documentation from IBM providing guidelines for (or at least a discussion of) developing RAS-compliant code? TIA Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS: dbc...@colesoft.com Home page: www.colesoft.com Facebook:www.facebook.com/colesoftware YouTube: www.youtube.com/user/colesoftware -- 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
RAS Guidelines
Does anyone know of any formal documentation from IBM providing guidelines for (or at least a discussion of) developing RAS-compliant code? TIA Dave Cole ColeSoft Marketing 414 Third Street, NE Charlottesville, VA 22902 EADDRESS: dbc...@colesoft.com Home page: www.colesoft.com Facebook:www.facebook.com/colesoftware YouTube: www.youtube.com/user/colesoftware -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
Getting back to the original content:
COBOL Support have identified an error in a COBOL v5.1 run-time routine, and
have opened APAR PI17184 to address it. A fixing PTF could be available as
soon as end of May, 2014.
-jc-
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
>
> On Mon, 14 Apr 2014 12:24:05 +, Chase, John wrote:
>
> >Hi All,
> >
> >I learned via PMR that Rational Developer for System z ("RDz") v9.x ("latest
> >& greatest") does not
> "officially" support Enterprise COBOL v5.1. The workaround suggested by RDz
> Support was to specify
> COBOL v4.2 and XMLPARSE(XMLSS) in the RDz wizard, because COBOL v5.1 does not
> support
> XMLPARSE(COMPAT). We did that, and the resulting program source generated by
> RDz compiled "clean"
> with COBOL v5.1, but ABENDs when invoked in CICS. The same source compiled
> with the COBOL v4.2
> compiler runs fine in CICS.
> >
> >At the suggestion of the IBMer handling the RDz PMR I've opened a Request
> >for Enhancement (RFE) on
> Developerworks. You may view the RFE at:
> >
> > http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=5
> > 0856
> >
> This sort of thing shouldn't require an RFE. When a vendor commits to
> supporting a product such as
> COBOL, the commitment should state, and customers should demand, that be
> _at_its_current_level_.
>
> How many ISVs reading this list would decline to support their products under
> z/OS 2.1 because they
> were purchased at 1.13? But I'd expect some latency for development and
> testing and/or requirement of
> an upgrade to the current level of the ISV product.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu
> with the message: INFO IBM-MAIN
**
Information contained in this e-mail message and in any attachments thereto is
confidential. If you are not the intended recipient, please destroy this
message, delete any copies held on your systems, notify the sender immediately,
and refrain from using or disclosing all or any part of its content to any
other person.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
On Fri, 2 May 2014 08:04:23 -0500, Elardus Engelbrecht wrote: >Tom Marchant wrote: > >>IBM announced two new LTO tape drives on Monday. One is Ultrium 6: >>http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-088 > >Thanks. I must have missed that announcement somehow. I will pass it on to my >storage guys to keep them occupied. Maybe because they are not mainframe tape drives. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
Tom Marchant wrote: >IBM announced two new LTO tape drives on Monday. One is Ultrium 6: >http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-088 Thanks. I must have missed that announcement somehow. I will pass it on to my storage guys to keep them occupied. I'm impressed that it has 2 SAS ports. >Maximum 160 MB/second media transfer rate. Native cartridge capacity is 2.5 TB. >If I did the arithmetic correctly, that's 4.34 hours. You're correct. That is about 260 minutes, give or take, for 2.5 TB, but the time may vary due to compression, latency and transfer times. Tom, many thanks for posting those links. I'm really appreciating it! Groete / Greetings Elardus Engelbrech -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List age
Built in to z/OS 2.1... It was at least 29 years old as of March. https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/Eo4W_SDRz0M I never did fully accomplish this desire :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New install library size
On May 1, 2014, at 7:02 PM, retired mainframer wrote: > What did you two do with your PHBs and bean counters? The salesman for our Hitachi reseller got us a really good deal. Shane said something about MVS being a small part. While we originally purchased the VSP for the mainframe, when our open systems storage guys started having lots of failures on their commodity arrays, we offered to let them add to our VSP and use it. They liked it so well that they’ve been adding more and more storage on the VSP ever since; now the mainframe is only using about 10% of the installed capacity. We’re happy, and the salesman’s happy too. -- Curtis Pew (c@its.utexas.edu) ITS Systems Core The University of Texas at Austin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
On Fri, 2 May 2014 06:38:25 -0500, Elardus Engelbrecht wrote: >John McKown wrote: > >>http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges > >>Just how long would it take to _find and restore_ an individual file >>>backed up on such a monster? Or even just do a backup to it? >>>What good is it, unless there is some I/O channel fast enough to >>>do backup and restores which utilize at least most of the tape? > >I quickly looked at Sony's LTO tape drives (PetaSite) which uses IBM >LTO specifications. Nice expensive things, but nothing, absolute >nothing is written about transfer rates unless I missed it somewhere. IBM announced two new LTO tape drives on Monday. One is Ultrium 6: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-088 http://preview.tinyurl.com/omxzxfj Maximum 160 MB/second media transfer rate. Native cartridge capacity is 2.5 TB. If I did the arithmetic correctly, that's 4.34 hours. And a lower performance Ultrium 5 drive: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS114-036 http://preview.tinyurl.com/kgxgufy -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
When the company is in litigation and needs data from years back for evidence in court, a few hundred dollars for some tapes seem very cost effective, as opposed to losing a case, or being charged with negligence for loosing data (very high fines apply)! Roger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, May 02, 2014 7:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape. On Fri, May 2, 2014 at 6:38 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > John McKown wrote: > > > > http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-le > ad-185-tb-cartridges > > Hmmm , interesting, but the webpage is slow. > > >Just how long would it take to _find and restore_ an individual file > backed up on such a monster? Or even just do a backup to it? What good > is it, unless there is some I/O channel fast enough to do backup and > restores which utilize at least most of the tape? > > I quickly looked at Sony's LTO tape drives (PetaSite) which uses IBM > LTO specifications. Nice expensive things, but nothing, absolute > nothing is written about transfer rates unless I missed it somewhere. > > >Or am I, once again, missing something? > > What if the tape itself is broken or teared? Granted, it is years ago > I encountered a teared tape, but ... > Good point! We had a 3592J tape cart tear just last year. What was especially bad is that it was a 3494 VTS back store tape. So by losing this one physical tape, we lost about 50 virtual 3490 volumes. We were very lucky that the tape was not full and that the virtual volumes lost contained mainly test data. I had argued at the time of installation that we should separate VTS virtual volumes by "environment" with each "environment" having its own set of back store tapes. And then duplexing the back store tapes which contained production data. I was shot down in flames because: (1) 3592J tapes are _expensive_ and duplexing would not be "cost effective"; and (2) it's too difficult to set up! (by the storage admin at the time). > > Groete / Greetings > Elardus Engelbrecht > > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
Vernooij, CP (SPLXM) wrote: >>What if the tape itself is broken or teared? Granted, it is years ago I >>encountered a teared tape, but ... >Thats a different subject: if you decided you don’t need to duplicate your >data, don't cry at the moment you need the duplicate copy. Indeed a different subject. We have different methods of backups. So if one media breaks, we have another media, usually at another location. But for me, tearing is just the same as INIT/overwriting a live tape full of precious jewels. I said on IBM-MAIN on 2012/10/11 this: "Since we got a robot, incorrect mounts disappeared... unless you get a x13 or x14 abend. Then these ops eject it, INIT it and re-mount it with disastrous results!" In one scenario of that ejecting error, one of those tapes were used by TSM (ADSM). The next day one of our servers crashed and guess... the same tape they needed to do their recovery was on THAT tape! That operator nearly lost his job because of that error. I think the client is still crying today about his loss... To come to the topic, having one big fancy media is nice, but you need to duplicate it on another media. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
What a kind way to say that I'm "near sighted" :-} . It is very true that I am not used to thinking in terms of a "mega center". Your thoughts opened up a whole new realm for me. I'm too used to a small, "cost conscious" (cheap) environment. On Fri, May 2, 2014 at 7:03 AM, Russell Witt wrote: > True if you look at this as a primary media for a single user. But > instead, look at this as the back-end storage media for a multi-user > virtual-tape environment (virtual-tape in the cloud configuration). Now, > instead of having hundreds of Tbytes of data from one customer on the tape > you have a Tbyte of data from hundreds of customers. So if customer A wants > to retrieve their 100-Tbytes of data it is spread across 100 of these > tapes; all retrieving at the same time. Now, if a dozen clients all try to > retrieve at exactly the same time you might have a performance issue. But > if only 1 or 2 of those clients retrieve at any one time, no problem at all. > > And you wouldn't (I hope) keep all your eggs in one basket, but instead > the Cloud-Virtual-Tape back-end would create at least 2 (3 or 4?) copies > onto a super-high capacity cartridge. As the final back-end storage for has > migrated through 2 or 3 other faster access media, this would be great. For > the data that was written once, read often for the first 30-90 days; seldom > for next year; and then will most likely never be read again but must be > maintained for 100+ years - perfect. And there is a LOT of data that is > falling into this category. > > Russell Witt > > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
What if the tape itself is broken or teared? Granted, it is years ago I encountered a teared tape, but ... Groete / Greetings Elardus Engelbrecht -- Thats a different subject: if you decided you don’t need to duplicate your data, don't cry at the moment you need the duplicate copy. 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
Time flies, so does technique: some 10 years ago STK revealed us the secret that they almost had the 1TB tape ready for production. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, May 02, 2014 13:16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: non-IBM: SONY new tape storage - 185 Terabytes on a tape. http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges Just how long would it take to _find and restore_ an individual file backed up on such a monster? Or even just do a backup to it? What good is it, unless there is some I/O channel fast enough to do backup and restores which utilize at least most of the tape? Or am I, once again, missing something? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
True if you look at this as a primary media for a single user. But instead, look at this as the back-end storage media for a multi-user virtual-tape environment (virtual-tape in the cloud configuration). Now, instead of having hundreds of Tbytes of data from one customer on the tape you have a Tbyte of data from hundreds of customers. So if customer A wants to retrieve their 100-Tbytes of data it is spread across 100 of these tapes; all retrieving at the same time. Now, if a dozen clients all try to retrieve at exactly the same time you might have a performance issue. But if only 1 or 2 of those clients retrieve at any one time, no problem at all. And you wouldn't (I hope) keep all your eggs in one basket, but instead the Cloud-Virtual-Tape back-end would create at least 2 (3 or 4?) copies onto a super-high capacity cartridge. As the final back-end storage for has migrated through 2 or 3 other faster access media, this would be great. For the data that was written once, read often for the first 30-90 days; seldom for next year; and then will most likely never be read again but must be maintained for 100+ years - perfect. And there is a LOT of data that is falling into this category. Russell Witt On 05/02/14, John McKown wrote: http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges Just how long would it take to _find and restore_ an individual file backed up on such a monster? Or even just do a backup to it? What good is it, unless there is some I/O channel fast enough to do backup and restores which utilize at least most of the tape? Or am I, once again, missing something? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
On Fri, May 2, 2014 at 6:38 AM, Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > John McKown wrote: > > > > http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges > > Hmmm , interesting, but the webpage is slow. > > >Just how long would it take to _find and restore_ an individual file > backed up on such a monster? Or even just do a backup to it? What good is > it, unless there is some I/O channel fast enough to do backup and restores > which utilize at least most of the tape? > > I quickly looked at Sony's LTO tape drives (PetaSite) which uses IBM LTO > specifications. Nice expensive things, but nothing, absolute nothing is > written about transfer rates unless I missed it somewhere. > > >Or am I, once again, missing something? > > What if the tape itself is broken or teared? Granted, it is years ago I > encountered a teared tape, but ... > Good point! We had a 3592J tape cart tear just last year. What was especially bad is that it was a 3494 VTS back store tape. So by losing this one physical tape, we lost about 50 virtual 3490 volumes. We were very lucky that the tape was not full and that the virtual volumes lost contained mainly test data. I had argued at the time of installation that we should separate VTS virtual volumes by "environment" with each "environment" having its own set of back store tapes. And then duplexing the back store tapes which contained production data. I was shot down in flames because: (1) 3592J tapes are _expensive_ and duplexing would not be "cost effective"; and (2) it's too difficult to set up! (by the storage admin at the time). > > Groete / Greetings > Elardus Engelbrecht > > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Dynamic TSO Submit Exit
Our IKJEFF10 (TSO submit exit) exists in LINKLIST. As I recall, in the past, I have simply replaced the module in the proper library and did an F LLA,REFRESH to start using the new version. Again, IIRC, this exit is invoked by the TMP using a simple LINK (or something like LINK) instruction. It may be necessary to have your TSO users logoff and back on to pick up the new copy of the exit. On Thu, May 1, 2014 at 7:25 PM, Jon Perryman wrote: > TSO exits are not designed to be dynamic but you can do things to make it > work dynamically. I don't use these exits so I can't say specifically what > will work. Here is what I would try. Be sure to consider overhead when > implementing your exits. > > 1. Try placing the the exit into LPA and use SETPROG to replace it as > needed. Each user may need to logoff/logon to get the new version of the > exit. > > 2. If that does not work, then CSVDYNEX was designed specifically to > implement / call exits. This method would require you create a stub submit > exit that simply calls CSVDYNEX REQUEST=CALL passing the R0/R1 that was > received by the stub. This method has more overhead and could possibly be > high overhead for very large jobs. To reduce the overhead, you could have > use REQUEST=CALL at JOB (and first time) and have it return the address you > actually want to call. Your stub exit would then save this address in the > exit parms for subsequent calls and call this address from the stub. > > There are other methods available but try these before you use them. Those > methods were specifically disabled by IBM for a reason (e.g. security > exposures). If you must use insecure methods, then only use them for > development purposes on a standalone system. > > Jon Perryman > > > > > > From: Dno > > > > > > > >Can it be done? Install a new version, back off if necessary without an > IPL? > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
John McKown wrote: >http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges Hmmm , interesting, but the webpage is slow. >Just how long would it take to _find and restore_ an individual file backed up >on such a monster? Or even just do a backup to it? What good is it, unless >there is some I/O channel fast enough to do backup and restores which utilize >at least most of the tape? I quickly looked at Sony's LTO tape drives (PetaSite) which uses IBM LTO specifications. Nice expensive things, but nothing, absolute nothing is written about transfer rates unless I missed it somewhere. >Or am I, once again, missing something? What if the tape itself is broken or teared? Granted, it is years ago I encountered a teared tape, but ... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: non-IBM: SONY new tape storage - 185 Terabytes on a tape.
On Fri, 2 May 2014 06:16:13 -0500, John McKown wrote: >Or am I, once again, missing something? ;-) Maybe it's a new family - WORF (write once, read forever). Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
non-IBM: SONY new tape storage - 185 Terabytes on a tape.
http://www.itworld.com/storage/416783/sony-develops-tape-tech-could-lead-185-tb-cartridges Just how long would it take to _find and restore_ an individual file backed up on such a monster? Or even just do a backup to it? What good is it, unless there is some I/O channel fast enough to do backup and restores which utilize at least most of the tape? Or am I, once again, missing something? -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Change tape block size
Victor Zhang wrote: >Is there a way to centrally change default tape block size? Is there a reason why you want to change the default tape block size? >Can TAPEBLKSZLIMIT in DEVSUPxx do this? Perhaps [1] , but see IBM's recommendation about coding a value larger than 32760. Groete / Greetings Elardus Engelbrecht [1] - We are not using it at all. We let the system decides on the optimal block size. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AT-TLS question
I would have thought you might have a few problems if you don't have a keyring for your client that trusts the Windows Server's CA. But, there's nothing like testing to prove a theory. Mike Wawiorko Please consider the environment before printing this e-mail -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim McAlpine Sent: 02 May 2014 11:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AT-TLS question Are you saying that the certificate dance is not required in this scenario ? Jim Mc. On Thu, May 1, 2014 at 6:38 PM, Tony Harminc wrote: > On 1 May 2014 07:48, Jim McAlpine wrote: > > We have the need to encrypt messages sent from z/OS on a particular > > port > to > > an application running under Webshere on Windows. The outgoing > > messages > are > > HTTP protocol and they would need to be converted to the HTTPS that > > Websphere understands. Is that something that can be done with AT-TLS. > > Yes - this is probably the classic use case for AT-TLS. You should > "simply" be able to configure Policy Agent so that all traffic from > your particular jobname and/or source or destination IP address is > forced to use TLS. If you don't require client authentication via > certificates (the normal case for a person sitting at a browser), then > things should be pretty straightforward once you catch on to the > gratuitously novel syntax of the Policy Agent configuration files. > > Tony H. > > -- > 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 This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Change tape block size
Hello all, Is there a way to centrally change default tape block size? Can TAPEBLKSZLIMIT in DEVSUPxx do this? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AT-TLS question
Are you saying that the certificate dance is not required in this scenario ? Jim Mc. On Thu, May 1, 2014 at 6:38 PM, Tony Harminc wrote: > On 1 May 2014 07:48, Jim McAlpine wrote: > > We have the need to encrypt messages sent from z/OS on a particular port > to > > an application running under Webshere on Windows. The outgoing messages > are > > HTTP protocol and they would need to be converted to the HTTPS that > > Websphere understands. Is that something that can be done with AT-TLS. > > Yes - this is probably the classic use case for AT-TLS. You should > "simply" be able to configure Policy Agent so that all traffic from > your particular jobname and/or source or destination IP address is > forced to use TLS. If you don't require client authentication via > certificates (the normal case for a person sitting at a browser), then > things should be pretty straightforward once you catch on to the > gratuitously novel syntax of the Policy Agent configuration files. > > Tony H. > > -- > 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
AW: Re: RMF / SMF CPU Time
>TRY DAF on the CBTTAPE.ORG or maybe file 019 FLSMFJOB? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AT-TLS question
>Yes - this is probably the classic use case for AT-TLS. Wouldn't this only encrypt the path from ip to ip. ip would decrypt and send plain text to WebSphere? I understand "application transparent" to say that the traffic is enctrypted "on the wire" (only) without the help of applications. Am I mixing up things? -- Peter Hunkeler Von: Tony Harminc An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: AT-TLS question Datum: 01.05.14 19:38 On 1 May 2014 07:48, Jim McAlpine wrote: > We have the need to encrypt messages sent from z/OS on a particular port to > an application running under Webshere on Windows. The outgoing messages are > HTTP protocol and they would need to be converted to the HTTPS that > Websphere understands. Is that something that can be done with AT-TLS. Yes - this is probably the classic use case for AT-TLS. You should "simply" be able to configure Policy Agent so that all traffic from your particular jobname and/or source or destination IP address is forced to use TLS. If you don't require client authentication via certificates (the normal case for a person sitting at a browser), then things should be pretty straightforward once you catch on to the gratuitously novel syntax of the Policy Agent configuration files. Tony H. -- 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
AW: Re: Android TN3270 client
ROTFLOL ... and some blue berries for desert? -- Peter Hunkeler >Eat bleu cheese? In a message dated 5/1/2014 1:43:29 P.M. Central Daylight Time, featse...@gmail.com writes: Not sure what a bluetooth mouse would do?! -- 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: SMS: managing overflow (Quiesced) volumes in each Storage Group
Neil,
How really true your comment is: now I am going to look if the dynamically
Quiescing the top 5 emptiest volumes can improve my current method of handling
large datasets in another storage group.
Currently I have two scenarios for different storage groups:
1. Very stable, but slowly growing SGs, with mainly DB2 tables. There I have 1
Quiesced volume and if something is allocated on it, I get an email, enable the
volume and add a new Quiesced volume to the SG.
2. A very dynamic SG for user and production datasets. There I have 10 Quiesced
volumes and an Extend SG and an overflow SG. Furthermore, I have changed all
SCs to Multi-Tiered, so SMS will first try to fill the Quiesced volumes in the
current SG before trying the overflow SG. The Quiesced volumes will be used for
large datasets that do not fit on the enabled volumes. The overflow SG will
normally be empty unless there is really no more space in the current SG. In
fact a 3-stage allocation scenario.
I first emptied the Quiesced volumes entirely daily, which costs time and CPU
and appears to move large datasets from one Quiesced volume to another. Now I
move only the not so very large datasets and they find a place on the enabled
volumes. However, the consequence is that the Quiesced volumes slowly fill up
with very large datasets and lose their function as last resort for very large
datasets.
I think I will introduce your sorting algorithm to see if this can constantly
provide free, Quiesced, space for the large datasets. If it does, I don't have
to move datasets anymore in order to provide adequate Quiesced space, I only
have to change the Quiesced volumes.
Thanks for sharing this idea: again this proves that combining ideas will
result in more than the sum of them. Sort of 1+1=3.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Neil Duffee
Sent: Thursday, May 01, 2014 17:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS: managing overflow (Quiesced) volumes in each Storage Group
It's interesting how simply listening in to the conversation here can prompt an
idea you wouldn't have otherwise. I need to thank Kees for this one tho' he
was pursuing a completely different (forgotten to me now) problem.
Like many/most, I have 1-2 quiesced volumes in each SMS Storage Group to
provide overflow for sporadic, large allocations. After several years of
running a daily process scraping (or attempting to) the datasets off those
volumes ('cause they are usually RLSEd to a much smaller value), I occasionally
encounter some occurrences where I can't move the dataset ie. never closed (DB2
tablespace), never released (mounted HFS/ZFS), still too big (bounces from one
Quiesced volume to another), etc. Starting yesterday, I've adopted Kees
attitude of "who cares which is the quiesced volume." I now sort each pool by
free space (not percentage), Quiesce,New the top two if they aren't already,
and Enable anything beyond the 1st five. That way, if someone plunks down a
large dataset on my overflow volume and it's no longer in the top 5, I'll
abandon it to general use (Enabled) and pick the next best volume(s) in the
group (to Quiesce,New).
If that happens over several days, it's a sign that I need to add more volumes
tho' my pools are mostly stable these days. It also means I'll have to change
my tactics when I want to empty a volume. I used to Quiesce,New but now I'll
have to use Disable,New. Oh, yeah, I also have an overflow pool that's tacked
on by the ACS routine to all allocations. When those get used, it indicates a
serious aberration in the pool size or activity.
Tho' Kees probably thought it was some extraneous information, describing his
problem in more than scant detail has provided inspiration elsewhere. I rarely
contribute (being digested daily helps/hinders) but am grateful to simply watch
the information flow. Tks much, folx.
> signature = 6 lines follows <
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot "For every
action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer 2004
--
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, copie
