Hello all!


Some of you batch gurus will be able to point out some
pitfalls I've missed, but let me explain first what this is
about.

I email out a little weekly journal newsletter to a group of ham radio folks I work with, our common interest assisting
vessels at sea, folks serving their country or faith abroad, etc.

One thing I've always wanted to implement was a bit of a
history section, keyed by date. These go out on Sunday
mornings, of course.

This batch would run at midnight utc on Sunday of course adn prepare the history information, compiling into it a file
that the weekly email generator code would find.

So, taking this Sunday's for example, the batch would look
in a defined directory for files named 0115.txt; 0116.txt; 0117 ... etc.

Easy enough done, stuff number of month and day into an env
var called %NEWS% using HOrst's logecho.
OF course I'm using HOrst's nset and count, as well as
ifnumber in this thing.

The first thing we need to do is see if the date's getting
toward roll over to next month.
That one's easy. Check if day of the month is 22 or
greater.

IF the date is 22 or greater we then need to create a
"turnover" file which will be used to create another
environment variable.

So here's how we're accomplishing that so far. the fun
comes once we've defined all this.
We start the set up for it to do its beautiful work like
this:


:: 300hist.bat
@echo off
:: desc: This batch is under construction
:: desc: function: Runs on Sundays 0000 utc or is triggered at that time. :: desc: helps us grab historic trivia for weekly journal
logecho $D | nset starter=$1
set checker=22
ifnumber %STARTER% biggerequivalthan %CHECKER > nul
if errorlevel 1 goto workit
:: if starter is bigger or equal to checker we may need to
:: turn over to a new month. IF not, we just cruise along.


set starter=
set checker=
goto regular
:workit
set starter=
set checker=
logecho $M | nset bump=$1
:: now we use HOrst's count to add one.

count BUMP +1
set checknum=10
:: environment variables are stored ignoring leading zeroes
:: unless you stuff them in. So we set checker to 10 and
:: test for smaller than, because if %BUMP% os a somg;e
:: digit we need to add a zero.
:: we're going to create a file to use to capture
:: data for the environment variable at turnover of month.
ifnumber %BUMP% smallerthan %CHECKNUM% > nul
if errorlevel 1 goto addzero
goto doit
:addzero
set checknum=
echo 0%BUMP%01 >> bumper.txt
set bump=
goto workout
:doit
set checknum=
echo %BUMP%01 >> bumper.txt
set bump=
goto workout
:workout
cd \working


:: now we see how many days are in the current month, so
:: that we turn over at the appropriate place utilizing the
:: file bumper.txt we created to set the new %NEWS%
:: env var for the appropriate day's history capture.
:: we already have repnum.txt with the data inside. HEnce:
nset repnum=$1 <repnum.txt
cd \
logecho $M%REPNUM% >> turnover.txt
set repnum=
nset turnover=$1 <turnover.txt
del turnover.txt

That's the setup, now let me show in you next msg how this
works if turnover not needed.

Regards,
Richard
---
* Origin: (1:116/901)

HI Folks,

following up a message from Richard Webb to all:

One thing I've always wanted to implement was a bit of a
history section, keyed by date. These go out on Sunday
mornings, of course.

This batch would run at midnight utc on Sunday of course adn prepare
the history information, compiling into it a file
that the weekly email generator code would find.

A couple of changes since that post ...

First, I came to the brilliant realization that when HOrst's count increments or decrements a numeric environment
variable it's going to nuke the leading 0 if it exists.

So, we rename all the files for months under 10 such as
315.* 518.* etc. etc.

This means we set the %NEWS% environment variable a little
bit differently as well, by playing with HOrst's count then
moving it to where we want it, to lose any leading 0 that
would have been generated.

AS for what happens with the month turnover, we could lose
the prepend leading 0 to single digit months code of course, and then use ifnumber to see if %NEWS% and %TURNOVER% are
equal. IF so, we reset %NEWS% to the date found in
%TURNOVER%
and call another batch. Because of this, we also create
semaphores for each day in the original batch.

An example, since we'll always have the proper date for
Sundays we don't need to test for turnover, but on mondays ...
:chkmon
count NEWS +1
ifnumber %NEWS% biggerequivalthan %TURNOVER%
if errorlevel 255 goto conmon
if errorlevel 1 goto turnover
goto conmon
:conmon
echo %NEWS% >> c:\hold\work\mon.sem
call mmsnhist.bat %NEWS%
if exist c:\hold\work\history.dat goto monhist
goto chktue

So, if turnover is reached, we branch to that label, reset
the env var %NEWS% and call rollhist.bat which checks for
the flag files, branches, and moves on.

Still open to suggestions if anybody sees an easier way to
roll this.


Regards,
Richard
---
* Origin: (1:116/901)

Hi! Richard,

In a message to All you wrote:

One thing I've always wanted to implement was a bit of a
history section, keyed by date. These go out on Sunday
mornings, of course.

Uh, huh.

This batch would run at midnight utc on Sunday of course adn prepare
the history information, compiling into it a file that the weekly
email generator code would find.

Okay, I want to look at your system... no scripting at this point...

The daily files consist of some sort of activity logs? The weeklies consist of
a compilation for the previous week?

I would be looking at a system something similar to...

-----8<-----C-U-T--H-E-R-E----->8-----
remark: YYYYMMDD.txt is the daily transaction/logging file
remark: the weekly file weekMMYY.txt is built on-the-fly after each day's logging

DAILY_LOOP
LOGGING_LOOP
YYYYMMDD.txt = [YYYYMMDD.txt + (new activity log entry)]
END LOGGING_LOOP
weekMMYY.txt = [weekMMYY.txt + YYYYMMDD.txt]
archive YYYYMMDD.txt
kill YYYYMMDD.txt
END DAILY_LOOP

WEEKLY_JOB
post weekMMYY.txt in email
archive weekMMYY.txt
kill weekMMYY.txt
END WEEKLY_JOB
-----8<-----C-U-T--H-E-R-E----->8-----

This system probably varies a little from what you intended. Can you explain what I might be missing?

So, taking this Sunday's for example, the batch would look
in a defined directory for files named 0115.txt; 0116.txt; 0117 ...
etc.

Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)

(With the system I propose, those files won't be necessary. The weekly file would be built-up during the week's daily operations. They would still be available in the relevant archive if something screws up, somewhere.)

Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

Cheers,
Paul.

---
* Origin: !WARNING(205): Power not on. Press any key to continue. (3:640/384)

Hell Paul,

On Fri 2012-Jan-13 17:23, Paul Quinn (3:640/384) wrote to Richard Webb:

One thing I've always wanted to implement was a bit of a
history section, keyed by date. These go out on Sunday
mornings, of course.

Uh, huh.

This batch would run at midnight utc on Sunday of course adn prepare
the history information, compiling into it a file that the weekly
email generator code would find.

Okay, I want to look at your system... no scripting at this point...

The daily files consist of some sort of activity logs? The weeklies consist of a compilation for the previous week?

I would be looking at a system something similar to...

DO that with station logs, but this is for the whole group.
The weekly file is mainly what vessels have used us and
that's already done.

There are a couple of sections that prepend all this
hwoever, and they're built as well to generate this email.
they're a "welcome newcomers" type section, a logistics, who needs pinch hitters, etc. section, etc.

<snip>

So, taking this Sunday's for example, the batch would look
in a defined directory for files named 0115.txt; 0116.txt; 0117 ...
etc.

Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)

(With the system I propose, those files won't be necessary. The

weekly file would be built-up during the week's daily operations.
They would still be available in the relevant archive if something
screws up, somewhere.)

Yep, had to lose the leading 0 in single digit months anyway because when HOrst's count does its thing it loses it. I'm
sure you saw that later.

These are still quite relevant as I might not be around.
For example, in April the Birthdays of Samuel MOrse, the
inventor of MOrse Code, and Gugliemo Marconi are both in
files for those dates.
So yes, still necessary as these aren't quite logging
functions per se. That part's already written and working
great.

Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

There's a good example of what I've had to wrestle with for
this part of it. This thing will go out on January 29, as
usual, discussing anything of significance for Sunday the
29th, Monday the 30th, the 31st, Wednesday the 1st, 2nd, 3rd and finally the 4th.
The "logging" part of this as I say is already done,
automagically, on the fly. What isn't and has required some manual intervention by me was looking through these little
text files to find historic trivia to stuff in there. For
example, had this been built last week it would have noted
that Thursday the 12th was the 2nd anniversary of the big
quake in Haiti. A few ham ops really used our network
services to get help to people who needed it. So that would of course be in 112.txt, (was 0112.txt) and would have been
automagically posted in last Sunday's history section.
Except, I never got to looking through those last weekend,
hence doing the automation shuffle <g..

