A7.3 Cume14 Re-use Of Deleted Records

[tpayne]

Does anyone know of any potential problems that could occur if we change JDE files to allow the re-use of deleted records on the AS400?

I know that use of Relative Record Number would be a problem, but that would also be a problem with any file reorganize. I am not aware that JDE uses Relative Record Number in any files.

There are a few files with the UKID field, but I think this is assigned using Next Numbers (if I remember correctly) and is not a RRN.

The reason for asking is that there are only maybe 3 days in the year when certain files like F4211/F0911 can be taken offline, and since F4211 for example has 100 million records, the time to reorganize would be horrendous.

YES they are working on purging using ARCTOOLS, which I know little about, but apparently this can reorganize a file while it is still being used. I asssume it just compacts the data, and maybe then deletes segments from the end of the file.

Until the reorganize can be completed, if we could re-use records already deleted to save files from getting larger, that would be good.

Thanks in advance for any advice.
Tony

 

[John Dickey]

What about any in house programs?=C2=A0 Might some have been written using relative record number processing, rather than keyed processing?=C2=A0 Woul d take a good amount of effort to try to find and investigate everything, i s what I am thinking.=C2=A0 I personally like the idea of not reusing delet ed records, even on a file like F0911.=C2=A0 When researching problems/issu es, it can be very advantageous to see the order that records were added to the file.=C2=A0 I have relied on that ability fairly often in my career. =C2=A0 So my recommendation/opinion is to not re-use deleted records.=C2=A0 I have heard of Arctools, but have not used it and do not know how it work s.=C2=A0 It is supposed to allow you to reorg files with very minimal downt ime.=C2=A0 So that should help out with the reorg situation.=C2=A0 On F0911 , what I did for that reorg is that before doing the RGZPFM command, I woul d drop the access path on non-critical logicals to *REBUILD, do the RGZPFM, then change the access path back
to *IMMED on the logicals.=C2=A0 Why?=C2=A0 The RGZPFM command will reorg only one logical file at a time.=C2=A0 If you drop the access maintenance a nd then rebuild after the reorg, if you have a multi-cpu machine, you can h ave several logical file rebuilds running at the same time.=C2=A0 So the ov erall reorg time is shorter.=C2=A0 The RGZPFM runs much faster and access a llowed back to the system much faster.=C2=A0 The risk is someone using a pr ogram that utilizes one of the logical files - that is why you have to iden tify your most used/critical logicals and keep them maintained in the reorg command.=C2=A0=C2=A0 But there are many F0911 logicals rarely used, so no problem letting people back on the system while rebuilding their access pat hs.
=C2=A0
John Dickey

 

[louiste]

Cannot think on any issues except if preserving the RRN -sequence that the records get written is imperitive. My also be silghtly slower when writing a large number of transactions if disk space is an issue.

 

[jean_driscoll]

There is one important program that I know about. It is the posting of Payroll. I worked for a company that had 8000 employees, so this payroll ran for 2 hours. If someone would add/delete journal entries during this period, the payroll post would sometimes assign the wrong company on journal entries due to the way it read the F0911. That was with A73 cum 12.

 

[tpayne]

Thanks John.

I don't think that there are any local programs that use RRN's, in fact unless local programs are very old, I don't think there are too many people around who remember having to use them (like on S/34 having to create your own Alternate Indexes / Logicals using RRN chains).

Problem we have is retail stores that are open 6 days a week, and at least 1 warehouse that is open 7 days. There isn't enough downtime to be able to do a regular reorg.

I like the idea of dropping little used access paths for a short time to speed up the reorgs. That makes a lot of sense. I know at past sites the F0911 reorgs take forever to rebuild the access paths.

They even considered renaming the F4211 file and starting with an empty one, then copying in the existing records. Not thought of that before, but it might be faster, especially if you could add the most recent data first. That might work for the F0911 too, provided inquiry access to historical data was not needed for a while.

 

[tpayne]

Thanks Teresa,

We are talking files that have more than 10 million records, with a lot of deleted ones, and limited down time when reorgs can be run.

I don't think preserving the RRN sequence is important, especially if we are usign Arctools, and I believe that this must move the records to the top of the file and therefore change the record sequence anyhow.

 

[tpayne]

Thanks Jean,

It looks like payroll is used here to an extent, so I don't know if this would be an issue, but most likely when we did a reorg this would be at the weekend when payroll journals were not being posted.

 

[ARIASMA]

We have just started using Arctools, and found that reorganization of such a large file will take you a long, long time. What we are doing is Archiving records over 2 years old (F0911 has 702 million records we are archiving 50%) then running the reorganization.

The same process should be run against the F4211 because it is use more often it does not give the ReorgWizard much access to the file. For example, we are running the ReorgWizard on the F4211 for a few weeks and it has process only 30 million records (F4211 328 million active records and 128 million deleted records)