Current execution system of labview 8.20

What is the Current execution system of labview 8.20

Hi,
I presume you mean how LabVIEW executes the code in your block diagram? You can see this happen using the "Highlight Execution" button located next to the run, run continuously and abort buttons.
Thanks,
CLA | LabVIEW 7.1... 2013
www.renishaw.com

Similar Messages

Is this roughly how the labVIEW Execution Systems work?

I've not taken a class in OS design, so I don't know the strategies used to implement multitasking, preemptive or cooperative. The description below is a rough guess.
LabVIEW compiles Vis to execute within its own multitasking execution environment. This execution environment is composed of 6 execution systems. Each execution system has 5 priority queues (say priorities 0->4). Vis are compiled to one or more tasks which are posted for execution in these queues.
An execution system may either have multiple threads assigned to execute tasks from each priority queue, or may have a single thread executing all tasks from all priority queues. The thread priorities associated with a multithreaded execution system are assigned according to the queue that they service. There are therefore 5 available thread priority levels, one for each of the 5 priority level queues.
In addition to the execution queues, there are additional queues that are associated with tasks suspended in various wait states. (I don't know whether there are also threads associated with these queues. It seems there is.)
According to app. note 114, the default execution environment provides 1 execution system with 1 thread having a priority level of 1, and 5 execution systems with 10 prioritized threads, 2 threads per priority queue. NI has titled the single threaded execution system "user interface" and also given names to the other 5. Here they will be called either "user interface" or "other".
The "user interface" system is responsible for all GUI actions. It monitors the keyboard and mouse, as well as drawing the controls. It is also used to execute non-thread-safe tasks; tasks whose shared objects are not thread mutex protected.
Vis are composed of a front panel and diagram. The front panel provides an interface between the vi diagram, the user, and the calling vi. The diagram provides programmatic data flow between various nodes and is compiled into one or more machine coded tasks. In addition to it own tasks, a diagram may also call other vis. A vi that calls another vi does not actually programmatically branch to that vi. Rather, in most cases the call to another vi posts the tasks associated with the subvi to the back of one of the labVIEW execution system�s queues.
If a vi is non-reentrant, its tasks cannot run simultaneously on multiple threads. This implies a mutex like construction around the vi call to insure only one execution system is executing the vi. It doesn�t really matter where or how this happens, but somehow labVIEW has to protect an asynchronous vi from simultaneous execution, somehow that has to be performed without blocking an execution queue, and somehow a mutex suspended vi has to be returned to the execution queue when the mutex is freed. I assume this to be a strictly labVIEW mutex and does not involve the OS. If a vi is reentrant, it can be posted/ran multiple times simultaneously. If a vi is a subroutine, its task (I think there is always only one) will be posted to the front of the caller's queue rather than at the back of the queue (It actually probably never gets posted but is simply mutex tested at the call.) A reentrant-subroutine vi may be directly linked to its caller since it has no restrictions. (Whether in fact labVIEW does this, I don�t know. In any event, it would seem in general vis that can be identified as reentrant should be specified as such to avoid the overhead of mutexing. This would include vis that wrap reentrant dll calls.)
The execution queue to which a vi's tasks are posted depends upon the vi execution settings and the caller's execution priority. If the caller's execution priority is less than or equal the callee's execution settings, then the callee's tasks are posted to the back of the callee's specified execution queue. If the caller's execution priority is greater than the callee's specifications, then the callee's tasks are posted to the back of the caller's queue. Under most conditions, the vi execution setting is set to "same as caller" in which case the callee�s tasks are always posted to the back of the caller's execution queue. This applies to cases where two vis are set to run either in the other execution systems or two vis are set to run in the user interface execution system. (It�s not clear what happens when one vi is in the �user interface� system and the other is not. If the rule is followed by thread priority, any background tasks in the �other� systems will be moved to the user interface system. Normal task in the �other� systems called by a vi in the �user interface� system will execute in their own systems and vice versa. And �user interface� vis will execute in the caller�s �other� system if the caller has a priority greater than normal.)
Additionally, certain nodes must execute in the "user interface" execution system because their operations are not thread-safe. While the above generally specifies where a task will begin and end execution, a non-thread safe node can move a task to the �user interface� system. The task will continue to execute there until some unspecified event moves it back to its original execution system. Note, other task associated to the vi will be unaffected and will continue to execute in the original system.
Normally, tasks associated with a diagram run in one of the �other� execution systems. The tasks associated with drawing the front panel and monitoring user input always execute in the user interface execution system. Changes made by a diagram to it own front panel are buffered (the diagram has its own copy of the data, the front panel has its own copy of the data, and there seems to be some kind of exchange buffer that is mutexed), and the front panel update is posted as a task to the user interface execution system. Front panel objects also have the advanced option of being updated sequentially; presumably this means the diagram task that modifies the front panel will be moved to the user interface execution system as well. What this does to the data exchanged configuration between the front panel and diagram is unclear as presumably both the front panel and diagram are executing in the same thread and the mutex and buffer would seem to be redundant. While the above is true for a control value it is not clear whether this is also true for the control properties. Since a referenced property node can only occur on the local diagram, it is not clear it forces the local diagram to execute in the user interface system or whether they too are buffered and mutexed with the front panel.
If I were to hazard a guess, I would say that only the control values are buffered and mutexed. The control properties belong exclusively to the front panel and any changes made to them require execution in the �user interface� system. If diagram merely reads them, it probably doesn�t suffer a context switch.
Other vis can also modify the data structure defining the control appearance and values remotely using un-reference property nodes. These nodes are required to run in the user interface system because the operation is not thread-safe and apparently the diagram-front-panel mutex is specifically between the user interface execution system and the local diagram thread. Relative to the local diagram, remote changes by other vis would appear to be user entries.
It is not clear how front panels work with reentrant vis. Apparently every instance gets its own copy of the front panel values. If all front panel data structures were unique to an instance, and if I could get a vi reference to an instance of a reentrant vi, I could open multiple front panels, each displaying its own unique data. It might be handy, sort of like opening multiple Word documents, but I don�t think that it�s available.
A note: It is said that the front panel data is not loaded unless the front panel is opened. Obviously the attributes required to draw an object are not required, nor the buffer that interfaces with the user. This rule doesn�t apply though that if property references are made to front panel objects, and/or local variables are used. In those cases at least part of the front panel data has to be present. Furthermore, since all data is available via a control reference, if used, the control�s entire data structure must be present.
I use the vi server but haven�t really explored it yet, nor vi reference nodes, but obviously they too make modifications to unique data structures and hence are not thread-safe. And in general, any node that accesses a shared object is required to run in the user interface thread to protect the data associated with the object. LabVIEW, does not generally create OS level thread mutexes to protect objects probably because it becomes to cumbersome... Only a guess...
Considering the extra overhead of dealing with preemptive threading, I�m wondering if my well-tuned single threaded application in LV4.1 won�t out perform my well-tuned multithreaded application in LV6.0, given a single processor environment�
Please modify those parts that require it.
Thanks�
Kind Regards,
Eric

Ben,
There are two types of memory which would be of concern. There is temporary and persistent. Generally, if a reentrant vi has persistent memory requirements, then it is being used specifically to retain those values at every instance. More generally, reentrant code requires no persistent memory. It is passed all the information it needs to perform its function, and nothing is retained. For this type of reentrant vi, memory concern to which you refer could become important if the vis are using several MBytes of temporary storage for intermediate results. In that case, as you could have several copies executing at once, your temporary storage requirements have multiplied by the number of simultaneous copies executing. Your max memory use is going to rise, and as labview allocates memory rather independently and freely, the memory use of making them reentrant might be a bit of a surprise.
On the other hand, the whole idea of preemtive threading is to give those tasks which require execution in a timely fashion the ability to do so regardless of what other tasks might be doing. We are, after all, suffering the computational overhead of multithreading to accomplish this. If memory requirements are going to defeat the original objective, then we really are traversing a circle.
Anyway, as Greg has advised, threads are supposed to be used judiciously. It isn't as though your going to have all 51 threads up at the same time. In general I think, overall coding stategy should be to minimize the number of threads while protecting those tasks that absolutely require timely execution.
In that sense, it would have been nice if NI had retained two single threaded systems, one for the GUI and one for the GUI interface diagrams. I've noticed that control drawing is somewhat slower under LV6.0 than LV4.1. I cannot, for example, make a spreadsheet scroll smoothly anymore, even using buffered graphics. This makes me wonder how many of my open front panel diagrams are actually running on the GUI thread.
And, I wonder if threads go to sleep when not in use, for example, on a wait, or wait multiple node. My high priority thread doesn't do a lot of work, but the work that it does is critical. I don't know what it's doing the rest of the time. From some of Greg's comments, my impression is it in some kind of idle mode: waking up and sleeping, waking up and sleeping,..., waking up, doing something and sleeping... etc. I suppose I should try to test this.
Anyway that's all an aside...
With regard to memory, your right, there are no free lunches... Thanks for reminding me. If I try this, I might be dismayed by the additional memory use, but I won't be shocked.
Kind Regards,
Eric

Preferred execution system

What is the exact meaning of:
User interface (I know)
Standard ?
Instrument IO ?
Data acquisition ?
Other 1 ???
Other 2 ???
Same as caller (I know)
I know that it also depend on if your computer is a Single or Dual Processor
Thanks!
Nitrof

> Greg McKaskle has written several good answers about execution systems:
>
> http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101...http://exchange.ni.com has been obsoleted by http://forums.ni.com/ni/ . I'm not sure how to find those three documents, but I found the following...
1999: priority of VIs
http://forums.ni.com/ni/board/message?board.id=170&message.id=5587
2001: Need some clarification on Execution Systems, Priorities, and threads with Labview on Windows NT
http://forums.ni.com/ni/board/message?board.id=170&thread.id=11944
2002: Multithreading in LabView loops doesn't work?
http://forums.ni.com/ni/board/message?board.id=170&message.id=23498&requireLogin=False
2002: best way to do parallel activities
http://forums.ni.com/ni/board/message?board.id=170&thread.id=24932
2003: Is this roughly how the labVIEW Execution Systems work?
http://forums.ni.com/ni/board/message?board.id=170&thread.id=45194
Is there anything more current?

Test System Engineer / LabVIEW Developer

As a member of the Nexjen Systems team, the Test System Engineer / LabVIEW Developer performs engineering design, software development and hardware specification for custom test & measurement systems.
Nexjen Systems offers a challenging environment where you can:
Develop your Engineering, Design and Software Development skills.
Refine your communication skills through direct client interaction.
Take responsibility for highly technical projects, with mentoring from experienced engineers.
Add significant value to clients’ product development and engineering efforts.
Nexjen Systems is a premier integrator of LabVIEW-based, automated test & measurement systems. We pride ourselves on providing a very high level of technical value to our clients through a range of services focused on test system engineering, construction and deployment. Nexjen Systems is located in Charlotte, our clients are located around the world. Learn more at www.nexjen.com .
Position Requirements
Engineering Degree (Electrical, Computer or Mechanical preferably).
3-5 Years LabVIEW and/or TestStand Development Experience.
3-5 Years Automated Test Equipment Design or Test Engineering Experience.
Desire to grow as an Engineer/Developer in a challenging technical environment.
PLEASE EMAIL RESUME' TO [email protected]

It would appear at their headquarters in Charlotte, North Carolina, USA
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Systems Engineer(LabVIEW)

Excellent opportunity for Systems Engineer(LabVIEW)
Locationheffield
Salary:£30 to £37k per annum
Austin Consultants are a National Instruments Alliance Partner and have been the UKs highest certified LabVIEW Consultants for three of the last four years. We are an elite team of LabVIEW Engineering professionals and software programmers working across multiple industries with a passion for problem solving and being at the forefront of technology.
We are currently looking for a LabVIEW Systems Engineer to join our dynamic and expanding team in our northern office based in the heart of Sheffield . As a Systems Engineer, you'll be part of a team that is responsible for developing both hardware and software applications based on Object Oriented Technology and Event based Architectures primarily in the LabVIEW Programming Language and on the National Instruments Hardware Platforms.
Key Skills
Qualifications & Requirements:
◦ Minimum of 3 continuous year’s practical experience in instrumentation & control, industrial automation and ATE is required.
◦ Minimum 2.1 honours degree in engineering or science related field,
◦ Minimum of LabVIEW qualification of Certified LabVIEW Developer or equivalent.
◦ Firm knowledge and experience of National Instruments embedded systems, including LabVIEW FPGA and LabVIEW Real Time.
◦ Understanding and practical experience of object oriented principles.
◦ Experience with all National Instruments hardware platforms, including DAQmx, cRIO, PXI,
◦ Practical electrical debug experience.
◦ Experience in a second language of JAVA, C and C++ is preferred but not essential.
◦ Ability to learn new skills/languages/applications quickly (MATLAB, JavaScript, STK, etc.).
◦ Must be able to handle multiple tasks and enjoy working with people.
◦ Strong problem solving skills
◦ Excellent communication skill
◦ A proactive/can do attitude
◦ Legal right to live and work in the UK. Sponsorship is not available.
◦ Must hold a full clean and valid UK driving license and be flexible to travel throughout UK.
Key Responsibilities:
The duties and responsibilities of this position include, but are not limited to, interacting directly with customers to program, train, inform, advise and consult in the design of their applications using the best test and measurement hardware and software by:
◦ Programming memory and speed efficient applications using LabVIEW and Object Oriented Programming and Event-based architectures.
◦ Developing intuitive GUIs.
◦ Selecting the correct measurement hardware for a given application based on a customer’s specification.
◦ Providing timely, accurate and effective solutions to technical problems.
◦ Providing guidance on the installation and working functionality of both software and hardware, including explanation of configuration settings.
◦Remaining aware of all competitive products and how they compare technically with Austin Consultants' core products.
◦ Working with the business development team to develop proof of concepts for customers.
◦ Must be available and happy to travel and work on customer sites around the UK.
Kindly send us your updated CV or call us for confidential chat regarding the opportunity.
Mathi Narayanaswamy
Resource Consultant
(LabVIEW, TestStand, VeriStand, VISION and other NI technologies)
Austin Resourcing (Division of Austin Consultants, National instruments Silver Alliance Partner)
Studio 41, Clink Street Studios
Clink Street
London
SE1 9DG
Tel: 0800 772 0795
Mobile: 07809344621
Email:[email protected]
www.austinresourcing.co.uk
LinkedIn: uk.linkedin.com/in/austinresourcing
Twitter: www.twitter.com/austinrecruit
Austin Consultants are the highest certified LabVIEW Consultancy in the UK. Visit them at www.AustinConsultants.co.uk
Come and Visit Austin Resourcing's Stand at NI Day on Nov 4th ,2014

Hello Fred,
Can you please tell me if Indian citizen can apply for this position. I have a graduate degree from US and have the work permit to work anywhere in US. So can I apply?
Thank you.
-Ujwal

What's the best Preferred Execution System setting for parallel testing run from TestStand

I configured what vi's I think need to be reentrant, but I am not sure what choice for "Preferred Execution System" is best for the vi's in my TestStand sequence that's going to run in parallel. Can anyone advise?
Thanks!

Hi mike_22,
This option should not matter unless you have a LabVIEW VI with parallel code blocks. If this is the case, you can set your VI to Other 1 or Other 2. Please take a look at this knowledgebase for further explanation.
Cheers,
Kelly R.
Applications Engineer
National Instruments

Execution system differs between VI properties and Execution Trace Toolkit

I have a time critical acquisition VI whose execution system is set to "E/S d'instruments" (instrument IO). When I dump the execution trace in the execution trace toolkit it appears as "LabVIEW Thread [Standard]". Moreover there is a second line with the same thread name. Is this just a confusing bug or does it reflect a possible conflict in my program ?
Thanks in advance.
Gael.
Additionnal information : I am working on FP-2015.

Gael,
I made my top-level VI run at normal priority in the "same as caller" execution system, and my subVI run at time critical priority in the "instr I/O" execution system. The trace (attached) showed correct behavior.
There are a few things to try. First make a backup of your application. Try removing the storage management subVI assigned to "other 1". You should now have a top-level VI running at normal priority in the same as caller exec system and a subVI running at time-critical in the instr I/O exec system (same as my setup).
If you still get the weird behavior, we might be able to isolate the behavior to a subVI you're calling inside the time-critical VI. Try removing one subVI at a time and collect a tra
ce each time.
Alternatively, you can start with my simply VIs and slowly add components from your application until you see the weird behavior.
I should remark that when you assign a VI to run at time-critical priority, that VI gets its own thread, even if the VI is set to run in the "same as caller" execution system. So even if your time-critical VI is not adhering to its assigned execution system, it's still running in its own time-critical priority thread (shown as red in the trace tool).
Attachments:
topVI_sameascaller_subVI_intrIO_timecritical.bmp ‏2089 KB
instr_io.vi ‏19 KB
sub_instr_io.vi ‏20 KB

Execution tracer idea - labview

Hi, I have been working with labview for the past month with hardware
and software.
I was wondering if there is a way to see the order of
execution of the vi....It would be nice to see on the block diagram a
trace system or numbering scheme or drop down flow that tells the order of
operation...I think this is all done behind the scenes in labview..It might
be nice to have a trace or label..maybe this exists..I am getting
the book for scientist(s) and engineers...so maybe it is there..any help..
FOR simple programs its not an issue....I have seen some complex vi's!!
I guess I am use to the old C programming...line by line..
maybe with time?
J
Solved!
Go to Solution.

NitinD wrote:
Alternatively, help yourself by creating a simple "Log results VI" that is connected after every major operation you are doing. LabVIEW essentially divides the codes in clumps, if you can figure out what clumps LV is dividing your code into, probably your job will be easier.
But I don't see how knowing the order of execution will help you. Even LabVIEW doesn't know it before hand. If your code is so execution-dependent perhaps you should use Frame Structures, that force sequential execution.
Actually LabVIEW knows it pretty well, but things like timers, delays and such can and will change the execution order between successive runs sometimes.
Also it is quite useless information to debug an application, because if the execution order of nodes matters in a program you have to force it (dataflow) or you will have a potential race condition, that can and will expose itself at the latest at the moment your application is installed at the other side of the globe and with no internet connection available to even attempt to do remote debugging.
Just learn to live with it and use its advantages. It is not hard to do correct code. Things like global variables and local variables are an ideal way to cause race condition so if you make it for yourself to a rule to never use them unless you have thought at least twice why they are necessary and how to make sure you have no race condition there, then you are already set for at least 50%.
You can have race conditions too in C, but there you have to explicitedly write multithreading code, which is kind of hard and therefore is only done when absolutley needed and usually by people who understand exactly what the implications are, and if they don't, they learn it fast during development, or abandon the project sooner than later.
Rolf Kalbermatter
Message Edited by rolfk on 08-30-2009 09:12 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Configure the priority/execution system of Sub-VIs

Hi,
I wonder if it is possible to configure a VI to run with different priorities or in different execution systems when called on different occations. It seems to me that the only way to influence this is by changing the properties of a VI and then saving it. That would leave me having n just slightly different VIs for n settings.
Sören

Hello,
VI server exposes properties which allow you to change the priority and execution of a VI dynamically. However, these properties cannot be set while the VI is running, and therefore a VI cannot set its own priority or execution system. This means that you have to use a plug-in architecture (dynamically called VIs) in order to dynamically choose the priority and execution system of VIs. I've attached a short example written in LV 7.1. If you are unfamiliar with VI server or dynamically calling VIs, the LabVIEW Intermediate II course covers these topics and I'm sure there is also plenty of good content on these forums and in the developer zone.
Regards,
Ryan K.
Note: You should be careful when adjusting the priorities and execution systems on a VI, as you can often end up with undesired results due to priority inversion.
Attachments:
Priority Demo.zip ‏20 KB

Can I find the OS of a remote system using LabVIEW?

I wish to be able to start an application on a remote system using
LabVIEW. To do this, I need to know what the OS of the remote system is
(Windows, Linux, etc). I can ask the user to provide this information
for me, but is there any way I can get LabVIEW to automatically
retrieve this information? I know I can use the application node with
the OS sub-section to get this information for the local machine... is
there any way I can remotely run this? Would VI server allow me to run
this, if I turned it into a VI, on the remote system such that I could
retrieve this information for the remote system? Or is there a neater
solution I'm missing?
Cheers,
M.J.

Heya... many thanks for the suggestion(s).
The problem with my case is there's any number of users on the network
that might be using this, and it could be running on a Windows or Linux
box, depending on user circumstances, so trying to get a VI Starter
type application put into the start-up of all machines just in case is
a) overkill & b) more than I want to bite off So basically I
need to have the VI running on the machine in order to use VI server is
what I'm hearing & reading from the help, which essentially my idea
of dynamically firing off labview & loading/running any VI on the
remote system just ain't possible... hmmmn.
Back to the drawing board then, it looks like...
Cheers,
M.J.

Using bootcamp was installing windows xp, at the select ntfs or fat format selected "leave the current file system intact." How can that be changed to a correct choice. Mac side opens correctly. Windows shows disk error.

using bootcamp, was installing windows xp, at the select ntfs or fat format mistakenly selected "leave the current file system intact." How can that be changed to a correct choice. Mac side opens correctly. Windows shows disk error. and doesn't respond to press any key. When looking in the startup disk section, windows on boot camp can be seen, but not selected. (13"MacBook Pro 10.6.8)

Have a read here http://support.apple.com/kb/TS1722 for solution.
Stefan

How to get the current logical system?

Dear Abapers:
I can't find the logical system value from the table SYST, pls tell me how to get the current logical system name, Thanks!

Hi,
Check with the table T000, the Logical system field name is LOGSYS.
Regards
Thiru

Two SNC system and one execution system

Hi Experts
Can there be possibilty of Two snc system to co exist with one execution system ECC?
IF yes can you folks please throw some light on the same?
This situation is arising because:
the Lime table in the existing system has really grown huge and the archiving is not helping becuase there are new records that are added to the system every day which are more than the archiving records
because of this huge data the upgrade is not possible and we are planning for a new setup, now to mitigate the risk we were tryin if two SNC system can coexist with one EEC system.
Now to add to the problem is there are certain business scenarios because of which we need to put in data in lime table every day
so reduction in data input is not possible.
As the data in LIME is only stock of the customer coming every day and if we just transaction data , even if we go away with all the data is not an issue with us as customer reports his existing stock on daily basis to us.
We have even thought of truncating all the tables available in in lime objects in SARA, we are thinking of this becuase system might act erratic when we setup new system and slow try moving few customer from existing to new system. as a pilot.
Supposing if we go ahead with it ,wht could be the issues ?
Thanks for all your help and suggestions
Regards
Manas Malhotra

