From: "Massimo S." Received: from mail2.quasarbbs.net ([80.86.52.115] verified) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTP id 3300176 for ecs-isp@2rosenthals.com; Thu, 06 Aug 2026 05:49:34 -0400 DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=default; d=ecomstation.it; bh=kwAOyLmHM0jtRrRmfNDYnG+zClGO921mgq/RdcrjvMA=; h=Return-Path:From:To:Subject:Date:Message-ID; b=LTcVrOHydNw7vE2VXrBKpUwxMxByJLrQvevXtg721GIydZePoW8sRLli2bdVcV5UXeLWE Vt8Om5TaV6acqQ9hG20PMaNcfUUIE9wtzjrWX2ZDnqmW/1pnCb+I2M07IvyxMUhsGOoSqx4 ph3FEjcCg9gy9nBTvr7A+b9BikyDjuZFTBsumBKzXGbv6KBOrL3cmVUt4OQghVcVgSAThFn l4Kk3DxNG6Eetyn3faviOTS41k9Ah++nEZqxeRytY5OhTnfcm8hgtNicqgnS+CLEmFM1slc XC+OCGmKNbOV0wRyHJagGtJ1jmf5slJ1Ig1weuxRVqg+FLDJ++I/6annAo3w== Authentication-Results: srv2; spf=none smtp.helo=[192.168.10.199]; spf=pass smtp.mailfrom=ecomstation.it Received: from [192.168.10.199] (dtp [192.168.10.199]) by srv2 (Weasel v3.143) for ; Thu, 06 Aug 2026 11:49:32 -0000 Reply-To: ml@ecomstation.it Subject: Re: [eCS-ISP] uacme 1.2.4 issue - update To: eCS ISP Mailing List References: Organization: Massimo S. Message-ID: Date: Thu, 6 Aug 2026 11:49:26 +0200 User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; it-IT; rv:1.7.13) Gecko/20060424 Thunderbird/1.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: it Content-Transfer-Encoding: 8bit Il 06/08/2026 11:24, Paul Smedley ha scritto: > Hey Max, > > On 6/8/26 17:03, Massimo S. wrote: >> Il 05/08/2026 23:03, Paul Smedley ha scritto: >>> I don't have easy access to an OS/2 box where I am right now, but what does chkdll32.exe uacme.exe on >>> the 1.0.19 & 1.2.4 executables say? >>> >>> My guess is that 1.0.19 had libcurl statically linked and 1.2.4 has it dynamically linked. >>> >>> dynamically linked is preferred as you get security updates for free >> >> But in this way don't work on servers. > > Of course it does. Sorry, if not tested, we don't know if it will run outside a development machine. Starting manually a couple of times an executable on a development machine is not a real test, this is just a (very) light test. I've worked for years in an NRT lab and i know well what this mean. Testing has levels. Development env. Pre-Production env. Production env. (only some) -> Deploy to all >> Anyway, if the need is libcurl: >> >> "YUM install libcurl >> Il pacchetto libcurl-7.75.0-3.oc00.pentium4 Þ giÓ installato e aggiornato all'ultima versione >> Niente da fare" >> >> It means that libcurl is alredy installed, updated and there is nothing to do. >> So what should i install more? >> >> I guess that developers do not test UACME scheduled, they simply start it from the >> command line, it works, oh well, it's all ok. >> >> But UACME is a server tool that must run scheduled, or it's unuseful. >> I guess that CRON is starting a command prompt window with "less environment stuff" >> and the issue pop out. > > It's pretty simple, there is some kind of defect in your cron. Steven doesn't appear to have this issue, and I > assume he's running 1.2.4 and also scheduling it. On another VM i've cronrfg.cmd (Rexx) and it show the same issue. Now about me it's clear UACMEs > 1.0.19 have some issue, eg. lack something and are not compatible with all environments. If they work on just 1 server in the world (Steven) this does not means they work for everyone. (different OS levels, different setups, different application runnings, different paths). Maybe Steven has come application that load in memory some DLLs that for pure lucky make UACME work even scheduled. My VM just run apache+php,Moylan ftpD, syslogD, cron and stop, they even don't run the WPS. Or another possibility 1.2.4 and 1.8.1 maybe handle in a bad way the "DOS" OS/2 paths. This could be a reason of this issue. >> Maybe UACME on /2 has to be compiled with libcurl to work properly. >> > It *is* compiled with libcurl, otherwise it wouldn't function. I mean directly linked inside. massimo