If you really want the second sign off to happen as well there are a couple
of different ways to handle that. All simple CL, however I don't have a
problem with using STRPASTHR either, there are a couple of advantages to it
that telnet does not offer as easily. It's just a bit harder to get set up
and requires a bunch of APPC controllers that would not be needed for
telnet. Also the Network attributes need to be correctly set up. Still
it's not that hard to do.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, October 31, 2016 2:48 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Cleaning up snads stuff
Jim,
I tested this with SIGNOFF ENDCNN(*YES) on LPAR B.
LPAR A still remains active.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Monday, October 31, 2016 3:28 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Cleaning up snads stuff
You could get that same behavior with telnet. When the telnet session ends,
end the communications too.
SIGNOFF ENDCNN(*YES)
The easiest way to do that is to create your own sign off program.
This is a snippet but has the salient parts.
SIGNOFF: PGM PARM(&LOG &DROP &ENDCNN)
DCL VAR(&LOG) TYPE(*CHAR) LEN(07)
DCL VAR(&DROP) TYPE(*CHAR) LEN(05)
DCL VAR(&ENDCNN) TYPE(*CHAR) LEN(04)
/* Setup the generic monitor message for standard error handling */
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(STDERR1))
/* Determine if this is a group job */
RTVGRPA GRPJOB(&GRPJOB)
IF COND(&GRPJOB *EQ '*NONE') THEN(DO)
ENDPASTHR
MONMSG MSGID(CPF0000) EXEC(DO)
QSYS/SIGNOFF LOG(&LOG) DROP(&DROP) ENDCNN(&ENDCNN)
ENDDO
ENDDO
ELSE CMD(DO)
ENDGRPJOB
ENDDO
GOTO CMDLBL(ENDJOB)
This will handle a group job, start pass-through or telnet. It clearly
could be updated with case statements etc.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, October 31, 2016 2:08 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: Cleaning up snads stuff
Rob,
A) I have a work in progress to find and cleanup the old distributions.
B) The reason we still use STRPASTHR is that on our Production LPAR,
1) certain user profiles automatically execute a STRPASTHR to a different
LPAR.
2) when a user signs off of system B, (the system STRPASTHR took them to),
when it returns to system A, that is also signed off.
I don't think you can replicate this with TELNET.
If I could, I would.
PGM
PASS3 RMTLOCNAME(PENCOR06)
MONMSG MSGID(CPF0000)
SIGNOFF
ENDPGM
PASS3 pgm
MISS: RCLRSC
QSYS/STRPASTHR RMTLOCNAME(&RMTSYS) VRTDEV(*NONE) +
RMTUSER(*CURRENT) RMTINLPGM(&RMTPGM) +
RMTINLMNU(&RMTMNU) PASTHRSCN(*NO)
RETURN /* Return To Caller */
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Monday, October 31, 2016 2:45 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Cleaning up snads stuff
I understand that some of you still use SNADS, and that's ok. It has some
use, if only for the Objectconnect Commands like SAVRST, SAVRSTLIB,
SAVRSTOBJ. Why anyone would use STRPASTHR instead of TELNET (except just to
test SNA connectivity) escapes me.
But, if you get into a clean up mode, like why do you get messages when you
delete someone like "distributions pending", or get a similar message when
you do SAVDLO (if only because it's part of the GO SAVE 21), then there are
things you can do.
WRKDSTQ
work with the entries
delete them
CFGDSTSRV
2=Routing table
The only system supplied one should be
------System------
Name Group Description
TCPIP TCP/IP Routing
1=Distribution queues
The only system supplied one should be
Remote Remote
Queue Name Queue Type Location Name Mode Name Net ID
QSMTPQ *RPDS TCPIPLOC *NETATR *LOC
I did have some which "appear" to be system supplied. Began with RCH... I
suspect they were for ancient versions of IBM support. Some really old
lpars. They were not on the newer lpars. I blasted them.
I found that Mimix was having a tough time replicating the deletion of a
user profile because of these.
I had some really ancient distributions.
I also had some that were less than a year old. Still stuck though.
Cleared them all.
After doing this I find I still have distributions.
CRTSAVF QTEMP/TRASH
SAVDLO DLO(*ALL) DEV(*SAVF) SAVF(QTEMP/TRASH)
CPC9063
Message . . . . : 1669 document library objects saved.
Cause . . . . . : 1669 objects were saved in save file TRASH in library
QTEMP at 10/31/16 13:49:16.
-- 29 folders were saved.
-- 1482 documents were saved.
-- 158 distributions were saved.
Looking for suggestions to hunt these distributions down and kill them.
Wait, figured them out.
http://www-01.ibm.com/support/docview.wss?uid=nas8N1016831
That worked.
Can't run these on our main production lpar as that changes the "last used"
date of each user profile (because it submits jobs for every person in the
system distribution directory). We have one analyst who likes to limit us
to running it only one time a year, planned in advance, to check on 'active'
users.
See also:
CPF9042 - User &1, User ID and address &2 &3 cannot be removed.
DLTUSRPRF
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
