SYSIN Task Initiation

[VAU...@vuctrvax.bitnet]

We did something similar to this a while back. I still have
my CICS startup JCL, but not the TCT entry. This is what the
last part of our startup looked like:

// EXEC DTSINIT...
NO
NO
YES
00,...
01,...
02,...
03,...

CSSN PS=BRS,NAME=BRS\
INIT SAMPLE\
/*
/. EXIT
/*
* $$ EOJ

Maryanne Vaughan
Vanderbilt University
VAUGHAN@VUCTRVAX

[Jeff Huestis]

I've been installing SQL/DS in a CICS 2.1-VSE/ESA environment, and ran into
something that I've never heard of (but haven't yet been able to get working).

The SQL installation manual says that if you code a TCT entry for CRLP support
(card-reader/line-printer), then you can put an SQL transaction into the
CICS startup job stream (after EXEC DFHSIP) and it will be invoked after CICS
initialization. But I can't find any other references to this technique in
the CICS manuals themselves. Does anybody know where to find an exhaustive
treatment of this?

Additional details:
1. Since I'm reading SIT override parameters from SYSIN/SYSIPT, I've put the
SQL transaction after the $END statement.
2. I'm doing this with DTSINIT, not with DFHSIP as in the SQL example, since
we have ICCF in our test region, not our production region.

Any further insights would be appreciated.

Jeff Huestis
Washington University Libraries

[Larry Holder]

> I've been installing SQL/DS in a CICS 2.1-VSE/ESA environment, and ran into
> something that I've never heard of (but haven't yet been able to get working).
>
> The SQL installation manual says that if you code a TCT entry for CRLP support
> (card-reader/line-printer), then you can put an SQL transaction into the
> CICS startup job stream (after EXEC DFHSIP) and it will be invoked after CICS
> initialization. But I can't find any other references to this technique in
> the CICS manuals themselves. Does anybody know where to find an exhaustive
> treatment of this?
>

> Jeff Huestis
> Washington University Libraries

We've had SQL/DS installed for a few months, and I have come up with
an alternative that works well (I agree that the manual was a
bit confusing, and this alternative isn't mentioned in it):

- Have a program, invoked by the start-up PLT, that
contains the commands:
EXEC CICS START TRANSID('CIRB') TERMID('CNSL')
EXEC CICS RETURN

- Have another program, invoked by the shut-down PLT, that
contains the commands:
EXEC CICS START TRANSID('CIRT') TERMID('CNSL')
EXEC CICS RETURN

This has worked well for us, and the messages displayed by the CIRB
and CIRT transactions will be displayed on the console.
You probably already have your VSE console 'CNSL' defined to CICS.
Also, we let all the CIRB and CIRT parameters default.
If you have any questions or follow-up on this, just e-mail direct.

Larry Holder, Sr. Programmer/Analyst Bitnet: ##09@UTMARTN
The University of Tennessee at Martin Phone: 901-587-7890
Martin, TN 38238 Fax: 901-587-7841

Software: VM/ESA 1.0, VSE/ESA 1.1, CICS/VSE 2.1, COBOL-II, DL/I, SQL/DS
Hardware: IBM 9221-150 with 9336 FBA dasd
PSW: (Personal Status Words): Saved by grace (Romans 1:16 & 8:38)

[(LONGLEGS)]

We take a different approach to running non-terminal transactions at
startup. We are on CICS 2.1.2 now, but this has been used since our 1.6
days. We have two datasets concatenated to a sequential terminal (defined
in the TCT). This sequential terminal is coded to be out of service. As a
part of our startup, we write transaction commands into the second of the
two datasets concatenated to the SAMIN DD card (the first dataset contains
commands always executed), and when our startup program finishes adding
commands to the file, it issues a CEMT command to set the line inservice.
We use this to set up automatic monitoring for new programs added to our
production regions (using OSI (excuse me, CA) - Intertest), but it should
work equally as well for anything. Ask if you want details.

-Joel Dunn
UNC-Chapel Hill Administrative Data Processing