Andy
Can anyone out there who are using ICC consoles tell me how they have the
console itself defined both in the consol member and hcd. This all worked
for us when we had a z8 hardware we are now on z9 but I don't see why
there
is a difference.
Here are some observations
V 1001,CONSOLE
IEE936I CONSOLE CONZ INITIALIZATION ERROR - RC:01 - 3277-2 IS
ASSUMED
D C,U=(1001),L=K9830TI-Z
IEE889I 16.21.53 CONSOLE DISPLAY 164
MSG: CURR=1 LIM=3000 RPLY:CURR=4 LIM=100 SYS=Z090 PFK=00
CONSOLE ID --------------- SPECIFICATIONS ---------------
CONZ 17 COND=A AUTH=ALL NBUF=1
1001 AREA=Z,A MFORM=T,S,J
Z090 DEL=R RTME=1/4 RNUM=19 SEG=19 CON=N
USE=FC LEVEL=ALL PFKTAB=MVSCMDS
ROUTCDE=1-10,12-128
LOGON=OPTIONAL
CMDSYS=Z090
MSCOPE=*ALL
INTIDS=N UNKNIDS=N
CNZ4200I CONSOLE CONZ HAS FAILED. REASON=IOERR
What I noticed was in the Consol00 member we had the UNIT(3270-X) which is
valid as per init and tuning.. The HCD was checked and its defined as a
3270-X also then says something like it will emulate a 3277-2. We then
changed to UNIT(3277-2). Then we found the following error in the syslog
V 1001,CONSOLE
D C,U=(1001),L=Z
IEE889I 17.33.30 CONSOLE DISPLAY 102
MSG: CURR=0 LIM=3000 RPLY:CURR=4 LIM=100 SYS=Z090 PFK=00
CONSOLE ID --------------- SPECIFICATIONS ---------------
CONZ 17 COND=A AUTH=ALL NBUF=0
1001 AREA=Z,A MFORM=T,S,J
Z090 DEL=R RTME=1/4 RNUM=19 SEG=19 CON=N
USE=FC LEVEL=ALL PFKTAB=MVSCMDS
ROUTCDE=1-10,12-128
LOGON=OPTIONAL
CMDSYS=Z090
MSCOPE=*ALL
INTIDS=N UNKNIDS=N
CNZ4200I CONSOLE CONZ HAS FAILED. REASON=IOERR
You will notice the IEE936 is not longer there but still the console wont
come up on the emulator.
How do you have your consoles defined in the HCD and Consolxx.. We are
thinking maybe we change it to 3277-2 and not let it emulate it but make
sure the HCD matches it?? When I display the 1001 address it shows up as:
IEE457I 20.46.20 UNIT STATUS 353
UNIT TYPE STATUS VOLSER VOLSTATE
1001 3277 O
Any ideas? We are doing this with Attachmate Extra.
I started to look at this thread because I'm interested in OSA matters. I
have never worked with the OSC type so I can't help from experience here.
However I may be able to help from the perspective of a background with
3270.
I checked the OSA-Express Integrated Console Controller Implementation Guide
redbook. I see that UNIT=3270 and MODEL=X are used for hardware and
UNIT=3270-X is used for CONSOLxx. I believe it's something of a coincidence
that the HCD panels used to help create the IOCP definitions - which is as I
understand it from afar - happen to use the code 3270-X, the code which
happens to be the one used in the CONSOLxx statements.
It's probably best actually to understand for what these codes might be
standing. I'm pretty sure it's quite wrong to assume that the code 3277-2
and 3270-X are equivalent. From having "grown up" with the 3270 range of
devices, I expect that 3277-2 simply means that the device so defined
accepts and generates the 3270 data stream as used with display devices and
has a presentation space of 24 rows and 80 columns, the dimensions of the
3277 Model 2. I expect that 3270-X simply means that the device so defined
accepts and generates the 3270 data stream as used with display devices[1]
but has a presentation space which will be determined dynamically by means
of the "Read Partition Query" exchange at the very beginning of the data
exchanges used when the device is logically activated[2][3].
Thus, as far as the CONSOLxx statements are concerned, the 3277-2 code and
the 3270-X code differ from one another in the means used by the 3270
application - in this case console support - to determine the dimensions of
the presentation space upon which the 3270 application can present its
data - in the case of console support the number of rows upon which message
lines of a particular column size width can be presented.
From the ICC redbook I see that your only option - presumably given that you
have defined the channel path type and control unit type as OSC - is 3270-X
(mapping to UNIT=3270,MODEL=X) when you wish to define a display rather than
a printer. Thus there is no question that you can actually match the codes
except when - as I suggested, by a sort of coincidence - they are both
3270-X.
I hope someone watching might explain but I am rather uncertain what
influence the hardware definition might have once the hardware has been
alerted to the fact that the device uses 3270 channel operations. Details
such as the actual presentation space dimensions are surely at far too
advanced a level to bother the channel operations. Presentation space
dimensions are at the level of what is contained within the data which the
channel is so helpfully shipping in and out of the device.
It's interesting that the CNZ4200I message has revision bars in the z/OS
V1R8 manuals. Is this failing with z/OS V1R8 and working with V1R7? Perhaps
that is the significant change rather than a z8 machine to a z9 machine.
Checking back to V1R7, I see this is a *new* message in V1R8 and perhaps
corresponds to some *new* support which - clearing the throat - may not be
"working as designed".
-
From section 2.1, "Defining an OSC CHPID via IOCP" in System z9 and eServer
zSeries z890 and z990 Open Systems Adapter-Express Integrated Console
Controller User's Guide, SA22-7990-01:
<quote>
Note: If you are using HCD to define your configuration it is important that
you select control unit type OSC and device type 3270-X for OSA-ICC.
</quote>
So we have confirmation that UNIT=3270 and MODEL=X are required for OSC.
This manual seems to offer no advice regarding how to define a CONSOLxx
member so it appears the redbook is the only specific advice available.
Checking the HCD manuals for 3270 I found the following in the User's Guide:
<quote>
Generic. Generic (or generic device type) is an MVS-defined grouping of
devices with similar characteristics. For example: the device types 3270-X,
3277-2, 3278-2, -2A, -3, -4, and 3279-2a, -2b, -2c, -3a, -3b belong to the
same generic. Every generic has a generic name that is used for device
allocation in the JCL DD statement. MVS interprets this name as "take any
device in that group". In an operating system configuration, each EDT has
the same list of generics. This list can only vary by the preference values
and VIO indicators that are assigned to the generics.
</quote>
I'm wondering whether or not this tends to confirm that, as far as hardware
definitions are concerned, it is sufficient to know that the channel
operations are those of non-SNA 3270 and that all the other fine details
are, in effect, ineffective commentary.
It would appear that the significance of the appearance of "3277-2" in the
IEE936I message is the following bracketed comment in section 19.11.1,
"Syntax and parameters of a CONSOLE statement", of the z/OS MVS
Initialization and Tuning Reference, SA22-7592-13, manual:
<quote>
(should Read Partition Query fail, MCS will attempt to bring the device
online with 3277-2 display attributes).
</quote>
No doubt there is some good reason why 3279-2 - mentioned seemingly equally
in the IEE936I message description - may be selected as a fall-back under
some circumstances but that does not concern us here.
The following from the same section is interesting given that you wished to
ensure compatibility between the HCD and CONSOLxx definitions:
<quote>
Default: If you do not code the UNIT keyword, the system uses the
information entered through HCD for the device number to determine the unit
type. If the HCD information indicates that it is a display device, the
system will default the UNIT value to 3270-X.
</quote>
We have the same definition I wonder if its the Attachmate or Bluezone
sessions we have set up neither works, they work as a tn3270 (meaning I
can get a vtam10 screen and logon) but as console it gets the error.
Here you indicate that you can use the ICC-attached TN3270E client
successfully as a non-SNA 3270 display connected to VTAM and an application
behind VTAM. Note that getting an USS[4] message 10 doesn't indicate much
since there will be no use of the "Read Partition Query" flow for the USS
exchanges - which logically flow on the SSCP-LU session.
Actually logging on to an application *may* be more useful. The application
may or may not use the "Read Partition Query" flow at the logical beginning
of the SNA session. What application was it and did the mode table entry
used contain X'80', the bit that indicates support for the "Read Partition
Query" flow, in the second byte of the hexadecimal string identified by the
"presentation services", PSERVIC, operand?
Incidentally, the TN3270E client is always a TN3270E client. When -
attempting to - being used as a console, it is under control of one set of
partner TN3270E server software and, when being used as a device defined to
VTAM, it is under control of another set of partner TN3270E server software.
-
Now I'm going to try to be *really* helpful! The suggestions for message
CNZ4200I - recall the one with revision bars in the V1.8 manual - are the
following:
<quote>
Operator Response: For reasons ABTERM, IOERR, OPENERR and SWERR, notify your
system programmer. For the other reasons, reactivate the console when
appropriate.
System Programmer Response: Search problem reporting data bases for a fix
for this problem. If no fix exists, contact the IBM Support Center.
</quote>
I expect that IBM cannot claim that you have not been diligent enough with
your own problem diagnosis - with attendant financial implications perhaps -
if you simply follow what the manual tells you to do.
Chris Mason
[1] Probably - "3270" strictly covers a range of displays *and* printers.
327X may have been a more accurate code since the displays tended to have
"327" as the first three numbers in their "names" while printers had "328"
as the first three numbers in their "names".
[2] This is - should you care to take a look at the description,
specifically the description of what the return code is all about - what the
IEE936I message is all about - AFAICS.
[3] In the case of an SNA session - even one terminated in the VTAM code
which gives a non-SNA channel-attached device the appearance of an SNA
device - the "Read Partition Query" exchange typically will take place
immediately after the real or assumed "Start Data Traffic" point in the
session immediately after the BIND.
[4] That means "Unformatted System Services", the VTAM component behind your
"VTAM10" message - and responses to unsuccessful attempts to specify a
VTAM-based application. In addition to the hard core of vociferous list
members who refuse to acknowledge this correct attribution of USS - or react
as if it was some guilty secret they'd prefer wasn't mentioned, USS is used
very freely in the list exchanges to describe UNIX System Services.
Consequently, it occurs to me that there may be a proportion of folk
habitually using USS to mean UNIX System Services who could have some
contact with the real USS in the shape of USS messages but have lost - or
never had - the knowledge of how these messages should properly be
described. Such folk may well use descriptions such as "VTAM10".
----- Original Message -----
From: "Andy White" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Friday, July 27, 2007 1:21 PM
Subject: Re: ICC Console
Thanks Roger and others I will give this a try next week when I can test
again.
Andy
Internet: Mailto:[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
