[Info-vax] Command Procedure Pipe output to a variable

[cao...@pitbulluk.org]

On Tuesday, August 31, 2021 at 12:05:19 PM UTC+1, HCorte wrote:
> A terça-feira, 31 de agosto de 2021 à(s) 11:43:30 UTC+1, cao... at pitbulluk.org escreveu: 
> > On Tuesday, August 31, 2021 at 10:49:46 AM UTC+1, HCorte wrote: 
> > > Implementing a command procedure that first obtains the device allocated to a process for example purposes called YYYYYY. 
> > > 
> > > How to output the results of (SEARCH SYS$INPUT "Devices allocated") to the variable DEVICEAUX tried (READ SYS$PIPE DEVICEAUX) but with no success. 
> > > 
> > > $ pipe SH PROCESS YYYYYY | SEARCH SYS$INPUT "Devices allocated" | (READ SYS$PIPE DEVICEAUX) 
> > > $ WRITE SYS$OUTPUT DEVICEAUX 
> > > $ DEVICE_AUX = F$EDIT(F$ELEMENT(1, ":", TEST),"TRIM") 
> > > $ WRITE SYS$OUTPUT DEVICE_AUX 
> > > 
> > > can make it work to write to a file 
> > > $ pipe SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" > DEVICEAUX.DAT 
> > > 
> > > but would prefer to avoid having to write and read from file if possible, also in command procedure should alls use SYS$PIPE instead of SYS$INPUT? 
> > The search will only ever return the device name of the most recently allocated device to the process YYYYYY, which will most likely be your pipe device MPAx: because the devices are listed on separate lines. 
> > DEVICEAUX is set in the context of the subprocess created by the pipe so the main process running the script will never see it. 
> > 
> > What is the problem you are trying to solve? 
> >
> > Keithremote 
> 
> Thanks Keith then for now gona go with the solution of writing to a file, in this case for this process the list of devices will alls be one and don't expect to be more. This Devices allocated will serve for matching for the command (sh network "tcp/ip" /full) the column Device_socket and retrieve the value/ip in column Remote Host.

There may be an ACP style I/O function you can do to query the list of open connections and what processes are connected to them. I vaguely recall doing something similar a long time ago with DECnet and its NETACP. You could also possibly listen for audit or alarm events for network logins and grab the data that way - you'd get the source and the process ID involved. Just a thought.