Re: OT: Happy New Year!
I couldn't agree more. NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. All attached documents are subject to FiTeq’s MNDA and are confidential. Thank you. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shai S Sent: Wednesday, September 24, 2014 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: Happy New Year! Happy Rosh Hashana to all of us from Ashdod, Israel. We hope that the coming new year will be peaceful and safe to all the people on earth. On Wed, Sep 24, 2014 at 5:44 PM, Itschak Mugzach imugz...@gmail.com wrote: A happy new Jewish year (Rosh Hashana) from Israel. ITschak On Wed, Sep 24, 2014 at 4:19 PM, John McKown john.archie.mck...@gmail.com wrote: 2014-09-24T15:34:00Z is the start of Rosh Ha'Shanah. Greetings to our members in Israel. If anyones wishes to, feel free to chastise me for being off topic. Won't be the first time. Likely not going to be the last. At least until my off-planet transfer orders come through. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- 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 -- Thanks. Shai -- 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: Sorry state of IT education?
This is why common core standards are igniting education. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, April 22, 2014 5:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sorry state of IT education? Not just IT. The entire education system from k-12 through bachelor's degree... Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | allan.stal...@kbmg.com snip Not too surprising to me. I imagine this is the norm for today because a well educated, intelligent, worker costs a lot more than a preprogrammed drone. http://www.informationweek.com/strategic-cio/executive-insights-and-innovation/the-sorry-state-of-it-education/d/d-id/1204552 quote Our profession is rife with people capable of performing procedures they've been taught, but incapable of thinking through a problem. Here's what we need to do. /quote /snip -- 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: Another Golden Anniversary - Dartmouth BASIC
Basic on a Commodore 64 as a hobby. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, April 09, 2014 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Another Golden Anniversary - Dartmouth BASIC OK, not a big mainframe impact. But how many of us started programming by using Basic on something like an Apple ][? https://www.dartmouth.edu/basicfifty/ -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- 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
VSAM Status Code 16/24 on READPREV
All, We are receiving a status code 16/24 while performing a KSDS VSAM 'READPREV'. This exception only occurs when the key is specified but does not occur if it is not entered through our UI. References point to it having MicroFocus origins, but we are running this on the mainframe under CICS. Any direction as to where to look next would be much appreciated. Thanks... John NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Status Code 16/24 on READPREV
Hi Lizette, We are using CICS TS 4.2 and are on z/OS 1.13. I'll have to look back to the STARTBR and see what it entails. Thanks... John -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, August 01, 2013 8:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Status Code 16/24 on READPREV Could you state: What version of CICS? What version of z/OS? Is this native VSAM File or RLS? Also, a quick peek at the manual on READPREV in CICS shows 16 INVREQ RESP2 values: 24 A READPREV command is issued for a file for which the previous STARTBR or RESETBR command has the GENERIC option If this is the correct codes, have you verified this? Also, this might help http://pic.dhe.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=%2Fcom.ibm.cic s.ts.applicationprogramming.doc%2Fcommands%2Fdfhp4_readprev.html Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, August 01, 2013 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Status Code 16/24 on READPREV If you go to SYSLOG at the time of the error, you might find some additional messages (IEC or other) Also, the CICS log may help. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Weber Sent: Thursday, August 01, 2013 8:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAM Status Code 16/24 on READPREV All, We are receiving a status code 16/24 while performing a KSDS VSAM 'READPREV'. This exception only occurs when the key is specified but does not occur if it is not entered through our UI. References point to it having MicroFocus origins, but we are running this on the mainframe under CICS. Any direction as to where to look next would be much appreciated. Thanks... John -- 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: VSAM Status Code 16/24 on READPREV
GENERIC is definitely the culprit. It uses it for a keyed read only. Hence it works for a non-specified key. However, this code functions properly on MicroFocus. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norbert Friemel Sent: Thursday, August 01, 2013 8:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Status Code 16/24 on READPREV On Thu, 1 Aug 2013 15:25:55 +, John Weber wrote: All, We are receiving a status code 16/24 while performing a KSDS VSAM 'READPREV'. This exception only occurs when the key is specified but does not occur if it is not entered through our UI. References point to it having MicroFocus origins, but we are running this on the mainframe under CICS. Any direction as to where to look next would be much appreciated. 16 = INVREQ 24 = A READPREV command is issued for a file for which the previous STARTBR or RESETBR command has the GENERIC option. http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=%2Fcom.ibm.cics.ts.applicationprogramming.doc%2Fcommands%2Fdfhp4_readprev.html Norbert Friemel -- 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: VSAM Return Code 44 Received on Write to Fixed Length File
Thank you for the assistance with our problem. It turns out our secondary index which allows non-unique records was running into the default limit. Happy Thanksgiving everyone. John -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 19, 2012 5:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Then u get some default. Do a LISTC on the AIX to see what it is. You might want to PRINT the records in the AIX itself just to see. Or on an EXAMINE on it. On Nov 19, 2012 6:52 PM, John Weber j...@fiteq.com wrote: Interesting about a secondary status variable. We'll investigate that. Regarding the AIX definitions. We do not include a RECORDSIZE parameter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 19, 2012 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File My habit with VSAM is to use the second COBOL FILE STATUS variable to get the actual VSAM return and reason codes. Often that is the only way to determine the actual reason. What comes to mind in your case is that the RECORDSIZE on your AIX is too small to record all the base keys associated with a single AIX key. This can cause a 44. Normally these keys are either ALL SPACES or ALL LOW-VALUES or maybe ALL HIGH-VALUES. On Nov 19, 2012 6:21 PM, John Weber j...@fiteq.com wrote: The only sysprint from the job is the status code display from the program. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, November 19, 2012 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Could you post the IDC messages for the 44? Lizette -Original Message- From: John Weber j...@fiteq.com Sent: Nov 19, 2012 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAM Return Code 44 Received on Write to Fixed Length File We are using a batch process to write account records to a VSAM file while also writing records to an audit file which is also a VSAM file. Both files include an index and several alternate indexes. Each alternate index allows duplicates (NONUNIQUEKEY). The audit file receives a VSAM return code of 44 and discontinues writing after writing 3,258 of 10,000 records. Neither file is a variable file so the explanation of return code 44 is not relevant to the problem or solution. (44 - REWRITE of different size record) The sizing in our allocations of our primary data and secondary index elements are appropriate for both files given the data in this exercise. Please advise on problem solving this issue and/or what additional information is needed. Thank you... John --- -- - 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 -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM Return Code 44 Received on Write to Fixed Length File
We are using a batch process to write account records to a VSAM file while also writing records to an audit file which is also a VSAM file. Both files include an index and several alternate indexes. Each alternate index allows duplicates (NONUNIQUEKEY). The audit file receives a VSAM return code of 44 and discontinues writing after writing 3,258 of 10,000 records. Neither file is a variable file so the explanation of return code 44 is not relevant to the problem or solution. (44 - REWRITE of different size record) The sizing in our allocations of our primary data and secondary index elements are appropriate for both files given the data in this exercise. Please advise on problem solving this issue and/or what additional information is needed. Thank you... John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Return Code 44 Received on Write to Fixed Length File
The only sysprint from the job is the status code display from the program. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, November 19, 2012 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Could you post the IDC messages for the 44? Lizette -Original Message- From: John Weber j...@fiteq.com Sent: Nov 19, 2012 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAM Return Code 44 Received on Write to Fixed Length File We are using a batch process to write account records to a VSAM file while also writing records to an audit file which is also a VSAM file. Both files include an index and several alternate indexes. Each alternate index allows duplicates (NONUNIQUEKEY). The audit file receives a VSAM return code of 44 and discontinues writing after writing 3,258 of 10,000 records. Neither file is a variable file so the explanation of return code 44 is not relevant to the problem or solution. (44 - REWRITE of different size record) The sizing in our allocations of our primary data and secondary index elements are appropriate for both files given the data in this exercise. Please advise on problem solving this issue and/or what additional information is needed. Thank you... John -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Return Code 44 Received on Write to Fixed Length File
Interesting about a secondary status variable. We'll investigate that. Regarding the AIX definitions. We do not include a RECORDSIZE parameter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 19, 2012 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File My habit with VSAM is to use the second COBOL FILE STATUS variable to get the actual VSAM return and reason codes. Often that is the only way to determine the actual reason. What comes to mind in your case is that the RECORDSIZE on your AIX is too small to record all the base keys associated with a single AIX key. This can cause a 44. Normally these keys are either ALL SPACES or ALL LOW-VALUES or maybe ALL HIGH-VALUES. On Nov 19, 2012 6:21 PM, John Weber j...@fiteq.com wrote: The only sysprint from the job is the status code display from the program. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, November 19, 2012 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Could you post the IDC messages for the 44? Lizette -Original Message- From: John Weber j...@fiteq.com Sent: Nov 19, 2012 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAM Return Code 44 Received on Write to Fixed Length File We are using a batch process to write account records to a VSAM file while also writing records to an audit file which is also a VSAM file. Both files include an index and several alternate indexes. Each alternate index allows duplicates (NONUNIQUEKEY). The audit file receives a VSAM return code of 44 and discontinues writing after writing 3,258 of 10,000 records. Neither file is a variable file so the explanation of return code 44 is not relevant to the problem or solution. (44 - REWRITE of different size record) The sizing in our allocations of our primary data and secondary index elements are appropriate for both files given the data in this exercise. Please advise on problem solving this issue and/or what additional information is needed. Thank you... John - - 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM Return Code 44 Received on Write to Fixed Length File
What are we looking for in the LISTCAT output? RECORDSIZE is not found. Is this because our VSAM file has a fixed length? Thanks. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 19, 2012 5:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Then u get some default. Do a LISTC on the AIX to see what it is. You might want to PRINT the records in the AIX itself just to see. Or on an EXAMINE on it. On Nov 19, 2012 6:52 PM, John Weber j...@fiteq.com wrote: Interesting about a secondary status variable. We'll investigate that. Regarding the AIX definitions. We do not include a RECORDSIZE parameter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, November 19, 2012 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File My habit with VSAM is to use the second COBOL FILE STATUS variable to get the actual VSAM return and reason codes. Often that is the only way to determine the actual reason. What comes to mind in your case is that the RECORDSIZE on your AIX is too small to record all the base keys associated with a single AIX key. This can cause a 44. Normally these keys are either ALL SPACES or ALL LOW-VALUES or maybe ALL HIGH-VALUES. On Nov 19, 2012 6:21 PM, John Weber j...@fiteq.com wrote: The only sysprint from the job is the status code display from the program. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, November 19, 2012 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM Return Code 44 Received on Write to Fixed Length File Could you post the IDC messages for the 44? Lizette -Original Message- From: John Weber j...@fiteq.com Sent: Nov 19, 2012 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VSAM Return Code 44 Received on Write to Fixed Length File We are using a batch process to write account records to a VSAM file while also writing records to an audit file which is also a VSAM file. Both files include an index and several alternate indexes. Each alternate index allows duplicates (NONUNIQUEKEY). The audit file receives a VSAM return code of 44 and discontinues writing after writing 3,258 of 10,000 records. Neither file is a variable file so the explanation of return code 44 is not relevant to the problem or solution. (44 - REWRITE of different size record) The sizing in our allocations of our primary data and secondary index elements are appropriate for both files given the data in this exercise. Please advise on problem solving this issue and/or what additional information is needed. Thank you... John --- -- - 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 -- 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Compiler Question
Thank you for all inputs.
The below information given to us by IBM states we are required by CICS to
use LINK (or XCTL) and can't use CALL; we pass a COMMAREA and use EXEC CICS
commands within our called module.
Also, there is no evidence of a performance hit. But since we can't use CALL
as
stated above, we need to use LINK no matter what.
Our IBM source stated the following:
'According to the z/OS C/C++ Programming Guide, SC09-4765,
the system() function is not supported under CICS.
However, there are two EXEC CICS commands that give you similar
functionality they are:
EXEC CICS LINK
EXEC CICS XCTL
So to answer your question no a CALL can not be done.'
'As far as high CPU consumption (slow performance) there are no known
issues in the area of a EXEC CICS LINK and high CPU.'
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rick Arellanes
Sent: Tuesday, October 16, 2012 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
The COBOL Performance Tuning paper talks about the performance differences of
using EXEC CICS LINK vs COBOL dynamic CALL. Perhaps this will be helpful to
you. You can find the performance tuning paper on the COBOL page at:
http://www.ibm.com/software/awdtools/cobol/library/ (scroll down near the
bottom of the page). The most current one is Enterprise COBOL Version 4 Release
2 Performance Tuning (which is at the top of the list). The CICS section starts
on page 27.
Rick Arellanes
IBM COBOL Development and Performance
On Fri, 12 Oct 2012 23:21:59 +, John Weber j...@fiteq.com wrote:
We have a COBOL CICS module being called using the LINK command.
Here is the interface call:
EXEC CICS
LINK PROGRAM('PROGRAM1')
RESP(WS-RESP)
COMMAREA(WS-COMMAREA)
END-EXEC
However, it has been brought up that creating a bound module instead of using
LINK can speed up response time.
Is this binding compiler in question CTRCOBMOD? If so, is this worth pursuing?
Thanks a lot...
John
--
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Compiler Question
Thanks Frank.
I read over your email in detail. It sounds like a static CALL is the way to
go.
It's a C++ calling our COBOL module. He mentioned an IBM BINDER 'binding' the
calling and called modules together. I've never heard that term before. Is it
a C++ term?
Also, will the AS INITIAL cover the need for doing explicit initializations?
I'd like to avoid the human error potential.
Thanks!
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Frank Swarbrick
Sent: Friday, October 19, 2012 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
That is so untrue I just don't know what to say. Look back at my previous
response about how to compile with the CICS(NOLINKAGE) option and how to CALL
it. Works great!
But wait; is the called module written in C/C++, not COBOL? If that is the
case then I can't say for sure. I bet it is still possible, but I couldn't say
for sure how it could be done.
Frank
From: John Weber j...@fiteq.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 19, 2012 8:28 AM
Subject: Re: COBOL Compiler Question
Thank you for all inputs.
The below information given to us by IBM states we are required by CICS
to use LINK (or XCTL) and can't use CALL; we pass a COMMAREA and use
EXEC CICS commands within our called module.
Also, there is no evidence of a performance hit. But since we can't
use CALL as stated above, we need to use LINK no matter what.
Our IBM source stated the following:
'According to the z/OS C/C++ Programming Guide, SC09-4765, the
system() function is not supported under CICS.
However, there are two EXEC CICS commands that give you similar
functionality they are:
EXEC CICS LINK EXEC CICS XCTL
So to answer your question no a CALL can not be done.'
'As far as high CPU consumption (slow performance) there are no known
issues in the area of a EXEC CICS LINK and high CPU.'
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Rick Arellanes
Sent: Tuesday, October 16, 2012 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
The COBOL Performance Tuning paper talks about the performance differences of
using EXEC CICS LINK vs COBOL dynamic CALL. Perhaps this will be helpful to
you. You can find the performance tuning paper on the COBOL page at:
http://www.ibm.com/software/awdtools/cobol/library/ (scroll down near the
bottom of the page). The most current one is Enterprise COBOL Version 4
Release 2 Performance Tuning (which is at the top of the list). The CICS
section starts on page 27.
Rick Arellanes
IBM COBOL Development and Performance
On Fri, 12 Oct 2012 23:21:59 +, John Weber j...@fiteq.com wrote:
We have a COBOL CICS module being called using the LINK command.
Here is the interface call:
EXEC CICS
LINK PROGRAM('PROGRAM1')
RESP(WS-RESP)
COMMAREA(WS-COMMAREA)
END-EXEC
However, it has been brought up that creating a bound module instead of
using LINK can speed up response time.
Is this binding compiler in question CTRCOBMOD? If so, is this worth
pursuing?
Thanks a lot...
John
--
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
--
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Compiler Question
That about sums it up. Thanks Frank!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Frank Swarbrick
Sent: Friday, October 19, 2012 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
A static call is fine (I don't even know if C can do dynamic calls, except
perhaps using DLLs). Realize, though, that any time you change the called
COBOL routine you'll have to relink (or re-bind) any program that calls that
routine. This is because, as mentioned, doing a static call causes the IBM
Binder to bind the caller and the called modules together into the same load
module or program object. You may know of binding as what used to be call
link-editing. The IBM Binder replaced the IBM linkage editor (some time ago).
As for AS INITIAL, it does not eliminate the need for VALUE clauses or explicit
initialization. All it does is it applies the VALUE clause to each
associated working-storage field each time that your COBOL subroutine is
called, rather than only the first time it is called.
Frank
From: John Weber j...@fiteq.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 19, 2012 10:28 AM
Subject: Re: COBOL Compiler Question
Thanks Frank.
I read over your email in detail. It sounds like a static CALL is the way to
go.
It's a C++ calling our COBOL module. He mentioned an IBM BINDER 'binding' the
calling and called modules together. I've never heard that term before. Is
it a C++ term?
Also, will the AS INITIAL cover the need for doing explicit initializations?
I'd like to avoid the human error potential.
Thanks!
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Frank Swarbrick
Sent: Friday, October 19, 2012 9:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
That is so untrue I just don't know what to say. Look back at my previous
response about how to compile with the CICS(NOLINKAGE) option and how to CALL
it. Works great!
But wait; is the called module written in C/C++, not COBOL? If that is the
case then I can't say for sure. I bet it is still possible, but I couldn't
say for sure how it could be done.
Frank
From: John Weber j...@fiteq.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 19, 2012 8:28 AM
Subject: Re: COBOL Compiler Question
Thank you for all inputs.
The below information given to us by IBM states we are required by
CICS to use LINK (or XCTL) and can't use CALL; we pass a COMMAREA and
use EXEC CICS commands within our called module.
Also, there is no evidence of a performance hit. But since we can't
use CALL as stated above, we need to use LINK no matter what.
Our IBM source stated the following:
'According to the z/OS C/C++ Programming Guide, SC09-4765, the
system() function is not supported under CICS.
However, there are two EXEC CICS commands that give you similar
functionality they are:
EXEC CICS LINK EXEC CICS XCTL
So to answer your question no a CALL can not be done.'
'As far as high CPU consumption (slow performance) there are no known
issues in the area of a EXEC CICS LINK and high CPU.'
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Rick Arellanes
Sent: Tuesday, October 16, 2012 8:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
The COBOL Performance Tuning paper talks about the performance differences of
using EXEC CICS LINK vs COBOL dynamic CALL. Perhaps this will be helpful to
you. You can find the performance tuning paper on the COBOL page at:
http://www.ibm.com/software/awdtools/cobol/library/ (scroll down near the
bottom of the page). The most current one is Enterprise COBOL Version 4
Release 2 Performance Tuning (which is at the top of the list). The CICS
section starts on page 27.
Rick Arellanes
IBM COBOL Development and Performance
On Fri, 12 Oct 2012 23:21:59 +, John Weber j...@fiteq.com wrote:
We have a COBOL CICS module being called using the LINK command.
Here is the interface call:
EXEC CICS
LINK PROGRAM('PROGRAM1')
RESP(WS-RESP)
COMMAREA(WS-COMMAREA) END-EXEC
However, it has been brought up that creating a bound module instead of
using LINK can speed up response time.
Is this binding compiler in question CTRCOBMOD? If so, is this worth
pursuing?
Thanks a lot...
John
-
- 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
Re: COBOL Compiler Question
Yes. Thanks!
The LE initialization using LINK caused high CPU consumption.
The alternative was to use the IBM BINDER to bind theirs and the called program
together.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Wayne Bickerdike
Sent: Monday, October 15, 2012 8:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Compiler Question
Great information Frank. Excellent, thanks.
On Sat, Oct 13, 2012 at 11:11 AM, Frank Swarbrick frank.swarbr...@yahoo.com
wrote:
What is CTRCOBMOD?
If you do a COBOL static call, or even a COBOL dynamic call, you are for the
most part not using CICS services to invoke your routine. For static I don't
think CICS knows or cares at all. For a dynamic call I think a CICS service
is invoked by the COBOL/LE runtime to load the module, but from there its
basically COBOL.
If you have no CICS commands inside the called module you don't have
to do anything special with the called module. You compile it just as
a batch COBOL program. (You still don't want to use things that
directly invoke MVS services, though, such as COBOL I/O, etc.)
If you have CICS commands you have a couple options. Others will probably
tell you about the way that I do not prefer. What I prefer is the following:
Place the following at the top of the called modules source code:
PROCESS CICS('NOLINKAGE')
(This assumes you're using the COBOL/CICS integrated preprocessor; if
you still use the CICS translator then specify the NOLINKAGE
translator option in the appropriate manner.)
By doing this, the CICS translator/preprocessor will not add the implicit
DFHEIBLK and DFHCOMMAREA fields to the COBOL LINKAGE SECTION and PROCEDURE
DIVISION USING. This allows you to do a COBOL CALL to the routine just like
you would in a batch program, i.e.:
CALL 'MYSUBR' USING PARM-1, PARM-2, PARM-3.
In your example below you could just do:
CALL 'PROGRAM1' USING WS-COMMAREA
Your called routine, if executing a CICS command, still needs to have the
DFHEIBLK area; you just have to add it explicitly. Add the following to your
LINKAGE SECTION:
COPY DFHEIBLC.
Then add the following to the beginning of your PROCEDURE DIVISION:
exec cics address
eib (address of dfheiblk)
end-exec
You now have DFHEIBLK addressability without requiring it to be passed as a
parameter from your calling program.
For the most part your called program can stay the same. You must
eliminate any EXEC CICS RETURN statements, though, and replace them
with a COBOL GOBACK. If you do EXEC CICS RETURN it behaves as if the
calling program executed it, and most likely will not be what you want
(which is to go back to the caller, not to return to CICS). This is
because to CICS your calling program and your called program ARE THE
SAME PROGRAM. With EXEC CICS LINK you go up a level, and a RETURN
goes back down. With COBOL CALL you do not go up a level, so if you
do RETURN you still go back a level, which is probably back to CICS
(unless your caller was LINKed to...)
Anyway, once you get a few things straight there's not much to it.
I'm sure that a static call gives the best performance.
I believe a dynamic call is still better than a LINK because when you do a
LINK you enter and initialize a new LE enclave each time.
Which brings up another caveat. If you do a CALL to the same program from
the same program multiple times within a task it behaves exactly as how this
behaves in batch. That is, your WORKING STORAGE section is initialized only
upon the first call. This is different than CICS LINK where you get fresh
working-storage each time. This can actually be quite an advantage, but you
have to make sure that your program that your currently LINKing to doesn't
depend on it. If it does, there are a couple of things you can do:
- Use the AS INITIAL clause of the COBOL PROGRAM-ID statement.
- Do a COBOL CANCEL after each COBOL CALL (I don't recommend this, and I
don't think it even works if you do a static call).
- Place any variables that you need initialized each time your program
is called in LOCAL-STORAGE SECTION rather than WORKING-STORAGE
SECTION. (You could just put all of your variables in LOCAL STORAGE,
but I imagine this would have unwanted overhead.)
- Leave everything in WORKING-STORAGE and add PROCEDURE DIVISION statements
to explicitly initialize any fields that require it.
I would guess that options 3 (LOCAL STORAGE) or 4 (explicit initialization)
would give you the best performance.
Have I forgotten anything? Possibly.
Have fun!
Frank
From: John Weber j...@fiteq.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, October 12, 2012 5:21 PM
Subject: COBOL Compiler Question
We have a COBOL CICS module being called using the LINK command.
Here is the interface call:
EXEC CICS
LINK PROGRAM
COBOL Compiler Question
We have a COBOL CICS module being called using the LINK command.
Here is the interface call:
EXEC CICS
LINK PROGRAM('PROGRAM1')
RESP(WS-RESP)
COMMAREA(WS-COMMAREA)
END-EXEC
However, it has been brought up that creating a bound module instead of using
LINK can speed up response time.
Is this binding compiler in question CTRCOBMOD? If so, is this worth pursuing?
Thanks a lot...
John
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
