Re: EXIT to control use of Class

[Paul Gilmartin]

On Sat, 17 Mar 2018 17:22:40 -0700, retired mainframer wrote:

>If I remember correctly, the OP wanted to change the job class if the user 
>specified the wrong one.  I don't think RACF will do that.
> 
Largely, I resent DWIM: code that purports to correct perceived errors.
With smartphones this has spawned legendary examples, some risqué.
http://www.paulhensel.org/teachspell.html

I prefer a failure so I can choose an alternative.

-- gil

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

[retired mainframer]

If I remember correctly, the OP wanted to change the job class if the user 
specified the wrong one.  I don't think RACF will do that.

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Dan D
> Sent: Saturday, March 17, 2018 11:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: EXIT to control use of Class
> 
> Hi Peter,
> 
> I think this may be simpler than others are making out ...
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha7
> 00/ControllingJobClassUsage.htm
> 
>  An installation can control job class usage by granting access based 
> on the
> submitter’s profile, or based on the owner’s profile, or both. 

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

Re: Cobol-Unix

[Paul Gilmartin]

On Sat, 17 Mar 2018 19:22:37 +, scott Ford wrote:

>I am trying to understand how to issue a unix via a Cobol Program running
>in Batch ..I found an example  IBM supplied...
> 
Why would someone use Batch COBOL to run a shell to use TSOCMD to execute
a TSO command?  Rube Goldberg?

>  Working-storage section.
>   01 Start-Filler  pic x(41)
>value '** Working Storage Begin '.
>   01 exec-path pic x(100).
>   01 exec-path-ptr pointer.
>   01 exec-parm1pic x(100).
>   01 exec-parm1-ptrpointer.
>   01 exec-parm2pic x(100).
>   01 exec-parm2-ptrpointer.
>   01 null-ptr  pointer value null.
>   Local-storage section.
>   01 rcpic s9(9) binary.
>   Procedure division.
>   Move Z'tsocmd' to exec-path.
>   Move Z'SEARCH CLASS(USER)' to exec-parm1
>   Set exec-path-ptr to address of exec-path
>   Set exec-parm1-ptr to address of exec-parm1
>   Set exec-parm2-ptr to address of exec-parm2
>  Call 'execl' using by value exec-path-ptr
>  by value exec-parm1-ptr
>  by value null-ptr
>returning rc
>   if rc = 0 then
>  display 'tsocmd worked'
>   end-if
>   Goback.
>
>My problem is how to i route the output back the caller ? I thought if I
>used STDOUT it would , but apparently not.
>
>//ETESTR4  JOB SYSTEMS,MSGLEVEL=(1,1),MSGCLASS=X,CLASS=A,PRTY=8,
>// NOTIFY=,REGION=4096K
>//STEP1  EXEC  PGM=CBLUNIX,REGION=0K,
>//   PARM='POSIX(ON) ALL31(ON) ENVAR("_CEE_ENVFILE=DD:STDENV")/'
>//STEPLIB  DD  DSN=IDF.TESTUNIX.LOADLIB,DISP=SHR
>//SYSPRINT DD  SYSOUT=*
>//SYSOUT   DD  SYSOUT=*
>//STDENV   DD  SYSOUT=*
>/*
As someone has already pointed out, STDENV should be SYSIN, not SYSOUT.

I believe STDIN, STDOUT, STERR, and STDENV DDs are peculiar to
BPXBATCH.  but you could invoke BXBATCH as if it were a standard
batch program

UNIX programs generally expect stdin, stdout, and stderr to be available.
Otherwise they misbehaive badly.

I'd be inclined to BPX1OPN /dev/null.  BPX1PIP to create a pipe.  Invoke the
UNIX program with BPX1SPN, assigning the null descriptor to descriptor 0
and the input end of the pipe to both descriptors 1 and 2.  DYNALLOC (BPXWDYN?)
the output of the pipe to a DDNAME and read the program's output from that.

I've done similar with Rexx, never with COBOL.

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

[David Boyes]

On 3/17/18, 1:55 PM, "IBM Mainframe Discussion List on behalf of Paul 
Gilmartin"  wrote:

>On Sat, 17 Mar 2018 16:29:29 +, David Boyes wrote:
>There's c3270 (which I never got to work) and older flavors of tn3270 (which 
>i've used)
>The trick is to switch modes dynamically.
>How about logging in on an emulated 3270, setting X11 DISPLAY back to your 
>desktop
>and starting Xterm under OMVS?  The trick would be to bootleg DISPLAY and Xauth
>through the 3270 logon.  I recall that years ago, when security was more 
>casual, I
>could start Xterm from a batch job.

The point of this exercise is not to have to use a special terminal emulator at 
all. I mentioned c3270 only to point out that it already has a well-tested 3270 
screen order processing engine that already knows how to do all the screen 
management and telnet option negotiation that's needed to allow a standard 
telnet session to emulate a 3270; we wouldn't have to start from scratch. If 
that 3270 engine code was included in the shell (activated say by an ioctl() 
and inheriting the current connection), then any application could trigger that 
emulation as needed and keep mainframe code that works today working without 
change. Most TSO or VM sessions would be (and are) perfectly usable with 
nothing smarter than a teletype - I do it all the time on VM when I need to 
quickly execute a command and don't need/want any fullscreen stuff, and the 
line editor mode is still in the base XEDIT code, if a bit dusty/crusty.

> If, only, ISPF would consider operating from other than the logged-in 
> terminal!

See above. There's no need to modify ISPF or any application, just enable the 
emulation when needed, either by ioctls inserted into the application or via a 
script that calls an external utility to toggle the emulation off/on. X11 takes 
a lot of additional infrastructure for this purpose; my approach would allow 
any ASCII terminal that is supported by termcap to work immediately. I could 
use my vintage ADM-3A (the world's stupidest glass TTY; supports only clear 
screen and position cursor, otherwise you have to rewrite every character on 
screen) and have a working environment.

> Long ago, there was ISPGUI (is there still?)  Sucked. 

I think Win10 finally broke the workstation agent code. It still sucked.

>  How about a dynamically resizable 3270 in an ISPF session!?
> (XEDIT comes close: I can pull the plug on an XEDIT session and reconnect 
> with a different
> terminal geometry.  XEDIT dutifully repaints the screen to the new geometry.  
> What about
> ISPF?  ISPF people say, "Impossible!  NFW!"  No.  Just do a WSF Query, as 
> XEDIT does, 
> and redraw the display. 

We won't get into 'who's editor is better' discussions; they just degenerate 
quickly into "Nyah!" and "Does not!". I don't think that one is totally ISPF's 
fault, though. 

> Long ago, there was SimWare.  (Are they still?  Who bought them?) 

Deservedly buried with a proper stake in it's heart, I hope. That package was a 
gigantic PITA. 

> Forget Session Managers.  Why not simply support concurrent logins as any 
> non-IBM OS
> does?

Step 1 - get VTAM out of the terminal management business... a lot of the basic 
assumptions it makes about devices just don't really hold true any more. I 
think the logical device model VM uses seems to work a lot better for that 
purpose. The basic system services concepts needed exist to permit multiple 
sessions; it's just a question of thinking it all the way through an 
implementation.



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

Re: Cobol-Unix

[Farley, Peter x23353]

One thing I see wrong with your JCL is the STDENV DD is supposed to be "DD *" 
input, not "SYSOUT=*" output.  STDENV is where you set environment variables 
(like PATH, etc.).  That is where you would put "BPX_SHAREAS=YES" to make the 
"exec" run in the same address space as the COBOL program.  You might need 
"BPX_SHAREAS=MUST", depends on your environment I think.  Check my spelling for 
that BPX variable in the Fine Manuals, I'm not sure I have typed it accurately.

Do you get any output at all on SYSOUT from the COBOL program?  What do you see 
there?

If the z/Unix call runs in a separate OMVS address space, you will get nothing 
in the SYSOUT's of the COBOL address space.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Saturday, March 17, 2018 3:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cobol-Unix

EXTERNAL EMAIL

I am trying to understand how to issue a unix via a Cobol Program running
in Batch ..I found an example  IBM supplied...

  Working-storage section.
   01 Start-Filler  pic x(41)
value '** Working Storage Begin '.
   01 exec-path pic x(100).
   01 exec-path-ptr pointer.
   01 exec-parm1pic x(100).
   01 exec-parm1-ptrpointer.
   01 exec-parm2pic x(100).
   01 exec-parm2-ptrpointer.
   01 null-ptr  pointer value null.
   Local-storage section.
   01 rcpic s9(9) binary.
   Procedure division.
   Move Z'tsocmd' to exec-path.
   Move Z'SEARCH CLASS(USER)' to exec-parm1
   Set exec-path-ptr to address of exec-path
   Set exec-parm1-ptr to address of exec-parm1
   Set exec-parm2-ptr to address of exec-parm2
  Call 'execl' using by value exec-path-ptr
  by value exec-parm1-ptr
  by value null-ptr
returning rc
   if rc = 0 then
  display 'tsocmd worked'
   end-if
   Goback.

My problem is how to i route the output back the caller ? I thought if I
used STDOUT it would , but apparently not.

//ETESTR4  JOB SYSTEMS,MSGLEVEL=(1,1),MSGCLASS=X,CLASS=A,PRTY=8,
// NOTIFY=,REGION=4096K
//STEP1  EXEC  PGM=CBLUNIX,REGION=0K,
//   PARM='POSIX(ON) ALL31(ON) ENVAR("_CEE_ENVFILE=DD:STDENV")/'
//STEPLIB  DD  DSN=IDF.TESTUNIX.LOADLIB,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//STDENV   DD  SYSOUT=*
/*

I am unsure how this works, if someone could point me a to a manual I would
be  'Happy Happy'..


-- 

 Regards,


*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

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

Cobol-Unix

[scott Ford]

I am trying to understand how to issue a unix via a Cobol Program running
in Batch ..I found an example  IBM supplied...

  Working-storage section.
   01 Start-Filler  pic x(41)
value '** Working Storage Begin '.
   01 exec-path pic x(100).
   01 exec-path-ptr pointer.
   01 exec-parm1pic x(100).
   01 exec-parm1-ptrpointer.
   01 exec-parm2pic x(100).
   01 exec-parm2-ptrpointer.
   01 null-ptr  pointer value null.
   Local-storage section.
   01 rcpic s9(9) binary.
   Procedure division.
   Move Z'tsocmd' to exec-path.
   Move Z'SEARCH CLASS(USER)' to exec-parm1
   Set exec-path-ptr to address of exec-path
   Set exec-parm1-ptr to address of exec-parm1
   Set exec-parm2-ptr to address of exec-parm2
  Call 'execl' using by value exec-path-ptr
  by value exec-parm1-ptr
  by value null-ptr
returning rc
   if rc = 0 then
  display 'tsocmd worked'
   end-if
   Goback.

My problem is how to i route the output back the caller ? I thought if I
used STDOUT it would , but apparently not.

//ETESTR4  JOB SYSTEMS,MSGLEVEL=(1,1),MSGCLASS=X,CLASS=A,PRTY=8,
// NOTIFY=,REGION=4096K
//STEP1  EXEC  PGM=CBLUNIX,REGION=0K,
//   PARM='POSIX(ON) ALL31(ON) ENVAR("_CEE_ENVFILE=DD:STDENV")/'
//STEPLIB  DD  DSN=IDF.TESTUNIX.LOADLIB,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//STDENV   DD  SYSOUT=*
/*

I am unsure how this works, if someone could point me a to a manual I would
be  'Happy Happy'..


-- 

 Regards,


*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

[Dan D]

Hi Peter,

I think this may be simpler than others are making out ...

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/ControllingJobClassUsage.htm

 An installation can control job class usage by granting access based on 
the submitter’s profile, or based on the owner’s profile, or both. 

Dan

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

[Paul Gilmartin]

On Sat, 17 Mar 2018 16:29:29 +, David Boyes wrote:
>
>It wouldn't be a huge effort to create the necessary code to make the standard 
>interface to z/OS be a line-mode telnet session, creating a fullscreen 
>environment using curses on demand (it's easy to impose a structured line 
>discipline over a unstructured connection). Providing a utility and set of 
>system calls that could switch on and off 3270 emulation mode on a standard 
>character mode terminal would allow (borrow the 3270 emulation engine from 
>c3270 and build it into the shell application) existing code continue to run 
>as is, and evolve over time. Something like:
>
>set ROWS=43; export ROWS
>set COLS=132;export COLS
>termmode --type 3270 --model=arbsize(support ROWSxCOLS screen size, or the 
>standard predefined 3270 sizes if no environment vars are present)
>XEDIT foo Bar a
>termmode --type nvt
>
There's c3270 (which I never got to work) and older flavors of tn3270 (which 
i've used)
The trick is to switch modes dynamically.

How about logging in on an emulated 3270, setting X11 DISPLAY back to your 
desktop
and starting Xterm under OMVS?  The trick would be to bootleg DISPLAY and Xauth
through the 3270 logon.  I recall that years ago, when security was more 
casual, I
could start Xterm from a batch job.

If, only, ISPF would consider operating from other than the logged-in terminal!

Long ago, there was ISPGUI (is there still?)  Sucked.  I once started an ISPGUI
from a batch job.  Ran into an impasse:  Couldn't reply to some message.  Went
to SR who said, "You need to reply to that from the 3270 you logged in with."
"I didn't log in with a 3270."  "WTF!  Impossible!  You must have logged in with
a 3270!"

IBM doesn't sympathize.  How about a dynamically resizable 3270 in an ISPF 
session!?
(XEDIT comes close: I can pull the plug on an XEDIT session and reconnect with 
a different
terminal geometry.  XEDIT dutifully repaints the screen to the new geometry.  
What about
ISPF?  ISPF people say, "Impossible!  NFW!"  No.  Just do a WSF Query, as XEDIT 
does, 
and redraw the display.  As it is, I get a recurrent "Terminal Input Error."  
Can't even get
to a READY prompt to LOGOFF.)

Long ago, there was SimWare.  (Are they still?  Who bought them?)  Ran in a VM 
service
machine and emulated a 3270 at the host.  A later release performed the 
emulation at
the desktop.  Slower; it transmitted the entire screen, not just modified data. 
 But at least
one co-worker preferred it that way: even though overall response took longer, 
he preferred
not to see the screen updating incrementally.

A co-worker once had nedit (X11) working under OMVS.  Has anyone got jedit 
working?

Forget Session Managers.  Why not simply support concurrent logins as any 
non-IBM OS
does?

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

[David Boyes]

On 3/16/18, 8:21 AM, "IBM Mainframe Discussion List on behalf of Jerry Callen" 
 wrote:

> I'm going to be an EXTREME outlier here.

To my mind, the 3270 is probably the biggest remaining problem. I've spent a 
fair amount of time on a real teletype and using the linemode telnet sessions 
that a standard telnet client provides. 

It wouldn't be a huge effort to create the necessary code to make the standard 
interface to z/OS be a line-mode telnet session, creating a fullscreen 
environment using curses on demand (it's easy to impose a structured line 
discipline over a unstructured connection). Providing a utility and set of 
system calls that could switch on and off 3270 emulation mode on a standard 
character mode terminal would allow (borrow the 3270 emulation engine from 
c3270 and build it into the shell application) existing code continue to run as 
is, and evolve over time. Something like:

set ROWS=43; export ROWS
set COLS=132;export COLS
termmode --type 3270 --model=arbsize(support ROWSxCOLS screen size, or the 
standard predefined 3270 sizes if no environment vars are present)
XEDIT foo Bar a
termmode --type nvt

ISPF or XEDIT that could work on an ANSI terminal would be really useful. 



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

[Bernd Oppolzer]

Am 17.03.2018 um 04:34 schrieb David Crayford:

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

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.


We made this observation, too. JCL is a motivation killer.
Luckily, compilation and transport etc. on our IDE does not require JCL.
Not even commands ... it's all menu driven (like: press button).

In fact, we had some young students, which were forced to work
for a while on the mainframe, and I coached them doing some C work
using embedded DB2 SQL. C should be easier for them than PL/1,
given their Java background; but anyway after this period they preferred
to return to their Java business, although we had a good time and
they succeeded with their projects. There may be a lot of reasons
for this decision, some personal, some about the perspectives of their
jobs, some about the sexiness of the environment ...

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

[Timothy Sipples]

David Crayford wrote:
>RDz has a different editor per language!

RDz (now IDz) has a different *default* editor per programming language.
That's because IBM decided -- quite correctly, in my view -- that a
developer who programs in language X would typically prefer to start
working in an editor that is popular with language X. This behavior is also
consistent with the general "perspectives" approach in Eclipse that tries
to provide task-specific adaptations as you move around.

However, that's only the default behavior. It's really easy to use a
different editor on-the-fly and/or to change the default(s), and it always
has been, from what I remember. See here for instructions for Version 14.1
of IDz (the latest release as I write this), for example:

https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.1.0/com.ibm.etools.rdz.language.editors.doc/topics/czdchoose_editor.html


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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