Is there a d3 equivalent to COMO as found on Universe?

Thanks

On Mar 29, 12:31 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
I should mention, for those that don't know, one of the features of
como is to route all output to a file. I know this can be done in
most 'clients' but we are looking for a way to turn on/off directly
from a proc/routine etc

Thanks

I don't think there is a D3 equivalent; however, as you mentioned you
can easily turn on screen capture on the client to accomplish the same
thing (some might actually consider this method superior, as you can
then use your preferred windows editor to search/scroll/bounce around
the captured file [some como files can get pretty huge!]). Doesn't
work if the job is running as a phantom or on the console, though!

Here are the relevant accuterm commands:

ESC STX C o p t ; path CR
Begin capture. Mode o may be O (overwrite), A (append), N (new file
only) or C (clipboard). Source p may be P to capture printed data or
null to capture received data. t may be T (text) to capture text only
(filters out control characters) or null for no filtering. Path is the
drive, directory and file name where the captured data is to be
stored. All characters received (or printed) are stored in the file
(or clipboard) until capturing is disabled (via local or remote
command). Note: when capturing to the clipboard, path is ignored).

ESC STX C X
End capture. The file containing the captured data is closed.


/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Dave:

I don't believe so. I always end up doing this myself; which is a pain.
:-(

Bill

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

On Mar 30, 6:07 am, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
Short answer is "no".

Longer answer is "maybe" - depends a lot on what else is happening in
the processes ... you MIGHT be able to have a little program that does
an SP-OPEN, does a Basic PRINTER ON, then EXECUTES your programs ...
when complete do an SP-CLOSE & inspect/retrieve output from.

--OR--

Use "d3tcl" and re-direction (get a copy of the 7.5 documentation &
read). For example,

[root@D3Linux root]# PICKUSER=dm ; export PICKUSER
[root@D3Linux root]# PICKMD=dm ; export PICKMD
[[root@D3Linux root]# d3tcl listu \(n > /testfile.como
[root@D3Linux root]# cat /testfile.como
07 Jun 2004 6386
pib# pid.... user........ udate utime account....... mdate mtime
location.....

you can wrap this up in an execute statement any way you like, but you
should get the basic idea. Same type of thing is available for D3/NT -
downside is that the d3tcl command will consume a "real user"!

Should suggest that such an addition would be "useful" to D3 .... also
should suggest to IBM that they replicate the LIST-RUNTIME-ERRORS
functionaility (unless there is something in U2 I'm not aware of,
which would NOT surprise me)

HTH

Ross Ferris
Stamina Software
Visage > Better by Design!

On Mar 29, 4:07 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
This may not be a solution for you but D3 does have the BACKGROUND
process that logs output to the Backgrounds.Output file for a phantom
process. We have used it for capturing activity, similar to COMO, for
phantom jobs. Works well.

On Mar 29, 12:31 pm, "dtsig" <d... (AT) hotmail (DOT) com> wrote:
almost...

when i was with NCR/ADDS working on their MV version, i implemented
"capturing" for EXECUTE in BASIC -- but expanded the scope and decided
to implement an ultra-sophisticated "capturing" flavor: effectively
you could have unlimited overlapping, named-COMO sessions attached to
any process (in any sequence - nested/unnested), with the ability to
even start/stop capturing remotely from other processes (assuming
privileges) with zero measurable degradation (i even had a capturing-
session enabled for more than a week without realizing it!) you could
capture the Input, Output, or Both. you could also have "timing data"
transparently embedded in the captured stream -- which was really
useful, because there were commands to "replay" the captured streams
as automation "macros" -- even features for reprogramming the timing-
delays on-the-fly while the streams were being replayed (especially
great for building demos). there were even features to scroll
backwards/forwards through any "active capture session" (and with
"search" capabilities, too), similar to scrolling back on a terminal
emulator (with/without page framing enabled); you could also scroll
thru stored sessions -- convenient for caching either long reports
(eg. 1000+ pages) or any time-intensive summary reports.

<sigh> when i got to pick systems to head up their engineering, they
had already implemented a flavor of capturing for BASIC's EXECUTE...
and unfortunately... there were way tooooo many a-other priority.

On Mar 29, 5:37 pm, "Ross Ferris" <r... (AT) stamina (DOT) com.au> wrote:
Ross,

I think there is a run-time error logging facility in unix UV. There
is an errlog file in the /usr/ibm/uv directory that holds one line per
error (not just basic errors, either). The uvconfig parameter
MAXERRLOGCNT controls how many errors are logged (the maximum number
of lines in errlog). The default is 100 (way too small, imo).

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Mar 29, 4:28 pm, "Scott Ballinger" <scott.ballin... (AT) gmail (DOT) com>
wrote:
Thanks Scott. But don't use accuterm and wouldn't.

Will look for another answer (universe?

On Mar 29, 5:37 pm, "Ross Ferris" <r... (AT) stamina (DOT) com.au> wrote:
Thanks Ross. Will look into this

dsig