2

I need convert some decimal to PD6.2, then send it to Mainframe. It's very hard to find any function in C#. please help. Thanks a million

Mike Long
  • 363
  • 4
  • 16
  • What code have you tried already? – Flexicoder May 11 '16 at 16:09
  • @Flexicoder haven't got any code. – Mike Long May 11 '16 at 16:12
  • There's loads for different languages already here. My advice: don't do it. Send "text-only" data, with a physical full-stop/period for the decimal place, in a fixed position in a fixed-length field. It is exceptionally easy for an IBM Mainframe to deal with that, and it also means (assuming you do it for all "non-text" fields) that you can do ASCII/EBCDIC conversion at file/record level, rather than field-by-field, which you need if your records have binary or packed-decimal or floating-point data (which are neither ASCII nor EBCDIC, they are just those things *and must not be "converted"*. – Bill Woodger May 11 '16 at 16:52

1 Answers1

0

See if this works

        public static void Main()
        {
            string lookup = "0123456789";
            int input = 123456789;
            string input_str = input.ToString();
            List<byte> output = new List<byte>();
            int index = 0;
            //odd number characters
            if (input_str.Length % 2 == 1)
            {
                output.Add((byte)lookup.IndexOf(input_str.Substring(index++, 1)));
            }
            for (int i = index; i < input_str.Length; i += 2)
            {
                output.Add((byte)((lookup.IndexOf(input_str.Substring(i, 1))) << 4 | lookup.IndexOf(input_str.Substring(i + 1, 1))));
            }



        }
jdweng
  • 33,250
  • 2
  • 15
  • 20
  • Thanks, but output is very weird. – Mike Long May 11 '16 at 18:47
  • @MikeLong "very weird" tell us nowt. Note that the code does not seem to do anything with the embedded "signs" (low-order, right-most, nybble) but superficially it is doing part of the work. Now, just think how much easier it would be just to output a fixed-length "string" (but without a delimiter, just a fixed-length lump of digits, with leading zeros and an actual decimal point followed by two digits. I don't think you'd even consider doing that worthy of the name "code" and you'd have 100% accuracy. If you need a signed value, chose either a leading or trailing sign, explicitly as + or -. – Bill Woodger May 11 '16 at 20:33
  • @MikeLong Then on the Mainframe, let's use COBOL as an example, it is dealt with by `MOVE something TO something-else`. OK, that's the same if the source is packed-decimal (the data-definitions tell the compiler what code to generate for the MOVE), but bear in mind the second big advantage (first being that you can't bog it up) in the (presumed) ASCII to EBCDIC conversion. – Bill Woodger May 11 '16 at 20:36
  • It was easier doing this in c# then having to do it 40 years ago in college in assembly language. – jdweng May 11 '16 at 23:56
  • @jdweng This may be due to my limited understanding, but I do not see any code for the sign nyble ???. Here is an answer in Java http://stackoverflow.com/questions/4337912/how-to-convert-unpacked-decimal-back-to-comp-3/4343256#4343256 – Bruce Martin May 12 '16 at 00:04
  • This answer http://stackoverflow.com/questions/35414574/comp-3-data-unpacking-in-java-embedded-in-pentaho/35418971#35418971 describes the comp-3 format – Bruce Martin May 12 '16 at 00:07
  • It's ever so easy to in COBOL. There is zero need to complicate things by giving packed-decimal data to COBOL from a non-Mainframe systems, implying the conversion of "character" fields from ASCII-to-EBCDIC and leaving anything else as is. So much simpler for the process, and for the non-COBOL code, if everything is "character". And COBOL doesn't care either way, still really easy. So why the twists and turns? Just because OP says it should be so? – Bill Woodger May 21 '16 at 11:19