Auto: Re: GRS setup for MONOPLEX to SYSPLEX

2023-06-25 Thread Frederic Mancini
Je suis absent le 26 juin 2023.

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


Re: GRS setup for MONOPLEX to SYSPLEX

2023-06-25 Thread Brian Westerman
While my advice is not to do it at all, that doesn't meant hat it isn't 
possible without a plex, just that it's really (really) not a good idea.  I 
have been at sites that were okay with the exposure, and if you are really, 
really careful;, you will still occasionally have issues, but for the most 
part, unless you are really careless, you will likely be okay.  But it's so 
darn cheap to grab a couple ficon cards (even on ebay) and do it right.  

If the OP is correct that you can use the built-in IFB ports or some other 
internal connection, then that's worth giving it a try.  I am very interested 
to hear how it goes for them without using FICON, it could be very interesting.

Brian

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


Re: CMS-like 'xmitmsg' for Linux (or Unix or MacOS or even Windoze)

2023-06-25 Thread Rony G. Flatscher

Hi Rick,

On 31.05.2023 21:50, Rick Troth wrote:

This was also posted to the Linux/390 list and the VM list, but seemed relevant 
for here too.

Over the past several days, I "cut a release" (that's GitHub speak) of the xmitmsgX package. The 
package mimics the behavior of the CMS 'XMITMSG' command. This is release 2.1.3 of the project. 
The facility on CMS is what provides uniform messages (e.g., error messages, but more than just 
for errors). I was actually shocked to learn (several years ago) that MVS doesn't have the same 
thing. (Though BPXMTEXT is a rough approximation of a partial subset.)
Several have commented that they find it handy to have this function on POSIX and Unix-like 
systems, so here it is.


The wizard from Oz had turned the crank several weeks ago on USS and provided feedback. (We thank 
ye.) I have rolled that in but have not yet been able to re-test (since I do not have access to 
USS myself).


Those who know and love Rexx should take note that this release includes support for Regina. 
Similar support for ooRexx will come later if I can either get some help or wrap my limited gray 
matter around the ooRexx interface. (Kinda complicated for me.)


... cut ...

ooRexx has the Rexx/SAA interface such that it should be possible to use ooRexx 
for it as well.

More than ten years ago ooRexx 4.0 introduced an additional, powerful native API that is comparable 
to JNI (Java native interface) which allows exploiting the message paradigm introduced with ooRexx 
also from C, C++, but also directly interact e.g. with ooRexx arrays and much more, cool stuff.


If you have ooRexx installed there are samples that demonstrate how one would go about creating 
external Rexx function libraries, and in addition also external Rexx method libraries. Just look up 
"samples/api/classic" and "samples/api/c++" and the respective readme.txt files.


It is actually quite easy as you will see.

HTH,

---rony

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


Re: Are there samples of COBOL methods or classes?

2023-06-25 Thread Rony G. Flatscher
As the very first computer language I learned was COBOL, I have been always interested to learn 
about OO COBOL but never had the necessary time to research it.


Are there by any chance simple COBOL snippets that would demonstrate how to use OO COBOL to interact 
with Java (e.g. creating a Java object, invoking a simple method with arguments and fetch the 
returned value) and a comparable example for COBOL 6.4?


Maybe something like interacting with the Java runtime environment like this 
(in Java):

   import javax.script.*;

   class Test
   {
public static void main (String args[])
{
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEnginese  = sem.getEngineByName("rexx");
String code   = "say 'Hello world from Rexx!';\n return 43";
Object result = null;
try
{
result=se.eval(code);
}
catch (ScriptException sexc)
{
System.err.println("Oops, ScriptException occurred: "+sexc);
}
System.out.println("script's result: "+result);
System.exit(0);
}
   }

 The above program actually works if BSF4ooRexx is installed and yields:

   G:\tmp\bsf4oorexx\cobol>java Test
   REXXout>Hello world from Rexx!
   script's result: 43

The documentation of the Java scripting framework's javax.script package can be found here: 
 .


---

It would be really interesting to see how one would use OO COBOL and COBOL 6.4 to interact with the 
Java runtime environment and e.g. exploit the Java scripting framework.


---rony

P.S.: SOM has been a very interesting and exciting technology and I always have found it a little 
bit sad that it was abandoned. It was possible in the OS/2 days to subclass the WPS SOM folder class 
in Object REXX and add password access protection to it in about 15 lines of Object Rexx code, it 
was just great (and for many to this day unbelievable  how easy and how powerful that was).



On 29.05.2023 00:40, Tom Ross wrote:

Hi, While working on the earlier problems I had, I ran into the concepts=20
of COBOL Methods and Classes, and understand they can be used for Java=20
in addition to regular COBOL programs. The documentation does not=20
explain the "why" behind these or the "how" and "what", so I wonder if=20
anyone has any business case explanations of what these are or samples=20
of some COBOL-only implementations so I can see why I might want to use=20
them and how to do it?

I like to keep my COBOL current and if there is a way to use COBOL more=20
effectively, I hope you can help me understand this!


OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called.  Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs.  So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s).  OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming.  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!

Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4.  If you do not need to communicate with Java, I would not
recommend OO COBOL.  The promise of Object Oriented Programing in the 1990s
has not materialized.  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!  One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.

Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL.  OO COBOL
was not designed to be used in a pure COBOL application, so no examples of
that.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: GRS setup for MONOPLEX to SYSPLEX

2023-06-25 Thread Radoslaw Skorupka

Amen to that.
I used to share PDSE, but it was "last resort" and for single action.
IMHO the only way to safely share PDSE data is to IEBCOPY it to PDSU (PS 
file) and IEBCOPY to PDSE.

(context is cross-sysplex)


--
Radoslaw Skorupka
Lodz, Poland



W dniu 20.06.2023 o 14:24, Allan Staller pisze:

Classification: Confidential

Not my dog, but I would not do that, except under extreme duress.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Monday, June 19, 2023 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Even PDSE can be safely shared. If updates only occur from one LPAR and 
read-only everywhere else. And, said updates may not be reflected immediately 
(or until next IPL) in the other read-only LPARs

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Monday, June 19, 2023 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS setup for MONOPLEX to SYSPLEX

Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX.
Reason: PDSE use sysplex communication, not GRS facilities.

Regarding to the topic: in order to share datasets you need ...nothing.
No parallel sysplex
No base sysplex
Not even GRSplex
No SMSplex
Simply nothing except DASD available from several systems.
Of course, the more mentioned facilities you have the better sharing is.
And yes, in order to share PDSEs (properly) you still have sysplex.
However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc.
Note: there are various flavours of sharing. Shared DASD as a data transport 
method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, 
because it is not heavily used. Batch datasets - assuming proper batch windows 
it is also can be shared easily.
For frequent sharing it is good to think about ICF ECS or RLS, etc.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 19.06.2023 o 17:03, Michael Babcock pisze:

Beware of PDSEs.  I’m not 100% sure but I think the sandbox needs to
be in the plex to share them.  Updating a PDSE outside of the plex can
cause corruption.

We have our sandbox in the plex just to avoid issues.

On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky  wrote:


We have a sandbox system that references TSO user and ISV catalogs
and datasets. The sandbox has a unique master catalog but shares
virtually everything else.

It does have access to the couple facility that the Sysplex is using ...
But it is not a member of the Sysplex.

Is it possible for a monoplex z/OS system to share DASD, user cats,
etc., with a SYSPLEX via GRS management and coupling facility?


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