Date: Mon, 24 Feb 2003 19:21:07 -0000
Reply-To: secretary@dkvj.org.uk
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: DKVJ <dkvj@EASYNET.CO.UK>
Subject: Re: Bug: v8. 02 TS2M0 Win2K Pro: call execute code repetition in
batch
In-Reply-To: <9B501B3774931C469BCCCC021BE537223D443A@remailnt2-re01.westat.com>
Content-Type: text/plain; charset="iso-8859-1"
Quite right Ian, but we seem to have fallen into that uncertain space
between brief detail and overlong explanation, and you have misunderstood my
point.
The original manifestation was one I found. Here's the scenario:
Compile Macro
File assignment for external text file.
Read in file
Append to permanent data set
Release file assignment.
Get List of available files to data set
Execute data step calling macro with each of the identified (and required)
files.
This worked on more than three hundred executions with the macro being
called with a single parameter: the 10 byte file name mantissa.
Then I cleaned up the data step: attributed the variables, and wrote a
second transaction tag data set in the same step to record the file name and
record count.
This time the macro failed to work. About 1/3 of the way through the
Executed code, characters were lost that meant the generated code was
syntactically incorrect.
The Execute data step still did the same work and generated a series of
statements like this:
%MReadFle( MFil = TX20020601);
However, the code generated by the MReadFle macro was corrupt at some point
part way down the list of files.
If I removed the Attrib statements and the second data step then it worked.
If I ran the Execute data step with one, five or even ten iterations as a
test, it worked.
But 300+ generations failed at about the 160th and again two more times
later on.
My colleagues issue involved a series of data retrievals based on whether
the file had been read, and whether it was available. The files were
substantially different in a number of different types, so different files
called for different macros. Otherwise his was very little more complex,
but it also broke somewhere in the middle. It too had worked on the tests
with the Execute data step only running once or a handful of times.
In both cases, segmenting the results and running the Execute data step in
thirds or quarters reduced the number of iterations below the breakpoint,
and the jobs worked.
We did consider and work on the idea of writing the code to a file and then
call in the file. That too had issues, I suspect of a very similar nature
since I believe we had corrupt code again.
The latest problem is as follows.
One macro to establish a spawner connection, no parameters.
Execute it in open code as
%SpConnct;
and it works.
Execute it as
Data _Null_;
Set CONNECT;
Call Execute( '%SpConnct;');
Run;
and it fails.
Part of the code within the SpConnct macro is missing if you call it from
within a data step. This means you lose the ability to conditionally
execute the connect process, and perform other processing you may require
around the connection establishment.
Kind regards
David
-----Original Message-----
From: Ian Whitlock [mailto:WHITLOI1@WESTAT.com]
Sent: 24 February 2003 15:18
To: 'secretary@dkvj-cons.co.uk'; SAS-L@LISTSERV.UGA.EDU
Subject: RE: Bug: v8. 02 TS2M0 Win2K Pro: call execute code repetition
in batch
David,
In general CALL EXECUTE has two features:
1) macro is executed immediately
2) generated SAS code is dumped in stack for later execution.
One rarely uses the first feature, since it probably indicates a misuse of
macro. Although the second feature is handy, it is not necessary because
the same thing can be accomplished by writing the code to a file and then
including it. This provides one simple work around to the bug.
In a good design where there is a lot of SAS code to be generated via CALL
EXECUTE it is best to reduce the call to the form
call execute ( '%mac ( parm1 = ' || value || ", .... ) ;
where the closing quotes are hidden in the .... part. This makes a very
compact form. Precisely the information from the data set that is required
is shown without an extraneous code. Moreover, the macro is separated from
the call so it is easy to make changes to the macro code.
If this form is used it is also easy to forgo feature 1 with
call execute ( '%nrstr(%mac) ( parm1 = ' || value || ", .... ) ;
In this case the CALL EXECUTE always deals with one character string which
is dumped in the input stack unquoted and ready to execute the macro. I
suspect that you would find this structure useful in overcoming the problem
that you indicate and I would be interested to know if when the code is
written is this form whether the bug goes away.
IanWhitlock@westat.com
-----Original Message-----
From: DKVJ Cons Co UK [mailto:dkv-j_consultancies@TOTALISE.CO.UK]
Sent: Monday, February 24, 2003 7:57 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Bug: v8. 02 TS2M0 Win2K Pro: call execute code repetition
in batch
I was ice bound when I saw this first come up on the list, so I didn't reply
earlier.
The problem was originally reported on the SAS web site as SN-005243 and a
patch released in 82BA02. This was subsequently bundled in 82BB16 and seems
to have been included in a hot fix bundle 82BX04.
After taking down a Solaris server around September last year and applying
the patch 82BB16, we saw some improvement in the original problem. However,
it was not resolved in all our test cases.
The issue we saw is that code assembled with Call Execute() has pieces of
the code missing. We could demonstrate where a reduced number of iterations
of the data step containing the Call Execute() would produce flawless code.
We could also demonstrate that a smaller increase in the code added in each
Call Execute() iteration caused the generated code to be faulty.
As the SN states, the type of error depended on the code being assembled,
and would result in parts of a data or proc step missing from the generated
code.
The bad news was that after applying the hot fix to Windows clients and the
Solaris server, the problem was not completely resolved at all. We ended up
circumventing the problem by running multiple data steps with Call Execute()
code so that the amount of code generated was still below the error
threshold. Messy, but reasonably robust, despite the error threshold being
ill defined.
It was tracked to SAS Marlowe at the time, and that is how the hot fix was
found and applied. Unfortunately, although two people had independently
found the problem with different sets of code, both manifestations were too
dependent on Corporate data and a fairly complex code structure to be
replicable at SAS.
Subsequently, we found the problem again in about November when we set up
the Unix to Windows spawner connection, with a much smaller code set. The
track was re-opened, but SAS have been unable to replicate the problem.
I have finished with the client, but my office has a network that allowed me
to test for the problem connecting from WinXP to WinNT with a spawner. I
have been able to reproduce the problem, and the track is still open, and I
am managing it.
It was tracked to Europe late last year, and I believe it has been with Cary
since just after Christmas. This time, the problem arises from ONE
iteration of the Call Execute(), and generation of about fifty lines of
code. The problem is exactly as seen earlier, except that the statement
"generating many hundreds of lines of code" is clearly not true in this
case.
Anyone expecting this will completely fix the problem may be disappointed.
Equally, anyone expecting that this is just a Windows 2000 problem, or
indeed a Windows problem will be disappointed.
Kind regards
David Johnson
Date: Thu, 20 Feb 2003 00:06:20 +0000
From: SAS User <sasuser@GUILDENSTERN.DYNDNS.ORG>
Subject: Re: Bug: v8. 02 TS2M0 Win2K Pro: call execute code repetition in
batch
on Wed, Feb 19, 2003 at 07:29:22PM +0000, SAS User
(sasuser@GUILDENSTERN.DYNDNS.ORG) wrote:
> I'm seeing the following problem using the 'vv' macro from
> ftp://ftp.uga.edu/pub/sas/contrib/cntb0027
Problem (improper resolution of Macro & call execute generated code) is
confirmed fixed by applying hotfix 82BB16:
http://ftp.sas.com/techsup/download/hotfix/82_win_sbcs.html#82BB16
--
