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
