Matan
I don't understand what you mean by "marks". It could be you mean the
comment records in the procedure.[1]
I already define all of this ...
I'm not sure you have. You have *not* shown what you have specified for
the RESOLVER_PROC statement in the BPXPRMxx member used in the
initialisation of z/OS.
What you may have done is the following:
a. IPLed z/OS
b. Waited for everything to initialise including the procedure used to run
the IP
component of Communications Server (CS), typically TCPIP.
c. You may have noticed that an address space called RESOLVER is running -
since, unless the "resolver" function is running, CS IP will not initialise
successfully.
d. You may have observed the log of the address space called RESOLVER and
noted the EZZ9298I and EZZ9304I messages you reported in your first post
which indicate that the "resolver" function - as supported by the program
running in the address space named RESOLVER - is not using the parameters
specified in the file referenced by the SETUP DD-statement,
PANDAG.USER.TCPPARMS(SETUPRES) as we now know.
e. You may now have terminated the running RESOLVER address space - I
think you may have had to use "force" - as it were - to do this since I
believe
program EZBREINI is marked as "noncancellable" in the "program properties
table" module.
f. You then entered the command S(TART) RESOLVER which will have started
the RESOLVER procedure you created and filed away almost certainly in
SYS1.PROCLIB having copied the RESOLVER procedure from a CS IP
distribution library.[2]
g. You then discovered in the log of this new address space named RESOLVER
that the statements in the file referenced by your SETUP DD-statement are
being used as indicated, no doubt, in the EZZ9298I and EZZ9304I messages.
***But*** you have not solved your problem - because you don't want to
have to go through this sequence every time you IPL your z/OS system - do
you?
If there is some sequence which does *not* involve cancelling the original
RESOLVER address space and starting it "by hand", then we still have a
mystery. Just removing comment card image records from the procedure file
cannot have changed anything - or my thinning hair is in danger of thinning
further!
Both Brian Peterson and I have pointed you to the proper way to address
what we guess is your problem, namely a properly coded RESOLVER_PROC
statement in the relevant BPXPRMxx member. Although I asked you to post
this, you have not done so. Please read the post I entered as a comment on
what Brian told you. The best answer I/we can come up with is described
there.
For confirmation of what we said, you should find the log of the address
space
with the name RESOLVER which was the one which initiated as part of the IPL
process. That should show the procedure name IEESYSAS - I think since I
can't recall ever having see the log of such a procedure.
-
In case there is something else going on which we can't work out, you
should
check that what you assume is your solution works when you IPL your system.
-
A further point is that it is pointless to have the same member specified
for
both GLOBALTCPIPDATA and DEFAULTTCPIPDATA. Any parameter specified in
the file will be used because it is specified in GLOBALTCPIPDATA so that
DEFAULTTCPIPDATA cannot be adding anything!
Since we are talking about GLOBALTCPIPDATA and DEFAULTTCPIPDATA I may
as well take the opportunity to mention that there are some TCPIP.DATA
parameters which, if a file is specified using the GLOBALTCPIPDATA
parameter,
the parameters *must* all be specified in this file. They are
DomainOrigin/Domain, NSInterAddr/NameServer, NSPortAddr, ResolverTimeOut,
ResolverUDPRetries, ResolveVia, Search and SortList. If you miss out any of
these the default value will be used. It is no use trying to specify the
parameters in any of the locations in the "search order" which applies to
the
TCPIP.DATA file, namely:
GLOBALTCPIPDATA
Environment variable - RESOLVER_CONFIG if UNIX
/etc/resolv.conf if UNIX
//SYSTCPD DD statement
x.TCPIP.DATA where x is userid for UNIX and userid/jobname/procname for MVS
SYS1.TCPPARMS(TCPDATA)
DEFAULTTCPIPDATA
TCPIP.TCPIP.DATA
I wonder if that has any bearing on the other problems you have been having
setting up your name server.
Chris Mason
[1] Actually I ***hate*** the comment records in procedures as supplied by
IBM and I (used to) routinely remove all of them before using any of the
procedures. They so much get in the way of "seeing" what matters. Because
there may actually be a pearl of wisdom amongst all the dross, I (used to)
compromise by inserting one comment record after the PROC statement which
provides the names of the distribution library and the member so that the
original procedure with its verbiage can be found easily if desired.
[2] It helps that I know you have concerns over procedures supplied for CS
IP
by IBM as indicated in another of your threads.
On Tue, 16 Feb 2010 13:11:35 +0200, מתן כהן
<matancohen...@gmail.com> wrote:
the strangest thing of all .
after deleting all the marks in the procedure the resolver initialization
was successfully.
thanks .
2010/2/16 מתן כהן <matancohen...@gmail.com>
Chris,
I already define all of this ,
my problem is in the initailization of the resolver procedure :
11.06.36 STC01108 ---- TUESDAY, 16 FEB 2010 ----
11.06.36 STC01108 IEF695I START RESOLVER WITH JOBNAME RESOLVER
IS ASSI
11.06.36 STC01108 $HASP373 RESOLVER STARTED
11.06.36 STC01108 IEF403I RESOLVER - STARTED - TIME=11.06.36
11.06.36 STC01108 IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED
11.06.36 STC01108 IEE252I MEMBER CTIRES00 FOUND IN SYS1.PARMLIB
11.06.36 STC01108 EZZ9298I DEFAULTTCPIPDATA - None
11.06.36 STC01108 EZZ9298I GLOBALTCPIPDATA - None
11.06.36 STC01108 EZZ9298I DEFAULTIPNODES - None
11.06.36 STC01108 EZZ9298I GLOBALIPNODES - None
11.06.36 STC01108 EZZ9304I NOCOMMONSEARCH
11.06.36 STC01108 EZZ9291I RESOLVER INITIALIZATION COMPLETE
1 //RESOLVER JOB MSGLEVEL=1
2 //STARTING EXEC RESOLVER
3 XXRESOLVER PROC PARMS='CTRACE(CTIRES00)'
XX*
XX* IBM COMMUNICATIONS SERVER FOR Z/OS
XX* SMP/E DISTRIBUTION NAME: EZBREPRC
XX*
XX* 5694-A01 (C) COPYRIGHT IBM CORP. 2001, 2005.
XX* LICENSED MATERIALS - PROPERTY OF IBM
XX*
XX* FUNCTION: START RESOLVER
XX*
4 XXEZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
XX*
XX* WHEN THE RESOLVER IS STARTED BY UNIX SYSTEM SERVICES IT
XX* STARTED WITH SUB=MSTR.
XX* THIS MEANS THAT JES SERVICES ARE NOT AVAILABLE TO THE RE
XX* ADDRESS SPACE. THEREFORE, NO DD CARDS WITH SYSOUT CAN
XX* SEE THE MVS JCL REFERENCE MANUAL FOR SUB=MSTR CONSIDER
XX* SECTION "RUNNING A STARTED TASK UNDER THE MASTER SUBSY
XX* THIS RESOLVER START PROCEDURE WILL NEED TO RESIDE IN A D
XX* SET THAT IS SPECIFIED BY THE MSTJCLXX PARMLIB MEMBER'S
XX* IEFPDSI DD CARD SPECIFICATION. IF NOT, THE PROCEDURE W
XX* NOT BE FOUND AND THE RESOLVER WILL NOT START.
XX* SEE THE MVS INITIALIZATION AND TUNING REFERENCE MANUAL
XX* MSTJCL CONSIDERATIONS IN SECTION "UNDERSTANDING THE MA
XX* SCHEDULER JOB CONTROL LANGUAGE"
XX*
XX* SETUP CONTAINS RESOLVER SETUP PARAMETERS.
XX* SEE THE SECTION ON "UNDERSTANDING RESOLVERS" IN THE
XX* IP CONFIGURATION GUIDE FOR MORE INFORMATION. A SAMPLE
XX* RESOLVER SETUP PARAMETERS IS INCLUDED IN MEMBER RESSET
XX*ESOLVER EXEC PGM=
XX* IBM COMMUNICATIONS SERVER FOR Z/OS
XX* SMP/E DISTRIBUTION NAME: EZBREPRC
XX*CPPROF
XX* 5694-A01 (C) COPYRIGHT IBM CORP. 2001, 2005.
XX* LICENSED MATERIALS - PROPERTY OF IBM
XX*
XX* FUNCTION: START RESOLVER
XX*
IEFC653I SUBSTITUTION JCL - PGM=EZBREINI,REGION=0M,TIME=1440,P
5 XXEZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
XX*
XX* WHEN THE RESOLVER IS STARTED BY UNIX SYSTEM SERVICES IT
XX* STARTED WITH SUB=MSTR.
XX* THIS MEANS THAT JES SERVICES ARE NOT AVAILABLE TO THE RE
XX* ADDRESS SPACE. THEREFORE, NO DD CARDS WITH SYSOUT CAN
XX* SEE THE MVS JCL REFERENCE MANUAL FOR SUB=MSTR CONSIDER
XX* SECTION "RUNNING A STARTED TASK UNDER THE MASTER SUBSY
XX* THIS RESOLVER START PROCEDURE WILL NEED TO RESIDE IN A D
XX* SET THAT IS SPECIFIED BY THE MSTJCLXX PARMLIB MEMBER'S
XX* IEFPDSI DD CARD SPECIFICATION. IF NOT, THE PROCEDURE W
XX* NOT BE FOUND AND THE RESOLVER WILL NOT START.
XX* SEE THE MVS INITIALIZATION AND TUNING REFERENCE MANUAL
XX* MSTJCL CONSIDERATIONS IN SECTION "UNDERSTANDING THE MA
XX* SCHEDULER JOB CONTROL LANGUAGE"
XX*
XX* SETUP CONTAINS RESOLVER SETUP PARAMETERS.
XX* SEE THE SECTION ON "UNDERSTANDING RESOLVERS" IN THE
XX* IP CONFIGURATION GUIDE FOR MORE INFORMATION. A SAMPLE
XX* RESOLVER SETUP PARAMETERS IS INCLUDED IN MEMBER RESSET
XX* OF THE SEZAINST DATA SET.
XX*
IEFC653I SUBSTITUTION JCL - PGM=EZBREINI,REGION=0M,TIME=1440,P
6 XXSETUP DD DSN=PANDAG.USER.TCPPARMS(SETUPRES),DISP=SHR,FRE
XX*SETUP DD DSN=TCPIP.SETUP.RESOLVER,DISP=SHR,FREE=CLOSE
XX*SETUP DD PATH='/ETC/SETUP.RESOLVER',PATHOPTS=(ORDONLY)
PANDAG.USER.TCPPARMS(SETUPRES) contain :
DEFAULTTCPIPDATA('PANDAG.USER.TCPPARMS(TCPDATA)')
GLOBALTCPIPDATA('PANDAG.USER.TCPPARMS(TCPDATA)')
as you can see the resolver don't used the PANDAG.USER.TCPPARMS
(SETUPRES)
in order to set his paramters.
2010/2/15 Chris Mason <chrisma...@belgacom.net>
Matan
When this statement is not coded, then RESOLVER is started using
certain
default values you cannot override.
What Brian Peterson is sort-of saving is that, when the system starts
the "resolver" function address space with the command
START IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR,REUSASID=YES
which is used when the BPXPRMxx RESOLVER_PROC statement specifies
RESOLVER_PROC(DEFAULT), the default, default values are used for all
the "resolver" function statements referenced by the non-existent SETUP
DD-
statement.
Thus, as you observed, it is as if the file referenced by the SETUP DD-
statement specifies nothing for the DEFAULTTCPIPDATA,
GLOBALTCPIPDATA,
DEFAULTIPNODES and GLOBALIPNODES statements and
NOCOMMONSEARCH.
This corresponds to the EZZ9298I messages and EZZ9304I message you
posted.
I hope that's clear.
Chris Mason
On Mon, 15 Feb 2010 11:43:53 -0600, Brian Peterson
<brian.peterson.ibm.m...@comcast.net> wrote:
Did you notice the requirement that the JCL for the RESOLVER proc
must be
fetched from MSTJCLxx's PROCLIB concatentation (probably
SYS1.PROCLIB)?
Did you code RESOLVER_PROC(name) in BPXPRMxx? When this
statement is
not
coded, then RESOLVER is started using certain default values you
cannot
override.
Brian
On Mon, 15 Feb 2010 18:41:36 +0200, מתן כהן
<matancohen...@gmail.com>
wrote:
hi,
i have a strange problem .
while customize my tcpip so it will work correctly.
i'm running the resolver procedure with the :
//SETUP DD DSN=PANDAG.USER.TCPPARMS
(SETUPRES),DISP=SHR,FREE=CLOSE
when the resolver is initiliaze i can see the following messages in
the
procedure log:
EZZ9298I DEFAULTTCPIPDATA - None
EZZ9298I GLOBALTCPIPDATA - None
EZZ9298I DEFAULTIPNODES - None
EZZ9298I GLOBALIPNODES - None
EZZ9304I NOCOMMONSEARCH
EZZ9291I RESOLVER INITIALIZATION COMPLETE
after a future investigation i noticed that no matter what the
content
of
PANDAG.USER.TCPPARMS(SETUPRES)
the resolver procedure don't read it although there is no particular
message
in SYSLOG or the procedure log.
any advice?
--
best regards,
matan cohen
----------------------------------------------------------------------
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
