I've been "listening" to the comments on "cheaper" servers .... can anyone
articulate a business case for
1) customers
2) BPs, consultants, trainers
3) etc.

Not that I'm promising anything ... just like to see what ya'll come up
with .....   Thanks!

Hope to see you in Nashville at COMMON!!

************
Have a great day! and .... Enthusiasm is like a ripple in the water... It
spreads!
Anne C. Lucas, Project Exec, iSeries Nation and iSeries Marketing -
www.ibm.com/eserver/nation1
205/823-4831  T/L 537-9968,  eFax:  603-687-8053,  800/223-3907 Pager
Admin Assist:   Alice Sebastiano Telephone:  (914) 642-4109, tie line
224-4109 Fax:  (914) 642-6976, tie line 224-6976




                      midrange-l-request@m
                      idrange.com                 To:       
midrange-l@midrange.com
                      Sent by:                    cc:
                      midrange-l-admin@mid        Subject:  MIDRANGE-L digest, 
Vol 1 #1737 - 10 msgs
                      range.com


                      04/11/2002 02:33 PM
                      Please respond to
                      midrange-l





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: ODBC FROM iSeries - huh? (Walden H. Leverich)
   2. RE: Retrieve SQLCODE descriptions programmatically? (Walden H.
Leverich)
   3. RE: Cheaper Servers? (DeLong, Eric)
   4. RE: ODBC FROM iSeries - huh? (Joe Pluta)
   5. RE: ODBC FROM iSeries - huh? (Walden H. Leverich)
   6. RE: Retrieve SQLCODE descriptions programmatically? (Vernon Hamberg)
   7. RE: Cheaper Servers? (James Rich)
   8. Re: Cheaper Servers? (Leif Svalgaard)
   9. Re: CAE - Mapping Network Drives (Chuck Morehead)
  10. RE: Cheaper Servers? - Been there - done that (Boling, David E.)

--__--__--

Message: 1
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: ODBC FROM iSeries - huh?
Date: Thu, 11 Apr 2002 14:21:29 -0400
Reply-To: midrange-l@midrange.com

>From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
>That raises a different question - is there a "generic" ODBC driver
>that simply converts ODBC calls to ANSI SQL CLI?  If so, and if this
>driver were ported to the iSeries, wouldn't it magically provide ODBC
>access to any DBMS with a true SQL engine?

Actually I'm afraid it doesn't work that way. For the rest of this I'm
ignoring single-level drivers like Access, I'm only referring to "real"
databases like SQLServer or Oracle or Informix or ...

It would seem that the smart thing for database vendors to do would have
been for them to write server-side translators from the CLI interfaces to
their individual databases. Then all someone would need was a client-side
driver that translated from ODBC to CLI. However, as it happens each vendor
write a client-side translator from ODBC to their proprietary network
interface.

That is to say SQL Server doesn't listen for CLI calls, it listens for
SQL-Server calls. It's the ODBC drivers job to translate from ODBC to
SQL-Server.

Also, as someone pointed out ODBC refers to Microsoft's implementation of
X/Open.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)



-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Wednesday, April 10, 2002 00:19
To: midrange-l@midrange.com
Subject: RE: ODBC FROM iSeries - huh?


> From: John Taylor
>
> Yup. Practically speaking though, it's rarely an issue because ODBC
> drivers are client side middlewhere, and client OS' such as Win/32 and
> *nix are well
> represented by the DBMS providers. Those who wish to use OS/400
> as a client
> to an MS-Access database are SOL, but how big can that demand really be?

Well, one of the side arguments came when Walden (absolutely correctly)
called me on my blanket statement that the iSeries can communicate to other
databases via ODBC.  It seems that I was just plain wrong on that point,
especially if you're talking about native ODBC drivers on the iSeries.  My
bad, and Walden took me to task for it.


