Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recursive/nested prodecure labels linking discrepancy #29

Open
didrikmunther opened this issue Jan 24, 2025 · 1 comment
Open

Recursive/nested prodecure labels linking discrepancy #29

didrikmunther opened this issue Jan 24, 2025 · 1 comment
Labels
priority-high Should be resolved in 1-2 sprints severity-high A bug for which there may be workaround but limits the usage of the Zowe for major use cases

Comments

@didrikmunther
Copy link

didrikmunther commented Jan 24, 2025

The current implementation of linking claims that the calls to Proc at (a) and (b) refers to the procedure defined at (1).

We have reason to believe that both (a) and (b) should refer to (2).

PL/I docs states (credit @montymxb):

… for nested procedures, PL/I uses the variable declared within the current block before using any
variables that are declared in containing blocks.

Building this program generates a warning about not having a RECURSIVE attribute on the inner PROC, further reinforcing our assumption.

Further testing is required, especially running this program. There are 3 possible outputs we can get from this program:

Output Meaning
1 1 Shadowing doesn't work, the compiler simply registers the first occurrence of a label (this is how our extension currently thinks it works).
1 2 2 Shadowing does work, and is similar to the description of the documentation of PL1.
1 2 1 There is a weird mix going on where shadowing does work in the same scope, but not when there are nested procedures.

Test program:

 STARTPR: PROCEDURE OPTIONS (MAIN);
 DCL VISITED_OUTER   BIT(1) INIT('0'B);
 DCL VISITED_INNER   BIT(1) INIT('0'B);

 PROC: PROCEDURE;                                    // (1)
   PUT LIST ('1');
   IF VISITED_OUTER = '1'B THEN DO; RETURN; END;
   VISITED_OUTER = '1'B;

   PROC: PROCEDURE;                                  // (2)
      PUT LIST ('2');
      IF VISITED_INNER = '1'B THEN DO; RETURN; END;
      VISITED_INNER = '1'B;
      CALL PROC;                                     // <- (a) Recursive call
   END PROC;

   CALL PROC;                                        // <- (b) Call to shadowing label
 END PROC;

 CALL PROC;
 END STARTPR;
@montymxb montymxb added priority-high Should be resolved in 1-2 sprints severity-high A bug for which there may be workaround but limits the usage of the Zowe for major use cases labels Jan 30, 2025
@didrikmunther
Copy link
Author

Update:

After @montymxb ran this program on the mainframe:

 STARTPR: PROCEDURE OPTIONS (MAIN);
 DCL VISITED_OUTER   BIT(1) INIT('0'B);
 DCL VISITED_INNER   BIT(1) INIT('0'B);

 PROC: PROCEDURE;
   PUT LIST ('1');
   IF VISITED_OUTER = '1'B THEN DO; RETURN; END;
   VISITED_OUTER = '1'B;

   PROC: PROCEDURE RECURSIVE;
      PUT LIST ('2');
      IF VISITED_INNER = '1'B THEN DO; RETURN; END;
      VISITED_INNER = '1'B;
      CALL PROC;
   END PROC;

   CALL PROC;
 END PROC;

 CALL PROC;
 END STARTPR;

Gives the following output:

1 2 2

Leading us to believe:

Shadowing does work, and is similar to the description of the documentation of PL1.

Here's also some documentation for linking

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-high Should be resolved in 1-2 sprints severity-high A bug for which there may be workaround but limits the usage of the Zowe for major use cases
Projects
None yet
Development

No branches or pull requests

2 participants