Hi Gerald.

29-Oct-02 04:15:20, Gerald Miller wrote to Jasen Betts


 GM> Hello Jasen,

 GM>     On Monday October 28 2002 at 20:02,
 GM>     Jasen Betts [3:640/531.42] wrote to Gerald Miller,
 GM>     about:  System check ???

 GM>>>>> I'm not familiar with the ISO format....

 JB>>>>  echo
 JB>>>> %{at}replace[2,d,%{at}replace[20,yy,%{at}replace[1,m,%{at}makedate[14936,4]]
 JB>>>> ]]
 JB>>>>                                                             /\
 JB>>>> :)                                                          ||

 GM>>> In your previous message, you had omitted the
",4" at the end,
 GM>>> but it still worked on my system. (???) Help me out and tell me
 GM>>> how you achieved the numbers "14936,4" and what is their
 GM>>> significance

 JB>>  14963 is 22nd of November 2020

 GM> Which is the day that I turn 75yo, if I should live that long.  ;-)

 JB>> That way I can replace "20" with "YY",
"1" with "M" and "2" with "D"

 JB>> the ",4" makes it use ISO format here (needs version 7 of 4dos)

 JB>> Here it says comes out of makedate as 2020-11-22 which gets translated
 JB>> to YYYY-MM-DD

 GM> I tried: "echo  %{at}makedate[14936,4]" and "echo 
%{at}makedate[14936]" and 
 GM> both 
 GM> times I got "11-22-20".  It's a little confusing - I
don't know if it's
 GM> dropping
 GM> the millennium 20 or the year 20?  I guess it may not matter much as it
 GM> stillyields up my system date format: MM-DD-YY....

It drops the century, for other date formats. 4dos 6 doesn't do multiple
formats in makedate so you just get your local format even if you stick the
,4 in there.


 GM>>> PATH\PROGRAM TO RUN           ³AFTER³        ³        ³DAYS ³
 GM>>>                               ³ DAYS³LAST RUN³NEXT RUN³ LEFT³ASK

 JB>> Why all the new fields? - aren't program, After-days, last-run and ask
 JB>> enough ? is it so you can add some new scheduling rules?

 GM> I hadn't thought about the possibility of adding "some new scheduling
 GM> rules",
 GM> but I like that concept.  Idea snagged for future expansion..

 GM> Regarding the line:

 GM>   ÄÄÄÄ 8402
 GM> ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅMM-DD-YYÅMM-DD-YYÅÄÄÄÄÄÅÄÄÄ

 GM> I was hoping that %{at}date[01.02.03] would provide a unique digit for
 GM> origin of
 GM> the data file.  Since you told me that command issues 8432 on your
 GM> system, and
 GM> the same command on a German system also issues 8432, I've decided that
 GM> the

the punctuation in the date isn't really a problem... 4dos ignores which
separators you use.

 GM> digit is not unique enough; but the %_country code WILL provide a unique
 GM> digit....  So, the above line is now

 GM>   ÄÄÄÄ 001
 GM> ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅMM-DD-YYÅMM-DD-YYÅÄÄÄÄÄÅÄÄÄ

 GM> Up pops a NEW problem!  Some country codes are a single digit, some
 GM> country codes are double digits and the remaining country codes are
 GM> triple digits. I searched the 4dos help (mine), looking for a %{at}pad
 GM> command so I can pad single digit country code with "00" and pad
 GM> double digit country code with "0", but, of course, you
know there is
 GM> no %{at}pad command in 4dos version 6.02. Suggestions

add 100 and only keep the last two characters,

but

  %{at}replace[2,d,%{at}replace[20,yy,%{at}replace[1,m,%{at}makedate[14936]]

this should give the date format anywhere in the would,
but the germans would probably perfer j instead ot y and t instead of d :)

 GM> The idea of using the country code in the line is so that the BTM can
 GM> make a comparison of that line and the current system country code.
 GM> If the compared digits are identical, then the BTM carries on.  If
 GM> the compared digits are different, then the BTM would convert the
 GM> data file to the current system country code AND the correct date
 GM> format

maybe you could just compare the format strings with locally generated ones.

 -=> Bye <=-

---