In a certain engineering organization, there is a strange and highly specific hiring pattern: every engineer on one particular team is named Zach.

This is not an exaggeration. There is Zach Smith, Zach Brown, Zach Wu, Zach Lee, Zach Patel, and many more. When a new hire joins, people do not ask, "What is your first name?" They ask, "What kind of Zach are you?" To keep them all straight, everyone refers to each person by their last name only: "Hey, Smith, can you review this PR?" or "Brown, did you see that Jira ticket?"

Because literally everyone on the team has the first name "Zach", it is considered redundant and unnecessary to ever write it down. All tools, scripts, and dashboards simply store and display last names. When someone assigns a Jira ticket to "wu", everybody understands that the full human being is "Zach Wu". Over time, people even stop thinking about the first name entirely. If you say "Patel", it is implied that you mean the Zach version.

This works reasonably well, right up until Jira assignment chaos begins.

Every day, tickets are created and assigned to Zachs. In theory, the person creating the ticket knows exactly which Zach is responsible, and types that Zach's last name into the assignee field. In practice, typos, autocomplete, and sheer human haste get in the way. Someone might intend to assign a ticket to "smith" but accidentally assign it to "smoth". They might type "wu" but click "wood". In a world where all first names are the same, last names carry all the meaning, and there is very little room for error.

The team has started to suspect that quite a few tickets have been misassigned. Some Zachs are buried under work that was not meant for them, while others are wondering why their board looks suspiciously empty. To figure out how bad the situation really is, they have produced a log of Jira ticket assignments.

For every ticket, the log contains two last names:

• intendedAssigneeName: the last name of the Zach who should have received the ticket.
• actualAssigneeName: the last name of the Zach who actually received the ticket in Jira.

Remember: both of these are only last names. The first name "Zach" is implied and never written.

Your job is to analyze this log and determine which Zachs ended up with tickets that were not meant for them.

More precisely, for each ticket:

• If intendedAssigneeName is equal to actualAssigneeName, then the ticket was correctly assigned. The right Zach (by last name) got the ticket.
• If intendedAssigneeName and actualAssigneeName are different, then the ticket was misassigned. In that case, the Zach identified by actualAssigneeName has received a ticket that was not intended for them, and you should count that as one incorrect assignment for that last name.

Note that the report you produce focuses on who received extra tickets they should not have gotten, not on who was missing tickets they should have received. For example:

• If a ticket was intended for "smith" but actually assigned to "brown", then:
  • "brown" has 1 incorrectly assigned ticket.
  • The fact that "smith" did not get their ticket is not counted in this particular report.

After processing all tickets, you must decide what to print:

• If every ticket was correctly assigned (that is, for every logged ticket, intendedAssigneeName == actualAssigneeName), then there are no problems to report. In this case, you should output exactly:
  • NO ISSUES
• Otherwise, at least one ticket was misassigned, and some Zachs (by last name) received tickets not meant for them. In this case, you must:
  • Identify every distinct last name that appears as an actualAssigneeName on at least one misassigned ticket.
  • Count how many misassigned tickets each such last name received.
  • Output one line per such last name, with:
    • the last name,
    • a space,
    • and the number of incorrectly assigned tickets they received.
  • These lines must be printed in sorted order by last name, using normal lexicographic (dictionary) order on the last name strings.

By the end, you will have constructed an "involuntary workload report" for the Council of Zachs: a list showing exactly which last names bore the brunt of misassigned Jira tickets. Whether the team decides to improve their processes, add stricter validation to the assignment field, or simply ban hiring any more Zachs with confusingly similar last names is beyond the scope of this problem.

Your task is simply to read the data and produce the correct summary.

Constraints

~1 \le numJiraTickets \le 10^6~

~1 \le |intendedAssigneeName|, |actualAssigneeName| \le 10~

Input Specification

The first line contains a single integer, ~numJiraTickets~.

The next ~numJiraTickets~ lines each contain two strings of lowercase letters, ~intendedAssigneeName~ and ~actualAssigneeName~, indicating that a Jira ticket was intended to be assigned to the Zach with last name ~intendedAssigneeName~ and actually got assigned to ~actualAssigneeName~.

Output Specification

If all Jira tickets were correctly assigned, output NO ISSUES.

Otherwise, output one line per Zach that was incorrectly assigned Jira tickets, outputting their last name and the number of Jira tickets they were incorrectly assigned.

Output them in sorted order by last name.

Sample Input 1

3
marto stuart
bennett stuart
stuart stuart

Sample Output 1

stuart 2

Sample Explanation 1

Unfortunately for Zach Stuart, he has been assigned Zach Marto and Zac Bennett's JIRA tickets.

Sample Input 2

3
stuart stuart
stuart stuart
stuart stuart

Sample Output 2

NO ISSUES

Sample Explanation 2

Unfortunately for Zach Stuart, he has been assigned three JIRA tickets.

Sample Input 3

2
s stuart
stuart s

Sample Output 3

s 1
stuart 1

Sample Explanation 3

Unfortunately for Zach Stuart, Zach S is distinct from Zach Stuart (though maybe not in our hearts). This is why Zach S comes before Zach Stuart.