Question: How to use Transfer() action to exchange files with z/VSE host? #88
Comments
|
I found this on the web: https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/jens-remus1/2020/11/24/how-to-transfer-an-aws-tape-via-3270-to-zvse?communityKey=1045d2d1-3ff8-4714-aad9-209328662aa7 (search for x3270 on the page). If you can find complete documentation for z/VSE IND$FILE, I can look into adding explicit support for it to x3270. |
|
Thank you Paul for this very useful link! It gives a clue. I tried to transfer small text file to a library member: It shows me the window on x3270 Actually I did not fully follow instructions. My terminal is in CUT mode. Do you think it critical to switch it to DFT? I do not have complete documentation for z/VSE IND$FILE. Tried to find it but no success so far. |
|
I don't think that CUT vs DFT mode would make any meaningful difference. Would it be possible to capture a data stream trace from x3270, from just before you start your transfer, until after the error message pops up? I'd like to see exactly what x3270 is sending to the host, and if the host is generating an error message in response. |
|
I tried to capture with tcpdump: Please see capture.pcap attached. |
|
And here is the log I have got from x3270 (File -> Trace Data and Events. |
(~1983?) -ahd- |
|
Yes, the x3270 trace is what I needed. It looks like x3270 is not recognizing the CUT-mode HOST ACK sequence. I will figure this out and let you when I have an explanation and (hopefully) a fix. |
|
Thank you Paul. |
|
|
Here is what is happening. x3270 CUT-mode support is based on the screen being in default display mode. In default display mode, which is triggered by an EraseWrite command, the screen is 24 rows by 80 columns. In alternate display mode, which is triggered by an EraseWriteAlternate command, the screen may be larger, depending on the model. In default display mode, the 24x80 screen is rendered in the upper-left corner of the larger, real screen. But in terms of buffer offsets, it really is 24x80. That is, in default display mode, buffer offset 0 is row 1, column 1, and offset 1920 is illegal. In alternate display mode (with a model 4, from your trace), offset 1920 is legal; it is row 25, column 1. Your host is trying to run a CUT-mode file transfer in alternate display mode. It sends an EraseWriteAlternate, and it sets the correct fields for a CUT acknowledgement in the correct locations for a 24x80 screen, ignoring (I guess?) the extra rows at the bottom of a model 4 screen. x3270 could be modified to support CUT-mode transfers in alternate display mode, but I would need to know what the host does when the real screen has extra columns, and not just extra rows, such as with a model 5. The big question is whether it treats buffer offset 80 as row 2, column 1 (as for a model 2) or as row 1, column 81 (as for a model 5). Could you send me another trace, but this time, run x3270 as a model 5 instead? |
|
Tried in 24x80 mode, but got the same kind of faiure. |
|
And here is the log for mode 5. Same kind of failure. |
|
The model 5 trace is good news. The host is simply using the wrong command (EWA instead of EW), but it is writing the data as if to a 24x80 display. So the necessary change to x3270 is one line, plus a unit test. I should be able to give you some test code shortly. |
|
Pre-release code that should be able to do a CUT file transfer with your host is here: |
|
WOW! It works!
Thank you Paul!
One concern. You mentioned that the root cause is on the VSE host side.
"The host is simply using the wrong command (EWA instead of EW)"
I am working on the very old z/VSE 4.2 version. Maybe it makes sense to
test it on actual one.
…On Thu, Aug 22, 2024 at 10:21 PM Paul Mattes ***@***.***> wrote:
Pre-release code that should be able to do a CUT file transfer with your
host is here:
https://x3270.bgp.nu/download/specials/suite3270-4.4pre1-src.tgz
<http://url>
—
Reply to this email directly, view it on GitHub
<#88 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFVD6CYZCGXHKLM2FQ3UNC3ZSY25FAVCNFSM6AAAAABMWVK432VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVGQ3TAMRSG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Yes, by all means try with a newer version of VSE. But the x3270 fix does not introduce a significant risk, so I might leave it there anyway. |
File -> File Transfer menu does not have option for z/VSE host. It has option for CICS, and on z/VSE IND$FILE is implemented as CICS transaction, but it is far from clear how to specify multiple options that could be needed for transfer command.
z/VSE Programming and workstation guide gives multiple examples how to arrange transfer using SEND/RECEIVE commands provided with IBM Personal Communication tool, but I am on Linux, and have only x3270 available.
x3270 Transfer() action looks to provide much more flexibility and have a lot of options, but still a lot of options mentioned in SEND/RECEIVE examples provided by IBM are not present explicitly in documentation.
There is otherOptions option, but it is not clear how to use to code multiple options needed.
For example there are commands
Host file MYMEM JOB consists of two parts but we have only one hostfile option in Transfer()
Not clear how to code parameters that follow the parenthesis?
Is it possible to formulate a rule how SEND/REIVE parameters in IBM documentation can be translated to the language of Transfer() action options?
If that is possible, appreciate you to give as a sample translation of commands on the screenshot to Transfer() action options?
The text was updated successfully, but these errors were encountered: