Based on your question, I'm assuming the BARCODE is one that takes character data (A). What happens if you pad with a character that is not in the barcode's data set, such as x'00'? Should be easy enough to set up a test scenario. Either it works, it prints unwanted bars in place of the x'00', or the write to the PRTF will fail because the barcode data is invalid.

Looked at CVTDTA, which allows you to pass raw barcode instructions, but that seems to require a fixed length, so you'd still need different fields for every length possibility. Different length BARCODE fields would be easier.

If your BARCODE is numeric (S), I think your only option is to have different length fields for every possibility.

if someone has a solution, that would be awesome. I condition a few fields in the DDS, usually 5 characters difference in lengths. Not pretty. So if the max value is 40a for CODE3OF9 but typical value is 30a, I code a 30a, 35a, 40a in the DDS and set indicators. ... What you suggested. 

A narrow bar width such as .007 or .008 produces a more dense barcode too. Those look exactly the same on an HP Laser printer. The .009 and .010 widths (again they look identical) produce a less dense (longer) barcode. 

Chris Ringer 

Chris,

I have lots of applications that produce different length and types of barcodes all day long, and the same area may have many different variables. Of course I am not using the BARCODE command as all our printers are driven by io corp software(adaptio)/print servers and in such, you simply terminate your barcode string with a ^b sort of deal. Of course, we started that way back a few decades ago. I can vary height, width (thickness), etc.  Sounds like to me the BARCODE DDS spec is lacking for modern things.

chris

> Sounds like to me the BARCODE DDS spec is lacking for modern things. 

Yep. You'd think it would have a "*TRIMR" option by now in 2014. 

Chris 

Did find one guy that was editing the DDS (from program) and recompiling the PRTF every time, to alter the field length of the BARCODE. Might not be too bad if you could ensure it were single-threaded. Otherwise you'd want to copy the source to QTEMP, CRTPRTF to a unique name, with appropriate OVRPRTF or EXTFILE. Then you'd want a cleanup job to run at some future time, to delete the no longer needed *FILEs once the SPLFs no longer exist. [Not that you can't create a *FILE PRTF in QTEMP, but printer writers sometimes get weird about that, since they no longer have access to the *FILE object at print time. Ordinary SCS files are usually OK, but as soon as you start involving fonts, or any IPDS or AFP stuff, ...]