HEre's another wrinkle. the batch it calls looks for two
files. For example, for today it would look in that
director for 113.all, and 113.txt as well.
the *.all file of course is retained, it has data we'll want to stuff in next year. the *.txt file will be deleted after it's appended.

Oh btw, the example i showed yesterday in a subsequent
message got changed up a bit too. I did the ifnumber test
before we incremented the environment variable by one, my
brain woke up and saw I had it in the wrong place, and also
had the test greater than or equal, or biggerequivalthan as
he calls it, and wanted "equival" instead.
YEs I ran it with some testbed stuff and stumbled across
that one <g>.

Regards,
Richard
---
* Origin: (1:116/901)

Hello Paul,

following up a message from Richard Webb to Paul Quinn:

I would be looking at a system something similar to...

DO that with station logs, but this is for the whole group.
The weekly file is mainly what vessels have used us and
that's already done.

There are a couple of sections that prepend all this
hwoever, and they're built as well to generate this email.
they're a "welcome newcomers" type section, a logistics, who needs
pinch hitters, etc. section, etc.

Meat of this "weekly journal" is made up of info regarding
vessels who file position and weather reports via our
network while offshore.
I'll grab one of those entries from this week and parse it
to explain. Btw, that code is already written, and working
pretty darned well. This is year #5 of this journal in fact <g>.

First, the raw entry in my data file ...


01/10/2012 01:13 KC2TIU W1CT 12-38.0n 061-21.0w SV TSAMAYA 2 POB

FIrst you can see that the entry was posted as of 01/10/2012 at 01:13 utc.

The call sign of the vessel's ham op was kc2tiu. The guy
who took the data was w1ct.

So, on Sunday mornings a batch (already created and working) parses each entry in the weekly data file. IT shows readers the last entry we have for kc2tiu, and looks in another file for info about the sailing vessel, such as marine call
signs, communications capabilities, operator's name, marine
service call sign if known, etc.

IN another section of the journal it looks at entries posted by JOhn, w1ct, or other posters. IT then tells readers how
many reports JOhn took last week, how many over the month,
how many over the year, and how many since my system started tracking this data. So the "next week in history ... "
section is just part of this, and the current one under
development <grin>.




Regards,
Richard
---
* Origin: (1:116/901)

HI Paul,

following up a message from Richard Webb to Paul Quinn:

Okay, I want to look at your system... no scripting at this point...

The daily files consist of some sort of activity logs? The weeklies consist of a compilation for the previous week?

<snip>

Ermm... shouldn't that be 0108.txt; 0109.txt; 0110.txt... :)

Yep, had to lose the leading 0 in single digit months anyway because
when HOrst's count does its thing it loses it. I'm
sure you saw that later.

YEp, and it's doing its thing quite nicely.

Oh, yeah, the main program, it does everything to a file
which is named "boatweek.lst" which is the email product
itself.
Within this is current logistical notes, notes on regular
net participants, and of course the info regarding vessels
underway I showed you a sample of, a short humor piece, and
maybe some additional stats.

Question. What happens Sunday 5 February, with the 30th & 31st of January's logging? Do they get caught up in "week0212.txt"?

There's a good example of what I've had to wrestle with for
this part of it. This thing will go out on January 29, as
usual, discussing anything of significance for Sunday the
29th, Monday the 30th, the 31st, Wednesday the 1st, 2nd, 3rd and
finally the 4th.
The "logging" part of this as I say is already done,
automagically, on the fly. What isn't and has required some manual intervention by me was looking through these little
text files to find historic trivia to stuff in there. For
example, had this been built last week it would have noted
that Thursday the 12th was the 2nd anniversary of the big
quake in Haiti. A few ham ops really used our network
services to get help to people who needed it. So that would of
course be in 112.txt, (was 0112.txt) and would have been
automagically posted in last Sunday's history section.
Except, I never got to looking through those last weekend,
hence doing the automation shuffle <g..

Yep, we do a rollover thing, so that if when the environment variable is incremented we now have the next month, such as
what happenedon February 29, we now roll it over, invoke a
different batch which is essentially the same code. It
played flawlessly on January 29 with the rollover to
February in midweek, so should do the same for February.

The whoel thing keys for number of days in a given month off a little text file
which contains that info which my system
creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be quite happy rolling over as
it's supposed to when invoked on 2/26.

Regards,
Richard
---
* Origin: (1:116/901)

Hi! Richard,

On Tue, 07 Feb 12, you wrote to me:

The whoel thing keys for number of days in a given month off a little
text file which contains that info which my system creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be
quite happy rolling over as it's supposed to when invoked on 2/26.

You know, I was only thinking about this the other day. I had thought to ask how the doo-hickey had operated during the rollover, and was gonna prompt you.
I'm glad you got in first. Thanks for the update. :)

Cheers,
Paul.

---
* Origin: *Real* programmers use COPY CON MYAPP.ZIP (3:640/384)

The whoel thing keys for number of days in a given month off a
little text file which contains that info which my system
creates at the beginning of each month. Of course I have to edit
it for leap years, since by default it assumes February has 28
days.

you know that you can automatically handle this with a small bit of math, right? i'd have to look at some code to make sure i state it correctly but leap
years can be determined by current year div 4 but there's also a 400 involved... this is why i need to take a sec later on and look at the real formula... then you can have an array with all of the month days count and automatically adjust FEB when it has 29 days ;)

)\/(ark


* Origin: (1:3634/12)

Hi Paul,

On Wed 2012-Feb-08 09:42, Paul Quinn (3:640/384) wrote to Richard Webb:

The whole thing keys for number of days in a given month off a little
text file which contains that info which my system creates at the beginning of each month. Of course I have to edit it for leap years, since by default it assumes February has 28 days. So, it should be
quite happy rolling over as it's supposed to when invoked on 2/26.

You know, I was only thinking about this the other day. I had
thought to ask how the doo-hickey had operated during the rollover,
and was gonna prompt you. I'm glad you got in first. Thanks for
the update. :)

YEp, I watched it run first couple weeks, I was pretty sure
it would operate alright during the rollover, but now I feel safe letting it run when I'm not here to attend it <g>. Had to fix a couple minor errors the first week it ran, but
nothing fatal, I'm rather proud of myself. That means I'll
break something really good next time i get to fiddling i
guess <g>.

YOu know I was really surprised, as I had a house full of
stepdaughter and her boyfriend and their zoo going on at the time, which was one reason I was finding something to do
that would keep them away from me. If I was doing a lot of
radio they'd be in here doing the "hey wow cool ... " thing, but programming, they'd leave me alone, she's mouse potato
gui only, and he's not literate enough to even handle that
one, so I figured I'd leave them with their version of Jerry Springer dealing with her mother in the other room and bury
myself in a programming project.

Regards,
Richard
---
* Origin: (1:116/901)

Hi! mark,

In a message to Richard Webb you wrote:

edit it for leap years, since by default it assumes February has
28 days.

you know that you can automatically handle this with a small bit of
math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved...

I think the 400 test is for century years, like: 1900, 2000, 2100 & so on.

this is why i need to take a sec later
on and look at the real formula... then you can have an array with
all of the month days count and automatically adjust FEB when it has
29 days ;)

How about a bit of something in some old Turbo-C...

--- 8< ---
int leap_yr_test(int test_yr)
/*
function determines if a given year is a leap year
Uses: 'test_yr' which is defined prior to function call
Pre: none
Post: a boolean value is returned indicating TRUE/FALSE
*/
{
/* local variables */
int result = FALSE;

switch (test_yr % 100)
{
case 0 : if ((test_yr % 400) == 0) result = TRUE; break;
default : if ((test_yr % 4) == 0) result = TRUE;
}
/* end switch. */
return(result);
}
/* end function. */
--- 8< ---

=:)

Cheers,
Paul.

---
* Origin: If it itches, it will be scratched. (3:640/384)

Hi! Richard,

On Wed, 08 Feb 12, you wrote to me:

even handle that one, so I figured I'd leave them with their version
of Jerry Springer dealing with her mother in the other room and bury myself in a programming project.

I've gone one better, and have moved downstairs again for summer. (The house is a 100-odd year old place, high-set, where the huge shady area downstairs is about 5-6 degrees cooler than 'up there'... and away from the womenfolk.)

