Re: PDSE and HLASM together in z/OS 2.1
After a bit of (archaeological) digging, it appears our manuals are incorrect and that we've visited this issue before. When HLASM 1.4 development was in full flight, the CODEPAGE option was added. This appears to have fallen victim to the short-on-os-storage issue - and the coded 128k value was changed to a whopping 132K! - the books never caught up with this modification. I agree with Miklos, and we will look to change this value - Richard will be on the case when he returns from SHARE. Sharuff smo...@uk.ibm.com btw - anyone going to SHARE ? If so, go say hello to Richard Cebula - its his first SHARE conference! >From:Miklos Szigetvari >Subject: Re: PDSE and HLASM together in z/OS 2.1 > > Hi > >Thank you Sharuff. >We have closed the PMR76555.010.618, as with REGION=1000M it worked, >I think it would be not bad if the SIZE default would be a little less. > > >On 27.02.2014 13:38, Sharuff Morsa3 wrote: > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: PDSE and HLASM together in z/OS 2.1
Thank you very much On 28.02.2014 12:26, Sharuff Morsa3 wrote: After a bit of (archaeological) digging, it appears our manuals are incorrect and that we've visited this issue before. When HLASM 1.4 development was in full flight, the CODEPAGE option was added. This appears to have fallen victim to the short-on-os-storage issue - and the coded 128k value was changed to a whopping 132K! - the books never caught up with this modification. I agree with Miklos, and we will look to change this value - Richard will be on the case when he returns from SHARE. Sharuff smo...@uk.ibm.com btw - anyone going to SHARE ? If so, go say hello to Richard Cebula - its his first SHARE conference! From:Miklos Szigetvari Subject: Re: PDSE and HLASM together in z/OS 2.1 Hi Thank you Sharuff. We have closed the PMR76555.010.618, as with REGION=1000M it worked, I think it would be not bad if the SIZE default would be a little less. On 27.02.2014 13:38, Sharuff Morsa3 wrote: Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. ---
CamelCase (was: ASSEMBLER-LIST Digest ...)
On 2014-02-25, at 10:00, John Walker wrote: > So, to respond to the one comment, it was ok for the Science guys to want > mixed case things because that was what they were used to. Ok, I can buy > that. Same rationale can be applied to the C programmers. Now, let's be > fair, using the very same reasoning, I can then justify MY perception that > mixed case shouldn't be used on the mainframe, because I am used to it. Now, > if you say they can justify their actions out of their preferrences and I can > NOT do the same thing, then you surely can see how that is not fair for > everyone, right? > Let's see. The monocase enthusiasts have JCL as they like it. The mixed case enthuiasts have C as they like it. All within the z/OS environment. Something for everyone. Sounds like a compromise; everyone should be happy. You sound bitter; intolerant. Would you stop the "science guys" at the border because they speak a different language? Why did you write your messave in mixed case? It's probably OK as long as you didn't compose it on a mainframe. -- gil
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
I think this discussion needs to distinguish clearly between case-sensitive (treating caps and lower case the same) and case-insensitive (treating the upper and lower case of the same character as different). "Mixed-case" could mean either, and is therefore unclear. IMHO, case-insensitivity is not human-friendly. I can't think of any reason to use it, but no doubt someone has, On Fri, Feb 28, 2014 at 9:52 AM, Paul Gilmartin wrote: > On 2014-02-25, at 10:00, John Walker wrote: > > > So, to respond to the one comment, it was ok for the Science guys to > want mixed case things because that was what they were used to. Ok, I can > buy that. Same rationale can be applied to the C programmers. Now, let's > be fair, using the very same reasoning, I can then justify MY perception > that mixed case shouldn't be used on the mainframe, because I am used to > it. Now, if you say they can justify their actions out of their > preferrences and I can NOT do the same thing, then you surely can see how > that is not fair for everyone, right? > > > Let's see. The monocase enthusiasts have JCL as they like it. > The mixed case enthuiasts have C as they like it. All within > the z/OS environment. Something for everyone. Sounds like a > compromise; everyone should be happy. > > You sound bitter; intolerant. Would you stop the "science guys" > at the border because they speak a different language? > > Why did you write your messave in mixed case? It's probably OK > as long as you didn't compose it on a mainframe. > > -- gil > -- OREXXMan
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
IBM Mainframe Assembler List wrote on 02/28/2014 11:18:33 AM: > From: Hobart Spitz > I think this discussion needs to distinguish clearly between case-sensitive > (treating caps and lower case the same) and case-insensitive (treating the > upper and lower case of the same character as different). "Mixed-case" > could mean either, and is therefore unclear. > > IMHO, case-insensitivity is not human-friendly. I can't think of any > reason to use it, but no doubt someone has, In human language based communication with other humans, case-sensitivity is meaningful and helpful. In any communication with automatons (except data entry), case-insensitivity is more human-friendly and can be easily tolerated by the machine(s). Making STUFF stuff Stuff sTuff ... have different meanings is not as fault-tolerant as it could be. ... Efforts and courage are not enough without purpose and direction. - John F. Kennedy Fasten your seat belts, it's going to be a bumpy ride. - Bette Davis (as character Margo Channing) _All About Eve_1950 Our greatest danger in life is in permitting the urgent things to crowd out the important. - Charles E. Hummel Quidquid latine dictum sit, altum viditur. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
I should be be on John Walker's side if 'z/OS' were telling him that he may no longer write his routines in headlines. As it is, what he appears to be saying is that I must write mine in headlines too; and I am unsympathetic, even hostile to that notion. He is and should be free to continue what he has always done, but not to impose his views upon others. There is, however, a larger issue here. Traditional all-majuscules source programs have two essential characteristics: They reflect now irrelevant, circa-1956 hardware technology; and they have a strong, all the stronger for being implicit and unexamined, anglophone bias. Consider the lines from José Camargo Caïn a été humilié par Dieu, et il tue son frère parce qu'il est dans l'incapacité de tuer Dieu. Rendered in majuscules without disacritical marks as CAIN A ETE HUMILIE PAR DIEU, ET IL TUE SON FRERE PARCE QU'IL EST DANS L'INCAPACITE DE TUER DIEU. it is, for a francophone, defaced. I look forward to the time when we shall be able to write source programs in mixed-case Unicode. Bertrand Russell once observed that if professional football (soccer) players came to be oppressed, he would of course come to their defense, diligently if not with great zeal. My view of Mr. Walker's problem is much the same. John Gilmore, Ashland, MA 01721 - USA
Re: CamelCase
English (and other Latin-alphabet languages) is mostly case-INsensitive. There's sometimes a difference between Bill and bill, but bILL, BILL, bIlL are just silly versions of the same word. There are some conventions in some c-based languages of using a symbol with a leading Capital letter, and a different, but related symbol spelled the same except for a leading lower-case letter. Beyond that, I doubt there's much sense in case-sensitivity outside of obfuscated code contests. Best practices in c-type coding have fairly strict spelling rules to avoid the madness. HLASM has it right. sas On 2/28/2014 11:28, Kirk Talman wrote: In human language based communication with other humans, case-sensitivity is meaningful and helpful. In any communication with automatons (except data entry), case-insensitivity is more human-friendly and can be easily tolerated by the machine(s).
Automatic reply: CamelCase
I'm currently out of the office with no access to email. I'll reply to your note as soon as I return. Have a great day, Steve
Automatic reply: CamelCase
I will be out of the office, returning Monday March 10th. I will respond to your email ASAP once I am back. In the meantime if you require an urgent response, please contact our Customer Support Centre on 212-855-1541. _ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Re: CamelCase
From: "Steve Smith" Sent: Saturday, March 01, 2014 9:56 AM English (and other Latin-alphabet languages) is mostly case-INsensitive. There's sometimes a difference between Bill and bill, but bILL, BILL, bIlL are just silly versions of the same word. But iTunes isn't?
Re: ASSEMBLER-LIST Digest - 27 Feb 2014 to 28 Feb 2014 (#2014-36)
When I said, ' So, to respond to the one comment, it was ok for the Science guys to > want mixed case things because that was what they were used to. Ok, I can > buy that. Same rationale can be applied to the C programmers. Now, let's > be fair, using the very same reasoning, I can then justify MY perception > that mixed case shouldn't be used on the mainframe, because I am used to > it. Now, if you say they can justify their actions out of their > preferrences and I can NOT do the same thing, then you surely can see how > that is not fair for everyone, right?', somebody said that was bitter? Umm, > no, however if you felt that way, my apologies. Still, the point is valid. > It IS inconsistent, and thus not fair. On Fri, 2/28/14, Automatic digest processor wrote: Subject: ASSEMBLER-LIST Digest - 27 Feb 2014 to 28 Feb 2014 (#2014-36) To: "Recipients of ASSEMBLER-LIST digests" Date: Friday, February 28, 2014, 11:01 PM ASSEMBLER-LIST Digest - 27 Feb 2014 to 28 Feb 2014 (#2014-36) LISTSERV at the University of Georgia ASSEMBLER-LIST Digest - 27 Feb 2014 to 28 Feb 2014 (#2014-36) Table of contents: PDSE and HLASM together in z/OS 2.1 (2) CamelCase (was: ASSEMBLER-LIST Digest ...) (4) CamelCase (2) Automatic reply: CamelCase (2) PDSE and HLASM together in z/OS 2.1 Re: PDSE and HLASM together in z/OS 2.1 (02/28) From: Sharuff Morsa3 Re: PDSE and HLASM together in z/OS 2.1 (02/28) From: Miklos Szigetvari CamelCase (was: ASSEMBLER-LIST Digest ...) CamelCase (was: ASSEMBLER-LIST Digest ...) (02/28) From: Paul Gilmartin Re: CamelCase (was: ASSEMBLER-LIST Digest ...) (02/28) From: Hobart Spitz Re: CamelCase (was: ASSEMBLER-LIST Digest ...) (02/28) From: Kirk Talman Re: CamelCase (was: ASSEMBLER-LIST Digest ...) (02/28) From: John Gilmore CamelCase Re: CamelCase (02/28) From: Steve Smith Re: CamelCase (03/01) From: robin Automatic reply: CamelCase Automatic reply: CamelCase (02/28) From: Steve Hazzard Automatic reply: CamelCase (02/28) From: "Ward Able, Grant" Browse the ASSEMBLER-LIST online archives.
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
At 11:18 -0500 on 02/28/2014, Hobart Spitz wrote about Re: CamelCase (was: ASSEMBLER-LIST Digest ...): I think this discussion needs to distinguish clearly between case-sensitive (treating caps and lower case the same) and case-insensitive (treating the upper and lower case of the same character as different). You have your definitions backwards. If I am case-sensitive I care about the case and thus see "A" as different from "a". If I am case-insensitive I do see "A" and "a" as the same character (and thus the same string of characters is the same no matter what CamelCase glyphs are used).
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
At 11:28 -0500 on 02/28/2014, Kirk Talman wrote about Re: CamelCase (was: ASSEMBLER-LIST Digest ...): Making STUFF stuff Stuff sTuff ... have different meanings is not as fault-tolerant as it could be. OTOH: Polish and polish ARE not the same. Telling someone in the army to "You should Polish your shoes so you will pass inspection" or claiming "I am a polish citizen" are both bad uses of the string p-o-l-i-s-h since the wrong case of the letter "P/p" makes the meaning of that string in the statements incorrect.
