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 <[email protected]> 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) > [email protected] > > From: WF Konynenberg <[email protected]> > Sent: Thursday, September 1, 2022 10:10 AM > To: Linux on 390 Port <[email protected]>; Alan Altmark < > [email protected]>; [email protected] > 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 [email protected] with the message: INFO LINUX-390 or > visit > http://www2.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
