Re: silicon photonics - faster than copper
On Thu, 17 Jan 2013 22:43:22 -0500, Shmuel Metz (Seymour J.) wrote: No; electrons have a non-zero rest mass. However, an electromagnetic field moves at c, so the Devil is in the details. Use of the term rest mass might lead the reader to expect electrons traveling at relativistic velocities. I read long ago (I naven't the citation) that electrons in a conductor in fact move at an average velocity more like walking speed. An electric pulse moving at 0.7 c (or so) doesn't involve electrons moving at that speed; it's more like a compression wave that far outpaces the individual particles it comprises. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cisco IPSEC client for Nexus Android tablet
Is there such a thing as the above ? Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed
Thanks, now I have one more place to check if I run across this error. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony Fletcher Sent: Thursday, January 17, 2013 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF RC20 on SELECT PGM(xxx) PARM(yyy) clues needed Too embarrassing! The return code was 20 and the reason code was 40. 40 means that the PGM was not found anywhere in the search set of data sets. Someone had removed the essential data set from the LINKLIST without telling anyone else. Of course it would have been much easier if the application had shown the reason code. regards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
On Fri, Jan 18, 2013 at 12:54 AM, R.S. r.skoru...@bremultibank.com.pl wrote: deleted c) you can use assymetric cryptography to exchange the keys. The safest way, probably he most complicated. deleted Public key? Where anybody can encode with the public key, but only the private key, kept by the sender, can decode? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
W dniu 2013-01-18 10:25, Mike Schwab pisze: On Fri, Jan 18, 2013 at 12:54 AM, R.S. r.skoru...@snip.com.pl wrote: deleted c) you can use assymetric cryptography to exchange the keys. The safest way, probably he most complicated. deleted Public key? Where anybody can encode with the public key, but only the private key, kept by the sender, can decode? That's why asymmetric cryptography was creted. Yes, site A can publish your public key and site B can use it to encrypt some message (it can be another key, symmetric). The message can be decrypted by site A only, because only site A has private key. We don't use asymmetric crypto for everyday use, because it's very CPU-consuming, about 1000 times more than symmetric. BTW: SSL handshake process in general work as described above. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS COMMAND VIA BATCH
Hi all, I think it is not possible to vary a sms volume throught a IKJ. You need to use Naviquest. There is a chapter in the DFSMS Storage Admin. Manual about this facility. Fábio Date: Thu, 17 Jan 2013 07:30:50 -0800 From: jhn_da...@yahoo.com.au Subject: SMS COMMAND VIA BATCH To: IBM-MAIN@LISTSERV.UA.EDU G'Day, I am trying to execute the following command via batch however I was unsuccessful : COMMAND VARY NOT FOUND Could anybody suggest how I can correct my problem: /* //STEP001 EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * VARY SMS,VOLUME(SMC1G5),DISABLE,NEW /* // Thanks in advance. -- 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: ICSF Symmetric Key being sent to a non-zOS system
Yes. I've read the manual enough that I believe that I understand the process. Define a an exported key with a clear value (so I know what it is). Give the value of the exporter key to the target site, wrap the symmetric key with the exporter key, and send that key to the them. I don't know how it works on the other side, if the they're not a zOS shop with ICSF. Mark Jacobs On 01/17/13 20:53, Walt Farrell wrote: On Thu, 17 Jan 2013 12:39:11 -0800, Phil Smith p...@voltage.com wrote: Mark Jacobs wrote: I've been reading the ICSF Applications Programmers guide and I understand the process on how to transport ICSF keys to another zOS system using importer/exporter keys, but I have no idea on how it would work on a non-zOS platform. Can anyone point me to some doc, or share their process if they've already done it? FYI, there's no such thing as an ICSF key. There are keys of various sorts that ICSF manages, but they aren't ICSF-ized per se. I guess if they're wrapped (encrypted) in a Crypto Express, they could be sort of thought of as being bound to ICSF, but they still are really just 56 or 64 or 128 or 192 or 256 or however many bits of key material. So...having said that, what do you mean by how it would work on a non-z/OS platform? How WHAT would work? An AES key is an AES key: if you have an AES algorithm and a key, you can encrypt data, and you'll get the same result on any platform (assuming you're using the same AES mode, etc.). I feel like I'm taking you to task here, and I don't mean to be - just trying to understand what your real question is! I read it as, how would I extract a key from ICSF and send it to a non-z/OS system? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mocha TN3270 on Android now available
There is something called AnyConnect ICS+ from Cisco Systems on the Google Play app store, which looks to be their VPN client. Thanks, Mark Regan From: Jim McAlpine jim.mcalp...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, January 17, 2013 12:13 PM Subject: Re: Mocha TN3270 on Android now available Is there a Cisco IPSEC client available for Android ? Jim McAlpine On Wed, Jan 16, 2013 at 10:58 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: Original Message Subject: Mocha TN3270 on Android now available Date: Sat, 12 Jan 2013 17:56:49 -0500 From: Tony Thigpen t...@vse2pdf.com Reply-To: VSE Discussion List vs...@lists.lehigh.edu To: vmes...@listserv.uark.edu ib...@listserv.uark.edu, vs...@lehigh.edu vs...@lehigh.edu For two years I have been waiting for a TN3270 client for my droid. One guy released something about 6 months ago, but the user interface was poor. About once every 6 months, I emailed Mocha to see if they were doing anything, but every time they replied we don't see a market, maybe you should consider an iPhone. Well, today, I did my 'ever so often' scan for TN3270 on Droid and this time I got a hit from where else but Mocha! http://mochasoft.dk/android_**3270.htmhttp://mochasoft.dk/android_3270.htm I have installed the trial version on my phone and it actually looks good (based on 5 minutes of playing). It may need a little refinement (like named connections) but at least we have something. I guess there is a Santa Claus. -- Tony Thigpen __**_ VSE-L mailing list vs...@lists.lehigh.edu https://lists.lehigh.edu/**mailman/listinfo/vse-lhttps://lists.lehigh.edu/mailman/listinfo/vse-l --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Passing of Chris Mason reported
Shmuel's borrowed Churchill quotation would perhaps have been an effective riposte to my post if it too had not been botched: 'errant' should be 'arrant'. 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: SMS COMMAND VIA BATCH
Try activating a console session before you issue the VARY command. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Fabio Luiz Pereira Sent: Friday, January 18, 2013 5:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS COMMAND VIA BATCH Hi all, I think it is not possible to vary a sms volume throught a IKJ. You need to use Naviquest. There is a chapter in the DFSMS Storage Admin. Manual about this facility. F�bio Date: Thu, 17 Jan 2013 07:30:50 -0800 From: jhn_da...@yahoo.com.au Subject: SMS COMMAND VIA BATCH To: IBM-MAIN@LISTSERV.UA.EDU G'Day, I am trying to execute the following command via batch however I was unsuccessful : COMMAND VARY NOT FOUND Could anybody suggest how I can correct my problem: /* //STEP001 EXEC PGM=IKJEFT01 //SYSPRINT DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * VARY SMS,VOLUME(SMC1G5),DISABLE,NEW /* // Thanks in advance. -- 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 of its attachments may contain Prince George’s County Government or Prince George's County 7th Judicial Circuit Court proprietary information or Protected Health Information, which is privileged and confidential. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited by federal law and may expose you to civil and/or criminal penalties. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP Apply Question
On 1/17/2013 10:56 AM, Dazzo, Matt wrote: I have a shared global zone between lpars with targets for each lpar. I am applying RSU maint, one lpar has osmf on it and one does not. What I would like to do is on one lpar is exclude applying the ptf's for the fmids pertaining to osmf but apply all the other ptf's in the RSU package I pulled down. I have looked in the smp commands guide on the apply command and saw that the you can't EXCLUDE by FMID? Any suggestions on excluding ptf's for certain FMID's? You're right, you can't EXCLUDE by FMID. You'll have to exclude individual PTFs. However, why do you want to exclude them? If z/OSMF is installed in the subject LPAR, why not keep the service current and in sync with z/OS, even if you aren't running z/OSMF? You may decide later to run it. As a matter of fact, due to requisites between z/OS and z/OSMF, you may be forced to APPLY them anyway. That is, there may be PTFs in z/OS that contain ++IFREQ for PTFs in z/OSMF. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP Apply Question
Kurt, thanks that's what I decided to do. Too many ptf's to exclude and I thought maybe we would use it later at some point. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, January 18, 2013 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP Apply Question On 1/17/2013 10:56 AM, Dazzo, Matt wrote: I have a shared global zone between lpars with targets for each lpar. I am applying RSU maint, one lpar has osmf on it and one does not. What I would like to do is on one lpar is exclude applying the ptf's for the fmids pertaining to osmf but apply all the other ptf's in the RSU package I pulled down. I have looked in the smp commands guide on the apply command and saw that the you can't EXCLUDE by FMID? Any suggestions on excluding ptf's for certain FMID's? You're right, you can't EXCLUDE by FMID. You'll have to exclude individual PTFs. However, why do you want to exclude them? If z/OSMF is installed in the subject LPAR, why not keep the service current and in sync with z/OS, even if you aren't running z/OSMF? You may decide later to run it. As a matter of fact, due to requisites between z/OS and z/OSMF, you may be forced to APPLY them anyway. That is, there may be PTFs in z/OS that contain ++IFREQ for PTFs in z/OSMF. Kurt Quackenbush -- IBM, SMP/E Development -- 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
FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
I can't get an FTP PUT to work with dataset names that contain a dollar sign (x'5B', which is the pound sign on the target system). Source system is z/OS, codepage IBM-500 Target system is z/OS, codepage IBM-285 FTP commands: TYPE E SITE ISPFSTATS PUT 'USERA.TSO.EXEC($TEST)' QUIT The output is: EZA1701I STOR 'USERA.TSO.EXEC($TEST)' 501 Invalid data set name ''USERA.TSO.EXEC($TEST)'. Use MVS Dsname conventions. EZA1735I Std Return Code = 27501, Error Code = 2 This happens with all dataset types and members, except for loadmodules, i.e. I can PUT load modules with lcd/cd/put even if they contain dollar signs in their name. Any clues? Thanks, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
The # is invalid in a dataset name. There is an FTP command (SBDataconn) to tell FTP to perform a specific translation. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B9A1/5.65?SHELF=f1a1bkd1DT=20120118035151 for details (watch the wrap). Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | allan.stal...@kbmg.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Boris Lenz Sent: Friday, January 18, 2013 7:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: FTP z/OS to z/OS 501 Invalid data set name - codepage issue? I can't get an FTP PUT to work with dataset names that contain a dollar sign (x'5B', which is the pound sign on the target system). Source system is z/OS, codepage IBM-500 Target system is z/OS, codepage IBM-285 FTP commands: TYPE E SITE ISPFSTATS PUT 'USERA.TSO.EXEC($TEST)' QUIT The output is: EZA1701I STOR 'USERA.TSO.EXEC($TEST)' 501 Invalid data set name ''USERA.TSO.EXEC($TEST)'. Use MVS Dsname conventions. EZA1735I Std Return Code = 27501, Error Code = 2 This happens with all dataset types and members, except for loadmodules, i.e. I can PUT load modules with lcd/cd/put even if they contain dollar signs in their name. Any clues? Thanks, Boris -- 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: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, January 18, 2013 15:08, Staller, Allan wrote: The # is invalid in a dataset name. Sorry about the ambiguity, I meant the English pound sign for the English currency (£). That's x'5B' in the UK codepage IBM-285. There is an FTP command (SBDataconn) to tell FTP to perform a specific translation. At the risk of not understanding the documentation, I've already tried out every possible combination of codepages in the SBDataconn command that I could think of, without any success. What's your suggestion for SBDataconn? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, 18 Jan 2013 14:47:13 +0100, Boris Lenz boris.l...@ims.sells.ch wrote: I can't get an FTP PUT to work with dataset names that contain a dollar sign (x'5B', which is the pound sign on the target system). Source system is z/OS, codepage IBM-500 Target system is z/OS, codepage IBM-285 FTP commands: TYPE E SITE ISPFSTATS PUT 'USERA.TSO.EXEC($TEST)' QUIT The output is: EZA1701I STOR 'USERA.TSO.EXEC($TEST)' 501 Invalid data set name ''USERA.TSO.EXEC($TEST)'. Use MVS Dsname conventions. EZA1735I Std Return Code = 27501, Error Code = 2 You could, of course, specify a second name on your PUT command to rename the data set or member to something different that will work on the remote site (i.e., that does not use the problematic national characters). PUT local-name remote-name -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
I don't have a specific recommendation. I would look for a '$' (USD) sign in the IBM-200 codepage . ISTR that the x'5B' is a currency symbol and is used in multiple code pages as dollar pound euro. for display purposes. The only thing I can say is that the ultimate value of the byte under discussion must be x'5B' to satisfy the internal needs of z/OS. It is possible that there is a bug in the translation tables used. If all else has been eliminated, I would open a PMR with the COMM SERVER folks. snip On Fri, January 18, 2013 15:08, Staller, Allan wrote: The # is invalid in a dataset name. Sorry about the ambiguity, I meant the English pound sign for the English currency (£). That's x'5B' in the UK codepage IBM-285. There is an FTP command (SBDataconn) to tell FTP to perform a specific translation. At the risk of not understanding the documentation, I've already tried out every possible combination of codepages in the SBDataconn command that I could think of, without any success. What's your suggestion for SBDataconn? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, January 18, 2013 15:37, Walt Farrell wrote: You could, of course, specify a second name on your PUT command to rename the data set or member to something different that will work on the remote site (i.e., that does not use the problematic national characters). Yes, I could. But what I'm after is something like PUT 'USERA.TSO.EXEC(*)', which will fail on the very first member and abort ($ is first in the alphabet...). x'5B' is a valid character in a dataset and member name, no matter which codepage. So I should be able to transfer a dataset that has a x'5B' character in its name. Thanks, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
Look at the Digital Certificate exchange process. It is the basis of SSL (HTTPS, SSH, Secure FTP). It should be supported on most platforms. It uses assymetric cryptography to encrypt the crypt the symmetric key. And the RSA encryption does use a bunch of CPU for a brief moment to encrypt the symmetric key. Steve RPS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Thursday, January 17, 2013 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ICSF Symmetric Key being sent to a non-zOS system I've been reading the ICSF Applications Programmers guide and I understand the process on how to transport ICSF keys to another zOS system using importer/exporter keys, but I have no idea on how it would work on a non-zOS platform. Can anyone point me to some doc, or share their process if they've already done it? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, 18 Jan 2013 15:15:47 +0100, Boris Lenz wrote: At the risk of not understanding the documentation, I've already tried out every possible combination of codepages in the SBDataconn command that I could think of, without any success. What's your suggestion for SBDataconn? Did you specify the same conversion at both ends? E.g.: quote site sbdataconn=(IBM-1047,ISO8859-1) locsitesbdataconn=(IBM-1047,ISO8859-1) ...? so whatever perversion is introduced at the transmitting end might be undone at the other. I had expected that translation would apply not to the names, only to the content. I guess that's wrong. Also discussed here recently: EBCDIC MODE B ... which transmits the data in untranslated binary. I don't know what happens to data set names. And that combination introduces spurious 0x40 in RECFM=VB data sets; seems to be no problem with F or U. Walt suggested specifying both names. That might not play well with MPUT/MGET. I hate EBCDIC! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Jan 18, 2013, at 07:15, Boris Lenz wrote: Sorry about the ambiguity, I meant the English pound sign for the English currency (£). That's x'5B' in the UK codepage IBM-285. Hmmm... ...[O]n September 23, 1999, communication with the [Mars Climate Orbiter] was lost as the spacecraft went into orbital insertion, due to ground based computer software which produced output in Imperial units of pound-seconds (lbf×s) instead of the metric units of newton-seconds (N×s) specified in the contract between NASA and Lockheed. http://en.wikipedia.org/wiki/Mars_Climate_Orbiter cites: ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf Likewise, any protocol that quietly translates $ to £ might lead to some very expensive mistakes in business transactions. I suspect lawyers prudently insist on U.S. dollars and U.K. pounds. Did Lockheed get paid? Sounds like of breach of contract. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, January 18, 2013 16:20, Paul Gilmartin wrote: Did you specify the same conversion at both ends? E.g.: quote site sbdataconn=(IBM-1047,ISO8859-1) locsitesbdataconn=(IBM-1047,ISO8859-1) I tried a lot. 'quote' is not necessary I think, when talking to a z/OS host. Frankly, I don't even understand why there should be a need for any code page conversion. I don't want to convert anything. Surely, I don't want to convert $ to £, nor $ (x'5B' in IBM-500) to $ (x'4B' in IBM-285). I want x'5B' to remain x'5B' - and I don't care how x'5B' appears in an emulator with code page 285 (it'll be £ though). Thanks, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
In IBM environments there is a hoary practice and tradition of defining x'5b' as the 'currency symbol', so named because it is municipal in its associated grapheme, '€' | '¥' | '$' | '£' | whatever, as is locally appropriate. The adoption of the euro has reduced their effective number, but there are still many currency symbols in local use, and a distinct code point for each was once deemed too expensive in an SBCS. Yet another argument for, minimally, DBCS versions of Unicode. 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: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
That's interested I worked Lu 6.2 xref and we never had to specify EBCDIC ..only binary Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 18, 2013, at 10:20 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 18 Jan 2013 15:15:47 +0100, Boris Lenz wrote: At the risk of not understanding the documentation, I've already tried out every possible combination of codepages in the SBDataconn command that I could think of, without any success. What's your suggestion for SBDataconn? Did you specify the same conversion at both ends? E.g.: quote site sbdataconn=(IBM-1047,ISO8859-1) locsitesbdataconn=(IBM-1047,ISO8859-1) ...? so whatever perversion is introduced at the transmitting end might be undone at the other. I had expected that translation would apply not to the names, only to the content. I guess that's wrong. Also discussed here recently: EBCDIC MODE B ... which transmits the data in untranslated binary. I don't know what happens to data set names. And that combination introduces spurious 0x40 in RECFM=VB data sets; seems to be no problem with F or U. Walt suggested specifying both names. That might not play well with MPUT/MGET. I hate EBCDIC! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, 18 Jan 2013 11:35:50 -0500, Scott Ford wrote: That's interested I worked Lu 6.2 xref and we never had to specify EBCDIC ..only binary How well did it deal with RECFM=VB? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS COMMAND VIA BATCH
It can become a problem if someone needs to make a change to the SCDS (such as update an ACS routine) and activate it while forgetting that some ACDS updates are not present in the SCDS. Once the SCDS is activated (which means it is copied to the ACDS), the previous ACDS updates disappear. So if the reason you disabled the volume is still valid, you would not be happy if it were suddenly re-enabled. If the operator command you issued (such as V SMS,...) is intended to be a permanent fix to the problem at hand, once it has been satisfactorily tested I would immediately update the SCDS with the same change. That way, a future SCDS update will not introduce a regression problem. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John Dawes :: Sent: Friday, January 18, 2013 6:16 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: SMS COMMAND VIA BATCH :: :: Retired Mainframer, :: :: I think you hit the nail on the head. Would it be a problem if ACDS and :: SCDS do not show the same status? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, 18 Jan 2013 17:34:07 +0100, Boris Lenz wrote: On Fri, January 18, 2013 16:20, Paul Gilmartin wrote: Did you specify the same conversion at both ends? E.g.: quote site sbdataconn=(IBM-1047,ISO8859-1) locsitesbdataconn=(IBM-1047,ISO8859-1) I tried a lot. 'quote' is not necessary I think, when talking to a z/OS host. Agreed. I tried three different (UNIX) clients and all accepted SITE without QUOTE. I don't recall whether in the past I encountered ond that required QUOTE, or it's used in an example somewhere. Of course, the IETF RFCs don't govern client user interfaces; RFC 959 doesn't even mention QUOTE. But have you tried both SITE and LOCSITE, with identical arguments, in the same transaction? Frankly, I don't even understand why there should be a need for any code page conversion. I don't want to convert anything. Surely, I don't want to convert $ to �, nor $ (x'5B' in IBM-500) to $ (x'4B' in IBM-285). Me, too. But have you tried EBCDIC; MODE B? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: silicon photonics - faster than copper
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Thursday, January 17, 2013 10:32 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: silicon photonics - faster than copper :: :: W dniu 2013-01-17 18:23, retired mainframer pisze: :: While photonic components (switches, etc) may be faster than the :: current :: semi-conductor ones, can the wiring really be a factor. Don't both :: electricity and light move at c? :: :: Neither light nor electricity move at c. :: :: Speed of light depends on the media. c is for vacuum. For fiber optic it :: is c/RI RI - refractive index, approx. 1.46 :: So for the calculations people tend to use speed of light (still in the :: FO) as 200 000 000 m/s. :: :: Now, speed of electricity is higher it's approx. 3/4 c. However I can't :: remember explanation for the number. This implies that the faster speed of the optical system has almost nothing to do with the wiring as claimed. Thus we have another example of brain-dead journalism. Either the reporter didn't understand what he was told and chose to embellish it incorrectly or he simply repeated whatever buzz words he got from the PR department. Neither case engenders confidence. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, January 18, 2013 18:11, Paul Gilmartin wrote: But have you tried both SITE and LOCSITE, with identical arguments, in the same transaction? Yes. Me, too. But have you tried EBCDIC; MODE B? Yes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
Yes, but I need to export a secure key to another platform. I don't believe I can export a secure key using the ICSF api's without wrapping it in an export key. The one piece of the puzzle that i don't have is, how does the non-zOS target platform unwrap the symmetric key from the exporter key so they can import it into their system. Mark Jacobs On 01/18/13 09:50, Steve Finch wrote: Look at the Digital Certificate exchange process. It is the basis of SSL (HTTPS, SSH, Secure FTP). It should be supported on most platforms. It uses assymetric cryptography to encrypt the crypt the symmetric key. And the RSA encryption does use a bunch of CPU for a brief moment to encrypt the symmetric key. Steve RPS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Thursday, January 17, 2013 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ICSF Symmetric Key being sent to a non-zOS system I've been reading the ICSF Applications Programmers guide and I understand the process on how to transport ICSF keys to another zOS system using importer/exporter keys, but I have no idea on how it would work on a non-zOS platform. Can anyone point me to some doc, or share their process if they've already done it? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- 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 -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
I'm not sure how this relates to MVS-only transfers, but x'5B' (in my
editor, dollar sign) cannot be used in file names sent to IBM TESTCASE in
support of SRs. The venerable tool PUTDOC has long handled dollar sign and
pound/number sign by translating to @:
/*/
/* If the destination is testcase, replace any '#' or '$' or */
/* '{' in the data set name with '@'.@ALA*/
/*/
Users of PUTDOC may not be aware of this translation--althhough it's fully
visible in generated data set names--but trying to directly FTP names
containing problem characters fails with a message about 'authorization'
or some such obfuscation.
.
.
JO.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: Boris Lenz boris.l...@ims.sells.ch
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 01/18/2013 09:15 AM
Subject:Re: FTP z/OS to z/OS 501 Invalid data set name -
codepage issue?
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
On Fri, January 18, 2013 18:11, Paul Gilmartin wrote:
But have you tried both SITE and LOCSITE, with identical arguments,
in the same transaction?
Yes.
Me, too. But have you tried EBCDIC; MODE B?
Yes.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cisco IPSEC client for Nexus Android tablet
On 1/18/2013 at 03:11 AM, Jim McAlpine jim.mcalp...@gmail.com wrote: Is there such a thing as the above ? http://lmgtfy.com/?q=cisco+ipsec+client+for+android Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP z/OS to z/OS 501 Invalid data set name - codepage issue?
On Fri, 18 Jan 2013 18:15:18 +0100, Boris Lenz wrote:
On Fri, January 18, 2013 18:11, Paul Gilmartin wrote:
But have you tried both SITE and LOCSITE, with identical arguments,
in the same transaction?
Yes.
Me, too. But have you tried EBCDIC; MODE B?
Yes.
The evidence implies that commands are translated from EBCDIC to
ASCII at the client and from ASCII to EBCDIC at the server using
the default code pages ate the respective sites, and SBDATACONN
is applied only to the data content. Sounds like material for a PMR.
Any affirmative resolution could avoid incompatibility only by
introducing a new option.
It might be interesting, though minimally useful, to experiment
with an ASCII client and z/OS server to test what ASCII character
strings are translated to valid EBCDIC data set names. What's the
CP 285 grapheme for the code point 0x5B ('$', perhaps)?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: silicon photonics - faster than copper
W dniu 2013-01-18 18:14, retired mainframer pisze: :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Thursday, January 17, 2013 10:32 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: silicon photonics - faster than copper :: :: W dniu 2013-01-17 18:23, retired mainframer pisze: :: While photonic components (switches, etc) may be faster than the :: current :: semi-conductor ones, can the wiring really be a factor. Don't both :: electricity and light move at c? :: :: Neither light nor electricity move at c. :: :: Speed of light depends on the media. c is for vacuum. For fiber optic it :: is c/RI RI - refractive index, approx. 1.46 :: So for the calculations people tend to use speed of light (still in the :: FO) as 200 000 000 m/s. :: :: Now, speed of electricity is higher it's approx. 3/4 c. However I can't :: remember explanation for the number. This implies that the faster speed of the optical system has almost nothing to do with the wiring as claimed. Thus we have another example of brain-dead journalism. Either the reporter didn't understand what he was told and chose to embellish it incorrectly or he simply repeated whatever buzz words he got from the PR department. Neither case engenders confidence. Well, you demand the reporters to have knowledge. Bad. :-) I use to teach about SAN, FICONs and fiber optic technology in general, usually the students are IT professionals, but believe me I have to explain them the difference between throughput and speed, people don't feel it's two-dimensional. My explanation (loosely translated to English): when you double the speed expressed in Gbps, for example from 8 to 16 GBps that means your train now have doubled number of cars (carriages). But the speed of light remain unchanged so it will take same time to travel from Lodz to Warsaw. Be aware, that very often you send small packets, only locomotive is sent. So, speed (Gbps) cannot compensate the distance. Speed helps with bulk data transfer, but doesn't help with interactive conversation. BTW: Why people use Fiber Optics? In very short: distance (not the case) EM interference (lack of them) - that's the reason! Big speed (in Gbps) available - copper is limited by the above, FO is not. BTW2 Google for AVAGO MicroPOD and US Conec PRIZM LighTurn - the future is now. ;-) -- 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: ICSF Symmetric Key being sent to a non-zOS system
W dniu 2013-01-18 18:24, Mark Jacobs pisze: Yes, but I need to export a secure key to another platform. I don't believe I can export a secure key using the ICSF api's without wrapping it in an export key. The one piece of the puzzle that i don't have is, how does the non-zOS target platform unwrap the symmetric key from the exporter key so they can import it into their system. Please, beliebve you can export the key in clear form. It is possible. BTDT. KGUP is your friend. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
sfi...@recoverypoint.com (Steve Finch) writes: Look at the Digital Certificate exchange process. It is the basis of SSL (HTTPS, SSH, Secure FTP). It should be supported on most platforms. It uses assymetric cryptography to encrypt the crypt the symmetric key. And the RSA encryption does use a bunch of CPU for a brief moment to encrypt the symmetric key. PKI Digital Certificate has some smoke and mirrors associated with it. Relying party needs secure repository of trusted public keys that is distributed by some trusted out-of-band process. Then the relying party can use public key from their secure respository to validate some digitially signed information. SSL, HTTPS, PKI, etc uses a level indirection. A repository of (certification authority) trusted public keys are embedded in browser distribution. Individuals can present public key to certification authority which does some validation process and generates a digitally signed (using a certification authority private key) digital certificate that attests to some equivalence between something that the individual claimed (like a name, or url, etc) and the presented public key. Subsequently an individual can transmit some digitally signed information (with their corresponding private key), with their appended digital certificate. The recipient (relying party) validates the CA's issued digital certificate by using the CA's public key from the previously distributed trusted repository (part of the browser distribution). Once the digital certificate has been validated, the recipient can extract the sender's public key from the digital certificate and validate the sender's digital signature on the transmitted message (to validate that the message really originated from the entity that the sender claims to be). In SSL, the recipient/client can also generate a session symmetric secret key, encrypt it with the server/sender's public key (from the validated digital certificate) and return it to the sender. Only the originally sender with the corresponding private key can decrypt the client's generated session symmetric secret key. Subsequent SSL communication then takes place with the client's session symmetric secret key In any case, for limited environment ... it is possible to exchange your own public keys out-of-band and keep them in your own trusted repository for future session key exchange w/o requiring 3rd party digital certificates (and having out-of-band distribution of the public keys from digital certificate issuing Certification Authorities kept in your trusted public key repository). lots of disclaimers: long ago and far away we were brought in to small client/server startup that wanted to do payment transactions on their servers, the small startup had also invented this technology called SSL they wanted to use; the result is now frequently called electronic commerce. Along the way we had to map the technology to payment business operations as well as establish some requirements for operation and use of SSL (some of which were almost immediately violated ... resulting in many of the exploits that continue until this day). some related posts http://www.garlic.com/~lynn/subnetwork.html#gateway we had been brough in to help word-smith the cal. electronic signature act which was under heavy pressure from the certification authority industry to mandate that electronic signatures could only be done with digital signatures and digital certificates. some past posts http://www.garlic.com/~lynn/subpubkey.html#signature Some past RSA show, the IBM executive that crypto reported to, was showing some Certification Authority (now defunct) CEO around the show ... and insisted on introducing the CEO to me. The CEO asked me what I did. I said that I was working on eliminating Certification Authorities from the face of the earth. I've frequently pointed out that the SSL Certification Authority industry is dependent on the domain name system integrity and that their proposal to improve the integrity of the domain name system can also result in no longer needing SSL http://www.garlic.com/~lynn/subpubkey.html#catch22 we have dozens of (assigned) patents in the area of public key use w/o using Certification Authorities and/or digital certificates http://www.garlic.com/~lynn/aadssummary.htm -- 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
Re: silicon photonics - faster than copper
I saw a recent TV special with Michio Kako where he explained the more dense the transistors the more heat was produced. That manufactures , I.e.; Intel and others were quickly approaching their limits on how dense they can be. So the manufactures were looking at other bases for the transistors, like ceramic ...it was very interesting Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 18, 2013, at 1:36 AM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2013-01-17 18:31, Martin, Larry D pisze: But light doesn't create heat; thus more circuits in a smaller space.. 1. Light could create heat, but I strongly believe this is not the case in such application due to powers which could be used. The problem occurs in long distance links (undersea cables for example) or outside of IT. 2. I would worry about transmitters. Transmitters do create heat. 3. There are also receivers. While heating of receivers is not nightmare for engineers, they do create a hit also. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Break a dataset into new record boundaries?
There was a drive in PERL-MVS (http://lists.perl.org/list/perl-mvs.html) to work on that stuff, but it looks like that they had to drop EBCDIC support because there were no porters. I myself do not posses the needed expertise, so I did not reply, but you may view the latest email (from a year ago) here: http://www.mail-archive.com/perl-mvs@perl.org/msg01451.html They seem to suggest that one coul;d compile Perl on z/OS, though (sans EBCDIC I assume) Ze'ev Atlas 201-801-0378 201-805-0286 (cell) From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, January 17, 2013 9:52 PM Subject: Re: Break a dataset into new record boundaries? In 1358352865.70255.yahoomail...@web120503.mail.ne1.yahoo.com, on 01/16/2013 at 08:14 AM, Ze'ev Atlas zatl...@yahoo.com said: Don't misunderstand me, I love Rexx... just would want it to have better IO and regular expressions (in z/OS - on other platforms Rexx already has this capability, though in POSIX sematics). To that end, I've ported PCRE to z/OS That should be useful, although it would still be nice to have a current Perl; 4.8.7 is pretty long in the tooth. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 http://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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching for storage (DASD) alternatives
On Thu, 17 Jan 2013 22:26:58 -0500, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: The original code base precedes FBA. Once they added FBA most of the work was done for FCP SCSI. I'm not sure what you're saying. MVS, VM, and VSE code bases *all* precede the invention of channel-attached FBA. They weren't engineered for use by MVS (e.g. originally no RESERVE/RELEASE), but it didn't matter since MVS wasn't engineered to accept device geometries that weren't based on (CYL, TRK, REC) addressing and allocation units. The CMS and CP file systems are based on fixed-size blocks, hiding the device geometry. Further, all usage by CP and CMS is on cylinder boundaries. So from both an application and dasd management perspective, FBA didn't present a huge problem for the people and programs involved. But adding SCSI device drivers was a Big Deal, requiring a lot of heavy lifting, and introducing a lot of new configuration and terminology (WWPN, LUN, NPIV) into the host OS. In VM, you either give the guest direct access to an HBA and let the guest talk to the device, or you use EDEVICEs, wherein CP will emulate FBA minidisks on SCSI LUNs. More interesting, I think, are the cultural barriers to SCSI, particularly with z/OS. When you use SCSI, you (the sysprog) typically don't own or manage the storage. It isn't typically directly plugged into your z box, but is part of a storage area network (SAN) with its own connectivity, performance, security, and recovery technologies (e.g. no IOP-managed multipathing) and management endpoints. You are beholden to and dependent on other admins in other lines of management. I have to say that this doesn't sit will with many mainframe shops that have been bastions of glass-house self-sufficiency for generations. And the consultants have to scramble, too, since all the rules of thumb change. Folks like to look for cheaper dasd, and I don't blame them, but I have to say 'be careful what you wish for.' :-) Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICSF Symmetric Key being sent to a non-zOS system
Mark, Haven't had to do it.. but here are a couple of ideas. http://www-01.ibm.com/support/docview.wss?uid=isg3T1010756 http://tools.ietf.org/html/draft-hoyer-keyprov-portable-symmetric-key-container-02 Once the key material is clear.. there are a plethora of ways to encrypt it that would be compatible on the other platforms. This has a plethora of OpenSSL uses.. one was how to encrypt an encryption key. http://security.ncsa.illinois.edu/research/grid-howtos/usefulopenssl.html Unfortunately, OpenSSL doesn't port to z/OS. I am sure the guys at PKWARE can do it... since they run on all the platforms. The only issue is still getting the key out in the clear.. and getting into the next container securely. I suppose transporting values that need to be XORed together. ICSF supports a remote key load for ATMs which might be worth a look. If you have OpenPGP running on z/OS... then I suppose you could use it as the transportation vehicle. HTH, Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Fri, Jan 18, 2013 at 1:08 PM, Anne Lynn Wheeler l...@garlic.comwrote: sfi...@recoverypoint.com (Steve Finch) writes: Look at the Digital Certificate exchange process. It is the basis of SSL (HTTPS, SSH, Secure FTP). It should be supported on most platforms. It uses assymetric cryptography to encrypt the crypt the symmetric key. And the RSA encryption does use a bunch of CPU for a brief moment to encrypt the symmetric key. PKI Digital Certificate has some smoke and mirrors associated with it. Relying party needs secure repository of trusted public keys that is distributed by some trusted out-of-band process. Then the relying party can use public key from their secure respository to validate some digitially signed information. SSL, HTTPS, PKI, etc uses a level indirection. A repository of (certification authority) trusted public keys are embedded in browser distribution. Individuals can present public key to certification authority which does some validation process and generates a digitally signed (using a certification authority private key) digital certificate that attests to some equivalence between something that the individual claimed (like a name, or url, etc) and the presented public key. Subsequently an individual can transmit some digitally signed information (with their corresponding private key), with their appended digital certificate. The recipient (relying party) validates the CA's issued digital certificate by using the CA's public key from the previously distributed trusted repository (part of the browser distribution). Once the digital certificate has been validated, the recipient can extract the sender's public key from the digital certificate and validate the sender's digital signature on the transmitted message (to validate that the message really originated from the entity that the sender claims to be). In SSL, the recipient/client can also generate a session symmetric secret key, encrypt it with the server/sender's public key (from the validated digital certificate) and return it to the sender. Only the originally sender with the corresponding private key can decrypt the client's generated session symmetric secret key. Subsequent SSL communication then takes place with the client's session symmetric secret key In any case, for limited environment ... it is possible to exchange your own public keys out-of-band and keep them in your own trusted repository for future session key exchange w/o requiring 3rd party digital certificates (and having out-of-band distribution of the public keys from digital certificate issuing Certification Authorities kept in your trusted public key repository). lots of disclaimers: long ago and far away we were brought in to small client/server startup that wanted to do payment transactions on their servers, the small startup had also invented this technology called SSL they wanted to use; the result is now frequently called electronic commerce. Along the way we had to map the technology to payment business operations as well as establish some requirements for operation and use of SSL (some of which were almost immediately violated ... resulting in many of the exploits that continue until this day). some related posts http://www.garlic.com/~lynn/subnetwork.html#gateway we had been brough in to help word-smith the cal. electronic signature act which was under heavy pressure from the certification authority industry to mandate that electronic signatures could only be done with digital signatures and digital certificates. some past posts http://www.garlic.com/~lynn/subpubkey.html#signature Some past RSA show, the IBM executive that crypto reported to, was showing some Certification Authority (now defunct) CEO around the show ... and insisted on introducing the CEO to me. The CEO asked me what I did. I said that I was working on eliminating Certification
Re: silicon photonics - faster than copper
In 50f8ec46.5030...@bremultibank.com.pl, on 01/18/2013 at 07:31 AM, R.S. r.skoru...@bremultibank.com.pl said: Neither light nor electricity move at c. Wrong except in classical Electrodynamics; the apparent slower speed of light in a material medium is due to interactions with the electrons, e.g., absorption/re-emission. ITYM that the effective speed of light in a material medium is less than the actual speed, which is c. -- 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: silicon photonics - faster than copper
Just curious... Both electricity and light are both slower than c when not in vacuum. I guess electricity is slowed down more by the dielectric constant, than light is slowed down by the reflective index... Speed of electricity From Wikipedia, the free encyclopedia == The speed at which energy or signals travel down a cable is actually the speed of the electromagnetic wave, not the movement of electrons. Electromagnetic wave propagation is fast and depends on the dielectric constant of the material. In a vacuum the wave travels at the speed of light and almost that fast in air. Propagation speed is affected by insulation, so that in an unshielded copper conductor ranges 95 to 97% that of the speed of light, while in a typical coaxial cable it is about 66% of the speed of light.[1] snip == Speed of light From Wikipedia, the free encyclopedia == The speed of light in vacuum, commonly denoted c, is a universal physical constant important in many areas of physics. Its value is 299,792,458 metres per second, a figure that is exact because the length of the metre is defined from this constant and the international standard for time.[1] In imperial units this speed is approximately 186,282 miles per second. According to special relativity, c is the maximum speed at which all energy, matter, and information in the universe can travel. It is the speed at which all massless particles and associated fields (including electromagnetic radiation such as light) travel in vacuum. It is also the speed of gravity (i.e. of gravitational waves) predicted by current theories. Such particles and waves travel at c regardless of the motion of the source or the inertial frame of reference of the observer. In the theory of relativity, c interrelates space and time, and also appears in the famous equation of mass-energy equivalence E = mc2.[2] The speed at which light propagates through transparent materials, such as glass or air, is less than c. The ratio between c and the speed v at which light travels in a material is called the refractive index n of the material (n = c / v). For example, for visible light the refractive index of glass is typically around 1.5, meaning that light in glass travels at c / 1.5 ? 200,000 km/s; the refractive index of air for visible light is about 1.0003, so the speed of light in air is about 90 km/s slower than c. snip == -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Thursday, January 17, 2013 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: silicon photonics - faster than copper While photonic components (switches, etc) may be faster than the current semi-conductor ones, can the wiring really be a factor. Don't both electricity and light move at c? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John McKown :: Sent: Thursday, January 17, 2013 4:25 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: OT: silicon photonics - faster than copper :: :: http://www.computerworld.com.au/article/446722/intel_prepares_use_lasers :: _light_shuffle_data_between_computers/ :: quote :: Intel is taking the first steps to implement thin fiber optics that :: will use lasers and light as a faster way to move data inside :: computers, replacing the older and slower electrical wiring technology :: found in most computers today. :: /quote -- 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 COMMAND VIA BATCH
In blu165-w50b6d4409c4150bbd0cef592...@phx.gbl, on 01/18/2013 at 10:02 AM, Fabio Luiz Pereira fabiolu...@hotmail.com said: I think it is not possible to vary a sms volume throught a IKJ. VARY is not a TSO command, so IKJEFT01 can't perform it directly, but I know of no reason that an authorized user couldn't use the CONSOLE command to issue the VARY. -- 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: silicon photonics - faster than copper
Maybe you should argue with Michio Kaku ..not me kiddo Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 18, 2013, at 9:06 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 50f8ec46.5030...@bremultibank.com.pl, on 01/18/2013 at 07:31 AM, R.S. r.skoru...@bremultibank.com.pl said: Neither light nor electricity move at c. Wrong except in classical Electrodynamics; the apparent slower speed of light in a material medium is due to interactions with the electrons, e.g., absorption/re-emission. ITYM that the effective speed of light in a material medium is less than the actual speed, which is c. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Searching for storage (DASD) alternatives
alan_altm...@us.ibm.com (Alan Altmark) writes: I'm not sure what you're saying. MVS, VM, and VSE code bases *all* precede the invention of channel-attached FBA. They weren't engineered for use by MVS (e.g. originally no RESERVE/RELEASE), but it didn't matter since MVS wasn't engineered to accept device geometries that weren't based on (CYL, TRK, REC) addressing and allocation units. re: http://www.garlic.com/~lynn/2013.html#30 Searching for storage (DASD) alternatives CP/CMS used ckd search paradigm as if it was fixed-block ... so when real FBA came along, it was trivial to remap to fixed-block. Note that a lot of CP/CMS had heavy influence from MIT CTSS/7094 ... which predated 360 CKD. ctss reference http://en.wikipedia.org/wiki/Compatible_Time-Sharing_System aka some number of the CTSS people went to the 5th flr to do Multics and others went to the IBM science center on the 4th flr and did virtual machines, internal network, bunch of other stuff. misc. past posts http://www.garlic.com/~lynn/subtopic.html#545tech OS/360 made heavy use of CKD multi-track search especially for vtoc and pds directories. I've frequently pontificated it was mid-60s trade-off between real-storage to maintain the information and channel/controller/device resource to perform the search outboard and the trade-off had inverted by the mid-70s; I would even get called into OS/VS2 multi-system accounts that were experiencing serious throughput problems because of the heavy used of multi-track search ... recent post about getting called into large national retailer ... after all the usual POK experts had been tried http://www.garlic.com/~lynn/2013.html#25 I've also periodically mentioned that I was told that even if I provided MVS with integrated and fully-tested FBA support ... that I still needed to show a $26M business case to cover education, documentation, training ... basically several hundred million dollars in incremental FBA disk sales ... and specifically could not use total total lifecycle savings ... and by-the-way ... customers were buying disks as fast as they could be produced ... so any FBA support would result in just changing from CKD sales to FBA sales ... not incremental new sales. This is despite the fact that all DASD was heading in the direction of FBA ... furthermore real CKD hasn't been manufactured in decades ... and just getting initial ECKD hardware working (to pickup a little of FBA benefit) cost on par with what they quoted me for MVS FBA support. misc. past posts mentioning CKD, FBA, multi-track search, etc http://www.garlic.com/~lynn/submain.html#dasd Of course, I've had somewhat similar encounter in the early 90s over fiber-channel support ... I had been asked in the 80s to help LLNL standardize some serial stuff that they had that eventually morphs into FCS in the early 90s. Then some POK channel engineers get involved and layered some heavy-weight stuff on-top of FCS that eventually becomes FICON ... and enormously reduces throughput ... compared to the native/underlying FCS throughput. recent post discussing fcs, ficon, z196 max i/o benchmark http://www.garlic.com/~lynn/2013.html#10 From build to buy: American Airlines changes modernization course midflight -- 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
Re: ICSF Symmetric Key being sent to a non-zOS system
Is this a key that already exists in your system, and one where you don't actually know what the key is (because its encrypted under your ICSF Symmetric Master Key? Or are you wanting to generate a new key and share that key with another system? In either case, if you don't want to use Public Key cryptography, (and assuming you don't want to send a plaintext key!) you need to create multiple key parts which will be combined in order to create the key. This key will either be the actual working key you wish to share, or it will make up a transport key under which you will later encrypt your already existing (operational) working key. To create this first key (whether it be the actual working key or a transport key used to encrypt (wrap) a working key) you need to generate two or more (usually three) random numbers of the proper size (probably 16 bits; a double-length key). You can use the RANDOM function in the ICSF Utilities ISPF panel, or really you can use any sort of random number generator. For however many of these random numbers (they key parts) you want (lets say 3) you properly should have them generated in private by 3 separate people. Each of these three people will then write down their key part (their 16-bit random number), in hex form (32 hex digits) on a piece of paper. The papers with the key parts should be inserted into 3 tamper evident envelopes by the three key part custodians and should be delivered to 3 key part custodians at the partner's site. These three key parts will then be combined to form the actual key. In an ICSF/CCA system you use the Key Part Import API service (CSNBKPI) to do this. You will then want to perform a Key Test function (CSNBKYT) on the new key (which is now encrypted under your ICSF SYM Master Key). The result of this test will be a 4 byte (8 hex digit) key check value which you will want to communicate to your partner. This way they can perform the key part import (sometimes known as key part combine) on their system and generate the key check value. As long as they get the same key check value that you got, the keys are now properly paired and (hopefully!) encrypted under each partner's appropriate Master Key. I have a nice REXX EXEC that I can give you that allows you to easily perform the following functions: 1) Create a key token for the selected key type (EXPORTER, DATA, or whatever) 2) Import a key part 3) After all key parts have been imported, do a final key part import to complete the import and finalize the creation of the key. 4) Return the appropriate KCV for each key part, as well as for the final combined key. Step 2 is performed once per key part. Each step can (should) be performed by separate individuals. The first and third steps would probably be the same (fourth!) person, while the 3 part 2 steps should be performed by the 3 custodians of the key parts. Each of these 4 persons (in a pinch person number 4 can be the same person as one of the custodians) needs to have SAF authority to perform the KPI and KYT functions (and probably others I am forgetting). Person number 4 additionally needs to be able to have authority to create a key token (CSNBKTC). Assuming this key is the actual working key, once both partners have imported and combined their key parts you are ready to communicate. If the key you shared in this manner is only a transport key then you have additional steps. If you are writing a program to invoke ICSF/CCA API calls to generate a new key and encrypt it for transport do the following. If you want to use KGUP instead I'll have to research it further, as I have not done it that way. You will want to use the Key Generate service (CSNBKGN) to generate (within the secure crypto processor) a random key (of the appropriate length). The key will be both 1) Encrypted under the ICSF SYM Master Key and returned to your application as an INTERNAL key token, 2) and encrypted under the transport key (which you have supplied to the KGN service) and returned to your application as an EXTERNAL key token. You will then extract the encrypted form the EXTERNAL key token. The encrypted key (assuming a double length key) is bytes 16 - 31 (16 bytes) of the 64 byte external key token. You will communicate this value to your partner who will then import it into their system using whatever processes they have available to do so. Warning: If your working key is not a DATA or MAC key, but is rather (most of) one of the other key types there is an issue with CCA control vectors that needs to be considered. I just yesterday learned how do work with this issue if the peer is using a non-CCA system, but I won't go into more details at this point, other than to say it involves the Control Vector Translate service (CSNBCVT). Hope I answered, in at least a somewhat understandable way, your (or at least someone's!) questions. Feel free to contact me for further help,
