I am trying to figure out the best way to arrange my folders and master files in developer studio. Currently we create a new folder it seems like for every project we create. We have currently about 60 folders under applications in our system. Many of our folders have master files (store, category, sales etc) that are found in many other folders. I am unsure as to what is best? Fewer folders with more master files and no duplication, or more folders with duplication of master files. Just looking for some ideas on how others are doing it.

Hi, H.

First, would you please update your profile signature with your product suite, release levels, and platforms so that we can better help you.

I administer a user-development Data Servers environment that has over 500 directories. When I got here, there were many, many duplicate masters and it took me quite awhile to clean that up. Needless to say, I don't recommend that.

What I would recommend is that you have a set of master directories or projects for your enterprise data sources. You can divide those up by functional or business area. Put those directories in your global path in edasprof.prf if everyone has access to them.

Other than hold masters, the other directories shouldn't have any enterprise masters in them, just focexecs, gifs, htms, etc. and masters for personal or extracted data.

You don't mention what your developer mix or user mix is but it might be good to know that.

Since we are self-service and our developers are users, each person can create their own directories, multiple ones if necessary, and we secure them by business group. We also recommend that each business group have a 'production' directory as we also don't have a development environment.

I'd be happy to share more info if you need it.

We have done almost exactly as Ginny has suggested. I would NOT recommend duplicate master files - first for maintenance purposes. If data changes you have to make sure you get ALL the copies of the MFD fixed. Also, having worked with numerous individuals who are confused as to why their Master files are not working like they think, you might not be using the MFD that you think you are.

As Ginny suggests, we have created all of our ADABAS MFDs in a directory, DB2 in a directory, SQL in a directory, and fixed/flat in a directory. Data files, fexes, images, etc. that are specific to a single app are also created in their own application directories.

Any files that are access-sensitive (e.g. security) are in their own directory and access to the folder is given as needed via user profiles.

That is great information, thank you. One other question. Some one at IBI told us that having many master files in a folder slows down your application. They told us to put our masters in smaller groups in folders because when you execute your focexec, it creates a link to all the masters in the folder and path. That seems to be why we have some many folders with multiple masters. I think I will do as you suggest. It makes sense to me. Thanks again.

OH, and I updated my profile so you can see what we use.

Depends on what you mean by "many." A couple hundred - probably OK. A couple thousand - you may start to see a delay.

Also, I don't think it actually creates a "link" to all the masters, but it does look through the path until it finds the Master File being referenced, so if that path is extensive including thousands of MFDs, it would take longer. Other tools like Report Assistant (or whatever it's called now) that need to retrieve a list of available MFDs would experience a similar delay. Just try to keep the path clean and concise. Use profiles if necessary to shorten the path for users.

HCall,

Like others, we organize our MFDs by business application and Data type. After 10 years of 'playing around' we've learned that organizing WebFOCUS stuff involves DataBase technology, Business Functions, Users, Roles, Domains, AppDir dictories, and RCaster organization. The number of Applications, Users, Developers, and Business Functions must all be considered as they influence how easy or hard it is to maintain the schema. We settled on the following methodology, and apply it uniformly worldwide:

1. We put the MFDs for 'public' (cross/multi application) data in AppDirectories according to their Database technology: One AppDir for public MS/SQL data, another AppDir for Oracle data. [We use only these two.] These AppDirs contain MFD's, FEX that display table content for development and diagnostics, and 'public' INCLUDEs. They are pathed (by EDASPROF.cfg) into everybody's path.
[I guess if we had a number of large independent applications using the same technology, which we don't, we'd split MFDs for that technology into multiple AppDirs.] The idea is to isolate MFD's so that whenever an RDBMS technology or large independent application changes we have all public MFDs in one place.

2. All other MFD's, by definition, aren't public, but specific to one business application regardless of data storage technology. We put these in one AppDir reserved for that application's MFDs, FEXs, HoldFiles, etc. If an application warrents its own AppDir then it has its own paralled MRE Domain and the AppDir is named in the MRE Domain's Application Path property. These AppDirs are mentioned, via APP PREPENDPATH, according to 'need to use', in each user's profile. When the application goes away, as they all do someday, we just archive the respective AppDir and Domain. If the DBMS technoology changes, we know which applications use it and change only the appropriate AppDirs.

4. MRE Groups are structured around business applications. Everyone who needs a business application is mentioned in that app's User Group. We run only under Windows, which does not support MRE User Group profiles. We wish it did because then most user's would not have their own profile, but get access to authorized applications via their group profile.

3. We have about 50 users. Most just run reports, they don't develop them, so each has a UserID, no MRE Domain, and no DevStudio. Their user profile APP PREPENDPATHs the AppDirs they need.

4. About 5 users are also developers. They have DevStudio, their own MRE Domain, and a user profile with a generous APP PREPENDPATH.

5. We're primarly an RCaster and Dashboard shop. Each Developer has his/her own RCaster UserID for testing. All production work is scheduled in a single RCaster UserID, "rcaster", with its own production schedules entered by the responsible developer. The schedue name always indicates the business application, and by inference, the AppDir it uses.

I hope this gives you more ideas to consider.

Chris Burtt