开云体育

Whew!
So, in answer to my question,
-From Hercules,

• /attach 481 to cmsuser as 181
• devinit 481 fish.het

-From 3270, do whatever tape processing is necessary, VM or DOS

-From Hercules,

• devinit 481 *

-From 3270

• det 181

I'm not sure what is meant by?
P.S. -- I will still unmount the tape manually, because I hate seeing message DMKTAP516I. :-)

René Ferland wrote:

[...]

And VM is not confused, he's just sending a confusing message. :-)

(LOL!) No argument. :)

[...]

Anyway, now the situation is clear and we know that /attach, devinit,
detach is a simple, fast and perfectly legit sequence.

Agreed. I should have just kept my dang mouth shut. :)

Cheers,

Rene FERLAND, Montreal

P.S. -- I will still unmount the tape manually, because I hate seeing
message DMKTAP516I. :-)

I don't blame you in the least. :)

I'll go slink back to my pond now and leave you guys alone. I must be getting old and losing my touch. I'm just confusing things instead of clearing them up!

Take care. :)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Hello Fish,

Thanks for taking your precious time to look at this.?

Yes, device 481 is a 3420 indeed. And VM is not confused, he's just sending a confusing message. :-)

If I am reading its documentation properly, VM/370 does not support the subsequent models of magnetic tape you mention. Even though addresses 4A0-4A15 are defined as 3480 in DMKRIO, they don't seem to work. And defining a 3480 on 481 in the Hercules configuration file does not fool VM/370 either. We still get message DMKTAP516I and even a new one, DMKTAP500I.

Anyway, now the situation is clear and we know that /attach, devinit, detach is a simple, fast and perfectly legit sequence.

Cheers,

Rene FERLAND, Montreal

P.S. -- I will still unmount the tape manually, because I hate seeing message DMKTAP516I. :-)

?

René Ferland wrote:

Fish wrote:

Does [SDL Hyperion 4.3] behave the same way?

Yes, but I feel Hercules is not the guilty one here.

Okay, after looking at Hercules code (and verifying it against the appropriate manual), it appears this behavior is actually correct -- for 3410, 3411 and 3420 tape devices (which, without you even telling me, I am presuming is how you have your tape device defined, correct? You tape device is defined as a 3420, yes?).

If you look on page 24-25 of reference manual "3803 Model 2, IBM 3420 Models 4, 6, and 8, Magnetic Tape Subsystems, Subsystem Description" (GA32-0021-01), you will see that it states quite clearly:


Motion Control Commands

Motion control commands move tape but do not transfer data
across the channel/tape control interface.

All motion control commands operate as follows:

1. Channel End is signaled when the command is accepted
(initial status).

2. Device End is signaled when the operation, except for
Rewind Unload (see below), is completed (ending status).

3. The tape control responds with 'busy' if the tape control
is addressed while executing the command.

Note: For Rewind/Unload, Channel End is signaled in initial status,
and Device End, Control Unit End, and Unit Check are signaled in an
interrupt status cycle after the command becomes effective at the
tape unit. Device End is signaled again when the operator reloads
tape, presses START, and the tape unit goes from 'not ready' to
'ready' providing the tape control has not been offline in the
interim.


So Hercules is indeed behaving correctly, and the DMKTAP516I "BAD SENSE" message that VM is reporting on the unload command (X'0F') is actually correct (normal) and completely benign, as indicated in the reported sense information: "SNS= 4022000000C0030...", the X'40' in the first byte of which means INTREQ = "Intervention Required" (which makes logical sense (no pun intended) since the drive is "not ready for use" since it no longer has any tape media mounted on it, and therefore requires a human being to "intervene" to "correct" the situation by mounting a new tape onto the drive).

IBM must have recognized that having an "I/O error" result from what *should* otherwise be a completely normal/usual/typical thing as asking the tape drive to please unload its media, was a mistake, because for all other subsequent tape drive models (i.e. 3422, 3430, 3480, 3490, 3590, 3592, 9347, 9348 and 0x8809, etc), a Unit Check (I/O error) no longer occurs on a Rewind-Unload command.

If you change the device type for your tape drive in your Hercules configuration to one of the previously mentioned models (e.g. 9347, which I believe was also, like the 3420, a reel-to-reel drive), I'll bet DMKTAP516I no longer occurs when the same sequence is used.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Sorry, forgot the Hercules log.

Rene FERLAND, Montreal

On Thu, Dec 31, 2020 at 01:09 AM, Fish Fish wrote:

Does it behave the same way?

Yes, but I feel Hercules is not the guilty one here.

Rene FERLAND, Montreal

My sequence is similar like yours, but after dump I issue?
Tape rew
Tape scan
To see what's on the tape?
Then?
Tape run?
This rewinds and unmount tape, of course there's a cms error message, since tape is no more. But is unharmful.?
For a new tape I start devinit and mount in operator console again?

René Ferland wrote:

Fish wrote:

Please do a ccw trace on 481 for both scenarios and post
the results. I'd like to see them.

See attached log from Hercules.

Okay, that's Hercules 3.13. But what about SDL Hyperion 4.3? Does it behave the same way?

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Wed, Dec 30, 2020 at 11:52 PM, Fish Fish wrote:

Please do a ccw trace on 481 for both scenarios and post the results. I'd like to see them.

See attached log from Hercules.

Rene FERLAND, Montreal

René Ferland wrote:

[...]

If I do:

/attach 481 to cmsuser as 181
devinit 481 fish.het
det 181

then the tape is unmounted yes, but I get:

TAPE 481 DETACHED CMSUSER 181
DMKTAP516I TAPE 481 BAD SENSE CMD= 0F
SNS= 4022000000C003000000000000800100010000FFFF000000
CSW= 00F0AD68 2E000001 USERID= SYSTEM

The (information) message DMKTAP516I is generated by "an
error recovery routine [which] encountered an error on a
sense operation".

Why the message? The tape was there and VM did rewind it
and unmount it.

Weird. I can't explain that. Bug in Hercules maybe? Have you tried doing a CCW trace on device 481 to see what's going on?

However, if I do

/attach 481 to cmsuser as 181
devinit 481 fish.het
devinit 481 *
det 181

or just

/attach 481 to cmsuser as 181
/detach 481 from cmsuser

I get

TAPE 481 DETACHED CMSUSER 181

and no DMKTAP516I message. Now VM is trying to rewind and
unmount a non-existing tape and get so confused that it
cannot produce any message induced by the said confusion?

I don't know about VM but poor Rene *is* confused. :-)

Me too now! :(

Please do a ccw trace on 481 for both scenarios and post the results. I'd like to see them.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Wed, Dec 30, 2020 at 10:28 PM, Fish Fish wrote:

By doing it in the CORRECT sequence instead ("detach 181" from CMS guest and nothing else), VM's I/O request to unmount the tape then succeeds.

[...]

I believe VM is purposely coded that way. Under some
conditions it doesn't unload the tape from the drive
whereas under other conditions it does. I can't remember.
It's been too many years.

I believe it's module DMKVDR that handles this? I seem to recall having to manually patch it (modify it) back when I was the VM/SP system administrator for our company, to purposely *prevent* VM from ever issuing the rewind and unload I/O to its tape drives upon detach.

We did this, as I recall, because our string of tape drives was physically attached to multiple systems, and if the VM operator accidentally issued the detach command for the wrong drive, it would of course dutifully unload the tape from that drive which the *production* system MIGHT have been using! (writing to!) (Oops!)

I believe later versions of VM's detach command supported a "(leave" option to accomplish the same thing (i.e. prevent the rewind-unload from ever being issued upon detach), but either we didn't have that version or else we patched DMKVDR anyway because it was too easy for the operator to forget to specify that option (and unloading a tape in the middle of an important job that was running on the production system was writing to was painful enough to warrant doing so in order to prevent it from EVER happening again!).

I'm too busy working on Hercules itself to check, but just for fun, can someone check my memory for me? Was it indeed the DMKVDR module (VDR = "Virtual Device Release"?) that handled this?

Thanks.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

René Ferland wrote:

/attach 481 to cmsuser as 181
devinit 481 jim.het
tape dump * * a
devinit 481 *
/detach 481 from cmsuser

and it generates no error messages.

Because you asked VM *directly* to detach REAL device X'481' drive from its CMS guest's system, I'm guessing it didn't bother trying to unload whatever media it might have thought might still be mounted on the drive. It didn't issue the "run" CCW (X'0F' = "Rewind and Unload"), but rather instead decided to leave the tape drive alone. It decided to leave the media (the tape) mounted on the drive, position right where it was at.

In Jim's scenario however, he detached the virtual drive from his CMS userid, which triggered VM to issue the "run" CCW to the corresponding real device to unload the media (the tape) that it *believed* was still mounted there. I believe VM is purposely coded that way. Under some conditions it doesn't unload the tape from the drive whereas under other conditions it does. I can't remember. It's been too many years.

On DOS/VS, I use a similar sequence:

/attach 481 to dosvs as 280
(submit my job)
devinit 481 jim.het
devinit 481 *
/detach 481 from dosvs

Which is the same exact thing since your "dosvs" was, like "cmsuser", just another virtual machine GUEST running under the VM hypervisor, which is the REAL operating system in this situation, and the one that is ultimately in control of its own REAL devices.


[...]

Moreover, on DOS/VS, if I am to work with tapes, I will
typically do the /attach before the IPL, once for all,
and the /detach after the shutdown.

Which IMO is the correct way to do it.

If I run DOS/VS native, the attach/detach is not needed because
the tapes are already defined in my Hercules configuration file.

Precisely.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Jim Snellen wrote:

[...]

3. tape dump * * a --> from 3270 session
4. devinit 481 * --> from Hercules
5. detach 181 --> from 3270 session

Hercules then shows what appears to be errors with ccw,
stat, sense info with INTREQ displayed. (????)

Is this normal or am I doing something wrong?

Yes and yes. :)


[...]

What are the proper steps for attaching, processing, and
detaching a tape file?

3. tape dump * * a --> from 3270 session
4. detach 181 --> from 3270 session
5. there is no step 5.

The CMS guest, in response to the "tape dump" command, writes data to the tape by issuing I/O requests to what it *believes* to be its "real" X'181' device. But the CMS guest's X'181' device is of course NOT a real device. It is a *virtual* device.

The hypervisor that is controlling the CMS guest (i.e. VM itself, i.e. CP) intercepts its CMS guest's I/O to virtual device X'181' and translates it instead into and I/O request for REAL device X'481'.

Then, whenever you issue the command "detach 181" from your CMS user, CP (i.e. VM) then issues an I/O request to its REAL device X'481' to rewind and unload the tape that was mounted on that drive, and all is still well with the world.

By re-initializing device X'481' from Hercules (to unload the tape that was mounted there) before detaching it from your CMS guest, you ended up confusing poor VM so that whenever you did eventually detach your CMS guest's VIRTUAL device X'181', VM then tried issuing its own rewind and unload I/O request to REAL device X'481', which then failed because there was suddenly no tape mounted on it to be rewound or unloaded!

By doing it in the CORRECT sequence instead ("detach 181" from CMS guest and nothing else), VM's I/O request to unmount the tape then succeeds.

Are the steps the same for both VM and the guest DOS system?

I doubt it, since DOS/VS is not a hypervisor O/S like VM is.

Now if you were to run DOS/VSE as a *guest* under VM however, then that would be a different matter. :)

HTH!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

I've been able to read and write tape files from both VM and DOS.? However, I'm unclear on the proper sequence of commands.
For example, to create a tape file under VM, I issue:
2.?devinit 481 d:/vm370/tape/tapedump.aws?--> from Hercules 3. tape dump * * a? --> from 3270 session

4. devinit 481 *? --> from Hercules

5. detach 181? --> from 3270 session
? ? Hercules then shows what appears to be errors with ccw, stat, sense info with INTREQ displayed. (????)
? ?
Is this normal or am I doing something wrong??

Until step 4, Windows Explorer shows 0 bytes for the output file but afterwards it show the number of bytes.
Until step 4, I cannot view the AWS file because it's owned by another process(I presume Hercules) but afterwards I can.

What are the proper steps for attaching, processing, and detaching a tape file?
Are the steps the same for both VM and the guest DOS system?

TIA

The manuals issue is resolved.

I've also created a tape using VM (TAPE/VMFPLC2) and DOS/VS (RPG).

Thanks.

Jim Snellen

On Tue, Dec 29, 2020 at 07:36 PM, Jim Snellen wrote:

Could I get a copy?

Sure, you can find it here:



We don't have the messages for Release 34, but they are available for Release 29 (better than nothing). :-)

Cheers,

Rene FERLAND, Montreal

Thanks Rene.

Type CANCEL or press END/ENTER to cancel the job
If I key CANCEL or press END/ENTER, the job cancels as it should.

On Tue, Dec 29, 2020 at 07:02 PM, Jim Snellen wrote:

I don't remember the proper response.