2013-01-05 13:28:21 UTC
since the publication of MVT for APL version 1.00 comments not unexpectedly show that handling the OPR user which is signed on to the recording terminal raises problems: Especially beginners tend to lose the correct unlock/lock rhythm when working at that terminal which then leads to unwanted effects.
During APL\360 operations the only reason to "use" the recording terminal is to enter privileged commands or I-Beams because it is the only privileged terminal in the system. Note that "privileged" is an attribute of a terminal, not of a user. It can be assigned to a signed on terminal and lasts until it gets either explicitely removed or the user signs off.
As opposed to early versions of APL\360 the 5734-XM6 version we are using today doesn't have the )PRIV system command to privilege other terminals: In the 5734-XM6 version this type of functions is contained in the OPFNS workspace instead, which still is missing in action.
With the intention to just implement the PRIVILEGE function I had a look at the definitions of the dyadic I-Beams and at "Table 1. Summary of APL\360 Special Operator Function" on page 36 of the APL\360 General Information Manual (GH20-0850-1) only to find that while I'm at it, it would make more sense to implement an at least minimal subset of the ecosystem that the table suggests: Obviously OPFNS isn't just a set of standalone functions, but most of the functions are operating on vectors of ports and can be connected directly with each other or by using and, or, not logicals.
This ecosystem gives interesting options in operating APL\360, like for example:
PRIVILEGE MEMO<-ON AND NOT PRIVILEGED
will privilege all terminals that are currently signed on but not privileged and remembers their port numbers in vector MEMO. Entering then later
will deprivilege exactly those terminals. And so on...
Sadly the above mentioned table isn't very specific, but it is the only information I have that can be used to define the functions in OPFNS. An open point is in particular how output of the "sinks" in function chains should look like: Just a vector of attributes, or a table listing objects with their attributes? And which attributes shall be listed? So, for the time being I stopped here and defined just one of these "sink" functions: The PORT function, which should according to the table report brief information on a vector of ports. I implemented it such that it delivers a vector of APL user numbers, being signed on currently (signed on port) or previously (signed off port). If one then wants a table (similar to the one the )PORTS command delivers) one has to do the APLish way what it takes to format the output. Perhaps someone remembers what type the output of these "sink" functions created, just vectors or ready made tables?
Well, enough chatting:
Please find some sample usage and a complete printout of that minimal OPFNS workspace at
Although this workspace (like the previously published SINPLT and BEER workspaces) could be input into your system using line by line copy and paste to a 1052 terminal, it's probably not feasible to do so as it's already quite a bit of code. So I've created an AWS tape from this workspace using the SELDUMP function of the APL utility program. This tape can be found at
To load it use the following utility control statements:
//SYSIN DD *
Use for example the APLCRTE job as a base, replace the control statements with the above ones and give it the opfns.aws tape instead of the apllib.aws tape. The utility will then replace the existing empty dummy OPFNS workspace from the MVT for APL distribution with the new one.