LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2010, week 5)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Sun, 30 May 2010 11:12:58 -0400
Reply-To:     Jesper Sahner Pedersen <jespersahner@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jesper Sahner Pedersen <jespersahner@HOTMAIL.COM>
Subject:      Re: Remote submit macro-generated code
Comments: To: Søren Lassen <s.lassen@POST.TELE.DK>
Content-Type: text/plain; charset=ISO-8859-1

Hi again Søren,

Some comments: - uploading macros will save time but macros will have to be maintained on more than one platform (regular uploading will of course limit this problem) - uploaded macros can be used independently on the remote platform. - transferring macros with every session only takes few seconds - transferring macros with every session keeps the remote platform "thin" and any remote CPU available can be used.

I use the following setup: - macros on mainframe are stored in catalogs (I wrote some code that loops through members in a PDS-dataset translating danish special characters to make the macros platform-independent) - SAS is run with options=NONLSCOMPATMODE - datasets are not entirely platform-independent, so data is created on PC using the datastep-option outrep= - uploading/inheriting macros is optionally.

With this setup a mainframe-program can be run optionally on mainframe or a remote PC. Of course when run on a remote PC time used to transfer data up and down must be taken into recognition. However - and this really surprises me - even with data transfer-time included one of my most CPU/memory- consuming programs runs at least 3 times faster (!) on a remote PC (laptop/2GHz/2GB RAM/32 bit) than on mainframe (z/OS).

The setup is possible since libnames are "platform-independent". I wonder if same is possible with filenames (using a proper engine to read a mainframe PDS-dataset from a remote PC) which would make the setup even cleaner(?)

Regards, Jesper

On Mon, 17 May 2010 17:36:50 -0400, S=?ISO-8859-1?Q?=C3=B8ren?= Lassen <s.lassen@POST.TELE.DK> wrote:

>Ah, yes, but that was not the question you originally asked... > >A catalog may be a good way to make a file library available across >sessions. Or may be a url filename (would that work? God knows, if she >is a SAS user). > >As Paul already suggested, it is probably easier to download (sorry, >upload, even though you are going from the mainframe to Windows) the >macro library. I think it can be done with a wildcard ("*" for member name). > >If you are going to do a lot of remote processing, either offloading >compute-intensive stuff from the mainframe, or just trying to get >good old OPC to keep track of your Windows jobs (excellent idea, >I suggested it a lot of times, but then I get the impression that people >think I am crazy when I do), one possible bottleneck is the bandwidth >of the connection between the two computers. If you allocate the >macro library in a catalog on the mainframe, all the macros that you >(auto)call will have to be transferred anew with every session; if you >upload them, the macros will be right there on the server's harddisk. >May be quite a lot faster. > >Please keep me informed about your progress, sounds like an exiting >project. > >Cheers, >Søren > > >On Sun, 16 May 2010 11:56:39 -0400, Jesper Sahner Pedersen ><jespersahner@HOTMAIL.COM> wrote: > >>Hi Søren, >> >>I agree, when macros are runtime dependent, it is more complicated. >> >>However, in order to inherit client-macros in the server-session you can >>store the macro in a SAS-catalog and use the inheritlib-option, like this: >> >>libname cat "g.bscla.macro.catalog" disp=old; >>filename ud catalog "cat.macros.xyz.source"; >> >>data _null_; >> file ud; >> put '%macro xyz;' >> /'data test;' >> /'do i=1 to 10;' >> /' output;' >> /'end;' >> /'run;' >> /'%mend;'; >>run; >> >>rsubmit inheritlib=(cat); >> filename macros catalog 'cat.macros'; >> options sasautos=(sasautos macros); >> %xyz; >>endrsubmit; >> >>This works fine! >> >>In my setup macros are stored in PDS-datasets on a MVS. I don't know if it >>is possible to inherit PDS-datasets directly (?), but as the example shows >>using a SAS catalog as container works fine. >> >>In general one might consider to store MVS-macros in SAS catalogs instead >of >>PDS-datasets since SAS-catalogs are kind of "platform-independent". >> >>Regards, >>Jesper >> >>On Sun, 16 May 2010 09:39:49 -0400, S=?ISO-8859-1?Q?=C3=B8ren?= Lassen >><s.lassen@POST.TELE.DK> wrote: >> >>>Jesper, >>>You may be able to do that with some very simple macros, >>>but as soon as things get a little complicated, it will not work. >>> >>>When macros get more complicated, the code to be submitted will depend on >>>the state of the world as it is when the macro is interpreted. In other >>>words, this may work: >>> >>>%macro print(ds); >>> proc print data=&ds; >>> run; >>>%mend; >>> >>>%let code=%str(rsubmit;%print(test)endrsubmit); >>>&code >>> >>>But this will probably not: >>> >>>%macro print(ds); >>> %if %sysfunc(exist(&ds)) %then %do; >>> proc print data=&ds; >>> run; >>> %end; >>> %else %put Dataset &ds not found; >>>%mend; >>> >>>%let code=%str(rsubmit;%print(test)endrsubmit); >>>&code >>> >>>The problem is that the print procedure will be executed on the >>>server depending on whether a table named TEST exists on the client. >>> >>>Regards, >>>Søren >>> >>>On Fri, 14 May 2010 21:27:41 -0400, Jesper Sahner Pedersen >>><jespersahner@HOTMAIL.COM> wrote: >>> >>>>Hi, >>>> >>>>Consider the following situation: >>>>%macro xyz; >>>> /* ..SAS-code.. */ >>>>%mend; >>>> >>>>rsubmit; >>>> %xyz >>>>endrsubmit; >>>> >>>>This will not work since %xyz is not evaluated on the clint-side BEFORE >>>>rsubmitting to the server, and the macro 'xyz' is not known by the >server. >>>> >>>>How can I evaluate %xyz BEFORE rsubmitting to the server? >>>> >>>>The idea of course is that the server doesn't need to know about macros >on >>>>the client (often many macros!), if macro-evaluation is done BEFORE >>>rsubmit. >>>> >>>>Regards, >>>>Jesper


Back to: Top of message | Previous page | Main SAS-L page