One of the problems with our users' ability to exploit ISPF WSA
(workstation agent) is that they have to know their workstation's IP
Address and plug it into the WSCON dialog panel. This is only a problem
when the user loses his DHCP lease, and acquires another address; this
happens a lot for many people because they take their
(useless-to-anyone-else, incredibly super secure - you wouldn't believe
it!) laptops home, and acquire a different address via the VPN. The net
is, the address can be the same or different, and this leads to
unreliability, and inconvenience.
I would like to circumvent the task of everyone doing an IPCONFIG (or
equivalent in our VPN) in order to verify or correct the IP Address for
WSCON with some automation reducing Help calls, and improving productivity
and general quality of life.
One avenue I intend to investigate will be VTAM/TCPIP because of info I've
found in the syslog:
EZZ6034I TELNET CONN 0008B9F7 LU A20SD475 IN SESSION ORIND010 150
IP..PORT: 172.18.106.111..2817
$HASP100 userid ON TSOINRDR
$HASP373 userid STARTED
IEF125I userid - LOGGED ON - TIME=07.37.28
172.18.106.111 is workstation IPAddress. I'll be looking for someway I can
get this address via the VTAM LU. Before I go into research mode in an
area I not familiar with, I thought I'd poll for hints and tips.
Any ideas?
Michael
This message contains information from Equifax Inc. which may be
confidential and privileged. If you are not an intended recipient, please
refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited. If you have
received this transmission in error, please notify by e-mail
postm...@equifax.com.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
I don't think you should WSA from/to an alien work station. But we do
it. . .
bobh
Any ideas?
Michael
----------------------------------------------------------------------
Robin Ryerse
> Date: Fri, 26 Oct 2007 11:35:13 -0400
>
> One of the problems with our users' ability to exploit ISPF WSA
> (workstation agent) is that they have to know their workstation's IP
> Address and plug it into the WSCON dialog panel. This is only a problem
>
With Unix System Services Rexx, I can readily:
user@MVS:128$ rexx "address SH 'who am i'"
user@MVS ttyp0000 Oct 26 09:56 (129.150.32.132)
Under TSO Rexx, you'd need to "address SYSCALL spawnp who ..."
trapping stdout in a pipe. Feasible in principle, but is it
worth it? would OSHELL or BPXBATCH be simpler?
-- gil
--
StorageTek
INFORMATION made POWERFUL
Under z/OS 1.8 with ISPF (ISPF 5.8) there is a new ISPF variable called
ZIPADDR. This variable contains the IP address of the TN3270 session. Pretty
cool and useful stuff. Easy to use.. no muss, no fuss. Just VGET and use the
value.
Prior to z/OS 1.8, the way you collected this same detail was a little more
difficult (but still possible) using the REXX CONSOLE support. The "D
NET,TSOUSER,ID=yourid" returns IST1669I which contains the IP Address for the
user's LU. I think this showed up with OS/390 2.10 (not completely sure).
Now how can this get tripped up in anything but the simplest environment?
First, consider the issue of Session Managers. Your IP Address is known by
the Sesion Manager LU, but not the Secondary LU TSO session (ZIPADDR is 0.0.0.0
and IST1669I does not appear).
Now consider the tracing backwards of LUNAME back to the owning APPL and
using Sesion Manager commands. It can be done, but it is lots of work and is
different for each Session Manager and Session Manager command authorization is
usually an issue.
Now consider a CMC (Communications Management Configuration) where all
logons go to a particular LPAR or subset of LPAR's (single Sysplex or multiple
Sysplexes). Your VTAM/APPN definitions let you osmose to whatever LPAR you want
to. Now your D NET commands against the local VTAM or TCPIP don't really
return anything of value... Even if you get useful data, you may need to query
cross LPAR and possibly cross Sysplex to relate the pieces and get an
answer. Within a single Syslex MVS ROUTE commands may help. But, as you can see,
this is not a trivial exercise. Now combine this with two session Session
Managers (Supersession and TPX) and you have our environment...
I gave up... I use just use IPCONFIG when I need the IP Address...
Rob
In a message dated 10/26/2007 12:04:56 PM US Mountain Standard Time,
George...@ICBC.COM writes:
Dave,
I'd be curious to know if the IP address is knowable to any ISPF
application. I struggled mightily a while back to find a way to
determine its value dynamically from within an ISPF (Rexx) application,
including a protracted discussion in this group.
I finally resorted to using a screen scraping emulator (Attachmate
EXTRA!) macro that snatches it from the first screen displayed in our
Session Manager connection process. A second macro plunks it into the
target ISPF panel field when required.
I'd sure love to be able to avoid the macros.
George (ICBC)
-----Original Message-----
From: ISPF discussion list [mailto:ISP...@listserv.nd.edu] On Behalf Of
Dave Salt
Sent: Friday, October 26, 2007 10:25 AM
To: ISP...@listserv.nd.edu
Subject: Re: Obtaining 3270 Emulator's IP Address via TSO REXX for ISPF
WSCON
Hi Michael,
On z/OS 1.8 and above (or any version of z/OS if SimpList is installed),
the IP address of the workstation can be dynamically determined. For
example, in z/OS 1.8 an asterisk can be entered in place of the IP
address on the WSCON panel. However this only works if there's a direct
TELNET connection, so unfortunately it doesn't help when connecting
through a VPN.
Dave SaltSee the new SimpList(tm) rollover image
at:http://www.mackinney.com/products/SIM/simplist.htm> Date: Fri, 26 Oct
2007 11:35:13 -0400> From: Michael...@EQUIFAX.COM> Subject:
Obtaining 3270 Emulator's IP Address via TSO REXX for ISPF WSCON> To:
ISP...@listserv.nd.edu> > This is cross-posted to ISPF-L & TSO-REXX> >
One of the problems with our users' ability to exploit ISPF WSA>
(workstation agent) is that they have to know their workstation's IP>
Address and plug it into the WSCON dialog panel. This is only a problem>
when the user loses his DHCP lease, and acquires another address; this>
happens a lot for many people because they take their>
(useless-to-anyone-else, incredibly super secure - you wouldn't believe>
it!) laptops home, and acquire a different address via the VPN. The net>
is, the address can be the same or different, and this leads to>
unreliability, and inconvenience.> > I would like to circumvent the task
of everyone doing an IPCONFIG (or> equivalent in our VPN) in order to
verify or correct the IP Address for> WSCON with some automation
reducing Help calls, and improving productivity> and general quality of
life.> > One avenue I intend to investigate will be VTAM/TCPIP because
of info I've> found in the syslog:> EZZ6034I TELNET CONN 0008B9F7 LU
A20SD475 IN SESSION ORIND010 150> IP..PORT: 172.18.106.111..2817>
$HASP100 userid ON TSOINRDR> $HASP373 userid STARTED> IEF125I userid -
LOGGED ON - TIME=07.37.28> > 172.18.106.111 is workstation IPAddress.
I'll be looking for someway I can> get this address via the VTAM LU.
Before I go into research mode in an> area I not familiar with, I
thought I'd poll for hints and tips.> > Any ideas?> > Michael> > > This
message contains information from Equifax Inc. which may be>
confidential and privileged. If you are not an intended recipient,
please> refrain from any disclosure, copying, distribution or use of
this> information and note that such actions are prohibited. If you
have> received this transmission in error, please notify by e-mail>
postm...@equifax.com.
_________________________________________________________________
R U Ready for Windows Live Messenger Beta 8.5? Try it today!
http://entertainment.sympatico.msn.ca/WindowsLiveMessenger
************************************** See what's new at http://www.aol.com
Another 'trip' is if you use an XWindows 3270 emulator. All of these
methods will return the IP address of the XWindow client which isn't
very useful.
--
Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive
mailto:sas...@sas.com (919)531-5637 Fax:677-4444 Cary, NC 27513