CICS Web Services
Mark Pace
--
Edward M Martin
Hello Mark,
Even with the SET DNS1 and DNS2, I had to do a SET DEFAULT_DOMAIN.
Ed Martin
Aultman Health Foundation
ext 35050
Alice Faria
sublib comes first TCPIP's or LE's? Try inverting the concat you have now.
Rich Smrcina
Does your VSE system have a locally resolvable hostname?
--
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com
Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
Mark Pace
Mark Pace
Mark Pace
Mark Pace
Edward M Martin
Hello Mark,
You definitely have to have the TCP/IP libraries before the LE libraries.
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Mark Pace
Sent: Wednesday, December 08, 2010 11:25 AM
To: VSE Discussion List
Mark Pace
Mark Pace
Tim Kessler
I think you need a DEFINE NAME,NAME=xxxx,IPADDR=vseipaddr
After doing that hopefully it will work. Next make sure you have your TCPIPSERVICE set correctly and active.
Senior Software Engineer
Velocity Software, Inc.
Main (650) 964-8867
http://www.velocitysoftware.com
Mark Pace
Edward M Martin
Hello Mark Pace,
Do you have the EZATRUE in your PLTPI?
Just backing up to the beginning.
indust...@winwholesale.com
> Issued a SET DEFAULT_DOMAIN=S390.MAINLINE.COM
> Cycled CICS and it made no difference.
DOMAIN .WINWHOLESALE.COM
So try specifying just your domain name -- which is: MAINLINE.COM
Sincerely,
Dave Clark
WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331
*********************************************************************************************
This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission.
*********************************************************************************************
David Stuart
There is an IBM Redbook called CICS Transaction Server for VSE/ESA: CICS Web Support , SG24-5997-00. It's a few years old, now, but I followed it, and when I got done, I had it working with the sample applications.
Dave
Dave Stuart
Prin. Info. Systems Support Analyst
County of Ventura, CA
805-662-6731
David....@ventura.org>>> "Mark Pace" <pacema...@gmail.com> 12/8/2010 9:35 AM >>>
Thanks, Tim, I do have the DEFINE NAME and it shows up with a Q NAMES.
I have a TCPIPSERVICE, and AFAIK it is set correctly, but it will not become
ACTIVE if TCPIP is closed, which it is do to the error I'm chasing.
On Wed, Dec 8, 2010 at 12:30 PM, Tim Kessler <ti...@velocitysoftware.com>wrote:
> Mark,
> I think you need a DEFINE NAME,NAME=xxxx,IPADDR=vseipaddr
>
> After doing that hopefully it will work. Next make sure you have your
> TCPIPSERVICE set correctly and active.
>
> *Tim Kessler*
> Senior Software Engineer
> Velocity Software, Inc.
> Main *(650) 964-8867*
> [image: Signature]
> *http://www.velocitysoftware.com* <http://www.velocitysoftware.com/>
Mark Pace
Mark Pace
David Stuart
It's required for CICS Listener support. I don't remember exactly when it was introduced. Caused me some heartache, at first.
I have it specified in both the PLT start-up and shutdown 'decks', as follows:
DFHPLT TYPE=ENTRY,PROGRAM=EZASTRUE CICS LISTENER 'EXIT'
Dave
Dave Stuart
Prin. Info. Systems Support Analyst
County of Ventura, CA
805-662-6731
David....@ventura.org>>> "Mark Pace" <pacema...@gmail.com> 12/8/2010 10:33 AM >>>
Uh, no.
Doing some research now to figure out what this is.
Thanks.
On Wed, Dec 8, 2010 at 12:39 PM, Edward M Martin <EMa...@aultman.com>wrote:
> Hello Mark Pace,
>
>
>
> Do you have the EZATRUE in your PLTPI?
>
>
>
> Just backing up to the beginning.
>
>
>
> Ed Martin
>
> Aultman Health Foundation
>
> 330-363-5050
>
> ext 35050
>
> *From:* owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] *On Behalf
> Of *Mark Pace
> *Sent:* Wednesday, December 08, 2010 11:50 AM
>
> *To:* VSE Discussion List
> *Subject:* Re: CICS Web Services
>
>
>
> Could this have anything to do with the fact that I have 2 interfaces? One
> on an OSA with a public IP and one on Hipersockets with a private IP
> address?
>
> On Wed, Dec 8, 2010 at 11:32 AM, Mark Pace <pacema...@gmail.com> wrote:
>
> Thanks - I'll go back to the original LIBDEF concatenation.
>
>
>
> On Wed, Dec 8, 2010 at 11:28 AM, Edward M Martin <EMa...@aultman.com>
> wrote:
>
> Hello Mark,
>
>
>
> You definitely have to have the TCP/IP libraries before the LE libraries.
>
>
>
>
>
> Ed Martin
>
> Aultman Health Foundation
>
> 330-363-5050
>
> ext 35050
>
> *From:* owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] *On Behalf
> Of *Mark Pace
> *Sent:* Wednesday, December 08, 2010 11:25 AM
> *To:* VSE Discussion List
> *Subject:* Re: CICS Web Services
Mark Pace
Tim Kessler
Are you sure the name is defined with the correct IP address on the correct stack (if more than one)?
I received the same error codes prior to defining the name. It came up without problems after defining it.
Perhaps posting a copy of your config deck may help.
I am running 10/14/10 version of IPNRBSDC if that could make a difference.
Velocity Software, Inc.
Mark Pace
Tim Kessler
Trying defining a name for IPADDR=10.6.0.9 in addition to the other one.
Senior Software Engineer
Velocity Software, Inc.
Main (650) 964-8867
http://www.velocitysoftware.com
Mark Pace
Edward M Martin
Hello Mark,
The EZATRUE is found in the new TCP/IP for VSE/ESA – IBM Program Setup and Supplementary Information SC33-6601-09.
And it must be after the DFHDELIM and before the EZACIC20.
Plus I found that I had to have a couple of other entries to ensure that it had time to start.
DFHPLT TYPE=ENTRY,PROGRAM=DFHDELIM
EZASTRUE DFHPLT TYPE=ENTRY, MUST BE STARTED X
PROGRAM=EZASTRUE
<other entries here>
EZACIC20 DFHPLT TYPE=ENTRY, INITIATE TCPIP CICS SOCKET X
PROGRAM=EZACIC20
The Return code x’0079’ is an LE Environment return code not a TCP/IP code.
TCP/IP decimal 121 is EINVAL listen() was not called for socket descriptor socket.
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Mark Pace
Sent: Wednesday, December 08, 2010 2:43 PM
To: VSE Discussion List
Subject: Re: CICS Web Services
Good idea, but no change.
Tim Kessler
Try adding SET IPADDR=default ip address
Doc says IPaddr = - Specifies the default network address of the TCP/IP for VSE partition
Senior Software Engineer
Velocity Software, Inc.
Main (650) 964-8867
http://www.velocitysoftware.com
Okay - here is the one thing that has me confused, and wonder if it's because of the 2 interfaces.
162 q optionsF7 0161 IPN253I << TCP/IP Current Options >>F7 0161 IPN452I System ID: 00F7 0161 IPN453I IP Address: 0.0.0.0 Submask: 0.0.0.0<snip>
Mark Pace
Martin Trübner
I understand that Tim is the winner- and you have it working- good!
but was there any other ingredients that was needed?
I know that I have it working and have no PLTPI, but what about DNS and
LIBDEF-chains?
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Mark Pace
billy.bi...@suddenlink.net
Mark Pace
Mark Pace
Edward M Martin
Hello Mark,
The EZASTRUE/EZACIC20 will be needed if you will start using the EZAO control functions.
The SET IPADDR is a required (I thought) parameter in all IPINIT decks.
Ed Martin
Aultman Health Foundation
ext 35050
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Mark Pace
Sent: Friday, December 10, 2010 9:16 AM
To: VSE Discussion List
Subject: Re: CICS Web Services
I removed the DFHPLT entries for
Tony Thigpen
The phases in the DFHPLT are for the EZA interface only.
Tony Thigpen
-----Original Message -----
From: Mark Pace
Sent: 12/10/2010 09:16 AM
> I removed the DFHPLT entries for
> EZASTRUE
> EZACIC20
>
> Did a COLD start and CWS still starts.
>
> On Fri, Dec 10, 2010 at 9:06 AM, Mark Pace <pacema...@gmail.com
> <mailto:pacema...@gmail.com>> wrote:
>
> It's hard to say unless I back out each of the other changes I made.
>
> The LIBDEF chains are fairly well documented, especially in APAR
> II12448, that the TCPIP library MUST come before the LE library for
> CICS.
>
> I'll remove the PLT entires, COLD start and try again to see if that
> changes anything.
>
> 2010/12/10 Martin Trübner <mar...@pi-sysprog.de
> <mailto:mar...@pi-sysprog.de>>
Mark Pace
Tony Thigpen
address. Some IP applications do not use gethostid() or the EZA
GETHOSTID so they don't care that it was not specified in the IPINIT.
Tony Thigpen
-----Original Message -----
From: Mark Pace
Sent: 12/10/2010 10:40 AM
> Apparently the SET IPADDR is not required as I've not had one coded in
> all the years I've run TCPIP for VSE.
>
> I really appreciate all the help over the last few days.
>
> On Fri, Dec 10, 2010 at 10:34 AM, Edward M Martin <EMa...@aultman.com
> <mailto:EMa...@aultman.com>> wrote:
>
> Hello Mark,
>
>
>
> The EZASTRUE/EZACIC20 will be needed if you will start using the
> EZAO control functions.
>
> The SET IPADDR is a required (I thought) parameter in all IPINIT decks.
>
>
>
> Ed Martin
>
> Aultman Health Foundation
>
> 330-363-5050
>
> ext 35050
>
> *From:* owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU
> <mailto:owner...@Lehigh.EDU>] *On Behalf Of *Mark Pace
> *Sent:* Friday, December 10, 2010 9:16 AM
> *To:* VSE Discussion List
>
>
> *Subject:* Re: CICS Web Services
>
>
>
> I removed the DFHPLT entries for
>
> EZASTRUE
>
> EZACIC20
>
>
>
> Did a COLD start and CWS still starts.
>
> On Fri, Dec 10, 2010 at 9:06 AM, Mark Pace <pacema...@gmail.com
> <mailto:pacema...@gmail.com>> wrote:
>
> It's hard to say unless I back out each of the other changes I made.
>
>
>
> The LIBDEF chains are fairly well documented, especially in APAR
> II12448, that the TCPIP library MUST come before the LE library for
> CICS.
>
>
>
> I'll remove the PLT entires, COLD start and try again to see if that
> changes anything.
>
>
>
> 2010/12/10 Martin Trübner <mar...@pi-sysprog.de
> <mailto:mar...@pi-sysprog.de>>
Chris Mason
----- Original Message -----From: Mark Pace
Sent: Wednesday, December 08, 2010 4:41 PMSubject: CICS Web ServicesI'm trying to implement CICS Web Services in CICS/TS z/VSE 4.2.I've added TCPIP=YES to the SITverified the correct // OPTION SYSPARM='00' matches the tcpip SYSPARM='00'Also add the VSELST2 to the GRPLIST concatenation.add a DEFINE NAME and SET DNS1 top TCPIP.When I start CICS I get the following error.
F8 0182 DFHSO0117 PRODCICS
Unable to determine the TCP/IP host name. Language Environment returncode X'00000079', reason code X'000000FF'. TCP/IP services areunavailable.
Now the manual says to look inz/OS UNIX System Services Messages and Codes manual.Is this really where I have to go to find a VSE TCPIP problem?
Chris Mason
Sent: Friday, December 10, 2010 3:08 PM
Subject: Re: CICS Web Services
Tony Thigpen
his knowledge of VSE and it's IP implementations is extremely limited.
Even to the point that some of his contributions in that area cause more
problems than they resolve. I would suggest he spend his time posting
answers to questions he has the correct knowledge of (like VTAM, SNA,
etc.). Those are areas where his contributions have been very helpful.
The TCP/IP for VSE product from CSI, is not designed like any other IP
implementation that I am aware of. Trying to take any knowledge of the
z/OS or z/VM implementation and using it for configuration of the
product is of very limited, if any, value.
The IPv6/VSE product (FKA TCP/IP-Tools) from BSI is designed more like a
linux implementation. It is not configured anywhere like the CSI
product. It has some configuration items similar to z/OS & z/VM, so z/OS
or z/VM IP configuration knowledge may or may not transfer.
When Chris states "What I find rather puzzling is that CWS documentation
does not explain that you need to have a SET IPADDR statement and then
explains what the purpose of setting it is so that you can work out the
appropriate value.", he should not be puzzled. The SET IPADDR
configuration item is specific to the CSI product. CWS was originally a
z/OS application. When it was written, it's authors had no expectation
that they would ever be running on VSE. It has been my experience that
CWS is very 'picky' about a lot of things, like return codes. If CWS
does not know a specific return code for an error, it just cancels
without even providing the actual return code that it did not like.
Another aspect of CWS is that the LE return codes it is providing are
not always the real IP return codes. That is why looking up the return
codes in the message yielded bad information.
On the subject of gethostid(), z/OS and z/VM return an IPv4 IP address.
They did this long before there was any IP on VSE. While both z/VSE IP
products have chosen to follow this convention, other platforms (like
Linux) do not. This is not the case on all other platforms. Linux, for
one, does not. It returns a unique 32bit number. No application should
ever depend on it being a valid IPv4 address. (Wait until we have IPv6
only stacks, then see what happens since there is no IPv4 address.)
Most everybody on this list knows who I am, but maybe Chris does not. I
am the author of the API for the BSI IPv6/VSE product. As that author, I
wrote the very first EZA interface for VSE quite a while before IBM
added their EZA interface to VSE.
Tony Thigpen
> *From:* Mark Pace <mailto:pacema...@gmail.com>
> *To:* VSE Discussion List <mailto:vs...@Lehigh.EDU>
> *Sent:* Wednesday, December 08, 2010 4:41 PM
> *Subject:* CICS Web Services
Chris Mason
> Chris has a lot of information stored in his gray matter, unfortunately,
> his knowledge of VSE and it's IP implementations is extremely limited.
Indeed it is. Prior to dealing with any particular thread it is just about
zero so what I can glean about any particular VSE IP implementation I pick
up from the thread - not that I consciously claim to use any knowledge other
than what is evident from thread posts or, much less, pontificate upon it.
> Even to the point that some of his contributions in that area cause more
> problems than they resolve. I would suggest he spend his time posting
> answers to questions he has the correct knowledge of (like VTAM, SNA,
> etc.). Those are areas where his contributions have been very helpful.
I disagree.
I believe what I contributed on this occasion to a VSE list thread - and on
others - advanced the sum of human knowledge.
If I have promoted any incorrect knowledge, please quote chapter and verse.
I cannot see any. We will be coming to a point later where you reminded me
that gethostid() is not as limited as it is in the VM and "MVS"
implementations.
> The TCP/IP for VSE product from CSI, is not designed like any other IP
> implementation that I am aware of. Trying to take any knowledge of the
> z/OS or z/VM implementation and using it for configuration of the product
> is of very limited, if any, value.
I didn't so you must have misunderstood.
What I did was indicate how the *standard* gethostid() function, common to
all platforms with have IP support available to them in some shape or
fashion, gets a value assigned to it. In your case it is VSE but, being a
*standard* function, precisely the same requirement exists also with VM and
"MVS". From what you say later, the product about which we are talking, CWS,
would appear to want to use that value in the same way in vse AS IN "MVS"
being essentially the same code.
I think a touch of emphasis is needed. I contributed to this thread because
gethostid() is *standard*. Later that will become even clearer. Until there
was some focus on gethostid() I kept my nonexistent council.
> The IPv6/VSE product (FKA TCP/IP-Tools) from BSI is designed more like a
> linux implementation. It is not configured anywhere like the CSI product.
> It has some configuration items similar to z/OS & z/VM, so z/OS or z/VM IP
> configuration knowledge may or may not transfer.
I'm sure this point must be relevant but quite how is not at all clear.
> When Chris states "What I find rather puzzling is that CWS documentation
> does not explain that you need to have a SET IPADDR statement and then
> explains what the purpose of setting it is so that you can work out the
> appropriate value.", he should not be puzzled. The SET IPADDR
> configuration item is specific to the CSI product.
If CWS is supposed to work with this particular VSE implementation, the
documentation should cater for this. It may be that it doesn't actually say
"Ensure SET IPADDR is specified." but, if the program relies on the
gethostid() value, it should insist that the systems programmer work out
what statement is required in whatever implementation they happen to be
using and what the significance is.
Actually, we still haven't had that CWS requirement mentioned. Perhaps
somebody knows that the gethostid() value must be specified in such a way
that, when translated to a name, that name becomes the name the CWS
component is configured to expect - or something like that. It would seem
that, by some happy chance, Mark Page and Tim Kessler happen to have
specified the appropriate value.
> CWS was originally a z/OS application. When it was written, it's authors
> had no expectation that they would ever be running on VSE. It has been my
> experience that CWS is very 'picky' about a lot of things, like return
> codes. If CWS does not know a specific return code for an error, it just
> cancels without even providing the actual return code that it did not
> like. Another aspect of CWS is that the LE return codes it is providing
> are not always the real IP return codes. That is why looking up the return
> codes in the message yielded bad information.
Again I'm not quite sure where this is relevant to my contribution. Perhaps
it is just a way of answering Mark Pace's original compliant about being
asked to refer to the z/OS UNIX System Services Messages and Codes manual.
> On the subject of gethostid(), z/OS and z/VM return an IPv4 IP address.
> They did this long before there was any IP on VSE. While both z/VSE IP
> products have chosen to follow this convention, other platforms (like
> Linux) do not. This is not the case on all other platforms. Linux, for
> one, does not. It returns a unique 32bit number. No application should
> ever depend on it being a valid IPv4 address. (Wait until we have IPv6
> only stacks, then see what happens since there is no IPv4 address.)
Here Tony and I happen to have some level of agreement - although he
wouldn't know why!
Long ago, shortly after I discovered "sockets" - because VTAM got the
brilliant and very much lamented "AnyNet Sockets over SNA" capability - I
produced a "sockets exerciser" program for running under TSO - later I
discovered VTAM development had just about exactly the same program - and
now you can use REXX - *and* a set of lecture notes describing sockets. The
interesting thing about gethostid() is that it is not really a sockets call
but rather an UNIX call. It is only in the C sockets interface in the "MVS"
implementations - copied from the VM implementation - that the value
returned is one of the interface IP addresses. Tony is here reminding us of
this fact - although it seems he is most familiar with Linux.
It was because I knew what the "official" nature of the value returned by
the original gethostid() call was that I produced the following notes in my
lecture material - from about 17 years ago now:
<quote>
<foil>
---------------------------------------------------
| id <--- gethostid() |
---------------------------------------------------
Gethostid
obtain an unique identifier for the system
id - an unique system identifier
<notes>
The GETHOSTID Subroutine
unsigned long gethostid();
id <--- returned
Returned Value
id - an unique identifier for the system
Implementations may have chosen to use the internet address of the only or
primary interface of the host in host byte order. This is actually, in
general, not good practice.
</quote>
So you can see I was less that impressed by hijacking an interface address
as an excuse for an unique identification.
I'll even let you all know about a little bit of a mess I got myself into by
not knowing that DB2 used the gethostid() value and required it to be an IP
address which mapped to a name used in some way uniquely to qualify which
DB2 instance was running - or something like that. I respecified the IP
definitions for an - I think/hope in retrospect - development rather than a
production LPAR and I "tidied up" the static VIPAs. In so doing I, in
effect, changed the PRIMARYINTERFACE specification which caused the value
returned by the gethostid() call to change. The following day, DB2 didn't
work and sometime in the afternoon, I was descended upon once someone had
worked out why DB2 wasn't working any more. Fortunately the "upgrade" to the
IP environment had included an SNMP package I had put together which I
swiftly used in order to respecify the PRIMARYINTERFACE. DB2 instantly
worked!
Maybe some remnant of my disapproval of the way the gethostid() value was
set in the "MVS" implementation had led me into failing to appreciate that a
product like DB2 could actually rely upon this theoretically inappropriate
association of the gethostid() value with one of the interface IP addresses.
> Most everybody on this list knows who I am, but maybe Chris does not. I am
> the author of the API for the BSI IPv6/VSE product. As that author, I
> wrote the very first EZA interface for VSE quite a while before IBM added
> their EZA interface to VSE.
Actually I was vaguely aware that you had something to do with one of the
VSE IP implementations. However, yet again, I'm not sure how relevant this
is. The information being bandied about here is information with which I
would expect any systems programmer who used CWS to be familiar.
Incidentally you should not rely on simply being known by list contributors.
I expect there are folk joining the list all the time who cannot be expected
to have the accumulated knowledge of the foibles on display.
Chris Mason
----- Original Message -----
From: "Tony Thigpen" <to...@vse2pdf.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Saturday, December 11, 2010 5:56 AM
Subject: Re: CICS Web Services
Martin Trübner
>> suitably barbed comment can be fired off in the direction of the
>> people responsible for the product
This is as good as "scratching the bulls horn" or "rubbing the back of
a wild boar on an oak tree" as the german saying is.
You are talking about a product (CICS/TS 1.1.) that has not seen any
innovation in 11 years.
Lately I heard "there is hope"
Ron Ashley
Ronald Ashley
System Programmer
256-535-1269
-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of Martin Trübner
Sent: Saturday, December 11, 2010 6:08 AM
To: VSE Discussion List
Subject: Re: CICS Web Services
Martin Trübner
>> In the last couple of months there have been e-mails that defame
>> each other.
I observed the same- maybe even longer than that...
anyway
My remark was not ment say anything against Chris-
just to point out that CICS/TS1.1
in VSE has a long history (is that better?)
Rich Smrcina
On 12/11/2010 08:32 AM, McBride, Catherine wrote:
>
> Yeah. A lot of us seldom post anymore for fear of being "jumped on". And no, Martin,
> you are not the problem. Far from it.
>
> <http://www.picapcpu.de>
>
--
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com
Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
Chris Mason
My previous post was the "good cop" version. Here's the "bad cop" version.
> ... unfortunately, his (Chris Mason's) knowledge of VSE and it's IP
> implementations is extremely limited.
But I do know how to use Google which can be a wonderful way of dealing with
"limited" "knowledge" - see later.
> Even to the point that some of his contributions in that area cause more
> problems than they resolve.
This is a difficult accusation with which to deal since it suggests
something general from what we are about to discover is quite particular. A
very dangerous and error-prone approach to take as most basic education is
at pains to point out. Under analysis, we find the accusation in the
particular is quite false!
> I would suggest he spend his time posting answers to questions he has the
> correct knowledge of (like VTAM, SNA, etc.).
And indeed I do. However, is there perhaps some not so subtle subtext here
dependent on the contentious point just made that I should *not* spend time
dealing with anything to do with VSE TCP/IP? Actually I don't unless I see
some confusion that relates to some point which is *not* specifically
dependent on the product - as here - and as I indicated in my original post:
>...> I've been following this because I just might have a word to say if it
>somehow involves a general IP-related matter. Now it just about does.
> The TCP/IP for VSE product from CSI, is not designed like any other IP
> implementation that I am aware of. Trying to take any knowledge of the
> z/OS or z/VM implementation and using it for configuration of the product
> is of very limited, if any, value.
I think I have now worked out to what this comment applies. I would have
preferred a clearer "charge sheet"!
Incidentally, this has been a thread of implications. I have to assume that
Dave Clark spotted that the implementation being talked about was the CSI
implementation and I, in effect, have confirmed that the SET IPADDR command
applied to the CSI product.
I suggested that the value set by the SET IPADDR command was an address of
one of the IP interfaces on the VSE IP node. Having checked on what is said
in all prior posts in the thread, I see that I jumped to a conclusion here
and that jump was probably caused by noting the way the VM and "MVS"
implementations of IP support the gethostid() function.
In a sense, this was "guilty as charged". But there are very persuasive
extenuating circumstances.
On the basis of the following comments:
> CWS is programmed so that it requires that gethostid() returns a valid
> address. Some IP applications do not use gethostid() or the EZA GETHOSTID
> so they don't care that it was not specified in the IPINIT.
>> Apparently the SET IPADDR is not required as I've not had one coded in
>> all the years I've run TCPIP for VSE.
> On the subject of gethostid(), z/OS and z/VM return an IPv4 IP address.
> They did this long before there was any IP on VSE. While both z/VSE IP
> products have chosen to follow this convention, other platforms (like
> Linux) do not. This is not the case on all other platforms. Linux, for
> one, does not. It returns a unique 32bit number. No application should
> ever depend on it being a valid IPv4 address. (Wait until we have IPv6
> only stacks, then see what happens since there is no IPv4 address.)
I was ready to discover that the SET IPADDR command would be better
understood if it had been designed as the SET HOSTID command. This would be
appropriate if the SET IPADDR command had one purpose only which is to
provide a value to be returned by the gethostid() command.
Now it was time - shock, horror - actually to bother to discover what the
product authors say about the SET IPADDR command:
<quote>
SET IPADDR
The SET IPADDR command sets the default network address of TCP/IP for VSE.
Syntax:
SET IPaddr=ipaddr
Arguments:
ipaddr - An IP address (more)
Specifies the network address of the TCP/IP for VSE partition.
Example:
86 set ipaddr = 192.168.0.9
F8 0084 IPN367I IP Address is set to 192.168.0.9
F8 0084 IPN188I IP Address 192.168.0.9 = Net: 43008 Subnet: 0 Host: 9
F8-0086 IPN300I Enter TCP/IP Command
Notes:
The SET IPADDR= command must be specified in the initialization library
member and, once specified, should not be changed without restarting TCP/IP
for VSE.
The IPN188I message in response to the SET IPADDR command shows the network
and sub-network numbers after the subnet mask is applied. The mask is set
using the Set Mask command.
This IP address may be overridden with the IPADDR parameter on the Define
Link command. See the TCP/IP for VSE Installation Guide for information
about how to do this.
</quote>
http://tcpdoc.csi-international.com/csi-products/tcpip/command/sipad.html
Well, it's because this explanation - *from the product authors* - of what
the SET IPADDR command means is so much closer to what I assumed than what
Tony Thigpen is suggesting - a suggestion with which I would tend to agree,
by the way - that I decided Tony Thigpen's contribution was so unwarranted
and deserved the "bad cop" response.
All this fancy converting of the IP address into its "net" and "host"
components does rather rub one's nose into accepting that they really,
really mean this parameter to be an IP address - to say nothing of a
complementary SET MASK command. Also note there is nary a word about the
gethostid() function.
That last note about the value being overridden by the IPADDR parameter of a
DEFINE LINK command is interesting. Once you take a look at the explanation
of the DEFINE LINK command[1] - and DEFINE ADAPTER command[2] - it is
evident that, in fact, SET IPADDR is some sort of default IP address most
relevant when the IP node supports only one interface.
All this indicates that my "SET
IPADDR=an-IP-address-of-one-of-your-interfaces" to which it would appear
Tony Thigpen is objecting should be attracting no objection whatsoever at
all on this earth ... So what the very many expletives deleted - bad cops
use lots of expletives I believe! - was Tony Thigpen complaining about?
Having discovered no merit at all in Tony Thigpen's objections, I will now
feel myself entitled more than ever in future to comment on something
related to IP-based implementations on VSE - even Tony Thigpen's very own -
if I feel something needs to be said!!! I think I may even allow myself some
Agincourt fingers! Ah - that's better!
In fact I approve - as indicated by my thoughts on the matter composed a
little time before November 1993 according to my lecture material - of the
idea that the value returned by the gethostid() function should be in line
with its original UNIX design and simply return a 32-bit number - quite
independent of anything to do with the IP addresses used by any of the
interfaces to the IP node.
The text associated with the original UNIX design - as I recall I obtained
it from the AIX manuals in 1993 - specifies that the number returned by
gethostid() should be a number unique to the UNIX node. Well, that may have
been an acceptable idea at the time it was dreamed up but I would expect it
can now be filed away with the statement from Thomas John Watson Senior that
the world needs only 5 computers![3]
If we assume for a moment that the SET IPADDR command really is a SET HOSTID
command, it does make sense to allow the 32-bit number to be specified in
the same way that an IPv4 IP address is specified - as a matter of
convenience.[4] To that extent the keyword "IPADDR" would be just about
acceptable - if potentially misleading.
> (Wait until we have IPv6 only stacks, then see what happens since there
> is no IPv4 address.)
If the function of providing the value returned by the gethostid() function
were given to a new command, say SET HOSTID, and, always allowing for
migration, if the new command is specified, the function of providing the
value returned by the gethostid() function no longer has anything to do with
the SET IPADDR command, one benefit would be to avoid the problem which Tony
Thigpen anticipates of all interfaces becoming IPv6 interfaces at some time
in the future.
> Most everybody on this list knows who I am, but maybe Chris does not. I am
> the author of the API for the BSI IPv6/VSE product. As that author, I
> wrote the very first EZA interface for VSE quite a while before IBM added
> their EZA interface to VSE.
Did this comment - indeed the whole post - remind anyone else of "Miya
sama"?
Chris Mason
[1]
http://tcpdoc.csi-international.com/csi-products/tcpip/command/deflink.html
[2]
http://tcpdoc.csi-international.com/csi-products/tcpip/command/defadap.html
[3] There is a similar 32-bit number embedded in the data link control
protocols used by - but not exclusive to - SNA. This is the node
identification in the exchange identification (XID) information fields.
Supposedly the first 12 bits (IDBLK) could be used uniquely to identify the
type of device and the following 20 bits (IDNUM) could be used uniquely to
identify the instance within type. Enough said!
[4] This would allow the standard INET_ADDR() subroutine call to be used in
order to convert from the external character, "dotted" decimal, form of the
32-bit to the internal 32-bit number. What is rather less well known I
believe is that wherever the usual 4 part "dotted decimal" character string
is used, if - as I would universally expect - it is converted to the 32-bit
number using the standard INET_ADDR() subroutine call, quite a variety of
character string representations of the 32-bit number can be used, according
to my notes on the character string which is the INET_ADDR input:
<quote>
- a pointer to a character string containing an internet address in the
conventional "dotted decimal" format with a null byte to indicate the end of
the string.
The usual four-part address has periods separating the four byte values.
A three-part address implies that the last part is the number for the last
two bytes.
A two-part address implies that the last part is the number for the last
three bytes.
A one-part address implies that the whole address is given as one number.
The number or numbers can actually be decimal, hexadecimal or octal using
the usual C notation.
</quote>
----- Original Message -----
From: "Tony Thigpen" <to...@vse2pdf.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Saturday, December 11, 2010 5:56 AM
Subject: Re: CICS Web Services
Chris Mason
----- Original Message -----Sent: Friday, December 10, 2010 3:08 PM
Subject: Re: CICS Web Services
Eric Vaughan
Please take this outside, literally.
-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf
Of Chris Mason
Sent: Sunday, December 12, 2010 2:41 PM
To: VSE Discussion List
Tony Thigpen
is to issue the following before terminating:
gethostid()
gethostname()
The value of gethostid() is displayed by CEMT INQ,TCPIPService.
Tony Thigpen
Louis Callari
I just got an email that IBM is having a Webinar on 12/14 for VSE 4.3. The registration link is
http://ibmstg.adobeconnect.com/ibmzvse1214e/event/registration.html
This webcast will discuss details of the new z/VSE Version 4.3. It will provide a release overview and the latest news on z/VSE - starting with the z/VSE roadmap and strategy; followed by exploitation of IBM hardware; latest functional enhancements of z/VSE components; and VSE connector enhancements. It will also discuss the statement of direction made in the October announcement.
The speaker is Ingolf Salm, IBM Boeblingen - Linux on System z & z/VSE Development.
Has this been announced on vse-l, I don't remember seeing it.
Louie Callari
Sitel
Chris Mason
You may skip the first four paragraphs because - ignorant though I am - I go
on to indicate what this DFHSO0117 message actually means and not only *how*
it can be avoided but *why* it is then avoided!
Eric
> Chris, et al. This has stopped serving the needs of the general list.
> Please take this outside, literally.
Very, very much to the contrary.
If you are distressed by the turn events have taken I very strongly suggest
you direct your comments to the source of the unpardonable slight, namely
the person who suggested I was not qualified through some sort of falsely -
as proved and to be proved - perceived ignorance to contribute to the list -
and - not to the aggrieved party - or is there some sort of hidden agenda
here to discourage any but a small coterie from using the list facilities?
Answer please.
If I am insulted on the list I shall - several expletives deleted - defend
myself on the list and you have no right whatsoever to suggest otherwise.
There, I feel better again!
However you and, in fact, Tony Thigpen by his latest contribution have
reminded me that there is something which may well serve the needs of the
list - perhaps not the *general* list necessarily but those who are involved
with the installation of any product which behaves like CICS Web Support
(CWS)[1]. As I indicated in my first response, before it was rudely and
quite inappropriately suggested that my contributions were unwelcome, there
ought to be some hint in the description of the customisation required by
any such product that whatever means the underlying platform uses in order
to satisfy the calls made by the product need to be exercised.
Furthermore, in case the value is used in some way as it is in the case of
DB2 at least in the case of the "MVS" IP-based product, *how* the value
returned by such calls is used also needs to be covered.
If you take the trouble to scan back over the posts in this thread - which
you could at any time have suggested were not "serving the needs of the
general list" - you will see that not having used the SET IPADDR command
caused CWS to "barf". From the "q options" command output IPN453I message, I
see by forensic Googling that the "IP Address" value shows whatever has
supposedly been set by the SET IPADDR command. In other words, the default
value is 32-bit zero or 0.0.0.0.
<quote>
IPN453I IP Address: aaaa Submask: bbbb
(Response) This is the network address of TCP/IP for VSE and the mask that,
when applied to any address on its network, yields the subnetwork number.
These values are set during initialization by the SET IPADDR and SET MASK
commands. Note that these values must not be changed during TCP/IP for VSE
operation.
</quote>
http://www.tcpip4vse.com/csi-products/TCPIP/OnlineDoc/SP15F/messages.pdf
The post by Mark Pace of 08 December 2010 20:59 shows the IPN453I message
with a value of 0.0.0.0 for the "IP Address" and he had not at the time he
entered this command yet used the SET IPADDR command.
All this just indicates that Mark Pace had *not* used the SET IPADDR
command.
Unfortunately Tony Thigpen has been having us all worrying about the
gethostid() function when we should have been worrying about the
gethostname() function - see below.
-
Here's the REAL DEAL:
Let us go back to first principles.
What is the message which we and CWS don't like: "DFHSO0117"
I know it's revolutionary, but let's actually look it up. I used
http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/index.html
and ticked one of the VSE boxes.
<quote>
1.53.21 DFHSO0117
DFHSO0117 applid Unable to determine the TCP/IP host name. Language
Environment return code X'retcode', reason code X'rc'. TCP/IP services are
unavailable.
Explanation: Language Environment has returned a non-zero return code/reason
code to a gethostname call during Listener initialization.
System Action: Listener initialization terminates. The CICS region does not
open its TCP/IP interface.
User Response: Determine the reason for the gethostname failure. The return
code and reason code included in the message text are described in the
TCP/IP for VSE/ESA Messages and Codes manual.[2]
Destination: Console
Module: DFHSOCK
XMEOUT Parameters: applid, X'retcode',X'rc'
</quote>
The manual which LookAt discovered for the message was "IBM z/VSE Messages
and Codes Volume 3 Version 4 Release 1 Modification Level 1", SC33-8308-01.
I can't imagine why someone didn't mention it before - perhaps Rich Smrcina
knew something! - but message DFHSO0117 is all about the gethost***name***()
function and not the gethost***id**() function.
A pause while the enormity of this revelation sets in ...
Now I began to sense my ignorance of the CSI VSE IP product - but I quickly
resolved my discomfort! I verified in the TCP/IP for VSE Command Reference
manual that setting a "host name", in the sense - if Tony Thigpen will
excuse me - that the VM and "MVS" product do using the HOSTNAME parameter in
the TCPIP.DATA file, is just not implemented. Thus, if there is no way to
specify the "hostname" directly, it would appear that the host name must be
obtained indirectly to some degree.
Now I turned to the TCP/IP for VSE Programmer's Guide in order to see what
the development authors might have to say about how the gethostname()
function was supported, there being no obvious "hostname" available for the
purposes of satisfying the function.
<quote>
The function determines the local host's name by locating the local host's
address as determined by the SET IPADDR command. The function then scans the
name table that was created with command DEFINE NAME,ID=xxx,IPADDR=xxx until
it finds a match for the local host's address. If it finds a match, it
returns the associated name entry.
</quote>
Well that's everything explained really rather simply. The error message
upon which this whole shaggy dog story of a thread is based says that the
gethostname() function isn't working. The relevant manual explains what is
needed - and hence what just might be missing. A bit of QED there, don't you
think?
Doffing my hat to Tony Thigpen and his insistence that I deal with TCP/IP
for VSE quite independently from the VM and "MVS" implementations of IP node
logic, let me propose that the following pair of commands would have done
the job of providing a "host name" for the benefit of the gethostname()
function and ultimately the very demanding CWS:
SET IPADDR = 0.0.0.1
DEFINE NAME,IPADDR=0.0.0.1,NAME=whatever.name.you.may.happen.to.want
In other words, the IPADDR value is used only as a means of providing a
"host name" and need have absolutely nothing whatsoever to do with any of
the *real* IP addresses used for the IP node's interfaces.
Perhaps someone with a "sandbox" can try this out and report back.
-
I actually spent a lot of time checking Google References for "DFHSO0117
VSE" which, as we can now see was quite unnecessary. However - since it's a
shame to waste all the effort - here is a summary of what I discovered:
The following are manuals I unearthed possibly useful for people setting up
CWS:
- CICS Transaction Server for VSE/ESA, CICS Web Support and 3270 Bridge,
SG24-5997-00
-- November 2000
-- http://www.redbooks.ibm.com/redbooks/pdfs/sg245997.pdf
- CICS Transaction Server for VSE/ESA, Enhancements Guide, Release 1,
GC34-5763-03
-- June 2002
-- ftp://ftp.boulder.ibm.com/s390/zos/vse/pdf3/dfhwe703.pdf
- How to use Web Services with z/VSE
-- May 2009
--
ftp://ftp.boulder.ibm.com/s390/zos/vse/pdf3/HowToUseWebServicesWithzVSE.pdf
There was also a Technote:
- DFHSO0117 and DFHSO0002 enabling TCP/IP in CICS - Technote
(troubleshooting)
-- September 2004
-- http://www-01.ibm.com/support/docview.wss?uid=swg21052017
There was an earlier thread in October 2007 initiated by Victor Echavarry
Diaz but no solution was actually described within the thread despite the
presumed best efforts of a number of subscribers, some frequent
contributors. However, although the message was DFHSO0117, the Language
Environment return code was X'00000458'. The thread can be found in
whichever are your favourite VSE-L archives using the date "Oct 9 2007, 9:33
pm". All of the references above covered the problem precisely as reported
involving the lack of the DEFINE NAME command. Interestingly enough,
although one might imagine massive frustration in those referenced documents
over VSE system programmers' inability to appreciate the need for the DEFINE
NAME command, there was nary a word about the SET IPADDR command.
There are also a couple of presentations from one Karl De Vore but his
explanation was brief and appeared to relate to the order of "sublibraries".
One persistent theme is the matter raised by Billy Bingham, namely that
there is an unexamined assumption that an IP node requires an IP address:
"the local IP address it (CWS) is working under", "the dotted decimal
address of your VSE/ESA system", "its (the TCP/IP for VSE/ESA server) IP
address" and "your server IP address".
How does CWS know what "the local IP address it (CWS) is working under" is
and what is "the local IP address it is working under" supposed to mean?
That is, is only a single interface assumed and, if more, which interface is
relevant? In any case, it would appear that SET IPADDR provides what it
regards as "the local IP address it is working under" - and, incidentally,
since we have flogged this to death, the value returned by the gethostid()
function.
Anyhow all this variety of names betrays the woolly thinking of the authors
trying to describe an entity which, unless implemented using virtual IP
addresses, cannot exist!
Chris Mason
[1] I must apologise to all and sundry that I misnamed CWS as "CICS Web
Services" in an earlier post rather than "CICS Web Support". Perhaps this
was just the sort of "slip" that Tony Thigpen takes as an indication of how
hopelessly ignorant I am. In fact, this merely indicates the extent to which
I was using what was being discussed in thread posts rather than checking -
which I have now done. You will see that Mark Pace used the word "Services"
rather than "Support" in his initial post.
[2] Where we came in, as it were, with this thread was the following
complaint:
>...> Now the manual says to look in z/OS UNIX System Services Messages and
>Codes manual.
>...> Is this really where I have to go to find a VSE TCPIP problem?
Well, actually that's not true is it? Apparently the codes are to be found
in the "TCP/IP for VSE/ESA Messages and Codes manual" - but they're not
because there's no such manual! On the other hand codes which look as if
they should be equivalent to the codes observed can indeed be found in the
"z/OS UNIX System Services Messages and Codes manual". On the face of it,
this is a bit of a mess so it's as well the real problem can be solved
without having to rely on those pesky codes!
----- Original Message -----
From: "Eric Vaughan" <evau...@illustro.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Sunday, December 12, 2010 11:49 PM
Subject: RE: CICS Web Services
Chris, et al. This has stopped serving the needs of the general list.
Please take this outside, literally.
>> ----- Original Message -----
billy.bi...@suddenlink.net
Martin Trübner
Chris Mason
----- Original Message -----From: Mark Pace
Tony Thigpen
Near the bottom of the page.
Tony Thigpen
-----Original Message -----
From: Chris Mason
Chris Mason
----- Original Message -----
Sent: Friday, December 10, 2010 3:08 PM
Subject: Re: CICS Web Services
Chris Mason
> I understand that Tim is the winner - and you have it working - good!
> but was there any other ingredients that was needed?
> I know that I have it working and have no PLTPI, but what about DNS and
> LIBDEF-chains?
Just to emphasise what the *two* requirements are in order to be able to
support a program which uses the gethostname() function and gets a response
with which it is happy, they are *both* the SET IPADDR command *and* the
DEFINE NAME command.
Mark Pace already had the DEFINE NAME command
DEFINE NAME,NAME=MISZVSE.S390.MAINLINE.COM,IPADDR=199.44.167.69
but lacked the SET IPADDR command which clearly he set as
SET IPADDR=199.44.167.69
before the three bells appeared in his one-arm bandit windows.
I guess it's worth repeating in order to increase the chance that anyone
using the archives gets the correct answer, here again is the text from the
description of the gethostname() call in the CSI the TCP/IP for VSE
Programmer's Guide:
<quote>
The gethostname( ) function acquires the local host's assigned name, if one
exists.
...
The function determines the local host's name by locating the local host's
address as determined by the SET IPADDR command. The function then scans the
name table that was created with command DEFINE NAME,ID=xxx,IPADDR=xxx until
it finds a match for the local host's address. If it finds a match, it
returns the associated name entry.
</quote>
I've included the first line which contains the text "if one exists" which
is intriguing ...
Incidentally, just to be 100% sure now that I had dusted off the CSI TCP/IP
for VSE Programmer's Guide, I checked to see what was said about the
gethostid():
<quote>
The gethostid( ) function returns the IP address currently used by the local
TCP/IP for VSE host.
...
The address returned is the one established by the SET IPADDR command. This
is also true of multi-homed hosts.
</quote>
This only goes to confirm the earlier speculation since Tony Thigpen gave us
the association between the SET IPADDR command and the gethostid()
function - in the context of CICS Web Support
>...> CWS is programmed so that it requires that gethostid() returns a valid
>address.
>...> Some IP applications do not use gethostid() or the EZA GETHOSTID so
>they don't care that it was not specified in the IPINIT.
a herring, if not fully crimson, a delicate shade of pink - but still handy
to know about.
Also there's no "if one exists" for gethostid() but we have managed to work
out from Mark Pace's IPN453I message example that 0.0.0.0 is assumed.
Which inspires another possible "sandbox" test. Why not try something like
DEFINE NAME,NAME=MISZVSE.S390.MAINLINE.COM,IPADDR=0.0.0.0
in order to see if this allows the name to be set without having to bother
with the SET IPADDR command. If this works, I claim all the nickels - and
Mark Pace can throw away the SET IPADDR command he thought he never needed
and possibly still doesn't!
Chris Mason
----- Original Message -----
From: "Martin Tr bner" <mar...@pi-sysprog.de>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Friday, December 10, 2010 2:56 PM
Subject: Re: CICS Web Services
> Mark,
>
> I understand that Tim is the winner- and you have it working- good!
>
> but was there any other ingredients that was needed?
>
> I know that I have it working and have no PLTPI, but what about DNS and
> LIBDEF-chains?
>
Chris Mason
I appreciate you mean well and for that I thank you.
However, I fear your efforts here have to be classified with the manual name
published with the message - with the exonerating condition in your case
that it's not your job to provide accurate information, rather "best
efforts" unlike the VSE manual authors.
I thought I had visited this page some time before and downloaded all the
manuals. Prompted by your post, I checked again and saw "Messages and Codes"
and wondered how I had missed it.
However, once I had downloaded it I discovered it was exactly the same
manual that I had downloaded already which has the title "Messages - TCP/IP
for VSE - Version 1, Release 5, Service Level F". Note that there are no
"codes" either in the title or within the manual. Thus the title on the web
page is just wrong.
Chris Mason
----- Original Message -----
From: "Tony Thigpen" <to...@vse2pdf.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Wednesday, December 15, 2010 3:21 AM
Subject: Re: CICS Web Services
billy.bi...@suddenlink.net
Mark Pace
Also there's no "if one exists" for gethostid() but we have managed to workout from Mark Pace's IPN453I message example that 0.0.0.0 is assumed.
Which inspires another possible "sandbox" test. Why not try something like
DEFINE NAME,NAME=MISZVSE.S390.MAINLINE.COM,IPADDR=0.0.0.0
in order to see if this allows the name to be set without having to bother
with the SET IPADDR command. If this works, I claim all the nickels - and
Mark Pace can throw away the SET IPADDR command he thought he never needed
and possibly still doesn't!
Chris Mason
Mark Pace
Mark Pace
Chris Mason
----- Original Message -----From: Mark Pace
Sent: Wednesday, December 15, 2010 3:49 PMSubject: Re: CICS Web Services
Chris Mason
DEFINE NAME,NAME=MISZVSE.S390.MAINLINE.COM,IPADDR=199.44.167.69
----- Original Message -----From: Mark PaceSent: Wednesday, December 15, 2010 2:40 PMSubject: Re: CICS Web Services
Chris Mason
mick poil
general manuals can lack useful techie information. However, IBM do
know that and so Redbooks are often used to help to fill the gap.
In CICS Transaction Server for VSE/ESA Web Support and 3270 Bridge
SG24-5997 published in 2000, you will find appendix "A.3 Listing of
TCP/IP IPINIT00 with CWS parameters highlighted". And the first one
highlighted is actually SET IPADDR.
It is very easy to miss something vital that is written down
somewhere, I wish I could remember to look everywhere that might be
relevant when I am tearing my hair out trying to figure out why
something does not work.
The requirement for OS/390 Unix manuals was due to VSE development
basing their TCP/IP support on the OS/390 product that was available
at the time (as they did for the OS/390 API used by CICS TS), and I
guess that they decided that it was not worth the effort and cost to
duplicate another manual.
Mike
Chris Mason
>...> Now the manual says to look in z/OS UNIX System Services Messages and
>Codes manual.
>...> Is this really where I have to go to find a VSE TCPIP problem?
> The requirement for OS/390 Unix manuals was due to VSE development basing
> their TCP/IP support on the OS/390 product that was available at the time
> ... and I guess that they decided that it was not worth the effort and
> cost to duplicate another manual.
Thanks for the closest we have had yet to an explanation for Mark Pace's
original question.
> I know that CICS TS VSE general manuals can lack useful techie
> information. However, IBM do know that and so Redbooks are often used to
> help to fill the gap.
This isn't really an excuse. Redbooks should never be relied upon in order
to "fill the gap" where information is missing. If you need the redbook in
order to discover which even optional definitions need to be in place in
order to support calls that the program for which you are responsible makes,
then you have failed to provide adequate documentation. Once actually
written down, this becomes rather obvious.
Redbooks have a particular place in documenting some experience in getting
typically a new program or some particular new function within a program up
and running with sample definitions and a description of procedures and some
indication of the impact on supporting programming. In other words whatever
the people who are running the redbook project imagine they would like to
see if they were trying to do the same thing "at home". To this is, or
should be, added what ought to be known in sufficient detail to provide an
understanding of how to adjust the sample definitions for conditions in
their own installations and how best to use the product in various
circumstances.
I have been looking at the OSA-ICC redbook, OSA-Express Integrated Console
Controller Implementation Guide, SG24-6364-01, recently and this is quite a
good example of what I mean. The shame is that it doesn't cover VSE as a
worked example as it does z/OS and z/VM.
>From being in a position of not knowing the CSI "TCP/IP for VSE" product at
all, by following up on what I found in the exchanges in this thread - and
in another thread of 3 years ago - and looking into the product manuals, I
have been able to work out what gives rise to the failure of the
gethostname() call which caused the appearance of the DFHSO0117 message.
Simply stated and as documented with the gethostname() function in the CSI
"TCP/IP for VSE" Programmer's Guide the value set by the SET IPADDR
statement is used to look up the table created by DEFINE NAME statements
looking for a match on the value specified by the IPADDR operand. The first
such match found is provided by the gethostname() function.
Two Language Environment return codes are mentioned in the various places
where the DFHSO0117 message has been discussed. These are
a. X'00000458' when the DEFINE NAME statement is missing which probably more
precisely means that there may have been DEFINE NAME statements specified
but none had an IPADDR operand which matched the value set by the SET IPADDR
statement
b. X'00000079' when the SET IPNAME statement is missing
This latter one is interesting and invalidates an idea I had and encouraged
some of the contributors to this list to test. Actually it would still be
interesting to perform the tests but only in order to confirm that we who
care about this are on top of the matter in hand.
The idea was that the SET IPADDR statement was not necessary if the IPADDR
parameter in the DEFINE NAME statement specified IPADDR=0.0.0.0 since it was
evident from a IPN453I message resulting from a QUERY OPTIONS command that
the value assumed for this fictional IP address for the IP node was 0.0.0.0.
The point is that, if it was acceptable to use this assumed address for the
lookup of the table built from DEFINE NAME statements, there would be no
separate return code for the case where the SET IPADDR statement had not
been specified.
Thus, if an installation doesn't want to pretend that an IP address is
assigned to the IP node itself especially when there exist multiple
interfaces none of which ought to be considered in any sense additionally to
represent the IP node, the following statement pair should be considered
where the IPADDR parameter can be anything other than 0.0.0.0 but need have
nothing whatsoever to do with real IP interfaces:
SET IPADDR=0.0.0.1
DEFINE NAME mynode,IPADDR=0.0.0.1
where "mynode" is the character string used to identify the IP node for
whatever use local programming such as CWS may make of the name provided by
the gethostname() command.
But, returning to those codes, the problem isn't really which manual to use
for the codes since they all have the same explanation - and it's literally
useless!
They are actually as follows:
- X'00000458' The referenced socket is not a type that supports the
requested function.
- X'00000079' The parameter is incorrect.
Doh!
In the case of the gethostname() function, the significance of the codes
would appear to be the following:
- X'00000458' No match of the IP address (32-bit number) specified by the
SET IPADDR command with any IP address (32-bit number) in the table built
from DEFINE NAME commands.
- X'00000079' The SET IPADDR command has not been used in order to change
the default IP address (32-bit number) from the initial value 0.0.0.0.
Any relationship between the standard explanations of these codes and what
they actually mean in the case of the gethostname() function is quite
impossible to determine.
Incidentally, for consistency I would expect the gethostid() call to
return -1 with return code X'00000079' rather than 0.0.0.0. Someone may like
to test this and Tony Thigpen may like to take note.
It is only because of the many documents which mention of the case of the
missing - suitable matching - DEFINE NAME statement and this thread which
covers the case of the missing SET IPADDR statement that we know what these
codes could tell us if they could speak. The actual explanation of what is
returned by the gethostname() call belongs in the manual which describes the
API - and it's not there - obviously!
It's now my submission that there is going to need to be some compensation
for this dereliction of duty by the CSI developers in that CWS documentation
needs to work out what codes might appear for the case of *all* functions
used by CWS where the error could be caused by a configuration failure.
I've been here before - d j vu! - because, when I was putting together my
presentation on sockets programming - before I discovered that CICS had
produced quite a good one! - I tried to work out what all the error codes
were for all the sockets calls. The - whatever MVS was called in 1993 -
sockets manuals was clearly not fully reliable.
I wonder if Mark Pace realises what a perspicacious question he was asking
when he said "Is this really where I have to go to find a VSE TCPIP
problem?" Indeed none of the sources - and that includes the z/OS UNIX
System Services Messages and Codes manual - at the end of the day make any
sort of sense.
-
> In CICS Transaction Server for VSE/ESA Web Support and 3270 Bridge
> SG24-5997 published in 2000, you will find appendix "A.3 Listing of TCP/IP
> IPINIT00 with CWS parameters highlighted". And the first one highlighted
> is actually SET IPADDR.
I disagree profoundly. This redbook and this appendix in particular were no
help whatsoever in appreciating that the SET IPADDR statement was required.
And I am going to explain in considerable detail why.
It was only when I read your supposed excuse that I managed to work out what
those funny character arrows were to the right of the statement list!
In the sense that there is an arrow pointing to the statement far to the
right, I guess you could just about - on a good day - with the wind behind
you - reluctantly admit that the statement was not quite the same as most of
the other statements - just so long as you were using a magnifying glass and
actually noticed the *** arrows.
When I am told a definition statement in a redbook is highlighted, I
normally expect the statement to be in bold type. Indeed some statements are
in bold type - so I imagined this convention was in operation - and some of
them also have arrows to the right. But there are also statements which are
*not* in bold and have arrows to the right, including, of course, the now
famous SET IPADDR statement. And just to complete the muddle, there is also
one statement in bold which does *not* have an arrow to the right.
Those statements in bold with the arrow to the right:
DEFINE ROUTE - although only the GATEWAY operand is actually in bold - and
the title is most odd
DEFINE NAME - only the first one, presumably the one which is expected to
match the IP address and provide the gethostname() value
SET DNS1
Those statements actually in bold without the arrow to the right:
DEFINE HTTPD
Those statements not in bold with the arrow to the right:
SET IPADDR
DEFINE LINK
Note that the subset of the above statements which can be considered "CWS
parameters" on the basis that something is said about them in the body of
the redbook, principally section 3.1.3 TCP/IP, is the following list:
DEFINE HTTPD
DEFINE NAME
SET DNS1
This means that the claim that the statements are "CWS parameters" in regard
to the following statements does not stand up to examination:
DEFINE LINK
DEFINE ROUTE
SET IPADDR
This, of course, includes the famous SET IPADDR statement.
Thus your claim that SET IPADDR is needed for CWS customisation relies
solely and completely on a feeble character arrow to the far right of the
SET IPADDR statement which is so easy to miss it almost certainly will be.
When while trying to sort out what was said about DFHSO0117 having found the
redbook, I deliberately went to that appendix just to see if there was a SET
IPADDR statement there and whether or not anything was said about it. While
noticing that the DEFINE NAME statement was in bold, I concluded nothing
special was said about the SET IPADDR statement.
Incidentally, it probably *didn't* help that I *hadn't* first worked through
the DFHSIT listing - which I have just now spotted - where the "arrows" are
rather less easy to miss.
For the next point I got the feeling I was turning over stones and nasty
creepy-crawlies kept appearing and scuttling away!
Checking on whether or not there is any text in the body of the redbook to
support the supposedly highlighted statements, when checking on DNS1 I saw
that it is suggested/implied that having specified a name server and
presumably expecting to be able to map the SET IPADDR value to a name is an
alternative to having a DEFINE NAME statement. Well, this may be so but it
is *not* an idea supported by the "TCP/IP for VSE" Programmer's Guide
description of the gethostname() function. One of these two sources must be
wrong - and I know where my money is!
I'm afraid I find myself constantly having to advise that it's a feature of
redbooks that they range from superb to dismal which is why I say they
should not be absolutely necessary to install a product just additionally -
one hopes - helpful.
-
In case you're wondering how anyone could have a "CSI "TCP/IP for VSE"
system *without* a SET IPADDR statement specified it's a very reasonable
assumption that an installation revised their definitions to change from one
to many interfaces and understood that SET IPADDR was logically if not
actually obsolete as a means to specify the IP address of an IP interface.
After all, there is provision to specify the IP address on the interface
definition where IP architecture says it belongs. The same goes for the SET
MASK statement - in a slightly odd way![1]
In order to see if there just might be a redbook available in support of
this CSI "TCP/IP for VSE" product, I fairly quickly found the following at
the redbook web page:
Getting Started with TCP/IP for VSE/ESA 1.4
http://www.redbooks.ibm.com/abstracts/sg245626.html
It's of about the same vintage, May 2000, as the CICS Transaction Server for
VSE/ESA, CICS Web Support and 3270 Bridge, SG24-5997-00, redbook, November
2000, and there's a common oddity in the comment box over the DEFINE ROUTE
statements indicating a common stable: "Routine" for "Routing" - and "g" and
"e" are not actually adjacent on the keyboard!
This seems to be the only redbook available. It is noticeable that the
DEFINE LINK and DEFINE ADAPTER statements do not have IPADDR operands
specified which they do today. Indeed the assignment of IP addresses to the
interfaces is very odd indeed.
According to the sample configuration, the way IP addresses are associated
with their respective interfaces is by means of one SET IPADDR statement and
then a DEFINE ALTIP statement for each interface that should not default to
having the SET IPADDR value. Most odd - and I keep getting this vibe that
definitions should be kept simple for VSE users!
SET IPADDR = 192.168.155.108
DEFINE LINK,ID=IS3172,TYPE=3172,DEV=600,MTU=1492
DEFINE ADAPTER,LINKID=IS3172,NUMBER=0,TYPE=ETHERNET <== IPADDR =
192.168.155.108
* VSE240 F7 SECONDARY TCP/IP PARTITION
DEFINE LINK,ID=PARTF7,TYPE=IPNET,SYSID=07,MTU=4096,STOPPED <==
IPADDR=192.168.155.126
* VSE231 GUEST MACHINE UNDER VM/ESA
DEFINE LINK,ID=VSE231,TYPE=CTCA,DEV=402,MTU=4096,STOPPED <==
IPADDR=192.168.155.124
* VM/ESA 2.3 SYSTEM
DEFINE LINK,ID=VMESA,TYPE=CTCA,DEV=400,MTU=4096 <== IPADDR=192.168.155.125
DEFINE ALTIP, ID=VSE231, IPADDR=192.168.155.124
DEFINE ALTIP, ID=VMESA, IPADDR=192.168.155.125
DEFINE ALTIP, ID=PARTF7, IPADDR=192.168.155.126
It seems Mark Pace or one of his colleagues tumbled to how ridiculous a
structure this was, presumably at the time it became possible to specify the
IP address where it belongs on the DEFINE LINK or DEFINE ADAPTER statement.
The systems programmer then made much more sense of his/her "TCP/IP for VSE"
definitions and didn't look back - until the dual use of SET IPADDR as the
value returned by the gethostid() function directly and used as a way of
providing the value for the gethostname() function indirectly came along and
bit Mark in tender parts!
So there is still a role for the SET IPADDR statement - although I would
ideally like to see that role expressed as an alternative statement such as
a SET HOSTID statement. The role is twofold: to produce a value for the
gethostid() function and - this is the peculiar one - to produce a value for
the gethostname() function by means of a lookup in the table defined by
DEFINE NAME statements. Actually, I'd here prefer a less roundabout way of
specifying the name by use of a SET HOSTNAME statement and get it over with
at one go, as it were![2] Then there may actually be no need whatsoever at
all to have any DEFINE NAME statements since either the "TCP/IP for VSE"
node will never need to perform name to address translation - or address to
name translation - or, if such translations are needed, a name server can
invariably be used.
-
Having taken an interest in some of the definition statements in the
redbook, especially those supposedly highlighted, I see two operands on the
DEFINE LINK, HOSTNAME and HOSTAPPL, which supposedly should be there only
when TYPE=CLAW. Well, I appreciate I'm something like 10 years too late to
be providing review comments on the redbook!
-
> I have come in rather late on this one.
Because of the "out of office" messages which plague the CICS-L list, it is
in fact documented that you probably just missed the original post, the 8th,
since your OOO message appeared on 9th and you planned your return on 13th -
and people complain about Wikileaks!
Chris Mason
[1] Actually while reviewing this before posting, I think I know why the
DEFINE MASK is separate from the DEFINE LINK or DEFINE ADAPTER statements. I
expect it's all about "classless" and "classful". It would appear that CSI's
"TCP/IP for VSE" is essentially "classful" and that this new-fangled
"classless" idea should be treated with considerable caution and kept
separate from "pure" "classful" definition statements. Of course, I
exaggerate, but it's a bit odd!
[2] I was wondering what role the "hostname" value had in the architecture
of an IP node since it certainly is a parameter which "belongs to" the IP
node. It may or may not be instructive that the old original "TCP/IP for VM"
comes with a little test program which continued through to "TCP/IP for MVS"
and on to the z/OS Communications Server IP component. This is HOMETEST. The
HOMETEST utility TSO command locates the "hostname", adds the
"domain-origin" suffix string (roughly equivalent to the value set by SET
DEFAULT_DOMAIN in CSI "TCP/IP for VSE") if necessary and consults the
resolver function. This can involve a lookup in the local table and/or the
name server. HOMETEST is happy only when all IP addresses in the "home"
list, that is, the IP addresses of all interfaces defined to the IP node,
are returned as associated with the "hostname", qualified if necessary by
the "domain-origin" suffix string.
----- Original Message -----
From: "mick poil" <michael...@googlemail.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Thursday, December 16, 2010 8:33 AM
Subject: Re: CICS Web Services
mick poil
seem to suffer from some variant of dyslexia and was still able to
deduce the relevance of the arrows even from a first-time read.
But I decided otherwise.
Happy Christmas everybody.
Chris Mason
> But I decided otherwise.
So you decided to be rude instead of apologising for making an unsupportable
claim about the redbook having clearly explained what Mark Pace - and all
other contributors to the thread - missed.
I found a strong indication that Mark Pace may very well have used the
redbook in order to work out what he needed for CICS Web Support:
>...> add a DEFINE NAME and SET DNS1 top TCPIP.
This was his last bit of customisation he mentioned in his initial post.
I've no doubt he also added a DEFINE HTTPD but this didn't seem relevant to
a problem relating to a "host name" so it didn't get mentioned.
However if we take all three items: DEFINE NAME, SET DNS1 and DEFINE HTTPD,
we have precisely the three items that are described in the "3.1.3 TCP/IP"
section *and* are distinguished by appearing in bold type in "A.3 Listing of
TCP/IP IPINIT00 with CWS parameters highlighted".
But readers do not have to take my word for it that your statement
>...> In CICS Transaction Server for VSE/ESA Web Support and 3270 Bridge
>SG24-5997 published in 2000, you will find appendix "A.3 Listing of TCP/IP
>IPINIT00 with CWS parameters highlighted". And the first one highlighted is
actually SET IPADDR.
is offensive. They can work it out for themselves.
Chris Mason
----- Original Message -----
From: "mick poil" <michael...@googlemail.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Monday, December 20, 2010 8:53 AM
Subject: Re: CICS Web Services
Chris Mason
------
---------
You describe the two gethostid() and gethostname() functions later but the error cases can be discussed here.
-----------
-------------
----- Original Message -----From: Leo LangevinSent: Monday, December 20, 2010 1:59 PMSubject: RE: CICS Web ServicesChris,
I had read the beginning of the thread and was going to reply when it got a bit "ugly". So I wanted to see how it would pan out, with various conjectures as to how the VSE stack works, was designed, and is being used. So I decided to finally toss in a bit of useful information based on your last post.
DESIGN
----------
The VSE stack was not designed after Unix. What they both have in common are the RFC's that is part of the Internet community, and that's it. It was written entrely in Assembler, using VSE macros and control blocks, and it's implementation is different than Unix, VM, z/OS, and so comparing their implementations doesn't really work. For example, Unix does not have partitions and can share its massive chunk of storage across all programs, while we have a stack that runs in a set amount of storage that cannot grow without redefining and doing an IPL. It's a small thing, but interesting to note.
INTERFACE
--------------
Since the product was written in Assembler, the simplest method of access is to use our SOCKET macro. However, that only works for Assembler programs, and so we have a pre-processor that inserts a CALL to a routine that will issue the SOCKET macro calls for you. Now, IBM prefers to use the EZA or BSD interface (depending on what they are doing) as part of their language environment. So we have a general routine that will take these calls and feed it through the routine(s) that will issue the correct SOCKET macro call, and will return the updated values, including the return code. We did not write EZA or BSD, just the common way to use it. The return codes that you see in CWS are not from the VSE stack, but from the IBM routines that take the CSI return code and generate something extremely foreign to what was given. IBM has control as to what this is and what it means and it is up to them to document and explain their values.
It may even be further encumbered by CWS putting out its own codes, such as X'00000079' for a GETHOSTID failure (the CSI SOCKET CONTROL call returns a "4"). Because of the distance between the point where the VSE stack delivers the code and CWS displays a value, I am not certain at what point it decides that x'04' is better served by being X'79'
IP AND NAME
----------------
Now, one of the current (15F or prior, this will change in the next version) methods of getting information that is not really datagram related is to use the SOCKET CONTROL call. What this does is send a 16-byte command to an internal program (IPNACONT), which will fulfill the request and return a response. So, if GETHOSTBYNAME is send with a domain name, it will call the DNS client and have it resolve it (if possible) and then return a buffer to the calling application. If the return code information was non-zero, we will return that and the application will then do what it will with the information. In the case of CWS it ends up going through the IBM point of calling and that interface from them have some interesting hex results.
I am looking at the source code for our stack in another window as I type this, so what I am presenting is accurate as of 15F.
There are 5 DNS-type calls that an application program can issue. By "DNS-type", what I mean by that is that while it may call the DNS client (IPNADNSC), that interface may or may not call a DNS server, depending on the needs. These are:
GETHOSTBYNAME - Pass the string that contains the doman name and return the IPADDR value. It will first look at DEFINE NAME entries, and if no match, it will call the DNS server. This is the ismple explanation.
GETHOSTBYLUNAME - This is for TN3270 use. You give it the LUNAME as used in the DEFINE TELNETD and it will scan through the control blocks and return the IPADDR. This does not call IPNADNSC.
GETHOSTBYADDR - Pass the IP address of a specific domain and IPINADNSC will be invoked to find a DEFINE NAME in storage for a match, and if not, it wil call the DNS server to return the A-type record for the actual domain name. Again, this is simplified.
Now the next 2 are probably the ones that are causing so much grief, sort of, because of their form of use, but also because of the way that the application has chosen to use these calls.
GETHOSTID - IPNADNSC is called and it will look in storage for the local IP address as set during initialization. It is in a field we document internally as "IP address of Host". It is the same field output from a QUERY OPTIONS. During a DEFINE LINK, if no IPADDR is given, this is the value assigned to that LINK. If you manually enter another SET IP=, the stack will delete any existing value and it will replace the contents of that field with the new value, and then update all appropriate fields with the new value (simplification). As you can see, if you rely on GETHOSTID, then you will always only get this value and no other. And application can choose to require that this value is set or not, depending on the author. If the ability to associate with a specific link rather than a specific address is desired, then that is really an application design, choosing to use the single "IP address of host" over another way. If not set, then a default value is used.
GETHOSTNAME - IPNADNSC is called. All it really does is look in the control blocks for a DEFINE NAME that has an "IP=" that matches the value on the "SET IP=" parameter. If it finds a match, it returns a 64-byte response. If not, it returns RC=4. Some applications may not care if you have a DEFINE NAME or not, and some might.
Now, you can actually monitor this entire process by issuing the commands:
SET DIAG=CONT
SET DIAG=DNC
The firt one will display any SOCKET CONTROL calls going on, and what they were requesting. The second will show the DNS client request that came in and what it discovered. The output will go to SYSLST. (SET DIAG=RESET when you are done experimenting).
The design for CWS was obviously done from the point of view that there would be one IP address at one host that would be providing Web services. Since I don't have access to the code for CWS (we have our own Web services product, "Entree", which I do have access to), I ca how hard or easy it would be to make this adjustment. It's easy for someone on the outside who doesn't have the code to think it's something minor, but it's been my experience that this is often not the case and requires reworking. (With Entree, we don't care if you have multiple IP addresses or not. After all the internal Xsocket code will update the LOIP address with whatever the IP address of the route used to get there via the appropriate LINK. (I just verified that it does just that at OPEN time).
DOCUMENTATION
----------------------
I do agree that one should not require a "redbook" to do normal use action or support. Since CWS is an IBM product, then such issues should be addressed to them using the standard channels that we do for getting any change done. Looking at the CSI documentation for how CWS internally function (using the call to the IBM interface that calls the CSI stack), really won't be useful in understanding how it all really works.
I have some theories, but they are nothing more than that, so I'll let them pass.
Finally, I am available for a phone call if you want to discuss in-depth how the VSE stack actually works and interfaces. Despite this post, I really don't like to type much! ;)
Leo Langevin CSI International
Leo.Langevin@CSI-International.com (Powered by Entrיee)
1-800-795-4914 (ext. 3020) (USA)
052 565 6840 (Israel)
tbi...@orgill.com
Thank you for the information at the end of this post. I know this is an old post but I ran into this pissing contest looking for an answer to the same error message. After reading all these post and confirming I had everything set right I finally got to your post which helped me solve my problem.
The diagnostic commands you listed showed me it had an invalid SYSID value. Since I was trying to communicate with the '00' stack (The Default) I did not and never have had the // OPTION SYSPARM='00' in the CICS startup. Evidently this is necessary to resolve the host name because when I added it Web Services came up.
Thanks again, maybe this helps someone else down the road.
Tim