On Sun, 18 Feb 2018 19:07:17 +0000, J R wrote: >If the spec you are working to says nothing about the inbound data other than >"ASCII", you should be able to assume (yes, I know) that the data contains >nothing more than the basic characters 'A' to 'Z', 'a' to 'z' and '0' to '9'. >No punctuation, no characters with diacritical marks, no binary fields, etc. >If this does not describe your data, your spec is incomplete. > I believe "ASCII" can properly be used to refer to the first 128 characters in CCSID 819. including special characters. Informally, many use "ASCII" to refer to CCSID 819 or other ISO-LATIN code pages.
If it has euro, it's probably ISO-LATIN (but which?), not ASCII. It might even be the popular UTF-8 (CP 1208), of which the first 128 code points are the same as ASCII. >Other than ASCII, what else do you know about the inbound data? > >Side note 1: I notice you always mention that your program runs as an STC. >This is most likely irrelevant. > >Side note 2: I notice that you code in COBOL. If the fact that your program >runs as an STC is relevant, I would recommend coding in HLASM in which control >block management is more straightforward. > Control blocks for socket or control blocks for iconv? >> On Feb 18, 2018, at212:50, scott Ford wrote: >> >> We read ASCII data via a EZASOKET READ call. The data is encrypted , so we >> decrypt it and then >> convert to EBCDIC. I looked at FTP data and there is a SBDATACON >> parameter..giving both EBCDIC and ASCII ccsids or codepages. >> Just curious: which? Why not transfer in binary, making SBDATACON irrelevant? The less munging the better. >> I dont know what the inbound ASCII data stream codepage is ...after a >> encrypt/Decrypt using AES128 or AES256. >> IOW, do you not know that the source codepage in SBDATACON correctly describes the original data? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
