RE: fun with printer overlays - how to change top margin by tiny increments (.01 inches)

I think that FRONTMGN(*DEVD) does the exact same thing as Change QPRTVALS, but on a single printer file (instead of system-wide). It seems to de-couple the overlay from the text.
Unfortunately, it also takes away any simple margin control -such as FRONTMGN (.25 .25)
Thanks for all your help!

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Musselman, Paul
Sent: Tuesday, March 20, 2012 4:59 PM
To: Midrange Systems Technical Discussion
Subject: RE: fun with printer overlays - how to change top margin by tiny increments (.01 inches)

<<I think if I change a system-wide printer control data area as a contractor, that would be the last thing I do at my current gig :) >>

You don't have to be a contract programmer to execute a 'last thing' command! (;

<<Good question. I have talked to other pgmrs on BBSs who have been thru this, and they have a separate control table. They use a std offset, but if a particular printer or outq is in the control table, then they add that offset to the margins in the pgm. Kinda yucky, but it will work. Any better ideas??>>

I don't know how yucky it is, but ours works-- we decoupled the overlay from the text around 1999, when we were first getting involved with overlays. Had similar issues-- we couldn't get the overlays high and to the left enough. We wrote a standard routine-- the user passes the application name and warehouse code, and we look it up in a file and find the front and back overlay names, the front and back offsets, and the text margins. We assemble a generic OVRPRTF command with 'holes' for the user to plug in the outq name and library and pass the string back to the user. This lets us customize almost everything for each location-- from the name of the overlay(s) to the individual offsets. All the offsets are in the control file-- no defaults (other than system defaults). And the user program doesn't have to know a thing about the overlay other than which output queue it wants to use.

Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Tuesday, March 20, 2012 5:36 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: fun with printer overlays - how to change top margin by tiny increments (.01 inches)

"Change QPRTVALS: "

I think if I change a system-wide printer control data area as a contractor, that would be the last thing I do at my current gig :)


"FRONTMGN(*DEVD) takes all control of the text alignment away from you. "

Not really. But it does seem to force me to re-work the pgm to externalize the printer file so I can then use the POSITION keyword. Although I must use that for EACH text line, so it is somewhat involved. If I use a variable ie POSITION(&VPOS .5) then at least I can bump up the VPOS variable for each line by 1/6.

"Can you try FRONTMGN(0.25 0.25)? That should give results similar to FRONTMGN(*DEVD)."

Tried all that. It works, but the margins are unnecessarily wide using the 0,0 mark. I found that if I use FRONTMGN(*DEVD), I can use the entire geography of the printer to print. I have to print higher up the page than the 0,0 mark that FRONTMGN (0 0) allows.

"As a side note-- if you make this change for the new printer, how will it affect the old printers??"

Good question. I have talked to other pgmrs on BBSs who have been thru this, and they have a separate control table. They use a std offset, but if a particular printer or outq is in the control table, then they add that offset to the margins in the pgm. Kinda yucky, but it will work. Any better ideas??






-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Musselman, Paul
Sent: Tuesday, March 20, 2012 4:07 PM
To: Midrange Systems Technical Discussion
Subject: RE: fun with printer overlays - how to change top margin by tiny increments (.01 inches)

Joel--

Do you have a QPRTVALS data area? Would you be able to create one and de-couple the overlays from the text at least for a test?? Using the QPRTVALS data area you can set the FRONTMGN wherever you want it, independent of the overlay offset.

I think the FRONTMGN(*DEVD) takes all control of the text alignment away from you. FRONTMGN(*DEVD) probably shifts the data origin to a point 1/4" from the top and 1/4" from the left side. This setting is determined by the printer, not the system. The overlay can be moved in relation to the data origin, but can't go higher or farther left.

Can you try FRONTMGN(0.25 0.25)? That should give results similar to FRONTMGN(*DEVD).

As a side note-- if you make this change for the new printer, how will it affect the old printers??

Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Tuesday, March 20, 2012 4:39 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: fun with printer overlays - how to change top margin by tiny increments (.01 inches)

The reason I am fighting this battle: A widely used contract form prints on many different printers. A box prints all around the page (1/2" from the border).

On a new printer, the top line of the box is too low, it collides with a pre-printed corporate logo.

I have to move the box up a hair. The only way I have found to do that is use FRONTMGN(*DEVD). This moves the OVERLAY up (but too far), along with the text.

Now I have to move the OVERLAY AND the text down (but not as far down as it used to be).

I can move the OVERLAY down nicely (and precisely) using the FRONTOVL(overlayname .2 .1), which works perfectly.

However by using the FRONTMGN(*DEVD) keyword, I seem to have lost any ability to move the text back down - at least with an internally-described printer.

So how do I tweak the text down - with precise control - if I already nullified the FRONTMGN control by using FRONTMGN(*DEVD) ?