home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20150 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  2.2 KB
  1. Path: sparky!uunet!gatech!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: Passing parameters to detached processes.
  5. Message-ID: <9212301623.AA19674@uu3.psi.com>
  6. Date: 30 Dec 92 15:11:51 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 51
  10.  
  11.  
  12.     In article <1992Dec29.020155.5303@news2.cis.umn.edu>, 
  13.     rao@moose.cccs.umn.edu (Rao Akella) writes:
  14.     >
  15.     |>
  16.     |>I'm running a command procedure in a detached process, invoking it
  17.     |>as follows:
  18.     |>
  19.     |>    $ RUN SYS$SYSTEM:LOGINOUT/INPUT=PROC.COM/OUTPUT=PROC.OUT/DETACH
  20.     |>
  21.     |>Is there any way to pass parameters to PROC.COM?
  22.     |>
  23.  
  24.     Not through the RUN command.  Some alternatives.
  25.  
  26.         1.  Specify /INPUT=PROC2.COM which contains the line:
  27.  
  28.             $ @PROC parameters
  29.  
  30.     2.  Use SUBMIT/PARAM
  31.  
  32.     3.  Use SPAWN (though you can't get a detached process this way.)
  33.  
  34. 1-3 work just fine.
  35.  
  36.     4.  Use /ERROR="parameter string" and translate SYS$ERROR in the
  37.         procedure to retrieve the parameters.  You should probably
  38.         then do a $DEFINE SYS$ERROR SYS$OUTPUT.  This is a hack and
  39.         not something I'd recommend.
  40.  
  41. Not only that, but in the case at hand, it doesn't work; what you'll find in
  42. SYS$ERROR is a PPF that's the same as SYS$OUTPUT.  (I'm not sure exactly who
  43. "fixes this up" and where, but the original value of /ERROR is simply not
  44. accessible by the time LOGINOUT gives the command file control.)
  45.  
  46. You CAN pass a small amount of information through by setting the process
  47. name - but PROC.COM would have to know enough to look for the information
  48. there.  If I'm reading the original question correctly, what's desired is a
  49. way for the information to appear in PROC's P1-P8, exactly as it "normally"
  50. does.
  51.  
  52. Passing information through the process name is also a hack, and requires care
  53. to avoid chosing a name that conflicts with an existing process (in which case
  54. the proposed name would be ignored" - but while it's an "unexpected" use of a
  55. documented, supported interface, I'd have to call it documented and supported
  56. nontheless.
  57.  
  58. Note that running LOGINOUT to map the CLI in this way is itself undocumented
  59. and unsupported....
  60.                             -- Jerry
  61.  
  62.