- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Is SYSUAF merge possible?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2003 06:09 AM
тАО09-03-2003 06:09 AM
Re: Is SYSUAF merge possible?
previous answer seem right and i don't answer you because I agree with allbodies.
Now I think there are a lot of LOGIN in your system, so LOGINOUT process keep lock on SYSUAF.
Hein post is the most right but if you can accept a low risk you coul run follow statements:
$! Raise to close files on error
$ ON ERROR THEN GOTO XIT_LOOP
$! Raise to close files on Ctrl-C
$ ON CONTROL_Y THEN GOTO XIT_LOOP
$! Open without lock SYSUAF.DAT
$ OPEN/READ/SHARE=WRITE SRC -SYS$SYSTEM:SYSUAF.DAT
$! Open my sequential file to merge
$ OPEN/WRITE DST SYSUAF.SEQ
$MAIN_LOOP:
$! Read no lock record
$ READ/NOLOCK SRC LINE /END=XIT_LOOP
$ WRITE DST LINE
$ GOTO MAIN_LOOP:
$XIT_LOOP:
$! Close all file
$ CLOSE/NOLOG SRC
$ CLOSE/NOLOG DST
$ EXIT
Naturally you cannot lock SYSUAF because any user can need to login so you aren't sure to read last version of data.
Bye
Antoniov
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-03-2003 06:14 AM
тАО09-03-2003 06:14 AM
Re: Is SYSUAF merge possible?
If you will not conver but you wish merge, you can open destination file as follow:
$ OPEN/READ/WRITE/SHARE=WRITE DST -
SYS$SYSTEM:SYSUAF.DAT
Naturally, source file is located on another node and you need modify OPEN of source statement.
Bye
Antoniov
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2003 04:23 AM
тАО09-07-2003 04:23 AM
Re: Is SYSUAF merge possible?
I understand that you are very careful in this matter.
Maybe if I can recommend to use following approach:
BACKUP/IGNORE=INTERLOCK SYS$SYSTEM:SYSUAF.DAT node_sysuaf.dat
Do this operation on both systems.
After you successfully created a copy of SYSUAF.DAT then use the previous given instructions.
Even if it will fail the original files are still intact!
By the way, the qualifier /IGNORE=INTERLOCK is very helpful. You may know it from the image backup of your system disk etc...
Kind Regards
Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-07-2003 02:44 PM
тАО09-07-2003 02:44 PM
Re: Is SYSUAF merge possible?
>Maybe if I can recommend to use following approach:
>BACKUP/IGNORE=INTERLOCK SYS$SYSTEM:SYSUAF.DAT node_sysuaf.dat
> By the way, the qualifier /IGNORE=INTERLOCK >is very helpful. You may know it from the >image backup of your system disk etc...
Andreas, sorry to contradict you, but /IGNORE=INTERLOCK is *NOT* very helpful.
The SOLE purpose of /IGNORE=INTERLOCK is to reduce the severity of the BACKUP ACCONFLICT condition from "E" (Error) to "W" (Warning). It is NOT a magic wand to make online backups. Please don't rely on backups of system disks made using it.
Under /IGNORE=INTERLOCK there is no synchronization with other processes or with RMS when reading the file. At best it will give you a "crash consistent" copy of the input file. At worst you'll get random junk. Although it's rare that the output file is completely useless, it's not impossible. Bottom line is any file copied by BACKUP which generates an ACCONFICT should be considered suspect.
If you want to get a clean, guaranteed consistent copy of an open file (opened for shared access), please use CONVERT/SHARE:
$ CONVERT/SHARE SYS$SYSTEM:SYSUAF.DAT node_sysuaf.dat
the output file is guaranteed to be useable. You won't know if record(s) added or modified *during* the CONVERT will be present in the output file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-08-2003 05:05 AM
тАО09-08-2003 05:05 AM
Re: Is SYSUAF merge possible?
1. I wrote a little program that used SYS$GETUAI to extract EVERYTHING about a user including the binary password. This program wrote the information to the DCL symbol table with LIB$SET_SYMBOL. Everything comes back as a string symbol when you take this approach.
2. For each user in the incoming SYSUAF, I translated one record using the above GETUAI and created a DCL script that would add the user to my running system with the same exact attributes as they had in the incoming system. This script writer wrote one ADD_xxxxxx.COM script for each user xxxxxx.
3. I wrote a little program that used SYS$SETUAF to handle the binary passwords. If you have the same username and binary password and if the other password-related items are the same, you have preserved the password. So my script writer included a little run of the password-setter based on the binary values in the incoming account's password data.
4. Here's the part that avoided conflicts by name: I didn't just run the scripts. Instead, I wrote another script that located the ADD_xxxxxx.COM files. Using F$PARSE to extract the name and using DCL string subtraction to remove the "ADD_" I found the name of the incoming user. I then did a quick sanity check with F$GETUAI on the incoming user name. If it was OK, I ran the script. I just didn't run the ADD_xxxxxx scripts that had name conflicts. So SYSTEM, DECNET, etc. were never affected.
5. My situation was such that there were no UIC conflicts either, so I never had to deal with that problem.
I don't claim this is elegant. But it works on a running system without too much disruption. Plus it leaves you the files representing the record of what you added.
Before anyone asks why I would need such a bizarre tool, we have migrated our production server twice now. Both times, we took a backup copy of everything but then had to "update" the copies a couple of times when converstion testing ran into snags. Due to logistics issues, it was easier (on the user community) to update the incoming user data this way. And of course, once you have such a tool, you re-use it when the situation comes up again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2003 06:14 AM
тАО09-15-2003 06:14 AM
Re: Is SYSUAF merge possible?
$ convert/share/stat/exc=RIGHTSLIST.EXC RIGHTSLIST.WPG,RIGHTSLIST.EDM RIGHTSLIST.NEW
%CONVERT-F-LOADIDX, error loading secondary index 2
-RMS-F-DUP, duplicate key detected (DUP not set)
Remember the local system is VMS v7.2-2 and the remote is v7.1-1h1. Were there version differences between rightslist formats?
I've tried pre-creating the output with an FDL from v7.2-2, converting the v7.1 file to v7.2 format... but keep getting the same error.
Any further suggestions or help?
Thanks,
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2003 06:51 AM
тАО09-15-2003 06:51 AM
Re: Is SYSUAF merge possible?
Use CONVERT/EXCEPTION=rightslist-dups.dat
This is similar to my first reply with the suggestion about SYSUAF itself.
When the convert is done DUMP/RECORD the
exception file and evaluate its contents
to determine whether you can just smile and be happy, (dup on 1,4 - system !) or whether you need to shuffle some records.
You can probably use DCL to READ/DELETE/KEY
and/or WRITE/SYMB to amnipulate a few records.
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2003 08:41 AM
тАО09-15-2003 08:41 AM
Re: Is SYSUAF merge possible?
Looks like I can only attach one file at a time...here's the local one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2003 08:42 AM
тАО09-15-2003 08:42 AM
Re: Is SYSUAF merge possible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2003 10:26 AM
тАО09-15-2003 10:26 AM
SolutionConsidering the samll amount of data involved I would suggest to use CONVERT/MERGE instead of a full-fast convert. The /Merge will tell convert to use plain-vanilla RMS $PUTs to insert a record at a time (in primary key order). I suspect (untested) that the failing records will now land in the exception file as there will be an indentifyable failing record.
A DCL loop with reads from secondary rightslist and inserts to the primary would be much similar.
In the case of the convert/fast the primary and first alternate structure were already build, but then convert discovered unrecoverable inconsistency. What could it do but abort?
An other approach would be to pre-process the data files with $SORT to weed out the dups
on alternate. Not pretty, but straightforward.
Good luck,
Hein