Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)

2021-01-20 Thread Paul Gilmartin
On Wed, 20 Jan 2021 13:13:44 -0500, David Spiegel wrote:

>"... Formerly some utilities (Linkage Editor?) imposed a limit of 3120. ..."
>Linkage Editor //SYSLIN had a Max BLKSIZE of 3200.
> 
I stand corrected.

Damn!  So I was needlessly using 3120 all those years.

It's mentioned (in an example) in:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bdta500/bdta50085.htm

-- gil

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


Re: TSO XMIT and no member list

2021-01-20 Thread Paul Gilmartin
On Wed, 20 Jan 2021 17:15:26 +, Seymour J Metz wrote:

> > Would it be proper first to do BPXWDYN( INFO SYSPRINT ... )
>> and finally restore it to its initial state in case it hadn't been DSN(*)?
>
>Yes, but if you use the SYSOUT keyword then you don't need to reallocate 
>SYSPRINT in the first place.
> 
Is there a form to select in batch TSO the class chosen by the JCL OUTPUT
statement as I've done in JCL with:
//SYSPRINT  DD  SYSOUT=(,)
???

-- gil

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


Re: TSO RECEIVE and System Determined Blksize (was: TSO XMIT and no member list)

2021-01-20 Thread Paul Gilmartin
On Wed, 20 Jan 2021 10:03:01 -0600, Wendell Lovewell wrote:
>
>Could you please elaborate on your comment "never solved issue like non-SDB 
>(system determined blocksize) in XMIT and RECEIVE command"? 
>
Long ago there were discussions here of ISPF SUBMIT's failing because
of inadequate (default?) SPACE for its workfiles.  The same might apply
to TRANSMIT.  Likewise old utilities might have hardcoded BLKSIZE
(3120?  6144?) suboptimal for recent DASD.  But if such utilities were
changed to BLKSIZE=0 the larger values supplied by SDB might cause
downstream programs to fail.

Formerly some utilities (Linkage Editor?) imposed a limit of 3120.

I had some Rexx programs fail when EXECIO removed its internal
BLKSIZE computation to let SDB operate.  Rapidly fixed by APAR,
but Support advised "Always code BLKSIZE."  An ironic consequence
of SDB.

>I have been having an issue with TSO RECEIVE (and a program that also calls 
>IEBCOPY) when SDB is "Y".  IEBCOPY is having some sort of problem and 
>displaying this message:
>
>IEB1139W THE OUTPUT DATA SET BLOCK SIZE IS BEING REDUCED FROM 32720 TO 27920 
>BYTES.  ANY EXISTING PHYSICAL RECORDS
> LONGER THAN 27920 BYTES ARE FAT BLOCKS AND MAY CAUSE I/O ERRORS.
>
>and ending with a return code of 4.  The dataset being RECEIVEd is actually 
>fine, as the LRECL is always less than 27920 (80 in this case).  But RECEIVE 
>sees the RC=4 from IEBCOPY and ends with RC=12.  
>
>IBM currently has case number TS004689510 open for this, but I assumed it was 
>a new issue although I only have SDB=Y on right now for testing.  

-- gil

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


Re: TSO XMIT and no member list

2021-01-20 Thread Paul Gilmartin
On Wed, 20 Jan 2021 05:43:20 -0500, David Spiegel wrote:
>
>ALLOC F(SYSPRINT) DA(DUMMY) REU
>XMIT ...
>ALLOC F(SYSPRINT) DA(*) REU
> 
Would it be proper first to do BPXWDYN( INFO SYSPRINT ... )
and finally restore it to its initial state in case it hadn't been DSN(*)?
(DISP(MOD) if it had been a data set.)

Is it necessary to CLOSE a file before REUSing it?

It's a shame there's no way to provide an alternate DDNAME list
(a poor substitute for redirection) to that IEBCOPY.

Does DSN(*) write via TPUT?  PUTLINE?  Other (specify)?
Does OUTTRAP work with DSN(*)?

-- gil

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


Re: TSO XMIT and no member list

2021-01-19 Thread Paul Gilmartin
On Wed, 20 Jan 2021 00:55:59 +0100, R.S. wrote:

>I want to switch off member list when TSO XMIT ... DA(SOME.PDS) is running?
>I just want to issue the command and I don't want to see loong
>member list on the screen.
>Any clue?
>
OUTTRAP?

-- gil

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


Re: Actual signs set by the DP (divide decimal) instruction

2021-01-19 Thread Paul Gilmartin
On Tue, 19 Jan 2021 11:40:34 -0600, John Ganci wrote:
>...
>"The sign of the quotient is determined by the rules of algebra. The sign of 
>the remainder has the same value as the dividend sign. These rules hold even 
>when the quotient or remainder is zero."
>
Does this guarantee the conventional A % D * D + A // D == A, for all
four combinations of signs of A and D?

(Rexx operators: "%" for integer division; "//" for remainder.)

-- gil

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


Re: JCL to tar USS directory

2021-01-15 Thread Paul Gilmartin
On Fri, 15 Jan 2021 19:39:41 +, Frank Swarbrick wrote:

>
>From the z/OS Unix System Services Command Reference 
>(https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa500/bpxbatr.htm):
>
>  *   It must be a text file defined with read access only
>
So, must I have a RACF rule prohibiting write access, or what?
Or prohibit write and execute access with UNIX mode bits?
WTF!?

>  *   Specify one argument per line
>
So, not
//STDPARM DD *
PGM /bin/echo FOO BAR
/* 


>If a MVS data set is specified:
>...
>  *   The data set cannot have sequence numbers in it. 
>
OK.

>If you use the ISPF editor to edit the data set, set the sequence numbers off 
>by typing number off on the command line before you begin typing in the data.
>If sequence numbers already exist, type UNNUM to remove them and set number 
>mode off.
>
That's a "How-to", belonging in a Users Guide, not a Command Ref.,
and undoubtedly well covered in the ISPF Ref.
What about all other editors?

>  *   Trailing blanks are truncated for SYSIN and variable block data sets, 
> but not for fixed block data sets. For a fixed block data set, trailing 
> blanks will be included in the parameter text for a given argument up to the 
> end of the record.
>
Truncated for variable but not for fixed!?  Doesn't that seem backwards?
After all, the programmer can control trailing blocks for variable; not for 
fixed.

"Truncated for SYSIN ..., but not for fixed block data sets."  Doesn't that 
statement
contradict itself for fixed block SYSIN, a frequent occurrence?

Who wrote this crap?  Clearly no one proofread it with technical knowledge.

>As for the note about "JCL in-stream data set", I disagree that it belongs in 
>the JCL ref.  The behavior is specific to how BPXBATCH itself handles instream 
>data.  I don't think it's a general statement about instream data.
>
I was thinking of the "immediately  follows" qualification, not at all
specific to BPXBATCH.

-- gil

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


Re: JCL to tar USS directory

2021-01-15 Thread Paul Gilmartin
On Fri, 15 Jan 2021 18:22:09 +, Frank Swarbrick wrote:

>For in-stream data sets: with the SH option, trailing blanks are not 
>truncated. Records in in-stream data sets are concatenated with blanks as 
>separator characters, and the string remaining after the SH token is passed as 
>a single argument to a /bin/sh -c command. For the PGM option, the string is 
>divided not only at line boundaries but also at blanks within a line.
>
>From "Guidelines for defining STDPARM", 
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxa400/gfdstdparm.htm
> 
Sigh.  Users Guide.  Syntactic rules belong not in a Users Guide
but in a Command Ref., which is where I looked.

>  *   [...]
>  *   An JCL in-stream data set
>
>The BPXBATCH parameter data immediately follows the STDPARM DD statement. 
>Trailing blanks are truncated for in-stream data sets, but not for other data 
>sets.
>
And that's JCL. It belongs in the JCL Ref., where it undoubtedly appears.
It shouldn't be duplicated here, except in an example.

>...
>Here is another way, placing the arguments on separate lines:
>
>//STDPARM  DD *
>SH /myscript.sh 
>
>
>/*[Copy code]
>
"[Copy code]"?

The example might instructively show a trick to concatenate (long) lines with
a command substitution:
//STDPARM  DD *
SH /myscript.sh 
$( : These lines are 
  concatenated! )
/*
Is equivalent to:
//STDPARM  DD *
SH /myscript.sh 

/*

-- gil

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


Re: JCL to tar USS directory

2021-01-15 Thread Paul Gilmartin
On Fri, 15 Jan 2021 10:12:52 -0500, Kurt Quackenbush wrote:

>On 1/14/2021 10:10 AM, Bill Giannelli wrote:
>> can anyone provide JCL to tar a USS directory?
>//PAX  EXEC PGM=BPXBATCH
>//STDPARM  DD *
>PGM /bin/pax -zvwf /u/user/paxfile.pax.Z
>/directory/to/be/paxed/
>/*
Must that second line be indented so it is not abbutted to the first, resulting 
in:
PGM /bin/pax -zvwf /u/user/paxfile.pax.Z/directory/to/be/paxed/
... ???  The manual,
z/OS  Version 2 Release 4
UNIX System Services Command Reference
IBM  SA23-2280-40

 needs clarification here.  And in 

From a TSO command environment, the parameter string itself will now
support up to 32754 characters.

Doesn't TSO CALL impose a limit of 100?

Parameters to BPXBATCH can also be supplied via the stdparm DD up to a 
limit of 65,536 characters.

65,536?  65,535 is more plausible.

In addition, program_name can contain option information.

My experience has been that after SH the remainder of the PARM is passed
as the command-string to "sh -c 'command-string'".

When PGM is specified, the PARM is tokenized at blanks. The first token is
the program (path)name; remaining tokens are arguments to the program.

When PGM and program_name are specified and the specified program name
does not begin with a slash character (/), BPXBATCH prefixes the user's 
initial
working directory information to the program path name.

"initial working directory"?  I'd expect "current" working directory.
What about when SH is specified?

>//STDOUT   DD SYSOUT=*
>//STDERR   DD SYSOUT=*
>
5. BPXBATCH does not support any ddnames other than stdin , stdout, stderr,
   stdenv or stdparm. Attempting to allocate or reference any other ddnames
   will result in enqueue failures or unpredictable results. To use an MVS 
data set
   in your batch UNIX application, use "dynamic allocation", such as SVC99 
or
   the TSO ALLOC command. Also, you must remove all "static allocations"
   (ddnames referring to the MVS data set in question) from all steps in the
   batch job.

How many misstatements or misleading statements are in that paragraph?
Certainly static (JCL) allocation is less susceptible to enqueue failures than
dynamic allocation.

-- gil

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


Re: JCL to tar USS directory

2021-01-15 Thread Paul Gilmartin
On Fri, 15 Jan 2021 02:55:30 -0600, Jantje wrote:

>On Thu, 14 Jan 2021 09:00:21 -0600, Bill Giannelli wrote:
>
>>can anyone provide JCL to tar a USS directory?
> 
Tar is obsolescent, largely replaced by pax with added features.

>IMHO, if you are going to do anything in Unix on mainframe, you want to use 
>Co:Z from DovetailedTechnologies: https://www.dovetail.com/index.html
>
o Co:Z is generally highy recommended.
o However, some sites choose by policy not to install Co:Z.
o Therefore ISVs should avoid distributing to customers code that depends on 
Co:Z.
o BPXBATCH suffices to invoke tar/pax.
o SMP/E relies heavily on Unix on mainframe but is Co:Z free.

-- gil

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


Re: CCSID descriptions

2021-01-14 Thread Paul Gilmartin
On Wed, 13 Jan 2021 09:04:03 -0600, Norbert Friemel wrote:

>On Wed, 13 Jan 2021 08:58:49 +, Windt, W.K.F. van der (Fred) wrote:
>>
>>The IBM website used to have complete descriptions of every CCSID including a 
>>complete overview of every character (glyph) in that CCSID with it's 
>>encoding. Simply googling "IBM CCSID 1140" would quickly get you to the page 
>>of CCSID 1140. The CCSID was in the url so you could quickly switch to 
>>another CCSID by changing the url. But with the change to Knowledge Center I 
>>can't find those pages anymore... Does anybody know where the CCCSID 
>>descriptions have gone?
>
>Not a website but ... 
>ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/
> 
That would benefit greatly from an index mapping countries to CCSIDs.


On Wed, 13 Jan 2021 09:16:08 -0800, Tom Brennan wrote:

>After the last time things were changed, I've been going here:
>https://www.ibm.com/support/knowledgecenter/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference02.htm
>
Grrr... both of those are images rather than text, so I can't simply open,
e.g., File:CP01154.pdf, type "Ж" in a search box, and see it highlighted
at coordinate x'EC'. 

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 12:34:20 -0800, Charles Mills wrote:

>http://www.longpelaexpertise.com/toolsTOD.php sez 
>
>TOD: (STCK): x" D91B6D3E F6430440 "
>UTC Date and Time (Date + HH:MM:SS): 11-Jan-2021 21:25:22
>UNIX Date/Time: 1610400322
> 
Some consequence of this impelled me to look for CVTLSO:
PH03250: TIME64() FAILS TO RETURN A VALID VALUE WHEN CVTLSO IS NEGATIVE.

Over 11 days of negative leap seconds!?  And I thought I was the compulsive
tester of edge cases.

IBM fixed it

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 17:24:52 -0600, Mike Schwab wrote:

>Request for information.
>To convert from STCK format to Unix time, what constants would you
>subtract from the STCK value for the same origin, then divide by what
>constant for the same time unit?  Or divide / subtract if easier.
> 
An example in Regina, tested with Itschak's hex example, giving
the same result as http://www.longpelaexpertise.com/toolsTOD.php

1073 $ cattimeoff
trace R
signal on novalue
numeric digits 20

call putenv "TZ=Universal"

TodOff = date( 'T', '1900-01-01', 'I' )
TimeNow = x2d( 'D91B6D3EF6430440' )
TimeDiv = 409600

UnixTime = TimeNow % TimeDiv + TodOff
1074 $ 
1074 $ regina timeoff
 2 *-* signal on novalue
 3 *-* numeric digits 20
 5 *-* call putenv "TZ=Universal"
 7 *-* TodOff = date( 'T', '1900-01-01', 'I' )
   >=>   "-2208988800"
 8 *-* TimeNow = x2d( 'D91B6D3EF6430440' )
   >=>   "15644217847788536896"
 9 *-* TimeDiv = 409600
   >=>   "409600"
11 *-* UnixTime = TimeNow % TimeDiv + TodOff
   >V>   "15644217847788536896"
   >V>   "409600"
   >V>   "-2208988800"
   >=>   "1610400322"


>> >> -Original Message-
>> >> From: Itschak Mugzach
>> >> Sent: Tuesday, January 12, 2021 10:00 AM
>> >>
>> >> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable 
>> >> TOD)
>> >> Converted to decimal  : 15644217847788536896
>> >> Actual dat eof run is : Yesterday

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 22:53:02 +0200, Itschak Mugzach wrote:.
>
>I tested that there already. My rexx returns a different time. I noticed
>that they only use the first four bytes. The code snip I gave is from the
>TOD IPCS rexx.
> 
Regina gives me:
502 $ date
Tue Jan 12 15:59:30 MST 2021
503 $  rxx "numeric digits 20; say d2x( (  time( 'T' ) - date( 'T', 
'1900-01-01', 'I' ) ) %1.048576 )"
D91C6646

Pasting into  http://www.longpelaexpertise.com/toolsTOD.php sez
TOD: (STCK): x" D91C6646  "
UTC Date and Time (Date + HH:MM:SS): 12-Jan-2021 15:59:31
UNIX Date/Time: 1610467171 

What was the output of your:
>> Say 'STCK HEX VALUE ' c2x(tod)
>> tod=C2D(tod)
>> Say 'STCK DEC VALUE ' tod
???

>> -Original Message-
>> From: Itschak Mugzach
>> Sent: Tuesday, January 12, 2021 10:00 AM
>>
>> This is the STCK value: D91B6D3EF6430440 (I have it in hex in variable TOD)
>> Converted to decimal  : 15644217847788536896
>> Actual dat eof run is : Yesterday
>> the code:
>> /* rexx */
>> NUMERIC DIGITS 20
>> RC = SYSCALLS('ON')
>> ADDRESS SYSCALL  'TIME'
>> Say 'Current date is' retval
>>
>> TOD = 'R _ 6   '
>> Say 'STCK HEX VALUE ' c2x(tod)
>> tod=C2D(tod)
>> Say 'STCK DEC VALUE ' tod
>> tod=Trunc(tod/4096)
>> microsec=tod//100
>> seconds=Trunc(tod/100)
>> Say 'Seocnds =' Seconds
>> xxx = 70 * 3600 * 24 * 365
>> Say 'diff=' xxx
>> Say Seconds - xxx
>> SAY '2ND DIF = ' SECONDS - XXX - RETVAL

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 19:19:01 +0200, Itschak Mugzach wrote:
>
>So if I ignore leap seconds, Can I just divide the number by 409600 and
>subtruct 1.1.1970-1.1.1900?
> 
Here's some code I wrote.  The input data are the list of leap seconds
in PoOp.

