EXECUTE has an optional CAPTURING clause. I am curious about the frequency of its usage. I can think of a few workload scenarios.
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
BASIC EXECUTE Capturing output, or not
+2EXECUTE has an optional CAPTURING clause. I am curious about the frequency of its usage. I can think of a few workload scenarios.
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
You are right, CAPTURING is mostly used to process the resulting output or suppress the output.
Too, we are used to pay attention to RESULTING value to define what type of 'errorlevel' we get.
We are used to log properly the RESULTING/CAPTURING values in case of 'error' (in-text or code).
Regarding phantoms, we are used to use BRIEF and manage error's log properly, except for runtime messages which are routed to uv/errlog. One of our main request about errlog is to have the call stack (SYSTEM(9001)) .
When running large update progs, we are used to start 'COMO ON 'xyz_timestamp' to capture all 'progress info' CRT'ed by prog and echo'ed of commands EXECUT'ed, It's the better solution to read the complete log of treatment and keep it.
Sometimes, we create output with multiple print channel to &HOLD& (log, errlog, result as data, result as document, ... ) then we can properly split echoes of a prog.
I hope this help.
With kind regards
------------------------------
manu fernandes
------------------------------
EXECUTE has an optional CAPTURING clause. I am curious about the frequency of its usage. I can think of a few workload scenarios.
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
Dale
------------------------------
Dale Kelley
I'm it!
Dale W Kelley Inc
Hohenwald TN US
------------------------------
EXECUTE has an optional CAPTURING clause. I am curious about the frequency of its usage. I can think of a few workload scenarios.
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
1. CAPTURING: Process the resulting output for some information.
2. CAPTURING: Suppress the output so it does not disrupt a terminal screen.
3. CAPTURING: Phantom processes where repeated EXECUTE fill a disk with large &PH& file records.
4. No CAPTURING: Phantom process where the output could prove useful if something goes awry. Expected possible failures would most likely be caught in the first scenario and logged.
I assume that most instances of EXECUTE use CAPTURING for one of the cited examples. Would anyone like to share their thoughts on the fraction of EXECUTE with or without CAPTURING to the whole population of EXECUTE, or other workloads for using or ignoring the CAPTURING clause?
The PHANTOM command now supports a BRIEF keyword to suppress output (except for "Messages" according to the documentation). I assume "Messages" are the kinds of errors that would appear in the errlog file. Perhaps also messages that would appear on STDERR vice STDOUT, but I would need to run that experiment.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
I use CAPTURING in case I get some unexpected result. Then I can create some kind of alert to a superuser, a business manager, log file, as case may be, including the CAPTURED text or some subset thereof. The session where the anomaly occurred may not be the place to read & react to the captured output. Sometimes I also explicitly display the CAPTURED text to the session that generated it, sometimes not.
Chuck Stevenson
------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------
Sign up
Already have an account? Login
Welcome to the Rocket Forum!
Please log in or register:
Employee Login | Registration Member Login | RegistrationEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.
77 4th Avenue
Waltham, MA 02451 USA
