I am writing a report to show the customers that have had a hire for 4 different time frames. This is done in a sub program called by the main. I am stumped by what calculations I need to perform as I only have start-time, end-time, hire-date,return-date. I have to work how many of those customers fall into each category i.e. 5 customers hired for only 1 day etc
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
calling a sub program to calulate time
- Thread starter carolly
- Start date
As I understand it, you want to find out how many customers did (I'll call him) John Doe work for during 4 different time frames.
So let's put it into perspective. John Doe worked for 4 time-frames. Within each of these time frames, he worked for at least 1 customer, but it could have been 5 or 50 or who knows how many customers. So he worked for X number of customers within each time frame.
It would seem that a "time-frame" would be a continuous sequence of time. You would have to look for breaks in the times given, and also need to know such things as how many hours does he work during each day, does he get travel time, lunch breaks, etc.? Also, if he works 8 hours a day for a particular customer, finishes his work there, and the next day at the beginning of his work-day, works for a different customer -- is this 1 time frame or 2 time frames? Also, if there is a break in times, but he is still working for the same customer -- is this 1 time frame or is it 2 time frames? You need to go back to the person giving you the specs and ask these questions, I would think.
Let's make it simple and assume that he works 8AM to 4 PM each day, and disregard lunch breaks, travel time, etc. And we'll assume that if he works the full day for 1 customer and begins the next day working the same customer, then we're still within the same time-frame. But if he finished with 1 customer at the end of a day and then begins the next day for a different customer, then that's 2 different time frames. Other than that, we'll differentiate time frames by looking at breaks between the ending time of 1 job and the beginning time of the next.
Let's say he starts at 8AM at the beginning of August 2, 2001 ("hire-date" for Customer 1) at 8AM ("start-time"
. He finishes work for Customer A at 2PM ("end-time" the same day (so this is the "return-date" for Customer 1). At 2:01 PM ("start-time", he begins work for Customer B. This is a continuous sequence of time, so we're still on Time Frame #1, even though we switched customers. He ends work for Customer B at 4PM that night, then begins again at 8AM on August 3, 2001, and continues until 11AM (which will be your "end-time" on the same day. We are still within Time Frame #1 because there has been no time-break (other than going home and coming back to work the next day). His "return-date" for Customer B will be August 3, 2001. He begins work for Customer C at 11:01AM ("start-time" on August 3, 2001 ("hire-date" for Customer C) and stops at 3PM the same day. This will be his "return-date."
Then, the next start-time is 8AM on August 4, 2001 for Customer D. So now we have a break here. Time Frame #1 ended at 3PM on August 3. This would thus be the start of Time Frame #2.
You go on analyzing these figures, looking for breaks between the time frames until you get to the end-time of Time Frame #4.
Am I making any sense at all here? Or am I missing the boat entirely? Let me know if this is of any help.
Nina Too
So let's put it into perspective. John Doe worked for 4 time-frames. Within each of these time frames, he worked for at least 1 customer, but it could have been 5 or 50 or who knows how many customers. So he worked for X number of customers within each time frame.
It would seem that a "time-frame" would be a continuous sequence of time. You would have to look for breaks in the times given, and also need to know such things as how many hours does he work during each day, does he get travel time, lunch breaks, etc.? Also, if he works 8 hours a day for a particular customer, finishes his work there, and the next day at the beginning of his work-day, works for a different customer -- is this 1 time frame or 2 time frames? Also, if there is a break in times, but he is still working for the same customer -- is this 1 time frame or is it 2 time frames? You need to go back to the person giving you the specs and ask these questions, I would think.
Let's make it simple and assume that he works 8AM to 4 PM each day, and disregard lunch breaks, travel time, etc. And we'll assume that if he works the full day for 1 customer and begins the next day working the same customer, then we're still within the same time-frame. But if he finished with 1 customer at the end of a day and then begins the next day for a different customer, then that's 2 different time frames. Other than that, we'll differentiate time frames by looking at breaks between the ending time of 1 job and the beginning time of the next.
Let's say he starts at 8AM at the beginning of August 2, 2001 ("hire-date" for Customer 1) at 8AM ("start-time"
. He finishes work for Customer A at 2PM ("end-time" the same day (so this is the "return-date" for Customer 1). At 2:01 PM ("start-time", he begins work for Customer B. This is a continuous sequence of time, so we're still on Time Frame #1, even though we switched customers. He ends work for Customer B at 4PM that night, then begins again at 8AM on August 3, 2001, and continues until 11AM (which will be your "end-time" on the same day. We are still within Time Frame #1 because there has been no time-break (other than going home and coming back to work the next day). His "return-date" for Customer B will be August 3, 2001. He begins work for Customer C at 11:01AM ("start-time" on August 3, 2001 ("hire-date" for Customer C) and stops at 3PM the same day. This will be his "return-date."Then, the next start-time is 8AM on August 4, 2001 for Customer D. So now we have a break here. Time Frame #1 ended at 3PM on August 3. This would thus be the start of Time Frame #2.
You go on analyzing these figures, looking for breaks between the time frames until you get to the end-time of Time Frame #4.
Am I making any sense at all here? Or am I missing the boat entirely? Let me know if this is of any help.
Nina Too
Hi Caroll,
It sounds like you want a list of all Customers, showing how many people they hired for each "time frame". For example, time frame 1 for cust x can contain a 4. The 4 can represent (I guess) 4 periods worked by John Doe or 4 different people or any combination of the two cases.
The puzzle is, what are "time frames"? Are they hrs, days, wks, mos? Or Jan thru Mar, Apr thru Jun, etc.? Or are they times of day? like 8 A.M - 12 Noon, 1 P.M. - 5 P.M.
Also what is rtn date? Is it the end date for the time worked? What are start/end time?
Are they the TOD JD started/ended the shift? Is it the start/end of the "time frames"? There are other Ques, but these will suffice for now.
Help us out here Caroll.
Regards, Jack.
It sounds like you want a list of all Customers, showing how many people they hired for each "time frame". For example, time frame 1 for cust x can contain a 4. The 4 can represent (I guess) 4 periods worked by John Doe or 4 different people or any combination of the two cases.
The puzzle is, what are "time frames"? Are they hrs, days, wks, mos? Or Jan thru Mar, Apr thru Jun, etc.? Or are they times of day? like 8 A.M - 12 Noon, 1 P.M. - 5 P.M.
Also what is rtn date? Is it the end date for the time worked? What are start/end time?
Are they the TOD JD started/ended the shift? Is it the start/end of the "time frames"? There are other Ques, but these will suffice for now.
Help us out here Caroll.
Regards, Jack.
StephenJSpiro
Programmer
It sounds like you are a temporary agency or some such, with your customers hiring your staff for different lengths of time in different billing periods. But maybe not. Please do not expect to get coherent help unless we have a coherent statement of the problem. NinaToo and Slade have given a lot of thought to your problem, and had to guess what you really want. Did you make them waste their time? Please post a complete statement of your problem.
Stephen J Spiro
Stephen J Spiro
- Thread starter
- #5
Sorry guys, I am new to this and do not intend to waste any bodies time. I have a program that calculates hire times of bikes. The time is taken from when it is hired to the time it is returned. i.e. 24 hours is one day and anything more than an hour over that time consititutes another day. I have 4 time frames to put this information into. i.e. 1 day, 2 days, 3-7 days and > 7 days. What I have tried is:
IF DATE-RETURN - DATE-HIRE
IS > 7
AND TIME-RETURN - TIME-HIRE
IS < 2400
ADD 1 TO DAYS-OVER-7
etc until all records have been read - would this work?
IF DATE-RETURN - DATE-HIRE
IS > 7
AND TIME-RETURN - TIME-HIRE
IS < 2400
ADD 1 TO DAYS-OVER-7
etc until all records have been read - would this work?
StephenJSpiro
Programmer
The combinations are very complicated. This is a good case for an EVALUATE.
You have these cases, just for >7 days:
Date-ret - date hire Time-ret - time hired
7 negative
** for example, ret 8am, hired 3pm
** This means before 7 full days
7 <+1 (that is, from 0 to +1)
** This means before less than an hour late
7 >+1
** This means more than an hour late
>7
** LATE!
You need similar relationships for your other time periods.
Code it this way:
EVALUATE
Date-ret - date hire ALSO Time-ret - time hired
WHEN 7 ALSO less than zero
WHEN 7 ALSO less than +1
DO something
WHEN 7 ALSO greater than +1
WHEN greater than 7 ALSO any
DO something else
END-EVALUATE.
You can even code all of the other cases in the same EVALUATE statement.
-------
A while ago, I wrote an article about the EVALUATE statement for "Enterprise Systems Journal". It goes into a lot of detail ... this is a VERY powerful instruction! If anyone would like a FREE copy of the article, send me an e-mail with a mailing address (the article is on paper only, because of the illustrations and charts).
Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at
stephenjspiro at hotmail.com
You have these cases, just for >7 days:
Date-ret - date hire Time-ret - time hired
7 negative
** for example, ret 8am, hired 3pm
** This means before 7 full days
7 <+1 (that is, from 0 to +1)
** This means before less than an hour late
7 >+1
** This means more than an hour late
>7
** LATE!
You need similar relationships for your other time periods.
Code it this way:
EVALUATE
Date-ret - date hire ALSO Time-ret - time hired
WHEN 7 ALSO less than zero
WHEN 7 ALSO less than +1
DO something
WHEN 7 ALSO greater than +1
WHEN greater than 7 ALSO any
DO something else
END-EVALUATE.
You can even code all of the other cases in the same EVALUATE statement.
-------
A while ago, I wrote an article about the EVALUATE statement for "Enterprise Systems Journal". It goes into a lot of detail ... this is a VERY powerful instruction! If anyone would like a FREE copy of the article, send me an e-mail with a mailing address (the article is on paper only, because of the illustrations and charts).
Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at
stephenjspiro at hotmail.com
StephenJSpiro
Programmer
Whoops, I'm embarrassed. You may not be able to use "greater than 7" or "less than zero" (YET). These are "partial conditional expressions" and will be in the new standard, but NOT everyone has implemented them yet.
As Jack says, first turn them into INTEGER-OF-DATE, then subtract. Get time difference the long way...
If partial conditional expressions are not yet implemented on your compiler, you would have to code something like
EVALUATE TRUE ALSO TRUE
WHEN (date-diff = 7) ALSO (time-diff is less than zero)
WHEN (date-diff = 7) ALSO (time-diff is less than +1)
DO something
WHEN (date-diff = 7) ALSO (time-diff greater than +1)
WHEN (date-diff > 7) ALSO any
DO something else
END-EVALUATE.
Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at
stephenjspiro at hotmail.com
As Jack says, first turn them into INTEGER-OF-DATE, then subtract. Get time difference the long way...
If partial conditional expressions are not yet implemented on your compiler, you would have to code something like
EVALUATE TRUE ALSO TRUE
WHEN (date-diff = 7) ALSO (time-diff is less than zero)
WHEN (date-diff = 7) ALSO (time-diff is less than +1)
DO something
WHEN (date-diff = 7) ALSO (time-diff greater than +1)
WHEN (date-diff > 7) ALSO any
DO something else
END-EVALUATE.
Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at
stephenjspiro at hotmail.com
Stephen, I was about to "correct" you and tell you that when you evaluate a data field, you can use conditional expressions.
Except that you already are absolutely correct. I remember the compile errors I got when trying to code "EVALUATE [data-field) WHEN > 7 etc. Yes, you have to use EVALUATE TRUE in these cases.
So just a slight addition. I have found that it is important to do a WHEN OTHER in an EVALUATE statement -- and in this case a WHEN OTHER ALSO OTHER.
This is because, especially in the testing phase, one never knows what sort of weird numbers and combinations will appear in your data fields. And if it isn't specifically covered by one of the WHEN's, then the program won't know what to do, and thus will sometimes do what you definitely don't want it to do. This is especially so when using EVALUATE TRUE with relational expressions.
Sometimes you simply want to generate an error message when values not covered show up. Or you may want it to do nothing, in which case, code the EVALUATE OTHER's as CONTINUE (NEXT SENTENCE won't work here).
Hope this helps, Nina Too
Except that you already are absolutely correct. I remember the compile errors I got when trying to code "EVALUATE [data-field) WHEN > 7 etc. Yes, you have to use EVALUATE TRUE in these cases.
So just a slight addition. I have found that it is important to do a WHEN OTHER in an EVALUATE statement -- and in this case a WHEN OTHER ALSO OTHER.
This is because, especially in the testing phase, one never knows what sort of weird numbers and combinations will appear in your data fields. And if it isn't specifically covered by one of the WHEN's, then the program won't know what to do, and thus will sometimes do what you definitely don't want it to do. This is especially so when using EVALUATE TRUE with relational expressions.
Sometimes you simply want to generate an error message when values not covered show up. Or you may want it to do nothing, in which case, code the EVALUATE OTHER's as CONTINUE (NEXT SENTENCE won't work here).
Hope this helps, Nina Too
NinaToo,
i do not completely agree with you there.
WHEN OTHER indeed is useful if at execution the possible values are uncertain.
Whenever they are, however, or at least should be, WHEN OTHER serves as a sort of "whimp clause", like: "i'm pretty sure it should be A, B or C, but just in case it's not, i'll include WHEN OTHER anyway".
If the value tested by the EVALUATE isn't covered by one of the WHEN's, nothing happens. That might be what you describe as "doing what you don't want it to do", but excluding WHEN OTHER doesn't lead to unexpected actions !
I find it a little more elegant to establish that the values tested in the EVALUATE are in the expected range, before entering the EVALUATE. But, that's just my perspective.
Regards,
Ronald.
i do not completely agree with you there.
WHEN OTHER indeed is useful if at execution the possible values are uncertain.
Whenever they are, however, or at least should be, WHEN OTHER serves as a sort of "whimp clause", like: "i'm pretty sure it should be A, B or C, but just in case it's not, i'll include WHEN OTHER anyway".
If the value tested by the EVALUATE isn't covered by one of the WHEN's, nothing happens. That might be what you describe as "doing what you don't want it to do", but excluding WHEN OTHER doesn't lead to unexpected actions !
I find it a little more elegant to establish that the values tested in the EVALUATE are in the expected range, before entering the EVALUATE. But, that's just my perspective.
Regards,
Ronald.
Ronald, in some cases you have a point. One time I coded an EVALUATE TRUE statement where the condition was either [data-field1] being greater than [data-field2] or the two fields being equal, or [data-field1] being less than [data-field2]. This covers all of the possibilities and thus a WHEN OTHER isn't necessary.
But let's say you are evaluating a string value in DATA-FIELD1. If you have one condition where the value equals 'A', then have another condition where the value equals 'B' and so forth. But what if something weird gets sent you way, and it equals LOW-VALUES or HIGH-VALUES or some sort of random garbage? This is where you need the WHEN OTHER to deal with this sort of stuff.
I'd rather be a "wimp" than have my program pull the entire system down because it doesn't know what to do if some strange values appear in strange places.
Nina Too
But let's say you are evaluating a string value in DATA-FIELD1. If you have one condition where the value equals 'A', then have another condition where the value equals 'B' and so forth. But what if something weird gets sent you way, and it equals LOW-VALUES or HIGH-VALUES or some sort of random garbage? This is where you need the WHEN OTHER to deal with this sort of stuff.
I'd rather be a "wimp" than have my program pull the entire system down because it doesn't know what to do if some strange values appear in strange places.
Nina Too
Nina,
yeah, that example just about covers the "uncertain values" situation.
I am by no means calling anybody a whimp; that's just an expression. You can also call it a "safety hatch". Not dealing with uncertain values is definitely a bad idea !!!
Regards,
Ronald.
yeah, that example just about covers the "uncertain values" situation.
I am by no means calling anybody a whimp; that's just an expression. You can also call it a "safety hatch". Not dealing with uncertain values is definitely a bad idea !!!
Regards,
Ronald.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question