These days I tend to play a lot with various virtual machines. Most of the older DOS ones don't get used but the Windows ones, except the WinXP box, run pretty much 24/7. Check out...

http://members.dodo.com.au/~colgilly/hideaway/Page.html (for some of them.)

I've recently commenced work on another Linux vBox (Xubuntu v11.10) which will eventually replace the two Win98 vBoxen and hopefully one of the Linux vBoxes as well. There's never enough time in the day 'cause if I'm not actually tinkering then I'm reading & researching.

Cheers,
Paul.

---
* Origin: Any day spent above ground is a good one. (3:640/384)

HI Mark,

On Tue 2012-Feb-07 22:34, mark lewis (1:3634/12) wrote to Richard Webb:

The whoel thing keys for number of days in a given month off a
little text file which contains that info which my system
creates at the beginning of each month. Of course I have to edit
it for leap years, since by default it assumes February has 28
days.

you know that you can automatically handle this with a small bit of
math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved... this is why i need to take a sec
later on and look at the real formula... then you can have an array
with all of the month days count and automatically adjust FEB when
it has 29 days ;)

YEp, knew about the divisible by four part, just hadn't
played with that in the code that runs Feb 1 yet. Would
like to see that other formula when you find it. I'm sure
we could plug it in. TImo's batch calculator does some
interesting things.

Think I'd heard of the other one too, but was thinking about the divisible by 4
bit, just hadn't implemented that one
<g>.

Regards,
Richard
---
* Origin: (1:116/901)

HI Paul,

On Wed 2012-Feb-08 15:22, Paul Quinn (3:640/384) wrote to Mark Lewis:

Hi! mark,

edit it for leap years, since by default it assumes February has
28 days.

you know that you can automatically handle this with a small bit of
math, right? i'd have to look at some code to make sure i state it correctly but leap years can be determined by current year div 4 but there's also a 400 involved...

I think the 400 test is for century years, like: 1900, 2000, 2100 &
so on.

Think you might be right, I'm pre coffee at the moment but
that sounds right.

this is why i need to take a sec later
on and look at the real formula... then you can have an array with
all of the month days count and automatically adjust FEB when it has
29 days ;)

How about a bit of something in some old Turbo-C...

--- 8< ---
int leap_yr_test(int test_yr)
/*
function determines if a given year is a leap year
Uses: 'test_yr' which is defined prior to function call
Pre: none
Post: a boolean value is returned indicating TRUE/FALSE
*/
{
/* local variables */
int result = FALSE;

Ah so if one were to compile that does it give you an
errorlevel if true and another if false?
test_yr easy to define, especially as an environment
variable as in
logecho $C$Y | nset test_yr=$1
USes HOrst's logecho and nset.

switch (test_yr % 100)
{
case 0 : if ((test_yr % 400) == 0) result = TRUE; break;
default : if ((test_yr % 4) == 0) result = TRUE;
}
/* end switch. */
return(result);
}
/* end function. */
--- 8< ---

=:)

INteresting!

Regards,
Richard
---
* Origin: (1:116/901)

Hi Paul,

On Wed 2012-Feb-08 15:56, Paul Quinn (3:640/384) wrote to Richard Webb:

even handle that one, so I figured I'd leave them with their version
of Jerry Springer dealing with her mother in the other room and bury myself in a programming project.

I've gone one better, and have moved downstairs again for summer.
(The house is a 100-odd year old place, high-set, where the huge
shady area downstairs is about 5-6 degrees cooler than 'up there'...
and away from the womenfolk.)

Except for my lady I finally got them moved out a couple
weeks ago. Too much crazy for me.

These days I tend to play a lot with various virtual machines. Most
of the older DOS ones don't get used but the Windows ones, except
the WinXP box, run pretty much 24/7. Check out...

http://members.dodo.com.au/~colgilly/hideaway/Page.html (for some
of them.)

Sounds like you're having fun. I'm busy with lots of radio
projects still, trying to sell some equipment to regroup the business scaled down a little bit, with hopes of returning
to New Orleans this summer.


Regards,
Richard
---
* Origin: (1:116/901)

this is why i need to take a sec later on and look at the real
formula... then you can have an array with all of the month days
count and automatically adjust FEB when it has 29 days ;)

How about a bit of something in some old Turbo-C...

