• Subject: Re: AS/400 NetServer
  • From: "Neil Palmer" <neilp@xxxxxxxxxxx>
  • Date: Thu, 25 Jan 2001 13:23:23 -0500


Just remove the DLYJOB in the startup program that was a circumvention for 
a TCP/IP timimg problem at startup in V4R3. 
That DLYJOB is not needed in V4R4 or later.  Leave the autostart job entry 
in QSYSWRK subsystem to start TCP/IP.


Diana Hicks <DianaH@jupiter.fl.us>
Sent by: owner-midrange-l@midrange.com
2001/01/25 10:27
Please respond to MIDRANGE-L

        To:     "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com>
        Subject:        Re: AS/400 NetServer


I'm having a similar problem with NetServer (CPIB683 reason code 6 and
return code 3409 during IPL).  I did recently upgrade from V4R3 to V4R5 
added STRSBS QUSRWRK to QSTRUP.  When I was on V4R3, I added the DLYJOB 
autostart job entry in QSYSWRK for the timing issue.  According to your
email below, you mentioned it should be removed.  My question is do both 
DLYJOB in QSTRUP and the autostart job entry in QSYSWRK need to be removed
for V4R5?  I'll also check into the APAR you mentioned.  Thanks.


Date: Mon, 22 Jan 2001 01:45:17 -0500
From: "Neil Palmer" <neilp@dpslink.com>
Subject: Re: AS/400 NetServer

In the past I had this exact problem, but can't recall exactly what I did 
to fix it.
It may have been one of these:

When you upgraded to V4R5 (maybe you came from V4R3 - this applies to 
anyone upgrading to V4R4 or higher) did you modify your startup program to 

include the  STRSBS QUSRWRK  (after STRSBS QSERVER) ?  IBM added this in 
V4R4.  (RTVCLSRC QSYS/QSTRUP after each release upgrade to check for any 
changed IBM may have made).

Did you have TCP/IP starting via an autostart job entry in QSYSWRK 
subsystem, and a DLYJOB in the startup program after the first subsystem 
was started (prior to STRSBS QSERVER) to give TCP/IP time to start ?  This 

was necessary early in V4R3 due to a timing problem with TCP/IP startup. 
If you have it there in V4R4 or V4R5, remove it.

Now if that return code was 3409 on the CPIB683 you may as well try the 
circumvention listed below, although you would think the fact V4R5 isn't 
listed implies it's fixed in V4R5 base code:
Item MA22413 

  APAR Identifier ...... MA22413  Last Changed..00/12/20 
  Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
  Severity ................... 2      Date Closed ......... 00/08/16
  Component .......... 9400DG300      Duplicate of ........
  Reported Release ......... 440      Fixed Release ............ 999
  Component Name 5763 5769 5716       Special Notice           HIPER
  Current Target Date ..00/09/22      Flags  RESTART/BOOT/IPL
  SCP ...................
  Platform ............
  Status Detail: SHIPMENT - Packaged solution is available for
  PE PTF List:
  PTF List:
  Release 230   : PTF not available yet
  Release 305   : PTF not available yet
  Release 310   : PTF not available yet
  Release 320   : PTF not available yet
  Release 360   : PTF not available yet
  Release 370   : PTF not available yet
  Release 410   : PTF not available yet
  Release 420   : PTF not available yet
  Release 430   : MF25440 available 00/11/22 (1000 )
  Release 440   : MF25091 available 00/12/20 (0350 )
  Parent APAR:    SA90279
  Child APAR list:
  QZLSSERVER comes active a minute or so and then ends. Joblog
  says it is ending normally.  Qsysopr gets msg CPIB683 RC6
  RC3409. VLOGS on the system include vl/44012001, vl/4400800F,
  vl/44000002, VL/1F000001. NETSTAT *CNN shows no NETBIOS jobs.  A
  display of ports only showed 139 (not 137, 138) in close-wait
  status so I ended it. Dev logged on to cust system and found
  that the heap used by the NetServer's comm stack was corrupted.
  Run the following commands to create a new heap:
  * PROBLEM: (MA22413) Licensed Program = 5769999              *
  *          Crash/Hang Requiring an IPL to Recover            *
  *          SRC B600 0103                                     *
  * USERS AFFECTED: All OS/400 users.                          *
  * RECOMMENDATION: Apply LIC PTF MF25440 for R430.            *
  NetServer will not start.  QHST log receives msg CPIB683 with
  RC6 and RC3409 (ETIME).  Other symptoms include a system crash
  with SRCB6000103.  Both cases are variants of the same storage
  corruption problem.  In the first case, the control segment of
  NetServer's private heap was corrunpted.  In the second case
  the virtual function table for a QmNSReq message object was
  overlaid with a QuGate.
  The management of internal NetServer message queues was changed
  to prevent mutiple deletes of the same object.  Affected modules
  are vsocket and zlsNBTab.
                         * HIPER *
  SRLS:      NONE



| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].