In the $BSE/lib/user/ubsp file I read this section:n_vrc_path:14
vrc_path:ba:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:cc:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:cp:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:ps:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tc:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:td:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tf:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tg:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:ti:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tp:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tr:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:ts:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tu:B40Oc4own:B40Uc4stnd:B40 c4
vrc_path:tt:B40 c4This information is also available via the "pacc:OPER_001" setting in the same file and the fd<VER>OPER_001 file in $BSE/lib. Now I wonder: What is the relevance of this redundant information? What is the origin from this information in the user file? Is there a way to manipulate the derivation structure for a specific user? If there is not, then why is this information not contained in the fd file itself?

Hi,


What is the origin from this information in the user file?


The VRC info has been generated when you did a convert to runtime for a user to link him to a pack.combi and a company.


Is there a way to manipulate the derivation structure for a specific user?


Yes, there is a way to manipulate.
You can do it in the fd6.1<Pack.Comb> file by editing.
For example
I want that a specific user only is permitted to run a changed session, e.g.: tiitm0101m000.
Specify a new directory into the application directory, e.g.: specific.
Into this directory you create the directory where to put the object e.g.: otiitm and a directory ptiitm.
Put the 'o' object into the otiitm e.g.: oitm0101 and the p-object into the ptiitm e.g.: pitm0101.
Now you can edit the fd6.1<Pack_Comb> by copying the oti line and the pti line and put at the begin the userid and the new created directory e.g.:
{<userid>}oti:${BSE}/application/specific:<the rest of the origin line>
{<userid>}pti:${BSE}/application/specific:<the rest of the origin line>
Be aware of that after you have done a Create Runtime DD the fd6.6<Pack_Comb> file has been rebuild again. So the changes are lost.

GN

Djie-En: qoute:Better use [ quote ] and [ / quote ] (but than without spaces)



Sorry for being unclear. I know where the ufile and the fd file came from. For any of the settings in the user file you will be able to point a session that contains the information. My point is that some of the information in the ufile (like the derivation structure) is contained in other files as well. And, I assume if it is set in the user file (where it is also set somewhere else) there should be a posibillity to set things user specific, thus overruling the general settings.

To be absolutlely clear: I mean using sessions and not using editors to change the RDD files.

OmeLuuk,

I dont have any info yet on the VRC structure in the u<user-files>.

But here is more info about how and when the fd files are used.

This is from the release notes of the Porting Set - 7.3a.03

MaintReger: # 17888 (BDNT11170): Slow startup time of first session on Windows

Date: Tue, 8 Apr 2003 16:06:49 +0200

Created on: MaintCorelli
Type: bugfix

Problem Description (Customer terms)
Startup of session is slow, in spite of the fact that the tabledefinition files for that package combination are pre-loaded into the Baan Shared Memory.
Problem only applicable for Windows platform. Specially sessions, which needs a lot of tabledefinitions, are very slow. Because the tabledefinitions are pre-loaded into the Baan Shared Memory you should expect that also first time startup is fast.

For example: When you start session tdsls4101m000 for the first time, it takes about 15 seconds before the session is completely started and available.

Problem Description (Technical terms)
In case the bshell needs to obtain the tabledefinition info for the first time, an explode is done to determine the pathname.
E.g.: d:\baan\tools\dd\dttaad\dttaad200.

This explode reads the search path information from the fd file, to determine the location of the tabledefinition.
During this explode action, the physical file on disk is also opened to determine whether the file really exists. And this open action consumes a lot of time, specially on Windows. When a session needs a lot of tabledefinitions, the total time of all these open actions can become big: 10-20 seconds.

In case the file does also exists on disk, this pathname is taken to search in SHM. When found in SHM, the contents of the file itself are read from Shared Memory (SHM). (Unless the file is not in SHM, in that case the contents will still be read from disk) .

Workaround
There is no workaround for this issue.

