HLASM code page support enhancements

2023-02-09 Thread Jonathan Scott
We have just shipped APAR PH50915, an enhancement to code page support, which makes it possible to identify the source code page and specify the object code pages to be used for EBCDIC, ASCII and Unicode constants (now including UTF-8): https://www.ibm.com/support/pages/apar/PH50915 Additional

Re: HLASM code page support enhancements

2023-02-09 Thread Paul Gilmartin
On 2/9/23 05:56:28, Jonathan Scott wrote: We have just shipped APAR PH50915, an enhancement to code page support, ... https://www.ibm.com/support/pages/apar/PH50915 Thanks. Will this, by clarification, relax restrictions on the use of ASCII self-defining terms, such as: MVI L,

Re: HLASM code page support enhancements

2023-02-09 Thread Jonathan Scott
gil writes: > Thanks. Will this, by clarification, relax restrictions on the use > of ASCII self-defining terms, such as: > > MVI L,CA'x' ASCII and Unicode self-defining terms have been supported in assembly expressions since PI89365 in 2017. With the latest fix PH50915 they are also

Re: HLASM code page support enhancements

2023-02-10 Thread Paul Gilmartin
On 2/9/23 08:06:41, Jonathan Scott wrote: gil writes: Thanks. Will this, by clarification, relax restrictions on the use of ASCII self-defining terms, such as: MVI L,CA'x' ASCII and Unicode self-defining terms have been supported in assembly expressions since PI89365 in 2017. W

Re: HLASM code page support enhancements

2023-02-13 Thread Jonathan Scott
Any reference to an ASCII or Unicode term where the value contains characters outside the invariant EBCDIC character set will clearly have a value which depends on the EBCDIC code page in which the source was written. This means that it is not possible to determine the binary value of such a const

Re: HLASM code page support enhancements

2023-02-13 Thread Paul Gilmartin
On 2/13/23 02:51:52, Jonathan Scott wrote: Any reference to an ASCII or Unicode term where the value contains characters outside the invariant EBCDIC character set will clearly have a value which depends on the EBCDIC code page in which the source was written. This means that it is not possible

Re: HLASM code page support enhancements

