AW: Re: UTF-8 woes on z/OS, a solution - comments invited

[Peter Hunkeler]

>>If for some odd reason you absolutely insist on an EBCDIC-ish approach then
>>you can do what the Japanese have done for decades: Shift Out (SO), Shift
>>In (SI). Refer to CCSID 930 and CCSID 1390 for inspiration. You'd probably
>>use one of the EBCDIC Latin 1+euro codepages as a starting point, such as
>>1140, then SO/SI from there to pick up the exceptional characters.
>>
>The worst of both worlds.



It's repeating history. The origin of all that code page mess was companies 
(not countries at that time) starting to build their own custom code page for 
any character in need that was not in the (single) EBCDIC code page. Later, 
some standardization was done and country code pages evolved.


While is was justifiable at that time, it is not today. Do not start this mess 
again by doing your own code page thing in your programs. Go Unicode, UTF-8 or 
UTF-16, whatever suits best.


--
Peter Hunkeler

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

Re: Problem Mounting File system

[גדי בן אבי]

Thanks
I found the problem.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Wednesday, September 6, 2017 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem Mounting File system

The user ID ZFS doesn't have access to the CICS zFS file, which is protected by 
CICS.*

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: 06 September 2017 10:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Problem Mounting File system

Hi,

We are in the process of building a new system running z/OS v2.2

When I try to mount a file system, I get:
MOUNT FILESYSTEM('CICS.V54.ZFS') MOUNTPOINT('/usr/lpp/cicsts/cicsts54') 
TYPE(ZFS) MODE(RDWR) BPXF135E RETURN CODE 0079, REASON CODE EF096055.  THE 
MOUNT FAILED FOR FILE SYSTEM CICS.V54.ZFS.

In the system log, I see
ICH408I JOB(ZFS ) STEP(ZFS ) 467
  CICS.V54.ZFS CL(DATASET ) VOL(G22UC1)
  INSUFFICIENT ACCESS AUTHORITY
  FROM CICS.* (G)
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
BPXF274I FILE SYSTEM CICS.V54.ZFS 468
FAILED TO MOUNT.
RETURN CODE = 0079, REASON CODE = EF096055

It looks like there is no user associated with ZFS.
I do have a profile in the STARTED class for ZFS.*

What can be causing this?

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: Problem Mounting File system

[Sankaranarayanan, Vignesh]

The user ID ZFS doesn't have access to the CICS zFS file, which is protected by 
CICS.*

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: 06 September 2017 10:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Problem Mounting File system

Hi,

We are in the process of building a new system running z/OS v2.2

When I try to mount a file system, I get:
MOUNT FILESYSTEM('CICS.V54.ZFS') MOUNTPOINT('/usr/lpp/cicsts/cicsts54') 
TYPE(ZFS) MODE(RDWR) BPXF135E RETURN CODE 0079, REASON CODE EF096055.  THE 
MOUNT FAILED FOR FILE SYSTEM CICS.V54.ZFS.

In the system log, I see
ICH408I JOB(ZFS ) STEP(ZFS ) 467
  CICS.V54.ZFS CL(DATASET ) VOL(G22UC1)
  INSUFFICIENT ACCESS AUTHORITY
  FROM CICS.* (G)
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
BPXF274I FILE SYSTEM CICS.V54.ZFS 468
FAILED TO MOUNT.
RETURN CODE = 0079, REASON CODE = EF096055

It looks like there is no user associated with ZFS.
I do have a profile in the STARTED class for ZFS.*

What can be causing this?

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Problem Mounting File system

[גדי בן אבי]

Hi,

We are in the process of building a new system running z/OS v2.2

When I try to mount a file system, I get:
MOUNT FILESYSTEM('CICS.V54.ZFS') MOUNTPOINT('/usr/lpp/cicsts/cicsts54') 
TYPE(ZFS) MODE(RDWR)
BPXF135E RETURN CODE 0079, REASON CODE EF096055.  THE MOUNT FAILED FOR FILE 
SYSTEM CICS.V54.ZFS.

In the system log, I see
ICH408I JOB(ZFS ) STEP(ZFS ) 467
  CICS.V54.ZFS CL(DATASET ) VOL(G22UC1)
  INSUFFICIENT ACCESS AUTHORITY
  FROM CICS.* (G)
  ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
BPXF274I FILE SYSTEM CICS.V54.ZFS 468
FAILED TO MOUNT.
RETURN CODE = 0079, REASON CODE = EF096055

It looks like there is no user associated with ZFS.
I do have a profile in the STARTED class for ZFS.*

What can be causing this?

Gadi

לתשומת ליבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה 
שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance 
with Malam and/or its subsidiaries (hereinafter : "Malam") regulations and 
signatory rights, no offer, agreement, concession or representation is binding 
on the Malam, unless accompanied by a duly signed separate document (or a 
scanned version thereof), affixed with the Malam seal.

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

Re: Lack of Support for Doc for COBOL

[John McKown]

On Tue, Sep 5, 2017 at 4:51 PM, Mike Schwab  wrote:

> How about an II APAR with notes about errors in the manuals?
>

​Just to be my usual "out in left field" self, I wish that IBM would allow
all "no longer available or maintained" manuals to have their "source"
released using the CC​-NC-SA license ( https://creativecommons.org/
licenses/by-nc-sa/4.0/). I do understand why they don't, I guess. But "in a
perfect world" it would be nice. Even nicer would be if they'd use TeX ( tɛx
 ) ​for​ the source.

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

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

Re: Lack of Support for Doc for COBOL

[Steve Thompson]

On 09/05/2017 09:21 PM, John McKown wrote:

On Tue, Sep 5, 2017 at 8:05 PM, Edward Gould 
wrote:




​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.



Where I work, we run parallel sysplex. We have multiple LPARs in 
the main sysplex and it was decided to make our Load Libs PDSE 
some years back (perhaps z/OS 1.13?).


However, I've experienced a PDSE failure using z/OS 1.13 at a 
different shop. Thankfully it was a PDSE holding listing members 
and not the source members. I also lost the Loadlib associated 
with it. So I can appreciate the angst.


With the changes that IBM has made to support PDSE, we have not 
had, that I am aware of, any PDSE failures since I was hired.


Meanwhile, I am a bit concerned that problems are not being 
addressed in COBOL manuals, even if they are "small" or 
"insignificant" problems.


Those insignificant DOC problems cause headaches for people 
writing code to do translation. The difference is, I recognized 
immediately how wrong this was (I'm not doing translation, but 
something related).


Now, for INSPECT TALLYING and EVALUATE, I had to go to a third 
party's explanation to get my COBOL code to work. Yep, I had to 
go to a Fujitsu COBOL manual to get an example. The one I had 
when I was writing SMF code on a W/NT 4.0 box many years ago.


Mind you, not the first time for me to use either verb, but there 
was some interesting things I needed to do and the COBOL 4.2 
manual just didn't do it for me. One look at what was said with 
the Fujitsu book and I recognized how I was misreading IBM's doc.


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: Lack of Support for Doc for COBOL

[John McKown]

On Tue, Sep 5, 2017 at 8:05 PM, Edward Gould 
wrote:

> > On Sep 5, 2017, at 4:51 PM, Mike Schwab  wrote:
> >>
> >> The number of defects reported against COBOL V4 is almost zero!  That
> is one of
> >> the reasons why we are considering dropping support for COBOL V4.
> >>
>
> Sorry to persuade you otherwise. After much talk to/from management we are
> delaying going to the next v6(?) in COBOL.
> We/they don’t trust PDSE. It has broken once to often for this customer (I
> agree) and they lost load modules up the ying yang.
> They also got feedback from the programmers and how they hate the new
> COBOL’s.
> Management knows that sooner or later they have to go but between PDSE and
> COBOL, they are delaying it as long as they can.
> They understand that they are out of service but to quote one VP better to
> be out of service than to loose load modules and that means downtime and
> they can’t afford downtime.
> The auditors know about this but as it turns out they hate PDSe’s as much
> as upper management. The CIO is aware and not happy but he got burned with
> PDSE and he agrees that it is worth the chance. I was surprised at their
> resistance but when you here venom coming out of a VP’s mouth about PDSE’s
> you would understand.
> I tried to get the programmers resistance to have them write down their
> issues, but I had a feeling they didn’t have to justify much as the VP was
> really pissed.
> When IBM makes enemies like this over one portion of the OS, they are
> asking IMO to loose a customer.
>

​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.



>
> Ed
>
>

-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

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

Re: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 5, 2017, at 4:51 PM, Mike Schwab  wrote:
>> 
>> The number of defects reported against COBOL V4 is almost zero!  That is one 
>> of
>> the reasons why we are considering dropping support for COBOL V4.
>> 

Sorry to persuade you otherwise. After much talk to/from management we are 
delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I 
agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and 
COBOL, they are delaying it as long as they can. 
They understand that they are out of service but to quote one VP better to be 
out of service than to loose load modules and that means downtime and they 
can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much as 
upper management. The CIO is aware and not happy but he got burned with PDSE 
and he agrees that it is worth the chance. I was surprised at their resistance 
but when you here venom coming out of a VP’s mouth about PDSE’s you would 
understand.
I tried to get the programmers resistance to have them write down their issues, 
but I had a feeling they didn’t have to justify much as the VP was really 
pissed.
When IBM makes enemies like this over one portion of the OS, they are asking 
IMO to loose a customer.

Ed 

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

Re: PDS/E issue

[Lizette Koehler]

What is the MESSAGE id of the PDSE MEMBER IN USE message.

That might provide a clue.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steely.Mark
> Sent: Tuesday, September 05, 2017 2:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDS/E issue
> 
> We are z/OS 2.2.  For a DR test our current volumes are flashed ( I may not
> be using the correct term) and we IPL from these volumes. The DR test is also
> performed on a separate CPU not connected to the current environment. After
> the IPL we have a process which updates several members in a PDS/E .
> We use a file-aid job to update the members - this PDS/E is a  JES2 proc. The
> job received the following messages : PDSE MEMBER IN USE, UNABLE TO PROCESS
> MEMBER 1234.  I tried several ways to determine what was using the data
> set and/or member. I was able to edit the data set and member. I used a MXI
> enq display and D GRS,RES=(*,xxx.x) command and nothing was found.
> 
> I was able to allocate a new pds/e using ISPF 3.2 and copy the members using
> ISPF 3.3. Then I was able to rename the datasets and resume processing. After
> the rename - with the old dataset - I tried to run the update job and it
> still failed with the in use message.  With  the new pdse the job ran as
> expected.
> 
> I didn't have any more time to investigate.
> 
> Has anyone else had this type of issue ?
> 
> Any other idea's what to do if this occurs again?
> 
> Thank You
> 
> 

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

