IBM Mainframe Forum

hi
i found a question that using accept statement to accept 2 numeric item,and compute the sum of them(see attachment pic)
why i enter 25,25,it interprets to 25000,25000. if it is string ,it should add the space.
why this happens and how to solve it ,thanks a lot!

Your potential to actually use the ACCEPT in a mainframe environment is small.

Check and understand what it says in the manual.

Avoid words like "TOTAL" which might mean something to the compiler.

To be a little more helpful, you'll need to look in two places in the manual. Firstly at the ACCEPT statement. Secondly at unisigned numbers (start with USAGE). Thirdly, the list of "reserved words", so you see one reason why we always put hyphens into things and not just pick "obvious" words. OK, that was three places in the manual.

For the USAGE thing, look at your DISPLAY output in HEX and ask "what on Earth is that?" You want to "see" it happening, run your compile again, but with the option for the generated assembler listing. OK, four places in the manual.

if it is string ,it should add the space.

Your statement here is categorically WRONG. COBOL should not do anything -- COBOL does what it does, period. If you think COBOL should do something, you need to learn COBOL since you know nothing about it. Furthermore, COBOL does not have strings like some other computer languages -- COBOL has variables.

Did you test your program by entering <space><space><space>25 for the two values? If so, what was the result? If not, try it.

i test the <space><space><space>25,and 00025,the result is ok .
i am a beginer of cobol(also beginner in programming),and i also learning java now ,so i was just try to practice cobol basic statement and syntax like i do in java.
Mr.Robert, you said " COBOL should not do anything -- COBOL does what it does", i am not quite sure about it ,can you explain it , what are the cobol's strength,and things most suitable for cobol to do . thanks a lot!

When you say "it <COBOL> should add the space", you completely and totally misunderstand the system. COBOL should not do anything -- ever. It is a well-defined language which works as specified in the Language Reference and Programming Guide manuals which are in turn based upon the international standards committee for COBOL. Saying COBOL should do something is (1) putting YOUR expectations on the language which is not appropriate, and (2) showing that you have not read the manuals to find out what COBOL will (not should) do in any given case. There are places where the manual is not clear about something, but for the most part if you want to know how COBOL handles things, look it up in the manual.

COBOL strengths are in manipulating data and generating reports. You have complete control of every byte of the output line and with such facilities as OCCURS, REDEFINES, and RENAMES (not to mention COMP, COMP-1, COMP-2, COMP-3, COMP-4, COMP-5, DISPLAY, DBCS, and NATIONAL variables) there's a lot of flexibility in writing code. COBOL does not have strings like other languages as every variable has its maximum length defined at compile time, and that maximum length won't change while the program is running.

When you provide input into your ACCEPT statement, since the variable is defined as 5 bytes there will be 5 bytes provided -- always (as I said, COBOL has no strings). Since you first gave 25, the final three bytes of the variable are filled with spaces. In doing the internal arithmetic, COBOL converts the space (hex '40') to a zero (hex 'F0') and that's why your 25 became 25000.

thank you!

Robert Sample wrote:Since you first gave 25, the final three bytes of the variable are filled with spaces.

Uderlying the original question was "way is my numeric field left-justified and spaced-padded not right-justified and zero filled"?

Robert Sample wrote:In doing the internal arithmetic, COBOL converts the space (hex '40') to a zero (hex 'F0') and that's why your 25 became 25000.

How and why? Because COBOL doesn't do that.

For instance, Pumpkin, try your program again with the numeric fields (I'm not going to mind about anyone calling them variables, apart from potential confusion with languages that have strings) defined as PIC S9(5). Tell us what happens. Hint, the answer is S0C7.

This is not a side-effect of ACCEPT. This is how COBOL works day-in-day-out. Anyone can try it. Define a "PIC X(5) VALUE "25"". Move that to a "PIC 9(5)" and a "PIC S9(5)". Display both the numeric items. Do some arithmetic with the first item (as in "elementary item" or "data item", we still have lots of words and phrases) (like add zero to it) and display the result. Now try with the second item. Poof. You can code the display of the result if you like, it won't get there.

BillyBoyo wrote:
...way is my numeric field left-justified...

Sorry about that, typo. Sounds like a line from some new Hippy religion. Should have been "why".

The effect referred to above is modified by a compiler option Robert and I previously discussed. With that compiler option set, even the "PIC 9(5)" will go BANG! S0C7.

When you use fields which are numeric but USAGE IS DISPLAY (which is the default if you specificy no USAGE) Cobol will always convert them to packed intermediate values for calculations of any sort. You field contained F2F5404040 because of the way ACCEPT works. ACCEPT is not really thinking that you will put a numeric field as the receiving item. It is syntactically valid to do so, but ACCEPT will treat it as alphanumeric (ie, PIC X(whatever)). Note that there is nothing particular to see in hex, because the field was not treated as a numeric item. If you want to see the effect I was expecting (and you won't even need the hex display) move a PIC X(5) VALUE "25" to your NUM1 and display NUM1.

You usage is DISPLAY-item looks like this in half-byte pairs "ZNZNZNZNSN". The "N" parts are what goes to make up the number when Cobol "packs" the USAGE DISPLAY field. The "S" makes the sign. The "Z"s (zone) are discarded, giving you a packed field of NNNNNS. Because your field is defined as unsigned, Cobol will generate code to ensure that is "stays" unsigned, it will make the sign "F". You "sign" was actually 4 (from the 40 code for space). But, you never got to use it because Cobol clobbered it to make it an "F". If you put a sign on your field definition (PIC S9(5)) Cobol will not clobber the sign, the 4 will appear in the "sign" part of the packed number Cobol generates for the calculation and the result will be S0C7.

What this all means is that you have to be careful. You can actually have any old rubbish in the "zone" part of a number. Yes, the number parts and the sign have to be valid, but the zone part can be drivel and your program still "work" ie, not produce an S0C7.

If you do a test for NUMERIC, any rubbish in the zone areas will be spotted and the field will fail the test.

Whenever data comes into your system via data entry - validate it. See what happens with your program, unchanged, but you enter groups of 1 to 5 letters. Or just press ENTER with no input.

If you want a little exercise, try to work out how to make your existing program, unchanged, un-recompiled, get an S0C7 and tell us why.