Osmosis Technical Support Page

On this page, common technical support questions related to Osmosis will be presented and answered. Before you call for technical support, please check this page.

How many connections can Osmosis support?

Technically, Osmosis can handle an unlimited number of simultaneous connections. Each connection is threaded asynchronously so that it will be processed, held or denied depending upon the number of connections set in User Preferences, AppleEvent Time-outs, Helix processing capabilities as well as other factors. Note that the actual number of simultaneous connections cannot exceed the user license for the Helix server.

Each request opens a connection, which is closed immediately as soon as Helix provides a response. Helix interprets each open connection as a 'user log-on'; each closed connection as a 'user log-off'. A simultaneous connection occurs when there are two or more open connections.

Osmosis is periodically crashing my web server.

All versions prior to 3.0.1 contain a subtle error that may cause a crash when many requests are being made simultaneously. Update to version 3.0.1 or higher. It is available for downloading on this web site.

When transferring records, the record separator is also loaded.

Helix, using the dump/load dialogs, dumps record separators but does not load them. Osmosis transfer steps bypass the dialogs. If you are using Helix 4.5.2 (or higher), you may choose to omit the separator from the dump dialog OR use Osmosis version 3.0.1 or higher which will automatically strip the record separator before loading.

Osmosis returns a strange error, "HAEGETROW_" failed.

This is an error returned by Helix when a record can not be entered. It is most commonly seen when a format mismatch is encountered. Check your entry template.

A script transfers data to several collections, but the script prematurely terminates.

Osmosis will attempt to complete each script step in a sequential fashion. If it encounters a step that cannot be completed, the script execution will stop. Problems such as a collection not being available or a view not being on a user menu are examples of errors. Osmosis will report all errors in the log file.

I have named my HTML form fields, but Osmosis does not recognize them.

Insure you follow the convention, "UserEntry#". Note that the name is case sensitive and there is no space between the text, "UserEntry" and the number; a leading zero is not required for any number; and only values 0 through 128 are acceptable. Also check that the first UserEntry# is '0'.

If you are using checkboxes, make sure the FieldCount parameter is properly enabled in the script's Entry step.

How do I access my scripts when I want to use realms?

Normally, you would place all scripts in the same folder as the Osmosis application, "cgi-bin". To launch a script named in the HTML, create an alias of the Osmosis application and place it in the realm folder. Indicate the location of the Osmosis alias relative to the HTML file. For example:

The HTML file containing this code fragment is located in a realm folder along with an alias of the Osmosis application. The FORM ACTION will use the alias to locate the Osmosis application, which will then run the named script.

Can I run a Web server, Osmosis and Helix on the same machine?

Yes, but you will experience a severe processing penalty resulting in slow access time and poor data base response. We strongly recommend Helix be on a separate machine.

Can LocalTalk be used to as my network connection between my Web server and Helix application?

Yes. LocalTalk can be used. For faster speeds, we suggest Ethernet.

How can I insure unique internet connections?

As part of the HTTP specification, the web server keeps track of who makes the request, thereby returning the response to the proper location. However, when a request is made of Helix via Osmosis, Helix itself must also keep track of this information. One such method is to use a unique identifier created as 'data' when a browser client accesses the Helix data base. A user name passed in by the browser client or an incrementing number created by Helix serves as possible unique values. This value is then passed out by Helix (as a hidden field) as part of the HTML. Subsequent submissions pass the unique value back to Helix and use it as a link for the session.

How does Osmosis handle multiple users access of the same script and keep global data from being overwritten?

Osmosis uses the process name feature.

Here's how a process name is used: A script's process name is passed to Osmosis as a parameter. When present, Osmosis puts the name into a local variable. If another variable exists with the same name, the script is queued, otherwise the script is run. After the script is completed, the next queued script (of the same process name) is executed.

Script Name: TestMe
Process Name: First

Let's say that 4 users all run this script at the same time...

Osmosis processes TestMe for User 1
User 2 is pended
User 3 is pended
User 4 is pended
Osmosis processes TestMe for User 2
User 3 is pended
User 4 is pended
Osmosis processes TestMe for User 3
User 4 is pended
Osmosis processes TestMe for User 4

Now consider, that as part of the script TestMe, a field value is posted to a Global Relation that will be used as part of a query and/or returned as part of the HTML output. Note that all four users all post the same field value to the Global Relation. If we did not use process name, the potential exists for the global value of User 1 to be overwritten by User 2's global value BEFORE User 1 gets any output returned. We must wait for User 1's output before we can reuse the global value for User 2. This is how process name is used.

If other scripts post values to DIFFERENT fields in the Global Relation, then we can use a new process name. This allows multiple Osmosis scripts to be processed asynchronously by Osmosis and Helix.

In short, a process name is required when a global value is used by a script's output.

What is the technique to flag the records in the source Collection that the subject records have been transferred (dumped)?

The concept of 'transfer' is akin to "dump & load", except that you are not creating text files. Data is dumped from one view and then loaded back into another. One or more collections must be identified, but it can also be the same one.

Unfortunately, the 'post on dump' does not work for AEEA retrieves. This is the AEEA command that is used when data is dumped.

Several workarounds are available:

1. Whenever a record is entered/modified, a date/time is stamped into a date field. This field will be used a query value compared to the last time the transfer was performed. In other words, query the records whose modification date/time is greater than a global value. You will need to keep a record of each transfer so that the 'last time' the transfer was done is really the maximum date/time in this relation of data transfers.

2. A second option is to create a query for the records to be dumped. Then using a post on entry, perform an POST EVERY option 1 or 2 post based on the link 'Query' = 'T'. You could post a flag into each record.

3. Let's say you are dumping out records with several fields. One of the fields being dumped contains the unique key (record#, for example). After the records are 'transferred from', then 'transferred to', you perform another 'transfer to', except this time, posting back to the same collection/relation they originally came from. The view you use is inert (so that records are not created), and has an option 1 post selected. The link is unique key = unique key, posting a flag into the record. This last approach is actually perferred as it affords confirmation the transfer process was successful.

I received the error "Stop on Error Encountered". What does this mean?

Look at Osmosis Tech Note 1 for a discussion of this.

Return to the main page.

philm@powersrvcs.com