|
Big Al, As usual, you've said a mouthful. 1) SF99105 does not apply to the release you are running. Try this web site: http://as400service.rochester.ibm.com/supporthome.nsf/Document/10000031 Order and apply all group PTF's which you believe apply. Reorder them every time you apply a cum, if not more often. The individual PTF's with a group PTF change. Sometimes weekly. For example the Database group ptf for V4R3 is SF99103. I forget at which release that IBM started adding the marker data areas, but you could try DSPDTAARA SF99103. But I believe that you've already looked for this so maybe it was after V4R3 that they've added this marker function. 2) No release is ever 'stable'. The group ptf's are often updated. However there may come a time when that release is no longer supported and both cum's and group ptf's may dry up. The above mentioned web site will list the last time the group ptf was updated. For example for V4R3 Database hasn't been updated since 11/99 while performance tools has been updated 5/11/2001 - go figure. (Probably so you can forecast if the sexy new hardware will fix your ills.) 3) Da** straight you're overdue. Get it done. ;-) 4) There are multiple ways of thwarting users from running queries interactive. The strictest way is to CHGCMD RUNQRY <F4> and remove *INTERACT. Try it, quite effective. Another way we use we be very applicable for you. Remove the part of the record selection in which the users modify to fit their needs. Instead use a prompt screen to get these parameters. Submit the job to batch. In the batch program create a PF in QTEMP. Store these parameters in this file. Join this file instead of using record selection. If they try to run the query interactively the file will not exist and it will spew all over them. 5) We have both the CMF and ITH. I would be happy to look over these queries for you. Have you tried running these queries in debug mode, (STRDBG)? The little messages can be a real performance hint. 6) I too find BPCS use of the INLIBL versus retrieving the library list from a job description a duplication of effort and error. Before I go too far, are we competitors? Rob Berendt ================== Remember the Cole! MacWheel99@aol.com Sent by: To: MIDRANGE-L@midrange.com owner-midrange-l@mi cc: drange.com Subject: Re: query problems / reading files 05/15/01 10:12 AM Please respond to MIDRANGE-L 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 +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
