>Hi,
>
>Was thinking throughtout the new year night <g>. Your concepts I can get some (in my layout) and use some. Like you said all this is a long process, thus initially I won't stop building. My directory structure is as follows:
>

>C:
>+---VSO2 (Deve dir)
>      +----Lib  (Framework dir) etc.
>      +----SW (All apps dir)
>            +-----A09  (App dir contains the EXE)
>                   +----CMP00001 (Data dir)
>                   +----SPRS (screens)
>                   +----PRGS (progs)
>                   +----MPRS (menus)
>                   etc.
>                   +----VSOSYS (project dir)
>

>
>Now as I was thinking, !!!phew!!!, the per client directory structure as and when required. This follows:
>

>C:
>+---VSO2 (Deve dir)
>      +----Lib  (Framework dir) etc.
>      +----SW (All apps dir)
>            +-----A09  (App dir contains the EXE)
>                   +----CMP00001 (Data dir)
>                   +----SPRS (screens regular production files)
>                   +----PRGS (progs regular production files)
>                   +----MPRS (menus regular production files)
>                   etc.
>                   +----VSOSYS (project dir)
>                   +----GBLSYS (project directory using client initials as I already maintain them)
>                         +----SPRS (screens, optional as and when required)
>                         +----PRGS (progs, optional as and when required)
>                         +----MPRS (menus, optional as and when required)
>                         etc.
>                   +----AISYS (project directory using client initials as I already maintain them)
>                         +----SPRS (screens, optional as and when required)
>                         +----PRGS (progs, optional as and when required)
>                         +----MPRS (menus, optional as and when required)
>                         etc.
>                   etc.
>

>
>These are just theories yet. Now VSOSYS my project directory is the main stream app whose project is what I will want to distribute under regular circumstances and for emergencies. GBLSYS for eg. is the directory structure of my client GBL and will contain only the required files, as this project is on the same level as VSOSYS it will automatically find files which are still in common. The sub-dirs under GBLSYS will contain files that may be sort of checkedout for development from the regular dirs. Just a thought in between instead of GBL I can maybe have a code for the release note no. that you had mentioned.
>
>So when I compile using the dir GBLSYS the build is for, in this case, my client GBL and I deliver to him only. Now client XYZ comes along with an urgency I compile from VSOSYS my regular app and deliver it to him. Once I am through with say client GBL (or R.N. code) I have the task of merging the checked out modules into the main stream app. This might create problems as I might have modified a same named file during the urgency request of XYZ but here I guess FC from DOS will be handy. Once merged the GBLSYS directory will be removed until required again.
>
>As far as data structures are concerned I will only have one CMP00001 and taking your adivse I'll one add and increase size where client dirs are concerned.
>
>These thoughts started at 1:00am and ended at 8:00am with a lot of sleep inbetween, so I guess there may be a lot of holes to be plugged in this scenario. What I am counting on is that becuase my original dir structure is not disturbed, so worse comes to worst, I'll be able to start of from where I last stopped.
>
>Please advise and let me know if I have to clarify a point. Could you give me a critical evaluation of my derivations of your convcept.


Hi, I hope I can ...

From what I see, you may have missed the basis of how we work, though maybe I didn't say it that explicitly;
We always work in VSOSYS, and upgrade to some PRODSYS when R.N. is ready. Hence, you would have a GBLPRODSYS where you upgrade the not approved R.N. to (thus not to PRODSYS yet). And after the R.N. is approved, you would upgrade to PRODSYS, and the R.N. would be removed from GBLPRODSYS.
IMO you would need the same for LIB, as long as you develop the framework too (like we do).

I think (I see) that you decided that you keep on building, but please know how many problems you will get to yourself by this, and that for each byte changed in the one program or screen you will need a complete copy of all. Technically maybe not a problem, but overdone. But, functionally IMO this IS a problem, because indeed you will need to keep track of which functions are changed i.e. the next time your once upgraded customer needs another upgrade before the R.N. is approved by him, you will need another complete copy, right ? so how to do that.
So what we'd do, is copy the changed programs (etc.) only to GBPPRODSYS, and since it's not in PRODSYS, customer B won't be harmed if he wants a change to another program. However, if customer B wants a change in a program that affects the R.N. for GBL, you are in trouble, or better : B can't get his upgrade until GBL approves the R.N. Note that this is exactly what's happening at ours, only at the level of developers; once in a while we have to tell customer B that he can't get his upgrade "this week yet", because according programs are in progress by some other R.N.; nothing to do dear customer (and it would be what you want).

As I told you, you'd need the Release Note system, which btw may come to the scanning of all your customer directories once a program needs to be changed; a surrogate system, but it will work I think.

Please note that again this takes some more from you from the point of general development, because the fact that one new program didn't affect the old onces by means of code, doesn't say that there won't be a data-conflict. This is hard to explain in words, but I think you recognize what I mean. In fact this comes to force yourself never to have ANY conversions needed for an upgrade; indirectly this comes to what I mean (too hard to explain further). 100 % proper normalizing does this job, and your app will have an infinite life, and can be extended forever. The lifecycle is therefor endless too.

Also note this :

We also use another method, which is more similar to your interpretation of the concept. This comprises of having "Alternative Functions" which in fact are meant as real custom functions for the one customer, i.e. are not part of the package. For us this is one print only, and this is for the printout of Production Orders, which are too complicated to ever let be created by a report generator (we built our own). Now this function (or functions) just do exist in the normal VSOSYS, and contains some standard print who nobody will use, and it acts as a trigger to the custom function. So, per customer we have a GBSSYS directory indeed, and it could contain this custom function. Now each function (like the P.O. print) applicable to exist in custom work, contains a call to some system function, which finds out whether the function exists in the customer's directory indeed. Note that this works like this at the customer's site, and that at our DE site a popup appears which asks for "for which customer do you want to call the function", showing all the customer's functions for this stanard function;

Now for you application it 'd sort of work the other way around; like you suggested, you copy the source to the custom directory, and from that point on, you develop in the copy, until the customer approves the function, and then you copy it back to VSOSYS. Now supposed you'd have the same popup as we have, you will always be notified about the program pending for another customer, right ? so that would be a way of working too.
But in all cases, I'd strongly advise to forget about the build.

If you have further questions, or can't sleep anymore, please ask again ...

Peter