2

I tried to look everywhere what the function/system call sys$cli does.

I am using Vax 7000 machine, which has the openVMS v6.2 operating system, so I am not sure the newer versions of VMS/VAX has it, but even if they do - I couldn't find any source about this call. I found sys$get and sys$put , I even found cli$ commands, but not sys$cli.

Is anybody familiar with this function and can give me a documantation of it or link to a documantation?

UserB95
  • 121
  • 2
  • 1
    It is described as "mostly undocumented" [here](http://labs.hoffmanlabs.com/node/1264). – HABO Feb 11 '16 at 21:15
  • 1
    @HABO That is a little helpful... Sounds weird that there is no full specification of this anywhere... – UserB95 Feb 12 '16 at 01:56
  • 1
    If you put it in the same line as SYS$GET and SYS$PUT then to be frank you probably have no clue what you are talking about: Put the knife down and back-out slowly with your hands where we can see them. Seriously - WHY do you care? WHATproblem are you trying to solve? SYS$CLI is unlikely to be the answer. Is this about existing code failing? Cheers, Hein. – Hein Feb 13 '16 at 16:43
  • 2
    @Hein I need to implement this system call for something I cannot elaborate about. If you have a documentation/implementation of this system call I'll be happy if you can share it here :) – UserB95 Feb 13 '16 at 17:08
  • 1
    Nonsense. Of course you can elaborate. You just have to spend some energy to figure out how to share enough, but not too much to increminate your self or whatever the hold-back might be. If you refuse to provide information that allows folks to try to help, then I suggest you get hold of some sources/listings and figure it out by yourself. Good luck – Hein Feb 13 '16 at 17:45
  • @Hein If I could find some it would be awesome, but I tried (actually even a senior of mine tried before he left the company - but he didn't succeed) What I *CAN* say is I need to traslate sys$cli to linux system calls (since I am trying to translate some program to run on a newwer environment) – UserB95 Feb 13 '16 at 17:51
  • So there is existing code, not broken, but it is not clear what the code is supposed to do, thus making it hart to port. My guess is it to implement LIB$SPAWN before that became avaiable. One approach could be to use a 'STRINGS' program on the executable to see if that gives clues for commands, symbols or logicals. Can you re-link the application? Perhaps you can add a fake SYS$CLI to link egainst and figure out the arguments and from there the intent? – Hein Feb 13 '16 at 23:29
  • If I remember correctly, SYS$CLI is a supervisor mode system service. I believe only Kernel and executive mode System Services were documented. There are many wrappers around SYS$CLI. For example, I believe all the functions described in the Command Definition Utility invoke SYS$CLI. The reason it is not documented is that there was some expectation that there would be multiple CLI's supported at some time in the future. – user3344003 Mar 20 '16 at 04:24
  • SYS$CLI is (was) a system service call to determine the Command Language Interpreter an executable was currently using. One had to write the program to change its mode to Supervisor (which required prvileges natch) and then SYS$CLI would (should) work. Supervisor mode was a beautiful concept never fully utilised by DEC which would allow the VMS to run command language interpreters other than DCL at the same time as DCL. For example Unix, MS-DOS (aargh) etc. etc. Us software engineers loved the concept, DEC Management hated it 'cos they thought it would wean customers away from DEC ... – Richard Hammond Mar 12 '18 at 20:03

0 Answers0