Re: V3R2: Configuring SLIP dialout

Le 18/07/2022 à 22:22, Patrik Schindler a écrit :

Hello,

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).

If I remember fine, PPP session is running in a batch job with QTCP user profile. Maybe this is the same with SLIP.

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?

Is there a batch job starting at the same time which could be related to the SLIP session? Maybe with the name of the dial profile? Maybe the authority issue happens within this job and is reported in your joblog?

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

Normally, no need to do so as QSECOFR has *ALLOBJ special authority. And the same applies with owner authority adoption. It is not used with an *ALLOBJ user profile.

Any ideas?

What is the authority for other user profiles on that object? If needed, could it be possible to change it so that *PUBLIC can use the object?

Thanks!

:wq! PoC