Re: OCOPY fails to convert text
In 5223415504632809.wa.paulgboulderaim@listserv.ua.edu, on 03/03/2014 at 05:07 PM, Paul Gilmartin paulgboul...@aim.com said: But, is there a convenient alternative collective term designating those 8-bit character sets in which 'A' is 0x41; '0' is 0x30, etc.? Perhaps Shmuel can, in a more constructive mode, suggest one. Does ISO Latin include ISO8859-x No; there are ISO 8859-x code pages for non-Latin alphabets, e.g., Hebrew. Those include all of the letters needed for English, but are missing the accented letters needed for, e.g., French. -- 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: OCOPY fails to convert text
On 3 March 2014 20:54, Farley, Peter x23353 peter.far...@broadridge.com wrote: GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. More than a reasonable chance; since IBM-1047 and ISO-8859-1 encode *exactly* the same set of displayable and control characters (what IBM calls Character Set (CS) 697, and ISO calls (duh) Latin 1)), converting without loss is trivial. Windows, when it uses them at all, uses code pages that contain displayable characters in places where 1047 et al have control characters, so it is not in general possible to convert from e.g. Western Windows 1252 to IBM-1047 without loss. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On Tue, 4 Mar 2014 12:24:41 -0500, Tony Harminc wrote: On 3 March 2014 20:54, Farley, Peter x23353 wrote: GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. More than a reasonable chance; since IBM-1047 and ISO-8859-1 encode *exactly* the same set of displayable and control characters (what IBM calls Character Set (CS) 697, and ISO calls (duh) Latin 1)), converting without loss is trivial. Windows, when it uses them at all, uses code pages that contain displayable characters in places where 1047 et al have control characters, so it is not in general possible to convert from e.g. Western Windows 1252 to IBM-1047 without loss. Actually, it depends on your definition of loss. If both pages contain 256 code points, it may be posible to convert from one to the other, then back, and have the same thing you started with. The interim may not look the same, but that may not matter. I think I'll go with ASCII-based until Shmuel objects. And long thereafter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
In 2783130373802539.wa.paulgboulderaim@listserv.ua.edu, on 03/04/2014 at 12:21 PM, Paul Gilmartin paulgboul...@aim.com said: I think I'll go with ASCII-based until Shmuel objects. And long thereafter. That would be impossible. -- 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: OCOPY fails to convert text
In 60A88FF084694521B417F4096A824778@barryf93b83d71, on 03/01/2014 at 09:44 PM, retired mainframer retired-mainfra...@q.com said: Look at the meaning of the convert operand in UNIX System Services Command Reference. YES specifies conversion table BPXFX000 which, unless you have changed it, is an alias for BPXFX111 which converts between IBM-037 and IBM-1047, both of which are EBCDIC. You probably need to specify BPXFX311 which converts between IBM-1047 (EBCDIC)and ISO8859-1 (ASCII). ISO 8859-1[1] is Latin 1, not ASCII. [1] Does IBM have a z/OS code page for ISO 8859-15 yet? -- 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: OCOPY fails to convert text
Thank you for the tip.
However, I had to change the OCOPY statement to:
ocopy indd(filein) outdd(fileout) ,
text convert('sys1.linklib(BPXFX311)') pathopts(use) FROM1047
Without the FROM1047, no conversion.
Curiously, I OCOPYd a simple text file with the new format. OCOPY did not
convert. However, when I reverted to the old format, it converted.
As Alice said, 'Curiouser curiouser.'
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Shmuel Metz (Seymour J.) :: Sent: Sunday, March 02, 2014 3:31 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: OCOPY fails to convert text :: :: In 60A88FF084694521B417F4096A824778@barryf93b83d71, on 03/01/2014 ::at 09:44 PM, retired mainframer retired-mainfra...@q.com said: :: :: Look at the meaning of the convert operand in UNIX System Services :: Command Reference. YES specifies conversion table BPXFX000 which, :: unless you have changed it, is an alias for BPXFX111 which converts :: between IBM-037 and IBM-1047, both of which are EBCDIC. You probably :: need to specify BPXFX311 which converts between IBM-1047 (EBCDIC)and :: ISO8859-1 (ASCII). :: :: ISO 8859-1[1] is Latin 1, not ASCII. From the UNIX Systems Services Command Reference: BPXFX311. Specifies an ASCII-EBCDIC conversion table to convert between code pages ISO8859-1 and IBM-1047. It doesn't matter what the official title of ISO 8859-1 is. For getting OCOPY to perform the desired conversion, it only matters that IBM uses it to mean to ASCII. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On 2 March 2014 18:30, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: [1] Does IBM have a z/OS code page for ISO 8859-15 yet? IBM has produced only two code pages for Latin-9; one ASCIIish (923) and one EBCDIC (924). Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On Mon, 3 Mar 2014 14:32:43 -0800, retired mainframer wrote: :: :: ISO 8859-1[1] is Latin 1, not ASCII. From the UNIX Systems Services Command Reference: BPXFX311. Specifies an ASCII-EBCDIC conversion table to convert between code pages ISO8859-1 and IBM-1047. It doesn't matter what the official title of ISO 8859-1 is. For getting OCOPY to perform the desired conversion, it only matters that IBM uses it to mean to ASCII. Well, Shmuel, pedantically and characteristically, is insisting that ASCII means precisely a 7-bit character set (even as USS does not mean UNIX System Services). But, is there a convenient alternative collective term designating those 8-bit character sets in which 'A' is 0x41; '0' is 0x30, etc.? Perhaps Shmuel can, in a more constructive mode, suggest one. Does ISO Latin include ISO8859-x (and some Windows-peculiar character sets) and exclude IBM-1047? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. http://en.wikipedia.org/wiki/ISO/IEC_8859-1 http://en.wikipedia.org/wiki/EBCDIC_1047 HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, March 03, 2014 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OCOPY fails to convert text On Mon, 3 Mar 2014 14:32:43 -0800, retired mainframer wrote: :: :: ISO 8859-1[1] is Latin 1, not ASCII. From the UNIX Systems Services Command Reference: BPXFX311. Specifies an ASCII-EBCDIC conversion table to convert between code pages ISO8859-1 and IBM-1047. It doesn't matter what the official title of ISO 8859-1 is. For getting OCOPY to perform the desired conversion, it only matters that IBM uses it to mean to ASCII. Well, Shmuel, pedantically and characteristically, is insisting that ASCII means precisely a 7-bit character set (even as USS does not mean UNIX System Services). But, is there a convenient alternative collective term designating those 8-bit character sets in which 'A' is 0x41; '0' is 0x30, etc.? Perhaps Shmuel can, in a more constructive mode, suggest one. Does ISO Latin include ISO8859-x (and some Windows-peculiar character sets) and exclude IBM-1047? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OCOPY fails to convert text
I have a REXX EXEC that copies a MVS file to zFS file. The zFS file is used as
input to create a chart under Windows.
When the REXX EXEC runs, the file is copied without any text conversion. Here
are REXX statements:
infile = 'CP.EN.X20.TRNCOUNT.VB'
outfile = path || '/TRNCOUNT.CSV'
chmod_command = chmod || outfile 777
say outfile
say chmod_command
allocate ddname(fileout) pathopts(ordwr,ocreat) pathdisp(keep,keep) ,
path(' || outfile || ')
allocate ddname(filein) DA('CP.EN.X20.TRNCOUNT.VB') shr
ocopy indd(filein) outdd(fileout) text convert(yes) pathopts(use)
if rc ¬= 0
then say ocopy failed for CP.EN.X20.TRNCOUNT.VB ,
(RC= || rc || )
address syscall chmod_command
free ddname(fileout)
free ddname(filein)
And this is the results from the SYSTSPRT:
.50 *-* infile = 'CP.EN.X20.TRNCOUNT.VB'
. CP.EN.X20.TRNCOUNT.VB
.51 *-* outfile = path || '/TRNCOUNT.CSV'
. /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
.52 *-* chmod_command = chmod || outfile 777
. chmod /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
777
.53 *-* say outfile
. /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
./etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
.54 *-* say chmod_command
. chmod /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
777
.chmod /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV 777
.55 *-* allocate ddname(fileout) pathopts(ordwr,ocreat)
pathdisp(keep,keep) , path(' || outfile || ')
. allocate ddname(fileout) pathopts(ordwr,ocreat)
pathdisp(keep,keep) , path('/etc/u/dept976/Departmental/CICS
._Graphs/CSV/TRNCOUNT.CSV')
.57 *-* allocate ddname(filein) DA('CP.EN.X20.TRNCOUNT.VB') shr
. allocate ddname(filein) DA('CP.EN.X20.TRNCOUNT.VB') shr
.58 *-* ocopy indd(filein) outdd(fileout) text convert(yes) pathopts(use)
. ocopy indd(filein) outdd(fileout) text convert(yes)
pathopts(use)
.59 *-* if rc ¬= 0
. 0
.62 *-* address syscall chmod_command
. chmod /etc/u/dept976/Departmental/CICS_Graphs/CSV/TRNCOUNT.CSV
777
The resulant zFS file is a copy of the MVS file - no text conversion.
I don't know why this is happening. I have a more complex REXX EXEC that
transfers
approximatedly 120 files in the same manner. I have no problems with the second
REXX EXEC.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
Look at the meaning of the convert operand in UNIX System Services Command Reference. YES specifies conversion table BPXFX000 which, unless you have changed it, is an alias for BPXFX111 which converts between IBM-037 and IBM-1047, both of which are EBCDIC. You probably need to specify BPXFX311 which converts between IBM-1047 (EBCDIC)and ISO8859-1 (ASCII). :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Mark Yuhas :: Sent: Saturday, March 01, 2014 8:06 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: OCOPY fails to convert text :: :: I have a REXX EXEC that copies a MVS file to zFS file. The zFS file is :: used as input to create a chart under Windows. :: When the REXX EXEC runs, the file is copied without any text conversion. :: Here are REXX statements: snip :: ocopy indd(filein) outdd(fileout) text convert(yes) pathopts(use) snip :: The resulant zFS file is a copy of the MVS file - no text conversion. :: I don't know why this is happening. I have a more complex REXX EXEC :: that transfers :: approximatedly 120 files in the same manner. I have no problems with :: the second :: REXX EXEC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