pretty neat... but it looks like it is missing something...

function leapyear( year : integer) : boolean;
{ Returns true if YEAR is a leaplear
A year is a leap year if it is evenly divisible
by 4 except :
if it is divisible by 100 then :
it is NOT a leap year unless it is divisible
by 400 but not 4000

Thus 2000 (divisible by 400 but not by 4000) is a leap year
but 4000 (divisible by 4000) is NOT a leap year.
Reference : Introductory Astronomy and Astrophysics, page 61
By E. v. P. Smith and K. C. Jacobs - (C) 1973 W. B. Saunders Co.}

{ By Jud McCranie, Jan. 4, 1987 }
{ Revised Jan. 5, 1987 }

begin
leapyear := (year mod 4 = 0);

if year mod 100 = 0
then leapyear := (year mod 400 = 0) and (year mod 4000 > 0);

end; {*** leap year ***}


)\/(ark


* Origin: (1:3634/12)

YEp, knew about the divisible by four part, just hadn't
played with that in the code that runs Feb 1 yet. Would
like to see that other formula when you find it. I'm sure
we could plug it in. TImo's batch calculator does some
interesting things.

i just posted pascal code for it... the modulo arithmetic (aka clock math) routine is needed for ease of coding... the full explanation of how to determine a leapyear is contained in the comments at the start of the code i posted...

)\/(ark


* Origin: (1:3634/12)

Hi Mark,

On Wed 2012-Feb-08 14:53, mark lewis (1:3634/12) wrote to Richard Webb:

YEp, knew about the divisible by four part, just hadn't
played with that in the code that runs Feb 1 yet. Would
like to see that other formula when you find it. I'm sure
we could plug it in. TImo's batch calculator does some
interesting things.

i just posted pascal code for it... the modulo arithmetic (aka clock
math) routine is needed for ease of coding... the full explanation
of how to determine a leapyear is contained in the comments at the
start of the code i posted...

YEp, now if I had the compiler I'd compile it. We'll ahve
to bounce this around some more <g>.

Btw my error when I commented divisible by 400 isntead of
100, pre coffee <g>.

Regards,
Richard
---
* Origin: (1:116/901)

Hi! mark,

On Wed, 08 Feb 12, you wrote to me:

How about a bit of something in some old Turbo-C...

pretty neat... but it looks like it is missing something...

Not just neat! It was a part of a programming assignment that helped me win an
'honours' pass for the language at a tech college... 20-something years ago. However...

function leapyear( year : integer) : boolean; { Returns true if YEAR

[ ...trim... ]

Reference : Introductory Astronomy and Astrophysics, page 61
By E. v. P. Smith and K. C. Jacobs - (C) 1973 W. B. Saunders Co.}
{ By Jud McCranie, Jan. 4, 1987 } { Revised Jan. 5, 1987 }

Now, that's neat. ;-) I didn't have that reference available and was only able to verify date information from an encyclopedia, with a table that covered
from 1582 to 3099. That was sufficient for the assignment (and was probably another bonus point in my favour, as I was the only one in the class to verify the output thusly). Even though the tutor was an amateur mathematician he didn't want to belabour the point with a bunch of rowdy, smelly students who were only in it for the computing credits.

Cheers,
Paul.

---
* Origin: This tagline made from 100% recycled electrons. (3:640/384)

Hi! Richard,

On Wed, 08 Feb 12, you wrote to me:

How about a bit of something in some old Turbo-C...

--- 8< ---
int leap_yr_test(int test_yr)
/*
function determines if a given year is a leap year
Uses: 'test_yr' which is defined prior to function call
Pre: none
Post: a boolean value is returned indicating TRUE/FALSE
*/

Ah so if one were to compile that does it give you an errorlevel if
true and another if false? test_yr easy to define, especially as an environment variable as in
logecho $C$Y | nset test_yr=$1 USes HOrst's logecho and nset.

Nah. It's only a 'function' stub. You would need to wrap a main program section around it, and call the function.

Have a look at a couple of other utils from Horst's archive. There's one that might simplify the job called "what.com". Another one that might help is "isdate.com". I haven't played with either, so caveat emptor. ;-)

Cheers,
Paul.

---
* Origin: In CyberSpace, no one can hear you scream. (3:640/384)

HI Paul,

On Thu 2012-Feb-09 11:58, Paul Quinn (3:640/384) wrote to Richard Webb:

How about a bit of something in some old Turbo-C...

--- 8< ---
int leap_yr_test(int test_yr)
/*
function determines if a given year is a leap year

<snip>

Ah so if one were to compile that does it give you an errorlevel if
true and another if false? test_yr easy to define, especially as an environment variable as in
logecho $C$Y | nset test_yr=$1 USes HOrst's logecho and nset.

Nah. It's only a 'function' stub. You would need to wrap a main
program section around it, and call the function.

Have a look at a couple of other utils from Horst's archive.
There's one that might simplify the job called "what.com". Another
one that might help is "isdate.com". I haven't played with either,
so caveat emptor. ;-)

I've looked at those, but not with an eye toward this. I
get over this creeping crud I'll have to do that.

Regards,
Richard
---
* Origin: (1:116/901)

HI Paul,

following up a message from Richard Webb to Paul Quinn:

<snip>

Have a look at a couple of other utils from Horst's archive.
There's one that might simplify the job called "what.com". Another
one that might help is "isdate.com". I haven't played with either,
so caveat emptor. ;-)

Just had a look at what.com from HOrst, used Timo's level to test waht it does when given the command

"what year"

Since we're 2012 it returned 112. <hmmm> That might be
worth a look.

When my daily batch invokes first of month batch and we're
at February 1 we can always call a batch which runs wht.com, checks for errorlevels.
I'd have to set 'em up as

if errorlevel 140 goto leap
if errorlevel 139 goto normal
if errorlevel 137 goto normal
if errorlevel 136 goto leap

etc. on down. If we go to normal it dumps the number 28 in
that little text file we'll use at the end of the month, and at different times
during the month to see how many days
we've got and plug it into an environment variable when
necessary.

I've got a eyar to play with that one, but I think that'll
do it!

Thanks for reminding me of those. I use some other tools
for handling day of the month, so never really looked at
either one that closely. I've got all of HOrst's little
tools on my dos path though, and the documentation handy,
just because i know there will be just the occasion when
they're the right tool <g>.




Regards,
Richard
---
* Origin: (1:116/901)

Hi! Richard,

On Thu, 09 Feb 12, you wrote to me:

Just had a look at what.com from HOrst, used Timo's level to test
waht it does when given the command

"what year"

[ ...trimmed... ]

I've got a year to play with that one, but I think that'll
do it!

I had in mind something simple, like...

-+- 8< ---
WHAT day
IF ERRORLEVEL 1 GOTO NEWMONTH

:NEWMONTH
:: Do your processing for a following new month...
--- 8< ---

That way it doesn't matter what month, or whether the year is a leap year or not, it just does a new week's worth of post-able notes over the rollover period.

Thanks for reminding me of those. I use some other tools
for handling day of the month, so never really looked at
either one that closely. I've got all of HOrst's little
tools on my dos path though, and the documentation handy,
just because i know there will be just the occasion when
they're the right tool <g>.

Me too. I'm looking for something to use ISDATE with now... there must something I can invent... It looks too groovy to leave it alone. ;-)

Cheers,
Paul.

---
* Origin: Smash forehead on keyboard to continue... (3:640/384)

HI Paul,

On Fri 2012-Feb-10 14:58, Paul Quinn (3:640/384) wrote to Richard Webb:

I've got a year to play with that one, but I think that'll
do it!

I had in mind something simple, like...

-+- 8< ---
WHAT day
IF ERRORLEVEL 1 GOTO NEWMONTH

:NEWMONTH
:: Do your processing for a following new month...
--- 8< ---

Take care of all that with a process that runs once a day,
does some specifics for what day of the week, gets the day
of the month, does some other things accordingly.

When we roll over to a new month on the first we capture how many days it has for other reasons anyway, so that capture
is used in this little history thing that runs 0000 utc
Sunday morning.

I use days in the month, again at the end of the month to
average how many vessels logged per day, posts in a couple
of echoes/newsgroups, etc.

Were I building such a system from scratch though I'd
probably look at something such as you showed there.

That way it doesn't matter what month, or whether the year is a leap
year or not, it just does a new week's worth of post-able notes over
the rollover period.

Still would because of the way I end up doing things around
here.

Regards,
Richard
---
* Origin: (1:116/901)