Would a command validation exit program help you with this? Seems like you could retrieve the call stack of the job requesting the SIGNOFF command, determine whether you need ENDCNN(*YES) or not, then execute the amended command string.

Just a WAG...

-Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Kahn
Sent: Monday, July 06, 2009 6:24 AM
To: Midrange Systems Technical Discussion
Subject: Re: SIGNOFF ENDCNN(*YES) without disconnecting iSeries Access

2009/7/3 Mark S. Waterbury <mark.s.waterbury@xxxxxxx>:
Hi, Dave:

You could call your version of the LOGOFF command SIGNOFF,  and change
the command processing program as follows:

    PGM        PARM(&LIST)
    DCL        VAR(&LIST) TYPE(*CHAR) LEN(7)
    DCL        VAR(&SYSNAME) TYPE(*CHAR) LEN(8)
 /* attempt to end an SNA pass-through session ... */
    ENDPASTHR  LOG(&LIST)
    MONMSG     MSGID(CPF0000) EXEC(DO)
       RCVMSG  PGMQ(*SAME *) MSGTYPE(*EXCP) MSGKEY(*NONE) +
                 WAIT(0) RMV(*YES)
       ENDDO
 /* if that fails, sign off, and end TCP connection ... */
    RTVNETA    SYSNAME(&SYSNAME)
    IF (&SYSNAME *EQ 'S103X29M') +
       QSYS/SIGNOFF  LOG(&LIST) ENDCNN(*NO)
    ELSE +
       QSYS/SIGNOFF  LOG(&LIST) ENDCNN(*YES)
    ENDPGM

The idea here is to retrieve the system name, and if it is the name of
your "normal" primary system, issue the "real" SIGNOFF command with
ENDCNN(*NO), otherwise (you must have done a telnet to some other
system, so) issue the "real" SIGNOFF with ENDCNN(*YES).

Would that work better for you?

Hi, Mark. That's a nice idea; thanks for that. The main problem I see
with it is that the user could have any one of three systems as the
home system for any given session. A single hard-coded value would not
be enough to be able to identify the home system. Also, with multiple
telnets the home system could appear more than once in the stack and
we would want to end the connection at the lower levels. It's only at
the very top level that we want to avoid it.


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.