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