afaik you still need a terminal to run the task that starts
ckti.
here is a way you could set up multiple ckti transaktions with
automatic restart (only the "default" CKTI is restartet when
CICS disconnects / reconnects from/to MQ).
i wrote a xephon article for it which got published
at the end of 2002 so you may find it there too...
setup a console with the cics stc userid (or whatever userid you
prefer)
transaction A starts transaktion B on the console. transaction
B reads a namelist holding INITQ names and starts as many ckti
as required.
this can either be used manually or by operation automation tools
or whatever exists in your environment.
one way to make it happen automatically is to use ckti to trigger
this procedure.
so have a "default" ckti/initq in your cics system
define a local queue ("control"), put in a persistent message, trigger
first,
"default" initq, process A (transaction a)
whenever the default ckti becomes active (cics start, adapter
reconnect, ...) the default initq is opened. because of this the
"control" queue gets triggered and transaction A is started,
this will start transaction B at the specified console, and
B will start the CKTI transactions.
so you have automatic start and restart, you can add / remove
initqs during cics run without restart by editing the
namelist and force a trigger manually....
just one way to accomplish multiple ckti.....
regards
stefan
-----Ursprüngliche Nachricht-----
Von: Miller, Dennis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 28. Januar 2003 21:20
An: [EMAIL PROTECTED]
Betreff: Re: Wish list for Conference
Just an idea...I don't have it working. I thought IBM lifted the restriction
on termid in CICS V3 or V4. I know you have to setup surrogate authorities
differently if there is no termid, but I didn't think it was a show stopper.
> -----Original Message-----
> From: Bullock, Rebecca (CSC) [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 11:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Wish list for Conference
>
> Thanks, Dennis. Actually, I think I played around with this and finally
gave
> up. It wasn't as easy as I thought it would be. As I remember (and it's
hazy
> since it was a long while back), the problem was that there's no terminal
> facility to tie the userid to. But thanks for suggesting it. (Or did you
> have a working model?)
>
> -----Original Message-----
> From: Miller, Dennis [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Wish list for Conference
>
>
> > Sure would be nice to be able to easily restart the CICS trigger monitor
> > and end up with the address space userid, the same as you get when it's
> > started from the PLT.
>
> Doesn't seem like much of a stretch to write a small program to accomplish
> that.
>
>
> Something like:
>
> EXEC CICS ASSIGN STARTCODE(MYSTART) END EXEC
>
> IF MYSTART NOT EQUAL "SD"
> MOVE 'CKQC STARTCKTI' TO mydata (or build CKQC commarea
> from input source)
> EXEC CICS START(EIBTRNID) FROM (mydata ) USERID(myuserid) END-EXEC
> EXEC CICS RETURN END-EXEC
> END IF
>
> EXEC CICS RETRIEVE INTO(mydata) END EXEC
> EXEC CICS LINK PROGRAM('CSQCSSQ ') INPUTMSG(mydata)
> EXEC CICS RETURN END-EXEC
>
>
>
>
> > -----Original Message-----
> > From: Bullock, Rebecca (CSC) [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 28, 2003 9:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Wish list for Conference
> >
> > Well, of course, some of us won't get to go to the conference :-( so I
> guess
> > the choice is to put 'em here. Here's a list I came up with...
> >
> > 1) I'd like to strongly second an earlier wish to have Java clients
> support
> > channel tables. I need this and I need it badly.
> >
> > 2) Also a Java thing. First, understand I'm not a Java programmer, but
the
> > impression I've gotten from reading others' postings (and I may be wrong
> > here) is that if you're using the Java client, you must specify the
userid
> > and that Java won't pick up the userid from the task issuing the MQ
calls.
> > OK, if it's possible within the constructs and constraints of the
> language,
> > please make a change so that the userid is picked up from the task's
> userid
> > automatically, similar to the situation with the regular C client on an
NT
> > box.
> >
> > 3) I think many of us have seen the problem of not being able to start a
> > channel when there are duplicates in the channel SYNCQ. The fix is to
get
> a
> > utility from IBM (CSQ4SYNC on OS/390 and I'd guess there's something
> similar
> > on the distributed qmgrs). It would be nice if that utility were
> distributed
> > as part of the product. And, after all, what harm is there? If it's not
> the
> > problem and there are no duplicates, nothing will be deleted.
> >
> > 4) Sure would be nice to be able to easily restart the CICS trigger
> monitor
> > and end up with the address space userid, the same as you get when it's
> > started from the PLT.
> >
> > 5) It seems that people are often asking from help with shutdowns. How
> about
> > sample startup and shutdown scripts for the distributed environments? At
> > least it would get people started.
> >
> > 6) Based on an (unpleasant) experience where a Solaris sysadmin
installed
> MQ
> > on a server for me and then we couldn't get crtmqm to work after putting
> on
> > the latest CSD... How about removing the part of the install script that
> > allows you to loop back and select another option to install? Or at
least>
> a
> > warning that if you do that, trouble will ensue. And, if possible, how
> about
> > listing out interpreted CLASSES when you do a pkginfo? (Can you do
that?
> I
> > don't know.) I learned more than an OS/390 person should ever need to
know
> > about Solaris install scripts and packages as a result of this simple
(and
> > very human) error.
> >
> > 7) Now here's one that I don't really expect anyone from IBM to take
> > seriously, but I'm putting here anyway: How about some doc on setting up
> MQ
> > mainframe security in a nonRACF environment? This is actually a concern
> with
> > a multitude of IBM products for those of us in ACF2 shops (and, I would
> > guess, other security packages, too). There's always a lot of "well,
let's
> > try this and see what happens". It's messy and error-prone. Actually,
this
> > would be a good collaborative project for those of us in this situation.
> >
> > Anyway, that's my semi-short list. Have fun in Las Vegas!
> >
> > -- Rebecca
> >
> > Rebecca Bullock
> > Computer Sciences Corporation
> > MFCoE/Newark CS Team
> >
> > Educational Testing Service Account>
> > Princeton, NJ 08541
> >
> > email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> >
> >
> >
> >
> >
**************************************************************************
> > This e-mail and any files transmitted with it may contain privileged or
> > confidential information. It is solely for use by the individual for
whom
> > it is intended, even if addressed incorrectly. If you received this
e-mail
> > in error, please notify the sender; do not disclose, copy, distribute,
or
> > take any action in reliance on the contents of this information; and
> delete
> > it from your system. Any other use of this e-mail is prohibited. Thank
you
> > for your compliance.
> >
> > Instructions for managing your mailing list subscription are provided in
> > the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>
>
> **************************************************************************
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and
delete
> it from your system. Any other use of this e-mail is prohibited. Thank you
> for your compliance.
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
