Analysis by John Burke
Does anybody really know what time it is?
Does anybody really care?
As usually happens about this time of year, there were questions posted to
HP 3000-L about how to set the system clock. This is because most of us in
North America will be faced with resetting our system clocks at the end of
October to reflect the change from Daylight Savings Time to Standard Time.
If you are not on MPE/iX 5.0 or 5.5 you will probably wish you were, since
the only supported method HP provides is a system SHUTDOWN followed by a
system START. If you are at least on MPE/iX 5.0, then changing from
Daylight Savings to Standard time or vice versa is accomplished easily with
the TIMEZONE form of the SETCLOCK command. In fact, here is a snippet of
JCL from a scheduled job stream I use (I am located in the Eastern time
zone of the US):
!IF HPDAY = 1 AND HPMONTH = 10 AND HPDATE > 24 THEN ! SETCLOCK TIMEZONE = W5:00 !ELSEIF HPDAY = 1 AND HPMONTH = 4 AND HPDATE < 8 THEN ! SETCLOCK TIMEZONE = W4:00 !ENDIF
There is, however, one giant caveat to this: Your "real" system time must be correct. Check it now. (Note: If you updated to 5.0 or received a new machine, and have not already gone through a synchronizing process, there is a good chance you will need to. I did on both machines I manage.) For example, using the SHOWCLOCK command and SHOWCLKS.PUBXL.TELESUP on my system yields:
[2]:showclock SYSTEM TIME: SUN, SEP 8, 1996, 11:15:42 AM CURRENT TIME CORRECTION: 0 SECONDS TIME ZONE: 4 HOURS 0 MINUTES WESTERN HEMISPHERE [3]:showclks.pubxl.telesup SHOWCLKS/XL A.10.00 DEBUG/iX B.79.06 HPDEBUG Intrinsic at: 5e0.00007258 PROGRAM+$198 PRIV=$3 := $0 Greenwich Mean Time : SUN, SEP 8, 1996, 3:16 PM *** GMT/MPE offset : -4:00:00 *** MPE System Time : SUN, SEP 8, 1996, 11:16 AM *** C Library Information Current value of Time Zone(TZ) variable : NOT ASSIGNED CTIME function return : Sun Sep 8 11:16:07 1996
If your system does not look something like this (adjusted of course for your time zone), then you need to correct things first before adjusting for the change to Standard time at the end of October.
Step 1: RTFMs. See Chapter 10 of the 5.0 Communicator for a discussion of the SHOWCLOCK and SETCLOCK commands. Also, in the MPE/iX HELP system read over the (quite complete) entries for SHOWCLOCK and SETCLOCK.
Step 2: :setclock timezone=zn:00 (your timezone, e.g.
w4:00)
Step 3: :setclock ;cancel (stop the correction)
Step 4: :setclock date=mm/dd/yy;time=hh:mm;now (set
correct date and time).
That should do the trick. By the way, if important at your site, the TZ variable can be set via a system logon UDC. The form is: SETVAR TZ "EST5EDT"
To disable PARM=-1
or not to disable PARM=-1
It all started out innocently enough with the question: "I understand that
HP finally gave us a way to configure whether PARM=-1 is available at sign
on time. Can someone tell me how to change it?"
A spirited discussion ensued about the advisability of disabling PARM=-1 for logons with some MPE heavyweights chiming in on the side of "Don't do it."
First, a little background. Since the very early days of MPE/XL, users have been able to signon as "HELLO ..... ;PARM=ciparm" where "ciparm" is one of the allowed values for running the command interpreter as a program (0, 1, 2, 3, 4, 5 for any user and -1, -2 for users with SM capability; any other value is treated as 0). When passed to the root command interpreter via HELLO, 2 and 4 are equivalent to 0 while 3 and 5 are equivalent to 1. For example, with PARM=1 the session will terminate after processing the INFO= string or, if there is no INFO= string, after executing the first user-supplied command. Note that INFO="...";PARM=1 is therefore a replacement for the old command logon in Classic MPE.
If, however, a user with SM capability signs on with PARM= -1, or -2, then the CI banner and the welcome message is suppressed and UDCs are NOT cataloged. Thus, logon UDCs are not executed since they are not even known. If you rely on a security technique that uses logon UDCs as many people did and perhaps still do, then your security system is breached, especially if you stopped putting passwords on "MANAGER.SYS". So, there was considerable weight behind a request that HP provide some way to disable PARM= -1 or -2 for logons. MPE/iX 5.0 introduced such a way (I guess there was no perceived rush). Note: most commercial security packages use AIF Procedure Exits now and do not rely on logon UDCs.
The rational for allowing PARM=-1 in the first place? From an HP publication: "This is helpful in allowing a system manager or HP Technical Consultant to log into a system that is not allowing any user to log on." If you disable PARM=-1, you could have a serious problem on your hands some day. One consultant commented, "I've had to dial in and rescue users a number of times over the years ... generally with success. The two times this year that I actually failed to help the user was when they had done enforcelogonudcs=on."
However, it was pointed out that MANAGER.SYS is THE target for hackers, and if your system is accessible from the internet and your only security is provided by logon UDCs, you may be vulnerable to people trying to HELLO MANAGER.SYS;PARM=-1 until they guess your passwords.
So, what should you do? And suppose your only current avenue for enforcing security (beyond simple MPE passwords) is with logon UDCs? It was determined that you cannot remove MANAGER.SYS from your system nor can you remove SM from MANAGER.SYS. One HPer from Austria (Don't you just love the global nature of Internet communication?) came up with an interesting solution: Create a SM user that mirrors the capabilities of MANAGER.SYS but is known only to authorized personnel and then remove IA capability from MANAGER.SYS so that HELLO MANAGER.SYS... is not allowed because of insufficient capability.
Oh yes, if you still want to disable PARM=-1 (and PARM=-2) logons, i.e. always enforce logon UDCs, then do the following:
:HELLO MANAGER.SYS :SYSGEN MI SY ENFORCELOGONUDCS=ON HO EXIT K EXIT
Reboot with START NORECOVERY GROUP=config, where "config" is
the configuration group you kept the changes to (usually "CONFIG").
DLT and the HP 3000:
Has the time come?
The question: "From the HP World '96 Conference in Anaheim I gained the
impression that DLT technology is the new tape storage medium of choice. I
have two questions for consideration. a) Are DLT drives supported on the HP
3000 under MPE/iX? and b) What is HP's DLT drive strategy for the HP
3000?"
Also asked: "What are the advantages? Disadvantages?"
The responses (edited and paraphrased in spots):
"Currently, HP does not support DLT on the 3000. However, MPE/iX 5.5 PowerPatch 1 if I remember correctly will support the DLT4000. There appear to be three major advantages to DLT:To which was added"1) Performance: In raw numbers (without compression), DLT will handle more than 6Gb/hr backup. The raw numbers on the 7980 (the current fastest drive) are 3.4Gb/hr.
"2) Volume: While the 7980 can only hold 280Mb, the DLT4000 is able to hold 40Gb. I believe DAT, better referenced as DDS, will hold more than the 7980 on one media (@2Gb), but it too does not come close to the volume of the DLT4000.
"3) New Technology: It appears that as much as possible that the industry has selected the DLT to replace the DDS technology.
"One additional reason I've heard is the expected life of the media. DLT is expected to have a longer shelf life.
"Disadvantages? Well,
"1) You have to buy one.
"2) Different media/format. As with any new tape technology, you run into the problem of storing on one machine and restoring on another. You may find that you will need to retain at least one of your current drives."
"Finally,Actually, this (MPE/iX 5.5 PP 1) is not necessary for ORBiT's solution. We've been running DLT successfully on 4.0, 5.0 and 5.5. Please see http://www.orbitsw.com for our DLT White Paper. "
"The most important advantage to me is that DLT offers a bit-error rate (hard-error) of 1 in 10EXP17 vs 1 in 10EXP14 using DDS technology. This means that unrecoverable errors will occur 1000 times less frequently than DDS."NSLOOKUP: no, it is
Chris Bartram of 3K Associates provided the setup information to use nslookup:
"Since nslookup is a Posix application, it's looking for the Unix nameserver-resolver file (/etc/resolv.conf). You need to create a symbolic link from /etc/resolv.conf to /SYS/NET/RESLVCNF. In the Posix shell, you'd type:ln -s /SYS/NET/RESLVCNF /etc/resolv.confFrom MPE, type:
:NEWLINK /etc/resolv.conf;to=/SYS/NET/RESLVCNFThere are other files you should probably link:
:NEWLINK /etc/services;to=/SYS/NET/SERVICESBy the way, HP is now shipping something called "nslookup.nsrv0000.telesup" (introduced in General Release 5.0 patch NSSED95) that is not the full NSLOOKUP port. Rather, it simply allows you to look up host addresses."
:NEWLINK /etc/protocol;to=/SYS/NET/PROTOCOL