Re: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4

[Gord Tomlin]

Some snippage and interspersed comments...

On 2019-09-20 17:11, Jon Perryman wrote:

For instance, mapping to C does not support remapping, redefinition or re-declaring 
variables such as "org" in assembler.


Actually, it does, using unions, but the results are not very pretty. 
Here's an example from IHAIPA.


Assembler macro snippet:

IPAHEAD  DSCL96  Header section
 ORG   IPAHEAD
IPAIDDSCL4   Eye-catcher
IPALEN   DSH Length
IPASPDSX Subpool
IPAVER   DSX Version number
IPAICTOD DSCL8   TOD at completion of system initialization
IPALPARM DSCL8   IPL load parameter
 ORG   IPALPARM
IPAIODFU DSCL4   IODF unit address
IPALOADS DSCL2   LOADxx suffix
IPAPROMT DSCL1   Operator prompt flag
IPANUCID DSCL1   Nucleus ID
IPANAMES DSCL24  System name values
 ORG   IPANAMES
IPAHWNAM DSCL8   HWNAME value
IPALPNAM DSCL8   LPARNAME value
IPAVMNAM DSCL8   VMUSERID value
IPALPDSN DSCL44  IPL load parameter dataset name
IPALPDDV DSCL4   IPL load parameter dataset device number

C header snippet, generated by EDCDSECT:

union {
unsigned char  _ipahead[96];
struct {
unsigned char  _ipaid[4];
short int  _ipalen;
unsigned char  _ipasp;
unsigned char  _ipaver;
unsigned char  _ipaictod[8];
unsigned char  _ipalparm[8];
unsigned char  _filler1[72];
} _ipa_struct1;
struct {
unsigned char  _filler2[16];
unsigned char  _ipaiodfu[4];
unsigned char  _ipaloads[2];
unsigned char  _ipapromt;
unsigned char  _ipanucid;
unsigned char  _ipanames[24];
unsigned char  _filler3[48];
} _ipa_struct2;
struct {
unsigned char  _filler4[24];
unsigned char  _ipahwnam[8];
unsigned char  _ipalpnam[8];
unsigned char  _ipavmnam[8];
unsigned char  _ipalpdsn[44];
unsigned char  _ipalpddv[4];
} _ipa_struct3;
} _ipa_union1;



6. C does not support unaligned fields (e.g. AL2, AL3 or AL4). If variable - 
dsect is not aligned properly, then you will need special handling to support 
these properly in C. Maybe an inline function to deal with this.


It does.

Snippet from CVT:

CVTAQAVT DS0A -  ADDRESS OF THE FIRST WORD OF THE TCAM
*DISPATCHER WHICH CONTAINS THE ADDRESS OF
*THE ADDRESS VECTOR TABLE (AVT).  IF ZERO,
*TCAM IS NOT STARTED.
CVTTCMFG DCX'00' -   TCAM FLAGS
CVTTCRDY EQU   X'80' -   TCAM IS READY TO ACCEPT USERS
CVTLDEV  EQU   X'40' -   LOCAL DEVICE ATTACHED TO TCAM
*(MDC357)  @Z40XA9A
CVTNWTCM EQU   X'20' -   MULTIPLE TCAM FEATURE ACTIVE. @D1A
CVTAQAVB DCAL3(0) -  SAME AS CVTAQAVT ABOVE

Snipped from C struct generated using EDCDSECT:

struct {
int_cvttcrdy  : 1,
   _cvtldev   : 1,
   _cvtnwtcm  : 1,
  : 5;
int_cvtaqavb : 24;
} cvtaqavt;

Also see the following for a description of the use of #pragma packed by 
EDCDSECT:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcux01/genstruct.htm

The same page documents how various Assembler definitions, including 
fields that are unaligned due to specification of a length value.


Compile a C program that displays the SIZEOF(struct_name) and verify it matches 
the assembler calculated size of the dsect.


Very good advice. Everyone should do that.

Having said all that, I can guarantee that you will like the macros 
Peter has generated better than those generated by EDCDSECT.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: SFTP Special Charcters

[Frank Swarbrick]

File systems and file transport protocols should all support metadata such as 
file encoding, etc.

Get on it.




From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, September 20, 2019 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SFTP Special Charcters

On Fri, 20 Sep 2019 17:51:31 +, Seymour J Metz wrote:

