"PERMANENT" shows up exactly one time in the Extended BASIC manual, and that is as a reserved word. It does not show up in the context of CALL SUB.
It could be a bug in the XB parser which does allow the keyword to be placed within the SUB parameters, even without a code-generating utility. It accepts it when entering, it accepts it when executing, but you can do nothing with what it creates. With all XB's stack in VDP RAM, I can see the SUB definition and variables more easily. What I see is the parameter X is prefixed with the token >FB (as mentioned above by @Gary from OPA)
I suspect this errant line creates a variable named >FB >58.
To test, I entered this line:
1000 SUB EFFORT(PERMANENT X,Y,PERMANENT Z)
Which created this (truncated) entry in VDP RAM:
>45 >46 >46 >4F >52 >54 E F F O R T
>B7 >FB >58 >B3 >59 >B3 >FB >5A >B6 ( _ X , Y , _ Z )
In this example, the SUB's name is EFFORT. The "(", ",", and ")" are tokenized, and the "_" is they keyword PERMANENT tokenized.
So, what I conclude is this definition creates three local variables: _X, Y, and _Z, with "_" representing the byte >FB. Which means that variable cannot be touched by XB unless you use some hackery.
Which I did. I took this program:
10 CALL EFFORT(2)
999 STOP
1000 SUB EFFORT(PERMANENT X)
1010 PRINT _X
1020 SUBEND
Then changed the "_" in VDP RAM to token >FB, giving this:
10 CALL EFFORT(2)
999 STOP
1000 SUB EFFORT(PERMANENT X)
1010 PRINT PERMANENT X
1020 SUBEND
Cool, huh? Yup... up until I ran it: