Oh well.  I'll just use move if there is no other way.
The data in your field is not human-readable character data.  You could 
not reasonably expect a user to see "100N" and know that it means -1005.
The %DEC() and %INT() BIFs are expecting human-readable character data. 
For example, it could be '   -1234' or '     -85.65' and they'd have no 
trouble interpreting it.  But '00000856N'they won't understand because 
it's not human-readable character data.
What you have in your field is the contents of a zoned decimal field. I'm 
curious as to why you have this loaded into a character field in your 
program.  Why not read it into a zoned decimal field in the first place? 
When you read the file, just code the field as zoned decimal.   (Either in 
the external definition, or in the I-spec if it's program described.)
IF for some obscure reason you can't do that, you can either use the MOVE 
op-code (as you've already discovered) or you can simply overlay the 
character field with a zoned field in a data structure.  For example:
     D                 ds
     D  myCharFld                     9A
     D  myZonedFld                    9S 2 overlay(myCharFld)

      /free

          myCharFld = '00000856N';
          // myZonedFld now contains -85.65.

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-2025 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 copyright@midrange.com.

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