>FSVO "autodetect". Windoze expects to see an extraneous zero-width 
>non-breaking space as the first character of a file using UTF-8; that of 
>course, will break any software that is not expecting it. The ida of jamming 
>in an extraneous character as a byte-order mark when the issue of byte order 
>has no relevance is something that only the developers of edge (ptui!) could 
>love. If you have a valid source file for a language whose compiler does not 
>allow an extraneous initial character, than windoze will not autodetect it as 
>UTF-8.
>
It's ironic.  In other contexts I've known Windows partisans to sneer at
the UNIX tradition of "magic numbers" which the BOM represents.

And it's not probative.  A file starting with the BOM octets could as well
be ISO8859-x.

The detection must be Bayesian/heuristic.  A file of significant size containing
numerous non-ASCII characters, but only in valid UTF-8 sequences is
highly likely to be UTF-8.  A file containing only ASCII characters is
ambiguous: it doesn't matter whether it's considered ASCII or UTF-8.

Hungarian notation is unlikely to be a solution -- programmers will
not embrace a filename extension such as ".U8TXT".  And MIME
metadata is not usually available.

>>Does your Windows system support UTF-8?  It's prevalent and I've
>>known Windows programs to auto-detect 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: I see a need for general conversion of mappings was Re: C headers in z/OS 2.4

[Jon Perryman]

 > XLC has a DSECT conversion utility. 


Surprisingly, I think I must have been the only one to generate IPCS mapping 
automatically using assembler macro's. Less than 100 lines of simple code 
greatly improved dump reading. As a product developer, I had to read a lot of 
dumps and this saved a lot of time.

This  same implementation would work for conversion to any language. The 
problem is actually with the mapping to the destination language. For instance, 
mapping to C does not support remapping, redefinition or re-declaring variables 
such as "org" in assembler.

Here is the logic I would use for mapping to C. Sorry if I don't get something 
quite right. It's been a very long time since I wrote these macro's and the 
source is backed up somewhere. Output would be to syspunch.

Sadly, this would be a lot easier if C had a true macro language instead of 
it's limited pre-processing language. 

Macro called from assembler source file has a parm with the DSECT mapping macro 
name:

1. Call dsect mapping macro.

2. OPSYN DSECT and CSECT to macro #DSECT. OPSYN DC and DS to macro #DS. OPSYN 
ORG to macro #ORG. OPSYN EQU to macro #EQU.

3. Call dsect mapping macro. 

4. call macro #END 

Macro #DSECT simply closes the previous structure with a comment about struct 
size and generate a new struct using the label.   
Macro #END simply closes the previous structure with a comment about struct 
size. 

Macro #ORG simply exits. Remapping logic is in macro #DS.

Macro #EQU if n'syslist > 1 then call #DS macro passing  otherwise this 
is a flag. Maybe a C macro that matches the variable name that calls a specific 
inline C function for this flag. Another possibility is test creating a C 
struct with 8 bool variables to see if it is 1 byte long. If so, then you may 
be able to use a C struct with bool variables. If there are multi bit flags, 
then you may need to add C macro's to support the combination.
Macro #DS is the meat of the process. 

1. T ' gives you the data type, L ' gives you the length of the data and 
label-label gives you the offset. 

2. Comments were not needed for IPCS, If they are needed, you will need to find 
a solution.

3. Signed / unsigned is not defined in the dsect (instructions determine). You 
might need macro options allowing you to specify unsigned fields.

4. For me, duplication factor or stacking was not used in any macro's I needed. 
Duplication factor (e.g. DS 4A), can be calculated by using the next variable 
minus this variable divided by variable length. For stacked data (e.g. DS 
A(0,0,0),CL30), you can calculate overall length by using the next variable 
minus this variable.

5. For assembler data types that have direct C equivalents (e.g. A, H, F, D), 
you would create matching variables with the C equivalent.

6. C does not support unaligned fields (e.g. AL2, AL3 or AL4). If variable - 
dsect is not aligned properly, then you will need special handling to support 
these properly in C. Maybe an inline function to deal with this.

7. Probably everything else would be a byte array with the specified length.

Compile a C program that displays the SIZEOF(struct_name) and verify it matches 
the assembler calculated size of the dsect.

Jon.
On Wednesday, September 18, 2019, 11:31:42 AM PDT, Steve Smith 
 wrote:  
 
 XLC has a DSECT conversion utility.  Check the User's Guide.  Many don't
like its output (probably including Peter Relson), but it can be useful,
maybe as a starting point.

sas

On Wed, Sep 18, 2019 at 1:26 PM Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> Hmm-m-m.  Interesting idea, but I can see complex language-dependent
> variable definition issues.  Might be a real bear to implement in the
> compilers in any shared-code-among-languages way.  

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

Re: z/OS 2.4 September update collection

[Susan Shumway]

Hi Lionel,

Seeing this now, after your more recent post on the same subject in the 
other thread. Thanks, again, for the notice! We're on it...


-Sue Shumway

On 9/19/2019 8:51 AM, Lionel B Dyck wrote:

Downloaded the Sept indexed collection and found a BUG in the 
1._Open_Me_First_zOS_V2R4_Adobe_Indexed_Collection.html file.

  


Here is an example:   < a href="../zosv2r4pdfkit-Jul-19/izsc200_v2r4.pdf" >

  


Notice the directory listed still shows Jul-19 while the package unzips by 
default to /. . /zosv2r4pdfkit-Sep-12-2019/

  


Just a small issue but it prevents easy access to the contents.

  


Btw. It would be nice if this file were named index.html 

  


Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you are, 
reputation merely what others think you are." - John Wooden

  



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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: z/OS V2R4 library updated for z15!

[Susan Shumway]

Hi Lionel,

Thanks for bringing that to our attention! What you're referencing is 
actually for the "table of contents" that is included in the Adobe 
Indexed PDF Collection, not the index.html file that you can obtain 
individually or as part of the bulk PDF download on the z/OS V2R4 
Library. Regardless, the links should work. I'll pass your findings 
along to the collection builder so that he can make the necessary 
improvements and repost the V2R4 collection as soon as possible.


-Sue Shumway



On 9/20/2019 12:33 PM, Lionel B Dyck wrote:

The issue isn't the dates in the manuals or elsewhere - the issue is the path 
to the pdf includes the 'Jul 19' as part of the path/directory name which was 
fine for July but the Sept update changed the directory name to 
zosv2r4pdfkit-Sep-12-2019 and yet the href tags still have zosv2r4pdfkit-Jul-19 
making the reference invalid and preventing opening the pdf as it can't be 
found (unless you didn't delete the July directory).


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you are, 
reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Tomlin
Sent: Friday, September 20, 2019 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS V2R4 library updated for z15!

On 2019-09-20 10:23, Susan Shumway wrote:

Hi Gord,

I did some poking around and finally realized that you're probably
referring to the dates listed in the index.html file, correct? Those
are static and don't reflect the true build dates of the PDF files - I
have a request in to have that column (and some other static data)
removed from the index.html file.

In the meantime, the PDFs that you download, either individually or
with that bulk download option, should always represent the latest content.
Please let me know if you don't see the latest dates (July, September,
etc.) on the PDFs themselves and I'll work to figure it out.

-Sue Shumway
Hi Sue,


You're right, I was looking at the dates in index.html, and "ASSumed"
that they were accurate. I checked the dates in some individual PDFs, and the 
manuals are more recent.

Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: z/OS V2R4 library updated for z15!

[Susan Shumway]

Hi Gord,

Great, I'm glad that that was the problem and the PDFs themselves are 
up-to-date for you. And it was an easy mistake to make! We'll have the 
index.html file corrected right away.


-Sue Shumway

On 9/20/2019 10:52 AM, Gord Tomlin wrote:

On 2019-09-20 10:23, Susan Shumway wrote:

Hi Gord,

I did some poking around and finally realized that you're probably 
referring to the dates listed in the index.html file, correct? Those 
are static and don't reflect the true build dates of the PDF files - I 
have a request in to have that column (and some other static data) 
removed from the index.html file.


In the meantime, the PDFs that you download, either individually or 
with that bulk download option, should always represent the latest 
content. Please let me know if you don't see the latest dates (July, 
September, etc.) on the PDFs themselves and I'll work to figure it out.


-Sue Shumway
Hi Sue,


You're right, I was looking at the dates in index.html, and "ASSumed" 
that they were accurate. I checked the dates in some individual PDFs, 
and the manuals are more recent.


Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

OT ARPANET Tshirt

[Mike Schwab]

I've bought T-shirts from here.  Printed in US, sizes correct.  Lasts
dozens of washes.

https://shirt.woot.com/offers/welcome-to-the-arpanet?ref=w_cnt_top20_12_tl


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

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

IND$FILE (was: SFTP Special Charcters)

[Paul Gilmartin]

On Thu, 19 Sep 2019 19:45:08 +, Statler, David  wrote:

>My terminal emulator was using a setting called "Default Code Page".  I went 
>and changed it to "1047 USA, Canada" and now the character is displaying 
>correctly!
>
>Thank you very much!!
>
You're welcome.

But I'm curious.  Does IND$FILE for ASCII transfers automatically
convert according to those terminal emulator settings?  I assume
the translation would  be performed by the emulator if at all.

If the target is a new z/OS UNIX file, does IND$FILE set the CCSID
in the metadata tags correctly?

If the host file is an existing tagged UNIX file, does IND$FILE verify
that the CCSID agrees?  How does it report disagreement?

Likewise, does FTP set or verify the CCSID of UNIX files according to
the SBDATACONN value/

Lately, the FTP client accepts an allocated DDNAME as the local file.
Does it set or verify FILEDATA according to the allocation?  The
FILEDATA, RECFM, and LRECL have many possibilities of conflict
with the TYPE, MODE, and STRU in FTP commands.  Are these
detected and reported?

I have used "pax" options to convert EBCDIC to ASCII.  But if I
have an EBCDIC file tagged with conventional linebreak=NL and
convert it with "pax" to ASCII (I presume it uses UNICODE services)
the NLs are converted to LFs,  but the target file is still tagged
NL.  I took that to SR.  WAD.

I understand that if "pax" converts CCSID of a file tagged as
FILEDATA=RECORD it mindlesslhy translates octets in the RDWs.
I haven't tried SR for that.  I'd expect WAD.

I hate EBCDIC!

-- gil

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

Re: SFTP Special Charcters

[Paul Gilmartin]

On Fri, 20 Sep 2019 17:51:31 +, Seymour J Metz wrote:

>FSVO "autodetect". Windoze expects to see an extraneous zero-width 
>non-breaking space as the first character of a file using UTF-8; that of 
>course, will break any software that is not expecting it. The ida of jamming 
>in an extraneous character as a byte-order mark when the issue of byte order 
>has no relevance is something that only the developers of edge (ptui!) could 
>love. If you have a valid source file for a language whose compiler does not 
>allow an extraneous initial character, than windoze will not autodetect it as 
>UTF-8.
>
It's ironic.  In other contexts I've known Windows partisans to sneer at
the UNIX tradition of "magic numbers" which the BOM represents.

And it's not probative.  A file starting with the BOM octets could as well
be ISO8859-x.

The detection must be Bayesian/heuristic.  A file of significant size containing
numerous non-ASCII characters, but only in valid UTF-8 sequences is
highly likely to be UTF-8.  A file containing only ASCII characters is
ambiguous: it doesn't matter whether it's considered ASCII or UTF-8.

Hungarian notation is unlikely to be a solution -- programmers will
not embrace a filename extension such as ".U8TXT".  And MIME
metadata is not usually available.

>>Does your Windows system support UTF-8?  It's prevalent and I've
>>known Windows programs to auto-detect it.

-- gil

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

Re: SFTP Special Charcters

[Seymour J Metz]

FSVO "autodetect". Windoze expects to see an extraneous zero-width non-breaking 
space as the first character of a file using UTF-8; that of course, will break 
any software that is not expecting it. The ida of jamming in an extraneous 
character as a byte-order mark when the issue of byte order has no relevance is 
something that only the developers of edge (ptui!) could love. If you have a 
valid source file for a language whose compiler does not allow an extraneous 
initial character, than windoze will not autodetect it as UTF-8.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 19, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP Special Charcters

On Thu, 19 Sep 2019 16:16:39 +, Statler, David wrote:

>I'm dealing with the exact same thing (except going from Windows to Mainframe).
>
>In your FTP client, you should be able to have it issue the following command:
>
>quote site sbdataconn=(IBM-1047,ISO8859-1)
>
Does SFTP suipport that command nowadays?  It strikes me as more
characteristic of FTPS.

>Which should help in the translation, but it's not working for me.  I've got 
>an open case with IBM right now in trying to get it figured out.
>
Does your Windows system support UTF-8?  It's prevalent and I've
known Windows programs to auto-detect 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: Throwback Thursday: Ultimatum | Shark Tank

[Seymour J Metz]

> Beyond cursing the darkness did you consider lighting one candle
> by repairing the URL to:
 >  
 > https://www.computerworld.com/article/3432781/throwback-thursday-ultimatum.html

Il va sans dire. But I shouldn't have to.
> The headers supplied by your "broken e-mail client"

I didn't say that it was *my* client that was broken in this instance. 

> Q-P is quite capable of dealing with long text strings such as the
> one appearing in your original text which I quoted.

Which has nothing to do with whether the senders client is capable of dealing 
with it, nor are the headers from my client relevant to determining the 
encoding used by the OP.

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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, September 19, 2019 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Throwback Thursday: Ultimatum | Shark Tank

On 2019-09-19, at 09:17:44, Seymour J Metz wrote:
>
>> The pilot fish is a mainframer.
>
> I've caught too many gross errors oer the years to believe that, although 
> this particular article sounds plausible, perhaps even certain.
>
>>
> https://www.computerworld.com/article/3432781/throwback-thursday-ultimatum.h
>> tml
>
> Another broken e-mail client, as bad as the one I'm forced to use.
>
Beyond cursing the darkness did you consider lighting one candle
by repairing the URL to:

https://www.computerworld.com/article/3432781/throwback-thursday-ultimatum.html

The headers supplied by your "broken e-mail client" show:
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Q-P is quite capable of dealing with long text strings such as the
one appearing in your original text which I quoted.

-- 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: z/OS V2R4 library updated for z15!

[Lionel B Dyck]

The issue isn't the dates in the manuals or elsewhere - the issue is the path 
to the pdf includes the 'Jul 19' as part of the path/directory name which was 
fine for July but the Sept update changed the directory name to 
zosv2r4pdfkit-Sep-12-2019 and yet the href tags still have zosv2r4pdfkit-Jul-19 
making the reference invalid and preventing opening the pdf as it can't be 
found (unless you didn't delete the July directory).


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Tomlin
Sent: Friday, September 20, 2019 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS V2R4 library updated for z15!

On 2019-09-20 10:23, Susan Shumway wrote:
> Hi Gord,
> 
> I did some poking around and finally realized that you're probably 
> referring to the dates listed in the index.html file, correct? Those 
> are static and don't reflect the true build dates of the PDF files - I 
> have a request in to have that column (and some other static data) 
> removed from the index.html file.
> 
> In the meantime, the PDFs that you download, either individually or 
> with that bulk download option, should always represent the latest content.
> Please let me know if you don't see the latest dates (July, September,
> etc.) on the PDFs themselves and I'll work to figure it out.
> 
> -Sue Shumway
> Hi Sue,

You're right, I was looking at the dates in index.html, and "ASSumed" 
that they were accurate. I checked the dates in some individual PDFs, and the 
manuals are more recent.

Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
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: *MASTER* enqueue on SYS1.LOGREC - user error -

[Carmen Vitullo]

ah ! that'll do it :) 



Carmen Vitullo 

- Original Message -

From: "J Ellis" <020d5fbe36e0-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, September 20, 2019 10:35:38 AM 
Subject: Re: *MASTER* enqueue on SYS1.LOGREC - user error - 

We have met the enemy ... 

the job that runs on this LPAR had DISP=OLD in the serlog DD 

thanks to all ... 

-- 
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: *MASTER* enqueue on SYS1.LOGREC - user error -

[J Ellis]

We have met the enemy ...

the job that runs on this LPAR had DISP=OLD in the serlog DD

thanks to all ...

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

Re: z/OS V2R4 library updated for z15!

[Gord Tomlin]

On 2019-09-20 10:23, Susan Shumway wrote:

Hi Gord,

I did some poking around and finally realized that you're probably 
referring to the dates listed in the index.html file, correct? Those are 
static and don't reflect the true build dates of the PDF files - I have 
a request in to have that column (and some other static data) removed 
from the index.html file.


In the meantime, the PDFs that you download, either individually or with 
that bulk download option, should always represent the latest content. 
Please let me know if you don't see the latest dates (July, September, 
etc.) on the PDFs themselves and I'll work to figure it out.


-Sue Shumway
Hi Sue,


You're right, I was looking at the dates in index.html, and "ASSumed" 
that they were accurate. I checked the dates in some individual PDFs, 
and the manuals are more recent.


Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: *MASTER* enqueue on SYS1.LOGREC

[Carmen Vitullo]

I've done this on my 2.3 test lpar 

setlogrc ignore 
IFB097I LOGREC RECORDING MEDIUM CHANGED FROM LOGSTREAM TO IGNORE 
SETLOGRC DATASET 
IFB097I LOGREC RECORDING MEDIUM CHANGED FROM IGNORE TO DATASET 






D GRS,RES=(*,SYS1.LOGREC) 
ISG343I 09.36.48 GRS STATUS 285 
S=SYSTEM SYSDSN SYS1.LOGREC 
SYSNAME JOBNAME ASID TCBADDR EXC/SHR STATUS 
SYST *MASTER* 0001 007C0E88 SHARE OWN 





Carmen Vitullo 

- Original Message -

From: "J Ellis" <020d5fbe36e0-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, September 20, 2019 9:33:21 AM 
Subject: Re: *MASTER* enqueue on SYS1.LOGREC 

Thanks for the quick replies, can you issue a D GRS,RES=(*,SYS1.LOGREC) and see 
what it says ? 

-- 
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: *MASTER* enqueue on SYS1.LOGREC

[Matt Hogstrom]

 D GRS,RES=(*,SYS1.LOGREC)
 ISG343I 10.37.44 GRS STATUS 093  
 S=SYSTEM  SYSDSN   SYS1.LOGREC   
 SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS  
 TVT7050   *MASTER*   0001   006CBCF0   SHARE  OWN

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 20, 2019, at 10:33 AM, J Ellis 
> <020d5fbe36e0-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Thanks for the quick replies, can you issue a D GRS,RES=(*,SYS1.LOGREC) and 
> see what it says ?
> 
> --
> 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: *MASTER* enqueue on SYS1.LOGREC

[J Ellis]

Thanks for the quick replies, can you issue a D GRS,RES=(*,SYS1.LOGREC) and see 
what it says ?

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

Re: z/OS V2R4 library updated for z15!

[Susan Shumway]

Hi Gord,

I did some poking around and finally realized that you're probably 
referring to the dates listed in the index.html file, correct? Those are 
static and don't reflect the true build dates of the PDF files - I have 
a request in to have that column (and some other static data) removed 
from the index.html file.


In the meantime, the PDFs that you download, either individually or with 
that bulk download option, should always represent the latest content. 
Please let me know if you don't see the latest dates (July, September, 
etc.) on the PDFs themselves and I'll work to figure it out.


-Sue Shumway

On 9/19/2019 11:08 AM, Gord Tomlin wrote:

On 2019-09-12 22:25, Susan Shumway wrote:

Hi all,

Many deliverables in the z/OS V2R4 product documentation library were 
updated today to include content for z15 and other z/OS function - 
check it out!


z/OS Internet Library: 
http://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary 





Hi Sue,

FYI, the zip file of PDFs still contains the March 30, 2019 versions. 
I'll show the navigation ensure that it's clear what file I'm referencing.


 From 
http://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary 


Click the V2R4 link next to "Download books in PDF format"

The following page is displayed:
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4Library?OpenDocument 



On that page, click "Download all z/OS V2R4 Library publications to ZIP 
file". The publications in the zip file downloaded from this location 
are the March 30 publications.


Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: *MASTER* enqueue on SYS1.LOGREC

[Allan Staller]

Perhaps a lack of maintenance? I couldn't find anything in a quick problem 
search.
I suggest opening a case with IBM.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Friday, September 20, 2019 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: *MASTER* enqueue on SYS1.LOGREC

Tried on my local system.  Here are my results … this is a 2.4 system

NC000 TVT7050  19263 10:15:09.28 IBMUSER  0290  D GRS,C
MR000 TVT7050  19263 10:15:11.91 IBMUSER  0090  ISG343I 10.15.09 GRS 
STATUS 069
DR069 0090  NO ENQ RESOURCE 
CONTENTION EXISTS
DR069 0090  NO REQUESTS PENDING FOR 
ISGLOCK STRUCTURE
ER069 0090  NO LATCH CONTENTION 
EXISTS
NC000 TVT7050  19263 10:16:15.96 IBMUSER  0290  SETLOGRC IGNORE
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF237I 0500 
ALLOCATED TO SYS6
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF285I   
SYS1.LOGREC  KEPT
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF285I   VOL 
SER NOS= T70501.
MR404 TVT7050  19263 10:16:16.04 IBMUSER  0090  IFB097I LOGREC 
RECORDING MEDIUM CHANGED FROM DATASET   TO IGNORE 078
NC000 TVT7050  19263 10:16:26.75 IBMUSER  0290  SETLOGRC DATASET
N 000 TVT7050  19263 10:16:26.76  0290  IEF196I IEF237I 0500 
ALLOCATED TO SYS7
MR404 TVT7050  19263 10:16:26.76 IBMUSER  0090  IFB097I LOGREC 
RECORDING MEDIUM CHANGED FROM IGNORETO DATASET 081
NC000 TVT7050  19263 10:16:36.70 IBMUSER  0290  D GRS,C
MR000 TVT7050  19263 10:16:37.21 IBMUSER  0090  ISG343I 10.16.36 GRS 
STATUS 083
DR083 0090  NO ENQ RESOURCE 
CONTENTION EXISTS
DR083 0090  NO REQUESTS PENDING FOR 
ISGLOCK STRUCTURE
ER083 0090  NO LATCH CONTENTION 
EXISTS

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook 

  LinkedIn   Twitter 


