Date: Sat, 29 Mar 2003 00:59:14 -0700
Reply-To: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
Subject: Re: hot fix 82BB16, 82BB32,
82BX04: Call Execute() generates trun cated code...
Content-Type: text/plain; charset=us-ascii
In a code such as that shown below, I would create file CODE using the
catalog engine, and place it in the WORK library:
filename x catalog 'work.code.code.source';
Two advantages of this approach: it's system-independent, so you don't
have to worry about changing the physical filename if you port your
program; and it's automatically cleaned up when SAS exits, or by the
cleanup program if SAS abends.
Your point about making sure that all PUTs are immediately preceded by
a FILE statement is a good one. Perhaps we should request a PUTFILE
statement, which would have exactly the same function as a PUT statement
except that the first parameter would be a file name, e.g.
putfile log 'this is a debugging statement';
This would allow the use of your call_execute macro regardless of the
presence or absence of FILE statements in the surrounding code, and
would make it easier to write to the log or an external file during
debugging as well.
I use the technique of writing to a temporary file and then %INCLUDEing
it fairly often, but I usually take advantage of all the power of the
PUT statement when I do so, rather than writing a single string
variable. It's often convenient to use the $QUOTE function, and using
newlines and leading blanks makes the resulting log even easier to read.
I would not, however, abbreviate %INCLUDE to %INC. I also explicitly
clear the filename after I'm through with the file. I usually don't
bother to delete the catalog entry, but I could use PROC CATALOG to do
so I thought the program would run out of space.
--
JackHamilton@FirstHealth.com
Manager, Technical Development
Metrics Department, First Health
West Sacramento, California USA
>>> "Ian Whitlock" <WHITLOI1@WESTAT.COM> 03/28/2003 8:25 AM >>>
David,
It is not clear that you want a workaround to the problem, but here is
one
relatively easy to implement on a large program filled with many CALL
EXECUTEs.
As long as you do not use CALL EXECUTE to ececute macro instructions
that
will be acted upon later in the DATA step, you could use the technique
shown
below to modify the code. Just 3 changes are required when the
autocall
library contains the macro CALL_EXECUTE given below.
1) change each CALL EXECUTE to %CALL_EXECUTE
2) place filename with fileref CODE before the DATA step
containing a CALL EXECUTE
3) place %INC CODE ; after the DATA step.
%macro call_execute ( string , file = code ) ;
file &file ;
length __string $32767 ;
drop __string ;
__string = &string ;
put __string ;
%mend call_execute ;
/* test code */
%macro mac ( p ) ;
%put mac called with parm=&p ;
%mend mac ;
filename code temp ;
data _null_ ;
do x = 1 to 5 ;
%call_execute ( '%mac(' || put (x,2.) || ")" ) ;
string = "data w" || put(x,2.-l) || "; y = 1 ; run ;" ;
%call_execute ( string ) ;
end ;
run ;
%inc code ;
You will get into trouble with the above, if CODE is a fileref in the
program, or if you are not in the habit of protecting PUTs with an
immediately preceding FILE statement.
One advantage to this fix it that it will probably speed up the code
and
make the log easier to read.
IanWhitlock@westat.com
-----Original Message-----
From: ListServer [mailto:reply@SASL.NO.SPAM]
Sent: Friday, March 28, 2003 1:18 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: hot fix 82BB16, 82BB32, 82BX04: Call Execute() generates
truncated code...
There have been a number of people posting problems regarding Call
Execute()
truncating code.
The original problem number is SN005243.
The first fix for the problem was 82BA02.
It was subsequently grouped into 82BB16.
It has been grouped again into 82BB32.
It is now part of Hot Fix bundle 82BX04.
I have participated in a number of discussions on SAS/L over this issue
and
reported the following findings:
Solaris 8, SAS 8.2, applied 82BB16, some manifestations cleared up,
some
remain.
Windows NT and Windows XP, applied 82BB16, all tested manifestations
remain.
After discussions stretching back to around September last year, the
problem
I reported has been replicated, tracked to Germany and finally to
Cary.
The current report is "Cary has confirmed that this is a problem and a
defect has been raised. I can't give any indication on when it may be
solved
but from early indications it looks like it will be fixed in V9.1.
There is
no circumvention except not to use call execute."
If you think that I should have applied 82BB32, the following birdie's
reply
will interest you: "I can confirm that the 16 & 32 packages contain the
same
hotfix.".
Despite all that may have been said, this problem does still exist.
There
is evidence that applying the hotfix BB16 or BB32 will clear up some
circumstances.
However, the replicated problem is one macro being called conditionally
by a
data step ONCE only. The macro contains less than 1kb of code. The
problem
was reported to be linked to the amount of code generated. This is
not
correct.
If SAS is running on a single user machine, you may care to try the
hotfix
for this problem. You can back it out later on.
If it is a shared machine, then the decision is harder. Had I known
what I
now know, the Solaris would never have had the patch applied.
Kind regards
David Johnson
