Direct screen output from an EXE to a file (Alpha, 7.3-2)

[IanD]

I have an application EXE tool that runs and put's the output to the screen (smg)

The problem is the tool will not exit unless a Control C/Y is entered (it scans for input for various functions)

I would dearly love to capture the output to a file for future scanning for automation but am having issues figuring out how to do this

i.e.
tool :== "exe_location:image.exe"

tool <displays output but sits there waiting for control C/Y>

I have tried...

- define sys$output doesn't work, wait's for control C/Y to exit
- pipe doesn't work because it has the same issue as above
- spawn is equally of no help nor is run/detach
- ssh didn't help either, the screen became totally unresponsive
- pipe tool < x.x but that didn't work either (error message about couldn't initialize cursors). I was trying to pipe into the EXE a file x.x (with the idea of adding Control C/Y to a file, didn't know how to add Control C/Y to the x.x file anyhow)

I thought perhaps some type of set host / log to the same node to execute the command and then having the process killed as a long shot but gave up

I do not have access to the source code so I cannot re-code the functionality

Is there some wrapper code (I'd even take Jazz, Electro Swing, but not heavy metal, my days of that are well and truly over!) out there that I can encapsulate this in perhaps to make it think it's writing to a screen device when it's not or some other simple way of doing this?

[Bob Gezelter]

Ian,

The possible solutions are limited by the fact that the program is a "black box", with the source code unavailable.

There are two approaches that may allow you to address this problem, unfortunately, neither is trivial.

First, one could use the scripting facility of a terminal program (e.g., Kermit) to programmatically interact with the program. There is a full book on Kermit which includes a description of its scripting capabilities.

The second approach is to use the OpenVMS Pseudoterminal driver (see http://h71000.www7.hp.com/doc/84final/ba554_90018/ch06.html). This driver allows full programming of the dialogue. I do not know if there are issues with the combination of SMG and the pseudoterminal driver.

- Bob Gezelter, http://www.rlgsc.com

[John Reagan]

To add to Bob's comment about the pseudoterminal. Do you have DECset installed?
DTM (DEC Test Manager) has some support to test screen-based applications. I'm
not sure if the support includes the ability to "control-c/y" however.

[VAXman-]

In article <9578ab19-0b0d-4736...@googlegroups.com>, Bob Gezelter <geze...@rlgsc.com> writes:
>On Monday, September 7, 2015 at 4:27:41 AM UTC-4, IanD wrote:

>> I have an application EXE tool that runs and put's the output to the scre=
>en (smg)
>>=20
>> The problem is the tool will not exit unless a Control C/Y is entered (it=

> scans for input for various functions)

>>=20
>> I would dearly love to capture the output to a file for future scanning f=

>or automation but am having issues figuring out how to do this

>>=20
>> i.e.
>> tool :=3D=3D "exe_location:image.exe"
>>=20

>> tool <displays output but sits there waiting for control C/Y>

>>=20
>> I have tried...
>>=20

>> - define sys$output doesn't work, wait's for control C/Y to exit
>> - pipe doesn't work because it has the same issue as above
>> - spawn is equally of no help nor is run/detach
>> - ssh didn't help either, the screen became totally unresponsive

>> - pipe tool < x.x but that didn't work either (error message about couldn=
>'t initialize cursors). I was trying to pipe into the EXE a file x.x (with =
>the idea of adding Control C/Y to a file, didn't know how to add Control C/=

>Y to the x.x file anyhow)

>>=20
>> I thought perhaps some type of set host / log to the same node to execute=

> the command and then having the process killed as a long shot but gave up

>>=20
>> I do not have access to the source code so I cannot re-code the functiona=
>lity
>>=20
>> Is there some wrapper code (I'd even take Jazz, Electro Swing, but not he=
>avy metal, my days of that are well and truly over!) out there that I can e=
>ncapsulate this in perhaps to make it think it's writing to a screen device=

> when it's not or some other simple way of doing this?
>
>Ian,
>

>The possible solutions are limited by the fact that the program is a "black=

> box", with the source code unavailable.
>

>There are two approaches that may allow you to address this problem, unfort=
>unately, neither is trivial.
>
>First, one could use the scripting facility of a terminal program (e.g., Ke=
>rmit) to programmatically interact with the program. There is a full book o=

>n Kermit which includes a description of its scripting capabilities.
>

>The second approach is to use the OpenVMS Pseudoterminal driver (see http:/=
>/h71000.www7.hp.com/doc/84final/ba554_90018/ch06.html). This driver allows =
>full programming of the dialogue. I do not know if there are issues with th=

>e combination of SMG and the pseudoterminal driver.

Pseudo-terminals ought to keep him busy for a long while. If that SMG$ output
does any screen manipulation, he'll have to handle escape sequences that would
occur. Don't get me wrong, I too would suggest your pseudo-terminal approach
but it's not something that will solve his problem without effort; especially,
if Ian is not a programmer and he's never used the pseudo-terminal previously.
Of course, I'm available for hire and I'm very, very familiar with the OpenVMS
pseudo-terminal, and I've already dealt with the escape sequence problems. ;)

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2015-09-07 08:27:38 +0000, IanD said:

> I have an application EXE tool that runs and put's the output to the
> screen (smg)
>
> The problem is the tool will not exit unless a Control C/Y is entered
> (it scans for input for various functions)
>
> I would dearly love to capture the output to a file for future scanning
> for automation but am having issues figuring out how to do this

See if setting the terminal to a printer works; set that, then try
redirection with that output. Sometimes the tool will properly detect
that setting and will allow that output.

Others have suggested the pseudo-terminal morass. That'll allow you to
send the ^Y, too.

An analog to the pseudo-terminal morass captures the output via a
telnet or ssh stream, maybe using netcat or some emulator-specific
screen capture. The Unix expect tool can potentially be useful here,
too.

More effort is to start reversing the tool, and — for this case —
probably by intercepting the SMG calls made. Shim the SMGRTL image.
This is probably the most effective approach, as it produces data
without requiring the creation of a application-display-customized
control sequence parser.

Not having the source code is an impediment, not a prohibition.
Depending on exactly what the tool is doing, reversing or rewriting it
can be a viable option.

Binary reversing tools and I/O redirection are among the areas where
OpenVMS trails other platforms, unfortunately. Something like
srm_check — an Alpha disassembly tool that was provided with OpenVMS —
only gets you so far.

Above presumes that local laws and/or software licenses permit any of
this, etc.


--
Pure Personal Opinion | HoffmanLabs LLC

[IanD]

On Monday, September 7, 2015 at 10:37:30 PM UTC+10, Bob Gezelter wrote:
> On Monday, September 7, 2015 at 4:27:41 AM UTC-4, IanD wrote:

<snip>

>
> The possible solutions are limited by the fact that the program is a "black box", with the source code unavailable.
>
> There are two approaches that may allow you to address this problem, unfortunately, neither is trivial.
>
> First, one could use the scripting facility of a terminal program (e.g., Kermit) to programmatically interact with the program. There is a full book on Kermit which includes a description of its scripting capabilities.
>
> The second approach is to use the OpenVMS Pseudoterminal driver (see http://h71000.www7.hp.com/doc/84final/ba554_90018/ch06.html). This driver allows full programming of the dialogue. I do not know if there are issues with the combination of SMG and the pseudoterminal driver.
>
> - Bob Gezelter, http://www.rlgsc.com

Thanks

I had a bit (30 seconds) look at kermit and that would require an install by the looks - this is a production environment, cannot install anything without approval from someone at least 2 notches up from god himself - they are in fear of touching anything on this environment :-(

I'll have a look at the Pseudoterminal driver, probably outside of my league but I'll look never the less

On Monday, September 7, 2015 at 11:07:45 PM UTC+10, John Reagan wrote:

<snip>

>
> To add to Bob's comment about the pseudoterminal. Do you have DECset installed?
> DTM (DEC Test Manager) has some support to test screen-based applications. I'm
> not sure if the support includes the ability to "control-c/y" however.

No, nothing like that on this system :-(

> On Monday, September 7, 2015 at 11:14:09 PM UTC+10, VAXman- wrote:

<snip>

>
> Pseudo-terminals ought to keep him busy for a long while. If that SMG$ output
> does any screen manipulation, he'll have to handle escape sequences that would
> occur. Don't get me wrong, I too would suggest your pseudo-terminal approach
> but it's not something that will solve his problem without effort; especially,
> if Ian is not a programmer and he's never used the pseudo-terminal previously.
> Of course, I'm available for hire and I'm very, very familiar with the OpenVMS
> pseudo-terminal, and I've already dealt with the escape sequence problems. ;)
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>
> I speak to machines with the voice of humanity.

I'm not a programmer by profession, dabbled in a number of languages out of interest sake etc but never really written anything one could sell :-)

Did 6502, Z80, 68000 assembler when I was a young school kid, some Vax macro, C, C++, Prolog (barely), some Java and Python

Really only written routines as opposed to large scale application stuff. Self taught, so I know how to program all the wrong ways to hack something together

Love to hire you but the chances of anyone here paying for the skills I've seen you post elsewhere (didn't you look at adding loops to DCL?) are less than zero unfortunately

This is more of something I would like to do to make the systems here more robust and hopefully keep the cross-hairs off VMS for a while longer...

[Johnny Billquist]

If you are just interested in capturing what is coming out, then using
xterm and turn on logging. You'll get every byte in a file which you can
then sit and look at as you please.

Johnny

[Jan-Erik Soderholm]

Den 2015-09-07 kl. 17:33, skrev IanD:
> On Monday, September 7, 2015 at 10:37:30 PM UTC+10, Bob Gezelter wrote:
>> On Monday, September 7, 2015 at 4:27:41 AM UTC-4, IanD wrote:
>
> <snip>
>
>>
>> The possible solutions are limited by the fact that the program is a
>> "black box", with the source code unavailable.
>>
>> There are two approaches that may allow you to address this problem,
>> unfortunately, neither is trivial.
>>
>> First, one could use the scripting facility of a terminal program
>> (e.g., Kermit) to programmatically interact with the program. There is
>> a full book on Kermit which includes a description of its scripting
>> capabilities.
>>
>> The second approach is to use the OpenVMS Pseudoterminal driver (see
>> http://h71000.www7.hp.com/doc/84final/ba554_90018/ch06.html). This
>> driver allows full programming of the dialogue. I do not know if there
>> are issues with the combination of SMG and the pseudoterminal driver.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Thanks
>
> I had a bit (30 seconds) look at kermit and that would require an
> install by the looks - this is a production environment, cannot install
> anything without approval from someone at least 2 notches up from god
> himself - they are in fear of touching anything on this environment :-(
>
> I'll have a look at the Pseudoterminal driver, probably outside of my
> league but I'll look never the less

Note that the Python kit has support for Pseudo terminals
built-in. Here are some exemples:

http://www.vmspython.org/doku.php?id=vmsptdexample

Maybe you could run your EXE through that interface and
"remote control" it using the Python commands...

Jan-Erik.

[John Reagan]

SET HOST/LOG 0 will also capture something. Not sure if will be usable however

[Bob Gezelter]

IanD,

Actually, I had forgotten shimming the SMG shareable image as mentioned by Hoff. That may well be the cleanest approach, as it should eliminate most parsing of character streams.

The challenge is that it does require programming skills beyond basic.

John Gillings authored a technical paper on the general library-shimming approach. It can be found in the OpenVMS Technical Journal, Volume 7.

[Stephen Hoffman]

On 2015-09-07 16:04:51 +0000, Bob Gezelter said:

> Actually, I had forgotten shimming the SMG shareable image as mentioned
> by Hoff. That may well be the cleanest approach, as it should eliminate
> most parsing of character streams.
> The challenge is that it does require programming skills beyond basic.
>
> John Gillings authored a technical paper on the general
> library-shimming approach. It can be found in the OpenVMS Technical
> Journal, Volume 7.

Related: <http://labs.hoffmanlabs.com/node/1906>. The Shimmer tool
reads in the shareable image vectors, and then generates a stub image.

You'll have to tell it to keep the intermediate source files around
(via the command line), as the usual output is a stub shareable image
and the tool normally cleans up after itself.

You'd have to extend the stub source code by determining and then
parsing the arriving subset of SMG calls; calls that are originating
from within the application.

This approach will require some C coding, as the intermediate source
files are C and (for the build) DCL.

[Craig A. Berry]

On 9/7/15 10:51 AM, John Reagan wrote:
> SET HOST/LOG 0 will also capture something. Not sure if will be usable however

Or, if you don't have DECNet installed:

$ telnet/log=session.log localhost

[Jan-Erik Soderholm]

Den 2015-09-07 kl. 10:27, skrev IanD:
> I have an application EXE tool that runs and put's the output to the
> screen (smg)
>
> The problem is the tool will not exit unless a Control C/Y is entered
> (it scans for input for various functions)
>
> I would dearly love to capture the output to a file for future scanning
> for automation but am having issues figuring out how to do this
>
> i.e. tool :== "exe_location:image.exe"
>
> tool <displays output but sits there waiting for control C/Y>
>

To send a ctrl-C using the Python pseudo terminal interface, you simply:

execute(ptd, '<your image here...>')

then later:

ptd.write(ptdlib.KEYS["CTRL-C"])

There are a number of special keys predefined that can
be sent to the image runnng in the pseudo terminal.

ESC = chr(27)
KEYS = {
"F1" : ESC + "[11~",
"F2" : ESC + "[12~",
"F3" : ESC + "[13~",
"F4" : ESC + "[14~",
"F5" : ESC + "[15~",
"F6" : ESC + "[17~",
"F7" : ESC + "[18~",
"F8" : ESC + "[19~",
"F9" : ESC + "[20~",
"F10" : ESC + "[21~",
"F11" : ESC + "[23~",
"F12" : ESC + "[24~",
"F13" : ESC + "[25~",
"F14" : ESC + "[26~",
"F15" : ESC + "[28~",
"F16" : ESC + "[29~",
"F17" : ESC + "[31~",
"F18" : ESC + "[32~",
"F19" : ESC + "[33~",
"F20" : ESC + "[34~",
"HELP" : ESC + "[28~",
"DO" : ESC + "[29~",
"FIND" : ESC + "[1~",
"INSERT-HERE" : ESC + "[2~",
"REMOVE" : ESC + "[3~",
"SELECT" : ESC + "[4~",
"PREV-SCREEN" : ESC + "[5~",
"NEXT-SCREEN" : ESC + "[6~",
"UP" : ESC + "[A",
"DOWN" : ESC + "[B",
"LEFT" : ESC + "[C",
"RIGHT" : ESC + "[D",
"A-UP" : ESC + "[OA",
"A-DOWN" : ESC + "[OB",
"A-LEFT" : ESC + "[OC",
"A-RIGHT" : ESC + "[OD",
"PF1" : ESC + "[OP",
"PF2" : ESC + "[OQ",
"PF3" : ESC + "[OR",
"PF4" : ESC + "[OS",
"KP0" : ESC + "[Op",
"KP1" : ESC + "[Oq",
"KP2" : ESC + "[Or",
"KP3" : ESC + "[Os",
"KP4" : ESC + "[Ot",
"KP5" : ESC + "[Ou",
"KP6" : ESC + "[Ov",
"KP7" : ESC + "[Ow",
"KP8" : ESC + "[Ox",
"KP9" : ESC + "[Oy",
"MINUS" : ESC + "[Om",
"COMMA" : ESC + "[Ol",
"PERIOD" : ESC + "[On",
"ENTER" : ESC + "[OM",
"CTRL-A" : chr(1),
"CTRL-B" : chr(2),
"CTRL-C" : chr(3),
"CTRL-D" : chr(4),
"CTRL-E" : chr(5),
"CTRL-F" : chr(6),
"CTRL-G" : chr(7),
"CTRL-H" : chr(8),
"CTRL-I" : chr(9),
"CTRL-J" : chr(10),
"CTRL-K" : chr(11),
"CTRL-L" : chr(12),
"CTRL-M" : chr(13),
"CTRL-N" : chr(14),
"CTRL-O" : chr(15),
"CTRL-P" : chr(16),
"CTRL-Q" : chr(17),
"CTRL-R" : chr(18),
"CTRL-S" : chr(19),
"CTRL-T" : chr(20),
"CTRL-U" : chr(21),
"CTRL-V" : chr(22),
"CTRL-W" : chr(23),
"CTRL-X" : chr(24),
"CTRL-Y" : chr(25),
"CTRL-Z" : chr(26),
}


If I had the EXE I could try it...

[VAXman-]

All these methods (/LOG) will, indeed, capture the output; however, I believe
that the OP needs to known when a particular line of his application's output
occurs such that a corresponding CTRL-C or CTRL-Y can be sent as input to the
application.

[David Froble]

Control

Peek and Spy

Others

[David Froble]

Damn greedy consultant! And you'll probably use your ill gotten gains on silly
things such as mortgage, food, and such ....

:-)

[VAXman-]

>Control

THat's CONTRL. ;)

[David Froble]

What do you expect from a senile old geezer ?

:-)

[VAXman-]

>>> Control
>>
>> THat's CONTRL. ;)
>>
>
>What do you expect from a senile old geezer ?
>
>:-)

CONTRL would capture everything sent to the terminal -- output and input, if
so desired. However, there's still the issue of responding with a CTRL-C or
CTRL-Y when specific output (a prompt, for example) is encountered. CONTRL,
and your other suggestion, are not freeware either -- not that I wouldn't be
happy to see a CONTRL sale made in this case. The OP could easily solve his
specific problem with a pseudo-terminal without the expansive features CONTRL
extends to its user.

[Jan-Erik Soderholm]

I have now tested the "example 3" on:
http://www.vmspython.org/doku.php?id=vmsptdexample
that runs a MONITOR session (exit with ctrl-Z) and a
RMU/SH STAT session (exit with an "E") and it runs OK.

The Python script creates a log file with all output.
Yes, a lot of ESC sequences, but that can be handled.
The ESC charactes are replaced with "\x1b" and CR/LF/TAB
with \r, \n and \t, but that can be replaced later.

The MONITOR part looks like this:

----------------------------------------------
execute_until(ptd, 'monitor system/all', 15)
print >>fo, '-' * 50
for line in ptd.screen():
print >>fo, line
print >>fo, '-' * 50

ptd.write(ptdlib.KEYS['CTRL-Z'])
lines = ptd.read_until_prompt()
for line in lines:
print >>fo, repr(line)
----------------------------------------------

"15" is a timeout value but you could also "timeout" by
reading the output and search for some string or whatever...

The CTRL-Z is sent to whatever image is running by
the pseudo terminal.

If it was me, I'd try to run the actual EXE using this.

Regards,
Jan-Erik.

[David Froble]

Personally, I'm a bit of a control (sic) freek. I like to be able to control
what's happening, not just what some utility, such as CONTRL, allows. So for
myself, I'd first consider re-writing the app, and second I'd consider the
pseudo-terminal solution.

The problem with either is that not everyone has the time, aptitude, and / or
capability to do either of the above, thus third rate (or worse) solutions.

[Jan-Erik Soderholm]

> or capability to do either of the above,...

My test with the pseudo-terminal feature in the Python kit
took 5-10 ninutes and I know nothing about pseudo terminals
in general. I just copied the example code.

I think IanD at least should concider that solution.


Jan-Erik.

[David Froble]

This would assume that he has the Python product already available, or, if he
can get permission to install such. Sometimes it's not all under someone's
control (sic).

Nor is it clear that if he wrote something that he'd be allowed to use it.

Consider, those who might want VMS gone might be able to handicap it with such
regulations.

[Jan-Erik Soderholm]

Everything assumes something... :-)

I'm only pointing to a solution that seems to solve the problem.
IanD can use it, or not.

[johnwa...@yahoo.co.uk]

Surely (!) depending on the circumstances and objectives, the Python
pseudo-terminal stuff doesn't need to run on the VMS box, just needs
to run somewhere which does have access (telnet/ssh?) to the VMS box?
Much the same as one might do with a PC-based or UNIX-based terminal
emulator? Or have I misunderstood? Or are there pieces of this
picture that aren't yet fully described?

IF remote access from Python somewhere other than the VMS host system
is an option, it might simplify some aspects of the challenge.

Or it might be irrelevant.

[Jan-Erik Soderholm]

Hm, no. The pseudo terminal is created on the same system as where
the Python script is running. There is no network involved.

On the other hand, the Python install is dead-simple.

- Put two files (LD container files) on your system.
- Connect them with LD CONNECT and MOUNT the disks.
- Run two COM files (creates a few logicals and symbols)
- Run the script or use Python in any other way.

Nothing is "installed" on the system. Deassign the logicals and
delete the two LD files and the Python envoronment is "gone"...

[John Reagan]

On Tuesday, September 8, 2015 at 2:54:13 PM UTC-4, Jan-Erik Soderholm wrote:

> On the other hand, the Python install is dead-simple.
>
> - Put two files (LD container files) on your system.
> - Connect them with LD CONNECT and MOUNT the disks.
> - Run two COM files (creates a few logicals and symbols)
> - Run the script or use Python in any other way.
>
> Nothing is "installed" on the system. Deassign the logicals and
> delete the two LD files and the Python envoronment is "gone"...

The "second" COM file defines a TEMP logical name that pisses off many
other things (like my LLVM configure/make file).

Also, trying to share LD containers in a cluster needed some extra magic
in my SETUP.COM file to not always try to create the LD units.

Besides that, worked just fine.

[VAXman-]

In article <msn1am$fs9$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <mslfr5$7qv$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>>> VAXman- @SendSpamHere.ORG wrote:
>>>> In article <mskhnp$22q$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>>>>> IanD wrote:
>>>>>> I have an application EXE tool that runs and put's the output to the screen (smg)
>>>>>>
>>>>>> The problem is the tool will not exit unless a Control C/Y is entered (it scans for input for various functions)
>>>>>>
>>>>>> I would dearly love to capture the output to a file for future scanning for automation but am having issues figuring out how to do this
>>>>>>
>>>>>> i.e.
>>>>>> tool :== "exe_location:image.exe"
>>>>>>
>>>>>> tool <displays output but sits there waiting for control C/Y>
>>>>>>
>>>>>> I have tried...
>>>>>>
>>>>>> - define sys$output doesn't work, wait's for control C/Y to exit
>>>>>> - pipe doesn't work because it has the same issue as above
>>>>>> - spawn is equally of no help nor is run/detach
>>>>>> - ssh didn't help either, the screen became totally unresponsive
>>>>>> - pipe tool < x.x but that didn't work either (error message about couldn't initialize cursors). I was trying to pipe into the EXE a file x.x (with the idea of adding Control C/Y to a file, didn't know how to add Control C/Y to the x.x file anyhow)
>>>>>>
>>>>>> I thought perhaps some type of set host / log to the same node to execute the command and then having the process killed as a long shot but gave up
>>>>>>
>>>>>> I do not have access to the source code so I cannot re-code the functionality
>>>>>>
>>>>>> Is there some wrapper code (I'd even take Jazz, Electro Swing, but not heavy metal, my days of that are well and truly over!) out there that I can encapsulate this in perhaps to make it think it's writing to a screen device when it's not or some ot

>>>>> Control
>>>> THat's CONTRL. ;)
>>>>
>>> What do you expect from a senile old geezer ?
>>>
>>> :-)
>>
>> CONTRL would capture everything sent to the terminal -- output and input, if
>> so desired. However, there's still the issue of responding with a CTRL-C or
>> CTRL-Y when specific output (a prompt, for example) is encountered. CONTRL,
>> and your other suggestion, are not freeware either -- not that I wouldn't be
>> happy to see a CONTRL sale made in this case. The OP could easily solve his
>> specific problem with a pseudo-terminal without the expansive features CONTRL
>> extends to its user.
>>
>
>Personally, I'm a bit of a control (sic) freek. I like to be able to control
>what's happening, not just what some utility, such as CONTRL, allows. So for
>myself, I'd first consider re-writing the app, and second I'd consider the
>pseudo-terminal solution.
>
>The problem with either is that not everyone has the time, aptitude, and / or
>capability to do either of the above, thus third rate (or worse) solutions.

Well, my offer to the OP to code this up still stands and I don't do things
third rate. I do, however, charge a rate.

[VAXman-]

Python is a lot of weigh for what could be a very simple and small program
to control the OP's app.

[Jan-Erik Soderholm]

That "weigh" is of minor importance today, you don't see it and it doesn't
matter on todays systems. In particular for a quick one-off type of issue
such as in this case...

No reason to write something that already has been written.

[VAXman-]

In article <msos1q$9jb$1...@news.albasani.net>, Jan-Erik Soderholm <jan-erik....@telia.com> writes:
>Den 2015-09-09 kl. 00:51, skrev VAX...@SendSpamHere.ORG:

>That "weigh" is of minor importance today, you don't see it and it doesn't

Yeah, I missed the 't'; typing too fast when making a quick reply.

>matter on todays systems. In particular for a quick one-off type of issue
>such as in this case...
>
>No reason to write something that already has been written.

I was referring to the Python package as a whole. The 'libraries' alone are
massive.

[Jan-Erik Soderholm]

He he, I actualy googled it and thought that "weigh" was the
correct spelling. I hope that you didn't thought that I was
pointing fingers with the ""... :-)

>
>
>> matter on todays systems. In particular for a quick one-off type of issue
>> such as in this case...
>>
>> No reason to write something that already has been written.
>
> I was referring to the Python package as a whole.

So did I. A non issue for a one-off quick-fix...

> The 'libraries' alone are massive.

They are mostly just stored on disk as "modules" and only
loaded in to memory when "imported" by the Python script.



>

[Phillip Helbig (undress to reply)]

In article <165ce149-3555-4c68...@googlegroups.com>, John

Reagan <xyzz...@gmail.com> writes:

> The "second" COM file defines a TEMP logical name that pisses off many
> other things (like my LLVM configure/make file).

Then both are behaving badly. Applications should define logical names
with unique prefixes, for example.

[Jan-Erik Soderholm]

They are both behaving as expected out there in the big world. :-)
TMP, TEMP and TMPDIR are standard environment variables for
scratch storage.

[Phillip Helbig (undress to reply)]

In article <msq74g$a1$1...@news.albasani.net>, Jan-Erik Soderholm

> They are both behaving as expected out there in the big world. :-)
> TMP, TEMP and TMPDIR are standard environment variables for
> scratch storage.

At least on VMS, defining global symbols or logical names without making
them unique to the application via a prefix or whatever is just bad
programming practice. Something written with VMS in mind would probably
just use SYS$SCRATCH; that's what it's for.

[Jan-Erik Soderholm]

> ...Something written with VMS in mind...

Right, if we should limit us that much. :-)
But then we wouldn't have very much to run on our systems.

B.t.w., current Python kits uses TMPDIR which I think has
superseded TEMP and TMP as the standard environment variable.

[Craig A. Berry]

On 9/8/15 1:24 PM, David Froble wrote:
> Jan-Erik Soderholm wrote:

>> My test with the pseudo-terminal feature in the Python kit
>> took 5-10 ninutes and I know nothing about pseudo terminals
>> in general. I just copied the example code.
>>
>> I think IanD at least should concider that solution.

>

> This would assume that he has the Python product already available, or,
> if he can get permission to install such.

I think he's already said he can't install anything. However, the Python
kit is all self-contained on a disk image. One can leave it as an LD
disk, put it on a thumb drive, etc., use it from there, and then remove
it when the exercise is complete. Whether using some files temporarily
and then removing them would be considered an "installation" by the
bureaucracy in question is not something we can answer for him.