Restriction:  Presumes a system such as Linux providing the "right"
hierarchy in /usr/share/zoneinfo.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
/*bin/true;exec rexx "$0" "$@";exit # REXX  Magic!
   Doc: Verify the leap second list in Principles of Operation.
*/

ABCD = ,
7D91 048B CA00  ,  /* Circa Jan 1970 -- Must be first!  */
,  /* From PrincOps:   */ 
8000    ,  /* May 1971 -- TOD Rollover.   */
8126 D60E 4600  ,  /* Dec 1971 -- UTC begins. */
820B A981 1E24  ,  /* Jun 1972 -- first leap second.  */
82F3 00AE E248  84BD E971 146C  8688 D233 4690  8853 BAF5 78B4  
8A1F E595 20D8  8BEA CE57 52FC  8DB5 B719 8520  8F80 9FDB B744  
9230 5C0F CD68  93FB 44D1 FF8C  95C6 2D94 31B0  995D 40F5 17D4  
9DDA 69A5 57F8  A171 7D06 3E1C  A33C 65C8 7040  ,
A5EC 21FC 8664  A7B7 0ABE B888  A981 F380 EAAC  AC34 336F ECD0  
AEE3 EFA4 02F4  B196 2F93 0518  BE25 1097 973C  C387 0CB9 BB60  
C9CC 9A70 4D84  CF2D 54B4 FBA8  ,
D1E0 D681 73CC , /* 2016-12-31 23:59:60  */
d7c7 8993 9481 99a3, /* EBCDIC "PGilmart"*/
D7D9 E4C9 E3C5 D940, /* EBCDIC "PRUITER" */
F7A3 048A D5DC   /* The End of Time! */

signal on novalue
numeric digits 25
say ABCD
say
parse value ABCD with A B C D .
call Adjust
TOD1970 =  TOD
say '/*' TOD TOD1970 '*/'
say d2x( ( x2d( '7FFF' ) + TOD1970 + 1 ) * 4096 * 100 )
say d2x( ( 1483228827+ TOD1970 ) * 4096 * 100 )
say

RC = W( '#include ', 1 )  /* Start at line 1  */
RC = W( '#include ' )
RC = W( '#include ' )
RC = W( 'static const time_t leaps[] = {' )

do Lctr = 0 while ABCD<>''
parse value ABCD with A B C D ABCD
call Adjust
RC = W( '/* TOD:' A B C D ,
'UNIX: */' right( TOD - TOD1970, 10 )copies( ',', ABCD>>'' ),
'/*' Frac '*/' );  end Lctr
RC = W( '};' )
RC = W( '' )

RC = W( 'int ShowIt( const time_t *pT ) {' )
RC = W( 'char s[100];' )
RC = W( '' )
RC = W( 'strftime( s, 99, "%c", localtime( pT ) );' )
RC = W( 'printf( "Time =%11ld  for: %s\n", (long)*pT, s );' )
RC = W( 'return 0; }' )

RC = W( '' )
RC = W( 'int main( void ) {' )
RC = W( 'const time_t *I;' )
RC = W( '  time_t TT;' )
RC = W( '' )

RC = W( 'system( "uname -a" );' )
RC = W( 'putenv( "TZ=right/Universal" );')
RC = W( 'putenv( "TZ=right/America/Denver" );')
RC = W( 'putenv( "TZ=right/America/Los_Angeles" );')
RC = W( 'printf( "For Timezone: %s\n", getenv( "TZ" ) );' )
RC = W( 'tzset(); for ( I = leaps; I

Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 13:46:07 -0400, Clark Morris wrote:
>>
>>And a general note: when using ISPF edit to remove sequence numbers from a 
>>(large) number of (large) members, you might need to cater for the fact that 
>>a 
>>PDS might need to be compressed at some stage in the middle of your 
>>processing!
>
>Use of update in place should work if all that is being done is
>sequence number stripping since the size of the member does not
>change.
> 
Does ISPF Edit update in place, even optionally?  I think PDS usually
creates a new member.

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 19:19:01 +0200, Itschak Mugzach wrote:
>
>So if I ignore leap seconds, Can I just divide the number by 409600 and
>
409600?

>subtruct 1.1.1970-1.1.1900?
>
Are you doing it the hard way?  Borrowing from seconds to minutes,
minutes to hours, hours to days, days to months (which aren't of
uniform lengths), months to years (which aren't of uniform lengths
in some calendars) ...?

Show sample data and your code.

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 18:41:54 +, Robert Prins wrote:
>
>...  the advantage of keeping things together, like the PL/I RFE I've
>very recently entered,
>.
>Feel free to vote for it, although I already expect it to be accepted.
> 
I don't speak PL/I, but wouldn't it be even better to declare an array of
structures, each having two fields, ISO and INFO.  Initialization could then
keep the initial values even closer together.

>And a general note: when using ISPF edit to remove sequence numbers from a
>(large) number of (large) members, you might need to cater for the fact that a
>PDS might need to be compressed at some stage in the middle of your processing!
>
Use PDSE.

>PS: Please people, strip off all the unnecessary garbage from your replies...
>
PS: Please, people, set your clock and timezone consistently: 
TZ=Europe/Vilnius, not GMT.

-- gil

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


Re: STCK and epoch time

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 16:30:52 +, Seymour J Metz wrote:

>The TOD clock is just a counter; what you get out of it depends on what you 
>put into it. There is a convention in PoOps, but if you want the correct time 
>and date it is much easier to use system services than to do the adjustments 
>yourself.
>
>MVS does not use the same epoch as Eunix. Unix System Services will adjust the 
>epoch properly.
> 
UNIX counts seconds, excluding leap seconds, starting 1970-01-01t00:00:00
MVS  counts microseconds/4096, including leap seconds, starting 
1900-01-01t00:00:10.

>
>From: ITschak Mugzach
>Sent: Tuesday, January 12, 2021 10:36 AM
>
>How exactly STCK (not STCKE) stores the time? I took the value (8 bytes)
>and converted it to decimal 10 characters. I expect it to be the same as
>the EPOCH time returned by USS time call. However the returned value is July
>29, 2019 (have a time from yesterday). I know there is a macro to do it,
>but I want to keep the correct epoch time.
>
I'm mystified (unless it's a coding error) by the 6-month error.  Show your 
code.

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 16:20:17 +, Seymour J Metz wrote:

>ISREDIT is only valid for an edit macro. You need on script to invoke EDIT and 
>a second script running as an IMACRO for the edit. If they are in SYSPROC then 
>you need to start the first comment with REXX.
>
Is the initial command environment ISPEXEC?  My experience has been it's TSO.

>   /* Outer script */
>  parse upper arg dataset
>  "CONTROL ERRORS RETURN"
>  'EDIT DATASET('dataset') MACRO(STRIPED')'
>  /* Tailor above to suit your needs */
>
>  /* Inner script */
>  'CONTROL ERRORS RETURN'
> ADDRESS ISREDIT
>  'UNNUMBER'
>
The first command must be MACRO.

>  'SAVE'
> 'END'

These might be combined in a single EXEC (untested):

   /* Rexx */
  address ISPEXEC  /* at least for documentation.  */
  "CONTROL ERRORS RETURN"
  call INITIAL
  parse upper arg dataset
  /* Logic to enumerate members?  */
  'EDIT DATASET('dataset') MACRO(STRIPED')'  /* Unbalanced "'"? )
  /* Tailor above to suit your needs */
  EXIT

  /* Initial Macro script */
INITIAL:
 ADDRESS ISREDIT
 'MACRO'
 IF RC<>0 RETURN
  /* Is NUMBER needed before UNNUMBER if not all members are numbered?  */
  'UNNUMBER'
  'SAVE'
 'END'
 EXIT

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-12 Thread Paul Gilmartin
On Tue, 12 Jan 2021 11:26:32 +, Sean Gleann wrote:
>
> 7 *-* "ISREDIT MACRO"
>   >L>   "ISREDIT MACRO"
>   +++ RC(20) +++
> 
That belongs not here but in your initial macro.

>21 *-*   "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
>   >L> "ISPEXEC EDIT DATAID() MEMBER() MACRO()"
> 
Does Edit evaluate the apparent symbol ""?  Where is it given a value?

Was that from the (lately deleted) PARSE SOURCE instruction?  Then:
 "ISPEXEC EDIT DATAID("DSN") MEMBER("MEMBER") MACRO("ME")"

If you're attempting to use your driving exec as your initial macro (I've
done that at times), you need dual-path logic to prevent loops.

>  ISPP330 BDISPMAX exceeded   -/-100 displays exceeded in batch mode on
>panel
>
What's causing Edit to attempt a display?

As alternatives to Edit I suggest either EXECIO DISKR - EXECIO DISKW
or LMGET -  LMPUT logic.

-- 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 holddata per https?

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 22:07:04 +, Jesse 1 Robinson  
wrote:

>I can confirm that HTTPS replaces FTP for downloads very nicely. Our use of 
>FTP depends on a gizmo (Bluecoat) that cannot understand FTPS. We made the 
>switch to HTTPS some time ago. 
>
How?  It doesn't seem to be as simple as changing the scheme in
ftp://public.dhe.ibm.com/s390/holddata/full.txt
to:
https://public.dhe.ibm.com/s390/holddata/full.txt
... that gives 404.  "Bluecoat" seems to be a Symantec subsidiary.
Is it also some sort of proxy?

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 17:58:07 +, Lars Höglund wrote:
>
>You can use SETMSG even in batch that's why ISPMLIB
> 
What is its effect?

>-Ursprungligt meddelande-
>Fr�n:  Seymour J Metz
>Skickat: den 11 januari 2021 18:39
>
>Why a separate allocation step?
>
>Why 3120 for ISPPROF?
> 
BLKSIZE(0)?

How old is that code?  What portable UNIT esoteric is advised for a temp DSN?

--
On Mon, 11 Jan 2021 17:43:09 +, Seymour J Metz wrote:

>ISPF has an ISPEXEC command in support of clists; '"ISPEXEC CONTROL ERRORS 
>RETURN"' is equivalent to 'ADDRESS ISPEXEC "CONTROL ERRORS RETURN"' with more 
>overhead. That rc 20 means that it is not running under ISPF. Under ISPF, the 
>initial environment is ISPEXEC.
>
I thought, TSO.  Silly design.

A mischievous developer might create a command environment named
ADDRESS with an ADDRESS command so:
address ADDRESS 'ADDRESS'
... would work without error.

Contrariwise, when I used CMS/370 ISPF many decades ago, ADDRESS ISREDIT
was mis-implemented.  Something like:
address ISREDIT 'MACRO'
"RC(-3)"
... but:
address ISREDIT 'ISREDIT MACRO'
... succeeded.

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 16:36:35 +, Sean Gleann  wrote:
>
>The next command in the REXX is "ISREDIT MACRO", but that leads back to the
>RC(20) situation
>"ISPEXEC CONTROL ERRORS RETURN"
>"ISREDIT MACRO"
>  +++ RC(20) +++
> 
"ISREDIT MACRO" must be the first command in a MACRO.  It may not
follow "ISPEXEC ..."

