date:20180316


On 17/03/2018 9:27 AM, Bernd Oppolzer wrote:

The motivation for the RDz migration was:

a) some problems of isolation of source codes which have been
checked out from other developers (this has been fixed partially
in the meantime, and it can be fixed totally by moving all sources
to the DB2 repository and making the checkout datasets private
and protected)

b) the hope that younger developers can be moved to mainframe
development by a more "modern" IDE (but they aren't interested,
anyway ... they simply don't want to learn PL/1 and such things,
which they consider hard). 


We've been quite lucky that the young guys we've hired have been 
adaptable and pick up
the mainframe pretty quickly. One guy we interviewed thought ISPF was 
cool in a kind of retro way
like the old 8-bit games that are back in fashion. One thing they all 
universally detest is JCL. I suppose

if you come from a bash or powershell background it may seem a bit alien.

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On 16/03/2018 11:21 PM, Kirk Wolf wrote:

David and Jerry -

Curious, but have you guys tried the REST Api for z/OS Jobs?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_API_RESTJOBS.htm

That's an interesting idea. That might be a fun Node.JS project. I just
read the doc and the REST API looks cool. One thing I did notice is that
IBM use
their propriety LTPA tokens for authentication. Why didn't they use JSON
web tokens like everybody else?

This is what CICS explorer uses for jobs.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Co:Z SFTP also has complete JES support (using SSI 80; JES spool
dataset browse). wouldn't be too hard to roll your own client using your
favorite language and ssh/sftp library. A fancy UI could start displaying
spool files as they stream to make it snappier, although it would still
probably be tough to quite match the performance of SDSF just because how
low level it is.

On Fri, Mar 16, 2018 at 8:33 AM, David Crayford wrote:

Jerry,

I've found that the SDSF REXX API works well in USS and have written
several scripts to do useful stuff like bounce web server started tasks. We
use this from Atlassians Bamboo CI tooling to deploy web applications to
z/OS triggered from git merges in Bitbucket. Rockets git port has been a
game changer for us! If there was a curses library for REXX it would be
possible to write something similar to SDSF for the shell. There is also
the oeconsol command to execute MVS commands from the shell which is really
cool.

Like you I prefer to work in z/OS UNIX with all the code in the file
system. It's so much better than using data sets. We don't have Linux on Z
installed but do a lot of work on x86 Linux servers. You mentioned
hipersockets which is great for shuttling data around at high speeds for
JDBC and stuff in production systems but what other advantages does it
offer for development?

On 16/03/2018 8:21 PM, Jerry Callen wrote:

I'm going to be an EXTREME outlier here.

Background: I learned computing on OS/360 thru MVS, first using cards,
then TSO/ISPF. I jumped ship to Unix in the mid 80s and now I'm back on the
mainframe, doing ports of open source software to z/OS (under USS) at
Rocket Software.

I am logged into both USS (via ssh from PuTTY) and TSO/ISPF (via
BlueZone) from a Windows laptop all day long. If I had a decent tool for
accessing JES (there's no avoiding SDSF for the time being) from USS, I'd
NEVER be in TSO.

I use emacs as my development environment. I don't call it an "editor"
because it does so much more than edit text. In particular, the "shell
buffer" feature is indispensible; think of TSO session manager, but on
insane steroids. The USS port of emacs is ancient and creaky (though I
dearly hope we can remedy that within the next year), and I will grant that
emacs has a very stiff learning curve, but once you know it, it's
unbelievably productive.

For source control, I use the Rocket port of git. Essentially all of our
mainframe development is moving from other source control systems (SCLM,
cvs, svn) to git; there are good open source tools for converting from cvs
and svn that preserve all the history and branches.

For builds, I use whatever the open source project I'm currently working
on uses, which is generally some variation on automake/autoconf/configure/make.
The automake/autoconf situation on z/OS isn't yet what it wants to be. For
my own projects, I just use raw make. I often create make files that work
on both USS and Linux on Z (my go-to Unix when I need to use a tool not yet
on USS).

In short: I treat z/OS as a Unix box. Nearly all of the compilers (COBOL,
PL/I, C/C++, plus the assembler and binder) can be used from USS, on Unix
files (no need to move source, maclibs, include files, etc. into a PDS).
IBM has provided very good, albeit complex and tricky to use well,
ASCII/EBCDIC "bimodal" encoding support to ease the encoding problem. IBM
is actively porting newer languages (like JavaScript in node.js) to z/OS.

I can run TSO commands from the shell prompt (using, of course, the
"tsocmd" command...) when I need to. I keep building tools to help insulate
me from TSO and batch (like my SMP query interface at
https://github.com/zorts/smpapi), and of course Rocket continues to
release new and updated tools for free (though our bandwidth is
limited...). The big remaining hole is JES queue access. I can, of course,
submit jobs from USS, but getting the output in a nice, consumable manner
remains a challenge; hence, my TSO session.

We have a cadre of younger developers who follow a similar path, though
often using vim instead of emacs, and im some cases Windows-based editors
(Eclipse, Webstorm, SlickEdit, etc.) and FTP.

Bear in mind that my first "real" editor was ISPF, which I used for
years. Even with that history, I can't imagine using it for any serious
editing at this point.

Slight diversion: Linux on Z is a

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Bernd Oppolzer


Am 16.03.2018 um 15:20 schrieb David Crayford:

On 16/03/2018 5:16 PM, Itschak Mugzach wrote:

The purpose of RDZ was to save expensive TSO cycles and overhead.


That's interesting! RDz spawns a UNIX process for each connection and 
the server is written in Java which makes extensive JNI calls. I would 
suggest that RDz is significantly more expensive WRT CPU cycles than 
ISPF.


Same for us. When we were in the RDz migration project
(which was cancelled in the end), we sometimes had severe
LPAR CPU consumption issues during RDz builds ... with our
"old" TSO ISPF based system, we never had such issues.

The motivation for the RDz migration was:

a) some problems of isolation of source codes which have been
checked out from other developers (this has been fixed partially
in the meantime, and it can be fixed totally by moving all sources
to the DB2 repository and making the checkout datasets private
and protected)

b) the hope that younger developers can be moved to mainframe
development by a more "modern" IDE (but they aren't interested,
anyway ... they simply don't want to learn PL/1 and such things,
which they consider hard).

BTW: I don't use the ISPF editor for everyday's work; I have all
my projects in PC or server directories and do the editing there
using KEDIT or THE (the Hessling Editor), and I send the files to
the mainframe only for compilation. I have also all tools for
searching and comparing at hand that I need, in best quality.
This is the best environment I can imagine. For my private
Stanford Pascal compiler project I use a GitHub repository.
Many of my co-workers do the same. So for us there is no
need to have a more "modern" IDE. For me and my co-workers
it would have been a pain to be forced to use "RDz only",
especially if there are no powerful import facilities.

Kind regards

Bernd

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

Re: EXIT to control use of Class

2018-03-16 Thread zMan

Oh, if only class was so easily acquired! Think of the people we could
improve...

(sorry)

On Fri, Mar 16, 2018 at 4:00 PM, Carmen Vitullo  wrote:

