My thanks for the history lesson for BCPii. I was under the impression,
from a z/OS customer point of view it was quite a bit less mature. I may just
be hitting problems that hadn't been encountered elsewhere.
Two issued were related to the ENF OpSys MSG interface.
If the z/OS Image name connected to via BCPii and enabled via HWIEVENT was
exactly 8 characters, it didn't work at all. Most all image name here are 8
characters but some are less and those worked which led us down a path looking
more at the CEC than the Image. The PTF for this fix was just released.
Another problem relates to long single line messages. I was testing
throughput via my ENF exit and found D U,,,xxxx,52 works fine but D U,,,xxxx,53
causes an abend in BCPii indicating some limit on the number of characters
BCPii handles through its data space. I've only been working with the product
since late last Spring but have hit a good number of issues. IBM has been good
about dealing with them if not a little on the slow side.
Pleasure talking with you...
Regards,
Stan
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
W. Kevin Kelley
Sent: Monday, January 03, 2011 10:37 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: BCPii code
On Mon, 3 Jan 2011 14:47:45 -0500, Stan Weyman
<stan.wey...@emc.com> wrote:
> The sample code is ok but nothing that will help that much. One of the
two examples is specifically for the ENF interface BCPii provides for, among
many other things, getting return code info for things such as issuing z/OS
commands. The return code you receive from BCPii simply means BCPii was
able to issue its call, not that the specific function you were attempting
worked <sigh>. To get the results of some BCPii calls, you need to code an
ENF exit. Another ENF interface is for Operating System message tracking.
Seems to work ok as long as the operating system message isn't too long,
then it doesn't work so good <g>. Given how 'young' this product is, there
are problems I've come across.
>
>
Stan,
I haven't seen the sample BCPii code but the ENF stuff that you refer to has
been there since around 1990 or so. BCPii is an extension to the architecture,
and is built on top of some of the same infrastructure, that was put in-place
to support the HMC System Console and remote hardware operations that was
exploited by the Target System Control Facility (TSCF) around 1990. (I was
the chief designer of TSCF). TSCF subsequently became the Processor
Operations (ProcOps) component of the Tivoli System Automation (TSA)
product. So the underlying architecture and infrastructure that BCPii is based
on has been there quite awhile. What is new is the SNMP layer and the ability
to use the internal network to go from image to image.
I ran the original task force in 1989 that defined the underlying architecture
and I am a co-author of the patent that was issued for the architecture. The
idea for BCPii came from me to solve a GDPS hardware control problem and I
brought together the folks that funded and coded the initial GDPS
implementation. Other folks in z/OS found a need for hardware control and the
GDPS implement was subsequently reworked into system code. I haven't had
anything to do with it directly in quite awhile, but I do keep an eye on it.
W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
