× 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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.