Exiting Command Procedure

[Joseph Dellwo]

I'm a newbie so bear with me.
This is probably simple but I can't find the answer anywhere. We run a program called Promis (pcl) which allows users to run .com files but otherwise they don't interact directly with VMS. I've written a Command Procedure that will then run a script back in Promis, ie:
$ pcl @hivac:HIVAC
Now they are back in Promis but my Procedure is still running.
My question is, Is there a way to issue a command and exit the procedure without having to quit Promis and return to DCL to allow the procedure to continue. Leaving it running causes problems later.
I hope this makes sense. I've attached my .com file.

Thanks, Joe

[Aaron Lewis_1]

Joe, you would need to keep Promis in control of the stream of events, it should execute the DCL, then return. When you re-run the PCL script from DCL, the DCL procedure is in control, and will continue to run until the user exits from Promis, then exits from DCL.

How are calling this from Promis, does it support a 'shell' or 'spawn' command?

[Jan van den Ende]

Joe,

As a start, let me elcome you to the VMS Forum!

please rename any attachments to .COM before posting!

Proost.

Have one on me.

jpe

[Aaron Lewis_1]

Jan, I think you meant to say:

Please rename to .TXT before posting.

[Arch_Muthiah]

Joe,

No idea about your pcl program.

You have problem with only this .com procedure? or with all com procedure?

In this "$pcl @hivac:HIVAC", is HIVAC your .COM file?, if that is the case, you did not pass the value for P1.

When you run your .com procedure you attached, displayed any message on the terminal?

What is the "status" of your .com procedure which keeps running?

Try running small .com procedure with only one statement like
$ write sys$output f$time()
$ exit

Also I would suggest you to change the
" $ on error then goto xraise" as
" $ on warning then goto xraise"

just trial only, because no idea about your pcl program

Archunan

[Arch_Muthiah]

Joe,

I think your pcl has been designed only to run DCL procedure only. The purpose of the pcl program design may be to avoid giving direct DCL access to any user.

Btw, does your system shows that .com procedure is in "running" state or "scheduled" state.?

Archunan

[Joseph Dellwo]

I've attached it as txt.

Thanks for your quick responses.
I've tried spawn and pipe but back in Promis I lose the command prompt. It acts like I have two things competing for my inputs.

When people login they don't even see VMS, they go straight into Promis (started with pcl). HIVAC.scr is the script which calls this file,implant.com, and passes the P1 to it. The command I mentioned in my first message was to return to Promis and run the script again so folks can select another .com file to run.
----
Just read Archunan's message.
PCL has a menu item to run "user commands" which is how my script calls my DCL Procedure. How do I check the procedure state?
Thanks, Joe

[Jan van den Ende · Accepted solution]

Joe,


The command I mentioned in my first message was to return to Promis and run the script again so folks can select another .com file to run.


And now, the real question is, does RETURN actually mean that this CAN be returned to?
ie, is the statement before the return point some incarnation of SPAWN ( CALL LIB$SPAWN maybe?) or is it some kind of chaining (like CALL LIB$DO_COMMAND )?

If SPAWN, then replace
$ pcl @hivac:hivan
by ...
$ LOGOUT

Your description of the symptoms ARE consistent with this scenario.

A quick test would be a
$ SHOW PROC /ALL/ID=

If this shows more than 1 process in the Process Tree, I suspect this is the case.

However, DO inspect the code of the Promis program: it should be able to HANDLE a true RETURN as generated by a subprocess LOGOUT.

DISCLAIMER:
Most of this is speculation based on too little info and too little ( = NO !) knowledge of Promis, so: NO WARRANTY!!


hth

Proost.

Have one on me.

jpe

[Joseph Dellwo]

It says "There is one process in this job"
If I replace the command with Logout it logs me out of the system.

The problem is when I run this several times I'll get the "command procedures too deeply nested" message. I'm using Set Verify and if I return to Vax I see it spit out the last comands in my file then run the exit handler as many times as my file was run.

I have several points where I'd like my file to exit and run a Promis script. I'll probably have to find a workaround with some extra promis scripts. This little command file replaces about a hundred script so I'll live with this if I have to.

Thanks, Joe

[Arch_Muthiah]

Joe,

