Desktop productivity for business analysts and programmers

The Perils of DOSUBL

Reply
Frequent Contributor
Posts: 100

The Perils of DOSUBL

So, I've been running some programs with my spiffy new upgrade to SEG 7.12, but alas all is not well.  I was getting an odd error as follows:

ERROR:  An exception has been encountered.
Please contact technical support and provide them with the following traceback information:
 
The SAS task name is [DATASTEP (2)]
Exception occurred at (66BD18E2)
Task Traceback
Address   Frame     (DBGHELP API Version 4.0 rev 5)
66BD18E2  0618FDA8  sasxmc2:tkvercn1+0x8A2
056D11A0  0618FE94  uwudosub:tkvercn1+0x160
056D1816  0618FEA8  uwudosub:tkvercn1+0x7D6

accompanied by this little joy:
SAS_Has_Stopped_Working.jpg

What the heck?

 

So, I traced through the logic by various means (the PUTLOG may be a bit laborious, but that's sometimes what it takes), and here's the culprit:

_RC	=	DOSUBL(CATS('SYSECHO "Tab=',"&Tab_Name",'";'));

The above SAS statement runs just fine... except when it doesn't.  I'm reading in an Excel spreadsheet that has been exported from Excel as tab delimited text.  Unfortunately, there are a few blank lines that extend past the end of the real data.  If I delete the blank lines, everything runs just fine.  Add in the blank lines, and DOSUBL causes the above noted exception on the third or so iteration.  It's the weirdest thing.  DOSUBL works fine for the first couple of blank lines and then causes things to crash on reading the third or so blank line.  Comment out the DOSUBL, and SAS couldn't care less if Excel has a few blank lines.  

 

Color me baffled,

 

Jim

 

P.S.  It should be noted that I'm running SAS 9.3 (9300.0.19933.37002) where I believe DOSUBL is not considered a "production" level command.

Super User
Super User
Posts: 6,332

Re: The Perils of DOSUBL

[ Edited ]

The value of the macro variable probably hasn't changed during the running of the current data step.

Why not just code the SYSECHO command directly in the current data step instead of trying to call it with DOSUBL?

It will run once when the data step starts and report the value of the macro variable.

%let TAB_NAME=next_tab ;
...
data ...;
  sysecho "Tab=&tab_name" ;
  ....

run;

 

 

Frequent Contributor
Posts: 100

Re: The Perils of DOSUBL

Tom,

 

I have 326 of these exported-as-delimited-text Excel tabs.  The code that was having a problem is called as a macro that is driven by a DATA step.  I'll try your suggestion and see if it works.  

 

Regardless, SYSECHO is a nice thing but not absolutely necessary.  I report this DOSUBL issue more out of amazment than out of needing to find a solution.  Sometimes DOSUBL does some really bizarre things as has been noted elsewhere.  Hopefully these oddities are sorted out in 9.4.

 

Jim

 

Trusted Advisor
Posts: 1,056

Re: The Perils of DOSUBL

Very interesting (and weird!)

 

If I were you, I would definitely report it to tech support, especially if you can boil it down to a nice simple piece of code that they can use to reproduce the problem. Whatever's causing this hiccup is probably causing grief somwhere else, and if SAS can fix it it'll help everybody.

 

I like to think that I have an imaginary "Bingo" card that I put a new chip on every time I find a bug in SAS. Here's your chip!

 

Well done,

   Tom

Frequent Contributor
Posts: 100

Re: The Perils of DOSUBL

I've created a problem ticket.  I know the exact code that is causing the problem (below), but it appears to be at least in part to be data related.  If they ask, I probably can provide them with the input data as well; it's not proprietary or anything.

_RC	=	DOSUBL(CATS('SYSECHO "Tab=',"&Tab_Name",'";'));

Jim

Ask a Question
Discussion stats
  • 4 replies
  • 324 views
  • 0 likes
  • 3 in conversation