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



I have only used BARCODE a few times.

One example is this:
BARCODE(CODE3OF9 1 *NOHRI X'01') - compiled without UOM

A second example, compiled with UOM(*CM)

BARCODE(CODE 128 2 *NOHRI X'01')

John McKee

On Wed, Nov 14, 2012 at 7:48 AM, chris barr <cbarr5011@xxxxxxx> wrote:
John McKee,

Thanks for the response.

In my original post I have (.1 *UOM) which is the smallest value for an inches.
I tried it with (.25 *UOM) with my PRTF compiled with the Unit of Measure
of centimeters. Neither worked.

thanks,
cb



________________________________
From: "midrange-l-request@xxxxxxxxxxxx" <midrange-l-request@xxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Tue, November 13, 2012 10:41:00 PM
Subject: MIDRANGE-L Digest, Vol 11, Issue 1806

Send MIDRANGE-L mailing list submissions to
midrange-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
midrange-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MIDRANGE-L digest..."


*** NOTE: When replying to this digest message, PLEASE remove all text unrelated
to your reply and change the subject line so it is meaningful.

Today's Topics:

1. Re: Using SSD with IBMi V7R1 (Luis Rodriguez)
2. JDE Green Screen and system values QPRCMLTTSK and QQRYDEGREE
(Jim Oberholtzer)
3. Re: RUNSQL Command: Help & Escape Messages (Sam_L)
4. Re: JDE Green Screen and system values QPRCMLTTSK and
QQRYDEGREE (John Jones)
5. Re: BARCODE Keyword (franz400)
6. Re: JDE Green Screen and system values QPRCMLTTSK and
QQRYDEGREE (Jim Oberholtzer)
7. RE: BARCODE Keyword (chris barr)
8. Re: BARCODE Keyword (John McKee)


----------------------------------------------------------------------

message: 1
date: Tue, 13 Nov 2012 19:42:35 -0430
from: Luis Rodriguez <luisro58@xxxxxxxxx>
subject: Re: Using SSD with IBMi V7R1

Kenneth

Last year I came across the following developerWorks article:

http://tinyurl.com/6aqt5xl

Check it out, I think you will find it very interesting...

Best Regards,


Luis Rodriguez
IBM Certified Systems Expert ? eServer i5 iSeries
--




On Tue, Nov 13, 2012 at 7:35 PM, Graap, Kenneth <Kenneth.Graap@xxxxxxxxxxxxx
wrote:

I?m new to using SSD?s (Solid State Drive)? In a few days I will be
installing 8 - 177GB SSD?s to my system.

My thoughts are:

I will add them into the iASP containing our production
data.

I will specify that certain heavily used files be stored
on SSD using this command:

CHGPF FILE(P1FILES/ARCONY) UNIT(*SSD)

And then occasionally run this command:

STRASPBAL TYPE(*MP)

What do you think?

Is this a good way to utilize our new SSD resource ?

Kenneth
AKA ? ??? or ???
Kenneth E. Graap
System Administrator
503.226.4211 x5537
http://www.linkedin.com/in/kennethgraap




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





------------------------------

message: 2
date: Tue, 13 Nov 2012 18:18:11 -0600
from: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
subject: JDE Green Screen and system values QPRCMLTTSK and QQRYDEGREE

Do any of you folks running JDE green screen version (I forget if it's
World or OneWorld) know of a reason why QPRCMLTTSK (Processor Multi
Tasking) or QQRYDEGREE (Query Processing degree) should be set:

QPRCMLTTSK: Off
QQRYDEGREE: *NONE.

I would have thought turning on multitasking (9406-825 with all four
processors turned on) and setting query degree to *OPTIMIZE would be
good things.

The customer has them turned off and before we turn them on and learn
the hard way that was a bad idea, I thought I would ask your thoughts....

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects



------------------------------

message: 3
date: Tue, 13 Nov 2012 20:21:32 -0500
from: Sam_L <lennon_s_j@xxxxxxxxxxx>
subject: Re: RUNSQL Command: Help & Escape Messages

Vern,

