Organizing RGZPFM in V4R3

[David Abramowitz]

One of my clients purchased a model 620 w/V4R3 to replace their 9406 F35 running V3R2. We are in the midst of running parallel tests, and are extremely impressed with the performance of the 620. That is we were impressed, until we hit nightly procedures that reorganize files. It appears that a typical reorg takes two to five times the length of time that it did on the CISC system. A typical reorg is: <tt>RGZPFM filename KEYFILE(*FILE)</tt> Does anyone know why reorgs are slower on the RISC box? Is there a way to speed up the process while retaining sequencing? TIA, David Abramowitz

[Guest.Visitor]

Try 5769999 MF21025 Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[David Abramowitz]

On Monday, March 08, 1999, 10:21 AM, Chuck Pence wrote: Try 5769999 MF21025 Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever. <hr> Once again, thanks Chuck. . .I will let you know how it turns out. David Abramowitz

[Guest.Visitor]

Hi David, I am involved in a 3.2 to 4.2(620) upgrade. About 576009 **** solution . I fear i dont get it. Can you please explain?Thanks in advance. Raj S.

[David Abramowitz]

On Wednesday, March 10, 1999, 02:48 PM, Rajamanickam Sankaran wrote: Hi David, I am involved in a 3.2 to 4.2(620) upgrade. About 576009 **** solution . I fear i dont get it. Can you please explain? Thanks in advance. Raj S. <hr> I don't think I can create an explanation that would tell you any more than this thread has already mentioned. All I can say is get all the PTFs you can, make sure they are loaded and applied. At this stage, with V4R4 announced, it seems a bit odd to be planning an upgrade to V4R2. Why not wait for V4R4 availability? David Abramowitz

[Guest.Visitor]

Upgrade process is about to be completed and the cutover is withina week. All the PTFs that were ordered alongwith the machine are installed and cum package is applied temporarily. Raj S.