HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.l-vmctr
Date:         Fri, 28 Aug 1992 14:33:56 CST
From:         Jim Colten <IJIM@UMINN1.BITNET>
Subject:      Re: Last date a minidisk was updated.

>>Hi,
>>    Am I wrong or does moving a minidisk with VMSECURE change the
>>"last updated" date you see when you do a MDSKSCAN or run the VMRMUA
>>report?  If so, how do I work around this?  I want to clean old minidisks
>>off a couple of volumes.  Thanks.  T.S.
>
>I believe that date is simply the latest file update timestamp
>encountered for that minidisk; ie. moving the minidisk will
>not change the timestamp.  We run our Clearvol process (front
>end to VMSECURE) to clear entire volumes without worrying about
>changing any data or timestamps within minidisks.
>


Well, that depends.  Here is what I see (VMSECURE 4.0, CMS5):

   1) look at the FILE timestamps on a disk
   2) do a VMSECURE MDSKSCAN for the disk
   3) move the disk, same device-type, same size
   4) repeat steps 1 & 2 above, neither the FILE timestamps nor the
      last update timestamp reported by MDSKSCAN show any change.
   5) move the disk to a different device-type (3380->3370)
   6) repeat steps 1 & 2 above, the FILE timestamps are preserved, but
      MDSKSCAN indicates that the disk was updated TODAY.

I believe that this is because MDSKSCAN takes its info from a timestamp in
the CMS file system's directory on the mdisk, not from file timestamps,
from a directory timestamp.

I also believe that VMSECURE will use DDR to move a disk when DDR is a
viable option (same device architecture, same size).  Otherwise it will
use COPYFILE (or alternative).  With DDR, the entire disk image, including
the file system directory is moved intact, with no change.  With COPYFILE,
only the data is kept intact, the physical structure of the file system
will changed, and the file system directory will be re-written (more than once)
and will contain today's filestamp.

Jim Colten
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Tue, 25 Aug 1992 21:36:32 +0300
From:         Larry Israel <VSLARRY@WEIZMANN.WEIZMANN.AC.IL>
Subject:      RE: Problem with old VMBACKUP

The VMBACKUP in question that has errors on some minidisks after it was used
to go from a 3380-A to a 3380-K is Rel 4.1.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 10:09:00 EDT
From:         Bob Fowles 814-865-4774 <RBF@PSUVM.BITNET>
Subject:      Re: Fixes via Direct Info

Hi Nick,

I can now send e-mail directly to IBM employees via Internet (the one I am
currently using is a ".com" address).  I have previously done that with a
DEC employee.  Sure would be nice to have something like sci.info.com
where I could send an error report (or the like) and receive a fix or info
about the problem.  Right now, I type up a report, SCRIPT it, print it on
an 3812, take it to our FAX machine, FAX it, your secretary picks it up and
gives it to the recipient, who then goes through a similar procedure to FAX
a response.  Time to use the Internet!  (gee, do I sound like a salesperson?)

Bob
From: STOODT@NUACVM.BITNET (Tim Stoodt)
Newsgroups: bit.listserv.l-vmctr
Subject: Last date a minidisk was updated.
Date: 28 Aug 92 17:31:09 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Hi,
    Am I wrong or does moving a minidisk with VMSECURE change the
"last updated" date you see when you do a MDSKSCAN or run the VMRMUA
report?  If so, how do I work around this?  I want to clean old minidisks
off a couple of volumes.  Thanks.  T.S.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Temple University -- Computer Services
X-Acknowledge-To: <V4039@vm.temple.edu>
Newsgroups: bit.listserv.l-vmctr
Date:         Fri, 4 Sep 1992 11:26:47 EDT
From:         Stan Horwitz <V4039@VM.TEMPLE.EDU>
Subject:      Temp and perm disk accounting

Several of you  were kind enough to reply to  my posting regarding vmarchive.
My boss and  I spent this morning writing a  set of specifications indicating
how we  want our systems folks  to configure VMarchive. The  input I received
from several l-vmctr subscribers was very helpful.

It would be very helpful for planning and monitoring purposes if we could use
one of VMaccount's reports  to show us the average file size  of files on our
system, both on  temporary and permanent DASD. Information  about the average
length of time files are stored on both  types of DASD would also be nice. Is
such  a  report available  through  VMaccount?  The VMaccount  manual  listed
several informative reports,  but none seem to provide this  level of detail.

If a report with  this level of detail is not available,  then is it possible
to generate a snapshot  filelist of every file on the  system at a particular
time, including  temp disks  that looks  like a filelist.  I can  easily pull
this file into SAS and do lots of  analysis on the file sizes. I will even be
able to group statistics into  classifications such as faculty, student, etc.
that VMaccount will not let me do as easily since it has no waying of knowing
which accounts fall into a particular classification.

Stan Horwitz, Consultant    | Bitnet           | Internet
Temple University           | V4039@TEMPLEVM   | V4039@VM.TEMPLE.EDU
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Portland Community College
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 14:59:31 PDT
From:         "Russell N. Hathhorn, VM Systems Support" <SYSMAINT@PCCVM.BITNET>
Subject:      Re: Direct ( lack-of / impossible to get at ) Info

HERE HERE !!!  Absolutely - SCI belongs on BITNET !!!

Feel free to add my name to any communications to SCI urging such a move.

+---------------------------------------------+-------------------------------+
|   Russell N. Hathhorn                       |  Bitnet: SYSMAINT@PCCVM       |
|   VM Systems Programmer/Analyst             |  Compu$erve: 76636,1036       |
|   Portland Community College                |  Voice: (503) 244-6111 x 4705 |
|   12000 S. W. 49th Avenue                   |  Fax:   (503) 324-7010        |
|   Portland, Oregon  97219-0990              |  "     Just say NO to OCO   " |
+---------------------------------------------+-------------------------------+
| "No free man shall ever be debarred the use of arms.  The strongest reason  |
|  for people to retain the right to keep and bear arms is, as a last         |
|  resort, to protect themselves against tyranny in government."              |
|  Thomas Jefferson - Proposal Virginia Constitution, June 1776               |
|  Thomas Jefferson Papers, 334 (C. J. Boyd, Ed., 1950).                      |
+-----------------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.l-vmctr
Date:         Thu, 3 Sep 1992 19:24:55 EDT
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      How do you feel about DIRECT INFO?

Ok folks, here is your chance. I passed some negative
info for the dial-up DIRECT INFO at Systems Center,
and now management asked me to check this out a bit
more. They want to know how you feel about it, and
what you like, or what you dont.

You can write to me personally instead of this list,
and try not to hit me too hard, just a couple of years
ago I used to be at your side.

I will pass all comments I received to management.
If you want your comments to go anonymously, then
simply dont sign your name underneath, as I plan
to strip off all headers completely. If you want
your comments to go under your name, then simply
put your signature file or your name and orginization
underneath your comments.

I will not pass anyones comment, to anyone else, ie
if JIM@NOWHERE sends me a note, JOE@somewhere.else
will not see it, ie your notes will be confidential.

One last request: Please be short and to the point.
Present your arguments and make your case.

So send me your comments about direct info. Tell me
why its difficult, why its easy... why its useful,
why its a pain...

At this point I would also like to thank Bob Fowles
from Penn State for the info he sent me on INTERNET,
who knows, maybe we'll get lucky this time.

Nick Gavrielatos
SCI Customer Services
ucnick@socrates.umd.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.l-vmctr
Date:         Tue, 25 Aug 1992 23:07:19 EDT
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      Re: Fixes via Direct Info
X-To:         L-VMCTR@VM1.CC.UAKRON.EDU

To setup an ibmmail id it costs extra money. Those of you
who have it know what I mean. Even after that you get charged
by the amount of info you sent out(usually by the Kilobyte).

