D3 Phantom Logoff/on nightly process
Marshall
keep it on a terminal so that it can be monitored visually. Problem
is the terminal is used during the day and if it is logged on the
Phantom has trouble logging it off remotely. What I need it to do is:
LOGOFF {port}
LOGON {port} NIGHTLY
When the port logs on to that user it automatically starts the nightly
process.
It simply won't logoff the terminal from the Phantom.
Any ideas?
Marshall
x
> process.
Marshall,
Excuse me if I'm off the topic here.
It might be a problem related to the login paragraph for that
particular account.
On PICK, the MD record that has the same name as the account is
executed whenever you log to the account.
Lucian
Tony Gravagno
users aren't logging of the port at the end of the day, so you're
doing a logoff from the phantom so that it can restart your nightly
process. But it also sounds like you're saying a logoff command from
a phantom fails, compared to a logoff executed from a PIB which might
(?) have better success.
Have you considered breaking fingers of users who don't logoff a
critical device at the end of the evening? (That's my italian
heritage again...)
Have you considered making it a regular process for the person at that
station to run the nightly job? This seems to have worked for
file-saves for a few decades.
What's the OS and release? Maybe peeps here can try this at home.
My big question would be: why does this process need to be logged off
so brutally all the time? Is the end-users running some intensive
process before walking out the door? If you're sure the tube is idle
and Logoff doesn't work then I would come back to trying to figure out
if this is phantom-specific. That leads to checking D3 release notes
to see if this issue has been fixed since your release was issued.
Finally, can you explain why this process needs to be monitored
visually? This sounds like one of those "we do this because of that",
and it's the "that" that needs fixing more than "this".
HTH
T
Marshall
1. Currently a user does execute the process manually each evening,
trying to automate so it doesn't get forgotten.
2. Since the terminal is in use during the day it can be left in a
menu or at TCL or logged off, who knows...
3. The process needs to be monitored because it's a crappy legacy
process and since our system will be going away within a few months
(the company was bought out and the new owning company has its own
system they will be bringing in) there's no sense in trying to fix the
crappiness of something that works 90%+ of the time.
4. Yes, a LOGOFF from a Phantom seems to fail, currently on D3 7.4.x
on AIX 5.2.
5. Breaking of fingers is bad things since user is my boss.
I just wondered if anyone had encountered and solved the issue without
an upgrade and I forgot to include my release and O/S (my bad, break
my fingers, if you can find me...hehehhe :) )
Most likely I will have to setup another tube and run it on there so I
can have the visibility that is desired and my boss doesn't have to
manually start the process each night.
Thanks,
Marshall
On Jul 10, 10:42 am, Tony Gravagno
> >Marshall- Hide quoted text -
>
> - Show quoted text -
dbene...@gmail.com
<address.is.in.po...@removethis.com.invalid> wrote:
> It took me a few times to understand the issue. It sounds like your
> users aren't logging of the port at the end of the day, so you're
> doing a logoff from the phantom so that it can restart your nightly
> process. But it also sounds like you're saying a logoff command from
> a phantom fails, compared to a logoff executed from a PIB which might
> (?) have better success.
>
> Have you considered breaking fingers of users who don't logoff a
> critical device at the end of the evening? (That's my italian
> heritage again...)
>
Is that the Sicilian side??? ;-)
Tony does have a fix, have the user start the nightly process. This
works until the user is sick.
If you need to monitor things, depending on what is happening, you
could update the program to print a log of milestones. If the process
halts/stalls/crashes you will have a bit of work figuring out where
things stopped.
Another thing you could do is write out to a file a few records of the
details that are being worked on. Combine this with the last idea,
and your search is greatly reduced but the disk activity could be
high. If you use only a handful of record id's for this detail such
that you only keep the detail that was last successful, and the
current detail being worked upon actual disk activity will be low, as
most writes will be cached. Do be careful not to include these sorts
of writes within a transaction that needs to be committed, otherwise
you'll fill the disk with pending updates.
Donno if these ideas are worth anything,
Dale
Scott Ballinger
execute "logoff nnn"
sleep 5
execute "reset-user nnn"
sleep 5
execute "logon nnn,user,pw"
Although not from a phantom, this has been 100% reliable over many
many years (and many AP/D3 releases).
Another option to accomplish what you want (monitor visually) is to
capture the output (as a txt file) via accuterm:
ESC STX C o p t ; path CR
Begin capture. Mode o may be O (overwrite), A (append), N (new file
only) or C (clipboard). Source p may be P to capture printed data or
null to capture received data. t may be T (text) to capture text only
(filters out control characters) or null for no filtering. Path is the
drive, directory and file name where the captured data is to be
stored. All characters received (or printed) are stored in the file
(or clipboard) until capturing is disabled (via local or remote
command). Note: when capturing to the clipboard, path is ignored).
This might accomplish what you want and allow the process to run as a
phantom.
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
GlenB
Why don't you launch the process from a cron and execute it nightly
using the d3 command line? If all you need is a user logon to start it
and there's no extensive user interaction, then it would be simple to
use cron to launch it and also capture the output for review. I'm not
an AIX expert, but under Linux you can set a MAILTO environment
variable in the crontab and all standard out/error will be directed to
an e-mail sent to that user/address.
The following will logon as user dm in the dm account and run WHO and
then EXIT.
d3 -d '\r\mdm\rdm\rWHO\rEXIT\r'
Just remember to send '\r' after a TCL statement and to EXIT properly
after the process is completed. You can stack any kind of nighly
process start script in the command line, provided the key strokes are
the same every time. I don't recommend you do this if there is a BASIC
sleep timer involved. If there is, see if you can weed it out so that
the process starts instantly. Cron will handle the scheduling for you.
GlenB
x
Let's say for port 15.
RESET-PORT 15 (IRON
LOGOFF 15
KILL P15
Make sure you don't LOGOFF & KILL port 0.
Lucian
Ross Ferris
> On Jul 10, 9:43 am, Marshall <mlu...@airtechnics.com> wrote:
>
> d3 -d '\r\mdm\rdm\rWHO\rEXIT\r'
>
>
OR, as a variation to the theme, if you want to check/confirm that
everything worked AOK, maybe
d3 -d '\r\mdm\rdm\rWHO\rEXIT\r' > /outputdir/outputfile.txt
A phantom could execute the above & then check the output file for
sucess (as well as WHERE and/or LISTU) --> assuming as always that you
didn't hit MAXUSERS
Art
> Let me try to tackle this one at a time.
>
> 1. Currently a user does execute the process manually each evening,
> trying to automate so it doesn't get forgotten.
> 2. Since the terminal is in use during the day it can be left in a
> menu or at TCL or logged off, who knows...
SNIP
>
> > >It simply won't logoff the terminal from the Phantom.
>
> > >Any ideas?
>
> > >Marshall- Hide quoted text -
>
> > - Show quoted text -
What I have done in the past is use the "POKE" command to send logoff
commands to the terminal. Since I also couldn't predict where the
terminal might be left, I sent commands for the most likely places the
user might leave the terminal, to escape out of the inquiry screen, or
whatever, and then the off command for the menu to actually logoff the
process. I would throw several combinations of sequences, hoping one
of them would match with where the user left the terminal. It didn't
always work if the user left the screen in an unusual place, but it
worked often enough to be useful. And it could be tweaked over time
to pick up additional places.
Art
Homer L. Hazel
Steve Alexander used to sell this wonderful program that I believe
was called Guard Dog. I remember having a client of mine buy it
for their AP/PRO system. It worked like a champ. It would
somehow monitor the logged on users and log them off after a
preset time of non use.
I don't know if it's still around nor if it is available for D3, but it
would be worth a look.
Larry Hazel
"Art" <artm...@triad.rr.com> wrote in message
news:a3dd857c-dc97-40af...@27g2000hsf.googlegroups.com...
Scott Ballinger
I did a quick test, and I have no problem logging off then logging on
a process from a phantom.
Perhaps the logoff is not the problem?
/Scott Ballinger
Here is my test:
:ct bp sb
001 n = 22 ;* my port
002 sleep 2
003 execute "logoff ":n
004 sleep 2
005 execute "reset-user ":n
006 sleep 2
007 execute "logon ":n:",xxx,yyy"
:who
22 xxx,zzz
:z run bp sb
[438] Job #1480545689 submitted.
:
< Connect time= 2 Mins.; CPU= 26000 Units; LPTR pages= 0 >
< logged off at 12:41:33 on 13 Jul 2008 >
12:41:33 13 Jul 2008
Enter your user id:
12:41:36 13 Jul 2008
Enter your user id:
09 Jan 2007 6386
:who
22 xxx zzz
:which
System Release Information
==========================
D3 Release Version 7.5.0.LINUX
Most recent mload into boot abs performed at 20:19:44 on 25 Feb
2008.
Implementation. . . . . . 6386
Software Serial Number. . nnnnnnnnn
System ID Number . . . . nnnnnnnn
Release . . . . . . . . . D3/UNIX: LINUX
Unix Information. . . . . Linux;pick0:LINUX;
2.6.9-42.0.10.ELsmp;#1 SMP Fri
Feb 16 17:17:21 EST 2007;3129F62A
:
Tony Gravagno
Logoff gracefully, and do it's own escallation if required _before_
the process is brutally terminated. In current releases there should
be no reason to reset/kill anything and I think it's a really bad
thing that these commands are the first weapons used in process
warfare.
T
Tony Gravagno
>
>A phantom could execute the above & then check the output file for
>sucess (as well as WHERE and/or LISTU) --> assuming as always that you
>didn't hit MAXUSERS
Along those lines, I filed an action item with RD to add functionality
equivalent to Como.
And this reminds me as well...
D3 has both Tandem and Converse - either of these can be used to
accomplish the "we need to watch the process" goal - without someone
having to physically be at the specific device doing the work.
Personally, I prefer the breaking fingers idea for at least 3 reasons:
1) It's a boss who can't seem to be trusted to run/watch processes.
2) The company was sold, the system will be gone soon, and you're
going to be unemployed anyway, so why not break some fingers now while
you can?
3) In a world where there are few rewards for some of the work that we
do, the ability to break some fingers now and then is a fringe benefit
that isn't used as often as it should. Break early, and break often!
Yes, that's the Sicilian in me, Dale. Funny how my wife didn't mind
when I told her I was Italian, and then one day in passing I mentioned
it was actually Sicilian and she freaked. Can't imagine why...
HTH
T
Marshall
suggestions to see what works best with the least work. I don't want
to put a lot into it since it will just be going away soon anyway.
Thanks,
Marshall
Ross Ferris
> I don't want
> to put a lot into it since it will just be going away soon anyway.
>
> Thanks,
>
> Marshall
Do I sense a migration? Away from the Application? D3? Multi-value in
general?
Marshall
corporations JDE system. So I really don't want to put a lot of time
into anything, but just get by on things until the migration is
complete.
Thanks,
Marshall