× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

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

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?

:wq! PoC

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2023 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.