X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.l-vmctr
Date:         Sun, 30 Aug 1992 16:57:33 EDT
From:         "Nick Gavrielatos" <ucnick@SOCRATES.UMD.EDU>
Subject:      VMXMACUP - How it works
X-To:         l-vmctr <l-vmctr@vm1.cc.uakron.edu>

Those of you who already know it forgive me, but let me try to
summarize the way VMXMACUP works and what it does.

Well, to run it you need 3 things. a) Access to VMRMAINT's 176
disk, since that's where all source macros live. b) the update
fix c) the AUX file. The update fix and the aux file you create
them by spliting the FIXE file that you get from SCI.

Now VMXMACUP first looks at the aux file and read the updates
that it has to apply. It reads the aux file starting from the
last record in there, ie it reads it in reverse order!
So if you have 2 fixes to apply, say 123 and 789, and if 123 is a
PREREQUISITE to 789, then the aux file should have them in the
following order
789
123

Many of the errors that result when we try to apply a fix with
VMXMACUP, are the results of an incorrectly coded aux file, so
that should be the first place to look if there is an error.

Now, VMXMACUP applies each update to the source macro, and it
finally creates an optimized version of the macro with all the
updates. It then does two things: It leaves a copy of this
optimized version on vmrmaint's 191 disk, just for our
reference, ie just so that we see what the updated macro looks
like. You can just erase that file away afterwards, it really
plays no role at all.

It also uses IUCV(actually the COPYTO primitive, which is an iucv
application) to send the optimized version of the updated macro
to VMSECURE's A disk. Careful here: It sends the updated macro to
VMSECURE's A disk, no matter what that disk is. If you access
VMSECURE's -say- FFF disk as its A disk, then that's where the
updated and optimized macro will go. It stays there so that next
time you recycle VMSECURE, it will pick this copy ahead of the
old one, and will load this one in memory instead again of the
old one.

Last but not least, it will issue a MACLOAD that will load the
updated and optimized macro in memory right away. This way you
dont have to bring VMSECURE down and up in order for a fixe to
take effect. The change takes affect right away, and while
VMSECURE is up and running, ie update is dynamic.

Now, that's just how it works, I am sure some would like it to do
extra things, or even different things, but that's pretty much
what it does. If you have an enhancement request call it in and
it'll take its turn, you know how things go...

One more thing. Everytime I was going to upgrade, I would always
erase from VMSECURE's 191 disk(every product's 191 disk) all the
updated macros, so that the newly loaded code would be executed.

There is even an exec that can help you here, I think it comes
with vmcenter or center 2, and its called(again I think) VMIDFC
for Duplicate File Checker. It takes as args two filemodes, and
it tells you what files are common in both these 2 disks, so you
can erase the ones on the product's A disk.

-------

I know that wasnt a very detailed explanation, but I hope it helps
explain VMXMACUP's general 'way of doing things' :-)

Let me know if you have any further questions, time permitting
I'll try them out. Have a nice weekend!

Nick Gavrielatos
ucnick@socrates.umd.edu

P.S. I miss my old VM userid... I hate unix, I'll never learn
     this vi editor thing, it takes me 2-3 times longer to type up
     a note...

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU