Re: Can I use a NAS attached to z/OS

[David Crayford]

On 12/1/22 8:34 am, Wayne Bickerdike wrote:

Fundi, now Rocket, bought a licence for MFNetdisk. Dave Crayford might know
if it's still available or in use.


We used it up for HSM ML2 until we purchased a second hand ATL. It was a 
very innovative product and worked well. However, like all software it 
had bugs
and when they surfaced it was quite nasty. It's my understanding that 
Shai open sourced MFNetDisk or at least made it free with no support.





I used the free version for a while, it was a great concept.

On Wed, Jan 12, 2022 at 10:18 AM PINION, RICHARD W. <
rpin...@firsthorizon.com> wrote:


Let's not forget Shai Hess's MFNetDisk.  I don't think it's available
anymore.
But, I used it extensively from 2010 to 2016.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Radoslaw Skorupka
Sent: Tuesday, January 11, 2022 5:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can I use a NAS attached to z/OS

[External Email. Exercise caution when clicking links or opening
attachments.]

W dniu 10.01.2022 o 13:00, Colin Paice pisze:

Having a playful and inquiring mind, I wondered if it was possible to
get HSM etc to work with a Network Attached Storage box (Synology).
For education - not production.
Colin

Yes and no.
1. Yes, you can configure your NAS as NFS (I hope so) and connect z/OS to
NFS server. However it has nothing to do with DFSMShsm.
2. Yes, you can send your HSM data outside. But that require additional
software like current Model9 or old (maybe still in use?) VTF clone - a
software which emulated tapes on DASD. I vaguely remember some (EMC?)
product which directed HSM data stream to OSA card and finally some
non-mainframe disk array. Note: I'm NOT talking about DLm or former
BusTech. It was before EMC acquired BusTech.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice:
This e-mail message, including any attachments, may contain legally
privileged and/or confidential information. If you are not the intended
recipient(s), or the employee or agent responsible for delivery of this
message to the intended recipient(s), you are hereby notified that any
dissemination, distribution, or copying of this e-mail message is strictly
prohibited. If you have received this message in error, please immediately
notify the sender and delete this e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can I use a NAS attached to z/OS

[Wayne Bickerdike]

Fundi, now Rocket, bought a licence for MFNetdisk. Dave Crayford might know
if it's still available or in use.

I used the free version for a while, it was a great concept.

On Wed, Jan 12, 2022 at 10:18 AM PINION, RICHARD W. <
rpin...@firsthorizon.com> wrote:

> Let's not forget Shai Hess's MFNetDisk.  I don't think it's available
> anymore.
> But, I used it extensively from 2010 to 2016.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Radoslaw Skorupka
> Sent: Tuesday, January 11, 2022 5:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can I use a NAS attached to z/OS
>
> [External Email. Exercise caution when clicking links or opening
> attachments.]
>
> W dniu 10.01.2022 o 13:00, Colin Paice pisze:
> > Having a playful and inquiring mind, I wondered if it was possible to
> > get HSM etc to work with a Network Attached Storage box (Synology).
> > For education - not production.
> > Colin
>
> Yes and no.
> 1. Yes, you can configure your NAS as NFS (I hope so) and connect z/OS to
> NFS server. However it has nothing to do with DFSMShsm.
> 2. Yes, you can send your HSM data outside. But that require additional
> software like current Model9 or old (maybe still in use?) VTF clone - a
> software which emulated tapes on DASD. I vaguely remember some (EMC?)
> product which directed HSM data stream to OSA card and finally some
> non-mainframe disk array. Note: I'm NOT talking about DLm or former
> BusTech. It was before EMC acquired BusTech.
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Confidentiality notice:
> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DS6800

[Mike Schwab]

I've asked, and they only do FC, with a series of PCIe cards.

https://www.synology.com/en-us/compatibility?search_by=category=fc_host_bus_adapters=1_log_p=1

On Tue, Jan 11, 2022 at 10:24 PM Radoslaw Skorupka
 wrote:
>
> Does it support CKD volumes and FICON connectivity?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 08.01.2022 o 21:44, AbsKerneels pisze:
> > Why do you not just get yourself the latest SYNOLOGY device.
> >
> > Cost much less and can do 10 times more :
> >
> > https://www.synology.com/en-us/support/nas_selector
> >
> > Note: Just try and speak to a NAS expert for educational purposes.
> >
> > Anton
> >
> >
> > On 1/8/2022 12:56 PM, Ben Huntsman wrote:
> >> Hi there-
> >> Apologies in advance for the spam.
> >> The first storage system I learned on was a DS8100.  That was a
> >> fun system!  I'm building a small home lab and was hoping to get a
> >> DS6800, due to its similarities and ability to do CKD as well as FB.
> >> So I figured I'd ask, does anyone here have an old DS6800 they aren't
> >> using and might be willing to sell for lab/personal use?
> >>
> >> Many thanks in advance, and sorry again for the noise!
> >>
> >> -Ben
> >>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can I use a NAS attached to z/OS

[PINION, RICHARD W.]

Let's not forget Shai Hess's MFNetDisk.  I don't think it's available anymore.
But, I used it extensively from 2010 to 2016.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Tuesday, January 11, 2022 5:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can I use a NAS attached to z/OS

[External Email. Exercise caution when clicking links or opening attachments.]

W dniu 10.01.2022 o 13:00, Colin Paice pisze:
> Having a playful and inquiring mind, I wondered if it was possible to 
> get HSM etc to work with a Network Attached Storage box (Synology).  
> For education - not production.
> Colin

Yes and no.
1. Yes, you can configure your NAS as NFS (I hope so) and connect z/OS to NFS 
server. However it has nothing to do with DFSMShsm.
2. Yes, you can send your HSM data outside. But that require additional 
software like current Model9 or old (maybe still in use?) VTF clone - a 
software which emulated tapes on DASD. I vaguely remember some (EMC?) product 
which directed HSM data stream to OSA card and finally some non-mainframe disk 
array. Note: I'm NOT talking about DLm or former BusTech. It was before EMC 
acquired BusTech.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can I use a NAS attached to z/OS

[Radoslaw Skorupka]

W dniu 10.01.2022 o 13:00, Colin Paice pisze:

Having a playful and inquiring mind, I wondered if it was possible to get
HSM etc to work with a Network Attached Storage box (Synology).  For
education - not production.
Colin


Yes and no.
1. Yes, you can configure your NAS as NFS (I hope so) and connect z/OS 
to NFS server. However it has nothing to do with DFSMShsm.
2. Yes, you can send your HSM data outside. But that require additional 
software like current Model9 or old (maybe still in use?) VTF clone - a 
software which emulated tapes on DASD. I vaguely remember some (EMC?) 
product which directed HSM data stream to OSA card and finally some 
non-mainframe disk array. Note: I'm NOT talking about DLm or former 
BusTech. It was before EMC acquired BusTech.



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DS6800

[Radoslaw Skorupka]

Does it support CKD volumes and FICON connectivity?


--
Radoslaw Skorupka
Lodz, Poland




W dniu 08.01.2022 o 21:44, AbsKerneels pisze:

Why do you not just get yourself the latest SYNOLOGY device.

Cost much less and can do 10 times more :

https://www.synology.com/en-us/support/nas_selector

Note: Just try and speak to a NAS expert for educational purposes.

Anton


On 1/8/2022 12:56 PM, Ben Huntsman wrote:

Hi there-
    Apologies in advance for the spam.
    The first storage system I learned on was a DS8100.  That was a 
fun system!  I'm building a small home lab and was hoping to get a 
DS6800, due to its similarities and ability to do CKD as well as FB.  
So I figured I'd ask, does anyone here have an old DS6800 they aren't 
using and might be willing to sell for lab/personal use?


    Many thanks in advance, and sorry again for the noise!

-Ben



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RLS False Contention Statistics

[Attila Fogarasi]

What is your MAXSYSTEMS value?  There is a false lock contention penalty
when your MAXSYSTEMS value exceeds 7 or 23.  Of course your MAXSYSTEMS has
to match the actual number of parallel sysplex members :)  Also what is
your false lock contention rate?  1% is typically acceptable though it
really varies with your application structure.  Ultimately it is an
application design issue, and Db2/IMS do a much better job of concurrent
data access.

On Wed, Jan 12, 2022 at 2:19 AM Crawford, Robert C. <
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> All,
>
> I can't reconcile RLS lock structure false lock contention between the
> various SMS statistics records.
>
> According to the type 42 subtype 17 we have a lot of false contention
> (field SMF42HCC).  However, our type 42 subtypes 15 (storage class response
> time) and 16 (dataset response time) false contention buckets are zero.
> The only exception in the 16's and 17's are fields SMF42GUB and SMF42FUB
> that record locks that hashed to the same entry, which I thought was the
> definition of false contention.  However, the statistics in those fields
> are a little more than half than the false contention reported in the
> subtype 15's.
>
> I have SMS dataset monitoring set up for both SMF and IGWDATA.
>
> We are feature level Z (don't ask) so all the statistics should be below
> the line.
>
> Our lock structure is already 1G in size so I'd like to find the root
> cause of the false contention before making it any bigger.
>
> Does anyone have some advice?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> "Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
> - Tolstoy
> Please send requests to mainframe management through our front door at
> go/mfmfrontdoor<
> https://onc.jira.usaacloud.com/secure/Dashboard.jspa?selectPageId=15466>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

I can't remember other than it was only around 10 lines.  I think just 
variable access and some simple calculations.


On 1/11/2022 10:47 AM, Paul Gilmartin wrote:

What didn't your "small performance test" do?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

(Subject: and content trimmed.)
On Tue, 11 Jan 2022 09:41:23 -0800, Tom Brennan wrote:
>...
>finally pushed me over:  I ran a small performance test and Rexx beat
>CLIST by about 1000 times if I remember correctly.  So I pulled out the
>Rexx manuals.
>
Back in the day when fiche was available I ran a code coverage tool on a
CLIST with a "do very little" loop.  The preponderance of time was spent
in CALL/RETURN from "get one source character" routine.  Great
structure; lousy performance.  I assume they never heard of macros.

CLIST performance was supposed to improve with TSO/E R2 and code
reusable between Rexx/CLIST, but no fiche.

What didn't your "small performance test" do?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

Nice!  Now do CLIST

Ok, just joking.  I was probably the last person on my block to switch 
from CLIST to Rexx when it became available on MVS.  A simple thing 
finally pushed me over:  I ran a small performance test and Rexx beat 
CLIST by about 1000 times if I remember correctly.  So I pulled out the 
Rexx manuals.


On 1/10/2022 8:46 PM, David Crayford wrote:

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.
That seems to be begging the question. Certainly the current 
implementation is inefficient, but what fundamental issue prevents a 
more efficient implementation?


A more effecient implementation requires a rewrite.

For that matter, what fundamental issue prevents compiling into Java 
bytecode with a large runtime similar to the CREXX runtime?


None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
It's strongly typed and the JVM is going to JIT compile it so it will be 
fast. As Rene mentioned you can use Java classes so there is a massive 
eco-system available.



I knocked up some simple benchtests which create an array of squares and 
then find the maximum value. The maximum value is the end element. The 
results are just what I expected. ooRexx performs poorly.
Stem variables are particularly bad which is to be expected because they 
are essentially associative arrays. Using the Array class was much 
better but the result was still many orders of magnitude worse then the
other languages I tested. What's interesting is that LuaJIT is as fast 
as C++ and interpreted Lua is almost as fast as Julia which has JIT.


❯ rexx -v
Open Object Rexx Version 4.2.0
Build date: Dec 29 2013
Addressing Mode: 64
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2013.
All Rights Reserved.
This program and the accompanying materials are made available under
the terms of the Common Public License v1.0 which accompanies this
distribution or at
http://www.oorexx.org/license.html

❯ cat squares.rexx
/* REXX */
numeric digits 30
MAX = 1000
s. = 0
do n = 1 to MAX
   s.n = n * n
end
m = 0
do i = 1 to MAX
   m = max(m, s.i)
end
say max

❯ time rexx squares.rexx
1000rexx squares.rexx  43.04s user 3.25s system 99% cpu 46.296 total

❯ cat squares2.rexx
numeric digits 30
s = .Array~new()
do n = 1 to 1000
   s~append(n * n)
end
m = 0
do n = 1 to s~items
   m = max(m, s[n])
end
say m

❯ time rexx squares2.rexx
100
rexx squares2.rexx  17.25s user 1.32s system 99% cpu 18.568 total

❯ lua -v
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio

local s = {}
for n = 1, 1000 do
    s[n] = n * n
end
local max = 0
for _, n in ipairs(s) do
   max = math.max(max, n)
end
print(max)

❯ time lua squares.lua
100
lua squares.lua  0.79s user 0.07s system 99% cpu 0.862 total

❯ luajit -v
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/

❯ time luajit squares.lua
1e+14
luajit squares.lua  0.08s user 0.05s system 99% cpu 0.137 total

❯ python3 --version
Python 3.8.10

❯ cat squares.py
s = []
for n in range(1, 1000+1):
     s.append(n * n)
print(max(s))

❯ time python3 squares.py
100
python3 squares.py  1.13s user 0.16s system 99% cpu 1.288 total

❯ julia --version
julia version 1.4.1

❯ cat squares.jl
s = Int[]
for n = 1:1000
   push!(s, n * n)
end
println(maximum(s))

❯ time julia squares.jl
100
julia squares.jl  0.56s user 0.74s system 214% cpu 0.608 total

❯ clang++ --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

❯ cat squares.cpp
#include 
#include 
#include 
#include 
int main() {
     constexpr int MAX = 1000;
     std::vector s(MAX);
     for (uint64_t n = 1; n <= MAX; n++) s.push_back(n * n);
     std::cout << *std::max_element(s.begin(), s.end()) << "\n";

❯ time ./squares
100
./squares  0.05s user 0.05s system 99% cpu 0.107 total





--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
behalf of David Crayford [dcrayf...@gmail.com]

Sent: Monday, January 10, 2022 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming 
features (Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS


On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.
What do you mean by "the message paradigm"? How does it differ from 
sending method invocation and response messages to objects?
The message paradigm as set forth by Smalltalk explicitly defines a 
class for messages, allows for
intercepting messages, rerouting messages at the will of the 
programmer and much more, as messages
themselves become objects that the programmer can interact with, if 
needed.


ooRexx implements the 

Re: COBOL V6 question

[Carmen Vitullo]

First thing I checked when the compile issues first appeared was to 
check the loadlib's luckily they all are PDS/E's :)


I hate to assume all the V6 testing that was done before I was handed 
this uncovered most of these issues.


I'm gonna try and research as much as I can so I can be prepared for any 
issues that arise this year, then, I'll pass the baton :)


thanks Dave

Carmen

On 1/11/2022 11:23 AM, Dave Jousma wrote:

On Tue, 11 Jan 2022 11:18:55 -0600, Dave Jousma  wrote:



There might still be reason for a level of panic.

COBOL V6 required PDS-E load libraries.  If you are already PDSE everywhere, 
then no issue.   Not hard to convert, but disruptive.
CPU to compile COBOL V6 goes up exponentially.So if CPU is constrained, 
could be an issue.

There are many new features introduced in COBOL V6.   Many have hold actions to 
have the enabling LE support for those functions in all environments BEFORE 
rolling out the COBOL PTF, otherwise you may see errors in prod.


I should have also added that we did have some application code changes to make too.   
There are also some "rules" about mixed run-units (i.e. mixture of cobol 
versions, assembler, etc in same run unit).

We are only a few shorts months away from EOS for V4.2.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Dave Jousma]

On Tue, 11 Jan 2022 11:18:55 -0600, Dave Jousma  wrote:


>
>There might still be reason for a level of panic.
>
>COBOL V6 required PDS-E load libraries.  If you are already PDSE everywhere, 
>then no issue.   Not hard to convert, but disruptive.
>CPU to compile COBOL V6 goes up exponentially.So if CPU is constrained, 
>could be an issue.
>
>There are many new features introduced in COBOL V6.   Many have hold actions 
>to have the enabling LE support for those functions in all environments BEFORE 
>rolling out the COBOL PTF, otherwise you may see errors in prod.
>
I should have also added that we did have some application code changes to make 
too.   There are also some "rules" about mixed run-units (i.e. mixture of cobol 
versions, assembler, etc in same run unit).  

We are only a few shorts months away from EOS for V4.2.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Dave Jousma]

