Thanks for your quick response.

As far as I can understand, that code is to create the task...and that can be done in ensemble as in ..."System Operation/Task Manager/New Task". The problem is that when creating the task you must specify a "Task Type" and there is no way that those types can be created easily...a part from in Studio.  In the "New Task" screen I can read the following:

For user-defined tasks you must first create a new subclass of the %SYS.Task.Definition class which will then be selectable as a 'Task type'.

Which means there is a way to create a class that creates a "Task Type" that later can be selected when creating a new task. But this is my problem. I don't know how to create that class and if needs to be stored in a specific location for ensemble to get that new type.

Thanks

Thanks for your response. Maybe I was a little bit unclear...sorry about that.

I did not include the full message, just the first characters as an example of the structure of the message I am receiving.

Basically, I am receiving a message (string) from a database ( pInput As EnsLib.SQL.Snapshot), and converting that string into an HL7 message ( ##class(EnsLib.HL7.Message). ImportFromString(pInput.GetData(1))).

The string I am receiving is fine, nothing is missed, but when the string is converted into HL7, part of the message just dissapears. I cannot see any limitation on the number of characters, and if I check the size of the converted HL7 is not close to any round number as 2,000, 3,000...

I am going to try to change the schema to a custom one with the same structure I am receiving and check if that works...

Thanks

Thanks for your help Robert...

I have changed the input parameter in the storeprocedure to VARCHAR(8000) instead of VARCHAR(MAX) and is working so far...

Thanks

The point is that storeprocedure has been used for ages with another integration engine and with other applications...and that call never had any problem. That store procedure was configure to accept an incoming string with any length...that is why the VARCHAR(MAX) was used.

Use varchar(max) when the sizes of the column data entries vary considerably, and the size might exceed 8,000 bytes.

Thanks but that would be similar as the code that worked for me...What I really want is to pass the parameter as a parameter in the call to execute the procedure.

Anyway as I say in the new comment...I don't think the problem is within the code but with the odbc or with the "MAX" for the input parameter.

Thanks

Well...after trying and trying for a while I have more information to share:

As the testing store procedure with no input parameters was working fine... I decided to play with it and copy the code from the other procedure into this testing one. I did, and magically the call worked. But it was still not working with the store procedure I want to use. I checked the input parameter in case that was the problem and it could be the "MAX" for the varchar. Maybe this is what is causing issues. If I set 1000, 2000 or any other value...it works fine, no issues at all, even I manage to run the store procedure I want with that input parameter set to a numeric value and not "MAX" and it worked...but then I changed it to "MAX" and after a few messages that did work...stopped working and I am having the same problem now...

Memory allocation failure

So I know the code is fine, the call to the store procedure is fine...I guess is something with the connection or the way the ODBC talks to the database or how that input parameter is passed to the database.

I would appreciate any suggestion... 

Thanks

Good point!

Thanks

In my case, processes accessing the global are just to read data from global, the global will not be changed by them. It is just once a month the global needs to be updated and only then is when the locks would be required.

Thank you both for your quick replies.

That was exactly what I was looking for....

I think I will be using both...one to stop the other processes accessing the global + locks to really ensure no other processes access the global.

My code will be something like the following:

// Stop other ensemble jobs accessing to the global to avoid bad messages. 
// Jobs are such as services/processes/operations by name. 
DO ##class(Ens.Director).EnableConfigItem("xxx",0,0)
$$$LOGINFO("xxx Disabled")

// Add a lock to control access to the global.
// 0 => 1 attemp only.
LOCK +^lockname:0
// If lock is unsuccesfull, $TEST variable = 0
If '$TEST {
$$$LOGERROR("Lock cannot be obtained. Process cannot continue.")
Quit tSC 
}
$$$LOGINFO("LOCK on")



*** code here to update global ***



// Start other ensemble jobs accessing to the global to avoid bad messages. 
// Jobs are such as services/processes/operations by name. 
DO ##class(Ens.Director).EnableConfigItem("xxx",1,0)
$$$LOGINFO("xxx Enabled")

// REmove lock to control access to the global.
LOCK -^lockname
$$$LOGINFO("LOCK off")