Re: TCP/IP issues around startup

Well, since IBM had fielded over 250 pmr's on this lately I would not
continue this way. This is like saying:
"I've tapped a dozen DC street walkers and haven't caught a communicable
disease yet, I can't see why I should bother with protection."

Did you also notice the "may corrupt ldap" and other issues? Granted most
people don't run ldap on their i but we have our external ldap on an i in
our DMZ.

It's such a simple fix to add
ENDHOSTSVR *ALL
ENDTCP
DLYJOB DELAY(300)
in your job stream.
Then your ENDSYS and what not.

I've submitted a request to the Memo to Users to be amended.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 12/14/2009 08:43 AM
Subject: Re: TCP/IP issues around startup
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I'm at V6R1, a 1-LPAR i5 520. Here is what I have been doing when
applying
PTFs:

ENDSYS DELAY(300)

after which I do the PWRDWNSYS *IMMED RESTART(*YES) and I haven't been
having any issues.

DSPLOG from Saturday when I did this shows:

System ended to restricted condition.

TCP/IP is ending.

IPv6 interface ended successfully.

User QSYS in job 730219/QSYS/QTCPWRK ended TCP/IP *LOOPBACK interface
127.0.0.0
User QSYS ended IP interface 192.168.0.1 on ETHERNET1.

A request to end TCP/IP has completed.

TCP/IP is ending.

Job 730219/QSYS/QTCPWRK ended on 12/12/09 at 19:51:22; 1.129 seconds used;
en
PWRDWNSYS command issued with parameters specified.

PWRDWNSYS command in progress.


This is how it has been since install of V6R1. I thought it was supposed
to
be that way - that even though the system was in a restricted state, there
was still some TCP/IP. Don't ask me to explain it because I can't. But,
as
I said, I haven't had any problems.


On Mon, Dec 14, 2009 at 8:01 AM, <rob@xxxxxxxxx> wrote:

Back in mid October there was a thread "Survey: STRTCP(*YES) or
STRTCP(*NO) in IPL attributes". Perhaps this started due to a related
issue we at Group Dekko are having with IBM. Normally we are quite
stringent in running
ENDHOSTSVR *ALL
and
ENDTCP
prior to running
ENDSBS *ALL *CNTRLD DELAY(120)

I have found out that if you do an ENDSBS *ALL... prior to doing the
ENDTCP you will see TCP/IP jobs ending even AFTER you receive the

message

"system ended to restricted state". After IPL you may find that some
TCP/IP server jobs do not start. Try to run without TELNET! See this
reply from IBM regarding pmr 13039,500,000:

<snip>
We have been seeing various issues with TCP servers not starting back up
when subsystems are ended without ending tcp servers first.


ENDSBS *ALL *IMMED without ending TCP and TCP related servers has

numerous

associated issues.

in regards to Telnet. If the Telnet server is not ended prior to the
ending of subsystems it may not restart automatically. An endtcpsvr
*telnet is needed and then a strtcpsvr *telnet. The CS1 team has

received

approximately 250 PMRs in the last 15 months with the Telnet issue on

not

ending Telnet before SBS QSYSWRK is ended.

Netserver tasks also may not end orderly and may not restart properly in
not ended in controlled manner.

LDAP may create FFDC errors and lose data if not ended orderly.

Saves and Backups may fail due to hung TCP jobs without ending TCP and

TCP

servers prior to ENDSBS *ALL *IMMED




Our recommendation is prior to having a customer ENDSBS *ALL *IMMED

please

have customers run the following:

ENDTCPSVR *ALL
ENDHOSTSVR *ALL

allow the above two commands to complete (or if in a CL delay 5 minutes
DLYJOB 300 )
ENDTCP


Developers have put out a fix for V6R1 PTF SI35204 (superseded by
SI37176
) that when a customer does an option 21 save to save the entire

system

that PTF will add those three commands to the job stream to prevent

these

issues. However if customers do not use option 21 to save than they
will want to add these commands to their CL programs prior to ending

their

subsystems.
</snip>


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Jeff Crosby
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.