date:20140403

Just a wild guess on my part would be that the OP should not be using JZOS,
which does not use RRS for any kind of two phase commit, but perhaps
should run his application under the control of a transaction manager
such as WAS, CICS, JBOSS (whatever it's called now), or maybe even Tomcat.
Of course the start up and shutdown overhead of such a product is
_expensive_.


On Wed, Apr 2, 2014 at 10:41 PM, Rob Schramm rob.schr...@gmail.com wrote:

 Sounds to me like the ssue has nothing to do with JZOS.  Refer to the DB2
 Application Programming Guide for JAVA.  Covers limitations of type-4 jdbc
 driver.

 Rob Schramm
 On Apr 2, 2014 11:06 AM, Denis Gäbler denisgaeb...@netscape.net wrote:

  Hi,
 
  what you are trying to achieve is the task of a transaction manager. Keep
  multiple resources (MQ, DB2) in sync.
  What would you do to do the same thing from a COBOL application? TSO
 batch
  does not provide this functionality either.
  RRS provides this functionality, but there is no API for it that you
 could
  use from pure Java.
 
  As an example, instead of using JZOS you could run the Java application
 in
  IMS Java Regions, CICS, DB2 Java Stored Procedure or WebSphere z/OS.
  What can also be considered is using a Java based persistence framework,
  e.g. Spring to keep the resources in sync.
 
  In the end you could also write your own transaction manager.
 
 
  Hope that helps,
 
  Denis.
 
 
 
  -Original Message-
  From: Mohammad Khan mkkha...@hotmail.com
  To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
  Sent: Wed, Apr 2, 2014 4:11 pm
  Subject: Using DB2 and MQ under JZOS
 
 
  I have a batch program that runs under JZOS ( on z/OS 1.13 ) which
  connects to
  DB2 using jdbc type 2 connection and connects to a local MQ queue in
  binding
  mode. It updates DB2 data as well as writes to MQ. It seemed to work ok
  until it
  encountered an error writing to MQ and abended. More important was the
  fact that
  DB2 updates still got committed. Apparently the updates to the two
  resources are
  being managed in isolation rather than being coordinated in a global
  transaction. I guess I haven't figured out how to properly code for this
  scenario. I haven't found any guidance or sample code in MQ, DB2 or JZOS
  documents or have failed locate it. Any help, sample code or links to
  relevant
  documents will be highly appreciated.
  Regards
  Mohammad
 
  --
  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




-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: EAV Volumes

2014-04-03 Thread Lucas Rosalen

I don't know the entire process and we don't use EAV volumes at my shop,
but I believe the first action to take would be checking for any PTF needed
by running a SMP/E MISSINGFIX FIXCAT with category IBM.Function.EAV.
I also believe category IBM.Device.* would help, depending on your DASD ESS.

*Lucas Rosalen*


2014-04-03 3:27 GMT-03:00 venkat kulkarni venkatkulkarn...@gmail.com:

 We have requirement from customer to  have EAV volumes on z/OS 1.12
 systems.

 Below are the step, I followed for this configuration.

 *a) Software requirements:* Extended address volumes require z/OS V1R10.

 *b) Hardware requirements:* A Licensed interal code (LIC) upgrade to an IBM
 DS8000 is needed so that an EAV can be configured in the storage subsystem.
 *c) *Allow SMS to select extended address volumes during its volume
 selection processing. Set the USEEAV parameter in the IGDSMS*xx* PARMLIB
 member to YES: USEEAV(YES).

 d) In the IGDSMS*xx* PARMLIB member, specify an optional break point value
 for SMS to use when making volume selection decisions for VSAM data sets.
 On the BreakPointValue parameter, specify a number of cylinders (0-65520).


 Do we have any other steps, which I am missing before I use these EAV
 volumes like, any thing has to be done on IODF side  or something else.

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

OT - Rant

2014-04-03 Thread Scott Ford



rant


Please do us the courtesy by providing a FULL description of either your 
problem or question. Its not to your best interest to ask fluff questions ( 
questions lacking substance ), we are technical of this Listserv. We are 
willing to help. One liners are basically useless, if you want help.




/rant


Scott

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

Re: EAV Volumes

2014-04-03 Thread John Eells


venkat kulkarni wrote:

We have requirement from customer to  have EAV volumes on z/OS 1.12 systems.

Below are the step, I followed for this configuration.

*a) Software requirements:* Extended address volumes require z/OS V1R10.

snip

What does your customer want to use the EAVs *for*?  z/OS V1.10 was the 
minimum requirement for defining them, and R12 added a number of other 
things but more followed in R13.  Here's the history:


- z/OS R10 introduced EAV with support for VSAM (including zFS)
- z/OS R11 added Extended Format Sequential and support for data sets 
spanning the 64K cylinder line

- z/OS R12 added support for:
  - PDS and PDSE (including load modules and program objects)
  - Plain vanilla (nonextended format) sequential
  - BDAM
  - GDG
  - LPALIB, LPA list, link list data sets, SYSn.IPLPARM, SVCLIB 
Catalogs, VVDSs

  - JES2 and JES3 spool and checkpoint, JES3 JCT
  - DFSMSrmm, DFSMShsm™ data sets
  - Standalone Dump data set and AMASPZAP support
  - VSAM AIX support in Language Environment
- z/OS R13 added support for:
  - Support for 1TB EAV volumes (rolled back to z/OS R12)
  - SDSF support for output data sets
  - FTP support for SMS-managed and non-SMS-managed PS basic and large 
format, PDS and PDSE, and GDG data sets
  - PL/I Support with the PTF for APAR PM43745 (available on z/OS R11 
and up)


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: FREE DDNAME with concatenated datasets?

On Thu, 3 Apr 2014 11:34:01 +0300, Binyamin Dissen wrote:

I don't see that you dump the S99MSG. stem or check RESULT - the perm concat
seems to be failing.
 
Do you not believe that msg(2) suffices?  I tested before I posted with error
injection, and the allocation messages appeared on my terminal.  Have you
correspondingly run a test with error injection showing that messages fail
to appear?  Please post input and results so I may try to replicate.

-- gil

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

Re: EAV Volumes

2014-04-03 Thread Scott Barry

On Thu, 3 Apr 2014 11:57:06 +0530, venkat kulkarni venkatkulkarn...@gmail.com 
wrote:

We have requirement from customer to  have EAV volumes on z/OS 1.12 systems.

Below are the step, I followed for this configuration.

*a) Software requirements:* Extended address volumes require z/OS V1R10.

*b) Hardware requirements:* A Licensed interal code (LIC) upgrade to an IBM
DS8000 is needed so that an EAV can be configured in the storage subsystem.
*c) *Allow SMS to select extended address volumes during its volume
selection processing. Set the USEEAV parameter in the IGDSMS*xx* PARMLIB
member to YES: USEEAV(YES).

d) In the IGDSMS*xx* PARMLIB member, specify an optional break point value
for SMS to use when making volume selection decisions for VSAM data sets.
On the BreakPointValue parameter, specify a number of cylinders (0-65520).


Do we have any other steps, which I am missing before I use these EAV
volumes like, any thing has to be done on IODF side  or something else.


One must also consider potential ISV software product impact and 
locally-developed program/application compatibililty.

Suggest reviewing/deploying the IBM EAV Migration Assistant Tracker utility to 
help identify non-compliant programs, available on IBM.COM website -- then you 
will want to track/identify program-compliance and progress going forward.

Scott Barry
SBBWorks, Inc.

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

Re: Software (compiler) PTF or maintenance level

On Mon, 31 Mar 2014 21:19:05 -0700, Jon Perryman wrote:

... z/OS updates are at the module level rather than product level. 

Depending on which product, as you have acknowledged in another forum.



 From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net

 on 03/31/2014� at 06:03 AM, John McKown john.archie.mck...@gmail.com said:
But that doesn't show the PTF level.

There is no such thing; there's only the list of all service�installed.

Depending on which product.

-- gil

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

Re: EAV Volumes

2014-04-03 Thread Staller, Allan

1TB (z/OS 1.12 plus)

snip
 The current maximum size is 223GB (I Think)
/snip

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

Re: Using DB2 and MQ under JZOS

2014-04-03 Thread Mohammad Khan

Hi Denis,
Thanks for your response. I'm not trying to write my own transaction manager 
rather I'm hoping to use RRS in that role, after all RRS is already being used 
for DB2 access. Now if Java does not provide any means of using RRS to 
coordinate multiple resources I guess I'm out of luck. I'll probably have to 
use DB2 provided functions to write to MQ. 
 BTW we do have batch cobol programs at our site that access both DB2 and MQ 
