Re: Performance in S9(08) COMP
On Wed, 15 Oct 2014 12:08:05 -0500, Ron Thomas ron5...@gmail.com wrote: Ok. So what i understand is there will not be a performance degradation , the compiler option in our installation is set as Trunc(bin). Thanks Ron T -- You might want to read the COBOL Performance Tuning paper (for Enterprise COBOL 4.2) at: http://www-01.ibm.com/support/docview.wss?rs=203q=7018287uid=swg27018287 to see the performance implications of various compiler options, run-time options, data types, and other factors. Rick Arellanes IBM Tools Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Allocation in COBOL
Here is how you can do it in COBOL directly:
Define a structure like this (for setenv; you only need the ENV-VALUE part for
putenv):
01 ENV-VARS.
05 ENV-NAME PIC X(8).
05 ENV-VALUE PIC X(100).
05 ENV-OVERWRITE PIC S9(8) COMP.
Then set the environment variable (the name is the DDNAME) using one of the
following:
MOVE zINFILE TO ENV-NAME. (INFILE is the input
DDNAME)
MOVE zDSN(HLQ.INPUT(MEM1)),SHR
TO ENV-VALUE.
MOVE 1 TO ENV-OVERWRITE.
CALL setenv USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE.
MOVE zOUTFILE TO ENV-NAME.(OUTFILE is the output
DDNAME)
MOVE zDSN(HLQ.OUTPUT),NEW,UNIT(SYSDA),DELETE,SPACE(4,4)
TO ENV-VALUE.
MOVE 1 TO ENV-OVERWRITE.
CALL setenv USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE.
MOVE zCARDIN=DSN(HLQ.CARDIN),SHR TO ENV-VALUE.(CARDIN is another input
DDNAME)
CALL putenv USING ENV-VALUE.
You can also set an LE environment variable using PARM.GO like this:
PARM.GO=('/ENVAR(CARDIN=DSN(HLQ.CARDIN),SHR)')
Then OPEN the file. Our run-time logic checks to see if a DD for the DDNAME is
already allocated and if not, it will use the environment variable name that
matches the DDNAME to allocate it. The DDNAME stays allocated after CLOSE.
However, when you OPEN the file again, the run-time logic checks to see if the
environment variable has changed. If so, it will deallocate the DDNAME and
reallocate it using the new parms.
For more info on the parms that you can use for the dynamic allocation support,
see:
QSAM:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg50/1.9.4.1
VSAM:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg50/1.10.6.3
LINE SEQUENTIAL:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg50/1.11.3
Rick Arellanes (IBM COBOL Development and Service)
On Fri, 6 Sep 2013 09:06:25 -0500, John McKown john.archie.mck...@gmail.com
wrote:
setenv does not _directly_ do a dynamic allocation. It sets up an LE
environment variable, which has the same name as what is normally
considered the DD name. If the DD name in the SELECT in COBOL is not
already allocated, _and_ an LE environment variable is properly set up,
_then_ the COBOL run time will do a dynamic allocation.
BPXWDYN can be used as already mention.
Before either of the above was available, I had code which use IKJTSOEV to
set up a TSO environment and then did a TSO ALLOCATE command. I got this
from Gilbert Saint-Flour.
WORKING-STORAGE SECTION.
01 FILLER.
05 WS-DUMMYPIC S9(8) COMP.
05 WS-RETURN-CODE PIC S9(8) COMP.
05 WS-REASON-CODE PIC S9(8) COMP.
05 WS-INFO-CODEPIC S9(8) COMP.
05 WS-CPPL-ADDRESS PIC S9(8) COMP.
05 WS-FLAGSPIC X(4) VALUE X'00010001'.
05 WS-BUFFER PIC X(256).
05 WS-LENGTH PIC S9(8) COMP VALUE 256.
PROCEDURE DIVISION.
CALL 'IKJTSOEV' USING WS-DUMMY
WS-RETURN-CODE
WS-REASON-CODE
WS-INFO-CODE
WS-CPPL-ADDRESS.
IF WS-RETURN-CODE ZERO
DISPLAY 'IKJTSOEV FAILED, RETURN-CODE=' WS-RETURN-CODE
' REASON-CODE=' WS-REASON-CODE
'INFO-CODE='WS-INFO-CODE
MOVE WS-RETURN-CODE TO RETURN-CODE
GOBACK
END-IF.
MOVE 'ALLOCATE DD(SYSPUNCH) SYSOUT HOLD' TO WS-BUFFER.
CALL 'IKJEFTSR' USING WS-FLAGS
WS-BUFFER
WS-LENGTH
WS-RETURN-CODE
WS-REASON-CODE
WS-DUMMY.
IF WS-RETURN-CODE ZERO
DISPLAY 'IKJEFTSR FAILED, RETURN-CODE=' WS-RETURN-CODE
' REASON-CODE=' WS-REASON-CODE
MOVE WS-RETURN-CODE TO RETURN-CODE
GOBACK
END-IF.
DISPLAY 'ALLOCATE WORKED ! ' UPON SYSPUNCH.
I like BPXWDYN best in today's environment. It seems the easiest to
understand and code.
On Fri, Sep 6, 2013 at 8:45 AM, Mark Jacobs mark.jac...@custserv.comwrote:
Looking at this IBM Technote, it implies they will.
http://www-01.ibm.com/support/**docview.wss?uid=swg21046577http://www-01.ibm.com/support/docview.wss?uid=swg21046577
Mark Jacobs
On 09/06/13 09:43, Charles Mills wrote:
I don't *think* CEEENV or setenv will do dynamic allocation.
That might be a good reason to pick BPXWDYN.
Charles
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@listserv.ua.**EDUIBM-MAIN@LISTSERV.UA.EDU]
On
Behalf Of Mark Jacobs
Sent: Friday, September 06, 2013 4:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dynamic Allocation in COBOL
This might not be the right forum for this question, but...
Doing some very limited in initial research I've found three documented
methods
Re: Reading PDS/PDSE members from within COBOL in a loop
The answer is yes, you can use COBOL to read a PDS directory and process each member separately. Define 2 files: 1 (PDS-DIR) to read the PDS directory and one (PDS-FILE) to read each member. The one to read the directory (PDS-DIR) is RECORDING MODE U with a record of PIC X(256). The other (PDS-FILE) is to read the member (e.g., RECORDING MODE F with a record of PIC X(80)). Define a LINKAGE SECTION item to map the PDS directory layout (you can find this in the DFSMS books). Now, use the COBOL built-in dynamic allocation support to open the PDS directory (do not define a DD statement in the JCL for these files since COBOL's dynamic allocation support will be bypassed if a DD already exists): MOVE zPDSDIR TO ENV-NAME MOVE zDSN(HLQ.PDSTEST).SHR TO ENV-VALUE MOVE 1 TO ENV-OVERWRITE CALL setenv USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE OPEN INPUT PDS-DIR Loop to read the PDS directory to get each member name and process the memberl stop when you reach the end To process each member: MOVE zPDSFILE TO ENV-NAME Use INSPECT and STRING to build the PDS data set name with member name in ENV-VALUE in the form of DSN(HLQ.PDSTEST(MEMBER)),SHR with a null termination MOVE 1 TO ENV-OVERWRITE CALL setenv USING ENV-NAME, ENV-VALUE, ENV-OVERWRITE OPEN INPUT PDS-FILE Read each record until EOF CLOSE PDS-FILE and repeat the processing with the next member CLOSE PDS-DIR When you change the ENV-VALUE for each DD name, COBOL will do the dynamic deallocation and dynamic allocation again using the new values. The ENV-xxx values are defined as: 01 ENV-VARS. 05 ENV-NAME PIC X(9). 05 ENV-VALUE PIC X(100). 05 ENV-OVERWRITEPIC S9(8) COMP. Rick Arellanes (IBM COBOL Development) On Sat, 6 Jul 2013 22:31:22 -0500, Ze'ev Atlas zatl...@yahoo.com wrote: Hi All I would assume that this question was asked many times before, but I could not have yet find the answer. I need to write a native z/OS COBOL program and it cannot be done in any of the other popular languages or environments for the reasons enumerated below. The program should be a driver that gets a PDS or PDSE library name, reads the directory of that library and then opens each member in turn in a loop and reads it and apply some process that uses calls to some LE package. Could that be done and is there any freely available sample code? Reasons why I cannot use other solutions I know that there are other GREAT solutions, by far better then my solution. I agree in advance with anybody who has a better solution, but I am not interested: I do not know PL/I well enough and am not interested in improving my knowledge. Rexx would not cut it in this case because Rexx interface with persistent LE environment is complicated I know how to do it in Assembler but I am refraining from coding in Assembler any more It cannot be using USS as the whole purpose of the project is doing something from within native z/OS. I am not interested in the existing IBM (or vendor) utilities since I need to apply my process to each member and each line in that member. Also, vendor utilities may not be available to everybody. The only solution other then COBOL driver that I could consider is if it could be done from within the SORT utility (as the driver) because of its ubiquity, but I could not figure out whether and how it could be done. Thanks ZA -- 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
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. COBOL does support the CALL statement under CICS even when you have EXEC CICS statements in the called programs. Please see the Migration Guide at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg50/5.4.1.3 or the before mentioned COBOL Performance Tuning paper on pages 28-29. Both of these tell you how to add the required parms: If your Enterprise COBOL program was processed by a CICS translator (either separate or integrated), then a caller of that program must pass the CICS EXEC interface block (DFHEIBLK) and the communication area (DFHCOMMAREA) as the first two parameters of the CALL statement. If your Enterprise COBOL program was not processed by a CICS translator, then you need to pass DFHEIBLK and DFHCOMMAREA only if they are explicitly coded in the called subprogram. Rick Arellanes IBM COBOL Development and Performance -- 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
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
Re: COBOL 3.4 and LE Considerations questions
LE does support downward compatibility when using OS/390 2.10 and later, but you must follow the giudelines and restrictions listed in the LE Programming Guide in section 1.2.2 Downward compatibility considerations found here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea21c0/1.2.2 Rick Arellanes IBM COBOL Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
