Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Condition Clause 88: THRU Values

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Wed Oct 24, 2012 3:00 pm    Post subject: Condition Clause 88: THRU Values
Reply with quote

Hi,

I have defined the condition clause as below, for the Purpose of checking one incoming message with Expiry date that needs to be a valid one,

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.


Under Procedure division, i have below logic,

Code:
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.

Code'd
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Oct 24, 2012 3:22 pm    Post subject: Reply to: Condition Clause 88: THRU Values
Reply with quote

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...
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Wed Oct 24, 2012 4:46 pm    Post subject:
Reply with quote

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.
and got results of
Code:
----+----1-
 FLAG FALSE
Back to top
View user's profile Send private message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Wed Oct 24, 2012 5:04 pm    Post subject:
Reply with quote

Hi Bill / Robert,
Thanks for your thoughts.

@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.
Back to top
View user's profile Send private message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Wed Oct 24, 2012 5:24 pm    Post subject:
Reply with quote

@robert, i tested the below code(with inclusion of redefines clause),
Code:
05 WS-055-EXPIRY-YYMM  PIC X(4).             
05 FILLER REDEFINES 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.

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                                             

And i got the result as,
Code:
WS-055-EXPIRY-YYMM  : 120E
FLAG SET                 
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Wed Oct 24, 2012 5:40 pm    Post subject:
Reply with quote

Why not use IF NUMERIC on each of the 10 level varaibles before you check the conditionals?

What compiler opitons are you using -- some of them can affect the results?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Oct 24, 2012 5:53 pm    Post subject: Reply to: Condition Clause 88: THRU Values
Reply with quote

Code:
05 WS-055-EXPIRY-YYMM  PIC X(4).             
05 FILLER REDEFINES 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.


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.
Back to top
View user's profile Send private message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Wed Oct 24, 2012 6:36 pm    Post subject:
Reply with quote

@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,

Code:
NUMPROC(NOPFD)
.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Wed Oct 24, 2012 6:46 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Wed Oct 24, 2012 6:55 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Oct 24, 2012 7:26 pm    Post subject: Reply to: Condition Clause 88: THRU Values
Reply with quote

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".
Back to top
View user's profile Send private message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Wed Oct 24, 2012 8:12 pm    Post subject:
Reply with quote

Quote:
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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Oct 24, 2012 8:26 pm    Post subject:
Reply with quote

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 . . .
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Oct 24, 2012 9:40 pm    Post subject: Reply to: Condition Clause 88: THRU Values
Reply with quote

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...
Back to top
View user's profile Send private message
dudenithy

New User


Joined: 02 Mar 2012
Posts: 48
Location: India

PostPosted: Thu Oct 25, 2012 12:15 pm    Post subject:
Reply with quote

Thanks Bill for your time to share more details on this topic,, Its big for me to understand, icon_rolleyes.gif hopefully i will icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Overlaying one set of charater values... Kevin Lindsley SYNCSORT 7 Sat Nov 05, 2016 3:21 am
This topic is locked: you cannot edit posts or make replies. How to pass the previous month date i... Suganya87 DFSORT/ICETOOL 5 Mon Oct 31, 2016 4:13 pm
No new posts Low values Results from VARCHAR FORMAT balaji81_k DB2 10 Thu Oct 20, 2016 1:18 am
No new posts How can we create a flat file in JAVA... rakesh.v18 Java & MQSeries 7 Fri Sep 23, 2016 10:46 pm
No new posts Using 'parm' to vary SORTOUT record v... Sysaron DFSORT/ICETOOL 13 Wed Sep 07, 2016 9:24 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us