> ok, I didn't think you could intergedate the JCL, and modify the JCL
> within one exit. very nice !
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Steely.Mark" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, March 16, 2018 2:53:39 PM
> Subject: Re: EXIT to control use of Class
>
> Here is the JES2 Exit 50 we used.
>
> If the ID is CA7ONL class U was forced.
>
> Thanks
>
> HASX50A TITLE 'USER EXIT 50 MODULE -- PROLOG (MODULE COMMENT BLOCK)'
> 0001
> ***
> 0014
> * * 0015
> * MODULE NAME = HASX50A (HASX50A load module) * 0016
> * * 0017
> * DESCRIPTIVE NAME = JOB STATEMENT SCAN * 0018
> * * 0019
> * STATUS = OS/VS2 - SEE $MODULE EXPANSION BELOW FOR FMID, VERSION *
> 0020
> * * 0021
> * FUNCTION = * 0022
> * * 0023
> * * 0023
> * * 0023
> * * 0023
> * * 0026
> * * 0042
> * REGISTER CONVENTIONS = SEE ENTRY POINT DOCUMENTATION * 0043
> * * 0044
> * PATCH LABEL = NONE * 0045
> * * 0046
> * MODULE TYPE = Procedure ( CSECT type ) * 0047
> * * 0048
> * PROCESSOR = IBM High Level Assembler/MVS 1.5.0 @Z07LASM 0049
> * * 0050
> * MODULE SIZE = SEE $MODEND MACRO EXPANSION AT END OF ASSEMBLY * 0051
> * * 0052
> * ATTRIBUTES = JES2 REENTRANT, RMODE ANY, AMODE 31 * 0053
> * Supervisor state, protect key of JES2's (1) * 0054
> * * 0055
> * ENTRY POINT = EXIT50A * 0056
> * * 0057
> * PURPOSE = SEE FUNCTION * 0058
> * * 0059
> * LINKAGE = STANDARD MVS LINKAGE * 0060
> * * 0061
> * EXIT-NORMAL = RETURN TO CALLER (HASPRDR) * 0062
> * * 0063
> * EXIT-ERROR = NONE * 0064
> * * 0065
> * EXTERNAL REFERENCES = SEE BELOW * 0066
> * * 0067
> * ROUTINES = MISCELLANEOUS JES2 SERVICE ROUTINES * 0068
> * * 0069
> * DATA AREAS = SEE $MODULE MACRO EXPANSION * 0070
> * * 0071
> * CONTROL BLOCKS = SEE $MODULE MACRO EXPANSION * 0072
> * * 0073
> * TABLES = SEE $MODULE MACRO DEFINITION (BELOW) * 0074
> * * 0075
> * MACROS = JES2 - $DOGBERT, $ENTRY, $JCTXGET, $MODEND, $MODULE, * 0076
> * $RETURN * 0077
> * * 0078
> * MACROS = MVS - none * 0079
> * * 0080
> * CHANGE ACTIVITY: * 0081
> * * 0082
> * $Z07LASM=NJETCP HJE7720 050203 CLW: HLASM 5.0 support * 0083
> * * 0084
> * A00-99 CREATED FOR JES2 z/OS 1.7 @Z07LTCP 0085
> ***
> 0086
> TITLE 'USER EXIT 50 MODULE -- PROLOG ($HASPGBL)' 0087
> COPY $HASPGBL COPY HASP GLOBALS 0088
> TITLE 'USER EXIT 50 MODULE -- PROLOG ($MODULE)' 0089
> ** 0090
> * Note that the environment for this module is * 0091
> * (USER,ANY). All routines compiled in this * 0092
> * environment require R11 to be the HCCT address, * 0093
> * and will use main task $SAVE/$RETURN services * 0094
> * when invoked from the main task, and special * 0095
> * USER environment $SAVE/RETURN services in other * 0096
> * run-time environments. * 0097
> * * 0098
> * This allows (with special code in $EXIT 20) the * 0099
> * same routine to be shared by both $EXIT 20 and * 0100
> * $EXIT 50. Note that while many services require * 0101
> * different linkage and parameters in different * 0102
> * run-time environments, this exit uses none of * 0103
> * those services. See HASX55A for an example of * 0104
> * how to implement environment-dependent services * 0105
> * from this type of exit. * 0106
> ** 0107
> EJECT , 0108
> HASX50A $MODULE ENVIRON=(USER,ANY), C0109
> RMODE=ANY, C0110
> IBMJES2=SAMPLE, C0111
> TITLE='USER EXIT 50 MODULE', C0112
> $BERT, Generate HASP BERT DSECT C0113
> $BERTTAB, Generate HASP BERTTAB DSECT C0114
> $BUFFER, GENERATE HASP BUFFER DSECT C0115
> $CADDR, GENERATE HASP CADDR DSECT C0116
> $CATBERT, Generate HASP CATBERT DSECT C0117
> $HASPEQU, GENERATE HASP EQU DSECT C0118
> $HCCT, Generate HASP HCCT DSECT C0119
> $HCT, GENERATE HASP HCT DSECT C0120
> $JCT, GENERATE HASP JCT DSECT C0121
> $JCTX, Generate HASP JCTX DSECT C0122
> $JQE, Generate HASP JQE DSECT C0123
> $MIT, GENERATE HASP MIT DSECT C0124
> $MITETBL, Generate HASP MTE dsect C0125
> $PADDR, GENERATE HASP PADDR DSECT C0126
> $PARMLST, GENERATE HASP PADDR DSECT C0127
> $PCE, GENERATE HASP PCE DSECT C0128
> $PSV, GENERATE HASP PSV DSECT C0129
> $TRE, Generate HASP TRE DSECT C0130
> $USERCBS, GENERATE HASP USERCBDS DSECT C0131
> $XECB, GENERATE HASP XECB DSECT C0132
>

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Tom Conley


On 3/16/2018 11:57 AM, John McKown wrote:


Yes, it has some nice facilities. But I cannot _easily_ invoke UNIX
commands from it, doing "UNIXy" things. And don't get me started on the
TSO OMVS command (which I despise mainly due to the limitations of TSO
3270).

Basically what I would like is to "invert" the "normal" process that I've
seen - that being when when someone uses the TSO OMVS command under ISPF to
do UNIX commands while staying in TSO. What I really want is to invoke ISPF
from a UNIX prompt, replacing the 3270 terminal interface with either a
"curses" (aka termcap) or a X11 terminal interface. Being able to do TSO
commands under UNIX ISPF would also be nice. REXX under UNIX has a nice
facility where it starts up a TSO address space when an ADDRESS TSO is
first used in a REXX program; said TSO address space continues until
explicitly shut down via a LOGOFF command or implicitly when the REXX
program ends.





Go to 3.17, Options, Directory List options, and put a slash in front of 
execute UNIX commnands from command line.  You now have a Unix shell. 
enter "/" on the command line to get a command entry panel like ISPF 
option 6 or SDSF.  Caveat, you need to use full Unix path for the filenames.


Regards,
Tom Conley

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

I was thinking of 3270 rather than LU1; the support is in TGET, TPG, TPUT and 
friends.

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

From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 16, 2018 2:57 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 1:44 PM, Seymour J Metz  wrote:

> The half-duplex use of the 3270 is an application, e.g., TMP,
> restriction:  the VTIOC macros support a full duplex mode.
>

Ah. Thanks. I don't know anything about VTIOC. I'll need to take a look at
it. ... A quick look at
https://secure-web.cisco.com/1z5XRgkDDuTEpEPDkgUreYQARmHY_2BS2--IP-SmbN-Pe9bAvPnoboO5f7Kzs1qge6_2C7hWyXvZyMI8vh5trY9zvw83LiEi4GTR-a9tF2HKQLnDRcOJ25Bta5UNaARDIBi1hrcvWWYJrFnaBdw3y-DzrStWJOrK09JCv3X0HU-KkMXSEYnfWYE992Fh5tUpj0OwSHNBRrkBStFVi9K_S-i232vpEl-nOikN8g1vjdUf_N3RvUt5Di-HOGLWk0WYGEkuzy4tgmbWE_aqJK96xL9mHOnRLN2o0A8x5zJsseAEY7oeIu3dr0qPQ235YPMbqjwKZqBuE_dJW15fcwBNav2fTOHs-Rw4-KPR08ncjgb24A1Ms5BvzJC8724Use24-aDnnH1hrxiQJnS1w3ni6FKxt2qLRwihkQRSO62LHZjLflxYbPZpFabvss7wzPZ2e/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.istimp0%2Fappend.htm
shows that TSO still support non-3270 VTAM terminals. It might be
interesting to write a "3767" emulator (hum, that may just be telnet) to
have a UNIX session "logon" to a 3767 TSO session. Hum, I need to think
about this a bit. Not that I'm likely to actually do anything. My interest
in z/OS, and computing in general, is tending downward for various reasons.

>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of John McKown 
> Sent: Friday, March 16, 2018 2:35 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell
>
> On Fri, Mar 16, 2018 at 1:29 PM, Seymour J Metz  wrote:
>
> > Don't confuse the limitations of the TSO VTIOC for 3270 with the
> > limitations of the application using them. The klunkiness of the OMVS
> > command is because they didn't choose to avail themselves of the
> available
> > services.
> >
>
> The only deficit that I see in the OMVS command is that it is what I think
> of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
> services when used when they are available. I've more or less gotten used
> to the "half duplex" use of the 3270 in TSO. What might be nice would be a
> way, in TSO, to "background" a TSO command like you can a UNIX command. Of
> course, I must remember that TSO was designed in the days of OS/MVT and is
> still more concerned with "resource consumption" rather that "user
> productivity".
>
>
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> 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
>

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
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: EXIT to control use of Class

