|
A mystery has surfaced & I am hoping someone can suggest something to check that I am missing. Last week there was an end user complaint about something with respect to customer addresses printing on shipping documents. I reminded them that a mod had been awaiting testing that was relevant to same topic. Thursday they told me they had tested my mod & were well pleased, so Thurs nite I implemented my ORD595 mod in the *LIVE version then Friday morning all *HELL broke loose & there were several different scenarios to deal with not just in shipping, so I backed the *LIVE back to how it was before modification implemented so I could have time to deal with the different scenarios & return to this when *PEACE restored. Sometimes problems been happening for a while & rest of us really not know it, so there is a remote possibility that contrary to my current understanding this did not just start happening last Friday. We ship from 2 facilities whose PC setup theoretically indentical. 2 laser printers for PC stuff & bar code labels for packages, and 1 dot matrix printer for 400 stuff like multi-part ORD59* shipping documents. Eons ago I suggested printing ORD59* in triplicate & need less printers but thumbs down - they prefer way it is. The folks in our shipping department are not computer hands on people. They work with the product then have at most an hour a day on the computer, when everything working right, but it tends to be in snatches of a few minutes when some shipment is ready to go & they do the associated paperwork. Our Evansville Indiana facility "EVA" printer PRT01 is getting shipping documents perfectly exceopt for one killer scenario. (Our system printer is PRT02) It works perfectly in the mornings. It goes Hay Wire in the afternoons It works fine in the evenings Hay Wire Symptoms: 400 reports go to PC printer buffer & disappear. All indications on 400 & on PC are that the documents printed except the printer has not budged send same document to PRT03, in another office, and it prints correctly Do any other report or screen print & the shipping printer them fine, but the shipping documents disappear to oblivion & only during the afternoon hours. As this contributes to a disruption to ability to get shipments out properly each afternoon, we have a parade of helpers who know something about various pieces of the puzzle, with some total reboots of the PC involved, but so far the pattern has held true. Shipping Documents run in the mornning or evening after last truck visit are fine, but those in the afternoon go into PC printer buffer & disappear. It only happens with shipping documents ... we can have a failure, print something else no problem, reprint shipping document & it evaporates, print something else fine, reprint shipping document & it evaporates, look at the shipping document on screen & it is all there, send it to print on printer at other end of the building & it prints perfect, release it to print on printer in shipping office & it evaporates. Friday I changed PRTF on all 3 to SAVE *YES to simplify this reprinting retries. We did have a hassle Friday with BOL wrong font & partial print then quit I lowered font point size via PRTF more dense CPI & that problem now gone away Since our other facility is using same BPCS software on same kind of PC I constandly asking how their shipping documents performing. Our Lawrenceville Illinois facility "LAW" is printing shipping documents perfectly except for two things a) Every ORD595O ORD596O ORD597O demands they check alignment at printer LAWPRTPL & they *ALL have PRTF of ALIGN *NO. Their form length overflow LPI CPI etc. identical except for the name of the PRTF & the individual programs printing what at what vertical lines. It makes no difference if users respond to CPA4002 with I continue G next form R retry It prints that shipping document satisfactorily then requests alignment check on the next one b) Intermittent random bogus ship to address in which the best explanation I can get is a break down in human communication as to what is the correct ship to address. We let our own end users decide Pop-Up menu option-1 where they decide it their reports are to be automatically on-hold so they release what they want in what sequence or let it all print then they pitch in garbage what they not need, Generally 400 novices do the latter while 400 experienced users do the former. There is an understandable learning curve here. EVA shipping reports go on hold & they only print the actual shipping documents. LAW shipping reports print without being released & also miscelanous other reports that they throw into the trash because they do not use them. This means that ORD561 is a suspect because it is designed for standard green bar paper while ORD59* is designed for 8 1/2 by 11 but we have lied to OS/400 & said this is *STD forms so the shipping people do not have to mess with form change messages. Our PC guru is currently on vacation in the land of the Pyramids & when he gets back there will be a few things to ask him to check. How exactly is this PC talking to the 400 ... is it on a network that might be extra busy in the afternoon hours? We have had problems in the past with Win application upgrades that eat memory needed for concurrent applications. Is it possible we recently had some upgrade that returned this problem to us? At one time someone wrote a macro to prevent PC printers from wasting paper between documents. Is there anything I should know about settings in the PC macro such as length of forms supported? How frequently does this PC get a check vs. viruses & firwall issues - are there any problems there? I would suspect this is an EVA shipping PC printer problem were it not for the LAW shipping alignment having concurrent problems. Any suggestions welcomed for locating & destroying the responsible gremlins. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) BPCS 405 CD Rel-02 mixed mode http://www.cen-elec.com Official Slogan = We Harness Quality Unoffical Motto = We do Wire and Hay Wire +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.