Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Charles Mills 
Eighth Edition (March 1993) 
 
| This edition replaces and makes obsolete the previous edition,
| SC26-4047-06.  Technical changes for this edition are summarized
| under"Summary of Changes" in topic FRONT_3 and are indicated by a 
| vertical bar to the left of the change.
 
| This edition applies to Release 4 of VS COBOL II, Program Numbers
| 5668-958 (Compiler and Library with Debug), 5688-023 (Compiler and
| Library), and 5688-022 (Library only), and to any subsequent releases
| until otherwise indicated in new editions or technical newsletters.
| Make sure you are using the correct edition for the level of the
| product.
 
  Order publications through your IBM representative or the IBM branch
  office serving your locality.  Publications are not stocked at the
  address below.
 
  A form for readers' comments is provided at the back of this
  publication.  If the form has been removed, address your comments to:
 
  IBM Corporation, Department J58
  P.O. Box 49023
  San Jose, CA, 95161-9023
  United States of America


And what a change in attitude from that Comment Form to today! Contrast what it 
says with the attitude today toward customer input:


Please use this form to tell us what you think about the accuracy,
  clarity, organization, and appearance of this manual.  Any suggestions you
  have for its improvement will be welcome.
 
Charles


On Sun, 21 May 2023 21:34:49 +, Frank Swarbrick 
 wrote:

>What was the release date on that?
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Frank Swarbrick 
What was the release date on that?

From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Sunday, May 21, 2023 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

VS COBOL II Release 4 -- change bars on the doc:

x LENGTH OF Special Register
x The LENGTH OF special register contains the number of bytes used by an
x identifier.

x LENGTH OF creates an implicit special register whose content is equal
x to the current byte length of the data item referenced by the
x identifier.

x Note:  For DBCS data items, each character occupies 2 bytes of
x storage.

... and more

Charles

On Sun, 21 May 2023 00:51:33 +, Frank Swarbrick 
 wrote:

>At least VS COBOL II, as far as I can remember.  This is when CICS added the 
>COBOL2 translate option to allow the LENGTH argument to be omitted, since it 
>used LENGTH OF under the covers.
>Also, it's called a "special register" rather than built-in function; though 
>now there is also an intrinsic function LENGTH, as well as BYTE-LENGTH.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Phil Smith III 
Well, various folks have convinced me that I missed this back when I looked for 
it! I have a hazy memory of asking someone-not this list-about it and being 
told "No" but that might be wishful thinking.

 

Hmm, it *had* been a while; I looked at the source, found this comment:
*Given two COBOL data elements, return an integer

*containing the difference between them. This is

*necessary because COBOL does not provide a way to

*do so, and users need this to calculate offsets

*between fields in a COBOL copybook
So it's not quite "length of" but surely one could have calculated it using 
lengths. The actual function is, unsurprisingly, quite short: ten lines of 
code, most of it linkage, only four lines of actual "do it" code.

 

Anyway, thanks for all the replies! I do remember feeling kind of disbelieving 
that this wasn't possible using native COBOL.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Charles Mills 
Dated March 12, 1993 

On Sun, 21 May 2023 14:46:10 -0500, Charles Mills  wrote:

>VS COBOL II Release 4 -- change bars on the doc:
>
>x LENGTH OF Special Register 
>x The LENGTH OF special register contains the number of bytes used by an
>x identifier.
> 
>x LENGTH OF creates an implicit special register whose content is equal
>x to the current byte length of the data item referenced by the
>x identifier.
> 
>x Note:  For DBCS data items, each character occupies 2 bytes of 
>x storage.
>
>... and more
>
>Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Charles Mills 
VS COBOL II Release 4 -- change bars on the doc:

x LENGTH OF Special Register 
x The LENGTH OF special register contains the number of bytes used by an
x identifier.
 
x LENGTH OF creates an implicit special register whose content is equal
x to the current byte length of the data item referenced by the
x identifier.
 
x Note:  For DBCS data items, each character occupies 2 bytes of 
x storage.

... and more

Charles

On Sun, 21 May 2023 00:51:33 +, Frank Swarbrick 
 wrote:

>At least VS COBOL II, as far as I can remember.  This is when CICS added the 
>COBOL2 translate option to allow the LENGTH argument to be omitted, since it 
>used LENGTH OF under the covers.
>Also, it's called a "special register" rather than built-in function; though 
>now there is also an intrinsic function LENGTH, as well as BYTE-LENGTH.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Paul Gilmartin 
On Sun, 21 May 2023 18:56:39 +, Seymour J Metz wrote:

>The Initiator calls it with a 32-bit PLIST, so below the bar and if you invoke 
>it with CALL you must be aware that it is a main program and do likewise.
>
>WEe hates it, precious, we hates it.
> 
It should have been easy enough for the initiator to query the AMODE and
provide a 31-bit or 64-bit list accordingly.

This feels like a design blunder resulting from haste to deliver.  The sort
that's orders of magnitude more costly to recover from in GA than in
development.