ok, I didn't think you could intergedate the JCL, and modify the JCL within one 
exit. very nice ! 



Carmen Vitullo 

- Original Message -

From: "Steely.Mark"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 16, 2018 2:53:39 PM 
Subject: Re: EXIT to control use of Class 

Here is the JES2 Exit 50 we used. 

If the ID is CA7ONL class U was forced. 

Thanks 

HASX50A TITLE 'USER EXIT 50 MODULE -- PROLOG (MODULE COMMENT BLOCK)' 0001 
*** 
0014 
* * 0015 
* MODULE NAME = HASX50A (HASX50A load module) * 0016 
* * 0017 
* DESCRIPTIVE NAME = JOB STATEMENT SCAN * 0018 
* * 0019 
* STATUS = OS/VS2 - SEE $MODULE EXPANSION BELOW FOR FMID, VERSION * 0020 
* * 0021 
* FUNCTION = * 0022 
* * 0023 
* * 0023 
* * 0023 
* * 0023 
* * 0026 
* * 0042 
* REGISTER CONVENTIONS = SEE ENTRY POINT DOCUMENTATION * 0043 
* * 0044 
* PATCH LABEL = NONE * 0045 
* * 0046 
* MODULE TYPE = Procedure ( CSECT type ) * 0047 
* * 0048 
* PROCESSOR = IBM High Level Assembler/MVS 1.5.0 @Z07LASM 0049 
* * 0050 
* MODULE SIZE = SEE $MODEND MACRO EXPANSION AT END OF ASSEMBLY * 0051 
* * 0052 
* ATTRIBUTES = JES2 REENTRANT, RMODE ANY, AMODE 31 * 0053 
* Supervisor state, protect key of JES2's (1) * 0054 
* * 0055 
* ENTRY POINT = EXIT50A * 0056 
* * 0057 
* PURPOSE = SEE FUNCTION * 0058 
* * 0059 
* LINKAGE = STANDARD MVS LINKAGE * 0060 
* * 0061 
* EXIT-NORMAL = RETURN TO CALLER (HASPRDR) * 0062 
* * 0063 
* EXIT-ERROR = NONE * 0064 
* * 0065 
* EXTERNAL REFERENCES = SEE BELOW * 0066 
* * 0067 
* ROUTINES = MISCELLANEOUS JES2 SERVICE ROUTINES * 0068 
* * 0069 
* DATA AREAS = SEE $MODULE MACRO EXPANSION * 0070 
* * 0071 
* CONTROL BLOCKS = SEE $MODULE MACRO EXPANSION * 0072 
* * 0073 
* TABLES = SEE $MODULE MACRO DEFINITION (BELOW) * 0074 
* * 0075 
* MACROS = JES2 - $DOGBERT, $ENTRY, $JCTXGET, $MODEND, $MODULE, * 0076 
* $RETURN * 0077 
* * 0078 
* MACROS = MVS - none * 0079 
* * 0080 
* CHANGE ACTIVITY: * 0081 
* * 0082 
* $Z07LASM=NJETCP HJE7720 050203 CLW: HLASM 5.0 support * 0083 
* * 0084 
* A00-99 CREATED FOR JES2 z/OS 1.7 @Z07LTCP 0085 
*** 
0086 
TITLE 'USER EXIT 50 MODULE -- PROLOG ($HASPGBL)' 0087 
COPY $HASPGBL COPY HASP GLOBALS 0088 
TITLE 'USER EXIT 50 MODULE -- PROLOG ($MODULE)' 0089 
** 0090 
* Note that the environment for this module is * 0091 
* (USER,ANY). All routines compiled in this * 0092 
* environment require R11 to be the HCCT address, * 0093 
* and will use main task $SAVE/$RETURN services * 0094 
* when invoked from the main task, and special * 0095 
* USER environment $SAVE/RETURN services in other * 0096 
* run-time environments. * 0097 
* * 0098 
* This allows (with special code in $EXIT 20) the * 0099 
* same routine to be shared by both $EXIT 20 and * 0100 
* $EXIT 50. Note that while many services require * 0101 
* different linkage and parameters in different * 0102 
* run-time environments, this exit uses none of * 0103 
* those services. See HASX55A for an example of * 0104 
* how to implement environment-dependent services * 0105 
* from this type of exit. * 0106 
** 0107 
EJECT , 0108 
HASX50A $MODULE ENVIRON=(USER,ANY), C0109 
RMODE=ANY, C0110 
IBMJES2=SAMPLE, C0111 
TITLE='USER EXIT 50 MODULE', C0112 
$BERT, Generate HASP BERT DSECT C0113 
$BERTTAB, Generate HASP BERTTAB DSECT C0114 
$BUFFER, GENERATE HASP BUFFER DSECT C0115 
$CADDR, GENERATE HASP CADDR DSECT C0116 
$CATBERT, Generate HASP CATBERT DSECT C0117 
$HASPEQU, GENERATE HASP EQU DSECT C0118 
$HCCT, Generate HASP HCCT DSECT C0119 
$HCT, GENERATE HASP HCT DSECT C0120 
$JCT, GENERATE HASP JCT DSECT C0121 
$JCTX, Generate HASP JCTX DSECT C0122 
$JQE, Generate HASP JQE DSECT C0123 
$MIT, GENERATE HASP MIT DSECT C0124 
$MITETBL, Generate HASP MTE dsect C0125 
$PADDR, GENERATE HASP PADDR DSECT C0126 
$PARMLST, GENERATE HASP PADDR DSECT C0127 
$PCE, GENERATE HASP PCE DSECT C0128 
$PSV, GENERATE HASP PSV DSECT C0129 
$TRE, Generate HASP TRE DSECT C0130 
$USERCBS, GENERATE HASP USERCBDS DSECT C0131 
$XECB, GENERATE HASP XECB DSECT C0132 
$XIT, Generate HASP XIT DSECT C0133 
$XPL Generate HASP XPL DSECT 0134 
TITLE 'USER EXIT 50 MODULE -- JOB STATEMENT SCAN' 0135 
*** 
0136 
* * 0137 
* EXIT50 - INSTALLATION EXIT 50 ROUTINE * 0138 
* * 0139 
*

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The VTIOC macros are the same as the old TIOC macros, with some extensions 
.

Macros like TGET, TPUT, TPG used to be in a manual called Guide to Writing a 
Terminal Monitor Program or a Command Processor; I don't recall the current 
title.




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


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Friday, March 16, 2018 3:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

PMFJI here, but you piqued my curiosity - What exactly are these VTIOC macros, 
and where would one find them?  Or are you talking about the normal VTAM SEND 
and RECEIVE processes?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Friday, March 16, 2018 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The half-duplex use of the 3270 is an application, e.g., TMP, restriction:  the 
VTIOC macros support a full duplex mode.

--

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

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

Re: EXIT to control use of Class

2018-03-16 Thread Steely.Mark

Here is the JES2 Exit 50 we used.  

If the ID is CA7ONL class U was forced. 

Thanks