[Louis Krupp]

On Mon, 7 Sep 2015 01:27:38 -0700 (PDT), IanD <iloveo...@gmail.com>

wrote:

>I have an application EXE tool that runs and put's the output to the screen (smg)
>
>The problem is the tool will not exit unless a Control C/Y is entered (it scans for input for various functions)
>
>I would dearly love to capture the output to a file for future scanning for automation but am having issues figuring out how to do this
>
>i.e.
>tool :== "exe_location:image.exe"
>
>tool <displays output but sits there waiting for control C/Y>
>
>I have tried...
>
>- define sys$output doesn't work, wait's for control C/Y to exit
>- pipe doesn't work because it has the same issue as above
>- spawn is equally of no help nor is run/detach
>- ssh didn't help either, the screen became totally unresponsive
>- pipe tool < x.x but that didn't work either (error message about couldn't initialize cursors). I was trying to pipe into the EXE a file x.x (with the idea of adding Control C/Y to a file, didn't know how to add Control C/Y to the x.x file anyhow)
>
>I thought perhaps some type of set host / log to the same node to execute the command and then having the process killed as a long shot but gave up
>
>I do not have access to the source code so I cannot re-code the functionality
>

>Is there some wrapper code (I'd even take Jazz, Electro Swing, but not heavy metal, my days of that are well and truly over!) out there that I can encapsulate this in perhaps to make it think it's writing to a screen device when it's not or some other simple way of doing this?

There was a time when I might have known how to do this on VMS, but
since you're (presumably) dynamically linking to the SMG library,
could you write your own with the same SMG$ entry points and make the
program link to that? Your SMG functions could write their arguments
to a file that you would specify and return the expected status code.
You might not have to redefine SYS$OUTPUT, which would make things
easier, and your output file would tell you what the program was
trying to do.

Louis

[Louis Krupp]

On Wed, 09 Sep 2015 21:54:42 -0600, Louis Krupp
<lkr...@nospam.pssw.com.invalid> wrote:

<snip>

>There was a time when I might have known how to do this on VMS, but
>since you're (presumably) dynamically linking to the SMG library,
>could you write your own with the same SMG$ entry points and make the
>program link to that? Your SMG functions could write their arguments
>to a file that you would specify and return the expected status code.
>You might not have to redefine SYS$OUTPUT, which would make things
>easier, and your output file would tell you what the program was
>trying to do.

Sorry; I went back and read the rest of the thread, and I see that
people who really know this stuff have already mentioned shimming the
library. (I never knew that was the word for it.)

Louis

[Jan-Erik Soderholm]

You can also put the two LD files in your local "home" directory and
run Python in your own process using process logicals and so on.
Nothing is seen system wide on the system.

See "Process installation" here:
http://www.vmspython.org/doku.php?id=downloadandinstallationpython

Time for IanD either to try it or to ditch it... :-)

[Phillip Helbig (undress to reply)]

In article <msptq1$21le$1...@news.kjsl.com>,
hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))

writes:

> In article <165ce149-3555-4c68...@googlegroups.com>, John
> Reagan <xyzz...@gmail.com> writes:
>
> > The "second" COM file defines a TEMP logical name that pisses off many
> > other things (like my LLVM configure/make file).
>
> Then both are behaving badly. Applications should define logical names
> with unique prefixes, for example.

I have no idea why the above article showed up as unread today:

From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to
reply))
Newsgroups: comp.os.vms
Subject: Re: Direct screen output from an EXE to a file (Alpha, 7.3-2)
Date: Wed, 9 Sep 2015 18:29:21 +0000 (UTC)
Organization: Multivax C&R
Lines: 9
Message-ID: <msptq1$21le$1...@news.kjsl.com>

It's been more than a year!