Re: UK NHS £10bn project failure
On Fri, 20 Sep 2013 20:06:39 +0800, David Crayford wrote: They seem to trust Amazon EC2 to deliver mission critical systems. Is this a trend or a flash in the pan? I don't have an issue with anyone using FOSS. Software that is - trusting confidential user/client data to companies subject to the draconian USA data seizure laws is lunacy. Even European hosting doesn't secure the backups on the US mainland. And yes I'm aware the the UK (and Aussie) governments are no better and certainly in cahoots with respect to things like Prism and XKeyscore. Unfortunately Scott McNealy was right all along - just took the rest of a while to catch on. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
Shane Ginnane wrote, re use of Amazon EC2 to deliver mission critical systems: I don't have an issue with anyone using FOSS. Software that is - trusting confidential user/client data to companies subject to the draconian USA data seizure laws is lunacy. Even European hosting doesn't secure the backups on the US mainland. And yes I'm aware the the UK (and Aussie) governments are no better and certainly in cahoots with respect to things like Prism and XKeyscore. Unfortunately Scott McNealy was right all along - just took the rest of a while to catch on. Indeed. The issue with EC2 and the like isn't capability or reliability, it's security. Protecting the data yourself outside the cloud-never letting unprotected data into their network-is the only real assurance you can have. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
Phil Smith wrote: begin extract Indeed. The issue with EC2 and the like isn't capability or reliability, it's security. Protecting the data yourself outside the cloud-never letting unprotected data into their network-is the only real assurance you can have. end extract/ I want to add, with as much urgency as I can muster, that high-security encryption must be used to provide this protection. No encryption scheme endorsed by Five Eyes provides any protection against them or indeed against similar Chinese groups. I, for one, judge that the intentions of the NSA are benign; but if it ever was that is no longer the issue. The technology for breaking these 'recommended' schemes is now so widely diffused that they provide only the illusion and not the substance of security. Paranoia is almost always dysfunctional. In this area it is not. We have all been far too naif for far too long. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
jwgli...@gmail.com (John Gilmore) writes: I want to add, with as much urgency as I can muster, that high-security encryption must be used to provide this protection. No encryption scheme endorsed by Five Eyes provides any protection against them or indeed against similar Chinese groups. I, for one, judge that the intentions of the NSA are benign; but if it ever was that is no longer the issue. The technology for breaking these 'recommended' schemes is now so widely diffused that they provide only the illusion and not the substance of security. Paranoia is almost always dysfunctional. In this area it is not. We have all been far too naif for far too long. it isn't just a single homogeneous entity. Spies Like Us http://www.investingdaily.com/17693/spies-like-us/ Private contractors like Booz Allen now reportedly garner 70 percent of the annual $80 billion intelligence budget and supply more than half of the available manpower. ... snip ... How Booz Allen Hamilton Swallowed Washington http://www.zerohedge.com/news/2013-06-23/visualizing-how-booz-allen-hamilton-swallowed-washington increasing privatizing of intelligence by for-profit companies focused on ever increasing quarterly profits. News is that spying on ex's is so common they even have name for it ... why wouldn't for-profit employees also be involved in industrial espionage? BAH case http://washingtontechnology.com/articles/2012/02/08/booz-allen-air-force-debarment.aspx note in the wake of this Success of Failure incident, congress put the agency on probation and not allowed to manage its own efforts ... but that may have just been ploy for further privatizng. http://www.govexec.com/excellence/management-matters/2007/04/the-success-of-failure/24107/ even some IBM connection, the head of IBM http://en.wikipedia.org/wiki/Louis_V._Gerstner,_Jr. leaves and becomes chairman of http://en.wikipedia.org/wiki/Carlyle_Group which then does private equity buyout of http://en.wikipedia.org/wiki/Booz_Allen_Hamilton slightly related http://www.garlic.com/~lynn/2013l.html#55 NSA foils much internet encryption http://www.garlic.com/~lynn/2013l.html#56 NSA foils much internet encryption -- 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
R744STRC SMF Field
Hi @all, hope someone can help me. I got stuck on a problem with a SMF field. Have someone ever tried to analyze a SMF74 ST 4 (Coupling Facility Activity) record. I do not see the value 5425 as a long floating point value in the record in any field. Can someone point me into the right direction? HELP… Thx Uwe Here is the RMF CF Report output * TOP OF DATA ** C O U P L I N G F A C I L I T Y A C z/OS V1R13 SYSPLEX PRDPLEX DATE 09/14/2013 RPT VERSION V1R13 RMF TIME 05.59.38 - COUPLING FACILITY NAME = RZAC1P1 TOTAL SAMPLES(AVG) = 897 (MAX) = 898 (MIN) = 896 - COUPLING FACILITY USAGE SUMMA - STRUCTURE SUMMARY - % OF % OF% OF STRUCTURE ALLOC CF #ALL CF TYPE NAME STATUS CHGSIZESTOR REQREQ UTIL LIST DB2D_SCA ACTIVE 33M 0.2 5425 0.5 0.4 The bold marked value is R744STRC from my point of view. In ERBSHOW I see this block. #13: +: C4C2F2C4 6DE2C3C1 40404040 40404040 *DB2D_SCA* +0010: CB3EBAB7 4D1D6525 0180 9651 *ô ¬¼( Á Øoé* +0020: 0082 * b* +0030: 4260 *â- * +0040: 4260 *â- * +0050: EA15 032E1347 * ²å* +0060: ** +0070: ** +0080: ** +0090: ** +00A0: ** SMF Field: Offset D H 52 34 R744STRC 8 l_float The total number of IXLLIST, IXLCACHE, or IXLLOCK requests made. This field will not necessarily equal the sum or R744SSRC, R744SARC, and R744SSTA due to internal processing. Use of the batch unlock function can produce large discrepancies because R744STRC is incremented for each lock being released, but only one coupling facility operation is executed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
John Gilmore wrote: I want to add, with as much urgency as I can muster, that high-security encryption must be used to provide this protection. No encryption scheme endorsed by Five Eyes provides any protection against them or indeed against similar Chinese groups. I, for one, judge that the intentions of the NSA are benign; but if it ever was that is no longer the issue. The technology for breaking these 'recommended' schemes is now so widely diffused that they provide only the illusion and not the substance of security. Paranoia is almost always dysfunctional. In this area it is not. We have all been far too naif for far too long. WellAES is well-vetted by independent cryptographers, and I'm still pretty comfortable with many times the heat-death of the universe to crack. Nothing is uncrackable if you posit unlimited computing power and time, after all. The recent Dual Elliptic Curve Deterministic Random Bit Generation fiasco is a different kettle of hamsters, but it certainly serves as an object lesson in considering whether recommended IVs are a good idea or not. ...phsiii (I r not a kryptografer, but I work with a bunch!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
http://ca.news.yahoo.com/blogs/geekquinox/china-surprises-computing-world-milky-way-2-supercomputer-163928852.html In a message dated 09/21/13 13:07:22 Central Daylight Time, p...@voltage.com writes: Nothing is uncrackable if you posit unlimited computing power and time, after all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
A chacun son goût! Anyone who judges AES adequate to his needs is of course free to use it. I will, however, add that cracking by enumeration of cases is not what I had in mind. In such terms even DES is impressive, but they are irrelevant. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Without Crypto Card?
W dniu 2013-09-20 16:00, Lloyd Fuller pisze: No. The crypto cards preceded the z machines. They were available as part of the 9672s. There are several different ones with slightly different capabilities. They are all on the I/O bus so they are slightly slower than the CPACF hardware for the same operation, but they may be more secure depending upon use. CPACF is what was added with the z990. This is a specialized processor that you access by issuing specific instructions (the K... ones). This processor has been updated with almost every new z machine. How many CPACF processors are available also varies by model. Lloyd Yes, I knew that, but my point was to start consideration from z99o and exclude older models. Not to say the premiere of the cards was with premiere of z990. Did I fail? It seem's so, English is not my native language. BTW: The information you wrote is already available in the thread. BTW2: The cards were available as part of G5 and G6 not whole 9672 family. ;-) -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
John Gilmore wrote: A chacun son goût! Anyone who judges AES adequate to his needs is of course free to use it. I will, however, add that cracking by enumeration of cases is not what I had in mind. In such terms even DES is impressive, but they are irrelevant. Do tell...? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unused variables
On 20 Sep 2013 08:12:42 -0700, in bit.listserv.ibm-main John Gilmore wrote: The idea of eliminating unreferenced variables in COBOL record declarations is of course absurd, and fulminations against it are at best otiose. It is always possible to construct quietist arguments against change, any and all change; but this straw man is too obviously so to very useful to careerist obstructionists. Basically all COBOL can do is eliminate unreferenced 77 levels which are independent (not in a structure and logically equivalent to 01 levels or records) and unused 01 (records) levels in Working-Storage. This may also apply to LOCAL-STORAGE. While fields within a record may be unused, eliminating them changes the structure and can cause problems. In one sense are we straining at gnats in an era when people send megabyte size pictures to each other over the Internet and product files may contain 1 or more pictures of each product? I agree with people that crud should be eliminated but changing record structures which may be used in multiple programs can have interesting results. Clark Morris We are left with working-storage and local-storage declarations for variables that then go unused. In many cases they were once used, but maintenance changes have made them redundant. In any case they may be eliminated safely, and they should be when an occasion to do so arises. They are individually ugly; and they add to source-program clutter, which is substantial in old COBOL programs. Whether a major undertaking, a formal project or the like, for their elimination is jusitified is another, very different question. I think not. All optimizing compilers eliminate dead code, sequences of instructions that can never be executed, and dead variables, which are never referenced. Some compilers and backends are better at these operations than others. The current IBM C/C++ and PL/I backend, for example, detects almost all aliasing schemes and even reflects these 'obscured' references in its XREF output. The current COBOL compiler does a modest but adequate job of this when full optimization is used. There is therefore almost no resource-savings argument to be made for a campaign to eliminate unreferenced variables; and further bureaucratization of this particular programming milieu is highly undesirable. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unused variables
Yeah, might have to go back and read some of those old backups for legal or otherwise unplanned situations. Probably be on the bottom of a 'to do' list as we covert to JAVA. In a message dated 09/21/13 18:18:57 Central Daylight Time, cfmpub...@ns.sympatico.ca writes: This may also apply to LOCAL-STORAGE. While fields within a record may be unused, eliminating them changes the structure and can cause problems. In one sense are we straining at gnats in an era when people send megabyte size pictures to each other over the Internet and product files may contain 1 or more pictures of each product? I agree -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List out all Indirect catalogued datasets
It seems to me you would want to do this for all the program product datasets, whether indirectly catalogued or not. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of baby eklavya :: Sent: Friday, September 20, 2013 3:07 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: List out all Indirect catalogued datasets :: :: We have our program products currently on the respack and they are :: indirectly catalogued .As a part of the OS upgrade , we are trying to :: separate them from the respack and put them on a new volume ..Then have :: the :: new volume hard coded in the catalog using DEF NVSAM . :: :: On Sat, Sep 21, 2013 at 3:32 AM, Lizette Koehler :: stars...@mindspring.comwrote: :: :: Can you explain what you are looking to do with the information? :: :: A LISTC command will list the information but you need to parse it to :: determine what is indirect. :: :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] :: On :: Behalf Of baby eklavya :: Sent: Friday, September 20, 2013 1:45 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: List out all Indirect catalogued datasets :: :: Hello , :: :: Is there a way to list out all the indirect catalogued datasets from a :: z/os :: 1.11 system ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 20130919105935.d48c3c35881ab4db81c1e...@gmx.net, on 09/19/2013 at 10:59 AM, nitz-...@gmx.net nitz-...@gmx.net said: that confirms that there is a bug somewhere in allocation. No; there are too many other variables. The same job should result in the same allocation on two different lpars, Maybe, if they are identical, which is unlikely. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
In 2372770761776465.wa.elardus.engelbrechtsita.co...@listserv.ua.edu, on 09/19/2013 at 01:19 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za said: Ok. If you say so. What was the first IBM utility? I don't know[1] what the first IBM utility was that did a dynamic allocation, but it wasn't IEHMOVE, because IEHMOVE did no such thing[2]. IEHMOVE was documented as requiring a DD statement with unit, volume and disposition; it used OPENJ to access individual data sets on the volume. [1] I suspect that it was SMP. [2] In fact, dynamic allocation didn't yet exist. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 20130919103311.ca8dd8fb03992fe99...@gmx.net, on 09/19/2013 at 10:33 AM, nitz-...@gmx.net nitz-...@gmx.net said: SPACE=(TRK,(1,0,0)), Does your first track start with an EOF? If not, what is in the first block[1]? SMS? What does your ACS specify for it? [1] I'd use AMASPZAP to dump it, but use whatever you're comfortable with. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 9823956692690441.wa.mathwstittbellsouth@listserv.ua.edu, on 09/19/2013 at 08:42 AM, Matthew Stitt mathwst...@bellsouth.net said: I also recall discussions about the minimum block size for datasets (disk and tape). It seems there was some magic about 20 bytes maybe being close to the minimum. 18. Tape, to distinguish a bad record from noise in the gap.. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 3097304782371193.wa.paulgboulderaim@listserv.ua.edu, on 09/19/2013 at 11:26 AM, Paul Gilmartin paulgboul...@aim.com said: We have evidence in this thread that what that manual says is untrue. We don't need this thread to see that what the quoted text says is untrue; there is no physical end-of-file character for CKD DASD, only a record with 0 data length. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 4360602823278101.wa.doughenryusbank@listserv.ua.edu, on 09/19/2013 at 12:17 PM, Doug Henry doug_he...@usbank.com said: But if you do a valid allocation what the manual says is correct. If you specify a valid allocation for a directory then what the manual says about Ensured Data Integrity on New Allocations is irrelevant; writing an EOF at the end has always been part of formatting a directory. What SMS added was writing an EOF for a new PS allocation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In CAJTOO59gy2LR60z=wrdn0umop773h5eq25no67qfeept6ki...@mail.gmail.com, on 09/20/2013 at 02:05 AM, Mike Schwab mike.a.sch...@gmail.com said: If we were still using real 3390s, I would suggest a track full of EOF records. Why? The first should be enough. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 523b395e.50...@valley.net, on 09/19/2013 at 01:50 PM, Gerhard Postpischil gerh...@valley.net said: I'm conflicted whether this should produce a JCL error. I can't think of any circumstance in which I wouldn't want an error message for an explicit DSORG=PO with a zero directory quantity on a new allocation. In any case, IBM should be persuaded to either produce a JCL error or modify the directory build to write an EOF. Directory build *does* write an EOF. The problem here is that there was no directory build. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 069f4b2c-987c-4e1a-9031-74b2a26a1...@yahoo.com, on 09/19/2013 at 08:28 PM, Scott Ford scott_j_f...@yahoo.com said: I guess this doesn't apply to br14 The reference to OPEN isn't relevant to IEFBR14, but allocation works the same regardless of what progam the EXEC statement specifies. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation test
In 142481833.948799.1379636086107.javamail.r...@sz0127a.westchester.pa.mail.comcast.net, on 09/20/2013 at 12:14 AM, DASDBILL2 dasdbi...@comcast.net said: I tried, unsuccessfully, four or five years ago to write an EOF record with a non-zero key length but a zero data length, On what device? and it failed with a permanent I/O error. What CSW status and sense data? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
No, Phil, it is not a question of my 'telling'. I will repeat my point just one more time. No encryption scheme that the five eyes recommend should be used in any circumstance in which you wish to be secure against them or those of their competitors who also dispose of, in practical terms, unlimited resources. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UK NHS £10bn project failure
The link doesn't go there anymore. I get top headlines only. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: efinnell15 efinnel...@aol.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Sat, 21 Sep 2013 14:31:26 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UK NHS £10bn project failure http://ca.news.yahoo.com/blogs/geekquinox/china-surprises-computing-world-milky-way-2-supercomputer-163928852.html In a message dated 09/21/13 13:07:22 Central Daylight Time, p...@voltage.com writes: Nothing is uncrackable if you posit unlimited computing power and time, after all. -- 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
