Thank you, Kris. 1 stem was all I need for this job. 'PIPE stem mystem. 1 | stem mystem.' worked perfectly.
On Thu, Jul 29, 2010 at 1:46 PM, Kris Buelens <kris.buel...@gmail.com>wrote: > Mike, I want to tell that your example is a bit (very) oldfashioned. A > simple "REXXVARS" was indeed the solution, you can do the same a bit easier > by using "REXXVARS TOLOAD". It produces records like > /varname/varcontents > (John doesn't guarantee the / will be the delimiter) > So you could code: > address '' 'PIPE REXXVARS TOLOAD', > '|Strfind " MYSTEM."', > '|.... > > > A second remark: if the stem one wants to get has numbered suffixes (like > is often the case), there is no need to have PIPE obtain all variables from > the calling exec. This would do to copy it into the "current" exec/macro: > address '' 'PIPE STEM mystem. 1 |STEM mystem.' > > 2010/7/29 Mike Walter <mike.wal...@hewitt.com> > > >> XEDIT macros can be, and usually are nowadays, written in REXX. You might >> want to think a bit more about the flow of what's happening. >> >> But to answer your question more directly, inside the XEDIT macro you are >> calling from the EXEC you can execute a pipe to get the variables of the >> calling exec. For example... >> >> /* your called XEDIT macro might contain... */ >> address COMMAND , >> 'PIPE (NAME GetCallerVars)' , >> '| REXXVARS 1' , /* Access caller's vars */ >> '| STRNFIND /s/' , /* Skip source name */ >> '| SPECS W2-* 1' , /* Drop 'n' and 'v' prefix */ >> '| JOIN 1 / /' , /* Var Name and Value into 1 */ >> '| STRFIND /'xfn'./' , /* Just our xfn.xxxx vars */ >> '| NOT CHOP BEFORE STRING /./' , /* Lop our "xfn", keep .xxx */ >> , /* Load them as 'c.xxxx' so we can easily tell from our vars*/ >> '| SPECS +~C+ 1' , /* Bld: /C */ >> 'WORD 1 NEXT' , /* /C.name */ >> '+~+ NEXT' , /* /C.name/ */ >> 'WORD 2-* NEXT' , /* /C.name/value */ >> '| STRIP TRAILING' , >> '| VARLOAD DIRECT' /* Restore caller's vars in here */ >> >> Now all the calling exec's variables are available in the XEDIT macro, >> prefixed by "c." For example, if the calling exec was named FORMARK EXEC, >> and began with: >> address 'COMMAND' >> parse source xos xct xfn xft xfm xcmd xenvir . >> ... >> and the called XEDIT macro was named $FORMARK, and began with that, too... >> >> In the called XEDIT macro, xfn xft xfm would be $FORMARK XEDIT fm, while >> c.xfn c.xft and c.xfm would be FORMARK EXEC fm. >> >> If the calling exec has lots of variables you may want to trim down the >> number that you feed into the VARLOAD stage. >> >> Mike Walter >> Hewitt Associates >> The opinions expressed herein are mine alone, not my employer's. >> >> >> >> *"Mark Pace" <pacemainl...@gmail.com>* >> >> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> >> >> 07/29/2010 09:28 AM >> Please respond to >> "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> >> >> >> To >> IBMVM@LISTSERV.UARK.EDU >> cc >> Subject >> Re: rexx stem >> >> >> >> >> well I've created a stem in REXX. I want to call XEDIT to present a menu >> using the data from that stem. >> >> On Thu, Jul 29, 2010 at 10:26 AM, zMan >> <*zedgarhoo...@gmail.com*<zedgarhoo...@gmail.com>> >> wrote: >> "pass" meaning what? Insert it into the file? >> >> >> On Thu, Jul 29, 2010 at 10:25 AM, Mark Pace >> <*pacemainl...@gmail.com*<pacemainl...@gmail.com>> >> wrote: >> I'm having writers (programmers) block today. Is there a way to pass a >> REXX stem to XEDIT? >> -- >> zMan -- "I've got a mainframe and I'm not afraid to use it" >> >> >> >> -- >> Mark D Pace >> Senior Systems Engineer >> Mainline Information Systems >> >> >> >> >> ------------------------------ >> >> The information contained in this e-mail and any accompanying documents >> may contain information that is confidential or otherwise protected from >> disclosure. If you are not the intended recipient of this message, or if >> this message has been addressed to you in error, please immediately alert >> the sender by reply e-mail and then delete this message, including any >> attachments. Any dissemination, distribution or other use of the contents of >> this message by anyone other than the intended recipient is strictly >> prohibited. All messages sent to and from this e-mail address may be >> monitored as permitted by applicable law and regulations to ensure >> compliance with our internal policies and to protect our business. E-mails >> are not secure and cannot be guaranteed to be error free as they can be >> intercepted, amended, lost or destroyed, or contain viruses. You are deemed >> to have accepted these risks if you communicate with us by e-mail. > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > -- Mark D Pace Senior Systems Engineer Mainline Information Systems
