Macro to login automatically for Win6530 Emulator
bandi
I feel so frustrated every time to login to the Tandem machine using
Win6530. Because there is certain time our for that session. I dont
know where it is configured. After every 3 or 5 minutes, the tacl
session automatically gets logged off. Again I have to again login
with my credentials.(which is not easy to type fast which has all the
combinations)
So, i am looking for a macro which automatically lets us login to the
Tandem machine, whenever we start our emulator. I am using here
Win6530.
Or else, is there any way to set infinite timeout for a session. I am
not sure, whether or not the timeout is from the emulator or from
Tandem.
Waiting for your valuable replies.
Thanks,
bandi
wbreidbach
If you get a "autologoff" it has been configured on the NonStop. You
can find out be entering
#getconfiguration/autologoffdelay/ at the TACL prompt.
Usually the autologoff delay is set by $CMON. Autologoff only hits if
a native TACL prompt is unanswered within a given time.
Probably this timeframe has been set for security reasons, we have set
it to 30 minutes.
It should be possible to configure an autologon in WIN6530, click
"options" -> "terminal" -> "operations".
If you just want to get a TACL prompt use "options" -> "communication"
-> "properties" and enter tacl as the service.
Tone
First off, it helps if you have profile created that you open to logon.
Go to EDIT->OPERATIONS and create a new operation called MYLOGON. Add
the commands :
LOGON <user>.<group>
<password>
and SAVE
Then go to OPTIONS->COMMUNICATION and select MYLOGON as the Startup
Operation.
Now save your profile, and disconnect and reconnect.
Now to the auto logoff.
Once logged into TACL, issue a #GETCONFIGURATION/AUTOLOGOFFDELAY/
command to see if TACL is configured with a timeout value. Will be -1 if
no timeout configured.
bandi
Yes, i get "autologoff". And i also executed the the tacl macro
"#getconfiguration/autologoffdelay". It gives 15, that means 15 mins
timeout.
Thanks for the info.
bandi
Yes, it worked. My problem is solved.Thank you so much.
Right now #getconfiguration/autologoffdelay shows 15, if want to make
it -1. How to do it?
Thanks !!
-bandi
MicroTech
> want to make it -1. How to do it?
> #SETCONFIGURATION / AUTOLOGOFFDELAY -1 /
The TACL config options can be altered only if you are logged on as
255,255. If you are, and do not know how the TACL/CMON interface works
(in some detail), PLEASE (for the sake of all users on your system)
read the TACL reference manual before experimenting!
Cheers,
Henry Norman
MicroTech Consulting
sites.google.com/site/microtechnonstop
wbreidbach
Autologoffdelay is set by the $CMON process in most installations. The
system manager should be responsible for configuring $CMON, parameters
like autologoffdelay are usually required by a security policy and are
not allowed to be changed.
Keith Dick
The above is correct. I just want to explain this a little more, hoping to make it more clear how things work.
The command Henry shows actually modifies the TACL object file to change the default value for the AUTOLOGOFFDELAY value. This default value is used if there is no $CMON, if TACL gets no reply from $CMON, or if TACL gets the reply from $CMON that says to use the defaults. Note again: It changes the TACL object file, so the changes persist indefinitely, for every TACL started from that copy of the TACL object file. So do not use this command without careful planning.
It is possible to specify a different copy of the TACL object file that the command is to modify. You would do that if you want some TACLs in the system to have a different default configuration than others.
A $CMON process is a customer-supplied server which TACL consults before performing certain commands. The request message from TACL describes the command to be performed, and the reply from $CMON tells TACL whether to reject the command, perform the command, or perform the command with certain parameters modified. LOGON is one of the commands for which TACL consults $CMON. If a $CMON process is present and functioning normally, TACL requests the configuration settings before each LOGON (and optionally after each LOGON). $CMON can respond either with a reply that says to use TACL's defaults or with a set of values to use for the TACL configuration.
Wolfgang is correct that these TACL configuration settings should be changed only with the permission of the system manager. They all affect various aspects of security.
Doug Miller
>The above is correct. I just want to explain this a little more, hoping to
> make it more clear how things work.
>
>The command Henry shows actually modifies the TACL object file to change the
> default value for the AUTOLOGOFFDELAY value.
Only if you specify a TACL object file to be modified.
#SETCONFIGURATION / <options> / [tacl_object] == modifies the specified object
file permanently
#SETCONFIGURATION / <options> / == modifies ONLY the current running TACL
process, and the mods disappear at LOGOFF.
>This default value is used if
> there is no $CMON, if TACL gets no reply from $CMON, or if TACL gets the reply
> from $CMON that says to use the defaults. Note again: It changes the TACL
> object file, so the changes persist indefinitely, for every TACL started from
> that copy of the TACL object file. So do not use this command without careful
> planning.
Note again: ONLY if you specify a TACL object file to be modified. That
parameter is optional, and, if it omitted, only the current running TACL
process is modified.
Keith Dick
Thanks for the correction. I misinterpreted what the manual says about it. That makes it safer than I thought it was.
Tone
Of course, if the system manager is security conscious enough to set up
an autologoff, he/she might disapprove of workstations that have
sessions set up that can automatically log on.
wbreidbach
>
> - Zitierten Text anzeigen -
As a system manager I think that autologoff is a must on production
systems and a pain on development systems. Years ago I had long
discussions about an additional function allowing to lock the terminal
instead of logging off the session. In my opinion this would make a
lot of sense.
At this time the autologoff is the only thing available for that
purpose. Unfortunately you can easily avoid the autologoff by just
entering "PAUSE" or any command interface like scf.
Years ago I wrote a little program called TERMLOCK which just requires
entering the password to unlock the terminal but the acceptance (to be
true even my side) was very poor because the above mentioned ways to
avoid autologoff are much easier to use.
whatever
You did not specify how you are connecting to your system. Are you
using telnet or SSH?
If you are using SSH and password authentication is allowed, you can
choose password authentication by going to
Options>Communication>Configure and only check the box for password
authentication. Then type in your password and save your profile.
When you start your session, the password will be sent automatically
without using a startup script.
We have our autologoffdelay set to 15 minutes for PCI reasons, but I
know that if you "hide" in a subsystem such as pathway or netbatch,
the autlologoffdelay does not work.
Also, if you don't want to do any of the above, you could just have a
macro/routine that writes a message to your screen every few minutes.
This will rest the timer for the autologoffdelay. For example:
?TACL ROUTINE
[#DEF DELAY ROUTINE |BODY|
#OUTPUT
#OUTPUT KEEPING TACL ALIVE
#OUTPUT
TIME
#DELAY 30000
]
[#DEF LOOP ROUTINE |BODY|
#FRAME
#PUSH I
#SET I 1
[#LOOP |WHILE| I = 1 |DO|
DELAY
]
]
DELAY
LOOP
jsrih...@gmail.com
I am using CAIL software for logging into tandem server. Every time to open a session, I need to do the below steps
Click on connect button
Type command product.abcpoos
Type password: say 'ready2go'
Then After entering into tandem server, need to type the below commands
logon product.abcpoos
Type password
Select the corresponding pipeline say 'k1'
All the steps are quite common and please let me know if we can automate this process with either VB script or any built in scripting language.
Waiting for your valuable info.
Thanks,
Sriharish