Re: allowed characters in member name

[Lennie Dymoke-Bradshaw]

Using quotes around the DSNAME will allow any combination of Hex chars for a 
Dsname I think (possibly excluding 44X'04' which represents the VTOC). However 
these are not supported for SMS datasets, nor can they be catalogued, nor can 
they be protected by RACF.
https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter

Note particularly,

"The system does not check data set names enclosed in apostrophes for valid 
characters. When SMS is
not installed or active incorrect characters or length result in data set 
allocation, but the data set is not
cataloged. When SMS is active, it will fail the job for incorrect characters or 
length."

However, I think it is not possible to do this with a member name. Happy to 
learn more though, if someone knows better.

Lennie Dymoke-Bradshaw
https: //rsclweb.com
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Leonard D Woren
Sent: 08 January 2024 06:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

I don't think anyone has mentioned that X'C0' (left brace in the U.S.) is valid 
in a member name.  I didn't test to see whether it's allowed in the first 
position; probably not.

X'C0' is also valid in a dsname on a non-SMS volume, but it's now broken in 
that you can't catalog it any more.  Get "NOT CATLGD 9". 
Again, I didn't try it in the first position which almost certainly is not 
allowed.


Regarding the limit of 8 characters between periods in a dsname, that was a 
requirement in OS CVOL days.  Seems to me that that validity test can and 
should be removed now that CVOLs are long long dead dead.  I could see 
requiring any levels in an MLA alias restricted to
8 characters.  Why is left as an exercise to the reader.


/Leonard




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

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

Re: allowed characters in member name

[Lennie Dymoke-Bradshaw]

I believe these came in with the re-write of the JCL Converter and/or 
Interpreter which occurred with MVS 4.2 (working purely from memory!)

Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 07 January 2024 23:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
LIKE= was part of that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 5:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:

>DCB for the subparameters as been depreciated and, in my opinion, bad form for 
>most of the 40 years I worked on mainframes. The DCB=modeldscb form used for 
>new GDS allocations hasn't been needed since SMS came along. Early 90s'?
>I may recall wrong, but I think LIKE was new with SMS.
>
Formerly needed; now deprecated.  Why was it ever needed?  I suspect the change 
was less to accommodate SMS than UNIX files, which support attributes but no 
DCB.

Answering my earlier question (IRTFM):

Example 2
//SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
//  LRECL=1024
In the example, the data set attributes used for MYDS7.PGM are obtained from
the cataloged model data set MYDSCAT.PGM. Also, the logical record length of
1024 overrides the logical record length obtained from the model data set.

--
gil

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

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

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

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 07.01.2024 o 21:55, Paul Gilmartin pisze:

On Sun, 7 Jan 2024 21:04:48 +0100, Radoslaw Skorupka wrote:

...
I have to admit: I almost never used DCB keyword in JCL and (AFAIR)
absolutely never DCB=HLQ.DATASET.NAME.
When teaching JCL I explain it, but also advice to not using that.
BTW: LIKE=HLQ.FOO-BAR works like a charm.


in :
 [ DCB= ( {dsname   }[,subparameter]...) ]

Is it possible likewise to override selected subparameters
of LIKE?  Was it so even before the subparameters were allowed
as separare parameters?  (Old habits diehard.)


Yes, yes, and yes.
I always use (and teach) that technique - LIKE says "I want the same, 
BUT..." and you provide the differences.
Of course it is IMHO unacceptable to *partially* support legal DS names 
in JCL - I mean DCB not accepting HLQ.FOO-BAR.



--
Radoslaw Skorupka
Lodz, Poland

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

Re: allowed characters in member name

[Radoslaw Skorupka]

W dniu 08.01.2024 o 05:01, Paul Gilmartin pisze:

On Mon, 8 Jan 2024 03:42:05 +, Gibney, Dave wrote:


Before LIKE, you needed IDCAMS to create VSAM files, after LIKE you could do 
this with just JCL


Ah.  So for PS or PO it has no advantage over DCB=dsname.  Perhaps for SPACE?


A lot of advantages including DSNTYPE (LARGE, EXTPREF - previously not 
available in JCL, only DC), PDSE compression, encryption, VSAM EA, etc.

Last, but not least: it is CONVENIENT.
I it just convenient to create new dataset "same as A.B.C".

--
Radoslaw Skorupka
Lodz, Poland

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

How to configure using PDS members in JCL.

[Colin Paice]

I have a PDS with configuration definitions in it and want to make it easy
to configure.

I want to have PDS members with content like PERMIT ... ACCESS(READ)
CLASS(...) ID(&ID)
and want the &ID to be substituted for example in JCL // SET ID=COLIN, and
be able to change the value on each run.
However JCL symbols only work with SYSIN DD * type data not within dataset
members.

What is the best way of doing this?

- I could have an inline IEBUPDTE which does the substitution and creates
the members.
- I've found references to IPOUPDTE.  Is there a modern version of this
provided by IBM?
- I could write an ISPF macro.
But none of these match the ease of changing the JCL // SET ID=COLIN
statement.

Colin

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

Re: How to configure using PDS members in JCL.

[Charles Hardee]

Colin,

I do it using IEBGENER:

// JCLLIB ORDER=pds.with.members.to.use
//SETSTEP  EXEC PGM=IEBGENER
//SYSINDD   DUMMY
//SYSPRINT DD   SYSOUT=*
//SYSUT1   DD   *,SYMBOLS=JCLONLY
// INCLUDE MEMBER=x
//SYSUT2   DD   DISP=SHR,DSN=dataset.to.contain.resolved.member

