At the moment, the only IBMLink ETR support queue for RECEIVE ORDER problems that I am aware of is 566894901 - the queue for SMP/E. The folks on the receiving end of this queue currently take problem reports for RECEIVE ORDER and pass them along to the organization which actually supports the RECEIVE ORDER process, which I assume to be IBM Software Manufacturing in Boulder.
I believe IBM is gradually becoming aware that it is necessary to establish better support for this "new world" of electronic interchange with customers. I suspect that the awareness of the necessity of this is currently highest in the SMP/E level 2 organization as well as their management, as they are the ones getting the brunt of the calls when IBM's order servers fail to process orders in a timely fashion. I further suspect that each PMR opened against 566894901 for problems with IBM's internet RECEIVE ORDER process provides further evidence for the proposition that the current nonexistent support for RECEIVE ORDER process problems needs to be fixed. I also believe that SMP/E itself should be modified in order to help customers distinguish between 1) customer setup issues and problems, and 2) IBM order processing issues and problems, and that SMP/E should provide some sort of guidance as to which support organization to request assistance from. I believe such enhancements to SMP/E further benefits IBM by helping customers get assistance from the correct organization. However, right now, since there is no correct support organization to report an IBM order build error to, a message that says "Contact IBM order build organization to report this error" will not (yet) help. Brian On Fri, 1 Jun 2007 15:40:01 -0500, Mark Zelden wrote: >I've been using SMP/E 3.4 to order holddata and maintenance for a year >now. At times (especially lately) it is *very* slow. I assume the >delay is on IBM's side building the order since the order is sent right >away and you can see that message in the SMP/E output. > >I ordered a single APAR earlier this morning and the job "timed out". The >default is 120 minutes of waiting. I did get the order with the "PENDING" >option a little later. I also changed some of my sample JCL to change >the wait time from 120 minutes to 300 minutes because of the problems >I have been seeing the last couple of months. But this all seems >very excessive. I haven't used ShopZ or the other download PTF site >I used to use, but they were both very quick in building orders. > >I just submitted a HOLDDATA only order and it's already been waiting >for over 90 minutes. OTOH, I just submitted my "old JCL" that does >an FTP in batch from service.boulder.ibm.com and the FTP step >ran in 6 seconds (I deleted the SMP/E RECEIVE step because of my other >job running). > >Is everyone getting these sort of delays with the orderserver? Is it >because everyone is using it now? A couple of other times I figured >it was because everyone was getting RSU maintenance at the same >time (you can sign up for an email when a new level is available), >but that isn't the case today. > >If this is all due to server overload, then I sure hope IBM addresses >the issue. I suspect it could be because the last time I had problems >getting the current RSU maintenance during the day, I re-submitted >the job to run before I left the office and it didn't time out. > >Yes, I know we could schedule these jobs to run at night... but since we >need to look at REPORT ERRORSYSMODS on a regular basis anyway, at >least the person submitting the job remembers there is something >to look at. Not to mention all the change control procedures to put >something in the production scheduling package and then all the >pain to change it if you need to. :-) > >Mark >-- >Mark Zelden > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
