IBM Mainframe Forum

Hi All,

I have a PIC X(5) field which can have the following values -

1. 12345
2. -12.3
3. A1234
4. Spaces

Out of these 4, the vallid values are - 12345 & -12.3 only. I am trying to find out a way using which I can ascertain that. I tried using IS NUMERIC but, that doesn't consider -12.3 a numeric digit. Another option which I was toying around with was to redefine the PIC X(5) Field as



& then, checking the redefined field as shown below -


This seems to be working fine but, I am concerned if this is the right way of doing this. Can someone please advise me on this or if there is a better way of doing this.

So, trailing spaces are valid? One, and only one, minus sign? One and only one decimal-point?

Test field for SPACE, those are invalid
Test for NUMERIC, those are valid
Left with the items listed above.

Use intrinsic function REVERSE to swap a copy of the field around. Use INSPECT to replace leading spaces by zero. Also INSPECT to replace only one decimal-point and only one minus sign, both by zero.

Then test this copied and mashed-up field for being NUMERIC. If it is, then your original field is in a valid format. Otherwise, not.

Hi Billy,

Thanks so much for your prompt reply. Please find below my replies.

BillyBoyo wrote:So, trailing spaces are valid?

Yes

BillyBoyo wrote:One, and only one, minus sign?

Yes

BillyBoyo wrote:One and only one decimal-point?

Yes

BillyBoyo wrote:Test field for SPACE, those are invalid

As in only SPACES?

BillyBoyo wrote:Test for NUMERIC, those are valid

But, it would not work in case of -12.3

BillyBoyo wrote:Left with the items listed above.

I am sorry but, I didn't get it.

BillyBoyo wrote:Use intrinsic function REVERSE to swap a copy of the field around. Use INSPECT to replace leading spaces by zero. Also INSPECT to replace only one decimal-point and only one minus sign, both by zero.

Then test this copied and mashed-up field for being NUMERIC. If it is, then your original field is in a valid format. Otherwise, not.

I get it. Great Idea, I must say! I am going to give it a shot. One more question, do you think performance wise, this would be better than what I was doing?

do you think performance wise, this would be better than what I was doing?

Considering the current z machines execute tens of millions or hundreds of millions of lines of COBOL code per second of CPU time, why do you care about performance?

You should only care about performance when there is a demonstrated problem -- a batch job not completing within its batch window, for example. Otherwise, unless your code is being executed BILLIONS of times, COBOL code performance should only be an issue if you have absolutely nothing else to look at, and again -- only if there is perceived problems with completing on time. While wiritng code, NEVER concern yourself with how the code will perform since the first and foremost task in writing code is to write code that solves the problem, period. Because if the code doesn't have to be right, you can improve performance to any arbitrary number you want.

Just to be clear. I'm saying you have three groups of data, two of which can be easily handled (NUMERIC or SPACE/SPACES).

The other group I've suggested how a method to deal with. I'd not expect you to notice when compared to your existing solution, although don't be surprised if mine is faster (I haven't checked)

EDIT: A better subject might have been "Check whether a field conforms to my particular format for accepting numbers". As you discovered, the field is not always come up as NUMERIC for the data that you want to treat as valid...

Hello,

Many places have a callable routine that will check if a value meets the "rules" for being "numeric".

This will take a bit more than simply slinging the code into 1 program, but will prevent replicating the same routines over and over for every program than needs to check for numeric when the data does not meet the requirements for "numeric" as understood by the compiler.

If performance ever becomes an issue, there is only one place to change to correct all of the programs using the routine. Also, if the rules ever change for some reason, there is only 1 place to change.

Hi All,
Thank you so much for helping me out with this. I ended up coding it as -

Thanks once again for your meaningful insights.

Billy,
I agree I could have chosen a better subject. It just didn't cross my mind at that time.

Dick,
That is indeed a good idea. We can definitely do that.

Hello,

If you implement the code you posted, the following will happen:


This leaves one invalid value A1234 and one incorrect value 01203 (which has also had the sign changed to positive).

Are you sure this is what you want? I believe more comprehensive code is needed.

I've assumed he was just showing the INSPECT part, with the original NUMERIC and SPACES dealt with, then FUNCTION REVERSE on the field and then that INSPECT. Anything after that which is NUMERIC means the original field is good-to-go, otherwise bad...

could be a wrong assumption

Hi Billy,

Items 2 and 3 would still have incorerct/invalid values, wouldn't they?

d