× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: query problems / reading files
  • From: rob@xxxxxxxxx
  • Date: Tue, 15 May 2001 17:25:50 -0500


The drill down sure would be pretty in Domino.

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 01:44 PM                                           
                                         
                    Please respond to                                           
                                         
                    MIDRANGE-L                                                  
                                         
                                                                                
                                         
                                                                                
                                         




I am also active in BPCS_L

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

Thanks, but in this particular query what I need to do when my time permits

is to replace it with a HLL program since the users want more out of it
than
you can really do efficiently in Query, or I should say I comfortable with.

I recognize that many limits of Query/400 can be circumvented by query to
summary file then use that summary file as input to another query, and we
are
in fact doing a lot of that also.

Perhaps the most useful like that in recent days is cost summary by item,
for
selected item classes to work files by facility then compare & only output
what's different in the fields of relevance.  We have parts we manufacture
in
one facility for usage in others, like our extruded wire, plastic blocks,
and
simple leads.  In theory the total cost to make something in one factory is

itemized by where the costs came from & that total should be cost of
material
for same item in another factory, but we have some discrepancies.

This has led to a decision to modify CST920 or CST940 - I not yet decided
which, to permit cost transfers for ONE item class at a time, and a fix it
program for CIC getting the right codes from IIM since the rules are
different for facility that makes vs. facility that uses the same item #s.

The query, that I mentioned in my earlier post, is taking 100% ITH
inventory
transactions that are relevant to JIT shop order transactions for a user
specified date range, which HAS the standard cost at the time of the
transaction, but they want the standard cost NOW, so that is why it is
linked
to CMF, when I favor CIC summary cost, but there is also the difficulty of
matching records when not all files have facility or warehouse (typically
one
or the other), and it is sequenced by department of the labor (wire
cutting,
ends terminating, plastic molding, etc.) and they are getting totals only
scrap vs. production by facility by department, so the query logic is quite

convoluted.

Now they want PPM (Parts per million) & scrap percentage in the report, but

with Query/400 when you do a totals only, computed stuff is shown as an
average of the column - an average of the percentages, not a recomputed
figure based on what is in the totals, which is why I think this needs to
be
HLL.

Also, when they get this, they want to be able to select on the
facility-department with the highest baddest percentage for the time period

reviewed & drill down to what machines operators parts etc. responsible.

One of many things on my to do list.

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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.