HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 9 Apr 1992 12:55:14 PDT
From:         "Mike Friedman (510) 642-1410" <SPGMNF@UCBCMSA.BITNET>
Subject:      Re: MVS/ESA 3.1.1 --> 4.2 Conversion Problem

My problem with SIMPASS SLU's and TSO logon appears to be solved.

In response to my posting here, someone suggested that I override the new
VTAM 3.3 FASTPASS processing (which I believe affects only TSO).  I tried
this, but it had no effect.

It turned out that Simware had to write a one-line zap to SIMPASS, which has
fixed the problem.  Apparently at least one of their other products (SIM3278)
had the same problem, and a zap had already been available for it.  Anyone
else who is moving from VTAM 3.2 or below to VTAM 3.3 (with PTF UY64158) or
above, and who runs a third-party VTAM/3270 emulator, might be affected also.

Thanks to everyone else who tried to help out.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 09:46:09 CDT
From:         Richard Peurifoy <X229RP@TAMVM1.BITNET>
Subject:      Re: Changing TOD clock

On Sun, 5 Apr 1992 02:11:04 EST Fran Hensler said:
>Why isn't there a way to change the TOD clock without shutting down and
>doing an IPL?
>
>A priviledged program should be able to do this.  After all, the computer
>operator would still have to intervene to toggle the TOD switch.
>
I don't know about VM, but this can be done on MVS. However there are some
problems to consider. If you run a system such as IMS (others as well I'm
sure) that time stamps it's logs you can cause problems. If the log is used
for recovery you may do updates out of sequence (this is mostly a problem in
the fall when you set the clock back an hour. You can also cause problems with
accounting if you charge for connect time (users logoff before they logon).
If you change the clock at the right time these may not be a problem, but
many centers run things all the time.

It would be nice if IBM would use GMT for timestamps, and also save the
offset for local time. Then changes to local time (daylight savings) would
not cuase any problems with the logs.

Richard
Organization: Youngstown State University
Date: Tuesday, 14 Apr 1992 09:23:17 EDT
From: Troy Allen Cross <TAC@ysub.ysu.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: Controlling Various ISPF primary menus

In article <IBM-MAIN%92041322401829@RICEVM1.RICE.EDU>, Leonard D Woren
<LDW@USCMVSA.BITNET> says:
>
>Typically it's done by having different logon procs (or ISPF startup
>clists if you do it that way) which have different panels libraries
>containing appropriate versions of ISR@PRIM.)
>
I use different logon procs/clists with the clist having
"ISPSTART PANEL(panel_name) NEWAPPL(new_application_name)".

I do not use different panel libraries containing different versions
of ISR@PRIM.

The only problem that I have found is if a user drops from ISPF
to TSO, the user must reissue the clist name rather than ISPF or
PDF command to get the proper ISPF main menu. The ISPF or PDF
command will result in the default (IBM supplied) ISR@PRIM menu.

Is there any other problems with this setup?

************************************************************************
* Troy Allen Cross                                                     *
* Software Specialist (MVS/XA & CICS/MVS SYSPROG)                      *
* Youngstown State University                                          *
* 410 Wick Avenue                                                      *
* Youngstown, OH 44555-3036                                            *
* A.K.A. on BITNET as TAC@YSUB and Internet as TAC@YSU.EDU             *
************************************************************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 15 Apr 1992 00:04:15 LCL
Comments:     <Parser> E: "From:"/"Sender:" field is missing.
From:         Undetermined origin c/o Postmaster <POSTMASTER@RICEVM1.BITNET>

OPTIONS: ACK    LOG    SHORT     NOTEBOOK ALL
Date: 15 April 92, 08:02:45 SLT
From: D03G004@SAKSU00.BITNET
To: IBM-MAIN smtp at interbit
Subject: test

test mail only
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 14 Apr 1992 03:59:51 LCL
Comments:     <Parser> E: "From:"/"Sender:" field is missing.
From:         Undetermined origin c/o Postmaster <POSTMASTER@RICEVM1.BITNET>

