× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



that's an interesting idea, but but we don't know what the client has
named their devices. the output could go to a general outq and then
be moved to the printer of their choice.

we have company option flags we can set to determine these things -
the customer can set to what they want it to be after testing to see
where it belongs.

thanks again,


On Tue, Jan 17, 2012 at 9:59 AM, James Horn <jdhorn@xxxxxxxxxxxxxx> wrote:
We have used the old technique of printing a device description and finding
the TYPE or WSCST and returning that to the program.
If both exist it returns the WSCST.  We test that to determine overlay
placement.

Jim

/*------------------------------------------------------------------*/

/* retrieve the TYPE/WSCST OF a printer
*/


            PGM        PARM(&PRT &TYPE
&WSCST)


            DCL        VAR(&prt    ) TYPE(*CHAR)
LEN(10)
            DCL        VAR(&TYPE   ) TYPE(*CHAR)
LEN(10)
            DCL        VAR(&WSCST  ) TYPE(*CHAR)
LEN(10)
            DCL        VAR(&JOBNAME) TYPE(*CHAR)
LEN(10)
            DCL        VAR(&USER) TYPE(*CHAR)
LEN(10)
            DCL        VAR(&NUMBER) TYPE(*CHAR)
LEN(6)
            DCL        VAR(&text  ) TYPE(*CHAR)
LEN(15)




            DCLF
FILE(QTEMP/TEST)


            MONMSG
MSGID(CPF0000)


            RTVJOBA    JOB(&JOBNAME) USER(&USER)
NBR(&NUMBER)



             DLTSPLF    FILE(Qpdcdev )
JOB(&NUMBER/&USER/&JOBNAME)


             OVRPRTF    FILE(QPDCDEV)
HOLD(*YES)
             DSPDEVD    DEVD(&prt)
OUTPUT(*PRINT)


             CRTPF      FILE(QTEMP/TEST)
RCDLEN(132)


             CPYSPLF    FILE(Qpdcdev ) TOFILE(QTEMP/test)
+

JOB(&NUMBER/&USER/&JOBNAME)
 STARTLOOP:
RCVF
             MONMSG     MSGID(CPF0864) EXEC(GOTO
CMDLBL(ENDloop))


             IF         COND(%sst(&Test 41 4) *EQ 'TYPE')
THEN(DO)
             CHGVAR     VAR(&type ) VALUE(%SST(&test  53
10))
             GOTO
CMDLBL(STARTLoop)

enddo


             IF         COND(%sst(&Test 41 5) *EQ 'WSCST')
THEN(DO)

             CHGVAR     VAR(&type ) VALUE(%SST(&test  53 10))
             GOTO       CMDLBL(STARTloop)
             enddo

             GOTO       CMDLBL(STARTLOOP)

 ENDloop:     DLTSPLF    FILE(Qpdcdev ) JOB(&NUMBER/&USER/&JOBNAME)

             ENDPGM
------------------------------

message: 3
date: Mon, 16 Jan 2012 16:31:36 -0600
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: overlays and laser printer shifting issues

hi Rick,

On 1/16/2012 4:12 PM, rick baird wrote:
In the last 2 or 3 years, we've had an ongoing problem with overlay
and/or laser output shifting out of alignment at some of our client
sites.


Yes, in my experience, overlays printed through Host Print Transform
tend to print in different positions, depending on the particular
MFRTYPMDL specified.

In one of my programs, I have worked around it as follows...

The DDS for the PRTF has this:

     A                                      OVERLAY(MYLIB/INVOICE -
     A                                      &PROVLDWN &PROVLACS)

(Mine is done via DDS, though you could do the same thing via parameters
on CRTPRTF, CHGPRTF or OVRPRTF if you prefer.)

Then my RPG code does this:

 prOvlDwn   = 0;
 prOvlAcs   = 0.25;

 if (wkDev = 'PRT06');
   prOvlDwn = 0.167;
 endif;

So, for some devices, the "down" position is 0, and others it's 0.167.
This makes it line up in both cases.  Sadly, I have it hard-coding the
device names of the devices that need a different offset (there's
probably a better way, but I haven't found it yet.)

My suggestion to you, therefore, is to make this "down" position
configurable.  Ask your customer to do a test print, and if it's not
lined up, then change the down position and try again.  If your overlay
position is specified via CRTPRTF like this:

   CRTPRTF FILE(myfile) FRONTOVL(myoverlay 0 0)

Then your instructions to the customer might be as simple as saying "if
the overlay doesn't line up, then type this command:
CHGPRTF FILE(myfile) FRONTOVL(myoverlay 0.167 0)"

If you find a better solution, please let me know... because this is a
frustration of mine.

-SK

--
Jim Horn
CATCO  651-697-6314    JDHorn@xxxxxxxxxxxxxx
Cell   612-791-3924
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.