Classification: Confidential Actually using VMUR sending files is an excellent way of take a secure offline backup of important files you really want ta have a safe backup of. The receiving Linux can be 'offline' normal tcp/ip networks making it more or less impossible to reach for intruders. You still have the 3270 interface to protect.
Nowadays you might need that. BR /Tore -----Original Message----- From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of Alan Altmark Sent: Sunday, September 4, 2022 5:20 To: LINUX-390@VM.MARIST.EDU Subject: Re: Can zLinux detect when files arrive in the virtual reader? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Dunno why you’re arguing with me, Don. I was presenting the hardware-based rationale for Linux to generate a UDEV event when it receives a an unsolicited DE on RDR or tape devices. Doing it for DASD would be a discussion for another day, as that’s a zebra of another hue. Regards, Alan Alan Altmark Senior Managing z/VM Consultant IBM Technology Services Endicott, NY USA > On Sep 3, 2022, at 6:41 PM, Donald Russell <russell....@gmail.com> wrote: > > All of that sounds very similar to how WAKEUP works. If the reader > isn’t spooled class * then WAKEUP won’t wake up unless the correct > class file arrives. I’d hazard a guess that’s a CP thing and not a CMS > thing. That is, CP won’t present the “ready” interrupt unless the > arriving file matches the spooled class of the reader. (vs WAKEUP > checking then going back to sleep because of the class mismatch) > > That’s fine, that’s all under user (root user sysadmin) control. > > I guess this is where you say to be careful. Yes, I’m not interested > in the arrival of a spool file, I’m interested in the arrival of a > spool *I can read. * > > My point earlier was that if CP presents the “device ready” interrupt > to a virtual machine running zLinux, then zLinux ought to do something > constructive with it. i.e. create a udev event so an *application* can > do something with it. > > You said “UDEV was meant to reflect physical device events to user space.” > > We’ll, the arrival of a “card deck” is a physical device event. > > Yes, Linux code could poll the reader every 9 seconds. (An interval > meant to be sarcastic) That’s a terrible design for virtual machines. > > >> On Fri, Sep 2, 2022 at 06:50 Alan Altmark <alan_altm...@us.ibm.com> wrote: >> >> I won’t pretend to be an expert in UDEV architecture, but the >> research I’ve done showed me that UDEV was meant to reflect physical >> device events to user space. >> >> Having refreshed my memory by re-reading “IBM 2821 Control Unit >> Component Description”, I think the arrival of a card deck in a card >> reader is equivalent to a USB stick appearing in a USB port. >> >> When you press the START key on a 2540 card reader, the device >> transitions from NOT-READY to READY, causing an unsolicited interrupt >> (Alert+Device >> End) that tells the OS to start reading. Once EOF is reached (no >> more cards in the hopper and the EOF button was pressed), the 2540 >> signals a Unit Exception, failing the outstanding READ operation >> that’s waiting for next card. From that the OS knows that the file is >> complete. Once, the UE >> is sent, the 2540 returns to the NOT-READY state. In VM, the arrival of a >> RDR file effectively pushes the START button on the virtual RDR. [I’m not >> looking to start a retrospective on the 2540 or its modes of >> operation that differed from the above description. I’m just trying >> to make a point.] >> >> But be careful. While we think we’re interested in the arrival of >> spool files, we’re not. Rather, we’re interested in knowing that if >> we start reading from the card reader, there are cards in the hopper to be >> read. >> I.e. If a spool file arrives with class Q, but your RDR is spooled >> class Z, you won’t be able to read the spool file. That’s why seeing the >> device >> transition to READY is so important. That only happens if an *eligible* >> file arrives in you RDR. (Anyone who has written a non-blocking >> socket application will appreciate that subtle difference.) >> >> Cards, tapes, disks. They all had removeable media and they all >> signaled the host the same way. Even a terminal would generate an >> unsolicited DE when you turned it on; that’s how the OS knew it was >> ok to write a logo to it. (I guess the human was the removable >> media!) >> >> This is not to be confused with changes in I/O configuration where >> subchannels are added to or deleted from the I/O configuration. >> That’s a whole different kettle of fish. >> >> Regards, >> Alan >> >> Alan Altmark >> Senior Managing z/VM Consultant >> IBM Technology Services >> 1 607 321 7556 (Mobile) >> alan_altm...@us.ibm.com >> >> From: WF Konynenberg <w...@konynenberg.org> >> Sent: Thursday, September 1, 2022 10:10 AM >> To: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>; Alan Altmark < >> alan_altm...@us.ibm.com>; LINUX-390@VM.MARIST.EDU >> Subject: [EXTERNAL] Re: Can zLinux detect when files arrive in the >> virtual reader? >> >> I would be inclined to suggest that use of udev for user I would be >> inclined to suggest that use of udev for user functionality like this >> likely constitutes abuse of the udev design. It might be better to >> find an approach that fits in the canonical Unix/Linux model of >> handling various device quirks. Steal ideas from, say, the magnetic >> tape driver interface and tooling, the tty subsystem, etc. Don't go >> out of your way to design something new that is completely unique to >> zlinux. I wouldn't be surprised if the rdr device driver needs a wee >> bit of fixing to make it properly support a classic style Unix/Linux device >> usage. >> >> --------------------------------------------------------------------- >> - For LINUX-390 subscribe / signoff / archive access instructions, >> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 >> or visit >> http://www2/ >> .marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=05%7C01%7Ctore.ag >> blad%40HCL.COM%7Cde9120c9573e41b8349b08da8e249b8d%7C189de737c93a4f5a8 >> b686f4ca9941912%7C0%7C0%7C637978585168809188%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C >> 3000%7C%7C%7C&sdata=EagnFAZAXnQTqD0ywgioPTONI%2FxUfPLS9Li9%2BsQvz >> P0%3D&reserved=0 >> > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www2/. > marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=05%7C01%7Ctore.agbl > ad%40HCL.COM%7Cde9120c9573e41b8349b08da8e249b8d%7C189de737c93a4f5a8b68 > 6f4ca9941912%7C0%7C0%7C637978585168809188%7CUnknown%7CTWFpbGZsb3d8eyJW > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > 7C%7C%7C&sdata=EagnFAZAXnQTqD0ywgioPTONI%2FxUfPLS9Li9%2BsQvzP0%3D& > amp;reserved=0 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390 ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
