Re: ostensibly identical spool files (Long)

A thought... If the DDS uses *PRTCTL instead of *FCFC, there would be a 3 byte 
difference. The *PRTCTL uses a 4 character field, versus the 1 character on 
*FCFC. They doing the CPYSPLF with *PRTCTL, instead of *FCFC
Bob

MBarton@pink.co.uk wrote:

> Hi
>
> I thought I would post this as a follow up for anyone who tries a
> similar thing to what I was attempting.
> You'll all probably say now  'well that will never work' !
>
> I will explain (again) what I was trying to do.
>
> Simple DDS external printer file with header/detail/footer formats.
> Just before calling the program I did an OVRPRTF to change
> the cpi/lpi, change to an AFPDS spool type and add an overlay
> (the overlay had no bearing whatsoever on the problem).
>
> This lined up perfectly.
>
> I then called the same program but w/o the over-ride which generated
>  which normal (SCS) spool.
> I then copied this using CPYSPLF *FCFC and then using an identical
> override to the one b4, generated a new spool.
> When this printed, the as/400 print was offset by about 3 characters to
> the right (but not the overlay).
>
> I now realise that my understanding of how spool files are held on the
> as/400 was too simplistic !
> The as/400 holds the indiviual fields (from external printer file) and not
> a single record/field which was generated by CPYSPLF process.
> The printing process (AFAIK)  adjusted the left margins depending on
> the fields in the spool.
> The externally described print spool only had one field per
> record in the spool - hence the difference.
>
> Many thanks to Paul Tykodi for his persistence and pointing me to
> Rodney Johnson @ ibm
>
> May this matter now rest
>
> 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.