though that's all I know about them. May be these programs have their own 
transaction management code but I find it very odd that these would not be 
transactionally sound. But who knows, reality is not limited by anyone's 
ability to conceive it.
 As for using an environment other that batch, this process was implemented in 
WAS/z but the cpu consumption killed the project. I don't know how much of that 
was WAS overhead and how much was due to the application code. My batch Java 
code does everything except for writing one message to MQ for about a fourth of 
the cost.
 Does Spring offer some kind of transactional facility ? I thought it was just 
a sql generator.
Regards
Mohammad

On Wed, 2 Apr 2014 12:05:36 -0400, Denis Gäbler denisgaeb...@netscape.net 
wrote:

Hi,
 
what you are trying to achieve is the task of a transaction manager. Keep 
multiple resources (MQ, DB2) in sync.
What would you do to do the same thing from a COBOL application? TSO batch 
does not provide this functionality either.
RRS provides this functionality, but there is no API for it that you could use 
from pure Java.

As an example, instead of using JZOS you could run the Java application in IMS 
Java Regions, CICS, DB2 Java Stored Procedure or WebSphere z/OS.
What can also be considered is using a Java based persistence framework, e.g. 
Spring to keep the resources in sync.

In the end you could also write your own transaction manager.


Hope that helps,

Denis.


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

Re: Using DB2 and MQ under JZOS

2014-04-03 Thread Mohammad Khan

I'm not using jdbc type 4  connection so its limitations should not matter 
unless type 2 ( which I'm using ) has the same limitations.
Regards
Mohammad


On Wed, 2 Apr 2014 23:41:52 -0400, Rob Schramm rob.schr...@gmail.com wrote:

Sounds to me like the ssue has nothing to do with JZOS.  Refer to the DB2
Application Programming Guide for JAVA.  Covers limitations of type-4 jdbc
driver.

Rob Schramm
On Apr 2, 2014 11:06 AM, Denis G�bler denisgaeb...@netscape.net wrote:

 Hi,

 what you are trying to achieve is the task of a transaction manager. Keep
 multiple resources (MQ, DB2) in sync.
 What would you do to do the same thing from a COBOL application? TSO batch
 does not provide this functionality either.
 RRS provides this functionality, but there is no API for it that you could
 use from pure Java.

 As an example, instead of using JZOS you could run the Java application in
 IMS Java Regions, CICS, DB2 Java Stored Procedure or WebSphere z/OS.
 What can also be considered is using a Java based persistence framework,
 e.g. Spring to keep the resources in sync.

 In the end you could also write your own transaction manager.


 Hope that helps,

 Denis.



 -Original Message-
 From: Mohammad Khan mkkha...@hotmail.com
 To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU
 Sent: Wed, Apr 2, 2014 4:11 pm
 Subject: Using DB2 and MQ under JZOS


 I have a batch program that runs under JZOS ( on z/OS 1.13 ) which
 connects to
 DB2 using jdbc type 2 connection and connects to a local MQ queue in
 binding
 mode. It updates DB2 data as well as writes to MQ. It seemed to work ok
 until it
 encountered an error writing to MQ and abended. More important was the
 fact that
 DB2 updates still got committed. Apparently the updates to the two
 resources are
 being managed in isolation rather than being coordinated in a global
 transaction. I guess I haven't figured out how to properly code for this
 scenario. I haven't found any guidance or sample code in MQ, DB2 or JZOS
 documents or have failed locate it. Any help, sample code or links to
 relevant
 documents will be highly appreciated.
 Regards
 Mohammad

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

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

Re: 3270 Emulators and consoles

2014-04-03 Thread Thomas Berg

So far have these been mentioned:

 x3270
BlueZone from Rocket
Opentext Host Explorer
Attachmate Extra Extreme 9
Reflection/Attachmate
PCOMM
Nexus
VistaTN3270 from Tom Brennan
QWS3270 from Jolly Giant
Rumba 7.5
Passport
SDI's TN3270 Plus
Hummingbird
Mochasoft
ZOC Terminal from EmTec:  
http://www.emtec.com/zoc/tn3270-terminal-emulation.html



Best Regards,
Thomas Berg
___
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)





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

Re: Using DB2 and MQ under JZOS

2014-04-03 Thread Mohammad Khan

I may be trying to push the envelop but RRS attach is already being used for 
connecting to DB2 as shown by the plan name used by the thread in our db2 
monitor. Now if I could only coax it ( ! ) to recognize MQ as well.


On Thu, 3 Apr 2014 04:33:44 -0500, John McKown john.archie.mck...@gmail.com 
wrote:

Just a wild guess on my part would be that the OP should not be using JZOS,
which does not use RRS for any kind of two phase commit, but perhaps
should run his application under the control of a transaction manager
such as WAS, CICS, JBOSS (whatever it's called now), or maybe even Tomcat.
Of course the start up and shutdown overhead of such a product is
_expensive_.



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

Re: 3270 Emulators and consoles

2014-04-03 Thread Thomas Berg

So far have these been mentioned:

 x3270
BlueZone from Rocket
Opentext Host Explorer
Attachmate Extra Extreme 9
Reflection/Attachmate
PCOMM
Nexus
VistaTN3270 from Tom Brennan
QWS3270 from Jolly Giant
Rumba 7.5
Passport
SDI's TN3270 Plus
Hummingbird
Mochasoft
ZOC Terminal from EmTec:  
http://www.emtec.com/zoc/tn3270-terminal-emulation.html
HOBLink



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)

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

Diagnosing QSAM CLOSE RC4

2014-04-03 Thread Alan Haff

I'm writing a relatively trivial assembler program that writes output to a
Unix file. I'm getting return code 4 from CLOSE, which of course simply
indicates that the close was unsuccessful. No additional diagnostic
messages are generated.

I've confirmed that I haven't clobbered the DCB or otherwise mangled any
control blocks (as best I can tell, anyway).

Any tips on how to determine the reason that CLOSE refused to close the
file? Thanks...

(The program is an ADRDSSU User Interaction Module exit that reformats DUMP
records into AWSTAPE format and writes them to a Unix file. The path will
eventually be an NFS-mounted filesystem when I get everything working.)

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

Re: EAV Volumes

2014-04-03 Thread Chris Hoelscher

My suggestion - run in trial mode for a very long time - we found many software 
vendor's products are NOT EAV compliant (and some say they have no plans to be) 
- we needed to know this so we could isolate non-compliant software
S DASD use to a pool of volumes where EAV would not be employed

Chris hoelscher
Technology Architect | Database Infrastructure Services
Technology Solution Services

123 East Main Street |Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 476-2538 - office
(502) 714-8615 - blackberry
Keeping CAS and Metavance safe for all HUMANAty


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Thursday, April 03, 2014 2:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] EAV Volumes

We have requirement from customer to  have EAV volumes on z/OS 1.12 systems.

Below are the step, I followed for this configuration.

*a) Software requirements:* Extended address volumes require z/OS V1R10.

*b) Hardware requirements:* A Licensed interal code (LIC) upgrade to an IBM
DS8000 is needed so that an EAV can be configured in the storage subsystem.
*c) *Allow SMS to select extended address volumes during its volume
selection processing. Set the USEEAV parameter in the IGDSMS*xx* PARMLIB
member to YES: USEEAV(YES).

d) In the IGDSMS*xx* PARMLIB member, specify an optional break point value
for SMS to use when making volume selection decisions for VSAM data sets.
On the BreakPointValue parameter, specify a number of cylinders (0-65520).


Do we have any other steps, which I am missing before I use these EAV
volumes like, any thing has to be done on IODF side  or something else.

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

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

Re: FREE DDNAME with concatenated datasets?

On Thu, 3 Apr 2014 11:34:01 +0300, Binyamin Dissen wrote:

I don't see that you dump the S99MSG. stem or check RESULT - the perm concat
seems to be failing.

OK.  I stand corrected.  PERMC appeared in z/OS 2.1; we have only 1.13.
But that's reported in RESULT, which I failed to check; allocation messages
go to the terminal; S99MSG is never set.

Revised EXEC and output below:

user@HOST: cat `whence catdd`   
   
