home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 263,935 of 264,096   
   =?UTF-8?Q?Arne_Vajh=C3=B8j?= to Brian Schenkenberger   
   Re: [Info-vax] DCL2   
   07 Dec 25 12:09:57   
   
   From: arne@vajhoej.dk   
      
   On 12/6/2025 3:47 PM, Brian Schenkenberger wrote:   
   > On Dec 6, 2025, at 15:23, Arne Vajhøj via Info-vax    
   > wrote:   
   >> I have always wanted something like:   
   >>   
   >> dcl.init() # open pseudo terminal   
   >> res1 = dcl.do(command1) # send command to pseudo terminal and return   
   >> output   
   >> ...   
   >> resn = dcl.do(commandn) # send command to pseudo terminal and return   
   >> output   
   >> dcl.close() # close pseudo terminal   
   >   
   > PTD$ routines exist today.   
      
   I know.   
      
   >                                 However, you’d need a process with DCL   
   mapped   
   > connected   
   > with the pseudo-terminal to execute the command you pass to it.   
      
   I know.   
      
   >                                                                   You’d be   
   > no better off   
   > than if you used a PIPE because that process is NOT the process for   
   > which you may be   
   > seeking the information (ie. SHOW PROCESS).   
      
   That model would mean a Python process and a DCL process. A   
   process duo.   
      
   And yes that could be a problem in some cases.   
      
   But in most cases I would expect both to either not be   
   interested in processes or be interested in other processes   
   than themselves.   
      
   > I really had to bend over backward to have my DCL debugger work in/with   
   > the current   
   > process because I wanted to be able to debug DCL in the process   
   > environment where a   
   > problem may persent itself. (eg. quotas, rights, privileges, defaults,   
   > etc.) Debugging DCL   
   > in a BATCH or NETWORK process was another goal. Debugging DCL in   
   > environments   
   > that are NOT interactive are quite different and there are often   
   > problems that the author   
   > doesn’t see until his|her procedure is executing in those environments.   
      
   DCL debugger is probably a bit different. It is by definition interested   
   in its own process. More difficult problem I think.   
      
   More advanced requirements means more advanced solution needed.   
      
   BTW, what is status of your DCL debugger? Commercial available?   
   Free available? Sitting on the shelf?   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca