IF WS-055-EXPIRY-YYV AND WS-055-EXPIRY-MMV
DISPLAY 'FLAG SET '
ELSE
DISPLAY 'FLAG NOT SET '
END-IF.
The Value for the field WS-055-EXPIRY-YYMM is 140E, But the above logic is TRUE. I wonder as the value of MM is 0E, (non numeric), why the Condition is set true. Is there something hexadecimal value is also considered as part of THRU defined in Condition.
Your clarifications will be really helpful.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Please use the Code tags to preserve spacing and the Preview button to ensure that your post looks how you want it to look.
You have defined your fields as "unsigned", yet the "E" that you mention indicates that you data conforms to a PICture that has a sign, and the that particular value is positive.
You have compiler option NUMPROC(NOPFD) (don't you?). That is how the "signed value in an unsigned field" gets treated as an unsigned value wherever you use it.
If your data is signed, you will be far better off to define it with a sign. Note that your Year is unsigned. Probably you have a the whole field which you are sub-dividing. So the first part should be unsigned (to match the data) and the second part signed (to match the data).
EDIT: I corrected "Cod tags" above, but the idea is such fun, I thought to mention it. Particularly useful for any "fishy" or otherwise mysterious code, or code that plain "stinks", perhaps. Maybe for "information" of the "Red Herring" variety, as well...
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Your post is not clear -- exactly what data is being used, character or hexadecimal? If hexadecimal, you are two bytes short of telling us the full value of the 05 variable. I tested the character data:
Code:
05 WS-055-EXPIRY-YYMM.
10 WS-055-EXPIRY-YY PIC 9(2).
88 WS-055-EXPIRY-YYV VALUE 00 THRU 99.
10 WS-055-EXPIRY-MM PIC 9(2).
88 WS-055-EXPIRY-MMV VALUE 01 THRU 12.
PROCEDURE DIVISION.
MOVE '140E' TO WS-VARS.
IF WS-055-EXPIRY-YYV AND WS-055-EXPIRY-MMV
DISPLAY 'FLAG TRUE'
ELSE
DISPLAY 'FLAG FALSE'
END-IF.
GOBACK.
@Robert, The data is of Character format, i will receive the Date in YYMM format that is in X(4), i need to ensure the YYMM received is valid data. So i will be moving the value into 9(4) and later checking the 88 condition code.
MOVE '120E' TO WS-055-EXPIRY-YYMM
DISPLAY 'WS-055-EXPIRY-YYMM : ' WS-055-EXPIRY-YYMM
IF WS-055-EXPIRY-YYV AND WS-055-EXPIRY-MMV
DISPLAY 'FLAG SET '
ELSE
DISPLAY 'FLAG NOT SET : '
END-IF
Remember, the above is how you have defined the data in your program. It is not (necessarily) how the data was defined when it was written to the file.
It was defined (stupidly) like this:
Code:
05 WS-055-EXPIRY-YYMM PIC S9(4).
You are using compiler option NUMPROC(NOPFD). You haven't confirmed this, but you are (possibly, less likely, MIG).
With NOPFD your 88s will give you a match.
If, as Robert suggested, you do a NUMERIC test, you might (depending on how your Cobol was installed, viz the NUMCLS option) get the 0E to be "not numeric".
However, the "0E" is really "05" when expressed as positive in a signed zoned decimal.
This is not to say that you don't have some problem that has arisen from all this.
The root of any problem is that the data has been defined one way when placed on the file, and another way "elsewhere", which is in your program and possibly many other places.
If you can say what your specific problem is, we may be able to provide further assistance.
@Robert/Bill,
I ve done with coding with IS NUMERIC and later conditional clauses in the meantime already as you mentioned here. Now im thinking of this issue why 0E is considering as numeric. I looked into the compiler option,
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
dudenithy wrote:
@Robert/Bill,
I ve done with coding with IS NUMERIC and later conditional clauses in the meantime already as you mentioned here. Now im thinking of this issue why 0E is considering as numeric.
I think that Mr. Woodger has already made the matter clear -- "E" is a signed (over-punched) zoned decimal digit. The use of over-punching to represent signs goes back decades, to when "computer" meant "grad student working out trig tables by hand". Read about actual punched cards -- pieces of stiff paper with holes in them -- here.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
From the Enterprise COBOL Language Reference manual, 6.1.6.2 on class conditionals:
Quote:
NUMERIC
identifier-1 consists entirely of the characters 0 through 9, with or without an operational sign.
If its PICTURE does not contain an operational sign, the identifier being tested is determined to be numeric only if the contents are numeric and an operational sign is not present.
If its PICTURE does contain an operational sign, the identifier being tested is determined to be numeric only if the item is an elementary item, the contents are numeric, and a valid operational sign is present.
Note: Valid operational signs are determined from the setting of the NUMCLS installation option and the NUMPROC compiler option. For more information, see the Enterprise COBOL Programming Guide .
For zoned decimal data, which your elementary variables are, E is a valid number 5 with sign C (positive). Unsigned, the value would be X'F5' but signed the value is X'C5'. The default NUMCLS option is PRIM, which indicates that C,D,F are valid signs in zoned decimal variables. However, both NUMCLS and NUMPROC must be examined to know for sure how the compiler will treat signs.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Generally it works like this. Person installing the Compiler knows what is available from the Customisation Guide, but may not have an "applications" background. "Applications" people tend to not be too aware of compiler options.
So what you tend to end up with is the defaults at installation, or choices not necessarily based on the data that is being worked with.
That gives you NUMPROC(NOPFD) and NUMCLS(PRIM). NOPFD accepts A thru F as valid in the sign (packed or zoned) and PRIM only allows C, D and F to test for "numeric".
The setting of NUMCLS for NUMPROC(PFD) is irrelevant, as only C, D and F are valid values anyway.
Those interested in knowing the value of NUMCLS can consult their compile listing/loadmodule, and the section in the Programming Guide on "Signature information bytes: compiler options" (even though, strictly, NUMCLS is an installation option, not a compiler option)
Set all that to one side, dudenithy, can you tell us what problem it is that you are looking into?
Your data that has been placed on the file has been defined with one PICture (PIC 9(4) or longer). That may or may not be true for all data on the file. If you have a "mix" of signed and unsigned data, you need to raise the paperwork to get it fixed, cos it is an accident waiting to happen.
If you just "do something different" with your "non-numeric" data, you may be at least delaying the processing of correct data, that is poorly expressed. You need to know.
You might be sitting on a huge problem. Or you might not. If you don't give us more information, then it will be up to you and your organisation to deal with it, and I hope that that does not been "test for NUMERIC and hope for the best".
dudenithy, can you tell us what problem it is that you are looking into?
@ Bill, Thanks for the detailed explanation and as mentioned earlier, my requirement was, i will receive the date in YYMM format which is a character, X(4).. I need to validate whether its a valid date, ie, YY should be between 00-99 and MM should be 01-12. Initially i did the coding as mentioned in my original post and still the Condition clause for Month is set (Date Value is 140E). Later i modified the logic to use IS NUMERIC and can able to complete my requirement, But still its strange to see why conditon clause accepts 0E as a acceptable one.
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
Quote:
But still its strange to see why conditon clause accepts 0E as a acceptable one.
It will be "strange" untiil you become familiar with / undestand how numeric data can be stored. There is a lot of information in the COBOL Language Reference (available thru the "IBM Manuals" link at the top of the page.
This topic contains some explanation material. There are other topics in the forum that talk about this. Suggest you re-read this topic and find these others and review them along with the manual.
It is quite important that you understand what is going on within the system . . .
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
dudenithy,
It may be a PIC X(4) to you and me and many others, but I'd make a small bet that someone, somewhere, getting data onto the file in some circumstance, and possibly in all, defined it as PIC S9(4).
If you want to see how it gets treated such that the 88 is true, generate the pseudo-assembler from the compile (if you don't already have it). That'll be with option LIST, and you'll have to have OFFSET off. You'll see the code that the compiler generates.
If you change your subordinate levels from PIC 99 to PIC XX you'll see the 88s "stop working" with that data. If you test that for NUMERIC, it won't be.
140E is 2014, May, when held in a signed zoned-decimal. Or gibberish if in a PIC X(4).
I suggest you be pretty sure about which before you go ignoring that and treating them differently in your program.
This is a PIC 99:
X'ZDSD'
Where Z is "zone", which will contain an F. S is "sign" and would normally contain an F, as your field is unsigned. The two Ds are the "digits" of your number.
X'F0F5' is what you'd expect for May.
What you have is
X'F0C5'. The "C" is either a positive sign or it is part of the character "E" that had got into the field through some type of error.
You have a PIC 99 where the data does not "conform to PICture". NUMPROC(NOPFD) "takes care of this" through blindly assuming that the data is OK anyway.
What NUMPROC(NOPFD) will do with your PIC 99 is generate code that "presumes" an F exists in the sign, no matter the original content. So your field gets treated as "05" and the 88 is true.
You may be doing yourself and your organisation a disservice by concentrating on the technicalities.
The most important thing is HOW DID THE DATA GET THAT WAY?
There, I've made it more difficult for you to ignore, so I'm done with it now...
hopefully i will 
