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




I have perhaps a dumb question.....why are you not purging IMHIST transactions
monthly and adding them to IMHGEN restored history?  This would speed up access
of inquiries, transaction processing,  etc.    At minimum quarterly.  I would
think your normal operations are bogged down where IMHIST is so big.  Have you
considered that?    Can't your users query IMHIST and IMHGEN?






"Burns, Bryan" <burnsbm@Echoincorporated.com> on 08/10/2001 02:59:55 PM

Please respond to mapics-l@midrange.com

To:   mapics-l@midrange.com
cc:    (bcc: Gail L Crane/Johanson/JMC)

Subject:  RE: Questions on purging IMHIST



Thanks guys, and to the others who have responded.  This has been immensely
helpful!  There seems to be a common element of not using the MAPICS purge
routines for IMHIST. Will do as suggested.  By the way, we have 94g of DASD,
69% used on a 620, so a purge, although not absolutely necessary should help
things.

And thank you Pete, for answering my questions point by point, you made it
so clear!

     Bryan Burns
     AS/400 System Operator
     ECHO  Incorporated
     847-540-8400  ext. 493
<Burnsbm@echoincorporated.com <mailto:Burnsbm@echoincorporated.com> >


-----Original Message-----
From:     Peter_Vidal@pall.com [SMTP:Peter_Vidal@pall.com]
Sent:     Friday, August 10, 2001 11:58 AM
To:  mapics-l@midrange.com
Subject:  Re: Questions on on purging IMHIST


These are very good recommendations.  I want to add the following:

I quote:

"1) The MAPICS documentation says to run a transaction history report
before a purge, but with 8 million records, how long would that take and how
much DASD would it use?  How necessary is this report?"

This report is not necessary to be generated/printed.

"2) I have been told the purge will have to be done on a three day
weekend as it will take 50 hours or more.  Any tips on speeding the purge
up?"

Do not purge:
a) Save the MAPICS files on tape
b) Identify tape(s) as the MAPICS' BACKUP BEFORE IMHIST PURGE (08/2001) or
something like that.
c) Create a physical file with JUST the record you want to keep in MAPICS
(IMHIST2).
d) Replace the IMHIST file with IMHIST2; something like: CPYF
FROMFILE(IMHIST2)
TOFILE(IMHIST) TOMBR(IMHIST) MBROPT(*REPLACE)

"3) If the purge is not finished when the work shift begins, I assume
that IM transactions will be locked out.  What other parts of MAPICS would
be locked?  This is not a dedicated mode task from what I can see."

With step #2, you will have no problems here.

"4) The IMHIST file has a member IMHNEW with 1.3 million records.  The
MAPICS web site has indicated  that IHNEW is built on the fly for
Transaction History reports.  A DSPFD indicates IMHNEW was last changed on
7/11/01.  We think that it got created but not cleared on that date when we
abended a transaction history report that had no limits.  Can we just do a
clear it with a CLRPFM?"

You can clear it.

Hope this helps!

Best regards and nice weekend!

Peter Vidal






                    sjones@hpproducts

                    .net                     To:     mapics-l@midrange.com

                    Sent by:                 cc:

                    mapics-l-admin@mi        Subject:     Re: Questions on
on purging IMHIST
                    drange.com





                    08/10/01 12:24 PM

                    Please respond to

                    mapics-l










Our IMHIST contains only current year & last year  transactions.  We have a
program that we run after year-end, that takes the older records from
IMHIST  and duplicates them into a new file that we create called IMHISTyy
where yy is the year of the transaction, ie at the end of 2001 we will
create a file called IMHIST00 that will only contain transactions that were
generated in year 2000.  Then we delete out those records and do a reorg on
IMHIST.

This helps in controlling the size of IMHIST & allows our users to still
write queries over prior years data if they need to.

Also with many people asking questions about moving to a newer release of
MAPICS, we found that having as few as possible records in IMHIST is a HUGE
help in cutting down the conversion time.




Steve Jones



                    "Burns, Bryan"

                    <burnsbm@Echoincorpo        To:
mapics-l@midrange.com

                    rated.com>                  cc:

                    Sent by:                    Fax to:

                    mapics-l-admin@midra        Subject:     Questions on on
purging IMHIST
                    nge.com



                    08/10/01 11:55 AM

                    Please respond to

                    mapics-l






Hello All,

We are running XA5.5 and I need some help with IMHIST.  It has more than 8
million records and is due for a purge.  I have the following questions:

1)         The MAPICS documentation says to run a transaction history
report
before a purge, but with 8 million records, how long would that take and
how
much DASD would it use?  How necessary is this report?

2)         I have been told the purge will have to be done on a three day
weekend as it will take 50 hours or more.  Any tips on speeding the purge
up?

3)         If the purge is not finished when the work shift begins, I
assume
that IM transactions will be locked out.  What other parts of MAPICS would
be locked?  This is not a dedicated mode task from what I can see.

4)         The IMHIST file has a member IMHNEW with 1.3 million records.
The
MAPICS web site has indicated  that IHNEW is built on the fly for
Transaction History reports.  A DSPFD indicates IMHNEW was last changed on
7/11/01.  We think that it got created but not cleared on that date when we
abended a transaction history report that had no limits.  Can we just do a
clear it with a CLRPFM?

Thanks for any help.

           Bryan Burns
           AS/400 System Operator
           ECHO  Incorporated
           847-540-8400  ext. 493
<Burnsbm@echoincorporated.com <mailto:Burnsbm@echoincorporated.com> >

_______________________________________________
Mapics-L mailing list
Mapics-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/mapics-l




_______________________________________________
Mapics-L mailing list
Mapics-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/mapics-l




_______________________________________________
Mapics-L mailing list
Mapics-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/mapics-l
_______________________________________________
Mapics-L mailing list
Mapics-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/mapics-l











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.