The previous month wasn’t an aberration. For the second
straight month the number of off-topic postings to HP3000-L, particularly
rants, was way down and the technical content was way up. Among the off-topic
items of interest, Alfredo Rego shared this from an article in the Financial
Times: “IT workers knowledgeable in mainframe operations are a dying breed,
although the hardware they run has proven surprisingly resilient to extinction…
Experts say organizations are facing
pressure to find adequately trained staff to maintain their mainframes...” Then
there was the report about the Multnomah County, Oregon Heath Department
looking for a Klingon interpreter for patients who speak Klingon. And, of
course, the report that New Hampshire's famous rock formation, "The Old
Man of the Mountain" finally succumbed to the erosion that created it.
And, finally, there was the report about Microsoft developing for the UK market
a portable toilet with Internet access called the “iLoo”. Was it really a hoax
as Microsoft later claimed?
In mid-August, Interex will be holding HPWorld 2003 at the Georgia World Conference Center in Atlanta, Georgia. As co-Chairman of SIGMPE, I’d like to invite everyone to join us at the last SIGMPE meeting before end of sales for the HP e3000; and, possibly, the last SIGMPE meeting ever. I hope that is not the case, but it is up to those with a continuing interest in MPE to keep the flame alive. Let’s try to make this the biggest SIGMPE meeting ever. One major topic of discussion will be the 2003 (and probably final) SIB and HP’s response. We are expecting HP’s formal response any day now, after which I hope to engage a discussion on HP3000-L. At the HPWorld 2003 SIGMPE meeting HP will report on its progress and we will have an opportunity to lobby on behalf of our favorites. At the 2003 HP e3000 Solutions Symposium Mike Paivenen of HP strongly suggested that vCSY would continue to work on specific enhancements even after October 31, 2003 if there is obvious value to its customers.
I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
Is the root file the root
of all knowledge?
This was the question: “I have an Image database in which the item declarations have been added willy-nilly, and now I'd like to sort those declarations for easier readability without breaking my database and without doing a reload. Will this work?” He then went on to describe how he wanted to generate a schema with Adager, sort the item list, create a new empty database with this schema and replace the original root file with the new one.
Leonard Berkowitz, Patrick Mullen and Wyell Grunwald noted that since he already had Adager, he could just use the ITEM SHUFFLE command to achieve the desired result. However, they warned that any application that uses item numbers instead of item names would have to be fixed; Omnidex being one example, along with Netbase and Bridgeware (which uses Netbase).
The discussion then veered of to discuss whether replacing the root file like this would work. Several people, myself included, chimed in that we had done similar things successfully in the past. Why were we successful? Because all the logical information about the database is contained in the root, and there is nothing in the datasets except data, links and counter information.
Some people have suggested that physical information, such as the number of entries in a dataset (FORM SETS in QUERY), is contained in the root file making the suggested swap invalid. This is false. When you do a FORM SETS in QUERY, each dataset is opened to determine the number of entries. A useful side effect of this is that if you open the database in QUERY with write access and issue the FORM SETS command, each dataset has its accessed and modified timestamps updated. (If the database is only opened with read access then only the accessed timestamp is updated.)
The
key nowadays though is to get an engineer interested. One user reported that
his efforts to remotely create a KSAM/XL file using RFA over a DSLINE were
failing with FSERR 3, required parameter is missing. After people checked
around a bit, it was discovered this worked for CM KSAM files but not NM KSAM
files (KSAM/XL).
The problem piqued the interest of Bill Cadier who reported, “It looks like this problem has been around a while. It took me some time to locate the service request filed for this, which is 5003-175117. It has not been fixed and I think the only reason for that is that nobody other than the original reporting customer ever encountered this.” A few days later, Bill reported, “I was able to track down the source of the difficulty. It was just a simple oversight in the code. It was only checking for the CM KSAM file type in deciding whether to process the KSAM parameters into the forms message parameter that would be passed to RFA'FOPEN. The patch that will fix this will be MPEMXG5. I've no ETA on it as it hasn't yet been prioritized on the lab's to-do list yet.”
“They
shouldn't have a parameter if they don't want someone to fiddle with it.”
One HP e3000 user with time on his hands was looking through SYSGEN and came upon the following table (MISC -> SHOW):
JOB
command parameter MAX MIN
CURRENT
----------------- ----------- ----------
---------- ----------
DEFAULT
CPU LIMIT cputime 32767 0 0
MAXIMUM
LIMIT maxlimit 3010 0 60
POOL
SIZE pool 200 1 1
He then noted that the pool controls the number of JSMAIN processes and wondered whether there was a situation where you would want to configure the minimum to be 2 or more and whether this was at all analogous to creating a pool of VT server processes.
In separate postings, Steve Macsisak and Stan Sieler provide an explanation: (SM) “the main advantage is so two people can log on at the same time. If you only have one JSMAIN one will have to be created for you before you can logon. If you have a small pool then you don't have to wait for one to be created. But having a pool of more than a few is not of much use since the OS will still keep that many in the pool all the time. Its not like the VT servers where you use the pre-built servers first and the OS will not create a new one until all of the pool has been exhausted. So for VTs you should have a few more than you will ever need which cuts down on process create overhead. For JSMAINS four or five on a very busy system will probably be enough to keep anybody from having to wait for one to be created.”
(SS) “As Steve said, it affects the performance during logons. It only comes into play during two or more (nearly) simultaneous logon attempts. Thus, if your average time between logons is several minutes, you generally won't benefit by having more than 1 spare JSMAIN. Note that you can configure the JSMAIN pool for SESSIONS independently from JOBS. If you have a lot of short jobs (e.g., averaging 5 or more jobs starting per minute), you might want to increase the JOBS JSMAIN pool. The same reasoning applies to sessions. In short, most people do not need more than one or two.”
Jazz has a document originally prepared by Scott McClellan, but I believe updated by others that documents operating system limits. Anyone dealing with administering an MPE system should have it book marked: http://jazz.external.hp.com/papers/limits/intro.html.
A new user writes, “I have to write a program (in Java or C++) to externally reset a password for a user on the HP 3000. Can anyone guide me on this?” Lars Appel responded "Why not simply let the user change it with the PASSWORD command? Type HELP PASSWORD ALL at the MPE prompt to see details." Several of us supposed “experts” were embarrassed to admit we didn’t know about the PASSWORD command and asked Lars when it was added. He responded that he was able to find it in his personal documentation system. It turns out the PASSWORD command was documented in the Communicator for MPE/XL 3.0, which explains (though it does not excuse) why some of us missed it. I know that in my case, I went from the Classic systems to MPE/XL 4.0 and probably never read the 3.0 Communicator. After Lars’ posting, I went right to my handy Orbit Pocket Guide and read through the list of MPE commands to see if there was anything else I was missing.
Of course it does not help that the 3.0 Communicator is not available publicly online. In fact, little prior to MPE/iX 5.5 is available online. One of the items finishing in the top ten on the 2003 SIB was about making all documentation publicly available even after 2006.
And, another from the “they haven’t turned off all the lights yet”
department,
James Hofmeister reports, in Mark Bixby's Solutions Symposium talk: "Is Your Homestead Secure? (Keeping your e3000 safe from hackers until 2006 or beyond)", he referenced a future fix to FTP: "A future version of FTPSRVR will likely add a new parameter to SETPARMS.ARPA.SYS to globally enable or disable 'site stream'." The future is now. The SR is 8606299646 and the enhancement is documented in FTPDOC.ARPA.SYS, which is included with the patch:
FTPHD07 for C.65.00 (Limited Distribution)
FTPHD08 for C.70.00 (Limited Distribution)
FTPHD09 for C.75.00 (Limited Distribution)
Contact our friends at the HP-Response Center 1-800-633-3600 and ask for enhancement (SR 8606299646) if you want this one.