Thanks Jon and Buck.

Taking odd the %Trim on the Data did the trick.

When I take a moment to think about it.... Duh!

To close to the problem.

Yes Jon, I just copied snips of code to post. The X was part of a for loop on the number of fields.
Should have cleaned it up a bit before the post.



-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Friday, July 31, 2015 9:31 AM
To: Rpg400 Rpg400-L
Subject: Re: Decimal Data Error On Packed Number

I'm assuming here that using X as the field start position and x as the length is simply an error in your example code here - it makes no sense in the real code.

I don't see why you would perform a trim - it is bound to cause problems. If the field starts in position X and has a length of Y then _all_ character positions in it are a valid part of the field. If you use %Trim then any leading spaces (which if you have an odd digits value that begins 40nnnn will result in an error as you have noted. Take for example the value 40409. (Hex 40409F probably) The trimmed version in character form is hex '9F40404' and that F will cause the error.

You need to get rid of the trim and replace your sub stringing with an alternative method. I don't know how many different sizes of fields you have the easiest, fastest method would depend on him many different types you have.


On Jul 31, 2015, at 8:42 AM, (WalzCraft) Jerry Forss <JForss@xxxxxxxxxxxxx> wrote:

Hi All,

I have a program that will take any IBMi file and create an excel.
Works great and is used daily. Users are creating new files using Query all the time.

I retrieve the fields for the file using QUSLFLD and are loaded into arrays.

FInput IF F32766 DISK UsrOpn ExtFile(FileOverride)
F InfDS(InputDS)

DInputDS DS
D InputRecords 156 159I 0
D InputRRN 397 400I 0

D DS INZ
D NumericFld 1 16P 0
D AlphaFld 1 16

IINPUT NS
I 132766 InputData

// Seperate Field
Data = %SubSt(InputData : FldStart(X) : FldLength(x));

// Load Field From String
%SubSt(AlphaFld : 17 - FldLength(X)) = %Trim(Data);

Here is the scenario.
The field must be packed, odd number of digits, must be using all digits AND first 2 digits contain 40.
Example: P5,0 contains 40000 it fails. If it contains 4000 no issue. If it contains 41000 no issue.

I read a record from Input and start parsing out the fields.

When it does the SubSt to the alphafld the result (NumericFld) contains invalid data and further in the code gets a decimal data error. Yes, I can add a monitor to trap it.

I know when it is going to happen because I can test on field type (P), length (Odd digits) and first position of Data contains X'40'.

First, Why does it decide to interpret the X'40' as a space I assume only in the scenario?

What can I do about it?

Is there a better way of parsing out the data?

Thanks!!!

Subject to Change Notice:

WalzCraft reserves the right to improve designs, and to change specifications without notice.

Confidentiality Notice:

This message and any attachments may contain confidential and privileged information that is protected by law. The information contained herein is transmitted for the sole use of the intended recipient(s) and should "only" pertain to "WalzCraft" company matters. If you are not the intended recipient or designated agent of the recipient of such information, you are hereby notified that any use, dissemination, copying or retention of this email or the information contained herein is strictly prohibited and may subject you to penalties under federal and/or state law. If you received this email in error, please notify the sender immediately and permanently delete this email. Thank You;

WalzCraft PO Box 1748 La Crosse, WI. 54602-1748
www.walzcraft.com Phone... 608-781-6355

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.