|
View previous topic :: View next topic
|
| Author |
Message |
James Halley
New User
Joined: 11 Apr 2012
Posts: 18
Location: USA
|
|
|
|
Hi, first post although I have viewed this forum as a guest and have been in the mainframe world since IBM 1401 days.
I have been a fan of ISPF Client Server since its beginning and have written numerous ISPF panel/REXX dialogs and batch jobs that exploit it including recent fun stuff like enabling Google searches from an ISPF command line. Until now I have used the WSA only on Windows 16-bit and 32-bit.
Now, for the first time, I am walking an external customer through setting up the WSA on a PC running Windows 7 64-bit. To make it more difficult, my organization does not yet have any Windows 7 64-bit PC's. I have been assuming that the WSA will work under Windows 7 64-bit since people on forums have said that they have gotten it to work.
I had the customer install the WSA using the workaround I have read about on forums which is to not use the installation program and instead copy the WSA components from a 32-bit PC to the 64-bit PC. That part worked fine and the Workstation Agent window becomes active when the customer clicks on WSA.EXE.
The customer verified that TCP/IP is enabled in the WSA Options. When the user selects "Options ... Information", the following is displayed: "TCP not initialized. Required services could not be loaded".
When this situation has arisen on a Windows 32-bit PC, the fix has been simple - set the WSA WINSOCK path to C:\Windows\System32
What I am hoping to find out from one of you is: What should we be using in the WSA as the WINSOCK path on a Windows 7 64-bit PC? Are there other actions that should be performed instead or also performed? Is it as simple as searching the Win7 64-bit PC for a WINSOCK.DLL and then using the path to it?
Thanks in advance for any and all suggestions!
Jim |
|
| Back to top |
|
 |
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
I've just started it, and my winsock path is blank, and the thing just runs, got W7-64 Pro here, so something else must be the problem, but don't ask me what. Installation directory I use is
| Code: |
| "C:\Program Files (x86)\WSA\WSA.EXE" |
|
|
| Back to top |
|
|
James Halley
New User
Joined: 11 Apr 2012
Posts: 18
Location: USA
|
|
|
|
prino, thank you for the reply. The WSA on your W7-64 Pro PC is able to find a compatible WINSOCK as does the WSA on my own W7-64 Home Premium PC.
My customer, however, is using Windows 7 64-bit Enterprise Edition.
I was hoping for the same level of consistency regarding TCP services in Windows 7 that I have found in older versions of Windows but it is not looking like that is going to be the case.
When I searched my own W7-64 Home Premium PC for WINSOCK.DLL, I found only WINSOCKHC.DLL -- I am for now assuming that the WSA somehow successfully loads TCP services through it.
I am not sure what step to take next other than to ask the customer to search for WINSOCK and see what is found - not something I am comfortable asking of someone I do not know and who is not an IT professional.
Thank you again for your reply. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
Would it be acceptable to talk with the customer's technical support? |
|
| Back to top |
|
|
James Halley
New User
Joined: 11 Apr 2012
Posts: 18
Location: USA
|
|
|
|
Dick, I would love to be able to speak with a tech at the customer's site but it is a politically charged situation and I must tread lightly.
If I could get the WSA to function on the customer's Win7 64-bit PC "out of the box", I would be comfortable in then recommending that we proceed to the next step which would be to set up an encrypted VPN -- which of course would require a network tech at the customer's site.
But since the WSA is not functional at the customer's site and IBM is obviously not supporting the WSA on 64-bit, I cannot in good faith recommend that we continue trying to make it work due to the critical nature of this project. For now, it looks like we will go with an SFTP or Connect:Direct solution. It is not my decision.
I've got my internal users in pretty deep with ISPF Client Server although it is invoked behind the scenes by dialogs; nobody here uses it via the standard ISPF panels. I'm getting pretty nervous about making it work here with our upcoming migration to Win7 64-bit. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi James,
| Quote: |
| but it is a politically charged situation and I must tread lightly. |
Understood. Rarely do the technical issues whup us, the the politics sure can 
| Quote: |
| and IBM is obviously not supporting the WSA on 64-bit, |
Have you opened an issue with IBM support to confirm this? They may have a suggestion.
| Quote: |
| I'm getting pretty nervous about making it work here with our upcoming migration to Win7 64-bit. |
None of my clients use WSA, but one just replaced every pc in the organization with Win7 systems. Rather than be early with 64-bit, they went with 32-bit. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
Wish list item: IBM, if you don't want to support WSA.EXE, then please release it as Open Source and let the user community take care of it.
Not very likely, I know.  |
|
| Back to top |
|
|
James Halley
New User
Joined: 11 Apr 2012
Posts: 18
Location: USA
|
|
|
|
Dick, I neglected to thank you for the welcome.
| Quote: |
| Have you opened an issue with IBM support to confirm this? They may have a suggestion. |
I might do that if I get an answer back from a current open ticket which is about the WSA shutting itself down like clockwork on multiple PC's after 1.5 gigabytes of data has passed through it during the execution of batch ISPF jobs that invoke the FILEXFER service. The 1.5 GB situation was very unusual since only a few of the files we move through the WSA are barely over 300 megabytes and most are under two megabytes.
The last Windows versions documented as supported by ISPF Client Server were 2000 and NT. It is obvious that IBM stopped development on ISPF Client Server long ago since a 64-bit compatible WSA install program was not introduced for Windows XP 64-bit. Plus the Workstation File name field on ISPF 3.7 is wholely inadequate for lengthy paths and surely from the days of 8 character short directory/file names - that is why I wrote my own panels and dialogs that increase the lowly 52 character workstation path length limit of ISPF 3.7 from 52 characters to 204 characters.
| Quote: |
| None of my clients use WSA, but one just replaced every pc in the organization with Win7 systems. Rather than be early with 64-bit, they went with 32-bit. |
Except for software upgrade expense issues, I don't really understand the benefits of 64-bit over 32-bit. I was surprised that the rather inexpensive HP desktop PC I bought at a mainstream store for home use last summer came with Windows 7 64-bit.
I probably would not have continued on with the ISPF Client Server if we had better alternatives - there is no z/OS FTP here so the only other option is pathetically slow IND$FILE. My dialogs that invoke ISPF Client Server services work particularly well for non-technical users. If they can find their way to a report they need on the SDSF held queue, they have only to press a PF key to display the report in Microsoft Notepad or save it to their PC or network drive. The dialogs to do these kind of things are fairly easy to write and the file transfer speed of ISPF CS is lightning fast compared to IND$FILE. |
|
| Back to top |
|
|
|
|