/* Rexx */ signal on novalue /* ***
   Doc: determine DDNAME leakage.
*/
address 'SH' 'set -x; uname -a'
call AllocIt 'alloc dd(FOOBAR)  shr dsn(SYS1.INJECT.ERROR)'
say

call AllocIt 'alloc dd(SYSLIB)  shr dsn(SYS1.MACLIB)'
call AllocIt 'alloc rtddn(CAT1) shr dsn(SYS1.MODGEN)'
say; say 'Allocated:'
call DDinfo

call AllocIt 'concat ddlist(SYSLIB,'CAT1')'
say; say 'Catenated:'
call DDinfo

call AllocIt 'free  dd(SYSLIB)'
say; say 'Freed; note that' CAT1 'is not freed:'
call DDinfo

call AllocIt 'alloc dd(SYSLIB)  shr dsn(SYS1.MACLIB)'
call AllocIt 'concat ddlist(SYSLIB,'CAT1') permc'
say; say 'Catenated, with PERMC; note that' CAT1 'is not catenated:'
call DDinfo

return( 0 )

AllocIt: procedure expose SIGL CAT1 CAT2
A = arg(1) copies( 'msg(2)', 1 )
call BPXWDYN A
say right( SIGL, 3 ) RESULT value( 'S99MSG.0' ) A
return( RESULT )

DDinfo:
do I = 1 until last0
Call bpxwdyn 'info inrelno('I')' ,
 'inrtddn(ddn) inrtdsn(dsn) inrtlst(last)'
say I ddn copies( '(catenated)', ddn='') dsn;  end I
return( 0 )
/*  */

user@HOST: catdd
   
sh:0+ uname -a 
OS/390 MVS3 23.00 03 2818
IKJ56228I DATA SET SYS1.INJECT.ERROR NOT IN CATALOG OR CATALOG CAN NOT BE 
ACCESSED
  5 386400258 S99MSG.0 alloc dd(FOOBAR)  shr dsn(SYS1.INJECT.ERROR) msg(2)

  8 0 S99MSG.0 alloc dd(SYSLIB)  shr dsn(SYS1.MACLIB) msg(2)
  9 0 S99MSG.0 alloc rtddn(CAT1) shr dsn(SYS1.MODGEN) msg(2)

Allocated:
1 SYSLIB  SYS1.MACLIB
2 SYS1  SYS1.MODGEN
 13 0 S99MSG.0 concat ddlist(SYSLIB,SYS1) msg(2)

Catenated:
1 SYSLIB  SYS1.MACLIB
2  (catenated) SYS1.MODGEN
 17 0 S99MSG.0 free  dd(SYSLIB) msg(2)

Freed; note that SYS1 is not freed:
1 SYS1  SYS1.MODGEN
 21 0 S99MSG.0 alloc dd(SYSLIB)  shr dsn(SYS1.MACLIB) msg(2)
 22 -23 S99MSG.0 concat ddlist(SYSLIB,SYS1) permc msg(2)

Catenated, with PERMC; note that SYS1 is not catenated:
1 SYS1  SYS1.MODGEN
2 SYSLIB  SYS1.MACLIB
user@HOST: 

-- gil

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

ISPF dynamically allocating dataset with DISP=OLD?

2014-04-03 Thread Chase, John

Hi, List,

z/OS 1.13 at RSU1312.  The other day, a user did something in ISPF that 
caused allocation of a Production JCL library to his TSO session with DISP=OLD 
instead of DISP=SHR, causing a hiccup in batch processing when the scheduler 
was locked out for a few seconds.  So far, we have not been able to replicate 
locking out another user at the dataset level via any combination of 
manipulations using (primarily) ISPF EDIT.

Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!):

014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045 EXPDT=0 DISP=Old
BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1 CTRI=CYL SQTY=50
NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1 EXCP=4001 
STEP=tsoproc
PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051

The SMF 42-006 that immediately follows:

042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records VOL=volser 
DSDEV=ccuu
DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256 DSMXR=58 DSMXS=57
AMSRB=4000 AMSRR=2562

The timestamps on those two records are identical down to hundredths of a 
second, so maybe the user was running a SuperC search?   We can't tell from 
evidence available to us today.

We've tried every combination we can think of with multiple users ISPF EDITing 
the same dataset, and the only time we get any conflict is if a second user 
tries to open a MEMBER for EDIT that is already opened for EDIT by another 
user; and we believe that lockout at the member level is accomplished via an 
ENQ named SPFEDIT.membername or something like that.  IOW, we have been unable 
to cause a dataset (PDS or PDSE) to be dynamically allocated with DISP=OLD 
using any variant of ISPF EDIT.

Is there any other way within ISPF that an existing dataset can be dynamically 
allocated with DISP=OLD?  If there is, we apparently have never encountered it 
before.

TIA,

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.

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

Re: ISPF dynamically allocating dataset with DISP=OLD?

ISPF option 3.4, doing a z on a PDS to compress it will result in a
DISP=OLD type allocation. This is the only thing that _I_ know of which
does this. Of course doing a TSO ALLOCATE command in a REXX program, CLIST,
or using the TSO command option (option 6), the user can directly do it
directly.

As a curiosity answer, ISPF has three possible resource names used with the
qname of SPFEDIT.

For the member of a PDS, it is 52 bytes long consisting of the DSN, padded
with blanks to 44 characters followed by the member name, padded to 8
characters by blanks.
For a sequential DSN, or a PDS when actually saving a member, it is the 44
character, blank padded, DSN.
For a UNIX file, it is 12 bytes consisting of a 4 byte inode number, 4 byte
device number, and 4 bytes sysplex indicator value (x'' - no UNIX
sysplex, x'0020' - UNIX sysplex file sharing active).

The above isn't relevant to the question, but I felt like running off at
the keyboard.



On Thu, Apr 3, 2014 at 12:41 PM, Chase, John jch...@ussco.com wrote:

 Hi, List,

 z/OS 1.13 at RSU1312.  The other day, a user did something in ISPF that
 caused allocation of a Production JCL library to his TSO session with
 DISP=OLD instead of DISP=SHR, causing a hiccup in batch processing when
 the scheduler was locked out for a few seconds.  So far, we have not been
 able to replicate locking out another user at the dataset level via any
 combination of manipulations using (primarily) ISPF EDIT.

 Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!):

 014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045 EXPDT=0
 DISP=Old
 BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1 CTRI=CYL
 SQTY=50
 NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1 EXCP=4001
 STEP=tsoproc
 PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051

 The SMF 42-006 that immediately follows:

 042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records
 VOL=volser DSDEV=ccuu
 DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256 DSMXR=58
 DSMXS=57
 AMSRB=4000 AMSRR=2562

 The timestamps on those two records are identical down to hundredths of a
 second, so maybe the user was running a SuperC search?   We can't tell from
 evidence available to us today.

 We've tried every combination we can think of with multiple users ISPF
 EDITing the same dataset, and the only time we get any conflict is if a
 second user tries to open a MEMBER for EDIT that is already opened for EDIT
 by another user; and we believe that lockout at the member level is
 accomplished via an ENQ named SPFEDIT.membername or something like that.
  IOW, we have been unable to cause a dataset (PDS or PDSE) to be
 dynamically allocated with DISP=OLD using any variant of ISPF EDIT.

 Is there any other way within ISPF that an existing dataset can be
 dynamically allocated with DISP=OLD?  If there is, we apparently have never
 encountered it before.

 TIA,

 -jc-

 **
 Information contained in this e-mail message and in any attachments
 thereto is confidential. If you are not the intended recipient, please
 destroy this message, delete any copies held on your systems, notify the
 sender immediately, and refrain from using or disclosing all or any part of
 its content to any other person.

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




-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: IBM 8150?

2014-04-03 Thread Anne Lynn Wheeler

michaelpeterso...@gmail.com writes:
 It was the 1st Ibm PC. with floppies and 256 k ram and a monochrom screen

 On Monday, February 20, 1995 10:19:29 AM UTC-5, Chris Call wrote:
 Can anyone ID a machine for me?  It's an IBM8150.  It runs a system called 
 DCPX,
 and runs at least one application written in 3790 macro assembly language.

wow from 1995, must be april 1st 

8100 used UC (universal controller) ... also used in 3705 and 3081
service processor.
http://en.wikipedia.org/wiki/IBM_8100

above references that it ran two different incompatible systems, DPPX
and DPCX

at one point evans asked my wife to review it ... and shortly afterwards
it was decommited.

old email about MIT lisp group asking evans for 801/risc chips and he
offered 8100 instead.
http://www.garlic.com/~lynn/2003e.html#email790711

first ibm personal computer was 5100 ... done in 1973 
http://en.wikipedia.org/wiki/IBM_5100

by the palo alto science center ... it ran PALM processor ... emulating
subset of 360 and ran a version of apl/360. predating later better known
5150 introduced in 1981.
http://en.wikipedia.org/wiki/IBM_Personal_Computer

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: ISPF dynamically allocating dataset with DISP=OLD?

2014-04-03 Thread Bob Rutledge


Chase, John wrote:

Hi, List,

z/OS 1.13 at RSU1312.  The other day, a user did something in ISPF that caused allocation of a Production 
JCL library to his TSO session with DISP=OLD instead of DISP=SHR, causing a hiccup in batch processing when 
the scheduler was locked out for a few seconds.  So far, we have not been able to replicate locking 
out another user at the dataset level via any combination of manipulations using (primarily) ISPF EDIT.

Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!):

014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045 EXPDT=0 DISP=Old
BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1 CTRI=CYL SQTY=50
NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1 EXCP=4001 
STEP=tsoproc
PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051

The SMF 42-006 that immediately follows:

042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records VOL=volser 
DSDEV=ccuu
DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256 DSMXR=58 DSMXS=57
AMSRB=4000 AMSRR=2562

The timestamps on those two records are identical down to hundredths of a 
second, so maybe the user was running a SuperC search?   We can't tell from 
evidence available to us today.

We've tried every combination we can think of with multiple users ISPF EDITing the same dataset, 
and the only time we get any conflict is if a second user tries to open a MEMBER for 
EDIT that is already opened for EDIT by another user; and we believe that lockout at 
the member level is accomplished via an ENQ named SPFEDIT.membername or something like that.  IOW, 
we have been unable to cause a dataset (PDS or PDSE) to be dynamically allocated with DISP=OLD 
using any variant of ISPF EDIT.

Is there any other way within ISPF that an existing dataset can be dynamically 
allocated with DISP=OLD?  If there is, we apparently have never encountered it 
before.


DSBSZ in the 42-6 is the block size; 256 implies directory activity.  It doesn't 
smell like EDIT.


Bob

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

Re: ISPF dynamically allocating dataset with DISP=OLD?

2014-04-03 Thread Bob Rutledge


Bob Rutledge wrote:

DSBSZ in the 42-6 is the block size; 256 implies directory activity.  It 
doesn't smell like EDIT.


On third thought, what would happen if you CREATEd a new member at the beginning 
of the directory?


Bob

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

Re: ISPF dynamically allocating dataset with DISP=OLD?

On Thu, Apr 3, 2014 at 12:54 PM, John McKown
john.archie.mck...@gmail.comwrote:

 ISPF option 3.4, doing a z on a PDS to compress it will result in a
 DISP=OLD type allocation. This is the only thing that _I_ know of which
 does this.


Oh. How this is relevant to this scenario is if the user was editing a
member in the PDS and tried to save it. At this point, the DSN is allocated
and ENQ'd with a DISP=SHR. The user gets an Sx37 abend because the PDS is
out of space. So s?he splits the screen, goes into option 3.4, does a z
to compress the PDS. At this point, ISPF upgrades then already existing
ENQ on the already allocated PDS from a SHR to an OLD. Remember that the
user still has the DSN allocated in EDIT on the other screen. The compress
finishes. Until z/OS 2.1, it was _impossible_ to downgrade from an
exclusive ENQ (DISP=OLD) back to the shared ENQ (DISP=SHR). So the DSN is
now allocated to the user with a DISP=OLD until such time as it is freed.
Which may __OR MAY NOT__ happen when the user exits the EDIT on the member.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: IBM Explorer for z/OS - installation problems?

2014-04-03 Thread Tony Harminc

On 2 April 2014 23:28, Rob Schramm rob.schr...@gmail.com wrote:

 Right-click - run as administrator

Dang - I should've thought of that. Thanks! Though it would be a bit
nicer if it said something, rather then just going away silently.

OK - so now that I have it installed, I can't see what it's useful
for. It has a notepad-like editor that can edit PDS members and
sequential datasets (as long as they're not too big, it warns), and
UNIX text files. It can submit JCL, and has a different JCL editor
that can highlight some JCL keywords.

Other than that, it seems to be just another installation of Eclipse,
with all its Java-ish goodness, and broken locale baggage.

Has anyone found it useful for something? Am I missing a secret menu
somewhere that has the good stuff?

Tony H.

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

The automation product mentined here

2014-04-03 Thread Paul Peplinski

Who and what? I want to say Syzergy or something like that, but nothing is 
found in the archives or on Google. They have a full product and a freeware 
product at one time.

Paul P

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

Redirecting stdout to a data set?

2014-04-03 Thread Phil Smith

If I have a C program running in batch that does printf(), that output appears 
in a SYS1 data set in SPOOL. Is there a way to redirect that to a DASD data 
set? I tried STDOUT DD ... but it didn't seem to make a difference. Some 
Googling didn't find anything. Just seems so...obvious, but obviously I'm 
missing something?!
--
...phsiii

Phil Smith III
p...@voltage.commailto:p...@voltage.com
Voltage Security, Inc.


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

Re: The automation product mentined here

2014-04-03 Thread Mullen, Patrick

http://www.syzygyinc.com/


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Peplinski
Sent: Thursday, April 03, 2014 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: The automation product mentined here

Who and what? I want to say Syzergy or something like that, but nothing is 
found in the archives or on Google. They have a full product and a freeware 
product at one time.

Paul P 

--
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: OT - Rant

2014-04-03 Thread zMan

MostlyJoking
Please do us the courtesy of not ranting without referring to the post that
triggered the rant. It's not in your best interest to rant randomly (posts
lacking a referent), we are confused enough by topic drift on this list
[Note: LISTSERV is a trademark of L-SOFT, is not a noun that can be used
generically]. We are willing to do our best to provide fully defined
questions. Unreferenced rants are basically useless, if you want folks to
change.
/MostlyJoking


On Thu, Apr 3, 2014 at 8:40 AM, Scott Ford scott_j_f...@yahoo.com wrote:



 rant


 Please do us the courtesy by providing a FULL description of either your
 problem or question. Its not to your best interest to ask fluff questions (
 questions lacking substance ), we are technical of this Listserv. We are
 willing to help. One liners are basically useless, if you want help.




 /rant


 Scott

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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: Redirecting stdout to a data set?

Try SYSPRINT.
Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcpg1c0/2.8.9.1.2
quote

When you use DD statements to redirect standard streams, the standard
streams will be associated with ddnames as follows:

- stdin will be associated with the SYSIN ddname. If SYSIN is not
defined, no characters can be read in from stdin.

- *stdout* will be associated with the SYSPRINT ddname. If SYSPRINT is
not defined, the C library will try to associate *stdout* with SYSTERM,
and if SYSTERM is also not defined, the C library will try to associate
*stdout* with SYSERR. If any of the above DDstatements are used as the
MSGFILE DD, then that DD statement will not be considered for use as the
*stdout* DD.

*Restriction:* The reference to the MSGFILE does not apply to AMODE 64
applications.

- stderr will be associated with the MSGFILE, which defaults to SYSOUT.
See z/OS Language Environment Programming
Guidehttp://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOCNUM/SA22-7561/CCONTENTS?
for
more information on MSGFILE.

*Restriction:* The reference to the MSGFILE does not apply to AMODE 64
applications.

- If you are running with the run-time option POSIX(ON), you can
redirect standard streams with ddnames only for MVS data sets, not for UNIX
file system files.

- If the ddname for *stdout* is not allocated to a device or data set,
it is dynamically allocated to the terminal in an interactive environment
or to SYSOUT=* in an MVS batch environment.

Table
13http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcpg1c0/2.8.9.1.2?SHELF=CBCBS1C0.bksDT=20110614131446#TBLDDSTD
summarizes
the association of streams with ddnames:

Table 13. Association of standard streams with ddnames
*Standard*
*stream*
*ddname* *Alternate*
*ddname* stdinSYSIN
none *stdout* SYSPRINT
SYSTERM, SYSERR stderr

DD associated with MSGFILE. For AMODE
64 applications stderr is SYSOUT, and
there is no alternate ddname. None

/quote

On Thu, Apr 3, 2014 at 2:27 PM, Phil Smith p...@voltage.com wrote:

