Last Updated: Tuesday, April 04, 2000 02:50 PM
Something's not working?
Call the HP Response center to report your problem, or search the electronic support database for information on your problem and info on whether a patch for it is available (or perhaps a workaround).
Look at the contents of HPSWINFO.PUB.SYS. There is a section in there
that
gives you the info you need.
The "pull" release is an early release that is available to the public, and
supported (not beta), by request. If you need a feature
available, a
patch, or just want to try out the new O/S, you can contact the RC and request
the "pull" release. Generally, there may be a couple of features that were
not completed yet for the "pull".
The "push" release is the completed
version for features. The shipping division (SRDO) will provide the "push"
release to *every* customer on support for that O/S. This means that
within the "push" date, everyone on 3000 support should receive their new update
within 3 or so months.
Print the contents of 'LOGDCC.PUB.SYS'
MDHGet the 'UPTIME' (free) program from Allegro Consultants (www.allegro.com)
See the Autorestart/iX manual for details on setting up this reboot functionality. Autorestart reboots the system in the event of a crash, takes a full (or mini) memory dump, then automatically comes up ready to run (by auto-streaming a startup job, the system can be completely ready to use after a system crash without anyone having to touch it).
Or, the el-cheapo method (which does NOT do a memory dump - just restarts the system);
Gilles Schipper provides the following mini-tutorial:
Step 1: Create an AUTOBOOT.PUB.SYS file, as follows:
:hello manager.sys
:editor
/a
1 START NORECOVERY#@
2
//
....
/C "#" TO '13 IN 1 <<changes # to be a CR >>
/C "@"
TO '10 IN 1 << changes @ to be a LF >>
/ k
autoboot.pub,unn
Step 2: Mark AUTOBOOT file as SYSTEM FILE, via SYSGEN
:hello manager.sys
:sysgen
sy
aauto file=autoboot.pub.sys
type=disc
hold
exit
keep
exit
Step 3: Create new SLT tape
Step 4:
During re-boot, at ISL prompt,
AUTOBOOT ON
Step 5:
boot from tape drive path (normally alternate path) and UPDATE CONFIG
That's all there is to it.
AUTOBOOT can be toggled on and off easily after that, with the ISL
AUTOBOOT
ON/OFF command.
If I understand the second part of your question, the above procedure
will
NOT result in a memory dump.
If you need to perform one, simply intercept the AUTOBOOT (by pressing
any
key within 10 seconds), reply Y to the question "Interact with IPL?",
and
then typing DUMP at the ISL prompt.
For ODBCLink from M.B. Foster:
--hardware on PC (net card/serial port/etc?)
one or more of the following:
- serial port (modem or hard wire connection)
- TCP/IP lan card
--software on HP3000 (product names, versions)
ODBCLink from MB Foster
ThinlanLink (part of MPE/iX 5.0 push) (only if you want lan connect
Image (Image/SQL not required, although can be used)
Allbase (optional)
Cognos PDL v 7.29 (optional, gets to KSAM and flat files)
host software for serial, PPL and winsock is supplied
--software on PC (product names, versions)
winsock.dll (WRQ's is nice, FTP Corp tested also) if you want
winsock connection
RNS from WRQ if you want lan connection via PPL
A client to use, we have tested with the following:
Impromptu v2.0 (Cognos)
PowerBuilder
MS Access v1 v1.1 or v2.0
Visual Basic v2 or v3
Visual C++ v1 or v1.5
MS Excel (really MS Query)
--any "bugs" or "features" to watch out for?
- with Image detail data sets, must have a unique key item for
updates
- most of the Microsoft products use a common interface called
the Jet Engine which causes updating problems in many cases
- using Visual Basic, if you code calls to the ODBC library, it
seems
that it works better than if you rely on the Experts that tend
to call the Jet Engine routines
--------------------------------------
For HP PC/API that comes with Image/SQL
--hardware on PC (net card/serial port/etc?)
- TCP/IP lan card
--software on HP3000 (product names, versions)
ThinlanLink (part of MPE/iX 5.0 push)
Image/SQL
Allbase (optional)
--software on PC (product names, versions)
RNS from WRQ is all I have used, don't know if alternatives exist
A client to use, we have tested with the following:
Impromptu v2.0 (Cognos)
PowerBuilder
MS Access v1 v1.1 or v2.0
Visual Basic v2 or v3
Visual C++ v1 or v1.5
MS Excel (really MS Query)
--any "bugs" or "features" to watch out for?
- versions prior to G.xx have been problematic, if you get involved,
best to get latest and greatest from RC before you begin
- with Image detail data sets, must have a unique key item for
updates
- most of the Microsoft products use a common interface called
the Jet Engine which causes updating problems in many cases
- using Visual Basic, if you code calls to the ODBC library, it
seems
that it works better than if you rely on the Experts that tend
to call the Jet Engine routines
[basename]GB - Created when the database is opened in batch or online.
Some concern because the file is released.
[basename]TC - Permanent file.
DB
The [basename]GB file is in actual fact the MPE/iX replacement for the DBB and DBG buffers of yore (MPE/V and IMAGE/V on MPE/XL) It is created when the first user accesses the database and purged when the last user closes the database. The buffer settings in DBUTIL have no effect on the size of this file.
The [basename]TC is a file that is created at ATTACH time. It is a small file and each record contains the name of the DBE to which the DB is attached. When the last DETACH is performed for that base, the TC file disappears.
There is also an ATCINFO file associated with the DBE that gets created at ATTACH time.
MWNote about Allbase (IMAGE/SQL) files
------------------------------------
I hope this clears up the confusion concerning
DBECon,DBEFiles,DBEFileSets etc..
An Allbase DBE consists of three types of file:
DBECon One only. This contains Allbase
startup parms such as logging
and other various controls
DBEFiles From one to thousands
User data is kept here
DBELogs For logging activity for recovery
and auditing
DBEFiles are collected together to form "DBEFileSets" There is no IMAGE counterpart to the "DBEFileSet", and is best imagined as a bunch of OSFiles grouped under a single heading. It is a "Set of DBEFiles", or DBEFileSet.
There may be many DBEFileSets created in an Allbase DBE. Remenber, a DBEFileSet is a logical thing, not physical
When an "Allbase native" table is created, its storage is allocated to a DBEFileSet, and not a single OS file which is the case when allocating a dataset to a file under turboimage. (IMAGE/SQL tables do not have any storage allocated to them out of ALLBASE DBEFileSet space, just a few rows in the Allbase system catalog used to describe it)
The Allbase Table may then grow to fill all DBEFiles in a DBEFileSet, at which point you may wish to increase the space you want made available to it by "increasing the capacity of the DBEFileSet". You do this simply by creating another DBEFile, then adding it to that DBEFileSet. Additionally, you do not have to allocate all the storage up front; you are able to create a DBFile with an initial allocation, an increment size and max size, Allbase will expand the file, by increment, when required.
A DBEFileSet may have just one or many tables assigned to it.
The Allbase system catalog (where image "table" and view definitions are kept) resides in a DBEFileSet called the SYSTEM DBEFileSet, and always includes the first DBEFile ever created (when the DBE is created in fact). The first file is called "DBEFLE0"....the same file as mentioned in previous postings to this thread.
The DBA would normally (and is recommended to) create other DBEFileSets having DBFiles to contain "user" data. This is because the SYSTEM DBEFileSet is the default location for temp tables used for results and sorting, etc. It is therefore important to keep contention on SYSTEM DBFiles as low as possible. There are other methods of controlling the allocation of, and contention for "SYSTEM" space such as defining tempspaces and moving stored sections etc, but are beyond this thread.
There have been so many requests for help about IMAGE/SQL lately, that I hope this might be some help:
1) Creating the DBE. Because this may be made up of a number of different files, you can never be absolutely certain that there will not be a name clash with a file you have already created. So I find that the easiest way to avoid clashes is simply to put your DBE into a group of its own, and not put anything else there at all. Some people prefer to let IMAGESQL create the DBE for them automatically, rather than doing it explicitly with ISQL. There are two drawbacks to this. The first is that the default SYSTEM filespace is not very big, and may very well be inadequate to accomodate sorts etc. The second is that the log files are not very big, and you may find you cannot execute an IMAGESQL "detach", without first deleting all the users one by one.
2) Maintenance words and access. When you create an IMAGESQL DBE (though I admit here that I'm just assuming it's the same as ALLBASE), it is released. So there is no MPE security on the DBE. Since you may want to attach Turbodb's from a number of different accounts, you may not be able to be logged in as the creator of both the DBE and the Turbodb. This is where maintenance words are useful, and if you are in this situation it will give much more flexibility if you set maintenance words on both the Turbodb and the DBE.
3) Set DDL off Once you have finished all the configuration via IMAGESQL, you can use SQLUTIL to switch off DDL (data definition language). This allows ALLBASE to assume that the system tables will not be changed when it opens the DBE, and keep them loaded in memory, which should give better response times.
PLPlease note that a PC Socket error 10054 is returned to PC API when users do not have write access to HPDAARLG.PUB.SYS. Please ensure that you have placed any ACD's on this file.
Try releasing HPDAARLG.PUB.SYS at least temporarily to test. If you have a very secure system, apply the following ACD to the log file:
@.@ = R,X,A,L
NM version much easier to use as a temporary work file from within Cobol programs - no need to KSAMUTIL etc. I have used in 2 ways: * consolidate bills of material from MM for homebrew backflush method, * implement priority queue (to-do) list for system log-file processor.
In both cases (XL 3.0) could do easily as temp files - need file equation, then open as random - key stuff done by Cobol.
GSYou might want to include: KSAM/XL has the ;REUSE option. KSAM/V also has the ;REUSE option but it is undocumented, although widely used.
CFNative Mode KSAM files (their file code will appear as KSAMXL when you do a :LISTF,2 on them) are attached to transaction managment and will be automatically recovered to their last consistent point upon reboot. However, the old compatibility mode KSAM files that we know and hmmm... appreciate?, are *not* attached to transaction management and still must be recovered with KSAMUTIL. CM KSAM files can be distinguished by the fact that there are actually two files, the data file and the key file, that make up the logical CM KSAM file.
:FILE MYKSAM;SAVE :PURGE *MYKSAM
We are considering buying a CD unit for our 992. I have heard that HP offers their manuals on CD by subscription. Does anyone use these manuals on CD and what are your likes and dislikes? What else can you do with your CD unit on your HP3000?
CBFor myself (I use a pc-based CDROM drive);
Likes: infintely cheaper, easier/faster to find things (very nice search
capability), all manuals on one disc (vs. the 60 or so linear feet
it takes to house the paper versions), using a sharable CDROM in a
PC (Windows for Workgroups) a whole group of people can share/access
the drive easily
Dislikes: When you DO print something out, most items don't print much like
the paper version (margins are off/mixed portrait & landscape pages
don't seem to print nicely), on-board illustrations are a little
slow sometimes
Host-based vs. PC based; PC based is much cheaper and more flexible,
especially if you already have Windows for Workgroups or other
software that lets you share CD drives. Of course, you can't
generate a boot tape for your 3000 from such a drive (the other
main useage for the HP3000-based unit). I found that the CD on a
3000 could read pc-type data (it handles most industry standards
for CD data) but there's not much else of use to a 3000 that's
available on a CD (unless you archive your own data to CDs?).
With the 5.0 host-based package that lets you share the drive
(when not in use for updates) among PC users, it helps justify
the cost if you want it for system updates anyway...
3.5.3.1. Exactly what networking services come with 5.0?
JPHHere is what you get:
On the 5.0 PUSH (C.50.00), the lan link software is now included as
part of FOS.
The following is included as part of FOS:
- HP36923A - THINLAN 3000/IX NETWORK LINK
a. 802.3/Ethernet Lan Drivers
b. TCP/IP Network Transport
c. NETIPC Sockets
d. BSD Sockets
e. SNMP
f. NS Services Inbound Virtual Terminal (VT) only.
- HP36957A - HP ARPA FILE TRANSFER PROTOCOL (FTP)
a. FTP
b. NS Services Remote Process Management (RPM)
- HP TELNET/IX CLIENT (32098-20097)
a. Outbound Telnet Client (over TCP)
b. Inbound Telnet Server (over TCP) - product available in future
The following is NOT included as part of FOS:
- HP36920A - NS3000/IX NETWORK SERVICES
a. Remote Database access (RDBA)
b. Remote File access (RFA)
c. Remote peripheral access
d. Network File Transfer (NFT/DSCOPY)
e. Virtual Terminal access (VT) inbound and outbound.
- HP2347A/HP2344A - HP ARPA Telnet Access / Express:
a. Inbound Telnet Server via DTC & TAC card.
If its a SCSI DDS drive, the required firmware is 10.7 (later firmware doesn't work either, at least for the moment). The firmware can be updated easily via a "special" tape by a CE. If its a HPIB DDS drive, the correct firmware is version C, but this requires actual disassembly of the drive to update.
Be sure to check this out well in advance. Nobody likes surprises.
It's a very common misunderstanding to associate your Current Working Directory (CWD) with your logon group, since in the past your logon group doubled as both the CWD and the logon group. The logon group is instrumental in determining what access you have to files (determining whether or not you belong to the group user (GU) class). It also is the location that your CPU and connect time account to when you log off. The CWD is a naming shortcut. It allows you to say FOO instead of FOO.GROUP.ACCOUNT. It has no bearing on security or access to a file, or the ability to create or purge a file.
From your message, it appears that you believe that allowing a user to place their CWD (via the :CHDIR command) to another group or account provides some type of additional access to the files there. Let me assure you that that is not the case! Placing your CWD into PUB.SYS (or /SYS/PUB - whichever way you prefer) makes no difference in the access that you have to files in that location. You cannot create files, purge files, read, write, or do anything else, unless you already had the ability to do that (i.e. you had SM capability). All it lets you do is say :PRINT CATALOG, rather than
:PRINT CATALOG.PUB.SYS.
The thing that makes this confusing is the :CHGROUP command. :CHGROUP makes it hard to see the difference between the logon group and the CWD. Whenever you do a :CHGROUP, it actually logs you off and then back on, very quickly. Check the CPU and connect times of the old group (via the :REPORT command) just after you do a :CHGROUP and you'll see that they were updated with the amount of time you spent in that group before you "moved" over to your new group. The :CHDIR command makes the difference between the CWD and logon group obvious by allowing you to shortcut your naming independently of changing your logon group. Of course, the logon group must stay within your logon account, and so the :CHGROUP command will (still) not allow you to move your logon group outside that realm. By the way, the :CHGROUP command still changes both the CWD and the logon group, so that if they were pointing to different locations before a :CHGROUP, afterwards they'd both be pointing to the same group.
1. The check-off list that came from HP.
2. Make sure the HPSUSAN in the kit is the right one for your computer.
JMCI updated my 927LX last month and found it was a relatively painless experienece. A couple other suggestions, in no particular order:
3. Read Interact back issues. Besides a recent update checklist article, the ones from a year or more ago under the title "An MPE Programmer Looks at MPE 5.0 [or POSIX]" are good. Sorry, I don't remember dates or authors and my back issues are at the office :-)
4. Check the contents of the SUBSYS tape (not a formality, stuff can get left out)
5. Review the conventions for POSIX file naming and "MPE escaped syntax." Review your backup procedures to be sure everything you want backed up does get backed up. If you are using a third-party product like RoadRunner, make sure (a) it is MPE 5.0 compatible and (b) it can back up the HFS directories, not just the MPE accounts under 5.0. (A) and (b) aren't necessarily the same. For example, I received an MPE 5.0 compatible RoadRunner upgrade automatically in February but had to request an additional upgrade before I could back up the HFS directories.
6. Check the status of all your other third party software products. Packages like MPEX will handle 5.0 just fine but it is prudent to install the 5.0 compatible version of any utility you rely on before installing 5.0 itself.
7. Be aware that if you have software or files stored off a 5.0 system and restored to your 4.0 system, there may be access problems. For example, I received a QUIZ schema from a software vendor; the schema was created on the vendor's 5.0 system and I restored it to my 4.0 system and made it readable by ANY; after the 5.0 update, users couldn't access the schema anymore; I first had to RELEASE the schema (band-aid solution), then change the POSIX owner and group IDs (permanent solution). You may not know you have files of this kind unless you contact your vendors and ask.
8. If your system is low on disk space, reserve the required space in advance.
9. If your system has limited memory, review the patch documents and apply the patch for low-memory systems. There is also a patch to resolve a bug whereby STORE silently ignores tape write errors and can, under some circumstances, create a bad tape without telling you. If you depend on STORE, you should be sure to apply the patch at the same time you do the update.
SM10. Keep in mind that, the way 5.0 is installed by default, users without capability will not have access to the root / directory and non-MPE directories under root. This means you are pretty secure to start with. But users can _create_ POSIX directories within MPE accounts and you will need to monitor this. It isn't an installation issue, as such, but there are implications: unless your users are quite sophisticated, you can update without immediate security risk; longer term, you can't ignore POSIX even if you don't mean to use it.
As much as anything, preparing for the 5.0 update is a question of comfort level. I found that if you follow the installation instructions, it goes by the book and isn't much more involved than any other update. The difference is how much new stuff there is to to learn in order to stay on top of the system _after_ the update.
NOFI have made three upgrades to 5.0 and will do the fourth this saturday.
The only problem is disc-space. Use the time until the upgrade to get the free space on ldev 1 that you must have. I have created the AXLDEV1 file (see the upgrade manual) in advance so I don't have to bother about enough disc-space. If you are short of space you have plenty of time to get a new discdrive.
See also 6.9.5. How can I programatically tell what MPE version I'm on?
Executing the following in a command file will move the console to your logon device (whether its a VT session or not). (This was contributed to the HP3000-L some time ago and I don't remember the original author...)
echo console tellop console moved to ldev !hpldevin debug ma %1074,1,,#!hpldevin;c echo consoleRG
With MPE 5.5 this works without the "debug" command, just use console !hpldevin
Some HP 3000 security packages rely on a system-wide logon UDC to protect the computer. Logon UDCs can be ignored if the user logs on with Parm=-1, which can potentially be a BIG security hole unless you have a patch from HP.
A new feature on MPE/iX 5.0 allows you to choose whether or not you can enforce logon UDCs by disabling the Parm=-1 option even for users with SM capability. You can turn this feature on in the Sysgen Misc section by doing the following:
:sysgen
sysgen> misc
misc> system enforcelogonudcs=ON
misc> show system
misc> hold
misc> exit
sysgen> keep
sysgen> exit
The change does not take effect until the system is restarted with START NORECOVERY. Nice new feature.
After reading the doc for SETCLOCK, I am under the impression that only the TIMEZONE form of the command does not change the hardware time:
And he's right. There's no need to change the hardware clock just to change time zones.
John also writes:
If you do SETCLOCK CORRECTION=-3600, your hardware and software clocks should change. It would be nice if the output of SETCLOCK specifically said which clocks were changing.
Since the hardware clock is not referenced during normal operation of the system, I'm afraid that mentioning it in the output of the SETCLOCK or SHOWCLOCK commands would confuse users into thinking that the hardware clock plays a role in obtaining timestamps. I'd rather the hardware clock be invisible.
Billy Rowland writes:
form clock affected type of change
-----------------------------------------------------------------------
date-time: local and universal gradual (default) or immediate
correction: local and universal gradual (always)
time-zone: local only immediate (always)
Which is mainly correct, except that for a time zone change from Daylight Savings to Standard (as northern hemisphere systems had last week) the change is not immediate. See the Communicator articles for a description of this embarrassingly complicated behavior. In essence, when going back to standard time, local time slows down gradually, while Universal time jumps forward immediately, then slows down gradually until it matches what it would have been if no SETCLOCK command had been issued. Weird, huh?
In another thread, Jeff Vance writes:
The clkutil utility sets the h/w clock only, and should not be needed anymore. The h/w clock is really only needed for the time prompt at boot up.
I think there is still a need for CLKUTIL. John gave an example of the hardware clock being set exactly one day ahead of where it should have been. If a system's hardware clock is set totally wrong, correcting it with the SETCLOCK command can get confusing. First you have to use SETCLOCK to set the correct time zone. Then you notice an enormous correction, so you have to use SETCLOCK;CANCEL to get rid of it. Then local time is still not correct, so you have to use SETCLOCK a third time to set the correct local time. *AND* it turns out that you have to use the ;NOW option this third time to accurately set the hardware clock. (I found this out *after* the Communicator articles had been written.) And maybe you just don't want to use the ;NOW option.
So sometimes it's just easier to sigh, reboot the system, and run CLKUTIL at the ISL prompt.
(Often you think that you've done everything right, but when the system is next booted, the operator is presented with a time which is off by 15 minutes or more. That's a hint that rather than proceed with the boot, the operator should reboot the system, get to the ISL prompt, and use CLKUTIL to set the hardware clock.)
Details of what does and does not count toward the user limit are listed below:
Counts toward user limit
-------------------------
1. A user logon from a terminal or PC is counted when using one of
the following connections:
- DTC direct connect
- DTC modem connect
- LAN (PC only)
- X.25
- PBX
- Statistical Multiplexer
- NS virtual terminal (Pt-to-Pt, LAN, X.25)
- PAD
2. An application which calls HPFOPEN or FOPEN on a terminal other
than its own will increment the user limit for each additional
terminal opened.
Does not count directly toward the user limit
----------------------------------------------
1. The physical console will always be available and will NOT
count toward the user limit.
2. Sessions have not been used to keep track of the user limit
since some applications can initiate multiple sessions for a
single user.
3. Jobs do not typically count toward the user limit unless the
job is running an application which is opening a terminal.
4. Processes do not directly relate to the user limit because it is
possible for a single process to HPFOPEN multiple terminals. As
well as, a single user can run an application that creates
multiple processes.
5. Remote applications which do not establish a virtual terminal
do not count toward the user limit. A common example of this
is Remote File Access. A user performing a dscopy with the
logon option does not count.
In summary, the user count tracks individual users interacting
with the system through an open terminal or PC connection.
-----------part #2 (clarifying article on NULL VT) ---------------
BY: James Hofmeister - Network Expert Center Atlanta
Eero Laurila - CSY Networking lab, NS services, VT.
This is a quick article to clear up a misconception with the functionality of "NULLVT" in the NS3000/iX product.
NS3000/iX supports a facility called "NULLVT", which is the ability to open a terminal device on a system for logon, but it specifically excludes the ability to do any terminal I/O with the system.
An example of one implementation demonstrating this functionality is the HP Resource Sharing product which supports multiple inbound connections from one PC to the HP3000 - while counting the PC as one user. This product allows the PC user to share discs and printers attached to the HP3000 - i.e. using it as a file and print server. The thing to note here is that there is no terminal I/O involved with the client.
On the technical side, allocating an ldev for terminal I/O is needed to satisfy MPE's requirements for logon. The way that VT's terminal I/O works is that a device that has been allocated for input/output (stdin/stdlist) will have a logical device manager (vt_ldm) attached to it.
The vt_ldm forwards I/O requests from MPE/iX's High-Level I/O (HLIO) subsystem to the client and vice versa through a vtserver process who owns the TCP-connection on the host. Also, the vt_ldm is created by the server process that allocates the device (in this case vtserver.net.sys).
Depending on which way the vt_ldm is created, the initialization info sent to the ldm tells whether the device is to be used for real I/O or "null" I/O. When created as a "null" terminal, the vt_ldm's state is set to indicate that there is no vtserver process to take care of forwarding data between the host and client and thus all the terminal I/O received from HLIO (High-Level I/O) is to be flushed.
Other NS services for example NFT(dscopy) and RFA(remote file access) can and will also use the "nullvt" functionality. If the user specifies a logon string in DSLINE [node];LOGON= parm, this results in a programmatic logon executed on the remote node through a null VT-terminal. Note that also in this case the device is allocated strictly for the logon purposes and there is no interactive communication with the remote host nor is there a server to take care of it. Using other NS services in this fashion saves resources on the host by eliminating the need for creating an extra server process (vtserver) to handle the terminal I/O that will not occur on NFT-only or RFA-only connection.
The misconception of the functionality in the "NULLVT" facility is the result of an article generated, as a Question / Answer response to a Customer User Group.
The text of the article should read:
Q: Does a single PC running multiple sessions on the server count as one or multiple users on the HP 3000?
A: Each session logged on to the HP 3000 doing terminal I/O is counted towards user licence. All VT-connections will create a vtserver process that allocates a device for "real" terminal I/O.
Example: Some MS Window clients offer multiple VT connections from a single PC to the HP 3000 Server. Each VT logon is a unique session and is counted as a session against the user license.
I updated our 967 to 5.0 in early June. At that time, several 3rd party software accounts (e.g. VESOFT, ROBELLE, NSD, etc.) existed on our system volume. I left them where they were to address later. I decided the time had come to move them to the user volume, and read everything I could find, etc. and moved them accordingly. I had no problem with anything except NSD which I use extensively. Many files had been assigned acds during the restore to the user volume. I had to create some workarounds quickly to get the system available for users, and then began to research this problem. I had read everything I could find on the HP Support Line about user volumes, but I had not looked into into acds. Anyway, I finally found document A3799035 "ACDS WERE ASSIGNED TO RESTORED FILES. WHY?" My restore command should have been something like:
"restore*t;@.@.nsd;show=offline;volset=user_volume_set;olddate;account=nsd"
This was unknown to the software company, as well as to others within my corporation that I had talked with. The document follows for your reading and enjoyment pleasure.
Document Id: A3799035
Date Loaded: 06-06-95
Description: ACDS WERE ASSIGNED TO RESTORED FILES. WHY?
PROBLEM TEXT
I recently restored files from my 957 (which was recently updated from 4.0 to 5.0) to my 995 which is on 5.0. All the files came from one account on the 957.
After restoring these files, they all had ACDs on them and the security was changed to not allow anyone to access the file.
A LISTFIILE ./filename,-3 showed that READ, WRITE, APPEND, LOCK, and EXECUTE access was all blank. A LISTFILE ./filename,4 showed ACD EXISTS.
In addition. LISTFILE ./filename,-3 showed that the GROUP ID: contained the name of an account that does not exist on this system (995), or on the original system (957)
Why did the system put ACDs on the file and restrict access?
RESOLUTION TEXT
An ACD is assigned to a file when certain criteria is met. One of these criteria is if the "object is directly below MPE groups whose GIDs do not match the GIDs of the accounts in which they exist." (see Page 5-21 of the 5.0 Communicator).
When the files were restored to your 995, the file system checked this GID field, saw it did not match the account you were restoring into and enforced this ACD assignment.
Your case was a bit special, since the files from the originating system (957) did NOT have ACDs but the GID field did exist and showed a account name which did not exist on the 957 either.
We determined that these files were restored to the 957 when it was on 4.0 from a 3rd party vendor. The 3rd party vendor had created these files on a 5.0 system, which assigned a GROUP ID (GID) to each file. When the files were restored to the 4.0 system, this field was meaningless to the file system. When the 957 was updated to 5.0, still no ACDs were assigned since the file system does not search the system for files meeting this criteria. It's not until the files are acted upon (as in copied, renamed or restored to a different system) that the GID field is evaluated. Therefore, when you restored this account to your 995, the 5.0 file system did what it was supposed to do: evaluate the GID of the incoming files and act accordingly.
The problem was solved by adding ;ACCOUNT=accountname to the RESTORE command. This assigned the correct GID to the incoming files, allowing the same access they had on the originating system.
KEYWORDS LIST
POSIX GROUP ID
ACD SECURITY
RESTORE ACD
If you're fortunate enough to have access to MPEX (version 25), you could also have issued the following command:
%ALTFILE (fileset); LOCAL; DELACD
This will 1) fixup all GROUPIDs to match the ACCOUNT where each file is located, and then 2) delete all ACDs associated with each file. Fixing up the GROUPIDs is a prerequisite for being able to remove the ACD. Of course, re-RESTORING the files is fine, just a bit longer.
a sector = 256 bytes
a megabyte = 1,048,576 bytes
hence,
sectors / 4096 = megabytes
Just because the logs do not indicate a disc problem does not necessarily indicate a media error did not occur. On 5.0 there is a new functionality which results in a file being made inaccessible if unrecoverable data was detected during a sparing operation on the way up. The file gets "locked".
Try going into FSCHECK (this is best done on an idle system or a hang or invalid results could possibly result) and execute the command "DISPLAYLOCKFILE ALL". This will check for locked files on all mounted volumes of all volume sets. What you must be aware of, if you find one, is that the file IS CORRUPT!! This functionality was implemented to allow users to recover data from the file if necessary, rather than:
1. pause a reboot and wait for an operator to decide if a file should be purged or saved
or 2. just purge the file, which is inconvenient at best and catastrophic at worst.
Unfortunately, due to the volume of console messages during a reboot, messages about such locked files are missed and then you have something of a mystery when someone asks where their file went.
Try the following command file:
parm dfid, dev=lp, pri=1, env=tt99.pub.sys file f!dfid;dev=!dev,!pri;cctl;env=!env setvar hpmsgfence 2 purge tempcmd,temp setvar hpmsgfence 0 echo copy !dfid;all,*f!dfid >tempcmd echo exit >>tempcmd run spooknm.pub.sys;stdin=tempcmd reset f!dfid purge tempcmd,temp
Note; on MPE/iX 5.5 PP5 and later, all you have to do is reference the HPSPOOLID CI variable (Jeff Vance).
The following command file, provided by Jeff Vance, returns the spoolfile ID for the $STDLIST of whatever job or session you pass it (for earlier MPE/iX versions):
PARM jobnum=!hplastjob, rtnvar=spid, entry=main # (This command file assumes Express 3 release, if you are not on Express 3 # then change all '#' to 'comment' and change '!hplastjob' to ''.) # # This command file returns the spoolfile id (Onnnnnnn) in the CI variable # named in the "rtnvar" parm. To reference this file you may need to # append ".OUT.HPSPOOL" to the value in "rtn_parm". Example: # :jobspid #J123 spid # :print !!spid.out.hpspool # if '!entry' = 'main' then # main entry, redirect output of :listspf errclear setvar !rtnvar '' # could syntax check jobnum parm here... listspf O@;seleq=[JOBNUM=!jobnum AND FILEDES=$stdlist] >./jobspid_tmp if hpcierr <> 0 then # listspf couldn't find job echo !jobnum not found. escape else xeq !hpfile !jobnum, !rtnvar, entry=parse_listspf <./jobspid_tmp deletevar _jobspid_@ return endif
elseif '!entry' = 'parse_listspf' then # listspf input has been redirected to TEMP file ./jobspid_tmp # throw away 1st 3 lines. input _jobspid_rec input _jobspid_rec input _jobspid_rec setvar !rtnvar rtrim(str(input(),2,8)) return endif
:newgroup target.account :sh shell/iX> cd /ACCOUNT/SOURCE shell/iX> mv * /ACCOUNT/TARGET