Junk data in sign field, how to fix

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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

dick scherrer · Posted: Thu Apr 12, 2007 8:02 am

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.

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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

William Thompson · Posted: Thu Apr 12, 2007 2:44 pm

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

dick scherrer · Posted: Thu Apr 12, 2007 6:16 pm

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.

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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

dick scherrer · Posted: Thu Apr 12, 2007 7:30 pm

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.

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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!

dick scherrer · Posted: Thu Apr 12, 2007 8:23 pm

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

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.

William Thompson · Posted: Thu Apr 12, 2007 8:26 pm

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?

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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

dick scherrer · Posted: Thu Apr 12, 2007 9:47 pm

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.

William Thompson · Posted: Thu Apr 12, 2007 10:26 pm

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?

William Thompson · Posted: Thu Apr 12, 2007 10:39 pm

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'.

dick scherrer · Posted: Thu Apr 12, 2007 11:39 pm

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

bharat_juneja · New User Joined: 21 Dec 2005 Posts: 20 Location: US

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 ...?

William Thompson · Posted: Fri Apr 13, 2007 3:07 am

dick scherrer · Posted: Fri Apr 13, 2007 3:33 am

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.

Phrzby Phil · Posted: Fri Apr 13, 2007 5:56 pm

Why isn't it spelled "nybble"?

dick scherrer · Posted: Fri Apr 13, 2007 6:10 pm

'Cause it isn't British . . . ?

Mickeydusaor · Posted: Fri Apr 13, 2007 8:29 pm

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

William Thompson · Posted: Fri Apr 13, 2007 8:37 pm

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

Mickeydusaor · Posted: Fri Apr 13, 2007 8:40 pm

Yes if there are moving the +ZZZ to the database field they are
causing there own problem.

dick scherrer · Posted: Fri Apr 13, 2007 8:43 pm

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