I could even envision a bizarre compatibility accommodation in which all
the parameter values are below-the-line and bits 32-63 of GR1 address
a 31-bit plist and the entire GR1 addresses a 64-bit plist referring to the
same below-the-line valuse/

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Seymour J Metz 
The Initiator calls it with a 32-bit PLIST, so below the bar and if you invoke 
it with CALL you must be aware that it is a main program and do likewise.

WEe hates it, precious, we hates it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Seymour J Metz 
32-bit PLIST, and the AMODE64 main program is responsible for clearing the VL 
bit before using the address. BAD.

For anything else, the PLIST is 64 bits wide, there is no VL bit and the last 
pointer is followed by -1 (all fox Fox). Parameters from AMODE64 to AMODE64 may 
be above the bar. But if you want to pass it to AMODE31, ...


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 2:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Paul Gilmartin 
On Sun, 21 May 2023 16:51:18 +, Seymour J Metz wrote:

>That's not a CALL convention. The primary use case for the halfword length is 
>programs that can be invoked with EXEC PGM=.  ...

>I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
>different.
>
If a program object is marked AMODE 64, does EXEC PGM= cause it to be
entered with a 64-bit PLIST?  May CALL invoke it with arguments above the bar
or must the caller copy arguments to below the bar?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Seymour J Metz 
That's not a CALL convention. The primary use case for the halfword length is 
programs that can be invoked with EXEC PGM=. For most subroutines, the entries 
in the PLIST point directly at the parameter or point to a language-specifc 
control block of some kind, e.g., a locator/descriptor for PLI CHAR variables. 
Always setting the end-of-list flag is a good habit to get into.

I assume that you're talking AMODE24 or AMODE31; for AMODE64 things are 
different.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, May 21, 2023 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

On Sun, 21 May 2023 08:02:59 +0300, Binyamin Dissen  wrote:
>
>Curious how you used a subroutine. It only worked for fields in a structure
>where you passed the address of the field and the next field and it subtracted
>the addresses?
>
>Was there a way to make COBOL pass a dope vector with descriptions of the
>field?
>
Does COBOL not follow the CALL or ADDRESS LINKMVS convention where
R1 addresses an array of fullwords where each addresses a halfword length
followed by the value?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-21 Thread Paul Gilmartin 
On Sun, 21 May 2023 08:02:59 +0300, Binyamin Dissen  wrote:
>
>Curious how you used a subroutine. It only worked for fields in a structure
>where you passed the address of the field and the next field and it subtracted
>the addresses?
>
>Was there a way to make COBOL pass a dope vector with descriptions of the
>field?
> 
Does COBOL not follow the CALL or ADDRESS LINKMVS convention where
R1 addresses an array of fullwords where each addresses a halfword length
followed by the value?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-20 Thread Binyamin Dissen 
On Sat, 20 May 2023 19:09:03 -0400 Phil Smith III  wrote:

:>Since when does COBOL have LENGTH OF? I looked for this about 12 years ago 
and didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

:>Not that the code has needed any support, but I'm glad that if it ever 
becomes an issue, I can say "Use the BIF instead"!

Curious how you used a subroutine. It only worked for fields in a structure
where you passed the address of the field and the next field and it subtracted
the addresses?

Was there a way to make COBOL pass a dope vector with descriptions of the
field?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-20 Thread Frank Swarbrick 
At least VS COBOL II, as far as I can remember.  This is when CICS added the 
COBOL2 translate option to allow the LENGTH argument to be omitted, since it 
used LENGTH OF under the covers.
Also, it's called a "special register" rather than built-in function; though 
now there is also an intrinsic function LENGTH, as well as BYTE-LENGTH.

One thing that LENGTH OF will do that the others won't is allow you to get the 
length of a table element without subscripting it, e.g.

01  my-table.
05  my-entry occurs 10 times.
10  me-one   pic x(8).
10  me-two   pic s9(9) comp.

call 'something' using my-table, content length of my-entry

The LENGTH OF special register and the BYTE-LENGTH function both return the 
number of bytes of a field.  The LENGTH function will return the number of 
"characters" for both USAGE DISPLAY and USAGE NATIONAL, meaning LENGTH 
OF/BYTE-LENGTH function for a PIC N(10) returns 20, while LENGTH function 
returns 10.

For the new UTF-8 it seems to do its own thing that I have not researched yet.  
But so far it returns 10 for all 3, even though it allocates 40 bytes for a PIC 
U(10).  I'm sure there is some logic behind it.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Saturday, May 20, 2023 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LENGTH OF in COBOL (was: ISPF HILITE Question)

Since when does COBOL have LENGTH OF? I looked for this about 12 years ago and 
didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

 

Not that the code has needed any support, but I'm glad that if it ever becomes 
an issue, I can say "Use the BIF instead"!


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

LENGTH OF in COBOL (was: ISPF HILITE Question)

2023-05-20 Thread Phil Smith III 
Since when does COBOL have LENGTH OF? I looked for this about 12 years ago and 
didn't find it, wrote a tiny and trivial assembler function to do the same 
thing. Did I miss it, or is it new since then?

 

