Be careful what you ask for; you might get it. Unless you tell the access
method how to translate, it likely to trip up the application. Even if you have
both to and from CCSID on the DD statement, there are potential pitfalls. I'd
much rather leave the application in control. Something like DCBE and
processing options to specify
Translate/raw
Application CCID
Query file CCSID
Others I've overlooked
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
John McKown <[email protected]>
Sent: Tuesday, August 21, 2018 12:26 PM
To: [email protected]
Subject: Re: Funny characters in CPAC.PARMLIB(HZSPRM00)
On Tue, Aug 21, 2018 at 10:40 AM Phil Smith III <[email protected]> wrote:
> John McKown wrote:
>
> >What I, personally, think would be nice is something which exists,
> >somewhat, in z/OS UNIX files. That is "file tagging". In z/OS UNIX you can
> >"tag" a file's contents to specify that the text in the file is in a
> >particular CCSID (code page). What might be nice would be if every piece
> of
> >data could, optionally, be "tagged" as having a CCSID for the data inside
> >it. Of course, this only works when all the data inside is "textual" and
> >not "binary". Anyway, tag the data as being in a particular CCSID. Then
> >have a parameter on the DD statement which basically indicates the CCSID
> >that the program expects its data to be in. If the data doesn't have a
> >"tag", assume CP-037 for historical purposes. If the DD doesn't specify a
> >CCSID, assume CP-037 too. So in the default case, the CCSIDs would both be
> >CP-037 so no translation would be made. I am assuming that the access
> >method would do the translation, using Unicode System Services, and would
> >not do a conversion if the CCSIDs were identical. If the CCSIDs don't
> >match, then the access method would use the Unicode services to do the
> >translation on input & output. I am assuming that all members of a PD
> S
>
> >would be in the same CCSID. I guess this could be extended for individual
> >members in a PDSE version "2.1" or something. The tagging would be
> >automatic if a file is created using JCL or DYNALLOC by using the CCSID
> >specified in the DD or DYNALLOC. Again, defaulting to CP-037 for historic
> >purposes.
>
> >I'm not saying how this "tagging" would be implemented. I don't know if
> >there is any room in the VTOC entry for a CCSID. Or if it would require
> >something in the VVDS. And the problem remains for "mixed" data where the
> >records contain both "binary" and "textual" information.
>
> That's an intriguing thought. Of course adding metadata like that to z/OS
> data sets creates a whole new mess, with "Oh, that application/whatever
> doesn't handle the tagging", but once we got there, it sure would make life
> simpler!
>
That's why I want the access method to implement the CCSID conversion,
along with "tagging" and a DD parameter so that the application receives
the data in the code point it is written to handle. I don't want the
application to have to deal with "metadata", but put it on the back of the
access method; most likely QSAM and BSAM and maybe even VSAM. Much like DB2
can do some of this.
--
Between infinite and short there is a big difference. -- G.H. Gonnet
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