I hope the "$exit" command in your procedures makes promis to exit.

Could try this one more time, that is...
1. Remove "$exit" from the procedure

that is...
....
$ exit ------- Remove this
$ END:
$ pcl @hivac:HIVAC

and make sure all your other procedures
(@hivac:implant_ENTER2
@hivac:implant_ENTER3
@hivac:implant_ENTER4,,,etc.)
have "$ pcl @hivac:HIVAC" command at the end, and remove any "$exit" statements in these procedures.

Hope this will help to keep promise session alive.

Archunan

[Jan van den Ende]

Joe,

so it looks like the command procedure is being Chained.
The main charactaristic:

@comfile, which runs HIVAC, giving control to the comfile, which @comfile ... in the next level of nesting.
Several rounds of that, and you are too deeply nested.
This construct is definitely a programming error.
The true cure would be to modify HIVAC.EXE to give control to DCL by SPAWNing it (calling xxxSPAWNxxx in whatever syntax used by the language HIVAC is written in), and looping back to the functional starting point of the program after SPAWN returns.
Depending on the need to use settings of the current process, there MAY be a solution if you put
$ pcl @hivac:HIVAC
in a separate .COM file, and replace that line in your script by:
$ RUN SYS$SYSTEM:LOGINOUT /INPUT=
$ LOGOUT

This starts a new (top level) process, in which your PCL command gets executed, and then stops the current.
But: NO settings like logicals, symbols, whatever are transfered to the new process. If they are not needed, you are home safe, but if you need to feed some of them to the new process, it becomes a whole new ballgame!

Success.

Proost.

Have one on me.

j[e

[Joseph Dellwo]

I do pass symbols back to a script file but I wanted to see how this works. I created implantjoe.com with my command and modified the original as you said and it just logs me out. It doesn't try to run the new com file. Show Process says 20E5BA1C is nonexistant.

$ END:
$ RUN SYS$SYSTEM:LOGINOUT /INPUT=implantjoe.com
%RUN-S-PROC_ID, identification of created process is 20E5BA1C
$ logout
ENG40 logged out at 2-DEC-2005 12:02:15.94

[Arch_Muthiah]

Joe,

could you please try my previous (posting)suggesions of removing $exit and adding $ pcl @hivac:HIVAC at the end each of your com procedure.


Archunan

[Joseph Dellwo]

Sorry Archunan,
that's the way I've had it for a while. Anyway, several other similar commands are in the middle of my com file. Either way, no difference.

Thanks, Joe

[Hein van den Heuvel]

WAG:
I get the impression you just need to replace that last "pcl @hivac:HIVAC"
with a straight 'exit'.

Hein.

[Arch_Muthiah]

Joe,

My assumptions was that your "pcl script" is capable of handovering any COM procedure to VMS CLI, then it dies itself. So your COM procedure should again invoke this "pcl script" at the end before it exits out of VMS.

I found there is a $exit command before $END:
Because of this $exit, you are unable to execute "$pcl @hivac:HIVAC" and bring back promis menu.

Or when your other procedures finshes execution, it exits from the session, instead of invoking "$pcl @hivac:HIVAC".

As per my understanding your current COM procedure never executes "$pcl @hivac:HIVAC" to keep your promis session alive unless you choose 'X'option. The same thing happes when you pass other COM procedure also.

Joe, can you send any of your other COM procedure?, because I don't suspect your promis script, but no surprise it does not give DCL prompt to the user.

Archunan

[Joseph Dellwo]

Archunan,
I'm afraid I don't quite follow you.
The "$pcl @hivac:HIVAC" and the other $pcl commands execute as I have planned in writing the procedure. If I hit X it goes to the END: label and runs the HIVAC script. I put the exit before that for good measure so if the procedure gets to the end of the ENTER: section it will exit before the END: label.

When I'm testing your suggestions I'm sending it straight to END: and it never sees the $exit you're worried about. As you can see in my last message it ran Loginout.

[Hein, if I just do a straight exit I'll just leave my users at a dcl prompt]

Anyway, don't waste anymore time on it. It does what I want, much better than the previous scripts. There's no real problem in usage. I just wanted to make it a little more elegant. Thanks for your help. I've learned a lot.

--joe