| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1998.1 | Print Queue Form & JBCSYSQUE.DAT Corrupted? | MSAM03::DOUGLASBURKE | Fleeting Edge of Technology? | Sat Dec 26 1992 01:57 | 46 |
| Let me add some additional information to item number 1 in .0.
By "networked printer", we also mean a "queued printer". WPS-PLUS
documents print fine when send to an LPS40, and ASCII documents print
fine on ALL printers, even the HPLJIII's on the network. The only
problem they are experiencing is printing to networked (that is queued)
HPLJIII.
Another interesting tidbit of information is that they do obtain an
unusual message when booting up, near the end of the ALL-IN-1 startup
command procedure:
"Print Form numbered 1104 should be named ALLIN1 - please check"
They did check the print queue form, and it was there. However, just
for drill, I asked them to delete it. When they tried, it would not
delete. Instead there was an error message explaining that the ALLIN1
print queue form did not exist.
Since we have been able to successfully delete this print queue form on
other systems, it lead me to believe that perhaps the JBCSYSQUE.DAT on
that system (VMS V5.4-2) was corrupted.
So why would it work on the LPS-40's. Maybe because they use a
different print queue form for that type of printer?
Let me state a theory then...could it be that because the ALLIN1 print
queue form is screwed up, that when the OA$FORMATTER tries to format a
message for output, it or some other mechanism uses this form, screwing
up the output too?
With this in mind, I have asked the customer to create a new
JBCSYSQUE.DAT and reboot all the machines in their cluster so that they
will all be using the same one, and will all recreate their application
queue definitions in that file.
Any comments? Does it sound like the correct approach? (I'll find out
in a day or two anyway when they give it a try.) Can anyone briefly
describe the process ALL-IN-1 goes through when a user prints a
document to a queued printer?
Doug
Disclaimer: The "ALLIN1" mentioned above is the name of the print
queue form...not my own personal mis-spelling of the
product.
|
| 1998.2 | Printer Type Tables | MSAM00::DOUGLASBURKE | Fleeting Edge of Technology? | Tue Dec 29 1992 02:41 | 9 |
| Well, the customer finally figured out what this printer problem was on
their own.
It seems that the upgrade procedure did not properly convert from the
old to the new Printer Type tables. When the customer checked these
tables out, they found that elements of the old table were there, but
in the wrong places.
Doug
|
| 1998.3 | Which printer files? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Mon Jan 04 1993 09:40 | 8 |
| Are we talking about WPs-PLUS .PRA/.PRC files here? If so, they aren't
converted by the installation, it's a manual process.
If you're talking about the other printer master files, what exactly
went wrong? We try to guess fields in any records you've created and
put messages in the installation log to tell you about our guesses.
Graham
|
| 1998.4 | Confused about part of the base note | AIMTEC::WICKS_A | A year behind in more ways than one | Wed Jan 06 1993 03:18 | 23 |
| Sowwan,
I'm not sure I understood comments 2 and 3 in the base note so could
you clarify the situation
ALL-IN-1 account USER, VMS accounts are VMS1, VMS2 etc...
VMS1 can see VMS2's MAIN drawer since they are the same account but
another separate account MYUSER can also see this drawer even though
he is supposed to not be able to - or did i misread it.
blank VMSuser fields are not recommended in any version of ALL-IN-1
(not just v3.0) since it means that anyone with sufficient privs
can log into that account - I thought it was prevented in at least v2.4
also?
I'm not sure how blanking out the VMSUSR field will help you but
<WRITE CHANGE PROFIl .%KEY="ALL-IN-1 USERNAME", VMSUSR=""
will do it
Regards,
Andrew.D.Wicks
|