Developer Studio runs intolerably slow at my Company. We have 17 application libraries in the Developer Studio application path and the overhead DevStudio encounters attempting to keep all those library members in sync bring it to its knees.

The 17 application libraries are standard IBM mainframe PDS's.

I am wondering how other installations deal with this issue.

FOCUS 7.2.5, WebFOCUS 714 and MVS.

Any feedback?

We had that problem too, I upgraded my local PC with 1 Mb of memory and now it's working without a problem.

Frank

Would that be 1 GB of memory? (1 MB wouldn't make much difference :-)

Darin...you'r right

But I'm old (IT wise speaking) My first computer had a 640kb memory. And the harddisk was 10mb.....
We run PcFocus on that and the software came with 10 or 12 8inch floppies.
I wrte a program that took more than a day to give me the result (I only needed to run that once a month)

So don't complane about performance....

Frank

My first one had 16KB memory and NO hard drive. Everything loaded and ran from the floppy drives.

My first computer had 1byte of memory and you had to load the program from punched tape.

If I needed to run a program my father would get me out of bed at 3am, 2 hours before I had gone to bed and give me a sound thrashing for waking him. Breakfast was licking a lump of gravel...

And when you tell folks today how hard you had it, there's none of them will believe you!

This message has been edited. Last edited by: hammo1j,

Hi Ed,
One problem you could encounter is if the PDS'es are being archived to quickly, which could cause a wait when they are referenced.
Rich

Hello All.

I work for the same company as Ed, and can add some detail to the conversation (other than commentary about the technical specs of my first computer).

We are running multiple EDA servers in MVS and AIX. For MVS, we have multiple PDS's allocated as libraries for our WebFOCUS components, with a separate PDS for each environment (Dev, Test, .... Prod). These datasets are concatenated in the JCL running for each MVS EDA server; as such, the PDS's are never in a migrated state, as they are perpetually referenced.

Originally, there was only one set of PDS's for all projects running against MVS. Identifying the large number of components in these libraries as the source of a caching "bottleneck", we created multiple sets of PDS's for each application and parted out the components to their respective libraries. This gave us a noticable difference in performance, where it is now comparable to accessing components in the AIX libraries through Developer Studio, but performance is slow enough to discourage development in Dev Studio (and certainly not on a par with the performance seen in training classes or at Summit).

As a further measure, we have checked "Cache remote directory and file information" in the Local Machine environment settings for each environment, which has also helped somewhat.

Having exhausted the above ideas, we have hit a performance plateau and are still struggling with development in Dev Studio.

In terms of the local machine, we have a mixed bag here; I'm running a 1.5 GHz processor and 1.50 GB of RAM on a 598MHz bus speed board. Accessing our biggest library, I do see a CPU spike, but not until the directory contents have been retrieved and are being refreshed to the screen. There's no spike in page file usage, and any spike in use of network bandwidth is negligible.

Has anyone else encountered performance issues using Developer Studio, particulary with WF release 7.1.x, and how did you get around it? If you have upgraded to a later version of WebFOCUS, did it help?

- Sean

Hi, Sean.

I'm not sure that I can help you but I do have a couple of thoughts. I have an AIX configuration with 490 directories. Yikes. It does take a while to open up Data Servers (we don't use Projects) and I just tested and it took 20 seconds to do a refresh. I wish we had fewer but be that as it may, the performance is tolerable.

The thing that puts repsonse time in the 'you-know-what' is when the web server/app server gets tied up. Can you check your reporting server console when things like saving, copying, etc. get bad? Do you have a lot of agents running?

Anyway, I'd check the client side too if I were you.

Not much, Huh?

Sean

Believe it or not the problem is not the retrieval of directories but the insertion of the results into memory on ds.

https://forums.informationbuilders.com/eve/forums/a/tpc/...761052662#1761052662

I have raised a case on this problem and IBI operative Whilhemina has duplicated the problem but it still remains unsolved as at 7.66.

I now use notepad++ which works fine instead of ds for normal development. It all depends if you can attach your MVS disk as a windows drive then notepad++ will work with the templates I have posted somewhere and it is very quick on directory listing and demonstrates the problem with ds.

Ginny, John [hammo1j],

Thank you both for your responses and suggestions. I have also read through the above thread about the performance issues when upgrading from 7.1.x to 7.6.x, and found it interesting...

In my company's case, we only upgraded to 7.1.x (patch version 7.1.7, with Dev Studio ver. 7.1.6) about a year ago. I won't say what we had before, except to say the development platform involved a chisel and slab of granite.

Some departments experimented with using DS prior to the upgrade, but found performance too slow to use. The company has mostly coded either in notepad or directly on the mainframe to date. We took another look at DS post-upgrade and some departments are actively using, but performance is still painful.

Ginny, I'll have to pursue your suggestions via Infrastructure, but the bad performance is pretty consistent and doesn't seem to vary with any contributing factors. (For the record, any info volunteered based on experience is never considered "not much". Thanks!)

John, what's interesting is that we're seeing performance issues in 7.1.x, whereas you saw a performance hit when upgrading from 7.1.x to 7.6.x. Was 7.1.x tolerable before? Either the problem isn't specific to version, or we're going to be calling these "the good old days" after our next upgrade.

Thanks for the time and creativity you have put into creating examples and bringing this to IB's attention.

It sounds like there is no "trick" we're missing to fix this issue, but rather an issue for IB to investigate. Ed opened this topic; I'll leave it to him to close, but I thank you both for your help.

- Sean

Might be worth looking at temporarily disabling your anti virus on 7.1. Certainly 7.1 is a greyhound compared to 7.6.

