z/OS reports "IOS097I MIDAW FACILITY NOT SUPPORTED..." under Hercules

[ToshiKZJ]

Hello everyone, Please tell me some advice.

The z/OS running under Hyperion Hercules v4.6.0.

The MVS command D IOS,MIDAW say...

    IOS097I MIDAW FACILITY NOT SUPPORTED BY PROCESSOR.

Do I need to do any extra configuration in cnf file?

Looking at the Hercules source code channel.c, Hercules seems to implement MIDAW functionality, but MVS says that the processor does not support MIDAW.

I don't have the skills to build a 'C' language program myself, so I'm using a pre-built version for Windows. Is there a way to enable MIDAW in the pre-built version Hyperion Hercules?

(Following is a part of Hercules configuration file):

CPUSERIAL 011DF7
CPUMODEL  3906
MODEL     M04
MAINSIZE  4096
LPARNAME  VMLPAR6Z
CNSLPORT  3270
MAXCPU    8
NUMCPU    4
ENGINES   4*CP
ARCHLVL   z/ARCH
DIAG8CMD  ENABLE ECHO
LOADPARM  0A81VNM.
SYSEPOCH  1900
TZOFFSET  +0000
OSTAILOR  z/OS
PANOPT    RATE=FAST MSGCOLOR=DARK
PGMPRDOS  LICENSED
TIMERINT  400
CCKD WR=4
CCKD RA=4
CCKD RAQ=8
CCKD RAT=8
CCKD NOSTRESS=0

0700 3270
000B 1403 \Printer\Print00B.list crlf
0004 3505
000C 3505 localhost:3505 sockdev ascii trunc eof
000D 3525 \Punch\Punch00D.txt ascii
000E 3211 \Printer\Print00E.list crlf
000F 1403 \Printer\Print00F.list crlf
0710 3270
0711 3270
0590 3590 *      # \Tape\ZMT001.het COMPRESS=1
0591 3590 *      # \Tape\ZMT002.het COMPRESS=1
0A80 3390 \DasdZGD3\D3RES1.cckd cu=3990-6 READONLY sf=\DasdZGD3\D3RES1_1.shadow
0A81 3390 \DasdZGD3\D3SYS1.cckd cu=3990-6
           .
           .
           .

[Fish-Git]

Hi Toshi!

I spent a few minutes Googling, and discovered the z/OS command to enable MIDAW support is the SETIOS command:

    SETIOS MIDAW=YES

Unfortunately, whenever I enter that command, I get the response:

    IOS085I SETIOS. MIDAW=YES MIDAW FACILITY NOT SUPPORTED BY PROCESSOR

I believe the problem (the bug) is in either Hercules's "Channel Subsystem Call" (B25F = CHSC) instruction support, or it's "Service Processor Call" (B220 = SERVC) instruction support, in source files chsc.c and chsc.h, and service.c and service.h respectively.

Also unfortunately, neither of those two instructions are documented by IBM either:

• Instructions not listed in Principles of Operation

