V3R2: Configuring SLIP dialout

Hello,

perhaps some of you remember V3R2 from the 1990's? There already was TCP/IP, but since I'm running it on a P03 with Twinax, and "only" a 2609 dual V.24 adapter, there is no LAN support. Not a big deal, though.
I have successfully managed to transparently bridge an SDLC connection to my Token Ring LAN with the help of an older Cisco Router model. So the machine appears in my APPN network as a LAN node. Nice! And the maximum speed of 19200 bps of the 2609 isn't *that* bad, as long as you're not trying to work in a hurry while a print job is squeezed through the line. ;-) (Learning how to use different modes — and thus pacing values — for interactive sessions and remote queue transfers is postponed to a later point in time.)

Now I'm shifting my attention to the second serial port on that 2609. I want to run TCP/IP. V3R2 has no PPP support, just SLIP (Serial Line Interface Protocol).

So I configured the async AUX port of my Cisco Router to accept incoming SLIP requests without any authentication, created a line description, and a dial profile to my best knowledge.

When I try to start the connection in the "Work with Point-to-Point TCP/IP" screen, the connection attempt immediately fails. The main reason is shown by this diagnostic message (CPD0171) from the job log.

CPD0171 Diagnostic 30 22-07-18 21:58:51 QCACALL QSYS 024C QCMD QSYS 011F
Message . . . . : Not authorized to program QTOCPPSM in library QSYS.
Cause . . . . . : Attempt made to access an application program without
adequate authority. Recovery . . . : Obtain authority from the security
officer or program owner, and then try the command again.

Now, since I'm QSECOFR when trying to start the dialout attempt, I'm puzzled what's going wrong. I guess the call stack somewhere contains an entry with an adopted authority. But then, how could this have worked in the first place? A bug, maybe?

Adding QSECOFR with *ALL authority to QSYS/QTOCPPSM did not change the behavior.

Any ideas?

Thanks!

:wq! PoC