On Wed, 2 Sep 2015 07:38:11 -0500, John McKown wrote: >I am wondering if anyone else thinks that it might be useful for IBM to >make an enhancement to BSAM/QSAM support for the CCSID parameter in JCL. > >ref: >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/12.9 ><quote> > >Purpose > >You can request the access method to convert data between the coded >character set identifier (CCSID) specified on the JOB or EXEC statement and >the CCSID specified on the DD statement. Data conversion is supported on >access to ISO/ANSI Version 4 tapes using access methods BSAM or QSAM, but >not using EXCP. > ><quote/> >Why does this only support ASCII tapes? Would it be helpful to generalize >it to any data source read or written by BSAM/QSAM? > Of course, this is only of use for "pure text" data sets. But it might >address the recent thread on FTP'ing a VB data set, keeping the LLBB field >intact but translating the "data" portion to ASCII. > Yes, yes, yes. This is another instance of IBM's implementing a valuable facility but with unduly restrictive scope, perhaps at the wrong implementation layer. (Does the code reside in the tape driver? Even if so, why restrict it to ISO/ANSI tapes?)
Related: I can use SDSF to extract SYSOUT to UNIX files. I'd like to tag those files with CCSID for possible subsequent conversion to Unicode. How can I determine the effective CCSID for a SYSOUT. UCS and/or CHARS appear to carry similar information: how to render code points as viewable glyphs/graphemes. Is there a table, somewhere, that relates UCS or CHARS to CCSID? And a disappointment. If I have a file tagged CCSID=1047, FORMAT=NL, and I use pax to convert it to ASCII, the resultant files appear tagged CCSID=819, FORMAT=NL. But the NLs are converted to LFs, so the FORMAT should be LF. Submitted SR. Got WAD. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