At times I have needed two SYSEXEC members, one to start Edit with
the second as the initial MACRO.

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 16:36:35 +, Sean Gleann wrote:
>
>"ADDRESS ISPEXEC CONTROL ERRORS RETURN" results in
>IKJ56500I COMMAND ADDRESS NOT FOUND
>   +++ RC(-3) +++
> 
ADDRESS is a Rexx bultin instruction.  It should not be quoted
as if it were a host command.

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 16:17:43 +, Lars Höglund wrote:

>Example of ISPF-proc
>
>//*  PROC ISPFBAT  
>//ISPFBAT  PROC
>//*
>//*--  
>//* STEPNAME: CREPROF  
>//* STEPINFO: CREATE ISPPROF   
>//*--  
>//CREPROF  EXEC PGM=IEFBR14   
>
Couldn't these allocations be done in the BATCHPDF proc step, saving
one step?
 
>//ISPTLIB  DD DISP=(NEW,PASS), 
>//SPACE=(TRK,(15,15,5)),   
>//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
>//DSN=&ISPTLIB
>
Where iSPTLIB used?

>//ISPTABL  DD DISP=(NEW,PASS), 
>//SPACE=(TRK,(15,15,5)),   
>//LRECL=80,BLKSIZE=0,DSORG=PO,RECFM=FB,
>//DSN=&ISPTABL
>//*
>//*--  
>//* STEPNAME: BATCHPDF 
>//* STEPINFO: EXECUTE ISPF IN BATCH
>//*--  
>//BATCHPDF EXEC PGM=IKJEFT01,DYNAMNBR=128, 
>// PARM='ISPSTART CMD( )'  
>//SYSEXEC  DD  DISP=SHR,DSN=YOUR.ISPEXEC<---   
>// DD  DISP=SHR,DSN=ISP.SISPEXEC  
>
At times I've made SYSEXEC a temp DSN, with the BATCH step an IKJEFT*
beginning with a REPRO to copy SYSIN to a SYSEXEC member.  This makes
the JCL self-contained.

>//SYSPROC  DD  DISP=SHR,DSN=ISP.SISPCLIB   
>//ISPPLIB  DD  DISP=SHR,DSN=ISP.SISPPENU   
>//ISPSLIB  DD  DISP=SHR,DSN=YUOR.ISPSLIB<---   
>// DD  DISP=SHR,DSN=ISP.SISPSLIB   
>// DD  DISP=SHR,DSN=ISP.SISPSENU   
>//ISPMLIB  DD  DISP=SHR,DSN=YOUR.ISPMLIB<---   
>// DD  DISP=SHR,DSN=ISP.SISPMENU   
>// DD  DISP=SHR,DSN=ISF.SISFMLIB   
>// DD  DISP=SHR,DSN=SYSU.XMITIP.MSGS   
>//ISPLLIB  DD  DUMMY   
>//ISPPROF  DD  UNIT=WORK,SPACE=(TRK,(9,1,4)),  
>// LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PO 
> 
I endorse such use of a temp DSN for ISPPROF, avoiding ENQ conflicts
and making the PROC more useful to the general public.

>//ISPTABL  DD  DISP=(OLD,DELETE),DSN=&ISPTABL 
>
Is DELETE necessary?  Isn't that automatic for temp DSNs?

Are all the allocations above necessary in batch?  How is ISPMLIB useful?
Could they be made temp DSNs?

-- gil

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


Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Paul Gilmartin
On Mon, 11 Jan 2021 15:37:55 +, Sean Gleann wrote:

>Many thanks to all who responded.
>I opted to adapt and (try to) use the REXX that Andy Styles gave, but I'm
>tripping up over something that has to be one of those 'simple, basic'
>things.
>The "ISPEXEC CONTROL ERRORS RETURN" command gives me RC(20) as a result.
>I think I've got to use an 'ADDRESS ISPEXEC' command or something like that
>at the start of the REXX, but attempts at variants of this give the same
>result.
> 
You need to run your Rexx under ISPF, which implies you need to run under TSO.
This can all be done in batch, with suitably complex DD statements.

Otherwise, RC(20)

-- gil

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


Re: Using symbolic DD names

2021-01-10 Thread Paul Gilmartin
On Sun, 10 Jan 2021 14:34:03 +0200, Binyamin Dissen wrote:

>On Wed, 30 Dec 2020 19:21:52 + Billy Ashton wrote:
>
>:>Hey folks! I have a vendor product program that looks for different
>:>DDnames depending on the control statements passed into the program. Is
>:>there any way to define a dynamic DD statement using JCL symbols? For
>:>example, I would love to have //TB to correspond to TB01DAT,
>:>TB14DAT, or TB67DAT if I use SET TNO=01 or 14 or 67.
>
>:>Is such a thing possible? I tried using an instream proc definition and
>:>INCLUDE MEMBER= that proc name, but that failed, and of course, I tried
>:>the straight up JCL as above, and it failed.
>
>:>What do you all think?
>
>If you create a member for each DD statement,
>
> // INCLUDE MEMBER=TAB
>
>should work fine. Or am I missing something?
>
Gee.  One might create a collection of JCLLIB members mapping the
Cartesian product of all possible values of all possible symbols.  Then
no such member need contain any symbol references.

Seriously?  There's something wrong here.

I hate JCL!

-- gil

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


Re: Code to verify LOGON password

2021-01-09 Thread Paul Gilmartin
On Sat, 9 Jan 2021 00:12:07 -0600, Brian Westerman wrote:
>
>With some restrictions, I think that just issuing the RACROUT request=verify, 
>would be okay.  There should probably be some mechanism to revoke the ID if 
>there are two many guesses though. 
> 
Among these, I wonder about MFA.  Does RACF support MFA?

Why is sftp unable to mask the password entry on a 3270 while FTP does
so readily?

I once submitted an SR that tcsetattr() suppresses ECHO on a linemode
terminal but not a 3270.  IBM rejected it.

-- gil

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


Re: Code to verify LOGON password

2021-01-08 Thread Paul Gilmartin
On Fri, 8 Jan 2021 12:19:28 -0500, Sam Golob wrote:
>
>     Does anyone have user-written code for RACF, so that if the user
>types in a password, the code will verify if it is the user's actual
>LOGON password?
>
>     I'd like to see code that does this, for ACF2 and Top Secret as
>well, but I'm primarily interested in RACF.
>
Ideally, such code should work alike under SSH, OMVS, TSO, ...

And best if the SAF momentarily takes control of the terminal
so the password never appear in cleartext in the user's
address space or on the user's screen.

-- gil

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


Re: ZFS using zEDC hardware compression

2021-01-08 Thread Paul Gilmartin
On Fri, 8 Jan 2021 16:07:31 +, Seymour J Metz wrote:

>A zFS is stored in a VSAM linear data set. I found "Only extended-format 
>key-sequenced data sets can be compressed." at 
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/compdta.htm
> 
This is a plausible consequence of not using keys:  There's no easy way
to access a given datum.

>
>From: PINION, RICHARD W
>Sent: Friday, January 8, 2021 10:00 AM
>
>Can a ZFS dataset be defined with the DATACLAS zEDC compression option?  I'm 
>looking for a way
>to reduce the size of our SMPNTS datasets.
>
Since the payload of SMPNTS is .pax.Z files; software compressed,
there's little benefit in adding hardware compression.

-- gil

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


Re: Problem executing bpxwunix

2021-01-06 Thread Paul Gilmartin
On Wed, 6 Jan 2021 18:01:53 +, Frank Swarbrick wrote:

