Frank Swarbrick wrote:
Rather than posting the same thing to the CICS, IMS and DB2 lists I'm
just posting here.
After doing some research today I'd like to make the following
assertions:
DSNELI in SDSNLOAD
● This is the TSO attach module
● DSNHLI is an alias for this module
DFHD2LI in SDFHLOAD
● This is the DB2 CICS attach module
● DSNCLI is an alias for this module
● DSNHLI is an alias for this module
DFSLI000 in SDFSRESL
● This is the DB2 IMS attach module (among other things!)
● DSNHLI is an alias for this module
● DFHEI1 (the CICS stub) is an alias for this module
● DFHEI01 (an alternate CICS stub?) is an alias for this module
● CBLTDLI, AIBTDLI and other DLI entry points are aliases for this
module
Are these assertions true? Does the above mean that we can always link
with SDFSRESL, both in batch and in CICS, to resolve DSNHLI (DB2),
DFHEI1 (CICS) and CBLTDLI/AIBTDLI (DLI/IMS) linkage?
CAF throws a small wrinkle in it:
DSNALI in SDSNLOAD
● This is the DB2 CAF attach moodule
● DSNHLI2 is an alias for this module
● This module also has a DSNHLI entry point
According to this web page
http://www.idug.org/cgi-bin/wa?A2=ind0411A&L=db2-l&P=40916 I believe
I am able to do the following:
//LINKALI JOB NOTIFY=&SYSUID
//LINKALI EXEC PGM=IEWL,
// PARM='LIST,LET,XREF,RENT,REUS,NCAL,COMPAT(LKED)'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD
//DSNLOAD DD DISP=SHR,DSN=SYS3.DSN910.SDSNLOAD
//SYSLMOD DD DISP=OLD,DSN=NEW.LOAD
//SYSLIN DD *
INCLUDE DSNLOAD(DSNAA)
INCLUDE DSNLOAD(DSNALI)
MODE AMODE(31)
ENTRY DSNALI
ALIAS DSNHLI
NAME DSNALI(R)
This copies DSNALI from SDSNLOAD into NEW.LOAD and creates the DSNHLI
alias for it (rather than DSNHLI being an alias for the TSO attach
module, DSNELI). If I include NEW.LOAD in my load module concatenation
I am able to use CAF even without specifying the ATTACH(CAF) DB2
precompile option. This I have confirmed with Cobol programs compiled
with the DYNAM option. Should work for NODYNAM as well, but I haven't
tested it.
My test CICS region is broken (security is hosed!) so I can't test my
theory about at the moment. Plus it hasn't been configured yet for DB2
attach. Anyway, I am hopeful, but I'd welcome any thoughts.
My goals are:
1) to make link-editing simple by (I hope) including one set of SYSLIB
libraries for all of my Cobol compiles (batch, batch with IMS, batch
with DB2, batch with IMS and DB2, CICS, CICS with IMS, CICS with DB2,
CICS with IMS and DB2).
2) to make "batch" load modules that contain IMS and/or DB2 calls
callable both in batch and in CICS.
Here is the SYSLIB concatenation:
SYSLIB concatenation libraries for link-edit step
● Local application load libraries
● SCEELKED
● CSSLIB (can't remember why!)
● SDFSRESL
● SDFHLOAD (not needed?!)
● SDSNLOAD (not needed?!)
● SEZATCP
This I think should (might?) work for batch programs compiled DYNAM and
CICS programs compiled NODYNAM. Might work for batch programs compiled
NODYNAM as well...?
By the by, I added CSSLIB some time ago, but I can't for the life of me
remember why. Any idea?
These are z/OS UNIX callable services.
Frank
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
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
