On 14 Jan 2015 16:57:26 -0800, in bit.listserv.ibm-main you wrote: OOPs, the previous response got sent too soon.
>>Hi,I am looking for COBOL compiler option to compile our COBOL programs in = >>64 Bit mode.Please lead me if you have such a experience .The COBOL version= >> is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi > >AMODE 64 COBOL is still being worked on here at IBM. > >I (like the other poster) would like to know what you would do with AMODE 64 >COBOL? >Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 >code? >We assume that AMODE 64 COBOL will be used for very specialized one-off cases >to solve specific business problems, and that in general 99% of code will be >compiled for AMODE 31 even after we ship AMODE 64 COBOL. > > Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we >do not think very many users will need AMODE 64 in the next 10-15 years. >We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if >you know of any, please SHARE! (get it? :-) > While I can't speak to what is happening currently or be certain as to what would be used since my last contract was in 2006, there are some things in the 2002 standard, I wanted 40 years ago. The BINARY usages - BINARY-CHARACTER, BINARY-SHORT etc. would have been a far better way of handling the problem of picture not matching word capacity and also handling some of the fields on SMF records. USAGE BIT would have eliminated the need for assembler routines to deal with the bit switches on our customer, product and open account files that dated back to the 1960s. The floating point usages provide an elegant way of handling the distinction between Hex and IEEE with COMP-1 and COMP-2 for hex and the COBOL usages for IEEE. This way IEEE can be passed to and from JAVA without conversion. The decimal floating point usages and other language will allow passing decimal floating point to and from Java and also allow shops that use round to nearest even and other forms of rounding to eliminate special coding. For my former needs as a systems programmer, the new usages would have allowed me to fully handle the SMF 30 and other records without workarounds. If a major strategic objective is to move shops to languages such as Java, C# and C++ then a minimum amount of investment should be made in COBOL. If the goal is to have COBOL play nicely with other languages and newer data type then speedy enhancement to add data types available in other languages and DB2 to COBOL for interoperation and sharing of data within and between run units which have multiple languages. This will have to be accompanied by selling to high level - CIO and CTO management explaining how the enhancements what is seemingly low level detail can help their organizations. By adding all of the new data types and language that takes advantage of them to COBOL, capability to eliminate assembler routines and awkward coding is gained. I might add that business files can now contain megabyte fields - pictures JPEG and RAW, and gigabyte fields - Videos. If I knew more about some of the newer languages, I might be able to make a good case for IBM effort being directed to converting COBOL programs to one or more of them. If COBOL still is the best and simplest way to handle business problems, then much of the 2002 standard should be adopted. I would take advantage of the new EXIT statements in COBOL 5.1 or 5.2 and do appreciate seeing them. Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
