Hello,
I have not used MVbase is a very long time. I need to create a phantom
for a quick project. have looked in the manuals, but they don't have an
example I can simulate.
I have a program that I want to run at 1:00 am everyday. How can I
start a phantom using the LOGON command? Here is what I have done so
far.

created account SSFL
created program file SSFL.BP
created program SSFL.XML

How can I create a phantom with the above info? Any help will be
appreciated.

Pete

In D3 you would enter from tcl in the SSFL account, assuming your program is
cataloged:

z SSFL.XML


"mdsi2000" <mdsi2000 (AT) yahoo (DOT) com> wrote

Pete,

We run our daily FILE-SAVE as a scheduled phantom this way.

First create a login PROC that sleeps until 1:00am, runs your program,
and then loops, e.g.:

SSFL-PHANTOM
001 PQ
002 10 C begin loop
003 HSLEEP 01:00:00
004 P
005 HSSFL.XML (or whatever CATALOGed program you want to run)
006 P
007 GO 10

Then create a Q-pointer to the SSFL account in the SYSTEM dictionary
with the same name as the login PROC:

SSFL-PHANTOM
001 Q
002 SSFL
003
004
005
006
007 <same encrypted password as SSFL>
008 <same privilege level as SSFL>
009 L
010 10

Then start it up using LOGON:

It will run until the next time you boot mvBASE. You can also watch or
interact with it using the TANDEM verb:

Good luck!

David,
This is exactly what I was looking for! Thank you.

Peter Gonzalez

David,

I don't know mvBase, but doesn't your method burn a user license? Phantom
processes do not, at least in D3. Does mvBase support phantoms?


"David Ousele" <deva (AT) oregoncoast (DOT) com> wrote

We use "phantoms" to do backups and other nightly data transfers.
process. We then disconnect from the tandem and then do an UNLINK-LINE
lineno.
This doesnt consume a "user". We have our max num of users logged in
and have 3 phantom processes running without a problem.

Mark

No, shouldn't burn a licence on mvbase... Only "real" connections do, if I
recall correctly..

Regards
Simon
"Jeffrey Kaufman" <jkaufman (AT) keydata (DOT) us> wrote

<markm66 (AT) gmail (DOT) com> wrote

Yes this is true, caveat... you need to setup the system with 'extra'
processes at boot time. As pointed out earlier, these will not use seats
since they cannot be attached externally. mvBase uses the Mentor method of
separating processes and ports. Essentially this means that the logical
processes need not be attached to a physical 'port'. In the old days these
were serial connections of some sort, but the IP connections follow the same
limitations.

Look at the LIST-LINE-CHARS (or LLC) output from tcl to see if you have any
extra processes available. These would show up at the end of the list with
processes shown in the column headed 'process' without any companion port
listed in the 'port' column. If you don't see any of these, change your
setup in the mvBase administrator to a higher number of processes and
restart your mvBase engine. This will allow you to access these extra
processes without affecting your 'seats'.

Then using the mvBase tcl commands 'UNLINK-LINE', 'LINK-LINE', 'CONVERSE',
and 'TANDEM' you can connect physical port 10 to logical process 5, for any
reason (temporary execution needs usually.) Then communicate to it through
a standard connection session already in use (to execute the tcl command.)
Converse will communicate with a port, while
Tandem will communicate with the process. The SEND/GET databasic logic can
also be used to communicate with these processes under program control.
Note; the mentor option (C) to the 'PROTOCOL' command to clear the input
buffer can come in handy to smack one of these headless zombies which may
misbehave at times.

I have a phantom batch update processor that was originally implemented in
1989 which controls starting and stopping up to 12 (yes that's twelve)
separate phantoms at a time (using SEND/GET). It launches various
background updates and SSELECTs in real time without depending on a stack to
wait for the previous process to finish (ala Pick Phantom) and avoiding the
need to make a user sit and wait for a requested report to generate.

The control program monitors each phantom to see if it completes its
assigned task or seems to have 'hung' triggering an alert to the
administrator of the system (also uses an internal messaging capability to
store these alerts.) As the requests to run phantom jobs diminish, the
controller shuts-down these phantoms (using logoff) and then restarts them
as needed.

This program has been running unchanged since 1992 or so with no problems
(since Mentor v3.x). Can't say the same for the Phantom kludges we had to
implement to port over to D3, still need to get dirty on those from time to
time.

BFaux