Money is not an issue but I agree with you. My gut feeling is it is the
program. Since I don't have the time right now to really dig, it's
'easiest' to add the memory.

What I have suggested is that we should really look at switching our
programs from CM to NM. There is a tremendous amount of overhead due to
this. Another area I think we should be looking at is the databases.
Maybe a good 'tweaking' or a reorganization is what they need. The
biggest problem is time....

Rick


"L. A. Barnes" wrote:
>
> HP (and other hardware vendors) love it when you add more hardware to solve a
> problem.  At my last job that was the buzz word, until a great DBA (TR) did some
> investigating into the programs that were running.  T.R. was able to put a plan
> together that revamped some of these programs and the systems performance improved
> drastically.
>
> Memory can be a viable solution, but when you mentioned this huge COBOL program
> that was modified maybe the problem is still in the program.  It's always worth
> investigating, unless money is not an issue.
>
> Rick Clark wrote:
>
> > David,
> >
> > I understand that this is not much info, and I guess I am feeling more
> > like L.A.Barnes' little guy banging my head against the computer
> > today...... It has been one of those dazes!
> >
> > After further research, it turns out that a few more lines of code were
> > added to a huge COBOL program that when installed, the system takes a
> > nose dive. When removed, the system operates normal. We are thinking
> > that this additional code, when multiplied by 500+ users stored in
> > memory, caused the HP3000 performace bottlenecks. It is my understanding
> > that the 3000 systems, once it reaches a certain 'boiling' point, will
> > drop in performance. Not a gradual curve, but a drop.
> >
> > Bottom line is, we are buying more memory. This I hope will resolve our
> > problem.
> > I'm not convinced this is the problem, but it doesn't hurt. What I am
> > questioing now is that the Configuration guide (1995) shows the 959ks
> > has a max of 2048 memory. We were told that it is capable of 8gb and
> > that MPE/iX has a limit of 3.75gb. Is this true? What is the true max
> > amount of memory I can install in the system?
> >
> > Thanks again in advance.
> >
> > Rick Clark
> > Senior Systems Analyst
> > WW&R
> > Cleveland, Ohio
> >
> > David Gale wrote:
> > >
> > > Rick,
> > >
> > > unfortunately system performance has many more variables and I am afraid the
> > > information you have provided doesn't provide an imediate answer. JSMAIN
> > > does not appear to be a resource hog at his point.
> > >
> > > I will say that in the past when a sudden change of performance was noticed,
> > > and there didn't seem to be a change in anything else, the first thing I
> > > looked at was disc space. Make sure you are not using more than 85% on your
> > > volume sets.
> > >
> > > To really get a good look at performance issues, you need a good tool. <plug
> > > alert> I favor the Lund Performance Tools myself <end-plug>. You really need
> > > something that not only tells you the current pulse points of your system
> > > but allows you to capture trending information.
> > >
> > > There could be any number of problems therefore I cannot with honesty give a
> > > better opinion of your problem.
> > >
> > > Good Luck!
> > >
> > > Dave Gale
> > >
> > > > -----Original Message-----
> > > > From: Rick Clark [mailto:[log in to unmask]]
> > > > Sent: Thursday, October 28, 1999 10:26 AM
> > > > To: [log in to unmask]
> > > > Subject: JSMAIN.PUB.SYS
> > > >
> > > >
> > > > What is this program? We are running extremely slow the past few days
> > > > and nothing has changed that could have caused this (at least that is
> > > > what they are claiming). I am looking at the SHOWQ;ACTIVE and noticing
> > > > in the B queue one PIN consistently. This turns out to be
> > > > JSMAIN.PUB.SYS
> > > >
> > > >
> > > > Q  PIN   JOBNUM                           Q  PIN   JOBNUM
> > > >
> > > >                                           B   856
> > > >                                           C  M2652 #S1449
> > > >                                           C  U1263 #S1642
> > > >                                           C  U1108 #S1531
> > > >                                           C  U1452 #S1599
> > > >                                           C  U2146 #S1442
> > > >                                           C  U2709 #S837
> > > >                                           C  U2747 #S1626
> > > >                                           C  U2883 #S1459
> > > >                                           D  U186  #J1221
> > > >                                           D  U2547 #J1116
> > > >
> > > >
> > > >                     ------QUANTUM-------
> > > > QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST  TIMESLICE
> > > > -----  ----  -----  ---    ---    ------  -----  ---------
> > > >  CQ    152    200   1      2000   68      DECAY    200
> > > >  DQ    202    238   2000   2000   2000    DECAY    200
> > > >  EQ    240    253   2000   2000   2000    DECAY    200
> > > >
> > > > PUB SYS:DO SHOWP
> > > > PUB SYS:SHOWPROC ;PIN=856;SYSTEM
> > > > QPRI  CPUTIME   STATE  JOBNUM  PIN  (PROGRAM) STEP
> > > >
> > > > B100* 0:00.010  WAIT           856  (JSMAIN.PUB.SYS)
> > > > PUB SYS:
> > > >
> > > > Thanks in advance....
> > > >
> > > >
> > > > Rick Clark
> > > > Senior Systems Analyst
> > > > WW&R
> > > > Cleveland, Ohio
> > > >