can any one explain inter relation between these below given directives
; Do not log repeated messages. Repeated errors must occur in same file on same
; line unless ignore_repeated_source is set true.
; http://php.net/ignore-repeated-errors
ignore_repeated_errors = off
; Ignore source of message when ignoring repeated messages. When this setting
; is On you will not log errors with repeated messages from different files or
; source lines.
; http://php.net/ignore-repeated-source
ignore_repeated_source = off
From PHP Documentation:
ignore_repeated_errors
Do not log repeated messages. Repeated errors must occur in the same file on the same line unless ignore_repeated_source is set true.
ignore_repeated_source
Ignore source of message when ignoring repeated messages. When this setting is On you will not log errors with repeated messages from different files or sourcelines.
ignore_repeated_errors set On will suppress multiple occurrences of the same errors when they come from the same line of the same file.
Setting ignore_repeated_source to On as well will suppress multiple occurrences of the same errors, even if they come from different lines in different files.
A repeated message is one created on the same line in the same file. This could be in a loop or in a function:
for (...) {
someFunctionThatFails();
}
By enabling the second option, a repeated message does not need to be on the same line or file. A message of a certain type will then just be logged once per request. This will then give only one logged message:
someFunctionThatFails();
doSomeThingElse();
someFunctionThatFails();
Related
I am currently working with pthread and read the documentation from here: Pthread Manual Pthread Join.
However, when I read the pages I see the ERRORS, but not the corresponding return values, which will get returned from pthread_join. So my question is, are the ERRORS ordered in ascending order (since it might be an enumerator)?
Error values such as EDEADLK are macros defined by including the <errno.h> header file.
Example:
#include <pthread.h>
#include <errno.h>
...
int retval = pthread_join( threadID, NULL );
if ( retval == EDEADLK )
{
// error-handling code for deadlock
}
else if ( retval == EINVAL )
{
// error-handling code for invalid thread id
}
else if ( retval == ESRCH )
{
// error-handling code for no such thread id
}
Note that the above code is correct only for Linux, as the only error number specified by POSIX for pthread_join() is EDEADLCK.
Per the POSIX standard for error numbers, (bolded portions particularly relevant to your question):
2.3 Error Numbers
Most functions can provide an error number. The means by which each
function provides its error numbers is specified in its description.
Some functions provide the error number in a variable accessed through
the symbol errno, defined by including the <errno.h> header.
The value of errno should only be examined when it is indicated to
be valid by a function's return value. No function in this volume of
POSIX.1-2008 shall set errno to zero. For each thread of a process,
the value of errno shall not be affected by function calls or
assignments to errno by other threads.
Some functions return an error number directly as the function value. These functions return a value of zero to indicate success.
If more than one error occurs in processing a function call, any one
of the possible errors may be returned, as the order of detection is
undefined.
Implementations may support additional errors not included in this
list, may generate errors included in this list under circumstances
other than those described here, or may contain extensions or
limitations that prevent some errors from occurring.
The ERRORS section on each reference page specifies which error
conditions shall be detected by all implementations ("shall fail") and
which may be optionally detected by an implementation ("may fail"). If
no error condition is detected, the action requested shall be
successful. If an error condition is detected, the action requested
may have been partially performed, unless otherwise stated.
Implementations may generate error numbers listed here under
circumstances other than those described, if and only if all those
error conditions can always be treated identically to the error
conditions as described in this volume of POSIX.1-2008.
Implementations shall not generate a different error number from one
required by this volume of POSIX.1-2008 for an error condition
described in this volume of POSIX.1-2008, but may generate additional
errors unless explicitly disallowed for a particular function.
Each implementation shall document, in the conformance document,
situations in which each of the optional conditions defined in
POSIX.1-2008 is detected. The conformance document may also contain
statements that one or more of the optional error conditions are not
detected.
Certain threads-related functions are not allowed to return an error
code of [EINTR]. Where this applies it is stated in the ERRORS section
on the individual function pages.
The following macro names identify the possible error numbers, in the context of the functions specifically defined in this volume of
POSIX.1-2008; these general descriptions are more precisely defined in
the ERRORS sections of the functions that return them. Only these
macro names should be used in programs, since the actual value of the
error number is unspecified. All values listed in this section shall
be unique, except as noted below. The values for all these macros
shall be found in the <errno.h> header defined in the Base
Definitions volume of POSIX.1-2008. The actual values are unspecified
by this volume of POSIX.1-2008.
[E2BIG]
Argument list too long. The sum of the number of bytes
used by the new process image's argument list and environment
list is greater than the system-imposed limit of {ARG_MAX} bytes.
or:
Lack of space in an output buffer.
or:
Argument is greater than the system-imposed maximum.
[EACCES]
Permission denied. An attempt was made to access a file
in a way forbidden by its file access permissions.
[EADDRINUSE]
Address in use. The specified address is in use.
[EADDRNOTAVAIL]
Address not available. The specified address is not
available from the local system.
[EAFNOSUPPORT]
Address family not supported. The implementation does
not support the specified address family, or the specified
address is not a valid address for the address family
of the specified socket.
[EAGAIN]
Resource temporarily unavailable. This is a temporary
condition and later calls to the same routine may complete
normally.
[EALREADY]
Connection already in progress. A connection request is already
in progress for the specified socket.
.
.
.
I'm getting the following error when I try to put ~1000 records into one table. I've put >1000 records in a table before. There's plenty of space on the disk. Any ideas what would cause this write to fail? It usually fails trying to write PREVIOUS.LOG, but I have also seen it fail writing to one of the table's .DCL files.
Got event: {mnesia_system_event,
{mnesia_fatal,"Cannot open log file ~p: ~p~n",
["/opt/notifier/rel/notifier/Mnesia.notifier#ql1erldev1/PREVIOUS.LOG",
{file_error,
"/opt/notifier/rel/notifier/Mnesia.notifier#ql1erldev1/PREVIOUS.LOG",
emfile}],
I have a RPG program A and a CL program B. A accepts some user input from display file and use it as the entry parameter of B. b processes the entry parameter, and if there is an error the message will be received and resent by B so that it will be displayed on the bottom of the display file using message subfile. This message displaying mechanism works but not completely, as the message sent could only be glanced in a very short period of time, then it disappeared from the display file. What would be the cause of this problem? How to stop the message from disappearing?
Here is the sample code inside program B:
DCLF FILE(ECSWIFP1)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))
OVRDBF FILE(ECSWIFP1) TOFILE(ECSWIFP1) SHARE(*YES)
OPNQRYF FILE(ECSWIFP1) QRYSLT(&QRYSTR)
RCVF
CLOF FILE(ECSWIFP1)
DLTOVR FILE(ECSWIFP1)
RTVDTAARA DTAARA(&E4LIBN/&E4OBJN) RTNVAR(&DTARVAL)
GOTO CMDLBL(END)
ERROR:
CLOF FILE(ECSWIFP1)
MONMSG MSGID(CPF4520)
DLTOVR FILE(ECSWIFP1)
MONMSG MSGID(CPF9841)
MSG:
RCVMSG MSGTYPE(*ANY) MSGDTA(&MSGDTA) MSGID(&MSGID)
IF COMD(%SST(&MSGID 1 3)) *NE 'CPF') THEN(GOTO CMDLBL(MSG))
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGDTA(&MSGDTA) MSGTYPE(*STATUS) TOPGMQ(*EXT)
END:
ENDPGM
And here is part of the display file DDS for displaying message:
A R MSG SFL
A SFLMSGRCD(24)
A S0MSGK SFLMSGKEY
A S0PGMQ SFLPGMQ
A R MSGCTL SFLCTL(MSG)
A OVERLAY
A SFLDSP
A SFLINZ
A SFLSIZ(0005)
A SFLPAG(0001)
A S0PGMQ SFLPGMQ
Suppose there is no matching record based on the query string, then RCVF causes CPF0864 to be sent out, and this message can be displayed on the screen without problem.
But if a record is found and the field values are used in the RTVDTAARA command, and the failure of this command (e.g. data area not found) will causes the problem I described above, which is that the received message can only be glimpsed in a short period of time and then disappears. Why this happens?
The typical sequence is
write msgctl
write bottom
exfmt main
Make sure that any record format displayed after the message subfile has OVERLAY specified. Without OVERLAY, 'bottom' will erase the message subfile and 'main' will erase 'bottom'.
Application Display Programming is an old but useful reference.
EDIT After seeing the CL and DDS.
I believe the issue is due to SNDPGMMSG MSGTYPE(*STATUS). Status messages are special, and do not normally go into a subfile message queue. The Messages section in the Infocenter has more information on the different message types.
In CL PGMB, change the SNDPGMMSG to MSGTYPE(*DIAG) TOPGMQ(*PRV). This will throw the exception message to the caller (to PGMA) as a diagnostic message. Double check that you have OVERLAY in the DDS where you need it - my example above that would be bottom and main.
This sequence worked and display the message of message-subfile on the screen
The typical sequence is
write msgctl
write bottom
exfmt main
Make sure that any record format displayed after the message subfile has OVERLAY specified. Without OVERLAY, 'bottom' will erase the message subfile and 'main' will erase 'bottom'.
c
Suppose a display file has been declared in a CL program. It accepts some user input and conducts some validations to it. If it fails the validation a message would be displayed on the bottom of the display file. Is it possible to achieve this in CL? I have tried SNDPGMMSG with MSGTYPE(*DIAG), but the message is displayed only after the program has been terminated, and not on the display file during the execution.
The message to be sent is retrieved from message file so using field to display message is not applicable.
Normally we use message subfile to achive what you required above.
It can be done in display file for both CL and RPG
For CL example, you could read here http://www.mcpressonline.com/cl/the-cl-corner-letting-the-user-know-what-s-right-and-wrong.html.
You could search for "cl program message subfile" for other examples
Define a 75 character field in your display file DDS. Call it MESSAGE. In your CL do something like:
if (&option *ge '35') do
CHGVAR &MESSAGE 'Invalid option chosen'
goto getOption
enddo
Do any editors honer C #line directives with regards to goto line features?
Context:
I'm working on a code generator and need to jump to a line of the output but the line is specified relative to the the #line directives I'm adding.
I can drop them but then finding the input line is even a worse pain
If the editor is scriptable it should be possible to write a script to do the navigation. There might even be a Vim or Emacs script that already does something similar.
FWIW when I writing a lot of Bison/Flexx I wrote a Zeus Lua macro script that attempted to do something similar (i.e. move from input file to the corresponding line of the output file by search for the #line marker).
For any one that might be interested here is that particular macro script.
#line directives are normally inserted by the precompiler, not into source code, so editors won't usually honor that if the file extension is .c.
However, the normal file extension for post-compiled files is .i or .gch, so you might try using that and see what happens.
I've used the following in a header file occasionally to produce clickable items in
the VC6 and recent VS(2003+) compiler ouptut window.
Basically, this exploits the fact that items output in the compiler output
are essentially being parsed for "PATH(LINENUM): message".
This presumes on the Microsoft compiler's treatment of "pragma remind".
This isn't quite exactly what you asked... but it might be generally helpful
in arriving at something you can get the compiler to emit that some editors might honor.
// The following definitions will allow you to insert
// clickable items in the output stream of the Microsoft compiler.
// The error and warning variants will be reported by the
// IDE as actual warnings and errors... which means you can make
// them occur in the task list.
// In theory, the coding standards could be checked to some extent
// in this way and reminders that show up as warnings or even
// errors inserted...
#define strify0(X) #X
#define strify(X) strify0(X)
#define remind(S) message(__FILE__ "(" strify( __LINE__ ) ") : " S)
// example usage
#pragma remind("warning: fake warning")
#pragma remind("error: fake error")
I haven't tried it in a while but it should still work.
Use sed or a similar tool to translate the #lines to something else not interpreted by the compiler, so you get C error messages on the real line, but have a reference to the original input file nearby.