HASX50A  TITLE 'USER EXIT 50 MODULE -- PROLOG (MODULE COMMENT BLOCK)'   0001
*** 0014
* * 0015
* MODULE NAME = HASX50A  (HASX50A load module)* 0016
* * 0017
* DESCRIPTIVE NAME = JOB STATEMENT SCAN   * 0018
* * 0019
* STATUS = OS/VS2 - SEE $MODULE EXPANSION BELOW FOR FMID, VERSION * 0020
* * 0021
* FUNCTION =  * 0022
* * 0023
* * 0023
* * 0023
* * 0023
* * 0026
* * 0042
*REGISTER CONVENTIONS = SEE ENTRY POINT DOCUMENTATION * 0043
* * 0044
*PATCH LABEL = NONE   * 0045
* * 0046
* MODULE TYPE = Procedure ( CSECT type )  * 0047
* * 0048
*PROCESSOR = IBM High Level Assembler/MVS 1.5.0@Z07LASM 0049
* * 0050
*MODULE SIZE = SEE $MODEND MACRO EXPANSION AT END OF ASSEMBLY * 0051
* * 0052
*ATTRIBUTES = JES2 REENTRANT, RMODE ANY, AMODE 31 * 0053
* Supervisor state, protect key of JES2's (1) * 0054
* * 0055
* ENTRY POINT = EXIT50A   * 0056
* * 0057
*PURPOSE = SEE FUNCTION   * 0058
* * 0059
*LINKAGE = STANDARD MVS LINKAGE   * 0060
* * 0061
* EXIT-NORMAL = RETURN TO CALLER (HASPRDR)* 0062
* * 0063
* EXIT-ERROR = NONE   * 0064
* * 0065
* EXTERNAL REFERENCES = SEE BELOW * 0066
* * 0067
*ROUTINES = MISCELLANEOUS JES2 SERVICE ROUTINES   * 0068
* * 0069
*DATA AREAS = SEE $MODULE MACRO EXPANSION * 0070
* * 0071
*CONTROL BLOCKS = SEE $MODULE MACRO EXPANSION * 0072
* * 0073
* TABLES = SEE $MODULE MACRO DEFINITION (BELOW)   * 0074
* * 0075
* MACROS = JES2 - $DOGBERT, $ENTRY, $JCTXGET, $MODEND, $MODULE,   * 0076
* $RETURN * 0077
* * 0078
* MACROS = MVS  - none* 0079
* * 0080
* CHANGE ACTIVITY:* 0081
* * 0082
* $Z07LASM=NJETCP   HJE7720 050203 CLW:  HLASM 5.0 support* 0083
* * 0084
* A00-99CREATED FOR JES2 z/OS 1.7  @Z07LTCP 0085
*** 0086
 TITLE 'USER EXIT 50 MODULE -- PROLOG

Re: TSO authorized concurrent integrity [was: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell]

2018-03-16 Thread Farley, Peter x23353

I do not understand -- How can a second authorized program running concurrently 
to an already-running authorized program provide opportunity for an integrity 
threat?  Or am I just not clever (or evil) enough to conceive of a way to 
violate integrity in such a scenario?  Don't all the normal authorized 
integrity rules and fences still hold for concurrent programs?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, March 16, 2018 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, 16 Mar 2018 13:35:40 -0500, John McKown wrote:
>
>The only deficit that I see in the OMVS command is that it is what I think
>of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
>services when used when they are available. I've more or less gotten used
>to the "half duplex" use of the 3270 in TSO. What might be nice would be a
>way, in TSO, to "background" a TSO command like you can a UNIX command. Of
>course, I must remember that TSO was designed in the days of OS/MVT and is
>still more concerned with "resource consumption" rather that "user
>productivity".
> 
TSO's single address space design invites integrity threats if authorized 
programs
run concurrently.  Would you propose forking background programs into separate
address spaces?  Would BPX1EXM be a solution?

--

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: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Farley, Peter x23353

PMFJI here, but you piqued my curiosity - What exactly are these VTIOC macros, 
and where would one find them?  Or are you talking about the normal VTAM SEND 
and RECEIVE processes?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Friday, March 16, 2018 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The half-duplex use of the 3270 is an application, e.g., TMP, restriction:  the 
VTIOC macros support a full duplex mode.

--

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: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Paul Gilmartin

On Fri, 16 Mar 2018 13:35:40 -0500, John McKown wrote:
>
>The only deficit that I see in the OMVS command is that it is what I think
>of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
>services when used when they are available. I've more or less gotten used
>to the "half duplex" use of the 3270 in TSO. What might be nice would be a
>way, in TSO, to "background" a TSO command like you can a UNIX command. Of
>course, I must remember that TSO was designed in the days of OS/MVT and is
>still more concerned with "resource consumption" rather that "user
>productivity".
> 
TSO's single address space design invites integrity threats if authorized 
programs
run concurrently.  Would you propose forking background programs into separate
address spaces?  Would BPX1EXM be a solution?

-- gil

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 1:44 PM, Seymour J Metz  wrote:

> The half-duplex use of the 3270 is an application, e.g., TMP,
> restriction:  the VTIOC macros support a full duplex mode.
>

Ah. Thanks. I don't know anything about VTIOC. I'll need to take a look at
it. ... A quick look at
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.istimp0/append.htm
shows that TSO still support non-3270 VTAM terminals. It might be
interesting to write a "3767" emulator (hum, that may just be telnet) to
have a UNIX session "logon" to a 3767 TSO session. Hum, I need to think
about this a bit. Not that I'm likely to actually do anything. My interest
in z/OS, and computing in general, is tending downward for various reasons.



>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of John McKown 
> Sent: Friday, March 16, 2018 2:35 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell
>
> On Fri, Mar 16, 2018 at 1:29 PM, Seymour J Metz  wrote:
>
> > Don't confuse the limitations of the TSO VTIOC for 3270 with the
> > limitations of the application using them. The klunkiness of the OMVS
> > command is because they didn't choose to avail themselves of the
> available
> > services.
> >
>
> The only deficit that I see in the OMVS command is that it is what I think
> of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
> services when used when they are available. I've more or less gotten used
> to the "half duplex" use of the 3270 in TSO. What might be nice would be a
> way, in TSO, to "background" a TSO command like you can a UNIX command. Of
> course, I must remember that TSO was designed in the days of OS/MVT and is
> still more concerned with "resource consumption" rather that "user
> productivity".
>
>
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

The half-duplex use of the 3270 is an application, e.g., TMP, restriction:  the 
VTIOC macros support a full duplex mode.

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

From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 16, 2018 2:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 1:29 PM, Seymour J Metz  wrote:

> Don't confuse the limitations of the TSO VTIOC for 3270 with the
> limitations of the application using them. The klunkiness of the OMVS
> command is because they didn't choose to avail themselves of the available
> services.
>

The only deficit that I see in the OMVS command is that it is what I think
of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
services when used when they are available. I've more or less gotten used
to the "half duplex" use of the 3270 in TSO. What might be nice would be a
way, in TSO, to "background" a TSO command like you can a UNIX command. Of
course, I must remember that TSO was designed in the days of OS/MVT and is
still more concerned with "resource consumption" rather that "user
productivity".

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

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
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: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 1:29 PM, Seymour J Metz  wrote:

> Don't confuse the limitations of the TSO VTIOC for 3270 with the
> limitations of the application using them. The klunkiness of the OMVS
> command is because they didn't choose to avail themselves of the available
> services.
>

The only deficit that I see in the OMVS command is that it is what I think
of as "native" TSO 3270 whereas it should be, like SDSF, use ISPF display
services when used when they are available. I've more or less gotten used
to the "half duplex" use of the 3270 in TSO. What might be nice would be a
way, in TSO, to "background" a TSO command like you can a UNIX command. Of
course, I must remember that TSO was designed in the days of OS/MVT and is
still more concerned with "resource consumption" rather that "user
productivity".

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

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: EXIT to control use of Class

2018-03-16 Thread Pew, Curtis G

On Mar 16, 2018, at 12:50 PM, John McKown  wrote:
> 
> IMO, the simplest would be JES2 exit 20. In this exit, you can override
> the CLASS specified by simply putting the class desired into the JCTJCLAS.
> We use it to "disable" the use of PRTY by setting the JCTJPRTY value to "9".

It would be a little more difficult, but you could also use IEFUJV to override 
the JCL before conversion. That would require some minimal parsing of the JOB 
statement to find the CLASS parameter.

You could also be really hard-nosed, and use IEFUJI to cancel the job if it 
isn’t in the desired class.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

Don't confuse the limitations of the TSO VTIOC for 3270 with the limitations of 
the application using them. The klunkiness of the OMVS command is because they 
didn't choose to avail themselves of the available services.

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

From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 16, 2018 11:58 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 10:36 AM, Nightwatch RenBand <
johnmattson...@gmail.com> wrote:

> John, you may already know this, but if you do "TSO ISHELL"  you can then d
> B Browse or E Edit on a OMVS file and you have most, perhaps all I haven't
> checked everything, that ISPF editor can do.  Try it
>
>
Yes, it has some nice facilities. But I cannot _easily_ invoke UNIX
commands from it, doing "UNIXy" things. And don't get me started on the
TSO OMVS command (which I despise mainly due to the limitations of TSO
3270).

Basically what I would like is to "invert" the "normal" process that I've
seen - that being when when someone uses the TSO OMVS command under ISPF to
do UNIX commands while staying in TSO. What I really want is to invoke ISPF
from a UNIX prompt, replacing the 3270 terminal interface with either a
"curses" (aka termcap) or a X11 terminal interface. Being able to do TSO
commands under UNIX ISPF would also be nice. REXX under UNIX has a nice
facility where it starts up a TSO address space when an ADDRESS TSO is
first used in a REXX program; said TSO address space continues until
explicitly shut down via a LOGOFF command or implicitly when the REXX
program ends.

--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
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: EXIT to control use of Class

On Fri, Mar 16, 2018 at 12:39 PM, Peter  wrote:

> Hi
>
> Is there an EXIT which can assign CLASS to the users based on RACF ID ? For
> example even if a user tries to use CLASS C the user Job must run only
> using CLASS A.
>
> This is for our training LPAR and I would like to implement this feature.
>
> We are at zOS1.13
>

IMO, the simplest would be JES2 exit 20. In this exit, you can override
the CLASS specified by simply putting the class desired into the JCTJCLAS.
We use it to "disable" the use of PRTY by setting the JCTJPRTY value to "9".

ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hasc100/endoinpt.htm




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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: EXIT to control use of Class

Peter, you'd need multiple JES2 exit to do what you want, off the top of my 
head I'm thinking 
Exit 6  Converter/Interpreter Text Scan Exit 36 Pre-security Authorization Call 
and possibly 
Exit 54 JCL and JES2 Control Statement Scan (JES2 User Environment) 


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae400/jes2.htm
 




or a product like thruput manager 




Carmen Vitullo 

- Original Message -

From: "Peter"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 16, 2018 12:39:53 PM 
Subject: EXIT to control use of Class 

Hi 

Is there an EXIT which can assign CLASS to the users based on RACF ID ? For 
example even if a user tries to use CLASS C the user Job must run only 
using CLASS A. 

This is for our training LPAR and I would like to implement this feature. 

We are at zOS1.13 

Regards 
Peter 

-- 
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

EXIT to control use of Class

2018-03-16 Thread Peter

Hi

Is there an EXIT which can assign CLASS to the users based on RACF ID ? For
example even if a user tries to use CLASS C the user Job must run only
using CLASS A.

This is for our training LPAR and I would like to implement this feature.

We are at zOS1.13

Regards
Peter

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

Re: ISPF packed member question

2018-03-16 Thread Pommier, Rex

Mr. Kolusu,

Thisisawesome!!   It does exactly what I need.  

Thank you, sir!!!

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Friday, March 16, 2018 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF packed member question

Pommier Rex,

Here are a couple of old discussion that use REXX exec to find all the
Packed members

https://groups.google.com/forum/#!topic/bit.listserv.ispf-l/5Axnxbd7rok

https://groups.google.com/forum/#!topic/bit.listserv.ispf-l/LM185_oMtS8

However if your shop has FILE MANAGER , here is a sample that will list all
the members that are packed with a message in the SYSPRINT "data is ISPF
packed, skipping. "  and 2 lines above is the member name that is packed.
We can extract these 3 lines using DFSORT. Let me know if you are
interested.

//STEP0100 EXEC PGM=FILEMGR
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=your pds/pdse name
//SYSINDD *
$$FILEM DSP INPUT=PDS,
$$FILEM PACK=SKIP,
$$FILEM NLRECS=1
//*

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on
03/16/2018 06:47:35 AM:

> From: "Pommier, Rex" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/16/2018 06:49 AM
> Subject: ISPF packed member question
> Sent by: IBM Mainframe Discussion List 
>
> Hi list,
>
> I have what is hopefully an easy question that I just am looking in
> the wrong place.  Given a PDS of source or JCL, is there a quick,
> "easy" way of finding any/all the packed members within the PDS?
>
> Thanks,
>
> Rex

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: USS assembler program and envars

2018-03-16 Thread Paul Gilmartin

On Mon, 12 Mar 2018 16:55:09 -0500, Kirk Wolf wrote:
>
>This is kind of a hack, but you could spawn /bin/env with no arguments and
>redirect the output to an anonymous pipe and then read that into a buffer.
>The output with be  a repeated stream of "KEY=VALUE\n"
> 
But be careful.  If a programmer has been mischievous enough to do such as:
wombat="xyzzy
foo=bar" export wombat

env will show:
...
wombat=xyzzy
foo=bar


Better:
sh -c "export -p"
...
export wombat='xyzzy
foo=bar'
...
which is parseable.

-- gil

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

Re: ISPF packed member question

2018-03-16 Thread Sri h Kolusu

Pommier Rex,

Here are a couple of old discussion that use REXX exec to find all the
Packed members

https://groups.google.com/forum/#!topic/bit.listserv.ispf-l/5Axnxbd7rok

https://groups.google.com/forum/#!topic/bit.listserv.ispf-l/LM185_oMtS8

However if your shop has FILE MANAGER , here is a sample that will list all
the members that are packed with a message in the SYSPRINT "data is ISPF
packed, skipping. "  and 2 lines above is the member name that is packed.
We can extract these 3 lines using DFSORT. Let me know if you are
interested.

//STEP0100 EXEC PGM=FILEMGR
//SYSPRINT DD SYSOUT=*
//PDS  DD DISP=SHR,DSN=your pds/pdse name
//SYSINDD *
$$FILEM DSP INPUT=PDS,
$$FILEM PACK=SKIP,
$$FILEM NLRECS=1
//*

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on
03/16/2018 06:47:35 AM:

> From: "Pommier, Rex" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/16/2018 06:49 AM
> Subject: ISPF packed member question
> Sent by: IBM Mainframe Discussion List 
>
> Hi list,
>
> I have what is hopefully an easy question that I just am looking in
> the wrong place.  Given a PDS of source or JCL, is there a quick,
> "easy" way of finding any/all the packed members within the PDS?
>
> Thanks,
>
> Rex

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Jerry Whitteridge

I do the same - ISPF sessions for ISPF and Putty or Konsole sessions for
Omvs

Jerry Whitteridge
Delivery Manager - Safeway
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
03/16/2018 09:35:37 AM:

> From: John McKown 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/16/2018 09:36 AM
> Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell
> Sent by: IBM Mainframe Discussion List 
>
> On Fri, Mar 16, 2018 at 11:26 AM, Jerry Whitteridge <
> jerry.whitteri...@ibm.com> wrote:
>
> > I believe he means from inside of OMVS you can issue "tso ISHELL" and
get
> > to the ISHELL menus.
> >
>
> Interesting thought. I don't usually use TSO OMVS. I find it easier, for
> me, to have TSO ISPF going normally and then get to a UNIX prompt via
ssh.
> This works OK for me, so I guess I should stop wishing for ISPF under
UNIX.
>
>
>

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 11:26 AM, Jerry Whitteridge <
jerry.whitteri...@ibm.com> wrote:

> I believe he means from inside of OMVS you can issue "tso ISHELL" and get
> to the ISHELL menus.
>

Interesting thought. I don't usually use TSO OMVS. I find it easier, for
me, to have TSO ISPF going normally and then get to a UNIX prompt via ssh.
This works OK for me, so I guess I should stop wishing for ISPF under UNIX.



>
> This only works from a 3270 initiated OMVS session and not a ssh login via
> putty or similar.
>
> Jerry Whitteridge
> Delivery Manager - Safeway
> 602 527 4871 Mobile
> jerry.whitteri...@ibm.com
>
> IBM Services
>
> IBM Mainframe Discussion List  wrote on
> 03/16/2018 08:58:37 AM:
>


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Jerry Whitteridge

I believe he means from inside of OMVS you can issue "tso ISHELL" and get
to the ISHELL menus.

This only works from a 3270 initiated OMVS session and not a ssh login via
putty or similar.

Jerry Whitteridge
Delivery Manager - Safeway
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
03/16/2018 08:58:37 AM:

