Group,

Have you ever tried to copy a print hold-file from peqs to unix and
forgotten to enter the '(' immediately after the 'to:'? Well, I've done
this many times over the years. I have a couple of questions related to
this mistake:
1: It appears that AIX/d3 will not allow you to copy a print hold-file in
peqs to a non-numeric item ID (it seems to go into the system debugger).
Why?
2: Can you copy a print hold-file that has been copied to another file for
archiving purposes back to the peqs file (using a numeric item ID) and then
print it?

Rob

On 2011-01-31 19:34:45 -0500, "Robert S. Lobel" <RobertLobel (AT) COX (DOT) net> said:

Yes, but the restored item will show in the peqs listing with current
user id, account, date, time, etc., not the original

--
Kevin Powick

We're on D3/Linux (don't know if it is different for AIX or not) but I had a conversation a few months ago with TL about the HDR:PEQS items and how to retain those values if you copy items back into PEQS. I was told that itcan't be done.

We had a situation come up where I knew the spooler was hammered and neededto be reinitialized but I needed the several thousand print jobs that wereout there and I needed them to be in the correct queues etc..... I copiedthe PEQS and the HDR:PEQS into another file but couldn't get the HDR data to copy back in. TL basically said "you can't get there from here". So, long story short..... What Kevin said.

Steve

Kevin and Steve have already said you can't copy HDR:PEQS back to
PEQs, but that may not be important. You can copy the report data,
and restore it, and you can read the HDR metadata with code. So
(without doing this on a moment's notice) I can picture a small bit of
code that saves PEQS data to "PEQS.HOLD" and HDR data to
"PEQS.HOLD.HDR". Then you can restore data back to PEQS and use the
PEQS.HOLD.HDR data to guide where it gets printed and who gets it.

As far as accidentally missing the "(" on a Copy/To, it's easy to
overload the COPY and other commands to avoid this from happening.

As always, the environment is versatile and extensible. The DBMS
provide us with tools and it's up to us to use them. I much prefer
that they do this rather than trying to accommodate every possible use
and mis-use of the system.

In summary. All of the problems described here can be fixed pretty
easily without assistance from TL.

T

"Robert S. Lobel" <RobertLobel (AT) COX (DOT) net> wrote:

What Tony said is true (as usual) but you just need to do some Hex to Decimal conversions. A lot of the HDR fields are stored as Hex values (at least in D3/Linux).

Perhaps this topic could be added to "I wish I could do this with my Pick
system..." that Tony started.

I for one would like expanded print spooler options that allowed for (OTC)
- the saving of certain hold entries onto tape
- the restoration of hold entries from tape
- the retention of HDR details
- naming of hold entries
- admin thru dashboard
- etc

Would be great if we could get some consensus in this area, so that
petitioning TL would see some improvements added.

Rgrds Mario

"Robert S. Lobel" <RobertLobel (AT) COX (DOT) net> wrote

Perhaps this topic could be added to "I wish I could do this with my Pick
system..." that Tony started.

I for one would like expanded print spooler options that allowed for (OTC)
- the saving of certain hold entries onto tape
- the restoration of hold entries from tape
- the retention of HDR details
- naming of hold entries
- admin thru dashboard
- etc

Would be great if we could get some consensus in this area, so that
petitioning TL would see some improvements added.

Rgrds Mario

"Robert S. Lobel" <RobertLobel (AT) COX (DOT) net> wrote

"MarioB" wrote:

Wow, surprised to see you here man.

SP-ASSIGN TS
SP-EDIT xxMS

Weeeeeeeeeeeeee off to tape...

SP-TAPEOUT

Weeeeeeeeeeeeee back from tape

Buzzer sounds. This is possible, but probably not from TL anytime in
the near future. See prior post. *Will code for pizza.*

Reference back to my recent note about OSFI drivers. If TL would open
the API to the honkin Open Systems File Interface then we'd be able to
do this and a hundred other things all by ourselves.

ibid, with a little front-end code. We have the tools.

Probably already possible with TL's new SysAdmin app, with an
extension to same, or with lots of pizza and a weekend with no other
business.

I'll repeat back to you a line that you gave me some years ago:
changes can be made if there is a business case to justify it. Will
anyone here claim that they can sell more systems if the above
features are added? I don't think so. With the exception of the HDR
driver interface, I think this stuff is better left to the field.

YMMV
T

We "sort of" offer that option to our users now --> when a report is
generated, one of the desitination "printers" that people can direct a
report to is "F"ile .... the end result of which is an entry in a
database to describe the spooler entry (ie: who printed it, when, what
it is), and also a copy of th report stored in a "normal" (D3 or host
OS) file that can then be used to reprint, display on screen etc.

(We have found this "better" that SP-TAPEOUT etc, as the files simply
become part of the normal backup cycle, and are readily accessible
"online" - much better than the old COLD solutions people used to put
in place for this sort of stuff IMHO)

The tools are already there .... probably just a case of a minor
"tweak" to the application in question to utilize