> Yes on the point that ODBC is not well supported (if at all) on
> OS/400. But you don't necessarily need an ODBC driver to access a
> different  database. ODBC is simply an API... an implementation of the
> ANSI/ISO SQL Call Level Interface. In theory (I haven't tried) one
> should be able to access any DB server that implements the SQL CLI
> using OS/400 as a client.

Ah, now this is interesting.  I am definitely a neophyte here.  While I
understand the basic concept of the CLI, I'm not very familiar with the
implementation.  Does the SQLRPG precompiler generate calls to the CLI, or
is there another layer underneath that?  In any event, it shouldn't be too
hard to find a reference for SQL CLI, find a freeware PC DBMS that supports
CLI, and see if the iSeries can access it.


> Therefore, you can't use CLI on OS/400 to talk to
> an MS-Access database, because there's nothing on the other end to
> hear you.

Okay, this made light bulbs go off.  I can understand this completely.  A
DBMS includes an SQL engine, which should by default respond to CLI
requests.  This in turn provides ODBC support, because ODBC is just a
wrapper around CLI.  But in the case of desktop databases, the entire SQL
implementation is housed inside the ODBC driver.  If there were an actual
SQL engine around the smaller databases, they too would in theory respond
to
SQL CLI calls.

This begins to make more sense to me.

And I'll bet that the true commercial databases such as Oracle, Informix,
Sybase, et al, all have actual SQL engines and hence should communicate via
ANSI CLI.

Wow.  Wow.  This is very cool.

That raises a different question - is there a "generic" ODBC driver that
simply converts ODBC calls to ANSI SQL CLI?  If so, and if this driver were
ported to the iSeries, wouldn't it magically provide ODBC access to any
DBMS
with a true SQL engine?

Just wondering.

Joe


--__--__--

Message: 2
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: Retrieve SQLCODE descriptions programmatically?
Date: Thu, 11 Apr 2002 14:32:34 -0400
Reply-To: midrange-l@midrange.com

SQLCODE translates to message id's as follows:

Take absolute value of SQLCODE
Represent that as a 5 digit number
If the leading digit is zero change it to an 'L'
Prepend 'SQ' and you have the message ID.

Ex.
SQLCODE -501
Abs(-501) = 501
Make that 00501
Since leading digit is 0 make it an 'L'
Prepend SQ and the message id is SQL0501

SQLCODE -20054
Abs(-20054) = 20054
Prepend SQ and the message id is SQ20054

However, if memory serves data in SQLERRM is delimited with x'FF' not fixed
length and RTVMSG needs fixed length so you need some way of knowing how
long the message data should be.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)



-----Original Message-----
From: Vernon Hamberg [mailto:vhamberg@attbi.com]
Sent: Thursday, April 11, 2002 11:26
To: midrange-l@midrange.com
Subject: Re: Retrieve SQLCODE descriptions programmatically?


Are you basically talking RTVMSG? Negative SQLCOD translate to message
description IDs, with a little work, right?

Don't have one here. Nice idea.

At 09:28 AM 4/11/02 -0500, you wrote:
>Does anyone have a piece of code they would be willing to share?
>
>Ideally, I'm looking for a subprocedure (called from RPG/IV) that will
>accept a SQLCODE and SQLERRM, and return the explanation text from the
>SQL message file QSYS/QSQLMSG. Substitution variables would be replaced
>with values in SQLERRM.
>
>If not, I will probably write one. I find myself doing a lot of
>embedded SQL for CGI programs (works well), and I currently get the SQL
>code and state values for the prepare (if used), open, and first fetch
>of an SQL statement. I output these to HTML comments in the web page
>for tracking/debugging. I also want the SQL message (if an error) to
>show also. This would also be useful in traditional RPG/IV programs
>using embedded SQL.
>
>Sample usage...
>if sqlcod <> 0 or sqlstt <> '00000'
>eval sqlmessage = GetSQLMsg( sqlcod : sqlerrm )
>endif
>
>Thanks,
>Loyd
>
>--
>Loyd Goodbar
>Programmer/Analyst
>BorgWarner Incorporated
>Air/Fluid Systems, Water Valley, MS
>
>
>

--__--__--

Message: 3
From: "DeLong, Eric" <EDeLong@Sallybeauty.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: Cheaper Servers?
Date: Thu, 11 Apr 2002 13:35:46 -0500
Reply-To: midrange-l@midrange.com

James,

You keep hitting on this point, but I don't see why this is the
deal-breaker
you imagine it to be.  Correct me if I'm wrong, but Linux itself does not
directly support a graphical interface.  It uses a shell to implement the
graphical environment.  As IBM continues to migrate OOPS Navigator into
Java, IBM could offer the laptop with two partitions, OS400 and Linux, with
the Linux partition customized to use the laptop display and keyboard, just
like you have on your desktop.  Linux partition uses TN5250 to access the
OS400 partition.  IMO, this is an even better example of the flexibility
and
stability of iSeries architecture.

We've heard from Dr. Frank that MS could potentially migrate windows to run
as a partition under OS400.  Same solution as above, laptop hardware maps
to
the client partition, which can then access OS400 partitions through TN5250
or HTML interfaces....

I would imagine there are any number of ways to develop this product, but I
doubt we'll see it.....

Eric DeLong
Sally Beauty Company
MIS-Sr. Programmer/Analyst
940-898-7863 or ext. 1863



-----Original Message-----
From: James Rich [mailto:james@eaerich.com]
Sent: Thursday, April 11, 2002 12:33 PM
To: midrange-l@midrange.com
Subject: RE: Cheaper Servers?


On Thu, 11 Apr 2002 rob@dekko.com wrote:

> In your statement about the 400 not having a bit mapped display, were you
> referring to all, or just some of the many clients that the 400 supports:
> PC's, net stations, dumb terminals, etc...

I was referring to none of the clients.

The iSeries does not have a bit mapped display.  When was the last time
you plugged your SVGA monitor into the back of your iSeries?  OS/400 has
no concept of graphics.  Sure some clients do, but are those clients
running OS/400?  Of course not.  The statement (quoted below) said that
linux office applications could be ported to OS/400.  That is not true
because those applications rely on libraries which in turn rely on an
operating system that understands bitmapped displays.

You could possibly port X11 to OS/400 without requiring OS/400 to
understand bitmapped displays.  That would require you to run an X server
on some other operating system somewhere so you could display the X apps
running on the iSeries.  But this would not strictly qualify as using
OS/400 to replace microsoft windows as was the original intent of the
thread.  It doesn't qualify because with windows and unix you don't need
another machine to provide the framework for applications to run (in this
case the actual displaying of the app), whereas with remote X display you
do.  And since you still require another non-OS/400 machine to display
your program, why waste time with the stupid port in the first place?
Just run the app on the platform it was written for.

However I can see that there could be reasons for wanting to make your
iSeries be an X client.  If it was possible to port X11 to OS/400 that
might be interesting and useful.  You could for example write an RPG
program with gtk display possibilities, or maybe a Motif maintainance
program.  The key question to resolve is:  can X11 be ported to an
operating system that has no concept of bitmapped displays?  The answer to
that is:  no, it cannot - at least not entirely.  But enough of X11 might
be portable to make it useful.

> On Wed, 10 Apr 2002, Shields, Ken wrote:
>
> >          Issue 2. Linux has a very brisk suite of office tools, all of
> > which I'm sure could be incorporated into an OS/400 pc operating
system.
>
> No they couldn't.  Those office tools require bitmapped displays which
> OS/400 does not support.  I am unaware of single office application on
> windows or linux that does not require a bitmapped display, whether GUI
or
> command line.  Unless you consider sed to be an office application.

James Rich
james@eaerich.com

_______________________________________________
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: ODBC FROM iSeries - huh?
Date: Thu, 11 Apr 2002 13:46:10 -0500
Reply-To: midrange-l@midrange.com

> From: Walden H. Leverich
>
> That is to say SQL Server doesn't listen for CLI calls, it listens for
> SQL-Server calls. It's the ODBC drivers job to translate from ODBC to
> SQL-Server.

So you've got client-side programs (the ODBC drivers) translating from a
generic protocol to a vendor-specific protocol.  Boo hiss.  That's a REALLY
shortsighted approach.

Joe


--__--__--

Message: 5
From: "Walden H. Leverich" <WaldenL@TechSoftInc.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: ODBC FROM iSeries - huh?
Date: Thu, 11 Apr 2002 14:49:06 -0400
Reply-To: midrange-l@midrange.com

>From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
>...translating from a generic protocol to a vendor-specific protocol.

Precisely. I believe that's the same way it works with JDBC drivers. The
only difference is that pure-java drivers are in theory portable from
platform to platform.

-Walden

------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@TechSoftInc.com
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


--__--__--

Message: 6
Date: Thu, 11 Apr 2002 14:00:28 -0500
To: midrange-l@midrange.com
From: Vernon Hamberg <vhamberg@attbi.com>
Subject: RE: Retrieve SQLCODE descriptions programmatically?
Reply-To: midrange-l@midrange.com

I suppose the old standby - DSPMSGD OUPUT(*PRINT), then CPYSPLF, then
massage that for the data fields.

At 02:32 PM 4/11/02 -0400, you wrote:
>SQLCODE translates to message id's as follows:
>
>Take absolute value of SQLCODE
>Represent that as a 5 digit number
>If the leading digit is zero change it to an 'L'
>Prepend 'SQ' and you have the message ID.
>
>Ex.
>SQLCODE -501
>Abs(-501) = 501
>Make that 00501
>Since leading digit is 0 make it an 'L'
>Prepend SQ and the message id is SQL0501
>
>SQLCODE -20054
>Abs(-20054) = 20054
>Prepend SQ and the message id is SQ20054
>
>However, if memory serves data in SQLERRM is delimited with x'FF' not
fixed
>length and RTVMSG needs fixed length so you need some way of knowing how
>long the message data should be.
>
>-Walden
>
>------------
>Walden H Leverich III
>President
>Tech Software
>(516) 627-3800 x11
>(208) 692-3308 eFax
>WaldenL@TechSoftInc.com
>http://www.TechSoftInc.com
>
>Quiquid latine dictum sit altum viditur.
>(Whatever is said in Latin seems profound.)
>
>
>
>-----Original Message-----
>From: Vernon Hamberg [mailto:vhamberg@attbi.com]
>Sent: Thursday, April 11, 2002 11:26
>To: midrange-l@midrange.com
>Subject: Re: Retrieve SQLCODE descriptions programmatically?
>
>
>Are you basically talking RTVMSG? Negative SQLCOD translate to message
>description IDs, with a little work, right?
>
>Don't have one here. Nice idea.
>
>At 09:28 AM 4/11/02 -0500, you wrote:
> >Does anyone have a piece of code they would be willing to share?
> >
> >Ideally, I'm looking for a subprocedure (called from RPG/IV) that will
> >accept a SQLCODE and SQLERRM, and return the explanation text from the
> >SQL message file QSYS/QSQLMSG. Substitution variables would be replaced
> >with values in SQLERRM.
> >
> >If not, I will probably write one. I find myself doing a lot of
> >embedded SQL for CGI programs (works well), and I currently get the SQL
> >code and state values for the prepare (if used), open, and first fetch
> >of an SQL statement. I output these to HTML comments in the web page
> >for tracking/debugging. I also want the SQL message (if an error) to
> >show also. This would also be useful in traditional RPG/IV programs
> >using embedded SQL.
> >
> >Sample usage...
> >if sqlcod <> 0 or sqlstt <> '00000'
> >eval sqlmessage = GetSQLMsg( sqlcod : sqlerrm )
> >endif
> >
> >Thanks,
> >Loyd
> >
> >--
> >Loyd Goodbar
> >Programmer/Analyst
> >BorgWarner Incorporated
> >Air/Fluid Systems, Water Valley, MS
> >
> >

Message: 7
Date: Thu, 11 Apr 2002 13:03:58 -0600 (MDT)
From: James Rich <james@eaerich.com>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: Cheaper Servers?
Reply-To: midrange-l@midrange.com

On Thu, 11 Apr 2002, DeLong, Eric wrote:

> James,
>
> You keep hitting on this point, but I don't see why this is the
deal-breaker
> you imagine it to be.  Correct me if I'm wrong, but Linux itself does not
> directly support a graphical interface.  It uses a shell to implement the
> graphical environment.  As IBM continues to migrate OOPS Navigator into

The confusion here is using the words "graphical interface" where it
should be "graphical device".  Linux does directly support a graphical
device.  X11 directly supports a graphical device in concert with the
operating system.  OpenGL and Mesa directly support a graphical device in
concert with the operating system.  The linux framebuffer directly
supports a graphical device.

In order for X11 to switch the linux console from text only (or simple
framebuffer) to graphic display X must make a system to call to the linux
kernel to switch the hardware.  PC graphics cards work in two modes: text
only and graphic.  The kernel must make this switch and understand both
states.  X11 includes drivers for each make and model of graphics device,
but the kernel is what actually sends data to the graphics device.

OS/400 has no such ability.  There is no need for it:  you can't put a
graphics device in an iSeries anyway.

> Java, IBM could offer the laptop with two partitions, OS400 and Linux,
with
> the Linux partition customized to use the laptop display and keyboard,
just
> like you have on your desktop.  Linux partition uses TN5250 to access the
> OS400 partition.  IMO, this is an even better example of the flexibility
and
> stability of iSeries architecture.

It is true that this could be done.  But then it would be linux that is
running your display, keyboard, and mouse - not OS/400.  It was suggested
to port applications from linux to OS/400.  Doing so would require that
you have linux installed to use those applications (since you would need
something to run the screen, mouse, and keyboard).  Why do the port from
linux to OS/400 if you have to have linux installed to use them?

If you want to put OS/400 or any operating on some architecture it only
makes sense to do so if the operating system can use the hardware on that
architecture.  Running linux in an LPAR in *not* using OS/400 to run the
hardware.

Even if support was added to OS/400 for PC hardware (specifically video
cards, keyboards, and mouse) it is still ridiculous to think that OS/400
on portable hardware would topple Microsoft's monopoly.

James Rich
james@eaerich.com


--__--__--

Message: 8
From: "Leif Svalgaard" <leif@attglobal.net>
To: <midrange-l@midrange.com>
Subject: Re: Cheaper Servers?
Date: Thu, 11 Apr 2002 14:15:04 -0500
Reply-To: midrange-l@midrange.com

From: James Rich <james@eaerich.com>
> Even if support was added to OS/400 for PC hardware (specifically video
> cards, keyboards, and mouse) it is still ridiculous to think that OS/400
> on portable hardware would topple Microsoft's monopoly.

agreed, of course, but I didn't think that that was what most of
us had in mind. We would be happy with just having a laptop
OS/400.


--__--__--

Message: 9
Date: Thu, 11 Apr 2002 14:26:49 -0500
From: Chuck Morehead <cbmorehead@nokuse.com>
Subject: Re: CAE - Mapping Network Drives
To: midrange-l@midrange.com
Reply-To: midrange-l@midrange.com

What happens if you go to Start, Run, and then enter
\\your_AS400_IP_Address?  Does it bring up the AS/400 shares that are
configured under Netserver?  If not, the problem is probably either
Netserver isn't configured right or isn't running.

Chuck

----- Original Message -----
From: "Dave Snyder" <dsnyder@blcnet.com>
To: <midrange-l@midrange.com>
Sent: Thursday, April 11, 2002 1:15 PM
Subject: CAE - Mapping Network Drives


I recently converted my p/c from Client Access to Client Access Express and
am having trouble seeing the AS400 through windows. I have researched and
tried and looked up about as much as I can figure out to try, and just
can't
seem to get to the AS400 via Windows 98. I can ping the netserver on the
AS400 from my p/c, but can not find it using the FIND utility in Windows
nor
can I see it via Windows Explorer/Network Neighborhood. As far as I can
tell
I have the domain correct in the netserver, but still no go. Any more tips
for me to try?
Dave

_______________________________________________
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: 10
From: "Boling, David E." <bolingde@co.rowan.nc.us>
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
Subject: RE: Cheaper Servers? - Been there - done that
Date: Thu, 11 Apr 2002 15:32:39 -0400
Reply-To: midrange-l@midrange.com



-----Original Message-----
From: Vernon Hamberg [mailto:vhamberg@attbi.com]
Now, y'all can tell me why this did not fly the last time IBM tried this. I
don't know, personally.
--------------------------------

IMHO, I think part of the reason it didn't fly is the same reason IBM
almost
lost their share of the PC market at one time, they were afraid it would
take sales from larger system sales.  With the power of computers today,
it's has to be hard to make a system like the iSeries, that has the
resources to run a full scale application for demo purposes without someone
using it to run their business.

As an end user, I know that originally, IBM only wanted to sale the
"luggables" to business partners for just that reason.  In the end, they
were forced to sale it to end users anyway, after putting some restrictions
into the box.  This was before CINIT, but even then customers didn't like
to
hear, "You can't buy one" or "Only one user can logon".

Let's face it IBM has a time positioning the iSeries today after it has
made
billions, year after year for the organization.   How can it be expected
they would understand the concept of an laptop iseries.

IBM isn't in business "not to make money" or "to give stuff away free", but
sometimes they are very wrong on how to make money also.

My 2 cents (discounted to "nothing") and worth what was paid.

David Boling


--__--__--



End of MIDRANGE-L Digest





As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.