This is a demonstration of three different variables in a scoping exercise.

I used the fork() syscall because that is something that I can easily control on a relatively quiesced system.

What is happening in this example (Using the global counter variable):

1: ls in a shell

2: ls in a shell

3-9: A rsh login

10: ls in the original shell

The global variable increments as expected.

The thread variable increments as expected (there are multiple processes calling fork()).

The local variable is always local and never increments beyond 1. (See the NOTE below.)

The key points:

• The thread local has no context in the BEGIN or END blocks.

• The global behaves like all globals everywhere.

• Use locals with caution Ð they can bite their owners if not initialized (see NOTE below).

NOTE: The li (local int) is declared and initialized as such. The only reason it appears to work as a local is because it is re-initialized in each action block. It DOES NOT actually function as a local, but instead as a global. Some variations on the local usage and how it ÒrespondsÓ are recorded here:

• Declared using Ò__auto int li;Ó at the top of each action blockÊ acts like a global.

• Declared and used only in syscall block (using __auto with no initialization)Ê acts like a global (keeps its value between runs).

• Declared and initialized in BEGIN (or syscall) and accessed elsewhereÊ acts like a global. It is ÒknownÓ in the END block even though not declared there.

This is a TL3 system.

Initially I tried to write an example with a variable namespace clash between a local and a global (using a variable of that name). It failed on compile with the following error:

ERR-67: Line:12 Column:9 Variable 'clash' already declared at line 3.