As Eduard suggests, you need to know the class that the pInput object is derived from as it doesn't seem to be a valid Stream if .Size fails.

It also looks like you might be expecting a file as you retrieve the name so why not use the %File class if the file already exists.

In fact, noting how you get the Filename using the Attributes method this looks like the pInput object is a response with content which means the actual stream will be in pInput.Content

It is far too long since I worked on Hospital systems to give an authoritative answer given extra restrictions you may have but for https the connection and data are already secure.

For outbound infrastructure can ensure it is routed outside appropriately and you could even limit traffic to specific external endpoints.

For inbound a load balancer or reverse proxy in the DMZ can keep your system away from the outside world and limit traffic both between the two and only allow specific external endpoints to have access.

A dashboard for monitoring when SAM or a third party tool is not available.
Make sure there is the ability to add custom elements for the application and to select what elements are displayed to a user.
Also provide access to screens such as locks and processes with granular control over what they are able to do.

Essentially you don't want such users to have full management portal access just selected screens which are useful fronted by a monitor/dashboard that allows them to keep an eye on the database and application.

Just as a note, where you are manually building up your global in gbl you could use the $name function instead, for example...

set gbl="^NigelGlobal(""Subscript1"""_","_"""Subscript2"")"

can be

set gbl=$name(^NigelGlobal("Subscript1","Subscript2"))

which makes it easier to handle quotes etc...

update: ignore the very odd formatting this editor applied to the objectscript.

All the current suggestions are possible, however, usually if it is a Cache/Ensemble start issue the exe will not crash but will report the database failed to start.

In this case the error is that the EXE itself crashed and this is likely why there is nothing in alerts.log or cconsole.log as it did not progress that far.

This implies either an issue with the EXE or with the config details it will read from the registry.

If you check Windows Event Viewer there may be more information there to help resolve.

Should you be unable to resolve then the simplest option would be to install a fresh copy of Cache/Ensemble, first try the repair option with the same version then try upgrading with a newer version, over the top.  This should not lose anything and will either highlight an installation issue or rebuild the problem configuration.

If that fails, keep a copy of the database files, wipe the existing installation and then rebuild, extreme but it depends on how long you want to spend trying to find the problem.

Hello Alexander,

I did eventually find that, we don't use Ensemble and I had expected some central classes but they are only available in an Ensemble enabled namespace.

It does look like the EnsLib.FTP.InboundAdaptor eventually breaks down the strings from LIST using expressions defined in OnInit based on the remote OS which I assume they get using SYST.

I still don't understand why this isn't part of %Net.FtpSession as I cannot use this without Ensemble and Ensemble namespaces have their own complications, such as 2 extra databases, we currently avoid.

I think I will raise a WRC to request this.

Thanks for the help.

To get the remote filesize over SFTP you would use the FileInfo method in %Net.SSH.SFTP.

To get the stream size you would use the SizeGet method on the stream.

However, be aware that during the transfer, depending on OS and methods used there may be translations of line terminators which would affect file size (often called ASCII mode).  This is not very common in SFTP, unlike standard FTP, but can still occur.  Also, I have found in the past that on a non-file stream the SizeGet is not always the same as the final file size when saved but that might just be my findings in special cases.

That was very helpfull as it shows the value is not available, it does not appear in the list of CGI variables.

However, both the clients log and the CSP Gateway trace show the request had this in

Client record from SoapUI

CSP trace

CGI Variables from the details provided by the suggested output is attached as a PDF <update> attaching is failing unfortunately.

I am obviously doing something wrong so any pointers would be helpfull