GUI Compiling lots of programs

[Chris Kelleher]

MFG/PRO 8.6d, Progress 8.3B11, Windows NT 3.51 / Winframe 1.7

I am attempting to recompile the entire MFG/PRO release directory as part of our
migration to Progress 8.3B .

Since mfgutil did not work, I wrote a home grown program to loop through an
input list of program to compile (e.g., utcompil.wrk), compile with a save-into
the appropriate two-letter directory, and a check of ERROR-STATUS for any
compile errors.

The program itself work great, but I run into a problem after a large number of
files have been compiled -- the 'srt' file grows to 2gig and thus the whole job
barfs.

I know I can use multi-volume srt files, but don't have *that* much more space.
I also find it hard to understand why this file is growing so huge!

I've tried to restructure the compile to do a limited number of programs at a
time, but all within the same Progress session. Still fails the same way. Last
try it failed, after around number 905 out of about 4700.

I feel that there is probably some startup parameter to resolve this, but
haven't been able to guess or intuit what to use. I am using the following:

-e 128
-l 60
-c 75
-D 100
-TB 31
-TM 32

I've also tried without -TM & -TB, and have tried adding -s 60. No difference.

Anybody out there got a magic wand??

TIA, LLAP

Steve Delia
Corporate I/S
C.R. Bard, Inc.
Murray Hill, NJ, USA
908-277-8280

 

[Chris Kelleher]

Steve,

I'd suggest to do one of five things:

1. Use the "Compile Programs" option at 36.25.1, which will look through
utcompil.wrk for you and compile the programs. This should be able to
complete the job for you.

2. Break your one utcompil.wrk into several smaller ones, with about 800
files each (based on your numbers), and run them through one at a time.
don't change the process to run them through; instead, run the program, do
an OS copy and rename, and run the program again. This option will work
with number one as well.

3. Review the program you're using to see why you're having so much srt
file growth. Perhaps posting it here or on the PEG list, if it's not too
big...

4. Move your -T to a disk with enough capacity to support that multi-volume
srt file.

5. And of course, feel free to contact support to find out why mfgutil is
not working and get that corrected.

Good luck.

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 17 November 1999

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================

 

[Chris Kelleher]

Steve,

I too have written a program for compiling the MFG/Pro distribution. I
found MFGUtil to be clumsy and woefully inadequate, maybe I didn't give it a
chance. (Sorry Scott).

Point your -T to a local drive.
How much memory do you have on your NT workstation? Make your "-mmax" as big
as you can.

Using the client parameters shown below, I've never had a problem compiling
the entire distribution all at once.

-Bt 350
-D 100
-mmax 8192
-nb 200
-s 63
-l 512
-T c:\qad
-h 8
-TB 31
-TM 32
-rg

- Tris Hopkins
Flexalloy-Textron

 

[Chris Kelleher]

Thanks again for your response, Scott.
Regarding item 1, wouldn't I run into the same problem I'm having now? Besides,
I don't thing the logical names would be correct in the compiled code.

Regarding item 2, I did break up the entire 4700 programs into groups of 1000.
All except one group worked. That group failed around number 500. I'm
reluctant to continue with the manual breaking up of this list for two reasons:
1.) It's too manually intensive to do a lot -- I'd like to find a permanent
solutions; 2.) I fear missing something as I keep breaking the list up.

Regarding item 3, I did send the programs, but I have no idea what contributes
to srt file usage & growth (during a compile; I understand the use during index
rebuild). If I did, I might be able to zero in on it.

Regarding item 4, I'm not confident that throwing more disk (which I don't think
we have, anyway) will work. After the first 900 files, (500 during a different
group of files), the srt file hit 2gb. Even if I had 4gb to use, would that be
enough?

Regarding item 5, I tried. They were not too helpful (understandable), and
initiated a three-way ping-pong game with Progress & me -- very non-productive
and unacceptable. I am awaiting a call back from Progress; the QAD Support Rep
forwarded to me the Progress Call #.

*New question -- someone suggested not going through WinFrame (which I am doing)
-- would that make a difference??

Thanks again for your former and for future responses. LLAP

Steve Delia
Corporate I/S
C.R. Bard, Inc.
Murray Hill, NJ, USA
908-277-8280

 

[Chris Kelleher]

Steve,

I'll go to the end first. Unless you're recompiling your GUI code, I'd do
it on the server. If you are recompiling your GUI code, then I'd recommend
doing it directly on the Citrix server, and not through a Citrix session.

Now, for your specific points...

Item 1. If your code is the same as the code in 36.25.1, then yes, you
would have the same problems. However, I have run *that* code in GUI to
compile all of MFG/PRO before (over 3000 programs), and I have not run into
the problem you have. As for the logical name issue, you should be
following the famed three database model -- unless you change the logical
name (or forget to compile with it), there should be no problem.

Item 2. How often do you plan on recompiling all your code? Obviously,
that group contains *something* that's putting you over the edge. I took a
quick look at your code from the earlier post, and I see that it's your
own. Try running 36.25.1 and see what happens -- you may be pleased with
the results.

Item 3. I don't know for certain either, other than possible that standard
bugaboo of transaction scoping. Someone with more knowledge may be able to
assist with reviewing those.

Item 4. If this is a regular job, then there's cause to be concerned. If
this is a once-in-a-blue-moon job, then I'd be more interested in just
getting the thing to complete. The only exception might be that if the
code is the problem, a review (like mentioned previously) could avoid a
nasty programming oops.

Item 5. Did you contact support about mfgutil not working, or about
addressing your problem? Mfgutil is a QAD program, so we'd be responsible
for getting it to work. There may be Progress issues, but again, we'd need
to take care of it, ultimately.

Good luck.

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 17 November 1999

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================