HELPINFO FOR SESSION TTCOR9210M000
==================================

AIM OF THE SESSION:
In the past period many objects in update VRCs for B40_c4 extensions
have been delivered through PMC (either as an individual solution or
through a Service Pack). These objects were purely standard and should
not exist in the update VRCs for extensions. For newer solutions, these
objects were no longer created in update VRCs for extensions, so that an
old version of the object was in the update VRC for extensions. As the
objects in the update VRC for extensions have a higher execution
priority than the objects in the update VRC for standard, new fixes no
longer work (not all fixes have this problem, but some have it).
This session can be used to delete the unneeded objects from the update
VRCs for B40_c4 extensions. Besides deleting the objects it will print a
report of the objects and it has an option to update the PMC registry.

HOW TO USE THE SESSION:
The User enters a range of packages and program objects and the VRC
wherein the session has to be executed. The VRC can be entered only
once, it is not possible to enter a range of VRCs. The session checks
if the VRC does exist as an Update VRC in PMC. If not, then the VRC is
not allowed. So there is no risk that this session is being executed in
a VRC that is not defined as an Update VRC in PMC. After the starting
the process, the session executes 2 steps:
"Repair Functions" and "Delete Objects" .

The first step Repair Functions reads the Objects that exist in the VRC
that is entered by the user (read table ttadv239). For each object the
session reads the used Functions (in table ttadv240) and it repairs the
VRC wherein the function is found on the user's system (functions are
stored in table ttadv260). The VRC code of the functions is often
incorrect after importing fixes (either PMC fixes or std.dmp fixes). So
in this step data is rewritten in table ttadv240 (where-used functions
by program object).

The second step Delete Objects again reads table ttadv239 and selects
the Objects that exist in the VRC that is entered by the user, but only
those objects wherefore the program script source is taken from another
VRC. For these objects the actual VRC of the source is determined (this
does also work if the customer does not have sourcecodes, VRCs of
sources are found in table ttadv230).  If the source belongs to the same
extension as the object (e.g. the object is in an Update VRC for cnt0
extension and the source is from a cnt0 extension VRC) the object will
not be deleted. If the source does not belong to the same extension as
the object (e.g. the object is in an Update VRC for cnt0 extension and
the source is is from a standard VRC), then the session reads table
ttadv240 (which was repaired in step 1) to find if any function is used
that belongs to the same extension as the object. If such a function is
found, then the object will not be deleted. If no function is found that
belongs to the same extension as the object, then the object does not
belong to the Update VRC wherein it exists and the object will be
renamed to <object>.save . So it is not physically deleted, but is moved
to another name, so that it is not activated anymore.

The field Update Mode can be used to print a report before actually
updating the database or deleting the objects. This field has following
options:
1. Step 1 (Repair Functions) is executed, but the database will not be
updated. Instead a report is printed with the functions wherefore the
VRC will be repaired.
2. Step 1 (Repair Functions) is executed and the database is updated for
this step. Step 2 (Delete Objects) is executed, but the database is not
updated for this second step. A report is printed with the updates that
were done for step 1 and additionally all objects are printed that will
be deleted (renamed).
3. Step 1 (Repair Functions) and step 2 (Delete Objects) are both
executed and a report is printed with the database updates and the
renamed objects.

The field Update PMC registry can be set to Yes or No. The PMC registry
stores all solutions for each update VRC. For each solution it has the
status, the components that are delivered in the solution and the
installation history.
No : the PMC registry is not updated at all. In this situation the PMC
registry represents components in the dumps that were delivered by Baan.
Yes: if an unneeded objects is deleted in Step 2, the session searches
for all installed solutions that contain the deleted component and it
deletes that component from the solution in the PMC registry. In this
situation the PMC registry represents the actual situation of the
objects in the filesystem, which can be different from the components
that Baan delivered in the dump.

The advice is to set this field to No.

If you want to set the field to Yes, please note following: each update
VRC is linked to a base VRC. This allows you to install solutions
multiple times, e.g. once in a test environment and once in the live
environment. You define 2 update VRCs (one for the test env. and one for
the live env.), both refer to the same base VRC. The PMC registry with
components by solution is stored at the level of base VRC. If you set
this field Update PMC registry to Yes, then components will be deleted
from solutions in the PMC registry at base VRC level. If you run this
session in your test VRC only and not in the live VRC, then the
components are no longer visible in the PMC registry at all (neither in
the test VRC, nor in the live VRC). Therefore you may set the field to
Yes only when executing the session in the last update VRC that belongs
to a certain base VRC.