“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 20, 2019, at 10:04 AM, J Ellis 
> <020d5fbe36e0-dmarc-requ...@listserv.ua.edu> wrote:
>
> While testing a fix for a job that had previously filled logrec, I
> shut recording off : SETLOGRC IGNORE once testing once over, I turned
> recording back on: SETLOGRC DATASET Now however the MASTER A/S has a share on 
> it, which prevented the daily logrec dump/clear job from running.
>
> I was sure I had done this before with no issues, that is, no MASTER enqueue 
> left on logrec.
>
> has anyone encountered this and know of a way, short of an IPL to clear get 
> the MASTER enqueue to release ?
>
> D GRS,C
> ISG343I 07.36.44 GRS STATUS 091
> S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST
> SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS
> SYST  *MASTER*   0001   00AB37C0   SHARE  OWN
> SYST  SYEREPT009E   00AEE588 EXCLUSIVEWAIT
>
> D GRS,RES=(*,SYS1.LOGREC.SYST)
> ISG343I 07.38.06 GRS STATUS 114
> S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST
> SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS
> SYST  *MASTER*   0001   00AB37C0   SHARE  OWN
>
> --
> 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
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely 

Re: *MASTER* enqueue on SYS1.LOGREC

[Matt Hogstrom]

Tried on my local system.  Here are my results … this is a 2.4 system 

NC000 TVT7050  19263 10:15:09.28 IBMUSER  0290  D GRS,C 
  
MR000 TVT7050  19263 10:15:11.91 IBMUSER  0090  ISG343I 10.15.09 GRS 
STATUS 069   
DR069 0090  NO ENQ RESOURCE 
CONTENTION EXISTS 
DR069 0090  NO REQUESTS PENDING FOR 
ISGLOCK STRUCTURE 
ER069 0090  NO LATCH CONTENTION 
EXISTS
NC000 TVT7050  19263 10:16:15.96 IBMUSER  0290  SETLOGRC IGNORE 
  
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF237I 0500 
ALLOCATED TO SYS6
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF285I   
SYS1.LOGREC  KEPT   
N 000 TVT7050  19263 10:16:16.04  0290  IEF196I IEF285I   VOL 
SER NOS= T70501.
MR404 TVT7050  19263 10:16:16.04 IBMUSER  0090  IFB097I LOGREC 
RECORDING MEDIUM CHANGED FROM DATASET   TO IGNORE 078  
NC000 TVT7050  19263 10:16:26.75 IBMUSER  0290  SETLOGRC DATASET
  
N 000 TVT7050  19263 10:16:26.76  0290  IEF196I IEF237I 0500 
ALLOCATED TO SYS7
MR404 TVT7050  19263 10:16:26.76 IBMUSER  0090  IFB097I LOGREC 
RECORDING MEDIUM CHANGED FROM IGNORETO DATASET 081 
NC000 TVT7050  19263 10:16:36.70 IBMUSER  0290  D GRS,C 
  
MR000 TVT7050  19263 10:16:37.21 IBMUSER  0090  ISG343I 10.16.36 GRS 
STATUS 083   
DR083 0090  NO ENQ RESOURCE 
CONTENTION EXISTS 
DR083 0090  NO REQUESTS PENDING FOR 
ISGLOCK STRUCTURE 
ER083 0090  NO LATCH CONTENTION 
EXISTS

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 20, 2019, at 10:04 AM, J Ellis 
> <020d5fbe36e0-dmarc-requ...@listserv.ua.edu> wrote:
> 
> While testing a fix for a job that had previously filled logrec, I shut 
> recording off : SETLOGRC IGNORE
> once testing once over, I turned recording back on: SETLOGRC DATASET
> Now however the MASTER A/S has a share on it, which prevented the daily 
> logrec dump/clear job from running.
> 
> I was sure I had done this before with no issues, that is, no MASTER enqueue 
> left on logrec. 
> 
> has anyone encountered this and know of a way, short of an IPL to clear get 
> the MASTER enqueue to release ?
> 
> D GRS,C 
> ISG343I 07.36.44 GRS STATUS 091 
> S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST 
> SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
> SYST  *MASTER*   0001   00AB37C0   SHARE  OWN   
> SYST  SYEREPT009E   00AEE588 EXCLUSIVEWAIT  
> 
> D GRS,RES=(*,SYS1.LOGREC.SYST) 
> ISG343I 07.38.06 GRS STATUS 114
> S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST
> SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS
> SYST  *MASTER*   0001   00AB37C0   SHARE  OWN
> 
> --
> 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