Re: PDS/E issue

[Charles Mills]

I also wondered what

> this PDS/E is a  JES2 proc

meant exactly.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, September 5, 2017 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E issue

Maybe you could provide a simple stick diagram to clarify your config. I'm 
puzzled by the statement that the test involves 'a separate CPU not connected 
to the current environment'. If it's not connected, how does it share DASD with 
production? 

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Andy Wood]

On Tue, 5 Sep 2017 22:30:59 +0800, Timothy Sipples  wrote:

...
>you can do what the Japanese have done for decades: Shift Out (SO), Shift
>In (SI).

ZCZC
DECADESQUERY


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

Re: PDS/E issue

[Jesse 1 Robinson]

Maybe you could provide a simple stick diagram to clarify your config. I'm 
puzzled by the statement that the test involves 'a separate CPU not connected 
to the current environment'. If it's not connected, how does it share DASD with 
production? 

PDSE, unlike traditional PDS, is very sensitive to configuration. In general, 
sharing a PDSE across sysplex boundaries is not supported. Even though a file 
is physically accessible, sharing as PDSE requires support from XCF/XES. That's 
only possible within a single sysplex.

Is this the first test you've ever done in this config? 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely.Mark
Sent: Tuesday, September 05, 2017 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):PDS/E issue

We are z/OS 2.2.  For a DR test our current volumes are flashed ( I may not be 
using the correct term) and we IPL from these volumes. The DR test is also 
performed on a separate CPU not connected to the current environment. After the 
IPL we have a process which updates several members in a PDS/E .
We use a file-aid job to update the members - this PDS/E is a  JES2 proc. The 
job received the following messages : PDSE MEMBER IN USE, UNABLE TO PROCESS 
MEMBER 1234.  I tried several ways to determine what was using the data set 
and/or member. I was able to edit the data set and member. I used a MXI enq 
display and D GRS,RES=(*,xxx.x) command and nothing was found.

I was able to allocate a new pds/e using ISPF 3.2 and copy the members using 
ISPF 3.3. Then I was able to rename the datasets and resume processing. After 
the rename - with the old dataset - I tried to run the update job and it still 
failed with the in use message.  With  the new pdse the job ran as expected.

I didn't have any more time to investigate.

Has anyone else had this type of issue ?

Any other idea's what to do if this occurs again?

Thank You


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

Re: Lack of Support for Doc for COBOL

[Mike Schwab]

How about an II APAR with notes about errors in the manuals?

On Tue, Sep 5, 2017 at 12:29 PM, Tom Ross  wrote:
>>Very, considering there are literally hundreds if not thousands of shops
>>still using COBOL..
>
> Yes, it is unfortunate, but for a serious error we would reconsider our 
> position
> on COBOL V4 documentation.
>
> In this case, the reported bug was very minor, and most of the many many COBOL
> shops are already using COBOL V5 or V6, whose manuals are getting updated.
>
> The number of defects reported against COBOL V4 is almost zero!  That is one 
> of
> the reasons why we are considering dropping support for COBOL V4.
>
> Cheers,
> TomR  >> COBOL is the Language of the Future! <<
>
> --
> 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

PDS/E issue

[Steely.Mark]

We are z/OS 2.2.  For a DR test our current volumes are flashed ( I may not be 
using the correct term) and we IPL from these volumes. The DR test is also 
performed on a separate CPU not connected to the current environment. After the 
IPL we have a process which updates several members in a PDS/E .
We use a file-aid job to update the members - this PDS/E is a  JES2 proc. The 
job received the following messages : PDSE MEMBER IN USE, UNABLE TO PROCESS 
MEMBER 1234.  I tried several ways to determine what was using the data set 
and/or member. I was able to edit the data set and member. I used a MXI enq 
display and D GRS,RES=(*,xxx.x) command and nothing was found.

I was able to allocate a new pds/e using ISPF 3.2 and copy the members using 
ISPF 3.3. Then I was able to rename the datasets and resume processing. After 
the rename - with the old dataset - I tried to run the update job and it still 
failed with the in use message.  With  the new pdse the job ran as expected.

I didn't have any more time to investigate.

Has anyone else had this type of issue ?

Any other idea's what to do if this occurs again?

Thank You


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

Re: IEAARR

[Steve Smith]

In-line responses this time, hopefully clearly marked after mail processing:

On Sat, Sep 2, 2017 at 9:46 AM, Peter Relson  wrote:
> 
> I think the DYNSTORAGE keyword is redundant, and the macro could select
> from either the direct (RX-type) or indirect (A-type) keywords for each of
> the four major address keywords individually, depending on what's
> specified.  And really, whether I have "dynamic storage"
> available has nothing to do with how the parms should be passed.
> 
> Surely you understand that it is not possible in general for a macro to
> make such decisions.
>

Not sure what we're missing here.  The macro can easily determine
whether ARR= or ARRPTR= was specified.  And hell, write an error if
both or neither are.  What's not possible about that?  And clearly, it
would be far more useful to allow some operands to be direct, and some
as indirect.

> 
> I don't have a problem with the *PTR keywords as options, although I see
> no need for them.  If the address is in storage, then I can easily L/LG or
> whatever myself and pass it in a register.  But most of the time, it's
> easier and more efficient to LA/LAY/LARL the addresses, if not already in
> a register.
> 
> It is similarly impossible to know that it is OK to use LARL. And it is
> impossible to know that LAY is needed instead of LA. And it would be poor
> form to change to use a 6-byte instruction when a 4-byte instruction both
> had been used "forever" and works.
>

Part of my point.  There are too many ways to address things
nowadays... no macro can reasonably be expected to support them all.
I don't want macros to support them all.  I want it to let me load the
register myself.

> 
> Now that's a problem if I'm prevented from using R14 R15, R0, and R1; it's
> common not to have a whole bunch of free registers.  And it's more
> efficient to put the addresses where they need to be once, instead of
> copying them.  For example, I know that the ARR address is going to wind
> up in general register 1; I have the entire instruction set available to
> get it in there, without needing help from the macro.
> Many existing macros work that way, and I've never seen a problem with it.
> 
> You only know what you know, which is what it does today. The macro might
> find a need to use register one for its own temporary purposes prior to
> priming it with the data that you have provided. That is far from
> uncommon.
>

Sure you could change the macro, and/or change the actual interface.
But IBM has a long history of never doing that.  Any program assembled
and running correctly in 1966 should still work, right?

> 
> what would be really nice would be if every macro had a consistent way of
> specifying @Peter's "four [or more?] choices." The problem is often not so
> much the lack of a particular macro operand choice, but rather (just as
> one example) that one does not remember whether for this particular macro
> (R2) means that the value is in R2 or the value is in a fullword pointed
> to by R2. One has to go the manual and parse the description carefully to
> find out.
> 
> I fully agree. The first is of course a nice thought but it won't happen.
> The point about level of indirection is of course critical. And yes it
> means reading the book (and more often means reading the expansion) to
> make sure what you got is what you wanted.
>

Sometimes I think that going with callable services that use a
standard parameter list is the safest way to go.  But that certainly
has its own issues.

> 
> The VSAM macros support a variety of address formats like (*,scon). I'm
> not terribly fond of them, but at least it was an attempt at a universal,
> flexible syntax.
> 
> I'm not sure which macros those are, but IBM standards are clear on what
> is to be supported. They might be archaic, but they are standards. It's
> quite possible that those macros do not comply.

The VSAM xxxCB macros came from a strange time & place.  Fortunately,
they're completely unnecessary, although much of this discussion
applies to them.

>
> Peter Relson
> z/OS Core Technology Design
>

-- 
sas

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Robert Prins]

On 2017-09-05 15:41, Walt Farrell wrote:

On Tue, 5 Sep 2017 10:19:45 -0500, Paul Gilmartin 
wrote:


What language(s) cleanly handle vertical alignment of formatted text output
when the text contains UTF-16 supplemental/surrogate (not in the BMP)
characters? Here's an example of /bin/printf's failure for similar input
with UTF-8 on MacOS:

The script: printf "%-22s+++\n" "Hello World." printf "%-22s+++\n" "Привет
мир." printf "%-22s+++\n" "Bonjour le monde."

writes: Hello World.  +++ Привет мир.  +++ Bonjour le monde.
+++

I wish the "+++" would line up (at least in a monospaced font). What sort
of PICTURE would work for such, not restricting to BMP?


It would take more than a simple script like that, but with programming it
can be done. I have a Python program that does it, for example. The key is
understanding that some characters don't take up any space when printed
(combining characters, for example), and therefore don't contribute to the
length of the output string. When those characters are present you need to
pad the end with blanks if you want a fixed width output string.


And that is exactly what I'm doing with my translate/sum method. I know that any 
character that starts with the orange bytes in 
 is a non-printing one (and 
yes a few exceptions that I do not cater for, assuming the non-z/OS file to 
contain correct UTF-8) and the translate just sets them to zero.


As I wrote, it works like a charm, but may not be the most efficient way of 
doing things, although, given the (still) limited amount of UTF-8 text that has 
to undergo this kind of processing, it's probably way faster than converting the 
entire file into a multi-byte format, and using PL/I WCHAR's and the ULENGTH() 
builtin, which must, in its implementation, do something pretty similar anyway.


Robert
--
Robert AH Prins
robert(a)prino(d)org

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

New IBM Webinar for RMF/SMF

[Edward Gould]

 
Join us for a complimentary IBM Systems Magazine webinar, with content by 
IntelliMagic, and evolve to intelligent analytics to reduce performance risk, 
optimize infrastructure costs, and bridge the skills gap.
 
Predictive Intelligence from RMF/SMF for Enhanced Performance & Capacity 
Planning
Wednesday, October 4
10 PT / Noon CT / 1 ET

24x7 performance from the z/OS infrastructure is more important than ever, but 
also more difficult than ever using reporting tools designed decades ago.

Join us to:
Learn why AI techniques applied to RMF and SMF are needed and how it works
Hear real-world use cases where predictive intelligence protected z/OS 
performance
See how new analytics help lower MLC without negative performance impact 
 
Register Now 

 
More Upcoming Events 


Can't attend the live event? Register here 

 to receive a link to the recorded version.


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

Re: Lack of Support for Doc for COBOL

[Tom Ross]

>Very, considering there are literally hundreds if not thousands of shops
>still using COBOL..

Yes, it is unfortunate, but for a serious error we would reconsider our position
on COBOL V4 documentation.

In this case, the reported bug was very minor, and most of the many many COBOL
shops are already using COBOL V5 or V6, whose manuals are getting updated.

The number of defects reported against COBOL V4 is almost zero!  That is one of
the reasons why we are considering dropping support for COBOL V4.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[David W Noon]

On Tue, 5 Sep 2017 10:19:45 -0500, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: UTF-8
woes on z/OS, a solution - comments invited" (in
<2075516733653603.wa.paulgboulderaim@listserv.ua.edu>):

[snip]
> What language(s) cleanly handle vertical alignment of formatted text output 
> when
> the text contains UTF-16 supplemental/surrogate (not in the BMP) characters?

Python and Java, at least.

> Here's an example of /bin/printf's failure for similar input with UTF-8 on 
> MacOS:
> 
> The script:
> printf "%-22s+++\n" "Hello World."
> printf "%-22s+++\n" "Привет мир."
> printf "%-22s+++\n" "Bonjour le monde."
> 
> writes:
> Hello World.  +++
> Привет мир.  +++
> Bonjour le monde. +++
> 
> I wish the "+++" would line up (at least in a monospaced font).

This is a bug in your printf UNIX command. It is counting bytes to
determine print position, rather than counting glyphs. It probably isn't
Unicode-aware.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[David W Noon]

On Tue, 5 Sep 2017 16:33:43 +, Pew, Curtis G
(curtis@austin.utexas.edu) wrote about "Re: UTF-8 woes on z/OS, a
solution - comments invited" (in
):

> In Python 3, at least, the built-in substitution facility can handle it as-is:

Python 3 uses UTF-32 for all its default character strings. This
relieves the problem of counting bytes or counting glyphs.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Pew, Curtis G]

On Sep 5, 2017, at 10:42 AM, Walt Farrell  wrote:
> 
> Python has Unicode functions that let you examine the characteristics of the 
> characters within a string so you can figure out the proper length when 
> printed, but I'm not aware of anything built-in like a print function that 
> does that automatically. It would be handy.

In Python 3, at least, the built-in substitution facility can handle it as-is:

Python 3.5.4 (default, Aug 12 2017, 14:31:52) 
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def fmtprt(hw):
... print("%-22s+++\n" % hw)
... 
>>> fmtprt("Hello, world!")
Hello, world! +++

>>> fmtprt("Привет мир.")
Привет мир.   +++

>>> fmtprt("Bonjour le monde.")
Bonjour le monde. +++

>>> 


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Tony Harminc]

On 5 September 2017 at 10:30, Timothy Sipples  wrote:

>
> If for some odd reason you absolutely insist on an EBCDIC-ish approach then
> you can do what the Japanese have done for decades: Shift Out (SO), Shift
> In (SI). Refer to CCSID 930 and CCSID 1390 for inspiration. You'd probably
> use one of the EBCDIC Latin 1+euro codepages as a starting point, such as
> 1140, then SO/SI from there to pick up the exceptional characters.
>

Another EBCDIC-ish approach would be UTF-EBCDIC. This is fully support by
z/OS Unicode conversion services; perhaps PL/I (and other things) should
make it Just Work under the covers.

Tony H.

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Walt Farrell]

On Tue, 5 Sep 2017 10:19:45 -0500, Paul Gilmartin  wrote:

>What language(s) cleanly handle vertical alignment of formatted text output 
>when
>the text contains UTF-16 supplemental/surrogate (not in the BMP) characters?
>Here's an example of /bin/printf's failure for similar input with UTF-8 on 
>MacOS:
>
>The script:
>printf "%-22s+++\n" "Hello World."
>printf "%-22s+++\n" "Привет мир."
>printf "%-22s+++\n" "Bonjour le monde."
>
>writes:
>Hello World.  +++
>Привет мир.  +++
>Bonjour le monde. +++
>
>I wish the "+++" would line up (at least in a monospaced font).
>What sort of PICTURE would work for such, not restricting to BMP?

It would take more than a simple script like that, but with programming it can 
be done. I have a Python program that does it, for example. The key is 
understanding that some characters don't take up any space when printed 
(combining characters, for example), and therefore don't contribute to the 
length of the output string. When those characters are present you need to pad 
the end with blanks if you want a fixed width output string.

Python has Unicode functions that let you examine the characteristics of the 
characters within a string so you can figure out the proper length when 
printed, but I'm not aware of anything built-in like a print function that does 
that automatically. It would be handy.

Presumably one could do that in other languages, too. And presumably one could 
implement a print function that did that automatically. Perhaps someone has, or 
perhaps some language can do it automatically.

-- 
Walt

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Paul Gilmartin]

On Tue, 5 Sep 2017 22:30:59 +0800, Timothy Sipples wrote:
>
>FYI, if DB2 for z/OS is in the loop then DB2 will convert UTF-8 to UTF-16
>for your PL/I application(s). Just store the UTF-8 data in DB2, use the
>WIDECHAR datatype, and it all happens automagically, effortlessly, with no
>UTF-8 to UTF-16 programming required. See here for more information:
>
>https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/char/src/tpc/db2z_processunidatapli.html
>
What language(s) cleanly handle vertical alignment of formatted text output when
the text contains UTF-16 supplemental/surrogate (not in the BMP) characters?
Here's an example of /bin/printf's failure for similar input with UTF-8 on 
MacOS:

The script:
printf "%-22s+++\n" "Hello World."
printf "%-22s+++\n" "Привет мир."
printf "%-22s+++\n" "Bonjour le monde."

writes:
Hello World.  +++
Привет мир.  +++
Bonjour le monde. +++

I wish the "+++" would line up (at least in a monospaced font).
What sort of PICTURE would work for such, not restricting to BMP?

>If for some odd reason you absolutely insist on an EBCDIC-ish approach then
>you can do what the Japanese have done for decades: Shift Out (SO), Shift
>In (SI). Refer to CCSID 930 and CCSID 1390 for inspiration. You'd probably
>use one of the EBCDIC Latin 1+euro codepages as a starting point, such as
>1140, then SO/SI from there to pick up the exceptional characters.
>
The worst of both worlds.

-- gil

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

Re: IEAARR

[Charles Mills]

I doubt anyone is interested in a long dissertation on what I think. I will
just clarify two things.

- After reading what Peter writes about the benefits of macros, I think we
agree ...

- Yeah, comparing malloc() to STORAGE OBTAIN was a poor choice. malloc() is
like a baby GETMAIN with no options other than the size of the storage. My
point was not "number of features and variations" but rather "everything is
a standard call with standard linkage and parameters." Perhaps a better
comparison might be the __console2() library function, which manages to
implement many (most?) features of WTO, but do it in a standard call with
standard linkage.

Not sure of the exact definition of "system programming." Some use it to
mean SMP/E and SYS1.PARMLIB and some use the term to mean developing
software that does "sophisticated" functions, not reports and big files of
financial data. For the latter, I find C++ a terrific (system?) programming
language. I would guess that more "sophisticated" (whatever that means)
programs (across all platforms) are written in C/C++ than any other
language. Certainly true if you group in C++'s logical follow-on, Java. As I
wrote earlier, I am very happy to leave the "oh crap, I forgot to clear R2"
type problems of assembler behind me. And in a shout-out to IBM, I have been
*very* pleased with the performance of the compiled code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Monday, September 4, 2017 6:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEAARR

My take is this:

If you comply with the documented requirements of an interface then if you
choose to "roll your own" rather than use the macro, you will survive.
And you should expect that we will provide notification (as an
incompatibility) if that does not hold for some reason (upon which
notification you will be on the hook to see that notification and react).

But that does mean that you have to start by complying (and that includes
obeying the register-choice limitations). If you choose not to comply,
whether you roll your own or not, and we change something that affects only
someone who does not comply, we might notify, we might not. The risk is
yours (and your customers') to bear. It is up to your customers (or you if
it's for yourself) to gauge whether that risk is acceptable or not. And if
you don't inform your customers of that risk, then they might be rather
unhappy if something unfriendly results that they can tie to that
occurrence.

Notification might include notification to ISVs in Partners in Development
(if I have that name right) as well as within APAR hold data and/or release
migration data depending on the delivery mechanism of the change.


in a way, macros are for the convenience of IBM, not the convenience of the
user programmer.

I'd say "not even close". They are clearly for the convenience of the user
as well as for the provider (whether that provider by IBM or anyone else). 

It is far easier to invoke a macro than code all the bits and bytes (as well
as getting whatever syntax checking the macro provides).
It is true that it is likely more convenient for the provider to describe
how to invoke the macro than how to build the parameter area. 
IBM definitely chooses to consider the book description of the macro to be
the interface. If you use the macro, then you are intended to be protected
from incompatible changes.
If you do not, then you are on your own.


DCB

We are talking here about executable macros, not macros that define control
blocks.


There is
no STORAGE macro; there is address = malloc(bytes) and free(address).

And that's one reason why C is a nice application programming language and
not so great as a z/OS system programming language. 
If all z/OS storage were one subpool, there wouldn't be a z/OS.

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

More IBM company ***ery WAS: More IBM website ****ery

[Dana Mitchell]

I assume they know exactly what they are doing.  Look at the Board members,  
CEO's of AMEX, UPS, DOW, J, CAT, Ford, Boeing...  They don't seem to be 
interested in competing or growing, rather, they have somehow discerned how 
much z and Power revenues will decline each year and they cut staff and 
expenses just a hair more than that to keep margins looking good.  Sad.

Dana 

On Fri, 1 Sep 2017 10:23:04 -0400, Phil Smith III  wrote:
>
>Seriously, this is not how a world-class company operates.
>

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Pew, Curtis G]

On Sep 5, 2017, at 8:54 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Are you confusing UTF-16 and UCS-2?
>https://en.wikipedia.org/wiki/UTF-16
> 
>UTF-16 (16-bit Unicode Transformation Format) is a character encoding
>capable of encoding all 1,112,064 valid code points of Unicode. The
>encoding is variable-length, as code points are encoded with one or two
>16-bit code units. (also see Comparison of Unicode encodings for a
>comparison of UTF-8, -16 & -32)
> 
>UTF-16 developed from an earlier fixed-width 16-bit encoding known as UCS-2
>(for 2-byte Universal Character Set) once it became clear that 16 bits were
>not sufficient for Unicode's user community.[1]

I was trying to say what the second paragraph you quoted says, without 
explicitly mentioning UCS-2. At least part of the answer to “Why is there 
UTF-16?” is “Because once there was UCS-2.”

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: WinSCP or FileZilla to z/OS (not OMVS) ?

[Kirk Wolf]

Elardus,

I'm reasonably certain from looking at your script that your z/OS server is
running Co:Z SFTP, which is why it works :-)

Also, you could use PuTTY PSFTP to do batch scripting as well (on Windows),
or OpenSSH sftp on z/OS.

