RE: ostensibly identical spool files (Long) -- MIDRANGE-L

I think we played with something like that from Gumbo.  You could set up
filters to slice and dice reports, move them anywhere, email, etc.  I don't
quite recall, but I thought the *COPY* overlay thing was one of the
scenarios in the manual.  It's been a while.. :/

Eric DeLong
Sally Beauty Company
MIS-Sr. Programmer/Analyst
940-898-7863 or ext. 1863



-----Original Message-----
From: Draper, Dale [mailto:dale.draper@seu.sega.com]
Sent: Friday, November 02, 2001 11:11 AM
To: 'midrange-l@midrange.com'
Subject: RE: ostensibly identical spool files (Long)


Haven't I read of a utility that allows a spoolfile to be sent to multiple
outq's at the same time? Would that solve the requirement?

-----Original Message-----
From: MBarton@pink.co.uk [mailto:MBarton@pink.co.uk]
Sent: Friday, November 02, 2001 9:01 AM
To: midrange-l@midrange.com
Subject: RE: ostensibly identical spool files (Long)





>Eric said
>Does you original PRTF specify font or page margins that may be different
in
>the copied SPLF. Have you compared the spool file attributes to see if
there
>are differences?  Use WRKSPLFA OUTPUT(*PRINT) on both splfs and compare the
>reports.



     the external printer file was created with virtually no changes
to the defaults - only page size/length/overflow

I then performed the override (lpi/cpi overlay) and generated the spool
file.

A WRKSPLFA of both produces the following (only differences shown)
The first column is the original spool, the second the copied one
using CTLCHAR(*FCFC) to QSYSPRT.

 Device file  . . . . . . . . . . . . . . :   MSP635F             QSYSPRT
   Library  . . . . . . . . . . . . . . . :     MIKEUTL                QSYS

 User-specified data  . . . . . . . . . . :   MSP835              (blank)
 Program that opened file . . . . . . . . :   MSP835               (blank)
   Library  . . . . . . . . . . . . . . . :     MIKEUTL
(blank)
 Date file was opened . . . . . . . . . . :   02/11/01            different
 Time file was opened . . . . . . . . . . :   15:29:41            ditto
 Date file was last used  . . . . . . . . :   02/11/01            ditto
Record length  . . . . . . . . . . . . . :   *RCDFMT              125
Control character  . . . . . . . . . . . :   *NONE            *FCFC

Doing a DSPFD of the 2 printer files does reveal more differences but
I have now taken these into account.

>Paul said
>The *AFPDS to PCL conversion of the OS/400 Host Print Transform function
>works best when the spool file to be printed has been created by an
>application as opposed to copied from an already existing spool file.

I have no problem with this however....

I copied the normal spool to a physical file using FCFC.
I then wrote a short program to generate a copy of the spool using
the control chars in the physical file and then wrote the data to an
externally defined printer file within this program - with all the previous
over-rides in-situ.

The result was the same as if I had copied the physical file to QSYSPRT
however I have used ostensibly an application to generate the spool.

>If you changed your application logic to create two spool files (one
>production - one copy), using different printer files to choose the
>destination output queue and overlay to be applied, you would probably
>resolve your problem.

As mentioned b4, I would like to keep an original version for archive
purposes (and preferably a SCS type spool).


The only thing that I can think of  is that the CPYSPLF *FCFC is putting
in some invisible characters which subsequently alters any spool file
generated from the file.

Very strange !

 Mike



This communication and the information it contains: - (a) Is intended for
the person(s) or organisation(s) named above and for no other person(s) or
organisation(s).  Access to this mail by anyone else is unauthorised.  (b)
Is confidential, and may be legally privileged or otherwise protected in
law. Unauthorised use, circulation, copying or disclosure of any part of
this communication may be unlawful.  (c) May be susceptible to interference,
and should not be assumed that it has come in its original form and/or from
the stated sender or PinkRoccade UK accepts no responsibility for
information, errors or omissions in this e-mail or use or misuse thereof or
any act done or omitted to be done in connection with this communication. If
you are not the intended recipient, please inform postmaster@pink.co.uk
immediately and delete it and all copies from your system.
_____________________________________________________________________
This message has been checked for all known viruses by PinkRoccade delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.