topic Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li in SAS Programming

2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs lines

novinosrin — Tue, 12 Nov 2019 18:29:47 GMT

1. What makes null statement not just null ,global and executable?

I do not quite comprehend executable nature of null statement in the 1st place though there is an example in the docs that seems rather in comprehensive to me at least. Also, I do not find great utility to trust its executable component beyond its step boundary and specification of values embedded with semicolons . 2ndly, how does it become a global statement? So use anywhere as it says in the docs? How anywhere after all?

2. Alias for datalines are cards and lines: Is the use of alias just to remove the yellow color patch on the datalines? Well just curious though not important. Any other features?

See the yellow patch not coloring the datalines when you use lines. 🙂


data test1;
input a b;
cards;
1 2
;
data test2;
input a b;
datalines;
1 2
;
data test3;
input a b;
lines;
1 2
;

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

unison — Tue, 12 Nov 2019 18:51:35 GMT

2. Interesting.. I don't see any coloring difference between lines and datalines in my IDE? Can you snapshot it? From what I understand, they are purely aliases.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

novinosrin — Tue, 12 Nov 2019 18:54:14 GMT

In my PC SAS it does color distinction. However,l i am not allowed attachments on the internet at work. I may have to go home and upload it. Sorry about that

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

mkeintz — Tue, 12 Nov 2019 18:58:36 GMT

@novinosrin

Regarding #2, I was not aware of (or perhaps completely forgot about) the existence of a LINES statement. Only CARDS and DATALINES have any space in my memory bank. Although I reproduced what you describe (no yellow coloring for in-lline data when using the LINES statement), did you notice that the rendering of the data in your inserted program is yellow for ALL the programs, even using LINES.

As to #1, can you tell me what part of the docs you are referring to? I don't think I fully understand the question.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

novinosrin — Tue, 12 Nov 2019 19:11:00 GMT

Thank you Mark, I am not too concerned about #2 and certainly doesn't require a wharton answer. It's just fun. However 1st one seems to apply to a context.

https://documentation.sas.com/?docsetId=lestmtsref&docsetTarget=n0grfgqwd2djh5n1ordogecfgu76.htm&docsetVersion=9.4&locale=en

This says

Null Statement

Signals the end of data lines or acts as a placeholder.

Note:

The Null Statement has moved to SAS Global Statements.

Next one(the full explanation here) http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a000289429.htm

Null Statement

Signals the end of data lines or acts as a placeholder.

Valid:	Anywhere
Category:	Action
Type:	Executable

Yes there is an example there, just not convincing to me and i felt I may as well ask here.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Shmuel — Tue, 12 Nov 2019 19:03:27 GMT

I'm not sure this is the answer you are looking for.

As for your first question I think that next code illustrates a null statement:

if <condition> then ;  /* null statement */
else do;
   ...
end;

sometimes it fits way of thinking or emphasizes that the situation was not skipped.

As for your 2nd question:

In the early 1980 I remember I was using CARDS only.

Maybe DATALINES and LINES were added later.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

novinosrin — Tue, 12 Nov 2019 19:05:38 GMT

Thank you Sir. Can you really illustrate the IF THEN ;;;; with a practical example plz. How, why , when and what scenarios plz

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

SASKiwi — Tue, 12 Nov 2019 19:06:35 GMT

@novinosrin - My recollection is that the CARDS statement came first to SAS and it was originally restricted to 80 byte / char records, analogous to punched card input. DATALINES / LINES was added later to allow greater than 80 byte records. Now the CARDS and DATALINES statements behave exactly the same and whether greater than 80 byte records is allowed is controlled by the CARDIMAGE SAS option:

https://documentation.sas.com/?docsetId=lestmtsref&docsetTarget=p0114gachtut3nn1and4ap8ke9nf.htm&docsetVersion=9.4&locale=en

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

mkeintz — Tue, 12 Nov 2019 19:14:04 GMT

Well if the null statement can be used anywhere, that's probably enough to classify is as global. It's trivial below, but it is global:

proc freq data=sashelp.class;
  tables  sex;
run;
;
proc means data=sashelp.class;
   var age;
run;

I guess you can call it executable, because in the presence of in-line data, it tells the data step to stop processing data - i.e. to stop executing. But one could avoid it if one wanted to demonstrate especially bad programming practice:

data t1;
  input a b;
cards;
1 2
proc freq data=t1;   /* or proc freq data=t1;;;;*/
run;

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Tom — Tue, 12 Nov 2019 19:17:00 GMT

SAS statements end with a semi-colon. A "null statement" is just a free floating semi-colon. They are GLOBAL because they can appear outside of a PROC or DATA step (or inside either a PROC or a data STEP).

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Shmuel — Tue, 12 Nov 2019 19:16:29 GMT

@novinosrin wrote:

Thank you Sir. Can you really illustrate the IF THEN ;;;; with a practical example plz. How, why , when and what scenarios plz

When you have a many conditions it is easy to build a decisions table, like:

C stands for condition in next table:

C1    C2     C3  ....  Cn    exec
 0       0       0                   nothing (not available)
 0       0       1                    ex1
 0       1       0                    ex2
 ....
 1       1       1                   nothing

In such case I want to cover and code all combinations of the conditions, while some of then need no action

or I believe they are not available or I have no such data and cannot decide what to do - in such case a NULL statement

may be used.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Quentin — Tue, 12 Nov 2019 19:42:19 GMT

My favorite null statement to avoid (and perhaps the most common observed) is:

%macrocall(foo);

That semicolon is NOT part of the macro language. The final parenthesis ends the macro invocation and the macro executes. The semicolon is an extra null statement in the SAS language.

When you've got function-style macros that are designed to return part of a SAS statement, accidental generation of null SAS statements can cause all kinds of headaches.

That said, a lot of macro programmers like to end their macro calls with semicolons, even though they know they're introducing null statements.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

ChrisNZ — Wed, 13 Nov 2019 03:09:58 GMT

> Is the use of alias just to remove the yellow color patch on the datalines?

The color parser is not always right and makes mistakes.

