Sponsored Content
The Lounge What is on Your Mind? Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations Post 303045633 by Neo on Sunday 5th of April 2020 03:16:55 AM
Old 04-05-2020
Update (from one hour ago):


Updated the new community sites with latest posts, new users, likes, etc. from legacy site.

Ran an early preprocessing script against the legacy DB.

@Scrutinizer is testing a more refined version of preprocessing which will do even more migration magic. When he is ready, we will run his preprocessing script again the legacy DB and see how it looks.

Thanks for your patience.

We have already fixed the two bugs that we found in the initial launch; but are working to refine more custom bbcode issues.
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Shell Script migration issues

Hi All, We will be doing a Solaris 8 to Solaris 10 migration migration, just wanted to know if there are any known / common issues arise from this migration from Shell script point of view. I tried searching this site but mostly post are related to SA's question and jumpstart, etc. If there's... (4 Replies)
Discussion started by: arvindcgi
4 Replies

2. HP-UX

Migration - Compiler Issues.

All, We are migrating an application from HP-UX B.11.00 to HP-UX B.11.31 and both of them have the same informix version - 7.25se. However the compilers are different on both servers. HP-UX B.11.00 - has B3913DB C.03.33 HP aC++ Compiler (S800) HP-UX B.11.31 - has PHSS_40631 1.0 HP C/aC++... (2 Replies)
Discussion started by: helper
2 Replies

3. Programming

How to track table status delete/update/insert status in DB2 V10 z/os?

Dear Team I am using DB2 v10 z/os database . Need expert guidance to figure out best way to track table activities ( Ex Delete, Insert,Update ) Scenario We have a table which is critical and many developer/testing team access on daily basis . We had instance where some deleted... (1 Reply)
Discussion started by: Perlbaby
1 Replies

4. What is on Your Mind?

Status of Migration of Moderation Systems

First a bit of history .... A number of years ago one of our admins built a number of plugin systems for moderation, including (1) a voting system, (2) a "user feelings" system and (3) a confidential posting system. During this time, I was busy on other projects, not very active in the forums,... (1 Reply)
Discussion started by: Neo
1 Replies

5. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Two

OK. Like we all do, we learn a lot from tests, test migrations, and so forth. Today, I started from scratch on test migration 2, armed with a lot more knowledge, The main differences are as follows: Installed discourse plugin ruby-bbcode-to-md before starting the install Modified... (30 Replies)
Discussion started by: Neo
30 Replies

6. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Four

Test Build 4 on New Server, with changes identified in discourse test builds 2 and 3, primarily: Insuring ruby-bbcode-to-markdown is enabled. Removing line breaks from ICODE to markdown in migration script. Added vbpostid to posts in discourse to setup migrating vb "thanks" to discourse... (28 Replies)
Discussion started by: Neo
28 Replies
numa_sched_launch(5)						File Formats Manual					      numa_sched_launch(5)

NAME
numa_sched_launch - change process default launch policy VALUES
Failsafe Default Allowed values Recommended values unless the application requires explicit different behavior. DESCRIPTION
The dynamic tunable controls the default launch policy for newly created processes. The process launch policy controls the initial place- ment of the child process at creation time. The scheduler can migrate threads from one locality domain (LDOM) to another to distribute workload for better throughput and responsiveness. The default launch policy is applicable only to processes that have no explicit launch policy, processor binding, or LDOM binding applied to them (see mpctl(2) for details). There are three possible values of this tunable: This value explicitly disables any change in the default launch policy for processes irrespective of the system configuration. A newly created process will be placed using the legacy default launch policy. This is the default and recommended value. HP-UX will autosense the right policy setting based on system configuration. This policy directs HP-UX to optimize the launch policy for multi-process applications that share data. Such applications can get better performance when the applications are packed together in the same LDOM. The policy will cause child processes created using to be placed in the same locality domain as the parent process. Note that a different default launch policy may be used in the future with new system configurations for improved application performance when this tunable is enabled. Processes created using will be treated as if they are a new application and will continue to be launched using the legacy default launch policy. This value explicitly enables the new default launch policy for processes. A process created using is placed in the same locality domain as its parent process irrespective of the system configuration. Who Is Expected to Change This Tunable? System administrators who prefer to explicitly control the default launch policy for applications even when LORA (Locality Optimized Resource Alignment) mode is enabled (see numa_policy(5) for details). Restrictions on Changing The tunable changes take effect immediately. However, changes to this tunable will not affect processes that are already created. Such processes will need to be stopped and restarted to be launched with a modified tunable setting. When Should the Value of This Tunable Be Changed to 0? The value of should be set to to preserve the legacy process default launch policy even when the system is configured in LORA mode. When Should the Value of This Tunable Be Changed to 1? The value of should be set to to improve the performance of multi-process applications. When Should the Value of This Tunable Be Changed to 2? The value of should be set to when a multi-process application is likely to see improved performance even if the system is not configured for LORA mode. What Are the Side Effects of Changing the Value? The distribution of CPU utilization across the system will change. This situation can result in a change in performance. The change in performance is highly dependent on the workload and the partition configuration. What Other Tunable Values Should Be Changed at the Same Time? None. WARNINGS
All HP-UX kernel tunable parameters are release specific. This parameter may be removed or have its meaning changed in future releases of HP-UX. Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation, some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tun- able values, consult the documentation for the kernel software being installed. For information about optional kernel software that was factory installed on your system, see at AUTHOR
was developed by HP. SEE ALSO
fork(2), mpctl(2), vfork(2), numa_policy(5). Tunable Kernel Parameters numa_sched_launch(5)
All times are GMT -4. The time now is 03:05 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy