RE: MySQL on System i -- MIDRANGE-L

RPG and COBOL are business languages. PHP and Java are not. Or are you

putting PHP in a class with RPG?

Nope - I agree that it is tough to consider any language as the foundation
for business when it can't do decimal math.

Where I would classify PHP as similar to Java is in easy of learning for
someone not steeped in OO.

But really, I have no issue with PHP as an ADJUNCT to business

programming. But it is not a replacement for RPG!

100% agreed. I think the primary difference between us is that you can get
your head around Java and my brain still rebels at it. I have simply found
PHP a better "fit" for my ancient brain. Not only the language - but I also
don't need the extra complexity of WAS/Tomcat/whatever.

... you might want to look at Python.

I have - but we're back to OO and ancient brains again <grin> - and it is
not an IBM supported port and not likely to be.

You generate the client from the WSDL, and all of the plumbing is done

for you.

Haven't you cheated a bit there? No includes? And "generate"? - the PHP
code I showed is the whole thing - nothing up my sleeve!

I have not heard anybody suggest - and certainly I will never do so - that
PHP replace RPG. I have simply said that I believe PHP to be easier to
learn than Java for the average RPG programmer and therefore may be a better
fit for those tasks for which Java has been being promoted. The only folks
that I have heard suggesting anything as a replacement for RPG are the EGL
crew!

Jon Paris
Partner400

www.Partner400.com

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
midrange-l-request@xxxxxxxxxxxx
Sent: Wednesday, May 09, 2007 2:49 PM
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 6, Issue 956

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. iSeries NIC Utilization (Mike Cunningham)
2. RE: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...
(Jon Paris)
3. RE: Putting a display file into production.
(jmichael.smith@xxxxxxxxxxx)
4. RE: MySQL on System i (Joe Pluta)
5. RE: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...
(Roger Harman)
6. RE: First Annual COMMON conference - Spring 2007 (Chuck Lewis)
7. Re: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...
(Steve Richter)
8. Re: Why can't we eat our own cooking? (Booth Martin)

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

message: 1
date: Wed, 9 May 2007 14:22:17 -0400
from: "Mike Cunningham" <mcunning@xxxxxxx>
subject: iSeries NIC Utilization

Our iSeries has 3 NICs. Using our external and internal DNS
tables we route all off campus traffic to one NIC, and all on
campus traffic to a second. The third is there as a backup in
case either of the others fail and we can switch over to this
third NIC manually. All three are online, included the spare.
I would like to be able to see how much traffic is coming in
on the two active NICs and also see which of the three NICs
traffic is going out on. Management Central monitor can
start a LAN utilization monitor but it does not let me pick
which NIC to watch so I can only assume it's watching all
traffic. I think I could add an external SNMP monitor to
check that way but wanted to be able to check internally to
the iSeries and possible log use to a database.

Thanks

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

message: 2
date: Wed, 9 May 2007 14:23:02 -0400
from: "Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>
subject: RE: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...

I agree that COBOL has some restrictions on naming etc but this

>> no support for passing parms to sub routines within a
Cobol program.

Isn't one of them. There isn't any such support for RPG
either - we use subprocedures. The equivalent in COBOL is
nested programs, and they take parameters just as RPG
subprocedures do.

Although COBOL limits the exporting of names (for reasons I don't
understand) it is actually more powerful in terms of
public/global data etc.
than RPG. Within the context of one program - nested
programs can incorporate other nested programs (i.e.
procedures having local procedures) and can either share data
with them or not at their discretion.

Another nice aspect of COBOL that hopefully we'll see in RPG
shortly is the ability to share files between programs
(EXTERNAL files).

Jon Paris
Partner400

www.Partner400.com

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

message: 3
date: Wed, 9 May 2007 13:23:15 -0500
from: jmichael.smith@xxxxxxxxxxx
subject: RE: Putting a display file into production.

Using a "normal" library will work as well.

Library list would look like:
1> QTEMPUSER - Where every user has a unique library
2> PRODOBJLIB

At application startup:
DLTF QTEMPUSER/DSPFILE
CRTDUPOBJ to QTEMPUSER

As a personal standard(for me) QTEMP is always 1st in the
library list.
Newer object versions are created in other libraries, these are then
tested by: ADDLIBLE LIB(X) POSITION(*BEFORE QTEMP).

Michael

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Wednesday, May 09, 2007 11:34 AM
To: Midrange Systems Technical Discussion
Subject: RE: Putting a display file into production.

Michael
NICE idea (and even better, really simple), I'm jealous I
didn't think of
this myself..
Unfortunately, the standard we have at our site is that QTEMP
is at the
bottom of our library list.
I went through a REALLY lengthy e-mail thread just recently
on the pro's &
cons of placing QTEMP at the top, bottom or somewhere in
between, of the
library list.

Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 05/09/2007 12:20:39 PM:

Assuming that QTEMP is ahead of your production library in your
library list, consider creating a duplicate object in QTEMP

when ever

the applications does a "start up".

Then you can promote as often as you like.

Michael

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Tuesday, May 08, 2007 8:37 AM
To: Midrange Systems Technical Discussion
Subject: Re: Putting a display file into production.

Morning Bob
We just did the same thing with our order entry This is how

we did it

The WORKSTN in you program make user open (USROPN) Create a

new field

(stand-alone or whatever) that will contain the id of the

DDS In our

instance

D Wrkstnid s 20A inz('DDSNAMEA')

We have 3 Work stations
DDSNAME
DDSNAMEA
DDSNAMEB
In all instances we make changes to DDSNAME.
Then whichever is the value of Wrkstnid (in this instance

DDSNAMEA)

we copy DDSNAME to the other one (in this instance DDSNAMEB is the
opposite of
DDSNAMEA) and we change WRKSTNID to DDSNAMEB

Then within the C-specs we have the following command

C eval Clpstatement = 'OVRDSPF

FILE(ORD122) -

C TOFILE(*LIBL/' +
C %trim(Wrkstnid) +
C ')'
C eval Errorflag = As400cmd(Clpstatement)
C open ORD122

and obviously a

C if %open(Ord122)
C close Ord122
C endif
C MOVEL '1' *INLR
C RETURN

and within the D-specs

// Execute Command (system) Subprocedure Variables
D As400cmd PR 10I 0 ExtProc('system')
D CmdText * Value Options(*String)
D
D ErrorCPF S 7A Import('_EXCP_MSGID')
D ErrorFlag S 10I 0 Inz(0)

This may seem convoluted, and I've tried to explain it to

other people

here, but I know it works.
Whenever we need to make a change to the DDS, we promote everything
(NOT DDSNAMEB in this instance) to PRODUCTION, then inform

the users

that they need to sign-off and sign back on again at their earliest
convenience to start using the new version.

If you have any further questions
of if you think I've left something out, please feel free to ask

Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx
"If you're going through Hell, keep going" - Winston Churchill

Bob.Voltz@colaik.

com

Sent by:

To

midrange-l-bounce Midrange Systems Technical

s+alanshore=nbty. Discussion

com@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>

cc

05/08/2007 09:01

Subject

AM Putting a display file into

production.

Please respond to

Midrange Systems

Technical

Discussion

<midrange-l@midra

nge.com>

Is there a way to put a display file into production when users are
using the program and have a lock on it?

The information transmitted is intended only for the person

or entity

to which it is addressed and may contain confidential, proprietary,
and/or privileged material. Any review, retransmission,

dissemination

or other use of, or taking of any action in reliance upon this
information by persons or entities other than the intended

recipient

is prohibited. If you received this in error, please contact the
sender and delete the material.

--
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 message contains information from Certegy, Inc which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of
this information and note that such actions are prohibited. If you
have received this transmission in error, please notify by e:mail
postmaster@xxxxxxxxxxxx

==============================================================
============
====

--
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 message contains information from Certegy, Inc which may
be confidential and privileged. If you are not an intended
recipient, please refrain from any disclosure, copying,
distribution or use of this information and note that such
actions are prohibited. If you have received this
transmission in error, please notify by e:mail postmaster@xxxxxxxxxxxx
==============================================================
================

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

message: 4
date: Wed, 9 May 2007 13:33:23 -0500
from: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
subject: RE: MySQL on System i

From: Jon Paris

I use SugarCRM and I love it ... There isn't a business

feature in

SugarCRM that an RPG programmer couldn't write with one

keyboard tied

behind
their back.

But surely the point is Joe that they _didn't_ or at least

they didn't and

place it in the public domain and offer maintenance service. i5
applications of that type cost big $ "mid-level" or not.

Same applies for

Help desk software, BBS, wikis, etc. None of them mission

critical for

most people, but for sure "nice to have's" and the few i5

apps in this

arena are not cheap.

Jon, I think you miss my point. I agree that these sorts of
things are
great applications! They're just not enterprise business
applications of
the same type as ERP or banking or indeed any of the sorts of
things that
RPG excels at. I also am not certain of the utility of
running on the i5:
is it a platform-altering event or a yeah, so what? I suspect it's
somewhere in the middle.

The level of integration with your business systems is what
would determine
whether those applications need to run on the i5. If cost
is your primary
concern, it's a lot cheaper to run LAMP stuff on a Lintel
machine than it is
on the i5. On the other hand, if tight integration and centralized
management trump cost, then you might look at running on the
i5. However,
if cost is NOT the object, then an i5 solution becomes an
option again.

By the way - you introduced the notion into the discussion that
applications
had to be "mid-level" or above before they had utility.

I'm just happy to

see the base of modern applications on the box extended.

No, no, no! I'm not saying anything of the sort! I agree
that the sort of
applications that you're talking about--simple, flexible data
entry and
retrieval applications with minimal business logic--are
certainly useful,
but that they shouldn't be confused with back end business
logic that has
been the bailiwick of the midrange.

I worry about the "shiny new tool" syndrome. There are lots
of things PHP
does not do well, or at least hasn't been shown to do so in
any but isolated
circumstances, and large scale deployment of enterprise business
applications is one of those things. For example, people
point to Yahoo as
a reason to use PHP for business, but I doubt that anybody on
this list has
the sort of resources that Yahoo has to devote to the project
management and
infrastructure of the Yahoo application.

As to the language issues, I'm not going to get into the

semantics of that

- we already know we won't agree so there's little point.

I think the decisions between Java and PHP for user interface
and/or web
extensions is one of temperament rather than capability. PHP
is certainly a
completely capable language. I prefer Java for reasons I've
stated, but PHP
is fine -- for the interface side of the project.

It does however
seem to me that Zend and others have taken giant strides in

making PHP a

more robust business-oriented language and that they are

continuing to do

so.

See, that's where I'm not going. PHP is not a business
language, just like
Java isn't a business language. In my opinion, if a language
doesn't have a
native decimal number, it's disqualified out of the box.

RPG and COBOL are business languages. PHP and Java are not.
Or are you
putting PHP in a class with RPG?

For those i5 users unwilling or unable to dive into the

J2EE/Java/JSP/App

Server world, PHP offers easy access to a world of modern

features such as

web services. For example:

<?php
$QuoteClient = new

SoapClient("http://services.xmethods.net/soap/urn:xmethods-delayed-
quotes.ws
dl");

$IBM_Price = $QuoteClient->getQuote("ibm");
print("Current IBM stock price is \$$IBM_Price");

?>

Well, yeah, it does that sort of stuff! That's the age-old
argument about
standard libraries. By the way, you might want to check out the JAXP
capabilities of Java; they're more robust although not quite
as simplistic.
But really, I have no issue with PHP as an ADJUNCT to
business programming.
But it is not a replacement for RPG!

By the way, if you REALLY want a powerful scripting language,
you might want
to look at Python. Hans Boldt and I don't see eye to eye on a lot of
things, but one place where we do agree is on the pretty
incredible power of
Python. And it's available for the i.

http://www.iseriespython.com

Joe

P.S. JAX-WS (the Java equivalent) for the above:

<%
QuotePort port = new QuoteClient().getQuotePort();
BigDecimal price = port.getQuote("IBM");
out.write("Current IBM stock price is " + price);
%>

You generate the client from the WSDL, and all of the
plumbing is done for
you.

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

message: 5
date: Wed, 09 May 2007 11:33:41 -0700
from: "Roger Harman" <RHarman@xxxxxxxxxx>
subject: RE: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...

Isn't this the same as: OVRDBF FILE(MYFILE) SHARE(*YES) ??

Jon.Paris@xxxxxxxxxxxxxx 05/09/2007 11:23:02 AM >>>

<snip>
Another nice aspect of COBOL that hopefully we'll see in RPG
shortly is
the
ability to share files between programs (EXTERNAL files).
</snip>

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

message: 6
date: Wed, 9 May 2007 14:36:02 -0400
from: "Chuck Lewis" <chuck.lewis@xxxxxxxxxxxxx>
subject: RE: First Annual COMMON conference - Spring 2007

OK, that's what I remember us discussing over on CPF a while back :-)

Chuck

-----Original Message-----
From: midrange-l-bounces+chuck.lewis=leesupply.net@xxxxxxxxxxxx
[mailto:midrange-l-bounces+chuck.lewis=leesupply.net@midrange.

com] On Behalf

Of DebbieKelemen
Sent: Wednesday, May 09, 2007 1:22 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: First Annual COMMON conference - Spring 2007

No I've worked for Chefs for over 2 years now. We did
announce recently
that we are opening a "Corporate" office in San Francisco and they are
moving part of the departments out there. My department is
not moving.
Supposedly, the company is totally "committed" to staying
where we are.
Only time will tell.

Deb

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

message: 7
date: Wed, 9 May 2007 14:50:01 -0400
from: "Steve Richter" <stephenrichter@xxxxxxxxx>
subject: Re: *SRVPGM vs. dynamically CALLed *PGM from ILE COBOL...

On 5/9/07, Jon Paris <Jon.Paris@xxxxxxxxxxxxxx> wrote:

I agree that COBOL has some restrictions on naming etc but this

>> no support for passing parms to sub routines within a

Cobol program.

Isn't one of them. There isn't any such support for RPG

either - we use

subprocedures. The equivalent in COBOL is nested programs,

and they take

parameters just as RPG subprocedures do.

my cobol lifeline at the shop I was in gave nested programs a thumbs
down, but she did not give a reason. It did seem to be a big
production in terms of all the sections you need in a cobol program.
worth a try though.

Although COBOL limits the exporting of names (for reasons I don't
understand) it is actually more powerful in terms of

public/global data etc.

than RPG. Within the context of one program - nested programs can
incorporate other nested programs (i.e. procedures having

local procedures)

and can either share data with them or not at their discretion.

the overlaying of data structures seen in the typical COBOL program is
brutal for a programmer to deal with.

The limitiation that I will stand by and that Michael should be aware
of is you effectively cant call into a SRVPGM from COBOL. Basically,
COBOL does not work with ILE. ( COBOL only sees one max 10 char
procedure in the SRVPGM ) The COBOL code I worked with had been
"modernized" from mainframe COBOL to call external programs and use
embedded SQL.

-Steve

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

message: 8
date: Wed, 09 May 2007 13:51:03 -0500
from: Booth Martin <booth@xxxxxxxxxxxx>
subject: Re: Why can't we eat our own cooking?

The issue of "need" is all in my head. David has everything up and
running, it seems.

It just seems that if the System i is such an all-fired great machine
that it should be able to compete in some way with what David, and
others, are using.

Gosh, if we System i bigots can't make a case for using the
System i in
this very real-life situation, then how can we expect normal
people to
choose System i?

In other words, can we eat our own cooking?

Doug Palme wrote:

I cannot speak for anyone else but I would be willing to

contribute towards

a new box if that was needed.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth Martin
Sent: Wednesday, May 09, 2007 10:33 AM
To: Midrange Systems Technical Discussion
Subject: Why can't we eat our own cooking?

Why can't we eat our own cooking?

It has always bugged me that David, who runs this list out

of his own

pocket, as a unpaid hobby, has had to make the business

decision to not

use System i. If there is any place at all that can show

us how to use

System i for our work as we involve our businesses with the

Internet, it

is David and these lists that he maintains. If he can do

it, so can;t

we. If he can't, then maybe we can't, either?

Would the heavy hitters on this list please make the case

with the right

people to get David to Rochester for a week or so to get a new box
properly configured, and send him home with it? Please?

There are

some Important People that read this list, and their words

will carry

weight, especially if their efforts are deliberate and unified.

(I understand this post is way off topic, but then again,

maybe it is

exactly on topic?)

--
---------------------------------
Booth Martin
http://www.Martinvt.com
---------------------------------

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

--
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 6, Issue 956
******************************************