The ability to issue commands in batch is controlled by this statement in the JES2 init deck:
JOBCLASS(x) ...,COMMAND=IGNORE,... It's an ancient parm probably older than RACF. I would expect that most modern shops run this way. To OP's question, TSO reconnect was broken for years, then reinstated some time back but requiring this parm in PARMLIB(TSOKEYxx): RECONLIM=nn . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Seymour J Metz Sent: Friday, February 08, 2019 10:09 AM To: [email protected] Subject: (External):Re: Unable to reconnect TSO session after VPN disconnect That depends on your configuration but I would have hoped that your security folks shut it long since. You can issue MVS commands, including JES commands, with the CONSOLE command in a background TSO job, and the security controls have much finer granularity. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of CM Poncelet <[email protected]> Sent: Friday, February 8, 2019 9:46 AM To: [email protected] Subject: Re: Unable to reconnect TSO session after VPN disconnect No idea whether any of this would work (from 20+ years ago): *A.* " //<jobcard, submitted on LPAR A> 00004000" " /*ROUTE XEQ <LPAR B> 00005000" " //********************************************************************* 00006000" " //* ISSUE MVS COMMANDS IN BATCH * 00007000" " //* - VIA FREEFORM JCL CARD * 00007100" " //* - VIA INTERNAL READER * 00007200" " //* * 00007300" " //********************************************************************* 00007400" " //* 00007500" " //INTRDR EXEC PGM=IEBGENER 00007600" " //SYSPRINT DD SYSOUT=* 00007700" " //SYSIN DD DUMMY 00007800" " //SYSUT2 DD SYSOUT=(*,INTRDR) 00007900" " //SYSUT1 DD *,DLM=@@ 00008000" " /*$VS,'CANCEL <TSO USERID on LPAR B>' 00009000" " @@ 00040000" " //* 00050000" " // 00060000" *B.* (In Netview, I cannot remember the complete syntax and parms - but something like) V NET INACT <whatever node it is> <Delete the Userid session> V NET ACT <whatever node it is> HTH Chris Poncelet (retired sysprog) On 07/02/2019 22:29, John Szura wrote: > In the past we were able to reconnect to a TSO session when our VPN > disconnected via the use of Gilbert St Flour's IKJEFLN2. The implementation > of LOGONHERE made this exit unnecessary. However, now we can no longer > reconnect to a session when the VPN disconnects, due to a network issue or it > just goes down, even though we have an S for RECONNECT in the USS display. > Now we immediately get the following messages: > > IKT100I USERID userid CANCELED DUE TO UNCONDITIONAL LOGOFF > IKT122I IPADDR..PORT nnn.nnn.nnn.nnn..50569 IEF450I userid proc > procstep - ABEND=S622 U0000 REASON=00000000 > > Both LOGONHERE and RECONLIM are defaulted (YES and 20 respectively). I am > able to switch a TSO session to another TN3270 session without a problem but > not when the VPN connection goes down (after it comes back up well within the > 20 minutes, of course). All I can think is that some TCPIP parameter like > DISCONNECTABLE or INACTIVE was not carried forward when we upgraded our z/OS > even though the defaults for these parameters seem fine. > > I logon using the DNS name of one of our z/OS systems. I know I could logon > to the system using a VM DIAL command but when I do that, I lose the the use > of the ATTN on the keyboard to interrupt a long running REXX or program. > > Any help would be appreciated but I need a fix not a workaround. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
