maimoneb

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:...

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...

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...

Please post: 1) The lines following the DONOBLOCK error 2) Differences in versions (GT.M, OS) and hardware (CPU chips) Thanks, Bill

An additional note about considering the move to GT.M V6.3-011: Version V6.3-011 and after give more context for NOPRINCIO errors .if you are on V6 there’s no change to the database content format. In fact, if you are on V5, the database upgrade to V6 is automatic. However, once you use the expanded V6 capabilities of bigger keys and records, there’s no going back.

Also: V6.3-011 introduced gtm_hupenable and VIEW(“HUPENABLE”) to produce an error on principal device disconnect. This may be related to NOPRINCIO issues, but also to whether your environment expects/relies on processes continuing to run after a principal device disconnect. From the release note: USE for a terminal device recognizes NOHUPENABLE and HUPENABLE deviceparameters to determine whether to recognize a terminal disconnect on $PRINCIPAL as an error. The gtm_hupenable environment variable,...

From a prior post: Can it be solved by upgrading the database version (moving to V63011) ? From the GT.M V6.3-011 Release Note: V6.3-011 provides ... additional context for NOPRINCIO syslog messages.

NOPRINCIO errors indicate the loss of the PRINCIPAL device, e.g., start a GT.M program that produces output then close the terminal session. NOPRINCIO errors are fatal, so when GT.M detects one due to a second unsuccessful attempt to READ or WRITE to the device, it terminates the process immediately, possibly leaving an application state that is out of design. From the Messages & Recovery Procedures Manual: NOPRINCIO, Unable to dddd principal device: DDDD at LLLL due to: SSSS Run Time Fatal: This...