Hi Manas
Two SNC systems can coexist together.
You need to define seperate Business System Groups,RFC settings,Logical System definition
Also you need to have seperate Identification for your master data, create your own definition in BADI
Example:If you are sending same material XXX to two SCM systems how to diferrentiate ???
Because BADi methods EXIT_/SAPAPO/SAPLCIF_LOC_001 & EXIT_/SAPAPO/SAPLCIF_PROD_001
differentiate when two ERP systems are connected to one SNC system by prefix and sufix, now you need to have your own code to differentiate
Also big time care should be taken in defining the distrubution models (bd64) and even in XI/PI like
Example: we have two TM systems coexisting with one ERP, so we used conditoned based mapping
Itu2019s a condition based mapping.
1) When TransportationRequestSUITERequest/TransportationRequest/ShipToLocation/InternalID = BP1 or BP2 or BP3 u2026 the receiver is I5YCLNT100
2) When TransportationRequestSUITERequest/TransportationRequest/ShipToLocation/InternalID = BP4 or BP5u2026the Receiver is I5XCLNT100.
Also care should be taken on master data/FICO settings which both systems use in common. like using Ztypes instead of using standard one like order type, message type. It should be easy when you troubleshoot back!!!
The inbound message parameters should be taken care w.r.t business needs
Good to have a matrix mapping like what business process coexit in both systems and which doesnot and then try to see what settings need to be tailored???
Best Regards
Vinod

How to cooperate the current mail system with Sun Java Commnication Suite 5

Dear all and Shane,
Excuse me for bothering you again.
Due to time limited, I would like to know how to cooperate the current mail system with Sun Java Commnication Suite 5. I mean I would like to use current mail system (mailscanner + postfix + courier-IMAP + clamav + spamassassin + webmail) and use the outlook connector to connect to Sun Java COMMS 5 to share the calendar, contacts only.
Right now I have done the testing by using outlook, mac mail, thunderbird to share calendar,contacts via Sun Java COMMS 5 in Centos Linux 5.
My plan is as following
1. Sun Java Communication suites 5 server ( I called it comms5 ) will be in DMZ zone and will open the necessary ports in firewall.
2. I will create more than six sub domain name in Sun Delegate server and the necessary accounts within these domain names.
3. All messages will be transmitted via Postfix and clients will retrieve from Courier-IMAP
4. All Clients included other branch offices will use different mail clients to share their calendars, contacts via COMMS5 ( But how will COMMS handle the messages such like invitation ? )
Any suggestions will appreciate.
PS: Is it possible to classify the contacts in outlook address book ?
For example, when user click the receiver, it will show like as following
GLOBAL ADDRESS BOOK
--Director
--and so on
----CN.BRANCH OFFICE
-----------CN01 EMAIL ADDRESS
-----------CN02 EMAIL ADDRESS
-----------CN03 EMAIL ADDRESS
and so on
----JP.BRANCH OFFICE
-----------JP01 EMAIL ADDRESS
-----------JP02 EMAIL ADDRESS
-----------JP03 EMAIL ADDRESS
and so on
----TW.BRANCH OFFICE
and Due to the user account is located in CN.BRANCH OFFICE, it will extend the CN.BRANCH OFFICE contacts level.
Excuse me for bad English, hope you can understand it.
Best Regards,
Bruce

