I think you need to focus on the input stream. What type of stream is pInput ? You can get its classname using pInput.%ClassName(1)

If it is a file stream, what wrote it? Does its file contain a BOM at the start?

You might need to open a support case with WRC. I don't work for InterSystems.

%Admin_Task is a Resource, as are %Admin_Manage and %Admin_Operate.

In contrast, %All is a Role.

Access to SQL tables is controlled either at the Role level or at the individual User level.

If your user has permissions on the %Admin_Task resource because they hold a role, then it may be appropriate to grant the necessary SQL permissions to that role. By doing this, anyone else holding the role will also be able to access the table.

To grant the SQL permissions, edit the role (or user) definition. Go to the "SQL Tables" tab. Set the namespace dropdown to "%SYS" and check the box to include system items:

In my example above the %Operator role has no permissions on SQL tables in %SYS.

Use the Add Tables button to add a row that gives this role permission to perform a SELECT on the %SYS_Task.History table .

I think this limitation is unfortunate. Encountering the "Service unavailable" when you're trying to evaluate Caché for the first time might discourage you from continuing.

Is the E: drive a real local drive, or is it a mapped driveletter intended to give you access to a folder shared by another machine?

Also, the $ZF calls made by Studio via your source control class will operate with the server credentials that the InterSystems superserver (port 1972, typically) uses. On Windows that's the logon account of the Caché/Ensemble/HealthShare service. Whereas when you launch a Caché terminal onto you local instance from your Windows desktop, your $ZF calls will use the credentials you logged in to the Windows desktop with. Similarly on non-Windows platforms.

It looks to me like DC is integrated with ISC's SSO mechanism. SO maybe that's what's timing you out. Or perhaps if you log out from something else that uses SSO it affects your DC session? Just speculating...

One way is to create a SYSTEM^%ZSTART subroutine and put some COS code in there. Read the doc here about how to do this.

Take care to read the documentation carefully. For example, if your SYSTEM^%ZSTART causes an error your environment startup could fail. Here's a simple error handler to wrap your startup actions in:

 try {
  // Your code here
 }
 catch e {
  d ##class(%SYS.System).WriteToConsoleLog("SYSTEM^%ZSTART error: "_e.AsSystemError(),,1)
 }

Also note that if you are using InterSystems mirroring you may want to run your startup code only on the primary. In that case I recommend creating/editing the ZMIRROR routine in %SYS (on all mirror nodes) and using its NotifyBecomePrimary entrypoint instead of SYSTEM^%ZSTART. Another benefit of NotifyBecomePrimary is that it only runs after the databases are ready to be written to. In contrast, in a mirroring configuration SYSTEM^%ZSTART runs at a point where the databases are readonly.

Manoj, I respectfully suggest that your response isn't an answer to Sansa's question, but instead it is a comment on the question. I encourage you to use the "comment" link below a question in future in this kind of situation.

Also, our question here seems to be the same as Sansa's. Are you and Sansa perhaps working on the same project? If yes, coordinating your efforts to post a single question could be useful. In some cases you may even discover your own answer as you discuss the problem, saving you the trouble of posting a question here. In that case you might still choose to post an article sharing a tip with the community.