|
View previous topic :: View next topic
|
| Author |
Message |
arvind.m
Active User
Joined: 28 Aug 2008
Posts: 205
Location: Hyderabad
|
|
|
|
Hi all,
i need to convert 9(09).99 to S9(09)V99 COMP-3. how can i convert an edited format to a packed decimal.
thanks, |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
MOVE? COMPUTE? ADD?
Why are you not reading the manual to find the answer to this question -- the manuals link at the top of the page has the COBOL Language Reference and Programming Guide available. |
|
| Back to top |
|
|
arvind.m
Active User
Joined: 28 Aug 2008
Posts: 205
Location: Hyderabad
|
|
|
|
Hi Robert,
i used NUMVAL and it work good. but i need some info about
| Quote: |
automatic "de-editing" in COBOL
|
Thanks, |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Chapter 6.2.24.1.1 of the COBOL Language Reference talks about elementary moves -- if you have specific questions, either test some code or post a question. Broadly speaking, COBOL for the most part will figure out the numeric value and move it to the numeric variable. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
Hi Arvind,
If you're sure of the content (format) of the sending edited field just MOVE it to the packed field. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| automatic "de-editing" in COBOL |
| Quote: |
| If you're sure of the content (format) of the sending edited field |
And there is the biggest pitfall. . . (IMHO)
While a simply MOVE or NUMVAL(-C) make for some very easy coding, they all "blow up" when the content is not perfect. . . Which has caused many an abend in running production code.
People who have very little or "bad" experience (improperly trained and managed) drop in the simple code and then cannot imagine how they got an 0c7 in production and have no idea how to isolate the problem once the production job abends.
Unless i didn't get the memo, there is no simple way to ensure that the "edited" sending" field is valid. . . |
|
| Back to top |
|
|
arvind.m
Active User
Joined: 28 Aug 2008
Posts: 205
Location: Hyderabad
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Unless i didn't get the memo, there is no simple way to ensure that the "edited" sending" field is valid. . . |
Dick, you're missing the obvious ... if the program gets a S0C7 abend, then the data was bad. Kind of negative proof, but still pretty simple.
Of course, I tell my programmers that the S0C7 is the one abend that is completely programmer caused (they don't necessarily believe me, but I do tell them that). |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Robert,
| Quote: |
| if the program gets a S0C7 abend, then the data was bad. |
My point exactly. . . And the 0c7 is a bit late. . .
There are now several ways to "shoot off your foot" with the "improved" moves and functions because the same moves/functions do not provide a way to detect bad data, set a testable indicator, and prevent the abend.
Most of the inexperienced people i see who discover these "easier" instructions do all of their testing with valid data. When i have them change the data to include some invalid values, they nearly panic when the job abends (and this is still in test) - what to do to prevent this?
If some input comes with no manual changes from some other computer system (not some spreadsheet or keyed entries from a form), there may be reason to "trust" the data. Any "raw" input must be validated first (IMHO). |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| When i have them change the data to include some invalid values, they nearly panic when the job abends (and this is still in test) - what to do to prevent this? |
I have so much fun when assigned to testing -- it is a rare program I can't "break" (abend or process incorrectly) within 2 or 3 runs of data, whether or not I know anything about the program code. Programmers expect their data to be just so, and their code generally doesn't properly handle all the error conditions (not to mention boundary conditions). |
|
| Back to top |
|
|
|
|