*MASTER* enqueue on SYS1.LOGREC

[J Ellis]

While testing a fix for a job that had previously filled logrec, I shut 
recording off : SETLOGRC IGNORE
once testing once over, I turned recording back on: SETLOGRC DATASET
Now however the MASTER A/S has a share on it, which prevented the daily logrec 
dump/clear job from running.

I was sure I had done this before with no issues, that is, no MASTER enqueue 
left on logrec. 

has anyone encountered this and know of a way, short of an IPL to clear get the 
MASTER enqueue to release ?

D GRS,C 
ISG343I 07.36.44 GRS STATUS 091 
S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST 
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS 
SYST  *MASTER*   0001   00AB37C0   SHARE  OWN   
SYST  SYEREPT009E   00AEE588 EXCLUSIVEWAIT  

D GRS,RES=(*,SYS1.LOGREC.SYST) 
ISG343I 07.38.06 GRS STATUS 114
S=SYSTEM  SYSDSN   SYS1.LOGREC.SYST
SYSNAMEJOBNAME ASID TCBADDR   EXC/SHRSTATUS
SYST  *MASTER*   0001   00AB37C0   SHARE  OWN

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

Re: CA-1 migration to RMM

[Nai, Dean]

Excellent. Thanks Steve.


Dean Nai








On 9/19/19, 2:11 PMEDT, "IBM Mainframe Discussion List on behalf of Steve 
Beaver"  wrote:

> EXTERNAL:  Do not open attachments or click on links unless you recognize and 
> trust the sender.
>
>I have the CA1 to RMM guide and the old software (AS-IS)
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Mike Schwab
>Sent: Thursday, September 19, 2019 1:08 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: CA-1 migration to RMM
>
>As Free Abandonware, request permission for 
>https://urldefense.com/v3/__http://CBTTAPE.org__;!eeWmBe9sc1cuNw!Gh4DRfr788skY7ZVD9Sf2Md9tVkuQE3c08-D0vF8J37qcBC6kNhuQOLkBYkaFptJzw$
>  (admin Sam G.)
>to host the IBM supplied AS IS files and Any non-IBM supplied updates
>under the GPL 2 license or higher or equivalent that might be
>developed for z/OS 2.1 or higher.
>
>On Thu, Sep 19, 2019 at 10:38 AM Max Smith  wrote:
>>
>> Dean,
>>
>> Beginning with z/OS release V2R1 the conversion tools for DFSMSrmm will
>> no longer be supported by IBM and all related materials have been
>> removed from SYS1.SAMPLIB and SYS1.LINKLIB. All conversion programs
>> and samples are still available to clients who intend to migrate to
>> DFSMSrmm through the Software Migration Project Office (SMPO).
>> https://urldefense.com/v3/__https://www.ibm.com/it-infrastructure/z/capabilities/software-migration__;!eeWmBe9sc1cuNw!Gh4DRfr788skY7ZVD9Sf2Md9tVkuQE3c08-D0vF8J37qcBC6kNhuQOLkBYmMT-msAQ$
>>  
>>
>> Depending on your current software release levels these samples,
>> provided As-Is, will be completely functional. Should your software
>> release levels be incompatible with the As-Is samples you are free to
>> modify them for your own use or engage the services of the SMPO. The
>> SMPO can be contracted to provide sample updates as well as full
>> DFSMSrmm migration services.
>> https://urldefense.com/v3/__https://www.ibm.com/downloads/cas/EK5DGBK0__;!eeWmBe9sc1cuNw!Gh4DRfr788skY7ZVD9Sf2Md9tVkuQE3c08-D0vF8J37qcBC6kNhuQOLkBYmnViM0wg$
>>  
>>
>> If needed, the conversion documentation that had been available in
>> EDGCMM01 and EDGCMM0S is available
>> through the following link 
>> https://urldefense.com/v3/__https://www.ibm.com/downloads/cas/DJJZVJA0*loaded__;Iw!eeWmBe9sc1cuNw!Gh4DRfr788skY7ZVD9Sf2Md9tVkuQE3c08-D0vF8J37qcBC6kNhuQOLkBYk91Nqyug$
>>  
>> as the "Data Extraction Programs Users Guide for Conversion to DFSMSrmm".
>>
>> Hope this helps.
>>
>> Max Smith
>> DFSMS Development
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>-- 
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>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