Why does %include correct memory problem?
in [SAS]
|
From: Tom Abernathy on 8 Nov 2009 21:20 I have seen in the past that SAS treats the lines from the program as if they had been padded with blanks. Or sometimes when a statement spans multiple lines it eliminates the end-of-line character and causes the word at the end of one line to join with the word on the next line. Perhaps by reading from the external file prevented either or both of those issues. Was it one long RENAME statement? If so did it work if broken into multiple statements? That would make the total code longer, but would not have such a long individual statement. With SAS 9.2 SAS has introduced a bug that can cause statement style comments (*...;) in remote submitted macro definitions to not get parsed properly. It is inconsistent and seem to happen when the characters fall exactly on at just the right spacing. Adding characters can make the issue go away. Perhaps this parsing error is related to that. On Nov 8, 6:11 pm, art...(a)NETSCAPE.NET (Arthur Tabachneck) wrote: > Doug ran into a problem, yesterday, because his recode statement was too > long for his system, editor or some combination thereof. > > Joe and I suggested breaking the recodes into a number of data steps, and > Joe also suggested breaking the code into multiple recode statements, but > using %include to incorporate them into one data step. > > As Doug mentioned, Joe's suggestion worked. My question is why? > > I presume it is because the code is executed as soon as it is %include'd, > but I'd definitely appreciate confirmation of that and, better yet, some > direction regarding where to look in the manual(s) that would suggest using > %include to correct for such problems. > > Art > --------- > On Sun, 8 Nov 2009 10:35:47 -0600, Doug Cacialli <doug.cacia...(a)GMAIL.COM> > wrote: > > > > > > >This problem has been solved, although I'm unable to explain why. > >Cutting-and-pasting the offending data step into a separate script and > >using %INCLUDE in it's place produced the expected behavior (e.g., > >everything is appropriately renamed). Thanks to Joe Matise and Art > >Tabachneck for their excellent suggestions. > > >-Doug. > > >=== > >Douglas Cacialli, M.A. - Doctoral candidate > >Clinical Psychology Training Program > >University of Nebraska-Lincoln > >Lincoln, Nebraska 68588-0308 > >=== > > >On Sat, Nov 7, 2009 at 3:45 PM, Doug Cacialli <doug.cacia...(a)gmail.com> > wrote: > >> I'm running SAS 9.2 in both virtualized XP Pro (Virtual PC on Win 7) > >> and Vista Ultimate environments. The error occurs in both OS's. > > >> I'm renaming a few hundred variables, so if length could be an issue > >> I've most likely hit the point where it will be an issue. Some of the > >> reliability variables are tweaked slightly, so renaming groups of > >> variables (e.g., RENAME var1-var100 = rvar1-rvar100) won't work. I'll > >> try your suggestion, see what happens, and let you know the result. > > >> I searched the archives, but nothing jumped out at me. I'll take > >> another look there too. Thanks SO much. > > >> -Doug. > > >> === > >> Douglas Cacialli, M.A. - Doctoral candidate > >> Clinical Psychology Training Program > >> University of Nebraska-Lincoln > >> Lincoln, Nebraska 68588-0308 > >> === > > >> On Sat, Nov 7, 2009 at 3:36 PM, Joe Matise <snoopy...(a)gmail.com> wrote: > >>> That's been a problem posted on the list before... I don't recall > exactly > >>> what you do, but I think it's related to the length of the program or > >>> something else. > > >>> Are you using 9.1.3? The version would help, it's possible it's been > fixed > >>> in a newer version. > > >>> Anyhow, if it's length related, try taking half of the program or so and > >>> putting it in a second file, and either just running both programs > >>> separately one after the other, or using %include to run the second half > >>> from the first half. I'm not sure, but my vague memory tells me that > might > >>> be the solution that was found before. > > >>> -Joe > > >>> On Sat, Nov 7, 2009 at 1:05 PM, Doug Cacialli <doug.cacia...(a)gmail.com> > >>> wrote: > > >>>> Greetings SAS-L, > > >>>> I've encountered a troublesome little niggle that's led me to re-join > >>>> the SAS-L listserv after being gone for a couple years. > > >>>> I'm working with a data set that's been passed on from > >>>> person-to-person for the past few years. Half of the data set > >>>> contains reliability data (data coded by a second rater) structured > >>>> such that there's one observation per ID, and the second coder's data > >>>> is contained in variables with an "r" prefix. The other half of the > >>>> data set contains reliability data structured such that the second > >>>> coder's data comprises a second observation with the same ID. I'm > >>>> trying to write a script that will: (1) separate out any observations > >>>> with duplicate ID's, and; (2) rename the variables with an "r" prefix, > >>>> so that they can then be merged back in, resulting in a homogeneously > >>>> structured data set. > > >>>> Everything works as I except it to, except the RENAME statement. I'm > >>>> encountering the following error in the log: > > >>>> ... > >>>> 2215 savryevaluator = revaluat > >>>> 2216 savry1 = rsavry1 > >>>> 2217 savry1crit = ??? ??? rsavry1c; > >>>> - - > >>>> 22 200 > >>>> 200 > >>>> ERROR 22-322: Expecting a name. > > >>>> ERROR 200-322: The symbol is not recognized and will be ignored. > >>>> - > >>>> 24 > >>>> ERROR 24-322: Variable name is not valid. > > >>>> 2217! savry1crit = ??? ??? rsavry1c; > >>>> - > >>>> 22 > >>>> ERROR 22-322: Syntax error, expecting one of the following: a name, -, > :, > >>>> ;. > > >>>> 2218 * savry2crit = rsavry2c > >>>> ERROR: Missing numeric suffix on a numbered variable list ( - > rsavry1c). > >>>> ERROR: Old and new variable name specifications for RENAME must be of > >>>> the same type. Statement > >>>> is ignored. > >>>> 2219 savry3 = rsavry3 > >>>> 2220 savry3crit = rsavry3c > >>>> 2221 savry4 = rsavry4 > >>>> ... > > >>>> That jumbled sequence of characters in line 2217 doesn't appear in my > >>>> script. I tried re-writing that line and the lines surrounding it and > >>>> it reappears in the log when I run the script. I've tried looking at > >>>> the file in notepad, but it looks the same in the enhanced editor. > > >>>> Does anyone have any suggestions here? I'd be happy to learn either > >>>> what's going on to generate the error, or another way to accomplish > >>>> the task. Any help would be appreciated. > > >>>> Thanks everyone. > > >>>> -Doug. > > >>>> === > >>>> Douglas Cacialli, M.A. - Doctoral candidate > >>>> Clinical Psychology Training Program > >>>> University of Nebraska-Lincoln > >>>> Lincoln, Nebraska 68588-0308 > >>>> ===- Hide quoted text - > > - Show quoted text -
From: Sigurd Hermansen on 8 Nov 2009 22:49 Art: I don't see why breaking a %INCLUDE'd file into multiple files should correct an error due to an invisible sequence of non-printing (and, perhaps, non-displaying characters). In my range of experience, %INCLUDE merely shifts the program pointer from the file that contains the %INCLUDE to another file. Breaking a program file into subfiles may save files in a way that eliminates aberrant characters. Has Doug looked at the savry1crit = ??? �??? rsavry1c; statement in the original file in a hex editor? The fact that the error repeats in successive program executions suggests that the original file includes unknown to us a sequence of characters that doesn't display in a text editor. Were SAS responsible for inserting nuisance characters in a program, it would more likely happen at the beginning or end of the %INCLUDE'd script. As a general rule, one does not always get what you see (WYSISNOTWYG) in ASCII or EBCDIC files. Some find that disturbing, or even subversive, but computers explore the full range of alternatives, even if we don't realize they exist. S -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Arthur Tabachneck Sent: Sunday, November 08, 2009 6:11 PM To: SAS-L(a)LISTSERV.UGA.EDU Subject: Why does %include correct memory problem? Doug ran into a problem, yesterday, because his recode statement was too long for his system, editor or some combination thereof. Joe and I suggested breaking the recodes into a number of data steps, and Joe also suggested breaking the code into multiple recode statements, but using %include to incorporate them into one data step. As Doug mentioned, Joe's suggestion worked. My question is why? I presume it is because the code is executed as soon as it is %include'd, but I'd definitely appreciate confirmation of that and, better yet, some direction regarding where to look in the manual(s) that would suggest using %include to correct for such problems. Art --------- On Sun, 8 Nov 2009 10:35:47 -0600, Doug Cacialli <doug.cacialli(a)GMAIL.COM> wrote: >This problem has been solved, although I'm unable to explain why. >Cutting-and-pasting the offending data step into a separate script and >using %INCLUDE in it's place produced the expected behavior (e.g., >everything is appropriately renamed). Thanks to Joe Matise and Art >Tabachneck for their excellent suggestions. > >-Doug. > >=== >Douglas Cacialli, M.A. - Doctoral candidate >Clinical Psychology Training Program >University of Nebraska-Lincoln >Lincoln, Nebraska 68588-0308 >=== > > > >On Sat, Nov 7, 2009 at 3:45 PM, Doug Cacialli <doug.cacialli(a)gmail.com> wrote: >> I'm running SAS 9.2 in both virtualized XP Pro (Virtual PC on Win 7) >> and Vista Ultimate environments. The error occurs in both OS's. >> >> I'm renaming a few hundred variables, so if length could be an issue >> I've most likely hit the point where it will be an issue. Some of the >> reliability variables are tweaked slightly, so renaming groups of >> variables (e.g., RENAME var1-var100 = rvar1-rvar100) won't work. I'll >> try your suggestion, see what happens, and let you know the result. >> >> I searched the archives, but nothing jumped out at me. I'll take >> another look there too. Thanks SO much. >> >> -Doug. >> >> === >> Douglas Cacialli, M.A. - Doctoral candidate >> Clinical Psychology Training Program >> University of Nebraska-Lincoln >> Lincoln, Nebraska 68588-0308 >> === >> >> >> >> On Sat, Nov 7, 2009 at 3:36 PM, Joe Matise <snoopy369(a)gmail.com> wrote: >>> That's been a problem posted on the list before... I don't recall exactly >>> what you do, but I think it's related to the length of the program or >>> something else. >>> >>> Are you using 9.1.3? The version would help, it's possible it's been fixed >>> in a newer version. >>> >>> Anyhow, if it's length related, try taking half of the program or so and >>> putting it in a second file, and either just running both programs >>> separately one after the other, or using %include to run the second half >>> from the first half. I'm not sure, but my vague memory tells me that might >>> be the solution that was found before. >>> >>> -Joe >>> >>> >>> >>> On Sat, Nov 7, 2009 at 1:05 PM, Doug Cacialli <doug.cacialli(a)gmail.com> >>> wrote: >>>> >>>> Greetings SAS-L, >>>> >>>> I've encountered a troublesome little niggle that's led me to re-join >>>> the SAS-L listserv after being gone for a couple years. >>>> >>>> I'm working with a data set that's been passed on from >>>> person-to-person for the past few years. Half of the data set >>>> contains reliability data (data coded by a second rater) structured >>>> such that there's one observation per ID, and the second coder's data >>>> is contained in variables with an "r" prefix. The other half of the >>>> data set contains reliability data structured such that the second >>>> coder's data comprises a second observation with the same ID. I'm >>>> trying to write a script that will: (1) separate out any observations >>>> with duplicate ID's, and; (2) rename the variables with an "r" prefix, >>>> so that they can then be merged back in, resulting in a homogeneously >>>> structured data set. >>>> >>>> Everything works as I except it to, except the RENAME statement. I'm >>>> encountering the following error in the log: >>>> >>>> ... >>>> 2215 savryevaluator = revaluat >>>> 2216 savry1 = rsavry1 >>>> 2217 savry1crit = ??? �??? rsavry1c; >>>> - - >>>> 22 200 >>>> 200 >>>> ERROR 22-322: Expecting a name. >>>> >>>> ERROR 200-322: The symbol is not recognized and will be ignored. >>>> - >>>> 24 >>>> ERROR 24-322: Variable name is not valid. >>>> >>>> 2217! savry1crit = ??? �??? rsavry1c; >>>> - >>>> 22 >>>> ERROR 22-322: Syntax error, expecting one of the following: a name, -, :, >>>> ;. >>>> >>>> 2218 * savry2crit = rsavry2c >>>> ERROR: Missing numeric suffix on a numbered variable list (�- rsavry1c). >>>> ERROR: Old and new variable name specifications for RENAME must be of >>>> the same type. Statement >>>> is ignored. >>>> 2219 savry3 = rsavry3 >>>> 2220 savry3crit = rsavry3c >>>> 2221 savry4 = rsavry4 >>>> ... >>>> >>>> That jumbled sequence of characters in line 2217 doesn't appear in my >>>> script. I tried re-writing that line and the lines surrounding it and >>>> it reappears in the log when I run the script. I've tried looking at >>>> the file in notepad, but it looks the same in the enhanced editor. >>>> >>>> Does anyone have any suggestions here? I'd be happy to learn either >>>> what's going on to generate the error, or another way to accomplish >>>> the task. Any help would be appreciated. >>>> >>>> Thanks everyone. >>>> >>>> -Doug. >>>> >>>> === >>>> Douglas Cacialli, M.A. - Doctoral candidate >>>> Clinical Psychology Training Program >>>> University of Nebraska-Lincoln >>>> Lincoln, Nebraska 68588-0308 >>>> === >>> >>> >>
From: Joe Whitehurst on 8 Nov 2009 23:22 Hey Doug, Are you doing any work with Professor Landfield or any of his students? Joe Whitehurst Personal Construct Psychologist PS SAS 9.x.x.x has a number of character functions that might help with your immediate problem. e.g., ANYALNUM Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194054.htm> Searches a character string for an alphanumeric character and returns the first position at which it is found ANYALPHA Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194060.htm> Searches a character string for an alphabetic character and returns the first position at which it is found ANYCNTRL Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194153.htm> Searches a character string for a control character and returns the first position at which it is found ANYDIGIT Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194193.htm> Searches a character string for a digit and returns the first position at which it is found ANYFIRST Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002197039.htm> Searches a character string for a character that is valid as the first character in a SAS variable name under VALIDVARNAME=3DV7, and returns the first position at which that character is found ANYGRAPH Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194214.htm> Searches a character string for a graphical character and returns the first position at which it is found ANYLOWER Function<http://support.sas.com/onlinedoc/913/getDoc/en/lrdict.hlp= /a002194244.htm> Searches a character string for a lowercase letter and returns the first position at which it is found On Sun, Nov 8, 2009 at 11:08 PM, Doug Cacialli <doug.cacialli(a)gmail.com>wro= te: > I'll take a look in a hex editor tonight or tomorrow and report back. > I think if that's the case, it has to be SAS inserting those > characters ... I retyped that line and the lines surrounding it so > many times. In a few instances, the sequence occurred elsewhere but > always nearby (when I omitted the line altogether, for instance). I'm > unsure why this would occur in a system-specific manner, however; Art > was able to run the script without issue. Maybe it's version specific > ... I believe he's running 9.1.3. > > I do find that possibility rather disturbing (but not entirely subversive > :-). > > -Doug. > > =3D=3D=3D > Douglas Cacialli, M.A. - Doctoral candidate > Clinical Psychology Training Program > University of Nebraska-Lincoln > Lincoln, Nebraska 68588-0308 > =3D=3D=3D > > > > On Sun, Nov 8, 2009 at 9:49 PM, Sigurd Hermansen <HERMANS1(a)westat.com> > wrote: > > Art: > > I don't see why breaking a %INCLUDE'd file into multiple files should > correct an error due to an invisible sequence of non-printing (and, perha= ps, > non-displaying characters). In my range of experience, %INCLUDE merely > shifts the program pointer from the file that contains the %INCLUDE to > another file. > > > > Breaking a program file into subfiles may save files in a way that > eliminates aberrant characters. Has Doug looked at the savry1crit =3D ???= =EF=BF=BD??? > rsavry1c; statement in the original file in a hex editor? The fact that t= he > error repeats in successive program executions suggests that the original > file includes unknown to us a sequence of characters that doesn't display= in > a text editor. Were SAS responsible for inserting nuisance characters in = a > program, it would more likely happen at the beginning or end of the > %INCLUDE'd script. > > > > As a general rule, one does not always get what you see (WYSISNOTWYG) i= n > ASCII or EBCDIC files. Some find that disturbing, or even subversive, but > computers explore the full range of alternatives, even if we don't realiz= e > they exist. > > S > > > > -----Original Message----- > > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of > Arthur Tabachneck > > Sent: Sunday, November 08, 2009 6:11 PM > > To: SAS-L(a)LISTSERV.UGA.EDU > > Subject: Why does %include correct memory problem? > > > > Doug ran into a problem, yesterday, because his recode statement was to= o > > long for his system, editor or some combination thereof. > > > > Joe and I suggested breaking the recodes into a number of data steps, a= nd > > Joe also suggested breaking the code into multiple recode statements, b= ut > > using %include to incorporate them into one data step. > > > > As Doug mentioned, Joe's suggestion worked. =C3=82 My question is why? > > > > I presume it is because the code is executed as soon as it is %include'= d, > > but I'd definitely appreciate confirmation of that and, better yet, som= e > > direction regarding where to look in the manual(s) that would suggest > using > > %include to correct for such problems. > > > > Art > > --------- > > On Sun, 8 Nov 2009 10:35:47 -0600, Doug Cacialli < > doug.cacialli(a)GMAIL.COM> > > wrote: > > > >>This problem has been solved, although I'm unable to explain why. > >>Cutting-and-pasting the offending data step into a separate script and > >>using %INCLUDE in it's place produced the expected behavior (e.g., > >>everything is appropriately renamed). =C3=82 Thanks to Joe Matise and A= rt > >>Tabachneck for their excellent suggestions. > >> > >>-Doug. > >> > >>=3D=3D=3D > >>Douglas Cacialli, M.A. - Doctoral candidate > >>Clinical Psychology Training Program > >>University of Nebraska-Lincoln > >>Lincoln, Nebraska 68588-0308 > >>=3D=3D=3D > >> > >> > >> > >>On Sat, Nov 7, 2009 at 3:45 PM, Doug Cacialli <doug.cacialli(a)gmail.com> > > wrote: > >>> I'm running SAS 9.2 in both virtualized XP Pro (Virtual PC on Win 7) > >>> and Vista Ultimate environments. =C3=82 The error occurs in both OS's= .. > >>> > >>> I'm renaming a few hundred variables, so if length could be an issue > >>> I've most likely hit the point where it will be an issue. =C3=82 Some= of the > >>> reliability variables are tweaked slightly, so renaming groups of > >>> variables (e.g., RENAME var1-var100 =3D rvar1-rvar100) won't work. = =C3=82 I'll > >>> try your suggestion, see what happens, and let you know the result. > >>> > >>> I searched the archives, but nothing jumped out at me. =C3=82 I'll ta= ke > >>> another look there too. =C3=82 Thanks SO much. > >>> > >>> -Doug. > >>> > >>> =3D=3D=3D > >>> Douglas Cacialli, M.A. - Doctoral candidate > >>> Clinical Psychology Training Program > >>> University of Nebraska-Lincoln > >>> Lincoln, Nebraska 68588-0308 > >>> =3D=3D=3D > >>> > >>> > >>> > >>> On Sat, Nov 7, 2009 at 3:36 PM, Joe Matise <snoopy369(a)gmail.com> > wrote: > >>>> That's been a problem posted on the list before... =C3=82 I don't re= call > > exactly > >>>> what you do, but I think it's related to the length of the program o= r > >>>> something else. > >>>> > >>>> Are you using 9.1.3? =C3=82 The version would help, it's possible it= 's been > > fixed > >>>> in a newer version. > >>>> > >>>> Anyhow, if it's length related, try taking half of the program or so > and > >>>> putting it in a second file, and either just running both programs > >>>> separately one after the other, or using %include to run the second > half > >>>> from the first half. =C3=82 I'm not sure, but my vague memory tells = me that > > might > >>>> be the solution that was found before. > >>>> > >>>> -Joe > >>>> > >>>> > >>>> > >>>> On Sat, Nov 7, 2009 at 1:05 PM, Doug Cacialli < > doug.cacialli(a)gmail.com> > >>>> wrote: > >>>>> > >>>>> Greetings SAS-L, > >>>>> > >>>>> I've encountered a troublesome little niggle that's led me to re-jo= in > >>>>> the SAS-L listserv after being gone for a couple years. > >>>>> > >>>>> I'm working with a data set that's been passed on from > >>>>> person-to-person for the past few years. =C3=82 Half of the data se= t > >>>>> contains reliability data (data coded by a second rater) structured > >>>>> such that there's one observation per ID, and the second coder's da= ta > >>>>> is contained in variables with an "r" prefix. =C3=82 The other half= of the > >>>>> data set contains reliability data structured such that the second > >>>>> coder's data comprises a second observation with the same ID. =C3= =82 I'm > >>>>> trying to write a script that will: (1) separate out any observatio= ns > >>>>> with duplicate ID's, and; (2) rename the variables with an "r" > prefix, > >>>>> so that they can then be merged back in, resulting in a homogeneous= ly > >>>>> structured data set. > >>>>> > >>>>> Everything works as I except it to, except the RENAME statement. = =C3=82 > I'm > >>>>> encountering the following error in the log: > >>>>> > >>>>> ... > >>>>> 2215 savryevaluator =3D revaluat > >>>>> 2216 savry1 =3D rsavry1 > >>>>> 2217 savry1crit =3D ??? =EF=BF=BD??? rsavry1c; > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 - =C3=82 =C3=82 - > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 22 =C3=82 200 > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 200 > >>>>> ERROR 22-322: Expecting a name. > >>>>> > >>>>> ERROR 200-322: The symbol is not recognized and will be ignored. > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 - > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 24 > >>>>> ERROR 24-322: Variable name is not valid. > >>>>> > >>>>> 2217! savry1crit =3D ??? =EF=BF=BD??? rsavry1c; > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82= =C3=82 =C3=82 =C3=82 - > >>>>> =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82= =C3=82 =C3=82 =C3=82 22 > >>>>> ERROR 22-322: Syntax error, expecting one of the following: a name, > -, > > :, > >>>>> ;. > >>>>> > >>>>> 2218 =C3=82 * =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 savry2crit =3D =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 = =C3=82 =C3=82 > =C3=82 rsavry2c > >>>>> ERROR: Missing numeric suffix on a numbered variable list (=EF=BF= =BD- > > rsavry1c). > >>>>> ERROR: Old and new variable name specifications for RENAME must be = of > >>>>> the same type. Statement > >>>>> =C3=82 =C3=82 =C3=82 is ignored. > >>>>> 2219 savry3 =3D =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 rsavry3 > >>>>> 2220 savry3crit =3D =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 = =C3=82 =C3=82 =C3=82 =C3=82 rsavry3c > >>>>> 2221 savry4 =3D =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3= =82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 rsavry4 > >>>>> ... > >>>>> > >>>>> That jumbled sequence of characters in line 2217 doesn't appear in = my > >>>>> script. =C3=82 I tried re-writing that line and the lines surroundi= ng it > and > >>>>> it reappears in the log when I run the script. =C3=82 I've tried lo= oking > at > >>>>> the file in notepad, but it looks the same in the enhanced editor. > >>>>> > >>>>> Does anyone have any suggestions here? =C3=82 I'd be happy to learn= either > >>>>> what's going on to generate the error, or another way to accomplish > >>>>> the task. =C3=82 Any help would be appreciated. > >>>>> > >>>>> Thanks everyone. > >>>>> > >>>>> -Doug. > >>>>> > >>>>> =3D=3D=3D > >>>>> Douglas Cacialli, M.A. - Doctoral candidate > >>>>> Clinical Psychology Training Program > >>>>> University of Nebraska-Lincoln > >>>>> Lincoln, Nebraska 68588-0308 > >>>>> =3D=3D=3D > >>>> > >>>> > >>> > > >
From: Doug Cacialli on 8 Nov 2009 23:08 I'll take a look in a hex editor tonight or tomorrow and report back. I think if that's the case, it has to be SAS inserting those characters ... I retyped that line and the lines surrounding it so many times. In a few instances, the sequence occurred elsewhere but always nearby (when I omitted the line altogether, for instance). I'm unsure why this would occur in a system-specific manner, however; Art was able to run the script without issue. Maybe it's version specific .... I believe he's running 9.1.3. I do find that possibility rather disturbing (but not entirely subversive :-). -Doug. === Douglas Cacialli, M.A. - Doctoral candidate Clinical Psychology Training Program University of Nebraska-Lincoln Lincoln, Nebraska 68588-0308 === On Sun, Nov 8, 2009 at 9:49 PM, Sigurd Hermansen <HERMANS1(a)westat.com> wrote: > Art: > I don't see why breaking a %INCLUDE'd file into multiple files should correct an error due to an invisible sequence of non-printing (and, perhaps, non-displaying characters). In my range of experience, %INCLUDE merely shifts the program pointer from the file that contains the %INCLUDE to another file. > > Breaking a program file into subfiles may save files in a way that eliminates aberrant characters. Has Doug looked at the savry1crit = ??? �??? rsavry1c; statement in the original file in a hex editor? The fact that the error repeats in successive program executions suggests that the original file includes unknown to us a sequence of characters that doesn't display in a text editor. Were SAS responsible for inserting nuisance characters in a program, it would more likely happen at the beginning or end of the %INCLUDE'd script. > > As a general rule, one does not always get what you see (WYSISNOTWYG) in ASCII or EBCDIC files. Some find that disturbing, or even subversive, but computers explore the full range of alternatives, even if we don't realize they exist. > S > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of Arthur Tabachneck > Sent: Sunday, November 08, 2009 6:11 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Why does %include correct memory problem? > > Doug ran into a problem, yesterday, because his recode statement was too > long for his system, editor or some combination thereof. > > Joe and I suggested breaking the recodes into a number of data steps, and > Joe also suggested breaking the code into multiple recode statements, but > using %include to incorporate them into one data step. > > As Doug mentioned, Joe's suggestion worked. � My question is why? > > I presume it is because the code is executed as soon as it is %include'd, > but I'd definitely appreciate confirmation of that and, better yet, some > direction regarding where to look in the manual(s) that would suggest using > %include to correct for such problems. > > Art > --------- > On Sun, 8 Nov 2009 10:35:47 -0600, Doug Cacialli <doug.cacialli(a)GMAIL.COM> > wrote: > >>This problem has been solved, although I'm unable to explain why. >>Cutting-and-pasting the offending data step into a separate script and >>using %INCLUDE in it's place produced the expected behavior (e.g., >>everything is appropriately renamed). � Thanks to Joe Matise and Art >>Tabachneck for their excellent suggestions. >> >>-Doug. >> >>=== >>Douglas Cacialli, M.A. - Doctoral candidate >>Clinical Psychology Training Program >>University of Nebraska-Lincoln >>Lincoln, Nebraska 68588-0308 >>=== >> >> >> >>On Sat, Nov 7, 2009 at 3:45 PM, Doug Cacialli <doug.cacialli(a)gmail.com> > wrote: >>> I'm running SAS 9.2 in both virtualized XP Pro (Virtual PC on Win 7) >>> and Vista Ultimate environments. � The error occurs in both OS's. >>> >>> I'm renaming a few hundred variables, so if length could be an issue >>> I've most likely hit the point where it will be an issue. � Some of the >>> reliability variables are tweaked slightly, so renaming groups of >>> variables (e.g., RENAME var1-var100 = rvar1-rvar100) won't work. � I'll >>> try your suggestion, see what happens, and let you know the result. >>> >>> I searched the archives, but nothing jumped out at me. � I'll take >>> another look there too. � Thanks SO much. >>> >>> -Doug. >>> >>> === >>> Douglas Cacialli, M.A. - Doctoral candidate >>> Clinical Psychology Training Program >>> University of Nebraska-Lincoln >>> Lincoln, Nebraska 68588-0308 >>> === >>> >>> >>> >>> On Sat, Nov 7, 2009 at 3:36 PM, Joe Matise <snoopy369(a)gmail.com> wrote: >>>> That's been a problem posted on the list before... � I don't recall > exactly >>>> what you do, but I think it's related to the length of the program or >>>> something else. >>>> >>>> Are you using 9.1.3? � The version would help, it's possible it's been > fixed >>>> in a newer version. >>>> >>>> Anyhow, if it's length related, try taking half of the program or so and >>>> putting it in a second file, and either just running both programs >>>> separately one after the other, or using %include to run the second half >>>> from the first half. � I'm not sure, but my vague memory tells me that > might >>>> be the solution that was found before. >>>> >>>> -Joe >>>> >>>> >>>> >>>> On Sat, Nov 7, 2009 at 1:05 PM, Doug Cacialli <doug.cacialli(a)gmail.com> >>>> wrote: >>>>> >>>>> Greetings SAS-L, >>>>> >>>>> I've encountered a troublesome little niggle that's led me to re-join >>>>> the SAS-L listserv after being gone for a couple years. >>>>> >>>>> I'm working with a data set that's been passed on from >>>>> person-to-person for the past few years. � Half of the data set >>>>> contains reliability data (data coded by a second rater) structured >>>>> such that there's one observation per ID, and the second coder's data >>>>> is contained in variables with an "r" prefix. � The other half of the >>>>> data set contains reliability data structured such that the second >>>>> coder's data comprises a second observation with the same ID. � I'm >>>>> trying to write a script that will: (1) separate out any observations >>>>> with duplicate ID's, and; (2) rename the variables with an "r" prefix, >>>>> so that they can then be merged back in, resulting in a homogeneously >>>>> structured data set. >>>>> >>>>> Everything works as I except it to, except the RENAME statement. � I'm >>>>> encountering the following error in the log: >>>>> >>>>> ... >>>>> 2215 savryevaluator = revaluat >>>>> 2216 savry1 = rsavry1 >>>>> 2217 savry1crit = ??? �??? rsavry1c; >>>>> � � � � � � � � � � � � � - � � - >>>>> � � � � � � � � � � � � � 22 � 200 >>>>> � � � � � � � � � � � � � 200 >>>>> ERROR 22-322: Expecting a name. >>>>> >>>>> ERROR 200-322: The symbol is not recognized and will be ignored. >>>>> � � � � � � � � � � � � � � � � � - >>>>> � � � � � � � � � � � � � � � � � 24 >>>>> ERROR 24-322: Variable name is not valid. >>>>> >>>>> 2217! savry1crit = ??? �??? rsavry1c; >>>>> � � � � � � � � � � � � � � � � � � � � � - >>>>> � � � � � � � � � � � � � � � � � � � � � 22 >>>>> ERROR 22-322: Syntax error, expecting one of the following: a name, -, > :, >>>>> ;. >>>>> >>>>> 2218 � * � � � � � � � savry2crit = � � � � � � � � � � rsavry2c >>>>> ERROR: Missing numeric suffix on a numbered variable list (�- > rsavry1c). >>>>> ERROR: Old and new variable name specifications for RENAME must be of >>>>> the same type. Statement >>>>> � � � is ignored. >>>>> 2219 savry3 = � � � � � � � � � � � � rsavry3 >>>>> 2220 savry3crit = � � � � � � � � � � rsavry3c >>>>> 2221 savry4 = � � � � � � � � � � � � rsavry4 >>>>> ... >>>>> >>>>> That jumbled sequence of characters in line 2217 doesn't appear in my >>>>> script. � I tried re-writing that line and the lines surrounding it and >>>>> it reappears in the log when I run the script. � I've tried looking at >>>>> the file in notepad, but it looks the same in the enhanced editor. >>>>> >>>>> Does anyone have any suggestions here? � I'd be happy to learn either >>>>> what's going on to generate the error, or another way to accomplish >>>>> the task. � Any help would be appreciated. >>>>> >>>>> Thanks everyone. >>>>> >>>>> -Doug. >>>>> >>>>> === >>>>> Douglas Cacialli, M.A. - Doctoral candidate >>>>> Clinical Psychology Training Program >>>>> University of Nebraska-Lincoln >>>>> Lincoln, Nebraska 68588-0308 >>>>> === >>>> >>>> >>> >
From: Jonathan Goldberg on 9 Nov 2009 10:03 I gather that the original problem involved a long, automatically generated, rename statement. I began to wonder about the "long" part. What are the length limitations of SAS statements? I can't find anything in the manual but the SAS knowledge base included this: Usage Note 15883: Length limitations when submitting SAS code There are many ways to submit SAS code and the length limitation is different depending on how you submit your code. The following are the length limitations as imposed by the various submission methods prior to SAS 9.2 and for SAS 9.2 and beyond: * Submitting a SAS program via a batch file imposes a maximum length limit of 256 characters prior to SAS 9.2. For SAS 9.2 and beyond you can use the new SAS system option of LRECL= to specify a range of 1-32767 to use for reading and writing external files. The default for the LRECL= system option is 256. This option is valid in the configuration file, at SAS invocation, the OPTIONS statement, or the SAS Systems Option window. Under z/OS, the LRECL= system option is recognized only for reading and writing HFS files. * Submitting a SAS program from the Program Editor imposes a maximum length limit of 384 characters prior to SAS 9.2. For SAS 9.2 and beyond you can use the new SAS system option of DMSPGMLINESIZE= to specify a range of 136-960 to specify the maximum number of characters in a Program Editor line. The default for the DMSPGMLINESIZE= system option is 136. This option is valid in the configuration file or at SAS invocation. * Submitting a SAS program from the Enhanced Editor imposes a maximum length limit of 960 characters prior to SAS 9.2. For SAS 9.2 and beyond the maximum length is extended to 6,000 characters. * Submitting SAS code using the IOM submit via the metadata server or a stored process server imposes a maximum length limit of 2,000 characters prior to SAS 9.1. For SAS 9.1 the maximum length limit extends to 6,000 characters. For SAS 9.2 and beyond the maximum length limit extends to 32,767 characters. * Submitting SAS code using %include <file> imposes a maximum length limit of 2,000 characters prior to SAS 9.1. For SAS 9.1 and beyond the maximum length limit is 6,000 characters. For specific details under your operating system, see the SAS Companion documentation for your operating environment. So, prior to Version 9.2 the enhanced editor had a length limitation of 960 and %include had a limit of 2000. Is this consistent with the error message received? I wish I knew.
|
Next
|
Last
Pages: 1 2 Prev: what is this and how do I fix it? Proc GMAP Next: Delete adjacent obs with repeated info |