Conference vaxaxp::vmsnotes

    Your note references two separate Exabyte 8200 problems -- one on VAX, 
    one on Alpha.
    
    The VAX OpenVMS problem arose in V7.1 and is the one mentioned in
    the cover letter.  We are testing a fix for this now and hope to
    have it available as a remedial kit soon.
    
    The V6.2 Alpha problem you mention at the end of your note was actually
    due to Exabyte firmware, and is unrelated to the VAX problem. 
    
    Sue

    
    There's an update in the works to the OpenVMS VAX V7.1 MKDRIVER
    image (a replacement image).  A prototype copy of this update has
    fixed the problem that one of the SDK (field test) customers
    encountered with this tape drive under OpenVMS VAX.  (The tape
    drive has the current/last/lastest Exabyte firmware, and worked
    as expected under OpenVMS VAX V7.0, and -- with the new MKDRIVER
    image -- now works again under OpenVMS VAX V7.1.)
    

	Hello,

	We have a customer reporting problems using TLZ06 4MM DAT tape drives
after installing ALPSCSI02_070 on one of their OpenVMS Alpha V6.2 systems.
I don't have a full report yet of what these problems are, but apparently
they render the drive unusable.  When the V6.2 SYS$MKDRIVER is loaded, the
problems go away.  Could this be a problem with old firmware in the drives?
Okay, I will gather more information, then file a formal problem report.

	Thanks for any enlightenment,
	Bob Sampson

    See STKHLM::MAGTAPE for help on firmware etc. You may want to go there
    knwing what the problem is and what the firmware rev is.
    
    /a
    

   The MKDRIVER image for OpenVMS VAX V7.1 mentioned in the previous notes
   has not been released.  There was a similar problem found during testing
   (related with some Exabyte EXB-8200 testing on OpenVMS Alpha V6.2 systems,
   but it is not clear if the Exabyte-related problem might be related to the
   ALPSCSI02_070 fixes.

   In any event, acquire the firmware version of the drive, acquire details
   of the specific problem(s) seen, and acquire the output of a SCSI_INFO
   on the device.  Then IPMT the problem -- having a patch that is breaking
   a device needs to be addressed, and the IPMT is the way to get the report
   to the correct folks.

	Steve,

	Sorry for the delay.  We're working on it.  The customer has
suddenly gone quiet on me; I can't get the information out of him.
That's okay; we're sending someone out to visit him next week, so
stay tuned.  We will enter the IPMT, when and if we get the details.

	Bob Sampson

	Okay, sorry for the mixup.  The customer is *not* experiencing any
problem with DAT drives.  He is unable to use the old MLU (Magtape Loader
Utility, a.k.a. Mickey Lane Utility) with the new SYS$MKDRIVER.EXE provided
on OpenVMS V6.2 by the ALPSCSI02_070 ECO kit.  Any MLU command or API call
fails with a "no such device" error.  He is unable to use the new MRU
(Magtape Robot Utility), because it lacks an API.

	I'm having a call escalation started tonight (hopefully),
directing it to Sue Sommer, since she is expecting one anyway.

	Thanks,
	Bob Sampson

	Argh!  The IPMT found its way to the MRU people, who closed it by
simply stating that MLU was never a supported product.  What's more, I
found out today that this was just problem #1.  Problem #2 is that the
customer's application, when run on a DLT drive with the new MK driver,
unexpectedly sometimes gets SS$_ENDOFFILE or SS$_DATAOVERUN status returned
from IO$_READLBLK operations, which follow IO$_SKIPFILE operations.  We're
currently working on coming up with a self-contained reproducer.  Getting
information out of this customer has been like pulling teeth!

    if you run V7.1 and use IO$_SKIPFILE, then you really want to have
    a look at SYS$ETC:MKSET.TXT and SYS$ETC:MKSET.EXE if you haven't
    read the new features & release notes issue on the new IO$_SKIPFILE
    behaviour!
    
    /cmos

	Thanks!  I did skim the release notes and new features,
but I must have missed something.  CUJO:: is currently running
OpenVMS VAX E7.1, and doesn't have any SYS$ETC:MKSET.*.  But
I'll check it out tomorrow on a V7.1 system!  Spent the whole
day today vainly trying to reproduce the customer's problem...

    the MKSET stuff was added very late in the Gryphon game, so was
    definitely not present during E7.1, F7.1 and likely also G7.1
    
    /cmos

	Thanks; you've all been very helpful so far.  The customer is
reporting a problem with his application (occasional unexpected
SS$_DATAOVERUN or SS$_ENDOFFILE errors) on an OpenVMS Alpha V6.2 system,
on which the ALPSCSI02_070 ECO kit has been installed.  So, I still have
some questions:

1)	Does the MK driver supplied in the ECO kit enable the new, faster
	IO$_SKIPFILE always, on any drive that supports the required
	commands?  Or, is some V6.2 equivalent of SYS$ETC:MKSET.EXE needed?

