Ok, here is the documentation on Dynamic access of disks by Listserv;
obtained from the archives of the list [log in to unmask]
Following the documentation, is some recent mail on the subject, with the
last mail being from Eric Thomas, giving the setting of the keyword
Notebook. /duane
>> print 1176
>>>> Item number 1176, dated 88/11/20 16:29:10 -- ALL
>Date: Sun, 20 Nov 88 16:29:10 GMT
>Reply-To: Revised LISTSERV forum <LSTSRV-L@UGA>
>Sender: Revised LISTSERV forum <LSTSRV-L@UGA>
>From: "Eric Thomas (CERN/L3)" <ERIC@LEPICS>
>Subject: Using the Dynamic Disk Access feature of 1.5o
>
>Here is the (long-awaited? :-) ) documentation on the dynamic disk access
>feature of release 1.5o. It explains how to configure SYSVARS files,
>lists and filelists to use dynamically accessed disks. If you do not plan
>to use dynamic disks, you do not read to read any of this, since full
>compatibility is provided with the previous setup.
>
>
>What is a dynamic disk?
>-----------------------
>
>In the following discussion, the term "disk" will refer to a CMS format
>minidisk to which LISTSERV has R/O or R/W access at startup time, ie a
>virtual DASD defined or LINKed in the directory or PROFILE EXEC.
>
>There are two types of disks, static ones and dynamic ones. Release 1.5n
>and below supported only static disks. These are disks which are already
>and permanently ACCESSed once LISTSERV has started up (probably from the
>PROFILE EXEC, but see the description of the 'CHECKMDISK'/'MDISK.'
>definitions below). LISTSERV will never ACCESS nor RELEASE them, nor will
>it check that they are accessed properly (eg proper cuu, R/W or R/O
>access). It will, of course, produce an error if the disk is not properly
>accessed when a reference is made to it, eg when a user tries to GET a
>file that is supposed to be on disk L and there is no disk accessed as L.
>In any case, a static disk is uniquely identified to LISTSERV by its
>filemode.
>
>A dynamic disk is one that is LINKed at startup time, but not ACCESSed.
>LISTSERV will automatically ACCESS it when it needs to use it, and
>RELEASE it when it is no longer needed and the filemode 'slot' is
>required by another dynamic disk. During a single LISTSERV session, a
>dynamic disk can be accessed several times, and under different
>filemodes. A dynamic disk is uniquely identified by its virtual address.
>
>
>The "modes pool"
>----------------
>
>When LISTSERV starts up, it needs to determine what filemodes will be
>available to ACCESS dynamic disks. To do this, it issues a QUERY DISK
>command at startup time and marks "reserved" any disk which is presently
>accessed, as well as modes A,D,S and Z. That is, the modes under which
>static disks are accessed are automatically reserved. All modes that are
>not reserved are considered as being available for dynamic ACCESS.
>
>You might, however, wish to reserve a number of modes for your own
>applications, eg an EXEC invoked every day from WAKEPARM FILE which needs
>to ACCESS a few non-LISTSERV minidisks in R/W mode for a limited period
>of time. You can do this by inserting an entry in LOCAL SYSVARS for the
>RESMODES variable, whose default value is defined in LISTSERV SYSVARS
>(reminder: you should NEVER modify LISTSERV or BITEARN SYSVARS itself;
>pick up the variable you need to change, and copy it into LOCAL SYSVARS).
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>*
>* RESMODES
>*
>* This variable defines a list of filemodes which are to be considered as
>* "reserved" and never available for dynamic ACCESS. That is, LISTSERV
>* will never ACCESS a library minidisk by itself under one of these
>* filesmodes. You may of course use them to ACCESS minidisks from the
>* PROFILE EXEC or from any local command/exec you may have written. Note
>* that A,D,S and Z are always reserved, regardless of what you put in the
>* RESMODES variable. Also, any filemode which happens to be in use at the
>* time LISTSERV is started will be marked as reserved, so that LISTSERV
>* will never release minidisks which were ACCESSed when it was started.
>*
>RESMODES = 'BC'
>RESMODES is upcased.
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>
>Defining library minidisks
>--------------------------
>
>For each disk, dynamic or static, there are a number of parameters (for
>which a default value is provided) which tell LISTSERV how to "handle"
>the disk. These parameters are kept in a 'MDISK.cuu' stem, and are
>described below.
>
>In addition, there is a 'CHECKMDISK' variable, which lists the virtual
>addresses of those disks you wish to have checked during LISTSERV
>startup. For each disk checked in this fashion, you can decide what
>LISTSERV should do if it finds something wrong with the disk, as
>explained below. Provision has been made to request LISTSERV to access
>static disks itself, instead of doing it from the PROFILE EXEC, so that
>you do not have to write code to test the return code and send error
>notification in PROFILE EXEC. You can still ACCESS them from PROFILE EXEC
>if you so desire, provided you do not explicitly configure LOCAL SYSVARS
>to have them ACCESSed by LISTSERV.
>
>Please note that the CHECKDISK variable has been obsoleted by this new
>function. However, LISTSERV will map it into 'CHECKMDISK'/'MDISK.'
>definition statements as accurately as possible, for compatibility
>reasons.
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>*
>* CHECKMDISK - List of library minidisks to be checked at startup
>* MDISK.cuu - Information about library minidisks
>*
>* The 'MDISK.' stem defines various parameters associated with LISTSERV
>* "library" minidisks, ie minidisks on which LISTSERV might have to read
>* or write list archives or library files (as opposed to "system" files
>* like PROFILE EXEC or DATABASE FILE which are manipulated by LISTSERV
>* but are not apparent to the users). The syntax of the assignment is the
>* following:
>*
>* MDISK.cuu = 'acc rw ro nl th1 th2 / wlist / wmsg'
>*
>* The slash signs are used as separators. They allow for more parameters
>* to be specified in future releases while ensuring compatibility.
>*
>* - CUU is the minidisk address (*three* hexadecimal digits).
>*
>* - ACC indicates how the minidisk should be accessed. If it should be
>* accessed permanently at a fixed filemode, just specify its filemode
>* letter (eg 'F') and LISTSERV will access it during startup. If the
>* disk has already been accessed by the PROFILE, append a dash to the
>* filemode letter (as in 'A-') to bypass the ACCESS command. If the
>* disk should be accessed dynamically (ie as the needs arise), specify
>* '*' to let LISTSERV choose the filemode, '*S' to force the filemode
>* to be in the T-Y range (for security reasons) or '*fm' to force a
>* given filemode to be used for the disk (note that A,D and Z are
>* reserved and cannot be specified in this fashion).
>*
>* - RW indicates what LISTSERV should do if the minidisk is found to be
>* accessed in R/W status. 'N' means that this is a normal condition,
>* 'W' means that a warning message should be issued (see below) and 'L'
>* means that this is a fatal error and LISTSERV should log off.
>*
>* - RO is similar to RW and describes what happens if the minidisk is
>* R/O; NL specifies what should be done if the minidisk is not linked.
>*
>* - TH1 is the %utilization threshold above which a warning message will
>* be generated during startup. Specify 100 to bypass the test.
>*
>* - TH2 is the %utilization threshold above which LISTSERV will log off.
>* Specify 100 to bypass the test.
>*
>* - WLIST is a blank-separated list of RFC822 addresses to be notified if
>* something is wrong with the minidisk. Note that the postmasters are
>* always notified, so that the default setting of WLIST (null string)
>* actually means that the notification will be sent only to the
>* postmasters.
>*
>* - MSG is an optional message to be appended to the standard error or
>* warning messages generated by LISTSERV. This could, for example,
>* contain some description of the contents of the minidisk.
>*
>* Please note that only those CUUs listed in the CHECKMDISK variable will
>* be verified at startup time. However, some of the information in the
>* MDISK stem will be used when dynamically accessing libraries. The
>* default settings for library minidisks which have not been described
>* here is as follows:
>*
>* MDISK.cuu = '*S N N N 100 100//'
>*
>MDISK.191 = 'A- N L L 85 95 //A(191) is the LISTSERV system minidisk.'
>MDISK.192 = 'D- N L L 100 100 //D(192) is LISTSERV''s scratch work disk.'
>CHECKMDISK = '191 192'
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>
>How does one refer to a dynamic disk?
>-------------------------------------
>
>LISTSERV "library files" are externally identified by a filename,
>filetype and filelist-name, and internally mapped into a CMS filename,
>filetype and filemode. This CMS filemode, which we will call "static
>filemode", is usually specified by the person setting up the list of
>filelist, and defines both a disk-mode letter and an (optional)
>filemode-number, which defaults to 1. For a static disk, this is all the
>information that LISTSERV needs to store the file. For example, you could
>have a filemode of 'L2', meaning static disk L, mode 2.
>
>For a dynamic disk, the mode letter will not be constant and LISTSERV
>will need to know the virtual address of the disk. It must be appended to
>the static filemode, after a slash sign, to form the "dynamic filemode".
>For example, 'L2/201' means dynamic disk 201, mode 2. In the case of a
>dynamic disk, the mode letter is irrelevant, but still has to be valid:
>'!2/201' would be invalid, but 'X2/201' and 'L2/201' mean exactly the
>same thing.
>
>To refer to a dynamic disk, you simply substitute a dynamic filemode to
>the static filemode that you would have used for a static disk. For
>example, to put the archives of list XYZ on the 205 minidisk, instead of
>the G-disk, you would change from "Notebook= Yes,G1,..." to "Notebook=
>Yes,G1/205,..."; to change the default filemode for the ABC filelist, you
>would modify ABC FILEID and change from "*DEFAULT* G2 ..." to "*DEFAULT*
>G2/205 ..." (where '...' means the following parameters, if any, need not
>be changed).
>
>
>Migration of static disks to dynamic ones
>-----------------------------------------
>
>You might want to change a static disk into a dynamic one, ie decide
>that, from now on, the 'Public local lists' disk will be known as cuu 202
>instead of mode L. In order to make this change, you must perform the
>following steps:
>
>1. Modify PROFILE EXEC to remove the 'ACCESS 202 L' command.
>
>2. Add a 'MDISK.202' statement to LOCAL SYSVARS, and modify the
> 'CHECKMDISK' variable to include '202', unless of course you do not
> want to disk tested at startup time. You should do this by adding the
> following lines to LOCAL SYSVARS:
>
> MDISK.202 = '<fill-in as desired>'
> CHECKMDISK = CHECKMDISK '202'
>
> Do NOT copy the MDISK.191/192 statements from LISTSERV SYSVARS if you
> do not plan to change them. This will make sure that, if the default
> CHECKMDISK and MDISK.191/192 variables are modified in the future,
> this modification will not be lost.
>
>3. For all the lists that were archived on this minidisk, change
> "Notebook= Yes,Ln,..." to "Notebook= Yes,Ln/202,...", where 'n' is the
> filemode number that was there before, not the constant 'n'.
>
>4. For each filelist which had files on this disk, modify the
> 'filelist-name FILEID' file on LISTSERV 191 to replace all occurences
> of 'Ln' into 'Ln/202'. Be sure to modify the *DEFAULT* line if there
> is one and it points to this disk, and that your PROFILE XEDIT does
> not change the file into RECFM V.
>
>5. Release the disk if it was accessed, and start LISTSERV.
>
>6. For each list that was archived on this disk, issue a 'DATABASE
> REFRESH listname' command.
>
>Only steps 2-4 are required if you are creating a new dynamic disk,
>rather than converting a static one to dynamic.
>
>
>Usage notes
>-----------
>
>1. Filemode number '3' is no longer allowed, even on static disks. An
> error message will be generated if you attempt to use it, and no
> operation will take place.
>
>2. If you write programs that run in the LISTSERV virtual machine, such
> as local commands, File Access Validation Exits, programs called from
> WAKEPARM FILE, etc, you should never ACCESS nor RELEASE anything from
> these programs that is not defined as a RESERVED filemode in LOCAL
> SYSVARS.
>
>3. Programs that run in the LISTSERV virtual machine and need to
> temporarily ACCESS a minidisk can do so through the use of the
> following documented calling sequence (which will work only if
> LISTSERV has been started, ie not from PROFILE EXEC):
>
> Parse Value LSVDACC('FILE' fm rw) with rc more
> Select
> When rc == 0 Then Parse var more fm . /* Actual CMS filemode */
> When rc == 24 Then (...)
> /* Syntax error in 'fm', 'more' contains an error message */
> Otherwise (...)
> /* Other type of error, 'more' contains an error message */
> End
>
> Where 'fm' is the static (eg "L5") or dynamic ("X2/314") filemode and
> 'rw' is either "R/W" or "R/O", depending on whether R/W access is
> required or not. The disk may or may not be released by a subsequent
> call to LSVDACC for another virtual address; it is acceptable, but not
> mandatory, for the user program to explicitly release it when it is no
> longer needed.
>
> Please note that there are other types of LSVDACC calls, some of which
> allow minidisks slots to be "locked", but they are not presently
> documented and the calling sequence may change without notice.
>
>Eric
>
>
>
>=========================================================================
>Date: Fri, 31 Jan 1992 15:47:16 EST
>Reply-To: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>Sender: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>From: Hobart Braden <[log in to unmask]>
>Subject: File Modes for List Archive Notebook
>
>Files associated with a list can be directed to a dynamically-accessed
>disk using syntax in the <listname> FILEID file. For example,
>X5/200 will allocate files for the list on the minidisk at address 200,
>without assuming any particular filemode letter. Is there a way to
>direct the list archives notebook for a list to a disk in this manner,
>rather than having to specify a specific filemode letter in the
>Notebook= Yes,<fm>,<interval>,<access-level> statement in the list header?
>The motivation behind this question is: is it possible to keep each
>list's archive notebook on a separate minidisk while having more than
>26 lists???
>Any suggestions or referrals to documentation will be greatly appreciated.
>/Hobart Braden
>=========================================================================
>Date: Fri, 31 Jan 1992 17:35:33 EST
>Reply-To: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>Sender: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>From: Valdis Kletnieks <[log in to unmask]>
>Subject: Re: File Modes for List Archive Notebook
>In-Reply-To: Message of Fri, 31 Jan 1992 15:47:16 EST from <HRB@HARVARDA>
>
>On Fri, 31 Jan 1992 15:47:16 EST Hobart Braden said:
>>The motivation behind this question is: is it possible to keep each
>>list's archive notebook on a separate minidisk while having more than
>>26 lists???
>
>OK.. I'll bite.. what filemodes do you *use* after the first 26? ;)
>
>The whole *idea* behind dynamic filemodes in Listserv is to work around
>the 26-disk limit imposed by CMS - if you want more than 26 disks, you
>HAVE to start swapping disks at some point.
>
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Polytechnic Institute
>=========================================================================
>Date: Sat, 1 Feb 1992 18:05:38 +0100
>Reply-To: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>Sender: "Forum on LISTSERV release 1.7" <[log in to unmask]>
>From: Eric Thomas <[log in to unmask]>
>Subject: Re: File Modes for List Archive Notebook
>In-Reply-To: Message of Fri,
> 31 Jan 1992 15:47:16 EST from "Forum on LISTSERV release 1.7"
> <LSTSRV-L@SEARN>
>
>Notebook= Yes,X5/200,etc
>
> Eric
>
>
>
>
>
>
>
>
>
>
|