If I have a C program running in batch that does printf(), that output
appears in a SYS1 data set in SPOOL. Is there a way to redirect that to
a DASD data set? I tried STDOUT DD ... but it didn't seem to make a
difference. Some Googling didn't find anything. Just seems so...obvious,
but obviously I'm missing something?!
--
...phsiii

Phil Smith III
p...@voltage.commailto:p...@voltage.com
Voltage Security, Inc.

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

--
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: Redirecting stdout to a data set?

2014-04-03 Thread Phil Smith

Thank you John! Armed with that knowledge, this worked a treat:

//SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT)

...where that PDS is VB 1024 (but presumably doesn't need to be that long an 
LRECL).

That page you pointed to is what I had tried to find; it's sort of written 
sideways - When you use DD statements to redirect standard streams, the 
standard streams will be associated with ddnames as follows: seems like it 
would have made more sense as something like, When you write to standard 
streams, be aware that they map to the following DD names, and thus output 
written to those streams will be redirected if the matching DD is defined:

I like the example program, named HOCKEY!

Owe ya a beer at SCIDS.

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

Re: Redirecting stdout to a data set?

On Thu, Apr 3, 2014 at 3:15 PM, Phil Smith p...@voltage.com wrote:

 Thank you John! Armed with that knowledge, this worked a treat:

 //SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT)

 ...where that PDS is VB 1024 (but presumably doesn't need to be that long
 an LRECL).

 That page you pointed to is what I had tried to find; it's sort of written
 sideways - When you use DD statements to redirect standard streams, the
 standard streams will be associated with ddnames as follows: seems like it
 would have made more sense as something like, When you write to standard
 streams, be aware that they map to the following DD names, and thus output
 written to those streams will be redirected if the matching DD is defined:


RCF time?



 I like the example program, named HOCKEY!

 Owe ya a beer at SCIDS.


It'll need to be a virtual beer. I don't attend Share (unless _I_ pay all
expenses and use vacation time - IDTS), and I don't drink alcohol
(diabetic).

ITDS == I Don't Think So.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: Redirecting stdout to a data set?

IIRC, there is not only the standard assignment of

stdin == DD:SYSIN
stdout == DD:SYSPRINT
stderr == DD:CEEMSGS

but furthermore you can, like on Unix and Windows platforms,
redirect stdin and stdout using the and characters on the JCL parm ...
at least if you have some compile or run time options properly set ...

that is:

// EXEC SAMPLE,PARM='/ DD:INPUT DD:OUTPUT '

should in my opinion redirect stdin to

//INPUT DD ...

and stdout to

//OUTPUT DD ...

if SAMPLE is a C main.

Using other syntax, you can specify DSNs instead of DD-Names
on the redirection (TSO syntax, with or without quotes).

Had no time to try it ...

of course, it's not that useful, because of the length limitations on
the JCL parm;

we overcome this by writing a small program which reads a long parm from a
file and calls the C main (name specified on parm) using a system() call.
This way there is no limit on the length of the parm.

Kind regards

Bernd

Am 03.04.2014 22:15, schrieb Phil Smith:

Thank you John! Armed with that knowledge, this worked a treat:

//SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT)

...where that PDS is VB 1024 (but presumably doesn't need to be that long an
LRECL).

That page you pointed to is what I had tried to find; it's sort of written sideways - When
you use DD statements to redirect standard streams, the standard streams will be associated with
ddnames as follows: seems like it would have made more sense as something like, When
you write to standard streams, be aware that they map to the following DD names, and thus output
written to those streams will be redirected if the matching DD is defined:

I like the example program, named HOCKEY!

Owe ya a beer at SCIDS.

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

Re: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 15:36:48 -0500, John McKown wrote:

On Thu, Apr 3, 2014 at 3:15 PM, Phil Smith wrote:

 Thank you John! Armed with that knowledge, this worked a treat:

 //SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT)

 ...where that PDS is VB 1024 (but presumably doesn't need to be that long
 an LRECL).

This discussion raises a question in my mind.  In POSIX (I think), I read:


http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_05

 B.2.5 Standard I/O Streams

Although the ISO C standard guarantees that, at program start-up, stdin is open 
for reading and stdout and stderr are open for writing, this guarantee is 
contingent (as are all guarantees made by the ISO C and POSIX standards) on the 
program being executed in a conforming environment. Programs executed with file 
descriptor 0 not open for reading or with file descriptor 1 or 2 not open for 
writing are executed in a non-conforming environment. Application writers are 
warned (in exec, posix_spawn, and Redirection) not to execute a standard 
utility or a conforming application with file descriptor 0 not open for reading 
or with file descriptor 1 or 2 not open for writing.

OK.  So suppose I compile, link and execute my program with all available POSIX
enablement options.  In that program, I code:

system( ls );

ls surely expects to be able to write to descriptor 1.  Does executing a POSIX
program from JCL guarantee that descriptor 1 is available to be inherited by
the forked child?  If not, where's the weasel-wording that says it doesn't need 
to?
Or, does the C RTL at startup go through the DDNAME search mentioned earlier
in this thread?  Wait!  it's worse!  DDNAMEs are not inherited on fork().

-- gil

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

Re: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 22:45:52 +0200, Bernd Oppolzer wrote:

IIRC, there is not only the standard assignment of

stdin == DD:SYSIN
stdout == DD:SYSPRINT
stderr == DD:CEEMSGS
 
Long ago, when I was a novice to MVS, and in a different language,
my mentor impelled such choices, at least the first two.  Looking
back, I now believe Simpler Is Better, and the choices should have
been (as BPXBATCH chose):

stdin == DD:STDIN
stdout == DD:STDOUT
stderr == DD:STDERR

... don't inflict MVS-think on other cultures.

but furthermore you can, like on Unix and Windows platforms,
redirect stdin and stdout using the  and  characters on the JCL parm ...
at least if you have some compile or run time options properly set ...

that is:

//   EXEC SAMPLE,PARM='/  DD:INPUT DD:OUTPUT '
 
BPXWUNIX performs splendidly mapping the standard descriptors
to arbitrary DDNAMEs (although many programmers are accustomed
to using only Rexx compound variables).  I wonder how it does it?
The streams are not buffered; I can assign them to different SYSOUT
data sets and monitor them with SDSF in real time.

-- gil

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

Executing a remote TSO command or CLIST with FTP?

2014-04-03 Thread Charles Mills

Just confirming what I RTFM: there is no way for an FTP client to directly
execute a TSO command on a remote z/OS system - is that right? Is there some
clever hack that I am missing?

 

This would be real useful, no? The ability - in this case, what I am trying
to do - to upload a TSO XMIT file and then run a RECEIVE on it.

 

Yes, I know I can run a job on the remote machine and the job could be batch
TSO. I am looking for something a little more straightforward than that.

 

Thanks,

 

Charles 


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

Re: Redirecting stdout to a data set?


The C RTL looks at startup for a DDName not already in
use. If SYSPRINT, for example, is already used (for example
by a PL/1 program calling the C module), the C RTL uses another
DDName, SYS1, SYS2, SYS3 and so on.

This lead to some headaches at our site, when we tried to redirect
trace output (on stdout = SYSPRINT) to a dataset. But because
SYSPRINT was already opened by PL/1, C used SYS1 and
allocated it to the display terminal ... this was an IMS/DC environment.
So the messages appeared on the screen. There was no way to
do an allocation to a file, because the C RTL always rejected the
DDName already allocated and chose the next free one ... and
allocated it to the display terminal.

The only way to solve this problem was: doing all the trace output
by a PL/1 procedure called by the C function ... no printf, but a
printf-compatible replacement for printf, issuing PL/1-PUT. This
way, SYSPRINT was used, and the redirection worked.

This was very early in the 1990s .. I'm almost sure, that this is not the
case any more. Because PL/1 changed to LE in the meantime, things
are now different.

But: we still have the problem, that the trace output from PL/1-PUT
and C printf are not in sync ... that is: due to different buffering in
the PL/1 and C RTL, the trace output does not appear in the correct time 
order.


Kind regards

Bernd



Am 03.04.2014 22:48, schrieb Paul Gilmartin:

On Thu, 3 Apr 2014 15:36:48 -0500, John McKown wrote:


On Thu, Apr 3, 2014 at 3:15 PM, Phil Smith wrote:


Thank you John! Armed with that knowledge, this worked a treat:

//SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT)

...where that PDS is VB 1024 (but presumably doesn't need to be that long
an LRECL).


