RO *ALL,C U=
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of CM Poncelet Sent: Saturday, July 16, 2016 11:58 AM To: [email protected] Subject: Re: Already logged on message - Wrong System ID There could well be an operator command to route commands to a different LPAR. But I have always preferred submitting batch jobs to do this, as I then had a record of what commands I had issued to be executed - and on which other LPAR and when. I submitted MVS commands directly from the 'master console' (e.g. from SDSF) only when necessary. Other people can do whatever they prefer. CP Edward Gould wrote: >Isn’t there a operator command that can route commands do different LPARS ? >Seems to me submitting a batch job to a different LPAR is a PITA when it can >simply be done with a oper command. >No? > >Ed > > > > >>On Jul 15, 2016, at 9:28 PM, CM Poncelet <[email protected]> wrote: >> >>The IEBGENER reads the SYSUT1 data and writes it to the INTRDR (internal >>reader) via SYSUT2, and issues the MVS command as executable on the "'/*ROUTE >>XEQ <etc.>" LPAR. >>Yes IEFBR14 could do this too, but only in shops whose >>RACF/ACF2/TSS/<whatever else> security allows it. E.g. IEFBR14 could be >>submitted to execute on a different LPAR as: >> >>'/*ROUTE XEQ <LPAR on which you are 'already logged on', e.g. LPAR1> ' <-- >>note route job to execute on a different LPAR '//* >> ' >>'//*********************************************************************' >>'//* ISSUE MVS COMMANDS IN BATCH VIA IEFBR14 *' >>'//* *' >>'//*********************************************************************' >>'IEFBR14 EXEC PGM=IEFBR14 ' <-- >>note now executing IEFBR14 on a different LPAR '// >> ' <-- note >>EOJ #1 >> >> ' CANCEL <your userid> ' <-- note issue MVS command to INTRDR after EOJ #1 >>'// ' <-- >>note EOJ #2 >> >>I have no idea what the "more modern // COMMAND syntax" is. >> >>If the OP cannot logon to another LPAR to submit the 'CANCEL' job, I would >>suggest the OP raise an issue about this with the 'help desk'. The OP should >>always be able to logon to a different LPAR. >>I have explained how to fix the problem. Whatever caused it is IMHO >>irrelevant and not worth investigating (MVS, OS/390, z/OS etc. is crap >>intended to prove only that IBM's hardware works). >> >>CP >> >> >>Anthony Thompson wrote: >> >> >> >>>Don't really understand that JCL. What is the point of IEBGENER stuff there? >>> >>>Isn't the only DD-card of relevance the /*$VS 'CANCEL <userid>' ? Wouldn't >>>IEFBR14 do just as well? >>> >>>Why not the more modern // COMMAND syntax, avoiding the cumbersome $VS crap >>>(and use C U=<userid> rather than the bigger hammer CANCEL?). Always >>>assuming the appropriate authorities are allowed via RACF OPERCMDS and the >>>JES command authorities defined for that job class. >>> >>>And how does the OP get to edit/submit that job when he can't log in on >>>another LPAR? >>> >>>Ant. >>> >>>-----Original Message----- >>>From: IBM Mainframe Discussion List [mailto:[email protected]] On >>>Behalf Of CM Poncelet >>>Sent: Friday, 15 July 2016 11:33 AM >>>To: [email protected] >>>Subject: Re: Already logged on message - Wrong System ID >>> >>>Here it is again, but now with quotes around the JCL ... <grin> >>> >>>Update and submit the following JCL, but from a different LPAR and on which >>>you can logon: >>> >>>'/*ROUTE XEQ <LPAR on which you are 'already logged on', e.g. LPAR1> ' >>>'//* ' >>>'//*********************************************************************' >>>'//* ISSUE MVS COMMANDS IN BATCH *' >>>'//* *' >>>'//*********************************************************************' >>>'//* ' >>>'//INTRDR EXEC PGM=IEBGENER ' >>> '//SYSPRINT DD SYSOUT=* >>> ' '//SYSIN DD DUMMY >>> ' '//SYSUT2 DD >>>SYSOUT=(*,INTRDR) ' >>> '//SYSUT1 DD *,DLM=@@ >>>' <your userid>' '/*$VS,'CANCEL >>> ' '@@ >>> ' '//* >>> ' >>>'// ' >>> >>>This should terminate your being logged on the other named LPAR (e.g. LPAR1 >>>or LPAR2) within the sysplex. >>> >>>CP (retired sysprog) >>> >>> >>>Tom Marchant wrote: >>> >>> >>> >>> >>>>On Thu, 14 Jul 2016 17:08:28 +0530, Jake Anderson wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I am trying to access one of an LPAR1 within a sysplex. Where I get a >>>>>message as you already logged on to LPAR1. When I have someone to check my >>>>>ID from other system its shows that My ID is active in LPAR2. >>>>> >>>>> >>>>> >>>>> >>>>We cannot help you to understand what is happening when you paraphrase the >>>>messages that you receive. Please give the exact messages. Include the >>>>response from D TS,L on both LPARs. >>>> >>>> >>>> >>>> >>>> >>>>>We have MIM but we have not enabled Parallel Logon facility serialization. >>>>> >>>>>I am curious why z/OS is displaying a wrong System Name instead of the One >>>>>my ID is active ? >>>>> >>>>> >>>>> >>>>> >>>>I am curious why you think that the system is giving you the wrong >>>>information, rather than that you are not connecting to the system that you >>>>want. >>>> >>>> >>>> >>>> >>>> >>>>>Its like I am logged into LPAR2, but when I try accessing LPAR1, it shows >>>>>that you are already logged on to LPAR1.. >>>>> >>>>> >>>>> >>>>> >>>>Does it really say LPAR1? Or does the it just say that you are already >>>>logged on the the current LPAR? >>>> >>>> >>>> >>>> >>>> >>>>>This gets resolved after My ID is cancelled from LPAR 2. >>>>> >>>>> >>>>> >>>>> >>>>If your session was really cancelled on LPAR2, you were logged on to LPAR2, >>>>not LPAR1 >>>> >>>> >>>> >>>> >>>> >>>---------------------------------------------------------------------- >>>For IBM-MAIN subscribe / signoff / archive access instructions, send email >>>to [email protected] with the message: INFO IBM-MAIN >>> >>>---------------------------------------------------------------------- >>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to [email protected] with the message: INFO IBM-MAIN >>> >>> >>> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN >> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > >. > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