2023-02-13 Thread Jonathan Scott
Ref: Your note of Mon, 13 Feb 2023 09:23:37 -0700 gil writes: > Wouldn't that limitation have applied to EBCDIC terms contains characters > outside the invariant EBCDIC character set? such as: > CLI L,C'['or: > DCC'[' > where it is not possible to determine the binar

Re: HLASM code page support enhancements

2023-02-13 Thread Charles Mills
. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jonathan Scott Sent: Monday, February 13, 2023 8:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements Ref: Your note of Mon, 13 Feb 202

Re: HLASM code page support enhancements

2023-02-13 Thread Ed Jaffe
On 2/13/2023 9:27 AM, Charles Mills wrote: Any reliance on the visible glyph as an unambiguous indication of the underlying bit pattern is going to be fraught. I know for absolute fact that my 3270 emulators and ISPF are properly synchronized to correctly process and display characters using t

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
The real question is why, but really why, IBM had to introduce this EBCDIC horror, where symbols like [,], ^ and some less signifacant ones moved around like dry leaves in the fall wind.  Why didn't IBM jist left them in one place.I did never find any explanation, let alone logical explanation. 

Re: HLASM code page support enhancements

2023-02-13 Thread Seymour J Metz
r List on behalf of Ze'ev Atlas <01774d97d104-dmarc-requ...@listserv.uga.edu> Sent: Monday, February 13, 2023 1:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements The real question is why, but really why, IBM had to introduce this EBCDIC horro

Re: HLASM code page support enhancements

2023-02-13 Thread Paul Gilmartin
On 2/13/23 11:29:23, Seymour J Metz wrote: It's awful in the mainframe world, but it's also awful in the PC world. Multiple code pages matching ASCII or ISCII in 0-127 and chaotic everywhere else. Maybe z/OS should move to UTF-8 as the standard code page. +1 for UTF-8. I have two desktop sy

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
DU Subject: Re: HLASM code page support enhancements The real question is why, but really why, IBM had to introduce this EBCDIC horror, where symbols like [,], ^ and some less signifacant ones moved around like dry leaves in the fall wind.  Why didn't IBM jist left them in one place.I did

Re: HLASM code page support enhancements

2023-02-13 Thread Jonathan Scott
Ze'ev Atlas wrote: > The real question is why, but really why, IBM had to introduce > this EBCDIC horror, where symbols like [,], ^ and some less > signifacant ones moved around dry leaves in the fall wind. That's a bit off-topic, but the answer is "Compatibility". Old physical printers and termi

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
The switching of those three characters, used widely in regex, is not only confusing, it is a disaster.ZA Sent from Yahoo Mail on Android On Mon, Feb 13, 2023 at 2:30 PM, Jonathan Scott wrote: Ze'ev Atlas wrote: > The real question is why, but really why, IBM had to introduce > this EBCDI

Re: HLASM code page support enhancements

2023-02-13 Thread Seymour J Metz
C was not the first language to use []. From: IBM Mainframe Assembler List on behalf of Jonathan Scott Sent: Monday, February 13, 2023 1:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements Ze'ev Atlas

Re: HLASM code page support enhancements

2023-02-13 Thread Paul Gilmartin
On Feb 13, 2023, at 12:55:45, Seymour J Metz wrote: C was not the first language to use []. Algol-60?  IBM was enthusiastic about Algol early in the s/360 era. -- gil

Re: HLASM code page support enhancements

2023-02-13 Thread Phil Smith III
ASCII-EBCDIC is on my Time Machine list (you know, "Kill Hitler; avoid the ASCII-EBCDIC dichotomy; no null-terminated strings in C." - you'll have your own items). Note that UTF-8 is not a code page; it's an encoding for all of Unicode. To convert z/OS to use Unicode at this point would requir

Re: HLASM code page support enhancements

2023-02-13 Thread Paul Gilmartin
On 2/13/23 13:10:42, Phil Smith III wrote: Just be glad that the basic character set is fixed in EBCDIC code pages. Imagine if A-Z moved around! That might be good. It would motivate the designers to fix the damned problem. Or adopt the solution in widespread use. -- gil

Re: HLASM code page support enhancements

2023-02-13 Thread Tony Harminc
On Mon, 13 Feb 2023 at 14:30, Jonathan Scott wrote: > Ze'ev Atlas wrote: > > The real question is why, but really why, IBM had to introduce > > this EBCDIC horror, where symbols like [,], ^ and some less > > signifacant ones moved around dry leaves in the fall wind. > > > That's a bit off-topi

Re: HLASM code page support enhancements

2023-02-13 Thread Tony Harminc
On Mon, 13 Feb 2023 at 13:10, Ze'ev Atlas < 01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > The real question is why, but really why, IBM had to introduce this EBCDIC > horror, where symbols like [,], ^ and some less signifacant ones moved > around like dry leaves in the fall wind. Why

Re: HLASM code page support enhancements

2023-02-13 Thread dave . g4ugm
> -Original Message- > From: IBM Mainframe Assembler List > On Behalf Of Ze'ev Atlas > Sent: 13 February 2023 18:10 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: HLASM code page support enhancements > > The real question is why, but really why, IBM

Re: HLASM code page support enhancements

2023-02-13 Thread Phil Smith III
> I believe that the real answer is that IBM didn't introduce these characters, "users", I think mainly universities found they needed them and so tweaked their systems so they could be used. Yes! Remember the various print trains: http://www.quadibloc.com/comp/lineint.htm

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
Where can I find that publication? Ze'ev Atlas On Monday, February 13, 2023 at 04:09:47 PM EST, Tony Harminc wrote: On Mon, 13 Feb 2023 at 13:10, Ze'ev Atlas < 01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > The real question is why, but really why, IBM had to introduce th

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
Can I quote you in my documentation, please Ze'ev Atlas On Monday, February 13, 2023 at 02:30:57 PM EST, Jonathan Scott wrote: Ze'ev Atlas wrote: > The real question is why, but really why, IBM had to introduce > this EBCDIC horror, where symbols like [,], ^ and some less > signifaca

Re: HLASM code page support enhancements

2023-02-13 Thread Paul Gilmartin
On 2/13/23 11:35:23, Jonathan Scott wrote: Ze'ev Atlas wrote: The real question is why, but really why, IBM had to introduce this EBCDIC horror, where symbols like [,], ^ and some less signifacant ones moved around dry leaves in the fall wind. That's a bit off-topic, but the answer is "Compat

Re: HLASM code page support enhancements

2023-02-13 Thread Ze'ev Atlas
GilYou are correct of course.  When I ported PCRE to Classic z/OS I had in mind the poor souls who are forced to work in Classic z/OS, JCL, Rexx. TSO, EBCDIC and all.  But yes, I wish that IBM would find a fool proof way to bring those poor souls and their arcane systems to the twenty first cent

Re: HLASM code page support enhancements

2023-02-13 Thread Phil Smith III
Gil wrote, re the "basic" characters moving around in EBCDIC code pages: >That might be good. It would motivate the designers to fix the damned >problem. Or adopt the solution in widespread use. It might have motivated them to switch to ASCII in 1975 or so (random year, don't pick at me for it!)

Re: HLASM code page support enhancements

2023-02-14 Thread Seymour J Metz
I [li...@akphs.com] Sent: Tuesday, February 14, 2023 12:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements Gil wrote, re the "basic" characters moving around in EBCDIC code pages: >That might be good. It would motivate the designers to fix the damned &

Re: HLASM code page support enhancements

2023-02-14 Thread Seymour J Metz
, February 13, 2023 11:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM code page support enhancements On 2/13/23 11:35:23, Jonathan Scott wrote: > Ze'ev Atlas wrote: >> The real question is why, but really why, IBM had to introduce >> this EBCDIC horror, where symbols

Re: HLASM code page support enhancements

2023-02-14 Thread Ze'ev Atlas
Can I quote your answer verbstim in my documentation Ze'ev Atlas On Monday, February 13, 2023 at 02:30:57 PM EST, Jonathan Scott wrote: Ze'ev Atlas wrote: > The real question is why, but really why, IBM had to introduce > this EBCDIC horror, where symbols like [,], ^ and some less >

Re: HLASM code page support enhancements

2023-02-14 Thread Tony Harminc
On Mon, 13 Feb 2023 at 21:41, Ze'ev Atlas < 01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > Where can I find that publication? > Ze'ev Atlas > Good question. I scanned my paper copy some time last year, I think, and I'm pretty certain I uploaded it to Bitsavers. But I don't see it there