We have just moved our consoles from 3x74 to osa-icc connection.
We ipled for the first time last night an I got a call that cics didn't
recognize
the consoles.
Can any one help me in the definiton of this type of console? In the iocds they
are defined as 3270-x, is this the only change I'll
Do you have RACF turned on to your consoles, basically do you operators
need to sign on to use a console? I got burnt on that, I need to have them
defined to CICS the new names of the consoles and to RACF.
Andy S. White
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on
Yes, the operators must sign on to the consoles.thx
Mace
On Thu, Feb 12, 2009 at 9:39 AM, Andy White awh...@metlife.com wrote:
Do you have RACF turned on to your consoles, basically do you operators
need to sign on to use a console? I got burnt on that, I need to have them
defined to CICS the
I would suggest that you check the console names you've given your new
consoles, and compare them to the names you used previously. The console
name I'm talking about is the NAME parameter of the CONSOLE statement in
SYS1.PARMLIB(CONSOLnn).
Maybe you gave your new ICC consoles new names, and
Thanks for the quick reply. In reading defining mcs consoles to cics it says
to give it the 8 character name of the console from the consolxx parmlib
member. But in the mvs init and tuning guide it said the name could be 2-8
characters so I only made it 7. Is cics going to regurgitate the 7
On Thu, 9 Oct 2008 07:17:06 +0200, Barbara Nitz [EMAIL PROTECTED]
wrote:
I still think that at one point prior to console restructure console retention
attributes were kept as part of the sysmcs xcf group (permanent status
recording). I am 100% sure that it wasn't sufficient to 'only' have
Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of W. Kevin Kelley
Sent: Wednesday, October 08, 2008 5:38 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OSA ICC Consoles
Yes, I have been following this discussion...
First of all, Consoles does not keep any console information in the
couple
Hal Merritt wrote:
POR? Why? AFAIK, the last three remaining reasons for a POR are: loss of
power, adding a new LPAR, and bringing up a box for the very first time.
I thought I heard that some relief in adding an LPAR is in the pipeline.
You heard correctly.
However the list above can be
@BAMA.UA.EDU
Subject: Re: OSA ICC Consoles
On Tue, 7 Oct 2008 20:34:35 -0500, Field, Alan C.
[EMAIL PROTECTED] wrote:
A POR isn't necessary to activate microcode updates on current
hardware.
IBM worked hard three or four years ago to eliminate this requirement.
Caveat: If you're current
On Tue, 7 Oct 2008 20:34:35 -0500, Field, Alan C.
[EMAIL PROTECTED] wrote:
A POR isn't necessary to activate microcode updates on current hardware.
IBM worked hard three or four years ago to eliminate this requirement.
Caveat: If you're current. Sometimes jumping driver levels, depeding upon
: Tuesday, October 07, 2008 5:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OSA ICC Consoles
On Tue, 7 Oct 2008 14:17:05 -0500, Hal Merritt wrote:
POR? Why? AFAIK, the last three remaining reasons for a POR are: loss
of
power, adding a new LPAR, and bringing up a box for the very first
time.
I don't
in unexpected places.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Jousma, David
Sent: Wednesday, October 08, 2008 8:15 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OSA ICC Consoles
While a POR is usually technically not required, what
Hal Merritt wrote:
For us, only the OSA's would be disruptive. All other paths are
redundant and can be taken (completely) off line and varied back on with
minimal impact.
The same apply to Crypto cards. However both - CEX2C and OSA's can be
configured in redundant way. At least for TCP/IP
Yes, I have been following this discussion...
First of all, Consoles does not keep any console information in the couple data
sets. Secondly, the console attribute retention behavior has changed as a
result of the Console Restructure.
Prior to the Console Restructure, when a console was
After a POR, I would not expect any OSA sessions to be active. I'll assume
that you did a normal shutdown and deactivation of each LPAR. This would
tend to leave the OSA banner page. The POR would have reset the OSA cards,
thus breaking any session with the PC TN3270 software. I cannot remember
Kevin,
thanks for following and for addressing my question. I have changed the title
as the original thread has drifted to an POR or not POR discussion.
Thanks also for correcting my sloppy wording and guessing what I meant :-)
I still think that at one point prior to console restructure
On Tue, 7 Oct 2008 06:55:27 +0200, Barbara Nitz wrote:
Dave,
a few questions:
1. Is your sysplex located fully on the box that was POR'd?
Barbara,
We're not a sysplex, so none of this applies. But that's an interesting
situation for those that are. Do you IPL in a specific order in a
:[EMAIL PROTECTED] On
Behalf Of Dave Kopischke
Sent: Tuesday, October 07, 2008 1:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OSA ICC Consoles
On Tue, 7 Oct 2008 06:55:27 +0200, Barbara Nitz wrote:
Dave,
a few questions:
1. Is your sysplex located fully on the box that was POR'd?
Barbara,
We're
On Tue, 7 Oct 2008 14:17:05 -0500, Hal Merritt wrote:
POR? Why? AFAIK, the last three remaining reasons for a POR are: loss of
power, adding a new LPAR, and bringing up a box for the very first time.
I don't know. Our CE comes in, applies firmware maintenance and says a POR
is required to
a POR because it is simpler than doing the manual process six
times to reload them all.
Alan
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Kopischke
Sent: Tuesday, October 07, 2008 17:19 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OSA ICC
Dave,
We're not a sysplex, so none of this applies.
I beg to differ. :-) Unless you're still at z/OS 1.2, you have a WLM CDS which
requires a sysplex CDS which makes you a sysplex. Well, a sysplex of one called
a monoplex (Shane, I don't want to hear a comment from you:-) !). So this still
Greetings,
I searched the archives and didn't find anything that might help
explain what I'm observing.
I'm at the end of a console replacement project and had an issue
after a POR last night. None of the PC consoles came back online after
the POR/IPL. All had to be varied as consoles and
I don't think we have problems after an IPL. POR might be different -
don't recall.
As an aside have you defined them as NIP consoles in the IODF?
Alan
Subject: OSA ICC Consoles
Greetings,
I searched the archives and didn't find anything that might help
explain what I'm observing.
I'm
On Mon, 6 Oct 2008 13:43:30 -0500, Field, Alan C. wrote:
I don't think we have problems after an IPL. POR might be different -
don't recall.
As an aside have you defined them as NIP consoles in the IODF?
I defined two PC's as NIP consoles. But the old 3270 is defined higher in the
order, so I
IIRC after a POR and before any IPL we had to reestablish the ICC
connection from PCOMM.
-Original Message-
Dave Kopischke
On Mon, 6 Oct 2008 13:43:30 -0500, Field, Alan C. wrote:
I don't think we have problems after an IPL. POR might be different -
don't recall.
As an aside have you
On Mon, 6 Oct 2008 15:14:53 -0400, Ken Porowski [EMAIL PROTECTED]
wrote:
IIRC after a POR and before any IPL we had to reestablish the ICC
connection from PCOMM.
We use EXTRA!, so would that be the same as Disconnect/Connect ??? If so,
that only got us to the OSA page where it displays OSA
Yes same as Connect. It has been my experience that having the 'OSA
page' prior to any attempt at use is a requirement for consoles. We
always make sure the ICC consoles are in that OSA connected state PRIOR
to starting an IPL. Connecting AFTER IPL you will have to VARY the
device ONLINE before
27 matches
Mail list logo
