Automic Workload Automation

 View Only

Expand all | Collapse all

Problem configuring TLS Gateway on OS/400

  • 1.  Problem configuring TLS Gateway on OS/400

    Posted Feb 26, 2025 03:23 AM
    Edited by Santiago Fernandez Mar 05, 2025 03:35 AM
    Hi everyone,
    We are setting up a TLS Gateway to communicate a non-TLS OS/400 port
    We have followed the installation manual, but we can only see it trying to communicate and after a few minutes it ends without result.
    The log I copied gives little information, but it seems to be searching for the IPs, although I do not see the server machine.


    20250225/082102.346 - U02000097 Connection with partner 'wss://10.254.169.70:2222/agent(/10.254.169.70:60804)' accepted.

    20250225/082102.424 -           U02002039 - 1        Successfully established connection with 'PCUC4001' (socket handle = '1158237757').

    20250225/082102.440 -           U00063013 - 1        FT '19517004': Connecting to '10.17.16.4' at port '2309'.

    20250225/082102.752 -           U02000060 - 1        Closing connection to Agent '0.0.0.0/0.0.0.0'.

    20250225/082102.752 -           U02000412 - 1        '0.0.0.0/0.0.0.0' ordered to close TLS connection with agent 'PCUC4001'.

    20250225/082102.752 - U02100051 Web socket connection 'PCUC4001 closed with status code 'No code present (1005)', reason '-'.\

    20250225/082102.768 - U02000327 Unexpected error on connection 'PCUC4001' (socket handle = '2'), reason '-'.

    20250225/082102.768 - U00045014 Exception 'java.nio.channels.ClosedChannelException: "null"' at 'org.eclipse.jetty.websocket.core.internal.WebSocketSessionState.onEof():169'.

    20250225/082102.768 - U02100051 Web socket connection 'PCUC4001 closed with status code 'No code present (1005)', reason '-'.\

    In the screenshot you can see what happened when triggering a JOBF in AS400.
    It remains connecting.... but does not do anything.

    I look forward to any help on this matter.
    Thanks in advance



    ------------------------------
    Santiago Fernández
    UC SOFTWARE
    santiago.fernandez@ucsoftware.es
    ------------------------------



  • 2.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 14, 2025 05:54 PM

    Hi Did you ever get this fixed? 




  • 3.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 03:28 AM
    Hi, that's solved. Need some help? Regards.


    ------------------------------
    Santiago Fernández
    UC SOFTWARE
    santiago.fernandez@ucsoftware.es
    ------------------------------



  • 4.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 03:33 AM
    Yes. Been on call with Carahsoft who my go between with Broadcom for over 5 hours.

    No one has a clue what Error: 'CPF1338 - Errors occurred on SBMJOB command.Cause . . . . . : See the messages previously listed. Recovery . . . : Correct the errors and then submit the command again. >ProcessBuilder.cpp#sys::ProcessBuilder::start(const UserPrincipal'.

    Means.

    Kenny Hutchins Gilchrist, PMP(r), SAFe6 RTE, SAFe6 Scrum Master, CSM, DOL, CSPO
    Manager, Workload Automation & Dev Ops | IT-Infrastructure and Operations
    [cid:image001.png@01DBF539.183CCB60]
    8403 Colesville Rd, 14th fl
    Silver Spring, MD 20910
    Office: 202.682.6603
    Mobile: 240.338.5307
    Fax: 202.962.8842
    Khutchin@ullico.com<mailto:khutchin@ullico.com>

    Notice. This message is intended only for use by the person or entity to which it is addressed. Because it may contain confidential information intended solely for the addressee, you are notified that any disclosing, copying, downloading, distributing or retaining of this message, and any attached files, is prohibited and may be a violation of state or federal law. If you received this message in error, please notify the sender by reply email, and delete the message and all attached files. Please be aware that Ullico utilizes Transport Layer Security (TLS) encryption by default with all recipients, when feasible. All email communications sent or received through ullico.com email accounts are processed through Mimecast. Thank you




  • 5.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 03:56 AM
    Hi again, Kenneth, I think your problem has little to do with ours, except that it occurs on an OS/400 system.
    I've asked around here, and we have some ideas, at least on how to approach your solution.


    Error: 'CPF1338 - Errors occurred on SBMJOB command. Cause: See the messages previously listed. Recovery: Correct the errors and then submit the command again. >ProcessBuilder.cpp#sys::ProcessBuilder::start(const UserPrincipal'
     
    is related to a failed execution of the SBMJOB command on an IBM i (AS/400) system, likely triggered from Automic Automation (probably via an AS400 Agent or through an external process call).

    1. Check Previous Messages (AS/400 Job Log)

    The error says:

    "See the messages previously listed"

    This means the real error happened before the CPF1338 message.

    • Open the Job Log for the user on IBM i (e.g., using WRKJOB or DSPJOBLOG).

    • Look for messages like:

      • CPF2105 - Object not found

      • CPF9801 - Library not found

      • CPF0000 - Error in command

    • These will show the real reason why the SBMJOB failed.

    2. Review the SBMJOB Command Sent from Automic

    • Check how the SBMJOB is being built and triggered from Automic:

      • Is it part of an AS400 JOBS object?

      • Is it executed via OS/400 Command in a JOBP?

    • Ensure that:

      • The user executing the command has the correct permissions.

      • The SBMJOB syntax is valid.

      • Required libraries (LIBL) are correctly defined in the job environment.

    3. Check the User Context

    The error includes a reference to ProcessBuilder::start(const UserPrincipal), suggesting a problem with the user context used to launch the process, for example:

    • User not authenticated properly.

    • User profile is disabled, lacks permissions, or has expired.

    • Required environment variables for that user are not properly set.

    4. Review the Automic Agent Logs

    • Go to the Automic AS400 Agent directory (on IBM i or wherever the agent runs).

    • Check the following logs:

      • agent.log

      • joblog.[JOBID].log

      • Also look for any stderr.log or out.log

    • These may contain more detailed info about what failed in the SBMJOB.

    Manual Test Example

    From an interactive IBM i session, try running the same command manually:

    SBMJOB CMD(CALL PGM(MYPROGRAM)) JOB(MYTEST)

    If it fails, the system will show you the real error, which can help determine if the problem is:

    • Missing library in the user's library list

    • Program not found

    • Wrong parameters

    • Missing authority

    Common Fix

    • Make sure the agent user has the correct libraries in their JOBD or job environment.

    • If the job uses a custom library that is not in the default list, you can add:

    ADDLIBLE LIB(MYLIB) POSITION(*FIRST)
     
    before the CALL statement in your script.
     
        Also verify that the user's JOBD, environment, queues, library list, and authorities are correctly set.


    ------------------------------
    Santiago Fernández
    UC SOFTWARE
    santiago.fernandez@ucsoftware.es
    ------------------------------



  • 6.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 12:41 PM

    Thanks this was helpful. The root cause of our issue was The SBMJOB command (SBMJOB CMD(CALL PGM(UC4/IRSTRJOB))) was returning an exit code 1 when run directly on the AS/400.<u5:p></u5:p>

    The QPJOBLOG indicated the random missing library, which once deleted allowed SBMJOB to run. Now we are dealing with an issue with the TLS Gateway/Non-TLS connection for the AS400 File transfer jobs working intermittently. 

    Currently reviewing what the requirements are for AS400 to be configured connect and run with the TLS Gateway properly. 




  • 7.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 02:46 PM

    I'm glad to hear you're making progress on the case. Not knowing the agent and AE versions you're using, I'd assume that, given the issue you mentioned, you're already experiencing issues with v24. If so, we had a similar problem with AS400 communication with AE in 24.4. It was resolved by also updating the agent to the same AE version. Our problem was communication and FT between the AS400 and the Automic Server, but not the other way around. In other words, there was a problem or bug between versions 24.x and earlier than 24.4 in the agent and AE running 24.4. If it's something else, please let us know. Another possibility is certificate management.



    ------------------------------
    Santiago Fernández
    UC SOFTWARE
    santiago.fernandez@ucsoftware.es
    ------------------------------



  • 8.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 06:25 PM

    Our AE is Automic Web Interface 21.0.6-release-21.0.6-1683907809487-500cf955ee1.

    We were initially fine using the OS400 agent 12.3.2+build.1581360004782, but we ran into an issue that Carahsoft wouldn't support because that version was no longer supported.

    We then updated to 21.0.5+build.1675092225494, but encountered the issues we discussed earlier. The 21.0.5+build.1675092225494 agent is stable enough to run batch jobs - however, the file transfer jobs are hit or miss due to the TLS Gateway configuration.

    I've been trying to get Carahsoft or Broadcom to clearly explain what specific configuration we need to set up on the AS400 to get the Communication Processes (CPs) to behave properly. For example:

    From the documentation:

    This section is self-maintained and contains port-to-host mappings of either all available Communication Processes (CPs) or TLS Gateways, depending on the Agent's server connection setup.

    When an Agent starts using the value defined in the cp= parameter, it receives a list of all CPs available from the Automation Engine and connects to one of them.

    You can also use the CP_ENDPOINT parameter in the UC_SYSTEM_SETTINGS variable to define where to reach the CPs. In this case, the Agent receives all entries from the CP_ENDPOINT definition and stores this information. The Agent can then select an available endpoint from the list the next time it starts or reconnects to the Automation Engine.

    If the CP_ENDPOINT points to the location of only one load balancer, the CP sends this location to the connecting Agent. If it points to more than one load balancer, the CP sends the location of all the load balancers available to the Agent, so it can choose one when starting or reconnecting.

    Allowed formats:

    • Port number = DNS Name

    • Port number = TCP/IP Address

    Outside of following the Installing the Agent for OS/400 guide step-by-step, what else is actually required to get the AS400 V21/V24 agent stable on all fronts - batch jobs and file transfers?

    I've asked every single Broadcom engineer that Carahsoft has put me in touch with, but I've gotten little to no clear answers. At this point, I'm open to any ideas or suggestions because Carahsoft and the Broadcom engineers I've worked with so far seem to be clueless about how this AS400 agent should work with the TLS Gateway.




  • 9.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 09:55 PM

    Also noticing the File Transfer jobs are throwing false errors. 

    This message showed up 3 times in a row, show the jobs ENDED_NOT_OK when I checked the destination folder the file transfer was successful. 

    2025-07-15 20:22:31 - U00012129 Connection opened from non-TLS Agent 'I5CLOUD' to TLS Agent 'Server' via Gateway 'UCTLSGTW(1.1.1.1:02223)'.
    2025-07-15 20:22:32 - U538976288 ??? ""
    2025-07-15 20:24:39 - U00012129 Connection opened from non-TLS Agent 'I5CLOUD' to TLS Agent 'ServerNAme' via Gateway 'UCTLSGTW(1.1.1.1:02223)'.
    2025-07-15 20:04:52 - U00011124 Selection started with filter 'GRPS/File(File)' ...
    2025-07-15 20:04:52 - U00011125   '/QSYS.LIB/GRPS.LIB/FILE.FILE/FILE.MBR'
    2025-07-15 20:04:52 - U00011126 Files selected: '1'.
    2025-07-15 20:04:53 - U00011134 ERROR '0' bytes, incorrect transfer of '0' records for file '/QSYS.LIB/GRPS.LIB/FILE.FILE/FILE.MBR'->'E:\Folder\Folder\Folder\Folder\File.txt'. Duration  '00:00:01'.
    2025-07-15 20:04:53 - U00063020 FT '4232184': File 'E:\Folder\Folder\Folder\Folder\File.txt' already exists.
    2025-07-15 20:04:53 - U00011409 FT '4232184': File Transfer has ended abnormally.



  • 10.  RE: Problem configuring TLS Gateway on OS/400

    Posted Jul 15, 2025 06:30 PM

    Also how do you manage the Certificate (I assume the TLS/KEYSTORE). Are you using a Certificate connection between the AS400 and AE? 




  • 11.  RE: Problem configuring TLS Gateway on OS/400

    Posted 30 days ago

    Whether a connection certificate is needed between an IBM i (AS/400) system and Automic Automation v21.x depends on the type of communication being established between the two systems.

    When is a certificate required?

    1. If you're using encrypted communication (SSL/TLS):

      • For example, if you're using the AS/400 Agent from Automic (AGENT IBM i) and configure it to communicate with the Automation Engine (AE) via TLS, then yes, a certificate is required (either self-signed or issued by a certificate authority).

      • The Automation Engine and the agents can encrypt communication if configured accordingly in their .ini files and certificates are defined.

    2. If REST API is used over SSL from AS/400:

      • For example, if Automic's REST API is called from AS/400 programs (via CURL, sockets, or HTTP modules), and the API uses HTTPS, then AS/400 must trust the server's certificate (AE REST).

      • This means importing the root certificate or the server certificate into IBM i's trust store (via Digital Certificate Manager - DCM).

    3. If the connection is unencrypted (not recommended):

      • A certificate is not required, but it is not secure for production environments.

    Recommendations

    • Check the .ini files of the AS/400 agent, especially the communication and security sections, to see if TLS is enabled.

    • If you're enabling TLS, configure:

      • The certificate on the Automation Engine (CP/Java).

      • The agent's certificate trust store on AS/400, using DCM (Digital Certificate Manager).

    • Make sure the AE port (e.g., 2217) accepts TLS if enabled.

    Let's go through the configuration needed to enable TLS (certificates) for communication between the Automation Engine (AE) and the AS/400 Agent in Automic v21.x.

    On the Automation Engine (ucsrv.ini)

    Typical location: /bin/ucsrv.ini on the AE server.

    Section [TCP]

    Enable TLS mode:

    [TCP]
    port=2217
    ssl=yes
    keyfile=keystore.p12
    keypass=your_keystore_password
    keystoretype=PKCS12
    • ssl=yes: enables TLS.

    • keyfile: path to the AE server's certificate file.

    • keypass: keystore password.

    • keystoretype: file type (PKCS12, JKS, etc.).

    Section [SECURITY] (if applicable)

    [SECURITY]
    use_tls=1
     
        Note: The .p12 or .jks file must contain a valid certificate (issued or self-signed) with its private key.

    On the AS/400 Agent (agent.ini or the agent's ucsrv.ini)

    Location: on the IBM i system where the AS/400 Agent (AGENT IBM i) runs.

    Section [HOST] or [TCP] (depends on version)

    [TCP]
    host=ae-server.domain.local
    port=2217
    ssl=yes
    truststore=truststore.p12
    truststorepassword=your_truststore_password
    truststoretype=PKCS12

    • ssl=yes: enables TLS for the agent.

    • truststore: file containing trusted certificates (e.g., AE server certificate or CA).

    • You can generate this in IBM i using DCM (Digital Certificate Manager) or import a .p12 if preferred

    Verifications and tests

    • Use telnet or openssl s_client from AS/400 (if available) to test TLS connection to AE.

    • Check the agent logs (agent.log) and AE logs (CP log) to confirm successful handshake.

    • Make sure both system clocks are synchronized (certificates fail with clock drift).



    ------------------------------
    Santiago Fernández
    UC SOFTWARE
    santiago.fernandez@ucsoftware.es
    ------------------------------



  • 12.  RE: Problem configuring TLS Gateway on OS/400

    Broadcom Employee
    Posted 30 days ago
    Edited by Michael Dolinek 30 days ago

    Hi all!

    I want to make things clearer how our system works

    • How the OS/400 agent connects:
      The OS/400 agent usually connects directly to the Automation Engine's CP. It uses an older connection method known as the "GSS protocol."
    • When is the TLS-gateway used to connection to the Automation Engine:
      The TLS-gateway can be used only if no Automation Engine's CP is configured and running. In that situation, the TLS-gateway can act as a CP, allowing the OS/400 agent (and some other agents) to connect to the Automation Engine through it. Of course, TLS-gateway must be setup to "offer" a CP and the Agent must be configured in that way that it connects to the TLS-gateway's CP.
    • What is the main purpose of the TLS-gateway:
      The main purpose of the TLS-gateway is to help agents transfer files to each other, only when they use different connection types. For example, if one agent connects using the newer, secure "TLS" method and another uses the older "GSS" method, the TLS-gateway helps them exchange files.
    • How the TLS-gateway Itself connects:
      The TLS-gateway itself connects to the Automation Engine's JCP. This is the same way modern e.g. Windows agents (version 21 and newer) connect.
    • When TLS certificates are needed:
      You need TLS certificates when you use the secure "TLS" connection method to connect to the Automation Engine's JCP. Many newer components (like AWI, Analytics, and most Agents and Integrations from version 21 onwards) use this secure TLS connection.

    Hopefully this helps

    Michael



    ------------------------------
    Michael K. Dolinek

    Engineering Program Manager | Agile Operation Division
    Broadcom Software
    ------------------------------



  • 13.  RE: Problem configuring TLS Gateway on OS/400

    Posted 30 days ago

    Thanks Michael. Can you confirm if I need to add the Windows server (Automation Engines) DNS record to my AS400 host file to resolve the JOBF using the TLS-GATEWay from throwing false errors? Or am I facing an issue with Agent/AE compatibility? 

    ref: https://knowledge.broadcom.com/external/article/282117/jobf-from-as400-to-other-system-agent-fa.html

    AE: Version: Automic Web Interface 21.0.6-release-21.0.6-1683907809487-500cf955ee1

    AS/OS400 Agent: 21.0.5+build.1675092225494 OS400 41A/EPX6/1 OS/400 V7R3M0




  • 14.  RE: Problem configuring TLS Gateway on OS/400

    Broadcom Employee
    Posted 25 days ago

    Hi @Kenneth Hutchins

    For proper communication within your Automation Engine (AE) environment, Domain Name System (DNS) resolution is essential in the following scenarios:

    • AE Components (CPs/JCPs): DNS is required whenever the connection strings of your Agents for the AE Communication Processes (CPs) or Java Communication Processes (JCPs) utilize DNS hostnames (e.g., ae-jcp.yourdomain.com) instead of direct IP addresses.
    • TLS-Gateways: The same applies if you let your Agents connect to the TLS-gateway's CP and the connection strings are configured with DNS hostnames.

    Be aware that Agents regularly receive updated lists of available CPs and JCPs from the Automation Engine, which include DNS hostnames. This means Agents (and AWI, Analytics, TLS-gateway(s), Integrations, RA Solutions etc.) might need DNS resolution even if they initially connected via an IP address.

    Therefore, ensure:

    • All servers hosting CPs, JCPs, and TLS-gateways have correct DNS settings.
    • These servers are resolvable via DNS and network-reachable from all Agents (and also from the TLS-gateway)

    Hope this helps

    Michael



    ------------------------------
    Michael K. Dolinek

    Engineering Program Manager | Agile Operation Division
    Broadcom Software
    ------------------------------