These statement are the same (read @SASKiwi 's comment). Don't rely on the color parser to tell you what syntax is right, even if most times it helps.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

hashman — Wed, 13 Nov 2019 06:12:07 GMT

@mkeintz:

Mark, ha-ha. It's a good thing you'd forgotten about LINES since this is a poison pill - if only the color thing discovered by @novinosrin were the problem. Try this:

data have ;                                                                                                                             
  infile lines ;                                                                                                                        
  input x ;                                                                                                                             
  lines ;                                                                                                                               
1                                                                                                                                       
2                                                                                                                                       
run ;

What do you get? Right, this:

ERROR: No logical assign for filename LINES.

Huh? But now, try this:

data have ;                                                                                                                             
  infile cards ; * place 1 ;                                                                                                                        
  input x ;                                                                                                                             
  lines ;        * place 2 ;                                                                                                                                
1                                                                                                                                       
2                                                                                                                                       
run ;

And everything is hunky-dory. Bottom line (npi), LINES is never good in place 1, regardless of what is in place 2, even if it's LINES itself. However, CARDS and DATALINES are always good in place 1 irrespective of whether place 2 is occupied by CARDS, LINES, or DATALINES.

I have no first clue why it was necessary to create such a confusion, as if CARDS/CARDS4 weren't good enough. If it was just the desire to cater to a younger audience by shaking off the image of CARDS as something ancient harking back to the mainframe, the introduction of LINES and DATALINES was hardly worth the effort. SAS is still chock full of keywords, and indeed features, borrowed from the mainframe, and I find absolutely nothing wrong with it. Getting rid of them would be tantamount to throwing the baby away with the bathwater. Shall we get rid, just for starters, of:

MSGLEVEL LRECL RECFM DISP OLD NEW SHARE MOD
& and && as symbolic references and . and .. as indicators of their termini
The concepts of STEP, PROCEDURE, LIBRARY, CATALOG
The entire PL/I syntax (including the macro language syntax) upon which the entire SAS language syntax is built
...

I guess I'm asking a rhetorical question. I've always coded CARDS, code CARDS, and will always code CARDS - and nothing else. If it should offend some folks inheriting my code who have never seen a punch card, none of my business - they can replace it with DATALINES if they think it adds any value to their code. As far as LINES is concerned, see above.

Kind regards

Paul D.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Tom — Wed, 13 Nov 2019 06:38:34 GMT

The Version 8 documentation (which in many ways is soo much easier to read) clearly shows that LINES is an alias for CARDS/DATALINES. https://v8doc.sas.com/sashtml/lgref/z0188182.htm

DATALINES

Indicates that data lines follow

Valid:	in a DATA step
Category:	File-handling
Type:	Declarative
Aliases:	CARDS, LINES
Restriction:	Data lines cannot contain semicolons. Use DATALINES4 when your data contain semicolons.

But does not show that INFILE LINES is a valid alias for INFILE DATALINES.

https://v8doc.sas.com/sashtml/lgref/z0146932.htm

DATALINES | DATALINES4 specifies that the input data immediately follows the DATALINES or DATALINES4 statement in the DATA step. This allows you to use the INFILE statement options to control how the INPUT statement reads instream data lines.

Alias:	CARDS \| CARDS4
Featured in:	Changing How Delimiters are Treated

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Kurt_Bremser — Wed, 13 Nov 2019 08:48:25 GMT

Why is a null statement considered executable? Think of this:

select (gender);
  when ('M') put "this is a male";
  when ('F') put "this is a female";
  otherwise; /* null statement */
end;

The select() block needs a branch for every situation resulting of what's in the select() statement (or it will throw an ERROR), so it executes the null statement following the otherwise keyword.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

novinosrin — Wed, 13 Nov 2019 13:21:22 GMT

Sir Good morning, While it's nice to note your creative thinking, I am just seeking absolute clarity on the null statement(; or ;;;; ) as executable stand alone in its own right as claimed by the docs. An executable global statement valid anywhere be it in open code or a datastep/proc construct doesn't seem convincing yet.

@ Everyone, To go further, what token would a null statement be? Would it be a special token, text(name token), or just a place holder text. How does the compiler see and do what is been instructed? Then of course at execution time we can deal with it accordingly if we know what does it execute

@Kurt_Bremser wrote:

Why is a null statement considered executable? Think of this:
select (gender);
  when ('M') put "this is a male";
  when ('F') put "this is a female";
  otherwise; /* null statement */
end;
The select() block needs a branch for every situation resulting of what's in the select() statement (or it will throw an ERROR), so it executes the null statement following the otherwise keyword.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

Kurt_Bremser — Wed, 13 Nov 2019 13:37:36 GMT

In the compiled executable machine code, the null statement is not present at all. It has mutated into the location where the next machine code instruction to be executed is stored.

See my select() example. The only thing left from the null statement is the JMP that jumps to the first instruction after the end; but that JMP is coded at the end of all the branches.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

hashman — Wed, 13 Nov 2019 14:36:46 GMT

@Quentin:

Quentin, like you, I've learned from Ian that coding something that serves no function should be avoided for two reasons: (1) it may lead to an error and (2) to a confusion. The semicolon after a macro is one of those, and it falls in both categories. A period after a macro reference "just in case" is another, though it falls just into category #2.

Kind regards

Paul D.

Re: 2 questions 1.What makes null statement not just null ,global and exec2.Datalines vs cards vs li

mkeintz — Wed, 13 Nov 2019 14:55:52 GMT

@hashman

I admit, I've gone over from CARDS to DATALINES, primarily because it is more self-descriptive, which is not entirely the same as catering to a younger audience. So I hold my head high even as I recall dropping a program/data deck of 300 ordered cards.

@novinosrin Nice topic!