Migration checklist (no, not away from VMS!)
William Webb
Anybody got a reasonably good checklist so I don't have to re-invent the wheel?
Thanks in advance,
WWWebb
--
NOTE: This email address is only used for noncommerical VMS-related
correspondence.
All unsolicited commercial email will be deemed to be a request for
services pursuant to the terms and conditions located at
http://bellsouthpwp.net/w/e/webbww/
William Webb
Syltrem
2) Restore to the other machine
3) Boot Minimum
4) Edit the SYLOGICALS.COM (or your own .COM that defines logical names for
the disks) and map the logicals to the new disks on this machine
5) Possibly change the Ethernet adapter in your IP config (had to do it for
Multinet)
6) Reboot normal
That's mostly it I guess. If logical names are properly used, all should
work fine.
HTH
--
Syltrem
OpenVMS 7.3-1 + Oracle 8.1.7.4
http://pages.infinit.net/syltrem (OpenVMS related web site, en français)
---zulu is not in my email address---
"William Webb" <william...@gmail.com> a écrit dans le message de
news:8660a3a105060...@mail.gmail.com...
Carl Friedberg
Terminal Server Manager (TSM), if you are still using it;
DecNet has its own set of device-naming rules which can
produce interesting results until you figure out the new
device name (assuming it has changed). With phase IV,
you get to play with NCP to fix this. Don't have experience
doing this with DecNet+ yet...
All your queue entires will need to be deleted and re-created
if that matters to you, if the name of the disk(s) to which the
individual entries refer, change.
Beach Runner
Carl Friedberg wrote:
Colorado support maintains an up to date checklist.
Ask for it if you have a contract.
The number 1 problem is that the upgrade runs autogen. Make sure your
system has a recent good version of agen$feedback.dat within 30 day and
24 hours of uptime. The problems arise when people have not made
changes to modparams.dat, or don't save valid feedback.
Clean up any root directories, so they have no .exe in them.
Make sure any changes done in sysgen are in modparams.dat
>
>>
Wayne Sewell
>Subject: Re: Migration checklist (no, not away from VMS!)
>Date: 8 Jun 2005 16:47:33 CDT
>Message-ID: <JcI3nSOo7Bbw@tachxxsoftxxconsult>
>From: "Syltrem" <syltr...@videotron.ca>
>X-Newsgroups: comp.os.vms
>Subject: Re: Migration checklist (no, not away from VMS!)
>1) Take a good backup of every disk (if at all possible, image backups)
>2) Restore to the other machine
>3) Boot Minimum
>4) Edit the SYLOGICALS.COM (or your own .COM that defines logical names for
>the disks) and map the logicals to the new disks on this machine
>5) Possibly change the Ethernet adapter in your IP config (had to do it for
>Multinet)
With TCPWARE, you have to get a new license key, since the address of the
network adapter is embedded in the key.
>6) Reboot normal
>
>That's mostly it I guess. If logical names are properly used, all should
>work fine.
>
===============================================================================
Wayne Sewell, Tachyon Software Consulting (281)812-0738 wa...@tachysoft.com
http://www.tachysoft.com/www/tachyon.html and wayne.html
===============================================================================
Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."
Main, Kerry
I would expand Wayne's comment to "review all OpenVMS and third party
software products (including support utilities) for potential licensing
changes that might be required by moving to a new server hardware
configuration".
As an example, the issue of some third party products position on per
cpu licensing and whether dual cores are treated as separate processors
is still very much on a vendor by vendor basis. Also, moving from single
cpu to dual cpu would require SMP license etc.
Another area to examine would be batch queues. If the current
environment is a heavy batch environment, then the moving of these jobs
to the new environment needs to be planned as batch jobs keep the
physical characteristics of where they were originally submitted to.
Likely already mentioned, but when moving production app's on any
platform, you need to ensure that all third party products are supported
by the vendors on the target OS environment version.
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Syltrem
news:FD827B33AB0D9C4E92E...@tayexc19.americas.cpqcorp.net...
> I would expand Wayne's comment to "review all OpenVMS and third party
> software products (including support utilities) for potential licensing
> changes that might be required by moving to a new server hardware
> configuration".
>
I skipped that step. You may have to get new licenses from the vendors.
So this means you have to boot minimum, edit your SYSTARTUP_VMS.COM and make
sure your applications and batch queues don't start. Boot normal. Install
new license keys and test. Then after you can start the applications and
batch queues.
> As an example, the issue of some third party products position on per
> cpu licensing and whether dual cores are treated as separate processors
> is still very much on a vendor by vendor basis. Also, moving from single
> cpu to dual cpu would require SMP license etc.
>
> Another area to examine would be batch queues. If the current
> environment is a heavy batch environment, then the moving of these jobs
> to the new environment needs to be planned as batch jobs keep the
> physical characteristics of where they were originally submitted to.
I don't understand. Batch jobs will just start on the queues. Of course you
have to be careful about SYSGEN parameters on the new machine but basically
all should work, you only have to tune later. It's more of a problem if you
plan to move to a significantly smaller machine but other than that...
>
> Likely already mentioned, but when moving production app's on any
> platform, you need to ensure that all third party products are supported
> by the vendors on the target OS environment version.
>
If you do an IMAGE restore, then it's the same OS and version, just a
different hardware and that should not be an issue.
Main, Kerry
> -----Original Message-----
> From: Syltrem [mailto:syltr...@videotron.ca]
> Sent: June 9, 2005 10:49 AM
> To: Info...@Mvb.Saic.Com
> Subject: Re: Migration checklist (no, not away from VMS!)
>
> news:FD827B33AB0D9C4E92E...@tayexc19.americas.
> cpqcorp.net...
>
[snip...]
> > Another area to examine would be batch queues. If the current
> > environment is a heavy batch environment, then the moving
> of these jobs
> > to the new environment needs to be planned as batch jobs keep the
> > physical characteristics of where they were originally submitted to.
>
> I don't understand. Batch jobs will just start on the queues.
> Of course you
> have to be careful about SYSGEN parameters on the new machine
> but basically
> all should work, you only have to tune later. It's more of a
> problem if you
> plan to move to a significantly smaller machine but other than that...
>
Take a look at the existing jobs submitted to batch queues via the following example:
$ pipe show queu/all/full|search sys$pipe "File:"
Notice the physical device reference - these jobs will not run if moved as is (e.g. image restore) to a new system. They need to be re-submitted.
> >
> > Likely already mentioned, but when moving production app's on any
> > platform, you need to ensure that all third party products
> are supported
> > by the vendors on the target OS environment version.
> >
>
> If you do an IMAGE restore, then it's the same OS and version, just a
> different hardware and that should not be an issue.
>
> --
Correct. The note was in reference to moving to a new server that might require a new OS version that what the old system version was at.
norm.r...@metso.com
"Main, Kerry" <kerry...@hp.com> wrote on 06/09/2005 11:26:16 AM:
>
> > -----Original Message-----
> > From: Syltrem [mailto:syltr...@videotron.ca]
> > Sent: June 9, 2005 10:49 AM
> > To: Info...@Mvb.Saic.Com
> > Subject: Re: Migration checklist (no, not away from VMS!)
> >
> > "Main, Kerry" <kerry...@hp.com> a écrit dans le message de
> > news:FD827B33AB0D9C4E92E...@tayexc19.americas.
> > cpqcorp.net...
> >
>
> [snip...]
>
> > > Another area to examine would be batch queues. If the current
> > > environment is a heavy batch environment, then the moving
> > of these jobs
> > > to the new environment needs to be planned as batch jobs keep the
> > > physical characteristics of where they were originally submitted to.
> >
> > I don't understand. Batch jobs will just start on the queues.
> > Of course you
> > have to be careful about SYSGEN parameters on the new machine
> > but basically
> > all should work, you only have to tune later. It's more of a
> > problem if you
> > plan to move to a significantly smaller machine but other than that..
> >
>
> Take a look at the existing jobs submitted to batch queues via the
> following example:
> $ pipe show queu/all/full|search sys$pipe "File:"
There is a DCL Utility called FIXQUE.COM that proports to get all queue
information into a reload file that can be edited, then run on the
new system. I don't know where it lives, now, of if it wants updating.
$! Copyright (c) 1991,1992 Digital Equipment Corporation. All rights
reserved.
$! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
$! Procedure to try and gather all possible information out of an existing
$! queue file, to prepare for an attempt at recovery.
$!
$! As output, creates a command procedure called FIXQUE_RELOAD.COM which
can
$! be run to restore the previously existing queues, jobs, characteristics,
$! and form definitions after creating a new, empty queue file.
$!
norm.r...@metso.com
Sorry for the double post, but Keith Parris's name is all over the version
I have.
Main, Kerry
[snip ..]
As a protection, for any type of migration to a different system, once all users are off the system and all batch and print queues stopped, as a "just in case" step, I would create a log file (and being really paranoid would print the log files to paper as well) of all the appropriate batch *and* device (e.g. printer) que info e.g.
$show queue/batch/all/full/out=old_system_batch__queue_details.log
$show queue/dev/all/full/out=old_system_device_queue_details.log
And of course, a full backup of the old system before starting any data migration to a new system is assumed.
:-)
Wayne Sewell
>Subject: Re: Migration checklist (no, not away from VMS!)
>Message-ID: <JxCk4UYieSS9@tachxxsoftxxconsult>
>>
>> Another area to examine would be batch queues. If the current
>> environment is a heavy batch environment, then the moving of these jobs
>> to the new environment needs to be planned as batch jobs keep the
>> physical characteristics of where they were originally submitted to.
>
>I don't understand. Batch jobs will just start on the queues. Of course you
>have to be careful about SYSGEN parameters on the new machine but basically
>all should work, you only have to tune later. It's more of a problem if you
>plan to move to a significantly smaller machine but other than that...
>
Here's an example. This job is currently in a batch queue on my system, a
nightly tapesys backup of important files.
Batch queue TAPE$HARDY, idle, on HARDY::
/BASE_PRIORITY=4 /JOB_LIMIT=1 /OWNER=[TAPESYS] /PROTECTION=(S:RSMD,O:RSMD,G,W)
Entry Jobname Username Status
----- ------- -------- ------
964 SYSBAK_HOTSTUFF_1
TAPESYS Holding until 9-JUN-2005 20:30:00.00
Submitted 9-JUN-2005 00:05:07.30 /KEEP /LOG=LAUREL$DKB100:[TAPESYS_PRODUCTION.][SYSBAK.LOGS]SYSBAK_HOTSTUFF_1.LOG;
/PARAM=("HOTSTUFF","1") /NOPRINT /PRIORITY=100
File: _LAUREL$DKB100:[TAPESYS_PRODUCTION.SYSTEM]SYSBAK.BIS;776
Note that the file name contains a physical device name, despite the fact that
it was submitted using a logical name. This is the "physical characteristics
of where they were originally submitted to" mentioned earlier.
So *if* you place the disk cloned from _LAUREL$DKB100: into the same relative
slot on the same relative scsi controller on the new system, then this batch
job will work. If the disk has a different scsi ID on the new system, or is
not on the second scsi controller, the name will be different, such as
_LAUREL$DKC400:, and the job will fail because it can't find the command
procedure on _LAUREL$DKB100: .
===============================================================================
William Webb
Thanks, everybody. In addition to the generic gotchas, my particular
concerns specifically address the retention of historic ABS
information, and I've opened a call about that. Got two really nice
upgrade checklists from HP in the meantime, as well.
Wayne,
Your point is well taken-- just about the only time I believe in using
physical device names is in SYLOGICALS.COM, although there may be
application-specific exceptions to the general rule, but if and only
if a logical absolutely can't be used.
Dave Froble
>>-----Original Message-----
>>From: norm.r...@metso.com [mailto:norm.r...@metso.com]
>>Sent: June 9, 2005 11:41 AM
>>To: Info...@Mvb.Saic.Com
>>Subject: RE: Migration checklist (no, not away from VMS!)
>>
>>"Main, Kerry" <kerry...@hp.com> wrote on 06/09/2005 11:26:16 AM:
>>
>>
>>>>-----Original Message-----
>>>>From: Syltrem [mailto:syltr...@videotron.ca]
>>>>Sent: June 9, 2005 10:49 AM
>>>>To: Info...@Mvb.Saic.Com
>>>>Subject: Re: Migration checklist (no, not away from VMS!)
>>>>
>>>>"Main, Kerry" <kerry...@hp.com> a écrit dans le message de
>>>>news:FD827B33AB0D9C4E92E...@tayexc19.americas.
>>>>cpqcorp.net...
>>>>
>>>
>>>[snip...]
>>>
What's interesting is that triple dubya never gave any details of the
'migration', but there has been plenty of advice on how to do the unknown.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
Peter Weaver
>...
> With TCPWARE, you have to get a new license key, since the address of
> the network adapter is embedded in the key.
What version of TCPWare did that? In the past 8 years I have never seen
a TCPWare license tied to any hardware and I have seen quite a few
TCPWare licenses.
--
Peter Weaver
Weaver Consulting Services Inc.
Canadian VAR for CHARON-VAX
www.weaverconsulting.ca
Syltrem
"William Webb" <william...@gmail.com> wrote in message
news:8660a3a105060...@mail.gmail.com...
>> physical device names is in SYLOGICALS.COM, although there may be
>> application-specific exceptions to the general rule, but if and only
>> if a logical absolutely can't be used.
>>
>> WWWebb
>>
I take good note of that too.
I'm currently doing a revision of our disaster recovery plan and had
overlooked this fact.
The plan was actually tested and all the applications were fine, but I never
started the jobs already waiting in the queues. Will test next time.
Thanks
Syltrem
Peter 'EPLAN' LANGSTOEGER
>Wayne Sewell wrote:
>> With TCPWARE, you have to get a new license key, since the address of
>> the network adapter is embedded in the key.
>
>a TCPWare license tied to any hardware and I have seen quite a few
>TCPWare licenses.
Probably the licenses before LMF was used (I use TCPware since 1988 or 89
but I can't remember now how this was done. I believe to remember that I
had to send them CPU, XCPU and the Mac.Add at this times)
OTOH, I had a Hardware I.D. on one of my last TCPware (Alpha) license PAKs.
No HWID on my hobbyist PAKs though.
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
AEF
Peter 'EPLAN' LANGSTOEGER wrote:
> In article <3h8mr7F...@individual.net>, "Peter Weaver" <news...@weaverconsulting.ca> writes:
> >Wayne Sewell wrote:
> >> With TCPWARE, you have to get a new license key, since the address of
> >> the network adapter is embedded in the key.
Wow, a post from the future! Google Groups shows this as posted at
02:08 EDT, but it's only 01:47 EDT as I write this! I guess they
screwed up their time zone calculations!
While there have been some improvements in the Beta Google Groups, they
still manage to screw things up by being overly ambitious, at least in
this case.
Oh well.
Back to the present for me!
Wayne Sewell
>Subject: Re: Migration checklist (no, not away from VMS!)
>Message-ID: <Qf8u8JJD8iwz@tachxxsoftxxconsult>
>From: "Peter Weaver" <news...@weaverconsulting.ca>
>X-Newsgroups: comp.os.vms
>Subject: Re: Migration checklist (no, not away from VMS!)
>Organization: Weaver Consulting Services Inc.
>Wayne Sewell wrote:
>>...
>> With TCPWARE, you have to get a new license key, since the address of
>> the network adapter is embedded in the key.
>> ...
>
>What version of TCPWare did that? In the past 8 years I have never seen
>a TCPWare license tied to any hardware and I have seen quite a few
>TCPWare licenses.
>
I'm not sure which version it was. I just remember having to do it at some
point when installing at a customer site. It's possible that they changed the
licensing mechanism since then. If that is no longer true, I apologize.
Wayne
===============================================================================
William Webb
The license-keyed-to-physical-hardware business stopped around the
same time that systems quit having unique hardcoded system IDs. (and I
remember having some third-party product on my 8530, whether RAXCO's
Security Toolkit or someone else's product that's long-forgotten), and
we had to arrange for special keys when we did DR testing at SunGard.
Anyway, I can do the hardware-specific license key one better.
My copy of Golden Eggs has a DONGLE.
(There will now be a brief intermission while about half the readers
go to the Jargon File, D section.)
: ^ )
Syltrem
I downloaded FIXQUE.COM today and tested it.
I found one problem in it, due to the fact that a long time ago, a
programmer started a batch that resubmitted itself over and over, resulting
in a lot of entry creation, and since then our entry numbers are very large.
$ sh ent
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
1002735 POW_LIC_CNT SYLTREM Executing
On available batch queue AXIS_KRONOS
So... the check to see if column 1 of a line has a blank in it is no longer
working.
I fixed the problem by checking if the 2nd or 3rd word of the line fetched
from the "show que/full/all" file is "queue", as in:
Generic server queue MULTINET_SMTP
or
Server queue SMTP_HELIOS, idle, on HELIOS::, mounted form DEFAULT
Who do I send the correction to, so that it finds its way to the next
freeware CD?
Keith Parris, are you there?
Very useful tool.
Thanks
"Syltrem" <syltr...@videotron.ca> a écrit dans le message de
news:wCFre.2336$g4.3...@tor-nn1.netcom.ca...
Keith Parris
> Who do I send the correction to, so that it finds its way to the next
> freeware CD?
> Keith Parris, are you there?
I'm not there, I'm here. :-)
You can reach me at firstname...@hp.com or parris at encompasserve
<dot> org.
Thanks for the correction.
norm.r...@metso.com
Can you post the correction for those who have the code and don't want to
have to download all of it
all over again, please.
"Syltrem" <syltr...@videotron.ca> wrote on 07/13/2005 04:25:09 PM:
> Good afternoon all
>
> I downloaded FIXQUE.COM today and tested it.
> I found one problem in it, due to the fact that a long time ago, a
> programmer started a batch that resubmitted itself over and over,
resulting
> in a lot of entry creation, and since then our entry numbers are very
large.
> $ sh ent
> Entry Jobname Username Blocks Status
> ----- ------- -------- ------ ------
> 1002735 POW_LIC_CNT SYLTREM Executing
> On available batch queue AXIS_KRONOS
>
> So... the check to see if column 1 of a line has a blank in it is no
longer
> working.
> I fixed the problem by checking if the 2nd or 3rd word of the line
fetched
> from the "show que/full/all" file is "queue", as in:
> Generic server queue MULTINET_SMTP
> or
> Server queue SMTP_HELIOS, idle, on HELIOS::, mounted form DEFAULT
>
> Who do I send the correction to, so that it finds its way to the next
> freeware CD?
> Keith Parris, are you there?
>
Keith Parris
> Can you post the correction for those who have the code and don't want to
> have to download all of it all over again, please.
Here is a list from $DIFFERENCES. The V6 Freeware version is the top
version; the fixed version is at the bottom of each difference area.
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
737 $ if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1 !Next
queue -->
738 $! Must be the header for jobs in this queue
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
733 $!!! if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1
!Next queue -->
734 $ if f$elem(1," ",record) .eqs. "queue" .or. f$elem(2,"
",record) .eqs. "queue" then goto Q_LOOP_1 !Next queue -->
735 $! Must be the header for jobs in this queue
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
782 $ 'if_v55 job_entry = f$edit(f$extract(1,6,record),"TRIM")
783 $ 'if_v55 if f$type(job_entry) .nes. "INTEGER" then goto SHOW_ERROR
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
779 $ 'if_v55 job_entry = f$edit(f$extract(0,7,record),"TRIM")
780 $ 'if_v55 if f$type(job_entry) .nes. "INTEGER" then goto SHOW_ERROR
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
976 $! If this wasn't a file line, then after the blanks, there
should be a
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
973 $
974 $! icitte
975 $!
976 $!
977 $! If this wasn't a file line, then after the blanks, there
should be a
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
1005 $ if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1 !Next
queue -->
1006 $ goto Q_LOOP_2 !Go handle the next job in same queue -->
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
1006 $!!! if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1
!Next queue -->
1007 $ if f$elem(1," ",record) .eqs. "queue" .or. f$elem(2,"
",record) .eqs. "queue" then goto Q_LOOP_1 !Next queue -->
1008 $ goto Q_LOOP_2 !Go handle the next job in same queue -->
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
1024 $ if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1 !Next
queue -->
1025 $ goto Q_LOOP_2 !Found start of next job -->
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
1026 $!!! if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1
!Next queue -->
1027 $ if f$elem(1," ",record) .eqs. "queue" .or. f$elem(2,"
",record) .eqs. "queue" then goto Q_LOOP_1 !Next queue -->
1028 $ goto Q_LOOP_2 !Found start of next job -->
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
1052 $ if .not. rerun then delete/nolog -
1053 FIXQUE_QUEUE_GENERIC.TEMP;*,-
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
1055 $ if .not. rerun then delete/noconf/nolog -
1056 FIXQUE_QUEUE_GENERIC.TEMP;*,-
************
************
File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
1136 $ if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1 !Next
queue -->
1137 $ SE_SKIP_LOOP:
******
File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
1139 $!!! if f$extract(0,1,record) .nes. " " then goto Q_LOOP_1
!Next queue -->
1140 $ if f$elem(1," ",record) .eqs. "queue" .or. f$elem(2,"
",record) .eqs. "queue" then goto Q_LOOP_1 !Next queue -->
1141 $ SE_SKIP_LOOP:
************
Number of difference sections found: 8
Number of difference records found: 19
DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=USRD:[PARRIS]TEMP.EDT;17-
USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1-
USRD:[PARRIS]FIXQUEUE_COM.TXT;2
norm.r...@metso.com
Keith,
Thanks for the updates.
Would you please explain this section:
> File USRD:[PARRIS.KP_CLUSTERTOOLS]FIXQUE.COM;1
> 976 $! If this wasn't a file line, then after the blanks, there
should be a
> ******
> File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
> 973 $
> 974 $! icitte
> 975 $!
> 976 $!
> 977 $! If this wasn't a file line, then after the blanks, there
should be a
Why a bare $ line?
What is "icitte"?
What does this set of comments add?
Oh, and for readability, I prefer that, for example:
> 1007 $ if f$elem(1," ",record) .eqs. "queue" .or. f$elem(2,"
",record) .eqs. "queue" then goto Q_LOOP_1 !Next queue -->
Be changed to
> $ if f$elem(1," ",record) .eqs. "queue" .or. -
f$elem(2," ", record) .eqs. "queue" then goto Q_LOOP_1 !Next queue
-->
-Norm
Keith Parris <keithparr...@yahoo.com> wrote on 07/15/2005 12:12:02
PM:
Keith Parris
>>File USRD:[PARRIS]FIXQUEUE_COM.TXT;2
>> 973 $
>> 974 $! icitte
>> 975 $!
>> 976 $!
>> 977 $! If this wasn't a file line, then after the blanks, there
> Why a bare $ line?
> What is "icitte"?
> What does this set of comments add?
This and the rest of the changes were kindly provided by Syltrem. I'm no
linguist, but based on a quick web investigation, it appears this word
may be French and just seems to be indicating that this is the specific
area of code in need of corection -- the Altavista/Babelfish definition
for "icitte" is "In this place (the place where the person is who
speaks); as opposed to there, over there."
You can simply omit this change.
Syltrem
"Keith Parris" <keithparr...@yahoo.com> a écrit dans le message de
news:4FQCe.8748$Pa6....@news.cpqcorp.net...
Hi !
I just placed this comment to come back to this place when debugging, then
forgot about removing it.
Icitte is not very good french either, and I'm surprised that Babalfich
picked it up fine (translation is ok). The real word in the dictionary is
"ici" and translated to "here" but since "ici" may easily be part of many
words when searching wit hthe editor..
Just take off the comment !
Syltrem
norm.r...@metso.com
Syltrem
news:OF136A8533.173715A0-ON852570...@metso.com...
Have you been on holidays for 2 months?
No, my MS-Outlook just lost track of this thread I previously marked as
"watch this thread"...
And yesterday I stumbled over this post by pure coincidence...
I would love to have 2 months vacations ! Especially since we had a great
summer season here.
--
Syltrem
http://pages.infinit.net/syltrem (OpenVMS related web site, en français)