Plenty of ways to skin a cat and plenty of cats to skin :-) KISS is important here. The more complex the solution, the more fragile.
Why not use the FTP strategy? That is, the STC drives a FTP process to submit the job and retrieve the result. This is a snap in REXX. One concern, if the STC is single thread, then waiting for something may not be a good idea. But I think you have the right idea: regroup and take a hard look at the root business/technical problem you are trying to solve. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Wednesday, February 01, 2012 8:03 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Intrdr All, As someone once said there are about a dozen ways to do something...I need to regroup and review. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 1, 2012, at 8:26 AM, "McKown, John" <john.mck...@healthmarkets.com> wrote: > Being a bit of a UNIX partisan, I'd do a fork()/exec() to run the > application. You'd fork()/exec() "/bin/sh -c" to run a UNIX REXX script. This > UNIX REXX script uses ADDRESS TSO to run a TSO REXX program (yes, it's > getting complicated) to do what the JCL usually does. When the TSO REXX > finishes, the UNIX REXX script continues, and subsequently finishes. When the > UNIX REXX script finishes, the shell finishes and the originating program can > be informed via a SIGCHLD signal. Or it can just "hang" itself in a UNIX > wait(). > > If you're really good, you may not need the TSO REXX. I just think it's > easier to convert JCL to TSO REXX than UNIX REXX. > > OK, this is likely going overboard. It would require a major rewrite of the > STC's current code. But it does give an example of running another process > asynchronously with the originator being informed of completion. > > Of course, depending on what the STC is doing in the mean time, the creation > of the dataset can be eliminated by using a named pipe, or perhaps even an > anonymous pipe. Have the asynchronous process write to the named pipe. Have > the main STC read from it. The main STC will "wait" in the "read" of the pipe > until the subprocess starts writing. And will get an EOF on the pipe when the > subprocess does a CLOSE on it. Come to think of it, this will even work with > a batch job submitted via the INTRDR, so long as you are running on the same > system. If you really need the dataset for later, have the final step of the > batch job use IEBGENER to copy the dataset contents to the named pipe. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential > or proprietary information. If you are not the intended recipient, > please contact the sender by reply e-mail and destroy all copies of > the original message. HealthMarkets(r) is the brand name for products > underwritten and issued by the insurance subsidiaries of > HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), > Mid-West National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > > > >> -----Original Message----- >> From: IBM Mainframe Discussion List >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Hunkeler Peter (KIUP 4) >> Sent: Wednesday, February 01, 2012 1:12 AM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Intrdr >> >>> There is a STC running , similar in characteristics as CICS, runs >>> all >> the time. >>> Submits a job via Intrdr, job creates a Qsam file, STC must wait for >> job to complete, >>> Because STC needs the data and it is single thread... >> >> Why does it have to be a submitted job? Can't you just link to the >> program, or programs one after the other, that create the file? >> Knowing more about this requirement might trigger new ideas. >> >> -- >> Peter Hunkeler >> >> --------------------------------------------------------------------- >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
