%Subst/%Trim problem

[gregwga50]

This code:

Monitor ;                                         
      [COLOR="#0000FF"]wkCode10 = %Subst(%Trim(D1rcode):1:10);[/COLOR]      
      P_UGLN = %int(wkCode10);                     
 On-error *all ;                                   
      Clear P_UGLN ;

Produces this error:
Length or start position is out of range for the string operation

When:
D1RCODE = '20121018 '

The fields are defined as follows:

 D D1rcode                       20

 D wkCode10        S             10

Not sure why I get the Length or start position is out of range for the string operation error. D1RCODE is a subfield in a data structure. Don't know if that enters into it.

[DAG0000]

Re: %Subst/%Trim problem

It looks like you trying to retrieve a number from the first 10 bytes of D1rcode. The %Trim is making the resulting length of the value your using in that field less the 10. The trim is also removing leading blanks so i think you should probably be using %TrimR.

The statement should probably look something like this:

%TrimR(%SubST(D1rcode:1:10))

Is there a reason for using field wkCode10? This could just as easily be done in 1 step:

PUGLN = %Int(%TrimR(%SubST(D1rcode:1:10)))

[gregwga50]

Re: %Subst/%Trim problem

I just added wkCode10 for debugging purposes 2 try and narrow down the problem. The original code had

P_UGLN = %int(%Subst(%Trim(D1rcode):1:10))

[tomliotta]

Re: %Subst/%Trim problem

How many characters does %Trim(D1rcode) have? We see your definitions for D1rcode and wkCode10, but the function result might even trim down to nothing.

[Scott Klement]

Re: %Subst/%Trim problem

Can you simply remove the %TRIM? I don't see why this is there... the extra blanks won't affect the %INT() BIF, so the %TRIM is just requiring the computer to do extra work, and I can't see any purpose for it...?! This %TRIM is causing the problems that you cite... you can't take a 10 character substring of a string that's only 8 long.

[gregwga50]

Re: %Subst/%Trim problem

Actually the string is defined as char 20. This website for some reason supresses the trailing blanks

Tha actual value is '20121018' followed by 12 blanks

[Scott Klement]

Re: %Subst/%Trim problem

The _input_ to %TRIM is CHAR(20). The _output_ of %TRIM is a separate string that is only 8 long, and it won't have any blanks -- that's what %TRIM does, it removes blanks (or other characters) and outputs a new string.

Your %SUBST takes the output of the %trim, not the input. So in the example you posted, it will be trying to extract 10 characters from a string that's only 8 long.

And the forum software _will_ show trailing blanks if you use [code][/code] tags.

[Rocky]

Re: %Subst/%Trim problem

I suggest the following:

slen = %len(%Trim(Dircode));
if slen > 10;
  slen = 10;
endif;
wkCode10 = '';
if slen > 0;
  wkCode10 = %Subst(%Trim(Dircode):1:slen);
endif;

This will return a max of 10 characters - but not won't specify a larger length value than the actual data.

[john.sev99]

Re: %Subst/%Trim problem

As Scott has said, the %TRIM is producing an intermediary result, which in your example of 20121018 is only 8 characters long so trying to get the 1st 10 characters from that is of course outside the range.
If you wanted to remove trailing blanks, then doing it after the %SUBST would make more sense - %TRIM(%SUBST(dircode:1:10)).
Or maybe you think there could be leading blanks and %SUBST won't give you the full number? If you needed to remove leading blanks, then putting it into an intermediary variable is probably the easiest - x=%TRIML(dircode) and then doing a %SUBST on x.

[tomliotta]

Re: %Subst/%Trim problem

If you needed to remove leading blanks, then putting it into an intermediary variable is probably the easiest - x=%TRIML(dircode) and then doing a %SUBST on x.

The combined possibility of both leading and trailing blanks is one reason for using %TRIM() in most cases. It's not particularly clear why any trimming is done in this particular case since %INT() doesn't care about leading/trailing blanks at all. (Scott also mentioned that.)

No need for any intermediate. The straight %SUBST() should work by itself. And the reason to use %SUBST() would only be because there might be extra unwanted characters out in the last ten bytes. If those are always blank anyway, there might not even be a use for %SUBST().

[B.Hauser]

Re: %Subst/%Trim problem

Going back to the original problem:
Could it be that D1RCODE was *Blank?

Otherwise neither IMHO neither %Trim nor %SUBST is needed. %INT will remove all leading and trailing blanks from the string. But none of the Built-in-Functions for converting into numeric values converts an empty string (or *Blanks) into *Zeros, but returns an error instead.

Birgitta
Birgitta.