Test Procedure
On a Windows platform:
1. Take care that all tabledefinitions are pre-loaded into Baan Shared Memory for the package combination you are working in.
2. Fill in the following in the BW Command field: -- -dbgsrdduse -dbgfdev -logfile trace_shm -keeplog tdsls4101m000
3. Start BW, when session tdsls4101m000 is started, close the session window again and log out of Baan
4. View the file trace_shm (created in BSE_TMP directory).
5. It should show you for example:

_explode : (d:/baan4c/tools/dd/dttgfd/dttgfd303)
explode: F_BRDD:dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303
get_explode_fname(d:/baan4c/tools/dd/dttgfd/dttgfd303)
Table dump d:/baan4c/tools/dd/dttgfd/dttgfd303 load from srdd (no disk check done)

And there should be no "sopen" for the tabledefinitions, which are in Shared Memory.

6. Now do the same test, but then take care that the all the tabledefinitions are NOT pre-loaded into the Baan Shared Memory.
7. View the trace file, and it should show you now for example:

_explode : (d:/baan4c/tools/dd/dttgfd/dttgfd303)
explode: F_BRDD:dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303
get_explode_fname(d:/baan4c/tools/dd/dttgfd/dttgfd303)
Table dump d:/baan4c/tools/dd/dttgfd/dttgfd303 load from disk
_explode : (d:/baan4c/tools/dd/dttgfd/dttgfd303)
explode: F_BRDD:dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303, d:/baan4c/tools/dd/dttgfd/dttgfd303
open(d:/baan4c/tools/dd/dttgfd/dttgfd303), fd 5 errno 0
sopen(d:/baan4c/tools/dd/dttgfd/dttgfd303) 0x52f388

Now, there are "sopen" for the tabledef's which are loaded from disk.

Beside this test procedure you can also test using an old bshell (not containing this fix), and a new one.
My test showed out, when using the old bshell, the startup time was 17 seconds, and when using the new one, the startup time was about 2 seconds.

Motive source
DF:213234

Congrats with your number of posts... 1000!

I know what the fd file is used for. I do not know what the VRC paths in the u-file are used for.

Well, it should be easy to find out: delete those lines, and try to start ba/bw/bx, maybe with some logging turned on. That should show fast enough what the lines are used for!

Happy hacking! :D

Nico

My guess is it is used to pick up the correct object in VRC path of the user. When user is executing the perticular session, the relevant object is located using this path.

-- Avinash

No, that is where the fd file is used for.

Note that the notation is only "metalanguage", not directory structure like as in the fd file.

It is a bit like the meta-derivation structure in the report of ttstpsessinfo, but when the ufile does not contain the part, then still ttstpsessinfo shows the meta derivation structure.

Maybe something to do with finding objects in shared memory? Meaning, when starting up, it first checks whether the necessary object (with the correct VRC derivative) is already sitting in shared memory before going off and reading the fd file to read it from disk?

Just guessing!
Nico

The problem with loggin and tracing is that you can tell the file is being read, but you cannot tell what information from what file is used in what moment in time.

I think the fd file is used to reads stuff from disk like objects, reports, forms etc. and the vrc_path is used databse stuff like messages, labels etc.

Hope this helps,
Dick

Dikkie,

If so, then why set in the u-file of the user? Because VRC path is user specific? Because VRC path is language dependent? imho: no.

If so, then why set in the u-file of the user?

Probably for performance reasons!

If not, why convert anything to runtime? If you want to have the easiest setup, it would be enough to convert only the database information, and the rest could be read from the tools tables. But, and Baan realised this early in the development cycle, it is better to save some information outside the database, and gain performance!

So, back to the u-files: if Dick is right, fetching labels/messages now boils down to a single query on a single table, and the label/message is retrieved. Otherwise it would cost a couple of joins: user->package combination->VRC's->labels/messages.

Indeed, what Nico mentioned, it is all about performance. In the fd file it shows a path to the place, so that can't be used for messages etc. And the other way around also would require more database access.

Hope this helps,
Dick

But why it is chosen to put it in the ufiles... This is a lot of redunancy while it is not user related. This means a contamination of ufiles with fd information.