About Kevin Atchley

Kevin Atchley · ‎01-31-2008

It does appear the setting the buffers and blocks without setting RMS_SEQFILE_WBH does help with backup/copies we are doing. Testing does show there were no ill-effects. Thanks to all.

Kevin Atchley · ‎01-25-2008

It is a BACKUP style copy of files. We have machine A that mounts an NFS mount point that is being "hosted" by machine B. Machine A then does a BACKUP of the files from machine A to a saveset on machine B. We then expand those files out to their new homes.

Kevin Atchley · ‎01-25-2008

For Clarification : (sorry, I should have put this in the first post) Both systems are VMS 7.3-2. It is a system to system copy of data utilizing and NFS mount on the target system. And Yes, I did re-type the command instead of cut/paste, and stick an extra 0 on the /EXTEND.

Kevin Atchley · ‎01-25-2008

I am looking at migrating data from one system to another and am trying to reduce the time of copying data as much as possible. I have made some changes in the BACKUP command and gained some improvement, but I want to reduce it more. While Googeling I ran across someone suggesting I make a change to set RMS_SEQFILE_WBH = 1 and then a SET RMS /BUFFER=10 /EXTEND=650000 /BLOCK=127. I did this on a test system with test data and was able to improve the trial times from 30min down to 5min. Does anyone have any advice or experience about whether using this command can/will cause problems. During the data migration period both source and destination machine will not be used, so I should have unshared access to the data. Thanks in advance, -k

Kevin Atchley · ‎11-01-2006

Thank you. After some minor tweaking for my own purposes this appears to have done the job I need. Thanks for all your help.

Kevin Atchley · ‎10-05-2006

Good Afternoon All, I pose a question for you. I have a command procedure that copies a series of files from Node A to Node B. Once the files get copied to Node B, I would like the command procedure to set the file attributes to /NOBACKUP on those files. I do not want the attributes for the files on NODE A set to /NOBACKUP, so they must stay as is. Is there an easy way to do this? Thank you all, -k

Kevin Atchley · ‎10-26-2005

Good Day All ... I am posting a question to see how other members in the community deal with this issue. We have large quantity of DEC terminal servers in our company, stretched across many nodes. The models we are using range from the old DECServer 100s, 200s, and 300s, to the DECServer 90 modular series (90TL, 90L+, 90M), all the way through the 700 and 900 series. I am trying to find out what others are using to configure devices like these. Since the locations we manage are highly distributed, we cannot use the physical console port on the device. We need something that can be used for remote administration. Also, since most of these models do not support TCP/IP, we need something the can access them via LAT (or MOP?) (even on the devices that do support TCP/IP, as we only use LAT for communication). We are currently using Digital's TSM (Terminal Server Manager - yeah, i know it's old, but it does the trick). However, since it is retired (for some time now), it will not be ported to new versions of VMS. I know that the terminal servers can be configured through DECNet (which is how TSM does what it does), however we are looking for something a little easier. Digital/Compaq did come out with a product at one time called NetRider(?) that allowed for graphical management of TCP/IP enabled devices, and configuration of LAT devices via the use of a DECAgent90, however this is not an option in our current environment. Anyway, I hope that give you an idea of the situation we're in, and I was just hoping to get some ideas of what other people in the community are using. Any advice/information would be greatly appreciated. -k

Kevin Atchley · ‎08-22-2005

{see description of solution above}

Kevin Atchley · ‎08-22-2005

Thank you all for your generous help. We have finally determined what was happening, and why we were seeing the odd behavior. As it turns out, when the users log into the server, they go into a custom written menu. The menu, among many other things, changes the UIC of the user's process as it traverses the menu. The issues we were seeing were nothing more than a timing issue. When the 1st user logged in, they started in group [00100] and had process name = user name; they went into menu and changed UIC to [00250]. The next user logged in and started in group [00100] with process name = user name; they went into menu and their UIC changed to [00250]. Now, when user #3 logged in with UIC [00100] and process name = user name, they DID NOT go into menu. So when user #4 logged in with UIC [00100], their process name did not change to match user name, it stayed the _LTAxxxx that VMS assigned it. And so on, and so on, and so on.... Thank you all for your help and the information you presented. Have a good day, -k

Kevin Atchley · ‎08-19-2005

Again, Thank You All, Antonio, I have had some luck in creating duplicate process names for the same user name following some of the suggestions you left. I'm not sure if this is what we are doing, but I will start looking at our code to find out if this is the culprit. Also, in response to several other suggestions i can say that the usernames are not being padded with spaces to give the "appearance" of similar process names. Doing a f$length( f$getjpi("pid","PRCNAM)) on the processes shows the process name for all of them is the same length. Also, there is nothing special in the system or user login procedures that is making these changes, but there is other local code to be looked at. Again, I have heard that duplicate process names are not allowed in a specific group (which I know can be circumvented with a few tricks). I am still wanting to find out what this "group" is? Is this the UIC for the account that was logged in while the process name was being assigned? Is there some way to see what "group" the process is in, such as a SHO PROC /ALL? How can I verify that all of the processes are in different groups (or the same group)? Thanks, -k

Kevin Atchley · ‎08-19-2005

