INFO-VAX Fri, 07 Nov 2008 Volume 2008 : Issue 602 Contents: Re: .DIR performance with many versions vs. many unique names ? Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Re: Synchronizing SYSUAF between independent machines Variable record format but used with fixed lenght data ? Re: Variable record format but used with fixed lenght data ? Re: Variable record format but used with fixed lenght data ? Re: Variable record format but used with fixed lenght data ? Re: Variable record format but used with fixed lenght data ? Re: Variable record format but used with fixed lenght data ? Re: VAX-11/785 microdiagnostics help requested ---------------------------------------------------------------------- Date: Thu, 06 Nov 2008 20:49:24 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: .DIR performance with many versions vs. many unique names ? Message-ID: Hein RMS van den Heuvel wrote: > On Nov 6, 4:42 pm, Jan-Erik Söderholm > wrote: > >> Maybe having multiple versions of the same file is >> stored in less space in the .DIR file then having >> unique names !? > > Correct. Each additional version takes just 8 bytes (untill a block is > full) > Each new directory entry takes 4 + filename + 8. > OK, so with a specific number of files, unique names will create a larger DIR file. > Just create a dierctory with a few examples and DUMP/DIR xxx.DIR > > Also... if you can add a 'proper' date stams in always ascending order > (YYYYMMDD or even YYMMDD in this case.) Right, that's a bonus. The last files created are those displayed last on screen after a DIR... :-) > That way it will be easier to add room if needed. OK, becuse it's faster to create new files at the end of the DIR, right ? And what about deletes ? The plan is to run a delete/before= regulary, but those files deleted will be at the start/top of the dir. That might cause some extra I/O's maybe (?) The fact is that I have another systems where all files are created with timestamps, and I have hard time to get the "Dir Data (Hit %)" in MONI FILE getting over even 5% on that systems (DS20, 8.2, standard blue storageworks 9 GB disks). I've tried to set ACP_DIRCACHE to 10.000 or 20.000 boocks, but it doesn't help. So, actualy, I am also looking for a way of getting this other system running with higher Dir Data Hit rates. On the system I'm looking at now, we have either 100% Dir Data Hit's (or zero when there are no attemts). I do not want to make that go the same way with it's I/O. B.t.w, this is also a DS20, but using HZG80's for the disk system. Could the DIR data caching has anything to do with the number of *unique* file names (and not only the *total* number of files) ? Jan-Erik. > > Hein. > > ------------------------------ Date: Thu, 06 Nov 2008 20:33:02 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Message-ID: <2wIQk.3893$U5.24936@newsb.telia.net> Len Whitwer wrote: > On Nov 5, 11:56 am, VAXman- @SendSpamHere.ORG wrote: >> In article , johnwalla...@yahoo.co.uk writes: >> >>> {...snip...} >>> It does indeed seem like very bad form to have a stack dump because of >>> a "simple" licensing issue. So, asking a perhaps dumb question, are >>> there any likely system configuration issues (y'know, along the lines >>> of "insufficient GBPAGES", etc) which could lead to the licensing >>> issue ending up in the unclean-exit symptoms we see here, issues which >>> might arise when someone new to this kind of thing (as Len appears to >>> be) has a go at installing and using the BASIC compiler? >> It looks like the license error was signalled and not returned, and that >> the BASIC compiler image was linked /TRACEBACK. I just pulled the BASIC >> compile .EXE off of the DVD and check it for /TRACEBACK. >> >> -- >> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM >> >> ... pejorative statements of opinion are entitled to constitutional protection >> no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) >> >> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside >> of usenet _must_ include its contents in its entirety including this copyright >> notice, disclaimer and quotations. > > Where do you think I should go from here?? > > Len About the unclean exit from BAS ? You can always report it. Or with the license as such ? I do not think anyone here can tell based on the information provided by you. Where do you *want* to go ? Jan-Erik. ------------------------------ Date: Fri, 07 Nov 2008 04:48:18 GMT From: John Santos Subject: Re: OVMS Integrity BASIC LTU Getting only 1 user at cost of $2400.00??? Message-ID: craig.a.berry@gmail.com wrote: > On Nov 4, 6:09 pm, Len Whitwer wrote: > >>Ordered HP Basic LTU for integrity BA347AC "concurrent license" at a >>list price of $2400.00. Installed on rx2620 system and can only get >>"ONE USER" on system. > > > Somewhat counterintuitively, that's pretty much the definition of a > concurrent use license for which you have not purchased extra units. > Technically it's an activity license that allows a certain number of > simultaneous uses and the default number of uses allowed is whatever > quantity you ordered. Naturally you ordered a quantity of one since > you thought you were buying a compiler, but what you actually bought > was the rights for one use of the compiler at a time. If you had > ordered a quantity of two, you'd be allowed two concurrent uses, and > so on. > > You can read up on license types here: > > http://h71000.www7.hp.com/doc/83final/BA322_90078/4584pro_001.html#intro_lic_types_sec > > Selling something called a "concurrent use" license where the default > number of concurrent uses allowed is one is kind of like advertising > an all-you-can-eat buffet where you have to pay again every time you > go through the line. There's no rational way an uninitiated customer > can figure out what they need by reading the product names. Whoever > is selling you this stuff should do a better job of explaining how the > licensing works and making sure you get what you need. I had the exact same issue when specing a customer system. Arrived, installed, lo and behold, the 2nd user gets an error... (Don't remember if it was a stack dump - that part of it sounds bogus.) Since we only do compiling at installation time and when fixing bugs, we decided to live with it. (We have DSPP on our development systems.) It was totally unclear that we were being quoted a single user license when we ordered the systems. We've only been using DEC/Compaq/HP software for 37 years, so we don't have all the terminology down yet. I think there might be multiuser bundled prices that are significantly cheaper, but don't know. (For example, 5 users is much cheaper than one user.) Last time we bought compiler licenses was for an Alpha, and IIRC, the single user license for both BASIC and C was about $1500 and the unlimited licenses were about $3500, so we went with unlimited. I thought $2400 was steep for a single user of a mature compiler, but cheap for an unlimited license. And we are also paying for support as well, so not all the developer time comes out off the license purchase pot. Gee, we'd like to pay less. Is there anyone out there who wants to pay *more* for software? :-) :-) :-) So we whinge a bit and live with it. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Fri, 07 Nov 2008 04:12:54 GMT From: John Santos Subject: Re: Synchronizing SYSUAF between independent machines Message-ID: Main, Kerry wrote: >>-----Original Message----- >>From: Ramon Jimenez [mailto:rjimen37@ford.com] >>Sent: Tuesday, November 04, 2008 10:16 AM >>To: Info-VAX@Mvb.Saic.Com >>Subject: Synchronizing SYSUAF between independent machines >> >>Hello >> >>We have two HP Integrity boxes (OS Version V8.3-1H1) >> >>One of them must be keept as a failover, so we need to keep >>information synchronized between both machines. >> >>The application and data has been confined into a Logical Disk, so we >>just dismount the shadow and copy the files into the other machine. If >>we need to switch over we just need to mount the volumes on the >>failover server. >> >>We also need to keep synchronized the sysuaf.dat (and related files >>rights.dat...). >> >>Which could be the best method to do it? Had the same problem. Customer has two identical systems at two sites, each covering a different geographical area. Each system is the warm backup of the other. The users of system A and system B overlap some, but not completely. (Many users only have access to one of the systems, and the users that have access to both have different usernames, generally tagged with "_E" or "_W" for East and West.) The two systems use different UIC group numbers, so it is easy to keep the user populations distinct. We had earlier written a program (in Basic) that took a list of usernames and used sys$getuaf/sys$setuaf to dump or load all the given authorize records to a file. We had originally written this for a VAX-to-Alpha migration, where we wanted to not simply merge the VAX UAF with Alpha one due to quota issues. When loading, the program looks up DEFAULT (or some other specified account) and maximizes various and sundry quotas with those of DEFAULT. (Not all of them, just those we wanted to bump up on the Alpha.) The DCL command file that runs this program prompts for the username (can have wild-cards, or be a uic-format account, e.g. [101,*]) and then uses AUTHORIZE to list/brief them. It then parses the resulting SYSUAF.LIS file to extract all the user names, and generates a command file which runs AUTHORIZE and adds them all (with correct UIC's to get the identifiers correct), and a second command file to generate "grant/id" for all the rights held by the designated users. For doing active/passive failovers, we modified this slightly to run every night generating the necessary command files and uaf dump, and copying them to the inactive system. When switching, one of the steps is to restore the latest sysuaf dump on the passive system before turning it over to the users. We haven't quite figured out what to do about usernames that were deleted on the active system since the last time it failed over. Right now, it looks like we'll run the dump process on the passive system after creating/loading all the current sysuaf info, and then diff the resulting "ADD_USERS" command file. Anything that is on the passive system that wasn't in the ADD_USERS command file we just used to load are accounts that were deleted (or renamed?) since the last time. It's expected there will be no more than a handful of this and we'll fix them up manually. Of course, you get zillions of "duplicate username" and "duplicate identifier" errors when you add usernames on the passive system that were already there from the last time; we submit these command files as a batch job and search the log (/match=nor) to ignore these... It's a little ugly, and if HP adds new fields to the UAF we'll have to update the program, but it works and is pretty fast. We used a variation of this to initially populate the UAF. The customer had provided us with a spreadsheet which we exported to a CSV file and then parsed with DCL. IIRC, it had a username, first and last name, role (used to determine what rights the user has; our application uses application- defined VMS rights for determining who can do what), and a few other items that we used to generate various UAF fields. >> >>Regards Ramon > > > Why not cluster the two systems, shadow the appropriate disks and > simply disable logons on the backup system until such time as it > is required? Cost! Have you priced cluster licenses (or worse yet, MCOE licenses) recently? After discount, it was well over $30K each for a pair of rx3600's. Plus they needed extra fibrechannel HBAs and 800 miles of dark 1GB or faster fiber. > > Of course, the preferred way if the app is cluster aware would be > to cluster and load balance between the two servers. You not only get > a better use of resources, but in the event one system failed, only > the users connected to that failed server would have to re-connect. > > In a primary-backup (active-passive) scenario as what typically exists > in Windows, UNIX and NSK servers, when the primary fails or is shutdown, > everyone needs to reconnect. > > > Regards > > Kerry Main > Senior Consultant > HP Services Canada > Voice: 613-254-8911 > Fax: 613-591-4477 > kerryDOTmainAThpDOTcom > (remove the DOT's and AT) > > OpenVMS - the secure, multi-site OS that just works. > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 06 Nov 2008 23:18:01 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Variable record format but used with fixed lenght data ? Message-ID: Hi. While analyzing some old indexed RMS datafiles that I *know* always are used with fixed size records (from COBOL apps), I've noticed that they are created with : RECORD CARRIAGE_CONTROL carriage_return FORMAT variable SIZE 280 Question is, why not use "fixed" when all records are fixed size anyway ? My best guess is that it is like this just becuse "variable" is the default, and noone has ever thought about changing it to "fixed"... Is there any drawback having the files beeing set to variable record format when one is always using fixed sized records anyway ? (Apart from the one I do know about. "Rdb Transparent Gateway to RMS" has some restrictions on variable records formated indexed RMS files, but as I read it, it is no issue if the records are all the same size anyway...) B.t.w, this is part of a project to setup DBI and the "Rdb Transparent Gateway to RMS" to be able to run SQL queries against the RMS files and also run joins between the RMS files and between the RMS files and the Rdb database. It all looks just fine right now. I'm currently entering field, record and database definitions into CDD to get some metadata for the RMS files (about 20 files). Jan-Erik. ------------------------------ Date: Thu, 06 Nov 2008 18:40:57 -0500 From: JF Mezei Subject: Re: Variable record format but used with fixed lenght data ? Message-ID: <0002b70f$0$26283$c3e8da3@news.astraweb.com> Jan-Erik Söderholm wrote: > Is there any drawback having the files beeing set to > variable record format when one is always using fixed > sized records anyway ? 2 extra bytes for the record length are stored. And I think if the record legnth is and odd size, a padding byte at the end. (not sure about fixed length record of odd size needing a padding byte or not). There are probably a few more assembler instructions that check the record length to ensure a record being read will fit into the buffer (since each record could be a different length). ------------------------------ Date: Thu, 06 Nov 2008 23:50:40 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: Variable record format but used with fixed lenght data ? Message-ID: JF Mezei wrote: > Jan-Erik Söderholm wrote: > >> Is there any drawback having the files beeing set to >> variable record format when one is always using fixed >> sized records anyway ? > > > 2 extra bytes for the record length are stored. And I think if the > record legnth is and odd size, a padding byte at the end. (not sure > about fixed length record of odd size needing a padding byte or not). OK, so to change to "fixed" one has to unload/reload the data due to the extra lenght bytes, right ? > > There are probably a few more assembler instructions that check the > record length to ensure a record being read will fit into the buffer > (since each record could be a different length). > OK, doesn't matter much probably.... :-) Anyway, if the Rdb Gateway to RMS doesn't complains about it, I'll probably just leave them as "variable"... This once was a RMS-only "database" a long time ago on some 11/7xx box. Aprox 10 years ago a switch to Rdb was started and never finished. The systems today has aprox 50-60 tables in Rdb and aprox 20 in RMS indexed files. I'd like to at least beeing able to run ad-hoq queries joining RMS files with Rdb tables... ------------------------------ Date: Fri, 7 Nov 2008 08:57:47 +0800 From: "Richard Maher" Subject: Re: Variable record format but used with fixed lenght data ? Message-ID: Hi Jan-Erik, Maybe they wanted to be able to add any new fields to the end of the record and leave in-situ historical data untouched? Is there a record-type field somewhere? A returned record-length check? Who knows? Cheers Richard Maher PS. Is DBI and Transparent Gateway still supported or sold? "Jan-Erik Söderholm" wrote in message news:JWKQk.3898$U5.25028@newsb.telia.net... > Hi. > While analyzing some old indexed RMS datafiles > that I *know* always are used with fixed size > records (from COBOL apps), I've noticed that > they are created with : > > RECORD > CARRIAGE_CONTROL carriage_return > FORMAT variable > SIZE 280 > > Question is, why not use "fixed" when all records > are fixed size anyway ? My best guess is that it is > like this just becuse "variable" is the default, and > noone has ever thought about changing it to "fixed"... > > Is there any drawback having the files beeing set to > variable record format when one is always using fixed > sized records anyway ? > > (Apart from the one I do know about. "Rdb Transparent > Gateway to RMS" has some restrictions on variable > records formated indexed RMS files, but as I read it, > it is no issue if the records are all the same size > anyway...) > > B.t.w, this is part of a project to setup DBI and > the "Rdb Transparent Gateway to RMS" to be able to > run SQL queries against the RMS files and also run > joins between the RMS files and between the RMS files > and the Rdb database. It all looks just fine right now. > I'm currently entering field, record and database > definitions into CDD to get some metadata for the > RMS files (about 20 files). > > > Jan-Erik. ------------------------------ Date: Thu, 06 Nov 2008 19:49:03 -0500 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: Variable record format but used with fixed lenght data ? Message-ID: <49139074$0$90265$14726298@news.sunsite.dk> JF Mezei wrote: > (not sure > about fixed length record of odd size needing a padding byte or not). It does. Arne ------------------------------ Date: Fri, 7 Nov 2008 01:24:49 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Variable record format but used with fixed lenght data ? Message-ID: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >Question is, why not use "fixed" when all records >are fixed size anyway ? My best guess is that it is >like this just becuse "variable" is the default, and >noone has ever thought about changing it to "fixed"... >Is there any drawback having the files beeing set to >variable record format when one is always using fixed >sized records anyway ? I'm going to guess the file accesses of a fixed file will be a touch faster, and the files will be slightly smaller, due to not having to deal with the small overhead of dealing with the "variable" record length. If you have a "sandbox" where you can play with your application, why not use CONVERT/FDL to convert to a fixed record format, and run your sandboxed application to see if it's any faster? I'm going to guess the file size will be smaller but most of it will be due to squeezing out of unnecessary space (deleted records/buckets) and only a small amount to the variable/fixed conversion. Many RMS indexed files benefit from a rebuild once in a while. ------------------------------ Date: 06 Nov 2008 16:27:42 -0500 From: Rich Alderson Subject: Re: VAX-11/785 microdiagnostics help requested Message-ID: Johnny Billquist writes: > Rich Alderson skrev: >> Thank you for your advice. We cannot successfully boot the Diagnostic >> Supervisor diskette, and are looking into why that might be. One of the >> other tools provided is the "Micro Diagnostics Floppy #1", part number >> AS-E158S-DE, which tests such things as whether the WCS is working at all. >> This is invoked from the >>> prompt with the TEST command, according to the >> installation manual. > Do you know how much, if any similarity exists with the 86x0 machines here, > Rich? I don't have much on the 11/78[05], but I do have a lot of stuff on > the 86x0... I'm sorry, Johnny, I don't know. When I had an account on an 8600 -> 8650 (field upgrade), it was running Ultrix and I was managing 3 DEC-20s and a Systems Concepts SC-30M. I didn't get to play with the 8650 at all (kingdom building and all that). -- Rich Alderson "You get what anybody gets. You get a lifetime." news@alderson.users.panix.com --Death, of the Endless ------------------------------ End of INFO-VAX 2008.602 ************************