Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
Trailing Blanks in BARCODE in DDS
has no ratings.
Published: 29 Jul 2014
Revised: 01 Aug 2014 - 1031 days ago
Last viewed on: 28 May 2017 (2143 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Trailing Blanks in BARCODE in DDS Published by: Bob Cozzi on 29 Jul 2014 view comments(5)

I am modifying a legacy app that uses the BARCODE keyword.

Barcode lengths have changed over the years and this app has a fixed-length barcode field in the DDS.

Obviously if the field isn't filled up, trailing blanks are included in the barcode that is printed on the page. I'm wondering if anyone has a trick that can prevent those trailing blanks from showing up in the barcode? The direction I'm going in is obvious--multiple fields, each with a different length--but that's just crazy.

Are there any alterntives?

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: DaleB
Premium member *
Reading, PA
Comment on: Trailing Blanks in BARCODE in DDS
Posted: 2 years 9 months 30 days 14 hours 40 minutes ago

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.

Posted by: Ringer
Premium member *
Comment on: Trailing Blanks in BARCODE in DDS
Posted: 2 years 9 months 30 days 10 hours 11 minutes ago

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 

Posted by: clbirk
Premium member *
Comment on: Trailing Blanks in BARCODE in DDS
Posted: 2 years 9 months 29 days 11 hours 15 minutes ago

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

Posted by: Ringer
Premium member *
Comment on: Trailing Blanks in BARCODE in DDS
Posted: 2 years 9 months 29 days 11 hours 1 minutes ago
Edited: Thu, 31 Jul, 2014 at 11:43:29 (1032 days ago)

> 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 

Posted by: DaleB
Premium member *
Reading, PA
Comment on: Trailing Blanks in BARCODE in DDS
Posted: 2 years 9 months 28 days 9 hours 21 minutes ago

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, ...]