OPTIONS: ACK    LOG    SHORT     NOTEBOOK ALL
Date: 14 April 92, 11:11:06 SLT
From: D03G004@SAKSU00.BITNET
To: IBM-MAIN smtp at interbit
Subject: HELP IN CONTROLLING ROUTCODE.

  we have userexit to control the printing tape labels with routcode(14)
 it runs ok in mvs/sp but when we moved to xa 2.2.3 we found out that the
 routcode(14) is used in the xa for modules(IEFACTRT & IEECVXIT) instead.
  we tested routcode(13).
 it prints tape labels with sub system messages like:
  idms, cics, and jes328x messages.

 however we want only the tape label to be prnted without subsystem messages.

 anybody knows how to do it?

 thanks in advance.

 our control for this userexit as follows:

 in SYS1.PARMLIB
 mem(CONSOL00)
 CONSOLE DEVNUM(607 alternat(606 routcod(13)
 mem(MPFLST00)
 IEC705I,SUP(YES),RETAIN(YES),USEREXIT(LABEL)
 mem(PFKTAB00)
 WE SET ONE KEY =
 V O-607,ONLINE; V O-607,CONSOLE,ROU=13
Newsgroups: bit.listserv.ibm-main
From: ah739@cleveland.Freenet.Edu (Leslie J. Somos)
Subject: Re: MVS Jobname Conventions
Reply-To: ah739@cleveland.Freenet.Edu (Leslie J. Somos)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Thu, 9 Apr 92 18:48:07 GMT


In a previous article, SYSMATT@UKCC.UKY.EDU ("Matt Simpson") says:

>We are an MVS/TSO and VM/CMS shop. In the past, TSO usage has been
>extremely limited (systems programmers only). The only access our MVS
>applications programmers have had to MVS is via batch jobs submitted
>from VM/CMS. The output from these batch jobs is spooled back to their
>VM reader queue for browsing.
>In the past, we have never had any standards for jobnames for MVS batch
>jobs. Since the VM spool system knows who every print file belongs to,
>there was no need to enforce jobname standards for identification.
>As TSO usage becomes more prevalent, we are going to have more users
>wanting to submit jobs from TSO and view the output directly from the
>MVS spool via SDSF, instead of routing it back to a VM spool file. Since
>MVS does not have the same concept of "spool file ownership" as VM, it
>becomes more of a problem to know what job belongs to whom, and who is
>allowed to view what output.
>I realize that in the past, many TSO shops have required all jobs
>submitted via TSO to have a jobname consisting of the userid plus 1
>character. Much of the default security in TSO and SDSF still seems to
>follow this convention. We have had a few complaints, and will probably
>have more, from new TSO users who have not had this restriction under
>CMS, and don't like it under TSO.
>What are other TSO/SDSF shops doing out there?  Are you still requiring
>jobs to be the userid plus 1 character? If not, how are you identifying
>the "owner" of a job to determine who is allowed to view/print/delete
>it?


The vanilla 'SUBMIT' command requires the name of the job submitted to
be the TSO userid plus _at_least_1_character_.  You can add even more,
up to the maximum of 8 characters total.  All (5) different shops I've
worked in used 3- or 4- character long TSO userids.

>
-- 
Leslie J. Somos
ah739@cleveland.freenet.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 19:46:45 -0500
From:         Clyde Laushey <SSTSCSL@VCUVM1.BITNET>
Subject:      Question on CICS/MRO and LPA modules

 We are currently running MVS/XA and two CICS/MRO systems, each of which
 has one TOR, one FOR and three AORs.  Approximately 175 CICS modules in
 the LPA occupy about 1.7Meg.  We need to free up some Common area.

 I have two questions concerning this:

 1.  Which modules must be in LPA for MRO to work and which definitely
     should be in LPA for performance reasons?   Any recommendations or
     references to existing documentation would help.

 2.  Is there a way to determine which modules are being used heavily,
     such as execution counts by module name?

 Thanks in advance for any help.

     +----------------------------------------------------------------+
     |  Clyde Laushey, Technical Services     Richmond,  VA  23219    |
     |  Virginia Commonwealth University      Phone:  (804) 786-7166  |
     |  110 South 7th Street,  4th Floor      Bitnet: SSTSCSL@VCUVM1  |
     +----------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Marist College
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 23:47:50 EDT
From:         "A. Harry Williams" <HARRY@VM.MARIST.EDU>
Subject:      Re: PIPE Dreams?

On Mon, 6 Apr 1992 14:33:00 PDT Leonard D Woren said:
>On Sun, 5 Apr 1992 16:19:16 GMT,
>   Paul Gilmartin <pgilmart@ISIS.CS.DU.EDU> said:
>> ... When may I expect to see compatible MVS/TSO PIPES?
>
>At the recent SHARE, I wrote and submitted a requirement for PIPES on
>TSO.  In a session on Friday morning (the third one of something like
>"Look What we Found in the Bit Bucket"), they mentioned that CMS PIPES
>runs on TSO.  Go to your PIPES maint disk and run the PIPGMOD exec.
But is it supported?  Who will accept APARS on it under TSO?

>Ship the resulting object deck over to MVS and linkedit it.  You now
>have PIPES, but without any help and without any support.  Also, you
>have to be licensed for PIPES on that machine.  We run MVS under VM,
>so we have no licensing problem.  Now, what can I use it for?
>
>/Leonard
Organization: Youngstown State University
Date: Wednesday, 8 Apr 1992 14:20:55 EDT
From: Troy Allen Cross <TAC@ysub.ysu.edu>
Newsgroups: bit.listserv.ibm-main
Subject: Re: Service-only CBPDO Subscription Offering and MVS PUTs

In article <IBM-MAIN%92040811030303@RICEVM1.RICE.EDU>, SSTSCES@VCUVM1.BITNET
(Charles Scott) says:
>
>               My understanding is that a CBPDO costs about $200.00
> IF you are not on an IBM mainframe.  The subscription service is free but
> I assume if you are non-blue, the cost would be per tape.

I thought that about a year ago that IBM did away with the CBPDO charge
for non-blue customers (YSU uses Amdahl).

If the charge is still in place, we will be using MVS PUTs till the cows
come home.  ;-)

I guess it is time to talk to my SE.

************************************************************************
* Troy Allen Cross                                                     *
* Software Specialist (MVS/XA & CICS/MVS SYSPROG)                      *
* Youngstown State University                                          *
* 410 Wick Avenue                                                      *
* Youngstown, OH 44555-3036                                            *
* A.K.A. on BITNET as TAC@YSUB and Internet as TAC@YSU.EDU             *
************************************************************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 7 Apr 1992 10:10:00 LCL
From:         LONGLEGS <LONGLEGS.SYSTEMS@MHS.UNC.EDU>
Subject:      Re: Clear Screen for USSTA

When I set up USSTAB's for our SNA terminals, I set up a USS10 message that
covered all 24 lines of the terminal to get around this problem.  This
worked pretty well.  Obviously USSTAB's are a poor substitute for a VTAM
menu, and we eventually implemented a menu program.

-Joel Dunn
 UNC-CH Administrative Data Processing
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 13 Apr 1992 21:26:17 PLT
From:         Dave Gibney <GIBNEY@WSUVM1.BITNET>
Subject:      Re: Controlling Various ISPF primary menus

   I was hoping for more flexible answers.
   "Unfortunately?" we're also beginning a RACF implementation. To many products
 assume the presence of access control, and some companies sales force is pushy

   Better disclaim, I claim responsibility for my opinions only.
   WAZZU is blameless.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <UNCDWC@UNCVM1>
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 08:07:22 EDT
From:         Doug Cutler <UNCDWC@UNCVM1.BITNET>
Subject:      Re: PL/1

     SAS used the PL/1 transient library up to 5.18, at 6.06 and above
it is no longer required because of th recodeing of most if not all
of the SAS system in "c".


  Doug. Cutler                       Office of Information Technology,
  VM Systems Programmer              University of North Carolina.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Sun, 12 Apr 1992 19:55:00 PDT
From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
Subject:      Re: User interface under TSO

> Basically, there's no ddname for the terminal in your TSO
> address space because the I/O isn't done in your TSO address
> space.  All the terminal I/O is done by VTAM (or TCAM).  SVC 93
> queues your requests to VTAM (via VTIOC) or TCAM (via TIOC,
> using QTIP).

Actually SVC 93 passes the request to VTIOC which is a VTAM
*application*.  It may be a little special, but basicly it's
just a VTAM application to VTAM with *one* terminal, yours.

VTIOC translates SVC 93 (and terminal control SVC's) into the
action required by the actual terminal.  This includes counting
lines, generating the ***'s as necessary, and (yes) handling TPUT
ASID/USERID from other address spaces to this TSO sessions
terminal.

When VTIOC has a 3270 stream all set to go it uses VTAM
to transport the data to the actual terminal.

> When you think about it, how could another address space send your
> terminal a message if your address space "owned" your terminal in the
> normal sense?  Since whoever owns your terminal cannot be the sole
> I/O-er thereof, why not make the owner a huge centralized bureaucratic
> entity like VTAM?  (A proven methodology in the real world? :-)

VTIOC *does* run in your address space (mostly or largely
in SRB mode).  The other address space queues the message
for your address space's terminal processing (VTIOC in the
case of a VTAM terminal) and notify's it (x-mem post or
SRB schedule?).  VTAM is NOT involved at this level.

