what does the 'input statement specification'?

[tianerhu]

I  can't make a desicion between choice B and D?

what does the 'input statement specification' mean?

[Kurt_Bremser]

It does mean that the part of the INPUT statement dealing with variable salary is wrong. But that would prevent the step from running.

Since salary is expected to be numeric, and the problem happens only once in 20 rows, B is correct.

[tianerhu]

Thanks a lot.

[jimbarbour · Accepted solution]

If you look at the fourth line in the messages, you'll see "Salary=." -- when you see a value of ".", that's a representation of a missing numeric value.  Therefore the specification on the Input statement had to be numeric.  It might look like the below.  Notice how there is a dollar sign after the two Employee fields but not after the Salary.  A dollar sign is the input specification for character.  If there is no dollar sign, the input specification is for numeric.  There are some variations on how an INPUT statement can be coded, but this is basically what INPUT specifications look like.

INFORMAT Birth_date Date9.;
INPUT
    Employee_ID $
    Employee_Gender $
    Salary
    Birth_date
    ;

In this case, the Salary on line 4 is coded as 46#30.  That's not typically how a Salary would be coded, and it's not a valid value for a numeric field.  That data, 46#30, doesn't work with the numeric input specification.  My answer would be "C" that this is the first of potentially many errors, this error occurring in the fourth line of input.  Any line of data with a non-numeric value in the Salary position will receive this error.

Jim

[Sajid01]

The correct answer is B.
The value of Salary should be a number whereas it has '#' in it.
Therefore error is triggered at execution time.

[tianerhu]

Thank you very much.

[tianerhu]

Thank you for your help.

[Tom]

This is a poor question.  First the text is presented in proportional font and so the columns of the problem data is impossible to determine.

Either B or D could be the real cause of the error.   Is the data wrong or did the programmer try to read it in the wrong way.

Common sense says that B is more likely the real problem.  Why would you want to define SALARY as a character string?  And if you did why would it include a # ?

[ballardw]

---

@Tom wrote:

Common sense says that B is more likely the real problem.  Why would you want to define SALARY as a character string?  And if you did why would it include a # ?

---

Salary as character if it contains values like "way overpaid" 😀 .

Or poor attempt at humor aside, that the Salary field could actually be some sort of accounting code. US federal government employees for example GS14 Step9 placed a pretty specific, for a given year, salary value IF you have the look up table.

My $0.02.

[PaigeMiller]

---

@Tom wrote:

This is a poor question.  First the text is presented in proportional font and so the columns of the problem data is impossible to determine.

---

Of all the very smart things @Tom has said over the years, I think this is my favorite.

[PaigeMiller]

How can it be A? It can't be A, there are no ERRORs in the LOG, there are only NOTEs.

How can it be B? It can't be B, there are no ERRORs in the LOG, there are only NOTEs.

How can it be C? It can't, because after this NOTE about invalid data for Salary in line 4, the log continues on and produces no more invalid data messages, and then it ends by saying the data set WORK.EMPLOYEES has 20 observations and 4 variables. It's done, it hasn't found additional invalid data.

So, it must be D. QED! 🙂 (Except for that part about the INPUT statement is in error, as someone pointed out above it could be there is a typographical error in the value of Salary, and so just because we have eliminated A B and C, that doesn't mean D is correct, it may not be an error in the INPUT statement.)