Do not forget that the Command filter does not capture the results of CP commands. If there are CP commands in the mix, the pipeline topography will be different; they will have to be selectively sent to a CP filter.
My skeleton EXEC that is the starting point of all new EXECs that I write has Address Command as its first statement. Listen to Marty. If Mother were actively participating in the discussions, she would undoubtedly tell you the same thing, as would one of Alan Altmark's two personalities. Chuckie would tell you to ignore the advice because he intentionally tries to cause bad things to happen. Regards, Richard Schuh > -----Original Message----- > From: CMSTSO Pipelines Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Marty Zimelis > Sent: Wednesday, June 25, 2008 11:39 AM > To: [email protected] > Subject: Re: ADDRESS CMS vs ADDRESS COMMAND (was: Rita+*VAR*+CALLPIPE) > > I don't think Russ was emphatic enough in his response. The > number of cycles you'll save (or not save) is minuscule in > comparison to the amount of time and energy you'll waste > trouble shooting an exec or pipeline that fails for one > person in your shop because that person had a private FOOBAR > EXEC on their A-disk when your program was expecting the > public FOOBAR MODULE to be called. > > ALWAYS use Address Command -- because even private tools have > a way of being found and used by others (who will come back > to you for support when they fail)! > > Marty > ____________________ > Martin Zimelis > Principal > maz/Consultancy > > > -----Original Message----- > > From: CMSTSO Pipelines Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Russel Brooks > > Sent: Wednesday, June 25, 2008 2:32 PM > > To: [email protected] > > Subject: Re: [CMS-PIPELINES] ADDRESS CMS vs ADDRESS COMMAND > > (was: Rita+*VAR*+CALLPIPE) > > > > Address CMS does command resolution as if you were typing > the command > > from the keyboard prompt. Example, you don't have to enter the > > correct case of the command as the system will try the > mixed case you > > entered then UPPER case it and try again. This obviously > takes a few > > extra cycles. > > > > Address Command requires you to enter the correct command name the > > first time. Besides saving a few cycles you'll also avoid > > accidentally calling programs that you didn't intend to > call. Example > > getting an Exec when you wanted the module or nuc command. > > > > In general all tools for public use should run in Address Command. > > The only exception is when the tool provides a pseudo > command line to > > the user and then I invoke those user entered commands with Address > > CMS to simulate the keyboard prompt environment. > > > > -- > > Russ Brooks -- SVM Support (aka: RLB at STLVM5) > > TieLine: 8-543-3024 = 408-463-3024 > > [EMAIL PROTECTED] SVL-D123 > > > > Astronomy Picture of the Day: http://antwrp.gsfc.nasa.gov/apod/ > > > > > > > > > > > > "SPITZ, HOBART CTR DFAS" <[EMAIL PROTECTED]> Sent > by: CMSTSO > > Pipelines Discussion List <[email protected]> > > 06/25/2008 08:41 AM > > Please respond to > > CMSTSO Pipelines Discussion List <[email protected]> > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: ADDRESS CMS vs ADDRESS COMMAND (was: Rita+*VAR*+CALLPIPE) > > > > > > > > > > > > > > Since our site has become popular we are looking at > performance issues > > that previously were ignored. > > > > Has anyone recently quantified the performance benefits of ADDRESS > > COMMAND vs. ADDRESS CMS, or the COMMAND stage vs. the CMS > stage? We > > have common modules that we compile and EXECLOAD, so we would be > > looking only a limited set of application code to be modified for > > ADDRESS COMMAND / COMMAND stage. I presume the modules > that would be > > the best candidates for such a change would be those that > issue many > > host commands. > > > > Thanks. > > > > -----Original Message----- > > From: CMSTSO Pipelines Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of John P. Hartmann > > Sent: Thursday, May 29, 2008 4:26 PM > > To: [email protected] > > Subject: Re: [CMS-PIPELINES] FW: Rita+*VAR*+CALLPIPE > > > > >>> We don't use ADDRESS COMMAND. We exploit and depend on > > ADDRESS CMS. > > > > You be glad this is not an IBM internal forum ten years ago. > > You'd have > > needed serious attention in the burns unit. > > > > pipe='rexxvars 1|take 1|console' > > Address COMMAND > > 'PIPE' pipe > > 'RITA' pipe > > > > Gets me > > > > s CMS COMMAND RSVDLNSX REXX Q2 rsvdlnsx ? > > s CMS COMMAND RSVDLNSX REXX Q2 rsvdlnsx ? > > > > Where rsvdlns is a stage in the pipeline that runs the EXEC > with the > > test cases through a COMMAND recursion into the pipeline to > trap the > > test output and stick it at the bottom of the screen so > that it stays > > around. > > > > The only way you can see RITA's REXX program is to do a COMMAND > > recursion within the pipeline that RITA runs. Then you can > count your > > way back to something before the current pipeline set was > started and > > you will indeed find another REXX environment on the SUBCOM chain. > > > > Like I said, one has to go out of one's way to trip over this. > > > > j. > > > > > > 2008/5/29 SPITZ, HOBART CTR DFAS <[EMAIL PROTECTED]>: > > > > > John is right. I was not clear in my first note, although > > the second > > > one spells out "accessing and updating the callers > variables". Most > > of > > > the *vars* in CALLPIPEs use the numeric operand that > > accesses a higher > > > level caller's variables. As I said elsewhere, the > problem seems to > > be > > > more limited than I thought: It happens when we use > > CALLPIPE CMS XXX > > > and XXX uses PIPE ... *VAR* 1 ... . That is not a big > > enough problem > > > that we can't work around it. > > > > > > There are no RITA EXECs or PIPE EXECs. > > > > > > I meant what I said about the "pipe" global variable: > > > > > > Pipe = "rita" /* actually set from a config file, > ... or not. > > */ > > > > > > Pipe "(listerr ... )", > > > > > > We don't use ADDRESS COMMAND. We exploit and depend on > ADDRESS CMS. > > > > > > Sorry for any confusion. > > > > > > Would anyone care to answer my questions about the ALL stage? > > > > > > -----Original Message----- > > > From: CMSTSO Pipelines Discussion List > > > [mailto:[EMAIL PROTECTED] On Behalf Of John P. Hartmann > > > Sent: Thursday, May 29, 2008 2:51 PM > > > To: [email protected] > > > Subject: Re: [CMS-PIPELINES] FW: Rita+*VAR*+CALLPIPE > > > > > > >>> PIPE is "pipe", and not when it's "rita" > > > > > > You didn't mean that, right? You meant that pipes are > issued with > > > ADDRESS COMMAND PIPE and Rita is fired up with ADDRESS > COMMAND RITA, > > > right? > > > > > > If not I'll bet you half a shiny bit that you have a RITA > > EXEC around > > > (or > > > possibly a PIPE one, but that would be even more mindboggling). > > > > > > j. > > > > > > 2008/5/29 John P. Hartmann <[EMAIL PROTECTED]>: > > > > > > > I suspect Hobart is not telling us the whole truth about his > > > experiments. > > > > In particular we might be held in the dark as to which other > > operands > > > he is > > > > using on the REXX variable access stages. > > > > > > > > /* > > > > /* > > > > Signal on novalue > > > > pipe='rexxvars|take 1|console' > > > > Address COMMAND > > > > 'PIPE' pipe > > > > 'RITA' pipe > > > > Exit RC > > > > > > > > Gets me this response (as it should): > > > > > > > > s CMS COMMAND TR EXEC A1 TR > > > > CMS > > > > s CMS COMMAND TR EXEC A1 TR > > > > CMS > > > > CPU Utilization by Pipeline Specification > 29 May 2008 > > > > 20:35:34 > > > > > > > > > > > > 0.099 ( 0.099) ms total in "NoName001" (1 > > > > invocation) > > > > > > > > > > > > 2.015 ms > > > > total. > > > > > > > > > > > > Detailed output from Rita in UNNAMED RITA007. > > > > > > > > Adding MAIN to the rexxvar stage gets the same response (as it > > > should). > > > > > > > > Yes, RITA does run a REXX filter to process the output > of RUNPIPE. > > > And > > > > yes, if you go out of your way you might be able to > interfere with > > it, > > > > though I cannot think of how to do so off the top of my head. > > > > > > > > > > > > j. > > > > > > > > 2008/5/29 SPITZ, HOBART CTR DFAS <[EMAIL PROTECTED]>: > > > > > > > > That's exactly what it sounds like, but, per p.3 of > "Streamlining > > Your > > > >> Pipes", we are using RITA MODULE. (I don't think we > > actually had a > > > >> choice. :-) ) > > > >> > > > >> We use a configuration variable PIPE that we set to > RITA when we > > want > > > to > > > >> get performance info., so we know that the programs haven't > > changed. > > > >> Our pipe statements look like: > > > >> > > > >> Pipe "(listerr end ? name" > > UsedName"."ExecType"."LineNo()")", > > > >> ... > > > >> > > > >> A number of programs all show the same problem. Since these > > programs > > > >> sub-filters all receive and set the callers variables correctly > > when > > > >> PIPE is "pipe", and not when it's "rita", it would seem to be > > > something > > > >> external to the programs. > > > >> > > > >> Any ideas? > > > >> > > > >> - Hobart > > > >> > > > >> -----Original Message----- > > > >> From: CMSTSO Pipelines Discussion List > > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Rob > > van der Heij > > > >> Sent: Wednesday, May 28, 2008 5:14 PM > > > >> To: [email protected] > > > >> Subject: Re: [CMS-PIPELINES] FW: Rita+*VAR*+CALLPIPE > > > >> > > > >> On Wed, May 28, 2008 at 4:08 PM, SPITZ, HOBART CTR DFAS > > > >> <[EMAIL PROTECTED]> wrote: > > > >> > > > >> > When we run RITA and we have a filter, any *VAR* stages > > (REXXVARS, > > > >> VAR, > > > >> > VARLOAD, VARSET, etc.), in a CALLPIPE, seem to not be > > able to get > > > the > > > >> > variables that they get when we run without RITA. > > > >> > > > > >> > Are we doing something wrong? > > > >> > > > >> Could it be you have a PIPE or RITA EXEC involved. That would > > > >> introduce another level of execcomm and mess up things. > > > >> > > > >> Rob > > > >> > > > > > > > > > > > > > >
