Re: SAVRSTxxx

SAVRSTxxx uses APPC security *SAME.
To make it work you have to define remote LU as SECURE LOCATION.
When using APPN, it is configured in *APPNRMT configuration list. When using
plane APPC, it is configured in APPC device description.
For better security you can configure location password, which will be verified
during session setup.
With this setup SAVRSTxxx will run on remote system under the same profile as on
source system (profile should exist on both systems with the same password).

Also make sure that QCMN susbsystem has communication entry:
                    Job                  Default        Max
 Device        Mode      Description     Library        User           Active
 *APPC         QSOCCT    *USRPRF              QUSER          *NOMAX

Best regards
    Alexei Pytel



"Al Barsa, Jr." <barsa2@ibm.net> on 07/22/99 11:19:12 AM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:
Subject:  Re: SAVRSTxxx





At 09:01 PM 7/21/99 +0000, you wrote:
>  What profile is being used when using the SAVRSTxxx commands?  Or more
>likely, what needs to be configured?  The target machines I tried have
>valid configs / routes for SNADS and IP. QSYSOPR contained connection
>failure msgs w/ a code of 715,0.  I believe that those are also security
>related.  I saw no place to put in a user ID / password.  QUSER is enabled
>on both machines.  The sending user's profile exists on both machines.
>
>  I tried using those commands and I got an SNA sense code back saying that
>it wasn't sending the user ID and password.  The SNA format is FH7.
The original design of the SAVRSTxxx commands got corrupted with changes to
the default authority of the RSTxxx commands.

Originally (when this stuff was designed) just about anyone could restore
anything.  Now you need *ALLOBJ authority to restore something (which is a
pain in the ass).  So when I use these commands, I sign on with a profile
(available on both systems) that has *ALLOBJ authority.

IMHO, IBM is requiring *ALLOBJ for too many things.  This causes too many
users to assign themselves *ALLOBJ authority, which defeats the whole
purpose of security in the first place.

Al




+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.
400 > 390

Phone:         914-251-1234
Fax:      914-251-9406
http://www.barsaconsulting.com
http://www.taatool.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---