So I am terribly sorry, Toshi, but it appears you are, for the time being, out of luck.  :(

Resolving this issue may not be possible, or if it is, may take a VERY long time.  :(

Maybe someone can examine z/Arch Linux source code and figure out (reverse engineer/decode?) what bit(s) we need to turn on in one or both of those instructions??

I will keep this issue open, but do not expect any progress on it any time soon.

[ToshiKZJ]

Hi Fish.

I'm not try to execute CCW which actually uses MIDAW yet.

I wanted to do a MIDAW test, so when I tried the Display IOS command, the response was that the CPU didn't support MIDAW, so I asked for help.

I will make a program to execute CCW that is using MIDAW in the near future, though not immediately. And report the results in this issue.

If MVS's EXCP routine does not examine the CCW to test for MIDAW availability, the CCW would be passed to the channel and the MIDAW might be processed by Hercules.

Thanks for looking into it so quickly.

Toshi.

[Fish-Git]

I will make a program to execute CCW that is using MIDAW in the near future, though not immediately. And report the results in this issue.

Thanks! I would appreciate that very much!

[Fish-Git]

My real concern is that because z/OS mistakenly believes MIDAWs are not supported, it isn't using them. If Hercules could be fixed, then z/OS would use them, and its I/O would be more efficient.

[mcisho]

The string MIDAW does not occur anywhere in the Linux kernel 5.17.6 source code.

[Fish-Git]

The string MIDAW does not occur anywhere in the Linux kernel 5.17.6 source code.

Thanks for checking, Ian.

Do you think it would be possible to determine what the output of either the "Channel Subsystem Call" (B25F = CHSC) and/or "Service Processor Call" (B220 = SERVC) instruction looks like? Then we could compare it to Hercules's output to see where the differences are, and maybe, via trial and error, determine which bit we need to turn on? Possible? Or not worth the effort?

[mcisho]

I think it much more likely to be CHSC output than SERVC output. We know what the input to some CHSC calls is, and we know what some of the output from some of those CHSC calls is. There are many different CHSC calls, Linux kernel references about 15 of them. The kernel source only defines those variables it is interested in, so the vast majority of CHSC output is unlabelled. A z/OS IPL issues loads of CHSC requests while it determines what devices are out there, what they are, and what they are capable of.

It appears that MIDAW is a system wide option (from the commands mentioned in previous messages), so the MIDAW indicator is probably in the Store Channel-Subsystem Characteristics response (structure CHSC_REQ10 in Hercules speak). If we can find where z/OS keeps that response, we could compare a real zSeries with Hercules.

[Fish-Git]

If we can find where z/OS keeps that response, we could compare a real zSeries with Hercules.

Which I greatly fear is much easier said than done.  :(

[illogical-path]

There are a couple of other things to be aware of for zOS to use MIDAW.

MIDAW was primarily developed to address a specific performance issue with EF (Extended Format) datasets when using FICON channels - maybe around 2006. FICON can have a a significant protocol overhead with ccw/data chaining - basically more frames going back an forth between channel and control unit. This overhead was increased with EF datasets due to the extra 32 byte suffix added to each physical block. MIDAW eliminated this by allowing a single ccw, with no data chaining.

Because of the above , in addition to ensuring the processor supports MIDAW, Media Manager (MM) in zOS will only use MIDAW for FICON channels. Although the use of MIDAW should be transparent to the CU, the use of MIDAW can alter the timing of CCW exchanges, so I believe the device must explicitly confirm it supports MIDAW and there is a bit in the zOS UCB, (UCBMIDAW) which MM will check before using MIDAW for that device.

A lot of the benefits of MIDAW - reduction in Ficon protocol - have now been superseded by zHPF (aka FCX or Transport Mode) which has similar TIDAW capability, albeit part of the basic FCX architecture.

Although zLinux uses standard IDAW and TIDAW, it probably never required MIDAW, as it uses fixed block records and wouldn't have the specific EF dataset problem. A quick check on orb.h seems to confirm this as the MIDAW bit (25) isn't even defined, it is just encompassed in the '6 bits of reserved zeros' definition.:

• https://elixir.bootlin.com/linux/v5.19.17/source/drivers/s390/cio/orb.h

Even if all the necessary bits were lined up and MIDAW was being used, I would be surprised if it made much difference to IO performance/efficiency in Hercules. MIDAW was all about solving bandwidth issues across the FICON physical medium - none of which exist in Hercules.

[ToshiKZJ]

Hi Fish.

Aside from the problem that the cpu instruction did not notify that MIDAW was available, it was possible to execute CCW using MIDAW from the application on the z/OS side with the EXCPVR macro.

However, since the bit that indicates that MIDAW is available for UCB is 0, it was necessary to forcibly turn ON the UCBCSFLG UCBMIDAW bit in the UCB Prefix of the I/O target device.

The EXCP driver checks for inconsistencies between the UCBMIDAW bit and the IOB EXTENSION's IOBEMIDA bit, but does not seem to see consistency with the flag bits associated with the "IOS097I MIDAW FACILITY NOT SUPPORTED" message.

When z/OS is run on Hercules, I don't think z/OS itself or JES2 does I/O using MIDAW, but it was possible for an application program to do I/O using MIDAW with EXCPVR. It may not be a complete implementation for Hercules, but it was useful for testing application programs.

In my personal opinion, if Mr Fish needs to spend a lot of time investigating to fix the "IOS097I MIDAW FACILITY NOT SUPPORTED" issue, please close it. I think it would be nice to have it as an enhancement item in the future.

Thanks to everyone who responded to the this issue. Toshi.

[Fish-Git]

Based on illogical-path's comment providing background on the issue, and the tests that ToshiKZJ has completed, I am in agreement with Toshi that this issue is simply not worth pursuing any further. I am closing this issue.

Thank you everyone for your research and thoughtful comments. I really appreciate it.

[Tirocinante]

Hi all!

If there's something that blows my mind is how on earth someone is "lucky" enough to get their hands on a D3RES...

With all due respect I really hope you manage to get it working. That would be cool! Unfortunately I know nothing about DFSMSdfp Advanced Services, CCW, MIDA flag or even EXCP for that matter.

According to IBM, MIDAWs are supported only for DASDs and only when running on an IBM System z9 or higher processor. IBM suggests examining bit UCBMIDAW in the UCB to determine whether MIDAWs are supported by the device. Got that from SC23-6861-02 z/OS DFSMSdfp Advanced Services manual while doing some studies on how to get the mainframe working with EAV DASD (Extended Address Volume; they support more than 65520 cylinders through a 28-bit cylinder number and the use of two more DSCBs: 8 and 9). By the way, I wanted to get it working on Hyperion's 64-bit CCKD but unfortunately when I tried to specify a quantity of cylinders that big it seemed that some previous routine checked for some sort of "maximum cylinders allowed" and then I couldn't create a DASD with more than 65520 cylinders. In theory, z/OS 1.10 and above support EAV DASDs. Just told you that as an anecdote. Sorry... I got carried away. Anyway, refer to page 180 (maybe some preceding pages could be of help either). Sorry for not being of much (if any) help. Wish you all the best.

Again, hope you manage to get it working...

Regards, Marzio.