Home > Archive > Cobol > June 2006 > Week Number in Fujitsu cobol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Week Number in Fujitsu cobol
|
|
| Euromercante 2006-06-17, 7:55 am |
| How i can get w number in Fuitsu COBOL?
Many Thanks
JM
| |
|
|
|
|
| Frederico Fonseca 2006-06-17, 7:55 am |
| On Wed, 14 Jun 2006 10:20:34 +0100, "Euromercante"
<nospam_eurogest@euromercante.pt> wrote:
>How i can get w number in Fuitsu COBOL?
>
>Many Thanks
>JM
>
Further to my post search google for a thread i CLC "help, calculate
the number of the w in a year" where someone was asking for the
same question with RM/COBOL. Same answers applies here.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
|
|
| Oliver Wong 2006-06-17, 7:55 am |
|
"Euromercante" <nospam_eurogest@euromercante.pt> wrote in message
news:newscache$9awu0j$no3$1@newsfront4.netvisao.pt...
> Thanks Frederico.
>
> How can get JulianDay? (1 to 366, correct?)
You could hardcode a list of offsets based on the month (e.g. January =
0, February = 31, etc. with careful consideration for leap years), and add
the offset plus the date.
So February 20th would be February's offset (31) plus 20 = 51.
- Oliver
| |
| Oliver Wong 2006-06-17, 7:55 am |
|
"Oliver Wong" <owong@castortech.com> wrote in message
news:g7Wjg.40471$771.335@edtnps89...
>
> "Euromercante" <nospam_eurogest@euromercante.pt> wrote in message
> news:newscache$9awu0j$no3$1@newsfront4.netvisao.pt...
>
> You could hardcode a list of offsets based on the month (e.g. January =
> 0, February = 31, etc. with careful consideration for leap years), and add
> the offset plus the date.
>
> So February 20th would be February's offset (31) plus 20 = 51.
Note that this actually gives you the day of the year (a value between 1
and 366), not the JulianDay, which is the number of days that have elapsed
since Monday, January 4713 BC in the proleptic Julian Calendar (a value from
potentially negative infinity to positive infinity).
- Oliver
| |
| Euromercante 2006-06-17, 7:55 am |
| it is not easy !!?
"Oliver Wong" <owong@castortech.com> wrote in message
news:o9Wjg.40496$771.4752@edtnps89...
>
> "Oliver Wong" <owong@castortech.com> wrote in message
> news:g7Wjg.40471$771.335@edtnps89...
=[color=darkred]
add[color=darkred]
>
> Note that this actually gives you the day of the year (a value between
1
> and 366), not the JulianDay, which is the number of days that have elapsed
> since Monday, January 4713 BC in the proleptic Julian Calendar (a value
from
> potentially negative infinity to positive infinity).
>
> - Oliver
>
| |
| Frederico Fonseca 2006-06-17, 7:55 am |
| On Wed, 14 Jun 2006 16:34:44 +0100, "Euromercante"
<nospam_eurogest@euromercante.pt> wrote:
>Thanks Frederico.
>
>How can get JulianDay? (1 to 366, correct?)
>
>
From the example I posted you will notice a "Accept day-1 from DAY.
This returns a value made up of YYDDD where DDD is the number of days
since January 1st.
If you wish to get the Julian day of a particular date then the
following would be an acceptable solution.
01 WORK-DATE.
02 W-CCYY PIC 9(4).
02 W-MONTH PIC 9(2).
02 W-DAY PIC 9(2).
01 WORK-DATE-PRV-YEAR.
02 W-CCYY-1 PIC 9(4).
02 W-MONTH-1 PIC 9(2).
02 W-DAY-1 PIC 9(2).
01 WORK-SERIAL PIC S9(9) BINARY.
01 START-YEAR PIC S9(8).
01 WORK-NUM PIC 9(8).
01 DAYS PIC 9(3) USAGE DISPLAY.
PROCEDURE DIVISION.
SUBTRACT 1 FROM W-CCYY GIVING W-CCYY-1
MOVE 12 TO W-MONTH-1.
MOVE 31 TO W-DAY-1.
MOVE WORK-DATE TO WORK-NUM.
COMPUTE WORK-SERIAL = FUNCTION INTEGER-OF-DATE(WORK-NUM).
MOVE WORK-DATE-PRV-YEAR TO WORK-NUM.
COMPUTE START-YEAR = FUNCTION INTEGER-OF-DATE(WORK-NUM).
COMPUTE DAYS = WORK-SERIAL - START-YEAR.
DISPLAY "julian day for date " WORK-DATE " is " DAYS
" or " W-CCYY DAYS
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| James J. Gavan 2006-06-17, 7:55 am |
| Euromercante wrote:
> it is not easy !!?
I wouldn't call it hard :-) - but can get a little complicated.
Familiarize yourself with the Date Functions in the Fujitsu on-line help
file and give a good read to the ISO Date Standard that Frederico
referenced, (which is Gregorian based). Store ALL dates as ccyy-mm-dd
because you then have an automatic sort key. (I'm not into accounting so
as per ISO, I store ccyy-mm ).
Given that you wanted to calculate interest, say at 2.5% per day for the
period 2005-03-27 to 2006-June-11 inclusive - this is achievable by
using a combination of Date Functions.
What is your particular interest in the W Number ? If it is
associated with financial systems use the tried and true manual methods.
Back when I was in accounting, depending upon the company, some used :-
- a 13 Period year consisting of 4 ws (28 days). But 13 x 28 doesn't
give you 365, so they tacked on the additional one day to Period 13.
- another choice was 4,4,5 (4 ws, 4 ws, 5 ws = a Quarter); odd
days get tacked on to the fourth Quarter.
- not used often, but a cumulative w count based on the day name when
2006 Jan 01 started. The above can give you 52 or 53 w years; so tack
on any remaining days to W 53 - or perhaps the accountants want them
tacked on to W 52.
So some senior bean-counter would spend perhaps half an hour determining
the 'official' w or period ends which became the company's calendar
for the coming year.
Whichever method above, if that's what you are after :-
Use a small computer file holding the official corporate calendar table
for the option you are interested in :-
- Period # and calendar ending date
- Number of ws ( 4 or 5), Quarter # and the calendar ending date
- W # and calendar ending date
You don't have much choice - the accountants will tell you what they
want - and it wont necessarily fit in with clean computer logic !
Jimmy
| |
| HeyBub 2006-06-17, 7:55 am |
| Euromercante wrote:
> Thanks Frederico.
>
> How can get JulianDay? (1 to 366, correct?)
>
The "Julian Day" is the number of days that have elapsed since Monday,
January 1st, 4713 BC. Today is almost JD 2,500,000. Of course, since they
didn't have COBOL back then, that Monday is the zeroth day.
| |
| Euromercante 2006-06-17, 7:55 am |
| I only want to make a report, totalizing amounts and values for w Nr.
Thanks
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:kLYjg.27034$Mn5.26100@pd7tw3no...
> Euromercante wrote:
>
> I wouldn't call it hard :-) - but can get a little complicated.
>
> Familiarize yourself with the Date Functions in the Fujitsu on-line help
> file and give a good read to the ISO Date Standard that Frederico
> referenced, (which is Gregorian based). Store ALL dates as ccyy-mm-dd
> because you then have an automatic sort key. (I'm not into accounting so
> as per ISO, I store ccyy-mm ).
>
> Given that you wanted to calculate interest, say at 2.5% per day for the
> period 2005-03-27 to 2006-June-11 inclusive - this is achievable by
> using a combination of Date Functions.
>
> What is your particular interest in the W Number ? If it is
> associated with financial systems use the tried and true manual methods.
> Back when I was in accounting, depending upon the company, some used :-
>
> - a 13 Period year consisting of 4 ws (28 days). But 13 x 28 doesn't
> give you 365, so they tacked on the additional one day to Period 13.
>
> - another choice was 4,4,5 (4 ws, 4 ws, 5 ws = a Quarter); odd
> days get tacked on to the fourth Quarter.
>
> - not used often, but a cumulative w count based on the day name when
> 2006 Jan 01 started. The above can give you 52 or 53 w years; so tack
> on any remaining days to W 53 - or perhaps the accountants want them
> tacked on to W 52.
>
> So some senior bean-counter would spend perhaps half an hour determining
> the 'official' w or period ends which became the company's calendar
> for the coming year.
>
> Whichever method above, if that's what you are after :-
>
> Use a small computer file holding the official corporate calendar table
> for the option you are interested in :-
>
> - Period # and calendar ending date
> - Number of ws ( 4 or 5), Quarter # and the calendar ending date
> - W # and calendar ending date
>
> You don't have much choice - the accountants will tell you what they
> want - and it wont necessarily fit in with clean computer logic !
>
> Jimmy
| |
|
| In article <newscache$ns4y0j$4r5$1@newsfront4.netvisao.pt>,
Euromercante <nospam_eurogest@euromercante.pt> wrote:
>I only want to make a report, totalizing amounts and values for w Nr.
That's nice... but answering a few questions might help others to help you
with this...
.... questions like 'how often will this report be run?' and 'What is the
anticipated transaction volume?' and 'Is it for a single installation or
should it be parameterised so as to be able to run for multiple bases,
that is, is it for a single 'store' or will it be for a series of 'stores'
in a group, a series of groups in a division, etc?'
All of these are factors to be considered in your design.
DD
| |
|
|
|
|
|
| In article <KaEkg.43471$iF6.33049@pd7tw2no>,
James J. Gavan <jgavandeletethis@shaw.ca> wrote:
>Rick Smith wrote:
>
>To which one could further add, are you using a conventional calendar
>year starting at January 01, or perhaps a company fiscal year starting
>say on 1st April, and what if 1st January or 1st April falls on a Friday
>or a Saturday - what does your first w consist of ?
Hmmmmm... this might be seen as a subset of 'Is it for a single
installation or should it be parameterised so as to be able to run for
multiple bases, that is, is it for a single 'store' or will it be for a
series of 'stores' in a group, a series of groups in a division, etc?'';
if there is more than one installation on which reporting is required then
it might be concluded - especially in These Modern Times of Globalised
Corporations - that different installations run on different calendars...
a calendar used in London (eg, 16 Jun 2006) might not be the same as one
used in Jerusalem (20 Sivan 5766) might not be the same as one used in
Jeddah (Jumada-al-Oola 1427).
But... this may all be a bit of premature pirouetting, dancing before some
simple crawling-rules are established. I'd be interested in seeing how
the questions of run-frequency and data-volume are answered, first.
DD
| |
| James J. Gavan 2006-06-17, 7:55 am |
| docdwarf@panix.com wrote:
> In article <KaEkg.43471$iF6.33049@pd7tw2no>,
> James J. Gavan <jgavandeletethis@shaw.ca> wrote:
>
>
>
> Hmmmmm... this might be seen as a subset of 'Is it for a single
> installation or should it be parameterised so as to be able to run for
> multiple bases, that is, is it for a single 'store' or will it be for a
> series of 'stores' in a group, a series of groups in a division, etc?'';
> if there is more than one installation on which reporting is required then
> it might be concluded - especially in These Modern Times of Globalised
> Corporations - that different installations run on different calendars...
> a calendar used in London (eg, 16 Jun 2006) might not be the same as one
> used in Jerusalem (20 Sivan 5766) might not be the same as one used in
> Jeddah (Jumada-al-Oola 1427).
>
> But... this may all be a bit of premature pirouetting, dancing before some
> simple crawling-rules are established. I'd be interested in seeing how
> the questions of run-frequency and data-volume are answered, first.
>
> DD
>
What's this - bullshit baffles brains :-) Your Jeddah - June
(Jumaa-al-Oola) comes out as Huzayran in Syria ! And as for the year
1427 - I knew I was right - that big chunk of sand still has a mindset
of the Middle Ages ! And howz about this :-
----------------------------------------------------------------------
Hello every body
We have finished writing a new complete jalali ( shamsi ) and hejri (
arabic) calendar and converting routines for Julian Calendar .
Now we are interested in merging it in evolution , so that it can
support them .
Any idea or help will be appreciated
Yours
Javad Nejati
*********************
Yeah, Arafat do please tell them to look into Arabeyes' ITL library
and see if there are any improvements that can be rolled in. There
is NO reason to duplicate work and it would be ideal if they opted
to lend a helping hand instead of reinventing the wheel :-)
Salam.
- Nadim
----------------------------------------------------------------------
This one is interesting on Arabic calendars. Oi Vey ! They even
acknowledge the Chosen People who moved back into Palestine :-
http://www.roxanefarabi.com/Culture...%20Calendar.htm
Not to be caught napping, Uncle Bill offers Microsoft support routines
for the Hijri calendar :-
http://www.microsoft.com/middleeast...icCalendar.aspx
Our enquirer could even google on 'Financial-Calendars' - not that I
think it will help him much.
I'm assuming he's probably talking one corporation - however even if it
has subsidiaries, likely they all have the same financial year-end to
produce a consolidated financial statement for the group. However -
globalization; certainly was occurring when I was using quill and ink,
but I tend to think globalization is a phenomenon of the past 20 years -
and if they do have different year-end dates, becomes a real stinker for
consolidation, particularly if they are intra-trading, (because of the
reconciliations involved).
All the above is interesting trivia - still doesn't help him with his
W Numbers :-)
Don't you dare retort, "I barely know what I think myself ..." - Google
first !
Jimmy
| |
|
| In article <pLLkg.54484$IK3.30157@pd7tw1no>,
James J. Gavan <jgavandeletethis@shaw.ca> wrote:
>docdwarf@panix.com wrote:
[snip]
[color=darkred]
>What's this - bullshit baffles brains :-)
I'm not sure... when folks start to believe I have some I might go about
seeing what it is that baffles them.
>Your Jeddah - June
>(Jumaa-al-Oola) comes out as Huzayran in Syria !
There's almost always 'Something More'... if there weren't then folks
might get fewer 2:am calls from the Prod crew.
[snip]
>Our enquirer could even google on 'Financial-Calendars' - not that I
>think it will help him much.
>
>I'm assuming he's probably talking one corporation - however even if it
>has subsidiaries, likely they all have the same financial year-end to
>produce a consolidated financial statement for the group. However -
>globalization; certainly was occurring when I was using quill and ink,
>but I tend to think globalization is a phenomenon of the past 20 years -
>and if they do have different year-end dates, becomes a real stinker for
>consolidation, particularly if they are intra-trading, (because of the
>reconciliations involved).
>
>All the above is interesting trivia - still doesn't help him with his
>W Numbers :-)
It might be interesting to see the responses to the several queries which
have been presented... I seem to recall one posting that gave me a
simultaneous heaviness-of-heart and wryness-of-smile because it read
something like 'You mean it isn't easy?'
>
>Don't you dare retort, "I barely know what I think myself ..." - Google
>first !
If doing a web-search first will help to determine 'what I think, myself'
then it might be time for Utter Despair. It's obvious that I should be
concerned about how the Space Aliens steal my brainwaves... now I have to
worry about the Google Spiders?
DD
| |
| William M. Klein 2006-06-19, 9:55 pm |
| When posting in a COBOL forum (such as this), I think it is entirely reasonable
to use the term "Julian date" as it is used in the COBOL Standard. See (for
example - not limited to here), page 569 of the '02 ISO Standard,
"The Julian date form is YYYYDDD, where YYYY represents the year and DDD
represents the ordinal date within that year."
That term MAY (probably does) have a different meaning in some contexts, but I
believe its meaning in a COBOL context is both clear and universally (or nearly
so) understood.
--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:1290r6isubat6de@news.supernews.com...
> Euromercante wrote:
>
> The "Julian Day" is the number of days that have elapsed since Monday, January
> 1st, 4713 BC. Today is almost JD 2,500,000. Of course, since they didn't have
> COBOL back then, that Monday is the zeroth day.
>
>
>
| |
| HeyBub 2006-06-19, 9:55 pm |
| William M. Klein wrote:
> When posting in a COBOL forum (such as this), I think it is entirely
> reasonable to use the term "Julian date" as it is used in the COBOL
> Standard. See (for example - not limited to here), page 569 of the
> '02 ISO Standard,
> "The Julian date form is YYYYDDD, where YYYY represents the year and
> DDD represents the ordinal date within that year."
>
> That term MAY (probably does) have a different meaning in some
> contexts, but I believe its meaning in a COBOL context is both clear
> and universally (or nearly so) understood.
>
Your point is well-taken. A neophyte COBOL programmer, however, not knowing
that the language defines its own universe, may pick up the lay definition
and become terribly  . Besides....
There was a time, not so very long ago, when even most COBOL types took
"Julian Date" in COBOL to mean YYDDD (not YYYY), thereby saving one whole
byte (when packed).
Not being totally oblivious to the COBOL world, I did try to warn COBOL
users that the "Julian Day" is zero-indexed, thereby not in conformance with
the universe as it is understood by COBOL programmers.
[color=darkred]
|
|
|
|
|