|
midrange.com
David -
Change the "Message Split Size" on your POP attributes (CHGPOPA) to
*NOMAX. I believe this will fix your problem.
HTH,
Steve
midrange-l-request@midrange.com on 11/13/2001 12:01:19 PM
Please respond to midrange-l@midrange.com
To: midrange-l@midrange.com
cc:
Subject: MIDRANGE-L digest, Vol 1 #623 - 13 msgs
Send MIDRANGE-L mailing list submissions to
midrange-l@midrange.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@midrange.com
You can reach the person managing the list at
midrange-l-admin@midrange.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MIDRANGE-L digest..."
Today's Topics:
1. Re: SQL (Mike Naughton)
2. SNDDST attachments ( C.123 ) (zlist1@atplas.com)
3. RE: SQL/ordering data based on a computed result/stored procedure?
(rob@dekko.com)
4. RE: Green screen - it's time is over (Joe Pluta)
5. Re: Green screen - it's time is over (Bruce Barrett)
6. Re: OO benefits? (was Re: Fast400 Value to iSeries community is
less than zero ) (jkrueger@andrewscg.com)
7. RE: V5R1 (David.X.Kahn@gsk.com)
8. Re: OO benefits? (was Re: Fast400 Value to iSeries community is less
than zero ) (Leif Svalgaard)
9. WRKSBSJOB (Norbut, Jim)
10. Re: WRKSBSJOB (Peter_Vidal@pall.com)
11. Re: Green screen - it's time is over (Brad Stone)
12. Re: SNDDST attachments ( C.123 ) (Brad Stone)
--__--__--
Message: 1
Date: Tue, 13 Nov 2001 12:03:21 -0500
Subject: Re: SQL
To: midrange-l@midrange.com
From: "Mike Naughton" <mnaughton@juddwire.com>
Reply-To: midrange-l@midrange.com
If you're looking for a SQL courge, I've found Graeme Birchall's "SQL
Cookbook" to be very helpful. It seems to cover all the bases, and it
gives lots of examples, so instead of just describing the syntax of the
commands it shows how to use them. Even better, sometimes it shows what
happens if you use them wrong, and then explains why. He seems to have put
a lot of work into this, and I was impressed.
It's a PDF file you can download from his web site, and the price is right
-- it's free! Just search on "SQL Cookbook" and you should find it.
midrange-l@midrange.com writes:
>OK, what I REALLY need is an SQL course, but can someone help me?
>
>Steven Donnellan
>AS/400 Systems Manager
>IBM Certified Specialist - AS/400 Professional Operator
>Simon Jersey Ltd
Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-863-4357 x444
mnaughton@juddwire.com
--__--__--
Message: 2
To: Midrange-L@midrange.com
Subject: SNDDST attachments ( C.123 )
From: zlist1@atplas.com
Date: Tue, 13 Nov 2001 12:02:51 -0500
Reply-To: midrange-l@midrange.com
Whenever I attached a document using SNDDST the name of the document
shows up on the subject field and the attachment gets the name C.123
What setting(s) are required to have the real name of the document for
the attachment instead of C.123
Thanks in advance
David
--__--__--
Message: 3
Subject: RE: SQL/ordering data based on a computed result/stored procedure?
To: midrange-l@midrange.com
From: rob@dekko.com
Date: Tue, 13 Nov 2001 12:04:49 -0500
Reply-To: midrange-l@midrange.com
No. I truly believe that OPNQRYF or physically storing the value would
work. OPNQRYF would not work because it is not complex enough. Physically
storing the value would not work because of the fact that pricing changes
by time for this application. That is why the
select item, cust, price(item, cust) from thisfile
works. price is a stored procedure with two parameters: item and cust,
and returns one value, the price. Much like using a subprocedure in RPGLE.
And your stored procedure can be written in RPGLE, or whatever. From what
I gathered, trying to cobble OPNQRYF to calculate price would fail. Unless
you processed your OPNQRYF against a SQL view which contained this
price(item,cust).
Rob Berendt
==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"jt" <jt@ee.net>
Sent by: To:
<midrange-l@midrange.com>
midrange-l-admin@mi cc:
drange.com Fax to:
Subject: RE: SQL/ordering
data based on a computed result/stored
procedure?
11/13/2001 11:25 AM
Please respond to
midrange-l
Rob,
This is true also. Or OPNQRYF.
But depending on the extent it /could/ be accessed, there are performance
gains to physically store the value. I think current price would be
something accessed quite frequently, if it was readily available, but ICBW.
Having seen the follow-up posts, I would add: or ILE modules, or UDF, or
/COPY, yada, yada, yada.
I think I can safely and categorically state: "There is more than one way
to skin a cat"...;-) These kinds of implementation decisions all come down
to balancing performance, likelihood business rules will change, and
skill-set, IMV.
jt
> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of rob@dekko.com
> Sent: Tuesday, November 13, 2001 10:16 AM
> To: midrange-l@midrange.com
> Subject: RE: SQL/ordering data based on a computed result/stored
> procedure?
>
>
>
> Whose says you can't store it in the database? Just don't store it
> physically - use a view.
>
> Rob Berendt
>
> ==================
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
>
>
>
> "jt" <jt@ee.net>
> Sent by: To:
> <midrange-l@midrange.com>
> midrange-l-admin@mi cc:
> drange.com Fax to:
> Subject: RE:
> SQL/ordering data based on a computed result/stored
> procedure?
> 11/13/2001 08:57 AM
> Please respond to
> midrange-l
>
>
>
>
>
>
> Reeve,
>
> I may be old-fashioned, but I've held to the idea that if you have a need
> to
> sort on a computed field, you should have that in the DB. I would
suggest
> triggers to implement the business rules, although there is a performance
> hit.
>
> JMHO.
>
> jt
>
> > -----Original Message-----
> > From: midrange-l-admin@midrange.com
> > [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
> > Sent: Tuesday, November 13, 2001 8:12 AM
> > To: Midrange-L@Midrange. Com
> > Subject: SQL/ordering data based on a computed result/stored procedure?
> >
> >
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > I need to display data in ascending order where the key field (price)
is
> > dynamically computed. I can do this with the QLGSORT API's and I
> > can do it
> > with funky RPG; I'm wondering if I can do it with SQL and stored
> > procedures,
> > or something of that ilk.
> >
> > "Price" is a function of the item's base price and the current
> incentives
> > (discounts) in place for that customer/product line combination;
> > the actual
> > incentive is determined from a complex set of business rules.
> > Therefore, a
> > $100 item with a 20% discount (net $80) becomes less expensive
> than a $90
> > item with a 10% discount (net price $81), and I'd like the $80
> > item to show
> > up before the $81 item.
> >
> > So, SQL reads a group of items, applies a function to the item base
> price,
> > gets a "net" price, and presents ordered-by-net-price data into my
> > application program. It seems simple enough?
> >
> > No green-screen, client/server, or CFINT opinions are required!
> >
> > Thanks,
> > rf
> >
> >
> > --
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> > mailing list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > 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@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> 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@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> 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@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--__--__--
Message: 4
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Subject: RE: Green screen - it's time is over
Date: Tue, 13 Nov 2001 11:10:25 -0600
Reply-To: midrange-l@midrange.com
> different category than raw SQL statements passed via SQL.
That is:
different category than raw SQL statements passed via ODBC.
Gotta learn to proofread...
--__--__--
Message: 5
Date: Tue, 13 Nov 2001 09:08:35 -0800
From: "Bruce Barrett" <bbarrett@pmigroup.com>
To: <midrange-l@midrange.com>
Subject: Re: Green screen - it's time is over
Reply-To: midrange-l@midrange.com
>The truth is that the AS/400, now spelled iSeries, is still the best
>business platform available. But its uniqueness no longer resides in that
>wonderful integrated 24x80 window that we grew up with. Instead, it lies
in
>the ability to write powerful applications in languages with tight
>integration to its incredible database. Personally, I think IBM's
direction
>of pushing everything to SQL is ludicrous, but it is silly for me to whine
>about SQL. Instead, I need to embrace it as best I can and work it into a
>realistic development environment.
Joe,
You are the only person in all of the list that seems to have seen the
light. See bolded.
--__--__--
Message: 6
From: jkrueger@andrewscg.com
To: midrange-l@midrange.com
Date: Tue, 13 Nov 2001 11:11:43 -0600
Subject: Re: OO benefits? (was Re: Fast400 Value to iSeries community is
less than zero )
Reply-To: midrange-l@midrange.com
>> Complexity = Sum of distinct steps the pgmr needs to be knowledgeable of
to
perfom a task.
>> So I am suspicious of client/server increasing complexity because their
are
more steps the pgmr needs to know about in a cs tran than a pgm call tran.
>> Client server via dtaq is more complex that the pgm call because the
pgmr
must be knowledgable of 7 steps compared to 4 in the common module pgm call
approach.
Good analysis! But I have to point out, you vastly over simplified the
number
of things the client/server programmer needs to understand, because you
didn't
include the steps for starting the servers and putting them in 'listen'
mode,
you didn't talk about debugging skills, and you didn't talk about the
on-going
maintenance challenges...
Client/Server (and any multi-tiered architecture) *IS* more complicated
than
programming within a single system!
That said, though, there are a number of good points to be made for the
style of
architecture needed to build applications that leverage multiple tiers. I'd
like
to contribute the following observation:
Just because one programming architecture may have strengths over another
doesn't mean that is good to force all business programmers to understand
it and
deal with it on a day to day basis... There are dozens and dozens of
programming
tools available whose sole purpose in life is to shield the business
programmer
from system complexities!!!
IMHO, much of this argument smacks of debates I was hearing thirty years
ago
about why one flavor of assembler language was better than another... It
keeps
making me wonder why we can't raise our arguments up to a more relevant
level!
Janet Krueger
Andrews Consulting Group
--__--__--
Message: 7
From: David.X.Kahn@gsk.com
Subject: RE: V5R1
To: midrange-l@midrange.com
Date: Tue, 13 Nov 2001 17:06:17 +0000
Reply-To: midrange-l@midrange.com
Dan said,
> If you are purchasing a package to run on the new box,
> make sure that the package is compatible with V5R1.
That's correct, and I know it needs to be done. However, I always have a
little trouble getting my head round this. Assuming the package is not
using hacks, which most of them don't nowadays if they can run at security
levels 40 and 50, there ought to be nothing in a new release that will
break it (other than relying on some dropped feature such as OV). And if
they are using hacks we're back into the territory of Ed Fishel's warnings
about what IBM are happy to support us on...
Dave...
--__--__--
Message: 8
From: "Leif Svalgaard" <leif@leif.org>
To: <midrange-l@midrange.com>
Subject: Re: OO benefits? (was Re: Fast400 Value to iSeries community is
less than zero )
Date: Tue, 13 Nov 2001 11:19:50 -0600
Reply-To: midrange-l@midrange.com
From: <jkrueger@andrewscg.com>
> IMHO, much of this argument smacks of debates I was hearing thirty years
ago
> about why one flavor of assembler language was better than another... It
keeps
> making me wonder why we can't raise our arguments up to a more relevant
level!
just human nature, Janet...
--__--__--
Message: 9
From: "Norbut, Jim" <Jim.Norbut@Grubb-Ellis.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: WRKSBSJOB
Date: Tue, 13 Nov 2001 11:38:24 -0600
Reply-To: midrange-l@midrange.com
Okay=85.I am probably going so feel really silly for asking this one.
How can I see all the active/waiting jobs in QBATCH ?
If I do a WRKSBSJOB SBS(QBATCH) USER(*ALL)
It only shows me the active entries=85.and since we only allow 4 jobs to ru
=
n
at a time=85that=92s all I see.
Jim Norbut
Systems Administrator
Grubb & Ellis Company
Phone =09(847) 753-7620
Fax=09(847) 753-9854
--__--__--
Message: 10
Subject: Re: WRKSBSJOB
To: midrange-l@midrange.com
From: Peter_Vidal@pall.com
Date: Tue, 13 Nov 2001 12:38:03 -0500
Reply-To: midrange-l@midrange.com
WRKJOBQ
"Norbut, Jim"
<Jim.Norbut@Grubb-E To:
"'midrange-l@midrange.com'"
llis.com> <midrange-l@midrange.com>
Sent by: cc:
midrange-l-admin@mi Subject: WRKSBSJOB
drange.com
11/13/01 12:38 PM
Please respond to
midrange-l
Okay?.I am probably going so feel really silly for asking this one.
How can I see all the active/waiting jobs in QBATCH ?
If I do a WRKSBSJOB SBS(QBATCH) USER(*ALL)
It only shows me the active entries?.and since we only allow 4 jobs to run
at a time?that's all I see.
Jim Norbut
Systems Administrator
Grubb & Ellis Company
Phone (847) 753-7620
Fax (847) 753-9854
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--__--__--
Message: 11
From: "Brad Stone" <brad@bvstools.com>
Subject: Re: Green screen - it's time is over
To: midrange-l@midrange.com
Date: Tue, 13 Nov 2001 12:55:03 -0500
Reply-To: midrange-l@midrange.com
On Tue, 13 Nov 2001 10:51:03 -0600
"Joe Pluta" <joepluta@PlutaBrothers.com> wrote:
> On the other hand, I think there IS a market for a purely
> TCP/IP-based
> protocol, either HTML or some other variant, that can
> emulate the clean
> interface of the 5250. Most graphical applications are
> not nearly as
> friendly to data-entry-intensive applications as our
> beloved green screen.
HTML being the worst case scenario. Its not even close to
being as "clean" as 5250 green screens. It's also a lot
slower.
Brad
www.bvstools.com
--__--__--
Message: 12
From: "Brad Stone" <brad@bvstools.com>
Subject: Re: SNDDST attachments ( C.123 )
To: midrange-l@midrange.com
Date: Tue, 13 Nov 2001 12:56:58 -0500
Reply-To: midrange-l@midrange.com
David,
A better solution than SNDDST would be to use the send email
API or a product similar. I have one if you intersted at:
http://www.bvstools.com/mailtool.html
It allows you to do a lot more than SNDDST, including up to
30 email recipiants, multiple attachments (that can be the
body text, for example an HTML file) and allowing you to set
the subject, message text and from email address.
Brad
www.bvstools.com
On Tue, 13 Nov 2001 12:02:51 -0500
zlist1@atplas.com wrote:
> Whenever I attached a document using SNDDST the name of
> the document
> shows up on the subject field and the attachment gets the
> name C.123
>
> What setting(s) are required to have the real name of the
> document for
> the attachment instead of C.123
>
> Thanks in advance
>
> David
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
>
Bradley V. Stone
BVS.Tools
www.bvstools.com
--__--__--
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
End of MIDRANGE-L Digest
As an Amazon Associate we earn from qualifying purchases.
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.