Not that the code has needed any support, but I'm glad that if it ever becomes 
an issue, I can say "Use the BIF instead"!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPF HILITE Question

2023-05-19 Thread Steve Thompson 

Thanks for that.

I just started experimenting with "functions" in COBOL 6.2 and 
saw those constructs, and just hadn't tried them yet.


Steve Thompson

On 5/19/2023 3:58 AM, Frank Swarbrick wrote:

Yes, the ISPF COBOL highlight is not up to date at the moment.  They got up to 
date a few releases back, but at least on my system they are not up to date 
with COBOL 6.3 and 6.4 at the least.

Not sure you need BYTE-LENGTH for this, though.  FUNCTION LENGTH() or LENGTH OF 
works just fine for ODO.

I recommend using the following to eliminate the need for the FUNCTION keyword.  And it 
will eliminate the "error" highlight you are seeing, since that keys of the 
FUNCTION keyword.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
 FUNCTION ALL INTRINSIC.

COMPUTE L = LENGTH(MYFIELD)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Thursday, May 18, 2023 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF HILITE Question

I have been chasing through a few IBM ISPF manuals and I am trying to figure out why, when HILITE is COBOL, certain 
words are "pink". Now I thought this was used to show a logic error, such as an "IF" with a missing 
"END-IF", or an extraneous "END-IF".

Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of one, but it is getting colored pink. 
Could this be because ISPF doesn't know about new functions in COBOL? In this case it is 
"BYTE-LENGTH" (because I need to know at execution time what the size of the named label 
is -- "Depending on" is being used).

Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are not in synch?

TIA,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
Regards,
Steve Thompson
VS Strategies LLC
Westfield IN
972-983-9430 cell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPF HILITE Question

2023-05-19 Thread Lionel B. Dyck 
Take a look at CBT Tape file 967 from Tom Conley - it is the CBT Usermod 
Collection for ISPF (aka CUCI) and supports many additional hilite languages 
and enhancements.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Butler
Sent: Friday, May 19, 2023 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF HILITE Question

As an enhancement to the HILITE command, it would be nice if the list of 
keywords for any given language could be edited to customize them for 
individual use.  

I use PL/I to edit SQL statements, and a few tweaks would be nice...lacking an 
SQL type, of course.

Cheers,

Jon.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPF HILITE Question

2023-05-19 Thread Jon Butler 
As an enhancement to the HILITE command, it would be nice if the list of 
keywords for any given language could be edited to customize them for 
individual use.  

I use PL/I to edit SQL statements, and a few tweaks would be nice...lacking an 
SQL type, of course.

Cheers,

Jon.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPF HILITE Question

2023-05-19 Thread Frank Swarbrick 
Yes, the ISPF COBOL highlight is not up to date at the moment.  They got up to 
date a few releases back, but at least on my system they are not up to date 
with COBOL 6.3 and 6.4 at the least.

Not sure you need BYTE-LENGTH for this, though.  FUNCTION LENGTH() or LENGTH OF 
works just fine for ODO.

I recommend using the following to eliminate the need for the FUNCTION keyword. 
 And it will eliminate the "error" highlight you are seeing, since that keys of 
the FUNCTION keyword.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
FUNCTION ALL INTRINSIC.

COMPUTE L = LENGTH(MYFIELD)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Thursday, May 18, 2023 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF HILITE Question

I have been chasing through a few IBM ISPF manuals and I am trying to figure 
out why, when HILITE is COBOL, certain words are "pink". Now I thought this was 
used to show a logic error, such as an "IF" with a missing "END-IF", or an 
extraneous "END-IF".

Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of one, but it is 
getting colored pink. Could this be because ISPF doesn't know about new 
functions in COBOL? In this case it is "BYTE-LENGTH" (because I need to know at 
execution time what the size of the named label is -- "Depending on" is being 
used).

Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are not in synch?

TIA,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ISPF HILITE Question

2023-05-18 Thread Robert Prins 
On Thu, 18 May 2023 at 20:20, Steve Thompson  wrote:

> Or have I stumbled on a situation where ISPF and COBOL 6.x are
> not in synch?
>

This used to be the "normal" situation for PL/I, and with PL/I builtins
multiplying like rabbits, it may well be the case again. Ditto for COBOL...

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ISPF HILITE Question

2023-05-18 Thread Steve Thompson 
I have been chasing through a few IBM ISPF manuals and I am 
trying to figure out why, when HILITE is COBOL, certain words are 
"pink". Now I thought this was used to show a logic error, such 
as an "IF" with a missing "END-IF", or an extraneous "END-IF".


Where my curiosity/confusion is, is this:

COBOL has [intrinsic] FUNCTIONs. And I'm trying to make use of 
one, but it is getting colored pink. Could this be because ISPF 
doesn't know about new functions in COBOL? In this case it is 
"BYTE-LENGTH" (because I need to know at execution time what the 
size of the named label is -- "Depending on" is being used).


Could someone point me in the approximate correct direction?

Or have I stumbled on a situation where ISPF and COBOL 6.x are 
not in synch?


TIA,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN