× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: 405 CD Shipping Documents
  • From: "Cservak, Barney" <BCservak@xxxxxxxxxx>
  • Date: Thu, 25 Jan 2001 10:48:39 +1100

If the printer is configured on the AS/400 as a 5225 *VRT device, the
problem may well be that the destination options on the output queue should
be XAIX XAUTOQ.


> Regards,
> 
> Barney Cservak
> I S Technical Specialist
> CSR Building Materials
> Telephone    :  +61 2 9372-5792
> Facsimile    :  +61 2 9964-1329
> Mobile       :   0419 476701
> E-mail       :   bcservak@csr.com.au
> Pager        :   +61 2 132222 pager # 380227


-----Original Message-----
From: MacWheel99@aol.com [mailto:MacWheel99@aol.com]
Sent: Wednesday, 24 January 2001 9:54
To: BPCS-L@midrange.com
Subject: 405 CD Shipping Documents


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
+---
+---
| 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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.