Something like this? HEX2CHAR DC 256(C'0123456789ABCDEF'((*-HEX2CHAR)/32+1,1),C'0123456789ABCDEF'(*-HEX2CHAR-(*-H EX2CHAR-1)/32*32,1))
I haven't tested it. Gunnar ----- Original Message ----- From: "Lennie J Dymoke-Bradshaw" <[email protected]> To: <[email protected]> Sent: Monday, August 13, 2012 3:20 PM Subject: Re: Printing a return code > Keven, > > That would generate a 256 byte table in Hex. > For the TROT translation we need a 512 byte table in char. > > Lennie Dymoke-Bradshaw MBCS CITP > Accredited Senior I/T Specialist, System z, Security and Cryptography, IBM > Software Group > Mail: Lennie J Dymoke-Bradshaw/UK/IBM@IBMGB or > [email protected] > > > > > From: "Hall, Keven" <[email protected]> > To: [email protected] > Date: 11/08/2012 00:31 > Subject: Re: Printing a return code > Sent by: IBM Mainframe Assembler List > <[email protected]> > > > > Or like so: > > HEX2CHAR DC 256AL1(*-HEX2CHAR) > > Keven > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:[email protected] > ] On Behalf Of Steve Smith > Sent: Thursday, August 09, 2012 11:48 AM > To: [email protected] > Subject: Re: Printing a return code > > Using TROT is a great idea, but why not code the table like so: > > HEX2CHAR DC C'000102030405060708090A0B0C0D0E0F' > DC C'101112131415161718191A1B1C1D1E1F' > DC C'202122232425262728292A2B2C2D2E2F' > DC C'303132333435363738393A3B3C3D3E3F' > DC C'404142434445464748494A4B4C4D4E4F' > DC C'505152535455565758595A5B5C5D5E5F' > DC C'606162636465666768696A6B6C6D6E6F' > DC C'707172737475767778797A7B7C7D7E7F' > DC C'808182838485868788898A8B8C8D8E8F' > DC C'909192939495969798999A9B9C9D9E9F' > DC C'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF' > DC C'B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF' > DC C'C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF' > DC C'D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF' > DC C'E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF' > DC C'F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF' > > sas > > On Wed, Aug 8, 2012 at 9:24 AM, Rob Scott <[email protected]> > wrote: > > > > I use the "TROT" instruction with the following 512 byte translate table > : > > > > DS 0D > > LC_TABLE_HEX2CHAR DS 0XL512 > > DC X'F0F0F0F1F0F2F0F3F0F4F0F5F0F6F0F7' 00-07 > > DC X'F0F8F0F9F0C1F0C2F0C3F0C4F0C5F0C6' 08-0F > > DC X'F1F0F1F1F1F2F1F3F1F4F1F5F1F6F1F7' 10-17 > > DC X'F1F8F1F9F1C1F1C2F1C3F1C4F1C5F1C6' 18-1F > > DC X'F2F0F2F1F2F2F2F3F2F4F2F5F2F6F2F7' 20-27 > > DC X'F2F8F2F9F2C1F2C2F2C3F2C4F2C5F2C6' 28-2F > > DC X'F3F0F3F1F3F2F3F3F3F4F3F5F3F6F3F7' 30-37 > > DC X'F3F8F3F9F3C1F3C2F3C3F3C4F3C5F3C6' 38-3F > > DC X'F4F0F4F1F4F2F4F3F4F4F4F5F4F6F4F7' 40-47 > > DC X'F4F8F4F9F4C1F4C2F4C3F4C4F4C5F4C6' 48-4F > > DC X'F5F0F5F1F5F2F5F3F5F4F5F5F5F6F5F7' 50-57 > > DC X'F5F8F5F9F5C1F5C2F5C3F5C4F5C5F5C6' 58-5F > > DC X'F6F0F6F1F6F2F6F3F6F4F6F5F6F6F6F7' 60-67 > > DC X'F6F8F6F9F6C1F6C2F6C3F6C4F6C5F6C6' 68-6F > > DC X'F7F0F7F1F7F2F7F3F7F4F7F5F7F6F7F7' 70-77 > > DC X'F7F8F7F9F7C1F7C2F7C3F7C4F7C5F7C6' 78-7F > > DC X'F8F0F8F1F8F2F8F3F8F4F8F5F8F6F8F7' 80-87 > > DC X'F8F8F8F9F8C1F8C2F8C3F8C4F8C5F8C6' 88-8F > > DC X'F9F0F9F1F9F2F9F3F9F4F9F5F9F6F9F7' 90-97 > > DC X'F9F8F9F9F9C1F9C2F9C3F9C4F9C5F9C6' 98-9F > > DC X'C1F0C1F1C1F2C1F3C1F4C1F5C1F6C1F7' A0-A7 > > DC X'C1F8C1F9C1C1C1C2C1C3C1C4C1C5C1C6' A8-AF > > DC X'C2F0C2F1C2F2C2F3C2F4C2F5C2F6C2F7' B0-B7 > > DC X'C2F8C2F9C2C1C2C2C2C3C2C4C2C5C2C6' B8-BF > > DC X'C3F0C3F1C3F2C3F3C3F4C3F5C3F6C3F7' C0-C7 > > DC X'C3F8C3F9C3C1C3C2C3C3C3C4C3C5C3C6' C8-CF > > DC X'C4F0C4F1C4F2C4F3C4F4C4F5C4F6C4F7' D0-D7 > > DC X'C4F8C4F9C4C1C4C2C4C3C4C4C4C5C4C6' D8-DF > > DC X'C5F0C5F1C5F2C5F3C5F4C5F5C5F6C5F7' E0-E7 > > DC X'C5F8C5F9C5C1C5C2C5C3C5C4C5C5C5C6' E8-EF > > DC X'C6F0C6F1C6F2C6F3C6F4C6F5C6F6C6F7' F0-F7 > > DC X'C6F8C6F9C6C1C6C2C6C3C6C4C6C5C6C6' F8-FF > > > > Rob Scott > > Lead Developer > > Rocket Software > > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > > Tel: +1.781.684.2305 > > Email: [email protected] > > Web: www.rocketsoftware.com > > > > -----Original Message----- > > From: IBM Mainframe Assembler List [ > mailto:[email protected]] On Behalf Of Bauer, Bobby > (NIH/CIT) [E] > > Sent: 08 August 2012 14:07 > > To: [email protected] > > Subject: Printing a return code > > > > New to the list but been written assembler off and on for years. > > I'm writing some code using the BCPii API. The return codes from the > CALLs are placed into storage in (to me) an unusual manner. In a full word > that looks like: > > 00000301 > > or > > 00000F01 > > > > How can I make these printable? I'm using a SNAP to debug but getting > the RC into a WTO would be a LOT easier. Any ideas? > > > > Bobby Bauer > > Center for Information Technology > > National Institutes of Health > > Bethesda, MD 20892-5628 > > 301-594-7474 > > > > > -- > sas > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