One more thing: Watch out when you download fixes from the
BBS, because the NOT sign in rexx(^) as well as the OR
character(|) dont get downloaded correctly, but instead
get translated to some other irrelevant hex character,
which of course if pass undetected can cause problems
later on.

Nick
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 16:21:23 CST
From:         Jim Colten <IJIM@UMINN1.BITNET>
Subject:      Re: quality ???

On Wed, 26 Aug 1992 16:28:00 EDT Bob Fowles 814-865-4774 said:
>>>
>>>running under vmrmaint, with vmsecure mdisks pointing to alternate
>>>mdisks, and alternate mdisks ( only ! ) accessed, vmxmacup updates the
>>>PRODUCTION vmsecure 191 with error macros and trashes system !!!!!!!
>>
>>That is working as documented.  For that reason, and because there really
>>is no such thing as safe testing of a directory maintanence product on a
>>production system, we *ALWAYS* apply fixes and mods to new VMSECURE shipments
>>on a second level system.
>>
>>Jim Colten
>
>I'm not sure what you mean by "working as documented".  For years I have been
>using SCI distribution tapes under VMRMAINT to upgrade VMSECURE using only
>alternate minidisks, and the upgrade process has never invoked VMXMACUP to
>change the production VMSECURE 191.  Perhaps you are referring to an upgrade
>step that I never select.  When the upgrade finishes, I then logon to a
>2nd-level system where I have the alternate minidisks mapped and test it
>there.  When ready for production, I switch addresses in the 1st-level
>VMSECURE and restart.
>   Bob Fowles, Center for Academic Computing, Penn State

I meant that the described VMXMACUP behavior matched the VMXMACUP documentaion.

I am not aware of any procedure available via VMIMAINT that invokes VMXMACUP.
In the original post, VMXMACUP was being used (at the customer's descretion)
to apply some fixes.

The procedure you describe is essentialy the procedure we follow except that
since we have fallen to the temptation to add function to VMSECURE, we have
quite a bit more than just testing to do on the level-2 system.

Would it be nice to have an alternate-disk-aware VMXMACUP?  You bet!  Am I
holding my breath?  No.  Besides, we still have to test at level-2, so the
the speed gained by VMXMACUPing at level-2 is at least partially offset by
the need to SESSION to level-2 for testing.

Jim Colten
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 14:45:07 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      quality ???

I am attempting to upgrade to vmsecure 4.4B

The tape I am using was cut 7/9/92

I have loaded the new code to alternate minidisks and am attempting
to apply 48 of the 52 corrections

zap 500 attempts to mod same bytes as 480

fixe 371, 455a, 455b, 492, 501a, 501b, 504, 530
all generate error messages during macup

running under vmrmaint, with vmsecure mdisks pointing to alternate
mdisks, and alternate mdisks ( only ! ) accessed, vmxmacup updates the
PRODUCTION vmsecure 191 with error macros and trashes system !!!!!!!

"how u like dem apples ??!? "

               AAAARRRGGH !!        Mike

ps - all zaps/fixes are listed on summary sheet for 4.4B - is there
     any chance that I should only be applying zaps/fixes that
     start X44B....   ??????? ( would still have some errors ! )
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Thu, 27 Aug 1992 07:45:03 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      fixes

   Maybe I'm old-fashioned, but if I see a fix listed on a sheet
labeled 4.4B summary, I naturally assume that fix applies to 4.4B
and should be applied if it is for a generic problem or a problem
related to the system/software config I'm running the package on -
else why tell me about ?

Especially when you see co-requisite fixes such as 455 (4 parts )
where 2 parts are coded X440.... and two are coded X44B

same type of thing for X44B530, pre & coreqs may be either X440 or
X44B

if a fix is X44A only, why put it on the X44B summary ?

am I asking/assuming too much ???                Mike
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 14:41:14 CST
From:         Jim Colten <IJIM@UMINN1.BITNET>
Subject:      Re: quality ???

On Wed, 26 Aug 1992 14:45:07 EDT Mike Ramundo said:
>I am attempting to upgrade to vmsecure 4.4B

Nice of you to precede me on this, just now starting that project myself!


>
>The tape I am using was cut 7/9/92
>
>I have loaded the new code to alternate minidisks and am attempting
>to apply 48 of the 52 corrections
>
>zap 500 attempts to mod same bytes as 480
>
>fixe 371, 455a, 455b, 492, 501a, 501b, 504, 530
>all generate error messages during macup

UGH!  Thanks for the warning.  You are going to call SCI and complain bitterly,
right?

>
>running under vmrmaint, with vmsecure mdisks pointing to alternate
>mdisks, and alternate mdisks ( only ! ) accessed, vmxmacup updates the
>PRODUCTION vmsecure 191 with error macros and trashes system !!!!!!!

That is working as documented.  For that reason, and because there really
is no such thing as safe testing of a directory maintanence product on a
production system, we *ALWAYS* apply fixes and mods to new VMSECURE shipments
on a second level system.

>
>"how u like dem apples ??!? "
>

Jim Colten
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Tue, 25 Aug 1992 13:13:51 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      Re: VMARCHIVE

archiving from temp disk via staging are is std operation here - no
problem as long as 'DELAY' is NOT specified and as long as user
remembers to 'VMARCH QUERY FILES (fn) (FT) ( for *' so that he/she
sees all versions regardless of disk they were archived from
From: RWWMAINT@MSU.BITNET (Richard W Wiggins)
Newsgroups: bit.listserv.l-vmctr
Subject: Re: Last date a minidisk was updated.
Date: 28 Aug 92 19:03:06 GMT
Article-I.D.: VM1.L-VMCTR%92082815043251
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

>Hi,
>    Am I wrong or does moving a minidisk with VMSECURE change the
>"last updated" date you see when you do a MDSKSCAN or run the VMRMUA
>report?  If so, how do I work around this?  I want to clean old minidisks
>off a couple of volumes.  Thanks.  T.S.

I believe that date is simply the latest file update timestamp
encountered for that minidisk; ie. moving the minidisk will
not change the timestamp.  We run our Clearvol process (front
end to VMSECURE) to clear entire volumes without worrying about
changing any data or timestamps within minidisks.

/Rich Wiggins, Michigan State U
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 15:24:45 CDT
From:         Chris Hardy <CHRIS@RICEVM1.RICE.EDU>
Subject:      Re: quality ???

On Wed, 26 Aug 1992 14:45:07 EDT Mike Ramundo said:
>I am attempting to upgrade to vmsecure 4.4B
>
>ps - all zaps/fixes are listed on summary sheet for 4.4B - is there
>     any chance that I should only be applying zaps/fixes that
>     start X44B....   ??????? ( would still have some errors ! )

I think you should apply only the X44B....  zaps.  Let me know  what
SCI thinks about this after you talk to them.  We are running 4.4A with
zaps applied with prefix  X44A...  only.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Wed, 26 Aug 1992 17:22:52 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      Direct ( lack-of / impossible to get at ) Info

I recently was drafted as POSTMAST for all of the network nodes here
at SUNY-Albany, and as such have been gathering as much info on bitnet
and listserv as possible (in the pauses betwix regular responsibilities)

I understand that a for-profit company only has to pay a negligable fee
( relative to what we all pay for maintenance ! ) ( i believe <<5K )
to become connected to BITNET.

I think we should demand that Systems Center connect to BITNET and
bring up LISTSERV.

Each Product/Version could be a list - to which we could all do the
standard listserv commands: index, get, (etc) - ie

tell listserv at systmctr index vmx44b
       or
tell listserv at systmctr get vmx44b x440342

bulletins relative to a product could be kept either in the product
group or in a SCINFO or DRCTACSS list ( Think what they would save
having Direct Access online and at least partially distributed via
e-mail ) - i'd be first to subscribe !!

Think how much we ( and systems cntr ) would save in phone and
postage expenses. They could even set up some generic ids
such as SECURE-E to collect questions and/or problem reports
on vmsecure/E ( for example ), which could ( I would think )
be easily sucked into their current tracking system from that
id's reader !

Anyone want to join me in writing to the head of Customer Services
( I believe it is:     Art Allen, V.P. Customer Services )
with this suggestion/request ???

With all the gateways from various networks to bitnet, I think this
service would be of great benefit to all but a very small percentage
of SYSTEM CENTER's customers
( only those having no net connections of any kind at all ( are there
  any serious sites willingly in that category ?? ) )

how about it ??

           Mike

*---------------------------------------------------------------------*
                                                                     
  Michael R. Ramundo                        Fax (518) 442-3697       
  Systems Programmer / Analyst            Audio (518) 442-3709       
  Computing Services Center, CS-9C               Network             
  State University of N.Y. at Albany        SYSMRR @ ALBNYVM1        
  Albany,  New York    12222            SYSMRR @ uacsc2.albany.edu   
                                                                     
*---------------------------------------------------------------------*
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.l-vmctr
Date:         Sun, 30 Aug 1992 16:46:16 EDT
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      ZAPs/FIXEs Naming Convention
X-To:         l-vmctr <l-vmctr@vm1.cc.uakron.edu>

I thought I sent the following yesterday, but our system
is messed up lately, and I dont know if it made it there,
as it didnt really send it back to me(something that it
did for the test I send a few min ago), so here I am
resending it. Feel free to delete it if you've already
read it.

-----------------



I have been busy lately(havent we all) and didnt have
the time to answer right away, but I'd like to explain
a couple of things about the zaps or fixes naming convention.

Its probably better if I do it using an example or base,
so let that be vmsecure.

Currently there are 2 releases of vmsecure supported
the 4.4A release and the 4.4B release. I know a hand full
of people have 4.40 out there, but that was the LA or
Limited Availability release(post Beta if you wish) and
noone should really have that running production, but
anyway.

Well, suppose SCI makes a zap while 4.4A is in production.
It will be named X44Annn. Now, if this zap applies to the
4.4B release as well, it will not be copied to a X44Bnnn,
but will instead keep its old regular name. The 4.4B
summary file will include it, so that folks know to
apply that as well to the 4.4b release.

Another example. Suppose sci made a fix when 4.4 was in
production(it never really was, but for the sake of the
argument lets assume so). It was named X440nnn. Now if this
fix applies to 4.4A and even further to 4.4B, then it will
keep its X440nnn name, and that name will be included in
the summary file of both releases.

This is how things have always been here, and this stands
for all products.

As a result, the recommended way of applying maintenance
would be to obtain the product summary file, check and
find which zaps/fixes apply to your system(some are
for HPO only, some for XA etc, some might have an APAR
as a prereq etc) and then apply these zaps/fixes
REGARDLESS of the first 4 characters of their name.

The reason this convention is used is of course
maintenability. Its a lot easier to maintain one file
than 2 or 3 or even more. Careful here, I am not saying
this is my preferable way of doing things(I am not
saying its not either) so dont hit me :-) if you dont
agree with it, I am just saying how things are done
and what the naming convention is so that it might
help you apply maintenance easier and with fewer
headaches.

I hope that helps, have a nice day.

Nick Gavrielatos
ucnick@socrates.umd.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.l-vmctr
Date:         Sun, 30 Aug 1992 16:29:00 EDT
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      test
X-To:         l-vmctr@vm1.cc.uakron.edu

just a small test folks, sorry
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.l-vmctr
Date:         Thu, 27 Aug 1992 08:05:58 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      vmxmacup

Does anyone know how this macro works ? ie - if I change password
on vmsecure 191 and/or set up a rule to deny vmrmaint link 191 in
the vmsecure rules file, will that prevent interference with the
production system - only the current 'A' accessed by vmrmaint will
get updated ? ( Or does vmxmacup know when it is not running under
vmsecure and issue some undocumented commands to vmsecure to
send files from vmrmaint, receive them on vmsecure, and load updates
into vmsecures virtual storage ? )

( too early for this kind of stuff - eh ? )

mike
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU