Re: "The Computers Nobody Wanted"

[Phil Smith III]

Paul Gilmartin wrote:
>For me, it was broken on the UA LISTSERV website and in
>Mac Mail.app.  The raw source shows:
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>...
>
> http://worrydream.com/refs/Strassmann%20-%20The%20Computers%20Nobody%20Wante

*shrug* it was sent as:
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Whatever the listserv does to it is clearly beyond my control.

> Only sorta.  Firefox calls it a security risk.  "http"?

As I wrote, yes, it's http. Also not under my control, eh?

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

Re: "The Computers Nobody Wanted"

[Paul Gilmartin]

On Thu, 14 Apr 2022 17:16:56 -0400, Phil Smith III  wrote:

>? My link worked fine as sent, both at my end and in Gmail. Gil, your client
>seems to be breaking QPed lines?! 
>
For me, it was broken on the UA LISTSERV website and in
Mac Mail.app.  The raw source shows:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
...
http://worrydream.com/refs/Strassmann%20-%20The%20Computers%20Nobody%20Wante
d.pdf

Broken URL; no Q-P, Doll!

>Anyway, yours works too!
> 
Only sorta.  Firefox calls it a security risk.  "http"?

-- 
gil

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

Re: "The Computers Nobody Wanted"

[Phil Smith III]

? My link worked fine as sent, both at my end and in Gmail. Gil, your client
seems to be breaking QPed lines?! Anyway, yours works too!


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

Re: "The Computers Nobody Wanted"

[Paul Gilmartin]

On Thu, 14 Apr 2022 16:59:46 -0400, Phil Smith III  wrote:

>http://worrydream.com/refs/Strassmann%20-%20The%20Computers%20Nobody%20Wante
>d.pdf
>
ITYM 
.

-- 
gil

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

"The Computers Nobody Wanted"

[Phil Smith III]

http://worrydream.com/refs/Strassmann%20-%20The%20Computers%20Nobody%20Wante
d.pdf

 

This is sort of interesting, starting at bottom of PDF page 10, "The IBM 360
Promises". A different view on the 360 from the one we grew up with; reality
is presumably somewhere in the middle.

 

(And how did I come across this, I hear you cry? Looking to refresh my
memory on the Xerox model that my dad had bought, on which I learned PL/C,
in 1975. Because "PLC" keeps coming up, though the latest occurrence was
this one: https://en.wikipedia.org/wiki/Programmable_logic_controller )

 

And yes, that's an http link, not https. Not my site, sorry.


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

Re: dequeue program

[Dave Jousma]

On Thu, 14 Apr 2022 16:30:49 +, Steely.Mark  
wrote:

>There was a program that when executed would prevent the ENQ on a dataset. 
>This was used for jobs which would FTP a file and then use that file in steps 
>after the FTP.
>
>This was the JCL used:
>
>//JS010   EXEC PGM=FTPDEQ,
>//PARM='data.set.name.here'
>//SYSUDUMP DD SYSOUT=*
>
>This would be the first step in the job.
>
>Any one remember this program and  would share a copy of it ?
>

There is/was a program on CBTTAPE called BYPASSNQ that I used to use a long 
time ago before IBM built in the ability to bypass enqueue in ISPF when coding 
a volser.   you pass it the program you want to call as the PARM.

//GO  EXEC PGM=BYPASSNQ,PARM=IEHPROGM   
//STEPLIB  DD DISP=SHR,DSN=YOUR.LOADLIB 
//SYSPRINT DD SYSOUT=*  
//DD1  DD UNIT=3390,VOL=SER=TGT10A,DISP=OLD 
//ABNLTERM DD SYSOUT=*  
//SYSUDUMP DD SYSOUT=*  
//SYSIN DD *
 SCRATCH DSNAME=SYS1.SIOALMOD,VOL=3390=TGT10A   
/*

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

Re: dequeue program

[Seymour J Metz]

IYM that the program dynamically allocated the dataset with a disposition of 
SHR.

It is possible to prevent the ENQ for a started task with an entry in the 
program properties table (PPT), but that is not done by the program.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steely.Mark [steely.m...@aaa-texas.com]
Sent: Thursday, April 14, 2022 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: dequeue program

There was a program that when executed would prevent the ENQ on a dataset. This 
was used for jobs which would FTP a file and then use that file in steps after 
the FTP.

This was the JCL used:

//JS010   EXEC PGM=FTPDEQ,
//PARM='data.set.name.here'
//SYSUDUMP DD SYSOUT=*

This would be the first step in the job.

Any one remember this program and  would share a copy of it ?

Than You

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

dequeue program

[Steely.Mark]

There was a program that when executed would prevent the ENQ on a dataset. This 
was used for jobs which would FTP a file and then use that file in steps after 
the FTP.

This was the JCL used:

//JS010   EXEC PGM=FTPDEQ,
//PARM='data.set.name.here'
//SYSUDUMP DD SYSOUT=*

This would be the first step in the job.

Any one remember this program and  would share a copy of it ?

Than You

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

Re: Reliable source for OCO?

[Seymour J Metz]

The best way to address potentially transient URLs in wiki may be to quote the 
relevant text as part of the citation. If I could find a reliable online 
secondary source, that would be better due to wiki's prejudice against primary 
sources.

Back when they were still available, I used to read the logic manuals for 
things that should have been in the reference manuals, and I used to read the 
code for things that should have been in the logic manuals.

I still remember when IBM rewrote some logic manuals as HIPO manuals that were 
missing what the letters satood for, and the appalling VSFORTRAN documentation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Thursday, April 14, 2022 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reliable source for OCO?

On Thu, 14 Apr 2022 at 07:37, Seymour J Metz  wrote:

> I'm editing the wikipedia [[Operating system]] article, and another editor 
> has challenged the sentence "The logic manuals for their contemporary 
> descendants, z/VM, z/VSE and z/VM, are not available to the general public."
> What are the relevant URLs for IBM's policy? Thanks.

The OCO (or more subtle) status of current software is in the
announcement letters. Using IBM URLs as a reference is a bit of a
trap, because IBM so frequently removes and rearranges things, and
seems to have a global robots.txt that prohibits pretty much
everything.

It's not obvious to me that the existence of published logic manuals
aligns with the OCO status of a product. IIRC many products that were
not OCO have still had logic manuals withdrawn in favour of
"diagnostic guides" and the like. At the same time some of those
diagnostic books are remarkably detailed, and the logic is described
or can be inferred even though the source code is not available.

I also seem to remember some discussion of this on this very list,
including the definitions of terms like "restricted materials of IBM",
"object code only", and so on. I'm not finding them in a quick search,
but one thing that did come up is a 2018 post from Gabe Goldberg, who
said he had "my OCO file -- a decade or so worth of material
documenting IBM's folly removing source code ("Object Code Only" for
those who didn't live through it). " Might be worth contacting him.
I'm not sure he's still active on this list, but g...@gabegold.com
looks to be current.

Tony H.

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

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

Re: Reliable source for OCO?

[Seymour J Metz]

That might be reasonable in a different context, but wiki has rules about 
verifiability. Worse, they consider secondary sources more reliable than 
primary sources, which to anybody with exposure to Academia seems insane.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, April 14, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reliable source for OCO?

Seymour,

He is asking you to prove a negative. Call him on it.

Tony Thigpen

Seymour J Metz wrote on 4/14/22 07:37:
> I'm editing the wikipedia [[Operating system]] article, and another editor 
> has challenged the sentence "The logic manuals for their contemporary 
> descendants, z/VM, z/VSE and z/VM, are not available to the general public." 
> What are the relevant URLs for IBM's policy? Thanks.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Reliable source for OCO?

[Tony Thigpen]

Seymour,

He is asking you to prove a negative. Call him on it.

Tony Thigpen

Seymour J Metz wrote on 4/14/22 07:37:

I'm editing the wikipedia [[Operating system]] article, and another editor has challenged 
the sentence "The logic manuals for their contemporary descendants, z/VM, z/VSE and 
z/VM, are not available to the general public." What are the relevant URLs for IBM's 
policy? Thanks.



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

--
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: Reliable source for OCO?

[Tony Harminc]

On Thu, 14 Apr 2022 at 07:37, Seymour J Metz  wrote:

> I'm editing the wikipedia [[Operating system]] article, and another editor 
> has challenged the sentence "The logic manuals for their contemporary 
> descendants, z/VM, z/VSE and z/VM, are not available to the general public."
> What are the relevant URLs for IBM's policy? Thanks.

The OCO (or more subtle) status of current software is in the
announcement letters. Using IBM URLs as a reference is a bit of a
trap, because IBM so frequently removes and rearranges things, and
seems to have a global robots.txt that prohibits pretty much
everything.

It's not obvious to me that the existence of published logic manuals
aligns with the OCO status of a product. IIRC many products that were
not OCO have still had logic manuals withdrawn in favour of
"diagnostic guides" and the like. At the same time some of those
diagnostic books are remarkably detailed, and the logic is described
or can be inferred even though the source code is not available.

I also seem to remember some discussion of this on this very list,
including the definitions of terms like "restricted materials of IBM",
"object code only", and so on. I'm not finding them in a quick search,
but one thing that did come up is a 2018 post from Gabe Goldberg, who
said he had "my OCO file -- a decade or so worth of material
documenting IBM's folly removing source code ("Object Code Only" for
those who didn't live through it). " Might be worth contacting him.
I'm not sure he's still active on this list, but g...@gabegold.com
looks to be current.

Tony H.

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

Re: System Proclibs, Member management

[Farley, Peter x23353]

I recently had to do a similar research function like this one, I found you 
have to use whatever data you can glean from your batch scheduler (at a 
minimum), and even then you can miss PROC's used by STC's started at IPL rather 
than by a scheduler as well as "on demand" jobs requested outside of the 
scheduler.

SORT JOINKEYS is your very good friend for this effort.

Use your SCLM to identify which PROC's are used by which jobs (the XREF product 
from DCMS, Inc. [https:// www.dcmsi.com] does an excellent job at that task), 
match the job names against the scheduled jobs list and if there are no matches 
then try to find who last touched the PROC in your SCLM and ask that person / 
team tell you if it is obsolete or not.

It doesn't cover 100% of cases but it will catch most of them.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Thursday, April 14, 2022 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System Proclibs, Member management

EXTERNAL EMAIL

Prolly wandering somewhat off topic...

Lionel sez;

"but if you do it under an official change control process at least 
you've documented what you're doing and received official approval for 
doing it."

At a former shop that was the only way application proclibs and jcl 
members were added updated and deleted, using CA-LIBRARIAN and their 
CCF, still not 100% because you are still relying  on the applications 
programmers to manage the PROC's and JCL but it was much more manageable 
and easy to restore back, the ownership of the process then was the 
change management team, something nowadays has gone the way of the dinosaur

Carmen

On 4/14/2022 9:47 AM, Lionel B. Dyck wrote:
> There is always the approach of making a copy and then deleting - or just 
> renaming suspect members and waiting for the fallout.
>
> This can be dangerous but if you do it under an official change control 
> process at least you've documented what you're doing and received official 
> approval for doing it.  Is it worth the effort - only if you really need to 
> recover the disk space, which is doubtful at this point in time.
>
> Plus these old/obsolete elements may prove useful, if only as examples to 
> work from at some point.
>
>
> Lionel B. Dyck <><
> Website:https://urldefense.com/v3/__https://www.lbdsoftware.com__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!agrnuavPffXJPLatRvFxIDSsMzsN5ua6ra97mWgAxdtXTQWFPs7lF6C-zcovTZ_vHt2weA$
>  
> Github:https://urldefense.com/v3/__https://github.com/lbdyck__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!agrnuavPffXJPLatRvFxIDSsMzsN5ua6ra97mWgAxdtXTQWFPs7lF6C-zcovTZ_C2xcklA$
>  
>
> “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 
> Radoslaw Skorupka
> Sent: Thursday, April 14, 2022 09:38 AM
> To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: System Proclibs, Member management
>
> My humble opinion: NO. No way.
> I have seen discussion about tracking library access, hopefully at member 
> level.
> So what?
> Let's imagine member ABC has not been touched for 5 months.
> Can you delete it?
> No, you are not sure about half-year or once-a-year processes.
>
> Of course, detailed report of recently read members allows you to eliminate 
> majority (or minority?) of members in the library.
> However the rest has to be manually checked. And this is less technical, more 
> organizational task. You have to find an owner or at least a person who knows 
> anything about given member and talk to him.
>
> My €0.02
>
>
> BTW: I have found a member dated on 1981 recently. Fortunately I'm pretty 
> sure it is just a piece of junk nowadays.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
> W dniu 12.04.2022 o 16:41, Mark Jacobs pisze:
>> Does anyone do this in other than a manual method? Deletion of obsolete 
>> members and like things. If so, can you share your methods?
>> Mark Jacobs
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>
>
-- 
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/

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

This message and any attachments are intended only 

Re: System Proclibs, Member management

[Carmen Vitullo]

Prolly wandering somewhat off topic...

Lionel sez;

"but if you do it under an official change control process at least 
you've documented what you're doing and received official approval for 
doing it."


At a former shop that was the only way application proclibs and jcl 
members were added updated and deleted, using CA-LIBRARIAN and their 
CCF, still not 100% because you are still relying  on the applications 
programmers to manage the PROC's and JCL but it was much more manageable 
and easy to restore back, the ownership of the process then was the 
change management team, something nowadays has gone the way of the dinosaur


Carmen

On 4/14/2022 9:47 AM, Lionel B. Dyck wrote:

There is always the approach of making a copy and then deleting - or just 
renaming suspect members and waiting for the fallout.

This can be dangerous but if you do it under an official change control process 
at least you've documented what you're doing and received official approval for 
doing it.  Is it worth the effort - only if you really need to recover the disk 
space, which is doubtful at this point in time.

Plus these old/obsolete elements may prove useful, if only as examples to work 
from at some point.


Lionel B. Dyck <><
Website:https://www.lbdsoftware.com
Github:https://github.com/lbdyck

“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 
Radoslaw Skorupka
Sent: Thursday, April 14, 2022 09:38 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System Proclibs, Member management

My humble opinion: NO. No way.
I have seen discussion about tracking library access, hopefully at member level.
So what?
Let's imagine member ABC has not been touched for 5 months.
Can you delete it?
No, you are not sure about half-year or once-a-year processes.

Of course, detailed report of recently read members allows you to eliminate 
majority (or minority?) of members in the library.
However the rest has to be manually checked. And this is less technical, more 
organizational task. You have to find an owner or at least a person who knows 
anything about given member and talk to him.

My €0.02


BTW: I have found a member dated on 1981 recently. Fortunately I'm pretty sure 
it is just a piece of junk nowadays.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 12.04.2022 o 16:41, Mark Jacobs pisze:

Does anyone do this in other than a manual method? Deletion of obsolete members 
and like things. If so, can you share your methods?
Mark Jacobs

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

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



--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: System Proclibs, Member management

[Lionel B. Dyck]

There is always the approach of making a copy and then deleting - or just 
renaming suspect members and waiting for the fallout.

This can be dangerous but if you do it under an official change control process 
at least you've documented what you're doing and received official approval for 
doing it.  Is it worth the effort - only if you really need to recover the disk 
space, which is doubtful at this point in time.

Plus these old/obsolete elements may prove useful, if only as examples to work 
from at some point.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“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 
Radoslaw Skorupka
Sent: Thursday, April 14, 2022 09:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System Proclibs, Member management

My humble opinion: NO. No way.
I have seen discussion about tracking library access, hopefully at member level.
So what?
Let's imagine member ABC has not been touched for 5 months.
Can you delete it?
No, you are not sure about half-year or once-a-year processes.

Of course, detailed report of recently read members allows you to eliminate 
majority (or minority?) of members in the library.
However the rest has to be manually checked. And this is less technical, more 
organizational task. You have to find an owner or at least a person who knows 
anything about given member and talk to him.

My €0.02


BTW: I have found a member dated on 1981 recently. Fortunately I'm pretty sure 
it is just a piece of junk nowadays.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 12.04.2022 o 16:41, Mark Jacobs pisze:
> Does anyone do this in other than a manual method? Deletion of obsolete 
> members and like things. If so, can you share your methods?
> Mark Jacobs

--
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: System Proclibs, Member management

[Radoslaw Skorupka]

My humble opinion: NO. No way.
I have seen discussion about tracking library access, hopefully at 
member level.

So what?
Let's imagine member ABC has not been touched for 5 months.
Can you delete it?
No, you are not sure about half-year or once-a-year processes.

Of course, detailed report of recently read members allows you to 
eliminate majority (or minority?) of members in the library.
However the rest has to be manually checked. And this is less technical, 
more organizational task. You have to find an owner or at least a person 
who knows anything about given member and talk to him.


My €0.02


BTW: I have found a member dated on 1981 recently. Fortunately I'm 
pretty sure it is just a piece of junk nowadays.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 12.04.2022 o 16:41, Mark Jacobs pisze:

Does anyone do this in other than a manual method? Deletion of obsolete members 
and like things. If so, can you share your methods?
Mark Jacobs


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

Re: View ASCII Command inUSS

[Paul Gilmartin]

On Thu, 14 Apr 2022 12:59:35 +, Seymour J Metz wrote:

>Yes and no. Special files are kernel facilities. The shell recognizes "|" as a 
>pipe request, creates the special file and file descriptors. The communication 
>between the processes does not involve the shell.
> 
I wonder whether:
iconv -f ISO8859-1 -t IBM-1047 trace_large.log | 
{ chtag -vr /dev/fd/0; head; }
would provide additional information or change the behavior?


>>> On Tue, 12 Apr 2022 13:00:30 -0500, Michael Babcock wrote:
>>>
 I had to add the -B to prevent �head� from doing autoconvert on the file.

 -bash-4.3# iconv -f ISO8859-1 -t IBM-1047 trace_large.log | head -B
 

-- 
gil

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

Re: z16 documentation discrepancy

[Radoslaw Skorupka]

Yes, CFCC is another case for discrepancies in documentation. I just 
pointed few of them, it wasn't complete list.

And to be clear - I complaining about documentation, not limitations.
I'm perfectly OK with statements like:
"CF LPAR can be up to 16TB, but current CFCC will not use more than 3TB."
or
"General LPAR can be up to 32TB, but z/VSE will not use more than 32GB 
and will not work on LPAR >128GB".

What I don't like is discrepancy or false information in the documentation.

BTW: I don't intend to require 16TB for program RM (residency mode). :-)

--
Radoslaw Skorupka
Lodz, Poland



W dniu 11.04.2022 o 21:25, Martin Packer pisze:

I’m not sure if this is a metathread about consistency or not  but let me 
assume not.

With z/OS 2.5 you can go above 4TB – up to 16TB – but only with 2GB pages. And 
these aren’t your ordinary run of the mill pages. Think Db2 BPs, Java Heap, 
zCX. (We talked about this – Marna and I in the last episode of our podcast.) 

One limit you didn’t mention – but I found of interest recently – is CFCC. I’m 
told the limit for that is 3TB. (Customer was at 2TB and could use more – so 
this was not academic.)

Hoping this helps.

Martin Packer, Senior Performance, Capacity, Architecture Specialist

IBM Technology, Worldwide

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: 
https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA


From: IBM Mainframe Discussion List  on behalf of Radoslaw 
Skorupka 
Date: Monday, 11 April 2022 at 20:06
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] z16 documentation discrepancy
Actually it is not z16 specific, similar discrepancies could be observed
for previous generations.

I mean memory limits for given LPAR modes (General, CF, z/VM, Linux
Only) and operating systems.
Example: PR/SM Planning says z/OS 2.5 is limited to 4TB, while it was
announced the limit was increased to 16TB.
PR/SM says z/TPF is limited to 1TB, while Redbook z16 Tech. Guide says
it is 4TB.
According to PR/SM Planning Linux is limited to 1TB.
There are cases where one can find "different versions of truth" within
single book.
Similiar discrepancies can be found in regard of limit of processors.


Fine print note: Memory limit for LPAR in General mode is increased to
32TB which is more than z/OS can support, but this is not discrepancy,
here we have two different limits. Same scenario in z15 and z/OS 2.4 -
LPAR 16TB, OS 4TB.
In the paragraph above I'm talking about different answers for same
question.

--



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

Re: View ASCII Command inUSS

[Seymour J Metz]

Yes and no. Special files are kernel facilities. The shell recognizes "|" as a 
pipe request, creates the special file and file descriptors. The communication 
between the processes does not involve the shell.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, April 13, 2022 9:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: View ASCII Command inUSS

On Thu, 14 Apr 2022 08:46:50 +0800, David Crayford wrote:
>>>
>> Can the behavior be replicated with /bin/sh?
>
>Worth a try.
>
Indeed.  If the same bug exists in both shells Rocket is likely
to fix it sooner than IBM.

>The fact that it's using pipe operators implies the shell is in play.
>
I *believe* pipe is a kernel facility which shell invokes with C RTL
calls (pipe(); fork(); exec(); dup2; ... ).  Shell doesn't actually move
the data.  But there's plenty wiggle room in the options shell
supplies to those C RTL calls: it might be able to enable/disable
autoconversion or tag the descriptors with CCSIDs (incorrectly?)

An IBM expert averred long ago on MVS-OE that the actual
conversion is performed by kernel.

>As I said, I would take this to Rockets forum which is a more appropriate
>place to discuss bash.
>
>> But does bash supply unsolicited arguments to utilities?
>>
>> Appendix L describes too many knobs and levers.


>> On Tue, 12 Apr 2022 13:00:30 -0500, Michael Babcock wrote:
>>
>>> I had to add the -B to prevent “head” from doing autoconvert on the file.
>>>
>>> -bash-4.3# iconv -f ISO8859-1 -t IBM-1047 trace_large.log | head -B
>>> 

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

Reliable source for OCO?

[Seymour J Metz]

I'm editing the wikipedia [[Operating system]] article, and another editor has 
challenged the sentence "The logic manuals for their contemporary descendants, 
z/VM, z/VSE and z/VM, are not available to the general public." What are the 
relevant URLs for IBM's policy? Thanks.



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

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