William F

Hello, Unfortunately, I made a typo in the title of the discusion. I should have written 'GT.M WebServer from xinetd to systemd'. I still hope to have answers on the subject.

Hello, Currently, our web application is using GT.M through API calls. On this server, HTTP requests are managed by xinetd calling our MUMPS code. But now, we are asked to move from xinetd to systemd. Does anyone has some advise about this ?

The verifcation test is successful. Our different nevrionment are 64 bits compliant. What is not cristal clear is why from one environment to another we don't have the warning ?

Thanks for your reply. On all our machines, GT.M is installed using this TARGZ file : gtm_V63010_linux_x8664_pro.tar.gz So, normally, we should be in 64 bits no ?

Here is more lines surrounding the posted code : f s n=$o(^rc("syn",$o(^rc("syn","")),"types",n)) q:n="" d . i ^rc("syn",$o(^rc("syn","")),"types",n)=rctpid d s st=(st&0) i st d . f s n=$o(paids(n)) q:n="" d . . s st=$$param^parameter(.rs,.pa,id) . . i st d w "paUcIdxUpd:"_id_" updated",! . . e d . . . w "paUcIdxUpd Status:"_st,! Concerning the CPU, on my main PC without compilatiin error, I've got : OS : Ubuntu 20.04 Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Vendor ID: GenuineIntel Model...

Hi all, On my current project, I'm using 4 PCs with GT.M V63010 installed. I've got a strange compilation error which occur with the following lines of code. On 2 PCs, the code compile and works fine. On the 2 others, the compilation fails with GTM-W-DONOBLOCK error. f s n=$o(^rc("syn",$o(^rc("syn","")),"types",n)) q:n="" d . i ^rc("syn",$o(^rc("syn","")),"types",n)=rctpid d s st=(st&0) ^----- %GTM-W-DONOBLOCK, Argumentless DO not followed by a block . . i st d w "paUcIdxUpd:"_id_" updated",! ^-----...

We're using GT.M as a database server, responding to frontend requests through xinetd. No background job is scheduled for that. And those requests seem to be local. Our problem is that we can't percisely define which routine is causing this trouble. Is there a way to have more details on this kind of error ? Can it be solved by upgrading the database version (moving to V63011) ?

Hi all, We've installed GTM V63010 on a brand new server with Ubuntu 2022. We encounter some recurrent errors than we can't reproduce on developper machine (see logs extracts below). As you can read, we've got many GTM-F-NOPRINCIO even if when no user operation are done on this database. Does anyone has any idea ? Mar 22 18:17:00 GTM-MUMPS[27853]: %GTM-F-NOPRINCIO, Unable to write to principal device -- generated from 0x00007FC2CA4675E4. Mar 22 18:17:58 GTM-MUMPS[27860]: %GTM-F-NOPRINCIO, Unable...