> From: John McKown 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/16/2018 08:58 AM
> Subject: Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell
> Sent by: IBM Mainframe Discussion List 
>
> On Fri, Mar 16, 2018 at 10:36 AM, Nightwatch RenBand <
> johnmattson...@gmail.com> wrote:
>
> > John, you may already know this, but if you do "TSO ISHELL"  you can
then d
> > B Browse or E Edit on a OMVS file and you have most, perhaps all I
haven't
> > checked everything, that ISPF editor can do.  Try it
> >
> >
> Yes, it has some nice facilities. But I cannot _easily_ invoke UNIX
> commands from it, doing "UNIXy" things. And don't get me started on the
> TSO OMVS command (which I despise mainly due to the limitations of TSO
> 3270).
>
> Basically what I would like is to "invert" the "normal" process that I've
> seen - that being when when someone uses the TSO OMVS command under ISPF
to
> do UNIX commands while staying in TSO. What I really want is to invoke
ISPF
> from a UNIX prompt, replacing the 3270 terminal interface with either a
> "curses" (aka termcap) or a X11 terminal interface. Being able to do TSO
> commands under UNIX ISPF would also be nice. REXX under UNIX has a nice
> facility where it starts up a TSO address space when an ADDRESS TSO is
> first used in a REXX program; said TSO address space continues until
> explicitly shut down via a LOGOFF command or implicitly when the REXX
> program ends.
>
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> 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: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

On Fri, Mar 16, 2018 at 10:36 AM, Nightwatch RenBand <
johnmattson...@gmail.com> wrote:

> John, you may already know this, but if you do "TSO ISHELL"  you can then d
> B Browse or E Edit on a OMVS file and you have most, perhaps all I haven't
> checked everything, that ISPF editor can do.  Try it
>
>
Yes, it has some nice facilities. But I cannot _easily_ invoke UNIX
commands from it, doing "UNIXy" things. And don't get me started on the
TSO OMVS command (which I despise mainly due to the limitations of TSO
3270).

Basically what I would like is to "invert" the "normal" process that I've
seen - that being when when someone uses the TSO OMVS command under ISPF to
do UNIX commands while staying in TSO. What I really want is to invoke ISPF
from a UNIX prompt, replacing the 3270 terminal interface with either a
"curses" (aka termcap) or a X11 terminal interface. Being able to do TSO
commands under UNIX ISPF would also be nice. REXX under UNIX has a nice
facility where it starts up a TSO address space when an ADDRESS TSO is
first used in a REXX program; said TSO address space continues until
explicitly shut down via a LOGOFF command or implicitly when the REXX
program ends.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Nightwatch RenBand

John, you may already know this, but if you do "TSO ISHELL"  you can then d
B Browse or E Edit on a OMVS file and you have most, perhaps all I haven't
checked everything, that ISPF editor can do.  Try it

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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

2018-03-16 Thread Kirk Wolf

David and Jerry -

Curious, but  have you guys tried the REST Api for z/OS Jobs?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.izua700/IZUHPINFO_API_RESTJOBS.htm


This is what CICS explorer uses for jobs.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Co:Z SFTP also has complete JES support (using SSI 80; JES spool
dataset browse).  wouldn't be too hard to roll your own client using your
favorite language and ssh/sftp library.   A fancy UI could start displaying
spool files as they stream to make it snappier, although it would still
probably be tough to quite match the performance of SDSF just because how
low level it is.



On Fri, Mar 16, 2018 at 8:33 AM, David Crayford  wrote:

> Jerry,
>
> I've found that the SDSF REXX API works well in USS and have written
> several scripts to do useful stuff like bounce web server started tasks. We
> use this from Atlassians Bamboo CI tooling to deploy web applications to
> z/OS triggered from git merges in Bitbucket. Rockets git port has been a
> game changer for us! If there was a curses library for REXX it would be
> possible to write something similar to SDSF for the shell. There is also
> the oeconsol command to execute MVS commands from the shell which is really
> cool.
>
> Like you I prefer to work in z/OS UNIX with all the  code in the file
> system. It's so much better than using data sets. We don't have Linux on Z
> installed but do a lot of work on  x86 Linux servers. You mentioned
> hipersockets which is great for shuttling data around at high speeds for
> JDBC and stuff in production systems but what other advantages does it
> offer for development?
>
>
>
> On 16/03/2018 8:21 PM, Jerry Callen wrote:
>
>> I'm going to be an EXTREME outlier here.
>>
>> Background: I learned computing on OS/360 thru MVS, first using cards,
>> then TSO/ISPF. I jumped ship to Unix in the mid 80s and now I'm back on the
>> mainframe, doing ports of open source software to z/OS (under USS) at
>> Rocket Software.
>>
>> I am logged into both USS (via ssh from PuTTY) and TSO/ISPF (via
>> BlueZone) from a Windows laptop all day long. If I had a decent tool for
>> accessing JES (there's no avoiding SDSF for the time being) from USS, I'd
>> NEVER be in TSO.
>>
>> I use emacs as my development environment. I don't call it an "editor"
>> because it does so much more than edit text. In particular, the "shell
>> buffer" feature is indispensible; think of TSO session manager, but on
>> insane steroids. The USS port of emacs is ancient and creaky (though I
>> dearly hope we can remedy that within the next year), and I will grant that
>> emacs has a very stiff learning curve, but once you know it, it's
>> unbelievably productive.
>>
>> For source control, I use the Rocket port of git. Essentially all of our
>> mainframe development is moving from other source control systems (SCLM,
>> cvs, svn) to git; there are good open source tools for converting from cvs
>> and svn that preserve all the history and branches.
>>
>> For builds, I use whatever the open source project I'm currently working
>> on uses, which is generally some variation on 
>> automake/autoconf/configure/make.
>> The automake/autoconf situation on z/OS isn't yet what it wants to be. For
>> my own projects, I just use raw make. I often create make files that work
>> on both USS and Linux on Z (my go-to Unix when I need to use a tool not yet
>> on USS).
>>
>> In short: I treat z/OS as a Unix box. Nearly all of the compilers (COBOL,
>> PL/I, C/C++, plus the assembler and binder) can be used from USS, on Unix
>> files (no need to move source, maclibs, include files, etc. into a PDS).
>> IBM has provided very good, albeit complex and tricky to use well,
>> ASCII/EBCDIC "bimodal" encoding support to ease the encoding problem. IBM
>> is actively porting newer languages (like JavaScript in node.js) to z/OS.
>>
>> I can run TSO commands from the shell prompt (using, of course, the
>> "tsocmd" command...) when I need to. I keep building tools to help insulate
>> me from TSO and batch (like my SMP query interface at
>> https://github.com/zorts/smpapi), and of course Rocket continues to
>> release new and updated tools for free (though our bandwidth is
>> limited...). The big remaining hole is JES queue access. I can, of course,
>> submit jobs from USS, but getting the output in a nice, consumable manner
>> remains a challenge; hence, my TSO session.
>>
>> We have a cadre of younger developers who follow a similar path, though
>> often using vim instead of emacs, and im some cases Windows-based editors
>> (Eclipse, Webstorm, SlickEdit, etc.) and FTP.
>>
>> Bear in mind that my first "real" editor was ISPF, which I used for
>> years. Even with that history, I can't imagine using it for any serious
>> editing at this point.
>>
>> Slight diversion: Linux on Z is a VERY nice platform. I have rarely
>> encountered any problems porting x86 Unix code to Linux on Z, and usually

Re: ISPF packed member question

On Fri, Mar 16, 2018 at 8:47 AM, Pommier, Rex 
wrote:

> Hi list,
>
> I have what is hopefully an easy question that I just am looking in the
> wrong place.  Given a PDS of source or JCL, is there a quick, "easy" way of
> finding any/all the packed members within the PDS?
>

"easy"? I don't think so. There is not anything in the PDS directory entry
to indicate PACK ON or OFF. You must read the first record of the member.
If it starts with the "magic word" of X'000140C6', then it is packed with
Fixed length records. If it starts with the "magic word" of X'000140E5'
then it is packed with Variable length records. Or maybe just check for the
first 3 bytes being X'000140'. Wish that I could find the book where this
is documented. I think that I read it, long ago, in an ISPF manual.

>
> Thanks,
>
> Rex
>
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is
> not the intended recipient or an employee or agent responsible for
> delivering this message to the intended recipient, you are hereby notified
> that any disclosure, distribution, copying, or any action taken or action
> omitted in reliance on it, is strictly prohibited and may be unlawful.  If
> you have received this communication in error, please notify us immediately
> by replying to this message and destroy the material in its entirety,
> whether in electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: ISPF packed member question

2018-03-16 Thread Pommier, Rex

The problem is I don't know which ones (if any) are packed.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Wilkie
Sent: Friday, March 16, 2018 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF packed member question

If you know what you are searching for, you can enter the name of the PDS in 
the 3.4 screen. When you see the member list enter SRCHFOR on the command line 
and all members that contain that search string will be highlighted.

For example if you are looking for the name BILL in all members   SRCHFOR  BILL

HTH

Bill

From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Sent: Friday, March 16, 2018 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF packed member question

Hi list,

I have what is hopefully an easy question that I just am looking in the wrong 
place.  Given a PDS of source or JCL, is there a quick, "easy" way of finding 
any/all the packed members within the PDS?

Thanks,

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

--
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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: AW: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell


On 16/03/2018 5:16 PM, Itschak Mugzach wrote:

The purpose of RDZ was to save expensive  TSO cycles and overhead.


That's interesting! RDz spawns a UNIX process for each connection and 
the server is written in Java which makes extensive JNI calls. I would 
suggest that RDz is significantly more expensive WRT CPU cycles than ISPF.



It look like that the problem the op looks for is end user experience.
As per rdz, most clients are not aware that every dataset/table they view is 
saved in their workspace directory. Btw was even more danger as it allows the 
end user to connect to any ip and gain other user authority.


ITschak
נשלח מה-iPad שלי

‫ב-16 במרץ 2018, בשעה 10:13, ‏‏Peter Hunkeler ‏ כתב/ה:‬


 (or is it "Rational Developer"? - what about the irrational

developers, what do they use? :-})


It is now more for the latter: IBM has rebranded RDz to IDz


--
Peter Hunkeler



--
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

Re: how do you handle shared ZFS in a sysplex

Thanks David that makes sense, and that's what I'm leaning towards. I had to 
make some concessions with some products, I was forced to create a symlink on 
the sysplex root because of how the users accessed some ISV products, so my 
symlink to a system specific filesystem for example '/web' links to 
/$SYSTEM/local/web so it removed this issues I'm was having with /usr/lpp (that 
was the old mount point) 
So, if I understand correctly you create a symlink for an ISV filesystem 
pointing to /$SYSTEM/usr/lpp ? 




