sponsored links

Collapse

Announcement

Collapse
No announcement yet.

Can someone help explain this output?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can someone help explain this output?

    Hello,

    This is baffling me, I don't get why "=" trims off the last digit? Does anyone know why?

    Code:
    d ZonedDecimal    S              6s 0        
    d Character       S              6a          
    
      ZonedDecimal = 37787;                      
    
      Character = %editc(ZonedDecimal:'P');      
      Dsply Character; // Result: DSPLY    3778          
    
      EvalR Character = %editc(ZonedDecimal:'P');
      Dsply Character; // Result: DSPLY   37787          
    
      *InLr = *On;                               
      Return;
    Cheers,
    Ryan



  • #2
    Further to this, if I increase the field size, it seems '=' to puts it in the middle of the field??

    Code:
    d ZonedDecimal    S              6s 0        
    d Character       S             10a          
    
      ZonedDecimal = 37787;                      
    
      Character = %editc(ZonedDecimal:'P');      
      Character = %xlate(' ':'-':character);     
      Dsply Character; // DSPLY  --37787---      
    
      EvalR Character = %editc(ZonedDecimal:'P');
      Character = %xlate(' ':'-':character);     
      Dsply Character; // DSPLY  -----37787      
    
      *InLr = *On;                               
      Return;

    Comment


    • RDKells
      RDKells commented
      Editing a comment
      In fact the output is --37787, which is 7 long so that explains why the last 7 is missing but it doesn't explain why it's got 2 leading blanks instead of 1.

  • #3
    A 'P' edit code returns the sign thus returning a string 7 characters long, you are putting into a 6 character field thus losing a character. You can %trim(%editc()) to just get the digits. If you can ever have a negative value you could still lose part of the value. If you know you will never have a negative value you could use '3' edit code or maybe 'Z' if you won't ever have zero - the RPG manual has a chart of all the edit codes. %char can also be useful but again have to understand what it does to make sure fits your use case.

    Comment


    • #4
      I was actually looking at the edit code thing here; https://www.ibm.com/support/knowledg...mstdfedtcd.htm but didn't clock the minus sign would take up an extract character.

      Obvious now you've explained it, thanks Scott.


      This is a record count so won't be negative, however there are numerous fields before it that could be and require the negative sign output - I guess the original developer did so many 'P's in a row they just got stuck in a trance and did it for all decimal fields.

      Regarding losing part of the value - all result fields are the same size as the source fields, so if a negative value taking up all fields is produced it will be returned as a positive...!!

      Example -123456 is output as 123456...

      Code:
      d ZonedDecimal    S              6s 0        
      d Character       S              6a          
      
        ZonedDecimal = -123456;                    
      
        EvalR Character = %editc(ZonedDecimal:'P');
        Character = %xlate(' ':'-':character);     
        Dsply Character; // DSPLY  123456          
      
        *InLr = *On;                               
        Return;

      Great, now I've noticed this I can't leave it as it is... Lol.


      Thanks Again,
      Ryan

      Comment


      • #5
        Ryan,

        %xlate(' ':'-':character) converts a blank to minus !!!!!
        In the example you gives evalR strips the minus character.
        That is why you can't see it.

        Use editcode "3" that Scott recommends or use %char() instead.

        Drop the xlate part. It only brings confusion to fellow programmers because it is not necessary.

        Comment


        • #6
          Hi Peder,

          This is just a test program I wrote to demonstrate the issue - %xlate is just used to make it easier to see on here where the blanks are.

          The issue, per Scott M's advice, is that the signage (due to edit code P) takes up an extract space so the result is 7 but the result field is 6 - nothing to do with xlate.

          Comment

          Working...
          X