Joined: 31 May 2004 Posts: 391 Topics: 4 Location: Richfield, MN, USA
Posted: Thu Jul 24, 2008 3:38 pm Post subject:
NUMVAL (or NUMVAL-C) will not remove quotation marks from argument-1. See Language Reference Manual for valid formats of argument-1. I'm surprised ("12345678") gave you a good result. _________________ ....Terry
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
Posted: Fri Jul 25, 2008 1:41 pm Post subject:
I coded the example you provided, and it displayed the values as I would expect. I used the same compiler directives, and other compiler directives, and these all worked as expected. Is it possible that you're overlaying the value after you execute the COMPUTE with the NUMVAL? Maybe a group move or a REDEFINES?
Joined: 31 May 2004 Posts: 391 Topics: 4 Location: Richfield, MN, USA
Posted: Fri Jul 25, 2008 7:13 pm Post subject:
Since I don't have access to a mainframe to test it myself, my post was based on the contents of http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR10/7.1.32?DT=20020920180651 and it seemed to me that only spaces, decimal points, + or - signs, CR, DB, and numeric digits were the only characters allowed for argument-1. The manual fails to mention that single and double quotes are also allowed. _________________ ....Terry
The single quotes in COBOL represent a Literal Value. In other words, the quotes are not really part of the data, the quotes reflect that the values between the quotes represent an Alphanumeric Literal.
Regarding jsharon1248's response, No. I have no other processing or redefines that would cause an overlay. The code sample that I listed is actually in a COBOL CICS module. When testing, I used INTERTEST to step through each line of code, displaying the value of the target field. This similiar issue is happening with numeric amount fields that are over 8 digits in length.
When walking through the code, when I stop immediately after the execution of this statement:
COMPUTE WS-NUM-A = FUNCTION NUMVAL ("123456789")
The value of WS-NUM-A shows 6784000075. I can't explain it, and I've seen the NUMVAL work in other modules, but none of the modules that I investigated deal with data over 8 digits.
Does NUMVAL require specific RUNTIME libraries that may affect such processing.
Here's something interesting: I just tried taking the exact same load module and put it in a different CICS Region. In the new region, the NUMVAL worked fine with the exact same statement. Both CICS Regions are running the same release of CICS.
This seems like a run-time environmental issue. Has anyone seen anything like this or do you have any ideas where I can look next to determine what the problem is in my CICS Region?
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
Posted: Thu Jul 31, 2008 12:03 pm Post subject:
A couple points. First, I'm willing to bet that you're not showing us the actual code. Post the actual WS variable definitions and the actual procedure division statements. Second, it's not likely, but it's possible that Intertest is getting confused. Try writing the variables to a file or DB2 table and see if the correct values are written.
Here is the Intertest Display:
The breakpoint is AFTER the COMPUTE STMT. Note the value of the target field IMLPBOOK-ORIG-AMOUNT is 8400007549 and the Source field CUR-XML-TEXT is 123456789.
The issue is not due to an Intertest intermediate problem because the same results happen when Intertest is Turned OFF. The target field is subsequently written to a file. When the module is compiled Without Intertest, the same results occur.
My interim solution is to code my own numeric conversion routine which works fine as a band-aid. But I would really like to understand what the issue really is with the NUMVAL function.
As time permits, I will document the issue and send it to our systems programming team to review it. Several other developers in different departments have been experiencing similar concerns and have suggested avoiding the NUMVAL function. However, I'm sure there must be a rational explanation of this issue.
Thanks for your valuable time in following this Ridiculous thread.
I thank you for your thoughtful input, DICK. However, your manner and unprofessionalism (and ignorance for that matter) is uncalled-for and should have no place in a professional environment and especially on this board where most professionals come to seek qualified advice and direction.
As per your keen insight to this issue DICK, I just have a few comments that a rookie may pose to your professional commentary regarding this ridiculous issue.
First, DICK, you mention that the numeric variable has implied decimal positions. As far as I know, with my meekly limited experience in this field, the implied decimal should not cause the numeric translation to be so different as we have seen the result that I posted. At most the result would be off by two low-order zeros. Secondly, although I may not have posted it, this issue also exists when the numeric field is defined as a strictly USAGE IS DISPLAY field (i.e. PIC 9(10)). This is an important thing to note in this case, which proves that you may not be the all-knowing expert professional that you seem to present yourself to be.
So DICK, I'm not sure where your thought process was going when you mentioned the ridiculous post due to the implied decimal positions. I searched several IBM Manuals, and did not find any pre-conditions that specified that the result field must not contain an implied decimal point. On the contrary, I found that the IBM docs support implied decimals in the target field. So DICK, If you and your divine wisdom know of such specification, I would surely and humbly appreciate your infinite kindness of presenting such information.
According to the IBM Website, DICK, it seems that your mouth works faster than your enormous brain. You can see by researching "SE28757 - RUN-THREADS-INCORROUT NUMVAL NOT WORKING WITH DECIMAL POINT BUT DEPENDS ON LOCALE" that NUMVAL does actually work with decimal points. This comes from IBM, but maybe you know more than IBM, so they must obviously be mistaken.
I've posted the link to this article for you convenience:
By the way, in case you need to ask, I am working in an english Locale(EN_US) as the article states, the decimal will work.
Furthermore DICK, just to prove that your ignorance is only overshadowed by your obvious unprofessionalism and down right rudeness, you can read the Enterprise COBOL for z/OS manuals (if your brain can find the core memory to read!). If you have some time on your busy hands, maybe during a time when you aren't making such an [DONKEY] of yourself, you can read page 114 of the Enterprise COBOL for z/OS Programming Guide Version 4 Release 1. Here, IBM mentions not only that the result field CAN have implied decimals, but also be Signed. Here, I took the opportunity to include the example used on that page in case your too high on yourself to read the manual:
Code:
01 A Pic x(10).
01 B Pic S999V99.
. . .
Accept A from Console
Compute B = Function Numval(A)
Regarding your Second Point, DICK, about the field being 1000 bytes long. This also shows your uprofessional and uninformed and, quite frankly, asinine and dim-witted remarks have no place on this board and you should be banned from providing such ignorant remarks when you have no idea what your talking about.
Again with your Second Point, DICK, If you took time to learn just a little COBOL, you would probably have come across the Enterprise COBOL for z/OS Language Reference Version 4 Release 1. Here, IBM states that the NUMVAL function removes leading and trailing spaces from the argument before proceding with the numeric conversion. Therefore, regardless of how long the argument is, whether it's 10 bytes or 1000 bytes, the result is the data after removing the leading and trailing spaces. In the case that I posted the actual data is only 9 Numeric characters, which qualifies for the NUMVAL specification. Here is the excerpt from this manual for your review DICK:
"The function removes any leading or trailing spaces in the string to produce a numeric value."
For the quote above, I'm not even going to bother giving you the specific page number, DICK, because you are obviously too full of yourself to admit that your response was grossly inaccurate, unprofessional, immature, and simple-minded and lacking of any forethought in composing your tactless response which has no significance to the original substance and temperment of the question posed.
I personally feel that your inconsiderate response was thoughtless, rude, undiplomatic and offendlingly blunt and as I have shown you here, grossly inaccurate and incompetent. The forum moderators would be justified to ban you from participating in this professional environment since you have shown yourself to be lacking of qualification and mentally deficient in your brash behavior and curt and unjustified remarks.
I know that I may have used some big words in this reply. Feel free to use a dictionary if you need to DICK!
For all the others who would, with good intentions, read this thread, I appologize for my bluntness in responding to this Dicks contribution to this thread. My intentions in starting this thread are purely professional and thought-provoking and above all, well meant.
Getting back to the real issue: I have investigated several IBM Manuals and Website articles regarding the use of NUMVAL and I have not seen the specific issue presented. It may be possible, as Nic Clouston suggests, that there may be an issue sysprogs. As time permits, I will document this specific issue and contact my systems support group. Also as an FYI, I am not the only developer in my company to have this issue. Many developers have seen this issue and have opted to develop a work-around for numeric conversion functionality.
Joined: 20 Oct 2006 Posts: 1411 Topics: 26 Location: germany
Posted: Tue Sep 02, 2008 5:58 am Post subject:
Santlou,
your source field for the NUMVAL function is 1000 bytes.
That means the function will go thru the complete 1000 bytes looking for numerics and '.' .
Then intermediate results (usable chars from the 1000 byte field) are justified in the receiving field according to the pic clause.
If you were to investigate the complete 1000 char of the source field,
instead of the abbreviated display that you have provided,
you could see why your receiving field was populated as it was.
If you only want to convert the first 9 char of your 1000 bytes field, use reference modification.
by the way, this post is for consumption by others. I don't really care what you do. It is your problem, not mine. _________________ Dick Brenholtz
American living in Varel, Germany
Thank you for your relatively professional yet still sarcastic response. For the sake of technical experience and presentation for the members of the group that would like to follow this issue, I've presented some additional information here.
I would understand your implication regarding the source field size of 1000 bytes. But if I understand what you're implying in your latest response, you're saying that there must be other 'non-space' characters in the source field, I would have to disagree. If this is the case, we would see the same results if with other values in the 1000 byte sending field. In addition, I've also used reference modification to specify the first 9 bytes of the source field, but the results are still inaccurate. Also note that the source field in this case can contain from 1 to 15 numeric digits. As an FYI, the reason that the original post showed the source field defined with 1000 bytes is that the field is actually a result of an XML Parse function and the source field actually supports a variety of data elements that would be parsed from XML. However, this should have no significance to this discussion as the issue described pertains specifically to the NUMVAL function.
I can prove this by sending only 8 numeric digits in the source field in the same manner that I sent 9 digits. When sending 8 significant numeric digits in the 1000 byte source field, the results are accurate. In addition, I have tried this same iteration of NUMVAL by hard-coding a 9-digit literal, which resulted in inaccurate results.
Below I've included additional excerpts from Intertest displays showing the results of various tests.
I've defined the result field for this test as listed below. Note for this test I did not specify any implied decimals or sign. This is strictly to address questions listed in prior responses in this thread. So here we have a simple numeric field definition:
Code:
05 WS-AMOUNT-TEMP PIC 9(15).
The screen shot below shows a breakpoint just before a COMPUTE statement where I am using NUMVAL to convert an 8-character field containing only numeric digits. For this test, I am using a hardcoded literal for all these tests in order to show you that the 1000 byte field has no significance in the result since it also happens with the hardcoded literals. Note the target field contains spaces in this screen shot showing the BEFORE image.
The screen shot below shows the result AFTER the COMPUTE using the NUMVAL function with an 8-character field containing only numeric digits. Here the result is accurate as expected.
This next screen shot below shows the effect of adding leading and trailing spaces to the source literal, but still specifying only 8 numeric digits. Here the result is still accurate as expected the target field represents the numeric value as converted properly by NUMVAL.
Now the next screen shot shows the issue. Here the hardcoded literal contains only 9 valid numeric digits with no spaces.
However, the result shows an obvious inaccurate value. This COMPUTE statement is exactly the same as the first one that I listed here, except that the source field contains a 9-character literal.
Below, is a screen shot showing the full value of the result field. Note the value of this numeric field is 56784000074, but I expected it to be 123456789.
Code:
CA-InterTest for CICS r7 - MAIN STORAGE UTILITY - Termid = 5AAA
Starting at Address =3ED191C7 Hexadecimal Character
02 WS-AMOUNT-TEMP | F0F0F0F0 F5F6F7F8 F4F0F0F0 | 000056784000
| F0F7F4 | 074
Now the next screen shot shows the same issue using hardcoded literal containing 9 valid numeric digits with leading and trailing spaces. The result still shows an obvious inaccurate value. This COMPUTE statement is exactly the same as the one that I listed above, except that the source field contains a 9-character literal with leading and trailing spaces.
These screen shots show the issue that we are encountering with the NUMVAL function. At first I did consider the fact that it may be an INTERTEST problem, but once the module was compiled without intertest the same results occured. However, I do believe that the issue is related something in CICS and not something specific to COBOL. When I setup the same tests in a Batch module, everything works fine in all cases. So it is probably related to the CICS environment. According to our CICS support group, the CICS region contains all appropriate runtime libraries in the RPL. However, as I mentioned earlier, as time permits, I will document this issue and forward it to our MVS Support team. I will post the results when available.
By the way DICK, I understand that this is not your problem, but I thank you for your concern and your characteristically unprofessional and sarcastic response in saying that this is my problem not yours. If you were a real professional, you should have applogized for your foolishness and sarcastic and dim-witted comments that you posted in your original reply. As a technical professional I'm appalled and disgusted with your behavior, but I guess we all must deal with nut-jobs like you.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