Regards,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Sep 5, 2017 at 3:52 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Elardus Engelbrecht wrote:
>
> >Dyck, Lionel B. (TRA) wrote:
> >>Any thoughts on how to get WinSCP or FileZilla to access z/OS datasets
> when  connected?
> >>All I am able to get is access to the OMVS side of the system.
>
> >You can use WinSCP to access z/OS datasets. I will post on Monday a
> sample batch job (in windoze) how to do that.
>
> No FileZilla, since I could not use automated transfers in one or other
> way.
>
> As promised, here is a generated Windows WinSCP script, I use to access a
> PS or PO dataset's member:
>
> For retrieving three members from two PDS datasets:
>
> "C:\Program Files\WinSCP\WinSCP.com" ^
>   /ini=nul ^
>   /command ^
> "open sftp://:@/ -hostkey=""???""" ^
> "lcd C:\" ^
> "cd //HLQ1." ^
> "get " ^
> "get " ^
> "cd //HLQ2." ^
> "get " ^
> "exit"
>
> It is a PITA, but it is working. Transfer OMVS files is a dream. No
> problemo there!
>
> I still prefer the FTP process from Automation software on z/OS where you
> can do on large scale mulitple FTP transfers while renaming destination
> files using wildcards, timestamps, etc. like this:
>
> put 'HLQ.%%YESTERDAY'  OUTPUT-%%YESTERDAY.TXT
>
> It is hard to do the same tricks from a windoze machine...
>
> Grab whatever utility you can use and live with that... ;-D
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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: UTF-8 woes on z/OS, a solution - comments invited

[Timothy Sipples]

Paul Gilmartin wrote:
>Why is there UTF-16?
>[]
>o It lacks the compactness of UTF-8 in the case of Latin text.

Japanese Kanji, Traditional Chinese, Simplified Chinese, and emoji (!), as
examples, are not Latin text. More than 1.5 billion people is a lot of
people, and that's not counting all the billions of emoji users. :-)

And who cares about this compactness, really? Bytes are no longer *that*
precious, especially when they're compressed anyway.

>(What does Java use internally?)

UTF-16, as it happens.

FYI, if DB2 for z/OS is in the loop then DB2 will convert UTF-8 to UTF-16
for your PL/I application(s). Just store the UTF-8 data in DB2, use the
WIDECHAR datatype, and it all happens automagically, effortlessly, with no
UTF-8 to UTF-16 programming required. See here for more information:

https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/char/src/tpc/db2z_processunidatapli.html

If for some odd reason you absolutely insist on an EBCDIC-ish approach then
you can do what the Japanese have done for decades: Shift Out (SO), Shift
In (SI). Refer to CCSID 930 and CCSID 1390 for inspiration. You'd probably
use one of the EBCDIC Latin 1+euro codepages as a starting point, such as
1140, then SO/SI from there to pick up the exceptional characters.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: may have job opening here 4 z/OS generalist + some CICS + some Prog Prod

[John McKown]

On Sat, Sep 2, 2017 at 12:12 PM, scott Ford  wrote:

> Yeah... So John what do you guys do about system fixes, maintenance ?
>

​Didn't look at email over the Labor Day weekend.

For IBM software, basically z/OS and it's "included" products such as RACF
and DFSORT, we would on a RECEIVE FROM NETWORK when IBM put up a new RSU.
But we would only install selected PTFs​ if we were experiencing a problem
or it as a "hiper" type situation. Our normal method of z/OS maintenance
was to reorder z/OS & associated products; install & test on the sandbox;
then create a new set of RES & CAT volume from those - IPL & test on a
Sunday, then "go / no go". However, we basically were told to "stabilize"
z/OS when we were "going to the cloud", so I stopped "wasting" MSUs by
"downloading unneeded maintenance". I am not sure exactly what we will do
in the future. I am hoping that we will simply order z/OS 2.3. But there
are some problems with that in that we have a "permanent execution" license
for some system level vendor products. I'm fairly sure these levels of
software will not run on z/OS 2.3. I don't know what we would do if we "had
to" upgrade z/OS. The company remains very cost conscience. And that area
(money) is totally outside my purview & knowledge.

​The other main IBM software is CICS Transaction Server. We are 4.2. I
don't really know what is going to happen to this product either. What we
have does the job for us. So justifying the increased cost to go to 5.4
seems unlikely. Our applications are basically fairly simple COBOL
programs. That is, they don't need any of the new facilities in 5.4 (or
even earlier).


​We basically did the same with vendor products. But the "cloud sourcing"
only slowed down our implementations. We have upgraded CA-Datacom/AD &
CA-11, & are finishing up CA-7 (delayed due to vacation).

We are not, never have been, nor are ever likely to be "on the edge".



>
> Scott
>
>


-- 
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

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

Re: IEAARR

[Peter Relson]

Clarifying:


If you comply with the documented requirements of an interface then if you 

choose to "roll your own" rather than use the macro, you will survive.


By "roll your own" I meant that you produce exactly what the macro 
produces in terms of what gets passed to the service and what (and how) 
output data is dealt with.
So usually you would invoke the macro, see what it expands to, then (in 
effect) copy that.

And of course that does also imply that you "got it right" whether by the 
macro or the hand-built analog.

Peter Relson
z/OS Core Technology Design


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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Paul Gilmartin]

On 2017-09-05, at 06:36, Pew, Curtis G wrote:
> 
> Unicode was originally supposed to be a fixed-width, 16-bit encoding. 
> Fixed-width was actually a design criteria for the original developers. It 
> was only after it became clear that there was no possible way to fit all the 
> needed characters into 16 bits that the “astral planes”[1] were (reluctantly) 
> added to Unicode and the various UTF encodings defined. In this light, UTF-16 
> is the closest thing to the original version of Unicode. Also, if your text 
> includes few or no Latin characters UTF-16 may be just as compact, or even 
> more compact, than UTF-8, and can probably be processed more easily.
>  
Are you confusing UTF-16 and UCS-2?
https://en.wikipedia.org/wiki/UTF-16

UTF-16 (16-bit Unicode Transformation Format) is a character encoding
capable of encoding all 1,112,064 valid code points of Unicode. The
encoding is variable-length, as code points are encoded with one or two
16-bit code units. (also see Comparison of Unicode encodings for a
comparison of UTF-8, -16 & -32)

UTF-16 developed from an earlier fixed-width 16-bit encoding known as UCS-2
(for 2-byte Universal Character Set) once it became clear that 16 bits were
not sufficient for Unicode's user community.[1]

> Since Java was developed when Unicode was still supposed to be a 16-bit 
> encoding the early versions at least used what we would now call UTF-16. As I 
> recall, there was a significant period of time after Unicode abandoned a 
> fixed-width 16-bit representation before Java implementations really 
> supported characters from the “astral planes”.
> 
> 
> [1] Unicode is still organized into 64K ranges called “planes”. The original 
> 0–x range is called the “Basic Multilingual Plane” (BMP) and “astral 
> planes” is a convenient nickname for the other ranges.

-- gil

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Pew, Curtis G]

On Sep 4, 2017, at 9:02 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Why is there UTF-16?
> 
> o It's a variable-length encoding, involving the same complexities as UTF-8.
> 
> o It lacks the compactness of UTF-8 in the case of Latin text.
> 
> Is it because it's (sort of) an extension of UCS-2?
> 
> (What does Java use internally?)

Unicode was originally supposed to be a fixed-width, 16-bit encoding. 
Fixed-width was actually a design criteria for the original developers. It was 
only after it became clear that there was no possible way to fit all the needed 
characters into 16 bits that the “astral planes”[1] were (reluctantly) added to 
Unicode and the various UTF encodings defined. In this light, UTF-16 is the 
closest thing to the original version of Unicode. Also, if your text includes 
few or no Latin characters UTF-16 may be just as compact, or even more compact, 
than UTF-8, and can probably be processed more easily.

Since Java was developed when Unicode was still supposed to be a 16-bit 
encoding the early versions at least used what we would now call UTF-16. As I 
recall, there was a significant period of time after Unicode abandoned a 
fixed-width 16-bit representation before Java implementations really supported 
characters from the “astral planes”.


[1] Unicode is still organized into 64K ranges called “planes”. The original 
0–x range is called the “Basic Multilingual Plane” (BMP) and “astral 
planes” is a convenient nickname for the other ranges.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Scott Chapman]

On Mon, 4 Sep 2017 21:02:29 -0500, Paul Gilmartin  wrote:

>(What does Java use internally?)
>
>-- gil

Currently Java does use UTF-16, but Java 9 will get a little smarter about 
that, storing ins 1 byte/character ISO8859-1/Latin-1 where it can. 
http://openjdk.java.net/jeps/254

The G1 garbage collector (which I believe will be the new default) will also 
get string deduplication:
http://openjdk.java.net/jeps/192

Since those are internal JVM things, if those make will it into the IBM JVM I 
of course don't know. 

Scott Chapman

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

Re: UTF-8 woes on z/OS, a solution - comments invited

[Elardus Engelbrecht]

Linda wrote:

>Ummm and I heard (and used it as) it as Seriously Outa Luck!

That is the one of the polite versions of "Sh*t Outa Luck"... ;-D


SOL is also (over 200+ meanings according to http://www.acronymfinder.com ):

System Off Line

Smile Out Loud
Sadly Outta Luck (polite form)
Stuff Outta Luck (polite form)
Sorta Outta Luck
Sobbing Out Loud  ... wh... sni... sni... ;-)
Swear Out Loud  ... %$#@#@%^&**

Re: WinSCP or FileZilla to z/OS (not OMVS) ?

[Elardus Engelbrecht]

Elardus Engelbrecht wrote:

>Dyck, Lionel B. (TRA) wrote:
>>Any thoughts on how to get WinSCP or FileZilla to access z/OS datasets when  
>>connected?
>>All I am able to get is access to the OMVS side of the system.

>You can use WinSCP to access z/OS datasets. I will post on Monday a sample 
>batch job (in windoze) how to do that.

No FileZilla, since I could not use automated transfers in one or other way. 

As promised, here is a generated Windows WinSCP script, I use to access a PS or 
PO dataset's member:

For retrieving three members from two PDS datasets:

"C:\Program Files\WinSCP\WinSCP.com" ^
  /ini=nul ^
  /command ^
"open sftp://:@/ -hostkey=""???""" ^
"lcd C:\" ^
"cd //HLQ1." ^
"get " ^
"get " ^
"cd //HLQ2." ^
"get " ^
"exit"

It is a PITA, but it is working. Transfer OMVS files is a dream. No problemo 
there!

I still prefer the FTP process from Automation software on z/OS where you can 
do on large scale mulitple FTP transfers while renaming destination files using 
wildcards, timestamps, etc. like this:

put 'HLQ.%%YESTERDAY'  OUTPUT-%%YESTERDAY.TXT 

It is hard to do the same tricks from a windoze machine...

Grab whatever utility you can use and live with that... ;-D

Groete / Greetings
Elardus Engelbrecht

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