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
Content-Type: text/plain; charset=ISO-8859-1
Hi again Søren,
- 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(?)
On Mon, 17 May 2010 17:36:50 -0400, S=?ISO-8859-1?Q?=C3=B8ren?= Lassen
>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
>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
>On Sun, 16 May 2010 11:56:39 -0400, Jesper Sahner Pedersen
>>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";
>> file ud;
>> put '%macro xyz;'
>> /'data test;'
>> /'do i=1 to 10;'
>> /' output;'
>> filename macros catalog 'cat.macros';
>> options sasautos=(sasautos macros);
>>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
>>PDS-datasets since SAS-catalogs are kind of "platform-independent".
>>On Sun, 16 May 2010 09:39:49 -0400, S=?ISO-8859-1?Q?=C3=B8ren?= Lassen
>>>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:
>>> proc print data=&ds;
>>>But this will probably not:
>>> %if %sysfunc(exist(&ds)) %then %do;
>>> proc print data=&ds;
>>> %else %put Dataset &ds not found;
>>>The problem is that the print procedure will be executed on the
>>>server depending on whether a table named TEST exists on the client.
>>>On Fri, 14 May 2010 21:27:41 -0400, Jesper Sahner Pedersen
>>>>Consider the following situation:
>>>> /* ..SAS-code.. */
>>>>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
>>>>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
>>>>the client (often many macros!), if macro-evaluation is done BEFORE