RE: V4R4M0 & NEWI problems -- BPCS-L

What I've done is to stop the BPCS subsystem & other subsystems, stop the
host servers *ALL, & then ENDTCP - in that order.  Things behave when done
in the correct order.  It worked before going to V4R4M0 & it tells me that
IBM is changing the underlying code in TCP/IP between releases & in my case
it bite me.

This took care of the "ALL" the daemons in BPCS going out to lunch & pegging
the machine when I stopped TCP BEFORE doing anything else.  It works like it
should.

I also was able to fix a long standing problem with not getting the STRNWID
command to work on an IPL on a V4R2M0 machine.  It was an authority problem
& all I did was to give QPGMR *USE authority to the QSYGETPH and QWTSETP
objects.  This I got from ssanders on the SSA help line.  Thanks to ssanders
- don't know a first name but I sure do thank them for pointing me in the
right direction.

Got two problems fixed Saturday so it wasn't totally wasted spending the day
at work.  Of course we did month-end & year-end after setting the date back
to March 31 on Saturday.

Dennis

"One never notices what has been done; one can only see what remains to be
done." -- Marie Curie 
"I love deadlines.  I especially like the whooshing sound they make as they
go flying by."  Dilbert's Words Of Wisdom:

Dennis Munro    
Badger Mining Corporation
dmunro@badgerminingcorp.com <mailto:dmunro@badgerminingcorp.com> 
(920) 361-2388


        -----Original Message-----
        From:   Micki Rogers/MiWheel [SMTP:Mrogers@miwheel.com]
        Sent:   Monday, April 03, 2000 8:39 AM
        To:     BPCS-L@midrange.com
        Subject:        Re: V4R4M0 & NEWI problems


        Also, try ENDHOSTSVR *ALL (and let this completely finish) before
your
        ENDTCP


        

                            "Genyphyr

                            Novak"                 To:
<BPCS-L@midrange.com>                                          
                            <novakg@ssax.co        cc:

                            m>                     Subject:     Re: V4R4M0 &
NEWI problems                                
                            Sent by:

                            owner-bpcs-l@mi

                            drange.com

        

        

                            03/30/2000

                            10:27 PM

                            Please respond

                            to BPCS-L

        

        




        Hi Dennis,

        I would not suggest bringing down TCP/IP without bringing down the
Newi
        daemons first - they are likely looping because you have ended TCP
out from
        underneath them while they are running and listening on ports.

        Try either ending the subsystem they run in or end them manually
with
        option
        4, then bring down TCP.


        Thanks

        Genyphyr Novak
        SSA

        -----Original Message-----
        From: Dennis Munro <DMunro@badgerminingcorp.com>
        To: 'BPCS Users' <BPCS-L@midrange.com>
        Date: Thursday, March 30, 2000 11:38 AM
        Subject: V4R4M0 & NEWI problems


        To all and I apologize for the length of this email but it takes
space to
        explain what is wrong & what's been done:

        We are running ver.6.0.02plf, c/s, Mar'98 cum on an AS/400 model S20
with
        dual processors, V4R4M0, & all the latest cum, database, hiper, y2k,
        performance tools, & client access ptf's.

        As part of our "day end" process, I bring down IP as a means of
keeping
        people from being logged on while I do a backup of the system &
BPCSF data
        library.

        Since going from V4R2M0 to V4R4M0 this last weekend, I have been
having
        trouble with my production machine.  I was baby sitting it last
night & was
        able to determine that when I shut down TCP/IP, the NEWI daemons
"peg" both
        processors & the IP shut down takes about 1 hour and 45 minutes to
end.
        Looking at the job log, all I see is a blank time gap from 23:16:57
to
        00:57:23 when nothing is logged.  When I start my "day end", I
change the
        job attributes to LOG(4 00 *SECLVL) LOGCLPGM(*YES).  What I did last
night
        after seeing the processors peg was to WRKACTJOB SBS(SUBSYSN) and
kill the
        two NEWI jobs that had the system running at over 100% utilized.  As
soon
        as
        I did that, the rest of my day end process continued normally.  Is
there a
        "better way" to stop all the daemons running?

        These same programs (BPCS & "day end" ) run on my test box (a single
        processor 720) running the same software & ptf levels & it woks just
fine.
        Obviously, there is a difference someplace - but where.

        I wrote all these programs about 2 �  years ago when we first
started with
        BPCS & IP.  Being a novice to both at the time, the way I chose to
do it
        was
        stop IP.  But I also stop the BPCS subsystem.  We do have a major VB
        application that gets at the BPCS data & the only way I have to lock
them
        out is to bring down IP.

        Searching through OGS, the only reference I found to NEWI/OMS was
BMR 45731
        which doesn't really apply to my current problem but is something I
also
        have a problem with.  It was reported on 6.0.02 & fixed for 6.0.04 &
6.1 -
        no mention of a fix for 6.0.02.  I filed a HelpLine incident & now I
wait
        for them to respond.

        I'm tired of waiting & am looking for some input from others in the
BPCS
        community as to their possible solutions/questions/comments, etc.

        I also logged an incident with IBM & after working with them for a
couple
        of
        hours yesterday, I was told to call my ERP vendor.  According to all
the
        logs we looked at, IP was doing what it was supposed to be without
any
        errors.

        Thanks - Dennis

        "One never notices what has been done; one can only see what remains
to be
        done." -- Marie Curie
        "I love deadlines.  I especially like the whooshing sound they make
as they
        go flying by."  Dilbert's Words Of Wisdom:

        Dennis Munro
        Badger Mining Corporation
        dmunro@badgerminingcorp.com <mailto:dmunro@badgerminingcorp.com>
        (920) 361-2388

        +---
        | This is the BPCS Users Mailing List!
        | To submit a new message, send your mail to BPCS-L@midrange.com.
        | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
BPCS-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner: dasmussen@aol.com
        +---


        +---
        | This is the BPCS Users Mailing List!
        | To submit a new message, send your mail to BPCS-L@midrange.com.
        | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
BPCS-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner: dasmussen@aol.com
        +---




        +---
        | This is the BPCS Users Mailing List!
        | To submit a new message, send your mail to BPCS-L@midrange.com.
        | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
BPCS-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner: dasmussen@aol.com
        +---
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---