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