>"bpxwunix() can be used outside of the z/OS UNIX REXX environment (for 
>example, in TSO/E). In this case, stdin, stdout, stderr, and environment 
>variables are not inherited from the current process environment. For example, 
>when executing a REXX exec in this environment, you must either export the 
>PATH statement before invoking the REXX exec (command = 'export PATH;tsocmd 
>time'), or supply the PATH statement to BPXWUNIX (env.1='PATH=/bin') in order 
>for the REXX exec to execute properly. Otherwise, the REXX exec fails and 
>message BPXWI is displayed."
>
>From 
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb600/wunix.htm
>
Looking at the example  I suspect the OP followed, from:

https://www.ibm.com/support/pages/system/files/inline-files/CSM_Session_automation_v1.1.pdf

o It fails to supply stdin
o It supplies a PATH which probably doesn't contain "echo".

This ought to be worthy of an RCF.  The author should have tested his Exec
under IRXJCL.

Why "address tso"?  I see no TSO commands.


>
>From: Seymour J Metz
>Sent: Wednesday, January 6, 2021 5:20 AM
>
>What was the exact call that you used and did you provide a PATH in the 
>environment parameter?  Since there is no login shell, things don't get 
>initialized the way you might expect.
>
>
>From: Gadi Ben-Avi 
>Sent: Wednesday, January 6, 2021 2:33 AM
>
>I would like to automate some csm (Copy services manager) from z/OS.
>I installed csmcli on z/OS, and if I run csmcli.sh from the omvs shell, it 
>works ok.
>I found the TechDoc named 'IBM Copy Services Manager session automation' by 
>Thomas Luther which has a rexx program that sets up the environment to run 
>csmcli.sh, get the output from it, and act upon the results.
>
>The rexx program uses bpxwunix to call cshcli.sh
>When I run the rexx program (whether under tso or in batch) I get lots of 
>error messages.
>I added an echo command at the beginning of csmcli.sh so I will know when it 
>starts.
>The command I added is 'echo "start csmcli.sh"'
>When I run it from the omvs shell, it works fine.
>When I run it from tso I get:
>echo: csmcli.sh 10: FSUM7351 not found
>
>Does this mean that it can't find the echo command?

-- gil

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


Re: Problem executing bpxwunix

2021-01-06 Thread Paul Gilmartin
On Wed, 6 Jan 2021 07:33:41 +, Gadi Ben-Avi  wrote:
>
>I would like to automate some csm (Copy services manager) from z/OS.
>I installed csmcli on z/OS, and if I run csmcli.sh from the omvs shell, it 
>works ok.
>I found the TechDoc named 'IBM Copy Services Manager session automation' by 
>Thomas Luther which has a rexx program that sets up the environment to run 
>csmcli.sh, get the output from it, and act upon the results.
>
Is that: 
https://www.ibm.com/support/pages/system/files/inline-files/CSM_Session_automation_v1.1.pdf
???

The BPXWUNIX example is amateurish; the author doesn't know Rexx very well.
He clearly doesn't understand that RETURN restores the parent addressing
environment.

Did you change the HOME and PATH ENVIRONMENT variables?

I'll suggest prefixing each "USS" command with "set -x; "


>The rexx program uses bpxwunix to call cshcli.sh
>When I run the rexx program (whether under tso or in batch) I get lots of 
>error messages.
>I added an echo command at the beginning of csmcli.sh so I will know when it 
>starts.
>The command I added is 'echo "start csmcli.sh"'
>When I run it from the omvs shell, it works fine.
>When I run it from tso I get:
>echo: csmcli.sh 10: FSUM7351 not found
>
>Does this mean that it can't find the echo command?
>
Yes.

>How can I fix this?
>
Try "PATH=/opt/IBM/CSM/CLI/:/bin"

Check that all the directories mentioned by Rexx exist.

-- gil

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


Re: Isolating a CSECT within a load module

2021-01-04 Thread Paul Gilmartin
On Mon, 4 Jan 2021 16:32:47 +0100, Massimo Biancucci wrote:
>
>I've tried to use sort to help.
>
>// EXPORT SYMLIST=*
>// SET INPMOD=oldmd
>// SET OUTMOD=newmod
>// SET INPLIB=myold.lib
>// SET OUTLIB=mynew.lib
>
I like that sort of parameterizing.  It puts the variables up front,
viewable at a glance.  I'd add the AMBLIST2 DSNs to the SET list.

Can something such as "SET DISP={PASS|CATLG} be used to control
temp vs. permanent workfiles?

>//*   *
>//*---*
>//ST010  EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
> DELETE 
> IF MAXCC=8 THEN SET MAXCC=0
>/*
>//*---*
>//*   *
>//*---*
>//ST020  EXEC PGM=AMBLIST
>//SYSPRINT DD DSN=,DISP=(,CATLG),
>// SPACE=(TRK,(5,5),RLSE)
>//LOADLIB  DD DISP=SHR,DSN=
>//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=
>/*...
My very peculiar preference is to omit the IDCAMS steps and code either:
//HANDLE DD DSN=,DISP=(MOD,CATLG),
// SPACE=(TRK,(5,5),RLSE)
//SYSPRINT  DD  DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE

Or:
//HANDLE DD DSN=,DISP=(MOD,DELETE),
// SPACE=(TRK,(5,5),RLSE)
//SYSPRINT DD DSN=,DISP=(MOD,CATLG),
// SPACE=(TRK,(5,5),RLSE)

But, performance?  Is a failing IDCAMS step less overhead than
an otiose DISP=(MOD,DELETE) etc.?

>I used "no-temp" dataset to better help in understanding the process.

-- gil

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


Re: Isolating a CSECT within a load module

2021-01-04 Thread Paul Gilmartin
On Mon, 4 Jan 2021 12:45:37 +0200, Steff Gladstone wrote:
>
>... using (within the linkage editor or binder) a
>REPLACE statement ahead of an INCLUDE statement and specifying in the
>REPLACE all of the other CSECTS in the load module.  ...
>
>Obviously this is unwieldy for a load module with lots of CSECTs.
>
Might that be scripted, filtering the output of AMBLIST to generate
SYSLIN commands?  Computers are good at doing unwieldy stuff.

Does Binder impose a limit on number of REPLACE statements?
Even if so, use multiple passes.

-- gil

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


Re: Question About the Binder SETSSI statement

2021-01-03 Thread Paul Gilmartin
On Sun, 3 Jan 2021 17:27:25 +, Seymour J Metz wrote:

>I would guess that PDS86 uses DESERV with EXT_ATTR=YES.
> 
Thanks.  Would that be?:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idas300/s3254.htm
...
66 (X'42')  4   PMARL_DATE  Date saved
70 (X'46')  4   PMARL_TIME  Time saved

I notice that NFS server returns time with sub-microsecond precision.'
Possible if the (undocumented) byte field is binary, not display.

I note also that HSM Migrate/Recall preserves the (FAMS?) timestamp;
IEBCOPY Unload/Load resets it to the reload time.

-- gil

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


Re: Question About the Binder SETSSI statement

2021-01-02 Thread Paul Gilmartin
On Sun, 3 Jan 2021 13:46:56 +1100, Greg Price wrote:
>
>If you store your programs in a PDSE then REVIEW and PDS can show you
>the date/time stamp of the programs in the member list because they can
>be extracted from the directory entry (unlike for PDS load modules).
> 
Is that from the directory or from FAMS?  Or are they the same thing?
Is it local or GMT?

-- 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 Unix TZ time zone environment variable

2020-12-31 Thread Paul Gilmartin
On Thu, 31 Dec 2020 19:16:15 -0600, John McKown wrote:

>On Thu, Dec 31, 2020 at 7:15 PM Mike Schwab wrote:
>
>> https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
>> One example is EST+5EDT,M3.2.0/2,M11.1.0/2, so modify by 2 hours.
>
>I don't think z/OS supports that. But I haven't looked at 2.4.
>
I believe it has for a long time, for international support.

If you have a good desktop system, the last line in each individual
entry of /usr/share/zoneinfo/ is the POSIX format; probably good
for z/OS.  E.g.:
547 $ tail -1 /usr/share/zoneinfo/America/Denver
MST7MDT,M3.2.0,M11.1.0

Beware of:
548 $ tail -1 /usr/share/zoneinfo/Asia/Tel_Aviv
IST-2IDT,M3.4.4/26,M10.5.0

Some older OSes don't support the "/26" modifier.  Funny calendar there.

And:
549 $ tail -1 /usr/share/zoneinfo/Europe/Dublin
IST-1GMT0,M10.5.0,M3.5.0/1

Standard time in Summer; negative Daylight Saving in Winter!

-- gil

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


Re: Using symbolic DD names

2020-12-31 Thread Paul Gilmartin
On Thu, 31 Dec 2020 07:50:44 -0600, Dana Mitchell wrote:
>
>... snippet ...
> 
Thanks.  I fixated on the wrong thing.

>In this instance, I append zscreen to keep the DD names unique if this is used 
>more than once simultaneously in split screens.  
>
I've used BPXWDYN( 'ALLOC RTDDN(DD) ...' ) similarly.  Stronger guarantee of
uniqueness; less ease of identification.

Thanks again,
gil

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


Re: Using symbolic DD names

2020-12-31 Thread Paul Gilmartin
On Thu, 31 Dec 2020 13:04:59 +, Seymour J Metz  wrote:

>ZSCREENI?
>
I stand corrected.  I glanced at my 4-year code too hastily.
Thanks.

But my question remains, how does compound symbol TRAP.
get populated?


>
>From:  Jeremy Nicoll
>Sent: Thursday, December 31, 2020 5:53 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Using symbolic DD names
>
>On Wed, 30 Dec 2020, at 22:59, Paul Gilmartin wrote:
>> On Wed, 30 Dec 2020 15:16:49 -0600, Dana Mitchell wrote:
>
>> >Address ispexec 'VGET (ZSCREEN) SHARED'
>> >ddname='$TRAP'zscreen
>> >'ALLOC FI('ddname') UNIT(3390) DSO(PS) RECFM(V B) LRECL(255) NEW DEL REU'
>> >'EXECIO 'trap.0' DISKW 'ddname' (FINI STEM TRAP.'
>> >
>> I'm mystified.  I've used very much the VGET as you wrote it to fetch an
>> entire screen image into a simple Rexx variable.
>
>You couldn't have done.  According to ISPF Dialog Developer's Guide and 
>Reference,
>zscreen is a 1-byte variable ...

-- gil

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


Re: Using symbolic DD names

2020-12-30 Thread Paul Gilmartin
On Wed, 30 Dec 2020 15:16:49 -0600, Dana Mitchell wrote:

>I do this frequently in REXX:
>
>Address ispexec 'VGET (ZSCREEN) SHARED'
>ddname='$TRAP'zscreen
>'ALLOC FI('ddname') UNIT(3390) DSO(PS) RECFM(V B) LRECL(255) NEW DEL REU'
>'EXECIO 'trap.0' DISKW 'ddname' (FINI STEM TRAP.'
>
I'm mystified.  I've used very much the VGET as you wrote it to fetch an
entire screen image into a simple Rexx variable.  But:
ddname='$TRAP'zscreen

... appears to be a straightforward Rexx assignment instruction, assigning to
the Rexx simple variable DDNAME the 5-character string '$TRAP' concatenating
the (several hundred character) string ZSCREEN.  I see nothing affecting the
compound symbol TRAP.  How does that get set?  Am I missing something?

I have long wished for an ISREDIT command to fetch a range of lines, or
all the NX buffer into a compound symbol, or LMPUT from a compound
symbol rather the absurdly cumbersome MULTX construct.  Why not?

-- gil

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


Re: Using symbolic DD names

2020-12-30 Thread Paul Gilmartin
On Wed, 30 Dec 2020 13:55:32 -0700, Lizette Koehler wrote:
>
>And yes Scheduling products can supply symbolics where native z/OS might now.
> 
JCL Converter is brain-dead.  Symbolics should be recognized *everywhere*,
even when split over continuation lines.

>Could you provide an example where your program when it executes would use a 
>random DD name in JCL?
>
Not a DD name in JCL, but some ISPF Rexx functions supply generated
DDNames for spool files.  To copy them out, I need to
address ATTCHMVS 'IEBGENER PARM1 AltDDList'

-- gil

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


Re: Using symbolic DD names

2020-12-30 Thread Paul Gilmartin
On Wed, 30 Dec 2020 19:21:52 +, Billy Ashton wrote:

>Hey folks! I have a vendor product program that looks for different 
>DDnames depending on the control statements passed into the program. Is 
>there any way to define a dynamic DD statement using JCL symbols? For 
>example, I would love to have //TB to correspond to TB01DAT, 
>TB14DAT, or TB67DAT if I use SET TNO=01 or 14 or 67.
>
ITYM "//TB"

>Is such a thing possible? I tried using an instream proc definition and 
>INCLUDE MEMBER= that proc name, but that failed, and of course, I tried 
>the straight up JCL as above, and it failed.
>
But to no avail.  From somewhere in the JCL Ref.:
4. Do not use symbols to change the identifier field, name field, or 
operation field of a JCL statement.

>What do you all think?
>
o ObEmerson
o Doesn't this contravene Peter R's strict assertion that IBM documentation
  does *not* attempt to document what is *not* supported.

-- gil

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


Scheduler (was: JCL divergence)

2020-12-30 Thread Paul Gilmartin
On Wed, 30 Dec 2020 11:22:42 +0100, Stefan Skoglund wrote:
>
>UNIX had early on cron which runs specific jobs regularly at
>predetermined times while at (atd) is more like a one of JCL batch job.
>...
>LINUX has the same functionality.
>
Of course.  "... not far from the tree."

A shortcoming of cron we encountered is that there's no provision
to specify a timezone when scheduling a recurring event.

Do other schedulers have such a facility?

This is a particular irritatant for mobile device users.

-- gil

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


Re: EBCDIC-ASCII converter and other tools

2020-12-29 Thread Paul Gilmartin
On Tue, 29 Dec 2020 22:29:16 +0100, R.S. wrote:

>Yes, exactly.
>This is one of the reasons for custom-defined table.
>Custom-defined is not "standard"
>And yes, the goal is to change selected characters, and prepare the
>opposite table. Of course translation can be reversible when the table
>has unique values (this is first of the conditions) . So, for example it
>can be A->B translation, but B has to be translated as well, let's say
>B->A. That would change ADAM BROWN to BDBM AROWN (assuming other
>characters are not translated), but it reversible.
>Let's say translation A -> B and B unchanged would give BDBM BROWN and
>there is no way to find out which character need to be reversed.
> 
https://en.wikipedia.org/wiki/Bijection

-- gil

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


Re: EBCDIC-ASCII converter and other tools

2020-12-29 Thread Paul Gilmartin
On Tue, 29 Dec 2020 18:12:06 +0100, R.S. wrote:

>1. Yes, maybe I described it incorretly.
>Regarding your question - yes I need something like
>convert ifile ofile [-tablefile]
>Just byte to byte translation. No CR/LF issues, no record boundaries,
>just byte to byte. The file can be large (may not fit in memory).
>
I'm surprised.  Is the input file a text file?  How are records delimited?
(Is it organized in records?)  If it's binary data I wouldn't expect
conversion to be useful.

Perhaps the answer to all such questions is RECFM=FB.

Does it originate on z?  How does it get to Windows?
FTP BINARY?

Are you writing a tool for non-programmers to use?

-- gil

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


Re: RMODE64

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 09:01:40 -0800, Ed Jaffe wrote:
>
>We are writing an RMODE(64) product because we love z/OS and wish to
>help push the boundaries of its technological limitations wherever we can.
> 
IBM hates people like that.

At a SHARE meeting (where I believe I met you), John E. (FSVO "E") practically
boasted that unlike Linkage Editor for which data specifications were open,
Binder's were closed,  saving IBM much anguish.

The issue: programmers, especially ISVs coded to the Doc; did things that no
IBM product did, and IBM never tested; and opened SRs when they didn't
work as documented.  I imagine many APARs were closed PRS.

IBM can say, "We never said that would work."  But if you stayed within the
boundaries of what IBM says would work, you wouldn't get much done.

-- gil

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


Re: [External] Re: Build and submit proc

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 22:14:15 +, Seymour J Metz wrote:

>Eunix has even less typing:
>
>Thu 12-24-20 12:49:37{2}[h:\] cp --help
>Usage: G:\USR\BIN\cp.exe [OPTION]... [-T] SOURCE DEST
>  or:  G:\USR\BIN\cp.exe [OPTION]... SOURCE... DIRECTORY
>
That doesn't look much like UNIX to me.  I guess that's the difference
between UNIX and Eunix.

-- gil

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


Re: [External] Re: Build and submit proc

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 16:02:07 -0500, Steve Thompson wrote:

>So write a PROC that puts INPUT with SYSUT1 and OUTPUT with SYSUT2. 
> 
I could imagine that nowadays TRSMAIN is merely an ALIAS entry point that
branches to AMATERSE with an alternate DDNAME list.

>I even took this a step further and had OUTPUT get deleted first before 
>AMATERSE. 
>
As in DISP=(MOD,DELETE)?  That might be a disservice to a programmer
who pre-allocates the data set with special SPACE, UNIT, VOL, BLKSIZE, etc.

And to what benefit, anyway?

I like to do such as:
//HANDLE  DISP=(MOD,CATLG),DSN=,UNIT=SYSALLDA,SPACE=(CYL,(10,100)
//OUTFILE  DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE
... to reuse an existing data set if one is catalogued.

-- gil

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


Re: [External] Re: Build and submit proc

2020-12-24 Thread Paul Gilmartin
On Wed, 23 Dec 2020 15:40:23 +, Pommier, Rex wrote:
>
>Yeah there's a problem with it - a human problem.  It's easy when in a hurry 
>to miss the fact they're reversed and key the input dataset name in the SYSUT2 
>and the output in the SYSUT1 if you're not paying attention.  Yeah I know it's 
>self-inflicted but that was what I thought when I saw Tom's comment.   BTDT, 
>felt the pain.
> 
SYSUT1 and SYSUT2 are so visually similar that they invite errors.
TRSMAIN was better, using INFILE and OUTFILE.  The developers
took a step in the wrong direction when AMATERSE switched to the
more error-prone SYSUT1 and SYSUT2.  Just because other utilities
had the same flaw.

"A foolish consistency is the hobgoblin of little minds, adored by
little statesmen and philosophers and divines."  -- Emerson

-- gil

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


Re: RMODE64

2020-12-24 Thread Paul Gilmartin
On Thu, 24 Dec 2020 08:44:09 -0800, Charles Mills wrote:

>I would never presume to tell IBM what to do, but if I were responsible for
>the "MVS Services" documentation I would start with a preamble much like
>@Gil describes in which I said "unless otherwise specified, callers must be
>..." and covered ASC, SRB/TCB, AMODE, RMODE, problem/supervisor, etc.
>
>It need not be negative "callers cannot be above the bar" or "not SRB" but
>rather positive "callers must invoke the services from below the bar, in TCB
>mode, etc." If IBM were theoretically to add some new MVS "mode" in the
>future -- a third alternative to TCB/SRB or a new AMODE or whatever -- it
>would not be necessary to change the write-up for every service, only to add
>one sentence to this preamble (and change the write-ups for services that
>actually supported the new mode).
>
>> Do you think there is anyone in the IBM world who needs that sentence?
>
>Yes, new entrants to the IBM world. We do want new entrants, don't we?
>Without them, the platform dies as we retire. The platform dies as CIO's
>perceive that it is not possible to hire staff to support the platform.
> 
Well said.  I attempted to avoid any aura of negativity by saying "may"
where you properly said "unless ... must", and I left Peter to assume the
readers would infer the contrapositive.

A few points:
o As z/OS grows in complexity, the needed documentation and its cost
  grows proportionally, perhaps quadratically.
o It becomes increasingly unlikely that a typical user has the needed
  background information.
o The cost of providing adequate documentation should be factored
  into the business case for new features, not used as an excuse for
  not providing it.


>-Original Message-
>From: Peter Relson
>Sent: Thursday, December 24, 2020 7:02 AM
>
>Perhaps you don't understand what I mean by "blanket statement":
>a single affirmative sentence in the Introduction to the manual, "Any
>service described herein may be invoked from a location below 2 GiB."
>
>
>Do you think there is anyone in the IBM world who needs that sentence? It
>might be thought that things prevalent by MVS/XA (the late 70's) are
>"known" and need not be stated.
>
>Regardless, such a statement is not what I read your previous post to
>suggest.
>
>
>>> VERY FEW system services officially support invocation in RMODE 64. If
>>> they don't say that they do, then do not assume that they do.
>>>  ...
>Is there a blanket statement to this effect in the relevant manual(s)?
>
>
>To me, that asks about a negative statement. Such a statement might have
>been "No service may be invoked from a location >= 2G unless it explicitly
>is documented that it allows that". As I mentioned previously, we do not
>typically have such negative statements.

-- gil

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


Re: [External] Re: Build and submit proc

2020-12-23 Thread Paul Gilmartin
On Wed, 23 Dec 2020 09:36:31 -0800, Tom Brennan wrote:

>Thanks Rex, exactly what I was going to say.
>
>On 12/23/2020 7:40 AM, Pommier, Rex wrote:
>>
>> Yeah there's a problem with it - a human problem.  It's easy when in a hurry 
>> to miss the fact they're reversed ...
>>
"reversed"?  Is there a canonical order for DD statements?  Perhaps
alphabetical, by DDNAME?

I'm comfortable with languages which generally put the TO before the FROM, as"
X = A + B;

The exception, predictably, is COBOL:
ADD A TO B GIVING X

I feel the designers of UNIX commands made the wrong choice.
generally putting the FROM before the TO:
cp file ... directory;
TOPS-10 did it the other way, setting me up for culture shock.

It's easier to parse and interpret on-the-fly with the target first.

-- gil

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


Re: [ISPF-L] Re: DEF(__STRING_CODESET__)?

2020-12-23 Thread Paul Gilmartin
On 2020-12-23, at 09:06:18, Kirk Wolf  wrote:
> 
> OK then:
> 
> #pragma convert("UTF-8")
> 
Thanks.

But that's a single instance.  ISPF Edit supports 56 terminal
code pages, listed in the Ref., and numerous code pages for
subject files. I don't know where they're listed; perhaps
anything that LE supports.  There's a caution that metacharacters
in regular expressions will be intereprete according to the
CCSID of the controlling terminal.  How?  I'm envisioning
an enormous "switch"  with a "case" and a pragma for each.

The support is magnificent.  A file tagged with CCSID is
rendered correctly, within the capability of the terminal.
UTF-8 file and Cyrillic terminal just works.

Puzzlingly, I see no mention of locale sensitivity in the
Ref. for regcomp().

Interpreting metacharacters in regex according to the terminal
CCSID makes it impractical to author portable Edit macros
containing regex.


>> This is the way that we do it -
>> 
>> #pragma convert("ISO8859-1")
>> const char*  ASCII_LITERAL = "a literal string in ISO8859-1";
>> #pragma convert(pop)
>> 
> I'm more interested in the wildly popular UTF-8.

Thanks again,
gil

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


Re: Build and submit proc

2020-12-23 Thread Paul Gilmartin
On Tue, 22 Dec 2020 19:51:50 -0800, Tom Brennan wrote:
>
>... look out if //SYSUT2 happens to be above //SYSUT1, ...
> 
Is there a problem with that?  I've done it regularly; about half
the time.  And over 90% with //SYSUT1 DD DATA.  Easier to read
if other DD statements are closer to EXEC.

-- gil

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


Re: RMODE64

2020-12-23 Thread Paul Gilmartin
On Wed, 23 Dec 2020 08:43:31 -0500, Peter Relson  wrote:

>>> VERY FEW system services officially support invocation in RMODE 64. If 
>>> they don't say that they do, then do not assume that they do.
>>
>>Is there a blanket statement to this effect in the relevant manual(s)?
>
>No, nor likely will there be. The books document what z/OS supports your 
>doing. They do not tend to document what is not supported. This should not 
>be new news to anyone.
> 
But they don't "document what z/OS supports".  How many services make
an affirmative statement of support such as, "this service may be invoked
from a location below 2GiB"?

Perhaps you don't understand what I mean by "blanket statement":
a single affirmative sentence in the Introduction to the manual, "Any
service described herein may be invoked from a location below 2 GiB."
Adding that doesn't seem to be such "a significant cost".  Otherwise
you're arrogantly presuming every programmer has your profound
understanding of z/OS internals and needn't ask questions such as
the one that started this thread.

>This applies to almost everything relating to an interface, including (but 
>not limited to) AMODE 64, data above the bar, ASC mode, ARs, high halves 
>of GRs.
>
>You could certainly argue that all services should be perfectly clear on 
>all of these things. They should be. And if it cost nothing to make that 
>happen, they would be. But doing so would incur a significant cost that 
>has not been felt to be justified. Maybe if all the IBM-Main folks put 
>together a "go fund me" page they could fund such an effort course>

-- gil

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


Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 15:05:47 -0600, Hobart Spitz wrote:
>
>Still not enough?  Write (or get your favorite assembler programmer to
>write) a CMS SLEEP like program.  There might be one on a CBT tape or on
>the web.
> 
Assembler!?  CBT tape!?  What rock have you been under for the few
decades that bog standard OS/390 Rexx has had:
address SYSCALL 'sleep' 

>99% of what JCL does for you can be done in REXX.  99% of what you can do
>with REXX *cannot* be done in JCL. Anyone who thinks otherwise is just
>wrong or is too lazy to do a little extra work that saves a lot of work
>later.  Work smart, not hard.
>
I settled on a synthesis: code allocations, the JCL 1% as JCL DD statements
and the 99% heavy lifting in IRXJCL Rexx or IKJEFT01 Rexx. I wash my hands
after writing the JCL.

Mr. Natural sez, Use the right tool for the job.

-- gil

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


Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin
On Wed, 23 Dec 2020 07:43:24 +1100, Wayne Bickerdike  wrote:

>Many moons ago, when I was a trainee programmer I asked my senior
>programmer why IBM couldn't just get rid of JCL. He laughed. I was serious,
>still am 45 years later.
> 
How do you solve the ENQ deadlock problem?  Telephone the sysop and
ask that the other guy be cancelled.

You need a language that performs multiple ENQs en masse.  Your design
is graded C- if the programmer needs to mention any DSN more than once.

It's been a while since JOL has been touted here as an alternative.
Perhaps Clement Clarke is no longer a contributor.

-- gil

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


Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 13:14:07 -0600, Hobart Spitz wrote:

>You can do it in batch REXX.
>
>Stop being brain-dead and thinking about everything in terms of JCL.
>
>I've don't write JCL anymore.
>
>JCL causes brain-damage.
>
Be nice, or at least stay on-topic and ad-rem, not ad-hominem.

JCL and the Initiator provide protection against ENQ deadlock
not available with Rexx.


>On Tuesday, December 22, 2020, Jousma, David wrote:
>
>> I would build the JCL, and then FTP it with the filetype below.   That
>> will submit and run the job.
>>
Why is this preferable to just writing directly, or via IEBGENER to INTRDR?

>> SITE FILEtype=JES NOJESGETBYDSN
>> put your.modified.jcl.

-- gil

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


Re: Build and submit proc

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 12:23:49 -0500, David Spiegel wrote:
>
>The interpretation of JCL occurs before the execution starts. Hence,
>your result.
>If you were to SUBMIT your JCL to the internal reader in STEP02 (rather
>than trying to execute the BKUP Cataloged Procedure), the new job  would
>read the updated BKUP PROC.
> 
There might be a requirement for the submitted job to have a JOB
statement similar to the submitting job's.  The submitting job could
fetch its JOB statement with SDSF.

Referbacks are a harder problem.

Or, Rexx is your friend.  Use IRXJCL inline for the second step.


>On 2020-12-22 12:11, Fred Kaptein wrote:
>> Hello,
>> I would like to build a JCL batch job called BACKUPS, that does the 
>> following:
>> 1) STEP01
>>  Create a JCL proc in MYLIB.PROCLIB(BKUP)
>> 2) STEP02
>>  Execute the proc MYLIB.PROCLIB(BKUP)

-- gil

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


Re: DEF(__STRING_CODESET__)?

2020-12-22 Thread Paul Gilmartin
(cross-posting)
On 2020-12-22, at 09:31:06, Kirk Wolf wrote:
> 
> This is the way that we do it -
> 
> #pragma convert("ISO8859-1")
> const char*  ASCII_LITERAL = "a literal string in ISO8859-1";
> #pragma convert(pop)
>  
I'm more interested in the wildly popular UTF-8.  On my
desktop I can:
791 $ locale
LC_CTYPE="en_US.UTF-8"
... 
792 $ echo aπb | sed 's/../x/'
xb

The regex substitution converts the first two characters,
the 'a' and the 'π' to the 'x'.

Suppose I'm Editing a similar file with ISPF Edit, CTYPE UTF-8,
which ISPF supports, and a CP875 terminal (which ISPF supports
but I don't have).  How does the analogous Edit command do
its magic:
Change r'..' 'x'

-- gil

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


Re: DEF(__STRING_CODESET__)?

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 12:13:46 +0100, Mario Bezzi wrote:

>Turns out that it's a typo in the documentation. The actual environment
>variable name is __STRING_CODE_SET__ and its use is described in the
>same manual.
>
>I hope this helps,
>
Thanks.  Have you submitted an RCF?

How do __STRING_CODE_SET__ and CONVLIT affect functions with
string arguments such as printf() and, especially, regcomp()?
I note that the ISPF Edit manual says that regular expressions in
Find and Change accommodate the code page of the attached
terminal, or 1047 in batch.


>On 12/22/20 12:05 AM, Paul Gilmartin wrote:
>> In any z/OS 2.4 doc I can search, I find only a single reference
>> to __STRING_CODESET__, in XL C/C++ User’s Guide:

-- gil

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


Re: RMODE64

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 09:09:06 -0500, Joseph Reichman wrote:
>
>Thanks I’m not writing RMODE64 code don’t see a reason to 
>
>I don’t know why Ed co. does cann’t believe the code is that large 
>Thanks for the heads up about LE 
>
>I believe the real reason for RMODE64 is Java 
> 
And, perhaps, data CSECTs.


>> On Dec 22, 2020, at 8:57 AM, Peter Relson wrote:
>> 
>> VERY FEW system services officially support invocation in RMODE 64. If 
>> they don't say that they do, then do not assume that they do.
>>  ...
Is there a blanket statement to this effect in the relevant manual(s)?
 
-- gil

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


Re: RFE: Some SuperC options should cater for longer lines

2020-12-22 Thread Paul Gilmartin
On Tue, 22 Dec 2020 13:37:58 +, Seymour J Metz  wrote:

>> 27998, the non-spanned maximum blocksize for 3390 devices,
>
>That's the optimal block size, not the maximum.
>
For QSAM and BSAM, thee maximum block size is 32760.  It might
be larger for EXCP.

"non-spanned"?  Does 3390 have "spanned" blocks?  Track Overflow?

"optimal"?  I'd have said "optimum".

https://english.stackexchange.com/questions/50843/what-is-the-difference-between-optimal-and-optimum

>
>From:  Robert Prins
>Sent: Tuesday, December 22, 2020 6:47 AM
>
>On 2020-12-21 18:00, Paul Gilmartin wrote:
>> On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:
>>
>>> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
>>>
>Updated to:
>
>It would be useful is the current limit would be raised to a higher value, and
>tentative maximum values could be 27998, the non-spanned maximum blocksize for
>3390 devices, or 32767, the maximum signed value for a halfword, but even a
>value of 1024 or 4096 would be more helpful.
>
One might argue for LINE_MAX, 2048:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxbd00/limitsh.htm

-- gil

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


DEF(__STRING_CODESET__)?

2020-12-21 Thread Paul Gilmartin
In any z/OS 2.4 doc I can search, I find only a single reference
to __STRING_CODESET__, in XL C/C++ User’s Guide:

When NOASCII is in effect, the compiler uses the IBM-1047 code page
for character constants and string literals, unless the code page is
affected by other related options; for example, the CONVLIT, LOCALE,
or DEF(__STRING_CODESET__) compiler options.

Where is __STRING_CODESET__ defined, not just mentioned in passing?
Can it be set to 1208?

-- gil

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


Re: RFE: Some SuperC options should cater for longer lines

2020-12-21 Thread Paul Gilmartin
On Mon, 21 Dec 2020 19:38:30 +, Robert Prins  wrote:

>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=147550
>
Where I read: 
It would be useful is the current limit would be raised to a higher value,
and the logical value would be 32767, the maximum 2-byte signed value.

Ummm...
32760 for RECFM=FB
32756 for RECFM=VB
 for RECFM=VBS  (but does SuperC support VBS?)
 for UNIX files
But I believe for UNIX, SUPERC uses QSAM, which imposes the limits above.

Underreaching.  SuperC should impose *no* limit of its own, but simply
OPEN OLDDD and NEWDD and reflect any errors reported by OPEN.
Access method limitations are documented in "Using Data Sets".

(When last I tried, SuperC accepted allocated UNIX files for OLDD
 and NEWDD, but not for DELDD.  Go figger.)

-- gil

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


Re: RMODE64

2020-12-21 Thread Paul Gilmartin
On Mon, 21 Dec 2020 10:50:42 -0600, Joe Monk  wrote:

>Well that quote is from the z/os 2.3 binder.
> 
Thanks.  I pretty clearly cited 2.4, where it remains unchanged.
>
>On Mon, Dec 21, 2020 at 10:48 AM Paul Gilmartin  wrote:
>>
>> In:  z/OS  Version 2 Release 4
>> MVS Program Management: User's Guide and Reference
>> IBM  SA23-1393-40
>>...
>>ANY | 31
>>Indicates that the module might reside anywhere in virtual storage
>>either above or below the 16-MB virtual storage line. synonym for ANY.
>>
>> (RCF submitted on error in paragraph quoted above.)

-- gil

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


Re: RMODE64

2020-12-21 Thread Paul Gilmartin
On Mon, 21 Dec 2020 10:14:21 -0600, Joe Monk wrote:

>RMODE(64)When neither binder options RMODE=64 nor RMODEX are specified,
>RMODE(64) ESD are treated as RMODE(ANY) 

RMODE(ANY) is antiquated and misleading.  I prefer to see RMODE(31).

In:  z/OS  Version 2 Release 4
MVS Program Management: User's Guide and Reference
IBM  SA23-1393-40

I read:
   Residence mode
   ...
   ANY | 31
   Indicates that the module might reside anywhere in virtual storage
   either above or below the 16-MB virtual storage line. synonym for ANY.

It matters little what a Glossary entry might say, no more than a Glossary
can redefine "black" as  "white".

(RCF submitted on error in paragraph quoted above.)

-- gil

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


Re: RMODE64

2020-12-21 Thread Paul Gilmartin
On Sun, 20 Dec 2020 23:26:22 -0600, Mike Schwab wrote:

>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ceev100/am64ap.htm
>xplink 64.  Also available for 24/31 bit programs.
>
I see no mention of RMODE there. Am I looking in the wrong place?


On Sun, 20 Dec 2020 21:14:21 -0800, Ed Jaffe wrote:

>On 12/20/2020 9:01 PM, Joseph Reichman wrote:
>> Just wondering as there doesn’t seem too much documentation on this but I am 
>> wondering if there are any restrictions running RMODE64
>>
>>The assembler services guide has a AMODE in the environment but nothing about 
>>the RMODE
>
>There are many, Many, MANY restrictions!
>
Are these listed anywhere?  For code or for data?  Services calls?  Citation 
needed.

>Having said that, we're working on a not-yet-released product that is
>nearly 100% RMODE(64).
>
Why?  2GiB should be enough for anyone.

-- gil

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


Re: Compiler options in object code?

2020-12-21 Thread Paul Gilmartin
On Sun, 20 Dec 2020 11:52:13 -0800, Charles Mills wrote:

>Does anyone know where any compiler options are preserved in object code? I
>am at this moment specifically interested in the XL C/C++ compiler options
>TARGET and ARCH. In the pseudo-assembler listing I see
>
__ARCH__ is available as a predefined macro:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbclx01/macros_option_settings.htm
... Prefix an eyecatcher and STRINGIFY it.

I don't see TARGET there.

-- gil

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


Re: Compiler options in object code?

2020-12-20 Thread Paul Gilmartin
On Sun, 20 Dec 2020 11:52:13 -0800, Charles Mills  wrote:

>Does anyone know where any compiler options are preserved in object code? I
>am at this moment specifically interested in the XL C/C++ compiler options
>TARGET and ARCH. In the pseudo-assembler listing I see
> 
I know FOSS products that do something like defining CC_OPTS as
a makefile macro then also quote it to pass to the compiler.
Schematically:
cc ${CC_OPTS} -DCCOPTS="${CC_OPTS}" source.c

Make sure you use it so optimization doesn't toss it.  Printing
it in response to a "version" command should suffice.

-- gil

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


Re: COBOL LIB

2020-12-18 Thread Paul Gilmartin
On Thu, 17 Dec 2020 13:35:02 -0800, Charles Mills  wrote:

>It is whatever your installation called it!
>
>Which COBOL?
>
>Many installations use something like IGY or IGY630 or IGY.V630 or IGY.V6R3M0 
>as an HLQ. You could look for those in ISPF 3.4.
> 
That depends on the administrators' having configured the panel correctly.

Submit an ISPF background compile and browse the submitted JCL with SDSF SJ?

-- gil

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


Re: Rexx APIs (was: IODF address)

2020-12-17 Thread Paul Gilmartin
On Thu, 17 Dec 2020 19:46:13 +, Seymour J Metz wrote:

>Or at least a function to return the current address of a string variable, 
>plus some way to control alignment.
> 
I've pondered something similar in connection with wishing for a
variant of ATTACH that would leave the subtask running concurrently
rather than WAITing for its completion.  That's greatly complicated
by the uncertain operation of Rexx storage management -- there's
no guarantee that a variable wouldn't be moved while the subtask
runs.  It might be necessary to use IRXEXCOM to copy arguments
to aligned OBTAINed storage at ATTACH and back at DETACH.

"string variable"?  Didn't we agree a few weeks ago that's redundant?

>____
>From: Paul Gilmartin
>Sent: Thursday, December 17, 2020 2:18 PM
>
>...  Should Rexx have
>GETMAIN/FREEMAIN (or successor) interfaces?  That would
>be analogous to malloc()/free(), burdening the programmer with
>storage management and hazards wild stores.

-- gil

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


Rexx APIs (was: IODF address)

2020-12-17 Thread Paul Gilmartin
On Thu, 17 Dec 2020 18:47:27 +, Seymour J Metz wrote:

>I know of no REXX facility to enumerate environments, but z/OS Version 2 
>Release 4 TSO/E REXX Reference describes the relevant environment, LINKPGM.
>
LINKPGM, which is essentially Assembler LINK macro, works well
for such as ICSF; less well for such as SMP/E which require the
programmer to pass structures containing addresses of user
allocated request/reply buffers.  Should Rexx have
GETMAIN/FREEMAIN (or successor) interfaces?  That would
be analogous to malloc()/free(), burdening the programmer with
storage management and hazards wild stores.

In any case, LINKPGM in a loop may incur heavy LOAD/DELETE
overhead.  That might be alleviated with Rexx Content Supervision
interfaces, or LPA, or cached DASD.

-- gil

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


Re: IODF address

2020-12-17 Thread Paul Gilmartin
On Thu, 17 Dec 2020 15:59:45 +, Seymour J Metz wrote:

>Look at the address statement and at the descriptions of the available 
>environments.
>
Is there a Rexx facility to enumerate "available environments"?  I suspect not, 
but it
would be a good CbtTape.org candidate.

ADDRESS SYSCALL has a good selection of common C interfaces, but not
assembler/IODF.

CMS Rexx has a callable services library (CSL):

https://www.ibm.com/support/knowledgecenter/en/SSB27U_6.4.0/com.ibm.zvm.v640.dmsb1/cslfunc.htm
(I haven't used it.)  Perhaps more general; more cumbersome.
Something similar for z/OS Assembler Services might be a good
CbtTape.org candidate.

Farther afield, Regina has the Generic Call Interface
(GCI) which enables you to define any entry point in any system library
as an external Rexx function. GCI is built into Regina on many platforms.
I haven't used it.  Some interfacing may be required.

OoRexx?

__
>From: Steve Horein
>Sent: Thursday, December 17, 2020 7:36 AM
>
>I think it's just ignorance on my part, but I haven't had much luck calling
>assembler services from Rexx - only some of those mentioned in the
>"Callable Services for High Level Languages". There are a LOT of those
>services that look extremely helpful for getting precise information, but I
>just don't know how to take advantage of them.
>
>On Thu, Dec 17, 2020 at 3:41 AM Rob Scott  wrote:
>
>> If something like hyperswap has moved the IODF to another device, then you
>> can use the IOCINFO "IODFINFO" service and get the information from the
>> IODI structure that is returned :
>>
>> Mapping macro is IOSDIODI in MACLIB
>>
Rexx interface left as an exercise for the student?


>> -Original Message-
>> From: Steve Horein
>> Sent: 16 December 2020 17:00
>>
>> I am able to determine the IODF unit address from IPAIODFU in IPA.
>> However, this value becomes stale if the address changes when the storage
>> folks move disk around. I can see the MVS command DISPLAY IPLINFO accounts
>> for those changes in message IEE254I:
>>
>> IEE254Ihh.mm.ss IPLINFO DISPLAY text

-- gil

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


Re: JCL PARM issue

2020-12-14 Thread Paul Gilmartin
On Mon, 14 Dec 2020 11:56:53 +, Seymour J Metz wrote:

>Yes - you only have one level of expansion.
> 
And doubled ampersands in the PARMDD file are not collapsed.
This is documented.

I have found that there is a circumvention for the convention that
prohibits using JCL symbols in quoted strings in the SET statment.
Something like:
//  SET Q=,X='Middle'
//  SET TRIAD=

Of course that is covered by the rule:
• Do not specify JCL symbols within other JCL symbols. The results can be
   unpredictable, especially if the imbedded JCL symbol is not previously 
defined.

"unpredictable" is feckless engineering.  IBM simply doesn't care to document 
the
behavior lest IBM be subject to SRs when the system transgresses such rules.

The JCL Ref. has 18 pages describing the behavior of symbols, mostly exceptions.
This is a symptom of design inconsistency -- Conway's Law.

>____
>From:  Paul Gilmartin
>Sent: Sunday, December 13, 2020 3:43 PM
>>
>It's time for an RFE for the equivalent of HLASM's DOUBLE BIF.  No "Maybe".
>
>Does PARMDD handle this better?

-- gil

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


Re: JCL PARM issue

2020-12-13 Thread Paul Gilmartin
On Sun, 13 Dec 2020 13:05:41 -0800, Charles Mills wrote:

>Do you think IBM would conceivably embrace the idea of PARM= honoring " 
>(quotation marks) as delimiters?
>
>PARM="'abc�*' PCRE2.TESTLIB(GRPIN)"
>
>would be a lot clearer than 
>
>PARM='''abc�*' PCRE2.TESTLIB(GRPIN)''
>
>I find products that allow the use of either " or ' to delimit strings to be a 
>lot easier to use. "Don't touch!" is a lot clearer (to me at least) than 
>'Don''t touch!'. 
>
(What are the non-ASCII characters?  MUA too smart by half?)

Rexx rules!  Simply, characters introduced by symbol substitution are
*never* recognized as metacharacters, so with simple doubling but
not redoubling, and not resorting to alternate delimiters:

verb = 'isn''t'
phrase = verb 'good'
sentence = 'This' phrase'.'
say sentence

prints:
This isn't good.

Lexical catenation is also valuable.

-- gil

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


Re: JCL PARM issue

2020-12-13 Thread Paul Gilmartin
On Sun, 13 Dec 2020 19:46:34 +, Seymour J Metz wrote:

>You have a double substitution. Take the parameter you want to pass, double 
>the apostrophes, put apostrophes around it, double the apostrophes and put 
>apostrophes around that. The way you coded it, the first exapnsion there is a 
>blank outside of the apostrophes, making the rest of the string a comment.
>
>Maybe it's time for an RFE to include comments in the substitution JCL.
>
It's time for an RFE for the equivalent of HLASM's DOUBLE BIF.  No "Maybe".

Does PARMDD handle this better?

>
>From:  Ze'ev Atlas
>Sent: Sunday, December 13, 2020 2:31 PM
>
>What am I doing wrongI have doubled every single quote within the string, that 
>should be:'''abc�*' PCRE2.TESTLIB(GRPIN)''
>|||�|�+-+ 
>|||++|+--+where the 
>external quotes are the enclosing quotes.So the actual PARM field looked like:
>// EXEC RUNGREP,TEST='-- Test 15 -',// 
>PARM1='abc�*'' PCRE2.TESTLIB(GRPIN)'''
>++TEST8 EXEC PGM=PCR2GREP, ++  PARM= 
>  IEFC653I SUBSTITUTION JCL - 
>PGM=PCR2GREP,PARM=''abc�*'
>Why does JCL drop the rest of PARM1?Thank you all

-- gil

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


Re: Silly question - can one force IDCAMS PRINT to show printable lower case characters?

2020-12-12 Thread Paul Gilmartin
On Sat, 12 Dec 2020 23:40:52 +, Seymour J Metz wrote:

>I might believe lost in the world of 3211; the 3211 is older than IDCAMS. 
>Shirley it's time to add a CCSID operand.
> 
What would CCSID do?  What implementation do you envision?
Would it interface to InfoPrint?  Shouldn't every utility have one?
But that's redundant; it should be an option on DD SYSOUT.
DD, EXEC, and JOB already have a CCSID option.  Is that enough?

And if SYSPRINT is DASD, it should just pass the data unfiltered.

BitSavers reinforces my conjecture.  Something you don't want in a production 
job:
www.bitsavers.org/pdf/ibm/1403/GA24-3073-8_1403_printer.pdf

Data Check (Sense Bit 4)
Data check indicates that a code in a data record sent to the printer does not 
match a code in the Universal Character
Set (UCS) feature storage. Printing does not occur in the
print position to which the unmatching code applies. The entire line (except 
for the data check position) OIr only a portion of the line may be printed. 
Therefore, the last
printed line may contain erroneous data and/or an incomplete record. Data check 
usually indicates that the UCS storage
was improperly loaded or that a data record code (other than blank or null) 
does not compare to any code in the UCS storage.
Provide an operator message and exit from this error- recovery procedure. The 
operator should then:
1. Accept the record and indicate that the application
program is to proceed without further retry of the
command, or
2. Restart the application program from a logical
point.
If the error persists, a call should be made to a service
representative.

-- gil

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


Re: Silly question - can one force IDCAMS PRINT to show printable lower case characters?

2020-12-12 Thread Paul Gilmartin
On Sat, 12 Dec 2020 23:34:50 +0200, Binyamin Dissen 
 wrote:

>Silly question - can one force IDCAMS PRINT to show printable lower case
>characters?
>
GRAPHICS (CHAIN(TN))/*COMMENT*/ -

Who woulda thunk it.

How come in this 21st Century this isn't the default?  I suppose a data
check caused an important cu$tomer's printer to miss a batch window.

Don't know about Hebrew.

-- gil

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


JCL EXEC name field?

2020-12-11 Thread Paul Gilmartin
In  the JCL Ref.:

 Chapter 16. EXEC statement
...
Name field
...
• The stepname may be preceded by up to 8 alphanumeric or national 
characters
   and then separated by a period. If the stepname is coded in this way,
   the characters up to and including the period are ignored.

WTF?

A way of coding a very short comment?  Is "." OK?

-- gil

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


Re: How test correct procstep RC with JCL IF?

2020-12-11 Thread Paul Gilmartin
On Fri, 11 Dec 2020 12:32:10 -0800, Charles Mills wrote:

>"Note that if stepnames are
>not unique within the job, such as when the same procedure is executed multiple
>times, results might be unpredictable; but in most cases, references to 
>non-unique
>stepnames will resolve to the first occurrence of that stepname."
>
>Does not give me a warm and fuzzy feeling.
>
Reminds me of the several contributors here who insist that
"//DD:name" is safe for UNIX utilities documented only as
supporting "//data.set.name" because that's how fopen()
works.  Even for utilities not documented as relying on fopen().

>What is "might be unpredictable"? How is that different from "are 
>unpredictable"?
>
That just means that it's unpredictable whether it's unpredictable;
not guaranteed to be unpredictable.

I've argued here that the indolent developers should get to work and
make any use of an "unpredictable" construct a JCL error.  That has
no impact on compatibility; an unexpected JCL error is covered by
"unpredictable".  Think robust programming.

Peter R, with True Blue indolence, has rebutted that those unpredictable
constructs are reserved for IBM internal use or for future extensions.
I'm skeptical.

I've long felt that responsible design should have required that the
name fields on corresponding IF, THEN, ELSE, and ENDIF be identical,
on pain of JCL error, for verifying correct conditional nesting.

-- gil

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


Re: How test correct procstep RC with JCL IF?

2020-12-11 Thread Paul Gilmartin
On Fri, 11 Dec 2020 11:13:31 -0800, Charles Mills wrote:

>Oh for gosh sakes!
>
>I had the bright idea of passing a unique label for IF to test so the PROC
>becomes
>
>//MYPROC PROC PRM1=,PRM2=,LBL=
>// EXEC PGM= etc.
>// IF ( = 4) THEN
>//STEP2 EXEC PGM= etc.
>// ENDIF
>
>//X EXEC MYPROC,PRM1=A,PRM2=B,LBL=FOO
>//Y EXEC MYPROC,PRM1=C,PRM2=D,LBL=BAR
>
>But no!
>
>9 IEFC662I INVALID LABEL
>
>Apparently you can't use a symbol for a step name? Is that right?
>
True rather than right.

I hadda lookitup.  In the JCL Ref.:
Rules for coding symbols in JCL
Follow these rules when coding symbols in JCL:
...
4. Do not use symbols to change the identifier field, name field, or 
operation field of a JCL statement.

JCL specification was written by the infinite number of monkeys
who didn't grasp orthogonality.

Even worse are the rules for overrides and referbacks to nested
PROC calls.  I recognize that immutable structure of control blocks
allows for only two levels.  The restriction could have been eased
by generated procprocstep names.

-- gil

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


Re: CA Broadcom Replacement Software

2020-12-10 Thread Paul Gilmartin
On Thu, 10 Dec 2020 09:35:30 -0500, Tom Conley  wrote:

>On 12/9/2020 4:41 PM, Jesse 1 Robinson wrote:
>> I want to disagree that multiple emulator sessions--even the best, and you 
>> all know what that is--substitutes for a proper external session manager. ...
>> 
Does an "external session manager" present the appearance of multiple
(possibly emulated) terminals, leaving each connected mainframe session
oblivious to the presence of that manager or other sessions?


--
>While Skip brings up a point that multiple sessions may reach a limit of
>usability, the big limitation for me is only one window with the session
>mangler.  There are may times that I bring up two TN3270 windows side by
>side for comparisons, etc.  My other beef with Session Manglers is that
>you must have a good attention key config to move from session to
>session, and I've only encountered one installation that really worked.
>
Most desktop systems have the capability to:

o Run multiple concurrent instances of an application, each with its own
  window.  This is most common for Linux programs.  MacOS and
  Windows prefer to run only one instance at a time of any application.

o Allow a single instance of an application to open multiple windows.

o Allow an application to support multiple tabs within a single window.

I don't know which of these capabilities are supported by "even the best".

I'm not afflicted with Windows.  I understand that Windows 10 (finally)
supports multiple workspaces (desktops), a capability available for
many releases of MacOS and Linux.

In each case, the OS or application provides the capability to switch
easily between workspaces (gesture), instances, windows, or tabs
(click).  That should allow moving easily from session to session except
for the muriphobic.

Other valuable facilities are the ability to copy-and-paste text between
sessions or between a session and any other application (such as
email for communication with support) and to capture a screen image,
preferably as searchable text for documentation.

-- gil

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


Re: Security and z/OS open source tools

2020-12-09 Thread Paul Gilmartin
On Wed, 9 Dec 2020 21:58:34 +, Frank Swarbrick wrote:

>I have downloaded and installed in my personal z/OS Unix directory curl and a 
>few other z/OpenSource tools from Rocket Software.  I have asked my z/OS 
>security guy if we can go ahead and have our systems group (outsourced to IBM 
>zCloud) "officially" install them.  He came back with the following:  "My 
>question is how do we approve, track and secure the open source code we are 
>putting on z/OS?"
> 
Note that curl issued multiple security advisories today, including:
https://curl.se/mail/archive-2020-12/0007.html

How long does it take Rocket to catch up?

Have Rocket's patches been merged into the curl base on github?

>Does anyone have suggestions on answering this concern?

-- gil

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


Re: does anyone recall any details about MVS/XA?

2020-12-09 Thread Paul Gilmartin
On Wed, 9 Dec 2020 20:35:49 -, Lennie Dymoke-Bradshaw wrote:

>Doh.
>32bits + 12bits = 44bits
>
That feels like AR mode which IIRC was 31bits + 13bits = 44bits.

Somewhere I heard 1 bit / 2.5 years.
 https://en.wikipedia.org/wiki/Moore%27s_law


>-Original Message-
>From: Lennie Dymoke-Bradshaw
>Sent: 09 December 2020 20:31
>
>Under MVS/ESA we had expanded storage. Expanded storage allowed each page to 
>be addressed using a 32 bit address. As each page held 4096 (2**12) bytes the 
>effective addressing was 32bits + 12bits = 48bits.
>
>Is this what you were thinking of?

-- gil

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


Re: CA Broadcom Replacement Software

2020-12-09 Thread Paul Gilmartin
On Wed, 9 Dec 2020 19:35:22 +, Styles, Andy wrote:
>
>Logging back on with RECONNECT - either at a native VTAM (unformatted?) 
>screen, as in LOGON APPLID(blah) DATA(RECONNECT) - and/or possibly with the 
>Reconnect option selected on the full screen TSO logon screen takes me 
>straight back to where I was whenever I experience a drop out. I don't know 
>whether that's a setting in VTAM, IP or something else, but it has saved me on 
>countless occasions. That's assuming you're trying to get back to TSO of 
>course.
> 
How does RECONNECT interact with multiple tn3270 windows?  If each
RECONNECT restores an additional tn3270 session, it's tedious but effective.


>-Original Message-
>From: Pommier, Rex
>Sent: 09 December 2020 19:18
>
>I'm going to *slightly* disagree with the multi windows instead of a session 
>manager.  Session manager gets closer to a single signon ...


>-Original Message-
>From:  Gibney, Dave
>Sent: Wednesday, December 9, 2020 1:09 PM
>
>DFRMM for CA-1
>Multiple tn3270 windows instead of any session manager
> 
Have the difficulties with multiple tn3270 windows such as ISPPROF ENQ
conflicts been resolved?


>> -Original Message-
>> From: Elaine Beal
>> Sent: Wednesday, December 09, 2020 11:07 AM
>> 
>> Any recommendations for CA1, CA Workload Automation (JSS/ESP), TPX 
>> session manager replacements?

-- gil

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


Re: does anyone recall any details about MVS/XA?

2020-12-09 Thread Paul Gilmartin
On Wed, 9 Dec 2020 19:31:34 +0100, R.S. wrote:
>...
>> I perceived aversion to RECEIVE FROMNTS as UNIXphobia.  Our product
>> was not so large that DASD space was a concern.  Can't please everyone.
>
>Gil,
>Don't kill messenger ;-)
>
Was that statement hostile?  (But smiley noted.)
And thanks.

>Yes, it is possible to IPL from network, it has been possible since z990
>or z9.
>...
>Of course the server is not included, so it is up to you to set up some
>ftp/sftp/ftps server and disk space, and Internet connectivity.And power
>supply...
>
And, especially, configure IP address and path in (HMC?) bootstrap loader.

How much driver system needs to be installed to support RECEIVE ORDER?
(Is that the next step?

>... zLinux installation is IPL-able
>from network. ZZSA is IPL-able from network.
>
ZZSA?  AZERTY keyboard?

>BTW:  At the time z/VM
>was installable/IPL-able from both DVD and network.
>
z/VM and zLinux appear to be relatively advanced technologies.

Clarke's Third Law: Any sufficiently advanced technology is
indistinguishable from magic.

Thanks again,
gil

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


Re: does anyone recall any details about MVS/XA?

2020-12-09 Thread Paul Gilmartin
On Wed, 9 Dec 2020 18:25:19 +0100, R.S.  wrote:
>...
>For blank new installations - download (or order media) DVD images of
>Driver system and put it into DVD drive in HMC... Well... there is no
>longer DVD drive... However you can put DVD content into some ftp server
>directory and IPL from that directory.
>
Ah!  So it's possible to IPL from network.  (IANASysadmin, so not in my
skill set.)  FTP only, or other schemes?  FTP is problematic; too widely
considered insecure.  Windows has a server, concealed under IIS; I've
used FileZilla server.

MacOS and Linux readily support mounting .iso images; so "content" step may
be skipped.  Windows image mounter flickers in and out of support.  I used
Virtual CloneDrive (Dolly? in logo).

Never for IPL (IANASysadmin), but for SMP/E RECEIVE FROMNETWORK.
Testers found the process so tedious I fell back to packaging a "pax"ed
SMPNTS and recommending "pax -r"; RECEIVE FROMNTS.

Some customers wished for a set of .xmit PDSU.  I demurred; masochists:
Too many steps for them to install; unlike any IBM product (but the
customer cited one product so packaged.  It was from a recently-acquired
subsidiary).  And too many steps for me to package.

I perceived aversion to RECEIVE FROMNTS as UNIXphobia.  Our product
was not so large that DASD space was a concern.  Can't please everyone.

-- gil

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


Re: does anyone recall any details about MVS/XA?

2020-12-08 Thread Paul Gilmartin
On Wed, 9 Dec 2020 01:50:32 +, Jesse 1 Robinson wrote:

>We have downloaded ServerPac for years entirely from the network. No need for 
>tape.
> 
What would one use to access the network?

>
On Wed, 9 Dec 2020 02:12:11 +, Seymour J Metz wrote:
>
>AFAIK tape is no longer an option. There used to be a DVD option; I don't no 
>whether it is still available. The normal vehicle for product and service 
>these days is the Internet.
>
>The basic process is still the same; if you don't have a driver system, you 
>need to restore a starter system and you must have an IOCDS that supports it. 
>The CBPDO dialogs all run on the driver system and the new system.

>____

>>>From:  Paul Gilmartin 
>Sent: Tuesday, December 8, 2020 8:41 PM
>
>What's the process today for a new site with no real tapes?
>
I mean a really, really new site.

-- gil

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


Re: does anyone recall any details about MVS/XA?

2020-12-08 Thread Paul Gilmartin
On Wed, 9 Dec 2020 00:48:31 +, Seymour J Metz wrote:

>You needed an MVS driver system to install MVS/XA. Most customers already had 
>an existing MVS/SP system, and didn't need to order the starter system. IPO 
>and PSO were available later. Optional souce was available on tape. There was 
>no PTF optional source; if the module was hit by service, you had to rely on 
>the microfiche.
>
What's the process today for a new site with no real tapes?

-- gil

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


Re: TSO ALLOCATE Pathname Length?

2020-12-05 Thread Paul Gilmartin
On Fri, 4 Dec 2020 16:12:21 -0800, Charles Mills wrote:

>And for JCL perhaps 255 is a reasonable limit. With only about 55 usable 
>columns on a JCL continuation statement, anything more than that becomes a 
>little unwieldy. (Yes, one might say all JCL statements are unwieldy!)
>
Don't denigrate the determination of programmers.  If one manages to
code a 1023-byte pathname spanning 19 lines (probably using an Edit
macro), the system should reward such perseverance by honoring it.

(Easier with PARMDD.)

Allowing allocation by relative pathname would help considerably in some
cases.

>But why does DYNALLOC limit to 255? With a 16-bit text unit length field it 
>would be easy to accommodate 1023 (or, of course, 32767 or 65535).
>
+1

-- gil

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


Re: TSO ALLOCATE Pathname Length?

2020-12-05 Thread Paul Gilmartin
On Sat, 5 Dec 2020 09:22:19 -0800, Charles Mills wrote:
>
>... IIRC I had a bug in software I was
>developing and created a dataset with what I had intended would be a PDS
>member name, TEST or FOO or something like that, and it worked with no
>issues. In some cases there might be a catalog access violation enforced by
>RACF, but that would not mean the dataset name itself was invalid.
>
//X  DD  DSN=(,KEEP),DSN='(FooBar)',UNIT=SYSALLDA,SPACE...
... creates an uncatalogued PS data set (before SMS).

Really bugged storage admins.

What about "DISABLE(DSNCHECK)"

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.idac100/c1030.htm

Does anyone use this?  Does anyone even care?

I suggested it long ago as a remedy for a DoS exposure in the OMVS
"mount" command.  No one paid attention, and IBM chose instead to
restrict the syntax of "mount"

-- gil

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


TSO ALLOCATE Pathname Length?

2020-12-04 Thread Paul Gilmartin
As long as we're discussing pathname length limits:

The JCL Ref says the value of PATH may be from 1 to 255 bytes.
The DYNALLOC Guide says the value of DALPATH may be from 1 to 255 bytes.

TSO/E commands and subcommands: ALLOCATE Command,
which I assume is based on DYNALLOC says
PATH(pathname) Identifies a UNIX file.
... The path name can be 2 to 250 characters, including the initial slash.

Why the somewhat more restrictive limit?

ObEmerson: Consistency?

Conway's Law?

-- gil

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


Re: Unable to ALLOC dsn without new

2020-12-04 Thread Paul Gilmartin
On Fri, 4 Dec 2020 14:38:29 -0800, Ed Jaffe wrote:

>On 11/24/2020 8:35 AM, Elaine Beal wrote:
>> I thought you had to have the new parm but i can ALLOC a new dsn under 
>> another id without it.
>
>New is the default in JCL. Maybe on ALLOC too!
>
From: z/OS: TSO/E Command Reference (They don't make it easy to remember):
If you do not specify OLD, SHR, MOD, NEW, or SYSOUT, a default value is 
assigned or a value is prompted for, depending on the other operands specified:
• If the LIKE operand or any space operands (SPACE, DIR, BLOCK, BLKSIZE, 
AVBLOCK, TRACKS, or CYLINDERS) are specified, then the status defaults to NEW.
• If the COPIES operand is specified, then the status defaults to SYSOUT.
• If the DATASET/DSNAME operand is entered without the LIKE operand or any 
space operands, then the status defaults to OLD.
• If the LIKE operand, the DATASET/DSNAME operand, and the space operands are 
all omitted, you are prompted to enter a status value.

In JCL, MOD may not have exactly the desired behavior.  Sometimes
I've resorted to:
//HANDLE  DD  DISP=(MOD,CATLG),SPACE...
//SYSUT2  DD  DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE

-- gil

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


Re: C macro for maximum path length?

2020-12-04 Thread Paul Gilmartin
On Fri, 4 Dec 2020 09:25:07 -0800, Charles Mills  wrote:

>@Gil, weren't you going to try a mkdir wombat/cd wombat endless loop and see 
>where it failed?
> 
My latest attempt:
# ###
#! /bin/sh
# Doc: Test limits of path length (PATH_MAX)
#  and directory nesting depth.

Build() { F="$1"
( while mkdir "$F" & cd "$F"; do pwd; done ) | tee "$F.log"; }

set x "Ridiculously long file name"

for I; do
Build "$I"; done

echo; uname -sr
for I; do
wc "$I.log"
tail -1 "$I.log" | wc; done
exit
# ###
I've long feared to try such things on z/OS because it's too easy to
create an object on which "rm -r" fails because of either excessive
recursion depth or excessive geenerated path length.

I'm not afflicted with a DOS system to test.

On Linux, it "fails cleanly":
Linux 4.19.0-12-amd64
   20412041 4196296 x.log
  1   14096
   145  31900 298410 Ridiculously long file name.log
  1 4364074

The limitation seems to be path length (~4096) rather than
nesting depth (at least 2041).

On MacOS it generates a stream of error messages until I interrupt it:
chdir: error retrieving current directory: getcwd: cannot access parent 
directories: No such file or directory
pwd: error retrieving current directory: getcwd: cannot access parent 
directories: No such file or directory

But never sets error status.  I suspect that setting the environment
variable PWD may mask an underlying problem.

>What happens if you make ~the maximum length path (~1024?) and then mount it 
>on some mount point?
>
>It seems like any "opt-in" for a longer path name would want to be program by 
>program (again, analogous to long parms) 
>
YA program object attribute?  Or JCL JOB option

I feel the same way about REFRPROT.  A site might need to keep
REFRPROT(NO) for backward compatibility while conscientious
programmers should enable REFRPROT(YES) for their own programs.
(REUS(REFR,REALLY)?)

>because I as a vendor would have no control over whether a customer did a 
>"global" opt-in in PARMLIB. (I would just get the "it blew up" ticket.)

>-Original Message-
>...
>On Fri, 4 Dec 2020 08:19:34 -0500, Peter Relson wrote:
>>
>>And that's why z/OS will never change the maximum path length by default 
>>(I actually thought it was 1024, but my knowledge is only from what 
>>CSVQUERY implemented and documents for returning the path name). There 
>>would have to be some sort of "opt-in" for a longer name.
>>
z/OS seems to be inviting the pitfall by  not providing the POSIX-required and
safe "allocating" form of realpath()?
>
A programmer with FOSS code that compiles successfully on a POSIX-conformant
system and fails on z/os because of the lack of PATH_MAX and who is most
familiar with:  Authorized Assembler Services Guide
DALPATH specifies the pathname of the z/OS UNIX file to be allocated.
... The maximum length of the pathname is 255 characters
and: z/OS: MVS JCL Reference; DD: PATH
pathname ...
• Has a length of 1 through 254 characters, not including the slash.

... is apt to take 255 as gospel and  code in desperation:
#ifndef PATH_MAX
#define PATH_MAX 255
#endif

(Why is the DALPATH parameter limited to 255 bytes, given that the
length is passed in a halfword?)

-- gil

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


Re: Getting Enhanced HOLDDATA from IBM

2020-12-04 Thread Paul Gilmartin
On Fri, 4 Dec 2020 17:25:09 +, Richards, Robert B. (CTR) wrote:

>EZA1736I FTP (EXIT 
>  
>EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration 
>parameters. 
>EZA1450I IBM FTP CS V2R3   
>  
>EZA1772I FTP: EXIT has been set.   
>  
>EZA1456I Connect to ?  
>  
>EZA1736I  dispby-112.boulder.ibm.com   
>  
>EZA1554I Connecting to: dispby-112.boulder.ibm.com 170.225.15.112 port: 21.
>  
>220-*
I used: ftp://service.boulder.ibm.com/s390/holddata/full.txt

It seems intermittent.  I got some timeouts;  the last few times it succeeded.
That might mean that it cached enough to work finally.  I had no failures
with ...service...

... 
 
>EZA1736I  locsite lrecl=80 blksize=0 recfm=fb cyl primary=15   
>  
>EZA1460I Command:  
>  
>EZA1736I  get full.txt 'xxxdsnxxx' (repl 
>EZA1701I >>> PORT 10,1,21,1,112,164
>  
>200 PORT command successful
>  
>EZA1701I >>> RETR full.txt 
>  
>150 Opening ASCII mode data connection for full.txt (16877484 bytes)   
>  
>EZA2590E recv error from receive_data - EDC8121I CONNECTION RESET. 
>(errno2=0x74520442)   
>EZA2607W Transfer aborted due to receive error (-1)
>  
>EZA2589E Connection to server interrupted or timed out. Initial IPv6 
>connection  
>EZA1721W Server not responding, closing connection.
>  
>EZA1735I Std Return Code = 16150, Error Code = 00010   

-- gil

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


Re: Getting Enhanced HOLDDATA from IBM

2020-12-04 Thread Paul Gilmartin
On Fri, 4 Dec 2020 17:03:37 +, Richards, Robert B. (CTR) wrote:

>Is anyone else getting connection resets when they attempt to do a FTP "get" 
>of the full.txt file?
>
>cd /s390/holddata
>locsite lrecl=80 blksize=0 recfm=fb cyl primary=15
>get full.txt 'your dataset name here' (repl
> 
Could you provide a full transcript:?

>results in:
>
>150 Opening ASCII mode data connection for full.txt (16877484 bytes)
>EZA2590E recv error from receive_data - EDC8121I CONNECTION RESET. 
>(errno2=0x74520442)
>EZA2607W Transfer aborted due to receive error (-1)
>EZA2589E Connection to server interrupted or timed out. Initial IPv6 connection
>EZA1721W Server not responding, closing connection.
>EZA1735I Std Return Code = 16150, Error Code = 00010
>

Not I:
647 $ curl -fOD - ftp://service.boulder.ibm.com/s390/holddata/full.txt
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:--  0:00:02 --:--:-- 
0220-***   * 
220-**
220-...
220 service.boulder.ibm.com FTP server (WU Version 2.6.3(5) Custom Fri Jun 2 
11:15:33 MDT 2017) ready.
331 Guest login ok, send any password.
230 Guest login ok, access restrictions apply.
257 "/" is current directory.
  0 00 00 0  0  0 --:--:--  0:00:03 --:--:-- 
0250 CWD command successful.
250 CWD command successful.
500 'EPSV': command not understood.
227 Entering Passive Mode (170,225,15,26,242,29)
200 Type set to I.
213 16877484
150 Opening BINARY mode data connection for full.txt (16877484 bytes).
 97 16.0M   97 15.6M0 0   817k  0  0:00:20  0:00:19  0:00:01  
982k226 Transfer complete.
100 16.0M  100 16.0M0 0   839k  0  0:00:19  0:00:19 --:--:-- 1056k

648 $ ls -l full.txt
-rw-r--r-- 1 paulgilm paulgilm 16877484 Dec  4 10:06 full.txt

-- gil

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


Re: C macro for maximum path length?

2020-12-04 Thread Paul Gilmartin
It would be a courtesy to leave a citation when appending to a thread.
A reader might wish to refer to the ped text.

On Fri, 4 Dec 2020 08:19:34 -0500, Peter Relson wrote:

>
>The real question is not "how long can a path be [today]?" but rather "how 
>long might a path be at any future point when this compilation is 
>running?" 
>
>
>And that's why z/OS will never change the maximum path length by default 
>(I actually thought it was 1024, but my knowledge is only from what 
>CSVQUERY implemented and documents for returning the path name). There 
>would have to be some sort of "opt-in" for a longer name.
>
Why, then, does z/OS not provide the POSIX-required and safe "allocating" 
form of realpath()?

Are any other utilities/functions affected?

Is it IBM's uniform policy never to relax any limit because a suitably
mischievous (or stupid) programmer might leverage it into an exposure?

How does this cover:
o NFS, where IBM can't control the content of the guest filesystem?
o The possibility that administrators might mount a tower of
  filesystems to a height beyond the putative hard-coded PATH_MAX
  ("putative" in that the value is mentioned in (obsolete?) M but
  no macro is defined)?

Study: https://eklitzke.org/path-max-is-tricky

-- gil

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


Re: C macro for maximum path length?

2020-12-03 Thread Paul Gilmartin
On Thu, 3 Dec 2020 11:49:05 -0500, Gord Tomlin wrote:

>On 2020-12-03 10:12 AM, Charles Mills wrote:
>> I believe you, but why then is the macro undefined? Why is the definition 
>> now commented out?
>> 
I suspect there's a buffer overrun hazard associated with a statically compiled
PATH_MAX.  Interesting, apparently well-researched link:
https://eklitzke.org/path-max-is-tricky

>> >From  (actually CEE.SCEEH.H(LIMITS)) on z/OS V2R4:
>> /*
>>   *  POSIX.1 1990 Section 2.8.5 Statement 1065 -
>>   *  these macros "shall be omitted on specific
>>   *  implementations where the corresonding value is
>>   *  >= the stated minimum, but where the value
>>   *  can vary depending on the file to which it is
>>   *  applied."
>>   *...
>>* #define LINK_MAX
>>* #define MAX_CANON
>>* #define MAX_INPUT
>>* #define NAME_MAX
>>* #define PATH_MAX
>>* #define PIPE_BUF
>>*/
>
>"an application may use the/fpathconf/()  
><https://pubs.opengroup.org/onlinepubs/009696699/functions/fpathconf.html>,/pathconf/()
>  <https://pubs.opengroup.org/onlinepubs/009696699/functions/pathconf.html>, 
>and/sysconf/()  
><https://pubs.opengroup.org/onlinepubs/009696699/functions/sysconf.html>  
>functions to
>determine the actual value of a limit at runtime."
>
>(<https://pubs.opengroup.org/onlinepubs/009696699/basedefs/limits.h.html>)
> 
OpenGroup/Single UNIX requires an "allocating" form of realpath();
z/OS XL C/C++ fails to provide one.

More:
What is the OP doing with this?

Even more:
   https://eklitzke.org/path-max-is-tricky

Rexx ADDRESS SYSCALL realpath
returns strings which appear correct but seem to exceed the
PATH_MAX computed by pathconf().  When I expressed astonishment
about that on MVS-OE, WJS replied:
   http://vm.marist.edu/htbin/wlvtype?MVS-OE.61764
   I suspect C passes a buffer of PATH_MAX+1.  The REXX support tends to use a
   local 4K scratch buffer for system call output areas when it can, and does
   in this case.
I.e. just define it as 4K and hope for the best.

I'll try this on Linux:
   ( set -x; while true; do mkdir wombat; cd wombat; pwd; done )

-Original Message-
From: Paul Gilmartin 
Sent: Wednesday, December 2, 2020 3:33 PM

read: https://www.zsh.org/mla/workers/2000/msg03393.html
etc. and weep.

-- gil

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


Re: C macro for maximum path length?

2020-12-02 Thread Paul Gilmartin
On Wed, 2 Dec 2020 16:43:11 -0800, Charles Mills  wrote:

>This code has been changed since I last compiled it on Z but I don't think I 
>changed that reference. It appears that PATH_MAX went away somewhere between 
>V2R2 and V2R4. I see some comments in limits.h that are consistent with that.
>
Longer, I think.  My utility realpath.c is dated 2012.
(I recompiled it on Mac OS and pedantic C issued 3 warnings;
one a genuine error in an unlikely path.)

>I picked up _POSIX_PATH_MAX from limits.h. I am running POSIX(ON). It that a 
>valid maximum path length or am I likely to get whacked with a buffer overflow?
>
>Re-stating the question, what is the maximum path length on z/OS UNIX? Can it 
>really be true that there is no hard maximum? I really have to ask pathconf() 
>every time? No maximum of possible maximums? The maximum is really whatever 
>z/OS wants it to be today?
>
Alas, I suspect yes. Single UNIX says:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html#tag_16_479_03
If resolved_name is a null pointer, the generated pathname shall be stored 
as a null-terminated
string in a buffer allocated as if by a call to malloc().
...
If the resolved_name argument is a null pointer, the pointer returned by 
realpath()
can be passed to free().
(Probably a good idea.)  But z/OS XL C C++:
 EINVAL
[the] resolved_name argument is a NULL pointer.

I suspect the concern may be that in the future the constraint may be relaxed
but you'll run a dusty program object allocating a static resolved_name and
incur a buffer overrun.

>What is FILENAME_MAX, referenced in 
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxbd00/fldata.htm
> ?
>
Don't know.  Can that be misused to incur a buffer overflow?  I suppose if
you parse a pathname and copy a component into a static char[ FILENAME_MAX ].

-- gil

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


  1   2   3   4   5   6   7   8   9   10   >