Thank You All, I think I am getting closer to understanding why it is happening, but now the questions is HOW is it happening. I have read that there can not be two processes with the same process name in the same group. So my question is, why/how can we have 20 processes with process name RANGE whan they are all logging in under the same usreid? I would assume they would have to be in different groups, and I'm sure we do have some local code in place that is changing process names and possible even group assignments, but how do I verify this? i.e. What information in SHO PROC /ALL/ID=xxxxxxxx points out that these two (or twenty) processes are in different groups? Thanks to all, (point will be assigned shortly) -k

Kevin Atchley · ‎08-18-2005

Thank you all for your response, however I still don't quite have the information I was looking for. Allow me to elaborate. Doing a SHOW USER/FULL, we have the following users logged in: Username Process Name PID Terminal RANGE RANGE 000D4808 LTA1187: (MAGT06/TS63) RANGE RANGE 000F900C LTA1338: (MAGT0T/TST7) RANGE RANGE 000B8E2B LTA1389: (MAGT0M/TSM6) RANGE RANGE 000F2A36 NTY8542: (ccc-ornent) RANGE RANGE 00088095 LTA1717: (MAGT0M/TSM2) RANGE RANGE 000CF896 LTA1946: (MAGT0X/TSX3) RANGE RANGE 0008A2A2 LTA1781: (MAGT0O/TSO2) RANGE RANGE 000D06A6 LTA1240: (MAGT09/TS97) RANGE RANGE 000B36B9 LTA1328: (MAGT08/TS81) RANGE RANGE 000C46BB NTY8995: (23aal66.milliken.com) RANGE RANGE 000EB4C4 LTA1247: (MAGTBB/TSBB5) RANGE RANGE 00086CD8 LTA1752: (MAGT09/TS95) RANGE RANGE 00102EF2 LTA1299: (MAGT0R/TSR4) RANGE RANGE 001168F4 LTA1823: (MAGTFF/TSFF5) RANGE RANGE 00107305 LTA1393: (MAGT06/TS66) RANGE RANGE 0011E30D LTA1841: (MAGT06/TS64) RANGE RANGE 00114117 LTA1372: (MAGT0O/TSO6) RANGE RANGE 000CBF2A LTA1607: (MAGT0O/TSO1) RANGE RANGE 0010E530 LTA1949: (MAGT09/TS93) RANGE RANGE 000E9160 LTA1409: (MAGT0T/TST8) RANGE _LTA1237: 000AD0FC LTA1237: (MAGT0O/TSO8) RANGE _LTA1278: 000E2A37 LTA1278: (MAGT0I/TSI1) RANGE _LTA1580: 0011FF33 LTA1580: (MAGT04/TS48) The question we have is why do some of the users have Username RANGE and Process Name RANGE, while others have Process Name LTAxxxx:? They should all be in the same group as they are all doing the same thing and logging in under the same account. We are more interested in finding out why there are some showing up as LTAxxxx: because we want those to show Process Name the same as User Name. Again, I don't know why our code was written to use Process Name when logging entries, but i have been told it's not something they want to try and change (if they can get around it). Again, TIA for your help, -k

Kevin Atchley · ‎08-18-2005

Greeting's All (1st time poster ... please bear with the newbie) We are running a system on VMS v7.3-1, and have noticed something peculiar. When doing a SHO USER /FULL, it shows a list of all user's logged into the system, along with the process name associated with each user. In all most all cases the process name matches the user name. However, in some cases the process name shows up as "_LTAxxxx:". This is causing a problem as we have some local code that grabs the process name and writes it to a log file, when it logs the "_LTAxxxx" we have no way of knowing what person we were logging information about at that time. And no .. i don't know why our local code was written this way, but it apparently cannot be changed easily so I was asked to find out why the process names were showing as they are. After doing some digging in manuals it seemed to me that there should never be duplicate process names within a given group. However, this does not seem to match what I am seeing on our system. If I do a SHO PROC /ALL /ID=xxxxxxxx I get the following information about several of the processes on his system: MAGA:CSKTA> pipe sho proc/all/id=0011E30D | sea sys$input "User I", "ess name" Node: MAGA Process name: "RANGE" User Identifier: [CONTR,RANEFF] MAGA:CSKTA> pipe sho proc/all/id=00114117 | sea sys$input "User I", "ess name" Node: MAGA Process name: "RANGE" User Identifier: [CONTR,RANEFF] MAGA:CSKTA> pipe sho proc/all/id=000E9160 | sea sys$input "User I", "ess name" Node: MAGA Process name: "RANGE" User Identifier: [CONTR,RANEFF] MAGA:CSKTA> pipe sho proc/all/id=000E2A37 | sea sys$input "User I", "ess name" Node: MAGA Process name: "_LTA1278:" User Identifier: [CONTR,RANEFF] As you can see the User Identifiers for all processes match (which I assume points to what group they belong, however the process names for some are the same and for some are different. So my question is .... How does the system determine what the processes name is for a user when they log in, why are some of the process names identical and why are some of them "_LTAxxxx:" processes, and if I am looking at the wrong information what information should I be looking at? TIA for all you help, -k

Re: Use of RMS_SEQFILE_WBH and Backups

Re: Use of RMS_SEQFILE_WBH and Backups

Re: Use of RMS_SEQFILE_WBH and Backups

Use of RMS_SEQFILE_WBH and Backups

Re: Setting File Attributes on a Remote Node

Setting File Attributes on a Remote Node

DEC Terminal Server Management

Re: How Are Process Names Generated?

Re: How Are Process Names Generated?

Re: How Are Process Names Generated?

Re: How Are Process Names Generated?

Re: How Are Process Names Generated?

How Are Process Names Generated?