Convert MainFrame Data [ EBCDIC ] To Ascii
Jim George
I have EBCDIC data from an IBM Mainframe which I need to convert to
ASCII Format.
I have managed to convert the remaining data into the proper format
but am stuck due to COMP-3.
There are fields as follows:
Seq Dt S9(7)
Seq Period X(2)
both of which are in a group.
How do i convert them into ASCII format ?
Any help is truly appreciated.
Thanks
Jim
Binyamin Dissen
:>I have EBCDIC data from an IBM Mainframe which I need to convert to
:>ASCII Format.
:>I have managed to convert the remaining data into the proper format
:>but am stuck due to COMP-3.
:>There are fields as follows:
:>Seq Dt S9(7)
:>Seq Period X(2)
:>both of which are in a group.
:>How do i convert them into ASCII format ?
1. X(2) is probably not COMP-3 (if it is, shoot the programmer).
2. COMP cannot be converted to ascii - it must be shipped as it. If you wish
to ship the data as ascii, write a program that copies the numerics to USAGE
DISPLAY fields and ship the expanded records.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Colin Campbell
not specially encoded data.
The wise course is to write a super simple program on the mainframe. It will use
the COPY member that describes the original data (you do use COPY members for all
files, right?), and a modified version of the COPY member where all of the data is
in character format. The numeric fields, if they require a sign, should be
described as SIGN TRAILING SEPARATE. (You could also use a Numeric Edited PICture
string for the output numeric fields if you prefer.) The program reads an input
record, moves each elementary item to the output record (CORRESPONDING will work),
and writes the output record.
Transmit the output to the ASCII platform, and you're done. No nasty surprises,
no errors.
Just another application of the KISS principle.
WOB
EBCDIC DISPLAY-NUMERIC with a SIGN LEADING SEPARATE, followed by the
conversion to ASCII. By doing so, you'll save yourself a bunch of grief.
If you KNOW the date-value will ALWAYS be positive, then you won't need the
separate sign-field.
As far as the other field, that can be converted asis.
Bill
"Jim George" <va_bal...@rediffmail.com> wrote in message
news:45147cf3.0303...@posting.google.com...
Michael Mattias
> I have EBCDIC data from an IBM Mainframe which I need to convert to
> ASCII Format.
Tutorial on exactly this subject:
http://www.providerpaymentpartner.com/tsihome_html/downloads/C2IEEE.htm
--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmat...@talsystems.com
(Author of same)
Robert Wagner
>I agree with Binyamin. Both EBCDIC and ASCII are intended to handle
characters,
>not specially encoded data.
>
>The wise course is to write a super simple program on the mainframe. It will
use
>the COPY member that describes the original data (you do use COPY members for
all
>files, right?), and a modified version of the COPY member where all of the data
is
>in character format. The numeric fields, if they require a sign, should be
>described as SIGN TRAILING SEPARATE. (You could also use a Numeric Edited
PICture
>string for the output numeric fields if you prefer.) The program reads an
input
>record, moves each elementary item to the output record (CORRESPONDING will
work),
>and writes the output record.
>
>Transmit the output to the ASCII platform, and you're done. No nasty
surprises,
>no errors.
>
>Just another application of the KISS principle.
No, the KISS principle says create the file in portable format in the first
place. Then, when someone calls to ask where he can get your file, you respond
'it's on server X at \dir'. Seconds later, he has it
It works a lot better than saying, 'I'll have to write a program to export it.'
Robert Wagner
>Regarding the COMP-3 (PACKED-DECIMAL) date-field, convert the value to
>EBCDIC DISPLAY-NUMERIC with a SIGN LEADING SEPARATE, followed by the
>conversion to ASCII. By doing so, you'll save yourself a bunch of grief.
>
>If you KNOW the date-value will ALWAYS be positive, then you won't need the
>separate sign-field.
Dates should never have been comp-3. They are not algebraic variables. You
cannot add 1 to a date. So why represent them as comp-3? Just to save space?
Why would dates not be postitive? Are BC dates negative? I doubt your
application deals with BC dates.
This is fuzzy thinking between mathematical variables and 'fields which happen
to contain numbers', such as SSN, ZIP code and part number. The former might
reasonably be packed, but not the latter.
Richard Plinston
> No, the KISS principle says create the file in portable format in the
> first place. Then, when someone calls to ask where he can get your file,
> you respond
>
> 'it's on server X at \dir'. Seconds later, he has it
(referring back to argument about C-ISAM files that you wrongly claimed
were ASCCI text files).
4 hours later he is complaining that he has wasted an afternoon with it as
it also contains records he had deleted in the application and doesn't have
some new records and there are blocks of junk data.
And that is just if it was MF C-ISAM or Level II. With IDXFORMAT"3" or
Fujitsu ISAM he would at least not even been able to make a start.
docd...@panix.com
Robert Wagner <rob...@wagner.net> wrote:
>"WOB" <wobco...@sprynet.com> wrote:
>
>>Regarding the COMP-3 (PACKED-DECIMAL) date-field, convert the value to
>>EBCDIC DISPLAY-NUMERIC with a SIGN LEADING SEPARATE, followed by the
>>conversion to ASCII. By doing so, you'll save yourself a bunch of grief.
>>
>>If you KNOW the date-value will ALWAYS be positive, then you won't need the
>>separate sign-field.
>
>Dates should never have been comp-3. They are not algebraic variables. You
>cannot add 1 to a date.
Mr Wagner, this is wrong in that it is clearly contradicted by the
capabilities provided by ANSI SQL; it is further contradicted by the
experiences of anyone who has performed arithmetic operations on Julian
dates.
DD
Howard Brazee
On 25-Mar-2003, rob...@wagner.net (Robert Wagner) wrote:
> Dates should never have been comp-3. They are not algebraic variables. You
> cannot add 1 to a date. So why represent them as comp-3? Just to save space?
Depends on the date format. I have often done arithmetic with dates.
> Why would dates not be postitive? Are BC dates negative? I doubt your
> application deals with BC dates.
I have seen some dates stored as a number of days since a company started.
Spreadsheets do something similar since around 100 years ago.
> This is fuzzy thinking between mathematical variables and 'fields which happen
> to contain numbers', such as SSN, ZIP code and part number. The former might
> reasonably be packed, but not the latter.
Agreed. These examples should always be PIC X( ).
Does anybody use PIC A()????
Robert Wagner
Richard
> >> No, the KISS principle says create the file in portable format in the
> >> first place. Then, when someone calls to ask where he can get your file,
> >> you respond
> >>
> >> 'it's on server X at \dir'. Seconds later, he has it
> >4 hours later he is complaining that he has wasted an afternoon
> You give him a flat file created by your last reorg.
Ohh, so you give him an _old_ version of the data that may be last
month's,
or even months ago.
Actually I don't have a 'flat file from the last reorg', That implies
that there is a two pass mechanism. I build a new indexed file from
the data file of the original and then rename the old files to some
junk name, rename the new file to the actual file name and delete the
junk names.
This runs faster and is (IMHO) less prone to failures. If there are
any fails then one is left with the original file unchanged or all
files have the wrong name (but still exists).
A copy to flat file and back to the original file may fail while
writing back and could leave the file incomplete.
Robert Wagner
>>Dates should never have been comp-3. They are not algebraic variables. You
>>cannot add 1 to a date.
>
>Mr Wagner, this is wrong in that it is clearly contradicted by the
>capabilities provided by ANSI SQL; it is further contradicted by the
>experiences of anyone who has performed arithmetic operations on Julian
>dates.
Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
date, 1 with a machine instruction. Nor can you add 1 to a 'julian' date without
a lot of overhead involving leap years.
Julius Caesar is dishonored by associating such a lousy date format with his
name. The difference between his calendar and Pope Gregory's has nothing to do
with format. It involves 365 days per year (julian) vs leap years and 365.24
days per year (gregorian).
Romans never wrote dates as 95001. That's something mediocre programmers dreamed
up and named 'julian'.
Robert Wagner
>Does anybody use PIC A()????
No. I think it's designated Archaic in the 2002 standard, meaning it's scheduled
for deletion on the next round.
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>
>> >> No, the KISS principle says create the file in portable format in the
>> >> first place. Then, when someone calls to ask where he can get your file,
>> >> you respond
>> >>
>> >> 'it's on server X at \dir'. Seconds later, he has it
>
>> >4 hours later he is complaining that he has wasted an afternoon
>
>> You give him a flat file created by your last reorg.
>
>Ohh, so you give him an _old_ version of the data that may be last
>month's,
>or even months ago.
Such requests are usually for testing format compatibility, or for reference
files which don't often change. If he needs a current version, I say "give me
five minutes to reorg it".
>Actually I don't have a 'flat file from the last reorg', That implies
>that there is a two pass mechanism. I build a new indexed file from
>the data file of the original and then rename the old files to some
>junk name, rename the new file to the actual file name and delete the
>junk names.
>
>This runs faster and is (IMHO) less prone to failures. If there are
>any fails then one is left with the original file unchanged or all
>files have the wrong name (but still exists).
>
>A copy to flat file and back to the original file may fail while
>writing back and could leave the file incomplete.
You should leave the original with its original name until the reorg is
successful. When the reorg finishes without error, THEN rename the original to
junk and the new version to the original name.
Granted, a two pass process is slower. But its by-product is a flat file. It
would be helpful to have two reorg scripts. If you live in an isolated world,
use .idx to .idx as your default. If you live in my world, where such calls are
frequent, use two pass as your default.
Richard Plinston
> Such requests .. If he needs a current version, I say "give me
> five minutes to reorg it".
My systems actually have users, usually all the working hours, and while
the file is in use it cannot be 'reorged' as this requires exclusive access.
Obviously your files have nothing better to do.
Which brings the argument back around to doing an extract in shared mode
while others are using the file. For this my 'report writer' sub-system
can, from a script, select appropriate records and export them to printed
report, CSV file, flat file, or HTML tables as required.
There isn't much point is retaining an old reorg flat file when the user
can extract exactly what he wants.
>> I build a new indexed file from
>> the data file of the original and then rename the old files to some
>> junk name, rename the new file to the actual file name and delete the
>> junk names.
> You should leave the original with its original name until the reorg is
> successful. When the reorg finishes without error, THEN rename the
> original to junk and the new version to the original name.
In what way isn't this what I said I was doing ?
> Granted, a two pass process is slower. But its by-product is a flat file.
> It would be helpful to have two reorg scripts. If you live in an isolated
world ...
I live in a world where the users get a system that gives them what they
want.
> If you live in my world, where such calls are frequent, use two pass as
> your default.
Now why would you get frequent requests for copies of your data files ? Is
it because they need to load them up into a database or spreadsheet to
shake out smoe information ?
If the system provided the view of the data they require then they don't
need to piss around with copies of the files.
Michael Mattias
news:3e826bad....@news.optonline.net...
FWIW you can always use..
IF "PIC X() item" IS [NOT] ALPHABETIC ...
I think some compilers offer 'out of the box' ALPHABETIC-UPPER and
ALPHABETIC-LOWER; but if not, you can always create these with:
SPECIAL-NAMES .
CLASS ALPHABETIC-UPPER IS 'A' THRU 'Z'. <<< ASCIII charset only,
for EBCDIC specify ranges.
CLASS ALPHABETIC-LOWER IS 'a' THRU 'z'. ditto
(that's close)
MCM
Donald Tees
> You should leave the original with its original name until the reorg is
> successful. When the reorg finishes without error, THEN rename the
original to
> junk and the new version to the original name.
>
> Granted, a two pass process is slower. But its by-product is a flat file.
It
> would be helpful to have two reorg scripts. If you live in an isolated
world,
> use .idx to .idx as your default. If you live in my world, where such
calls are
> frequent, use two pass as your default.
>
I use Isam a lot, as I write systems to run in isolation, and in remote
settings. They are easy to use, included in my compiler, and I am familiar
with them.
Nevertheless, I have a standard OOP object that manages each Isam file, and
simply gets stuck in at the design level, (takes five minutes of
programming). It has re-organization, index recovery, and dumping to
various formats built in. All backups are done at the line sequential
level.
Donald
Donald Tees
in building alphabetic class OOP objects.
Donald
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e826bad....@news.optonline.net...
SkippyPB
enlightened us:
I will say your incorrect facts must mean you have an active
imagination.
Juliun days, which is still used by astronomers, is based on the
number of days that have elapsed since noon universal time (UT), 1
January 4713 BCE (before current era, or B.C.); for example, 1 January
1996 CE (current era, or A.D.) is equivalent to Julian day 2,450,084.
And by the way, this system was named after Julius Caesar, but not the
one who ruled Rome and was assassinated by Brutus and others.
In ancient Rome before 45 BCE, for example, the civil year was 355
days, with an extra or intercalary month (Intercalaris), inserted
after Februarius every two years, but there was no rule to determine
the length of this month. Officials before Julius Caesar varied the
number of days in it, either for prolonging office terms, speeding up
election dates, or through sheer incompetence. By Caesar's time spring
equinox was falling in winter.
Sosigenes, the Greek astronomer, advised Julius Caesar on how to
correct this problem. So, on 1 January 45 BCE Caesar decreed that the
next year would be 445 days long. Contemporaries dubbed it the "year
of confusion", although its purpose was to end confusion. The new
Julian calendar was based on the solar year of 365 days, with an extra
day every fourth year. The intercalary month was eliminated, and every
other month, starting with January, would have 31 days. Other months,
except February, would have 30 days. February would have 29, and 30 in
leap years.
Two years later Julius got knifed, but his calendar ticked along until
7 BCE, when it was interfered with during the reign of Augustus. The
fifth month, Quintilis (the year started with the spring equinox, in
Martius, or March), which had been renamed Julius (our July) after the
deceased Caesar, had 31 days. Augustus, or the Roman Senate, wanted a
month named after the emperor, so the next month, Sextilis, with 30
days, was changed to Augustus, and given the same number of days as
Julius. The extra day was taken from the final month, Februarius. This
alteration left three months together, July, August, and September
each with 31 days, contrary to logical alternating 31/30-day months of
Sosigenes. To remedy this, September and November lost their 31st days
to October and December. That's why we have to remember "thirty days
hath September ..."
To make matters worse, after Julius died, the leap year was being
added every third, instead of every fourth, year. Augustus put a stop
to this by eliminating leap years from about 5 BCE to 8 CE (A.D.).
However, the Julian calendar year was 11 minutes, 4 seconds longer
than the solar year. By 1582, this error has accumulated to 10 days,
so the spring equinox (and consequently the Christian celebration of
Easter), was falling about 11 March. To correct this anomaly Pope
Gregory XIII, on the advice of his astronomers, took drastic action
and decreed that 15 October 1582 would immediately follow 4 October,
thus eliminating 10 days forever. To prevent the calendar from getting
out of phase with the seasons again, he decreed that years ending in
00 would be 365 days long unless evenly divisible by 400.
When you say a date like 96362 (year XX, number of days passed in the
year XXX) is a Julian date, that is not correct. In fact it is a
Gregorian Date expressed as number of days in the year. This is a
grossly misleading practice that was introduced by some who were
simply ignorant and too careless to learn the proper terminology. It
creates a confusion which should not be taken lightly. Moreover, a
continuation of the use of expressions "Julian" or "J" day in the
sense of a Gregorian Date will make matters even worse.
The Romans used to count years from the (mythical) year of the
founding of the city of Rome in year -751 of the Common Era. They
referred to a year count in the era as Ab Urbe Condita ("since the
founding of the City"), abbreviated to A.U.C. However, our Latin
calendar uses the same era as the Common calendar. The year number is
introduced by the word "Anno" (year). As an example of a complete
date, the 15th of December of 1965 is referred to as "Ante Diem XVIII
Kalendas Ianuarias Anno MCMLXVI", which translates loosely as "The
18th inclusive day before the Kalends of January of the year 1966".
Just an F.Y.I.
Regards,
////
(o o)
-oOO--(_)--OOo-
Micro$oft Haiku Error Message #111
The Tao that is seen
Is not the true Tao - until
You bring fresh toner.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Howard Brazee
On 26-Mar-2003, rob...@wagner.net (Robert Wagner) wrote:
> >>Dates should never have been comp-3. They are not algebraic variables. You
> >>cannot add 1 to a date.
> >
> >Mr Wagner, this is wrong in that it is clearly contradicted by the
> >capabilities provided by ANSI SQL; it is further contradicted by the
> >experiences of anyone who has performed arithmetic operations on Julian
> >dates.
>
> Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
> date, 1 with a machine instruction. Nor can you add 1 to a 'julian' date
> without a lot of overhead involving leap years.
Sure you can. You can also add 1 to dates stored in spreadsheet programs.
With a little work you can add 1 to just about any date format - and there are
reasons to do so. What do you do if you want to check if a date is within 30
days of another date? Or are you saying that this isn't a valid business need?
> Julius Caesar is dishonored by associating such a lousy date format with his
> name. The difference between his calendar and Pope Gregory's has nothing to do
> with format. It involves 365 days per year (julian) vs leap years and 365.24
> days per year (gregorian).
So who is associating Julius Caesar with Julian dates besides you? How much
honor did Caesar have before you made that association, and how much was his
honor reduced by such an association?
> Romans never wrote dates as 95001. That's something mediocre programmers
> dreamed up and named 'julian'.
Can you name one of these mediocre programmers? Was one of these mediocre
programmers Joseph Justus Scaliger?
Note: IBM's "Julian date" isn't the same thing as real julian dates, but was
designed to save space. Programmers would have preferred the original Julian
dates.
Howard Brazee
On 27-Mar-2003, SkippyPB <swie...@neo.NOSPAM.rr.com> wrote:
> Two years later Julius got knifed, but his calendar ticked along until
> 7 BCE, when it was interfered with during the reign of Augustus. The
> fifth month, Quintilis (the year started with the spring equinox, in
> Martius, or March), which had been renamed Julius (our July) after the
> deceased Caesar, had 31 days. Augustus, or the Roman Senate, wanted a
> month named after the emperor, so the next month, Sextilis, with 30
> days, was changed to Augustus, and given the same number of days as
> Julius. The extra day was taken from the final month, Februarius. This
> alteration left three months together, July, August, and September
> each with 31 days, contrary to logical alternating 31/30-day months of
> Sosigenes. To remedy this, September and November lost their 31st days
> to October and December. That's why we have to remember "thirty days
> hath September ..."
Which leaves us with months named sep, oct, non, & dec being the 9th, 10th,
11th, & 12th month of the year.
Of course Christmas = Halloween (Dec 25 = Oct 31)
docd...@panix.com
Robert Wagner <rob...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>>Dates should never have been comp-3. They are not algebraic variables. You
>>>cannot add 1 to a date.
>>
>>Mr Wagner, this is wrong in that it is clearly contradicted by the
>>capabilities provided by ANSI SQL; it is further contradicted by the
>>experiences of anyone who has performed arithmetic operations on Julian
>>dates.
>
>Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
>date, 1 with a machine instruction.
This was not your original assertion, Mr Wagner; your original assertion
was 'you cannot add 1 to a date'. Is it your habit to change assertions
when you are shown to be wrong?
>Nor can you add 1 to a 'julian' date without
>a lot of overhead involving leap years.
This is not your original assertion either, Mr Wagner; your original
assertion said nothing about using a particular instruction or 'overhead'
and addressed only the activity of addition. Is it your habit to change
assertions when you are shown to be wrong?
>
>Julius Caesar is dishonored by associating such a lousy date format with his
>name. The difference between his calendar and Pope Gregory's has nothing to do
>with format. It involves 365 days per year (julian) vs leap years and 365.24
>days per year (gregorian).
Quite fascinating to some, I am sure, Mr Wagner, but completely extraneous
to your assertion that 'you cannot add 1 to a date'... which is, by the
way, wrong.
>
>Romans never wrote dates as 95001. That's something mediocre programmers dreamed
>up and named 'julian'.
Mr Wagner, while it might be true that Romans never wrote dates in modern
Arabic numerals a bit of research brought me to
http://www.sizes.com/time/dayJulianr.htm ; this states that Scalinger
named a system of dating 'Julian' after the Julian year (Book V (intro
section) of De Emendatione Temporum, 1583AD/ACE).
Do you have any sort of documentation you might be able to present to
support your assertion about 'mediocre programmers' or shall 'making
things up, whole cloth' be added to the tactic of 'changing assertions
when shown to be wrong'?
DD
William M. Klein
As usual RW was in error (but at least he did qualify his statement with "I
think it's ...")
Neither PIC nor the alphabetic category is archaic in the 2002 Standard.
(In fact, it has "added" usefulness with the VALIDATE statement)
--
Bill Klein
wmklein <at> ix.netcom.com
"Donald Tees" <Donal...@sympatico.ca> wrote in message
news:SQCga.5448$062.8...@news20.bellglobal.com...
William M. Klein
Neither PIC A nor the alphabetic category is archaic in the 2002 Standard.
(In fact, PIC A has "added" usefulness with the VALIDATE statement)
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@ix.netcom.com> wrote in message
news:b5ve07$5to$1...@slb2.atl.mindspring.net...
Chuck Stevens
> You cannot add 1 to a date.
Maybe YOU can't. But I'm laboring under the impression that *I* can.
So far as I know, the following ought to work with any COBOL compiler
claiming compliance to the '85 standard (as the intrinsic functions
amendment was incorporated into it):
000100 IDENTIFICATION DIVISION.
000200 ENVIRONMENT DIVISION.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 01 MY-DATE PIC 99999999 PACKED-DECIMAL VALUE 20021231.
000600 01 MY-DAY PIC 9999999 PACKED-DECIMAL VALUE 2002365.
000700 PROCEDURE DIVISION.
000800 MAIN-PARAGRAPH.
000900 COMPUTE MY-DATE =
001000 FUNCTION DATE-OF-INTEGER
001100 (FUNCTION INTEGER-OF-DATE (MY-DATE) + 1)
001200 COMPUTE MY-DAY =
001300 FUNCTION DAY-OF-INTEGER
001400 (FUNCTION INTEGER-OF-DAY (MY-DAY) + 1)
001500 DISPLAY MY-DATE
001600 DISPLAY MY-DAY
001700 STOP RUN.
This of course presumes that MY-DATE and MY-DAY are encoded in YYYYMMDD and
YYYYDDD formats respectively. I would expect the new contents of these
fields to be 20030101 and 2003001 respectively.
I will acknowledge that this mechanism does not appear to support handling
of any dates from December 31, 1600 and before, but I would hazard the
comment that the ability to do arithmetic on dates from before the early
seventeenth century is not something for which either my company as a
compiler vendor or I as a member of J4 have had hordes of users clamoring.
The user doesn't need to be concerned about USER CODE overhead involving
leap years; how the compiler implementor provides for it may entail "a lot
of overhead" or it may not.
-Chuck Stevens
Rick Smith
PIC A has not been designated 'archaic.'
In any case, items designated 'archaic' are not scheduled
for removal from the standard. Those items designated
'obsolete' are to be removed with the next edition of the
standard. PIC A has not been designated 'obsolete',
either.
In previous discussions, in this newsgroup, some have
stated they do use PIC A and some have found no use.
One such discussion was:
<
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=956L1.1742%24te.2
584561%40news2.mia.bellsouth.net&rnum=3&prev=/groups%3Fq%3Dalphabetic%2B%252
2PIC%2BA%2522%2Bgroup%253Acomp.lang.cobol%26hl%3Den%26lr%3D%26ie%3DISO-8859-
1 >
Chuck Stevens
"William M. Klein" <wmk...@ix.netcom.com> wrote in message
news:b5ve07$5to$1...@slb2.atl.mindspring.net...
> Neither PIC nor the alphabetic category is archaic in the 2002 Standard.
> (In fact, it has "added" usefulness with the VALIDATE statement)
in response to Robert Wagner's comment
> No. I think it's designated Archaic in the 2002 standard, ...
Bill's right on both points, but I think he missed something.
> meaning it's scheduled for deletion on the next round.
uhhh ... no ... I don't think Mr. Wagner's been accurate here ...
"There is no plan for the removal of archaic elements; however, should their
use in program inventories become insignificant, they may be considered for
designation as obsolete by future architects of standard COBOL." (ISO/IEC
1989:2002 Page 833, Annex G, Archaic and obsolete language element lists,
Section G.1, Archaic language elements, second paragraph).
There are five ARCHAIC features in the 2002 COBOL standard: continuation
of COBOL words; MOVE of alphanumeric constants to numeric items; NEXT
SENTENCE in IF and SEARCH; ON OVERFLOW in CALL; and identifiers (as distinct
from delimited text) in COPY ... REPLACING.
"Obsolete language elements are elements that will be removed in the next
edition ..." (ISO/IEC 1989:2002 Page 834, Annex G, Archaic and obsolete
language element lists, Section G.2, Obsolete language elements, first
paragraph).
There are three OBSOLETE elements in the 2002 COBOL standard: the
communications facility; debugging lines and the DEBUGGING MODE clause; and
the PADDING CHARACTER clause.
-Chuck Stevens
Richard
> Julius Caesar is dishonored by associating such a lousy date format with his
> name.
The Julian date or day number system was named after Joseph Scaliger's
father, Julius Caesar Scaliger (actually this is not certain), and had
nothing to do with Julius Caesar or the Julian Calendar.
> The difference between his calendar and Pope Gregory's has nothing to do
> with format. It involves 365 days per year (julian) vs leap years and 365.24
> days per year (gregorian).
The Julian Calendar also had leap years. Mostly they were every 4
years as we have now. The Gregorian Calendar introduced the 100 and
400 year rules plus some adjustment.
> Romans never wrote dates as 95001. That's something mediocre programmers
> dreamed up and named 'julian'.
Romans never even used '9' '5' or '1', and certainly not '0'. They
never used a Julian Date, The Julian Calendar, which is a completely
different thing, was named after Julius Caesar becasue it followed his
mechanism of leap years.
A Julian date is a day number since a theoretical 4173 BC which is
currently around 2452720. The format of yy nnn is not a Julian Date
and has nothing to do with the Julian Calendar. It happens to save
space, which was very important when computers had 16K memory and 4Mb
14 inch disks, it was only 5 digits instead of 6 and this fitted into
Packed as 3 bytes.
For your '40 years experience' you've not learnt much that is true.
Howard Brazee
On 27-Mar-2003, "Chuck Stevens" <charles...@unisys.com> wrote:
> There are three OBSOLETE elements in the 2002 COBOL standard: the
> communications facility; debugging lines and the DEBUGGING MODE clause; and
> the PADDING CHARACTER clause.
Oh shoot. I use the DEBUGGING MODE all the time. At least fixes will be easy.
Ed Guy
> Hi!
> I have EBCDIC data from an IBM Mainframe which I need to convert to
> ASCII Format.
> I have managed to convert the remaining data into the proper format
> but am stuck due to COMP-3.
> There are fields as follows:
> Seq Dt S9(7)
> Seq Period X(2)
> both of which are in a group.
> How do i convert them into ASCII format ?
>
> Any help is truly appreciated.
Take a look at ParseRat (http://www.parserat.com/).
--
Ed Guy P.Eng,CDP,MIEE
Information Technology Consultant
Internet: e...@guysoftware.com
http://www.guysoftware.com
"Check out HELLLP!, WinHelp author tool for WinWord 2.0 through 8.0,
PlanBee Project Management Planning System
and ParseRat, the File Parser, Converter and Reorganizer"
William M. Klein
It is EASY to replace "debugging mode" with conditional compilation - if
you have that facility from the 2002 Standard. (Certainly NOT something
available yet in IBM compilers)
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:b5vk1v$6j1$1...@peabody.colorado.edu...
Chuck Stevens
> Oh shoot. I use the DEBUGGING MODE all the time.
The debug module was marked as obsolete in ANSI X3.23-1985, and under
ordinary circumstances all features of it would have been deleted in their
entirety in the standard that followed.
Although USE FOR DEBUGGING and DEBUG-ITEM were indeed dropped, debug lines
and WITH DEBUGGING MODE were retained.
Fundamentally, as I see it, compiler directives provide all of the
functionality (and more) that debugging lines in conjunction with WITH
DEBUGGING MODE provides.
These two remnants of the old ANSI-'74 DEBUG module are (still) obsolete in
ISO/IEC 1989:2002.
> At least fixes will be easy.
Yes, I think so.
-Chuck Stevens
Ed Guy
There are several defininitions of a "Julian Date" - it's often confused with
Julian Day Numbers, which I think is what was intended here. Astronomers and
chronologists use it.
The Julian day system was developed by Joseph Justus Scaliger (1540-1609) in the
course of his work on ancient chronologies published in 1583, and probably named for
its fit to the Julian year.
January 1, 4713 B.C. is the date determined by Scaliger to have three different
yearly counting schemes simultaneously at the start of their sequences and the
Julian Date of a day is the number of days since that date. This makes it easy to
determine the number of days between two days (just subtract one Julian day number
from the other).
The Julian Day Number can be stored in a 32 bit integer (taking up only four bytes),
less space than needed for most other date storage (including the YYMMDD six digit
format which brought the “Millenium Bug” to the world).
Ed Guy
Which I was using in COBOL programs as long ago as 1975. It took less space and was
Y2K compliant even then.
William M. Klein
The reason that "debugging mode" and debugging line were NOT dropped in the
2002 Standard is that they were NOT part of the "debugging module" in the
'85 Standard - rather they were part of the Nucleus.
ALL of the '85 Standard Debugging Module *has* been dropped from the 2002
Standard.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles...@unisys.com> wrote in message
news:b5vlng$21vv$1...@si05.rsvl.unisys.com...
Howard Brazee
On 27-Mar-2003, "William M. Klein" <wmk...@ix.netcom.com> wrote:
> FYI -
> It is EASY to replace "debugging mode" with conditional compilation - if
> you have that facility from the 2002 Standard. (Certainly NOT something
> available yet in IBM compilers)
Then I won't worry about it. When the time comes, conversion won't be
difficult.
Howard Brazee
may be because they screwed up in inventing their own "Julian date" that doesn't
match the original.
But whey there were Lilian dates and Julian dates to begin with is a question I
don't have the answer to.
Chuck Stevens
me like they were part of the DEBUG module as described in the '74 standard;
they were made part of the nucleus in the '85 standard (and thereby
retained) while the rest of the DEBUG module was marked obsolete.
-Chuck Stevens
"William M. Klein" <wmk...@ix.netcom.com> wrote in message
news:b5vm9m$7aa$1...@slb3.atl.mindspring.net...
Donald Tees
> Don't worry Donald.
>
> As usual RW was in error (but at least he did qualify his statement with
"I
> think it's ...")
>
> Neither PIC nor the alphabetic category is archaic in the 2002 Standard.
> (In fact, it has "added" usefulness with the VALIDATE statement)
>
> > Too bad. Class alphabetic is handy at times. I have used it
> experimentally
> > in building alphabetic class OOP objects.
> >
Speaking of which ... is the SPACE character considered ALPHABETIC?
Donald
Chuck Stevens
> Speaking of which ... is the SPACE character considered ALPHABETIC?
The short answer is "yes". It's also considered ALPHABETIC-UPPER and
ALPHABETIC-LOWER. The longer answer is still "yes" by default, but I can't
assert that there is no locale-dependent case in which it could never under
any circumstance be "no".
-Chuck Stevens
Peter E.C. Dashwood
>
> "William M. Klein" <wmk...@ix.netcom.com> wrote in message
> news:b5ve07$5to$1...@slb2.atl.mindspring.net...
>
> of COBOL words; MOVE of alphanumeric constants to numeric items; NEXT
> SENTENCE in IF and SEARCH; ON OVERFLOW in CALL; and identifiers (as
distinct
> from delimited text) in COPY ... REPLACING.
>
> "Obsolete language elements are elements that will be removed in the next
> edition ..." (ISO/IEC 1989:2002 Page 834, Annex G, Archaic and obsolete
> language element lists, Section G.2, Obsolete language elements, first
> paragraph).
I usually use ON OVERFLOW or ON EXCEPTION when coding CALL statements. Is it
only ON OVERFLOW that is deemed archaic, or are they both for the chop?
Fortunately, these days most of what I used to CALL, gets INVOKED...<G>
Pete.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Peter E.C. Dashwood
> FYI -
> It is EASY to replace "debugging mode" with conditional compilation - if
> you have that facility from the 2002 Standard. (Certainly NOT something
> available yet in IBM compilers)
>
Chuck Stevens
conditions that cuase the exception to occur normally are not related to an
overflow condition. ... [T]he ON EXCEPTION phrase accomplishes the same
task. That phrase is more meaningful." (ISO/IEC 1989:2002 Page 834, G.1,
Archaic Language Elements, item 4.
-Chuck Stevens
"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:3e839...@127.0.0.1...
<history snipped>
William M. Klein
is "better defined" *and* there is a NOT on EXCEPTION phrase while there was
never a NOT on OVERFLOW phrase added.
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:3e839...@127.0.0.1...
>
Peter E.C. Dashwood
it
> only ON OVERFLOW that is deemed archaic, or are they both for the chop?
>
> Fortunately, these days most of what I used to CALL, gets INVOKED...<G>
>
Thanks both Bill and Chuck for informative responses.
JerryMouse
I'm with you. I've found that misbehaving programs always start working
flawlessly when debugging tools are added.
Robert Wagner
>Robert Wagner wrote:
>
>
>> Such requests .. If he needs a current version, I say "give me
>> five minutes to reorg it".
>
>My systems actually have users, usually all the working hours, and while
>the file is in use it cannot be 'reorged' as this requires exclusive access.
So run just the first reorg step to create a flat file.
>Obviously your files have nothing better to do.
My reference files have nothing better to do. They contain, for example,
cross-reference between Sedol and CUSIP id, daily prices, CUSIP to issue name,
etc. They are updated by midnight batch jobs. Those are the kind of files
usually requested.
>Which brings the argument back around to doing an extract in shared mode
>while others are using the file. For this my 'report writer' sub-system
>can, from a script, select appropriate records and export them to printed
>report, CSV file, flat file, or HTML tables as required.
>
>There isn't much point is retaining an old reorg flat file when the user
>can extract exactly what he wants.
Except immediacy. He wants it NOW. I keep thinking, 'if you'd asked for it two
weeks ago, you would have had it one week ago. Don't blame me for your lack of
planning.' Being a diplomat, I don't say that, of course.
>I live in a world where the users get a system that gives them what they
>want.
What they think they want today, opposed to what the really will need tomorrow,
when the new parent company asks for a copy of your file.
>Now why would you get frequent requests for copies of your data files ? Is
>it because they need to load them up into a database or spreadsheet to
>shake out some information ?
Usually for testing. They'll be loading my file into their database some time in
the future. They want to shake out conversion programs. In that case, it doesn't
matter whether my files are current.
>If the system provided the view of the data they require then they don't
>need to piss around with copies of the files.
There is no 'view' on indexed files. That's a database concept. Granted they
could do it through ODBC, but that takes time and planning. They ask for a copy
of the file; they don't ask for a logical view of the data they require.
The same people have programmers who sit idle for months, then are inundated
with crushing deadlines. Poor management? Welcome to Reality. That's how it is
in the real world.
I'm thinking of writing an article about what it's like to be a Big Five
contractor. You wouldn't believe the mismanagement that goes on.
Robert Wagner
>On Thu, 27 Mar 2003 03:23:45 GMT, rob...@wagner.net (Robert Wagner)
>enlightened us:
>
>>docd...@panix.com wrote:
>>
>>>>Dates should never have been comp-3. They are not algebraic variables. You
>>>>cannot add 1 to a date.
>>>
>>>Mr Wagner, this is wrong in that it is clearly contradicted by the
>>>capabilities provided by ANSI SQL; it is further contradicted by the
>>>experiences of anyone who has performed arithmetic operations on Julian
>>>dates.
>>
>>Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
>>date, 1 with a machine instruction. Nor can you add 1 to a 'julian' date
without
>>a lot of overhead involving leap years.
>>
>>Julius Caesar is dishonored by associating such a lousy date format with his
>>name. The difference between his calendar and Pope Gregory's has nothing to do
>>with format. It involves 365 days per year (julian) vs leap years and 365.24
>>days per year (gregorian).
>>
>>Romans never wrote dates as 95001. That's something mediocre programmers
dreamed
>>up and named 'julian'.
>
>I will say your incorrect facts must mean you have an active
>imagination.
>
>Juliun days, which is still used by astronomers, is based on the
>number of days that have elapsed since noon universal time (UT), 1
>January 4713 BCE (before current era, or B.C.); for example, 1 January
>1996 CE (current era, or A.D.) is equivalent to Julian day 2,450,084.
I've always thought 'Julian' meant the IBM convention: yyddd. I'd never heard it
applied to the above, which i had called 'absolute date' for lack of a better
name. My date utility converts yymmdd and yyyymmdd to an absolute date
The problem with absolute dates is they all use a different base year. Some use
4713 BCE,some use 1900, some use year zero, some use 15 Oct 1582, when Pope
Gregory created the calender we use today. There is no uniformity, thus no way
these numbers could be portable.
Using the date the company started as a base is worse, because employee
birthdates will be negative.
Thanks for the encyclopedic account of calendar history.
Robert Wagner
>In article <3e82677d....@news.optonline.net>,
>Robert Wagner <rob...@wagner.net> wrote:
>>docd...@panix.com wrote:
>>
>>>>Dates should never have been comp-3. They are not algebraic variables. You
>>>>cannot add 1 to a date.
>>>
>>>Mr Wagner, this is wrong in that it is clearly contradicted by the
>>>capabilities provided by ANSI SQL; it is further contradicted by the
>>>experiences of anyone who has performed arithmetic operations on Julian
>>>dates.
>>
>>Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
>>date, 1 with a machine instruction.
>
>This was not your original assertion, Mr Wagner; your original assertion
>was 'you cannot add 1 to a date'. Is it your habit to change assertions
>when you are shown to be wrong?
Oh for Christ sake, my original assertion was "Dates should never have been
comp-3". I assumed 'date' meant yymmdd format rather than some absolute or
Julian format. You cannot Add Packed 1 to a yymmdd date.
>Do you have any sort of documentation you might be able to present to
>support your assertion about 'mediocre programmers' or shall 'making
>things up, whole cloth' be added to the tactic of 'changing assertions
>when shown to be wrong'?
We seem to be getting cross-posts from alt.lexicography and alt.flame.
docd...@panix.com
Robert Wagner <rob...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <3e82677d....@news.optonline.net>,
>>Robert Wagner <rob...@wagner.net> wrote:
>>>docd...@panix.com wrote:
>>>
>>>>>Dates should never have been comp-3. They are not algebraic variables. You
>>>>>cannot add 1 to a date.
>>>>
>>>>Mr Wagner, this is wrong in that it is clearly contradicted by the
>>>>capabilities provided by ANSI SQL; it is further contradicted by the
>>>>experiences of anyone who has performed arithmetic operations on Julian
>>>>dates.
>>>
>>>Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
>>>date, 1 with a machine instruction.
>>
>>This was not your original assertion, Mr Wagner; your original assertion
>>was 'you cannot add 1 to a date'. Is it your habit to change assertions
>>when you are shown to be wrong?
>
>Oh for Christ sake, my original assertion was "Dates should never have been
>comp-3".
That was one of your assertions, Mr Wagner... and another one, following
it shortly, was 'you cannot add 1 to a date'. That is the assertion I
addressed in my first response, the response to which you replied with an
apparent non-sequitur about not being able to '... AP date, 1 with a
machine instruction.'
>I assumed 'date' meant yymmdd format rather than some absolute or
>Julian format. You cannot Add Packed 1 to a yymmdd date.
This is another assertion entire, Mr Wagner, than the original which I
addressed, being 'You cannot add 1 to a date'. Is it your habit, then, to
change assertions when you are shown to be wrong?
Oh... and is it your habit to edit out the parts of posts you respond to
which show that you are wrong, as well? That seems to have happened
here... with nary an indication of the deletion to be seen.
>
>>Do you have any sort of documentation you might be able to present to
>>support your assertion about 'mediocre programmers' or shall 'making
>>things up, whole cloth' be added to the tactic of 'changing assertions
>>when shown to be wrong'?
>
>We seem to be getting cross-posts from alt.lexicography and alt.flame.
Plural majestatus est, Mr Wagner... but you seem to change assertions when
you are shown to be wrong and make other assertions of fact without any
sort of documentation as I have pointed out above; neither of these is, I
was taught, a technique of discourse used by a person of honor, decency
and moral rectitude.
DD
Arnold Trembley
> (snip)
> Oh for Christ sake, my original assertion was "Dates should never have been
> comp-3". I assumed 'date' meant yymmdd format rather than some absolute or
> Julian format. You cannot Add Packed 1 to a yymmdd date.
Then you really missed all the fun in comp.software.year-2000. It was
back in October of 1997 when they discussed multiplying dates:
COMPUTE YYMMDD = MMDDYY * 10000.01
I think the magic number for converting YYMMDD to MMDDYY was 100.0001.
Richard Plinston
>>Which brings the argument back around to doing an extract in shared mode
>>while others are using the file. For this my 'report writer' sub-system
>>can, from a script, select appropriate records and export them to printed
>>report, CSV file, flat file, or HTML tables as required.
>>
>>There isn't much point is retaining an old reorg flat file when the user
>>can extract exactly what he wants.
>
> Except immediacy. He wants it NOW. I keep thinking, 'if you'd asked for it
> two weeks ago, you would have had it one week ago. Don't blame me for your
> lack of planning.' Being a diplomat, I don't say that, of course.
Well it may take you a week to get around to things, but my users can get
extracts whenever they want of exactly what they want. They use my report
writer sub-system, click the file, the fields, the selections and then
extract.
Immediacy is what they have. Not some old copy of some reorg flat file of
unknown age.
> There is no 'view' on indexed files.
They can get whatever 'view' they like by sppecifying the fields they want
and the order of them, and the selection criteria. Of course some fields
may be restricted because of security levels.
It is not the 'indexed file' that gives the view, it is the application
software.
> The same people have programmers who sit idle for months, then are
> inundated with crushing deadlines. Poor management? Welcome to Reality.
> That's how it is in the real world.
It might be in your world.
docd...@panix.com
Mr Trembley, it could be easily imagined that someone might say 'well, you
are using an example of multiplication, not addition... so the original
assertion still stands!'
(such a someone would, of course, be demonstrating an utter ignorance of
the relation of multiplication to repetitive addition... but some folks
have demonstrated a great willingness to demonstrate ignorances in the
past)
DD
Donald Tees
Thank you.
Donald
SkippyPB
enlightened us:
>docd...@panix.com wrote:
>
>>In article <3e82677d....@news.optonline.net>,
>>Robert Wagner <rob...@wagner.net> wrote:
>>>docd...@panix.com wrote:
>>>
>>>>>Dates should never have been comp-3. They are not algebraic variables. You
>>>>>cannot add 1 to a date.
>>>>
>>>>Mr Wagner, this is wrong in that it is clearly contradicted by the
>>>>capabilities provided by ANSI SQL; it is further contradicted by the
>>>>experiences of anyone who has performed arithmetic operations on Julian
>>>>dates.
>>>
>>>Good try. Packed decimal is a 'class' provided by the machine. You cannot AP
>>>date, 1 with a machine instruction.
>>
>>This was not your original assertion, Mr Wagner; your original assertion
>>was 'you cannot add 1 to a date'. Is it your habit to change assertions
>>when you are shown to be wrong?
>
>Oh for Christ sake, my original assertion was "Dates should never have been
>comp-3". I assumed 'date' meant yymmdd format rather than some absolute or
>Julian format. You cannot Add Packed 1 to a yymmdd date.
>
You most certainly can add a packed 1 to a yymmdd date. There is
nothing in the compiler or in the (at least in the mainframe world)
that would prohibit such an operation. Would you have to validate you
ended up with a valid date? Certainly, but there is nothing
preventing one from adding a packed 1 to a date field.
>>Do you have any sort of documentation you might be able to present to
>>support your assertion about 'mediocre programmers' or shall 'making
>>things up, whole cloth' be added to the tactic of 'changing assertions
>>when shown to be wrong'?
>
>We seem to be getting cross-posts from alt.lexicography and alt.flame.
Regards,
////
(o o)
-oOO--(_)--OOo-
Micro$oft Haiku Error Message #111
The Tao that is seen
Is not the true Tao - until
You bring fresh toner.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
William M. Klein
(PC or mainframe) you may want to look at their "date" extensions. See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/6.2.1
and more specifically,
"Arithmetic with date fields"
at
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/6.1.5.2
One of the other "interesting" statements is at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr10/5.3.6.2.
1
which says,
"The only phrases of the USAGE clause that can be combined with the DATE
FORMAT clause are DISPLAY, COMPUTATIONAL (or its equivalents,
COMPUTATIONAL-4 and BINARY), and COMPUTATIONAL-3 (or its equivalent,
PACKED-DECIMAL). The DATE FORMAT clause is not allowed for USAGE COMP data
items if the TRUNC(BIN) compiler option is in effect."
--
Bill Klein
wmklein <at> ix.netcom.com
"SkippyPB" <swie...@neo.NOSPAM.rr.com> wrote in message
news:05C1964854F0ABF6.8F957440...@lp.airnews.net...
> On Fri, 28 Mar 2003 02:34:56 GMT, rob...@wagner.net (Robert Wagner)
> enlightened us:
>
> >docd...@panix.com wrote:
> >
> >>In article <3e82677d....@news.optonline.net>,
> >>Robert Wagner <rob...@wagner.net> wrote:
> >>>docd...@panix.com wrote:
> >>>
<snip>
> >
>
> You most certainly can add a packed 1 to a yymmdd date. There is
> nothing in the compiler or in the (at least in the mainframe world)
> that would prohibit such an operation. Would you have to validate you
> ended up with a valid date? Certainly, but there is nothing
> preventing one from adding a packed 1 to a date field.
><snip>
Robert Wagner
>rob...@wagner.net (Robert Wagner) wrote
>> The difference between his calendar and Pope Gregory's has nothing to do
>> with format. It involves 365 days per year (julian) vs leap years and 365.24
>> days per year (gregorian).
>
>The Julian Calendar also had leap years. Mostly they were every 4
>years as we have now. The Gregorian Calendar introduced the 100 and
>400 year rules plus some adjustment.
You are correct. Gregory adjusted 16 days, one day per century. I wasn't
thinking clearly.
>A Julian date is a day number since a theoretical 4173 BC which is
>currently around 2452720. The format of yy nnn is not a Julian Date
>and has nothing to do with the Julian Calendar. It happens to save
>space, which was very important when computers had 16K memory and 4Mb
>14 inch disks, it was only 5 digits instead of 6 and this fitted into
>Packed as 3 bytes.
>
>For your '40 years experience' you've not learnt much that is true.
The IBM format (yyddd) is the only reference I've seen to 'Julian date'. In 40
years, I've never used that format even though 'mediocre programmers' championed
it and lambasted me for failing to see the light. I was right; they were wrong.
Here in CLC, a similar dynamic is developing. It's easy now, as it was then, to
distinguish the good guys from the bad without getting into the merits of their
arguments. If they play the political/ad hominem card, they're bad guys; if they
play fair, they're good good guys. It's that simple.
Robert Wagner
>"There is no plan for the removal of archaic elements; however, should their
>use in program inventories become insignificant, they may be considered for
>designation as obsolete by future architects of standard COBOL." (ISO/IEC
>1989:2002 Page 833, Annex G, Archaic and obsolete language element lists,
>Section G.1, Archaic language elements, second paragraph).
>
>There are five ARCHAIC features in the 2002 COBOL standard: continuation
>of COBOL words; MOVE of alphanumeric constants to numeric items; NEXT
>SENTENCE in IF and SEARCH; ON OVERFLOW in CALL; and identifiers (as distinct
>from delimited text) in COPY ... REPLACING.
Of the five, the lion's share of "program inventories" goes to NEXT SENTENCE.
Before we got "continue' in '85, NEXT SENTENCE was considered synonymous. I see
it used that way in _many_ production programs.
>"Obsolete language elements are elements that will be removed in the next
>edition ..." (ISO/IEC 1989:2002 Page 834, Annex G, Archaic and obsolete
>language element lists, Section G.2, Obsolete language elements, first
>paragraph).
>
>There are three OBSOLETE elements in the 2002 COBOL standard: the
>communications facility; debugging lines and the DEBUGGING MODE clause; and
>the PADDING CHARACTER clause.
I also see DEBUGGING MODE used extensively. Of course, it doesn't show up on
production programs (it's been commented out). It is most often used in lieu of
READY TRACE to display paragraph names entered.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e81067a...@news.optonline.net...
>
>> You cannot add 1 to a date.
>
>Maybe YOU can't. But I'm laboring under the impression that *I* can.
>
>So far as I know, the following ought to work with any COBOL compiler
>claiming compliance to the '85 standard (as the intrinsic functions
>amendment was incorporated into it):
>
>000100 IDENTIFICATION DIVISION.
>000200 ENVIRONMENT DIVISION.
>000300 DATA DIVISION.
>000400 WORKING-STORAGE SECTION.
>000500 01 MY-DATE PIC 99999999 PACKED-DECIMAL VALUE 20021231.
>000600 01 MY-DAY PIC 9999999 PACKED-DECIMAL VALUE 2002365.
>000700 PROCEDURE DIVISION.
>000800 MAIN-PARAGRAPH.
>000900 COMPUTE MY-DATE =
>001000 FUNCTION DATE-OF-INTEGER
>001100 (FUNCTION INTEGER-OF-DATE (MY-DATE) + 1)
>001200 COMPUTE MY-DAY =
>001300 FUNCTION DAY-OF-INTEGER
>001400 (FUNCTION INTEGER-OF-DAY (MY-DAY) + 1)
>001500 DISPLAY MY-DATE
>001600 DISPLAY MY-DAY
>001700 STOP RUN.
>
>This of course presumes that MY-DATE and MY-DAY are encoded in YYYYMMDD and
>YYYYDDD formats respectively. I would expect the new contents of these
>fields to be 20030101 and 2003001 respectively.
>
>I will acknowledge that this mechanism does not appear to support handling
>of any dates from December 31, 1600 and before, but I would hazard the
>comment that the ability to do arithmetic on dates from before the early
>seventeenth century is not something for which either my company as a
>compiler vendor or I as a member of J4 have had hordes of users clamoring.
>
>The user doesn't need to be concerned about USER CODE overhead involving
>leap years; how the compiler implementor provides for it may entail "a lot
>of overhead" or it may not.
The only reason to use PACKED-DECIMAL is to permit high-speed in-inline machine
instructions. If you are going to call external functions, as you do above,
there is no speed advantage over DISPLAY. Thus my original assertion stands:
dates should not be stored in PACKED-DECIMAL format.
Robert Wagner
>This is another assertionentire, Mr Wagner, than the original which I
>addressed, being 'You cannot add 1 to a date'. Is it your habit, then, to
>change assertions when you are shown to be wrong?
>
>Oh... and is it your habit to edit out the parts of posts you respond to
>which show that you are wrong, as well? That seems to have happened
>here... with nary an indication of the deletion to be seen.
>
>>
>>>Do you have any sort of documentation you might be able to present to
>>>support your assertion about 'mediocre programmers' or shall 'making
>>>things up, whole cloth' be added to the tactic of 'changing assertions
>>>when shown to be wrong'?
>>
>>We seem to be getting cross-posts from alt.lexicography and alt.flame.
>
>Plural majestatus est, Mr Wagner... but you seem to change assertions when
>you are shown to be wrong and make other assertions of fact without any
>sort of documentation as I have pointed out above; neither of these is, I
>was taught, a technique of discourse used by a person of honor, decency
>and moral rectitude.
A person practicing honor, decency and moral rectitude treats his opponent with
respect, not as a hopeless idiot. His mannerliness is genuine, not formal and
stilted.
I've chosen to live in places where the vast majority practiced such courtesy
without effort. West Texas and Alabama. Now I live (temporarily) in New York,
where people are as rude as you, while making a cursory gesture toward formal
politeness.
If you want to learn _real_ manners, take a vacation in Montgomery, Alabama. Or
hang out with real cowboys near Lubbock, Texas. It will be an enlightening
experience.
Robert Wagner
>Robert Wagner wrote:
>
>>>Which brings the argument back around to doing an extract in shared mode
>>>while others are using the file. For this my 'report writer' sub-system
>>>can, from a script, select appropriate records and export them to printed
>>>report, CSV file, flat file, or HTML tables as required.
>>>
>>>There isn't much point is retaining an old reorg flat file when the user
>>>can extract exactly what he wants.
>>
>> Except immediacy. He wants it NOW. I keep thinking, 'if you'd asked for it
>> two weeks ago, you would have had it one week ago. Don't blame me for your
>> lack of planning.' Being a diplomat, I don't say that, of course.
>
>Well it may take you a week to get around to things, but my users can get
>extracts whenever they want of exactly what they want. They use my report
>writer sub-system, click the file, the fields, the selections and then
>extract.
>
>Immediacy is what they have. Not some old copy of some reorg flat file of
>unknown age.
>
>> There is no 'view' on indexed files.
>
>They can get whatever 'view' they like by sppecifying the fields they want
>and the order of them, and the selection criteria. Of course some fields
>may be restricted because of security levels.
>
>It is not the 'indexed file' that gives the view, it is the application
>software.
The Microsoft ODBC driver for flat files lets you define a 'schema' in another
text file, then access the flat file as though it was a database table. You can
specify keys too. It is surprisingly fast.
Combine that with msquery (which comes free with Excel) and you have a powerful
query tool.
I once needed to compare two flat files to insure the records matched. Each
contained 400K records. I wrote SQL to read file #1 sequentially and do a query
into file #2, printing a message on not found. It ran in less than five minutes.
I was impressed.
Robert Wagner
docd...@panix.com
It is good that you seem to have learned that somewhere, Mr Wagner; all
that's required from you might be a bit more practise.
Now please be so kind as to go back in this thread, notice where you
state, clearly and unequivocally, that 'You cannot add 1 to a date' and
how you were shown to be wrong about this. Until you can admit to that
you may consider this interchange to be ended.
DD
docd...@panix.com
Robert Wagner <rob...@wagner.net> wrote:
>"Chuck Stevens" <charles...@unisys.com> wrote:
>>
>>"Robert Wagner" <rob...@wagner.net> wrote in message
>>news:3e81067a...@news.optonline.net...
>>
>>> You cannot add 1 to a date.
>>
>>Maybe YOU can't.
[snip to the chase]
>Thus my original assertion stands:
>dates should not be stored in PACKED-DECIMAL format.
Thus, Mr Wagner, your assertion seems to change when you are shown to be
wrong.
DD
Robert Wagner
My assertion has not changed -- you cannot do a high-speed machine instruction
such as Add Packed on a date. That being the case, the date would better be
stored as DISPLAY.
If you you think you can make a case for _machine level_ arithmetic on dates,
please present evidence.
docd...@panix.com
Robert Wagner <rob...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <3e84ea65....@news.optonline.net>,
>>Robert Wagner <rob...@wagner.net> wrote:
>>>"Chuck Stevens" <charles...@unisys.com> wrote:
>>>>
>>>>"Robert Wagner" <rob...@wagner.net> wrote in message
>>>>news:3e81067a...@news.optonline.net...
>>>>
>>>>> You cannot add 1 to a date.
>>>>
>>>>Maybe YOU can't.
>>
>>[snip to the chase]
>>
>>>Thus my original assertion stands:
>>>dates should not be stored in PACKED-DECIMAL format.
>>
>>Thus, Mr Wagner, your assertion seems to change when you are shown to be
>>wrong.
>
>My assertion has not changed -- you cannot do a high-speed machine instruction
>such as Add Packed on a date. That being the case, the date would better be
>stored as DISPLAY.
Mr Wagner, are you saying, then, that you did not respond to a posting by
Mr Wagner where he quoted you as asserting 'You cannot add 1 to a date'?
DD
Richard Plinston
> The only reason to use PACKED-DECIMAL is to permit high-speed in-inline
> machine instructions.
No. Wrong. The main reason to use 'PACKED' is to save space. a yyddd date
can be stored in 3 bytes using PACKED and 5 bytes using decimal. To hold
it as ccyymmdd takes 8 bytes in decimal or 5 bytes in packed.
These were very important considerations when computer main memory was 16K
and tapes held a megabyte or three.
> Thus my original
> assertion stands: dates should not be stored in PACKED-DECIMAL format.
I thought that your assertion was that you can't add 1 to a date.
Richard Plinston
> You are correct. Gregory adjusted 16 days, one day per century. I wasn't
> thinking clearly.
Pope Gregory adjusted the calendar by 10 days in 1582. It was 3 days per 4
centuries.
>>For your '40 years experience' you've not learnt much that is true.
>
> The IBM format (yyddd) is the only reference I've seen to 'Julian date'.
What a sheltered and isolated life you have led.
> In 40 years, I've never used that format even though 'mediocre
> programmers' championed it and lambasted me for failing to see the light.
Presumably you thought of them as 'mediocre' because they didn't do things
your way.
> I was right; they were wrong.
That is your standard mantra, yes.
> Here in CLC, a similar dynamic is developing. It's easy now, as it was
> then, to distinguish the good guys from the bad without getting into the
> merits of their arguments. If they play the political/ad hominem card,
> they're bad guys; if they play fair, they're good good guys. It's that
> simple.
Well here in _this_ pond people are judged by _what_ they say. If they
make errors they are allowed to correct them, or show they are not errors,
if they simply repeat mis-information they are the 'bad guys'.
For example: so far you have made several statements about the Julian and
Gregorian calendar and about Julian dates, as if they were facts, but have
about a 100% record for these all being wrong.
Even your 'correction' above has two 'facts', both wrong, even though the
first round of corrections contained these for anyone with sufficient
skills to read them.
You have spent many decades 'learning' that making errors doesn't matter,
if you stonewall enough then eventually they will call you a complete
fuckwit and you will count a 'win', but only in your own mind.
I am not impressed by your 'deflection', if you continually make errors and
fail to make any effort to correct them or to learn anything then I will
call you an idiot child and tell you to fuck off.
It is _that_ simple.
Claiming that you are a 'good guy' because every yells at you just shows
how shallow you can be.
Richard Plinston
> A person practicing honor, decency and moral rectitude treats his opponent
> with respect, not as a hopeless idiot. His mannerliness is genuine, not
> formal and stilted.
What crap. You _are_ a hopeless idiot and should be treated as one.
Peter E.C. Dashwood
> rip...@Azonic.co.nz (Richard) wrote:
>
> Here in CLC, a similar dynamic is developing. It's easy now, as it was
then, to
> distinguish the good guys from the bad without getting into the merits of
their
> arguments. If they play the political/ad hominem card, they're bad guys;
if they
> play fair, they're good good guys. It's that simple.
>
next <G>...
I don't think a "dynamic is developing", Robert. I think people react to
what they observe.
You have certainly come in for a lot of flak, but that doesn't make the AA
gunners "bad guys". And you seem to handle it very well.
There are undoubtedly occasions here where you have "led with your chin" and
people have queued up to hit it. That's just Human...it isn't good or bad.
Maybe we should all learn to take exhanges on CLC a little less seriously...
Having said that, there is nothing wrong with stimulation and even
provocation, in an unmoderated Newsgroup.
It hasn't stopped you and I hope it won't...<G>
Peter E.C. Dashwood
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:b63baf$5u8$1...@aklobs.kc.net.nz...
Or you COULD just ignore his post if it inflames you to that extent,
Richard...<G>
Peter E.C. Dashwood
> "Chuck Stevens" <charles...@unisys.com> wrote:
>
> >
> >"Robert Wagner" <rob...@wagner.net> wrote in message
> >news:3e81067a...@news.optonline.net...
> >
> >> You cannot add 1 to a date.
> >
>
machine
> instructions. If you are going to call external functions, as you do
above,
> there is no speed advantage over DISPLAY. Thus my original assertion
stands:
> dates should not be stored in PACKED-DECIMAL format.
>
This is getting plain silly...
"You cannot add 1 to a date" Obviously wrong; you can add 1
to ANY Packed field.What was intended was that it does not MAKE SENSE to
increase the numerical representation of a date by 1, because this would not
necessarily produce a valid date. (It would sometimes...in fact, it would
MOST of the time <G>, but it would fail on around 3% of occasions).
"Dates should not be stored as Packed" A matter of opinion. Personally, I
agree. (But then I WOULD say that; I don't think ANYTHING should be stored
as packed in 2003...)
Now, is the thread about making people right or wrong, or is it about
dealing with converting MainFrame data to ASCII?
William M. Klein
news:b63baf$5u8$1...@aklobs.kc.net.nz...
> Robert Wagner wrote:
>
>
> >>For your '40 years experience' you've not learnt much that is true.
> >
> > The IBM format (yyddd) is the only reference I've seen to 'Julian date'.
>
> What a sheltered and isolated life you have led.
>
YYDDD is *not* an IBM format. It is part of the ANSI/ISO COBOL Standard
(and has been as long as I know of), via the
ACCEPT ... FROM DAY
statement - which is ENHANCED in the 2002 Standard to also include YYYYDDD
values. This goes along with the '89 Standard intrinsic functions that
fully handle such things as INTEGER-OF-DAY and DAY-OF-INTEGER.
For other non-IBM and/or non-COBOL "uses" see
OpenVMS at:
http://h71000.www7.hp.com/wizard/wiz_2943.html
VB
http://www.buygold.net/v04n09/v04n09.html
C/C++
http://www.startech.keller.tx.us/xdate.html
Robert Wagner
If I _were_ inclined to respond to myself, I would use a different sobriquet.
Robert Wagner
>Robert Wagner wrote:
> The main reason to use 'PACKED' is to save space. a yyddd date
>can be stored in 3 bytes using PACKED and 5 bytes using decimal. To hold
>it as ccyymmdd takes 8 bytes in decimal or 5 bytes in packed.
>
>These were very important considerations when computer main memory was 16K
>and tapes held a megabyte or three.
The IBM-704, a room-filling mainframe, had but a few dozen words of memory. My
IBM-1401 was equipped with 4K. Upon learning it could be configured up to 16K, I
wondered what anyone would do with such an _ocean_ of memory.
Seems like just yesterday, doesn't it?
>> Thus my original
>> assertion stands: dates should not be stored in PACKED-DECIMAL format.
>
>I thought that your assertion was that you can't add 1 to a date.
No, my assertion was "should not be stored". Inability to add 1 WITH A SINGLE
MACHINE INSTRUCTION was one of the premises leading to that conclusion.
Robert Wagner
>
>"Robert Wagner" <rob...@wagner.net> wrote in message
>news:3e84e08b....@news.optonline.net...
>> rip...@Azonic.co.nz (Richard) wrote:
>>
>> Here in CLC, a similar dynamic is developing. It's easy now, as it was
>then, to
>> distinguish the good guys from the bad without getting into the merits of
>their
>> arguments. If they play the political/ad hominem card, they're bad guys;
>if they
>> play fair, they're good good guys. It's that simple.
>>
>So what about us schizophrenics who are a dream one day and a nightmare the
>next <G>...
There are two cures for your condition: Prozac and Jack Daniel's. :>
>There are undoubtedly occasions here where you have "led with your chin" and
>people have queued up to hit it. That's just Human...it isn't good or bad.
You seem to be saying this is the cybernetic equivalent of daytime TV shows
which exaggerate The Human Condition. I hadn't noticed that before. :>
Do you get the Jerry Springer Show in NZ? It's in a class by itself.
>Having said that, there is nothing wrong with stimulation and even
>provocation, in an unmoderated Newsgroup.
>
>It hasn't stopped you and I hope it won't...<G>
Oh good. Thanks for the encouragement.
Richard Plinston
>
>> The main reason to use 'PACKED' is to save space. a yyddd date
>>can be stored in 3 bytes using PACKED
> Inability to add 1 WITH A
> SINGLE MACHINE INSTRUCTION was one of the premises leading to that
> conclusion.
Why has using a machine instruction for add have _anything_ to do with
saving space in memory and on tape ?
In fact your argument shows every sign as having _started_ with the
conclusion and then grabbing any silly argument as trying to support it.
Rick Smith
Peter E.C. Dashwood <dash...@enternet.co.nz> wrote in message
news:3e859...@127.0.0.1...
[snip]
> This is getting plain silly...
>
> "You cannot add 1 to a date" Obviously wrong; you can add
1
> to ANY Packed field.What was intended was that it does not MAKE SENSE to
> increase the numerical representation of a date by 1, because this would
not
> necessarily produce a valid date. (It would sometimes...in fact, it would
> MOST of the time <G>, but it would fail on around 3% of occasions).
Dates, in computer programs, are abstractions and may have
different representations.
If the representation is alphanumeric, such as March 29, 2003,
adding 1 to the date is problematic.
If the representation is numeric, such as 20030329, adding 1 to
the date may be accomplished by using a combination of COBOL
intrinsic functions.
If the representation is a relative day number, such as that returned
by the INTEGER-OF-DATE function; 1 may be added to the date
and will always produce a valid date provided the range for the
date represented, in ISO 8601 format, is greater than or equal to
1600-12-31 and less than or equal to 9999-12-31. This is true
without regard to the usage defined, as long as the picture is
sufficient to hold the value for 9999-12-31.
What is 'silly' is the use of unrestricted generalizations and
unstated assumptions to discuss the issue.
Jack Sleight
I think it was. What was his question?
Regards, Jack.
"Howard Brazee" <how...@brazee.net> wrote in message news:<b5sdpu$dua$1...@peabody.colorado.edu>...
> On 25-Mar-2003, rob...@wagner.net (Robert Wagner) wrote:
>
> > Dates should never have been comp-3. They are not algebraic variables. You
> > cannot add 1 to a date. So why represent them as comp-3? Just to save space?
>
> Depends on the date format. I have often done arithmetic with dates.
>
> > Why would dates not be postitive? Are BC dates negative? I doubt your
> > application deals with BC dates.
>
> I have seen some dates stored as a number of days since a company started.
> Spreadsheets do something similar since around 100 years ago.
>
> > This is fuzzy thinking between mathematical variables and 'fields which happen
> > to contain numbers', such as SSN, ZIP code and part number. The former might
> > reasonably be packed, but not the latter.
>
> Agreed. These examples should always be PIC X( ).
>
> Does anybody use PIC A()????
Michael Mattias
>
> No, my assertion was "should not be stored". Inability to add 1 WITH A
SINGLE
> MACHINE INSTRUCTION was one of the premises leading to that conclusion.
Let's assume for the sake of arg^h^h^h discussion that a 'single machine
instruction' is desireable.
Well, let's not.. because 'single machine instruction' is absolutely
immaterial. Some instructions require more cpu cycles to execute than do
others; thus it is possible to have two (or more) 'single machine
instructions' execute faster than one 'single machine instruction.'
Of course, I am being unfair. I am not accounting for the extra six or eight
bytes of storage required in the load module for each extra 'single machine
instruction.'
MCM
Frederico Fonseca
I think that the person in question will not know anything about what
goes "behind the line" when a program is executed, so this will only
add more distress to his poor mind.
Let's try and keep it simple as a gesture of goodwill to him.
FF
Frederico Fonseca
ema il: frederico _ fonseca at syssoft-int . com
Robert Wagner
That's called an ad hoc argument. It's really not an argument at all, it is an
explanation.
Saving space has not been a valid reason for at least ten years. Moreover, I
thought we'd agreed that packed and binary should not be stored on external
media. Thus the only reason to use packed is fast arithmetic .. on machines
which support packed instructions. If you cannot do MACHINE LEVEL arithmetic on
a field, such as a date, there is no reason to pack it. Other fields which
should not be packed are id numbers and postal codes, because it makes no sense
to do arithmetic on them.
Robert Wagner
The only way to tell for sure is to run a timing test. We recently did one here
in CLC. Running on Intel, it showed packed having no speed advantage over
display. Run on an IBM mainframe, I expect packed would be faster.
Rick Smith
[snip]
> Dates should never have been comp-3. They are not algebraic variables. You
> cannot add 1 to a date. So why represent them as comp-3? Just to save
space?
>
> application deals with BC dates.
>
happen
> to contain numbers', such as SSN, ZIP code and part number. The former
might
> reasonably be packed, but not the latter.
This got me to thinking about how I have sometimes applied
mathematical functions to dates and that it might be useful to
have such operations available as intrinsic functions in a
future COBOL standard. [No Bill, I do not have enough free
time to expand this to a presentation on the Future of COBOL.
<g>]
FLOOR-OF-YEAR (argument-1) returns the value for the
first day of the year.
CEILING-OF-YEAR (argument-1) returns the value for the
first day of the following year, if the value of argument-1
is not equal to FLOOR-OF-YEAR (argument-1).
Otherwise, returns FLOOR-OF-YEAR (argument-1).
FLOOR-OF-MONTH (argument-1) returns the value for the
first day of the month.
CEILING-OF-MONTH (argument-1) returns the value for the
first day of the following month, if the value of argument-1
is not equal to FLOOR-OF-MONTH (argument-1).
Otherwise, returns FLOOR-OF-MONTH (argument-1).
FLOOR-OF-WEEK (argument-1) returns the value for the
first day of the week, Monday.
CEILING-OF-WEEK (argument-1) returns the value for the
first day of the following week, Monday, if the value of
argument-1 is not equal to FLOOR-OF-WEEK (argument-1).
Otherwise, returns FLOOR-OF-WEEK (argument-1).
For those functions, listed above, I have used arguments
and return values based on the value of integer date.
Are there other date functions that may make sense?
docd...@panix.com
My error and apologies, Mr Wagner, for mis-stating myself and doing so in
a fashion which seems to have rendered my question incomprehensible; my
question should have read 'Mr Wagner, are you saying then, that you did
not respond to a posting by Mr Stevens where he quoted you as asserting
'You cannot add 1 to a date'?
DD
Steve Thompson
<snip>
> >Thus my original assertion stands:
> >dates should not be stored in PACKED-DECIMAL format.
>
> Thus, Mr Wagner, your assertion seems to change when you are shown to be
> wrong.
>
> DD
If you would ignore this ignoramus, he would go away (I kill
filed him some time ago).
He has been challenged by so many who are knowledgeable
about COBOL it is silly to continue with him -- in that he
weasels and changes the subject or flatly doesn't respond.
And his assertions about hardware/architecture tend to show
his absolute ignorance of same (I've only worked on x86,
U1100, Honeywell DPS series, WANG VS machines, IBM S/360,
370, 390 and z/ARCH, just to name some, and have written
macro-code for Amdahl).
It is when I read indirect postings of his on machine
architecture how data should/should not be stored and the
like that I just can't help but post such a warning.
--
Steve Thompson
www.vsstrategies.com
330/335-7228 office
Notice: By sending UCE/BCE (a/k/a, spam) to this address,
you are accepting and agreeing to our charging a $1000 fee,
per spam item, for handling and processing, and you agree to
pay any and all costs incurred (including court costs and/or
attorney's fees) for collecting this fee.
Robert Wagner
>docd...@panix.com wrote:
><snip>
>> >Thus my original assertion stands:
>> >dates should not be stored in PACKED-DECIMAL format.
>>
>> Thus, Mr Wagner, your assertion seems to change when you are shown to be
>> wrong.
>>
>> DD
>
>If you would ignore this ignoramus, he would go away (I kill
>filed him some time ago).
>
>He has been challenged by so many who are knowledgeable
>about COBOL it is silly to continue with him -- in that he
>weasels and changes the subject or flatly doesn't respond.
>And his assertions about hardware/architecture tend to show
>his absolute ignorance of same (I've only worked on x86,
>U1100, Honeywell DPS series, WANG VS machines, IBM S/360,
>370, 390 and z/ARCH, just to name some, and have written
>macro-code for Amdahl).
>
>It is when I read indirect postings of his on machine
>architecture how data should/should not be stored and the
>like that I just can't help but post such a warning.
What is "macro-code", Mr. machine architecture expert? I'm familiar with
micro-code but had never before heard of macro-code. It sounds like a high level
language.
Your student,
Robert
Robert Wagner
Yeah, 'fiscal calender' calculations. Most companies use the '4-4-5' system for
fiscal months. A minority use 13 months of 28 days each, which has the
disadvantage of lacking quarterly cutoffs.
Obviously, '4-4-5' would have to be operator overloaded because the fiscal year
contains only 364 days. Every company has its own way of dealing with the 1.24
day discrepency. They declare a 'fiscal leap year' containing an extra week
every ~7 years, at the whim of management. Kinda like the Roman Emperors did.
These jumps are not based on predictable rules; they come as last-minute
decisions. Deal with _that_ in your algorithm.
Rick Smith
> "Rick Smith" <rick...@mfi.net> wrote:
[snip]
> >Are there other date functions that may make sense?
>
> Yeah, 'fiscal calender' calculations. Most companies use the '4-4-5'
system for
> fiscal months. A minority use 13 months of 28 days each, which has the
> disadvantage of lacking quarterly cutoffs.
>
> Obviously, '4-4-5' would have to be operator overloaded because the fiscal
year
> contains only 364 days. Every company has its own way of dealing with the
1.24
> day discrepency. They declare a 'fiscal leap year' containing an extra
week
> every ~7 years, at the whim of management. Kinda like the Roman Emperors
did.
> These jumps are not based on predictable rules; they come as last-minute
> decisions. Deal with _that_ in your algorithm.
ISO 8601 defines a week number that ranges from 01 to 52 (53).
A function, WEEK-OF-INTEGER (argument-1), might return the
week number as defined by ISO 8601. The week number might
then be used to implement the policy regarding where the extra
week is to be included.
It seems unlikely that fiscal calendars could be standardized; but
standard COBOL support could be provided to make such
calendars easier to calculate.
docd...@panix.com
Steve Thompson <s_thompson#NO#SP...@ix.netcom.com> wrote:
>docd...@panix.com wrote:
><snip>
>> >Thus my original assertion stands:
>> >dates should not be stored in PACKED-DECIMAL format.
>>
>> Thus, Mr Wagner, your assertion seems to change when you are shown to be
>> wrong.
>>
>> DD
>
>If you would ignore this ignoramus, he would go away (I kill
>filed him some time ago).
Mr Thompson, the path you suggest is one which has been employed by
others; personally, I try to limit my exchanges with Mr Wagner to simple
matters of fact (his being wrong, for example, about ''incorrect' is
metric while 'wrong' is moral' or the abovementioned 'you cannot add 1 to
a date'). I did make a foray into communications about matters of food
and have found him to ascribe things to me I never said; I'll try to avoid
such 'merely social' communications in the future.
DD
Thane Hubbell
> This got me to thinking about how I have sometimes applied
> mathematical functions to dates and that it might be useful to
> have such operations available as intrinsic functions in a
> future COBOL standard. [No Bill, I do not have enough free
> time to expand this to a presentation on the Future of COBOL.
> <g>]
... some snippage ...
>
> FLOOR-OF-WEEK (argument-1) returns the value for the
> first day of the week, Monday.
>
... Except that the first day of the week is Sunday. This might be
"First business day" but it is a cultural thing, not true in all
countries (As far as Monday being the first business day that is).
My overall take on these types of things is that you might want to
create a user defined function. This will work like an intrinsic
function.
Rick Smith
Thane Hubbell <tha...@softwaresimple.com> wrote in message
news:bfdfc3e8.03033...@posting.google.com...
Both ISO 1989 and ISO 8601 define the days of a week
such that Monday has the value 1 and Sunday the value 7.
Those conforming to these existing standards must already
make some adjustment to accommodate culture or business
rules.
A user-defined function could still be used, such that,
MyStartOfWeek (MyIntegerDate) is implemented as
FLOOR-OF-WEEK (argument-1 + 1) - 1. Thus making
Sunday the 'floor' for any week.
The modifications I made for Y2K used the equivalent of
FLOOR-OF-WEEK (UserDate + DowAdjust) - DowAdjust.
In other words, DowAdjust was always applied even when
zero. This was done so users could set their start of week
according to their business rules.
My take is whether thousands of programmers should
create user-defined functions to express the same
general concepts. <g>
Donald Tees
> Yeah, 'fiscal calender' calculations. Most companies use the '4-4-5'
system for
> fiscal months. A minority use 13 months of 28 days each, which has the
> disadvantage of lacking quarterly cutoffs.
>
> Obviously, '4-4-5' would have to be operator overloaded because the fiscal
year
> contains only 364 days. Every company has its own way of dealing with the
1.24
> day discrepency. They declare a 'fiscal leap year' containing an extra
week
> every ~7 years, at the whim of management. Kinda like the Roman Emperors
did.
> These jumps are not based on predictable rules; they come as last-minute
> decisions. Deal with _that_ in your algorithm.
1. All of us *have* been dealing with them for years.
2. They are not "last minute" decisions, they are made, normally before the
fiscal year starts.
3. The most ussual way of dealing with them is as a table
of dates that are coverted to some sort of base "date" internallly, and
doing arithmetic compares. That cannot be done easily without adding and
subtracting dates.
Donald
Robert Wagner
>This got me to thinking about how I have sometimes applied
>mathematical functions to dates and that it might be useful to
>have such operations available as intrinsic functions in a
>future COBOL standard. [No Bill, I do not have enough free
>time to expand this to a presentation on the Future of COBOL.
><g>]
>Are there other date functions that may make sense?
I propose INTEGER-TO-HISTORICAL-DATE and HISTORICAL-DATE-TO-INTEGER. This would
be useful to historians and genealogists. Pope Gregory standardized the calendar
in 1582, but the Gregorian calendar was not adopted by some countries until many
years later:
Italy, Spain 1582
Catholic Germany 1582
Hungary 1587
Scotland 1600/1752 (see below)
Protestant Germany 1700
England and US 1752
France 1806 (after 13 years of a 'sans-culottes' calendar)
Russia 1918
Yugoslavia 1919
Greece 1923
Ethiopia still on Julian calendar
As a result, we would see Napoleon retreating from Borodino Field on August 26,
1812 (according to a Russian text), 12 days before the battle took place
(according to a French text).
Sweden is an interesting case. In 1700 it decided to convert from Julian to
Gregorian gradually, by dropping Feb. 29 for some 40 years. They did so in 1704
and 1708, then changed their mind. The year 1712 had *two* leap days in
February. In 1753, they converted to Gregorian all at once.
A related issue is when a year begins. We now take it for granted a year begins
on 01/01. In historical times, the year generally began on 03/25, which was
called Feast of Annunciation or, in England, Ladies Day. It was thought to be
the day of Christ's conception. Thus, the day after 1600-03-24 was 1601-03-25.
Scotland adopted the 01/01 convention in 1600 but not the rest of the Gregorian
standard until 1752. Other places adoped 01/01 long before they adopted the
Gregorian calendar:
Venice 1522
Spain 1556
France 1579
Russia 1725
Washington's actual birthday was Feb. 11, 1731. It is represented as Feb. 22,
1732 under the Gregorian calendar. Needless to say, dates written before the new
calendar are not designated O.S. (old style).
A third issue is leap year on the century mark. The year 1700 was a leap year in
England and others on the Julian calendar; it was a common (non-leap) year
elsewhere. In Russia and Greece, 1800 and 1900 were leap years.
The sans-culottes calender had a 13th month containing 5 days (6 in leap years).
Thus, the HISTORICAL-DATE functions would need inputs of country and, in some
cases, city.
Robert Wagner
>"Robert Wagner" <rob...@wagner.net> wrote in message
>
>> Yeah, 'fiscal calender' calculations. Most companies use the '4-4-5'
>system for
>> fiscal months. A minority use 13 months of 28 days each, which has the
>> disadvantage of lacking quarterly cutoffs.
>>
>> Obviously, '4-4-5' would have to be operator overloaded because the fiscal
>year
>> contains only 364 days. Every company has its own way of dealing with the
>1.24
>> day discrepency. They declare a 'fiscal leap year' containing an extra
>week
>> every ~7 years, at the whim of management. Kinda like the Roman Emperors
>did.
>> These jumps are not based on predictable rules; they come as last-minute
>> decisions. Deal with _that_ in your algorithm.
>
>1. All of us *have* been dealing with them for years.
>2. They are not "last minute" decisions, they are made, normally before the
>fiscal year starts.
>3. The most usual way of dealing with them is as a table
>of dates that are coverted to some sort of base "date" internallly, and
>doing arithmetic compares. That cannot be done easily without adding and
>subtracting dates.
Your solution has the elegance of simplicity. We could do the same with
Gregorian dates -- just construct a table with an entry for each date. Having
done so, converting to and from integer date would be a simple table lookup.
There would no need for all that messy math.
Robert Wagner
>A user-defined function could still be used, such that,
>MyStartOfWeek (MyIntegerDate) is implemented as
>FLOOR-OF-WEEK (argument-1 + 1) - 1. Thus making
>Sunday the 'floor' for any week.
Once you have an integer date, computing the previous Monday takes three lines
of code: divide by 7, adjust remainder for base day of week, subtract remainder.
>My take is whether thousands of programmers should
>create user-defined functions to express the same
>general concepts. <g>
We've been doing it for forty years. Why change things now? <g>
Rick Smith
> "Rick Smith" <rick...@mfi.net> wrote:
>
>
> >A user-defined function could still be used, such that,
> >MyStartOfWeek (MyIntegerDate) is implemented as
> >FLOOR-OF-WEEK (argument-1 + 1) - 1. Thus making
> >Sunday the 'floor' for any week.
>
> Once you have an integer date, computing the previous Monday takes three
lines
> of code: divide by 7, adjust remainder for base day of week, subtract
remainder.
compute floor-of-week =
function integer ((some-date - 1) / 7) * 7 + 1
>
> >My take is whether thousands of programmers should
> >create user-defined functions to express the same
> >general concepts. <g>
>
> We've been doing it for forty years. Why change things now? <g>
We change things now so that the future will be different,
hopefully better, than the past. <g>
Peter E.C. Dashwood
"Steve Thompson" <s_thompson#NO#SP...@ix.netcom.com> wrote in message
news:3E86670A...@ix.netcom.com...
> docd...@panix.com wrote:
> <snip>
> > >Thus my original assertion stands:
> > >dates should not be stored in PACKED-DECIMAL format.
> >
> > Thus, Mr Wagner, your assertion seems to change when you are shown to be
> > wrong.
> >
> > DD
>
> If you would ignore this ignoramus, he would go away (I kill
> filed him some time ago).
This seems to me to be a very sensible approach Steve.
If something upsets you, it makes sense to avoid it.
I thought about this a lot after reading your post.
I have never killfiled ANYBODY. Then I wondered WHY that is...?
Having been involved in flame wars here over the years <G> (and usually
given as good as I got...) I have come to the realisation that it isn't
really important. (At least, not to me...I accept that others will have
different viewpoints and you have expressed yours, for one.)
I guess my own reason for not suppressing posts is because I really value
the outlet this forum gives us. As an unmoderated, uncensored, Web Based
News Group, it is one of the last bastions of Free Speech left on the
Planet. People can come here and say whatever they want to, whether it is
fair, accurate, informed, uninformed, biased, or whatever.
That, to me, is precious.
If this group was moderated or censored, I probably wouldn't contribute.
Like you, there is one person who posts here (occasionally... when he does
so he gets jumped on so heavily he goes away for a while in the hope that
those who jumped on him will be gone when he reappears...<G>) who REALLY
pisses me off (and no, it isn't Robert...<G>). Nevertheless, I have never
suppressed his posts.
Now, my REASON tells me I should not even respond to this prick, but there
is some primaeval instinct that makes me WANT to so bad, I see a red mist
and sparks fly off my keyboard in response...<G> After reading and
considering your post, I'm not sure whether yours is the wiser approach and
maybe I SHOULD simply kill file this guy...
But then I'd miss all the fun...<G>
The bottom line is that we have something very valuable here.
Many times there will be stuff that we strongly disagree with (both in
content and in attitude), and you are probably right, that if this
consistently comes from a particular individual, then it is best not to
encourage said individual by responding or reading his posts.
Sadly, that doesn't work for me.
I shall defend to the death the right of anyone to post here, and when they
do, I'll bloody well read it <G>. And if it really winds me up, I'll bloody
well respond to it <G>.
And there I've gone against the exact advice I offered Richard...<G>
I guess we are all passionate about something...
Pete.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
Peter E.C. Dashwood
<docd...@panix.com> wrote in message news:b66t0i$a9$1...@panix1.panix.com...
> >
> >If you would ignore this ignoramus, he would go away (I kill
> >filed him some time ago).
>
> Mr Thompson, the path you suggest is one which has been employed by
> others; personally, I try to limit my exchanges with Mr Wagner to simple
> matters of fact (his being wrong, for example, about ''incorrect' is
> metric while 'wrong' is moral' or the abovementioned 'you cannot add 1 to
> a date'). I did make a foray into communications about matters of food
> and have found him to ascribe things to me I never said; I'll try to avoid
> such 'merely social' communications in the future.
>
enjoy the most...
(This is no way casting aspersions on your other posts, which are always
worth reading...<G>)