Leonard,
I will try to answer your questions. Please pardon the length of this append.
>1) There are no timestamps on the messages in the server console log.
> How many vote for timestamps?
All I can say on this one is "We hear you"!
>2) There is a "set accounting on" command. I would assume that most
> sites would normally want accounting on or off all the time.
> Should this not be an option in the dsmserv opt file?
We are hoping to get to complete unattended 24x7 operation. As part of that
goal, we hope to some day do away with the options file altogether.
>3) Should there be an option to write the accounting data to a
> file instead of to cp accounting services. This would be for
> sites that want the data for stats and not for charge back.
> to an VM userid. After all, most of the clients would not have
> an VM userid to have the chages applied against.
> One could see the server saving the data to files stored within it's
> own storage pools. On cms one could use dfsms to recall the data
> when needed.
If the accounting records could be written to a file instead of created
with Diag 4C, they would probably have to be written to a CMS file, not
written to one of DSM's own storage pools. All disk storage pool volumes
on VM are CMS RESERVED minidisks. DFSMS would not have access at the file
level on such a volume. However, this is an interesting option to explore,
and not without precedent.
>4) Can IBM-adsm document how the recovery log is used.
Any update made to the database must be written to the log first. At regular
intervals the database takes a checkpoint, which truncates old log records no
longer needed for recovery, thus freeing up log space. A checkpoint is also
performed on system restart after recovery is complete. The database and
recovery log, while related to each other, operate independently. So a
checkpoint may leave active records in the log which describe db pages that
haven't yet been written to disk. By taking three consecutive checkpoints,
you more or less flush all db pages to disk and truncate the log.
Note that the reason for these steps as outlined for PN49454 is for the
DUMP DB command to get a consistent database image (i.e. no uncomitted
updates). This also means that to get a consistent db image, you can't
do anything that will update the db while DUMP DB is running. (But if you
LOAD DB an inconsistent db image, you can run AUDIT DB to bring it to a
consistent state again.)
>5) ...
>
> On page 334 of the Administrator's Guide release 1 it is written
>
> "The MOUNTWAIT value is not used by the server to automatically
> cancel requests handled by exit machines. You can use the value in
> the DSMMOUNT EXEC or ignore it, however you see fit."
Let me take this one piece at a time. If you are not using the mount exit,
the server uses the MOUNTWAIT value by cancelling mounts after the MOUNTWAIT
period expires. If you are using the mount exit, the value of MOUNTWAIT is
passed on to the exit VM, but the server doesn't enforce it. It is entirely
up to the DSMMOUNT EXEC as to what is done with that value, if anything.
You would be right in that this is of little use when you use a WAIT option
with your TMS's MOUNT command.
> On page 333
>
> "4. If requested, the DSMMOUNT EXEC must cancel the tape mount.
...."
What this is trying to say is if the mount was cancelled through VMTAPE
(for example), then your DSMMOUNT EXEC must recognize that the mount was
cancelled and simply logoff. Don't code your DSMMOUNT EXEC to issue a
CANCEL REQUEST command to the server -- just logoff. When the server detects
the exit VM is logged off, but no tape was attached at the requested address,
the server cancels the mount request for that volume.
It is important that you use your TMS's facilities to cancel tape mounts when
you are using the mount exit. The DSM server WILL try to issue a FORCE command
on the exit VM when you do a CANCEL REQUEST. However, some TMS's get confused
when the requestor (in this case, the exit VM) logs off out from under a mount
request. This is why you should ALWAYS use the TMS's cancel. Another thing
with TMSs is they don't always tell you that your tape mount was cancelled.
Don't rely on return codes, unless your TMS doc specifically says you can.
I've seen tape mounts that get cancelled from a TMS mount (with a WAIT option)
end with a return code 0. That is why I said above that your DSMMOUNT EXEC
must recognize the mount was cancelled.
> ...
> The bad news, It can try to autolog an exit before cp completes the
> logoff process. I believe that dsmserv needs a short delay between
> seeing a mount exit machine logoff and the next autolog.
The server will attempt to autolog an exit VM three times, with a 3 second
delay between each try. If all attempts fail, that exit VM is marked "Offline"
and the server will not use it any longer. You can use the READY EXIT command
to tell the server to use that exit VM again. By the way, it is probably a
good idea to use the same number of exit VMs as you have the MOUNTLIMIT set.
If you have fewer exit VMs, tape mounts will queue on an available exit VM.
> I know that the force/pending problem in CP is not quite what it used
> to be, but I still bad feeling about the production use of force.
> Would it be a viable options to have the dsmserv server autolog
> another mount exit machine that could issue an vmtape cancel command?
> But then maybe the autologing of another mount exit machine could
> cause even more problems. Any good thoughts on this.
I, too, kind of cringe at the thought of using FORCE (and I wrote that code!).
Perhaps another angle would be to "disable" the CANCEL REQUEST command if
the mount exit is being used? Note that should someone FORCE off the exit VM,
it has the effect of cancelling the mount (with the above caveat on TMS's).
> Should the mountwait period be settable by a site? In the config file
> or by command or both?
MOUNTWAIT is an option on DEFINE/UPDATE DEVCLASS.
I hope this helps.
Wayne Hineman
IBM Almaden Research Center
|