PS: The ptbypass/restore code in VTIOC could use an update.  It
    currently uses a 3270 non-displayed field.  "non-display"
    doesn't mean that the data isn't there on the screen.  I
    believe that it should erase the non-display field after the
    next input to keep the data from appearing (or from being
    program input...)   I just happen to have some code
    which does this...
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: IBM-MAIN@RICEVM1.BITNET
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 9 Apr 1992 11:22:32 EST
From:         Eduardo Ferreira <duda@RDC.PUC-RIO.BR>
Subject: Re: COBOL

well, i don't want to begin a cobol vs any other language war, but...

I had worked with cobol for about 4 years, finally abandoning it for others
'clumsy' languages such as C, Pascal, and REXX.  No critics about COBOL, it
really does it work, but I can't even think about programming with it anymore.
For that matter, i'd better code ASSEMBLE...
And the self-documenting feature of cobol, well, as with any other language,
it depends completely on thee programmer.  I can do a working program in COBOL
quite clumsy and can write a real clear program in C.
it depends on who done it, i think.

regards,

 | Eduardo Ferreira                      |  E-MAIL : duda@rdc.puc-rio.br   |
 | System Programmer at Puc-Rio (Brazil) |  Voice  : +55 21 529 9422       |
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Original_To:  BITNET%"IBM-MAIN@RICEVM1.BITNET"
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 10 Apr 1992 13:02:00 MST
From:         LSHE@ARIZMIS.BITNET
Subject:      Re: COBOL

