Hi Julian,

I appreciate the response. We do indeed use transforms/subtransforms exactly for this purpose (and it occurs quite often) - but we have a system which requires no changes to the HL7 except for the date formats.  It occurred to me that since "Separators" and "Default Char Encoding" occurred on the Operation then there could be a similar setting for "Default DateTime Format" (if enough developers required it - or the problem was a very common one)!  This was mainly a question to see if I had missed a trick somewhere (and to see how common this was).

Many thanks for answering.

Andy

Thank you Jeffrey ... that totally correlates with the behaviour I am seeing. 

I have tested and assigning  request.%ConstructClone(1) to my context variable does indeed give me an object I can write to.

My Thanks go out to all concerned.

Thanks Eduard,

I determined that I could not write by later in the BPL assigning a value to context.A08Msg.{PD1:4(2).1} which did not save the changes; however,  when I changed the BPL to load context.A08Msg by calling a Transform  - a DTL which simply passed the source (request) to the target(context.A08Msg) - then the assign to context.A08Msg.{PD1:4(2).1} worked as expected.

I suspect the problem lies in the fact that request is an ens.request object while A08Msg is an EnsLib.HL7.Message object (as Robert suggested, but which does not seem to have been added as a comment).

Thanks for the response, I will try the request.%ConstructClone(1) method to see what effect this has.

Thanks for the answers Robert. 

It is a valid point when you mention the object type... my context.A08Msg was set to Enslib.HL7.Message whereas the request type is ens.Request; this could explain why I could not simply assign the request directly into context.A08Msg? 

Could I look 'inside' the request object to find the HL7 message payload?