Is there a universal standard in any way on how PC COBOL compilers handle normally mainframe style data types (COMP-3, COMP, and Zoned Decimal)? What is that? How would they handle each of them? Similarly or differently to what a mainframe compiler would do?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PC COBOL Standards 1
- Thread starter Glenn9999
- Start date
Before launching into an extended thread on this topic, could you tell us the motivation for the question? That might better focus the answers.
Tom Morrison
Tom Morrison
- Thread starter
- #3
For learning's sake, I'm trying to apply being able to write a program in another language to be able to handle some of the COBOL data types that these compilers might produce (especially that are necessarily non-standard on the PC side). I'm especially wanting to know too if and where there might be a divergence from what I know to be the case on the mainframe COBOL stuff.
There is no 'universal standard' regarding the data types that fall outside the scope of the ANSI/ISO COBOL standards. However, I think you will find the various data representations well documented in the various vendors' manuals. COMP-3 probably has broad agreement among the vendors, while COMP is probably the least amount of agreement.
Having said that, what problem are you trying to solve? Interlanguage calling, or sharing of data (as recorded in files)? If the latter, the COBOL standard specifically requires USAGE DISPLAY for interoperability.
I don't think I am being too helpful yet...keep asking questions.
Tom Morrison
Having said that, what problem are you trying to solve? Interlanguage calling, or sharing of data (as recorded in files)? If the latter, the COBOL standard specifically requires USAGE DISPLAY for interoperability.
I don't think I am being too helpful yet...keep asking questions.
Tom Morrison
- Thread starter
- #5
Basically, the first item, the ability to take something that's non-standard for the PC (but standard for COBOL) and be able to read it correctly, convert it correctly, etc.
I've gone ahead and written this for COMP-3 since what I got out of the PC COBOL (Fujitsu 3.0) was identical to what I expected from the mainframe. But I've gone on to other types and noticed what I got to be different, so I wasn't so sure about it - so I thought I'd ask.
Well, the mainframe is big-endian, while many PC architectures are little-endian. This can affect binary representations, but I think that most PC COBOL vendors also have a canonical, big-endian binary representation.
The other issue is the matter of representing the sign in combined and noncombined modes, including packed decimal. The is some history behind the PC COBOLs that did not follow the IBM sign convention, so do a bit of study on that. One thing that works reasonably well is, "That which is not negative is positive." This rule allows for variations in the representation of the positive sign without affecting conversion results.
So, how are you handling implicit information/metadata such as scale factor (implied decimal)?
Tom Morrison
The other issue is the matter of representing the sign in combined and noncombined modes, including packed decimal. The is some history behind the PC COBOLs that did not follow the IBM sign convention, so do a bit of study on that. One thing that works reasonably well is, "That which is not negative is positive." This rule allows for variations in the representation of the positive sign without affecting conversion results.
So, how are you handling implicit information/metadata such as scale factor (implied decimal)?
Tom Morrison
- Thread starter
- #7
That's what I'm noticing (and would expect). A COMP value is going to be big-endian while a COMP-5 is little-endian like the PC side of things.
Which is my primary issue right now. What I notice on one of the types seems inconsistent with what I'm used to seeing. So I'm wondering if that's consistent with all PC COBOLs or just for this one. So I wonder whether there is a standard and what it is so I can match it up with what I'm seeing. Really, determining sign is probably the biggest thing for making the numeric conversions work. But obviously, for things like DISPLAY types, what you're going to see is going to be much different in PC COBOL simply because of the ASCII/EBCDIC differences. Which comes down to coming up with a negative / positive test.
I haven't gotten to that one yet, but if I were expecting full interoperability on a fixed point integer basis, I would probably have to pass the number of decimal places in the COBOL file to get that done. But for what I'm doing (operating on the same field), I would expect COBOL to handle the proper decimal spacings for me - that if I passed the values to my program and I converted them and did the calculation using innate PC types and then converted and returned the results, the COBOL program could use the same type it passed to me and would be fine.
fredericofonseca
IS-IT--Management
Incorrect. COMP-5 is native format. so if you have a file created on a mainframe with any comp05 fields they will be big-endian, and if the file is created on an PC it will be little-endian.
Regards
Frederico Fonseca
SysSoft Integrated Ltd
- Thread starter
- #9
Correct in the general scheme of things, but on the PC COBOL side of things (and in the sense of what I was repsonding to), COMP-5 is the only way you can get a native binary format within the COBOL compiler. So the statement in the context it was made (see what I quoted) was correct.
The answer is no. Might have better luck with Fortran for Mainframe to PC Conversion. How Comp works is both machine and compiler specific. There may be some compiler options on some compilers to control how COMP ? Works.
If you do not like my post feel free to point out your opinion or my errors.
If you do not like my post feel free to point out your opinion or my errors.
- Thread starter
- #11
Just to try to bring this back to what I was looking for. I don't necessarily care how a PC COBOL is going to manipulate the data, I just care about the formats and how they are different so I can read them correctly in a totally different language that may or may not support.
For example, on Fujitsu, I notice that for a display value, it uses the ASCII equivalents for numbers, then for sign, it uses 3 (F/nosign), 4(C/+), or 5(D/-) in the high order.
Or COMP - I notice in Fujitsu COBOL that it is a big-endian binary representation. Basically swap the bytes and you got COMP-5, standard (for PC) little-endian notation.
Or COMP-3. I notice that Fujitsu COBOL represents that exactly as I know it on the mainframe. A number of digits encoded into the bytes, then C, D, or F.
I'm basically asking if what I'm noticing in Fujitsu COBOL is consistent across all PC compilers (like Microfocus) or does it vary and how it varies.
For example, on Fujitsu, I notice that for a display value, it uses the ASCII equivalents for numbers, then for sign, it uses 3 (F/nosign), 4(C/+), or 5(D/-) in the high order.
Or COMP - I notice in Fujitsu COBOL that it is a big-endian binary representation. Basically swap the bytes and you got COMP-5, standard (for PC) little-endian notation.
Or COMP-3. I notice that Fujitsu COBOL represents that exactly as I know it on the mainframe. A number of digits encoded into the bytes, then C, D, or F.
I'm basically asking if what I'm noticing in Fujitsu COBOL is consistent across all PC compilers (like Microfocus) or does it vary and how it varies.
Working with "mainframe type data items" on a PC raises MANY quesitons.
First, what type of mainframe? (My guess is that the person is assuming that all "mainframes" work like IBM MVS, OS/390, and zOS computers - but I could be mistaken on this assumption). That is NOT true.
Second, if comparing "mainframes" to PC's the first issue is EBCDIC vs ASCII for PIC X.
The next qustion is how are signs handled for DISPLAY numeric items (without SIGN IS SEPARATE).
Then, of course, if you are an international programmer, you can ask what PIC N means.
FINALLY, you can ask about non-Standard items like COMP-whatever, Usage POINTER, etc.
***
almost all COBOL pc compilers that I know of, have some documentation on how THEY handle these issues. Read YOUR documentation and then figure things out from there.
Bill Klein
First, what type of mainframe? (My guess is that the person is assuming that all "mainframes" work like IBM MVS, OS/390, and zOS computers - but I could be mistaken on this assumption). That is NOT true.
Second, if comparing "mainframes" to PC's the first issue is EBCDIC vs ASCII for PIC X.
The next qustion is how are signs handled for DISPLAY numeric items (without SIGN IS SEPARATE).
Then, of course, if you are an international programmer, you can ask what PIC N means.
FINALLY, you can ask about non-Standard items like COMP-whatever, Usage POINTER, etc.
***
almost all COBOL pc compilers that I know of, have some documentation on how THEY handle these issues. Read YOUR documentation and then figure things out from there.
Bill Klein
Here is some Micro Focus documentation.
Look here for RM/COBOL, in Appendix C.
Look in the Net COBOL LRM for Fujitsu, described in the Data Division, USAGE clause (approximately page 222).
AcuCOBOL seems to require registration.
Tom Morrison
Look here for RM/COBOL, in Appendix C.
Look in the Net COBOL LRM for Fujitsu, described in the Data Division, USAGE clause (approximately page 222).
AcuCOBOL seems to require registration.
Tom Morrison
Truusvlugindewind
Programmer
All true, but back to the basic question of the topicstarter:
On a mainframe packed-decimal is ideal for storing and calculating, because the 390 processor has instructions to calculate with packed-fields.
Other chips, like those found in unix and P.C.'s do not have these instructions. So calculatin with packed fields does not generate the most efficient code.
Bottom line:
- use packed field to store data in files and databases.
- use comp-5 to calculate.
Your program will generate the optimal code on all platforms and your data can always be exchanged and/or translated to other code-systems without having to worry about endian dependencies.
On a mainframe packed-decimal is ideal for storing and calculating, because the 390 processor has instructions to calculate with packed-fields.
Other chips, like those found in unix and P.C.'s do not have these instructions. So calculatin with packed fields does not generate the most efficient code.
Bottom line:
- use packed field to store data in files and databases.
- use comp-5 to calculate.
Your program will generate the optimal code on all platforms and your data can always be exchanged and/or translated to other code-systems without having to worry about endian dependencies.
-
1
- #15
) about efficiency on IBM mainframes, there are performance manuals which should be read.One reason for mentioning effeciency on the mainframe is that IBM invented COMP-3 (PACKED-DECIMAL) just for COBOL. When they designed the 370 computers, they added an instruction (Shift and Round Packed) just to make the ROUNDED option in COBOL more effecient.
Truusvlugindewind
Programmer
Crox. Nice to see you back on this forum.
As always: you're right! (a start from me to Crox). I was trying to give a "rule of a thump" -ish advice.
When you code COBOL as mentioned by me above, it performs almost perfect on both BIG-IRON 370 machines and on dinky-toy i386 thingies.
Next step could be optimizing to your CPU/compiler infrastructure. There should be on-and-a-halve-nanosecond out there to be gained....
As always: you're right! (a start from me to Crox). I was trying to give a "rule of a thump" -ish advice.
When you code COBOL as mentioned by me above, it performs almost perfect on both BIG-IRON 370 machines and on dinky-toy i386 thingies.
Next step could be optimizing to your CPU/compiler infrastructure. There should be on-and-a-halve-nanosecond out there to be gained....
- Status
