RE: query problems / reading files -- MIDRANGE-L

Al,

The group ptf's create a data area.  The data area is the same name as the
group ptf.  The data in the data area tells you what group ptf level you are
at.  The data areas are not all in the same library.  They may be in QSYS,
QJAVA, etc, depending upon what group the group ptf is for.

Many products have group ptf's - DB2, Java, HTTP, Apache, WebSphere,
Save/Restore to name a few.  HIPERS use a group ptf also.  Some products are
upgraded through group ptf's.  The Apache HTTP server comes as a group ptf.

Being current on Cume's does not mean you have all the ptf's for certain
products which is why being current on the group ptf's is also important.
Some ptf's in the group ptf's make it to a cume ptf but not all.

Phil

-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of MacWheel99@aol.com
Sent: Tuesday, May 15, 2001 11:13 AM
To: MIDRANGE-L@midrange.com
Subject: Re: query problems / reading files

from MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

I find this list to be a great source of education & I try to try out things
I see here that I had not previously been aware of.

Rob mentioned DSPDTAARA DTAARA(SF99105)
and I recognized SF99* as the number system of IBM PTFs
& I tried it on our system, curious about what Rob meant by the word
"disparity"
I suspected he meant disparity across the different systems of Maarten

I could not find any DTAARA(SF99105)
I could not find any DTAARA(SF99*)
I tried WRKDTAARA *ALL in *LIBL then *ALL in *ALL libraries then had master
security officer try it ... none nada with any such naming
I tried WRKOBJ SF99* & no hits even with *ALL libraries via master security
officer

Along the way I was reminded that when using *ALL, I really really need
sometimes an *ALL_EXCLUDING_BPCS

BPCS users will appreciate what I mean by that

So my question is if the PTF objects only exist at a particular point in the
upgrade cycle & ought to be cleaned out after each release is stable.

We are running lots of queries on our system - a model 170
Most of them are Query/400 against BPCS
I am overdue to upgrade V4R3 to V4R5

The only problems we now have are with a query that joins ITH & CMF
That is to say problems with run time - we also have problems with people
who
create queries, myself included, who sometimes forget the design limitations
of query/400.

ITH is the inventory history file with transactions for a year & we have
several thousand of them a DAY
CMF is the cost master file & although the record size is small, it is our
largest file with well over a million records.
As I understand query/400, it grabs all records in all files involved, then
it selects what is needed, as opposed to RPG & SQL which grab only the
records & fields needed.

Thus there is a practical ceiling on possible combinations of joined input,
that doubtless is related to our available disk work space & hardware.

We have been trying to remind the users of THIS query that you need to
change
the selection criteria in WRKQRY then send the sucker to JOBQ then wait
until
it is finished running before changing selection criteria to send another
version to JOBQ, because that way each iteration will complete in minutes &
not lock up the system.

Meanwhile we have been trying to remind query users in general that you need
to change selection criteria in RUNQRY & do interactive because we do not
want to be altering default selection criteria that affect other people,
except for queries like the ITH CMF one where they HAVE to go via JOBQ due
to
sheer size of records joined.

Sometimes the user of the query heeds the 2nd message instead of the first.

I wonder if the volume of records going into Maarten queries is comparable
on
each system, relative to disk work space.

I wonder if queries have *JOBD settings worth reviewing.
I mean where does it control sizes of blocks to use.
I know there are some disparities between BPCS & Query *JOBD that sometimes
bite us.
I wonder if Maarten uses software that messes with said *JOBD

From:   rob@dekko.com

I assume that the 820 and the other machines are all running V4R5, the same
CUM, and, if you run:
DSPDTAARA DTAARA(SF99105)
there is no disparity, correct?

What application are you querying against?  Basically, if it is BPCS or one
of our other applications I could try it for you.

Rob Berendt

==================
Remember the Cole!




                    "Maarten Vries, de"   <m_devries74@hotmai

We are running lots and lots of queries on our systems.
Recently we have upgrade to V4R5M0 and now we experience very very long
runtimes of the queries.

You can see that when the query runs, it is reading 300 records at the time
on a model 730 with 2GB main storage.
When I run the query on another system it is reading by blocks of 15000.
The other system is a base model 620.

This problem is happening on lots of systems, but I tested the query on a
model 820 and did not have any problems.

Another branch of us also runs on a model 620 and there the problem is
occuring. PTF level is the same and IBM cannot find the solution.
Does this ring a bell to anyone?

Maarten

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


+---
| 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
+---


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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
+---