2)	Given the general tape format shown below, is there any known
	reason that the new MK driver would cause the application errors?
	My best guess so far is that SS$_DATAOVERUN could be returned when
	the application expects to read a tape mark, so it sets P2 to zero
	or some small value, but unexpectedly reads a data block instead.
	Or it could expect a header block, but unexpectedly read a data block.
	Similarly, SS$_ENDOFFILE could be returned when the application
	expects to read a header or data block, but unexpectedly reads a
	tape mark instead.

*** beginning of tape ***
*** tape mark (EOF) ***
header block; 889 bytes
one or more data blocks; 32768 bytes each
*** tape mark (EOF) ***
header block; 889 bytes
one or more data blocks; 32768 bytes each
*** tape mark (EOF) ***
header block; 889 bytes
one or more data blocks; 32768 bytes each
*** tape mark (EOF) ***
(end of data has only one tape mark)

3)	Is it likely that the customer's application might be experiencing
	timing changes due to the new driver, that are causing the
	application to become confused (possibly by overlapping
	asynchronous I/O's)?

      I almost hate to say it, but can you IPMT this issue? (IPMT it to get
    the kit you need.)
    
       The ALPSCSI02 kit introduced the new skipfile support. It is enabled,
    and is causing the problems your customer see's. And yes, it is because
    of your customers non-ANSI tapes.
    
       A new kit for V6.2 includes the functionality of V7.1. (Skipfile
    disabled unless explicitly requested, along with the MKSET that can
    enable or disable it.) This kit will eventaully be released in a TIMA
    kit. 
    
       Let me know if you have further questions about this issue.
    
                         Mark d.

	Thanks again to everyone for the good advice and information.
I've been out sick for two days.  I still have one question.  Don't feel
obligated to answer, especially if the answer is stated or obviously
implied by the V7.1 New Features discussion.  What is the specific
mechanism that causes the customer's application to occasionally fail
in this manner, when the new skipfile is in effect?  I'm not just asking
out of curiosity.  The customer might ask what (if anything) he can do
to make his application behave consistently, without changing the tape
format.  Should his application adapt at run time to the skipfile
mechanism currently in use on the drive?  Or, is there some way to
"bulletproof" the application to work the same, regardless of skipfile?
This customer definitely wants his application to benefit from the speed
of the new skipfile.

	I will request that another IPMT be started for this customer,
to formally request the new ECO kit with the MKSET support, as well as
to formally request (if necessary) the answers to the above questions.

	Thanks,
	Bob Sampson

    ANSI standard is headers,tape mark, data, tape mark, trailers, two tape
    marks. That's it. One tape mark signifies end of file. Two tape marks
    in a row signal end of tape. The way most programs know that all files
    have been read is they encounter two tape marks in a row. 
    
    Vendors do one of two things that violate this standard - add data records 
    after the two tape marks or just write one tape mark at the end of all 
    data. Skip file searchs for end of data, then reverses a record and assumes
    it is now between the two last tape marks. 
    
       So bottom line is we follow the ANSI standard, which says two tape
    marks in succession signal end of data. IF vendor applications do not
    follow this standard, skipfile functionality will not work properly
    with their tapes.
    
       And if I've gotten any of the ANSI Standard info wrong, let me know.
    I've just worked this issue as far as skipfile functionality is
    concerned.
    
                       Mark d.

    re: .-1:
    
    That would seem to be an issue only if a skipfile(s) operation were to
    reach the end of data.  Is that correct?

    I believe that is what the fast skipfiles functions does - searches
    for a blank check - end of data.
    
                      Mark d.

	re: .-1:

	Are you saying that a fast IO$_SKIPFILE operation will *always*
find the end of data first?  This is a very confusing prospect for me.

    Okay, you're talking about skipping between files on a tape, and I'm
    talking about what happens when we reach the end of tape/data. I 
    sometimes forget that people can't read my mind. My fault.
    
      SKIPFILE in the case you are talking works fine. Rather than skip
    by records, reading tapemarks as we go along, we can now skip quickly
    to a specific file/tape mark down the tape. When we get to the 'target'
    tape mark, we READ POSITION to determine where we are on tape. 
    
      SKIPFILE issue I speak of is when we skip to the end of tape. Say we
    skipfile forward and endof positioned just past the second tape mark of
    the ASNI Standard Two Tape Mark Logical End of volume:
    
    
    | TM | FILE | TM | FILE | TM | TM |
                                      ^
                                      +-- Positioned here
    
    
    We were successful in the skipfile, so SS$_NORMAL is returned. We need
    to know whether we are at logical end of tape, so we can report an
    SS$_ENDOFVOLUME status, right? So now we space one file backward:
    
       | TM | FILE | TM | FILE | TM | TM |
                                    ^
                                    +-- Positioned here
    
    ...And then skip one record backward:
    
       | TM | FILE | TM | FILE | TM | TM |
                               ^
                               +-- Positioned here
       
    If that skip record results in a Tapemark Encountered, we know we are
    at Logical end of tape and return a SS$_ENDOFVOLUME. So we merely skip
    forward one file and are properly positioned bwtween the tape marks,
    returning SS$_ENDOFVOLUME status.
    
    | TM | FILE | TM | FILE | TM | TM |
                                 ^
                                 +-- We are here
    
    
    
    Now tape the case of a non-ansi tape:
    
    | TM | FILE | TM | FILE | TM | <--- Notice only one tape mark
    
    When we perform the SKIPFILE -1, SKIPRECORD -1, we end up as follows:
    
    | TM | FILE | TM | FILE | TM |
                                 ^
                                 +--- We are here
    Skipfile -1:
    | TM | FILE | TM | FILE | TM |
                            ^
                            +--- We are here
    
    And Skiprecord -1:
    | TM | FILE | TM | FILE | TM |
                     ^
                     +--- We are now here
    
     That SKIPRECORD would not have resulted in a TAPEMARK encounted
    status, so we have to assume we are positioned somewhere in the middle
    of the tape, so we return SS$_NORMAL and return to our original
    position:
    
    | TM | FILE | TM | FILE | TM |
                                 ^
                                 +--- We are here
    
    Our next forward positioning would cause us to get a BlankCheck/parity
    error as there is no more records on the tape. This is what I was
    referring to...
    
       Probably helps when I say what I'm thinking, huh? Sorry for the 
    confusion.
    
                      Mark d.
    

    Hey, no problem!  Thanks for explaining so clearly what you meant,
    though!  I can see it makes sense that there will be problems if
    a skipfile gets to end of data, if a double tape mark isn't there.
    
    I think the customer is probably becoming convinced that maintaining
    a double tape mark at end of data is a good idea anyway.  So, with
    this (relatively minor) application change, they should expect to
    see their problem (occasional unexpected SS$_ENDOFFILE and
    SS$_DATAOVERUN errors) go away, right?

    Correct. 
    
                         Mark d.

	We received an MKSET.BCK package in response to our IPMT.
It provides the same capability for OpenVMS Alpha V6.2(-1Hx) as
provided by SYS$ETC:MKSET.* on OpenVMS V7.1.

	This helps with testing.  I was given a copy of a customer's
tape, to which I appended another tape mark (EOF).  I then verified
that the end of volume is properly marked with double EOF.  The
customer's application *still* experiences unexpected errors after
skipfiles.  Oh, well, it was certainly worth trying!

	So, in this case, the problem is *not* solved by a double EOF
at end of volume.  I'm currently attempting to reproduce the problems
with my own C program, to find out whether the new MK drivers are
actually causing the problem, or whether this is simply a newly-discovered
problem with the application, that is somehow aggravated or exposed
by the new MK drivers (e.g. a timing problem that does not respond well
to faster skipfiles).

	Thanks anyway,
	Bob Sampson

    What happens when you do MKSET/NEVER MK###? Does the customer
    application still fail? If so, it is failing with the old behavior.
    
              Mark d.

	MKSET/NEVER is certainly something I can/will have him try.
I'm also trying to emulate his (ADA) application with my own C program.
Thanks for the good idea!

	Bob Sampson

    Please remember that the new skip file behavior in MKdriver is ONLY!!!
    for cases where the absolute number of files being skipped is 3 or
    more. Otherwise the old algorithm is always used. (In fact I have
    an on the side one that lets me do it always, but that is NOT in
    anyone's release code.) Most skipping that is done is either
    +1, +2, or -1, or -2 file marks, or + or - 32767 files to get to
    end of tape. If trying to do things like back/list, dir,
    or file lookup on tape, you are NOT using the new behavior regardless
    of MKSET setting because the skip count is small. set mag/skip=n
    better have n of 3 or more if you want any difference. The reason is
    that all the extra positioning needed to handle the case where
    you skipped EXACTLY to the end of data and are positioned after the
    second of 2 consecutive EOFs is rather expensive in time. Doing it
    on every positioning for most cases results in normal tape performance
    being FAR slower than the old method. Hence the switch. Granted, if
    you know the first file is 40GB long, the assumption is invalid, but
    the current code has no provision for anything else, and such 
    circumstances can be to a degree worked around as long as you
    understand what's up.
    
    Glenn Everhart
    

    By the way, the MKset stuff has nothing to do with an Exabyte 8200 
    problem that was recently fixed. That had to do with the common
    mode select logic accidentally setting fixed record length on the
    Exabytes, so that attempts to handle tape records other than 512 bytes
    were causing errors. That's fixed now, though I don't know where in the
    pipe the fixes are to customers. Rick Lord and Sue Sommer are to thank
    for fixing this.
    

    I believe this customer's problem is positlost when positioning his
    tapes. I hadn't considered this as the Exabyte 8200 issue. It's
    probably something I should rule out?
    
                       Mark d.

   If the Exabyte 8200 isn't up to the current (last) firmware revision,
   get the update from Exabyte.  Without this update, the drive will fail
   to work correctly on various recent OpenVMS releases...

   This firmware update is in addition to the fix for problems found in
   OpenVMS VAX V7.1 and a few other recent OpenVMS releases.  The fix to
   OpenVMS was for problems that manifest themselves rather more obviously
   than the `positlost' error -- the drives refuse to operate...

   Exabyte de-supported this drive a while back -- I'd look at one of the
   various available upgrades from DIGITAL, Exabyte, or other vendors...

	After some extensive testing of the new MK driver and the V6.2
MKSET package provided by engineering in response to an IPMT, I'm convinced
that the unexpected errors experienced by the customer's application are
*NOT* the fault of the MK driver.  It definitely looks like an application
and/or Ada issue.  So, I'm going to ask that the IPMT be closed, with the
request that the following observations and conclusions (which apply to
a DLT tape drive (TZ867) on a local SCSI bus) be added:

(1)	Testing with C programs indicates that the new MK driver always
	produces the correct, expected, documented tape motion (net result),
	with the customer's own tape format, having a double EOF at the
	very end of the tape data.  We are still investigating the errors
	from the customer's Ada application, but there is no further
	indication (other than their sudden appearance after the ALPSCSI
	ECO was applied) that their cause is a driver problem.

(2)	The new fast skipfile feature can be up to about 100 times faster.

(3)	The PER_IO option of the V6.2 MKSET package (provided by
	engineering in response to the IPMT) *does not work*,
	when the application defines IO$M_ALLOWFAST to be 4000 hex
	(as the iodef.h module defines it under OpenVMS V7.1), and
	uses it as a function modifier for an IO$_SKIPFILE request.

(4)	Similarly, an IO$_SETMODE request with IO$M_ALLOWFAST_ALWAYS
	funtion modifier (defined as per V7.1), although it is accepted
	by the driver, and completes with success status, does not
	enable fast skipfile on the channel.  This is not much of a
	surprise, since even the V7.1 I/O User's Guide does not mention
	IO$M_ALLOWFAST_ALWAYS as a valid function modifier for either
	IO$_SETMODE or IO$_SETCHAR.  Still, it leaves MKSET/ALWAYS as
	the *only* way on V6.2 to ensure that fast skipfiles is enabled.
	
(5)	Here is a table summarizing the observed
	skipfile behaviors under V6.2 with the MKSET package:

IO$_SKIPFILE    V6.2 MKSET package setting
func modifier   --------------------------
IO$M_ALLOWFAST  ALWAYS   PER_IO   NEVER
--------------  -------  -------  -------
specified       fast     slow     slow
not specified   fast     slow     slow
(useless)       (needed) (useless)

	slow:	The timings indicate that there may be a rewind to some
		calibration point (such as the beginning of the current
		track) prior to skipping records, causing performance to
		vary in a sawtooth manner, depending on the starting point.
		Overall performance is very poor.

	fast:	MKSET/ALWAYS is apparently required with the V6.2 MKSET
		package in order to enable fast skipfiles at all.
		Best performance is acheived when a large number of
		files are skipped all at once, allowing tape motion to
		reach and maintain full speed.

	Thanks, HTH,
	Bob Sampson

    MKset uses setchar, not setmode, to control characteristics, and
    has some different function modifiers to do it; they are not the same
    as used to modify io$_skipfile. As for the io$m_allowfast modifier
    failing, the question is what that bit definition is in 6.2. I only
    did that stuff for 7.1 and don't directly know the 6.2 bit definitions.
    They may well be different.
    
    The mkset.doc file in 7.1 does, I think, document the foregoing.
    However it may be the 6.2 backport did things a bit differently.
    glenn everhart
    

    For V6.2, MKSET defines IO$V_ALLOWFAST_PER_IO =8,
    IO$M_ALLOWFAST_PER_IO=256. Same for MKDRIVER.
    
    UCB bit for UCB$V_ALLOWFAST_PER_IO is 17 (decimal),
    UCB$M_ALLOWFAST_PER_IO = 131072
    
      Guess I better do some testing to make sure the person who backported
    this didn't mess up. We are on a same name basis. ;^)
    
                       Mark d.
    

	Thanks; this is not a major issue for us, since we know that
MKSET/ALWAYS works.  I do suggest that one good feature to consider
adding to the MK driver (for Raven?) might be support and documentation
for use of IO$M_ALLOWFAST_ALWAYS, IO$M_ALLOWFAST_PER_IO, or
IO$M_ALLOWFAST_NEVER function modifier with IO$_SETMODE, in addition to
IO$_SETCHAR.  The application could then control the *temporary*
skipfile method (slow or fast) of the tape drive (on the assigned
channel only), without having to rely on the *permanent* MKSET
(IO$_SETCHAR) setting.

    The UCB bit for allowfast has nothing to do with the function modifier.
    DO NOT assume they need to match.Code in MKdriver deals with the 
    UCB bits and nobody should be tweaking them from outside.
    glenn
    

    Re .32
    The mkset.txt does document (quite sparsely, but the info's there) use
    of the setchar to set the characteristics. This was used instead of
    setmode because it requires phy_io priv and I didn't want something
    like this being done by just anyone.
    glenn everhart
    

     IO$V_ALLOWFAST for V6.2R is bit 15 erroneously. It should be bit 14
    and will be changed accordingly. The previous incorrect reply will be 
    deleted. Sorry for the confusion.(It was all on my part.)
    
                           Mark d.

	Mark,

	Yes, after you alerted me to the fact that it might be a different
bit than in V7.1, I went looking for it.  I found out today by experiment
that IO$M_ALLOWFAST (in the MKSET package provided to me) is recognized as
8000 hex.  There are all sorts of "really lovely" kludges I've thought of,
as possible workarounds to be cleaned up later.  Ever used IO$M_FMODIFIERS
as a "universal" modifier?  ;-)

	Thanks,
	Bob Sampson

	BTW, I still like the idea of someday being able to *temporarily*
set one of the MKSET options (NEVER, PER_IO, ALWAYS) with IO$_SETMODE, on
a channel assigned to a foreign-mounted drive, using LOG_IO privilege.
This setting would *temporarily* override (only on the assigned channel)
the MKSET *permanent* setting.

	FWIW,
	Bob Sampson

Hi

Do we intend to provide a fix for the problem mention in .0? Is there one
available?

TIA

Matthew

:Do we intend to provide a fix for the problem mention in .0? Is there one
:available?

   There is a fix.  If it's not available in the patch area (and I
   would expect it would be there by now, but I've been, uh, burned
   by my patch-area-turnaround-time-sense before...), please contact
   me via e-mail, and I'll get you in touch with the SCSI engineers
   that worked on the fix.

    
    Steve...
    
    Any pointers to the kit please?? Doesn't look like its on TIMA as yet,
    at least not here in the UK that I can find.
    
    Many Thanks
    
    Chris D.
     
    

    Still can not find the patch...
    Has it been released?
    I have a customer with an Exabyte 8200 that wants to go to V7.1
    
    	/Guy

    ALPSCSI01_071 is the patch. Let me know if you still can't find it.
    
        Mark d.

    Hi,
    
    I have found the alpscsi01_071 patch for this problem, but not for the
    a fix for the vax?  
    
    Any news on where I can get hold of it?
    
    Claire
    
    

   I've passed the .44 request along to the engineer that worked on the fix.