Converting Cobol programs to pl/sql procedures or pakages
jmoore
converted to PL/sql procedures/packages? Our company is trying to
convert programs to pl/sql and they really haven't addressed many of
the challenges. First being batch programs that display/accept data
from the user. Our software runs thru a .net front end or batch
programs can be ran from a unix prompt. I have limited time to learn
this and other than reading books, I cuold use some great examples
that I could see what the Cobol program looks like and what the pl/sql
program lloks like. Even if it is a Cobol program that calls a
procedure would be great Any help would be greatly appreciated.
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
>Does anyone have any example code of Cobol programs that were
>converted to PL/sql procedures/packages? Our company is trying to
>convert programs to pl/sql and they really haven't addressed many of
>the challenges.
Depending on the application(s) involved and the data volume this can be a
moderately intricate task; there are Conversion Companies which have
entire divisions dedicated to just such efforts.
>First being batch programs that display/accept data
>from the user. Our software runs thru a .net front end or batch
>programs can be ran from a unix prompt. I have limited time to learn
>this and other than reading books, I cuold use some great examples
>that I could see what the Cobol program looks like and what the pl/sql
>program lloks like.
Let me get this straight... your company has given you an assignment to do
something that you have not yet learned and must complete in a very
limited time?
I would start by polishing up my resume and preparing to find another
employer. Without knowledge of both the (from) side and the (to) side the
likelihood of success is, in my experience, diminished.
DD
jmoore
> In article <43915d44-2d96-45d9-889a-f5b15f9ee...@y7g2000yqa.googlegroups.com>,
You got it straight and it is very ridiculous! They haven't really
ironed out all the pitfalls that go along with converting these
programs or the fact that it may not be as effiecient if they are
going to store everything in procedures/packages. Some genius thought
let's convert to PL/sql and that was it. I have been reading up on pl/
sql and have a few poor examples already done here. But, if they want
all cobol programs whether batch or online converted, I really could
use a good example of how to structure the pl/sql. Loops etc to handle
how Cobol is looping thru the table now and exceptions that would make
it go back and read the next record. Also, we have many sort
routines.
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
>On Jul 16, 2:48?pm, docdw...@panix.com () wrote:
[snip]
>> Let me get this straight... your company has given you an assignment to do
>> something that you have not yet learned and must complete in a very
>> limited time?
>>
>> I would start by polishing up my resume and preparing to find another
>> employer.
[snip]
>You got it straight and it is very ridiculous!
Sometimes I just guess lucky... now, get to polishing.
DD
jmoore
> In article <c211947d-80fb-4784-bbcb-93a48ea02...@k30g2000yqf.googlegroups.com>,
>
> jmoore <jmoore...@gmail.com> wrote:
> >On Jul 16, 2:48?pm, docdw...@panix.com () wrote:
>
> [snip]
>
> >> Let me get this straight... your company has given you an assignment to do
> >> something that you have not yet learned and must complete in a very
> >> limited time?
>
> >> I would start by polishing up my resume and preparing to find another
> >> employer.
>
> [snip]
>
> >You got it straight and it is very ridiculous!
>
> Sometimes I just guess lucky... now, get to polishing.
>
> DD
Anyone? Anyone? Bueler? Bueler?
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
>On Jul 16, 6:42?pm, docdw...@panix.com () wrote:
>> In article
><c211947d-80fb-4784-bbcb-93a48ea02...@k30g2000yqf.googlegroups.com>,
>>
>> >On Jul 16, 2:48?pm, docdw...@panix.com () wrote:
>>
>> [snip]
>>
>> >> Let me get this straight... your company has given you an assignment to do
>> >> something that you have not yet learned and must complete in a very
>> >> limited time?
>>
>> >> I would start by polishing up my resume and preparing to find another
>> >> employer.
>>
>> [snip]
>>
>> >You got it straight and it is very ridiculous!
>>
>> Sometimes I just guess lucky... now, get to polishing.
>
Oh, I *cannot* resist... I'm not sure... there aren't multiple consonants
or any -zy- combinations; Bueler would seem to be of more western-European
derivation...
... than one resulting from Polish-ing.
DD
jmoore
> In article <e299e138-392b-4659-9d37-d76fcc6a3...@z34g2000vbl.googlegroups.com>,
>
> - Show quoted text -
You seem to be the only one answering any posts in here. Clever as you
are with the whole polish-ing thing I could really use some feedback
from anyone else who has been through this ridiculous exercise of
moving from Cobol to PL-SQL.
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
>On Jul 28, 11:02?am, docdw...@panix.com () wrote:
>> In article
><e299e138-392b-4659-9d37-d76fcc6a3...@z34g2000vbl.googlegroups.com>,
>> >On Jul 16, 6:42?pm, docdw...@panix.com () wrote:
>> >> In article
>> ><c211947d-80fb-4784-bbcb-93a48ea02...@k30g2000yqf.googlegroups.com>,
>> >> jmoore ?<jmoore...@gmail.com> wrote:
>> >> >On Jul 16, 2:48?pm, docdw...@panix.com () wrote:
>>
>> >> [snip]
>>
>> >> >> Let me get this straight... your company has given you an assignment to do
>> >> >> something that you have not yet learned and must complete in a very
>> >> >> limited time?
[snip]
>> >> >You got it straight and it is very ridiculous!
[snip]
>You seem to be the only one answering any posts in here. Clever as you
>are with the whole polish-ing thing I could really use some feedback
>from anyone else who has been through this ridiculous exercise of
>moving from Cobol to PL-SQL.
The exercise is not necessarily ridiculous; a few of the folks posting
here, I believe, have some experience moving from a file-based system to a
table-based one. It is not a trivial thing to do and there are companies
which employ very experienced people to make sure the transition is
successful.
To entrust it to someone who knows little about it indicates - at least
according to my minimal experience - that Someone Important wants to see
it fail. Try not to take it personally.
DD
jmoore
> In article <4a1e8a66-23ba-4b04-94ad-0c33015e2...@q35g2000vbi.googlegroups.com>,
>
> - Show quoted text -
You may be right DD. or it may be just another assinine decision this
company is famous for. All I know is I want to get some experience
before our dept is thrown out the door. I think it would be awesome if
they hired someone experience moving from a file-based system to a
table-based one. That is why I came in here hoping to find someone who
may have some examples that might help me/us get started. Kind of hard
not to take it personally, when you have mouths to feed. I didn't come
in here to be a jerk, just looking for some help that's all.
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
>On Jul 28, 1:25?pm, docdw...@panix.com () wrote:
[snip]
>> The exercise is not necessarily ridiculous; a few of the folks posting
>> here, I believe, have some experience moving from a file-based system to a
>> table-based one. ?It is not a trivial thing to do and there are companies
>> which employ very experienced people to make sure the transition is
>> successful.
>>
>> To entrust it to someone who knows little about it indicates - at least
>> according to my minimal experience - that Someone Important wants to see
>> it fail. ?Try not to take it personally.
>
>You may be right DD. or it may be just another assinine decision this
>company is famous for. All I know is I want to get some experience
>before our dept is thrown out the door.
It is one thing to want experience, it is another thing to want someone to
part with the valuable skills and hard-earned lessons they've garnerd o'er
the long decades - and by which they earn their living - to part with it
for free.
>I think it would be awesome if
>they hired someone experience moving from a file-based system to a
>table-based one.
Until they do... they get what they pay for.
>That is why I came in here hoping to find someone who
>may have some examples that might help me/us get started.
I've tried to do just that but it seems to be in a direction other than
that which you expected. Funny how that works, especially with something
you don't know, eh?
>Kind of hard
>not to take it personally, when you have mouths to feed.
So do others here, if only their own.
DD
James J. Gavan
> On Jul 28, 1:25 pm, docdw...@panix.com () wrote:
>
>>In article <4a1e8a66-23ba-4b04-94ad-0c33015e2...@q35g2000vbi.googlegroups.com>,
<snip>
>
> You may be right DD. or it may be just another assinine decision this
> company is famous for. All I know is I want to get some experience
> before our dept is thrown out the door. I think it would be awesome if
> they hired someone experience moving from a file-based system to a
> table-based one. That is why I came in here hoping to find someone who
> may have some examples that might help me/us get started. Kind of hard
> not to take it personally, when you have mouths to feed. I didn't come
> in here to be a jerk, just looking for some help that's all.
jmoore,
Not sure if I have read you correctly, but do you know little or nothing
about SQL ?
Like any new activity in this game, you have got to do some reading. SQL
((R)DBMS or DBMS) is adequately covered by paperback texts; of course
you can always shell out for the expensive hard-cover tomes. Perhaps
some of those familiar can recommend texts that you should look at.
As regards syntax, go googling and you'll find interesting examples
which may appeal to your particular requirement. Surprisingly, a
PC-user, I found that the IBM site(s) have very good examples of SQL
syntax using COBOL. Granted it probably is all based on DB2 and some
'VERBs' you may not be able to use with your particular SQL Preprocessor
- nevertheless you can probably do a fair amount of 'cut and paste' from
their examples, obviously changing COBOL variable names.
Jimmy, Calgary AB
Pete Dashwood
Fair enough. But please understand that there is a time and a place for free
advice.
The problem here is that you have been asked to do something that your
company should be paying for, and some of the people in this forum are the
people who would be paid by them. Even with the kindest hearts in the world,
this one goes against the grain...:-)
Nevertheless, moved by your situation, I'll try and help.
If you know absolutely nothing about SQL you can learn it pretty quickly
from: http://www.w3schools.com/SQl/default.asp
By "quickly" I mean "in an afternoon" (Compared to other "languages", SQL
has a limited command set and derives its power from being able to be
recursively structured (that's what the "S" stands for in the name...)
PL/SQL is SQL on steroids. Once you have mastered the basic SQL, given you
have a programming background, the loop control and evaluations available in
PL/SQL shouldn't be too difficult.
In the same way any computer program can be decomposed into "sequence",
"evaluate" and "iterate" so PL/SQL has constructs to support all of these
functions.
Why not take a small COBOL program (with a simple record layout) and analyse
it along those lines, then apply the equivalent PL/SQL constructs and see
what you end up with? You said you want to get experience at this, I can see
no better way. If you tell your Boss you're doing a pilot "proof of concept"
that should get him off your back long enough for you to successfully
complete your first conversion.
Understand that there is a difference between the way in which flat files
and COBOL perceive data and the way the Relational Database (ORACLE or any
other) does. For your first cut, try and avoid a record layout that contains
OCCURS and REDEFINES. Fields defined as group levels in COBOL may or may
not be needed on the database, depending on whether they are referenced
frequently in code.
I have written at length about all of this and there are free articles you
can browse from the cobol21 web site. The ISAM to RDB page is still
incomplete, but there is a wealth of information on the PRIMA Toolset page.
(http://primacomputing.co.nz/cobol21/PRIMAToolset.aspx)
The "Pathway to Relational Database" document (click on the link just below
the image of the Arctic winter...) has full explanations and an appendix
that explains DB Normalization in very simple terms. I came to grips with
all of these problems when I was building tools to automate the conversion
from flat files to RDB, but whether you use the tools or not, the
explanations will, hopefully, be useful. (You might at least get enough
ammunition to persuade your employers that they need someone knowledgable to
assist with this, even if for a few days...) Once you have a fair grasp of
what is involved generally, conversion to PL/SQL becomes just a "special
case", where the RDB is "smarter" than would normally be the case.
Starting with no knowledge of RDB or SQL is not a good position to be in but
the task is not impossible. Give yourself a few days for "education" and
read avidly. There is a great deal of material available and part of the
difficulty is deciding what is relevant and what is not, for your particular
purposes.
I tried a quick GOOGLE using "COBOL to PL/SQL" and received over a million
hits, some of which looked very pertinent. There are companies who have
automated this process (much as I have done with standard RDB) and I'm sure
you can get the assistance you need, if your company is prepared to pay for
it.
Good Luck!
Pete.
--
"I used to write COBOL...now I can do anything."
Pete Dashwood
<snip>
> I have written at length about all of this and there are free
> articles you can browse from the cobol21 web site. The ISAM to RDB
> page is still incomplete, but there is a wealth of information on the
> PRIMA Toolset page.
> (http://primacomputing.co.nz/cobol21/PRIMAToolset.aspx)
The above link is correct but doesn't seem to work from within the post. It
may be the parentheses...
Try this...
http://primacomputing.co.nz/cobol21/PRIMAToolset.aspx
Pete
jmoore
I will check them all out! Thanks everyone for your help. We have been
embedded sql in alot of our cobol programs(Pro*Cobol), I think the
issue is how to do multiple cursors for or while loops etc. We have an
example program that does a sort and returns a report. The sort
basically takes table 1 reads until eof and then uses the mbrno to
read table 2 to get a few fields, then table 3 to get a few fields
releases the sort-rec and goes back to table 1. When done The return
reads sort and creates a report. We have many batch programs that do
this. I am keeping the cobol part to accept/display. I need to pass
the answers as variables to throw records away I do not need. I am
trying to figure out how to combine all 3 in the cursors and order by
the sort-key which is circuit and station then create the report all
inside a package or procedure. I have been reading pl/sql manuals
trying to figure out the best way to accomplish this. They seem to not
wnat us to use any temporary tables here. I know oracle has the utl-
file package and wasn't sure if I can use that. Maybe combine all the
cursors and do a hash group by. There are quite a few infastructure
issues that need to be worked out as well. Let me finish by saying I
really appreciate everyone's guidance here. I totally understand that
all of you have worked hard to attain your knowledge and to part with
it for free doesn't do you any favors. Unfortunately, with the job
market the way it is, I have to learn this fast. Without going into
detail the VP of development here has "farmed" out the pl/sql to India
and all of the sudden now the owner wants us to know it. So our whole
department, which has been promised to get training is now on its own.
There are alot of us who only know cobol here and I believe they
definitely want to get rid of Cobol. SO, DD you were right somebody
does want "us" to fail. But the "us" is the Cobol department. Pete,
James, DD thanks for your input! I wish I could go into more detail
about what is going on, but it wouldn't be politically correct.
jmoore
I bookmarked your site Pete!
docd...@panix.com
jmoore <jmoo...@gmail.com> wrote:
[snip]
>SO, DD you were right somebody
>does want "us" to fail.
I was right about something? Quick, someone mark the calendar.
DD
Pete Dashwood
Thank you. :-) (Always music to a Webmaster's ears... :-))
I hope you are able to get some benefit from looking at what's on it. I
REALLY need to get this site completed but I'm just too busy at the moment.
The next priority is the ISAM to RDB page and I hope to get onto finishing
that in a week or so. Most of the nitty-gritty material is already on the
Toolset page quoted above, but I have some more general "beginner
background" and some better pictures to add, which are quite independent of
the Toolset.
Pete.
ribjo
Moving COBOL with inline Oracle Pro*COBOL to PL/SQL is really
esoteric.
Since you and your company seem so lost, take what you know already
(Java, C#, C++, Ruby, ...) and make a proof of concept and change
"boss" minds.
Batch applications work best with COBOL, C++, Java, C# and PL/SQL is a
centralized resource or API for applications. How do you take a ISAM
file in PL/SQL and do operations with it?
How do you read/write BCD (decimal) in PL/SQL?
Is your PL/SQL code portable? What will you do when Oracle 12 breaks
your code?
Have you evaluated converting you COBOL code to Java packages inside
Oracle Database? That would make more sense to me.
Good luck
ponpart...@gmail.com
docd...@panix.com
In article <35db4fd5-effc-4f9b...@googlegroups.com>,
>On Friday, July 17, 2009 at 12:01:07 AM UTC+5:30, jmoore207 wrote:
>> Does anyone have any example code of Cobol programs that were
>> converted to PL/sql procedures/packages?
for the position(s) offered; to do otherwise leads many to conclude that
you are either trolling for resumes or running a blind ad to determine
rates.
DD
Bill Gunshannon
What position was he offering? He was asking for code samples.
Personally, I wouldn't waste the time answering as converting COBOL
to PL/SQL is a big step backwards and probably won't work out like
he thinks. That was one of the reasons I left my last COBOL gig.
Their plan was to do exactly that but here we are 4 years later and
they are still running the COBOL. Only thing that changed is they
lost me. :-)
bill
docd...@panix.com
>On 6/10/16 10:53 AM, docd...@panix.com wrote:
>> [posted and emailed]
>>
>> In article <35db4fd5-effc-4f9b...@googlegroups.com>,
>> <ponpart...@gmail.com> wrote:
>>> On Friday, July 17, 2009 at 12:01:07 AM UTC+5:30, jmoore207 wrote:
>>>> Does anyone have any example code of Cobol programs that were
>>>> converted to PL/sql procedures/packages?
>>
>> When posting to comp.lang.cobol please include a rate, or range of rates,
>> for the position(s) offered; to do otherwise leads many to conclude that
>> you are either trolling for resumes or running a blind ad to determine
>> rates.
>>
>> DD
>>
>
>Huh?
>What position was he offering? He was asking for code samples.
reading was "this is stuff that requires a seasoned Professional Coder
that my bosses have dumped into my lap with a cheery 'all ya gotta do
is...' and now I'm trying to find someone to Do My Job."
Thence came the conclusion of "need someone to do a job? please post a
rate (etc)".
>Personally, I wouldn't waste the time answering as converting COBOL
>to PL/SQL is a big step backwards and probably won't work out like
>he thinks. That was one of the reasons I left my last COBOL gig.
>Their plan was to do exactly that but here we are 4 years later and
>they are still running the COBOL. Only thing that changed is they
>lost me. :-)
annelids which might be drenched.
DD
robin....@gmail.com
mohamm...@gmail.com
docd...@panix.com
Bill Gunshannon
As of today, they are still running the COBOL. That should give
you a hint at just how daunting the task you are looking at is.
bill
pete dashwood
My company specializes in migrating COBOL code to different platforms
and environments.
We have established ourselves (after numerous successful migrations) as
a Centre of Competence for this type of exercise.
Please pass the following comments on to the people who are asking you
to do this (your Bosses...)
1. PL/SQL blocks consist of 3 parts. To convert COBOL, the Declarative
part and the Executable part would need to contain DATA and PROCEDURE
code EQUIVALENTS from the COBOL source. (The third part handles
exceptions and these would also need to contain the COBOL equivalent code.)
That means that each COBOL source program would need to be deconstructed
into the necessary parts, and then Transformed from COBOL source into
PL/SQL equivalence.
To do this manually would be an overwhelming task. It will require
facility with both COBOL AND ORACLE PL/SQL. It is feasible if you have
only a few COBOL programs, but for a full migration it would be foolish
to undertake this, even if you have people with the required skills. If
it is done manually the process will be extremely lengthy and very error
prone.
2. You COULD build some tools to help you automate it, but I can't see
them being built in PL/SQL... (You would need COBOL and/or C# or C++)
This does not perpetuate the use of COBOL because these would be
"throwaway" tools once the migration was complete.
Our Company (https://primacomputing.co.nz) has built many tools like
this over the years but we have nothing currently that will transform
COBOL to PL/SQL. (We could build it, but it would be costly and it would
take considerable time (months rather than weeks...)) However, if you
have hundreds of programs, this is the way you need to go, whether you
get us to help you, or whether you do it yourselves.
3. A "composite" approach could be viable where you break the existing
COBOL into object Classes and invoke those Classes from PL/SQL
procedures (using the Executable part of the block). However, this will
not remove the requirement to do COBOL maintenance. It does give you the
chance to gradually phase out the COBOL, rather than trying a Big Bang
Migration, which could be disastrous. New development could be in PL/SQL
while the legacy continues to run as COBOL, managed from PL/SQL procedures.
We have tools that can automate the conversion of existing COBOL code
into objects that can be invoked. (From PL/SQL or COBOL or C#/VB.Net or
indeed, anything that implements a COM interface. (ORACLE has support
for COM)
BOTTOM LINE:
There is no easy or "silver bullet" solution to bringing COBOL legacy
into PL/SQL, and you should think very carefully before undertaking it.
PL/SQL is really like an ORACLE implementation of LINQ, that seeks to
overcome the "impedance mismatch" between DB access and normal code by
integrating the two. PL/SQL goes further than LINQ and can be considered
a development language in its own right. However, it is a modern
language and may not do well with legacy.
Personally, I would not try to write my systems only in LINQ, any more
than I would try to do so in PL/SQL. Even though LINQ is superb for
managing data, it is intended only for that; PL/SQL is intended to be a
standalone language that can be easily driven from ORACLE DBs.
When doing new development you have more control over the architecture
and can decide to make your Classes "PL/SQL friendly" for example, but
with legacy conversion you do not have this luxury and your existing
COBOL legacy is unlikely even to be Object Oriented.
Both PL/SQL and LINQ are superior (over standard SQL) ways to access
relational data but there is surprisingly more to developing systems
than just accessing databases...
PL/SQL is one basket I would definitely NOT throw all my eggs into, and
especially not if some of those eggs involved COBOL legacy...
Pete.
--
I used to write COBOL; now I can do anything...
docd...@panix.com
>On 27/02/2018 1:10 PM, mohamm...@gmail.com wrote:
>> On Thursday, July 16, 2009 at 2:31:07 PM UTC-4, jmoore207 wrote:
[snip]
>> I am also facing same task which need to be convert Cobol programs to
>PL/SQL, Please Help me out If some has did before. Thank You
>>
[snip]
>BOTTOM LINE:
>
>There is no easy or "silver bullet" solution to bringing COBOL legacy
>into PL/SQL, and you should think very carefully before undertaking it.
the early-mid 1980s. If a company is assigning a new hire to 'search that
internet' for these questions now it seems that little has been learned.
DD
pete dashwood
> In article <ffmoat...@mid.individual.net>,
> pete dashwood <dash...@enternet.co.nz> wrote:
>> On 27/02/2018 1:10 PM, mohamm...@gmail.com wrote:
>>> On Thursday, July 16, 2009 at 2:31:07 PM UTC-4, jmoore207 wrote:
>
> The date of the original posting might tell a tale, Mr Dashwood.
dated. The post I responded to was current and a few days old.
> [snip]
>
>>> I am also facing same task which need to be convert Cobol programs to
>> PL/SQL, Please Help me out If some has did before. Thank You
>>>
>
> The amount of 'own work shown' might tell another tale.
expect to see "own work done" if it was a homework question. This was
not in that category, as far as I am concerned; it is someone being
tasked to do something by people who know no better.
> [snip]
>
>> BOTTOM LINE:
>>
>> There is no easy or "silver bullet" solution to bringing COBOL legacy
>> into PL/SQL, and you should think very carefully before undertaking it.
>
> Mr Dashwood, some folks posting here have been saying such things since
> the early-mid 1980s. If a company is assigning a new hire to 'search that
> internet' for these questions now it seems that little has been learned.
number of years, it is pretty obvious that nothing has been learned, or
the previous dire warnings were not persuasive enough.
It is not enough to say: "Don't do it." NOT doing it may not be an
option, and it is certainly not impossible to do.
A quick outline of WHY you should hesitate is required and it should
come from a source that is demonstrably competent with both COBOL and
PL/SQL.
(Having a vested interest in the retention of COBOL because you are a
COBOL programmer, for example, does not really offer a credible opinion.)
Some options were provided and the general advice was not to attempt it
without writing tools to do it, if the migration is large.
This is sound and unbiased advice, based on actual experience with
migrating COBOL to various database systems and languages.
However, it will not be what the poster or his Bosses want to hear and
so it will therefore also probably be ignored...
If someone asks for help, it is a matter for each of us to decide how
much help they will receive before invoices are raised. I'm happy to
spend 10 minutes off the clock in view of the help I have received over
the years...
docd...@panix.com
>On 1/03/2018 2:10 PM, docd...@panix.com wrote:
>> In article <ffmoat...@mid.individual.net>,
>> pete dashwood <dash...@enternet.co.nz> wrote:
>>> On 27/02/2018 1:10 PM, mohamm...@gmail.com wrote:
>>>> On Thursday, July 16, 2009 at 2:31:07 PM UTC-4, jmoore207 wrote:
>>
>> The date of the original posting might tell a tale, Mr Dashwood.
>
>I was not responding to the original post and am aware of when it was
>dated.
DD
pete dashwood
docd...@panix.com
>On 2/03/2018 4:15 PM, docd...@panix.com wrote:
>> In article <ffrbnd...@mid.individual.net>,
>> pete dashwood <dash...@enternet.co.nz> wrote:
>>> On 1/03/2018 2:10 PM, docd...@panix.com wrote:
>>>> In article <ffmoat...@mid.individual.net>,
>>>> pete dashwood <dash...@enternet.co.nz> wrote:
>>>>> On 27/02/2018 1:10 PM, mohamm...@gmail.com wrote:
>>>>>> On Thursday, July 16, 2009 at 2:31:07 PM UTC-4, jmoore207 wrote:
>>>>
>>>> The date of the original posting might tell a tale, Mr Dashwood.
>>>
>>> I was not responding to the original post and am aware of when it was
>>> dated.
>>
>> What tale did the date tell you, Mr Dashwood?
>>
DD