RE: QM/400 Conversion -- MIDRANGE-L

I would go with the OPNQRYF.  It is a very powerful tool on all AS400s.  You
should learn it.  Now sounds like the right time.

Have Fun,

Christopher K. Bipes     mailto:ChrisB@Cross-Check.com
Sr. Programmer/Analyst   mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.         http://www.cross-check.com
6119 State Farm Drive    Phone: 707 586-0551 x 1102
Rohnert Park CA  94928 Fax: 707 586-1884

If consistency is the hobgoblin of little minds, only geniuses work here.
Karen Herbelin - Readers Digest 3/2000


-----Original Message-----
From: Dennis Munro [mailto:DMunro@badgerminingcorp.com]
Sent: Tuesday, June 13, 2000 8:55 AM
To: 'MIDRANGE-L@midrange.com.'
Subject: QM/400 Conversion


I have gone throught the 28 (as of today) Query/400 queries that are run as
part of the end of month process & converted them to QM/400 objects.  It
wasn't as bad a job as I was fearing based on comments on this list but it
wasn't a piece of cake either.

The major dilema now is what to do with those queries (6) that create a
file?  For the present, I just run the Query/400 versions & use QM/400 for
the reporting function.  

What I would like to know is what options I have because these 6 queries
have variables that change (from/thru dates, accounting period, etc.) with
each running?  

OPNQRYF is one option but I'm not very fluent with that tool.  I would also
guess a person could use an RPG program to "extract" the data needed but
then the data needs to be sorted.  There is someplace an example of creating
DDS from the "variables" required which then is compiled to create a logical
file.

The easiest solution is to leave the queries as they are and manually change
the variables before running the month-end reports!  BUT you take the chance
of an error because you are doing it manually so is it really the "better"
alternative?

I have a question related to QM/400 & editing dates not defined as a date
data type.  BPCS version 6.0.02 dates are a real mess (I'm being kind when I
say that) and the only thing I have found is to not edit them so the field
is displayed as 20000531.  Not very elegant or user friendly.  Is there a
better solution for this problem?  I have changed some of the major files to
redefine the date fields as date data types but that also has it's risks.

I have a question related to QM/400 & what people do to "emulate" Query/400
Option 2 of matching records - i.e., always take the primary file record
even though there is no match on the secondary file.  I only have 1 of these
to deal with but how do I deal with QM/400 not having that capability?

Looking for some thoughts from the list.  Thanks  for your input.

Dennis Munro
Badger Mining Corporation
dmunro@badgerminingcorp.com
(920) 361-2388 
+---
| 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
+---