Universe Enhancement Request for uv/errlog - Return Stack

When reading uv/errlog events, I would like to know what the call return stack was when the error occurred.
In other words, the same info one gets from

• PORT.STATUS LAYER.STACK, or
• RAID "T" trace command, or
• SYSTEM(9001) function call.

Create a UVCONFIG parameter for verbose error logging if you think it will be too burdensome to inflict on unsuspecting customers, but with today's system speed and storage capabilities, I think most would opt for more info.

Business case:

uv/errlog is an underappreciated but powerful tool for application quality improvement by working patterns of errors, correcting data, & -- most importantly! – finding & correcting root causes.

Sometimes it is hard to resolve nebulous errors like:
- Bad data "Y" for conversion "D2/". Unconverted data used for selection.
- RetrieVe: syntax error. Unexpected symbol. Token was "ALL". Scanned command was . . .
- Verb `VAN` is not in your VOC
- Program "XYZ": Line 1234, Variable "ABC" previously undefined. Empty string used.

Even if one knows the basic program & line number that generated the error, if it is a utility subroutine, it is hard to determine the upstream mistake that caused the error.

When reading uv/errlog events, I would like to know what the call return stack was when the error occurred.
In other words, the same info one gets from

• PORT.STATUS LAYER.STACK, or
• RAID "T" trace command, or
• SYSTEM(9001) function call.

Create a UVCONFIG parameter for verbose error logging if you think it will be too burdensome to inflict on unsuspecting customers, but with today's system speed and storage capabilities, I think most would opt for more info.

Business case:

uv/errlog is an underappreciated but powerful tool for application quality improvement by working patterns of errors, correcting data, & -- most importantly! – finding & correcting root causes.

Sometimes it is hard to resolve nebulous errors like:
- Bad data "Y" for conversion "D2/". Unconverted data used for selection.
- RetrieVe: syntax error. Unexpected symbol. Token was "ALL". Scanned command was . . .
- Verb `VAN` is not in your VOC
- Program "XYZ": Line 1234, Variable "ABC" previously undefined. Empty string used.

Even if one knows the basic program & line number that generated the error, if it is a utility subroutine, it is hard to determine the upstream mistake that caused the error.

When reading uv/errlog events, I would like to know what the call return stack was when the error occurred.
In other words, the same info one gets from

• PORT.STATUS LAYER.STACK, or
• RAID "T" trace command, or
• SYSTEM(9001) function call.

Create a UVCONFIG parameter for verbose error logging if you think it will be too burdensome to inflict on unsuspecting customers, but with today's system speed and storage capabilities, I think most would opt for more info.

Business case:

uv/errlog is an underappreciated but powerful tool for application quality improvement by working patterns of errors, correcting data, & -- most importantly! – finding & correcting root causes.

Sometimes it is hard to resolve nebulous errors like:
- Bad data "Y" for conversion "D2/". Unconverted data used for selection.
- RetrieVe: syntax error. Unexpected symbol. Token was "ALL". Scanned command was . . .
- Verb `VAN` is not in your VOC
- Program "XYZ": Line 1234, Variable "ABC" previously undefined. Empty string used.

Even if one knows the basic program & line number that generated the error, if it is a utility subroutine, it is hard to determine the upstream mistake that caused the error.

When reading uv/errlog events, I would like to know what the call return stack was when the error occurred.
In other words, the same info one gets from

• PORT.STATUS LAYER.STACK, or
• RAID "T" trace command, or
• SYSTEM(9001) function call.

Create a UVCONFIG parameter for verbose error logging if you think it will be too burdensome to inflict on unsuspecting customers, but with today's system speed and storage capabilities, I think most would opt for more info.

Business case:

uv/errlog is an underappreciated but powerful tool for application quality improvement by working patterns of errors, correcting data, & -- most importantly! – finding & correcting root causes.

Sometimes it is hard to resolve nebulous errors like:
- Bad data "Y" for conversion "D2/". Unconverted data used for selection.
- RetrieVe: syntax error. Unexpected symbol. Token was "ALL". Scanned command was . . .
- Verb `VAN` is not in your VOC
- Program "XYZ": Line 1234, Variable "ABC" previously undefined. Empty string used.

Even if one knows the basic program & line number that generated the error, if it is a utility subroutine, it is hard to determine the upstream mistake that caused the error.