Re: EDI TLE 3.2.1 Scheduler -- BPCS-L

from Al Macintyre

conceptually the purpose of a Scheduler is to free up humans when the work 
involved is routine, not requiring human interaction.

We use GO CMDSCDE to generate some reports that some users need every day at 
a particular time.  When the report gets to the spool, the completed job also 
sends message to the user informing them of that fact.  Futzing with the code 
so that BPCS stuff can run outside the BPCS environment is a royal time 
consuming pain to implement, so we have not yet done it for a lot of reports. 
 

Other folks on this list swear by ROBOT & I do not know how it compares in 
this regard.

Although we are not using EDI at present, doing EDI manually was cumbersome 
when we were using it.  There were all kinds of error messages that might 
occur with the phone connection & users who got rattled as to which kind it 
was & responding inappropriately.  Logically it would be nice to automate the 
input of data from EDI, with reply lists to control the flow of the job based 
on whatever error message might occur.

The handshake & error recovery was sufficiently user-hostile (we were not on 
TLE) that although a lot of users knew how to run it, it generally got done 
by MIS due to the high error rate of end users responding to communication 
error messages & retry options.

We had customers who did their own releases on a predictable schedule, so 
that if we scheduled our connection with the VAN to hand-shake with the 
standard customer schedule, setting some flags based on failure modes, so as 
to automatically call back every hour or so until we got the standard data, 
this would relieve our users of a lot of hassles.

When various different users were doing it, when time permitted, we also had 
the notification status problem "Has anyone tried to get releases since last 
Tuesday?"  "What customer's releases were in the EDI we got last Thursday?"  
"When were the last updates we got from customer-X for item-Z?"  If an EDI 
scheduler was taking care of all this, then the only issue is where the data 
goes & the end user inquiry access to it.

With GO CMDSCDE we are able to "launch" the job right now, irrespective of 
the next time it would automatically execute, which is real nice.  I would 
hope that an EDI scheduler would have that option in the scenario of a 
customer phone call to verbally tell us that they have new releases out there.

However, we did have the problem of Buyers at Customers who were out of touch 
with how long their own internal release process functioned.  They called our 
Sales Reps & there is nothing for that customer at the VAN, because it has 
not yet left the Customer MIS Cycle.

Some customers would add updates without warning, outside their usual 
schedule, so ideally I would want to schedule this for the wee hours before a 
standard work day, and re-run it close to the lunch hour, to see if there 
have been any surprise updates.

We also had ma bell irritations, in which "all circuits are busy ... try your 
call again later" were more likely during certain hours of the work day, so 
that if the EDI was automatically scheduled to run in the wee hours when the 
demand on phone lines at its lowest point, that sounds to me like a good 
plan.  This irritates normal flow of business, for which EDI is only a 
portion of the annoyance with ma bell.

If sending ASNs, it might make sense to do them over-night, reflecting each 
day's shipments after billing completed.

I hope I have satisfactorily explained the CONCEPT of why anyone would want 
to use a Scheduler for EDI or anything else.

Al
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---