COBOL is updating, COBOL-85 has function call and lot of utility for software
engineering.


                Linda She.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 8 Apr 1992 09:14:50 EDT
From:         Dennis Caffi <ASMIDCC@VM7CG.HQ.AF.MIL>
Subject:      Re: MVS/ESA 3.1.1 --> 4.2 Conversion Problem
Comments: To: IBM Mainframe Discussion list
              <IBM-MAIN%RICEVM1.BITNET@uga.cc.uga.edu>
              7 Apr 1992 18:20:00 PDT from
              <CSYSMAS%UCLAMVS.BITNET@uga.cc.uga.edu>

 What version of Simware are you running ? We are having exactly the
same problem. We have a test and 1 production system running ESA 4.2
and we can use Simware to get to anything except the TSO on the same
host. Some things we can get to are Omegamon and TSO on another host
through a cross domain. Just the local TSO fails. One of our com guys
is putting up the latest Simware in hopes this will fix the problem.
Our VTAM is 3.2 and we should be putting up 3.3 soon.

-------------------------------------------------------------------------
Dennis Caffi                                IP: asmidcc@vm7cg.hq.af.mil
Senior MVS Systems Programmer
Grumman Data Systems / U.S. Air Force
Pentagon, Washington, D.C.
-------------------------------------------------------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Tue, 14 Apr 1992 22:51:58 EST
From:         "Lawrence E. Rondot" <RONDOT@IPFWVM.BITNET>
Subject:      Power networking requirements

We are in the process of configuring a VSE/ESA 1.1.2 system on a 9121-180.
Waht we would like to do is to install a POWER network and have it talk with
RSCS 2.3 on VM/SP rel 5 on our 4381-R13.  Until a conversion from VSE/AF 1.3.5
to VSE/ESA is completed (12-18 months?) we need to have the physical printer
attached to VM on the 4381.

We plan to have VSE/VTAM 3.x on the VSE/ESA system, and we have VM/VTAM 3.2
currently available on VM.

Can POWER even talk with RSCS?  Failing that can we get VSE spooled output to
the VM spool queues in an other way?

---------------------                 -------------------------
:  VSE/ESA          :   PNET - RSCS ? :     VM/SP 5           :
:   Power \ ________:_________________:____/ RSCS             :
:   VTAM  /         :                 :    \ VTAM             :
---------------------                 -------------------------

Thanks for any info and pointers....

Larry Rondot                               RONDOT@IPFWVM
IBM Systems Programmer & BITNET Techrep    RONDOT@CVAX.IPFW.INDIANA.EDU
Indiana - Purdue University at Fort Wayne  AT&T:   (219) 481-6203
2101 Coliseum Blvd East                    Other:  Scream this-a-way
Fort Wayne Indiana    46805-1499  USA      =* Standard Disclaimers *=
From: SPGMNF@UCBCMSA.BITNET (Mike Friedman (510) 642-1410)
Newsgroups: bit.listserv.ibm-main
Subject: Re: MVS/ESA 3.1.1 --> 4.2 Conversion Problem
Date: 10 Apr 92 17:54:31 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

On Thu, 09 Apr 92 12:55:14 PDT I said:
>
>Anyone else who is moving from VTAM 3.2 or below to VTAM 3.3 (with
>PTF UY64158) or above, and who runs a third-party VTAM/3270 emulator,
>might be affected also.
>
Slight correction:  PTF UY64158 (which introduced FASTPASS) isn't involved
in this case.  Apparently (as Michael Stein suggested in a reply to my
original posting) it's just a matter of the timing sequence of the binds,
which has changed with VTAM 3.3.

