Hi all,

Hoping someone might help out a bit with a few issues I'm having.... we've recently upgraded webfocus from version 5 to 7.1.4 . Starting developer studio now takes approx 2 minutes, but if I uncheck 'Show projects on explorer tree' the program loads instantly - with that setting checked though it's tortuously slow and freezes frequently.

Unfortunately my next problem is the MAINTAIN project I've inherited that is producing an error message(and also forcing me to keep 'show projects' checked!). We recently upgraded from webfocus version 5 to 7.1.4 and I'm wondering if there is something set incorrectly or I need to change a path in the code. The error is "(FOC03749) FOCCOMP is 'old'. To regain start up speed use RECOMPILE." This is also my first experience with MAINTAIN and my knowledge is VERY limited.

Lastly, in trying to create a new project I can't even open the MAINTAIN development environment - the program tries to load, but eventually comes back with 'program not responding'.

Sorry for so many questions...... I'm starting to wonder if this is an issue our webfocus technical staff needs to look into as I don't have access to the command console either???

thanks in advance for any help/suggestions,
Donna

Hi Donna
We at IBI will be more than happy to help with these issues. In the case of the compile error, the best thing to do is:

1) Back up the FCM files on the server (PLEASE do this first)
2) Then delete the original FCMs
3) Redeploy and Compile the Maintain applications.

This will guarentee that the FCMs (Or compiled Maintains) are new.

As for the slowness and the MDE not responding, this is most likely do to installation issues. Please open a case with CSS and we can walk you through it.

Thank you
Mark Derwin

Ok I want to bring this one back to the top because the new handy-dandy error message doc says this --

(FOC03749) %1 FOCCOMP is 'old'. To regain start up speed use RECOMPILE.
In this release the format of the MAINTAIN FOCCOMP has changed. You can
still use RUN to execute a MAINTAIN FOCCOMP but the time to first screen will
be slow (similar to EX of MAINTAIN FOCEXEC). To regain the start up speed use RECOMPILE on the old FOCCOMP to produce a new FOCCOMP.

That sounds to me like there's a way to recompile the old foccomps directly instead of doing each by hand? I have about 125 in different apps and am not looking forward to tediously going through each one. Is it indeed possible to do it on the existing base of compiled code?

Alternatively, is there a way to suppress the message on the screens of my end-users?

J.

John

Every new release may require that Maintain programs are recompiled. This is natural. Setting up a good deployment scenario is part of a setting up an environment that enables a smooth upgrade path. This is applicable to all WebFOCUS code, not just the Maintains. For me it would be normal to deploy as part of upgrade testing, as any changes that affect the code cannot be made in production.

Deploying a project will compile all maintains in that project; ensure Smart deploy is not checked to ensure recompile of Maintains that have not changed.

If you are saying that you have 125 projects that need deploying, I might suggest that this is overkill and should be condensed into a more manageable number.

The alternative is not to use MNTCON RUN but use MNTCON EX, but that is not something I would reccommend.

If you do not want to deploy correctly, you could build a program to pick up the maintain names and applications and issue a MNTCON COMPILE for each.

quote:

The alternative is not to use MNTCON RUN but use MNTCON EX, but that is not something I would reccommend.

IMHO, that depends on the size of the maintain. If my maintain has no more than 2 (maby 3) screens and less than 200 line sof code, I don't compile them. In my experience the gain of speed for these small maintains is negligable. And you can upgrade the webfocus product easily. So I try to keep my maintains as small as possible...

GamP

Don't forget persistent v. non-persistent. It is not just about lines of code and number of screens or start up time, the resource used to EX is very different than resource used to RUN.

To use either is a matter of testing / checking each Maintain. In general less resource is used for RUN than EX, though the startup to the user may be little different. It is informed personal choice as to which to use, not recommendation.

Frankly in my case the real issue is the big honkin' error messages that damage the screens. The menus don't move down along with the rest of the widgets on the screen and the framing gets hosed up, so that the user can be informed that the routine is taking .32 seconds to elaborate instead of .29. What should have been an efficiency concern is turning into a dozen human hours of upgrade work instead of an hour of CPU work that no one really notices.

It just seems like a Type II error built into the system.

J.

No John, the real issue is that you need to do a recompile.

You have upgraded but not allowed for the fact that a recompile might be required on any upgrade, this includes a Machine/OS upgrade.

There is a message that says you need to recompile, which should be a simple task - and you want what... sympathy?

I couldn't give a rat's a$$ about sympathy. I want the upgrade to not add to my schedule burden.

The application works perfectly without a recompile . . . except for the warning message. Error messages are a requirement, but presenting a warning that actually creates an error condition is short-sighted.

J.

There is always a reason for a recompile. Some upgrades do not require one, others, where there is a change that the programmers feel a compile is warranted, do.

Why, I have to ask, is a recompile such a big deal? I have system with 140 maintains, yes it takes a while for the machine to do. Takes me 2 minutes set off.

Between all the maintains, the supporting load focexecs, the popper-screens for data selection, javascripts, etc., I'm up around 750. individual units. I'm not comfortable putting all of that into a single app directory. We have about 35 apps deploying to the same location.

It's not that it's a crisis to do the legwork, it's just time consuming to make a full accounting to make sure every app has been deployed, and it's another place for failure to occur. For legit errors or incompatibilities I'm fine with it. But putting a message up that creates an error . . . The Maintain product developers are looking at us developers as the customer instead of looking at our customers as the customer.

J.

John,

I'm pretty sure you could write a procedure (fex) to do all the re-compiles in a batch.

Basically just a list of all the mnt names with the compile command:

MNTCON COMPILE [dirname/]procname
...
etc.