This discussion raises a question in my mind.  In POSIX (I think), I read:

 
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_05

  B.2.5 Standard I/O Streams

Although the ISO C standard guarantees that, at program start-up, stdin is open 
for reading and stdout and stderr are open for writing, this guarantee is 
contingent (as are all guarantees made by the ISO C and POSIX standards) on the 
program being executed in a conforming environment. Programs executed with file 
descriptor 0 not open for reading or with file descriptor 1 or 2 not open for 
writing are executed in a non-conforming environment. Application writers are 
warned (in exec, posix_spawn, and Redirection) not to execute a standard 
utility or a conforming application with file descriptor 0 not open for reading 
or with file descriptor 1 or 2 not open for writing.

OK.  So suppose I compile, link and execute my program with all available POSIX
enablement options.  In that program, I code:

 system( ls );

ls surely expects to be able to write to descriptor 1.  Does executing a POSIX
program from JCL guarantee that descriptor 1 is available to be inherited by
the forked child?  If not, where's the weasel-wording that says it doesn't need 
to?
Or, does the C RTL at startup go through the DDNAME search mentioned earlier
in this thread?  Wait!  it's worse!  DDNAMEs are not inherited on fork().

-- gil

--
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: Executing a remote TSO command or CLIST with FTP?

On Thu, 3 Apr 2014 14:03:24 -0700, Charles Mills wrote:

Just confirming what I RTFM: there is no way for an FTP client to directly
execute a TSO command on a remote z/OS system - is that right? Is there some
clever hack that I am missing?

This would be real useful, no? The ability - in this case, what I am trying
to do - to upload a TSO XMIT file and then run a RECEIVE on it.

Yes, I know I can run a job on the remote machine and the job could be batch
TSO. I am looking for something a little more straightforward than that.

ssh.  I regularly issue:

( cd local-directory amp; tar -cf - . ) | ssh user@remote cd remote 
directory amp; tar -xvf -

(but not so much on z/OS as on other OSes).

The PITA with RECEIVE is replying to the PITA prompt.

(I'd hardly be surprised to hear a better suggestion from Dovetailed.)

-- gil

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

Re: Executing a remote TSO command or CLIST with FTP?

On Thu, Apr 3, 2014 at 4:03 PM, Charles Mills charl...@mcn.org wrote:

 Just confirming what I RTFM: there is no way for an FTP client to directly
 execute a TSO command on a remote z/OS system - is that right? Is there
 some
 clever hack that I am missing?


There is no clever hack to allow remote execution via ftp. Other than
submitting a batch job to do something and then getting the output back via
ftp.



 This would be real useful, no? The ability - in this case, what I am trying
 to do - to upload a TSO XMIT file and then run a RECEIVE on it.


Yes, people who hack systems would love such a facility.



 Yes, I know I can run a job on the remote machine and the job could be
 batch
 TSO. I am looking for something a little more straightforward than that.


This is the right an proper way to do this when using ftp.




 Thanks,

 Charles


-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

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: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 23:05:28 +0200, Bernd Oppolzer wrote:

But: we still have the problem, that the trace output from PL/1-PUT
and C printf are not in sync ... that is: due to different buffering in
the PL/1 and C RTL, the trace output does not appear in the correct time
order.
 
Don't know about legacy data sets; don't know about PL/[1I], but if I
use UNIX files and sprintf(); write(); I expect more orderly results.

fflush(); might also help.

setvbuf( stream, NULL, _IOLBF, ... ); might likewise help.

-- gil

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

NetView TAF and TSO using ACF2 (UNCLASSIFIED)

2014-04-03 Thread Storr, Lon A CTR USARMY HRC (US)

Classification: UNCLASSIFIED
Caveats: NONE

Hello List,

Do any of you have an automated process that establishes a NetView TAF session 
to TSO using ACF2 as the security product?

IBM provides sample CNMS1098 that establishes a TAF session to TSO (using a 
PIPE to issue BGNSESS and the VET stage) but (naturally) the expected security 
product is RACF; the sample REXX chokes because the sequence of ACF2 displays 
is not identical to RACF.

Has anybody modified IBM's sample CNMS1098 REXX to work with ACF2?

Thanks,
Alan

P.S. I realize that this is an MVS forum but hope that some of you may also be 
familiar with NetView

Classification: UNCLASSIFIED
Caveats: NONE

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

Re: Executing a remote TSO command or CLIST with FTP?

On 2014-04-03 15:16, Scott Ford wrote:
 Charles:
 
 FTP exit ?  Just a guess …
  
That's getting perilously close to RYO.  At a minimum it requires
that you have control over configuration of the remote system to
install such an exit.

Lately, z/OS FTP has support for named pipes.  Again, this requires
that you be able to set up a receiver at the server end.

-- gil

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

Re: Redirecting stdout to a data set?


The problem is that the physical writes to the output streams
are deferred, and you don't have full control about the flushing of
the buffers, at least it does not work in the way we expect it.
This is no problem of the legacy data sets; it's only a problem of
the two RTLs, both writing to SYSPRINT (for example) and both
doing their own buffering. When we moved all the C printf work
to PL/1-PUT in the past (by our own printf replacement), all worked
well, of course.

The problem is not that important; we separated the trace output
to different DD-Names (PL/1: DRTRACE, C: CEEMSGS), and
we don't need to correlate the trace output ... in fact, there are not that
many calls when we cross borders (PL/1 to C and back), but large
time frames, when we stay within one language (normal business
logic in PL/1, insurance math service routines in C).

Other important features: the trace output can dynamically be activated
from outside (job control) on a per module base; different trace levels
are supported. No recompile needed. Activating traces is possible
even in production environment. This turned out to be very important
and helpful in error diagnosis.

Kind regards

Bernd



Am 03.04.2014 23:21, schrieb Paul Gilmartin:

On Thu, 3 Apr 2014 23:05:28 +0200, Bernd Oppolzer wrote:

But: we still have the problem, that the trace output from PL/1-PUT
and C printf are not in sync ... that is: due to different buffering in
the PL/1 and C RTL, the trace output does not appear in the correct time
order.


Don't know about legacy data sets; don't know about PL/[1I], but if I
use UNIX files and sprintf(); write(); I expect more orderly results.

fflush(); might also help.

setvbuf( stream, NULL, _IOLBF, ... ); might likewise help.

-- gil

--
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: Using DB2 and MQ under JZOS

2014-04-03 Thread Ward, Mike S

You can write a batch program either assembler or cobol that can talk to MQ. We 
have several here that do it. All you have to do is provide the correct copy 
libraries for compile/assemble and the correct bin libraries for linking. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mohammad Khan
Sent: Thursday, April 03, 2014 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Using DB2 and MQ under JZOS

Hi Denis,
Thanks for your response. I'm not trying to write my own transaction manager 
rather I'm hoping to use RRS in that role, after all RRS is already being used 
for DB2 access. Now if Java does not provide any means of using RRS to 
coordinate multiple resources I guess I'm out of luck. I'll probably have to 
use DB2 provided functions to write to MQ. 
 BTW we do have batch cobol programs at our site that access both DB2 and MQ 
though that's all I know about them. May be these programs have their own 
transaction management code but I find it very odd that these would not be 
transactionally sound. But who knows, reality is not limited by anyone's 
ability to conceive it.
 As for using an environment other that batch, this process was implemented in 
WAS/z but the cpu consumption killed the project. I don't know how much of that 
was WAS overhead and how much was due to the application code. My batch Java 
code does everything except for writing one message to MQ for about a fourth of 
the cost.
 Does Spring offer some kind of transactional facility ? I thought it was just 
a sql generator.
Regards
Mohammad

On Wed, 2 Apr 2014 12:05:36 -0400, Denis Gäbler denisgaeb...@netscape.net 
wrote:

Hi,

what you are trying to achieve is the task of a transaction manager. Keep 
multiple resources (MQ, DB2) in sync.
What would you do to do the same thing from a COBOL application? TSO batch 
does not provide this functionality either.
RRS provides this functionality, but there is no API for it that you could use 
from pure Java.

As an example, instead of using JZOS you could run the Java application in IMS 
Java Regions, CICS, DB2 Java Stored Procedure or WebSphere z/OS.
What can also be considered is using a Java based persistence framework, e.g. 
Spring to keep the resources in sync.

In the end you could also write your own transaction manager.

Hope that helps,

Denis.

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: Executing a remote TSO command or CLIST with FTP?

2014-04-03 Thread Charles Mills

 Yes, people who hack systems would love such a facility.

I strongly disagree. 

If you can get logged onto a z/OS system with FTP you are 99% of the way to 
hacker nirvana anyway. The ability to submit TSO commands would be no more of a 
threat than the ability to retrieve files (RACF password database anyone?), run 
shell commands, or run batch jobs. It could be protected with a SAF profile.

Perhaps I need to clarify: by clever hack I did not mean some defeat of the 
Statement of Integrity. I meant something clever along the lines of what Gil 
suggested, you can run a shell command, and from there you can run a TSO 
command by blah blah.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, April 03, 2014 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Executing a remote TSO command or CLIST with FTP?

On Thu, Apr 3, 2014 at 4:03 PM, Charles Mills charl...@mcn.org wrote:

 Just confirming what I RTFM: there is no way for an FTP client to 
 directly execute a TSO command on a remote z/OS system - is that 
 right? Is there some clever hack that I am missing?


There is no clever hack to allow remote execution via ftp. Other than 
submitting a batch job to do something and then getting the output back via ftp.



 This would be real useful, no? The ability - in this case, what I am 
 trying to do - to upload a TSO XMIT file and then run a RECEIVE on it.


Yes, people who hack systems would love such a facility.



 Yes, I know I can run a job on the remote machine and the job could be 
 batch TSO. I am looking for something a little more straightforward 
 than that.


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

need pub to help me with a REXX exec

2014-04-03 Thread John Norgauer

Can someone point me to a pub that explains how to debug and/or trace a 
REXX exec?

Thanks.



John Norgauer
Senior Systems Programmer
Mainframe Technical Support Services
University of California Davis Medical Center
1651 Alhambra Blvd
Suite 200
Sacramento, Ca 95816
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! JN  2004

Hardware eventually breaks - Software eventually works  anon


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

Re: Redirecting stdout to a data set?

2014-04-03 Thread zMan

Just curious: why not just put granular timestamps on the messages?
Wouldn't that have been simpler?


On Thu, Apr 3, 2014 at 5:37 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:

 The problem is that the physical writes to the output streams
 are deferred, and you don't have full control about the flushing of
 the buffers, at least it does not work in the way we expect it.
 This is no problem of the legacy data sets; it's only a problem of
 the two RTLs, both writing to SYSPRINT (for example) and both
 doing their own buffering. When we moved all the C printf work
 to PL/1-PUT in the past (by our own printf replacement), all worked
 well, of course.

 The problem is not that important; we separated the trace output
 to different DD-Names (PL/1: DRTRACE, C: CEEMSGS), and
 we don't need to correlate the trace output ... in fact, there are not that
 many calls when we cross borders (PL/1 to C and back), but large
 time frames, when we stay within one language (normal business
 logic in PL/1, insurance math service routines in C).

 Other important features: the trace output can dynamically be activated
 from outside (job control) on a per module base; different trace levels
 are supported. No recompile needed. Activating traces is possible
 even in production environment. This turned out to be very important
 and helpful in error diagnosis.

 Kind regards

 Bernd



 Am 03.04.2014 23:21, schrieb Paul Gilmartin:

  On Thu, 3 Apr 2014 23:05:28 +0200, Bernd Oppolzer wrote:

 But: we still have the problem, that the trace output from PL/1-PUT
 and C printf are not in sync ... that is: due to different buffering in
 the PL/1 and C RTL, the trace output does not appear in the correct time
 order.

  Don't know about legacy data sets; don't know about PL/[1I], but if I
 use UNIX files and sprintf(); write(); I expect more orderly results.

 fflush(); might also help.

 setvbuf( stream, NULL, _IOLBF, ... ); might likewise help.

 -- gil

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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: need pub to help me with a REXX exec

On Thu, 3 Apr 2014 15:58:59 -0700, John Norgauer 
john.norga...@ucdmc.ucdavis.edu wrote:

Can someone point me to a pub that explains how to debug and/or trace a
REXX exec?

TRACE
z/OS TSO/E REXX Reference
SA32-0972-00
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/dup0018.htm
 

I will strongly recommend that you begin every Rexx EXEC with

signal on novalue

... and leave it in force throughout.  (IIRC, Shmuel disagrees with this.)

-- gil

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

Re: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 19:00:00 -0400, zMan wrote:

Just curious: why not just put granular timestamps on the messages?
Wouldn't that have been simpler?
 
Perhaps.  Depends on how many places messages are issued.  If they
all funnel through a single formatting routine, easy.

BTW, I understand that SMF logs have no consistent timestamps.
IIRC, JWG has defended this malpractice based on the tradeoff
between sometimes needless granularity and bandwidth.

-- gil

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

Re: Redirecting stdout to a data set?


If you read the previous posts, the issue with the time order of
the messages was not the only issue. More important was the
problem, that the trace messages from C appeared on the screen
in the IMS/DC sessions, because the PL/1 modules had already opened
SYSPRINT, and so C used SYS1 ... this way the messages
could not be redirected to a dataset. By replacing the printf calls
in C by a function called CPUT which had the same signature as
printf (but called a PL/1 function issuing PL/1-PUT under the cover),
we redirected the C output to SYSPRINT and solved two problems:

a) the redirection problem ... trace output going to a dataset instead
of appearing on the screen

b) the time order of the messages was correct

This was in the first half of the 1990s. PL/1 had its own runtime,
and the C runtime was that what later should become LE.

When PL/1 later switched to LE, things got different, and we removed
CPUT, because printf now worked. The redirection problem disappeared,
but the time order problem remained. But this was considered no big
problem.

Kind regards

Bernd



Am 04.04.2014 01:00, schrieb zMan:

Just curious: why not just put granular timestamps on the messages?
Wouldn't that have been simpler?


On Thu, Apr 3, 2014 at 5:37 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:


The problem is that the physical writes to the output streams
are deferred, and you don't have full control about the flushing of
the buffers, at least it does not work in the way we expect it.
This is no problem of the legacy data sets; it's only a problem of
the two RTLs, both writing to SYSPRINT (for example) and both
doing their own buffering. When we moved all the C printf work
to PL/1-PUT in the past (by our own printf replacement), all worked
well, of course.



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

Re: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:

Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.

I don't believe that.  Must I try it?

Almost no one uses lines longer than 132 characters.

FSVO 132

VBA 133 should work unless you have an application that uses long print lines.

Heck, VBA 65 should work except when it doesn't.

-- gil

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

Re: Redirecting stdout to a data set?

On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:

Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.

Nope.  An SDSF display:

 SDSF OUTPUT DISPLAY userGENR JOB07738  DSID   103 LINE 0   COLUMNS 421- 
552
 COMMAND INPUT ===SCROLL === CSR  

* TOP OF DATA 
*
 
n #     --   --- #  $X1= 
D136984  R8BASEN  060303 ADAMSON : JES NJE over TCP/IP 
9/tcp   sink null discard 9/udp   sink null systat  
11/tcp  users daytime 13/tcp day
 42/tcp  name# IEN 116 whois   43/tcp  
nicname domain  53/tcp  nameserver   
 111/tcp sunrpc  111/udp auth113/tcp 
authentication sftp115/tcp uucp-path   117/
 1512/udp comsat login   513/tcp who 
513/udp whod shell   514/tcp cmd   

(Some of my lines may have contained non-printable characters, but I'm
confident that some line contained at least 241 printable characters.)

Almost no one uses lines longer than 132 characters.
VBA 133 should work unless you have an application that uses long print lines.

... unless ...
(Please don't ask, Who has a printer with that many hammers, anyway?)

-- gil

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

Re: Redirecting stdout to a data set?

2014-04-03 Thread Mike Schwab

Hmmm.  Must have been the Xerox printer limit then.

On Thu, Apr 3, 2014 at 7:33 PM, Paul Gilmartin paulgboul...@aim.com wrote:
 On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:

Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.

 Nope.  An SDSF display:

  SDSF OUTPUT DISPLAY userGENR JOB07738  DSID   103 LINE 0   COLUMNS 421- 
 552
  COMMAND INPUT ===SCROLL === CSR
 * TOP OF DATA 
 *
 n #     --   --- #  $X1= 
 D136984  R8BASEN  060303 ADAMSON : JES NJE over TCP/IP
 9/tcp   sink null discard 9/udp   sink null systat
   11/tcp  users daytime 13/tcp day
  42/tcp  name# IEN 116 whois   43/tcp 
  nicname domain  53/tcp  nameserver
  111/tcp sunrpc  111/udp auth113/tcp 
 authentication sftp115/tcp uucp-path   117/
  1512/udp comsat login   513/tcp who 
 513/udp whod shell   514/tcp cmd

 (Some of my lines may have contained non-printable characters, but I'm
 confident that some line contained at least 241 printable characters.)

Almost no one uses lines longer than 132 characters.
VBA 133 should work unless you have an application that uses long print lines.

 ... unless ...
 (Please don't ask, Who has a printer with that many hammers, anyway?)

 -- gil

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



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

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

Re: Redirecting stdout to a data set?

2014-04-03 Thread zMan

Ah, sorry. Missed that detail.

At least this topic hasn't drifted...


On Thu, Apr 3, 2014 at 7:48 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:

 If you read the previous posts, the issue with the time order of
 the messages was not the only issue. More important was the
 problem, that the trace messages from C appeared on the screen
 in the IMS/DC sessions, because the PL/1 modules had already opened
 SYSPRINT, and so C used SYS1 ... this way the messages
 could not be redirected to a dataset. By replacing the printf calls
 in C by a function called CPUT which had the same signature as
 printf (but called a PL/1 function issuing PL/1-PUT under the cover),
 we redirected the C output to SYSPRINT and solved two problems:

 a) the redirection problem ... trace output going to a dataset instead
 of appearing on the screen

 b) the time order of the messages was correct

 This was in the first half of the 1990s. PL/1 had its own runtime,
 and the C runtime was that what later should become LE.

 When PL/1 later switched to LE, things got different, and we removed
 CPUT, because printf now worked. The redirection problem disappeared,
 but the time order problem remained. But this was considered no big
 problem.

 Kind regards

 Bernd



 Am 04.04.2014 01:00, schrieb zMan:

  Just curious: why not just put granular timestamps on the messages?
 Wouldn't that have been simpler?


 On Thu, Apr 3, 2014 at 5:37 PM, Bernd Oppolzer
 bernd.oppol...@t-online.dewrote:

  The problem is that the physical writes to the output streams
 are deferred, and you don't have full control about the flushing of
 the buffers, at least it does not work in the way we expect it.
 This is no problem of the legacy data sets; it's only a problem of
 the two RTLs, both writing to SYSPRINT (for example) and both
 doing their own buffering. When we moved all the C printf work
 to PL/1-PUT in the past (by our own printf replacement), all worked
 well, of course.


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




-- 
zMan -- I've got a mainframe and I'm not afraid to use it

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

Re: need pub to help me with a REXX exec

2014-04-03 Thread Lizette Koehler

John,

You may wish to join the TSO REXX list.  It is full of people that just love
REXX coding.

Go to the bottom of this webpage to join
http://vm.marist.edu/htbin/wlvindex?TSO-REXX

You may also wish to check out RExx-LA  http://www.rexxla.org/

 

Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of John Norgauer
 Sent: Thursday, April 03, 2014 3:59 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: need pub to help me with a REXX exec
 
 Can someone point me to a pub that explains how to debug and/or trace a
REXX
 exec?
 
 Thanks.
 
 
 
 John Norgauer
 Senior Systems Programmer
 Mainframe Technical Support Services
 University of California Davis Medical Center
 1651 Alhambra Blvd
 Suite 200
 Sacramento, Ca 95816
 916-734-0536

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

Re: need pub to help me with a REXX exec

2014-04-03 Thread Jon Perryman

The REXX reference mentioned below has a chapter on debugging aids which has 
various. E.g. in TSO, pressing the attention key breaks into an exec which 
allows you to enter REXX statements on the fly (e.g. changing trace, set 
variables, HE, HT and others).

Jon Perryman. 




 From: Paul Gilmartin paulgboul...@aim.com



On Thu, 3 Apr 2014 15:58:59 -0700, John Norgauer 
john.norga...@ucdmc.ucdavis.edu wrote:
Can someone point me to a pub that explains how to debug and/or trace a
REXX exec?

TRACE
z/OS TSO/E REXX Reference
SA32-0972-00
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ikja300/dup0018.htm
 


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

Re: ISPF dynamically allocating dataset with DISP=OLD?

2014-04-03 Thread Lizette Koehler

Did they compress the dataset in ISPF 3.4?

Lizette

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Chase, John
 Sent: Thursday, April 03, 2014 10:42 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: ISPF dynamically allocating dataset with DISP=OLD?

 Hi, List,

 z/OS 1.13 at RSU1312.  The other day, a user did something in ISPF that
caused
 allocation of a Production JCL library to his TSO session with DISP=OLD
instead of
 DISP=SHR, causing a hiccup in batch processing when the scheduler was
 locked out for a few seconds.  So far, we have not been able to
replicate locking
 out another user at the dataset level via any combination of
manipulations using
 (primarily) ISPF EDIT.

 Here's a SMF14 record formatted by DAF (Thank you, Michael J. Cleary!!):

 014 VOL=volser DD=ISP15297 OPE=15.30.06.51 CRTDT=02045
 EXPDT=0 DISP=Old
 BUFNO=16 DSORG=PO RECFM=FB BLKSIZE=7520 LRECL=80 NVOL=1
 CTRI=CYL SQTY=50
 NTU=00582800 NTA=6000 VOL=OPER9A DEVTYPE=3390 NEX=1
 EXCP=4001 STEP=tsoproc
 PGM=IKJEFT01 14XF1=192 14CIS=18090271 14TKL=58051

 The SMF 42-006 that immediately follows:

 042 006 JDCOD=Close DSTYP=PDS DSFL1=Non-VSAM_fixed_length_records
 VOL=volser DSDEV=ccuu
 DSBSZ=256 DSIOR=9 DSIOC=7 DSIOP=1 DSION=256 DSSEQ=256
 DSMXR=58 DSMXS=57
 AMSRB=4000 AMSRR=2562

 The timestamps on those two records are identical down to hundredths of a
second,
 so maybe the user was running a SuperC search?   We can't tell from
evidence
 available to us today.

 We've tried every combination we can think of with multiple users ISPF
EDITing the
 same dataset, and the only time we get any conflict is if a second user
tries to
 open a MEMBER for EDIT that is already opened for EDIT by another user;
and we
 believe that lockout at the member level is accomplished via an ENQ
named
 SPFEDIT.membername or something like that.  IOW, we have been unable to
 cause a dataset (PDS or PDSE) to be dynamically allocated with DISP=OLD
using
 any variant of ISPF EDIT.

 Is there any other way within ISPF that an existing dataset can be
dynamically
 allocated with DISP=OLD?  If there is, we apparently have never
encountered it
 before.

 TIA,

 -jc-

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

Re: need pub to help me with a REXX exec

2014-04-03 Thread Thomas Conley


On 4/3/2014 6:59 PM, John Norgauer wrote:

Can someone point me to a pub that explains how to debug and/or trace a
REXX exec?

Thanks.


John,

The TSO/E Rexx Reference describes the Rexx TRACE command.  My personal 
favorite is trace i.


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: AW: Re: ISPF dynamically allocating dataset with DISP=OLD?

2014-04-03 Thread Hank Oerlemans

The behavior can be demonstrated with the PDS utility and leaving off the 
SHR parameter when specifying COMPRESS.


Don't blame ISPF. The critical thing is DISP=OLD allocation occurring 
after a DISP=SHR.

Hank O

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

Re: Executing a remote TSO command or CLIST with FTP?

2014-04-03 Thread Itschak Mugzach

Have a look at zen ftp control from william data systems that among othrr
things allow remote execution. It used ftp exit.

Itschak
בתאריך 4 באפר 2014 08:15, Paul Gilmartin paulgboul...@aim.com כתב:

 On Fri, 4 Apr 2014 00:15:21 -0400, Scott Ford wrote:
 
 Doesn't Connect Direct or whatever it's called do that, let you transfer
 a file and submit a job..?
 
 Is that the 7171/IND$FILE protocol?  Does it require that you be logged in
 with a TSO or CMS session hanging at a READY prompt?

 Kermit does (if it's still around) something similar.

 -- gil

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

Is there any MF shop using AWS service?

2014-04-03 Thread Tsai Laurence

Dears,
as the subject, if your shop using AWS service, what is it? Backup svc?
Solution ?

Laurence 蔡宗志 from my HTC

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

Re: Executing a remote TSO command or CLIST with FTP?