I put it in a CL program, which I called from both QCMD and with SBMJOB.
Both resulted in only a SQL0104 diagnostic message.

I ran this, which succeeded, as expected:
RUNSQL SQL('create table qtemp/mytable as (select * +
from QIWS/QCUSTCDT) with no data') +
COMMIT(*NONE)

Then I ran this, which failed with SQL0204, which is the right message,
but still only a diagnostic:
RUNSQL SQL('create table qtemp/mytable as (select * +
from ZZZZ/QCUSTCDT) with no data') +
COMMIT(*NONE)
And just for completeness, I did a SBMJOB, with the same result.

I posted a comment on the developerWork site.

Sam

On 11/13/2012 7:07 PM, Vernon Hamberg wrote:
Sam

Are you running the command only from a command line? It might not throw
an escape message there - some commands are like that. Try it in a program.

Vern

On 11/13/2012 4:38 PM, Sam_L wrote:
Luis,

SQL0104 is the correct message, but it a diagnostic. I think that if
your statement fails, then you should get an escape message, and the
developerWorks documentation seems to agree.

I'll do a little more experimentation, but so far I have failed to get
it to throw an escape message.

I did not notice the comment link--thanks. Seems a reasonable
explanation of the missing help.

Sam

On 11/13/2012 7:40 AM, Luis Rodriguez wrote:
Sam,

At the end of the developerWorks page you cited, there is a "Comments"
link. Of of those comments explains that the command has no Help Text
due,
mainly, to the need to translate it into several languages (and
providing
multiple PTFs for them). It seems that the help text would arrive
with the
next release .

Also, did you check the command with a valid SQL statement that, for
instance, tried to use an invalid file name? SQL0104 is, I think, the
proper message for the statement you wrote :-)

Best Regards,


Luis Rodriguez
IBM Certified Systems Expert ? eServer i5 iSeries




------------------------------

message: 4
date: Tue, 13 Nov 2012 20:28:33 -0600
from: John Jones <chianime@xxxxxxxxx>
subject: Re: JDE Green Screen and system values QPRCMLTTSK and
QQRYDEGREE

World is the green screen edition of JDE.

What you'll find is that the apps themselves are basically single-threaded
and that enabling multiprocessor support won't speed up individual jobs.
That said, when the jobs do database or query work that extra processor
capability will kick in. You can safely crank up the system values; you
won't have any problems.

Where multiple CPUs helps JDE the most is in allowing you to run more jobs
concurrently. Open up QBATCH to run more concurrent jobs. But leave the
Post and FASTR job queues single threaded; Post because you can mess things
up if multiple posting jobs run concurrently and FASTRs because multiple
FASTRs for the same user can cause record locking and slow the jobs down
instead of speeding them up. (You can run FASTRs from different users
concurrently with no problems, but generally people don't manage World
workloads to that granularity.)

The rule of thumb for World is that more CPUs = more concurrent jobs;
faster CPUs = shorter job run times. Both more & faster CPUs help, but
they affect performance in different ways. And "faster" CPUs should be
determined by CPW/CPU, not CPU clock speed.

On Tue, Nov 13, 2012 at 6:18 PM, Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

Do any of you folks running JDE green screen version (I forget if it's
World or OneWorld) know of a reason why QPRCMLTTSK (Processor Multi
Tasking) or QQRYDEGREE (Query Processing degree) should be set:

QPRCMLTTSK: Off
QQRYDEGREE: *NONE.

I would have thought turning on multitasking (9406-825 with all four
processors turned on) and setting query degree to *OPTIMIZE would be
good things.

The customer has them turned off and before we turn them on and learn
the hard way that was a bad idea, I thought I would ask your thoughts....

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

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




--
John Jones, CISSP


------------------------------

message: 5
date: Tue, 13 Nov 2012 21:56:13 -0500
from: "franz400" <franz400@xxxxxxx>
subject: Re: BARCODE Keyword

Have you read this IBM doc on IMB? It indicates slightly diff parameters

http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037e/0ecbcf493952b3a6862573d9007269db?OpenDocument


Jim Franz

----- Original Message -----
From: "chris barr" <cbarr5011@xxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, November 13, 2012 11:09 AM
Subject: BARCODE Keyword


I'm working on the IMb Barcode. I have a good barcode except that it is
too
big.

I have an Ricoh/IBM Infoprint 1872 and the firmware is current.

Here is the DDS code I used to create the barcode that came from the US
Postal
Site. Unit of Measure is *Inch and I have it set at .1. I tried it at
different sizes up to one inch, but the barcode never changes sizes. It
stays
at .25 inches.

IMBC31 31S 0 20BARCODE(34 (.1 *UOM) X'04' *HRI)

Has anyone experienced this issue with this barcode?

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




------------------------------

message: 6
date: Tue, 13 Nov 2012 22:05:09 -0600
from: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
subject: Re: JDE Green Screen and system values QPRCMLTTSK and
QQRYDEGREE

Thanks John!

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 11/13/2012 8:28 PM, John Jones wrote:
World is the green screen edition of JDE.

What you'll find is that the apps themselves are basically single-threaded
and that enabling multiprocessor support won't speed up individual jobs.
That said, when the jobs do database or query work that extra processor
capability will kick in. You can safely crank up the system values; you
won't have any problems.

Where multiple CPUs helps JDE the most is in allowing you to run more jobs
concurrently. Open up QBATCH to run more concurrent jobs. But leave the
Post and FASTR job queues single threaded; Post because you can mess things
up if multiple posting jobs run concurrently and FASTRs because multiple
FASTRs for the same user can cause record locking and slow the jobs down
instead of speeding them up. (You can run FASTRs from different users
concurrently with no problems, but generally people don't manage World
workloads to that granularity.)

The rule of thumb for World is that more CPUs = more concurrent jobs;
faster CPUs = shorter job run times. Both more& faster CPUs help, but
they affect performance in different ways. And "faster" CPUs should be
determined by CPW/CPU, not CPU clock speed.

On Tue, Nov 13, 2012 at 6:18 PM, Jim Oberholtzer<
midrangel@xxxxxxxxxxxxxxxxx> wrote:

Do any of you folks running JDE green screen version (I forget if it's
World or OneWorld) know of a reason why QPRCMLTTSK (Processor Multi
Tasking) or QQRYDEGREE (Query Processing degree) should be set:

QPRCMLTTSK: Off
QQRYDEGREE: *NONE.

I would have thought turning on multitasking (9406-825 with all four
processors turned on) and setting query degree to *OPTIMIZE would be
good things.

The customer has them turned off and before we turn them on and learn
the hard way that was a bad idea, I thought I would ask your thoughts....

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects

--


------------------------------

message: 7
date: Tue, 13 Nov 2012 20:20:00 -0800 (PST)
from: chris barr <cbarr5011@xxxxxxx>
subject: RE: BARCODE Keyword

Jim Franz,

Thanks for the response. Yes I started out with that exact code. However, when

we sent the barcode to the US Postal Service, they said it was too big. That?s
why I added the *UOM (unit of measure) parameter. I figured that .1 of an inch
would shrink it down, but it didn?t. That?s why I?m on this site asking for
help.

thanks,
cb

------------------------------

message: 8
date: Tue, 13 Nov 2012 22:40:35 -0600
from: John McKee <jmmckee@xxxxxxxxxxxxxx>
subject: Re: BARCODE Keyword

UOM does not influence the barcode height. That is a parameter which I
think I saw in your original post as .9. Try decreasing that number a
little.

John McKee

On Tue, Nov 13, 2012 at 10:20 PM, chris barr <cbarr5011@xxxxxxx> wrote:
Jim Franz,

Thanks for the response. Yes I started out with that exact code. However,
when
we sent the barcode to the US Postal Service, they said it was too big.
That?s
why I added the *UOM (unit of measure) parameter. I figured that .1 of an
inch
would shrink it down, but it didn?t. That?s why I?m on this site asking for
help.

thanks,
cb
--
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.



------------------------------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest 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.



End of MIDRANGE-L Digest, Vol 11, Issue 1806
********************************************
--
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 ...

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.