|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
