HIVE docs on  String Types shows me:

• STRING
• VARCHAR (Note: Only available starting with Hive 0.12.0)
• CHAR (Note: Only available starting with Hive 0.13.0

and

Varchar

Varchar types are created with a length specifier (between 1 and 65535), which defines the maximum number of characters allowed in the character string. If a string value being converted/assigned to a varchar value exceeds the length specifier, the string is silently truncated. Character length is determined by the number of code points contained by the character string.

Related to your  ERROR that tells us that STRING has no size limit => it is a STREAM in our terms.
 

So if you don't convert a STRING to VARCHAR   [ preferable VARCHAR(255) ] you won't be able to use an alphanumeric ID
You may, of course,  add some artificial numbering of type BIGINT to be used as ID.

In any case, just with data type STRING I'd call this a rather a text file than an SQL usable table.

Without touching the original source you may need to write your own loader:

• reading the HIVE "table" sequentially row by row
• insert it into a manually designed table/class with automatic id

the error message indicates that you try ECP access to a Mirror DB

Not all mirror configurations allow ECP access - the difference is read/write access and synch/async mirror
using a virtual IP address adds another level of complexity

Check your config against these rules: Configuring ECP Connections to a Mirror

The graphics in Mirroring may help to identify your situation.
 

To connect a Caché DB on a diffe3rnt serve use ECP

For other SQL DBs but also (Caché) see Using the Caché SQL Gateway 

2 main options. 

• $ZDATE Function offers a broad range of date presentations and conversions
• System.SQL*  contains most popular SQL based Date functions as
  • DATE
  • DATEADD
  • DATEDIFF
  • DATENAME
  • DATEPART
  • DAYNAME
  • DAYOFMONTH

  • DAYOFWEEK

  • DAYOFYEAR
  • LASTDAY
  • MONTH
  • MONTHNAME
  • QUARTER
  • TOCHAR
  • TODATE
  • TOTIMESTAMP
  • WEEK
  • YEAR

Within a persistent class you have also a Storage definition describing the structure of the stored data.
In addition access code for SQL projection is generated during the compile process.
Using Inspector in Caché Studio you will find a bunch of SQL specific parameters to control the presentation of your class and properties.
The whole model of describing Objects + SQL tables is known as Unified Data Architecture.

This link tells you more Objects, SQL, and the Unified Data Architecture

Your snip out from the full WSDL uses XML references s0: and s1:

similar to 

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://tempuri.org">

In addition I'm somewhat surprised to see  in your operation

            <input message="s0:myOperationSoapIn"/>
            <output message="s0:myOperationSoapOut"/>
            <fault message="s0:MyFault" name="MyFault"/>

This means you have 1 input msg but 2 different output msg.
If you see the Caché side
- input triggers a ClassMethod
- it returns something or returns an error

I'm not aware of some default logic to return a fault message that is generated.
Typically Success/Failure is signaled as part of the output message.    
As a consequence manual modification of the generated code could be required to split
the return message into 2  different message types. 

It's of cause some guessing behind as you didn't publish the full WSDL.