Good News Everybody!
The new search engine is LIVE!
Please report any problems to david (at) midrange.com.
|
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:
midrange.com
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 mailing list archive is Copyright 1997-2026 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.
