RAC Consulting Sponsor Message

A Copy of History

By Steve Hammond

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX.

Illitch looked up at the trees. Reb bullets were buzzing overhead like hornets. Leaves fell as if it were windy October afternoon, not a hot July morning. To his left, he heard a groan and a thud. When he looked, the poor soul lay on the ground quivering with a horrific head wound. Despite all this, the German boys of 27th Pennsylvania had to hold this line to cover the rest of the corp’s retreat, so the bullets be damned.

I’ve been taking a course on writing historic fiction. But my assignment above made me think about the history of MPEX, now that we are in the year 22 AV (After Vesoft — 2002 to most of the rest of you).

What’s your history with MPEX? What was the first MPEX command you used? I can tell you my answer to that — COPY, or actually its predecessor FCOPY. That command made managing a 3000 so much easier. Where I worked, they seemed to love reorgs long before the Dilbert/PHB era. I regularly had to move the HPWORD (remember that?) files from one account to another when someone got reassigned. Before we had MPEX, as system manager, I was doing DSCOPYs and STORE/RESTOREs about once a day — very labor-intensive. The arrival (or I should say smart purchase, by me) of MPEX made life much easier. I could move files around with ease, matching the transfer of people from one department to another.

But COPY is so much more and so much more powerful these days, so it’s time for us to look at being all you can be using COPY. The feature I use the most (and appreciate the most) is the ability to copy a database (or any other PRIV files). It is a very important tool in our nightly processing.

As I have mentioned in the past, one of the main segments of our nightly processing was a series of jobs which did intensive database updating. In olden days (when “disk was expensive”), we would do a DBSTORE of the databases at the start of each job. Now one of the first steps in each job is to do an MPEX COPY of the databases to a specific group. No more DBSTOREs, no more tapes. That nightly series of jobs went from using 13 tapes to four because of the addition of MPEX COPYs of databases. (As an aside, you need to ‘manage’ this just as you would any other process. Put IF statements in the job to check that the right number of files were copied — checking the MPEXNUMSUCCEEDED jcw is the easiest way. Then create a job that will use MPEX to COPY those databases back into production. Why are you being careful to make a copy of a production database if you don’t set up a means of getting it back into production?)

And that’s just one small part of COPY!

The syntax is fairly simple:

%COPY PRODB@.GROUP.ACCT,=.NEWGROUP.NEWACCT

If you’ve got SM capabilities you can copy across account boundaries. And what if the file already exists? Well, there’s a set of keywords — YES, NO, ASK. If you are running in interactive mode, ASK is the default option, meaning if the file exists, MPEX will ask you if you want to write over it. In batch mode, YES is the default. If you tack “;YES” onto your MPEX command, MPEX will not ask and will overwrite the existing files.

My personal favorite keyword is KEEPATTR — keep attributes. We have a user with SM capabilities named SYSMGR. A lot of work is done by that user, including copying of files from one account to another. If you don’t use the KEEPATTR option with COPY, the creator of the “to” files is SYSMGR. This is no problem until you start doing some STORE/RESTORE functions and you discover that SYSMGR is not a user in the that account. Now this doesn’t totally solve the problem, but it reduce some of the headaches. Of course attributes are more than creator — also retained are the file security, and the creation and restore dates. In fact everything remains the same except for the last modify and access dates and times and a lockword, if present.

If you need to keep those modify and access dates, then use KEEPAMDATES. So copying a group of files and retaining everything (except the lockword) would be done with:

%COPY fromset.GROUP.ACCT, toset.GROUP.NEWACCT;KEEPATTR;KEEPAMDATES

If you have a group of files with lockwords and you want to copy them and keep the lockword, then the way to do it is:

%COPY @.GROUP, @/=.NEWGROUP

This says keep the same lockword as you copy it.

You can copy files to a specific device (or group of devices) with the DEV= option. This allows you to copy across DS lines if you have established that remote connection. COPYACD will bring the ACD along with the file.

And on top of all this, you can use any of the ALTFILE attributes. What, we haven’t discussed the ALTFILE command? Hmmm, sounds like a good topic for a future column.

Steve Hammond, whose great-great-grandfather founded the 27th Pennsylvania Volunteer Infantry, works for a trade association in Washington, DC.