Dogz wrote:
Due to time limited, I would like to know how to cooperate the current mail system with Sun Java Commnication Suite 5.
I mean I would like to use current mail system (mailscanner + postfix + courier-IMAP + clamav + spamassassin + webmail) and use the outlook connector to connect to Sun Java COMMS 5 to share the calendar, contacts only.Getting your current mail system to 'co-operate' in this way will require more time then simply migrating the accounts of users on the current mail system to the comm-suite-5 installation and making use of UWC for Webmail access and ClamAV/SpamAssassin integration within the messaging MTA.
Also the use of Outlook Connector with a non-Sun IMAP backend isn't supported, nor is the use of a non-Sun IMAP backend possible with UWC.
Right now I have done the testing by using outlook, mac mail, thunderbird to share calendar,contacts via Sun Java COMMS 5 in Centos Linux 5. Once again I should remind you that CentOS is not a supported platform for comm-suite-5
Regards,
Shane.

I am currently running System Version:Mac OS X 10.6.8 (10K549) on a Macbookpro2,2. Is there any way I can upgrade to Yosemite?

I am currently running System Version:Mac OS X 10.6.8 (10K549) on a Macbookpro2,2
Is there any way I can upgrade to Yosemite? The App Store download says that they are unable to upgrade my system.

No. Your computer can’t be upgraded past Lion 10.7.5.
(118401)

Current execution system of labview 8.20

Similar Messages

Maybe you are looking for