Re: IBM getting out of the Ed business?
On 7/20/2013 9:26 PM, Ed Gould wrote: Big Blue cedes software and systems training biz to partners http://www.channelregister.co.uk/2013/07/16/ibm_software_systems_training_channel/ *IF* this is true... is Z/os may not be far behind. Why? What's the connection? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT QUESTION -RESULTS PUZZLING -
On Sat, 20 Jul 2013 22:48:00 -0700, Lizette Koehler wrote: If you go to CBTTAPE.ORG and go for FILE206, it seems to have a REXX parser for DCOLLECT records Some (not too many) years ago I lifted a cbt offering to mangle dcollect records - needed some mods for what I wanted, but did the job admirably. Not sure if this was it, but as always, the cbt has things you can use - or use as templates at least. Maybe If I was doing it today I'd flick the file to zLinux and use tools more applicable to this century than Rexx. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DCOLLECT QUESTION -RESULTS PUZZLING -
Such as? I will grant that REXX is old. But so are PERL, awk, and many other UNIX tools. Him, perhaps lua. But there is a port of lua to z/OS. A person here was kind enough to send it to me. Oh course, I do the same. But I do it to save on z/OS MSUs. On Jul 21, 2013 2:40 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Sat, 20 Jul 2013 22:48:00 -0700, Lizette Koehler wrote: If you go to CBTTAPE.ORG and go for FILE206, it seems to have a REXX parser for DCOLLECT records Some (not too many) years ago I lifted a cbt offering to mangle dcollect records - needed some mods for what I wanted, but did the job admirably. Not sure if this was it, but as always, the cbt has things you can use - or use as templates at least. Maybe If I was doing it today I'd flick the file to zLinux and use tools more applicable to this century than Rexx. Shane ... -- 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: [MVS-OE] Looking for help with an obscure C integer problem
In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? -- 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: [MVS-OE] Looking for help with an obscure C integer problem
On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote: In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? We don't know if it is a bug without seeing Charles code asis. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Default
thanks---the crlf is in data...which is what I was questioning.defaulted in ftpparms.at least it is here... -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
Went that route on the last C compiler problem I found. Life is too short. Or at the very least, the project deadline is too short. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, July 21, 2013 5:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM vs. Amazon for Cloud
Interesting article on how IBM is working to capture the Cloud share. http://news.yahoo.com/amazon-vs-ibm-big-blue-120912394.html By Alistair Barr SAN FRANCISCO (Reuters) - The tech industry maxim that no one ever got fired for buying IBM is a testament to how Big Blue has been the gold standard in computing services for decades. But IBM faces an unlikely challenger in Amazon.com Inc(NSQ:AMZN), the e-commerce retail giant that is becoming a force in the booming business of cloud computing, even winning backing from America's top spy agency. After years of being dismissed as a supplier of online computer services to startups and small businesses, Amazon Web Services (AWS) beat out International Business Machines(NYS:IBM) this year to snag a $600 million contract with the Central Intelligence Agency. IBM has successfully appealed its loss in the contest, stalling it for now. But the episode highlights how Amazon is evolving from an online retailer into a competitive provider of information technology and services to big companies, and government bodies. IBM bought SoftLayer Technologies, a rival to AWS, for $2 billion in June. That could help it when the CIA comes calling again, said Bill Moran at Ptak Associates. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM vs. Amazon for Cloud
Lizette, Sounds like IBM is expanding their business. Not a bad thing, especially in this economy. Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Jul 21, 2013, at 10:46 AM, Lizette Koehler stars...@mindspring.com wrote: Interesting article on how IBM is working to capture the Cloud share. http://news.yahoo.com/amazon-vs-ibm-big-blue-120912394.html By Alistair Barr SAN FRANCISCO (Reuters) - The tech industry maxim that no one ever got fired for buying IBM is a testament to how Big Blue has been the gold standard in computing services for decades. But IBM faces an unlikely challenger in Amazon.com Inc(NSQ:AMZN), the e-commerce retail giant that is becoming a force in the booming business of cloud computing, even winning backing from America's top spy agency. After years of being dismissed as a supplier of online computer services to startups and small businesses, Amazon Web Services (AWS) beat out International Business Machines(NYS:IBM) this year to snag a $600 million contract with the Central Intelligence Agency. IBM has successfully appealed its loss in the contest, stalling it for now. But the episode highlights how Amazon is evolving from an online retailer into a competitive provider of information technology and services to big companies, and government bodies. IBM bought SoftLayer Technologies, a rival to AWS, for $2 billion in June. That could help it when the CIA comes calling again, said Bill Moran at Ptak Associates. Lizette -- 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: [MVS-OE] Looking for help with an obscure C integer problem
That was my attitude last time. No, I am not the least worried about competitors. One, it's a big world with room for everyone; two, the two products I work on have no head-to-head competition; and three, my impression is that an awful lot of Z commercial products are written in assembler, not C. I am just worried about my own time and sanity. In any event, even if I were to spend a bunch of my life arguing my case with IBM, I *need* a timely solution. You can't push a piece of string. I have lost patience with being more generous to IBM's customers than IBM is. They seem not to want to fix the problem (however that might be defined) so much as make their numbers by closing the ticket. IMHO. At least the level one folks; much less so once you get through to someone who knows anything. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, July 21, 2013 7:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote: Went that route on the last C compiler problem I found. Life is too short. Or at the very least, the project deadline is too short. View it as an act of generosity to others who may encounter the problem. Of course, if they're likely to be your competitors you may be disinclined to be generous. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM vs. Amazon for Cloud
Very interesting article. About a year ago I read that Amazon's profit margins on AWS were north of 40% as compared to 2% for their etailing biz. If you were Amazon,which portion of the business would be most aggresively trying to grow? Anyone who does not think that Amazon is a major IT player is kidding themselves. Sent via the Samsung GALAXY S™4, an ATT 4G LTE smartphone Original message From: Lizette Koehler stars...@mindspring.com Date: 07/21/2013 10:46 AM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM vs. Amazon for Cloud Interesting article on how IBM is working to capture the Cloud share. http://news.yahoo.com/amazon-vs-ibm-big-blue-120912394.html By Alistair Barr SAN FRANCISCO (Reuters) - The tech industry maxim that no one ever got fired for buying IBM is a testament to how Big Blue has been the gold standard in computing services for decades. But IBM faces an unlikely challenger in Amazon.com Inc(NSQ:AMZN), the e-commerce retail giant that is becoming a force in the booming business of cloud computing, even winning backing from America's top spy agency. After years of being dismissed as a supplier of online computer services to startups and small businesses, Amazon Web Services (AWS) beat out International Business Machines(NYS:IBM) this year to snag a $600 million contract with the Central Intelligence Agency. IBM has successfully appealed its loss in the contest, stalling it for now. But the episode highlights how Amazon is evolving from an online retailer into a competitive provider of information technology and services to big companies, and government bodies. IBM bought SoftLayer Technologies, a rival to AWS, for $2 billion in June. That could help it when the CIA comes calling again, said Bill Moran at Ptak Associates. Lizette -- 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: Looking for help with an obscure C integer problem
Sorry for jumping late into this thread. Why not spend another variable of type long long to do the shift there? like unsigned long long valueToTest; unsigned int testWord; unsigned long long x; x = valueToTest 32; /* here */ testWord = (int) x; If now in the expression marked with /* here */ the compiler does not do the shift as a true 64 bit shift, there is no excuse and you should report this as a bug. The cast to int is done in the next statement. In the other case there may be some strange language rules that allow the long long variable to be casted to int before the shift - I don't know, but why lose time and think much about it? Kind regards Bernd Am 20.07.2013 22:24, schrieb Charles Mills: Cross-posted to IBM-MAIN and MVS-OE. I have the following code fragment in an inline function, compiled by the IBM XLC compiler as C++: unsigned long long valueToTest; unsigned int testWord; testWord = valueToTest 32; It *appears* to me (from somewhat circumstantial evidence in a much more complex big picture) when valueToTest has a value of 0x0034 then - If I compile Opt(0),NoInline then testWord gets the value I expect, 0x0034; but - If I compile Opt(2),Inline then testWord gets a value of 0. Questions: 1. Does that seem plausible? That the code would work as intended Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am guessing here) first cast valueToTest to an int of 0, then shift it right 32, and then assign it to testWord? 2. What should I code to avoid that? I guess I could shift valueToTest first (I don't need it again) and then in a separate statement assign it to testWord. Is that the proper coding technique? It's fairly involved to test the whole thing so I took the liberty of imposing on you folks rather than just trying stuff. Thanks much. Charles -- 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: Looking for help with an obscure C integer problem
BTW: I think I remember from an old book on C programming: if the target of an assignment is int, all operands on the right side are converted to int - if the target of an assignment is long, all operands on the right side are converted to long If I remember correctly, this would perfectly explain the behaviour you see (of course, it makes more sense for data types being shorter than the type of the assignment target, but if it's done as written above, you have it for longer types, too). Kind regards Bernd Am 21.07.2013 18:32, schrieb Bernd Oppolzer: Sorry for jumping late into this thread. Why not spend another variable of type long long to do the shift there? like unsigned long long valueToTest; unsigned int testWord; unsigned long long x; x = valueToTest 32; /* here */ testWord = (int) x; If now in the expression marked with /* here */ the compiler does not do the shift as a true 64 bit shift, there is no excuse and you should report this as a bug. The cast to int is done in the next statement. In the other case there may be some strange language rules that allow the long long variable to be casted to int before the shift - I don't know, but why lose time and think much about it? Kind regards Bernd Am 20.07.2013 22:24, schrieb Charles Mills: Cross-posted to IBM-MAIN and MVS-OE. I have the following code fragment in an inline function, compiled by the IBM XLC compiler as C++: unsigned long long valueToTest; unsigned int testWord; testWord = valueToTest 32; It *appears* to me (from somewhat circumstantial evidence in a much more complex big picture) when valueToTest has a value of 0x0034 then - If I compile Opt(0),NoInline then testWord gets the value I expect, 0x0034; but - If I compile Opt(2),Inline then testWord gets a value of 0. Questions: 1. Does that seem plausible? That the code would work as intended Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am guessing here) first cast valueToTest to an int of 0, then shift it right 32, and then assign it to testWord? 2. What should I code to avoid that? I guess I could shift valueToTest first (I don't need it again) and then in a separate statement assign it to testWord. Is that the proper coding technique? It's fairly involved to test the whole thing so I took the liberty of imposing on you folks rather than just trying stuff. Thanks much. Charles -- 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: Encryption of data written to disks FICON channels
Thank you all for the suggestions and comments. First I 'll try to explain the reasoning behind my request. 1. Encryption of 'Data In Rest' is a requirement by local PCI regulation 2. Encryption of 'Data In Rest' is just one step (in probably of many) of data protection required by this regulation 3. Field encryption by DB2 is good solution but it does not covers files or reports (sysouts) which require another solution 4. Disk encryption is probaly the best and simple solution for encryption of 'Data In Rest' , but (there always are some buts) If you do not have disks which are encryption enable you have to buy them, it might be expensive So we thought that in order to comply with the regulation requirements we'll use (if exist) some device which encrypt/decrypt the data going/coming from the disks. Anyway, thanks again, Arye Shemer. On 20 July 2013 13:46, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2013-07-20 09:12, Ron Hawkins pisze: Radoslaw, I agree with your question up to a point. Encryption of data at rest covers most of the disk related scenarios to do with data protection. It especially makes my favorite soapbox of erasing disks with multiple overwrites a redundant task. But it is not encryption of data in flight. Data on the channel, in cache, and transmitted from cache to cache by remote copy products is not encrypted by controllers that support encryption of data at rest. Well, I haven't considered encryption of the (FICON) network, simply assumed the server room is safe enough. For remote copy see below I don't have any problem with field, record or file level encryption, but there is a downside if you are doing remote copy over a network, as it encrypted data usually compresses very poorly. It's not a problem for everyone. 100% agreed. Arye, Decru used to provide encryption devices for SCSI on Fibre Channel, but I don't know if they ever extended that support to FICON. DWDM solutions provide encryption, despite of the protocol used (FICON, SCSI-FC, Eth). Of course at the second end of DWDM it is again decrypted. -- 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: Looking for help with an obscure C integer problem
Charles, Hi, here is my opinion (and this definitely falls under the category of obscure C): You are not considering the implications of sequence points in your C/C++. Sequence points should not be confused with operator precedence. Operator precedence is determinate, sequence points are not. I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is relevant here because there are sometimes subtle, and sometimes not so subtle, differences in how sequence points apply between various levels of C++. While C++11 (the most recent level of C/C++) seems to a have only tiny, mostly irrelevant and evolutionary changes from prior levels of C/C++; there are significant differences in how sequence points are defined and effect execution. Still, C++11 and the level of the C/C++ compiler that is compiling your program is only tangential to the situation you describe. Your code will execute with undefined behavior regardless of what compiler you use. But, knowing the level of the C/C++ compiler may be important if you wish to reconcile why it behaves one way sometimes and other ways other times (e.g. on a different z/OS). To me, your failure to consider the subtle impact of sequence points renders your code ambiguous and subject to undefined behavior. This manifests itself, for example, by executing differently when optimized. It is at the compiler's and optimizer's discretion to decide the order of execution for code that the C++ standard does not specifically define. This includes overlapping execution. I think the C/C++ compiler and optimizer are working exactly as specified by applicable ISO/IEC standards. The fault, dear Brutus, it not in our stars,But, in ourselves, that we are underlings Cassius in Shakespeare's Julius Caesar Harry Date: Sat, 20 Jul 2013 13:24:29 -0700 From: charl...@mcn.org Subject: Looking for help with an obscure C integer problem To: IBM-MAIN@LISTSERV.UA.EDU Cross-posted to IBM-MAIN and MVS-OE. I have the following code fragment in an inline function, compiled by the IBM XLC compiler as C++: unsigned long long valueToTest; unsigned int testWord; testWord = valueToTest 32; It *appears* to me (from somewhat circumstantial evidence in a much more complex big picture) when valueToTest has a value of 0x0034 then - If I compile Opt(0),NoInline then testWord gets the value I expect, 0x0034; but - If I compile Opt(2),Inline then testWord gets a value of 0. Questions: 1. Does that seem plausible? That the code would work as intended Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am guessing here) first cast valueToTest to an int of 0, then shift it right 32, and then assign it to testWord? 2. What should I code to avoid that? I guess I could shift valueToTest first (I don't need it again) and then in a separate statement assign it to testWord. Is that the proper coding technique? It's fairly involved to test the whole thing so I took the liberty of imposing on you folks rather than just trying stuff. Thanks much. Charles -- 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: Looking for help with an obscure C integer problem
You are 100% correct. You nailed it. Stroustrup p. 263: If both operands have arithmetic type, the right operand is converted to the type of the left preparatory to the assignment. That explains why it fails, but not why it works Opt(0). I am going to *guess* that Opt(0) it compiles as though I had coded testWord = static_castunsigned int(valueToTest 32) while with Opt(2) it compiles as though I had coded testWord = static_castunsigned int(valueToTest) 32; In your earlier post you suggested wasting another long long. Yes, that's an approach. Actually I am finished with valueToTest and can just do things in two steps without wasting a variable: valueToTest = 32; testWord = valueToTest; I am busy with other things perhaps until sometime this week but the first thing I am going to try is simply using parentheses to attempt to force the Opt(0) interpretation: testWord = (valueToTest 32); If that fails I will move on to more elaborate approaches. The two statement approach will either work or else it is a very clear bug and I will re-group. Will probably try the union approach at that point. Thanks! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Sunday, July 21, 2013 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem BTW: I think I remember from an old book on C programming: if the target of an assignment is int, all operands on the right side are converted to int - if the target of an assignment is long, all operands on the right side are converted to long If I remember correctly, this would perfectly explain the behaviour you see (of course, it makes more sense for data types being shorter than the type of the assignment target, but if it's done as written above, you have it for longer types, too). Kind regards Bernd Am 21.07.2013 18:32, schrieb Bernd Oppolzer: Sorry for jumping late into this thread. Why not spend another variable of type long long to do the shift there? like unsigned long long valueToTest; unsigned int testWord; unsigned long long x; x = valueToTest 32; /* here */ testWord = (int) x; -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
Right. There are two things here: 1. Resolving the immediate problem (and understanding exactly why it fails might be a good first step). 2. The quality of the code. You are right; it is poor code. I try to write pretty good code. I take no pride in avoiding the use of unnecessary parentheses. I confess, I (a.) failed to consider that testWord = valueToTest 32 would not reliably operate as intended; and (b.) I was completely satisfied when the function passed basic unit tests and though no more of it. Lesson learned, hopefully. Not certain exactly what the lesson is, but I will be more careful in the future. I have learned to be cautious about integer type conversions, but obviously not cautious enough. I guess the lesson is just like for sequences of logical operators: use parentheses to force what you expect. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Harry Wahl Sent: Sunday, July 21, 2013 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem Charles, Hi, here is my opinion (and this definitely falls under the category of obscure C): You are not considering the implications of sequence points in your C/C++. Sequence points should not be confused with operator precedence. Operator precedence is determinate, sequence points are not. I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is relevant here because there are sometimes subtle, and sometimes not so subtle, differences in how sequence points apply between various levels of C++. While C++11 (the most recent level of C/C++) seems to a have only tiny, mostly irrelevant and evolutionary changes from prior levels of C/C++; there are significant differences in how sequence points are defined and effect execution. Still, C++11 and the level of the C/C++ compiler that is compiling your program is only tangential to the situation you describe. Your code will execute with undefined behavior regardless of what compiler you use. But, knowing the level of the C/C++ compiler may be important if you wish to reconcile why it behaves one way sometimes and other ways other times (e.g. on a different z/OS). To me, your failure to consider the subtle impact of sequence points renders your code ambiguous and subject to undefined behavior. This manifests itself, for example, by executing differently when optimized. It is at the compiler's and optimizer's discretion to decide the order of execution for code that the C++ standard does not specifically define. This includes overlapping execution. I think the C/C++ compiler and optimizer are working exactly as specified by applicable ISO/IEC standards. The fault, dear Brutus, it not in our stars,But, in ourselves, that we are underlings Cassius in Shakespeare's Julius Caesar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
Harry Wahl wrote: begin extract It is at the compiler's and optimizer's discretion to decide the order of execution for code that the C++ standard does not specifically define. This includes overlapping execution. /end extract and this may be conceded. What is not in the compiler's and optimizer's discretion is to produce different final numerical or string results for different levels of optimization. Even notionally strange behavior, which violates naif notions of minimal surprise, may be entirely appropriate Inconsistent behavior as a function of optimization level is not. Viewed as a black box, the behavior of a a program must be deterministic in the sense that that a set I of inputs always produces the same set O of outputs. (If there are pseudo-random number generators or the like somewhere in the stew it may be necessary to specify O probabilistically, but nothing of that sort is involved here.) Moreover, 'sequence points' as I understand them do not differ from one compilation of an unaltered source program to another (although their treatment by different compilers may). Finally, the phrase This includes overlapping execution is a diversion here. The only sort of overlapping execution that this compiler and optimizer support, indirectly, is that realized by explicit execution-time multiprogramming. In a word, this phrase is not seriös here. 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: Default
Just to restate, so that I am sure that I understand. === You have data on z/OS which is textual in nature. I.e. no binary, all human readable text characters You want to transfer this data to Windows and translate it from EBCDIC to ASCII (well Windows-1250 code point really) You do _NOT_ want each logical record to end with a CRLF You want to use the normal Windows ftp server. You want to use the normal z/OS ftp client. === Have you tried: ASCII LOCSITE SBSENDEOL=NONE PUT SOME.DSN Remote.Windows.file.txt I'm not in a position to test it right now. On Sun, Jul 21, 2013 at 8:31 AM, Ron Wells ron.we...@slfs.com wrote: thanks---the crlf is in data...which is what I was questioning.defaulted in ftpparms.at least it is here... -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Complete Transparency for CA-SPOOL Print Jobs Needed
Greetings, Our client has CA-SPOOL with TCP/IP connected PCL printers. We need to know how to setup CA-SPOOL to transmit the ASCII PCL data our product, BPF, generates into JES exactly “as is”, “no translation, no insertion of characters”, to the PCL printers. These printers are connected TCP/IP. Both CICS and BATCH will put the complete printer ready PCL ASCII jobs into JES Queue for transmittal to printer by CA-SPOOL. One other thing. They may need to have other “regular” print going to the same printer. Maybe another NODE statement using a different class than the “transparency class” they would use to print our “printer ready” ASCII PCL with?? (wag) Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest 32. There are no side effects and the sequence point is at the end of the full expression. Can anybody enlighten me? Charles, is the code snippet you supplied the exact test cast that is resulting in undefined behaviour? I cannot recreate the problem and I've tried it on five different C++ compilers, including z/OS v1.13. On 22/07/2013 2:33 AM, Charles Mills wrote: Right. There are two things here: 1. Resolving the immediate problem (and understanding exactly why it fails might be a good first step). 2. The quality of the code. You are right; it is poor code. I try to write pretty good code. I take no pride in avoiding the use of unnecessary parentheses. I confess, I (a.) failed to consider that testWord = valueToTest 32 would not reliably operate as intended; and (b.) I was completely satisfied when the function passed basic unit tests and though no more of it. Lesson learned, hopefully. Not certain exactly what the lesson is, but I will be more careful in the future. I have learned to be cautious about integer type conversions, but obviously not cautious enough. I guess the lesson is just like for sequences of logical operators: use parentheses to force what you expect. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Harry Wahl Sent: Sunday, July 21, 2013 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem Charles, Hi, here is my opinion (and this definitely falls under the category of obscure C): You are not considering the implications of sequence points in your C/C++. Sequence points should not be confused with operator precedence. Operator precedence is determinate, sequence points are not. I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is relevant here because there are sometimes subtle, and sometimes not so subtle, differences in how sequence points apply between various levels of C++. While C++11 (the most recent level of C/C++) seems to a have only tiny, mostly irrelevant and evolutionary changes from prior levels of C/C++; there are significant differences in how sequence points are defined and effect execution. Still, C++11 and the level of the C/C++ compiler that is compiling your program is only tangential to the situation you describe. Your code will execute with undefined behavior regardless of what compiler you use. But, knowing the level of the C/C++ compiler may be important if you wish to reconcile why it behaves one way sometimes and other ways other times (e.g. on a different z/OS). To me, your failure to consider the subtle impact of sequence points renders your code ambiguous and subject to undefined behavior. This manifests itself, for example, by executing differently when optimized. It is at the compiler's and optimizer's discretion to decide the order of execution for code that the C++ standard does not specifically define. This includes overlapping execution. I think the C/C++ compiler and optimizer are working exactly as specified by applicable ISO/IEC standards. The fault, dear Brutus, it not in our stars,But, in ourselves, that we are underlings Cassius in Shakespeare's Julius Caesar -- 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: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.
// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()
static const unsigned long long lswMask =
0x;
// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage
if ( valueToTest == 0 ) return 0;
unsigned int testWord;
testWord = valueToTest lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
}
I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.
On 22/07/2013 2:33 AM, Charles Mills wrote:
Right. There are two things here:
1. Resolving the immediate problem (and understanding exactly why it
fails might be a good first step).
2. The quality of the code. You are right; it is poor code. I try to
write pretty good code. I take no pride in avoiding the use of
unnecessary parentheses. I confess, I (a.) failed to consider that
testWord = valueToTest 32 would not reliably operate as intended;
and (b.) I was completely satisfied when the function passed basic
unit tests and though no more of it. Lesson learned, hopefully. Not
certain exactly what the lesson is, but I will be more careful in the
future. I have learned to be cautious about integer type conversions,
but obviously not cautious enough. I guess the lesson is just like for
sequences of logical operators: use parentheses to force what you expect.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Harry Wahl
Sent: Sunday, July 21, 2013 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Charles,
Hi, here is my opinion (and this definitely falls under the category
of obscure C):
You are not considering the implications of sequence points in your
C/C++.
Sequence points should not be confused with operator precedence.
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is
relevant here because there are sometimes subtle, and sometimes not so
subtle, differences in how sequence points apply between various
levels of
C++.
While C++11 (the most recent level of C/C++) seems to a have only
tiny, mostly irrelevant and evolutionary changes from prior levels of
C/C++; there are significant differences in how sequence points are
defined and effect execution.
Still, C++11 and the level of the C/C++ compiler that is compiling
your program is only tangential to the situation you describe. Your
code will execute with undefined behavior regardless of what compiler
you use. But, knowing the level of the C/C++ compiler may be
important if you wish to reconcile why it behaves one way sometimes and
other ways other times (e.g.
on a different z/OS).
To me, your failure to consider the subtle impact of sequence points
renders your code ambiguous and subject to undefined behavior. This
manifests itself, for example, by executing differently
Re: Looking for help with an obscure C integer problem
Perhaps more to the point, here are my exact options, minus only some
comments:
TARG(LE,zOSV1R9)
# On 1/10/11 X Y wrote that Z was on z990s
ARCH(6)
# Force most enums to be integers for consistency
ENUMSIZ(INT)
# Test of several optimization options
AGGRCOPY HGPR LIBANSI
# Some new optimization -- suspect these if problem!
ROCONST
# TEST Seems to hose up the linker if CSECT also specified
# Uncomment to show macros -- *** V1R13 and above ***
# SHOWM LIST PPONLY
# Try suppressing the multi-character literal warning for Events
SUPP(CCN5802)
# NODLL may be necessary to make the program COBOL-loadable
NODLL
# XPL(OSCALL(U)) OBJECTMODEL(IBM)
# Set the following based on optimization desired
# 0 and NOINLINE TEST or 2 and INLINE NOTEST
# OPT(0) NOINLINE TEST GONUMBER
OPT(2) INLINE NOTEST NOGONUMBER COMPRESS
# Turn on the LIST option - pseudo-assembler listing
# LIST
# Experiment for - does not seem to hurt anything
DLL(CBA)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.
// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()
static const unsigned long long lswMask =
0x;
// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage
if ( valueToTest == 0 ) return 0;
unsigned int testWord;
testWord = valueToTest lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
}
I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
