Re: AMODE 64 COBOL
Tom, What about Cobol calling and using Hiperspaces.. we have customers who want us to relocate our subpool we build for messaging out of sp231 and up in 64bit storage. One small problem is we need persistence. Maybe we are a special case not sure. Scott On Thu, Oct 18, 2018 at 4:31 PM Frank Swarbrick wrote: > What are your thoughts on 31-bit COBOL calling 64-bit Swift, and vice > versa? > > > From: IBM Mainframe Discussion List on behalf > of Tom Ross > Sent: Thursday, October 18, 2018 12:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AMODE 64 COBOL > > As has been discussed, we are working on AMODE 64 COBOL in IBM COBOL > development and have been for some years now. Trying to get all the > players lined up has been a challenge. (IE: CICS, DB2, IMS, DFSORT, etc) > > Our understanding from the beginning was that AMODE 64 COBOL would be for > specialized cases, and not for general use. We have very few customers > requesting AMODE 64 COBOL, and it is for special cases like moving data > above the bar to do in memory searches of very large tables where the > performance benefit outweighs any other aspect. Currently these customers > are using AMODE 64 assembler for this specialized processing. > > We do not currently think that we would recommend AMODE 64 COBOL to > everyone. For example, if I took an AMODE 31 application and recompiled > all of the programs for AMODE 64 (just for fun, IE: no need for above the > bar data) the application would necessarily run slower. This is because > instead of 4-byte addresses the programs would be processing 8-byte > addresses. > For this reason alone, customers would most likely avoid AMODE 64 COBOL > unless they had a real need for it (IE: storage constraint with AMODE 31, > or need for improved performance for searching massive amounts of data in > memory) > > So far, we have not heard of COBOL customers with data storage constraints > below the BAR. We have heard of storage constraints for programs, > especially > in CICS, where multiple CICS regions are required to allow the sheer > numbers > of COBOL programs to be loaded below the BAR. This is an RMODE 64 > question, > as in ARRRMODE however, and I am focused on AMODE 64 for this posting. > > Because of all of this, we consider it acceptable to have some restrictions > on using AMODE 64 COBOL. We are also trying to do what we can to make it > easier to use AMODE 64 COBOL, but our general recommendation will most > likely > be to only use AMODE 64 COBOL if you really need it, not for general > purposes. > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMODE 64 COBOL
What are your thoughts on 31-bit COBOL calling 64-bit Swift, and vice versa? From: IBM Mainframe Discussion List on behalf of Tom Ross Sent: Thursday, October 18, 2018 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AMODE 64 COBOL As has been discussed, we are working on AMODE 64 COBOL in IBM COBOL development and have been for some years now. Trying to get all the players lined up has been a challenge. (IE: CICS, DB2, IMS, DFSORT, etc) Our understanding from the beginning was that AMODE 64 COBOL would be for specialized cases, and not for general use. We have very few customers requesting AMODE 64 COBOL, and it is for special cases like moving data above the bar to do in memory searches of very large tables where the performance benefit outweighs any other aspect. Currently these customers are using AMODE 64 assembler for this specialized processing. We do not currently think that we would recommend AMODE 64 COBOL to everyone. For example, if I took an AMODE 31 application and recompiled all of the programs for AMODE 64 (just for fun, IE: no need for above the bar data) the application would necessarily run slower. This is because instead of 4-byte addresses the programs would be processing 8-byte addresses. For this reason alone, customers would most likely avoid AMODE 64 COBOL unless they had a real need for it (IE: storage constraint with AMODE 31, or need for improved performance for searching massive amounts of data in memory) So far, we have not heard of COBOL customers with data storage constraints below the BAR. We have heard of storage constraints for programs, especially in CICS, where multiple CICS regions are required to allow the sheer numbers of COBOL programs to be loaded below the BAR. This is an RMODE 64 question, as in ARRRMODE however, and I am focused on AMODE 64 for this posting. Because of all of this, we consider it acceptable to have some restrictions on using AMODE 64 COBOL. We are also trying to do what we can to make it easier to use AMODE 64 COBOL, but our general recommendation will most likely be to only use AMODE 64 COBOL if you really need it, not for general purposes. 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
Re: AMODE 64 COBOL
Tom, What about COBOL as JNI for 64-bit Java in a Liberty server? Isn't that a "future proofing" area that IBM should be pre-emptively targeting? Or do you intend that no customer can use their COBOL business logic programs for JNI from 64-bit Java? Or be forced to "thunk" their 31-bit business code with assembler stubs from 64-bit Java, with all the performance penalties that "thunking" entails? IMHO IBM should not be waiting for "customer requests" for 64-bit COBOL. IBM needs to ASSUME that 64-bit COBOL will be a near-universal requirement far sooner than you can possibly predict from "customer requests", and devote the resources accordingly. And hire the resources now if they aren't there yet. It is penny-wise and pound/dollar/euro-foolish to keep staff resources low to improve profits now when the future of the mainframe business rides on those resources. Watson and cloud are not going to save the mainframe business. Assuming of course that IBM wants to save that mainframe business. Peter P.S. -- Oh, and of course COBOL 2000+ language upgrades at the same time or very soon after. It's far, far past time to get current with newer standard COBOL. SMOP. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Thursday, October 18, 2018 2:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AMODE 64 COBOL EXTERNAL EMAIL As has been discussed, we are working on AMODE 64 COBOL in IBM COBOL development and have been for some years now. Trying to get all the players lined up has been a challenge. (IE: CICS, DB2, IMS, DFSORT, etc) Our understanding from the beginning was that AMODE 64 COBOL would be for specialized cases, and not for general use. We have very few customers requesting AMODE 64 COBOL, and it is for special cases like moving data above the bar to do in memory searches of very large tables where the performance benefit outweighs any other aspect. Currently these customers are using AMODE 64 assembler for this specialized processing. We do not currently think that we would recommend AMODE 64 COBOL to everyone. For example, if I took an AMODE 31 application and recompiled all of the programs for AMODE 64 (just for fun, IE: no need for above the bar data) the application would necessarily run slower. This is because instead of 4-byte addresses the programs would be processing 8-byte addresses. For this reason alone, customers would most likely avoid AMODE 64 COBOL unless they had a real need for it (IE: storage constraint with AMODE 31, or need for improved performance for searching massive amounts of data in memory) So far, we have not heard of COBOL customers with data storage constraints below the BAR. We have heard of storage constraints for programs, especially in CICS, where multiple CICS regions are required to allow the sheer numbers of COBOL programs to be loaded below the BAR. This is an RMODE 64 question, as in ARRRMODE however, and I am focused on AMODE 64 for this posting. Because of all of this, we consider it acceptable to have some restrictions on using AMODE 64 COBOL. We are also trying to do what we can to make it easier to use AMODE 64 COBOL, but our general recommendation will most likely be to only use AMODE 64 COBOL if you really need it, not for general purposes. Cheers, TomR >> COBOL is the Language of the Future! << -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AMODE 64 COBOL
As has been discussed, we are working on AMODE 64 COBOL in IBM COBOL development and have been for some years now. Trying to get all the players lined up has been a challenge. (IE: CICS, DB2, IMS, DFSORT, etc) Our understanding from the beginning was that AMODE 64 COBOL would be for specialized cases, and not for general use. We have very few customers requesting AMODE 64 COBOL, and it is for special cases like moving data above the bar to do in memory searches of very large tables where the performance benefit outweighs any other aspect. Currently these customers are using AMODE 64 assembler for this specialized processing. We do not currently think that we would recommend AMODE 64 COBOL to everyone. For example, if I took an AMODE 31 application and recompiled all of the programs for AMODE 64 (just for fun, IE: no need for above the bar data) the application would necessarily run slower. This is because instead of 4-byte addresses the programs would be processing 8-byte addresses. For this reason alone, customers would most likely avoid AMODE 64 COBOL unless they had a real need for it (IE: storage constraint with AMODE 31, or need for improved performance for searching massive amounts of data in memory) So far, we have not heard of COBOL customers with data storage constraints below the BAR. We have heard of storage constraints for programs, especially in CICS, where multiple CICS regions are required to allow the sheer numbers of COBOL programs to be loaded below the BAR. This is an RMODE 64 question, as in ARRRMODE however, and I am focused on AMODE 64 for this posting. Because of all of this, we consider it acceptable to have some restrictions on using AMODE 64 COBOL. We are also trying to do what we can to make it easier to use AMODE 64 COBOL, but our general recommendation will most likely be to only use AMODE 64 COBOL if you really need it, not for general purposes. 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
