You are either not following the code I suggested or are not telling us everything we need to know about your code. I compiled and executed the following program:
CLASS WS-VALID-CUSIP IS
'@' '#' '*'
'A' THRU 'I'
'J' THRU 'R'
'S' THRU 'Z'
'0' THRU '9'.
01 WS-CUSIP PIC X(8).
MOVE 'ABJKST01' TO WS-CUSIP
MOVE 'CDLMUV23' TO WS-CUSIP
MOVE 'EFNOWX45' TO WS-CUSIP
MOVE 'GHPQYZ67' TO WS-CUSIP
MOVE 'IJRSAB89' TO WS-CUSIP
MOVE 'KLTUCD@#' TO WS-CUSIP
MOVE 'MNVWEF#*' TO WS-CUSIP
MOVE '@#*@#*@#' TO WS-CUSIP
MOVE 'IM SPACE' TO WS-CUSIP
MOVE 'PERCENT%' TO WS-CUSIP
IF WS-CUSIP IS NOT WS-VALID-CUSIP
DISPLAY 'WS-CUSIP >' WS-CUSIP '< IS NOT VALID.'
DISPLAY 'WS-CUSIP >' WS-CUSIP '< IS VALID.'
and the SYSOUT from execution was:
WS-CUSIP >ABJKST01< IS VALID.
WS-CUSIP >CDLMUV23< IS VALID.
WS-CUSIP >EFNOWX45< IS VALID.
WS-CUSIP >GHPQYZ67< IS VALID.
WS-CUSIP >IJRSAB89< IS VALID.
WS-CUSIP >KLTUCD@#< IS VALID.
WS-CUSIP >MNVWEF#*< IS VALID.
WS-CUSIP >@#*@#*@#< IS VALID.
WS-CUSIP >IM SPACE< IS NOT VALID.
WS-CUSIP >PERCENT%< IS NOT VALID.
As you can see, the code I suggested works perfectly.
Joined: 20 Oct 2006 Posts: 6970 Location: porcelain throne
you were asked to perform a simple coding change and paste the result.
all you give us is
@Ronald... I checked this number of times...
There have been other threads over the last couple of days that have alluded to the 'heavy handed' way in which we respond.
Most of the members who make suggestions and request info,
do it for a reason:
They are experienced professionals
who realize that lack of precision is the reason for most errors
and know that if something is not working properly
it is due to the rooky's lack of attention to detail
we are receiving nothing from you except your opinion and observations
which if were worth anything
you would not have posted such a beginners problem in this forum.
if you would bother to following suggested instructions
you may eventually solve your problem.
most of the senior members have learned
how to use instructions based on trial and error
until they managed to find the answer.
When we were learning, there was no internet.
Our seniors would be angry that we would not bother to figure things out on our own.
You coded something up, ran it and said:
oooww, iiiiitttt doosssssent work!
and when someone, attempting to help you, suggests something,
you ignore the request and again say,
ooowwwww, poooorrrr meeee, iiitt dooosssent work
something is wrong with the compiler.
either figure it out on your own,
or do exactly what people ask.
they are trying to discover what stupid, rookie thing you are doing
so that you will see your error or we can and then provide you with some eduction.
Joined: 06 Jun 2008 Posts: 8567 Location: Dubuque, Iowa, USA
maybe something is wrong with our operating system,
sure could not be me....
I lost count (it was well over 100 at that time) quite a few years ago of how many times programmers told me the system wasn't working right because their program just had to be running correctly. The tally so far: system 2, programmers N-2. Both issues were very specific and had fixes provided by IBM after we opened the PMR on them. I don't think we're going to find the third occurrence in this thread, either. In other words, Deepak, the odds are well over 100 to 1 that the problem is with your code, not the system.
In over 40 YEARS of mainframe programming, I have personally encountered TWO (count 'em, 2) problems that were directly related to SYSTEM software.
The first was a very specific COBOL program that, when compiled and executed (on an IBM 360 mod 30, if I remember correctly), sucked the internal reader dry - meaning that every job in the queue "disappeared". My job was cancelled - and upon resubmission, did the same exact thing. At a loss, we re-arranged several of the elements in Working-Storage, and swapped the location of a couple of PERFORMED Paragraphs and voila! the program worked just fine. We chalked the problem up to a one-in-a-million page boundary problem of some sort. Never saw anything like it again.
The second problem was an IBM VS-COBOL subroutine that was called to handle the multiplication of two large numbers. It didn't calculate the result correctly. I dissassembled the subroutine, found the error, fixed it (in my private library), and re-ran with a STEPLIB and it worked fine. I notified IBM of the problem (and the fix), and they did eventually sent out a PTF (about 3-months later).
So far, SYSTEM: 2, RON: N-2. Sounds like an echo in here, in here.
Joined: 09 Mar 2011 Posts: 7312 Location: Inside the Matrix
What concerns me is what the guy is up to with his validation.
SEDOL (Stock Exchange Daily Official List) Number is a number provided by the London Stock Exchange for stocks of various types which come under their listing control. CUSIP (never knew what it meant) is something similar for the US
So, SEDOL and CUSIP are reference data. The LSE, and whoever in the US, provide filess (or data, these days, I suppose) for you, with the numbers on, names of the stock, issuer, details, blah, blah. The files used to be on tape (we took the LSE, and they kindly included CUSIP automatically where necessary).
So, what is he up to? Is he working on some trade input system, where he is going to validate those references, so he can send a message back to the data enterer (too late at night to think of a proper word) saying that it is invalid - and then, if valid, access a database to see if the record is there?
What he hasn't told you is that not every character is valid in every position. Or that they use check digits (different systems as well, I see from google).
I'm sorry not to have noticed earlier, but because he stuck it on the end of an old thread and I looked at the thread without looking at the dates, I ignored it (I've never used anything fancy from SPECIAL-NAMES) until I saw the post-count going up like a fast-moving-post-count.