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.
I've suggested this on other forums in years past, but it didn't get a lot of traction, partly because we seem fractured rather than back in the good ol' daze when we all congregated around Clif Oliver's listserver.
It you like the idea here, click "Like" or "I have the same problem" here or any of the related responses.
Thanks!
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
------------------------------
I put my voice on these request.
A 'verbose' mode or a callable global subr to enrich the message.
Thanks by advance.
------------------------------
Manu Fernandes
------------------------------
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.
I've suggested this on other forums in years past, but it didn't get a lot of traction, partly because we seem fractured rather than back in the good ol' daze when we all congregated around Clif Oliver's listserver.
It you like the idea here, click "Like" or "I have the same problem" here or any of the related responses.
Thanks!
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
------------------------------
Definitely required, all it takes is for one error to happen repeatedly by a number of users and the errlog is filled with messages that you can't pin down.
------------------------------
David Inquieti
Helpdesk and Database Manager
Comtec Cable Accessories Ltd
Godmanchester GB
------------------------------
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.
I've suggested this on other forums in years past, but it didn't get a lot of traction, partly because we seem fractured rather than back in the good ol' daze when we all congregated around Clif Oliver's listserver.
It you like the idea here, click "Like" or "I have the same problem" here or any of the related responses.
Thanks!
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
------------------------------
Add me to the list of customers who believe this is needed. Either an ancillary log that includes the call stack (not sure how the call stack would fit into the errlog structure), or the ability to call a routine that customers may define to build their own enhanced logging capability. As Chuck and others stated, a standardized routine or utility might be throwing the error based on the inputs from a calling program/routine. Knowing which calling program generated these errors (or others like Variable ### previously undefined) will make it easier to support and improve our systems.
------------------------------
Ryan Ladd
------------------------------
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.
I've suggested this on other forums in years past, but it didn't get a lot of traction, partly because we seem fractured rather than back in the good ol' daze when we all congregated around Clif Oliver's listserver.
It you like the idea here, click "Like" or "I have the same problem" here or any of the related responses.
Thanks!
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
------------------------------
I think this January request was already granted when I made it.
I'm just now loading & evaluating UV 12.1 & I see this in my errlog.
This is on UV 12.1.1.1018, release date Jan 7, 2022. So predates my start of this thread.
SWEET!:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="
2 SOURCE/U.BP.O/C.HEAD 0x6180223:
1 SOURCE/U.BP.O/MENU.DRIVER 0x15c0224: ".
(Nevermind the error itself. A permissions goof on my part.)
The part in bold is what you see in PORT.STATUS. LAYER.STACK, SYSTEM( 9001 ), or RAID "T" command.
it shows how we got to this error.
I see there are embedded <LF>s or maybe @AMs that confuse ED. I've never seen that in errlog before.
I don't know what happens when the stack is too deep to be captured in the allotted 300(?) bytes in 1 errlog entry.
I have a pgm that monitors errlog. I'll have to modify it to handle the enhancement.
My January request is a repeat of one I made some time ago on this &/or linked in forums.
I didn't know my wish was fulfilled.
Thanks, RocketSW.
In ED's uparrow mode the entry looks like this:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="2 SOURCE/U.BP.O/C.HEAD 0x618
0223: 1 SOURCE/U.BP.O/MENU.DRIVER 0x15c
0224: ". ^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^0
00^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^00
0^000^000^000^000
In ED's uparrow mode:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="2 SOURCE/U.BP.O/C.HEAD 0x618
0223: 1 SOURCE/U.BP.O/MENU.DRIVER 0x15c
0224: ". ^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^0
00^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^00
0^000^000^000^000
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------
I think this January request was already granted when I made it.
I'm just now loading & evaluating UV 12.1 & I see this in my errlog.
This is on UV 12.1.1.1018, release date Jan 7, 2022. So predates my start of this thread.
SWEET!:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="2 SOURCE/U.BP.O/C.HEAD 0x618
0223: 1 SOURCE/U.BP.O/MENU.DRIVER 0x15c
0224: ".
(Nevermind the error itself. A permissions goof on my part.)
The part in bold is what you see in PORT.STATUS. LAYER.STACK, SYSTEM( 9001 ), or RAID "T" command.
it shows how we got to this error.
I see there are embedded <LF>s or maybe @AMs that confuse ED. I've never seen that in errlog before.
I don't know what happens when the stack is too deep to be captured in the allotted 300(?) bytes in 1 errlog entry.
I have a pgm that monitors errlog. I'll have to modify it to handle the enhancement.
My January request is a repeat of one I made some time ago on this &/or linked in forums.
I didn't know my wish was fulfilled.
Thanks, RocketSW.
In ED's uparrow mode the entry looks like this:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="2 SOURCE/U.BP.O/C.HEAD 0x618
0223: 1 SOURCE/U.BP.O/MENU.DRIVER 0x15c
0224: ". ^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^0
00^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^00
0^000^000^000^000
In ED's uparrow mode:
0222: Mon Jul 11 10:41:02 4 AWSSIMSQW01\\simsadmin d:\\sims\\dev Program "C.HEAD": Line 100, Unable to create capture file c:\\uvtemp/
capture0000007924aa. PID=7924 Userno=0 errno=13 Callstack="2 SOURCE/U.BP.O/C.HEAD 0x618
0223: 1 SOURCE/U.BP.O/MENU.DRIVER 0x15c
0224: ". ^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^0
00^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^000^00
0^000^000^000^000
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------
Yeah, well, I spoke too soon. Got too excited.
They only did this for SOME errors, not everything. Release notes for 12.1.1.1018:
- "UNV-32193 Beginning with this release, additional error messages are written to the errlog file in uvhome when a process ends abruptly while reading from or writing to a UniVerse file. The messages are intended to help diagnose the root cause of failure."
In my own errlog I saw,
- Unable to create capture file c:\\uvtemp/capture0000007924aa . . . Callstack="2 SOURCE/U.BP.O/C.HEAD 0x6181 SOURCE/U.BP.O/MENU.DRIVER 0x15c ".
I guess uvtemp is "a universe file". It is an OS directory. They usually use that lingo to mean a UV hashed table.
The good news is that it looks like they solved the problem of how to extract the info & put it into errlog, so they are more poised than before to generalize it.
The bad news is, it won't help me in my typical case, and I still have to change my errlog monitoring program to accommodate this.
A typical entry where I'd like to see that callstack (including executes) might be:
- [time][user] Bad data "19918" for conversion "D2/". Unconverted data used for selection.
. . . so somewhere we're probably building a SELECT that gets executed with an internal date as part of the selection criteria. Where?
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------
