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.
fsn=$o(^rc("syn",$o(^rc("syn","")),"types",n))q:n=""d.i^rc("syn",$o(^rc("syn","")),"types",n)=rctpiddsst=(st&0)^-----%GTM-W-DONOBLOCK, Argumentless DO not followed by a block..istdw"paUcIdxUpd:"_id_" updated",!
^-----%GTM-W-DONOBLOCK, Argumentless DO not followed by a block
This kind of syntax is used in multiple routines.
I solve that with new lines after de 'do'.
But how to explain the different behavior of compiler ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 name: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
Thread(s) per core: 2
Core(s) per socket: 4
One of the failing compilation environment is on a PC with those characteristics :
OS : Ubtuntu 22.04
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7451 24-Core Processor
Thread(s) per core: 1
Core(s) per socket: 1
Hope this can help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Argumentless DO with no immediately following embedded subroutine coded with the appropriate/matching level of “dot” level indicators wind up being run-time NOOPs. This aligns with the original MUMPS interpretive-flavored design aimed at running with the most likely/optimistic interpretation rather than generating extensive diagnostics. GT.M’s DONOBLOCK warnings indicate the code displays a probable intent that can’t be met at run time. These and other warnings may be suppressed with the -NOWARNING qualifier for the MUMPS, ZCOMPILE and ZLINK commands. The DONOBLOCK warnings appeared in the course of GT.M’s evolution, as did their responsiveness to the -NOWARNING qualifier. We have no other reports of the warnings being inconsistent on apparently identical or similar conditions not involving different GT.M version or differing use of qualifiers. We have ceased support of 32-bit versions and no longer have such an environment with which to investigate their behavior. Please consider using 64-bit versions as they have more capability and you seem to have 64-bit hardware.
In the code snippets below you so kindly provided, the bold highlights show argumentless DO commands that have no corresponding appropriately embedded code.
From: discussion@fis-gtm.p.re.sourceforge.net discussion@fis-gtm.p.re.sourceforge.net On Behalf Of William F
Sent: Tuesday, April 11, 2023 6:12 AM
To: [fis-gtm:discussion]34584@discussion.fis-gtm.p.re.sourceforge.net
Subject: [fis-gtm:discussion] Strange compilation error and behavior
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,!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One way to eliminate the warnings in all environments is to address the issues causing the warnings
From a previous post:
In the code snippets below you so kindly provided, the bold highlights show argumentless DO commands that have no corresponding appropriately embedded code.
From: discussion@fis-gtm.p.re.sourceforge.net discussion@fis-gtm.p.re.sourceforge.net On Behalf Of William F
Sent: Tuesday, April 11, 2023 6:12 AM
To: [fis-gtm:discussion] 34584@discussion.fis-gtm.p.re.sourceforge.net
Subject: [fis-gtm:discussion] Strange compilation error and behavior
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,!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
This kind of syntax is used in multiple routines.
I solve that with new lines after de 'do'.
But how to explain the different behavior of compiler ?
Please post:
1) The lines following the DONOBLOCK error
2) Differences in versions (GT.M, OS) and hardware (CPU chips)
Thanks,
Bill
Here is more lines surrounding the posted code :
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 name: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
Thread(s) per core: 2
Core(s) per socket: 4
One of the failing compilation environment is on a PC with those characteristics :
OS : Ubtuntu 22.04
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7451 24-Core Processor
Thread(s) per core: 1
Core(s) per socket: 1
Hope this can help.
Argumentless DO with no immediately following embedded subroutine coded with the appropriate/matching level of “dot” level indicators wind up being run-time NOOPs. This aligns with the original MUMPS interpretive-flavored design aimed at running with the most likely/optimistic interpretation rather than generating extensive diagnostics. GT.M’s DONOBLOCK warnings indicate the code displays a probable intent that can’t be met at run time. These and other warnings may be suppressed with the -NOWARNING qualifier for the MUMPS, ZCOMPILE and ZLINK commands. The DONOBLOCK warnings appeared in the course of GT.M’s evolution, as did their responsiveness to the -NOWARNING qualifier. We have no other reports of the warnings being inconsistent on apparently identical or similar conditions not involving different GT.M version or differing use of qualifiers. We have ceased support of 32-bit versions and no longer have such an environment with which to investigate their behavior. Please consider using 64-bit versions as they have more capability and you seem to have 64-bit hardware.
In the code snippets below you so kindly provided, the bold highlights show argumentless DO commands that have no corresponding appropriately embedded code.
From: discussion@fis-gtm.p.re.sourceforge.net discussion@fis-gtm.p.re.sourceforge.net On Behalf Of William F
Sent: Tuesday, April 11, 2023 6:12 AM
To: [fis-gtm:discussion] 34584@discussion.fis-gtm.p.re.sourceforge.net
Subject: [fis-gtm:discussion] Strange compilation error and behavior
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,!
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 ?
From a prior post:
Concerning the CPU, on my main PC without compilatiin error, I've got :
OS : Ubuntu 20.04
Architecture: x86_64
...
One of the failing compilation environment is on a PC with those characteristics :
OS : Ubtuntu 22.04
Architecture: x86_64
...
From the previous post:
...
gtm_V63010_linux_x8664_pro.tar.gz
...
So, normally, we should be in 64 bits no ?
Since both you hardware and the GT.M release you are using are 64 bits you will run in 64 bits.
To verify the version of GT.M you are running on the servers that do not give the warnings you can:
GTM>write $zversion
GT.M V6.3-010 Linux x86_64
Thanks,
Bill
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 ?
One way to eliminate the warnings in all environments is to address the issues causing the warnings
From a previous post:
In the code snippets below you so kindly provided, the bold highlights show argumentless DO commands that have no corresponding appropriately embedded code.
From: discussion@fis-gtm.p.re.sourceforge.net discussion@fis-gtm.p.re.sourceforge.net On Behalf Of William F
Sent: Tuesday, April 11, 2023 6:12 AM
To: [fis-gtm:discussion] 34584@discussion.fis-gtm.p.re.sourceforge.net
Subject: [fis-gtm:discussion] Strange compilation error and behavior
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,!