Of course in the old days, the operator would simply set the session
limits to zero or the jobfence to 14 so no new log ins would occur
during the minute or so this is all going on.
(GUI clients notwithstanding. I've noticed they always let users in as
long as their job is running. They don't pay attention such system
trifles as "fences" and "limits".)
On 12/15/22 12:46, Roy Brown wrote:
> Amen to Copy. When zipping a year’s weekly audit files, I was very careful to Copy, not Move, and then cross-check the file counts, and try re-expanding a couple of the files before deleting any originals.
>
> But I wouldn’t do the ‘keep a copy and edit that next time’. Not only would I need to keep track of what copies I had made of what, and where, I’d have to liaise with my fellow SysAdmins to ensure they did the same thing on their shifts.
>
> So, copy the live version every time.
>
> Re the Purgelink and replace, yes Copy would be safer than even Rename, I guess.
>
> But neither approach would quite be atomic, so I was trying to minimise that fraction of a second where somebody logging on could theoretically hit the gap between the two steps; firstly, by putting the two steps in a command file, and secondly, by thinking a Rename would be faster than a Copy.
>
> But putting the two steps in a command file, and just executing that, would be the key gap-minimiser here. We humans type s-l-o-w compared to the HP3000, and nobody rings that between steps, or offers it pizza 😛
>
> Roy
>
>
>> On 14 Dec 2022, at 23:27, Tracy Johnson<[log in to unmask]> wrote:
>>
>> Fair enough.
>>
>> Although I would have done a copy instead of a rename.
>>
>> And edited the copy next time it needed editing. Just habit I guess.
>>
>> I got to teach my habit to my son when he moving files from a USB stick to his laptop. Midway it failed, and he lost half of files. I told him never do a move, always do a copy.
>>
>> (Although this is just one file, the chance for failure in the middle of a rename is very very small.)
>>
>>
>>> On 12/14/22 18:09, Roy Brown wrote:
>>> Yes that’s exactly what you do:-
>>>
>>> Open MPEXMGR, edit it, save it as MPEXMGR2 or whatever,
>>> PURGELINK MPEXMGR
>>> RENAME MPEXMGR2, MPEXMGR
>>>
>>> Everybody else will keep using the old MPEXMGR until they log out, and will pick up the new one when they log in again. The old file will die when its last accessor has gone.
>>>
>>> Absolute lifesaver when you have to modify UDCs on a live system.
>>>
>>> Roy
>>>
>>> Sent from my iPad
>>>
>>>>> On 14 Dec 2022, at 22:56, Tracy Johnson<[log in to unmask]> wrote:
>>>> There are probably other lines of the MPEXMGR file that are probably still useful.
>>>>
>>>> PURGELINK will get rid of the whole file.
>>>>
>>>> (Unless you kept a copy of the newly saved MPEXMGR file and put it back right away.)
>>>>
>>>>
>>>>> On 12/14/22 17:49, Roy Brown wrote:
>>>>> Wouldn’t PURGELINK be usable to avoid this?
>>>>>
>>>>> Roy
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>>>> On 14 Dec 2022, at 13:53, Tracy Johnson<[log in to unmask]> wrote:
>>>>>> Or several lines.
>>>>>>
>>>>>> (Which means you'll need to get everyone out of MPEX that's in it.)
>>>>>>
>>>>>>> On 12/14/22 08:46, Tracy Johnson wrote:
>>>>>>>
>>>>>>>
>>>>>>> There is a line in MPEXMGR.PUB.VESOFT you need to comment out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 12/14/22 08:41, Craig Lalley wrote:
>>>>>>>> This is strange. I uninstalled netbase, rebooted. I still get these messages when I try to run MPEX
>>>>>>>> NetBase shell is not globally installed
>>>>>>>> Error: NetBase interface unavailable.
>>>>>>>> What is causes this?
>>>>>>>>
>>>>>>>> -Craig
>>>>>>>>
>>>>>>>>
>> --
>> Tracy Johnson
>> BT
>>
>>
>>
>>
>>
>>
>>
>> NNNN
>>
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visithttp://raven.utc.edu/archives/hp3000-l.html *
--
Tracy Johnson
BT
NNNN
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