something like 


ln -s /$SYSTEM/usr/lpp/RTCHIN /RTCHIN 


this would help if this works correctly... 
It's been hard to convince the team to allow me to remove the system specific 
filesystem that are identical and create one PLEX wide filesystem mounted @ 
//usr/lpp 
I think that would help greatly. 




my current structure. 



rwxrwxrwx 1 CPV8281 OMVSGRP 20 Mar 11 21:02 abinitio -> /SYSA/local/a binitio 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 bin -> $VERSION/bin 
rwxrwxrwx 1 CPV8281 OMVSGRP 9 Nov 14 10:33 cai -> /SYST/cai 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 dev -> $SYSNAME/dev 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 etc -> $SYSNAME/etc 
rwxrwxrwx 1 CPV8281 OMVSGRP 21 Mar 11 10:42 ftp -> /PLEX1/usr/local/ tp/ 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 lib -> $VERSION/lib 
rwxrwxrwx 1 CPV8281 OMVSGRP 21 Mar 13 07:58 nfs -> /PLEX1/usr/local/ fs/ 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 opt -> $VERSION/opt 
rwxrwxrwx 1 CPV8281 OMVSGRP 16 Sep 26 08:20 samples -> $VERSION/samp es 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 tmp -> $SYSNAME/tmp 
r-xr-xr-x 1664 CPV8281 TTY 0 Mar 16 08:53 u 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 usr -> $VERSION/usr 
rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 var -> $SYSNAME/var 
rwxrwxrwx 1 CPV8281 OMVSGRP 15 Mar 11 06:57 web -> /SYSA/local/web 
SYSA:CPV8281:/ > 

let me know if I'm understanding you correcly 
thanks for your help 




Carmen Vitullo 

- Original Message -

From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 16, 2018 8:51:36 AM 
Subject: Re: how do you handle shared ZFS in a sysplex 

Yea, it gets a little complicated for the non-sysres stuff. We are shared ZFS 
across the sysplex. We do have a couple of one-off's in /usr/lpp/ as well. So, 
a couple of observations I made. You have two types of filesystems. 1) those 
that are shared across the sysplex, 2) those that are "system/environment" 
specific. 

We have SYSRES ZFS shared as part of $VERSION for all systems running on the 
same SYSRES, we also do a similar process for ISV ZFS, using system symbol. 

For stuff that wants to be in the shared space, like /usr/lpp but really isn’t 
a part of that, I use symbolic links in /usr/lpp to resolve to a location 
outside of that filesystem. In my case it's to a directory location that 
resides in a system specific filesystem. It could just as easily be in some 
other shared part of the directory tree however. 

TEC1:$ ls -al 
total 640 
drwxr-xr-x 40 P0SJR OMVSGRP 8192 Oct 25 14:52 . 
drwxr-xr-x 10 P0SJR OMVSGRP 8192 Oct 25 14:51 .. 
drwxr-xr-x 9 P0SJR OMVSGRP 8192 Jan 4 10:13 IBM 
drwxr-xr-x 3 P0SJR OMVSGRP 8192 Apr 27 2017 NFS 
drwxr-xr-x 11 P0SJR OMVSGRP 8192 Dec 15 08:22 Printsrv 
drwxr-xr-x 3 P0SJR OMVSGRP 8192 Oct 20 17:34 TWS 
lrwxrwxrwx 1 P0SJR OMVSGRP 13 Oct 25 14:52 aqt -> /opt/fitb/aqt 
drwxr-xr-x 7 P0SJR OMVSGRP 8192 Oct 25 15:31 bcp 
drwxr-xr-x 8 P0SJR OMVSGRP 8192 Apr 27 2017 booksrv 
drwxr-xr-x 9 P0SJR OMVSGRP 8192 Apr 27 2017 cbclib 
lrwxrwxrwx 1 P0SJR OMVSGRP 16 Oct 25 14:52 cicsts -> /opt/fitb/cicsts 
drwxr-xr-x 6 P0SJR OMVSGRP 8192 Nov 13 2015 cobol 

I hope this helps. Feel free to contact me off-list if you want to compare 
notes. We've been in shared ZFS for a few years now, and while a lot of things 
to think of in the beginning, its been very easy to handle going forward. 
_ 
Dave Jousma 
Manager Mainframe Engineering, Assistant Vice President 
david.jou...@53.com 
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H 
p 616.653.8429 
f 616.653.2717 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Friday, March 16, 2018 8:38 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: how do you handle shared ZFS in a sysplex 

**CAUTION EXTERNAL EMAIL** 

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails** 

I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS 
environment with a sysplex root, version root and system(s) root. 
to facilitate this environment I IPL'd each LPAR from the same SYSRES and 
shared parmlib using symbols for system specific parms. 
What I'm wondering, is we have some products that are mounted @ /usr/lpp/, this 
of course is resolved to $VERSION/usr/lpp, someone had installed a product 
there and had 3

Re: ISPF packed member question

2018-03-16 Thread Bill Wilkie

If you know what you are searching for, you can enter the name of the PDS in 
the 3.4 screen. When you see the member list enter SRCHFOR on the command line 
and all members that contain that search string will be highlighted.


For example if you are looking for the name BILL in all members   SRCHFOR  BILL


HTH


Bill



From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Sent: Friday, March 16, 2018 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ISPF packed member question

Hi list,

I have what is hopefully an easy question that I just am looking in the wrong 
place.  Given a PDS of source or JCL, is there a quick, "easy" way of finding 
any/all the packed members within the PDS?

Thanks,

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
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: how do you handle shared ZFS in a sysplex

2018-03-16 Thread Jousma, David

Yea, it gets a little complicated for the non-sysres stuff.   We are shared ZFS 
across the sysplex.   We do have a couple of one-off's in /usr/lpp/ as well.   
So, a couple of observations I made.  You have two types of filesystems.  1) 
those that are shared across the sysplex, 2) those that are 
"system/environment" specific.

We have SYSRES ZFS shared as part of $VERSION for all systems running on the 
same SYSRES, we also do a similar process for ISV ZFS, using system symbol.

