• Subject: attaching EMC drives to 170
  • From: Terry Richardson <RichardsonT@xxxxxxxxx>
  • Date: Fri, 24 Sep 1999 15:27:36 -0400

Does anyone know if we can attach EMC 9337-486 DASD (30gb) to a model
170-2290?  We're replacing this unit on our production 530 with some larger
ones and want to make use of it if possible.

TIA

Terry Richardson
Sr. P/A
The Orvis Company, Inc.
802-362-8663


        -----Original Message-----
        From:   Emilio Padilla T. [SMTP:vpadilla@guate.net]
        Sent:   Friday, September 24, 1999 12:53 PM
        To:     MIDRANGE-L@midrange.com
        Subject:        Re: errors

        Hi,
        Did you try the Hoghunter option? I've use it a couple of times and
it
        work's fine.  In both times, i had only one job eating my cpu.
        In case you don't know, you can use the option 76 in control panel.
This
        function is available since v3r2.  I'm not in the office so I'm not
sure if
        it is available in power machines.

        A new control panel function (76) is supported at V3R2, and PTFs
MF11581,
        MF11960, MF11982, SF29221 at V3R1, which will invoke an internal
VLIC
        mechanism to inspect for a high-priority CPU blocking job; if one is
found,
        its priority may be lowered immediately by +20 (i.e., a priority 15
job will
        become a priority 35 job). This  function thus provides a new
alternative
        for the support person to correct system 100% busy symptoms (i.e.,
Processor
        Active light on solid) and no terminals are responding to operator
requests.
        There may be cases when the priority can not be changed, an example
would be
        if the job found was QSYSARB or QLUS.
        Hoghunter will not change the priority of any system jobs or VLIC
tasks.
        This function may not be totally successful, as the real cause of
the
        symptoms may be much more complex. After selecting control panel
function
        76, one of the following status SRC sequences will be displayed on
the
        control panel:

        D600 0652 -> A900 2052 - a job's priority was changed >
        D600 0653 -> A900 2053 - system job was indicated, priority not
changed
        D600 0654 -> A900 2054 - no CPU blocking job was found >

        (To clear one of these SRCs, it will be necessary to SIGNON the
console). A
        message will be sent to QHST, and QSYSMSG or QSYSOPR describing the
        action(s) which were taken; and an internal VLIC LOG entry (1700
0301 or
        1700 0302 or 1700 0303) will also be recorded to assist with any
possible
        subsequent problem resolution; this may include another selection of
control
        panel function 76.

        Emilio Padilla

        ----- Original Message -----
        From: Debbie Helms <DHelms@Lance.com>
        To: <MIDRANGE-L@midrange.com>
        Sent: Jueves 23 de Septiembre de 1999 10:56 AM
        Subject: RE: errors


        David - I tried everything to get rid of the jobs.  I could not
change,
        hold, or end the jobs.  Where would I look to determine what the
problem
        was?  I have sent a main storage dump to IBM - I don't really expect
to hear
        from IBM in reference to this dump.  We did run srvtrc on the jobs
that were
        running.  I have pages and pages of trace information.  I have
wrapped
        joblogs, history, lic logs.  I really don't know what I'm looking
for.  I am
        afraid that we will experience this problem again if we don't find
the cause
        of this problem.
        I agree that it sounds like os400 when you can not flush a job - but
try to
        argue with IBM.



        -----Original Message-----
        From: Kahn, David [JNJFR] [SMTP:DKahn1@JNJFR.JNJ.com]
        Sent: Thursday, September 23, 1999 8:48 AM
        To: 'MIDRANGE-L@midrange.com'
        Subject: RE: errors

        Debbie,

        I don't know BPCS but it looks suspiciously like a classic bug in an
        error
        handling routine causing the program to jump into the error routine
        where it
        again errors, jumps back into the routine and so on ad infinitum.

        Occasionally you get this kind of thing being triggered off by an
        interactive job losing contact with a 5250 emulation session. As
        this
        happened to 5 jobs simultaneously you may have had some kind of
        communications glitch(?).

        When you can't cancel run-away jobs you can sometimes contain them
        by
        changing their priority to 99. 10 minutes after they were "ended"
        with the
        *IMMED option, you can should be able to clobber them with the
        ENDJOBABN
        command. This usually, but not always, gets rid of them. If that
        doesn't
        work then you're generally stuck with them until the next IPL. Did
        you try
        these steps?

        It's one thing for IBM to say it's a BPCS problem, but no matter
        what the
        bug if you can't flush a problem job out of your system that has to
        be an
        OS/400 problem, surely?

        Dave Kahn
        Johnson & Johnson International (Ethicon) France
        Phone : +33 1 55 00 3180
        Email :  dkahn1@jnjfr.jnj.com (work)
           dkahn@cix.co.uk      (home)


        -----Message d'origine-----
        De: Debbie Helms [mailto:DHelms@Lance.com]
        Date: 22 September 1999 22:53
        : 'MIDRANGE-L@midrange.com'
        Objet: errors


        I had an interesting problem (opportunity) today.  Our 640 locked up
        around
        10:30 this morning.  We had about 5 jobs in QINTER that brought the
        system
        to its knees.  We could not cancel the jobs in any form.  IBM could
        not help
        us cancel the jobs.  Finally we decided the only option was to IPL.
        The
        joblogs wrapped so we do not know what exactly happened.  Listed
        below is a
        portion of the joblog that repeated itself.  In 40 seconds it had
        repeated
        this 8,400 pages.  IBM thinks the problem is in BPCS.  I don't know
        what to
        think.  If anyone has ever heard or seen this please let me know.
        +---
        | 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 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 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 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-Ups:

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 here. If you have questions about this, please contact [javascript protected email address].