Re: subroutine storage can be used by another?
- From: terry.sambrooks@xxxxxxxxxxx (Terry Sambrooks)
- Date: 13 Jun 2006 00:27:12 -0700
Hi Liao,
<wenson_liao@xxxxxxxx> wrote in message
news:<1150113090.469974.23770@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>...
Hello All
Recently,I wrote a COBOL program A which call subroutine B and C
statically,B and C are assembler,
the function of subroutine B is:
1)modify RECSIZE and BLKSZIE of a dataset by RDJFCB and OPEN macro
2)then pass the DCB address to program A
the function of subroutine B is:
1) PUT a record according to DCB address
The program A executed well!
But,when I add some code to make it could access a DB2 table, it
executed abend 0C4, the ceedump as follow:
Given the above information from the original poster, I am not sure other than for training purposes why this is being attempted.
As the objective is to write a record to an output data set, which appears to have consistent attributes during execution but which may differ from execution to execution, the question arises "Is Assembler needed at all?"
Provided the Cobol program is correctly defined to cater for the variety of output circumstances surely the requirement can be met simply by changing the LRECL externally, i.e. either in the JCL or via use of a pre-allocated data set. Use of System Determined BLKSIZE (SDB) should satisfy the need to change LRECL and BLKSIZE. (But is RECSIZE a term used more frequently with VSAM.)
If an Assembler routine needs to be in equation then I would agree with Bill Klein that the usual way for achieving the linkage between Cobol and Assembler is for the Cobol program to perform the Call passing the FD name (DCB) as a parameter, i.e. program A contains "CALL 'B' Using FD-outfile"
Within Program B DSECT IHADCB can be used as an overlay (effectively REDEFINES) of the DCB with the LRECL and BLKSIZE values being changed directly via use of the appropriate labels. I am reasonably certain that there is no need to resort to RDJFCB to do this given the OPEN/MERGE sequence. Open for non-VSAM files will merge attributes from Program, JCL, and File (DSCB) in that order so if the DCB is changed there should be no need to update the JFCB (JCL). (I believe RDJFCB need authorisation if updating fields so my suggestion avoids that particular security issue.)
To write the record program A simply issues "CALL 'B' Using FD-outfile, outarea"
I have deliberately avoided the issues of dynamic allocation, and VSAM files. The above comments are specifically related to non-VSAM files. (I have not used them in anger, but the use of the MODGEN macro within an Assembler routine is likely to be a requirement for VSAM.)
I have used the techniques described to alter the DDNAME of a file, so that a Cobol program has a single FD, but multiple DD statements processed consecutively, and in that instance an Assembler routine is necessary.
Kind regards - Terry
Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
Tel: +44 (0)114 262 0933
WEB:
www.legac-e.co.uk
www.kmsitltd.co.uk
Reg: England & Wales 3767263 at the above address
All outgoing E-mails are scanned but it remains the recipients responsibility to ensure that their system is protected from viruses, trojans, worms, and spy-ware.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Article in Z/Journal about COBOL
- Next by Date: Re: Decide whether programs invoked by a JCL exist
- Previous by thread: subroutine storage can be used by another?
- Next by thread: Re: subroutine storage can be used by another?
- Index(es):
Relevant Pages
|