On Tue, 11 Jan 2022 11:00:35 -0600, Carmen Vitullo  wrote:

>good to know !
>
>seems there's been a lot of panic here for no reason, now that all the
>programmers know we're using 6.2 COBOL compilers, ever issue they see is
>related, seems about right, seen this reaction at more than one site.
>

There might still be reason for a level of panic.

COBOL V6 required PDS-E load libraries.  If you are already PDSE everywhere, 
then no issue.   Not hard to convert, but disruptive.
CPU to compile COBOL V6 goes up exponentially.So if CPU is constrained, 
could be an issue.

There are many new features introduced in COBOL V6.   Many have hold actions to 
have the enabling LE support for those functions in all environments BEFORE 
rolling out the COBOL PTF, otherwise you may see errors in prod.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Carmen Vitullo]

good to know !

seems there's been a lot of panic here for no reason, now that all the 
programmers know we're using 6.2 COBOL compilers, ever issue they see is 
related, seems about right, seen this reaction at more than one site.


all issues have been resolved so far even some that were not COBOL but 
related to eztrieve - crazy


hank you

Carmen

On 1/11/2022 10:40 AM, Matthew Stitt wrote:

Since 1990 (or so)

  //COBEXEC PGM=IGYCRCTL,REGION=4M,COND=(4,LT),
  // PARM=('CICS("COBOL3,SP")',
  //   APOST,NOSSRANGE,LIB,MAP,OFFSET)
  //STEPLIB  DD DISP=SHR,DSN=SYS1.IGY.SIGYCOMP
  // DD DISP=SHR,DSN=CICSTS51.CICS.SDFHLOAD

Matthew

On Tue, 11 Jan 2022 10:27:43 -0600, Carmen Vitullo  wrote:


Thanks Peter, in a former company that's what I was use to also.

Carmen

On 1/11/2022 10:24 AM, Farley, Peter x23353 wrote:

Bummer.  I can't imagine having my SDLC admin not be at least a semi-skilled 
z/OS professional, or better yet a set of skilled professionals, but ours is a 
very large shop so that's what I'm used to having.

You have my deepest sympathy.

Peter

-Original Message-
From: IBM Mainframe Discussion List   On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:40 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V6 question

that helps Greatly thanks so much Peter, I was thinking a major project to 
rework the entire process.

unfortunately our Endeavor admin has very little mainframe or Endeavor 
experience :(

thanks again

Carmen

On 1/11/2022 9:34 AM, Farley, Peter x23353 wrote:

Carmen,

Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and with 
4.2 going off support this year management made a strong push to prevent 4.2 
modules (changes or additions) from going into production on a going-forward 
basis.  OTOH, we still have many production programs that haven't changed in a 
long time that were originally compiled with V3 running just fine.

Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the pre-compilers 
for V6.2 translations without any problems.  If your Endeavor process to translate DB2 
and/or CICS programs use the pre-compilers, they will continue to work as before.  If it 
ain't broke, there's no urgent need to "fix" it.

One slight drawback of the "built-in" DB2 and CICS translation is that your 
COBOL listing shows only the original SQL or EXEC CICS statements, not the underlying 
MOVE's and CALL's that implement them (you have to use the LIST compiler option to see 
the pseudo-assembler equivalent).  Some programmers may call that an improvement, some 
won't.

I'm not aware of any significant or documented program runtime performance benefit from 
using the "built-in" translators, though there may be compile-job efficiency to 
be gained (one step instead of several).

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion ListOn
Behalf Of Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:05AMTo:IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL V6 question

Well I just inherited COBOL support and our programmers have been trying to 
debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in CICS 
TS 5.4. the tool used is Endeavor, long story short, V6 was being tested in 
some processes but never updated in others.
my question is mostly a sanity check, from what I've read the DB2 pre compiler 
and the CICS translators are no longer needed, COBOL parms and options are now 
used if these are DB2 or CICS programs ?
this is valid ?
thanks Carmen

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Matthew Stitt]

Since 1990 (or so)

 //COBEXEC PGM=IGYCRCTL,REGION=4M,COND=(4,LT), 
 // PARM=('CICS("COBOL3,SP")', 
 //   APOST,NOSSRANGE,LIB,MAP,OFFSET)  
 //STEPLIB  DD DISP=SHR,DSN=SYS1.IGY.SIGYCOMP  
 // DD DISP=SHR,DSN=CICSTS51.CICS.SDFHLOAD 

Matthew

On Tue, 11 Jan 2022 10:27:43 -0600, Carmen Vitullo  wrote:

>Thanks Peter, in a former company that's what I was use to also.
>
>Carmen
>
>On 1/11/2022 10:24 AM, Farley, Peter x23353 wrote:
>> Bummer.  I can't imagine having my SDLC admin not be at least a semi-skilled 
>> z/OS professional, or better yet a set of skilled professionals, but ours is 
>> a very large shop so that's what I'm used to having.
>>
>> You have my deepest sympathy.
>>
>> Peter
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Carmen Vitullo
>> Sent: Tuesday, January 11, 2022 10:40 AM
>> To:IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COBOL V6 question
>>
>> that helps Greatly thanks so much Peter, I was thinking a major project to 
>> rework the entire process.
>>
>> unfortunately our Endeavor admin has very little mainframe or Endeavor 
>> experience :(
>>
>> thanks again
>>
>> Carmen
>>
>> On 1/11/2022 9:34 AM, Farley, Peter x23353 wrote:
>>> Carmen,
>>>
>>> Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and 
>>> with 4.2 going off support this year management made a strong push to 
>>> prevent 4.2 modules (changes or additions) from going into production on a 
>>> going-forward basis.  OTOH, we still have many production programs that 
>>> haven't changed in a long time that were originally compiled with V3 
>>> running just fine.
>>>
>>> Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the 
>>> pre-compilers for V6.2 translations without any problems.  If your Endeavor 
>>> process to translate DB2 and/or CICS programs use the pre-compilers, they 
>>> will continue to work as before.  If it ain't broke, there's no urgent need 
>>> to "fix" it.
>>>
>>> One slight drawback of the "built-in" DB2 and CICS translation is that your 
>>> COBOL listing shows only the original SQL or EXEC CICS statements, not the 
>>> underlying MOVE's and CALL's that implement them (you have to use the LIST 
>>> compiler option to see the pseudo-assembler equivalent).  Some programmers 
>>> may call that an improvement, some won't.
>>>
>>> I'm not aware of any significant or documented program runtime performance 
>>> benefit from using the "built-in" translators, though there may be 
>>> compile-job efficiency to be gained (one step instead of several).
>>>
>>> HTH
>>>
>>> Peter
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List   On
>>> Behalf Of Carmen Vitullo
>>> Sent: Tuesday, January 11, 2022 10:05 AMTo:IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: COBOL V6 question
>>>
>>> Well I just inherited COBOL support and our programmers have been trying to 
>>> debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in 
>>> CICS TS 5.4. the tool used is Endeavor, long story short, V6 was being 
>>> tested in some processes but never updated in others.
>>> my question is mostly a sanity check, from what I've read the DB2 pre 
>>> compiler and the CICS translators are no longer needed, COBOL parms and 
>>> options are now used if these are DB2 or CICS programs ?
>>> this is valid ?
>>> thanks Carmen
>> --
>>
>> This message and any attachments are intended only for the use of the 
>> addressee and may contain information that is privileged and confidential. 
>> If the reader of the message is not the intended recipient or an authorized 
>> representative of the intended recipient, you are hereby notified that any 
>> dissemination of this communication is strictly prohibited. If you have 
>> received this communication in error, please notify us immediately by e-mail 
>> and delete the message and any attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Carmen Vitullo]

Thanks Peter, in a former company that's what I was use to also.

Carmen

On 1/11/2022 10:24 AM, Farley, Peter x23353 wrote:

Bummer.  I can't imagine having my SDLC admin not be at least a semi-skilled 
z/OS professional, or better yet a set of skilled professionals, but ours is a 
very large shop so that's what I'm used to having.

You have my deepest sympathy.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:40 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V6 question

that helps Greatly thanks so much Peter, I was thinking a major project to 
rework the entire process.

unfortunately our Endeavor admin has very little mainframe or Endeavor 
experience :(

thanks again

Carmen

On 1/11/2022 9:34 AM, Farley, Peter x23353 wrote:

Carmen,

Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and with 
4.2 going off support this year management made a strong push to prevent 4.2 
modules (changes or additions) from going into production on a going-forward 
basis.  OTOH, we still have many production programs that haven't changed in a 
long time that were originally compiled with V3 running just fine.

Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the pre-compilers 
for V6.2 translations without any problems.  If your Endeavor process to translate DB2 
and/or CICS programs use the pre-compilers, they will continue to work as before.  If it 
ain't broke, there's no urgent need to "fix" it.

One slight drawback of the "built-in" DB2 and CICS translation is that your 
COBOL listing shows only the original SQL or EXEC CICS statements, not the underlying 
MOVE's and CALL's that implement them (you have to use the LIST compiler option to see 
the pseudo-assembler equivalent).  Some programmers may call that an improvement, some 
won't.

I'm not aware of any significant or documented program runtime performance benefit from 
using the "built-in" translators, though there may be compile-job efficiency to 
be gained (one step instead of several).

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List   On
Behalf Of Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:05 AMTo:IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL V6 question

Well I just inherited COBOL support and our programmers have been trying to 
debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in CICS 
TS 5.4. the tool used is Endeavor, long story short, V6 was being tested in 
some processes but never updated in others.
my question is mostly a sanity check, from what I've read the DB2 pre compiler 
and the CICS translators are no longer needed, COBOL parms and options are now 
used if these are DB2 or CICS programs ?
this is valid ?
thanks Carmen

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Farley, Peter x23353]

Bummer.  I can't imagine having my SDLC admin not be at least a semi-skilled 
z/OS professional, or better yet a set of skilled professionals, but ours is a 
very large shop so that's what I'm used to having.

You have my deepest sympathy.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V6 question

that helps Greatly thanks so much Peter, I was thinking a major project to 
rework the entire process.

unfortunately our Endeavor admin has very little mainframe or Endeavor 
experience :(

thanks again

Carmen

On 1/11/2022 9:34 AM, Farley, Peter x23353 wrote:
> Carmen,
>
> Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and 
> with 4.2 going off support this year management made a strong push to prevent 
> 4.2 modules (changes or additions) from going into production on a 
> going-forward basis.  OTOH, we still have many production programs that 
> haven't changed in a long time that were originally compiled with V3 running 
> just fine.
>
> Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the 
> pre-compilers for V6.2 translations without any problems.  If your Endeavor 
> process to translate DB2 and/or CICS programs use the pre-compilers, they 
> will continue to work as before.  If it ain't broke, there's no urgent need 
> to "fix" it.
>
> One slight drawback of the "built-in" DB2 and CICS translation is that your 
> COBOL listing shows only the original SQL or EXEC CICS statements, not the 
> underlying MOVE's and CALL's that implement them (you have to use the LIST 
> compiler option to see the pseudo-assembler equivalent).  Some programmers 
> may call that an improvement, some won't.
>
> I'm not aware of any significant or documented program runtime performance 
> benefit from using the "built-in" translators, though there may be 
> compile-job efficiency to be gained (one step instead of several).
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Carmen Vitullo
> Sent: Tuesday, January 11, 2022 10:05 AM To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL V6 question
>
> Well I just inherited COBOL support and our programmers have been trying to 
> debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in 
> CICS TS 5.4. the tool used is Endeavor, long story short, V6 was being tested 
> in some processes but never updated in others.
> my question is mostly a sanity check, from what I've read the DB2 pre 
> compiler and the CICS translators are no longer needed, COBOL parms and 
> options are now used if these are DB2 or CICS programs ?
> this is valid ?
> thanks Carmen
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Carmen Vitullo]

that helps Greatly thanks so much Peter, I was thinking a major project 
to rework the entire process.


unfortunately our Endeavor admin has very little mainframe or Endeavor 
experience :(


thanks again

Carmen

On 1/11/2022 9:34 AM, Farley, Peter x23353 wrote:

Carmen,

Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and with 
4.2 going off support this year management made a strong push to prevent 4.2 
modules (changes or additions) from going into production on a going-forward 
basis.  OTOH, we still have many production programs that haven't changed in a 
long time that were originally compiled with V3 running just fine.

Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the pre-compilers 
for V6.2 translations without any problems.  If your Endeavor process to translate DB2 
and/or CICS programs use the pre-compilers, they will continue to work as before.  If it 
ain't broke, there's no urgent need to "fix" it.

One slight drawback of the "built-in" DB2 and CICS translation is that your 
COBOL listing shows only the original SQL or EXEC CICS statements, not the underlying 
MOVE's and CALL's that implement them (you have to use the LIST compiler option to see 
the pseudo-assembler equivalent).  Some programmers may call that an improvement, some 
won't.

I'm not aware of any significant or documented program runtime performance benefit from 
using the "built-in" translators, though there may be compile-job efficiency to 
be gained (one step instead of several).

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:05 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL V6 question

EXTERNAL EMAIL

Well I just inherited COBOL support and our programmers have been trying to 
debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in CICS 
TS 5.4. the tool used is Endeavor, long story short, V6 was being tested in 
some processes but never updated in others.
my question is mostly a sanity check, from what I've read the DB2 pre compiler 
and the CICS translators are no longer needed, COBOL parms and options are now 
used if these are DB2 or CICS programs ?
this is valid ?
thanks Carmen
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V6 question

[Farley, Peter x23353]

Carmen,

Not *necessary* but still usable.  We are V6 also (6.2, not 6.3 yet), and with 
4.2 going off support this year management made a strong push to prevent 4.2 
modules (changes or additions) from going into production on a going-forward 
basis.  OTOH, we still have many production programs that haven't changed in a 
long time that were originally compiled with V3 running just fine.

Our DB2 and CICS SDLC process (in-house, not ISV product) still uses the 
pre-compilers for V6.2 translations without any problems.  If your Endeavor 
process to translate DB2 and/or CICS programs use the pre-compilers, they will 
continue to work as before.  If it ain't broke, there's no urgent need to "fix" 
it.

One slight drawback of the "built-in" DB2 and CICS translation is that your 
COBOL listing shows only the original SQL or EXEC CICS statements, not the 
underlying MOVE's and CALL's that implement them (you have to use the LIST 
compiler option to see the pseudo-assembler equivalent).  Some programmers may 
call that an improvement, some won't.

I'm not aware of any significant or documented program runtime performance 
benefit from using the "built-in" translators, though there may be compile-job 
efficiency to be gained (one step instead of several).

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Tuesday, January 11, 2022 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL V6 question

EXTERNAL EMAIL

Well I just inherited COBOL support and our programmers have been trying to 
debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in CICS 
TS 5.4. the tool used is Endeavor, long story short, V6 was being tested in 
some processes but never updated in others. 
my question is mostly a sanity check, from what I've read the DB2 pre compiler 
and the CICS translators are no longer needed, COBOL parms and options are now 
used if these are DB2 or CICS programs ?
this is valid ?
thanks Carmen 
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RLS False Contention Statistics

[Crawford, Robert C.]

All,

I can't reconcile RLS lock structure false lock contention between the various 
SMS statistics records.

According to the type 42 subtype 17 we have a lot of false contention (field 
SMF42HCC).  However, our type 42 subtypes 15 (storage class response time) and 
16 (dataset response time) false contention buckets are zero.  The only 
exception in the 16's and 17's are fields SMF42GUB and SMF42FUB that record 
locks that hashed to the same entry, which I thought was the definition of 
false contention.  However, the statistics in those fields are a little more 
than half than the false contention reported in the subtype 15's.

I have SMS dataset monitoring set up for both SMF and IGWDATA.

We are feature level Z (don't ask) so all the statistics should be below the 
line.

Our lock structure is already 1G in size so I'd like to find the root cause of 
the false contention before making it any bigger.

Does anyone have some advice?

Thanks.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FWIW: NoOps: IT Operations Getting Closer to Automated Future | Data Center Knowledge

[Mark Regan]

 
https://www.datacenterknowledge.com/manage/noops-it-operations-getting-closer-automated-future

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS Network Software Consultant (z NetView, z/OS Communications Server)
Contractor, Checks & Balances, Inc.
Email: marktre...@gmail.com
LinkedIn:  https://www.linkedin.com/in/mark-t-regan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL V6 question

[Carmen Vitullo]

Well I just inherited COBOL support and our programmers have been trying to 
debug an issue with CICS COBOL, seems Ent COBOL V4 was still being used in CICS 
TS 5.4. the tool used is Endeavor, long story short, V6 was being tested in 
some processes but never updated in others. 
my question is mostly a sanity check, from what I've read the DB2 pre compiler 
and the CICS translators are no longer needed, COBOL parms and options are now 
used if these are DB2 or CICS programs ?
this is valid ?
thanks Carmen 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 11.01.2022 14:06, David Crayford wrote:
> I've gone silent now Rony. But if you're a Windows user you may want to check 
> out Measure-Command
> for PowerShell so you don't have to instrument your code with timers.
>
> [1]
> https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2

Thank you for this pointer, David!

Mostly I have been working on Windows, but also on Linux and MacOS, for making 
sure that BSF4ooRexx
runs flawlessly and seamlessly on all those platforms.

---rony


>
> On 11/1/22 8:30 pm, Rony G. Flatscher wrote:
>> And here an example of ooRexx being used without any direct access to Java:
>>
>>  d1=.datetime~new  /* take time   */
>>  "java squares"    /* run command */
>>  d2=.datetime~new  /* take time   */
>>  say "duration:" d2-d1
>>
>> The results of running this program are:
>>
>>  G:\tmp\ibmmain\arrays>squares_oorexx.rex
>>  100
>>  duration: 00:00:00.247000
>>
>>  G:\tmp\ibmmain\arrays>squares_oorexx.rex
>>  100
>>  duration: 00:00:00.242000
>>
>> Quite fast! ;)
>>
>> ---rony
>>
>> On 11.01.2022 13:15, Rony G. Flatscher wrote:
>>> Now, if you want ooRexx to control an application and need to run the 
>>> NetRexx program from it, you
>>> can do that with ooRexx (including timings) as such:
>>>
>>>  /* ooRexx solution to control execution of NetRexx' squares  */
>>>  clz=bsf.loadClass("squares")  /* load NetRexx' squares class */
>>>
>>>  /* create an empty Java array of type java.lang.String   */
>>>  arr=bsf.createJavaArrayOf("java.lang.String")
>>>
>>>  d1=.dateTime~new  /* take time   */
>>>  /* run main method which expects a Java String array */
>>>  clz~main(arr)
>>>  d2=.dateTime~new  /* take time   */
>>>  say "duration:" d2-d1
>>>
>>>  ::requires "BSF.CLS" /* get full access to Java  */
>>>
>>> The results of running this program are, believe it or not, even faster:
>>>
>>>  G:\tmp\ibmmain\arrays>rexx squares.rxj
>>>  100
>>>  duration: 00:00:00.095000
>>>
>>>  G:\tmp\ibmmain\arrays>rexx squares.rxj
>>>  100
>>>  duration: 00:00:00.109000
>>>
>>> So the interpreted ooRexx can even beat ... :)
>>>
>>> ---rony
>>>
>>>
>>> On 11.01.2022 12:21, Rony G. Flatscher wrote:
 On 11.01.2022 05:46, David Crayford wrote:
> On 10/1/22 11:15 pm, Seymour J Metz wrote:
>>> ooRexx will never be high speed because it's implementation is
>>> fundamentally ineffecient.
>> That seems to be begging the question. Certainly the current 
>> implementation is inefficient, but
>> what fundamental issue prevents a more efficient implementation?
> A more effecient implementation requires a rewrite.
>
>> For that matter, what fundamental issue prevents compiling into Java 
>> bytecode with a large
>> runtime similar to the CREXX runtime?
> None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
> It's strongly typed and the
> JVM is going to JIT compile it so it will be fast. As Rene mentioned you 
> can use Java classes so
> there is a massive eco-system available.
 BTW, you could use Java classes from ooRexx as well, hence there is a 
 "massive eco-system
 available"
 for ooRexx. You would need the external function package named BSF4ooRexx, 
 which enables ooRexx to
 work with any Java class library, no matter whether it got created with 
 Java, NetRexx, Kotlin,
 Groovy, ...

> I knocked up some simple benchtests which create an array of squares and 
> then find the maximum
> value. The maximum value is the end element. The results are just what I 
> expected. ooRexx
> performs
> poorly.
 Not a surprise. :)

 This "simple benchtest" is architected in a way that makes interpreted 
 languages look
 especially bad
 compared to compiled languages, it is of a form that is not relevant in 
 real life. Also, using
 unnecessarily numeric 30 digits for the arithmetics is interesting, as 
 well as the outdated, seven
 year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.


> Stem variables are particularly bad which is to be expected because they 
> are essentially
> associative arrays. Using the Array class was much better but the result 
> was still many orders of
> magnitude worse then the
> other languages I tested. What's interesting is that LuaJIT is as fast as 
> C++ and interpreted Lua
> is almost as fast as Julia which has JIT.
 Not a surprise. :)

 Now, if it was truly the case that someone would need such an abmysal 
 amount of number crunching
 then speed becomes interesting. In such a case what I would do for any 
 interpreted language, I
 would
 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

I've gone silent now Rony. But if you're a Windows user you may want to 
check out Measure-Command for PowerShell so you don't have to instrument 
your code with timers.


[1] 
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2



On 11/1/22 8:30 pm, Rony G. Flatscher wrote:

And here an example of ooRexx being used without any direct access to Java:

 d1=.datetime~new  /* take time   */
 "java squares"/* run command */
 d2=.datetime~new  /* take time   */
 say "duration:" d2-d1

The results of running this program are:

 G:\tmp\ibmmain\arrays>squares_oorexx.rex
 100
 duration: 00:00:00.247000

 G:\tmp\ibmmain\arrays>squares_oorexx.rex
 100
 duration: 00:00:00.242000

Quite fast! ;)

---rony

On 11.01.2022 13:15, Rony G. Flatscher wrote:

Now, if you want ooRexx to control an application and need to run the NetRexx 
program from it, you
can do that with ooRexx (including timings) as such:

 /* ooRexx solution to control execution of NetRexx' squares  */
 clz=bsf.loadClass("squares")  /* load NetRexx' squares class */

 /* create an empty Java array of type java.lang.String   */
 arr=bsf.createJavaArrayOf("java.lang.String")

 d1=.dateTime~new  /* take time   */
 /* run main method which expects a Java String array */
 clz~main(arr)
 d2=.dateTime~new  /* take time   */
 say "duration:" d2-d1

 ::requires "BSF.CLS" /* get full access to Java  */

The results of running this program are, believe it or not, even faster:

 G:\tmp\ibmmain\arrays>rexx squares.rxj
 100
 duration: 00:00:00.095000

 G:\tmp\ibmmain\arrays>rexx squares.rxj
 100
 duration: 00:00:00.109000

So the interpreted ooRexx can even beat ... :)

---rony


On 11.01.2022 12:21, Rony G. Flatscher wrote:

On 11.01.2022 05:46, David Crayford wrote:

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.

That seems to be begging the question. Certainly the current implementation is 
inefficient, but
what fundamental issue prevents a more efficient implementation?

A more effecient implementation requires a rewrite.


For that matter, what fundamental issue prevents compiling into Java bytecode 
with a large
runtime similar to the CREXX runtime?

None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
strongly typed and the
JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
use Java classes so
there is a massive eco-system available.

BTW, you could use Java classes from ooRexx as well, hence there is a "massive 
eco-system available"
for ooRexx. You would need the external function package named BSF4ooRexx, 
which enables ooRexx to
work with any Java class library, no matter whether it got created with Java, 
NetRexx, Kotlin,
Groovy, ...


I knocked up some simple benchtests which create an array of squares and then 
find the maximum
value. The maximum value is the end element. The results are just what I 
expected. ooRexx performs
poorly.

Not a surprise. :)

This "simple benchtest" is architected in a way that makes interpreted 
languages look especially bad
compared to compiled languages, it is of a form that is not relevant in real 
life. Also, using
unnecessarily numeric 30 digits for the arithmetics is interesting, as well as 
the outdated, seven
year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.



Stem variables are particularly bad which is to be expected because they are 
essentially
associative arrays. Using the Array class was much better but the result was 
still many orders of
magnitude worse then the
other languages I tested. What's interesting is that LuaJIT is as fast as C++ 
and interpreted Lua
is almost as fast as Julia which has JIT.

Not a surprise. :)

Now, if it was truly the case that someone would need such an abmysal amount of 
number crunching
then speed becomes interesting. In such a case what I would do for any 
interpreted language, I would
use a compiled one.

As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
interpreted languages
bite the dust. The question then would be whether to solve this particular 
problem in an interpreted
language at all.

In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
particular purpose:

 /* NetRexx: squares.nrx  */
 options binary/* in this case we want speed */
 items = 1000
 s = long[items]   /* define a Java array of type long   */
 loop i=1 to items
n=long i   /* for multiplication we want to use long */
s[i-1] = n * n
 end
 /* use a Java stream (introduced with Java 8)  */
 say java.util.Arrays.stream(s).max.getAsLong

You 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

And here an example of ooRexx being used without any direct access to Java:

d1=.datetime~new  /* take time   */
"java squares"/* run command */
d2=.datetime~new  /* take time   */
say "duration:" d2-d1

The results of running this program are:

G:\tmp\ibmmain\arrays>squares_oorexx.rex
100
duration: 00:00:00.247000

G:\tmp\ibmmain\arrays>squares_oorexx.rex
100
duration: 00:00:00.242000

Quite fast! ;)

---rony

On 11.01.2022 13:15, Rony G. Flatscher wrote:
> Now, if you want ooRexx to control an application and need to run the NetRexx 
> program from it, you
> can do that with ooRexx (including timings) as such:
>
> /* ooRexx solution to control execution of NetRexx' squares  */
> clz=bsf.loadClass("squares")  /* load NetRexx' squares class */
>
> /* create an empty Java array of type java.lang.String   */
> arr=bsf.createJavaArrayOf("java.lang.String")
>
> d1=.dateTime~new  /* take time   */
> /* run main method which expects a Java String array */
> clz~main(arr)
> d2=.dateTime~new  /* take time   */
> say "duration:" d2-d1
>
> ::requires "BSF.CLS" /* get full access to Java  */
>
> The results of running this program are, believe it or not, even faster:
>
> G:\tmp\ibmmain\arrays>rexx squares.rxj
> 100
> duration: 00:00:00.095000
>
> G:\tmp\ibmmain\arrays>rexx squares.rxj
> 100
> duration: 00:00:00.109000
>
> So the interpreted ooRexx can even beat ... :)
>
> ---rony
>
>
> On 11.01.2022 12:21, Rony G. Flatscher wrote:
>> On 11.01.2022 05:46, David Crayford wrote:
>>> On 10/1/22 11:15 pm, Seymour J Metz wrote:
> ooRexx will never be high speed because it's implementation is
> fundamentally ineffecient.
 That seems to be begging the question. Certainly the current 
 implementation is inefficient, but
 what fundamental issue prevents a more efficient implementation?
>>> A more effecient implementation requires a rewrite.
>>>
 For that matter, what fundamental issue prevents compiling into Java 
 bytecode with a large
 runtime similar to the CREXX runtime?
>>> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
>>> strongly typed and the
>>> JVM is going to JIT compile it so it will be fast. As Rene mentioned you 
>>> can use Java classes so
>>> there is a massive eco-system available.
>> BTW, you could use Java classes from ooRexx as well, hence there is a 
>> "massive eco-system available"
>> for ooRexx. You would need the external function package named BSF4ooRexx, 
>> which enables ooRexx to
>> work with any Java class library, no matter whether it got created with 
>> Java, NetRexx, Kotlin,
>> Groovy, ...
>>
>>> I knocked up some simple benchtests which create an array of squares and 
>>> then find the maximum
>>> value. The maximum value is the end element. The results are just what I 
>>> expected. ooRexx performs
>>> poorly.
>> Not a surprise. :)
>>
>> This "simple benchtest" is architected in a way that makes interpreted 
>> languages look especially bad
>> compared to compiled languages, it is of a form that is not relevant in real 
>> life. Also, using
>> unnecessarily numeric 30 digits for the arithmetics is interesting, as well 
>> as the outdated, seven
>> year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.
>>
>>
>>> Stem variables are particularly bad which is to be expected because they 
>>> are essentially
>>> associative arrays. Using the Array class was much better but the result 
>>> was still many orders of
>>> magnitude worse then the
>>> other languages I tested. What's interesting is that LuaJIT is as fast as 
>>> C++ and interpreted Lua
>>> is almost as fast as Julia which has JIT.
>> Not a surprise. :)
>>
>> Now, if it was truly the case that someone would need such an abmysal amount 
>> of number crunching
>> then speed becomes interesting. In such a case what I would do for any 
>> interpreted language, I would
>> use a compiled one.
>>
>> As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
>> interpreted languages
>> bite the dust. The question then would be whether to solve this particular 
>> problem in an interpreted
>> language at all.
>>
>> In the case of REXX-savvy programmers I would suggest to use NetRexx for 
>> this particular purpose:
>>
>> /* NetRexx: squares.nrx  */
>> options binary/* in this case we want speed */
>> items = 1000
>> s = long[items]   /* define a Java array of type long   */
>> loop i=1 to items
>>n=long i   /* for multiplication we want to use long */
>>s[i-1] = n * n
>> end
>> /* use a Java stream (introduced with Java 8)*/
>> say java.util.Arrays.stream(s).max.getAsLong
>>
>> You would compile that NetRexx program with "netrexxc squares.nrx" and run 
>> 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

Now, if you want ooRexx to control an application and need to run the NetRexx 
program from it, you
can do that with ooRexx (including timings) as such:

/* ooRexx solution to control execution of NetRexx' squares  */
clz=bsf.loadClass("squares")  /* load NetRexx' squares class */

/* create an empty Java array of type java.lang.String   */
arr=bsf.createJavaArrayOf("java.lang.String")

d1=.dateTime~new  /* take time   */
/* run main method which expects a Java String array */
clz~main(arr)
d2=.dateTime~new  /* take time   */
say "duration:" d2-d1

::requires "BSF.CLS" /* get full access to Java  */

The results of running this program are, believe it or not, even faster:

G:\tmp\ibmmain\arrays>rexx squares.rxj
100
duration: 00:00:00.095000

G:\tmp\ibmmain\arrays>rexx squares.rxj
100
duration: 00:00:00.109000

So the interpreted ooRexx can even beat ... :)

---rony


On 11.01.2022 12:21, Rony G. Flatscher wrote:
> On 11.01.2022 05:46, David Crayford wrote:
>> On 10/1/22 11:15 pm, Seymour J Metz wrote:
 ooRexx will never be high speed because it's implementation is
 fundamentally ineffecient.
>>> That seems to be begging the question. Certainly the current implementation 
>>> is inefficient, but
>>> what fundamental issue prevents a more efficient implementation?
>> A more effecient implementation requires a rewrite.
>>
>>> For that matter, what fundamental issue prevents compiling into Java 
>>> bytecode with a large
>>> runtime similar to the CREXX runtime?
>> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
>> strongly typed and the
>> JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
>> use Java classes so
>> there is a massive eco-system available.
> BTW, you could use Java classes from ooRexx as well, hence there is a 
> "massive eco-system available"
> for ooRexx. You would need the external function package named BSF4ooRexx, 
> which enables ooRexx to
> work with any Java class library, no matter whether it got created with Java, 
> NetRexx, Kotlin,
> Groovy, ...
>
>> I knocked up some simple benchtests which create an array of squares and 
>> then find the maximum
>> value. The maximum value is the end element. The results are just what I 
>> expected. ooRexx performs
>> poorly.
> Not a surprise. :)
>
> This "simple benchtest" is architected in a way that makes interpreted 
> languages look especially bad
> compared to compiled languages, it is of a form that is not relevant in real 
> life. Also, using
> unnecessarily numeric 30 digits for the arithmetics is interesting, as well 
> as the outdated, seven
> year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.
>
>
>> Stem variables are particularly bad which is to be expected because they are 
>> essentially
>> associative arrays. Using the Array class was much better but the result was 
>> still many orders of
>> magnitude worse then the
>> other languages I tested. What's interesting is that LuaJIT is as fast as 
>> C++ and interpreted Lua
>> is almost as fast as Julia which has JIT.
> Not a surprise. :)
>
> Now, if it was truly the case that someone would need such an abmysal amount 
> of number crunching
> then speed becomes interesting. In such a case what I would do for any 
> interpreted language, I would
> use a compiled one.
>
> As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
> interpreted languages
> bite the dust. The question then would be whether to solve this particular 
> problem in an interpreted
> language at all.
>
> In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
> particular purpose:
>
> /* NetRexx: squares.nrx  */
> options binary/* in this case we want speed */
> items = 1000
> s = long[items]   /* define a Java array of type long   */
> loop i=1 to items
>n=long i   /* for multiplication we want to use long */
>s[i-1] = n * n
> end
> /* use a Java stream (introduced with Java 8) */
> say java.util.Arrays.stream(s).max.getAsLong
>
> You would compile that NetRexx program with "netrexxc squares.nrx" and run 
> the resulting Java class
> with "java squares".
>
> To give you a feeling for the speed (you can test it right on your own 
> computer and compare with
> your other versions), here the timings of your c++ program (compiled with MS 
> cl) and this NetRexx
> program on my Windows 10 laptop (all in 32-bit mode):
>
>   * c++ (using MS compiler) out of the box:
> G:\tmp\ibmmain\arrays>timeit squares.exe
> *** ooRexx-Timeit:  command: squares.exe
>
> 100
> *** ended.
>
> *** command:  squares.exe
> *** started:  2022-01-11T11:19:55.506000
> *** ended:    2022-01-11T11:19:56.493000
>  duration: 00:00:00.987000*
>
>   

Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 11.01.2022 05:46, David Crayford wrote:
> On 10/1/22 11:15 pm, Seymour J Metz wrote:
>>> ooRexx will never be high speed because it's implementation is
>>> fundamentally ineffecient.
>> That seems to be begging the question. Certainly the current implementation 
>> is inefficient, but
>> what fundamental issue prevents a more efficient implementation?
>
> A more effecient implementation requires a rewrite.
>
>> For that matter, what fundamental issue prevents compiling into Java 
>> bytecode with a large
>> runtime similar to the CREXX runtime?
>
> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
> strongly typed and the
> JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
> use Java classes so
> there is a massive eco-system available.

