Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
Hi,
At our CICS shop, for one of the input field on CICS screen - we are getting junk or invalid characters. This is causing the junk characters getting transferred to target database and further onto all related files.
If i want to stop the user from entering the junk characters on screen, what are the ways to do so ?
Note - The field is ALPHANUMERIC / X(40) general comment field.
Can we put a logic in code to validate that field character by charcter for not JUNKS ?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Well, you'll have to define what "JUNKS" means to your application.
You may want to wonder how a user can enter "junk", since they only have a keyboard. Everything they can type from there is perfectly ordinary non-junk stuff.
Rohan, Do you mean junk as a special characters apart from A-Z or 0-9 (btw they are no junk though)? if so then look at the below few links ( which you could have googled it as well) that would help.
Joined: 19 Mar 2009 Posts: 206 Location: Globe, India
ha ha..
Thanks guys.. junk means definitely non readable invalid characters apart from special characters and regular alphabets and numerics.
I also wonder how junks can be entered in CICS screen..
I see table is getting these junk data from one of the program related to CICS screen and still investigating if there is any issue in between data passed through COMMAREA or somewhere else.
I could see such junks getting transmitted for only one particular user of the application so thinking of all possiblities on what special things he would have done
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Well, the corruption is being done by the program (somehow). That particular user is doing something different, using the system differently, and that happens to give you the problem.
Depending on complexity (of task) and availability (of user) finding out what they do differently may help you find the problem.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Guys, a little thought here.
You have a CICS or IMS/DC data-entry screen. Go to one of those. Locate a transaction which has numeric fields. Try typing your name into that field. Didn't work?
Go to a "text" field. Try getting non-keyboard characters into that, whilst sitting at the terminal. Any luck?
If "junk", as in non-display characters, is getting into a field, there is program problem. Perhaps a subtle difference between what fields are displayed for input, and what are received for input. Perhaps something worse. But it is a programming problem.
If there is a mix of non-junk/junk, then what is the mix? Junk at the end of the field, at the beginning, scattered in a pattern throughout, scattered randomly throughout? What? (those are in order of my estimation of likelihood).
How is initialising a field going to help? It receives data, splattering whatever was there before, whether initlialised or not.
You have a program problem, not a keyboard problem, not a user problem. A program problem. You need to identify what the problem is before you try to fix it. If you start just throwing fixes, you may cover a symptom and not get the problem, until it bites you later.
Don't go validating billions of characters just for the heck of it. Non-text is appearing where it shouldn't, and it is not coming from the "screen".
One thing you can do is: sit two users side-by-side; one is the one who gets the problem; the other is another user who uses the same transaction; get the first user to do their work; watch the face of the other user - when they look surprised, you're starting to home in on it.
Otherwise or at the same time, look at the data which is affected, look at data which is not affected. Look at the program. Look at the data. Look at the program. Look at the data. Look for patterns, repeats, anything recognisable (things which may be packed numbers, things which may be binary counts, things which are a bit of text which is a recognisable indicator of something in the system).
Come up ONLY WITH PLAUSABLE possibilities. They must fit all the known facts, or must explain how something has changed to become the known fact.
Do not, do not, do not, just bang changes into the program which you cannot directly and consciously link to the problem.
If you add diagnostics of some type, be careful to check that the results don't change just from adding that code.
Also, how long has this been happening? When was the program last changed? When did that user start working on the project?
If you are going to change something, ask yourself "how will this affect the problem"? If you can't get a direct answer for that, you are pushing water uphill, and maybe washing away something useful at the same time.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Code:
03 WS-XLATE-TBL-REC.
05 WS-XLATE-TBL OCCURS 256 TIMES
INDEXED BY X-WS-XT, X-WS-XT-MAX
PIC X(001).
03 WS-WORK-AREA PIC X(079).
03 WS-BYTE PIC X(001).
03 WS-SUB PIC 9(008) BINARY.
03 WS-SUB-X REDEFINES WS-SUB
PIC X(004).
03 WS-FWORD PIC 9(008) BINARY.
03 WS-FWORD-X REDEFINES WS-FWORD
PIC X(004).
03 WS-INDEX PIC 9(008) BINARY.
03 WS-INDEX-X REDEFINES WS-INDEX
PIC X(004).
*
**** BUILD 'WS-XLATE-TBL' WITH CHARACTERS X'00' THRU X'FF'
*
COMPUTE WS-FWORD = (LENGTH OF WS-XLATE-TBL-REC /
LENGTH OF WS-XLATE-TBL (1)).
SET X-WS-XT-MAX TO WS-FWORD.
SET X-WS-XT TO 1.
*
PERFORM UNTIL X-WS-XT > X-WS-XT-MAX
SET WS-SUB TO X-WS-XT
SUBTRACT 1 FROM WS-SUB
MOVE WS-SUB-X (4:) TO WS-XLATE-TBL (X-WS-XT)
SET X-WS-XT UP BY 1
END-PERFORM.
Now, you've built a TRANSLATE-TABLE, but it needs further scrutiny. Get out your YELLOW-CARD and determine what bytes of the TRANSLATE-TABLE are legitimate and what aren't. For example, a '%' might be considered "JUNK". So, clear WS-SUB to ZERO, move '%' to WS-SUB-X (4:), set X-WS-XT to WS-SUB and move X'FF' (or whatever you desire), to WS-XLATE-TABLE (X-WS-XT + 1).
Then, issue an in-line PERFORM targeting the desired map-field. During the perform, if the 'n'th byte of the map-field is found to equal X'FF', then the field needs to be fixed and send a message to the operator, indicating the byte-position found in WS-SUB of the map-field contains an unacceptable character.
This should give you a better idea and get you on your way.
Good luck, we're all counting on you....
Code:
MOVE WS-MAP-FIELD (1:) TO WS-WORK-AREA (1:).
MOVE 1 TO WS-FWORD.
MOVE ZERO TO TALLY.
*
PERFORM UNTIL WS-FWORD > LENGTH OF WS-MAP-FIELD
MOVE WS-FWORD TO WS-SUB
MOVE WS-WORK-AREA (WS-SUB:1)
TO WS-BYTE
MOVE ZERO TO WS-INDEX
MOVE WS-BYTE TO WS-INDEX-X (4:)
SET X-WS-XT TO WS-INDEX
IF WS-BYTE NOT = WS-XLTE-TBL (X-WS-XT + 1)
MOVE LENGTH OF WS-MAP-FIELD
TO WS-FWORD
MOVE WS-SUB TO TALLY
END-IF
ADD 1 TO WS-FWORD
END-PERFORM.
If after the PERFORM, the TALLY Special-Register is non-zero, then this represents the MAP-FIELD position which contains invalid data.
Bill O'Boyle, Exactly I supplied these links earlier but TS says the bad data is out of what Mickeydusaor and Me suggested.
Bill, I meant if he has some junk in the database then that could be by because of . 1. Bad data from the screen itself 2. correct data from the screen but somehow in the program the data gets changed to bad data and for such change, one of the reason could be of NOT initialization.
However, I concur with all of your explaination to basically put a pause at the source of the data itself before even it gets processed.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Rohit,
I look at it this way. We are all colleagues on this forum and we help others when we can. Sometimes it's a struggle, whereas other times, the response from the poster (if sent) is the ever popular venacular "Oh Sh*t".
I've learned a lot from others and I hope some of my "Geekiness" has been worthwhile.
I've learned a lot from others and I hope some of my "Geekiness" has been worthwhile
Of course very much, because whatever I could be able to do today ( I'm sure other(s) too like me) has most of the contribution from this forum and eventually it will drill down to you (*ALL) experts.