HP3000-L Archives

February 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Doug Werth <[log in to unmask]>
Reply To:
Doug Werth <[log in to unmask]>
Date:
Wed, 9 Feb 2000 09:29:51 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
Stan Sieler <[log in to unmask]> writes:

>
> 1. TUINSTAL Y2K bug
> -------------------
>
> The Turbo Update mechanism has a Y2K bug in it.  TUINSTAL builds
> the file TUSYSDMP, which builds a new SL and tries to create a SYSDUMP
tape
> with a partial backup.  If run today (8 Feb 2000), the partial backup
> would be specified incorrectly as 2/8/0 ... and STORE (which is used by
> SYSDUMP) doesn't accept a single digit year.

This is one of the documented Y2K issues with MPE/V. You cannot use SYSDUMP
for partial backups based on modify date, only STORE. Which is why it is
labeled Y2K Safe, not Y2K compliant.

>
> Workarounds:
>
>    1) change system date to 1999-12-31 before running TUINSTAL
>       (note: you may have to purge TUSYSDMP if it's already been built)
>
> or
>
>    2) edit TUSLINFO prior to running TUINSTAL and change the line
>       towards the end with "$$/$$/$$" to "02/04/00" (or some such)
>       ...note: I haven't tested to see if TUNINSTALL will complain
>       if it can't find the $$/$$/$$ line.
>

As an alternative I used a third workaround. Since the TUINSTAL process
doesn't operate like AUTOINST or PATCHIX (there is no Phase II restore) I
decided to edit the sysdump job and tell it *not* to store any files at all.

>
> 2. Release 40 Patches
> ---------------------
>
<snip>
>

I was disappointed that there was no supported method for applying all of
the patches at once. I would much rather have had an AUTOPAT type of script
where it prompts for each patch to name. I can't complain though HP gave it
away for systems that were no longer supported.

All in all thought is went very well.

Doug Werth                             Beechglen Development Inc.
[log in to unmask]                               Cincinnati, Ohio

 "Programming is an art,  not a science,  and not all programmers
  are Picassos."  -- Frank Bajak, Associated Press

ATOM RSS1 RSS2