BTW, you could use Java classes from ooRexx as well, hence there is a "massive 
eco-system available"
for ooRexx. You would need the external function package named BSF4ooRexx, 
which enables ooRexx to
work with any Java class library, no matter whether it got created with Java, 
NetRexx, Kotlin,
Groovy, ...

> I knocked up some simple benchtests which create an array of squares and then 
> find the maximum
> value. The maximum value is the end element. The results are just what I 
> expected. ooRexx performs
> poorly.

Not a surprise. :)

This "simple benchtest" is architected in a way that makes interpreted 
languages look especially bad
compared to compiled languages, it is of a form that is not relevant in real 
life. Also, using
unnecessarily numeric 30 digits for the arithmetics is interesting, as well as 
the outdated, seven
year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.


> Stem variables are particularly bad which is to be expected because they are 
> essentially
> associative arrays. Using the Array class was much better but the result was 
> still many orders of
> magnitude worse then the
> other languages I tested. What's interesting is that LuaJIT is as fast as C++ 
> and interpreted Lua
> is almost as fast as Julia which has JIT.

Not a surprise. :)

Now, if it was truly the case that someone would need such an abmysal amount of 
number crunching
then speed becomes interesting. In such a case what I would do for any 
interpreted language, I would
use a compiled one.

As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
interpreted languages
bite the dust. The question then would be whether to solve this particular 
problem in an interpreted
language at all.

In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
particular purpose:

/* NetRexx: squares.nrx  */
options binary/* in this case we want speed */
items = 1000
s = long[items]   /* define a Java array of type long   */
loop i=1 to items
   n=long i   /* for multiplication we want to use long */
   s[i-1] = n * n
end
/* use a Java stream (introduced with Java 8)   */
say java.util.Arrays.stream(s).max.getAsLong

You would compile that NetRexx program with "netrexxc squares.nrx" and run the 
resulting Java class
with "java squares".

To give you a feeling for the speed (you can test it right on your own computer 
and compare with
your other versions), here the timings of your c++ program (compiled with MS 
cl) and this NetRexx
program on my Windows 10 laptop (all in 32-bit mode):

  * c++ (using MS compiler) out of the box:
G:\tmp\ibmmain\arrays>timeit squares.exe
*** ooRexx-Timeit:  command: squares.exe

100
*** ended.

*** command:  squares.exe
*** started:  2022-01-11T11:19:55.506000
*** ended:    2022-01-11T11:19:56.493000
 duration: 00:00:00.987000*

  * NetRexx (Java 17) out of the box:

G:\tmp\ibmmain\arrays>timeit java squares
*** ooRexx-Timeit:  command: java squares

100
*** ended.

*** command:  java squares
*** started:  2022-01-11T12:09:51.849000
*** ended:    2022-01-11T12:09:52.134000
 duration: 00:00:00.285000*

As C++ on your machine was fastest of all compiled solutions, this may be quite 
surprising: NetRexx
can beat even C++! :)

Again: pick the language that meets the job at hand at best! Doing abmysal 
loopings, arrays, etc.
pick a compiled language, solving "bread-and-butter" problems use the language 
that allows you to
quickly create the program solution in a readable, maintable manner.

REXX programmers have good reasons why they use an interpreter for their 
problem solutions for
decades on mainframes.

And as can be seen, even such artificial samples constructed to make 
interpreters look bad, it is
not difficult for programmers with REXX knowledge to use NetRexx to solve 
problems that really would
need "hi speed".

Or with other words: whenever REXX programmers need functionality and speed on 
a mainframe they
resort to external native programs that they instrumentate. The same is 
possible with 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 11:28 pm, René Jansen wrote:

I find that a very interesting question - I think there is no real reason, and 
that is one of the things CREXX is trying to prove.


I've already said enough in this thread. CREXX looks interesting and 
fun. I'm happy to contribute.




For the other things, other mailing lists. But we have to remember that ooRexx 
is doing a lot of work like keeping activation records and doing garbage 
collection, which used to be essential but we decided are not really a priority 
now due to large addressing spaces (would take a century and a non-existing 
machine to page everything in though) and we know a lot more about optimization 
(inlining, avoiding pipeline stalls, keeping routines in cache) that are only 
valid for modern ISA implementations.

It turned out that you need to profile the heck out of everything before you 
commit it. We could not do that for ooRexx yet - that is a manpower issue (man 
includes man and women (I wish) here). I do wish that all the knowledge on this 
list could be transformed into one or two people more to work on things - it is 
clearly not IBM or companies that bought pieces of its history that we can 
count on here.

Best regards,

René.


On 10 Jan 2022, at 11:15, Rony  wrote:


Am 10.01.2022 um 15:34 schrieb David Crayford :

On 10/1/22 10:10 pm, Rony G. Flatscher wrote:

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation
and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

If it's not necessary then why did you make such a big deal about it?

Well if you have really read the entire post you should know. Without 
implementing the message
paradigm things become clumsy and some important features, if you need them, 
are simply not available.



I'm still completely baffled by the why not implementing the "message paradigm" is 
clumsy. Returning "self" from a method makes sense to me. What if I'm creating a class 
which supports method chaining
but some methods return values other than self. Nothing you are saying makes 
sense to me. It's dogma.

No, there is no dogma here, just a description that a mechanism is available in 
ooRexx by default that needs explicit programming in other languages which wish 
to be as fluent as ooRexx! ;)

Just try it out. Many times new concepts that look alien at first or even 
unnecessary become more understandable by experimenting itj. Given your 
background I am sure that you would grasp these concepts quite quickly. J

—-rony

Rony G. Flatscher (mobil/e)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu  with 
the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN