I do not believe IEFBR14 with the COMMAND JCL statement will behave as expected. I believe the commands in JCL will be executed at interpretation, not execution. An IEBGENER step would provide the commands merely as data/text at the interpreter, and later that same data/text to INTRDR once routed for execution on the appropriate LPAR. I am going by recollection, so testing would be needed to settle the matter..
On Sat, Jul 16, 2016 at 11:57 AM, CM Poncelet <[email protected]> wrote: > 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
