Hi Group,

I have a question about the Pick (in this case MVBase) spooler.

I (potentially) will have multiple clients on one MVBase machine. Trying to
track spooler entries is difficult enough... however, when they run the
Month-End process, it produces close to 30 Hold Entries. Having 2 or 3 or 4
clients running different month-end will get confusing -- if not
impossible -- to figure out's who's is whose.

I'm sure there may be 3rd party spooler software out there and I'd love to
hear about it.

What I thought that might be interesting (as a possible solution) is to
change the user account (temporarily). If I could do this, then instead of
seeing the USER who generated the hold entry when using either a LISTPEQS or
SP-LISTQ, it would show a "Company: Report Name" (something like) - ABC: AR
Aging; OR XYZ: AP Forecast.

I've tried the Charge-To (that give the user to be User*ABC: AR Aging) but
when I generated the hold entry it kept just the user. I've also tried
messing around with the ACC data... that didn't work either.

So, the question is... is there a quick (and easy... short of LOGGING to for
each spooler entry) to change the user name (retain the old one) with a TCL
command, Basic command, or User Exit PRIOR to generating a Hold Entry... and
then change it back?

Thanks,

David

Why not assign each user a different Form Queue number and keep them
separate that way?

There's a limited about of space (50 bytes?) for each form queue entry, so
assigning each a name could be problematic.


Mark Brown

"David Ehrhart" <dehrhart (AT) southwest-software (DOT) com> wrote

Hi there,

I run one mvBASE system for 25 sites

All I do is assign a form queue to each site that logs in - that form Q is
then assigned to the printers at that site ( the printers setup in the
workstation component )

I just have a file that has the each site name as the item ID the first
attribute defines the form q number for that site

I have been running this way for nearly 7 years without any issues

Craig

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

My first thought too was to use different form queue numbers to
identify the client and job type.

But if you're running multiple clients on one box, are they all
running in the same account? If they're in different accounts then a
simple SP-LISTQ should tell you which jobs belong to which clients.
And when you're in one account you cannot de-spool reports from unless
they belong to your account - unless you use an option on SP-EDIT to
bypass that. Even if you have users login to a Q-pointer account,
that's the account you'll see in SP-LISTQ. Then the only issue is
with the type of print job it is, and that again is where form queue
numbers come in.

Are we missing something David? Pick has been doing things like this
for decades without need for any significant changes. Maybe we just
need to help clarify how the spooler already works so that you can get
the most out of it?

Tony

"Mark Brown" wrote:

David Ehrhart wrote:
From the sounds of it, you have everyone running in the same account.
Why don't you create a Q account for each client - that way each client
will appear to have their own account while utilising all the programs
of the base account, and their spooler jobs will be allocated to the
individual Q accounts.

For example, the real account name is REALACCOUNT. Create an entry in
the SYSTEM file in the SYSPROG account like:

CLIENT1
001 Q
002 REALACCOUNT
003
004
005
006
007
008 SYS2 <== or whatever privilege is appropriate
009 L
010 10

with equivalent entries for CLIENT2, CLIENT3 etc.

Each client will then log on as CLIENT1 (or CLIENT2), and any spooler
entries will be identified as belonging to account CLIENT1 (or CLIENT2 etc).

Does this help?

Cheers,


Brian Speirs
--
************************************************** *
Brian Speirs
h: (04) 479 9032 c: (021) 265 5906
e: brian at rushflat dot co dot nz

Tony (and the rest of you responding),

Thanks for the response!

Yes, I've been around for over 25 years in Pick and I do know the why's and
wherefores for setting up different User Names (okay, synonym accounts) for
each user and different spool Que's for different jobs... etc.

The issue that I'm trying to solve is... that AFTER the month end is run
there are 30 reports in the SP-LISTQ (or LISTPEQS). With one "Company" they
have gotten used to "spool entry 5 is the AR Aged Trial Balance" -- because
the person who does the month end process, does it in the same order each
time. However, with multiple "Companies" and multiple users those number
will (potentially) get out of order.

So, my question is HOW to KNOW -- just be looking at the SP-LISTQ -- where
is Company XYZ's AR Aged Trial Balance report without having to "Display"
each in the SP-EDIT?

I thought it would easy to identify it under the ACCT description in the
SP-LISTQ... IF there was an easy way to change the Account Name on the "fly"
with a command or user exit or etc. (so, it would be easily changed back).

I've always thought -- over the years -- that one of the few problems with
Pick is the spooler... or should I say the SP-LISTQ.

Again, thanks for all the response...

David

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

David Ehrhart wrote:
That helps!

You should be able to type in:

LISTPEQS (A

or

LISTPEQS "account-name"

to just list the print files in the account your client is working on.
If he has done the jobs in the same order, then he will simply need to
note the fifth print job listed.

Yes, it would be nice to name the reports!

Cheers,

Brian

--
************************************************** *
Brian Speirs
h: (04) 479 9032 c: (021) 265 5906
e: brian at rushflat dot co dot nz

Brian Speirs wrote:
David, the extra info certainly helps.

Brian, your solution applies only if people aren't occasionally
clearing items in the queue. If one non-HS job is run and then
disappears, the next HS job will be inserted but out of order.

David, take advantage of form queue numbers, that's what they're for.
For all AR Trial Balances, SP-ASSIGN HSF34 or some such unique number.
Then when the user does "SP-LISTQ A" or "LISTPEQS A" they will see
only their jobs, and the form number will tell them which job is which
- not the job number or print sequence. You'll have some minor
re-education to do there, but all of your client companies will come
to know that 34 is always the AR/ATB. If you want to write code
around this to present a list of jobs (with report names) relevant to
each company, it should be easy to do so, and that will eliminate the
need for people to memorize form numbers.

HTH
T

One method I have used is to write the print job description to a file with
the print job number as the key. I have a group of subroutines calls that
can be easily inserted into both procs & basic programs to build & maintain
the description file.

Then you can write a program that mimics listpeqs but picks up the
description from the job description file. I do some checking to match the
date & time so if a print job is deleted & reused without using my routine
to also delete the description item, then the wrong description doesn't
show.

Another method is to write a program that goes through the print queue gets
the first line, or X lines from the print job & update a description file
with that information. If the print jobs have a job name or heading on the
first line then this method works quite well and does not require any other
program mods.

Richard Brown

"Brian Speirs" <bss59REMOVE_THIS (AT) paradise (DOT) net.nz> wrote

Hi David,

I've done a couple of things to handle this. In some situations I
capture the print job# at creation and email the job# to the user. The
other situation requires standardized report headings which I have done
and my own sp-listq that looks at the header line of the peq file to
get identifying information and return only related print jobs.

Randy