Dealing with any clients in services is an art. In the case of IT, we primarily deal with American clients. It is useful to know how the English language works with them. Some of us mayhesitate to speak to the client.Beacuse we are not confident. When we practice the following tips, we can boost our confidence.
1. Do not write "the same" in an email - it makes little sense to them.
Example - I will try to organize the project artifacts and inform you of the same when it is done
This is somewhat an Indian construct. It is better written simply as:
I will try to organize the project artifacts and inform you when that is done
2. Do not write or say, "I have some doubts on this issue"
The term "Doubt" is used in the sense of doubting someone - we use this term because in Indian languages , the word for a "doubt" and a "question" is the same.
The correct usage (for clients) is:
I have a few questions on this issue
3. The term "regard" is not used much in American English. They usually do not say "regarding this issue" or "with regard to this".
Simply use, "about this issue".
4. Do not say "Pardon" when you want someone to repeat what they said. The word "Pardon" is unusual for them and is somewhat formal.
5. Americans do not understand most of the Indian accent immediately - They only understand 75% of what we speak and then interpret the rest. Therefore try not to use shortcut terms such as "Can't" or "Don't". Use the expanded "Cannot" or "Do not".
6. Do not use the term "screwed up" liberally. If a situation is not good, it is better to say, "The situation is messed up". Do not use words such as "shucks", or "pissed off".
7. As a general matter of form, Indians interrupt each other constantly in meetings - DO NOT interrupt a client when they are speaking. Over the phone, there could be delays - but wait for a short time before responding.
8. When explaining some complex issue, stop occasionally and ask "Does that make sense?". This is preferrable than "Do you understand me?"
9. In email communications, use proper punctuation. To explain something, without breaking your flow, use semicolons, hyphens or paranthesis.
As an example:
You have entered a new bug (the popup not showing up) in the defect tracking system; we could not reproduce it - although,
a screenshot would help.
Notice that a reference to the actual bug is added in paranthesis so that the sentence flow is not broken. Break a long sentence
using such punctuation.
10. In American English, a mail is a posted letter. An email is electronic mail. When you say
"I mailed the information to you"
, it means you sent an actual letter or package through the postal system.
The correct usage is:
"I emailed the information to you"
11. To "prepone" an appointment is an Indian usage. There is no actual word called prepone. You can "advance" an appointment.
12. In the term "N-tier Architecture" or "3-tier Architecture", the word "tier" is NOT pronounced as "Tire". I have seen many people pronounce it this way. The correct pronunciation is "tea-yar". The "ti" is pronounced as "tea".
13. The usages "September End", "Month End", "Day End" are not understood well by Americans. They use these as "End of September", "End of Month" or "End of Day".
14. Americans have weird conventions for time - when they say the time is "Quarter Of One", they mean the time is 1:15. Better to ask them the exact time.
15. Indians commonly use the terms "Today Evening", "Today Night". These are not correct; "Today" means "This Day" where the Day stands for Daytime. Therefore "Today Night" is confusing. The correct usages are: "This Evening", "Tonight".
That applies for "Yesterday Night" and "Yesterday Evening". The correct usages are: "Last Night" and "Last Evening".
16. When Americans want to know the time, it is usual for them to say, "Do you have the time?". Which makes no sense to an indian.
17. There is no word called "Updation". You update somebody. You wait for updates to happen to the database. Avoid saying "Updation".
18. When you talk with someone for the first time, refer to them as they refer to you - in America, the first conversation usually starts by using the first name. Therefore you can use the first name of a client. Do not say "Sir". Do not call women "Madam".
19. It is usual convention in initial emails (particularly technical) to expand abbreviations, this way:
We are planning to use the Java API For Registry (JAXR).
After mentioning the expanded form once, subsequently you can use the abbreviation.
20. Make sure you always have a subject in your emails and that the subject is relevant. Do not use a subject line such as HI .
21.Avoid using "Back" instead of "Back" Use "ago".Back is the worst word for American.(for Days use "Ago",For hours use "before")
22.Avoid using "but" instead of "But" Use "However".
23.Avoid using "Yesterday" hereafter use "Last day".
24.Avoid using "Tomorrow" hereafter use "Next day".
Get perfect Email ID for your Resume. Get before others grab.
Thursday, December 18, 2008
Wednesday, November 26, 2008
IBM® Lotus Domino attachment and object service (DAOS)
The IBM® Lotus® Domino® attachment and object service (DAOS) in release 8.5 reduces the total cost of ownership and helps customers with green computing practices by storing all file attachments in a separate repository on the server and retrieving them by reference. Read more to plan, set up, configure, and manage Lotus Notes® large objects.
With the release of version 8.5, IBM Lotus Domino server employs the Domino attachment and object service to save significant space at the file level by sharing data identified as identical between databases (applications) on the same server. Document attachments are the first components to use the DAOS feature in Lotus Domino.
In databases that use DAOS, Lotus Domino no longer saves a separate and complete copy of every document attachment. Instead, the server saves a reference to each attached file in an internal repository, and it refers to the same file from multiple documents in one or more databases on the same server. When an attached file is large and a message containing it is broadcast to thousands of users, creating a separate copy of the message for each recipient could require several gigabytes of disk space. Multiple copies of the same attachment often also proliferated in mail threads with multiple replies. With DAOS enabled, disk space usage is substantially reduced.
Use of an attachment object store is optional, and it involves considerable planning before you can implement it in Lotus Domino.
You can mark databases on a Lotus Domino server for participation in attachment consolidation by enabling consolidation on the DAOS tab in the Server document, and by ensuring that every database that you want to include in consolidation has the "Use Domino Attachment and Object Service" advanced database property selected. DAOS also requires transaction logging to be enabled. DAOS stores a single copy of each attachment in a central mapped repository. After you enable attachment consolidation on a server, all databases on the server that are included in consolidation use the repository to store attachments.
When attachment consolidation is enabled and a user saves an attachment, the body stored in the document contains a reference, sometimes called a ticket, to the attachment, which identifies the attachment in the repository. Consolidation occurs immediately; you do not have to wait for a task to run before disk space savings occur in the size of documents with attachments.
With the release of version 8.5, IBM Lotus Domino server employs the Domino attachment and object service to save significant space at the file level by sharing data identified as identical between databases (applications) on the same server. Document attachments are the first components to use the DAOS feature in Lotus Domino.
In databases that use DAOS, Lotus Domino no longer saves a separate and complete copy of every document attachment. Instead, the server saves a reference to each attached file in an internal repository, and it refers to the same file from multiple documents in one or more databases on the same server. When an attached file is large and a message containing it is broadcast to thousands of users, creating a separate copy of the message for each recipient could require several gigabytes of disk space. Multiple copies of the same attachment often also proliferated in mail threads with multiple replies. With DAOS enabled, disk space usage is substantially reduced.
Use of an attachment object store is optional, and it involves considerable planning before you can implement it in Lotus Domino.
You can mark databases on a Lotus Domino server for participation in attachment consolidation by enabling consolidation on the DAOS tab in the Server document, and by ensuring that every database that you want to include in consolidation has the "Use Domino Attachment and Object Service" advanced database property selected. DAOS also requires transaction logging to be enabled. DAOS stores a single copy of each attachment in a central mapped repository. After you enable attachment consolidation on a server, all databases on the server that are included in consolidation use the repository to store attachments.
When attachment consolidation is enabled and a user saves an attachment, the body stored in the document contains a reference, sometimes called a ticket, to the attachment, which identifies the attachment in the repository. Consolidation occurs immediately; you do not have to wait for a task to run before disk space savings occur in the size of documents with attachments.
Tuesday, November 25, 2008
DAOS
Developer Works Article on DAOS
There's a newly published article on DeveloperWorks that outlines how to setup DAOS in your environment. In the meantime, take a look here for more information.
DAOS How it Works and Security
In this section, we'll talk about how DAOS works and how it is secured.
So, first of all, DAOS will work on ANY database that resides on a DAOS-enabled server. There is a property selection box in the database properties, and if enabled, the database will use DAOS for all it's attachments. Basically, what happens is this:
When a document is saved (or emailed, or whatever), Domino sees it as essentially
ddddddXXXXXXXXXddddddddddddXXXXXXXXXXXXXXXdddddddddddddXXXX
where "d" represents the body and "X" represents one or more attachments.
DAOS "rewrites" that so that Domino now sees the document as
ddddddTddddddddddddTdddddddddddddT
where "T" is the "small ticket" information for DAOS
Then, DAOS puts the attachments in the file system and also puts a counter/reference to those attachments in a DAOS Catalog nsf file (more on that feature in a moment). You would have an NLO file for each attachment in the document (as long as the attachments are DIFFERENT).
There you have it! Now, you have a bunch of .NLO files on the file system of your Domino server. Then, when a user opens the document and double-clicks on the attachment icon, Domino knows to go to the DAOS store and retrieves the attachment.
But WAIT, you say...How do I secure it? Can't anyone just get into those .NLO files and manipulate them?
Well, yes and no. First of all, they are on the file system of your Domino server, and a user can't access those files in any way other than through the file structure. So let's take a moment and talk about how secure your Domino server is. In theory, if people have access to the file structure of your Domino server, you have more to worry about than them looking at those .NLO files and reading attachments! They have access to EVERYTHING! The keys to the kingdom, so to speak! They can access id files, .ini files not to mention EVERY single database on the server. So..I'm going to assume that your Domino server is locked down so that Joe user can't just map a drive to it and get at the files.
Secondly, in the next beta drop of 8.5, we will be providing an encryption mechanism for the DAOS store. Therefore, all the files will be encrypted. So, if Joe user does happen to have access, well, now they can be encrypted!
Now, back to how counts work and that comment above about attachments only being stored if they are different..
There is a database, the DAOS Catalog, that keeps track of all the counts for an attachment and where the "tickets" for the attachment are referenced. It knows every .NLO created, how many references for each of them and maintains a list of every .NSF file using the attachments. And, being a Notes database, if it becomes corrupted, DAOS will detect that corruption and attempt to remain operable. But, if for some reason the corruption is such that DAOS can't continue to function, there will be some commands an administrator can run that will resync everything.
Suffice to say, the developers will ensure you can get at your attachments! There will be many tools you can leverage that will allow you to restore NLOs, fixup the stores and keep the store up to date. Having said that however, you can't really manipulate the DAOS counts on your own. Administratively, it's a no-no.
We also had some great questions about the fact that if you got spammed or did a copy/paste of an attachment, wouldn't there be a million files out in the DAOS store? Now, here's where it gets really cool.
When you do a copy/paste of an attachment or if an attachment is the same across multiple messages, the DAOS code recognizes that! DAOS will then only store one version of the attachment, and create a ton of reference counts for each document!
So, while we can't keep you from getting spammed or copying attachments a bunch of times, we can make it easier by saving you a lot of disk space when that occurs! Too cool!
WHEW! That's a LOT of information!!!
There's a newly published article on DeveloperWorks that outlines how to setup DAOS in your environment. In the meantime, take a look here for more information.
DAOS How it Works and Security
In this section, we'll talk about how DAOS works and how it is secured.
So, first of all, DAOS will work on ANY database that resides on a DAOS-enabled server. There is a property selection box in the database properties, and if enabled, the database will use DAOS for all it's attachments. Basically, what happens is this:
When a document is saved (or emailed, or whatever), Domino sees it as essentially
ddddddXXXXXXXXXddddddddddddXXXXXXXXXXXXXXXdddddddddddddXXXX
where "d" represents the body and "X" represents one or more attachments.
DAOS "rewrites" that so that Domino now sees the document as
ddddddTddddddddddddTdddddddddddddT
where "T" is the "small ticket" information for DAOS
Then, DAOS puts the attachments in the file system and also puts a counter/reference to those attachments in a DAOS Catalog nsf file (more on that feature in a moment). You would have an NLO file for each attachment in the document (as long as the attachments are DIFFERENT).
There you have it! Now, you have a bunch of .NLO files on the file system of your Domino server. Then, when a user opens the document and double-clicks on the attachment icon, Domino knows to go to the DAOS store and retrieves the attachment.
But WAIT, you say...How do I secure it? Can't anyone just get into those .NLO files and manipulate them?
Well, yes and no. First of all, they are on the file system of your Domino server, and a user can't access those files in any way other than through the file structure. So let's take a moment and talk about how secure your Domino server is. In theory, if people have access to the file structure of your Domino server, you have more to worry about than them looking at those .NLO files and reading attachments! They have access to EVERYTHING! The keys to the kingdom, so to speak! They can access id files, .ini files not to mention EVERY single database on the server. So..I'm going to assume that your Domino server is locked down so that Joe user can't just map a drive to it and get at the files.
Secondly, in the next beta drop of 8.5, we will be providing an encryption mechanism for the DAOS store. Therefore, all the files will be encrypted. So, if Joe user does happen to have access, well, now they can be encrypted!
Now, back to how counts work and that comment above about attachments only being stored if they are different..
There is a database, the DAOS Catalog, that keeps track of all the counts for an attachment and where the "tickets" for the attachment are referenced. It knows every .NLO created, how many references for each of them and maintains a list of every .NSF file using the attachments. And, being a Notes database, if it becomes corrupted, DAOS will detect that corruption and attempt to remain operable. But, if for some reason the corruption is such that DAOS can't continue to function, there will be some commands an administrator can run that will resync everything.
Suffice to say, the developers will ensure you can get at your attachments! There will be many tools you can leverage that will allow you to restore NLOs, fixup the stores and keep the store up to date. Having said that however, you can't really manipulate the DAOS counts on your own. Administratively, it's a no-no.
We also had some great questions about the fact that if you got spammed or did a copy/paste of an attachment, wouldn't there be a million files out in the DAOS store? Now, here's where it gets really cool.
When you do a copy/paste of an attachment or if an attachment is the same across multiple messages, the DAOS code recognizes that! DAOS will then only store one version of the attachment, and create a ton of reference counts for each document!
So, while we can't keep you from getting spammed or copying attachments a bunch of times, we can make it easier by saving you a lot of disk space when that occurs! Too cool!
WHEW! That's a LOT of information!!!
Wednesday, August 20, 2008
$ Fields in Lotus Notes
$AssistMail
$Conflict
$ConflictAction
$File
$Fonts
$HHFlags
$KeepPrivate
$Links
$Moods
$PaperColor
$REF
$Revisions
$SealData
$Signature
$VersionOpt
$UpdatedBy
$VERREF
$$ViewBody
$$HTMLhead
$$ViewBody
$$QueryOpenAgent (4.6) or the form event WebQueryOpen (4.6)
$$QuerySaveAgent (4.5) or the form event WebQuerySave (4.6)
$$Return
$$ViewBody
$$ViewList
$$NavigatorBody,
$$NavigatorBody_n
$$ViewTemplate for viewname
$$NavigatorTemplate for navigatorname
$$ViewTemplateDefault
$$NavigatorTemplateDefault
$$SearchTemplate for viewname
$$SearchTemplateDefault
$$SearchSiteTemplate
$$Search
$$ReturnDocumentDeleted
$$ReturnAuthenticationFailure
$$ReturnAuthorizationFailure
$$ReturnGeneralError
$$WebClient (Roles)
Details:
$AssistMail
Indicates that a mail memo was sent by a background agent, rather than through the regular client UI.
$Conflict
$Conflict (Determines if there is a save conflict with the document)
$ConflictAction
Set to "1", allows automatic merging of replication conflicts
$Fonts
Not entirely sure about the implementation on this one, but it's a container for TrueType font information in rich text fields. If you create a formatted memo, then blow away this field, you'll see reversions to the internal font types for Notes: Helv, TmsRmn, and Courier. Nasty!
The $Fonts field is a rich text item with a font table in it. The font table provides a way for Notes to handle fonts other than the standard (non True Type) Helv, Tms Roman and Courier. Each additional font that is used has an entry in the table which consists of a relative number, a name (e.g., Arial), the family of the font and whether it is fixed or proportional. The latter two values only matter when the document is displayed on a system which doesn't have the specified font, as Notes tries to convert it to a "best fit" font that does exist.
The font table provides a way for Notes to handle fonts other than the standard (non True Type) Helv, Tms Roman and Courier.
Just to clarify, when you say "non-True Type," you mean that the standard fonts are non-True Type, not the "other fonts," correct?
All I mean is, the Helv, TmsRmn and Courier implementations are specifically not True Type fonts, because of the cross-platform nature of the Notes client. The $Fonts fields exists for the purpose of maintaining the font table information for any True Type fonts used in the document, right?
I'm pretty positive this is the behavior I've observed over the past 6 years...
$File
Object pointer for file and OLE attachments
$HHFlags
When you deselect the "Print header and footer on first page" checkbox in the properties for the database, each document created from then on contains a $HHFlags field with a value of "1". This field tells Notes not to print the header and/or footer on the first page.
Any documents created while the checkbox is enabled do not contain the $HHFLags field.
Any documents created while the checkbox is not enabled do contain the $HHFLags field.
$KeepPrivate
Creates the "Prevent copying/forward/printing" on any Notes document if set to "1". Note that this is not a security feature, since a user can copy the document to a local database, then reset the $KeepPrivate field through an agent.
$Links
@If(@Contains(@DocFields;"$Links");"Y";"N")
The field is document dependent, so if there is an attachment, it exists, otherwise, it does not.
$Moods
Mood stamp flag for Notes mail
$PaperColor
Yes, $PaperColor does exist as a seldom used internal field used for background form color (almost a moot sortof thing now with jazzier background graphics.
What it is is a number value 0-16 (I believe in string form, but may be a number) that dictates the color of the background. Lets say you have a workflow app or reports with a calculated status - lets say you'd like white as a new report, yellow as in process and [lime] green is closed. Why.....we all are quicker to associate color and/or graphics than looking for that darn status field or figuring out where we are in the flow.
So how do you automate different background colors dynamically - change the value of $papercolor - the next time the document is opened in the ui, the background color will reflect the value of $papercolor - but give it a play - design a simple form and view and create a doc with a $papercolor field. edit modify the string value, save, close and re-open - you'll see how it works!
Again, not something you'd use a lot, but useful for some situations.
old thread I know but for completeness here are the color names for the numbers:
@Member(ColorName;
"black":"white":"red":"green":"blue":"magenta":"yellow":"cyan":"dark red":
"dark green":"dark blue":"dark magenta":"dark yellow":"dark cyan":"gray":
"light gray":"white":"vanilla":"parchment":"ivory":"pale green":"sea mist":
"ice blue":"powder blue":"arctic blue":"lilac mist":"purple wash":"violet frost":
"seashell":"rose pearl":"pale cherry":"white":"blush":"sand":"light yellow":
"honeydew":"celery":"pale aqua":"pale blue":"crystal blue":"light cornflower":
"pale lavender":"grape fizz":"pale plum":"pale pink":"pale rose":"rose quartz":
"5% gray":"red sand":"buff":"lemon":"pale lemon lime":"mint green":"pastel green":
"pastel blue":"sapphire":"cornflower":"light lavender":"pale purple":"light orchid":"pink orchid":
"apple blossom":"pink coral":"10% gray":"light salmon":"light peach":"yellow":"avocado":
"leaf green":"light aqua":"light turquoise":"light cerulean":"azure":"lavender":"light purple":
"dusty violet":"pink":"pastel pink":"pastel red":"15% gray":"salmon":"peach":"mustard":
"lemon lime":"neon green":"aqua":"turquoise":"cerulean":"wedgewood":"heather":
"purple haze":"orchid":"flamingo":"cherry pink":"red coral":"20% gray":"dark salmon":"dark peach":
"gold":"yellow green":"light green":"caribbean":"dark pastel blue":"dark cerulean":"manganese blue":"lilac":"purple":"light red violet":"light magenta":"rose":"carnation pink":"25% gray":"watermelon":
"tangerine":"orange":"chartreuse":"green":"teal":"dark turquoise":"light slate blue":
"medium blue":"dark lilac":"royal purple":"fuchsia":"confetti pink":"pale burgundy":"strawberry":
"30% gray":"rouge":"burnt orange":"dark orange":"light olive":"kelly green":"sea green":"aztec blue":
"dusty blue":"blueberry":"violet":"deep purple":"red violet":"hot pink":"dark rose":"poppy red":
"35% gray":"crimson":"red":"light brown":"olive":"dark green":"dark teal":"spruce":
"slate blue":"navy blue":"blue violet":"amethyst":"dark red violet":"magenta":"light burgundy":
"cherry red":"40% gray":"dark crimson":"dark red":"hazelnut":"dark olive":"emerald":
"malachite":"dark spruce":"steel blue":"blue":"iris":"grape":"plum":"dark magenta":
"burgundy":"cranberry":"50% gray":"mahogany":"brick":"dark brown":"deep olive":"dark emerald":
"evergreen":"baltic blue":"blue denim":"cobalt blue":"dark iris":"midnight":"dark plum":"plum red":"dark burgundy":
"scarlet":"60% gray":"chestnut":"terra cotta":"umber":"amazon":"peacock green":"pine":"seal blue":"dark slate blue":
"royal blue":"lapis":"dark grape":"aubergine":"dark plum red":"raspberry":"deep scarlet":"70% gray":"red gray":
"tan":"khaki":"putty":"bamboo green":"green gray":"baltic gray":"blue gray":"rain cloud":"lilac gray":
"light purple gray":"light mauve":"light plum gray":"light burgundy gray":"rose gray":"80% gray":"dark red gray":"dark tan":"safari":"olive gray":"jade":"dark green gray":"spruce gray":"dark blue gray":
"atlantic gray":"dark lilac gray":"purple gray":"mauve":"plum gray":"burgundy gray":"dark rose gray":"black") - 1
$REF
UNID of parent document in parent/child relationship Notes documents. Rendering a Computed for Display text field on a document with this formula will show a doclink to the parent. You can modify this value, but you'll usually have a hardtime re-aligning the "Response Reference List" flag. You can also insert a list, but unfortunately, that doesn't give the document multiple parents. The NotesDocument.MakeResponse method sets the $Ref
$Revisions
Time/Date list history of all changes to a document. If you examine the Sequence Number attribute on any field, you can find that member of the $Revisions field, and determine the time of last edit for the field. This is the basis for the Notes field-level replication model, and it's one of the most ingenious solutions I've ever seen.
$SealData
Container for encrypted field data in a document
$Signature
Container for private-key encrypted digest of signable fields on the document. This is what Notes uses to verify an electronic signature. If you remove the $Signature field on a signed document, Notes will report a corrupted signature. If you attempt to modify it in any way other than through the NotesDocument.Sign method, you'd better know RSA better than Ron himself!
$UpdatedBy
List of previous editors. Does not add new editor if same as last editor, but does if same as any other prior editor. Not changable because it's maintained by hard-coded elements of API. Only recorded on documents which have some type of Author control. Open edit documents don't track editors.
$VersionOpt
Control field for the "save changes as new document" flag on a form. Basically, no matter what you've set on the form, changing this attribute in the document will create the various form effects associated with the flag.
$$HTMLhead
If you don't use the "For Web Access: Treat document contents as HTML" form property, adding a $$HTMLHead field to a form allows you to pass HTML information, such as Meta tags and JavaScript, to the Head tag for a document. The field can be any data type, but a hidden computed-for-display text field is the best choice.
$$ViewBody
Controller for view renderings on Browser clients.
$$QueryOpenAgent (4.6) or the form event WebQueryOpen (4.6)
The Notes Help 4.6 says about WebQueryOpen: A WebQueryOpen event runs the agent before Domino converts a document to HTML and sends it to the browser. Domino ignores any output produced by the agent in this context.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQueryOpen form events. This simulates the LotusScript QueryOpen form event that isn't supported on the Web.
The $$QueryOpenAgent field works in the same way. Works also in 4.6.
$$QuerySaveAgent (4.5) or the form event WebQuerySave (4.6)
The Notes Help 4.6 says about WebQuerySave: A WebQuerySave event runs the agent before the document is actually saved to disk. The agent can modify the document or use the document data to perform other operations.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQuerySave form events. This simulates the LotusScript QuerySave form event that isn't supported on the Web.
The $$QuerySaveAgent field works in the same way. Works also in 4.6.
$$Return
After Web users submit a document, Domino responds with the default confirmation "Form processed." To override the default response, add a computed text field to the form, name it $$Return, and use HTML as the computed value to create a customized confirmation.
$$ViewBody
Value is view name (in quotes) or a formula that computes the view name. Same as Embedded View.
This is the field you put in a form to display a view. See also the list of $$ forms below.
$$ViewList
Has no value. Same as Embedded Folder Pane.
This is the field you put in a form to display the list of available views and folders. See also the list of $$ forms below.
$$NavigatorBody, $$NavigatorBody_n
Value is navigator name (in quotes) or a formula that computes the navigator name.
Same as Embedded Navigator. To create multiple $$NavigatorBody fields on a form, append an underscore and a character to each subsequent field name.
This is the field you put in a form to display a navigator. See also the list of $$ forms below.
Associated with a lot of the $$ fields are the following forms:
$$ViewTemplate for viewname
Requires a embedded view or $$ViewBody field
Associates the form with a specific view. The form name includes viewname, which is the alias for the view or when no alias exists, the name of the view. For example, the form named "$$ViewTemplate for By Author" associates the form with the By Author view.
Domino requires an Embedded View or the $$ViewBody field on the form, but ignores the value.
$$NavigatorTemplate for navigatorname
Requires a embedded navigator or $$NavigatorBody field.
Associates the form with a specific navigator. The form name includes navigatorname, which is the navigator name. For example, the form named "$$NavigatorTemplate for World Map" associates the form with the World Map navigator.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value. Domino ignores create and read access lists on the form.
$$ViewTemplateDefault
Requires a embedded view or $$ViewBody field.
Makes this form the template for all Web views that aren't associated with another form.
Domino requires an embedded view or the $$ViewBody field on the form, but ignores the value.
$$NavigatorTemplateDefault
Requires a embedded navigator or $$NavigatorBody field.
Makes this form the template for all Web navigators that aren't associated with another form.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value.
$$SearchTemplate for viewname
Associates the form with a specific view. Domino requires the $$ViewBody field, but ignores the value. The form name includes viewname, which is the alias for the view, or, when no alias exists, the name of the view. For example, the form named "$$SearchTemplate for All Documents" associates the form with the All Documents view.
(source: Notes Help 4.6)
$$SearchTemplateDefault
Domino requires the $$ViewBody field, but ignores the value. This form is the default for all Web searches that aren't associated with a specific form.
$$SearchSiteTemplate
In a site search this form is used in stead of $$SearchTemplateDefault
(source: posting by Andrew S Grant on Notes.Net)
$$Search
When a user initiates a text search from the Web, Domino looks in the current database or in the search site database in a multiple-database search for a form with the actual name or the alias name $$Search. If the form exists, Domino opens it; otherwise, Domino displays the default search.htm file stored in the domino\icons directory.
And another set of very useful forms
$$ReturnDocumentDeleted
Displays to Web users when the user successfully deletes documents. Create an editable text field named MessageString to hold the error message.
$$ReturnAuthenticationFailure
Displays to Web users when the user's name and password can't be verified. Create an editable text field named MessageString to hold the error message.
$$ReturnAuthorizationFailure
Displays to Web users when the user doesn't have a high enough access level to access the database. Create an editable text field named MessageString to hold the error message.
$$ReturnGeneralError
Displays to Web users when any other errors occur.. Create an editable text field named MessageString to hold the error message.
Roles
$$WebClient
Is a role which is applied to all Web clients. This role can be very useful in hiding formulas. To check if a client is Web client use @IsMember("WebClient"; @UserRoles).
In general, $$ fields are used for web rendering controls, except in design elements where they are used to hold code. $ fields are generally used for document property controls.
$Conflict
$ConflictAction
$File
$Fonts
$HHFlags
$KeepPrivate
$Links
$Moods
$PaperColor
$REF
$Revisions
$SealData
$Signature
$VersionOpt
$UpdatedBy
$VERREF
$$ViewBody
$$HTMLhead
$$ViewBody
$$QueryOpenAgent (4.6) or the form event WebQueryOpen (4.6)
$$QuerySaveAgent (4.5) or the form event WebQuerySave (4.6)
$$Return
$$ViewBody
$$ViewList
$$NavigatorBody,
$$NavigatorBody_n
$$ViewTemplate for viewname
$$NavigatorTemplate for navigatorname
$$ViewTemplateDefault
$$NavigatorTemplateDefault
$$SearchTemplate for viewname
$$SearchTemplateDefault
$$SearchSiteTemplate
$$Search
$$ReturnDocumentDeleted
$$ReturnAuthenticationFailure
$$ReturnAuthorizationFailure
$$ReturnGeneralError
$$WebClient (Roles)
Details:
$AssistMail
Indicates that a mail memo was sent by a background agent, rather than through the regular client UI.
$Conflict
$Conflict (Determines if there is a save conflict with the document)
$ConflictAction
Set to "1", allows automatic merging of replication conflicts
$Fonts
Not entirely sure about the implementation on this one, but it's a container for TrueType font information in rich text fields. If you create a formatted memo, then blow away this field, you'll see reversions to the internal font types for Notes: Helv, TmsRmn, and Courier. Nasty!
The $Fonts field is a rich text item with a font table in it. The font table provides a way for Notes to handle fonts other than the standard (non True Type) Helv, Tms Roman and Courier. Each additional font that is used has an entry in the table which consists of a relative number, a name (e.g., Arial), the family of the font and whether it is fixed or proportional. The latter two values only matter when the document is displayed on a system which doesn't have the specified font, as Notes tries to convert it to a "best fit" font that does exist.
The font table provides a way for Notes to handle fonts other than the standard (non True Type) Helv, Tms Roman and Courier.
Just to clarify, when you say "non-True Type," you mean that the standard fonts are non-True Type, not the "other fonts," correct?
All I mean is, the Helv, TmsRmn and Courier implementations are specifically not True Type fonts, because of the cross-platform nature of the Notes client. The $Fonts fields exists for the purpose of maintaining the font table information for any True Type fonts used in the document, right?
I'm pretty positive this is the behavior I've observed over the past 6 years...
$File
Object pointer for file and OLE attachments
$HHFlags
When you deselect the "Print header and footer on first page" checkbox in the properties for the database, each document created from then on contains a $HHFlags field with a value of "1". This field tells Notes not to print the header and/or footer on the first page.
Any documents created while the checkbox is enabled do not contain the $HHFLags field.
Any documents created while the checkbox is not enabled do contain the $HHFLags field.
$KeepPrivate
Creates the "Prevent copying/forward/printing" on any Notes document if set to "1". Note that this is not a security feature, since a user can copy the document to a local database, then reset the $KeepPrivate field through an agent.
$Links
@If(@Contains(@DocFields;"$Links");"Y";"N")
The field is document dependent, so if there is an attachment, it exists, otherwise, it does not.
$Moods
Mood stamp flag for Notes mail
$PaperColor
Yes, $PaperColor does exist as a seldom used internal field used for background form color (almost a moot sortof thing now with jazzier background graphics.
What it is is a number value 0-16 (I believe in string form, but may be a number) that dictates the color of the background. Lets say you have a workflow app or reports with a calculated status - lets say you'd like white as a new report, yellow as in process and [lime] green is closed. Why.....we all are quicker to associate color and/or graphics than looking for that darn status field or figuring out where we are in the flow.
So how do you automate different background colors dynamically - change the value of $papercolor - the next time the document is opened in the ui, the background color will reflect the value of $papercolor - but give it a play - design a simple form and view and create a doc with a $papercolor field. edit modify the string value, save, close and re-open - you'll see how it works!
Again, not something you'd use a lot, but useful for some situations.
old thread I know but for completeness here are the color names for the numbers:
@Member(ColorName;
"black":"white":"red":"green":"blue":"magenta":"yellow":"cyan":"dark red":
"dark green":"dark blue":"dark magenta":"dark yellow":"dark cyan":"gray":
"light gray":"white":"vanilla":"parchment":"ivory":"pale green":"sea mist":
"ice blue":"powder blue":"arctic blue":"lilac mist":"purple wash":"violet frost":
"seashell":"rose pearl":"pale cherry":"white":"blush":"sand":"light yellow":
"honeydew":"celery":"pale aqua":"pale blue":"crystal blue":"light cornflower":
"pale lavender":"grape fizz":"pale plum":"pale pink":"pale rose":"rose quartz":
"5% gray":"red sand":"buff":"lemon":"pale lemon lime":"mint green":"pastel green":
"pastel blue":"sapphire":"cornflower":"light lavender":"pale purple":"light orchid":"pink orchid":
"apple blossom":"pink coral":"10% gray":"light salmon":"light peach":"yellow":"avocado":
"leaf green":"light aqua":"light turquoise":"light cerulean":"azure":"lavender":"light purple":
"dusty violet":"pink":"pastel pink":"pastel red":"15% gray":"salmon":"peach":"mustard":
"lemon lime":"neon green":"aqua":"turquoise":"cerulean":"wedgewood":"heather":
"purple haze":"orchid":"flamingo":"cherry pink":"red coral":"20% gray":"dark salmon":"dark peach":
"gold":"yellow green":"light green":"caribbean":"dark pastel blue":"dark cerulean":"manganese blue":"lilac":"purple":"light red violet":"light magenta":"rose":"carnation pink":"25% gray":"watermelon":
"tangerine":"orange":"chartreuse":"green":"teal":"dark turquoise":"light slate blue":
"medium blue":"dark lilac":"royal purple":"fuchsia":"confetti pink":"pale burgundy":"strawberry":
"30% gray":"rouge":"burnt orange":"dark orange":"light olive":"kelly green":"sea green":"aztec blue":
"dusty blue":"blueberry":"violet":"deep purple":"red violet":"hot pink":"dark rose":"poppy red":
"35% gray":"crimson":"red":"light brown":"olive":"dark green":"dark teal":"spruce":
"slate blue":"navy blue":"blue violet":"amethyst":"dark red violet":"magenta":"light burgundy":
"cherry red":"40% gray":"dark crimson":"dark red":"hazelnut":"dark olive":"emerald":
"malachite":"dark spruce":"steel blue":"blue":"iris":"grape":"plum":"dark magenta":
"burgundy":"cranberry":"50% gray":"mahogany":"brick":"dark brown":"deep olive":"dark emerald":
"evergreen":"baltic blue":"blue denim":"cobalt blue":"dark iris":"midnight":"dark plum":"plum red":"dark burgundy":
"scarlet":"60% gray":"chestnut":"terra cotta":"umber":"amazon":"peacock green":"pine":"seal blue":"dark slate blue":
"royal blue":"lapis":"dark grape":"aubergine":"dark plum red":"raspberry":"deep scarlet":"70% gray":"red gray":
"tan":"khaki":"putty":"bamboo green":"green gray":"baltic gray":"blue gray":"rain cloud":"lilac gray":
"light purple gray":"light mauve":"light plum gray":"light burgundy gray":"rose gray":"80% gray":"dark red gray":"dark tan":"safari":"olive gray":"jade":"dark green gray":"spruce gray":"dark blue gray":
"atlantic gray":"dark lilac gray":"purple gray":"mauve":"plum gray":"burgundy gray":"dark rose gray":"black") - 1
$REF
UNID of parent document in parent/child relationship Notes documents. Rendering a Computed for Display text field on a document with this formula will show a doclink to the parent. You can modify this value, but you'll usually have a hardtime re-aligning the "Response Reference List" flag. You can also insert a list, but unfortunately, that doesn't give the document multiple parents. The NotesDocument.MakeResponse method sets the $Ref
$Revisions
Time/Date list history of all changes to a document. If you examine the Sequence Number attribute on any field, you can find that member of the $Revisions field, and determine the time of last edit for the field. This is the basis for the Notes field-level replication model, and it's one of the most ingenious solutions I've ever seen.
$SealData
Container for encrypted field data in a document
$Signature
Container for private-key encrypted digest of signable fields on the document. This is what Notes uses to verify an electronic signature. If you remove the $Signature field on a signed document, Notes will report a corrupted signature. If you attempt to modify it in any way other than through the NotesDocument.Sign method, you'd better know RSA better than Ron himself!
$UpdatedBy
List of previous editors. Does not add new editor if same as last editor, but does if same as any other prior editor. Not changable because it's maintained by hard-coded elements of API. Only recorded on documents which have some type of Author control. Open edit documents don't track editors.
$VersionOpt
Control field for the "save changes as new document" flag on a form. Basically, no matter what you've set on the form, changing this attribute in the document will create the various form effects associated with the flag.
$$HTMLhead
If you don't use the "For Web Access: Treat document contents as HTML" form property, adding a $$HTMLHead field to a form allows you to pass HTML information, such as Meta tags and JavaScript, to the Head tag for a document. The field can be any data type, but a hidden computed-for-display text field is the best choice.
$$ViewBody
Controller for view renderings on Browser clients.
$$QueryOpenAgent (4.6) or the form event WebQueryOpen (4.6)
The Notes Help 4.6 says about WebQueryOpen: A WebQueryOpen event runs the agent before Domino converts a document to HTML and sends it to the browser. Domino ignores any output produced by the agent in this context.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQueryOpen form events. This simulates the LotusScript QueryOpen form event that isn't supported on the Web.
The $$QueryOpenAgent field works in the same way. Works also in 4.6.
$$QuerySaveAgent (4.5) or the form event WebQuerySave (4.6)
The Notes Help 4.6 says about WebQuerySave: A WebQuerySave event runs the agent before the document is actually saved to disk. The agent can modify the document or use the document data to perform other operations.
Create a shared agent that runs manually. Then write a formula that uses @Command({ToolsRunMacro}) to run the agent and attach it to the WebQuerySave form events. This simulates the LotusScript QuerySave form event that isn't supported on the Web.
The $$QuerySaveAgent field works in the same way. Works also in 4.6.
$$Return
After Web users submit a document, Domino responds with the default confirmation "Form processed." To override the default response, add a computed text field to the form, name it $$Return, and use HTML as the computed value to create a customized confirmation.
$$ViewBody
Value is view name (in quotes) or a formula that computes the view name. Same as Embedded View.
This is the field you put in a form to display a view. See also the list of $$ forms below.
$$ViewList
Has no value. Same as Embedded Folder Pane.
This is the field you put in a form to display the list of available views and folders. See also the list of $$ forms below.
$$NavigatorBody, $$NavigatorBody_n
Value is navigator name (in quotes) or a formula that computes the navigator name.
Same as Embedded Navigator. To create multiple $$NavigatorBody fields on a form, append an underscore and a character to each subsequent field name.
This is the field you put in a form to display a navigator. See also the list of $$ forms below.
Associated with a lot of the $$ fields are the following forms:
$$ViewTemplate for viewname
Requires a embedded view or $$ViewBody field
Associates the form with a specific view. The form name includes viewname, which is the alias for the view or when no alias exists, the name of the view. For example, the form named "$$ViewTemplate for By Author" associates the form with the By Author view.
Domino requires an Embedded View or the $$ViewBody field on the form, but ignores the value.
$$NavigatorTemplate for navigatorname
Requires a embedded navigator or $$NavigatorBody field.
Associates the form with a specific navigator. The form name includes navigatorname, which is the navigator name. For example, the form named "$$NavigatorTemplate for World Map" associates the form with the World Map navigator.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value. Domino ignores create and read access lists on the form.
$$ViewTemplateDefault
Requires a embedded view or $$ViewBody field.
Makes this form the template for all Web views that aren't associated with another form.
Domino requires an embedded view or the $$ViewBody field on the form, but ignores the value.
$$NavigatorTemplateDefault
Requires a embedded navigator or $$NavigatorBody field.
Makes this form the template for all Web navigators that aren't associated with another form.
Domino requires an embedded navigator or the $$NavigatorBody field on the form, but ignores the value.
$$SearchTemplate for viewname
Associates the form with a specific view. Domino requires the $$ViewBody field, but ignores the value. The form name includes viewname, which is the alias for the view, or, when no alias exists, the name of the view. For example, the form named "$$SearchTemplate for All Documents" associates the form with the All Documents view.
(source: Notes Help 4.6)
$$SearchTemplateDefault
Domino requires the $$ViewBody field, but ignores the value. This form is the default for all Web searches that aren't associated with a specific form.
$$SearchSiteTemplate
In a site search this form is used in stead of $$SearchTemplateDefault
(source: posting by Andrew S Grant on Notes.Net)
$$Search
When a user initiates a text search from the Web, Domino looks in the current database or in the search site database in a multiple-database search for a form with the actual name or the alias name $$Search. If the form exists, Domino opens it; otherwise, Domino displays the default search.htm file stored in the domino\icons directory.
And another set of very useful forms
$$ReturnDocumentDeleted
Displays to Web users when the user successfully deletes documents. Create an editable text field named MessageString to hold the error message.
$$ReturnAuthenticationFailure
Displays to Web users when the user's name and password can't be verified. Create an editable text field named MessageString to hold the error message.
$$ReturnAuthorizationFailure
Displays to Web users when the user doesn't have a high enough access level to access the database. Create an editable text field named MessageString to hold the error message.
$$ReturnGeneralError
Displays to Web users when any other errors occur.. Create an editable text field named MessageString to hold the error message.
Roles
$$WebClient
Is a role which is applied to all Web clients. This role can be very useful in hiding formulas. To check if a client is Web client use @IsMember("WebClient"; @UserRoles).
In general, $$ fields are used for web rendering controls, except in design elements where they are used to hold code. $ fields are generally used for document property controls.
Wednesday, May 28, 2008
Monday, May 26, 2008
Deny Access vs Full Access Administrators
Deny Access vs Full Access Administrators
I always thought that "Deny Access" was the be-all, end-all. But apparently not. If someone is listed in both the "Full Access Administrators" list and the "Deny Access" list for the server, they will still be able to access the server. The "Full Access Administrators" trumps the "Deny Access" setting.
From the Administrator Help file, here's information on the Full Access Administrators field:
Full access administrators
Full access administrator is the highest level of administrative access to the server. The full access administrator feature replaces the need to run a Notes client locally on a server. It resolves access control problems -- for example, such as those caused when the only managers of a database ACL have left an organization.
Full access administrators have the following rights:
* All the rights as listed for all administrator access levels (see above).
* Manager access, with all access privileges enabled, to all databases on the server, regardless of the database ACL settings.
Note ACL roles must still be enabled manually for full access administrators. Manager access, with all roles and access privileges enabled, to the Web Administrator database (WEBADMIN.NSF).
* * Access to all documents in all databases, regardless of Reader names fields.
* The ability to create agents that run in unrestricted mode with full administration rights.
* Access to any unencrypted data on the server.
Note Full access administrator does not allow access to encrypted data. The use of the specified user's private key is required to decrypt documents that are encrypted with public keys. Similarly, a secret key is required to decrypt documents encrypted with secret keys.
Obviously, you want to be careful with who is placed in that field. But when someone leaves the company, just putting them into Deny Access won't be sufficient. You have to pull them out of the Full Access Administrators field in addition to putting them in Deny Access.
I always thought that "Deny Access" was the be-all, end-all. But apparently not. If someone is listed in both the "Full Access Administrators" list and the "Deny Access" list for the server, they will still be able to access the server. The "Full Access Administrators" trumps the "Deny Access" setting.
From the Administrator Help file, here's information on the Full Access Administrators field:
Full access administrators
Full access administrator is the highest level of administrative access to the server. The full access administrator feature replaces the need to run a Notes client locally on a server. It resolves access control problems -- for example, such as those caused when the only managers of a database ACL have left an organization.
Full access administrators have the following rights:
* All the rights as listed for all administrator access levels (see above).
* Manager access, with all access privileges enabled, to all databases on the server, regardless of the database ACL settings.
Note ACL roles must still be enabled manually for full access administrators. Manager access, with all roles and access privileges enabled, to the Web Administrator database (WEBADMIN.NSF).
* * Access to all documents in all databases, regardless of Reader names fields.
* The ability to create agents that run in unrestricted mode with full administration rights.
* Access to any unencrypted data on the server.
Note Full access administrator does not allow access to encrypted data. The use of the specified user's private key is required to decrypt documents that are encrypted with public keys. Similarly, a secret key is required to decrypt documents encrypted with secret keys.
Obviously, you want to be careful with who is placed in that field. But when someone leaves the company, just putting them into Deny Access won't be sufficient. You have to pull them out of the Full Access Administrators field in addition to putting them in Deny Access.
Saturday, May 3, 2008
Completed IBM R8 LotusNotes SA & AD Update
Completed IBM R8 LotusNotes System Adminstration Update with the passing score of 91%
Completed IBM R8 LotusNotes Application Development Update with the passing score of 96%
Completed IBM R8 LotusNotes Application Development Update with the passing score of 96%
Thursday, February 28, 2008
Workload balancing in Domino
Domino administrators can use a number of techniques for balancing workload across servers in a Domino domain. Two of the most effective techniques are:
Allocating users and applications to servers. The administrator can assign users to home servers in a way that spreads the load across this set of servers. Similarly, the administrator can spread applications (databases) across a set of servers, and create replicas when necessary, to spread the application load across a set of servers.
Setting the maximum number of users for a server. Through a Notes.ini setting, Server_MaxUsers, the administrator can specify the maximum number of user sessions allowed on a server. When the server reaches this limit, it rejects requests for additional sessions until the number of sessions again falls below the Server_MaxUsers value.
These techniques work on any Domino server, whether or not it is part of a Domino cluster. While these techniques are generally effective, they are somewhat static and coarse grained. The real advantages come when you use Domino clusters for workload balancing.
In Domino clustering, server workload balancing allows heavily used servers to pass requests to other cluster servers. This form of workload balancing is dynamic, fine-grained, and generally transparent to the user, which means that work can be evenly distributed across the servers in the cluster. Clusters let you grow your system as the number of users you support increases. You can distribute user accounts across clusters and balance additional workloads to optimize system performance. You can create multiple database replicas to maximize data availability and move users to other servers or clusters as you plan for future growth.
Overview of workload balancing in Domino clusters
The Domino server and Notes client work together to provide workload balancing. When running as part of a cluster, the Domino server constantly monitors its own workload. To measure the workload, the Cluster Manager process on the server monitors the average response time of a representative set of server operations initiated by Notes clients (network time is not considered). The Cluster Manager also polls all the other servers in the cluster to determine their workload. When the workload on a server exceeds a certain level designated by the administrator, the server becomes "busy," and the Domino server rejects subsequent database open requests until the workload falls back below the specified level.
When the cluster-aware client (Notes R4 or later) tries to access a database on a busy server, it receives an error code indicating the server is busy. The client then contacts the Cluster Manager on one of the servers in the cluster. (Whenever the client accesses a server that is a member of a cluster, it stores a list of servers in the cluster in a persistent cache.) The Cluster Manager uses the Cluster Database Directory (CLDBDIR) to determine which other servers in the cluster have replicas of the database being requested, and then selects the least heavily loaded of these servers to handle the client request. The client then reissues the open request to this server. Note that this target server could be the same as the original server. On this second request, the open will succeed even if the target server is busy.
Figure1 . Workload balancing animation
Similar to failover, an icon for the new database will appear in the workspace, either stacked on top of the original icon or in a free area on the same workspace page as the original icon.
Workload balancing can be triggered in a wide variety of situations, such as:
A user double-clicks on a database icon in the workspace.
A user tries to launch a doclink, view link, or database link that is connected to a server that is busy.
A user activates a field, action, or button that contains an @Command (FileOpenDatabase) formula and the specified server is busy.
A Lotus Script routine issues a DB.OPENWITHFAILOVER call to open a database on a server that is busy.
An agent written in Java issues an openDatabase method with the failover parameter set to true for a database on a server that is busy.
A C API program issues an NSFDbOpenExtended call to open a database on a server that is busy.
Distribution of databases in the cluster
In a cluster, the distribution of users and databases takes on a new importance. When a server in the cluster fails, user requests are automatically redirected to other servers in the cluster. Ideally, this load should be spread equally across all other servers in the cluster. However, this can only happen when replicas of the databases on the failed server are spread roughly equally across the other servers in the cluster.
An example can illustrate this best. Suppose you have 1200 mail users that you want to put on a cluster with four servers. To start, you will probably allocate 300 users to each server. Now, to give these users high availability to their mail databases, you want to create a replica of each user's mail file on another server in the cluster. You might take all users on Server 1 and put a replica of their mail file on Server 2. This is not a good idea. If Server 1 fails, all 300 of its users will be redirected to Server 2. Servers 3 and 4 will not absorb any of this failover loads, because the necessary databases are only available on Server 2.
Clearly, a better approach is to spread the replicas for Server 1's users across the other three servers. If these are spread evenly -- that is, 100 of Server 1's users on Server 2, 100 on Server 3, and 100 on Server 4 -- a failure of Server 1 should result in a roughly equal increase in workload for the other three servers in the cluster.
Figure 2. Mail user distribution across four servers
The server availability index
As mentioned above, each server in a cluster periodically determines its own workload, based on the average response time of requests recently processed by the server. The workload on the server is expressed as the server availability index, which is a value between 0 and 100, where 100 indicates a lightly loaded server (fast response times), and 0 is a heavily loaded server (slow response times). Despite the fact that the server availability index is a number between 0 and 100, it is not a percentage. Some people think that a server availability index of, say 85, means that the server is 85% available. This is not the case -- in fact, it is far from it.
The actual formula for determining the availability index is not described anywhere in the Notes publications. What I am about to tell you is accurate for the Notes 4.5 and 4.6 releases,
but may change in future releases. The server availability index is closely related to a common performance metric called the expansion factor. The expansion factor is simply the ratio of the response time for a function under the current load to the response time for this same function in an optimum (light load) condition. So, for example, if the system currently takes 3 seconds to perform a database open, but could perform the same database open in .3 seconds under optimum conditions, the expansion factor for this operation is 10. The expansion factor for a set of operations can be computed as a simple weighted average. To compute the server availability index, the Domino server computes the expansion factor for a representative set of Notes RPC transactions over a recent time interval (roughly the last minute). The server availability index is then set to 100 minus this expansion factor.
Server availability index formula
Remember that the server availability index only considers the response time as measured at the server, which is typically only a small portion of the overall response time as seen by clients. In particular, the network time between the client and server often accounts for a significant portion of client response time. So a server availability index of 90 does not indicate that the response time as seen by clients is ten times the optimal value -- only that the server processing of this request took ten times longer than the optimal value.
The server availability threshold
Now that you know how Domino measures server load, you are ready to configure the server to indicate when it is busy. This is done with a Notes.ini setting called Server_Availability_Threshold. When Domino recalculates the server availability index (approximately once a minute), it checks to see if the index is below the server availability threshold. If the server availability index is less than the server availability threshold, the server is marked as busy. In other words, the server availability threshold specifies the lowest value of the server availability index for which the server should be considered to be available.
To set the server availability threshold, edit the Notes.ini file for the server and add the following:
Server_Availability_Threshold=
Or you can set the threshold from the Domino server console with the command:
Set Config Server_Availability_Threshold=
When set from the server console, the new threshold value takes effect immediately. When set by editing Notes.ini, the new threshold value takes effect the next time the server is started.
The default value for the server availability threshold is 0, which means load balancing is effectively disabled. Specifying a threshold value of 100 puts the server into the busy state regardless of its actual availability.
Setting the maximum number of users on a server
You can also balance the workload in a cluster by using the Server_MaxUsers setting. This setting specifies the maximum number of active users allowed on a server at one time. When the server reaches this limit, the server goes into the MAXUSERS state and rejects any additional requests until the number of active users falls below the Server_MaxUsers limit. When Domino rejects an access request because of a MAXUSERS state, the Cluster Manager attempts to redirect the request to another cluster server that contains the appropriate replica. If no other server is available, Domino rejects the access request and displays an explanatory message.
Note The Server_MaxUsers setting does not affect replication. Replication occurs even when a server is in a MAXUSERS state.
From the Domino Administrator
1. Click the Configuration tab.
2. In the Task pane, expand Server, and then click Configurations.
3. Do one of the following:
•If a Configuration Settings document already exists for the server you want, select that document, and then click Edit Configuration.
•If a Configuration Settings document does not already exist for the server you want, click Add Configuration, and add the name of the server in the "Group or Server name" field on the Basics tab.
4. Click the NOTES.INI Settings tab.
5. Click Set/Modify Parameters.
6. In the Item field, select or enter SERVER_MAXUSERS.
7. In the Value field, enter the maximum number of users you want to access the server at the same time.
8. Click Add, and then click OK.
9. Click Save & Close.
Allocating users and applications to servers. The administrator can assign users to home servers in a way that spreads the load across this set of servers. Similarly, the administrator can spread applications (databases) across a set of servers, and create replicas when necessary, to spread the application load across a set of servers.
Setting the maximum number of users for a server. Through a Notes.ini setting, Server_MaxUsers, the administrator can specify the maximum number of user sessions allowed on a server. When the server reaches this limit, it rejects requests for additional sessions until the number of sessions again falls below the Server_MaxUsers value.
These techniques work on any Domino server, whether or not it is part of a Domino cluster. While these techniques are generally effective, they are somewhat static and coarse grained. The real advantages come when you use Domino clusters for workload balancing.
In Domino clustering, server workload balancing allows heavily used servers to pass requests to other cluster servers. This form of workload balancing is dynamic, fine-grained, and generally transparent to the user, which means that work can be evenly distributed across the servers in the cluster. Clusters let you grow your system as the number of users you support increases. You can distribute user accounts across clusters and balance additional workloads to optimize system performance. You can create multiple database replicas to maximize data availability and move users to other servers or clusters as you plan for future growth.
Overview of workload balancing in Domino clusters
The Domino server and Notes client work together to provide workload balancing. When running as part of a cluster, the Domino server constantly monitors its own workload. To measure the workload, the Cluster Manager process on the server monitors the average response time of a representative set of server operations initiated by Notes clients (network time is not considered). The Cluster Manager also polls all the other servers in the cluster to determine their workload. When the workload on a server exceeds a certain level designated by the administrator, the server becomes "busy," and the Domino server rejects subsequent database open requests until the workload falls back below the specified level.
When the cluster-aware client (Notes R4 or later) tries to access a database on a busy server, it receives an error code indicating the server is busy. The client then contacts the Cluster Manager on one of the servers in the cluster. (Whenever the client accesses a server that is a member of a cluster, it stores a list of servers in the cluster in a persistent cache.) The Cluster Manager uses the Cluster Database Directory (CLDBDIR) to determine which other servers in the cluster have replicas of the database being requested, and then selects the least heavily loaded of these servers to handle the client request. The client then reissues the open request to this server. Note that this target server could be the same as the original server. On this second request, the open will succeed even if the target server is busy.
Figure1 . Workload balancing animation
Similar to failover, an icon for the new database will appear in the workspace, either stacked on top of the original icon or in a free area on the same workspace page as the original icon.
Workload balancing can be triggered in a wide variety of situations, such as:
A user double-clicks on a database icon in the workspace.
A user tries to launch a doclink, view link, or database link that is connected to a server that is busy.
A user activates a field, action, or button that contains an @Command (FileOpenDatabase) formula and the specified server is busy.
A Lotus Script routine issues a DB.OPENWITHFAILOVER call to open a database on a server that is busy.
An agent written in Java issues an openDatabase method with the failover parameter set to true for a database on a server that is busy.
A C API program issues an NSFDbOpenExtended call to open a database on a server that is busy.
Distribution of databases in the cluster
In a cluster, the distribution of users and databases takes on a new importance. When a server in the cluster fails, user requests are automatically redirected to other servers in the cluster. Ideally, this load should be spread equally across all other servers in the cluster. However, this can only happen when replicas of the databases on the failed server are spread roughly equally across the other servers in the cluster.
An example can illustrate this best. Suppose you have 1200 mail users that you want to put on a cluster with four servers. To start, you will probably allocate 300 users to each server. Now, to give these users high availability to their mail databases, you want to create a replica of each user's mail file on another server in the cluster. You might take all users on Server 1 and put a replica of their mail file on Server 2. This is not a good idea. If Server 1 fails, all 300 of its users will be redirected to Server 2. Servers 3 and 4 will not absorb any of this failover loads, because the necessary databases are only available on Server 2.
Clearly, a better approach is to spread the replicas for Server 1's users across the other three servers. If these are spread evenly -- that is, 100 of Server 1's users on Server 2, 100 on Server 3, and 100 on Server 4 -- a failure of Server 1 should result in a roughly equal increase in workload for the other three servers in the cluster.
Figure 2. Mail user distribution across four servers
The server availability index
As mentioned above, each server in a cluster periodically determines its own workload, based on the average response time of requests recently processed by the server. The workload on the server is expressed as the server availability index, which is a value between 0 and 100, where 100 indicates a lightly loaded server (fast response times), and 0 is a heavily loaded server (slow response times). Despite the fact that the server availability index is a number between 0 and 100, it is not a percentage. Some people think that a server availability index of, say 85, means that the server is 85% available. This is not the case -- in fact, it is far from it.
The actual formula for determining the availability index is not described anywhere in the Notes publications. What I am about to tell you is accurate for the Notes 4.5 and 4.6 releases,
but may change in future releases. The server availability index is closely related to a common performance metric called the expansion factor. The expansion factor is simply the ratio of the response time for a function under the current load to the response time for this same function in an optimum (light load) condition. So, for example, if the system currently takes 3 seconds to perform a database open, but could perform the same database open in .3 seconds under optimum conditions, the expansion factor for this operation is 10. The expansion factor for a set of operations can be computed as a simple weighted average. To compute the server availability index, the Domino server computes the expansion factor for a representative set of Notes RPC transactions over a recent time interval (roughly the last minute). The server availability index is then set to 100 minus this expansion factor.
Server availability index formula
Remember that the server availability index only considers the response time as measured at the server, which is typically only a small portion of the overall response time as seen by clients. In particular, the network time between the client and server often accounts for a significant portion of client response time. So a server availability index of 90 does not indicate that the response time as seen by clients is ten times the optimal value -- only that the server processing of this request took ten times longer than the optimal value.
The server availability threshold
Now that you know how Domino measures server load, you are ready to configure the server to indicate when it is busy. This is done with a Notes.ini setting called Server_Availability_Threshold. When Domino recalculates the server availability index (approximately once a minute), it checks to see if the index is below the server availability threshold. If the server availability index is less than the server availability threshold, the server is marked as busy. In other words, the server availability threshold specifies the lowest value of the server availability index for which the server should be considered to be available.
To set the server availability threshold, edit the Notes.ini file for the server and add the following:
Server_Availability_Threshold=
Or you can set the threshold from the Domino server console with the command:
Set Config Server_Availability_Threshold=
When set from the server console, the new threshold value takes effect immediately. When set by editing Notes.ini, the new threshold value takes effect the next time the server is started.
The default value for the server availability threshold is 0, which means load balancing is effectively disabled. Specifying a threshold value of 100 puts the server into the busy state regardless of its actual availability.
Setting the maximum number of users on a server
You can also balance the workload in a cluster by using the Server_MaxUsers setting. This setting specifies the maximum number of active users allowed on a server at one time. When the server reaches this limit, the server goes into the MAXUSERS state and rejects any additional requests until the number of active users falls below the Server_MaxUsers limit. When Domino rejects an access request because of a MAXUSERS state, the Cluster Manager attempts to redirect the request to another cluster server that contains the appropriate replica. If no other server is available, Domino rejects the access request and displays an explanatory message.
Note The Server_MaxUsers setting does not affect replication. Replication occurs even when a server is in a MAXUSERS state.
From the Domino Administrator
1. Click the Configuration tab.
2. In the Task pane, expand Server, and then click Configurations.
3. Do one of the following:
•If a Configuration Settings document already exists for the server you want, select that document, and then click Edit Configuration.
•If a Configuration Settings document does not already exist for the server you want, click Add Configuration, and add the name of the server in the "Group or Server name" field on the Basics tab.
4. Click the NOTES.INI Settings tab.
5. Click Set/Modify Parameters.
6. In the Item field, select or enter SERVER_MAXUSERS.
7. In the Value field, enter the maximum number of users you want to access the server at the same time.
8. Click Add, and then click OK.
9. Click Save & Close.
LN Tips - Multiple Clients
Author -> billbuchan
Okay. This isn't a coding tip, per say, but will be of most use to developers.
A common scenario, in order to rein in the developers, is to have a separate development environment, where the developers can crash servers to their hearts delight. (Being a developer, this is one of my few job-related joys).
However, there usually is (and certainly should be!) a separate certification hierarchy.
Some people might choose to use "file, tools (or security..they keep moving it!), switch ID", or might even go to the lengths of making custom location documents - one for their "production" ID, and one for their "development" ID.
This is bad:
- You keep having to switch between environments.
- You risk attempting to use the wrong ID in the wrong environment
- You start getting certificates bleeding through your names. nsf (personal name and address book).
All of which are bad.
So - the solution ?
Create separate notes client data directories, and have separate notes.ini files (usually placed in the data directory) for each environment. Then use:
nlnotes.exe =
to start them up on a desktop icon.
For instance, I have:
C:\Lotus\Notes6\nlnotes.exe =c:\notes\data\notes.ini
to start up my production client.
You can then have multiple clients running on your machine, oblivious to each other.
The environments need never see each other. And you can continue doing useful stuff in both clients.
Okay - different versions. How about your production environment is v5, and your test is v6 ? Or the other way around ?
Simple - install the notes Executable client in separate directories, and use the same trick.
But does it work ?
On a good day, I have:
- One notes and developer 4.6.7 client (dont ask)
- two notes v5.0.12 clients (development and test of tooling)
- three notes 6.0.1 clients (production, personal, and v6 app development)
All open at the same time.
So - no excuses. Separate directories, separate clients. Easy, simple, fast, productive. So what are you waiting for ?
Subscribe to:
Comments (Atom)