You can put the ds communication layer trace on to find out exactly what is going on. You may have a different problem with 71 in that the overhead is in the webfocus query to fetch the directory listing.

quote:

Originally posted by Sean P Murphy:
Ginny, John [hammo1j],

Thank you both for your responses and suggestions. I have also read through the above thread about the performance issues when upgrading from 7.1.x to 7.6.x, and found it interesting...

In my company's case, we only upgraded to 7.1.x (patch version 7.1.7, with Dev Studio ver. 7.1.6) about a year ago. I won't say what we had before, except to say the development platform involved a chisel and slab of granite.

Some departments experimented with using DS prior to the upgrade, but found performance too slow to use. The company has mostly coded either in notepad or directly on the mainframe to date. We took another look at DS post-upgrade and some departments are actively using, but performance is still painful.

Ginny, I'll have to pursue your suggestions via Infrastructure, but the bad performance is pretty consistent and doesn't seem to vary with any contributing factors. (For the record, any info volunteered based on experience is never considered "not much". Thanks!)

John, what's interesting is that we're seeing performance issues in 7.1.x, whereas you saw a performance hit when upgrading from 7.1.x to 7.6.x. Was 7.1.x tolerable before? Either the problem isn't specific to version, or we're going to be calling these "the good old days" after our next upgrade.

Thanks for the time and creativity you have put into creating examples and bringing this to IB's attention.

It sounds like there is no "trick" we're missing to fix this issue, but rather an issue for IB to investigate. Ed opened this topic; I'll leave it to him to close, but I thank you both for your help.

- Sean

Sean how long does it take for DS to create or copy/paste a fex? mine can take between 10-20 seconds to create and open a 21 byte fex. its astonishing just how long it takes- making a blank fex in a notepad take no time and copying and pasting via any other explorer than DS is again painless....

im wondering if the two issues are related? im not a long term user but have found the issue with every DS version after 716 and similarly every version has also had the loading speed issue you have- its prohibative and i would migate off it permenantly (explorer2 is a good alternative but is not free for business )

John,

Thanks for the ideas. Mentioning the fetch has me thinking about the concatenation of libraries and the way the cumulative components are cached and displayed. Thanks for the heads up about the decline in performance in 7.6. I just got done getting everyone excited about upgrading to the next version. I'm going to get hung from the flagpole for suggesting it...

Nubi,

How long it takes to create a FEX varies by stages of the create process, depending on what we are doing. This was an interesting point to mention. When creating a new FEX, the contents of the current folder must first be loaded for display as a Windows "save-as" style explorer window (about 12 seconds to cache 103 file names, in one of our smaller folders). Once the new FEX has been named, there's a further delay while the stub file is saved, but it's not long.

The next big delay comes when creating a new report, as a full list of available data sources is cached from our concatenated libraries for display in the WebFOCUS Table List. I don't have an accurate count of how many members are listed here, but it takes close to a minute to load.

I think we're witnessing the great irony of WebFOCUS. The product is excellent for churning high volumes of data (thanks largely to offloading the work to the source data's management system, where possible), but the development tools cannot handle high volumes of components.

The following is taken from the Managed Reporting Administration Manual, in the chapter on Additional Administration Topics. It may address some of the performance problems in DS.

You can obtain a list of available Master Files more quickly while you work in the Managed
Reporting or Data Servers areas if you do not retrieve information based on the REMARKS
attribute that is stored within the Master File.
By default, Developer Studio opens and parses all available Master Files and determines if
the REMARKS attribute is available in order to display information in the Table List dialog
box. You can change this behavior and decrease the time required to display the list of
available tables because each table will not be opened and parsed for available remarks.
If you do not want Developer Studio to check for the REMARKS attribute, modify the
ibiapplets.txt file, typically located in the following directory:
install_drive:\IBI\WebFOCUS76\ibi_html\javaassist

In the ibiapplets.txt file, change the following text from
TABLE FILE SYSTABLE
PRINT REMARKS AS '
BY NAME AS ''

to:

TABLE FILE SYSTABLE
-*PRINT REMARKS AS ''
-*BY NAME AS ''
PRINT NAME AS ''

Hi Sean, Ed,

FYI, programming already opened a project and would like you to open a case so that we can take a deeper look at the traces/logs etc. To do so, you may either call at 1-800-736-6130, or access online at InfoResponse.

Hope this helps.

Cheers,

Kerry

btw Performance in 767 DS is no better than any of the 76 releases...

Hi John,

Did you report the issue to Information Builders' Customer Support Services?

Ed, Sean, if you open a case, can you please let me know the case number so that we can better escalate the issue to appropriate departments?

Thank you,

Kerry

quote:

Originally posted by Sean P Murphy:
Nubi,

How long it takes to create a FEX varies by stages of the create process, depending on what we are doing. This was an interesting point to mention. When creating a new FEX, the contents of the current folder must first be loaded for display as a Windows "save-as" style explorer window (about 12 seconds to cache 103 file names, in one of our smaller folders). Once the new FEX has been named, there's a further delay while the stub file is saved, but it's not long.

The next big delay comes when creating a new report, as a full list of available data sources is cached from our concatenated libraries for display in the WebFOCUS Table List. I don't have an accurate count of how many members are listed here, but it takes close to a minute to load.

it is weird how the language can be so powerful yet the dev environment so unstable- im personally going to go back to the version which doesn't steal your focus when you run a fex (i think it was 716) and will get round the prohibative cretae/delete/load/navigate times by using notepad++.... wake me when a decent version of DS is released