Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Information Architects (IARC): E-Commerce & EIP -- Ignore unavailable to you. Want to Upgrade?

To: Jeffrey S. Mitchell who wrote (5155)	3/22/1998 6:17:00 PM
From: tech	Read Replies (1) \| Respond to of 10786

I don't know, but I think the question was if they STILL are having this problem and if it will effect the Q1 numbers you, and others, have been boasting about ? would be nice if you cut to the chase ... from reading your response it seems like the answer is yes ?

To: Jeffrey S. Mitchell who wrote (5155)	3/22/1998 8:11:00 PM
From: TEDennis	Read Replies (1) \| Respond to of 10786

Jeff: Re: code 'packaging' Having been responsible for the 'factory' at the receiving end of client code shipments, I know for a fact that putting 'demands' in the contract for delivery of code chunks doesn't work. What it does do is provide an environment that will allow escalation of the priority of the delivery task. However, just saying "have the code there by Tuesday" doesn't help much if the application expert(s) who know the pieces and parts of the application and all of his/her staff are busy fixing last night's production failure. The reason the code is shipped offsite is that the client staff is already overcommitted to current activities. The busywork of packaging it all up and shipping it offsite is just another thorn in their side. Incomplete packaging of code affects both the client and the offsite vendor. The client has to untangle the mess of files he has, and the vendor has to halt his processing until the next set of files are received. If they're lucky, they'll get them all next time. None of this effort would be necessary if the application(s) were being fixed on the client site, on the client's mainframe. That, and some environmental gotcha's, are why my first recommendations were always onsite remediation. Certainly there are times when the client's computer is maxed out and can't handle additional processing load. In that case, offsite is the only way to go. Or, there's no physical space to house the additional needed consultants, and the client is unwilling to allow offsite access to their mainframe. Gotta' send it offsite. The process of 'packaging' the pieces and parts of an application is much more difficult than an uninitiated person might expect. Besides the synchronization problem (keeping track of any changes that might have been made while the packaged code was offsite), there's also the problem of trying to rationalize shared copybooks (files that contain record descriptions that are shared between applications). The changes to the applications that share that copybook have to be staged together, or at least synchronously. Major operational problems. The overall process is primarily the same from site to site, but each site has its own ideosynchracies that make them unique. The really tricky ones are the sites that have embedded user exits in their source module access routines to take care of years of 'fiddling' with their environmental requirements. The offsite vendors have developed utilities to make the packaging job easier, but its almost guaranteed that it won't all be packaged properly the first time. The packaging problem is just another annoying minor detail that ensures that there will never be a "silver bullet" for the Y2K. Regards, TED