Our software printing was all written using XCALL SPOOL. Now there is going to be a second printer on the system.

Once we define that, wondering if there is a way to set the default printer for the individual linux users when they open A-Shell.

Essentially all users except one need to have their documents go to printer 'HPMAIN', which si the only printer currently set up. And the other user will have all her's go to printer 'XEROX1'

Hoping not to have to do special programming as it is a lot of code to redo. Is there some .INI file I can use or something in .bash_profile like a different miame.ini file I'd use for one user versus the others?

If needed some additional info...
In the current miame.ini file there is a line:
ALIAS=SPOOL:EZSPL
...
PRINTER=HPMAIN

And I have a note that last printer listed is the default printer

Thanks for any help.

There are several ways you could accomplish this.

One would be to create user-specific sections in a common EZ-SPOOL configuration file, as shown in the Setup Guide's sample EZ-SPOOL configuration file .

Another would be to activate EZ-SPOOL's printer selection menu, which would allow users to select the printer for each report.

Yet another would be to redirect all reports back to the terminal emulator by using DEVICE=AUXLOC: in the common printer init file. Depending on your emulator, you may then be able to either display a standard Windows printer selection menu, or just have the report routed directly to a previously defined (per emulator/user instance) printer. In the case of ATE, you can set this up on the Printer tab of the connection profile properties dialog.

Hi Jack,

I hope you are having a good summer!

I think your first option looks excellent. I took a look through the sample but I didn't notice what the name of the EZ-SPOOL configuration file. I am presuming it should be in /vm/miame along with the miame.ini file. But can't find anything there or inside A-Shell for an existing file.

Thanks

It's a bit hotter than I'd like, but I guess that's my fault for living in Southern California. (If you'd like to swap houses with me during the summer, I think something could be arranged...)

But as for EZ-SPOOL, it searches for an entire series of configuration files with different names and locations based on the current circumstances. The list is summarized in the Setup Guide under the topic EZ-SPOOL Config Files .

Since you may only need one such file (with different user-specific sections), you can probably just use the EZ:SYSTEM.SPL file. Note that you may need to define the EZ: ersatz (in SYS:ERSATZ.INI) - typically something like this:

EZ:=DSK0:[150,1]

So much cooler here in Canada, but some days around now we get some heat. Sounds like a great opportunity, even better if it was winter time.

I'll try the EZ spool solution out Thanks for the help.

Long delay till we went to use this and having a problem with it not recognizing the user.

I created a folder/ppn for EZ: and mapped it in SYS:ERSATZ.INI

I created EZ:SYSTEM.SPL as follows
MENU=OFF
TYPE=OFF
ASKPRT=OFF
DEFAULT=BANK

[lkitney]
MENU=OFF
TYPE=OFF
ASKPRT=OFF
DEFAULT=XEROX4

[alex]
MENU=ON
TYPE=ON
DEFAULT=XEROX4
PRTSPL=XEROX4,New Xerox
PRTSPL=BANK,Original Printer

Then to see what my default printer is, I typed in dot command
SET TRACE LP ON

I see that my default printer is BANK although I am logged in as alex

If I change line 4 of SYSTEM.SPL to be DEFAULT=XEROX4 instead of DEFAULT=BANK, I do see that my default is XEROX4 but that makes it XEROX4 for everyone.

What do I need to do to get it to recognize which linux user I am?

Thanks

Does someone have an idea about my previous post on this? I've also tried using [alex] in caps [ALEX] but this makes no difference.

The default printer still remains as BANK rather than changing to XEROX4 due to having [alex] section in EZ:SYSTEM.SPL

Thanks for any help,
Alex

Sorry for the delay - I started to look into it but somehow got sidetracked trying to reproduce this. But now that I've looked more closely at it, I think I can see the problem.

The DEFAULT statement only has an effect when no printer has yet been set (at the point that the DEFAULT statement is processed). Since the EZ-SPOOL config files are processed from top to bottom, by the time it processes the DEFAULT=XEROX4 command in the [alex] section, it has already processed the DEFAULT=BANK command in the global section, and thus the top one takes precedence.

Fortunately, there is a workaround, which relies on an apparently undocumented feature (sorry about that!) - the ability to name the global section [always], which in turn allows you to place it at the bottom, instead of the top, so that the user-specific DEFAULT=XEROX4 gets processed first, causing the global DEFAULT=BANK to be ignored:

Note that we are assuming there is no PRINTER= statement in the MIAME.INI, else it would establish the default before we get this far.

Also note that the section names are not case sensitive.

Putting the global options at the bottom isn't really a good solution though, since for many of the other commands, (e.g. MENU), it is the last instance processed that takes effect, not the first instance. So the global instance of the MENU=OFF would override the [alex] instance of MENU=ON.

To solve that, you can split the [always] options into two parts, one at the top for the commands where the last instance takes precedence, and one at the bottom for the commands where the first instance takes precedence (on which DEFAULT is probably the only case):

Another possible workaround would be to use the PRINTER command rather than the DEFAULT command, since PRINTER will override any previously-established printer. But that would also override one set by the application, which is probably not what you wanted.

Thanks for the info Jack, although still not functioning quite as I need it.

I now have ez:system.spl (the only .spl file in the system) as:

[always]
MENU=OFF
TYPE=OFF
ASKPRT=OFF
[lkitney]
DEFAULT=XEROX4
[alex]
DEFAULT=XEROX4
MENU=ON
TYPE=ON
ASKPRT=ON
PRTSPL=XEROX4,New Xerox
PRTSPL=BANK,original printer
[always]
DEFAULT=BANK

and in miame.ini I commented out the printer lines so they look like this:

;PRINTER=XEROX4
;PRINTER=BANK

A few things to figure out, so perhaps I'll number them.

1. If anyone prints something now without designating a specific printer (whether from a print command at a dot, or spooled from within a program). It is coming out to a 3rd printer, neither BANK nor XEROX4. Printing is going to what they call xerox1. Doesn't seem to heed what is in SYSTEM.SPL

If I 'set trace lp on' here's what I get when logged in as alex and do the following print.
p alex.tst

Trace: Default spooler name supplied:
Trace: EZSPL ptr = , file = alex.tst
Trace: SPOOL ptr = , switches = 0, copies = 1
Trace: Checking for default printer in /root/.PRINTER
Trace: lpr -#1 /vm/miame/dsk0/010010/alex.txt

Trace: system(lpr -#1 /vm/miame/dsk0/010010/alex.tst)
Trace: Hit Any Key ...

2. I don't get prompted/asked which printer to send to. Should setting MENU=ON etc. for [alex] make some menu pop up to ask me which printer I want.

3. If something is spooled from within a program should it go to the default from system.spl for the person unless you specify a particular printer in the xcall spool?

Thanks,
Alex
Thanks,

Note that I don't have a /root/.PRINTER file set up in linux.

I believe that most or all of the problem is due to the fact that PRINT.LIT bypass the EZ-SPOOL configuration files. (I think this matches the way it worked under AMOS, where EZSPL.SBR was just a replacement for SPOOL.SBR. Under A-Shell, SPOOL is actually an ALIAS for EZSPL.)

Thus PRINT ALEX.TST is printing to the operating system default queue, rather than any default established by the application or A-Shell. XCALL SPOOL,"ALEX.TXT", on the other hand, would process the configuration file. Here's an example of printing TEST.LST:

As you can see in the above trace, there is no indication of any processing of the system.spl, and no default printer is ever assigned. But if I run a program consisting of XCALL SPOOL,"TEST.LST", I get this trace:

After which I see the printer selection menu, with the printer set to XEROX4 (due to the MENU=ON and DEFAULT=XEROX4 in the [jack] section).

If you prefer that PRINT.LIT not bypass the EZ-SPOOL configuration files, a custom version could be created that just converted the PRINT file command into XCALL SPOOL,"file".

That makes it clear on how print.lit functions.

But on the spooling side, I made a program with xcall spool,"alex.tst"

When I ran it, although I have system.spl set up same as it was from a couple posts back, no menu pops up to ask which printer should be used. I was expecting it to give me option of XEROX4/New Xerox or BANK/Original Printer

It just ends up printing to default linux printer which is another one, xerox1

I'll try setting PRINTER=XEROX4 in my system.spl file and see if that forces all my spooling to go there as how they really want it is all printing for lkitney to go to XEROX4 and everyone else's to go to BANK.

95% of what is printed is spooled from within a program, the other 5% is done via print command at dot.
It ends up going to the default linux printer, not

Let's review the trace again to see if it is really processing the MENU commands in the expected order.

Here's what I tried now and how it's going.

This is my ez:system.spl

[always]
MENU=OFF
TYPE=OFF
ASKPRT=OFF
[lkitney]
PRINTER=XEROX4
DEFAULT=XEROX4
[reception]
PRINTER=XEROX4
DEFAULT=XEROX4
[alex]
PRINTER=XEROX4
DEFAULT=XEROX4
MENU=ON
TYPE=ON
ASKPRT=ON
PRTSPL=XEROX4,New Xerox
PRTSPL=BANK,original printer
[always]
PRINTER=BANK
DEFAULT=BANK

Intentions are that anything that prints for lkitney, reception or alex is to print on XEROX4 and everything else is to print on BANK. (unless of course user does something like print xerox4=file.txt then go to xerox4)

Problems at this point..
A handful of reports don't get printed anywhere, just seem to disappear when spooled.

I checked one of those and the spool is done as:
XCALL SPOOL,FILE,"",358,"","","",60
OR
XCALL SPOOL,FILE,"BANK",358,"","","",60

Another problem is that jobs run at night via cron aren't printing. The crontab file belongs to user lkitney which should mean everything would go to XEROX4.

What do you think?

Note above that PRINTER= lines are still commented out in miame.ini at this point.

If while logged in as alex, and I do a print xyz.txt the trace shows it printing to XEROX4 as expected. This is now picking this up from my .PRINTER file it looks like. For reception and lkitney likewise .PRINTER holds xerox4, all others are set to bank.

If I do a trace when doing an xcall spool in a simple program, here's what I get:

Trace: Default spooler name supplied:
Trace: EZSPL ptr = , file = alex.tst
Trace: Reading /vm/miame/dsk0/010010/system.spl
Trace: User = <[ALEX]>





Trace: EZSPL SPL options: PON=0, TPA=0, AON=0, OPT=1, tbl=0
Trace: SPOOL ptr = , switches = 0, dopies = 1
Trace: Checking for default printer in /home/alex/.PRINTER
Trace: lpr -Pxerox4 -#1 /vm/miame/dsk6/033001/alex.tst

Trace: system(lpr -Pxerox4 -#1 /vm/miame/dsk6/033001/alex.tst)
Trace: Hit any key:

Trace seems to show it doesn't find user alex as there are 5 sections in system.spl and 5 skipped sections.

Presumably prints to xerox4 due to finding it in .PRINTER rather than because of system.spl

I don't know what the trace is for users where a document didn't print anywhere. Also not what's happening when via cron, why no printing.

Thanks for your help,
Alex

What version are you running? It appears that in my version, the trace shows all of the lines of the spl file that actually get processed, whereas in yours, all we see is the skipping message. E.g. here's mine:

A-Shell 4.8(844)
set.lit 1.2(134)

Can update that, Linda sent me something about the latest many months ago but I didn't recall the install process.

20-Oct-11 16:45:40 J=TSKAAE P=QA U=dyathon T=pts/5:15956 F=/vm/miame/dsk6/033001/tran1.lst

lpr -Pbank -#1 -h -r /vm/miame/dsk6/033001/tran1.lst

20-Oct-11 23:00:02 J=TASAAA P=CLOSIT U=lkitney T=tsk:23305 F=/vm/miame/dsk1/033001/closit.rpt

lpr: unable to print file: client-error-bad-request

20-Oct-11 23:00:23 J=TASAAA P=REORG2 U=lkitney T=tsk:23305 F=/vm/miame/dsk6/033001/log.err

20-Oct-11 23:00:25 J=TASAAA P=PRINT U=lkitney T=tsk:23305 F=/vm/miame/dsk6/033001/log.err

20-Oct-11 23:00:28 J=TASAAA P=FNDBIL U=lkitney T=tsk:23305 F=/vm/miame/dsk6/033001/fndbil.rpt

20-Oct-11 23:00:30 J=TASAAA P=P U=lkitney T=tsk:23305 F=/vm/miame/dsk1/033001/trujnl.lst

20-Oct-11 23:00:30 J=TASAAA P=P U=lkitney T=tsk:23305 F=/vm/miame/dsk1/033001/timbil.lst

20-Oct-11 23:00:30 J=TASAAA P=P U=lkitney T=tsk:23305 F=/tmp/bakmsg.722

21-Oct-11 06:00:00 J=TASAAA P=TICRPT U=lkitney T=tsk:26428 F=/vm/miame/dsk6/033001/trpt1.lst

Note that the items starting at 23:00 are a group of nightly reports run via task manager/cron. It is the crontab of lkitney. The first report when spool is attempted results in lpr: unable to print file: client-error-bad-request.

I think that is because in the .bas/.run the xcall is:
XCALL SPOOL,"CLOSIT.RPT","",16,"","","",60
That's from some old code, but has never caused an issue before, so I don't know what's changed suddenly in it resulting in an error.

So I changed it to XCALL SPOOL,"CLOSIT.RPT" now without the additional parameters.

But seems there may be an issue with the task manager/cron. Why would it not show the lpr request in spool.log for these like it does for regular sessions?

Thanks Again

On the SPOOL.LOG issue, there are only two reasons that I can think of that a print request would not show:

1. The LP trace is set. (In this case, all of the tracing information is sent to the screen.)

2. The print operation aborts before it gets to the act of submitting the lpr request.

If this is reproducible, I would try to analyze the second possibility by launching the cron session with a special version of miame.ini that had many traces turned on (but not the LP trace). In particular, the XCALL trace would show that we actually get to the XCALL SPOOL. I would also turn on the FOPENS trace. And you should always have the SIGHUP, INOUT and BASERR traces enabled (at least in my opinion).

On the version issue, I'm afraid I can no longer provide any useful support for 4.8, as it is simply too long ago (about 8 years) to remember or practically investigate. I can accept the "if it ain't broke..." argument, but unfortunately that argument is fundamentally at odds with the idea of support. As an example of the difficulties involved, the EZ-SPOOL source module and the module containing the UNIX interface to the spooler have each had about 200 individual edits since then.

We are about to christen the current development version - 5.1.1238 - as the new stable 6.0 release. That's nearly 400 documented updates beyond where you are (not counting that each of those often had a .1, .2, .3 etc. patch). I certainly wouldn't expect production sites to suffer each of those updates, but we do expect people to at least get on the most recent "stable" (even number) release. In fact, our official policy is to only support the last stable release (currently 5.0, about to become 6.0), plus the current "development" release (currently 5.1, about to become 6.1).

By "support" here we mean that we maintain a separate set of source code matching the stable release, so that bugs can be patched as they get reported, without them being complicated by the on-going new features in the development version. So if we determined that a patch was needed to solve your problem, we could still do that to the 5.0 release, but not to the 4.8 release. In fact, as you can see from the 5.0 release notes , there have been quite a few patches to it in the nearly 4 years since it "went stable" in late 2007. But all of those patches were very specific fixes or refinements, designed to avoid introducing side effects so that affected people could update with confidence. And I think that scheme has been reasonably successful.

I would suggest redirecting some of the energy being spent on this issue into getting up to at least 5.0, or, given the imminent switch to 6.0, you might as well go all the way to the latest 5.1 release. You can always install it in a parallel directory for testing before doing the actual cut-over.

Sorry on the version, should have thought of that right from the start. Your software is well written, runs so smoothly I hadn't been upgrading their system.

For the upgrade method what document do I refer to?

I will upgrade tonite if possible.

See the page 5.0 page:
http://www.microsabio.com/a-shell50.html

And look at one of the text files in the Installation Instructions column of the table.

The same instructions would apply to going to 5.1, although there you have to just pull down the latest raw .bin file from the appropriate directory. (See the "you can get it here" link on the http://www.microsabio.com/downloads.html page)

Note: the main compatibility concern that I can recall being an issue in going from 4.8 up is the switch to the "decimal ppn" scheme. See edit 897 in the release notes for more details about that.

Some history on the hardware/software here.

A couple years ago their harwdware/os software company was going to upgrade them to a new linux server. They were going to replace two older computers with one. They went to one computer and plan was to move A-Shell onto that computer and install the latest version. I had explained what we needed to do and thought all was set.

Then on the weekend they went in, installed the new server and rather than going through the process, decided they'd just make a virtual out of the Fedora Core release 1 (Yarrow) that A-Shell was running on.

So here we are. I don't presume I can update to 5.1 A-Shell or have them supported by you on this virtual with Fedora Core 1 (or can I)?

The o/s of the new machine is CentOS. I'll have to get them involved again and see if we can install the latest A-Shell on it and test.

I don't see any particular problem with just installing the latest 5.x on your existing virtual machine. (Again, you probably want to start with a test installation in a new directory tree just to test it out first.) The one thing I'm not sure about is whether the -el4 version (which we recommend for all "modern" Linux versions) will work on Fedora Core 1 (which is kind of old at this point). But that's what I would start with, and if ashell doesn't launch, try the -lnx or -rh8x version instead.

(As long as you're in the updating mood, you might want to consider updating your Linux, but that can be done after the A-Shell update, with a possible need to switch between A-Shell variations depending on what you started with and ended up with.)

For what it's worth, I would say that most A-Shell/Linux users are running CentOS 4.x or 5.x.