Re: COBOL and DFSORT change?
On Thu, 18 Feb 2010 14:48:04 -0500, Richards, Robert B. robert.richa...@opm.gov wrote: I have been asked to determine is anything has changed with either DFSORT or Enterprise COBOL V4 recently that would change how it handles the following question from one of my programmers: Has something changed in IBM COBOL? It used to be that if the sort failed and the SORT-RETURN-CODE field was not referenced anywhere in the code, then the program abended. If the field was referenced in the code, then handling the failure became the responsibility of the program. According to the programmer, the job issued IGZ0026W after an ICE46A message and the program DID NOT abend and finished with a return code of ZERO. Is anyone aware of any changes? I am at z/OS 1.10. There have been no changes to this behavior in Enterprise COBOL. I just checked our documentation and it says that a run-time diagnostic message will be issued if the SORT fails and you do not reference SORT- RETURN in your program. See http://publibfp.boulder.ibm.com/cgi- bin/bookmgr/BOOKS/igy3pg50/1.12.11 for more info. Additionally, I have just verified using a small program that message IGZ0026W is indeed issued when the SORT fails if I removed the reference to SORT- RETURN. If you are still having problems with this, I would suggest that you open a PMR so that our COBOL service people can help you diagnose this. Rick Arellanes (IBM COBOL Development) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enterprise COBOL code generation question
On Fri, 1 May 2009 08:38:59 -0500, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris Snipped On 30 Apr 2009 13:00:02 -0700, in bit.listserv.ibm-main you wrote: Try TRUNC(OPT). Trunc STD would require the conversion to decimal to guarantee that the data fit the picture. TRUNC(BIN) is known and documented to generate less than optimal code. Son of a gun, that did it. From half a page of code to six instructions. I will have to test this program with TRUNC(OPT) pretty carefully to make sure it has no other adverse affects. The doc on OPT is pretty clear in its warnings. And the doc on TRUNC(BIN) does have the phrase ... you can avoid the performance overhead of using TRUNC(BIN) ..., implying there is, in fact, a performance penalty for using it. Thanks for pointing out the benefit of TRUNC(OPT) to me. But then there's this in the Notes for TRUNC in the Installation Customization Guide: 2. TRUNC=BIN is the recommended option when interfacing with other products that have S/390-format binary data (such as CICS, DB2, FORTRAN, and PL/I). This is especially true if there is a possibility of having more than 9 digits in a fullword or more than 4 digits in a halfword. So, we're stuck with TRUNC(BIN) in CICS, where arguably we'd want the best performance. :-( -jc- It looks like we may have missed an update to the Customization Guide. Please see the Programming Guide, which was updated to say: Recommendations: TRUNC(BIN) is the recommended option for programs that use binary values set by other products. Other products, such as IMS, DB2, C/C++, FORTRAN, and PL/I, might place values in COBOL binary data items that do not conform to the PICTURE clause of the data items. You can use TRUNC(OPT) with CICS programs as long as your data conforms to the PICTURE clause for your BINARY data items. You might want to read the Enterprise COBOL Version 3 Release 1 Performance Tuning Paper at: http://www.ibm.com/software/awdtools/cobol/library/ to read more about this. It says: As long as your usage of all binary (COMP) data items in the application conforms to the PICTURE and USAGE specifications, you can use TRUNC(OPT) to improve transaction response time. This is recommended in performance sensitive CICS applications. If your usage of any binary data item does not conform to the PICTURE and USAGE specifications, you can either use a COMP- 5 data type or increase the precision in the PICTURE clause instead of using the TRUNC(BIN) compiler option. Note that the CICS translator does not generate code that will cause truncation and the CICS co-processor uses COMP-5 data types which does not cause truncation. If you were using NOTRUNC with your OS/VS COBOL programs without problems, TRUNC(OPT) on IBM Enterprise COBOL behaves in a similar way. For additional information on the TRUNC option, please refer to the compiler options section of this paper. Rick Arellanes (IBM COBOL Development and Performance) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C03 abend when omitting CEE.SCEERUN from JCL
After talking to another co-worker, 2 more things come to mind: 1. If the OS/VS COBOL program is the one that opened the file and did not close it, the COBOL library routines will NOT automatically close the file when the application terminates. The COBOL library routines will only automatically close any open files that were opened (but not closed) in VS COBOL II and later programs. 2. If you have any of the older COBOL library data sets (e.g., OS/VS COBOL or VS COBOL II) ahead of SCEERUN in the LINKLST concatenation, this will also cause problems. You will have to remove the older COBOL library data sets from LINKLST. Check your LINKLST for duplicate modules beginning with ILBO or IGZ. For example, scan for ILBONTR and IGZEINI. If they appear in more than one data set, you will need to remove the older library data sets. In any case, you still should correct the original problem by closing the file that was left open. Rick Arellanes IBM COBOL Development -Original Message- On Tue, 21 Oct 2008 09:29:05 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi Bill, 1 VS Cobol Program is actually OS/VS Cobol (amblist shows 5740CB103 as compiler version). Program compilation details are like: AMODE(24),RMODE(24), NOT-RENT, RES Thanks and regards. Mürsel Taþgýn BT Sistem Yönetimi Yönetici Yardýmcýsý Akbank Genel Müdürlüðü Sabancý Center 34330, Ýstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Monday, October 20, 2008 9:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: C03 abend when omitting CEE.SCEERUN from JCL When you say 1 VS COBOL program Do you mean VS COBOL II or OS/VS COBOL? If it is OS/VS COBOL, then this may WELL be part of the problem. However, for either VS COBOL II or OS/VS COBOL, was the program compiled with RES or NORES? (You can use COBANAL or Edge Portfolio to find this out). If you have ANY NORES program mixed in with an Enterprise COBOL application, you are into the wonderful world of MIXRES and things can get VERY funny. I can (relatively) easily imagine that this may well lead to problems with different locations for SCEERUN. If your VS COBOL (OS/VS COBOL or VS COBOL II) program is compiled with NORES, then I suggest recompiling with RES and seeing if this fixes the problem. Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Tasgin BT Sistem Yönetimi Yönetici Yardimcisi Akbank Genel Müdürlügü Sabanci Center 34330, Istanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C03 abend when omitting CEE.SCEERUN from JCL
In the case of normal COBOL termination (e.g., GOBACK from main, STOP RUN, etc.) or abnormal COBOL termination (e.g., abend with TRAP(ON) in effect), COBOL will attempt to close any files that were left open and the C03 abend will be avoided. However, if an assembler program dynamically loads a COBOL program that opened a file and did not close it and then the assembler program deletes the COBOL program, this is where a C03 abend can occur. The COBOL Migration Guide says that unpredictable results may occur in certain cases if a COBOL program was SVC LOADed and then subsequently SVC DELETEd (the C03 abend is one of these unpredictable results). The COBOL library does not make any distinction as to where the library routines are loaded. However, I have seen cases before that when modules are loaded from different locations (STEPLIB, JOBLIB, LINKLSK, LPA, etc.), they may get loaded in different areas of storage. This would cause a DCB to be getmained at a different address. Then, when the COBOL program is deleted and if the DCB also gets freed (but the storage is not reused), the task termination code could still find the DCB in storage and can close the file successfully. However, if the DCB stoage got reused after the DCB was freed, task termination would no longer find the DCB in storage and would issue the C03 abend. So, seeing the C03 abend when putting the SCEERUN library in LPA or LINKLST vs. STEPLIB or JOBLIB may not actually be the cause of the problem, but rather may have just exposed the problem due to the way that storage was allocated and freed. It could be that your application was just lucky in not getting the abend until now when the storage usage was different. The correct solution is to always close your files before ending the application. It that is not possible for some reason, then do not delete the COBOL program that was SVC loaded by an assembler program until after the COBOL environment has terminated. Rick Arellanes IBM COBOL Development -Original Message- On Mon, 20 Oct 2008 10:00:50 +0300, Mürsel Ta#351;g#305;n [EMAIL PROTECTED] wrote: Hi, It is a DB2 Cobol program and make calls to other programs compiled with ASM, Enterprise Cobol and 1 VS Cobol program. We think that there is a problem with the program (ie. Not closing datasets properly etc.) But we cannot understand why does it work with CEE.SCEERUN in JOBLIB and doesn't work when it needs to call it from LNKLST. Thanks and regards. Mürsel Taþgýn BT Sistem Yönetimi Yönetici Yardýmcýsý Akbank Genel Müdürlüðü Sabancý Center 34330, Ýstanbul Tel: + 90 212 385 53 85 Faks: +90 212 282 62 76 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Datasets with KEYs
Perhaps you can do this with Enterprise PL/I REGIONAL(1) data sets. They are non-VSAM data sets with keys. http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibm3pg60/2.4? DT=20071108121521 Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (fwd) Re: Is IT becoming extinct?
I gotta ask this, hope you don't mind. Why is the code generation for fullword binary so weird? Try TRUNC(OPT), you will get: LH2,14(0,10) PGMLIT AT +10 A 2,0(0,8)MYDATA ST2,0(0,8)MYDATA See the COBOL Performance Tuning paper at http://www- 306.ibm.com/software/awdtools/cobol/library/ for more info on the TRUNC compiler option, as well as the performance implications of using the various suboptions of TRUNC. Rick Arellanes (IBM COBOL Development and Performance) On Tue, 8 Apr 2008 13:25:14 -0500, McKown, John [EMAIL PROTECTED] wrote: Tom, I gotta ask this, hope you don't mind. Why is the code generation for fullword binary so weird? I have: 77 MYDATA PIC S9(8) BINARY. .. ADD +1 TO MYDATA The code generated is terrible (to me): L 6,0(0,2)MYDATA SRDA 6,32(0) LH0,22(0,10) PGMLIT AT +10 SRDA 0,32(0) AR6,0 ALR 7,1 BC12,164(0,11)GN=17(0002D8) A 6,0(0,12) SYSLIT AT +0 GN=17EQU * ST7,0(0,2)MYDATA Why is COBOL doing 64 bit arithmetic? Why the BC around the A when the contents of register 6 are ignored? This is with TRUNC(BIN). With TRUNC(STD), I get: LH7,22(0,10) PGMLIT AT +10 (halfword H'1') A 7,0(0,2)MYDATA LR6,7 SRDA 6,32(0) D 6,4(0,12) SYSLIT AT +4 ST6,0(0,2)MYDATA which is much better, but still confusing. In my own code, a simple: L 6,MYDATA A 6,PLUS1 ST 6,MYDATA suffices. Or, going with what would be more similar to COBOL's code: LH 7,=H'+1' A 7,MYDATA ST 7,MYDATA what is with the SRDA and D? I cannot determine what SYSLIT+4 is because it looks like x'05F5E100' which makes NO sense to me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL and C
You can find info on calling between COBOL and C (as well as between other languages) in the Language Environment Writing ILC Applications book at http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CEEA4140/CCONTENTS?SHELF=CEE2BK61DN=SA22-7563- 04DT=20050804124136 Rick Arellanes IBM COBOL and PL/I Development On Thu, 9 Nov 2006 22:31:05 +0530, Chithra Nayar [EMAIL PROTECTED] wrote: Hi, Thanks to Mr Comstock.I tried the changes you suggested and it worked!!! How can i change the static call to a dynamic call?I tried by changing the first line PROCESS NODYNAM MAP LIST to PROCESS DYNAM MAP LIST and left the remaining unchanged. Compiled and linked the C code. MODULE ENTRY NOT PROVIDED. ENTRY DEFAULTS TO SECTION @ST1. is a message i got when the link of c code was done.I did not use #pragma. I got a SOC7 while executing this. WORKING-STORAGE SECTION. 01 ONEARG PIC X(10) VALUE SUDHEER123. 01 B1 PIC X(30). PROCEDURE DIVISION. MAIN. DISPLAY ONEARG IS ONEARG. CALL PADWPD1 USING BY REFERENCE B1, ONEARG. DISPLAY PADDED STRING B1. DISPLAY PADWPD1'S RC IS RETURN-CODE. I have no access to edit the link JCL to specify the entry point. Is there an alternate method to do this? Also can you please suggest some good book to learn about COBOL dynamically calling C routine? Thanks in Advance. Chithra -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html = -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Static versus dynamic linking
You might want to get a copy of our Enterprise COBOL Version 3 Release 1 Performance Tuning paper. It gives you some performance considerations for using the various features of COBOL and Language Environment, and for running with other products (such as IMS and CICS). For example, in it, you will find some percentage difference numbers of using static calls versus dynamic calls. Although the data was collected using Enterprise COBOL 3.1 running under z/OS 1.2, the principles and relative performance numbers should be about the same. You can find the Performance Tuning paper at http://www.ibm.com/software/awdtools/cobol/ and then click on the Library link and scroll to the bottom of the page. Rick Arellanes (IBM COBOL and PL/I Development and Performance) On Fri, 15 Sep 2006 09:24:28 -0400, Denis Gaebler [EMAIL PROTECTED] wrote: Hi List, we are planning to go from static linking under IMS to dynamic linking, COBOL transactions with DB2 access. The main reason for us is to avoid relinking in case of modules are changed. Are there any pitfalls, pros and cons about that? e.g. more CPU cycles and thus higher Software costs for the subsystems? Higher region recycling times in case of abends, Preload and LE considerations? What to do to avoid more I/Os? Thanks in advance. Denis Gäbler. Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html = -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z/os Performance issue: REWRITE a sequential data set
On Mon, 28 Aug 2006 19:32:15 -0500, Ed Gould [EMAIL PROTECTED] wrote: Finally, you should always report your problems (including performance problems) to IBM service so that it will come to us directly. Our PL/I service people can help you identify this type of performance problem and its solution quickly. Ahhh yes apparently the rest of IBM (MVS) doesn't feel the way you do:( Ed I can't speak for other products, but we in COBOL and PL/I development are concerned with the performance of our products. In fact, the reason that we made the changes to PL/I's QSAM, VSAM, and REGIONAL(1) I/O processing was due to customer feedback regarding PL/I's I/O performance. So, if you do encounter a performance problem with COBOL or PL/I running under Language Environment, please report it to IBM service and we (IBM service and the COBOL and PL/I developers) will work with you to understand the problem and see how/if we can resolve it. Rick Arellanes (IBM COBOL and PL/I Development and Performance) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z/os Performance issue: REWRITE a sequential data set
This performance problem was addressed in December 2004 (APAR PQ95212) when we did the I/O rewrite. We have made substantial improvements in Enterprise PL/I I/O during the past couple of years and we are in the process of making more. For example, PQ95212 (12/2004) improved PL/I's record I/O (non-VSAM and non-REGIONAL(1)) performance, PK06945 (11/2005) improved PL/I's VSAM I/O performance , and PQ12483 (3/2006) improved PL/I's REGIONAL(1) I/O performance. You should bring your LE run-time library up to current maintenance (at least including PL/I APARs PK28066 for VSAM and PK28237 for QSAM) and re- run your program. When I ran the testcase here using both PL/I for MVS amp; VM and Enterprise PL/I with the latest maintenence on LE for z/OS 1.6, the CPU times were 0.06 seconds and the EXCPs were 41 in both cases. If I run the Enterprise PL/I version using LE for z/OS 1.6 without APAR PQ95212, the job ran out of time and used more than 150,000 EXCPs. Finally, you should always report your problems (including performance problems) to IBM service so that it will come to us directly. Our PL/I service people can help you identify this type of performance problem and its solution quickly. Rick Arellanes (IBM COBOL and PL/I Development and Performance) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