The SIMPASS zap just removes a branch to code that checks for the correct
sequence.  That code was really there only because SIMPASS shares a lot of
code with SIMVTAM (which I believe is a multi-session manager).  That product
had more need to make sure that the proper session was being connected to.

I tried the zap under VTAM 3.2 as well, and it works there.  SIMPASS doesn't
have the same need as SIMVTAM to do the checking, so I'm not too worried about
using the zap either on my current or new VTAM.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Marist College
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 6 Apr 1992 10:00:43 EDT
From:         "A. Harry Williams" <HARRY@VM.MARIST.EDU>
Subject:      Re: PIPE Dreams?
              5 Apr 1992 16:19:16 GMT from <pgilmart@ISIS.CS.DU.EDU>

On Sun, 5 Apr 1992 16:19:16 GMT Paul Gilmartin said:
>Several of my colleagues are evangelizing for CMS PIPES.  I regard this
>PRPQ as more interesting than useful until there is PIPE support for some
Its now part of CMS8 also.

>of my favorite applications.  Does anyone know when we may expect PIPE
>support for such products as:
>
>    DCF                      (5688-015)
>    PostScript Interpreter   (5688-104), and
>    PSF                      (whatever) -- of course, I mean the CMS user
>                                        interface rather than the printer
>                                        driver itself.
What support are you looking for?  I can pipe the output of any of those
now.
>
>My motive should be obvious -- I'd like to be able to use any two or all
>three of these products in concert without the enormous temporary DASD
>storage they require.
>
>Likewise, I cherish portability.  When may I expect to see compatible
>MVS/TSO PIPES?
It runs there now.  Has for quite some time.  Its not officially
supported, but complain to IBM about that.  Given Poughkeepsie's
enthusiasm for NIH syndrome, I wouldn't hold my breath.  I think
one area it could be especially useful is in accessing SQL in
a portable way from Rexx.  CMS has RXSQL(for a hefty $ figure)
but I don't believe there is a RXDB2 that IBM has released.
Anytime one of my fellow Dutchess Co residents wants to talk
about this, feel free to give me a call.  We can do lunch.
(I always thought that was a wierd phrase.  Now I know it is. :-)
/ahw
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Via:        UK.AC.CAM.PHX;  8 APR 92 14:32:04 BST
Newsgroups: bit.listserv.ibm-main
Date:         Wed, 8 Apr 1992 14:32:08 BST
From:         "A. Grant" <AG129@UK.AC.CAMBRIDGE.PHOENIX>
Subject:      MVS screen clearing, once and for all

I work on the assumption that
(1) if output since the last user input (linemode TSO output, TPUTs from
    other users, etc.) is to be thrown away, use
         STLINENO LINE=1,MODE=OFF
(2) if such output is to be held until ENTER is pressed, use
         STFSMODE ON,INITIAL=YES
         TPUT  =X'110000133C000000',8,FULLSCR,,HOLD
         STFSMODE OFF
         TCLEARQ INPUT
Is this sufficient?  (I have seen it asserted that the first three lines
of option (2) reduce to option (1), but the effects are observably
different.  I have also seen both (1) and (2) asserted as the "correct
way".  So there are at least two ways...)  This question comes up every
so often; it would be nice to get a definitive and comprehensive answer.
--
Alastair Grant, University of Cambridge
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 16 Apr 1992 10:41:55 EST
From:         "Matt Simpson" <SYSMATT@UKCC.UKY.EDU>
Subject:      Re: MVS MOUNT command

MVS commands can be issued via an assembler program by using SVC 34.
There are various programs on the CBT tape which do this. They can also
be issued from TSO via SDSF if you have it, or there are several other
TSO operator interfaces available. Commands can also be issued from a
batch job via JCL statements if your site allows it.
Replying to WTOR messages is a little tougher, because you have to know
the message number to reply to. However, this isn't really necessary for
mounting DASD volumes. If you vary the drive online before issuing the
mount, you won't receive the REPLY DEVICE OR CANCEL message. If you set
your default mount attribute to private in your VATLST, then varying a
drive on-line will automatically mount the volume as private. I think
private is the best default, because then you don't have to worry about
datasets being allocated on a volume between varying it online and
issuing the mount. If you want it to be public or storage, you can issue
the mount after varying it online, and not have to reply to a message.
If you want it private, you don't even have to issue the mount.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU