Re: SIGNOFF ENDCNN(*YES) without disconnecting iSeries Access

Hi, Dave:

But, that is precisely what ENDCNN(*YES) means. It will drop the telnet connection. :-o

Here is how I solved this problem. I wrote a small command named LOGOFF, so, if a user is doing a "telnet B" (from system A), then they type LOGOFF and it does the SIGNOFF ENDCNN(*YES), and that takes them back to system A. It also handles ENDPASTHR, in case they used STRPASTHR to get from A to B. Here is the CL code for the CPP for the LOGOFF command:

PGM PARM(&LIST) DCL VAR(&LIST) TYPE(*CHAR) LEN(7) /* 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 ... */ SIGNOFF LOG(&LIST) ENDCNN(*YES) RETURN ENDPGM

and here is the source for the command:

CMD PROMPT('Log off an interactive session') PARM KWD(LIST) TYPE(*CHAR) LEN(7) DFT(*NOLIST) +
RSTD(*YES) SPCVAL(*LIST *NOLIST) + PROMPT('Job Log')
I found it was pretty easy to train users to do a LOGOFF instead of SIGNOFF, since they should "know" if they did a STRPASTHR or TELNET to get to another system.
Does that help?

Cheers,

Mark S. Waterbury

> Dave Kahn wrote:

We have a cloned version of the SIGNOFF command with the default for
the ENDCNN parameter altered to *YES. This gives us the default
behaviour we want in all circumstances except one. When the current
session is the top level from iSeries Access ENDCNN(*YES) disconnects.
Ideally we'd like to leave this at the signon screen. It probably
can't be done without writing a command processing program, but is
there any way such a program can detect that the next SIGNOFF
ENDCNN(*YES) would disconnect the iSeries Access session?