On 1 February 2012 15:50, Kirk Wolf <k...@dovetail.com> wrote: > OK, so I found a sneaky way of adding a new conversion table to Unicode > Services to match TCPIP.STANDARD.TCPXLBIN. Thanks again to Mark and John > for getting me started.. > > 1) Unless you want to modify SYS1.SCUNTBL, create a new PDS: HLQ.SCUNTBL > with RECFM=F,LRECL=256,BLKSIZE=256
(Remember the unfortunate would-be AOL users from Scunthorpe in the UK, years ago? We surely won't have that problem on IBM-MAIN in 2012... http://en.wikipedia.org/wiki/Scunthorpe_problem ) > 2) I wanted to create a new conversion from IBM-850 <-> IBM-037. Looking > these up in the manual, their two-character codes are EB (850) and AA (037). > For my new conversion, I'll use the conversion technique code "2". An interesting pair of codepages. You might find recent APAR OA37099 and its PTFs UA62130/UA62131, followed by OA38383 and UA63909/UA63910 of some interest. The first APAR *removes entirely* several hundred translations of technique "L" from Unicode services, and the second puts them back as technique "M" tables. The APAR texts are less then enlightening, and there is no PE on the first, nor are they marked as connected in any obvious way. The PTFs for the first were shipped as routine maintenance, and broke character conversion for applications using the iconv() service with codepage pairs like yours. Several of our customers had "Monday morning" problems when they promoted these PTFs into production, and the iconv() results suddently changed. Well, the second "fix" seems to put things back about they way they were, but there's no hint about what the whole exercise was for. This is the old issue of line ending conversion: does NL go to LF or to NEL, and so on. Reasonable people can agree to disagree on this, but I'm not sure it's reasonable that the customer's Unicode services configuration, let alone IBM maintenance should change the result of a conversion that has been working the same way for 10+ years. But I'm sounding grumpy, I'm sure... Your example of the same codepage pair we are using, plus a conversion technique in the user range (the "2") reminds me that I'm a little nervous about the whole topic. > If you look at TCPIP.STANDARD.TCPXLBIN, you will see that it has three > records - > 1) a comment > 2) the 256-byte ASCII->EBCDIC table > 3) the 256-byte EBCDIC->ASCII table > > a) create a new member CUN2EBAA (850->037, TECH=2) > > copy the first non-comment record from TCPIP.STANDARD.TCPXLBIN into this > member > > b) create another new member CUN2AAEB (037->850, TECH=2) > > copy the second non-comment record from TCPIP.STANDARD.TCPXLBIN into > this member > > 3) To activate your new conversion tables: > > setuni add,from(037),to(850),TECH(2),DSN(HLQ.SCUNTBL) > setuni add,from(850),to(037),TECH(2),DSN(HLQ.SCUNTBL) > > (You would also want to update PARMLIB(CUNUNIxx) to include these add > statements) How are you expecting a user conversion technique to fit into your or a customer's environment? In other words, how will the fact that you want a different conversion for these codepage pairs to be used be communicated to the program? Will it explicitly request a technique 2 conversion, or is it expected that things will fall through to technique 2 because of the system configuration? Are you using iconv() or calling the Unicode services directly? > 4) verify with iconv that it works. We have a simple utility in Co:Z that > will display single byte translate tables: > >> *showtrtab -s IBM-850 -t IBM-037 -q 2* What does that call internally? Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
