search

pmattes / x3270

Family of IBM 3270 emulators
47 stars 19 forks source link

Question: How to use Transfer() action to exchange files with z/VSE host? #88

Open LTepliakov opened 3 weeks ago

LTepliakov commented 3 weeks ago

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 image

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?

pmattes commented 3 weeks ago

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.

LTepliakov commented 3 weeks ago

Thank you Paul for this very useful link! It contains example showing how SEND VSE620XB.AWS A: VTAPE1 AWS ( FILE=HTF BINARY LRECL=32600 NOCRLF command looks on the language of Transfer() options c3270>Transfer(Direction=send, Host=cics, Mode=binary, LocalFile=VSE620XB.AWS, "HostFile=VTAPE1 AWS ( file=htf binary nocrlf )")

It gives a clue.

I tried to transfer small text file to a library member: Transfer(Direction=send, Host=cics, Mode=ascii, LocalFile=offer.dat, "HostFile=offer dat ( file=lib uc )")

It shows me the window on x3270 image and then fails image

Actually I did not fully follow instructions. My terminal is in CUT mode. Do you think it critical to switch it to DFT? x3270 wiki says that both protocols are supported. I am very reluctant to change configuration on z/VSE host side...

I do not have complete documentation for z/VSE IND$FILE. Tried to find it but no success so far.

pmattes commented 3 weeks ago

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.

LTepliakov commented 3 weeks ago

I tried to capture with tcpdump: sudo tcpdump -i any port 3270 -w capture.pcap tcpdump: data link type LINUX_SLL2 tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes ^C100 packets captured 204 packets received by filter 0 packets dropped by kernel

Please see capture.pcap attached. capture.pcap.gz

LTepliakov commented 3 weeks ago

And here is the log I have got from x3270 (File -> Trace Data and Events. It looks more readable. It starts from me pressing PF6 to enter CICS command mode and ends with pressing PF3 to several times to exit CICS and return to ICCF menu.

x3trc.log2.gz

swhobbit commented 3 weeks ago

… and ends with pressing PF3 to several times to exit CICS and return to ICCF menu.

ICCF. Now that's a name I haven't heard in a long time. A long time.

(~1983?)

-ahd-

pmattes commented 3 weeks ago

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.

LTepliakov commented 3 weeks ago

Thank you Paul. Really appreciate your help and prompt reaction!

LTepliakov commented 3 weeks ago

… and ends with pressing PF3 to several times to exit CICS and return to ICCF menu.

ICCF. Now that's a name I haven't heard in a long time. A long time.

(~1983?)

-ahd- Yeah, with z/VSE I sometimes feel myself as software archaeologist :)

pmattes commented 3 weeks ago

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?

LTepliakov commented 3 weeks ago

Tried in 24x80 mode, but got the same kind of faiure. I started x3270 as: $ x3270 -mode 3278-2 x3trc.1337281.gz

LTepliakov commented 3 weeks ago

And here is the log for mode 5. Same kind of failure. x3270 -mode 5

x3trc.mode-5.gz

pmattes commented 3 weeks ago

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.

pmattes commented 3 weeks ago

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

LTepliakov commented 3 weeks ago

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 https://github.com/pmattes/x3270/issues/88#issuecomment-2305470227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFVD6CYZCGXHKLM2FQ3UNC3ZSY25FAVCNFSM6AAAAABMWVK432VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVGQ3TAMRSG4 . You are receiving this because you authored the thread.Message ID: @.***>

pmattes commented 3 weeks ago

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.