Re: EBCDIC Bad History (was: Json table characters)
On Fri, 10 Aug 2018 16:38:26 -0400, Thomas David Rivers wrote: >> >#pragma codepage presents its on set of problems. > >Consider, for instance, you move the source into a Git repository >on a remote (and ASCII) system. And, if you have a cross-compiler, >might consider compiling on that remote system. > >Now, your source claims to be in code-page 1047 - but it certainly isn't likely >to be so, since the move to the ASCII system rendered it in ASCII. > >This means your cross-compiler has to quietly ignore the #pragma codepage >and hope that your transmission to the ASCII system did "the right thing." > Does FTP or another transport vehicle by defaut set SBDATACONN to the tagged character set? This is a general problem with self-defining data[1]. If someone sends me email from an ASCII system with "Content-type: text/plain; charset=ISO8859-1", it arrives in my VM inbox obviously translated to a variant (there are several) of EBCDIC, with the MIME header still saying (however in EBCDIC) "ISO8859-1". Shouldn't it be converted to reflect the translation? If I "pax" an EBCDIC file tagged with separator=NL and request conversion to ASCII, pax correctly tags the file with the target charset, converts the NLs to LFs, but still leaves "separator=NL". SR. WAD. Converting self-defining data should adjust the metadata. >Trigraphs are hideously ugly; but they did produce portable source files >that could be moved around and compiled. > >As I mentioned in another post; C++17 removed support for Trigraphs >from their language definition so, they are generally going away... I hate EBCDIC! [1] "What's self-defining data?" "I dunno. Why don't you ask it!?" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EBCDIC Bad History (was: Json table characters)
David Crayford wrote: On 10/08/2018 7:34 PM, Peter Relson wrote: I have no idea why the health checker header files in SYS1.SIEAHDR.H(HZS*) chose to use them. Because no one was willing to take a stand that everyone has a system like yours that can handle the braces, at the expense of someone who did not. You make a good point Peter and I certainly don't mean any disrespect to the original authors of those header files. It's just IMO trigraphs are worse then using a codepage such as 1047 which is the ubiquitous C codepage on z/OS. Nevertheless, it seems unlikely that there will be additional use of the #pragma codepage presents its on set of problems. Consider, for instance, you move the source into a Git repository on a remote (and ASCII) system. And, if you have a cross-compiler, might consider compiling on that remote system. Now, your source claims to be in code-page 1047 - but it certainly isn't likely to be so, since the move to the ASCII system rendered it in ASCII. This means your cross-compiler has to quietly ignore the #pragma codepage and hope that your transmission to the ASCII system did "the right thing." Trigraphs are hideously ugly; but they did produce portable source files that could be moved around and compiled. As I mentioned in another post; C++17 removed support for Trigraphs from their language definition so, they are generally going away... - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EBCDIC Bad History (was: Json table characters)
On 10/08/2018 7:34 PM, Peter Relson wrote: I have no idea why the health checker header files in SYS1.SIEAHDR.H(HZS*) chose to use them. Because no one was willing to take a stand that everyone has a system like yours that can handle the braces, at the expense of someone who did not. You make a good point Peter and I certainly don't mean any disrespect to the original authors of those header files. It's just IMO trigraphs are worse then using a codepage such as 1047 which is the ubiquitous C codepage on z/OS. Nevertheless, it seems unlikely that there will be additional use of the trigraphs going forward. And possibly, if specifically asked, some existing files could be changed to remove them in the future. Peter Relson z/OS Core Technology Design -- 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: EBCDIC Bad History (was: Json table characters)
>I have no idea why the health checker header files in >SYS1.SIEAHDR.H(HZS*) chose to use them. Because no one was willing to take a stand that everyone has a system like yours that can handle the braces, at the expense of someone who did not. Nevertheless, it seems unlikely that there will be additional use of the trigraphs going forward. And possibly, if specifically asked, some existing files could be changed to remove them in the future. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
