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



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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.