----- Original Message -----
From: midrange-l-request
Sent: 07/22/2010 03:20 PM EST
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 9, Issue 1212
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: Varying fields and SQL predicate LIKE (CRPence)
2. Re: Varying fields and SQL predicate LIKE (Alan Shore)
3. RE: Setting up IPDS printer (Grizzly Malchow)
4. Re: Varying fields and SQL predicate LIKE (Charles Wilt)
5. RE: Setting up IPDS printer (Dan Kimmel)
6. Re: Setting up IPDS printer (Aaron Bartell)
----------------------------------------------------------------------
message: 1
date: Thu, 22 Jul 2010 12:34:58 -0700
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: Varying fields and SQL predicate LIKE
On 22-Jul-2010 11:16, Charles Wilt wrote:
I'm not following this part.
Why would '% MAIN%' be better than '%MAIN%'?
One scenario will be able to cut-short its processing due to a
known length, whereas the other will have to compare the remaining
characters. Fewer matching prefix bytes means even less comparisons
across the following bytes, so there is less potential for
improvements. The cost of the comparisons are very small until the
complexity of the scan increases the amount of work. Even so, a
mostly insignificant portion of the overall amount of work.
In actuality, I tried to be smart....when I built my varying
search key field, I did the following:
replace(translate(addr1
,' '
,';:.,!@#$%?&*()-_+={}|??\"<>?/~`')
,' ','' ) as cmpAdr
So that the original data '123 MAIN ST.' became '123MAINST'
That takes care of the concern I raised.
Which lowered the average length of the data from 16 to 13. So I
was really looking for a 48% improvement...
But only an improvement for the scan processing, not for the
overall query processing. Even if measuring actual CPU-time versus
clock-time, the fixed-costs will skew downward any potential for
improvement.
The I\O is an effective fixed-cost for the table scan, increased
by a little more than 6MB in the given scenario for changing to add
the two-byte varying length. The CPU cost is near insignificant for
the comparisons against the non-matched bytes across the storage
which will already have been paged into memory; paged with similar
characteristics for both scenarios. Each will have similar CPU
costs for everything other than the text string scanning.
According to the percentages given, instead of looking for an
overall percent improvement, you are looking for an improvement only
with character scanning. Subtract from each test scenario, the
overall cost of selecting a single-byte comparison which will either
never match any row from or will match every row on the first byte;
a one-byte compare with no match includes the cost of doing all of
the I\O, but with the most minimally complex scan [compare of each
byte for length of data or field], and a one-byte compare where
every row will match on the first byte includes the cost of doing
all of the I\O while ensuring only one single-byte compare. To
prevent actual row selection, the query should be a SELECT COUNT(*)
summary so neither does any actual row\data retrieval. Finally,
review the percent difference between the two scenarios after
adjustment [for removal of the fixed I\O cost and an effective
minimal scan cost], for which an effective difference should be in
consideration of only the scanning costs.
<<SNIP>>
In my testing I am running each statement multiple times and
looking at the average of the last few runs. Though I haven't
switch the order as I'm running the statement over the fixed
length field first, so I'd expect if order mattered, the first
statement would be the one to suffer, not the second.
Averaging the last few of several runs, for each scenario, is
also a valid [and better than order reversal] approach to minimize
the impacts to the measurements. Switching order is mostly a trick
to expose any impact, and thus cost averaging across order switches
can be considerably more accurate; than if never having exposed the
flaw for only having performed the tests in one order.
<<SNIP>>
On Thu, Jul 22, 2010 at 1:07 PM, CRPence wrote:
Since a blank is not the prefix of the data being searched,
you could not see the maximum potential improvement you are
looking for.
Try searching on '% MAIN%' instead, to effect a better test;
not that I trust the performance test results for both
non-dedicated and without averaged repeated tests including
reversed order of any two compared scenarios.
------------------------------
message: 2
date: Thu, 22 Jul 2010 15:47:27 -0400
from: Alan Shore <AlanShore@xxxxxxxx>
subject: Re: Varying fields and SQL predicate LIKE
Totally agree
it took a while to explain to the users why they were getting such extracts
with %MAIN%
and then when we changed it to '% MAIN %' why they were NOT getting
addresses if N.MAIN ST
Ahh - users - you gotta love them
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
Charles Wilt
<charles.wilt@gma
il.com> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
07/22/2010 03:32 Subject
PM Re: Varying fields and SQL
predicate LIKE
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Alan,
True. But I don't see the extra hit as a problem. I'm simply
throwing the matches to the user so they can figure out which ( if any
) is the actual match.
On the other hand, the fact that '% MAIN%' wouldn't match '123 N.MAIN
ST.' could be a problem.
Charles
On Thu, Jul 22, 2010 at 2:42 PM, Alan Shore <AlanShore@xxxxxxxx> wrote:
Hi Charles
just my two penneth worth as I am also doing something similar
With like of '%MAIN%' you would also get anything like "12 DEMAINVAR
ROAD"
whereas using like of '% MAIN%' , this would NOT be a match
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
? ? ? ? ? ? Charles Wilt
? ? ? ? ? ? <charles.wilt@gma
? ? ? ? ? ? il.com> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?To
? ? ? ? ? ? Sent by: ? ? ? ? ? ? ? ? ?Midrange Systems Technical
? ? ? ? ? ? midrange-l-bounce ? ? ? ? Discussion
? ? ? ? ? ? s@xxxxxxxxxxxx ? ? ? ? ? ?<midrange-l@xxxxxxxxxxxx>
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?cc
? ? ? ? ? ? 07/22/2010 02:27 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Subject
? ? ? ? ? ? PM ? ? ? ? ? ? ? ? ? ? ? ?Re: Varying fields and SQL
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? predicate LIKE
? ? ? ? ? ? Please respond to
? ? ? ? ? ? Midrange Systems
? ? ? ? ? ? ? ? Technical
? ? ? ? ? ? ? ?Discussion
? ? ? ? ? ? <midrange-l@midra
? ? ? ? ? ? ? ? nge.com>
Chuck,
I'm not following this part. ?Why would '% MAIN%' be better than '%MAIN%'
In actually, I tried to be smart....when I built my varying search key
field, I did the following:
replace(translate(addr1
? ? ? ? ? ? ? ? ? ? ? ? ?,' '
? ? ? ? ? ? ? ? ? ? ? ? ?,';:.,!@#$%?&*()-_+={}|??\"<>?/~`')
? ? ? ? ? ? ?,' ','' ) as cmpAdr
So that the original data '123 MAIN ST.' became '123MAINST'
Which lowered the average length of the data from 16 to 13. So I was
really looking for a 48% improvement...
I considered removing numeric characters also, ie. '123 MAIN ST.' -->
'MAINST', but decided that might not work given addresses like '123 SR
4'
In my testing I am running each statement multiple times and looking
at the average of the last few runs. ?Though I haven't switch the
order as I'm running the statement over the fixed length field first,
so I'd expect if order mattered, the first statement would be the one
to suffer, not the second.
I see you point about the allocate(0)...I'll see if that makes a
difference.
Also, the table I built for testing had the fixed length column and
the varying one...I'll try setting up a couple of separate test
tables.
Charles
On Thu, Jul 22, 2010 at 1:07 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
? Since a blank is not the prefix of the data being searched, you
could not see the maximum potential improvement you are looking for.
?Try searching on '% MAIN%' instead, to effect a better test; not
that I trust the performance test results for both non-dedicated and
without averaged repeated tests including reversed order of any two
compared scenarios.
--
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) 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) 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: 3
date: Thu, 22 Jul 2010 14:47:56 -0500
from: Grizzly Malchow <grizzlym@xxxxxxxxxxxxxxxxxxxxx>
subject: RE: Setting up IPDS printer
I'm guessing you need to send the data as ascii to the printer. We do something similar with FedEx Shipping Labels. We use their web services for shipping and they send us back a string of ascii ZPL that is the shipping label. Once we receive the string of ZPL, we save it to a file on the IFS and print it as is to a *USERASCII spool file.
This sounds like it is a little different than your requirements, but I think it is along the same lines.
Grizzly Malchow
IT Manager
Northern Wholesale Supply, Inc
Phone: 651-407-1469
Toll Free: 800-666-1111
Mobile: 651-724-2452
Fax: 651-429-5757
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: Thursday, July 22, 2010 1:32 PM
To: Midrange Systems Technical Discussion
Subject: Re: Setting up IPDS printer
Update...
I was able to locate a pdf that gave me the default authentication to get
into the printer's web server. For archive purposes it is admin/1234 and
you just point your browser at the ip address of your printer.
Once logged in I am seeing the following in the printers job log which tells
me the communication is in fact happening and data is being sent down, but
the printer isn't doing anything with it.
http://screencast.com/t/NWExNTg3Y
I am wondering if there is an issue with EBCDIC to ASCII going on here that
is causing the control characters to be converted in a way that causes the
stream to be thrown away by the printer because it doesn't recognize
anything it can do with the stream.
Are there print settings on the IBMi I can try to see if that addresses the
issue? Also, below is the RPG program I am using to create the printer file
with the code Charles told me about.
FQPRINT O F 264 PRINTER
/free
except bclabel;
*inlr = *on;
/end-free
OQPRINT E bclabel 1
o '^XA'
O E bclabel 1
o '^LH30,30'
O E bclabel 1
o '^FO20,10^AD^FDZEBRA^FS'
O E bclabel 1
o
'^FO20,60^B3^FDAAA001^FS'
O E bclabel 1
o '^XZ'
midrange.com