I don't know if this will work for you, but it works for my needs.

You probably wouldn't want to put the substitution output back into the
original file.
Depending on how you're going to use the result, you could use a temporary
file or a permanent file.

Chuck

On Mon, Jan 8, 2024 at 6:16 AM Colin Paice  wrote:

> I have a PDS with configuration definitions in it and want to make it easy
> to configure.
>
> I want to have PDS members with content like PERMIT ... ACCESS(READ)
> CLASS(...) ID(&ID)
> and want the &ID to be substituted for example in JCL // SET ID=COLIN, and
> be able to change the value on each run.
> However JCL symbols only work with SYSIN DD * type data not within dataset
> members.
>
> What is the best way of doing this?
>
> - I could have an inline IEBUPDTE which does the substitution and creates
> the members.
> - I've found references to IPOUPDTE.  Is there a modern version of this
> provided by IBM?
> - I could write an ISPF macro.
> But none of these match the ease of changing the JCL // SET ID=COLIN
> statement.
>
> Colin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: How to configure using PDS members in JCL.

[Robert Prins]

On Mon, 8 Jan 2024 at 12:16, Colin Paice  wrote:

> I have a PDS with configuration definitions in it and want to make it easy
> to configure.
>
> I want to have PDS members with content like PERMIT ... ACCESS(READ)
> CLASS(...) ID(&ID)
> and want the &ID to be substituted for example in JCL // SET ID=COLIN, and
> be able to change the value on each run.
> However JCL symbols only work with SYSIN DD * type data not within dataset
> members.
>
> What is the best way of doing this?
>
> - I could have an inline IEBUPDTE which does the substitution and creates
> the members.
> - I've found references to IPOUPDTE.  Is there a modern version of this
> provided by IBM?
>

https://www.jaymoseley.com/hercules/cbt_ware/pdsupdte.htm

Comes with source, so can be changed to handle, like my version, lowercase,
and doesn't need the IPOUPDTE required $$$COIBM member.

Of course you're aware that edit macros change ISPF stats, which may not be
desirable, and large number of changes may fill up a PDS...

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: How to configure using PDS members in JCL.

[Seymour J Metz]

CPPUPDTE (nee IPOUPDTE) only changes a  existing member; the easiest ways I can 
think of to do what you want are ISPF file tailoring or JCL substitution with a 
// INCLUDE. I would probably go with the former.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Colin Paice 
Sent: Monday, January 8, 2024 7:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How to configure using PDS members in JCL.

I have a PDS with configuration definitions in it and want to make it easy
to configure.

I want to have PDS members with content like PERMIT ... ACCESS(READ)
CLASS(...) ID(&ID)
and want the &ID to be substituted for example in JCL // SET ID=COLIN, and
be able to change the value on each run.
However JCL symbols only work with SYSIN DD * type data not within dataset
members.

What is the best way of doing this?

- I could have an inline IEBUPDTE which does the substitution and creates
the members.
- I've found references to IPOUPDTE.  Is there a modern version of this
provided by IBM?
- I could write an ISPF macro.
But none of these match the ease of changing the JCL // SET ID=COLIN
statement.

Colin

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


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

Re: allowed characters in member name

[Seymour J Metz]

I believe that GDG model DSCBs are still a thing for non-SMS volumes.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Sunday, January 7, 2024 8:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Going back to hazy memories...

GDGs needed the DSN specified, and the DCB info DCB=(dsn,) so
that the allocation routines would correctly set the DSCB info
for the data set by getting the LRECL, RECFM, etc. so that
allocation would have all that. I'm not sure that DFP V3 fixed
this, or SMS or what. But I remember having to remember to do
these things back in the day, for SMF tapes and the like, when
doing the initial allocation for a GDG generation data set (GDS)
(+1, etc.).

Steve Thompson

On 1/7/2024 5:15 PM, Paul Gilmartin wrote:
> On Sun, 7 Jan 2024 21:50:07 +, Gibney, Dave wrote:
>
>> DCB for the subparameters as been depreciated and, in my opinion, bad form 
>> for most of the 40 years I worked on mainframes. The DCB=modeldscb form used 
>> for new GDS allocations hasn't been needed since SMS came along. Early 90s'?
>> I may recall wrong, but I think LIKE was new with SMS.
>>
> Formerly needed; now deprecated.  Why was it ever needed?  I suspect the 
> change
> was less to accommodate SMS than UNIX files, which support attributes but no 
> DCB.
>
> Answering my earlier question (IRTFM):
> 
>  Example 2
>  //SMSDS7  DD  DSNAME=MYDS7.PGM,LIKE=MYDSCAT.PGM,DISP=(NEW,KEEP),
>  //  LRECL=1024
>  In the example, the data set attributes used for MYDS7.PGM are obtained 
> from
>  the cataloged model data set MYDSCAT.PGM. Also, the logical record 
> length of
>  1024 overrides the logical record length obtained from the model data 
> set.
>

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

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

Re: allowed characters in member name

[Seymour J Metz]

L?

I would expect 8X'FF' to work for PDSE, but what happens with PDS?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Beaver <050e0c375a14-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Actually STOW 8XL’FF’

Will work

Sent from my iPhone

No one said I could type with one thumb

> On Jan 7, 2024, at 18:34, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:
>
>> Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>> subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe 
>> that LIKE= was part of that.
>>
> Did LIKE add any expressive power that DCB lacks?
>
> I believe neither DCB nor LIKE can be used in nor refer to DD PATH=
>
> The alternative might be to use JCL symbols for common attribute strings.
>
> Combining brevity and mnemonic value:
>Q = "'"
>QQ = '"'
>
> Don't forget to mention them in PROCEDURE EXPOSE.
> SIGNAL ON NOVALUE would remind you, if you chose to use it.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


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

Re: allowed characters in member name

[Seymour J Metz]

I don't know of any difference in expressive power and, no, you can't use it 
with a path.

ObVir I don't find Q and QQ to be mnemonic. YMMV.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 7, 2024 7:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Sun, 7 Jan 2024 23:42:41 +, Seymour J Metz wrote:

>Long ago (in OS/390?) IBM introduced a bunch of keywords equivalent to 
>subparameters of DCB, e.g., LRECL= is equivalent to DCB=LRECL=. I believe that 
>LIKE= was part of that.
>
Did LIKE add any expressive power that DCB lacks?

I believe neither DCB nor LIKE can be used in nor refer to DD PATH=

The alternative might be to use JCL symbols for common attribute strings.

Combining brevity and mnemonic value:
Q = "'"
QQ = '"'

Don't forget to mention them in PROCEDURE EXPOSE.
SIGNAL ON NOVALUE would remind you, if you chose to use it.

--
gil

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


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

Re: allowed characters in member name

[Paul Gilmartin]

On Mon, 8 Jan 2024 11:00:38 -, Lennie Dymoke-Bradshaw wrote:

>Using quotes around the DSNAME will allow any combination of Hex chars for a 
>Dsname I think (possibly excluding 44X'04' which represents the VTOC). However 
>these are not supported for SMS datasets, nor can they be catalogued, nor can 
>they be protected by RACF.
>https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter
>
Where I read such as:
- The system ignores blank characters at the end of a data set name.

Wouldn't it be better to say, "data set names shorter than 44 ccharacters
are padded with blanks to 44"?

- Double ampersands to identify a temporary data set name. Note that
  if you use apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer
  to the same data set.

That doesn't belong here.  It's described better in "Determining Equivalent
JCL".  It's incorrect here because it depends on the symbol AB being
undefined.

"Determining Equivalent JCL" states that double ampersands not enclsed
in apostrophes are reduced to single.  Does this suggest that within
apostrophes they are nor so reduced?

I once tried a DSN enclosed in apostrophes ("unqualified") beginning with
a period.  It failed with a syntax error.  I have never found this restriction
documented.

The data set name should not contain the 44 special characters (X'04')
created by hexadecimal editing or any operation that converts the
value of characters to X'04'.

The "created by ... converts" clause is improperly restrictive.  It doesn't
matter how they got there, "converted" or otherwise.

And no one has mentioned DISABLE(DSNCHECK)  before now.


-- 
gil

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

Re: How to configure using PDS members in JCL.

[Sri h Kolusu]

>> I have a PDS with configuration definitions in it and want to make it easy 
>> to configure.

Colin,

You could use DFSORT to do the substitution and generate the control cards 
which can be passed to the next steps that really execute the commands.
For example

// SET ID=COLIN
//*
//STEP0100 EXEC PGM=SORT,PARM='JP1"&ID"'
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=your.pds.with.racf.commands(member)
//SORTOUT  DD DSN=&&RCMD,DISP=(,PASS),SPACE=(TRK,(1,0),RLSE)
//SYSINDD *
  OPTION COPY
  INREC FINDREP=(INOUT=(C'&ID',JP1))
/*

This will create the new control cards with the ID substituted and write it to 
the temp file &&RCMD. Now you can use this file as input to the racf command 
processor.

//STEP0200 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*,DCB=BLKSIZE=121
//SYSPRINT DD SYSOUT=*
//SYSTSIN  DD DISP=(OLD,DELETE,DELETE),DSN=&&RCMD


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: allowed characters in member name

[Steve Thompson]

Why the use of data set names enclosed with apostrophes, that are 
not TSO oriented?


Back in the days when I was doing DOS to MVS migrations, to 
access certain DOS data sets, you needed this because they could 
contain names like this:


'PAYROLL STR 12MAY75' for either a Tape label or disk DSN. (where 
STR was the ID of the company you were doing payroll for -- In 
various service bureaus I've worked in).


DOS did not enforce the same restrictions as OS did (or MVS) for 
"File names" (DDNAME for OS) UNTIL VSAM (IIRC). VSAM in DOS, as I 
remember it, did enforce the same naming restrictions. BUT!!! 
SHARE options were different because VSAM was at the "domain" 
(O/S) level, for DOS where it is at the address space level for OS.


I mention this because there were migrations from DOS to 
OS{MVS|z/OS) for CICS that did not take this into account and so 
used multiple FILE names (DDN in MVS terms) and so cause 
performance issues under MVS-OS390-z/OS if that file is not 
accessed using a single DDNAME.   --- I was just dealing with 
such a situation with a client where the applications group 
managment did not want to hear it -- because they didn't want to 
make the changes that needed to be done. So IAM was brought in 
which addressed those problems!!


Long ugly story. But thought there might be a few that would need 
this deeper knowledge.


Also, back in the day (don't know if this is true to day with 
zVSE) there was a "dirty" bit set in the VTOC (DIRM if I remember 
correctly) that caused MVS to see that it may not have space 
extents correct (forgot the name of the DSCB) and so would re-org 
the VTOC and maybe the volume (holding a RESERVE) every time DOS 
would write to such a shared volume where it would set the VTOC 
dirty bit on.


Depending on what was on that volume, that RESERVE could and did 
affect the DOS and MVS sides.


Some of the things we run into today were caused by some 
decisions made years ago.


But as was noted, those names could be cataloged at one time in 
"MVS".


Steve Thompson



On 1/8/2024 10:10 AM, Paul Gilmartin wrote:

On Mon, 8 Jan 2024 11:00:38 -, Lennie Dymoke-Bradshaw wrote:


Using quotes around the DSNAME will allow any combination of Hex chars for a 
Dsname I think (possibly excluding 44X'04' which represents the VTOC). However 
these are not supported for SMS datasets, nor can they be catalogued, nor can 
they be protected by RACF.
https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter


Where I read such as:
- The system ignores blank characters at the end of a data set name.

Wouldn't it be better to say, "data set names shorter than 44 ccharacters
are padded with blanks to 44"?

- Double ampersands to identify a temporary data set name. Note that
   if you use apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer
   to the same data set.

That doesn't belong here.  It's described better in "Determining Equivalent
JCL".  It's incorrect here because it depends on the symbol AB being
undefined.

"Determining Equivalent JCL" states that double ampersands not enclsed
in apostrophes are reduced to single.  Does this suggest that within
apostrophes they are nor so reduced?

I once tried a DSN enclosed in apostrophes ("unqualified") beginning with
a period.  It failed with a syntax error.  I have never found this restriction
documented.

 The data set name should not contain the 44 special characters (X'04')
 created by hexadecimal editing or any operation that converts the
 value of characters to X'04'.

The "created by ... converts" clause is improperly restrictive.  It doesn't
matter how they got there, "converted" or otherwise.

And no one has mentioned DISABLE(DSNCHECK)  before now.




--
Regards, Steve Thompson

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

Re: allowed characters in member name

[Seymour J Metz]

DIRF.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Monday, January 8, 2024 11:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

Why the use of data set names enclosed with apostrophes, that are
not TSO oriented?

Back in the days when I was doing DOS to MVS migrations, to
access certain DOS data sets, you needed this because they could
contain names like this:

'PAYROLL STR 12MAY75' for either a Tape label or disk DSN. (where
STR was the ID of the company you were doing payroll for -- In
various service bureaus I've worked in).

DOS did not enforce the same restrictions as OS did (or MVS) for
"File names" (DDNAME for OS) UNTIL VSAM (IIRC). VSAM in DOS, as I
remember it, did enforce the same naming restrictions. BUT!!!
SHARE options were different because VSAM was at the "domain"
(O/S) level, for DOS where it is at the address space level for OS.

I mention this because there were migrations from DOS to
OS{MVS|z/OS) for CICS that did not take this into account and so
used multiple FILE names (DDN in MVS terms) and so cause
performance issues under MVS-OS390-z/OS if that file is not
accessed using a single DDNAME.   --- I was just dealing with
such a situation with a client where the applications group
managment did not want to hear it -- because they didn't want to
make the changes that needed to be done. So IAM was brought in
which addressed those problems!!

Long ugly story. But thought there might be a few that would need
this deeper knowledge.

Also, back in the day (don't know if this is true to day with
zVSE) there was a "dirty" bit set in the VTOC (DIRM if I remember
correctly) that caused MVS to see that it may not have space
extents correct (forgot the name of the DSCB) and so would re-org
the VTOC and maybe the volume (holding a RESERVE) every time DOS
would write to such a shared volume where it would set the VTOC
dirty bit on.

Depending on what was on that volume, that RESERVE could and did
affect the DOS and MVS sides.

Some of the things we run into today were caused by some
decisions made years ago.

But as was noted, those names could be cataloged at one time in
"MVS".

Steve Thompson



On 1/8/2024 10:10 AM, Paul Gilmartin wrote:
> On Mon, 8 Jan 2024 11:00:38 -, Lennie Dymoke-Bradshaw wrote:
>
>> Using quotes around the DSNAME will allow any combination of Hex chars for a 
>> Dsname I think (possibly excluding 44X'04' which represents the VTOC). 
>> However these are not supported for SMS datasets, nor can they be 
>> catalogued, nor can they be protected by RACF.
>> https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter
>>
> Where I read such as:
> - The system ignores blank characters at the end of a data set name.
>
> Wouldn't it be better to say, "data set names shorter than 44 ccharacters
> are padded with blanks to 44"?
>
> - Double ampersands to identify a temporary data set name. Note that
>if you use apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer
>to the same data set.
>
> That doesn't belong here.  It's described better in "Determining Equivalent
> JCL".  It's incorrect here because it depends on the symbol AB being
> undefined.
>
> "Determining Equivalent JCL" states that double ampersands not enclsed
> in apostrophes are reduced to single.  Does this suggest that within
> apostrophes they are nor so reduced?
>
> I once tried a DSN enclosed in apostrophes ("unqualified") beginning with
> a period.  It failed with a syntax error.  I have never found this restriction
> documented.
>
>  The data set name should not contain the 44 special characters (X'04')
>  created by hexadecimal editing or any operation that converts the
>  value of characters to X'04'.
>
> The "created by ... converts" clause is improperly restrictive.  It doesn't
> matter how they got there, "converted" or otherwise.
>
> And no one has mentioned DISABLE(DSNCHECK)  before now.
> 
>

--
Regards, Steve Thompson

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

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

Re: allowed characters in member name

[Seymour J Metz]

It is common for IBM manuals for one component to give incorrect rules for 
another component instead of referring the reader to the relevant 
documentation. This is especially common when describing REXX or JCL 
requirements for using that component.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, January 8, 2024 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: allowed characters in member name

On Mon, 8 Jan 2024 11:00:38 -, Lennie Dymoke-Bradshaw wrote:

>Using quotes around the DSNAME will allow any combination of Hex chars for a 
>Dsname I think (possibly excluding 44X'04' which represents the VTOC). However 
>these are not supported for SMS datasets, nor can they be catalogued, nor can 
>they be protected by RACF.
>https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-dsname-parameter
>
Where I read such as:
- The system ignores blank characters at the end of a data set name.

Wouldn't it be better to say, "data set names shorter than 44 ccharacters
are padded with blanks to 44"?

- Double ampersands to identify a temporary data set name. Note that
  if you use apostrophes, DSNAME='&&AB' and DSNAME='&AB' refer
  to the same data set.

That doesn't belong here.  It's described better in "Determining Equivalent
JCL".  It's incorrect here because it depends on the symbol AB being
undefined.

"Determining Equivalent JCL" states that double ampersands not enclsed
in apostrophes are reduced to single.  Does this suggest that within
apostrophes they are nor so reduced?

I once tried a DSN enclosed in apostrophes ("unqualified") beginning with
a period.  It failed with a syntax error.  I have never found this restriction
documented.

The data set name should not contain the 44 special characters (X'04')
created by hexadecimal editing or any operation that converts the
value of characters to X'04'.

The "created by ... converts" clause is improperly restrictive.  It doesn't
matter how they got there, "converted" or otherwise.

And no one has mentioned DISABLE(DSNCHECK)  before now.


--
gil

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

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

Re: How to configure using PDS members in JCL.

[Paul Gilmartin]

On Mon, 8 Jan 2024 14:22:42 +, Seymour J Metz wrote:

>CPPUPDTE (nee IPOUPDTE) only changes a  existing member; the easiest ways I 
>can think of to do what you want are ISPF file tailoring or JCL substitution 
>with a // INCLUDE. I would probably go with the former.
>
Oh my!  Can an INCLUDE statement be embedded in instream data, or is it a 
terminator
like other JCL statements?  I suppose concatenation is your friend.  Should 
such a
JCLLIB member begin with //  DD DATA,SYMBOLS=JCLONLY and end with /*?

Is there a necessary and valuable example in the Ref. or SAMPLIB?

-- 
gil

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

Re: OpenSSH CVE-2023-48795 vulnerability

[Rick Troth]

Thanks!

I don't see the artifacts for the 9.6p1 build. Do the project 
maintainers need to cut a release?


-- R; <><


On 1/5/24 20:04, kekronbekron wrote:

You could grab the latest (unsupported) release from this repo, once it's 
published.
Here's a link to the pull request, which introduces the latest version.
The build has succeeded.

https://github.com/ZOSOpenTools/opensshport/pull/6



On Saturday, January 6th, 2024 at 05:26, Filip Palian  
wrote:



For this type of verification SBOMs seems to be the way moving forward:
https://cyclonedx.org/use-cases/#known-vulnerabilities

Cheers,
FP

W dniu piątek, 5 stycznia 2024 rpinion865 <
042a019916dd-dmarc-requ...@listserv.ua.edu> napisał(a):


Does anyone know if the z/OS implementation of ssh is vulnerable to
CVE-2023048795? I tried searching
for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits
specific to z/OS. Thanks in advance.

Cross posting to IBMTCP-L and IBM Main

Sent with Proton Mail secure email.

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


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

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


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

Re: How to configure using PDS members in JCL.

[Seymour J Metz]

Sri h Kolusu suggest the INCLUDE; I assume that he tested it. IMHO file 
tailoring is a more versatile solution.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, January 8, 2024 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to configure using PDS members in JCL.

On Mon, 8 Jan 2024 14:22:42 +, Seymour J Metz wrote:

>CPPUPDTE (nee IPOUPDTE) only changes a  existing member; the easiest ways I 
>can think of to do what you want are ISPF file tailoring or JCL substitution 
>with a // INCLUDE. I would probably go with the former.
>
Oh my!  Can an INCLUDE statement be embedded in instream data, or is it a 
terminator
like other JCL statements?  I suppose concatenation is your friend.  Should 
such a
JCLLIB member begin with //  DD DATA,SYMBOLS=JCLONLY and end with /*?

Is there a necessary and valuable example in the Ref. or SAMPLIB?

--
gil

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


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

Re: How to configure using PDS members in JCL.

[Sri h Kolusu]

>> Sri h Kolusu suggest the INCLUDE; I assume that he tested it. IMHO file 
>> tailoring is a more versatile solution.

Shmuel,

Slight Correction.  It is NOT me who suggested the INCLUDE solution. It is by 
Charles hardee

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg135276.html

The solution I suggested was to use DFSORT which can pass parms to the input 
file using JPn construct which can be found here

https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg135283.html

Thanks,
Kolusu

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

Re: How to configure using PDS members in JCL.

[Charles Hardee]

Good catch Gil!

The one thing I forgot to say was that the member being included needs a
statement like this as the first entry:

// DD   *,SYMBOLS=JCLONLY

Sorry for the confusion.

C-


On Mon, Jan 8, 2024 at 10:47 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 8 Jan 2024 14:22:42 +, Seymour J Metz wrote:
>
> >CPPUPDTE (nee IPOUPDTE) only changes a  existing member; the easiest ways
> I can think of to do what you want are ISPF file tailoring or JCL
> substitution with a // INCLUDE. I would probably go with the former.
> >
> Oh my!  Can an INCLUDE statement be embedded in instream data, or is it a
> terminator
> like other JCL statements?  I suppose concatenation is your friend.
> Should such a
> JCLLIB member begin with //  DD DATA,SYMBOLS=JCLONLY and end with /*?
>
> Is there a necessary and valuable example in the Ref. or SAMPLIB?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: How to configure using PDS members in JCL.

[Steve Beaver]

CPPUPDTE (nee IPOUPDTE) cannot be used if your environment uses Endeavor.  It
Will break ever pds that has had used Endeavor



Steve 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Hardee
Sent: Monday, January 8, 2024 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to configure using PDS members in JCL.

Good catch Gil!

The one thing I forgot to say was that the member being included needs a
statement like this as the first entry:

// DD   *,SYMBOLS=JCLONLY

Sorry for the confusion.

C-


On Mon, Jan 8, 2024 at 10:47 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 8 Jan 2024 14:22:42 +, Seymour J Metz wrote:
>
> >CPPUPDTE (nee IPOUPDTE) only changes a  existing member; the easiest ways
> I can think of to do what you want are ISPF file tailoring or JCL
> substitution with a // INCLUDE. I would probably go with the former.
> >
> Oh my!  Can an INCLUDE statement be embedded in instream data, or is it a
> terminator
> like other JCL statements?  I suppose concatenation is your friend.
> Should such a
> JCLLIB member begin with //  DD DATA,SYMBOLS=JCLONLY and end with /*?
>
> Is there a necessary and valuable example in the Ref. or SAMPLIB?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: SSH tunneling for unattended process.

[Rick Troth]

Sorry for the delay. Holidays and family and friends and such. Ahhh...

It's been a minute, but I used SSH to carry PPP traffic back in the day.
The client side PPPD ran 'ssh' as a child process, arranging stdin and 
stdout, as if it was a dial-up modem.
The server side ran the counterpart 'pppd' as its command. (People don't 
always think about this, but you can run specific commands via SSH 
rather than always getting a shell prompt.)
Once upon a time, I was told "it'll never work", but I used it regularly 
before I learnt OpenVPN and never had problems.


So you wound up with two PPP processes talking to each other over SSH. 
This is what I meant by "directly". It did not use-L or-R options for 
TCP via the SSH tunnel. This is how RSYNC uses SSH even now.


Regarding your "ssh -L ...", non-standard ports are easier. (And -L 
means something else. See below.)


   ssh user@host:/port /


And-L means "local TCP listener" (traffic to be forwarded to the other 
end), while-R means "remote TCP listener" (remote connections conveyed 
back to the client end).


Clarification on -L and -R ...

   -L 1234:192.168.1.1:4321


in English means "listen locally on TCP port 1234 and send that traffic 
to 192.168.1.1 on the remote end at port 4321.


   -R 2345:192.168.3.3:5432


in English means "listen on the remote end at TCP port 2345 and send 
that traffic to 192.168.3.3 on this end at port 5432.


-- R; <><


On 12/29/23 21:47, kekronbekron wrote:

Thanks Rick.
This is the part I don't follow... "You can use SSH directly (with client invoking 
SSH to launch a service program on the target)".

Is it possible to make a simple example?
User A at Machine A wants to connect via port 4321 to machine B port 22, and 
it's just good old SSH connectivity.

I don't understand the "encrypt a connection" part.
Meaning, SSH-ing into machines is well known and there's encryption etc.

Correct me if I'm wrong but I think "ssh -L ..." is just to get to SSH on a 
target machine via a non-standard port?



On Friday, December 29th, 2023 at 20:35, Rick Troth  wrote:



I can't speak for Frank, but he started his inquiry with this:


We're looking at using an SSH tunnel (or reverse tunnel)to encrypt a

connection


where the application on the other end does not support TLS.


SSH is an excellent choice for this kind of job.
You can use SSH directly (with client invoking SSH to launch a service
program on the target)
or you can establish one or more TCP listeners (either direction) over
an SSH session, or any combination.
ALL of the traffic handled by way of the SSH session would be encrypted.

So I might not have understood exactly what Frank needs, but I'm a firm
believer in SSH.

Authentication of the remote SSH host is done using the SSH host key(s)
on the target system. That's standard.

Authentication of the client can be done using an SSH client key (as is
my practice) or using PKI certificates (as Colin describes in his blog).
Frank indicated that what he needs is unattended/automatic, easily
supported using either method.

Does that help?

-- R; <><



On 12/29/23 09:20, kekronbekron wrote:


Hi Rick/Frank,

If you have time, could you explain more about this setup.
I don't get what's desired..

On Friday, December 29th, 2023 at 19:04, Rick trothtro...@gmail.com  wrote:


Hi Frank --

BT/DT and it works great.

I took the usual means of capturing the host key of the target: signed
on as the service account and ran 'ssh' interactively. Ever after, the
client would not be prompted, but it would fail if the key changed. (And
that's the point.)

The client signed on using an SSH client key. Of course, I had to break
a rule here and magically obviate the need for a pass phrase. (Dark
magic. Not something we speak about in public.)

In this particular case, I ran it from/etc/inittab on a traditional Unix
(Linux) system. That way when the session would die it would be restarted.

This hack used either -L or -R, I forget which, but established a TCP
listener. All traffic was limited to local (which is the default), so no
risk of someone off-box sending or seeing cleartext.

-- R; <><

On 12/29/23 04:53, Colin Paice wrote:


Frank,
What do you have on the z/OS end? If the back end supports it, it can map
from a certificate to a userid.
See Using certificates to logon to z/OS
https://colinpaice.blog/2023/03/28/using-certificates-to-logon-to-z-os/
andWhat’s the difference between RACDCERT MAP and RACMAP?
https://colinpaice.blog/2020/07/28/whats-the-difference-between-racdcert-map-and-racmap/
Colin

On Fri, 29 Dec 2023 at 06:27, frankswarbrickfrank.swarbr...@outlook.com
wrote:


We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a
connection where the application on the other end does not support TLS.
The POC looks to be working. I am now pondering on the steps required to
make setting up the tunnel an automated process. It seems to me that we'd
want the z/OS user to be a "protected" user
(NOPASSWORD/NOPHRASE/NOOIDCARD

Re: How to configure using PDS members in JCL.

[Paul Gilmartin]

On Mon, 8 Jan 2024 12:39:17 -0600, Charles Hardee wrote:
>
>The one thing I forgot to say was that the member being included needs a
>statement like this as the first entry:
>
>// DD   *,SYMBOLS=JCLONLY
> 
An alternative might be to concatenate JCL and the subject member into INTRDR.
In either case, the subject member must have been coded with &SYMBOL references.
It's regrettable that there's no simple way to provide defaults for such 
symbols.

Ah!  code the member as a PROC.

-- 
gil

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

Re: OpenSSH CVE-2023-48795 vulnerability

[Rick Troth]

Thanks for the heads-up.
I have added OpenSSH 9.6p1 to the Chicory collection.
Sadly, I don't have a z/OS build system for that collection. (And if 
anyone can offer such, please pardon my sound-byte responses up to now.)


Had to bump-up the minimum level of OpenSSL from 1.0.2 to 1.1.1.
It builds and links against OpenSSL 1.1.1t and LibreSSL 3.8.1. Not sure 
their rejection of 1.0.2 is justified, but it's the current religion.


-- R; <><


On 1/5/24 07:50, rpinion865 wrote:

Does anyone know if the z/OS implementation of ssh is vulnerable to 
CVE-2023048795? I tried searching
for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits specific to 
z/OS. Thanks in advance.

Cross posting to IBMTCP-L and IBM Main

Sent with [Proton Mail](https://proton.me/) secure email.

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


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

Re: Help Trying to determine where abend occurred / unable to find linkage stack entry

[Joseph Reichman]

After getting an abend with SDWAEC2 (different from SDWAEC1) I observed 
SDWAXFLG to be X'92' that means SDWAEC2 psw came from the linkage stack 

Looking at the STCB field STCBLSDP I started going back ward by X'128' a 
linkage stack entry and was unable to find a marching PSW

THANKS   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Walt Farrell
Sent: Sunday, December 31, 2023 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help Trying to determine where abend occurred

Have you looked at the descriptions of the two fields?

>From https://www.ibm.com/docs/en/zos/2.1.0?topic=us-important-fields-in-sdwa I 
>see:


SDWAEC1
This field contains the PSW that existed at the time of the error.
SDWAEC2
The contents of this field vary according to the type of recovery routine:

For ESTAE-type recovery routines (except for ESTAI routines): If a 
program establishes an ESTAE routine, and subsequently performs a stacking 
operation while running under the same RB as when it established the ESTAE 
routine, SDWAEC2 contains the PSW from the linkage stack entry immediately 
following the entry that was current when the ESTAE routine was established. 
Otherwise, SDWAEC2 contains the current RBOPSW from the RB that activated the 
recovery routine, and the PSW is the one from the time of the last interruption 
of that RB that occurred while the RB was unlocked and enabled. Bit SDWAINTF in 
SDWAXFLG indicates whether the contents of SDWAEC2 are from the linkage stack 
(SDWAINTF is 1) or from an RB (SDWAINTF is 0).
For an ESTAI routine, this field contains zero.
For an FRR, the field contains the PSW used to give control to the FRR.


--
Walt

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

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

Re: OpenSSH CVE-2023-48795 vulnerability

[kekronbekron]

Yup, just post a comment on the PR, requesting a release.


On Monday, January 8th, 2024 at 22:36, Rick Troth  wrote:


> Thanks!
> 
> I don't see the artifacts for the 9.6p1 build. Do the project
> maintainers need to cut a release?
> 
> -- R; <><
> 
> 
> 
> On 1/5/24 20:04, kekronbekron wrote:
> 
> > You could grab the latest (unsupported) release from this repo, once it's 
> > published.
> > Here's a link to the pull request, which introduces the latest version.
> > The build has succeeded.
> > 
> > https://github.com/ZOSOpenTools/opensshport/pull/6
> > 
> > On Saturday, January 6th, 2024 at 05:26, Filip Palian s3...@pjwstk.edu.pl 
> > wrote:
> > 
> > > For this type of verification SBOMs seems to be the way moving forward:
> > > https://cyclonedx.org/use-cases/#known-vulnerabilities
> > > 
> > > Cheers,
> > > FP
> > > 
> > > W dniu piątek, 5 stycznia 2024 rpinion865 <
> > > 042a019916dd-dmarc-requ...@listserv.ua.edu> napisał(a):
> > > 
> > > > Does anyone know if the z/OS implementation of ssh is vulnerable to
> > > > CVE-2023048795? I tried searching
> > > > for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits
> > > > specific to z/OS. Thanks in advance.
> > > > 
> > > > Cross posting to IBMTCP-L and IBM Main
> > > > 
> > > > Sent with Proton Mail secure email.
> > > > 
> > > > --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > 
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SSH tunneling for unattended process.

[Andrew Rowley]

On 9/01/2024 6:26 am, Rick Troth wrote:


It's been a minute, but I used SSH to carry PPP traffic back in the day.
The client side PPPD ran 'ssh' as a child process, arranging stdin and 
stdout, as if it was a dial-up modem.


I think this is difficult on z/OS because by default stdin and stdout 
use ASCII<->EBCDIC translation, so anything sending binary data is broken.


I think you can override that, but not conveniently.

--
Andrew Rowley
Black Hill Software

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

Re: Help Trying to determine where abend occurred / unable to find linkage stack entry

[Tony Harminc]

On Mon, 8 Jan 2024 at 19:20, Joseph Reichman  wrote:

> After getting an abend with SDWAEC2 (different from SDWAEC1) I observed
> SDWAXFLG to be X'92' that means SDWAEC2 psw came from the linkage stack
>
> Looking at the STCB field STCBLSDP I started going back ward by X'128' a
> linkage stack entry and was unable to find a marching PSW
>
> THANKS
>

As you were marching backwards through the state entries looking for PSWs,
are you sure you didn't pass a header entry, which is much shorter, and
could point to a state entry in a previous stack section?

Tony H.

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

Re: SSH tunneling for unattended process.

[Filip Palian]

Depending on the use case https://www.stunnel.org can also be used exactly
for this purpose.

Cheers,
FP

wt., 9 sty 2024 o 12:01 Andrew Rowley 
napisał(a):

> On 9/01/2024 6:26 am, Rick Troth wrote:
> >
> > It's been a minute, but I used SSH to carry PPP traffic back in the day.
> > The client side PPPD ran 'ssh' as a child process, arranging stdin and
> > stdout, as if it was a dial-up modem.
> >
> I think this is difficult on z/OS because by default stdin and stdout
> use ASCII<->EBCDIC translation, so anything sending binary data is broken.
>
> I think you can override that, but not conveniently.
>
> --
> Andrew Rowley
> Black Hill Software
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Help Trying to determine where abend occurred / unable to find linkage stack entry

[Joseph Reichman]

Thanks all I did was decrement X’128’

> On Jan 8, 2024, at 10:08 PM, Tony Harminc  wrote:
> 
> On Mon, 8 Jan 2024 at 19:20, Joseph Reichman  wrote:
> 
>> After getting an abend with SDWAEC2 (different from SDWAEC1) I observed
>> SDWAXFLG to be X'92' that means SDWAEC2 psw came from the linkage stack
>> 
>> Looking at the STCB field STCBLSDP I started going back ward by X'128' a
>> linkage stack entry and was unable to find a marching PSW
>> 
>> THANKS
>> 
> 
> As you were marching backwards through the state entries looking for PSWs,
> are you sure you didn't pass a header entry, which is much shorter, and
> could point to a state entry in a previous stack section?
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Help Trying to determine where abend occurred / unable to find linkage stack entry

[Binyamin Dissen]

Which level recovery routine?

On Mon, 8 Jan 2024 19:19:59 -0500 Joseph Reichman 
wrote:

:>After getting an abend with SDWAEC2 (different from SDWAEC1) I observed 
SDWAXFLG to be X'92' that means SDWAEC2 psw came from the linkage stack 
:>
:>Looking at the STCB field STCBLSDP I started going back ward by X'128' a 
linkage stack entry and was unable to find a marching PSW
:>
:>THANKS   
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List  On Behalf Of 
Walt Farrell
:>Sent: Sunday, December 31, 2023 1:36 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Help Trying to determine where abend occurred
:>
:>Have you looked at the descriptions of the two fields?
:>
:>From https://www.ibm.com/docs/en/zos/2.1.0?topic=us-important-fields-in-sdwa 
I see:
:>
:>
:>SDWAEC1
:>This field contains the PSW that existed at the time of the error.
:>SDWAEC2
:>The contents of this field vary according to the type of recovery routine:
:>
:>For ESTAE-type recovery routines (except for ESTAI routines): If a 
program establishes an ESTAE routine, and subsequently performs a stacking 
operation while running under the same RB as when it established the ESTAE 
routine, SDWAEC2 contains the PSW from the linkage stack entry immediately 
following the entry that was current when the ESTAE routine was established. 
Otherwise, SDWAEC2 contains the current RBOPSW from the RB that activated the 
recovery routine, and the PSW is the one from the time of the last interruption 
of that RB that occurred while the RB was unlocked and enabled. Bit SDWAINTF in 
SDWAXFLG indicates whether the contents of SDWAEC2 are from the linkage stack 
(SDWAINTF is 1) or from an RB (SDWAINTF is 0).
:>For an ESTAI routine, this field contains zero.
:>For an FRR, the field contains the PSW used to give control to the 
FRR.
:>

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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