For stuff that wants to be in the shared space, like /usr/lpp   but really 
isn’t a part of that, I use symbolic links in /usr/lpp to resolve to a location 
outside of that filesystem.  In my case it's to a directory location that 
resides in a system specific filesystem.  It could just as easily be in some 
other shared part of the directory tree however.

TEC1:$ ls -al   
 
total 640   
 
drwxr-xr-x  40 P0SJROMVSGRP 8192 Oct 25 14:52 . 
 
drwxr-xr-x  10 P0SJROMVSGRP 8192 Oct 25 14:51 ..
 
drwxr-xr-x   9 P0SJROMVSGRP 8192 Jan  4 10:13 IBM   
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Apr 27  2017 NFS   
 
drwxr-xr-x  11 P0SJROMVSGRP 8192 Dec 15 08:22 Printsrv  
 
drwxr-xr-x   3 P0SJROMVSGRP 8192 Oct 20 17:34 TWS   
 
lrwxrwxrwx   1 P0SJROMVSGRP   13 Oct 25 14:52 aqt -> /opt/fitb/aqt  
 
drwxr-xr-x   7 P0SJROMVSGRP 8192 Oct 25 15:31 bcp   
 
drwxr-xr-x   8 P0SJROMVSGRP 8192 Apr 27  2017 booksrv   
 
drwxr-xr-x   9 P0SJROMVSGRP 8192 Apr 27  2017 cbclib
 
lrwxrwxrwx   1 P0SJROMVSGRP   16 Oct 25 14:52 cicsts -> 
/opt/fitb/cicsts 
drwxr-xr-x   6 P0SJROMVSGRP 8192 Nov 13  2015 cobol 
 

I hope this helps.  Feel free to contact me off-list if you want to compare 
notes.   We've been in shared ZFS for a few years now, and while a lot of 
things to think of in the beginning, its been very easy to handle going forward.
_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, March 16, 2018 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: how do you handle shared ZFS in a sysplex

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS 
environment with a sysplex root, version root and system(s) root.
to facilitate this environment I IPL'd each LPAR from the same SYSRES and 
shared parmlib using symbols for system specific parms. 
What I'm wondering, is we have some products that are mounted @ /usr/lpp/, this 
of course is resolved to $VERSION/usr/lpp, someone had installed a product 
there and had 3 different filesystem mounts, one for each system, it works OK, 
until I had to IPL one system from a different sysres, the filesystem from the 
other 2 systems mounted @ /usr/lpp were unmounted and the new version file 
system was mounted from the system I IPL'd.  
because of this fact, batch processing that needed that filesystem on the OTHER 
systems failed looking for the original $VERSION/usr/lpp. 
maybe not such a clear explanation but I'm wondering what other do in this 
case. I forced the team to move any file systems that need to be shared to 
//. and products filesystems that need to be system specific 
mounted @ /$SYSTEM/. but I'm having an issue moving forward, and I think 
I'm going to have a problem when I migrate maint around the plex with a new 
sysres, will I? 
 Any help would be greatly appreciated. 

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your

ISPF packed member question

2018-03-16 Thread Pommier, Rex

Hi list,

I have what is hopefully an easy question that I just am looking in the wrong 
place.  Given a PDS of source or JCL, is there a quick, "easy" way of finding 
any/all the packed members within the PDS?

Thanks,

Rex

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: z/OS "interactive computing" - AKA TSO/ISPF or UNIX shell

Jerry,

I've found that the SDSF REXX API works well in USS and have written
several scripts to do useful stuff like bounce web server started tasks.
We use this from Atlassians Bamboo CI tooling to deploy web applications
to z/OS triggered from git merges in Bitbucket. Rockets git port has
been a game changer for us! If there was a curses library for REXX it
would be possible to write something similar to SDSF for the shell.
There is also the oeconsol command to execute MVS commands from the
shell which is really cool.

Like you I prefer to work in z/OS UNIX with all the code in the file
system. It's so much better than using data sets. We don't have Linux on
Z installed but do a lot of work on x86 Linux servers. You mentioned
hipersockets which is great for shuttling data around at high speeds for
JDBC and stuff in production systems but what other advantages does it
offer for development?

On 16/03/2018 8:21 PM, Jerry Callen wrote:

I'm going to be an EXTREME outlier here.

Background: I learned computing on OS/360 thru MVS, first using cards, then
TSO/ISPF. I jumped ship to Unix in the mid 80s and now I'm back on the
mainframe, doing ports of open source software to z/OS (under USS) at Rocket
Software.

I am logged into both USS (via ssh from PuTTY) and TSO/ISPF (via BlueZone) from
a Windows laptop all day long. If I had a decent tool for accessing JES
(there's no avoiding SDSF for the time being) from USS, I'd NEVER be in TSO.

I use emacs as my development environment. I don't call it an "editor" because it does so
much more than edit text. In particular, the "shell buffer" feature is indispensible;
think of TSO session manager, but on insane steroids. The USS port of emacs is ancient and creaky
(though I dearly hope we can remedy that within the next year), and I will grant that emacs has a
very stiff learning curve, but once you know it, it's unbelievably productive.

For source control, I use the Rocket port of git. Essentially all of our
mainframe development is moving from other source control systems (SCLM, cvs,
svn) to git; there are good open source tools for converting from cvs and svn
that preserve all the history and branches.

For builds, I use whatever the open source project I'm currently working on
uses, which is generally some variation on automake/autoconf/configure/make.
The automake/autoconf situation on z/OS isn't yet what it wants to be. For my
own projects, I just use raw make. I often create make files that work on both
USS and Linux on Z (my go-to Unix when I need to use a tool not yet on USS).

In short: I treat z/OS as a Unix box. Nearly all of the compilers (COBOL, PL/I, C/C++,
plus the assembler and binder) can be used from USS, on Unix files (no need to move
source, maclibs, include files, etc. into a PDS). IBM has provided very good, albeit
complex and tricky to use well, ASCII/EBCDIC "bimodal" encoding support to ease
the encoding problem. IBM is actively porting newer languages (like JavaScript in
node.js) to z/OS.

I can run TSO commands from the shell prompt (using, of course, the "tsocmd"
command...) when I need to. I keep building tools to help insulate me from TSO and batch
(like my SMP query interface at https://github.com/zorts/smpapi), and of course Rocket
continues to release new and updated tools for free (though our bandwidth is limited...).
The big remaining hole is JES queue access. I can, of course, submit jobs from USS, but
getting the output in a nice, consumable manner remains a challenge; hence, my TSO
session.

We have a cadre of younger developers who follow a similar path, though often
using vim instead of emacs, and im some cases Windows-based editors (Eclipse,
Webstorm, SlickEdit, etc.) and FTP.

Bear in mind that my first "real" editor was ISPF, which I used for years. Even
with that history, I can't imagine using it for any serious editing at this point.

Slight diversion: Linux on Z is a VERY nice platform. I have rarely encountered
any problems porting x86 Unix code to Linux on Z, and usually I don't have to;
it's already a real, well-equipped Unix. Given hipersocket connectivity to
z/OS, I think it's got potential to be a terrific alternative to USS. However,
it's still just too weird for many shops: it requires a completely new set of
system administration skills, its own LPAR or VM, and it just doesn't seem to
getting much traction.

-- Jerry

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

Re: Can the CSI info alone produce a final list required for full resolution of researched PTFs?

2018-03-16 Thread Jerry Callen

>> Normally, the process of resolving all REQ/PREREQ/IFREQ requirements for
>> given PTF(s) and collecting all missing items that prevent resolution, up to 
>> the point where APPLY CHECK suggests that actual APPLY could be successful
>> could require several iterations.

> I have used GROUPEXTEND since being introduced and can't recall ever being
> successful in attaining full resolution with one pull.
> 
> It always took several pulls (iterations) to attain a full resolution.

It sounds to me as if the problem is that the SYSMODs identified by
GROUPEXTEND can have their own REQs, which are (of course) not in the
CSI until they get RECEIVEd.

Is anyone aware of an IBM-provided REST API to the entire SYSMOD
database? If you had that, you could presumably use that in
conjunction with the SMP "GIMAPI" to construct the full graph.

You could probably html-scrape content from Service Link, but that
seems hopelessly primitive.

I smell a nice science experiment brewing...

-- Jerry

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

how do you handle shared ZFS in a sysplex