IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Junk data in sign field, how to fix


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Thu Apr 12, 2007 4:42 am
Reply with quote

Hi Friends.
I am facing a problem of junk in a sign field of comp-3.
I can directly initialize all the fields as many of them have some value in the database.
I can't check not numeric comdition on a signed variable and if i move it to 9(3), it is always numeric. Problem is the signed field.

I was trying this technique...but here also it abended saying invalid sign.

database-QTY PIC COMP-3 S9(3).
WS-QTY PIC +ZZZ.

DISPLAY 'COMP-30 ' database-QTY
MOVE WS-QTY TO WS-QTY
DISPLAY 'COMP-31 ' WS-QTY
INSPECT WS-QTY REPLACING ALL SPACE BY ZERO
MOVE WS-QTY TO WS-QTY
DISPLAY 'COMP-32 ' WS-QTY


COMP-30 001
COMP-31 + 1
COMP-32 +001
COMP-30 000
COMP-31
IGZ0063S An invalid sign was detected in a numeric edited sending field in INITPGM
From compile unit INITAMF3 at entry point INITAMF3 at compile unit offset +0000D462

Please suggest.
Thanks
Bharat
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 8:02 am
Reply with quote

Hello,

Please post more of your code at the place of the abend - post some lines before and after the abend point.

Why is this "MOVE WS-QTY TO WS-QTY " in the code (twice)? Why edit a field supressing leading zeros to then replace the "spaces" with zeros?

Your "display" output does not match the code. You should cut/paste rather than entering it.

If you are reading data from a database table, it is very likely that the number is valid. If you moved the database data to a field inside the program, there may be problems there.
Back to top
View user's profile Send private message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Thu Apr 12, 2007 8:30 am
Reply with quote

Oh, sorry for the mistake.
It is a IDMS DB, so there is no way to set a default 0 value to the field like in DB2, it is 100% sure that there is junk in DB in this database-QTY. And seeing the COMP-30 display for that field i.e. 000, it is sure that the numeric part is ok. The problem in in signed bit. Is there a way to check the signed bit?

After I reach that record occurence I execute the following code:

DISPLAY 'COMP-30 ' database-QTY
MOVE database-QTY TO WS-QTY
DISPLAY 'COMP-31 ' WS-QTY
INSPECT WS-QTY REPLACING ALL SPACE BY ZERO
MOVE WS-QTY TO database-QTY
DISPLAY 'COMP-32 ' WS-QTY


COMP-30 001
COMP-31 + 1
COMP-32 +001
COMP-30 000
COMP-31
IGZ0063S An invalid sign was detected in a numeric edited sending field in INITPGM
From compile unit INITPGM at entry point INITPGM at compile unit offset +0000D462

Thanks,
Bharat
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Apr 12, 2007 2:44 pm
Reply with quote

DISPLAY 'COMP-30 ' database-QTY >> COMP-30 001
MOVE database-QTY TO WS-QTY
DISPLAY 'COMP-31 ' WS-QTY >> COMP-31 + 1
INSPECT WS-QTY REPLACING ALL SPACE BY ZERO
MOVE WS-QTY TO database-QTY
DISPLAY 'COMP-32 ' WS-QTY >> COMP-32 +001

What moves are generating these?
????? >> COMP-30 000
????? >> COMP-31
????? >> IGZ0063S An invalid sign was detected in a numeric edited sending field in INITPGM From compile unit INITPGM at entry point INITPGM at compile unit offset +0000D462

Why bother with the INSPECT?
PIC +ZZZ >> +bb1 where b is a blank
PIC +++Z >> bb+1 or
PIC +999 >> +001
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 6:16 pm
Reply with quote

Hello,

I'd suggest fixing the data in the database if it is corrupt - as well as correcting the code that allowed invalid numeric data to be placed in the database. Downstream code should not need to validate things already in the database.
Back to top
View user's profile Send private message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Thu Apr 12, 2007 6:55 pm
Reply with quote

Dick,
you are right but the point is right now, how do I rectify all the instaces of the field which already has a invalid signed bit in a single go..?
Since it's a signed comp-3 variable, I am not able to do many checks of this and if I move it to a 9(3), I loose the signed bit..?


Thanks,
Bharat
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 7:30 pm
Reply with quote

Hello,

What should happen to the invalid data? Is this task to correct the bad values?

For the "bad" values, what should they become?

Have you looked at the bad data in hex to see what value(s) exist?

Please post some examples of the bad data in hex and we'll go from there.
Back to top
View user's profile Send private message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Thu Apr 12, 2007 7:35 pm
Reply with quote

Yes, this program is to correct the "bad" values. I want to overwrite signed bit with a + without disturbing the 9(3) part.

I can just get to the 9(3) part, I can'd display the signed part.
9(3) part is ok, but there is something else in signed bit other than a 0 or 1. May be a space...I donno!
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 8:23 pm
Reply with quote

Hello,

There is no "sign bit" with comp-3 data. The low-order nibble (1/2-byte) is the sign for comp-3 data. Valid signs are C (positive), D (negative), and F (neither, but acts like it is positive).

I don't understand " there is something else in signed bit other than a 0 or 1". There should be no zero of one bit for a sign icon_confused.gif

Please post some of the 'bad' data in hex so we can move forward. Until what you have is known it will be difficult to suggest a fix. When you post, post the entire 'bad' field as well as the fields on either side with a description of what these fields are.

To get the values we need, read the item(s) and write them into a qsam file as a group, not the individual fields (to prevent the 0c7). The entire row is not needed - just the error field(s) and a bit of surrounding data. Once you have created a few records in a file, go into tso, browse the file and turn hex on. From there, copy/paste the data as "Code" using the tab at the top of the reply panel.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Apr 12, 2007 8:26 pm
Reply with quote

Please Bharat, What is giving you the impression that there is a "bad" sign? Moving a S9(3) comp-3 to a +ZZZ picture should give you exacally what you are getting, a '+bb1' where b is blank.
And what move/display/? is causing the "IGZ0063S An invalid sign was detected..." message?
Back to top
View user's profile Send private message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Thu Apr 12, 2007 9:38 pm
Reply with quote

There is a bad sign because I fixed one of such occurence but for that I have to traverse lot of records to find that I am hitting the right one. I can't do that will all such occurences. I need to device a generic logic that will fix all such bad fields.

Like in the above example it told that the value is 000, I displayed other fields that made a unique occurence and then I moved a +000 into it and it didn't abend on it again....

It exactly went down at this statement, the one after Inspect:
MOVE WS-QTY TO database-QTY
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 9:47 pm
Reply with quote

Hello,

We understand that the move raises the error. . . .

You must show what you have to determine what the "fix" will be.

How did you manage "fix" the one bad sign - a zero or one? ? ? That is not at all clear. . .

It may not be trivial, but you need to find the "bad" records and show their content. Why can you not do this for "all such occurrences"? It might take a little bit of work and a little bit of time, but it is do-able.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Apr 12, 2007 10:26 pm
Reply with quote

Let me see if I really understand:

You move a value from a S9(3) COMP-3 field to a +ZZZ numeric edited field.
You then replace whatever blanks that appeared because of the ZZZ with zeros.
You then move that numeric edited field back to the COMP-3 field and sometimes you get the IGZ0063S failure.

Was that just about it?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Thu Apr 12, 2007 10:39 pm
Reply with quote

Well, I?ll make a stab at this anyway???

Because of the zero suppression, if the number is zero then the fixed insertion '+' gets suppressed.

Elementary MOVE rules specify that if the receiving item is signed (it is), 'the sign of the sending item is placed in the receiving item, with any necessary sign conversion'.

Since the unique rules of zero suppression have suppressed the sign of the sending field, I think that is why you are getting the error.

Why don't you test this by using an edit picture of '+ZZ9'?
The only difference will be that when you have a numeric zero, the '+' will not be suppressed and COMP-31 will display as:
'+ 0'.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Thu Apr 12, 2007 11:39 pm
Reply with quote

Hi Bill,

I'm curious as to what caused the "search for junk" in the first place. I'm also still confused by the zero or one "sign bit".

The request for the actual data was to see what was "really" in the data, not some symptom. Doesn't look like anything real is going to be psoted. . .

If changing the edit mask caused the error to go away. . . . icon_confused.gif
Back to top
View user's profile Send private message
bharat_juneja

New User


Joined: 21 Dec 2005
Posts: 20
Location: US

PostPosted: Fri Apr 13, 2007 2:46 am
Reply with quote

Bill,
The searched started when I had a screen abend due to this field.
And when I hardcoded the value for that particular product to +000, the screen worked fine.

William,
By using this inspect logic, I was trying to find a way to locate all such products which had that quantity field junk. Yeah, using your method of +zz9 program didn't abend...but I have no way to verify whether there is any more such product in DB for which quantity is invalid...

How can I find that a comp-3 s9(3) has a valid value ...?
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Apr 13, 2007 3:07 am
Reply with quote

bharat_juneja wrote:
How can I find that a comp-3 s9(3) has a valid value ...?
Read the database field into a COMP-3 host variable, and ask IF NUMERIC. If it is, no garbage sign byte. If not, set or validate to your needs.
As an aside, which you probably are already covering, Find where the junk is entering your system and "plug" that offender "with extreme Prejudice".....
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Fri Apr 13, 2007 3:33 am
Reply with quote

Hello again,

What will you do with the "bad" values? Are you not concerned what is in the field(s) that causes the problem(s)? I'm not sure that simply moving zeros to the field(s) is a good solution. The changing of order quantities, inventory quantities, (etc), to zero may cause other problems for the system.

I'd still suggest finding the "bad" values and (once again) showing the hex content of the bad field(s) as well as the "key" to the problem records. There are multiple reasons for this. You may be able to determine what "should" have been in data. You may be able to identify where the problem records came from and so know what module(s) need to be corrected.

How did you determine you had a bad sign - as opposed to an entire corrupt value? If that info was posted, i've missed it and do apologize. It is more likely that the data is worse than having the correct digits and a bad sign. Common bad values are x'00's and spaces, but it could be almost anything.
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia

PostPosted: Fri Apr 13, 2007 5:56 pm
Reply with quote

Why isn't it spelled "nybble"?
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Fri Apr 13, 2007 6:10 pm
Reply with quote

'Cause it isn't British . . . ?
Back to top
View user's profile Send private message
Mickeydusaor

Active User


Joined: 24 May 2006
Posts: 258
Location: Salem, Oregon

PostPosted: Fri Apr 13, 2007 8:29 pm
Reply with quote

My question is what if you have a negative value in a field (-).??
then you are making it a postive value (+).

I would check all the fields in the table for a valid SIGN and display
the RECORD KEY of any fields that were in ERROR in a REPORT so
that someone could look at the record and determine if the value
should be a (+) or a (-) value.

simple test.

SPECIAL-NAMES.
CLASS VALID-PACVALS IS '0' THRU '9', '-', '+'.

if DATABASE-field VALID-PACVALS
bypass this record
else
move record-key to report
end-if
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Fri Apr 13, 2007 8:37 pm
Reply with quote

The sorry thing is, from what I can tell, is that he is causing the error by his move to an edit field and back. The "junk" he finds is his own doing... icon_rolleyes.gif
Back to top
View user's profile Send private message
Mickeydusaor

Active User


Joined: 24 May 2006
Posts: 258
Location: Salem, Oregon

PostPosted: Fri Apr 13, 2007 8:40 pm
Reply with quote

Yes if there are moving the +ZZZ to the database field they are
causing there own problem.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Fri Apr 13, 2007 8:43 pm
Reply with quote

One more time. . . .

If we can see the actual content of the bad field(s), we will surely be able to offer recommendations.

There may be nothing wrong (but i suspect there is) or as Bill suggests - whatever is wrong is self-inflicted.

And surely flipping the sign from a '+' to a '-' would be a very bad thing to do. . .
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Help required to reset decimal points... DFSORT/ICETOOL 6
No new posts db2 vs static data COBOL Programming 1
No new posts Sorting Date Field DFSORT/ICETOOL 4
No new posts External data queue (changes?) CLIST & REXX 0
No new posts Pull data using date difference betwe... DB2 6
Search our Forums:

Back to Top