On Thu, Dec 8, 2016 at 8:22 AM, Walt Farrell <[email protected]> wrote:
> On Wed, 7 Dec 2016 21:01:08 -0500, Phil Smith III <[email protected]> wrote: > > >It's not a specific application: we have an API that any random > application > >can use. So yes, today there are applications that are being happily > called > >from wherever. They want to add calls to our API, so they do so. Sometimes > >they need to enable things via the DD DUMMY. And yes, cognitive dissonance > >is what we'd like to avoid! Not sure what LINKLIST and STEPLIB have to do > >with anything here-those aren't the DD involved. > > Any random application? Really? > > So, how does the issuer of a CICS transaction allocate the DD to affect > how the API call operates? Or the issuer of an IMS transaction? Or the > issuer of an SQL request that invokes a DB2 stored procedure? > Oh, and to extend what Walt was saying; how does the API deal with multiple CICS transactions which invoke the API but want _different_ effects from your API. Given your example, one needs the the DD DUMMY to enable something but another needs that there not be any such DD so that it is disabled. Or worse, different users of the same transaction / program want opposite processing from the API so the DD must both be there and not be there at the same time. I will bet that the simple answer is "we don't support use of our API under CICS." Why document not the same restriction about a program run from the UNIX shell? If you say that you have users which demand that some program be run via UNIX, then you have a customer demand which you should look into addressing. If you are saying that you don't want "dual pathing", that is checking for both an environment variable and a DD existing / not existing. It is easy to run an LE program in batch and set an environment variable via CEEOPTS instead of using a DD. Of course, this is an incompatible change. Instead of: //OPTION DD DUMMY you could have (to turn on): //CEEOPTS DD * ENVAR('OPTION=TRUE') /* or have //CEEOPTS DD * ENVAR('OPTION=FALSE') /* (or no OPTION= environment variable at all) to turn OPTION off. ==== start of a new, but related, thought. Going much further afield, suppose your program is API is called MYAPI (just so I have a name). And you want to support both "regular" batch (EXEC PGM=SOMEPGM) as well as UNIX program ($ otherUNIXprogram ). Also suppose your API has a number of "options" which can be set beyond what are passed in via a CALL (which IMO, is the proper way to do it). By using an environment variable (which I will cleverly call MYAPI), you can have multiple different options set. For a UNIX program, the user might do: export MYAPI='-t -X -o /tmp/some/file' otherUNIXprogram A batch step could have: //CEEOPTS DD * ENVAR('MYAPI=-t -X -o /tmp/some/file') /* You've now got a way to pass multiple "parameters" to MYAPI separate from coding something in the user's program. But it's relatively simple for the user to use the parameters. And it works the same way in batch and UNIX shell invocations. It's just a different, new, way to approach the same problem. Just throwing out some options. If you don't like them, then you too can throw them out [grin/]. > > -- > Walt > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Heisenberg may have been here. Unicode: http://xkcd.com/1726/ Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
