Re: World’s largest computer outage!

[Leonard D Woren]

Paul Gilmartin wrote on 7/21/2024 10:07 AM:
But these things happen. I heard of a product that crashed 
reproducibly at customer sites having 8 or more tape drives.

Who does that in a test lab!>


This comes down to a problem with making sufficient resources 
available to developers and testers.  My sandbox system is a 4-way 
sysplex under VM.  There was an issue which looked like a bug but 
turned out to be an early design shortcoming from prior to my taking 
over that part of the product.  Some customers hit it on large systems 
but no matter how much I ran the tests on my sandbox, I could not 
trigger the problem.  Finally I got permission to try it on some other 
product's 7-way real LPAR system, and the problem hit on my first 
try.  And second try.  And third try.  So I was finally able to figure 
it out and fix the Day-0 design issue once I had sufficient resources 
available to encounter the problem.


Back when the model 3 IBM 3800 paper eater (*), er, high-speed laser 
printer, came out (1983 give or take), we got one, did the IOCP 
update, connected it up, fired it up and JES2 abended S0C4. Reliably 
if I recall.  I ended up in direct communication with the IBM 
developer who wrote the code.  He sent me an APAR fix and said "try 
this and let me know if works."  Me: "Didn't you test it?" Him: "No, I 
don't have a 3800-3 on my VM system."  The bug turned out to be that 
he didn't take into account that the -3 had longer sense data than the 
-1, so when JES2 did a SENSE to the -3, it overlaid a few bytes of 
some other critical JES2 data.  If the developer had had an actual 
3800-3, he would have tripped over this very early on.


I rest my case.

(*) The 3800 moved the continuous form paper at 8 feet per second. 
Astounding opportunity for paper cuts if you ignored the warning to 
not run it with the cover open.


None of the above in any way justifies Clownstrike's shoddy code 
getting distributed.  I hope they get sued out of business.


/Leonard


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

Re: World’s largest computer outing!

[Leonard D Woren]

(Multiple replies included.)

Rick Troth wrote on 7/19/2024 6:56 AM:

Somehow a name like "Crowdstrike" seems fitting.


Yeah, but this was Strike 3.  Seems that Crowdstrike sent out a bad 
update in 2009, and another bad update a year ago.  Quality control 
must be non-existent.  I hope they go out of business.  My employer 
had to get many additional people on the internal help desk to work on 
getting all employees back up.  The problem was compounded by other 
layers of paranoia, er, security.  (OTOH, it's extremely unlikely that 
my company will ever be hacked.)


Ultimately, the only reason that Windoze gets blame for this is that 
it's STILL just a big collection of bugs and security holes and 
because the core design is so flawed, it can't be fixed, so stuff like 
Crowdstrike gets installed to protect against bad actors.


Wayne Bickerdike wrote on 7/19/2024 1:46 PM:

Some kind of false economy to make the PC the entire tool of choice for
certain routine tasks.


PCs aren't the problem, Windoze is the problem.  If there weren't so 
many holes, there wouldn't need to be a continuous stream of new 
(newly discovered) holes needing to be fixed.


It's multiple orders of magnitude easier to fix one mainframe that's 
down than thousands of Windoze PCs.  Apparently every user with a 
bricked PC had to call the help desk and get a code and instructions 
for repairing their PC, because there was no way to push the fix out 
to everyone.  (And of course, we couldn't read our work email to find 
out what was going on or how to fix it!)  Some people never learn -- 
this reminds me of the Internet Worm from 1988, which I think (don't 
remember for sure) required staff to go visit all 2000 Sun 
workstations on campus to fix the Worm damage which had been rdist'd 
out, and which broke rdist so it could not be centrally remedied.  
https://en.wikipedia.org/wiki/Morris_worm  The 6000 number quoted 
there can't be right; the true number had to be much much higher since 
just one university had essentially all of its thousands of 
workstations hit.


This is why most things under my control are set to "download updates 
and ask to install."  So they're not installed bleeding edge time, and 
hopefully I'll hear about any disastrously bad update before I click 
Install.


Imagine how big the disaster would have been if it was z/OS 
auto-installing updates as soon as some random poor-QA company makes a 
bad fix available for silent automatic install.


/Leonard


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

Re: TSO ALLOC with/wo unit

[Leonard D Woren]

Specifying VOLUME more or less always requires specification of UNIT.  
Ignoring SMS altering the historic behavior, there is a "default 
unitname" associated with each userid.  For ALLOC VOL to work without 
UNIT, the VOL specified must be within the set of devices covered by 
that default unitname.


I think it doesn't matter that it's an existing data set.

Why are you specifying VOL for an existing data set???

/Leonard


Itschak Mugzach wrote on 3/20/2024 1:28 AM:

GAdi,

Does this rule apply to existing datasets? The allocation request was for
existing datasets not new.

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Wed, Mar 20, 2024 at 9:17 AM Gadi Ben-Avi  wrote:


As far as I know, If you do not specify a UNIT Type, it will look for
volumes that are STORAGE.
If there aren't any, the allocation will fail.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of ITschak Mugzach
Sent: יום ד 20 מרץ 2024 08:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSO ALLOC with/wo unit

[Some people who received this message don't often get email from
05a7ced721d8-dmarc-requ...@listserv.ua.edu. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]

I have a program in Rexx that allocates a dataset using dsname and volume
serial (1) . it works well in my shop but requires a unit type (2) in
another shop. Actually the error is msg "IKJ56241I SPECIFIED UNIT IS
UNDEFINED".
Why does 1 work here and fails in another shop?

1. ALLOC F(XXX) DA('dsname') VOLUME(volser)
2. ALLOC F(XXX) DA('dsname') VOLUME(volser) UNIT(390)

ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

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

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


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



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

Re: OT-ish: Very old IBM hardware & manuals available

[Leonard D Woren]

I'm pretty sure that the thing I saw was significantly older than 
650.  The bits were so big that they were using an oscilloscope to see 
them.  I don't recall if they said what machine that drum connected 
to.  I had gone there for some big deal event and it was very crowded.


Anyway, it's worth checking with CHM for interest in any old but 
historically significant hardware.


/Leonard

Seymour J Metz wrote on 1/25/2024 5:55 AM:

I started on a 650, and that had a 2,000 word drum. The 305, before my time, 
had a 2400 character drum. I'm not aware of any IBM drum smaller than that.

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


From: IBM Mainframe Discussion List  on behalf of Leonard D 
Woren 
Sent: Thursday, January 25, 2024 12:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT-ish: Very old IBM hardware & manuals available

Maybe contact the Computer History Museum https://computerhistory.org/
.  They probably have the resources to ship anything they're
interested in.

Their collection includes IBM hardware that predates any of us having
seen a digital computer.  It's been quite a while since I was there,
but they were working on fixing up an IBM drum storage device which I
think was the size of beer keg and held something like 550 bytes, no
typo, or maybe it was a few kbytes.

/Leonard


Robert Prins wrote on 1/23/2024 7:57 AM:

Hi all,

My father worked for IBM in the Netherlands for more than 30 years,
starting as a CE in the late 1950'ies. Last year he was diagnosed with
Alzheimer, and over the past few months my siblings and me have been
emptying his apartment and storage room, and we've come across a sizeable
quantity of IBM "stuff", from manuals for the 650 to old square cm
"integrated circuits" and even a magnetic core memory card. My siblings
weren't in the least interested in any of it, so I took it, and although
it's nice to look at, our house is already full enough as it is, so...

If anyone thinks they can offer a good home to these things, and I will,
hopefully soon, put pictures of everything that surfaces on my website,
feel free to contact me off this list and we can take it from there. You'll
most definitely be paying for shipping (from Lithuania), and based on what
I'm going to find out on fleabay, I might ask for a bit more.

Robert


--
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: OT-ish: Very old IBM hardware & manuals available

[Leonard D Woren]

Maybe contact the Computer History Museum https://computerhistory.org/ 
.  They probably have the resources to ship anything they're 
interested in.


Their collection includes IBM hardware that predates any of us having 
seen a digital computer.  It's been quite a while since I was there, 
but they were working on fixing up an IBM drum storage device which I 
think was the size of beer keg and held something like 550 bytes, no 
typo, or maybe it was a few kbytes.


/Leonard


Robert Prins wrote on 1/23/2024 7:57 AM:

Hi all,

My father worked for IBM in the Netherlands for more than 30 years,
starting as a CE in the late 1950'ies. Last year he was diagnosed with
Alzheimer, and over the past few months my siblings and me have been
emptying his apartment and storage room, and we've come across a sizeable
quantity of IBM "stuff", from manuals for the 650 to old square cm
"integrated circuits" and even a magnetic core memory card. My siblings
weren't in the least interested in any of it, so I took it, and although
it's nice to look at, our house is already full enough as it is, so...

If anyone thinks they can offer a good home to these things, and I will,
hopefully soon, put pictures of everything that surfaces on my website,
feel free to contact me off this list and we can take it from there. You'll
most definitely be paying for shipping (from Lithuania), and based on what
I'm going to find out on fleabay, I might ask for a bit more.

Robert



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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Leonard D Woren]

OK.  So we've established that the key is set via software.

Software can be hacked.

And now there's only a single spit of data to focus all the effort 
on.  Years ago at a SHARE presentation, I caught an IBMer after the 
session and they admitted that I was correct.


/Leonard

P.S.  Someone has to know all the security officers in order to 
contact them when necessary to input the keys.



Radoslaw Skorupka wrote on 1/15/2024 6:44 AM:

It is being done everytime you buy new machine and use ICSF.
TKE can be used for that, but even without it is feasible and 
secure. ...and secure. :-)

1. Master key is divided into parts. How many? 2 or more.
2. Each part is know to only one security officer. Note, the 
officers need not to know each other. That's information security - 
no single person can disclose the key. No one knows the key.
3. Every officer is "duplicated" by another person. That's data 
security - lost key part is not a problem, because we have another 
copy of the part.


So, let's assuming 2 key parts and three copies we have 6 persons 
and 6 safes to keep the parts.






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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Leonard D Woren]

There has to be a way to set it via software.  What happens when you 
replace the machine including the hardware where the master key is stored?


How is the key set into the disaster recovery machine?

/Leonard

Jousma, David wrote on 1/14/2024 4:50 PM:

Pretty hard to mess up the master key, since it only lives in the crypto 
hardware.

That's the other thing though.  Sounds like the OP wants to encrypt everything 
with the same HLQ, with the same key  that's a big exposure if the key gets 
accidentally deleted.  Not sure what the rule of thumb is either, as one key 
per dataset turns into a key management nightmare.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of Leonard D 
Woren 
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE 
format)?

(I read the whole thread before starting this reply. ) Steve Estle wrote on 1/13/2024 8: 
28 AM: > [. . . ] > My true reason for composing this is that we've discovered the 
inability to encrypt load libraries - even in PDSE format. [. . . ] >


(I read the whole thread before starting this reply.)

Steve Estle wrote on 1/13/2024 8:28 AM:

[...]
My true reason for composing this is that we've discovered the inability to 
encrypt load libraries - even in PDSE format.

[...]

I know this seems innocuous, but we'd like to encrypt as much as possible in 
our environment and due to Top Secret deficiencies we have to encrypt at high 
level qualifier level (HLQ) (all or nothing under each HLQ unfortunately).  
Given we have load module libraries under many differ HLQ's this is posing 
difficulties in moving forward with our rollout when an HLQ does have one or 
more load module libraries as part of that HLQ.  You can only imagine the pain 
of renaming a load library given all the JCL, etc that is referencing that 
library name.

So, you have poor naming conventions and a poor security system, and
you want IBM to make difficult changes which will potentially affect
all customers negatively?


2. If I were to submit an IBM idea, can I count on this community for some 
backing here to help in upvoting such an idea submission?

I'd vote the highest value of "no".


An aside, since I didn't keep track of which comment mentioned this
(maybe it was on an old item cross-posted from RACF-L?).  For those
concerned about ransomware, z/OS encryption of all data at rest means
that a ransomware hacker need only mess up the master key so that no
data sets can be decrypted.  No need to waste time encrypting all
data, since it's already encrypted.


/Leonard


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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Leonard D Woren]

(I read the whole thread before starting this reply.)

Steve Estle wrote on 1/13/2024 8:28 AM:

[...]
My true reason for composing this is that we've discovered the inability to 
encrypt load libraries - even in PDSE format.

[...]

I know this seems innocuous, but we'd like to encrypt as much as possible in 
our environment and due to Top Secret deficiencies we have to encrypt at high 
level qualifier level (HLQ) (all or nothing under each HLQ unfortunately).  
Given we have load module libraries under many differ HLQ's this is posing 
difficulties in moving forward with our rollout when an HLQ does have one or 
more load module libraries as part of that HLQ.  You can only imagine the pain 
of renaming a load library given all the JCL, etc that is referencing that 
library name.


So, you have poor naming conventions and a poor security system, and 
you want IBM to make difficult changes which will potentially affect 
all customers negatively?



2. If I were to submit an IBM idea, can I count on this community for some 
backing here to help in upvoting such an idea submission?


I'd vote the highest value of "no".


An aside, since I didn't keep track of which comment mentioned this 
(maybe it was on an old item cross-posted from RACF-L?).  For those 
concerned about ransomware, z/OS encryption of all data at rest means 
that a ransomware hacker need only mess up the master key so that no 
data sets can be decrypted.  No need to waste time encrypting all 
data, since it's already encrypted.



/Leonard


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

Re: allowed characters in member name

[Leonard D Woren]

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


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



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



/Leonard




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

Re: Assembler optimization OPTION

[Leonard D Woren]

Seymour J Metz wrote on 12/10/2023 7:06 AM:

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.


Right.  I actually found at least one very old bug by using HLA option 
FLAG(PAGE0).  An annoyance though is that there are some IBM macros 
which get flagged, so you have to either temporarily turn off 
FLAG(PAGE0) around them, or in some case, simply insert USING PSA,0.



A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?


Which value of "new" are you using?  Our products are supported on all 
z/OS releases still supported by IBM, so I'm somewhat limited in what 
instruction set I can use.  Currently, z/OS 2.4 is still supported (I 
assume until 2024-09-30), and since z/OS 2.4 runs on z12, I can't go 
past ZS(6) instructions.  However, that turns out to be a LOT of nifty 
instructions.  I have eliminated nearly all 2 and 4 byte literals, 
among other improvements.


With the relative branch instructions and SYSSTATE ARCHLVL=2, there is 
no excuse for base registers for code.


Note that LARL was retrofitted back to S/390 hardware, so there is no 
excuse whatsoever for not using it.


I have a loop somewhere using about 20 registers.  Have fun with that.

/Leonard


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

Re: Kinda fun

[Leonard D Woren]

Bob Bridges wrote on 11/8/2023 7:00 AM:

Let's see, how many nanoseconds is that again?


The answer to that is as relevant today as it was 50 years ago with 
Bus and Tag cables:  The speed of light is very close to 1 foot per 
nanosecond.  So making computer chips smaller and smaller inherently 
increases the speed.  How much delay is that for a channel extender 
(whatever the tech is today) for your remote copy dasd that's many 
miles away across town?


/Leonard



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Allan Staller

In those days, the limit on bus/tag cables was 200 ft (cumulative). IIRC,
that particular block multiplexer was running about 190 ft.  De-installing
the 2503 saved about 125 ft.



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

Re: Kinda fun

[Leonard D Woren]

Bob Bridges wrote on 11/8/2023 6:56 AM:

Reminds me of an old tagline:

/* The more sophisticated the technology, the more vulnerable it is to 
primitive attack. People often overlook the obvious.  -Dr Who, 1978 */


Long ago I was told why my shop didn't carpet the tape storage area.  
Apparently some shop that did had a problem with unreadable tapes.  
Eventually they figured out that all the unreadable tapes were on the 
bottom row of the tape storage.  And the outside cleaning people used 
a vacuum cleaner...



Farley, Peter wrote on 11/8/2023 7:58 AM:

1401N1 printer (the big beast) raised its hood automatically when it ran out of 
paper, no way to turn off that behavior.  NEVER put your coffee cup on top of 
that printer!!


Supposedly the reason that IBM put that feature on the 1403 was some 
big shops had a lot of 1403s and it helped the operator find the 
printer that needed to be fed.  Unfortunately, the feature didn't have 
a failsafe.  It was common to stack boxes of paper behind the 
printer.  At least once at UCLA, someone had stacked it one box too 
high, and when the printer cover went up, the back end of the cover 
was blocked by the too-high stack, raising the printer off the floor.


And BTW, the 3211 had a "raise cover" CCW.  I had some fun with that, 
and one of the other IBM-MAIN readers probably remembers that, from 
Post 360.



On Wed, 8 Nov 2023 09:49:34 -0500, Rick Troth  wrote:


I've heard tales (probably at KTRU) of reading magnetic tape/cards 
with iron filings and a loupe. 


In high school, I watched a guy splice 1" reel-to-reel video tape and avoid the 
picture rolling by finding the sync marks with the above method and carefully 
cutting the tape right on the sync marks.



BTW, I still have around 12 or so boxes of 2000 blank 80 column 
cards.  That's about 500 years of shopping lists...



/Leonard


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

Re: SCHEDIRB

[Leonard D Woren]

Joseph Reichman wrote on 9/28/2023 5:25 PM:

I pointing to the first that would be IKJEFT01


Most of the time.  But not on _my_ typical TSO sessions.  And since 
I'm using an IBM program for this, other sites would also be using 
it.  If I remember when I'm working I'll go check where T01 is in the 
TCBs/RBs on my TSO sessions.



I can interrogate the FLAG bytes RBSTAB at +A to make sure it’s a PRB and
then look at RBCDE to make sure it points to IKJEFT01


What about a batch job using one of the various alternate entry points 
for IKJEFT01?



One more idea you said TSO does SVC screening which is why my LOAD abended


I would be astounded to find out that TSO does SVC screening.

However, if you're running under [bleah] TSO TEST / TESTAUTH, I'm 
pretty sure that TEST[AUTH] somehow has its hooks into LINK and LOAD, 
and probably deep enough into LOAD that it also gets ATTACH[X] and 
every other program-fetch-related function.



This code would probably stop my LOAD from abending


Anytime you ask for help with an abend you need to say what the abend 
code is, other it's just "my program didn't work" to which my standard 
answer is either "so?" or "my condolences".



/Leonard


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

Re: Why it's important to take Seymour's advice

[Leonard D Woren]

For address spaces known to always be non-swappable, how about ALESERV 
ADD and just load the returned ALET into an AR, then SACF 512?  My 
code that does that has never failed (yet).  What are the risks, other 
than the obvious one of the target A/S going away while the code is 
running?


Come to think of it, what happens to WORKUNIT entries if the target 
A/S goes away?  I expect S0C4 with some obscure reason code, when 
referencing an ALET for an A/S which went away.


/Leonard


Peter Relson wrote on 9/20/2023 7:30 AM:

Adam J wrote

Given the proper authorization, you can:

- Issue an AXSET, specifying a value of 1
- Issue an SSAR instruction identifying the target address space as the 
secondary address space
- Use MVCP / MVCS instructions to copy data between your primary address space 
and the secondary address space



While that is "true" (aside from the fact that SSAR would be rejected if this 
is a reusable ASID and would need to be SSAIR),
this is not something you should do. And your "connection" could break at any 
instant unless the target address space is both non-swappable and not memtermable.

Adam J wrote

There is also the technique of using the special ALET value of x'0001' and 
using AR mode to reference data from another address space.


That too is a bad idea unless you have addressability to this other space as your 
"secondary" address space (which typically would be after a space-switch PC to 
"you").

z/OS does not support the concept of "address space faults" (i.e., the program 
check you get when referencing storage in another address space when that address space 
is swapped out).  This is one of the reasons why cross-memory servers are required to be 
in non-swappable address spaces.

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



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

Re: TCP/IP to JES3

[Leonard D Woren]

I thought I had a cute idea, but trying it, there are 2 problems.
FTP 
SITE FILETYPE=JES
200 SITE command was accepted
SITE LRECL=133
200 SITE command was accepted
PUT test.ds(member)
EXA1701I >>> SITE FIXrecfm 133 LRECL=133 RECFM=FBA BLKSIZE=32718
200 SITE command was accepted
EXA1701I >>> STOR test.ds(member)
125 Sending Job to JES internal reader FIXrecfm 80
250-It is known to JES as JOBn
250 Transfer completed (data was truncated)

I edit out some ftp messages regarding passive mode, etc.

Well, that's annoying.
1.  I can't figure out how to get an LRECL other than 80.
2.  Probably can't suppress the JOB statement.
But here's the trick to go directly to SYSOUT, if you're satisfied 
with LRECL=80 and the JOB statement printing:

//jobname JOB TYPRUN=COPY
[data to print]
[...]

TYPRUN=COPY is probably a holdover from punch cards, where you could 
duplicate a card deck that way.



/Leonard

Schmitt, Michael wrote on 9/22/2023 1:59 PM:

Thanks, I overlooked the "interacting with JES topic".

Looks like you can GET (receive) sysout but not PUT.

I suppose a worst case solution would be to wrap the output in JCL, where the 
JCL executes code to build LRECL=133 lines from instream data and then copy 
that to SYSOUT.


We used to transfer files this way: run a job on system A, where the job takes 
the file and converts it into instream data, embeds it in a job it constructs, 
submits that job that routes to system B, where it executes and unloads the 
instream data back into a file. In fact, I still have the JCL for that trick 
using TSO XMIT as the conversion program, for sending data between systems that 
are only connected by JES (and you don't want to go to the remote system to 
receive the file.)

To top that, I think I have a job that finds and collects a file and all of its 
dependencies, converts that all into instream data, builds and routes a job to 
a remote system, where it runs a program, takes the output files from that 
program, converts all of that, puts it into a job, routes it back to the 
original system, where the jobs runs and converts the files back and saves them!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Friday, September 22, 2023 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCP/IP to JES3

Try FTP with filetype=jes

Lionel B. Dyck <
Website: http://www.lbdsoftware.com/
Sent from my iPhone 15 Pro

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


On Sep 22, 2023, at 3:26 PM, Schmitt, Michael  wrote:

Is there a way to transfer sysout type data from a remote, non-mainframe 
system, into a JES3 spool? From which already existing tasks will grab the 
output according to destination, class, writer, etc.

Such as, use some product or capability to connect and transfer to a TCP/IP 
port.

Most of what I see is going the other direction, answering the question of "how do I 
get this report from the JES spool to my printer/pc/file server/etc?" But I need to 
get it into JES3, because the existing report distribution software wants to grab it from 
there.

I thought I remembered being able to inject jobs into the IEFRDER via FTP, and 
thought perhaps could also transfer to sysout, but don't see it in the 
Communications Server manual.

Bonus points for a solution that will also work with JES2, after the inevitable 
end-of-support for JES3.

__
Michael Schmitt | DXC Apps Development | MassMutual
(737) 910-8248 | michael.schm...@dxc.com



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

Re: Is the IBM Assembler List still alive - Dumps - Early days

[Leonard D Woren]

Seymour J Metz wrote on 9/8/2023 5:29 AM:

I used SuperWylbur, but even in the free version you had associative ranges, 
which greatly simplified many editing tasks.


Doesn't current ISPF's regexp support let you do the same thing? Not 
that I've learned yet how to do that stuff...


Even before regexps, you could always use the ISPF hack "X ALL", "F 
ALL string", "C ALL NX oldstr newstr".  Which is probably why I 
haven't gotten around to learning regexps.



/Leonard


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

Re: Is the IBM Assembler List still alive - Dumps - Early days

[Leonard D Woren]

Steve Thompson wrote on 9/7/2023 7:24 PM:

You ever work with WYLBUR?


Yes, at RAND circa 1976 as a guest of an employee, and at Stanford, 
which is where I quickly grew to hate it.  Funny thing is, many of the 
other Stanford systems people started using TSO more as they saw what 
I could do with it.



Single address space,


Just like the rest that I listed.  So a failure, instead of taking out 
1 TSO user, takes out hundreds of users.  Wylbur's ability to recover 
user's work from its own page files was both a blessing and curse -- 
users didn't lose more than one screen interaction of work, but it 
could take a long time for Wylbur to restart as it did that recovery.



Had its own scripting language, so applications were written to run 
inside of Wylbur.


Yet another tally mark in the disadvantages column.


/Leonard


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

Re: Is the IBM Assembler List still alive - Dumps - Early days

[Leonard D Woren]

Bill Johnson wrote on 9/7/2023 1:05 PM:

We used to use ROSCOE at a small shop in the 80’s because it used less 
resources. I hated it.


ROSCOE was one of a collection of TSO alternatives, which were all 
junk.  TONE, ACEP, Wylbur, maybe more that I don't remember.  They all 
had 1 two-pronged design goal:  except for Wylbur, a PITA in its own 
category, allow TSO-like online use without the perceived overhead of 
TSO, and also, they would run on systems other than MVS.


The reason the resource utilization of all of those was lower than TSO 
is that it took longer for programmers to get their work done, so the 
resource utilization was spread out over more elapsed time, lowering 
the apparent resources used in a given elapsed time period, but also 
lowering productivity.  Something beancounters generally don't factor 
because they don't understand it.  They liked the fact that a given 
set of hardware could support 50 (choose your poison from above) 
online users while TSO could support only 25.


Fortunately, we're way past hardware costing more than people.


/Leonard


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

Re: Is the IBM Assembler List still alive - Dumps - Early days

[Leonard D Woren]

What was the first OS that you had a 2 MB TSO region?  What hardware.

MVT TSO on the 4 MB 360/91 at UCLA was about 3/4 MB .  There was a lot 
you could do, although it was slow.  I did experiment with overlay 
modules though.  Bleah.


The reason you could do a lot in 3/4 MB is that it was done in 
efficient languages, like Assembler.  None of these modern bloatware 
languages that make every app on my phone 32 MB minimum, and often up 
to 500 MB.


/Leonard


Seymour J Metz wrote on 9/7/2023 3:32 AM:

I never had TSO in less than 2 MiB; 768 KiB gives me shudders.


From: IBM Mainframe Discussion List  on behalf of Clem 
Clarke 
Sent: Wednesday, September 6, 2023 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is the IBM Assembler List still alive - Dumps - Early days


Running TSO in 3/4 of a meg was interesting.  And VERY slow.



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

Re: Simple request from chatGPT to write assembler program.

[Leonard D Woren]

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.  Or was that an enhancement 
in the new PL/I compiler?  Was that PLIX?  Yeah, not using stuff for 
decades can cause memory fade.



/Leonard


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

Re: Simple request from chatGPT to write assembler program.

[Leonard D Woren]

Bill Johnson wrote on 9/6/2023 6:27 AM:

[...]  AI is the future. [...]


FSV "future".  Who remembers the "Parry" program from the early 
1970s?  At SAIL, later renamed to SU-AI.  Oh, if you weren't on the 
ARPAnet circa 1973, you probably never saw Parry.  It was the first AI 
program I knew about.  I don't remember which famous computer science 
guy said this, but there haven't been and will never be any 
"significant breakthroughs" in AI -- all progress will be slow and 
incremental.  I say that recent apparent advances in AI are more due 
to faster cheaper computers and storage, and now the Internet, than to 
any new software tech.



/Leonard


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

Re: Is the IBM Assembler List still alive

[Leonard D Woren]

My interview for my first full-time job, at a big Savings and Loan in 
1979 (after the HR interview) with my to-be boss Les went like this:  
he picked up a thick post-bound continuous-form listing, opened it to 
a random spot, pointed to an assembler instruction and asked "what 
does this do?"  Did that 2 more times and his 4th question was "how 
much money do you want?"


That place was a zoo.  Two weeks later Les quit.  His boss calls all 
of the workgroup into his office, points to Les and says "now here we 
have a rat deserting a sinking ship."  He was half-right. It was a 
sinking ship.  I gave it 3 years but it survived 6 years.  Oh, and a 
few months later that manager was fired.


BTW, I don't remember too well now, 44 years later, but I think most 
of the application code was in assembler.  CICS macro-level was 
brand-new and we hadn't started using it yet, and under the covers, it 
was still assembler.  Sort of.


In those days, the Federal government tightly controlled account 
types, terms, interest rates, everything.  One day the company got 
authorization for a new account type.  A few days later we get a call 
that the new account type wasn't broken out separately on some 
report.  A group of us assembler programmers managed to find the 
source.  In DYL250, which none of us knew although I had a vague 
awareness of how DYL250 worked.  So with about 5 of them gathered 
around, I open up the source in what passed for an online editor.  We 
stared at it, decided to clone "this" line to "over there", "change 
this column to xyz", "no it has to be higher up", etc.  After a few 
minutes of this, I saved the updated source and ran it and it worked.  
From that I conclude that "a good programmer doesn't have to know 
what's doing."  I don't know Pascal, but I modified a Pascal program 
once.  (It was torture.) In my career, I've modified a few programs in 
languages that I don't know.  I'll stick with HLA, although I keep 
saying I need to learn Metal/C.


Assembler with a good Structured Programming Macros set is almost as 
good as C, probably better in a number of ways, at least if you have 
HLA watching over your shoulder.


/Leonard


Colin Paice wrote on 9/6/2023 12:54 AM:

I remember going to a customer to discuss a deep technical problem.  Before
they let us into the inner sanctum were given a dump and were asked "what's
the problem?" My colleague looked at it and said there is a program check
at this address, and this is fixed in ptf uy " come on in you've
passed" they said .  They said this weeded out non technical people



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

Re: Is the IBM Assembler List still alive

[Leonard D Woren]

It proves nothing, so your your conclusion is wrong.  You just don't 
know where the assembler programmers are working.  We're working for 
the software vendors that most companies pay lots of money to because 
they don't want to hire their own assembler programmers.  Fine with 
me, except that through consolidation, there are only a handful of 
larger ISVs now, employing thousands of assembler programmers.  And 
since we're the old guys, we don't need no Assembler List.  We have 
our own internal experts to consult with if necessary.


I use my personal email for these lists because I don't want my 
comments to be identified with my employer.  Most Fortune 500 
companies have one or another or a number of our software products.  
Based on the support cases that I see, I get the idea that the product 
I work on is at every national bank in the world.  My job title is 
"Senior Software Engineer", probably because the term "Systems 
Programmer" has been mis-used for a number of decades.  Most MVS/et al 
"Systems Programmers" are SMP/E jockeys and/or systems 
administrators.  Back when I was an SMP/E jockey, I still wrote 
Assembler because there are so many system interfaces that can't be 
called from any HLL, at least not without jumping through ridiculous 
hoops.  I broke a rib laughing when I saw one product purportedly 
written in Metal/C, where most of the program was inline assembler.  
But it made some manager happy to say that his new product was written 
in C.


The first IBM mainframe language that I learned was 360 assembler.  
The second was PL/I.  Because of that order of experience, I strongly 
claim that all programmers should learn assembler first, even if for 
the rest of their careers they'll only be writing in the HLL de jure, 
because it's important to understand that certain HLL constructs 
generate crappy machine code.  I once had to fix a PL/I program that 
was the slowest in its category in the department.  I looked at the 
generated code and groaned.  I changed a couple of lines in the 
program.  Each of those 2 changes cut the CPU utilization of the 
program in half, making it use 1/4 of the CPU time as before my 
changes.  I would not have been able to do that without understanding 
the generated assembler.


/Leonard


Bill Johnson wrote on 9/1/2023 7:43 AM:

Which proves my point from a prior thread that coding and using assembler is 
almost nonexistent.


Sent from Yahoo Mail for iPhone


On Friday, September 1, 2023, 10:39 AM, Steve Thompson  wrote:

Yes I have. It doesn't have a lot of traffic.

Steve Thompson

On 9/1/2023 10:28 AM, Robert Raicer wrote:

Hi folks;

It's been several months since I've received anything from
the IBM Assembler List Server.  The last I knew, the list server
e-mail address was: assembler-l...@listserv.uga.edu

Is this still correct?
Are any of you still getting e-mails from that list server?

Thanks for the help!

Bob Raicer

--

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

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




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



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

TECO (was Re: Has anyone)

[Leonard D Woren]

Bob Bridges wrote on 8/16/2023 8:23 AM:

Too many years ago; I don't remember.  And it isn't as if "unintuitive" is a
fatal error in editors or any other application; TECO (anyone ever use
that?) is a powerful editor - it was on the PDP platform as I recall - with
early automation features that I used extensively, and it was full of odd
uses for  and '$' and some other characters, but it did a good job -
once I was used to it.  But whatever this Unix editor was, a half hour
wasn't enough for me to learn much about it or get used to anything.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* People who can't distinguish between "etymology" and "entomology" bug me
in ways I cannot put into words.  -Tal Waterhouse */


IBM-MAIN relevancy:  ISPF EDIT still rules!  (But now I should learn 
regexps.)


I never tried TECO, after reading "Real Programmers Don't Use PASCAL" 
40 years ago.  Extract:


    Some of the concepts in these Xerox editors have been 
incorporated into

editors running on more reasonably named operating systems -- EMACS and VI
being two.  The problem with these editors is that Real Programmers 
consider
"what you see is what you get" to be just as bad a concept in Text 
Editors as
it is in women.  No the Real Programmer wants a "you asked for it, you 
got it"
text editor -- complicated, cryptic, powerful, unforgiving, dangerous. 
TECO, to

be precise.

    It has been observed that a TECO command sequence more closely
resembles transmission line noise than readable text [4].  One of the more
entertaining games to play with TECO is to type your name in as a 
command line

and try to guess what it does.  Just about any possible typing error while
talking with TECO will probably destroy your program, or even worse --
introduce subtle and mysterious bugs in a once working subroutine.


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

Re: XCFAS and TRUSTED

[Leonard D Woren]

Andrew Rowley wrote on 8/20/2023 4:40 PM:

On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote:

Secondly, when IBM states that a task should be given the attribute 
of Trusted, then I take it to mean that IBM is saying that the task 
can be trusted that this attribute cannot be the source of an 
exposure for that task.


I think when IBM says a task should be given trusted, it's a 
stronger statement than that.


I take it to mean that the task should never be denied access by the 
security system, and any denial of access risks the stability or 
operation of the system.



The endpoint of the last clause above is the inability to IPL the system.

My vague recollection from back when I was a senior systems programmer 
is that you set as TRUSTED any task which is necessary in order to get 
enough of the system up and running so that you can logon and fix 
problems.  If JES2 or VTAM or (long list) fails before you can logon, 
have fun fixing it.  This was before there was such a proliferation of 
system address spaces, but I figure the same applies.


Putting on my cynical hat (which I never really take off), TRUSTED is 
a way for the systems programmer to make it harder for an over-zealous 
security officer to break the system.



/Leonard


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

Re: Will z/OS be obsolete in 5 years?

[Leonard D Woren]

Jon Perryman wrote on 7/19/2023 8:00 PM:



Sysplex is the ability to tightly couple up to 32 z16 boxes.
I know what Sysplex is, and it is decades older than z16.
Sysplex is a software construct, not hardware, although certain hardware is 
required to implement it.


Sysplex is both software combined with hardware constructs. Shared dasd, 
coupling facilities and other hardware combined with various software 
components are required for sysplex.


At the moment, z/OS is the OS of choice for utilizing sysplex.

No. z/OS (and MVS before it) is the operating system that implements Sysplex.
It is not something implemented in hardware that z/OS utilizes.

.
Without required structures in the coupling facility, you can't have sysplex. 
You may not be aware of these structures but nonetheless they are a hardware 
requirement for sysplex.



Well then, what is my 4-image sandbox "sysplex", running under some 
z/VM (bleah) (in an LPAR... bleah), using 4 guests, using another z/VM 
guest as the "coupling facility"?  Sure feels like a sysplex (except 
that anything running under z/VM is visibly slower), and the CF VM 
guest sure seems to implement sysplex in software.  There are virtual 
paths defined from the 4 z/OS guests to the CF guest.  In this setup, 
where's the CF hardware claimed to be required for sysplex?


/Leonard

P.S.  z/OS won't be obsolete in 5 years, we just don't know what it 
will be called.



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

Re: Code Page for dataset names

[Leonard D Woren]

Paul Gilmartin wrote on 7/7/2023 9:34 AM:

On Fri, 7 Jul 2023 15:39:52 +, kekronbekron wrote:

I suppose... even if the char is different in different code pages, it is ok.
Don't we just need some special char that's available in all known & used code 
pages?


I extended Matt's test. The 3 national characters plus the 12 special characters
in the JCL Ref. have identical code points in 037, 500, and 1047.


Irrespective of the wording in the JCL manual, I think the way to look 
at is that there are those 3+12 code points which display the same on 
those code pages.  (If I'm understanding the discussion correctly.  
Too lazy now to go look at code pages.)  So MVS JCL doesn't care if a 
code point prints as $ in the US and prints as british money sign in 
some countries and maybe some other monetary indicator in other 
countries.  JCL just deals with that code point as a valid character 
in a data set name.


Are there code pages where the extra letters in a latin alphabet 
(beyond 26) are mapped to the code points which print as $#@ in the 
USA?  My vague recollection from long long ago is that the answer is yes.


/Leonard


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

Re: Code Page for dataset names

[Leonard D Woren]

Glenn Knickerbocker wrote on 7/5/2023 3:27 PM:
And then there's the weird one that wasn't on the standard 3270 
keyboard: x'c0' is valid in data set names (but not catalog entries, 
so it can only be used in uncataloged data sets) and member names. 
It's a left-bracket in some pages, [...] The JCL Reference specifies 
it at 
https://www.ibm.com/docs/en/zos/2.5.0?topic=definition-unqualified-name 
as "a character X'C0'", not by appearance at all.


That curly thing is a brace, not a bracket.  (Therefore, "Square 
bracket" is redundant.)


It's sort of a distant memory, but I'm nearly certain that pre-SMS you 
could catalog a data set with a X'C0' in the name, just not as the 
first character after a dot.  Trying it now on z/OS 2.5, with 
DISP=(NEW,CATLG),DSN=...BRACE{ and a non-SMS STORCLASS, it created the 
data set but didn't catalog it:  "NOT CATLG 9".  Seems that every few 
years IBM changes the way this works or doesn't.


/Leonard


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

Re: CS/CDS instruction

[Leonard D Woren]

If some particular instruction set feature is installed, the 
definition of ASI/AGSI is enhanced to serialize the update, making it 
a simpler solution than a CDS loop or PLO.


In some performance testing a while back on a z14 or z15 which I think 
had the above serialization feature, the execution times for a very 
large number of executions of L / AHI / ST were very close to the same 
count of ASI.  If I recall, the ASI was a few percent slower, I guess 
because of the serialization.  I.e., unless you're doing abnormal 
tests as I did, you won't notice the difference.


/Leonard


Seymour J Metz wrote on 3/1/2023 1:33 PM:

In addition to the obvious instructions Phil mentioned, there is also PLO. I 
don't have any relevant performance data.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Ituriel do Neto [03427ec2837d-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 1, 2023 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CS/CDS instruction

Hi all,

Is there a similar instruction to CS or CDS, but using 64 bits register ?

I have a double word that contains a counter and using 64 bits instructions
would be faster to increment this value than manipulate it with other storage
areas and an even-odd pair of 32 bits registers.

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

--
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: Ransomware in VSAM and DB2

[Leonard D Woren]

It's actually much more complex than that.  Here's a little-known 
story from a place I used to used to work some decades back.  This did 
not happen on an MVS system, but some other vendor's system with those 
letters in a different order.  One day that system crashed, I think 
for no apparent reason.  Rebooting it failed.  Apparently the system 
disk volume was corrupted.  They restored from a backup.  That backup 
was corrupted.  They tried backup after backup, going all the way back 
to the oldest backup they had, 5 months old.  It was corrupted. They 
had to rebuild the system from scratch.  Apparently a hacker with a 
lot of patience had gotten them.  They were very tight-lipped about 
what happened, even to data center staff, but the above leaked out to me.


The takeaway should be just because your backups appear to be 
successful, unless you regularly test restoring from backups, you 
really don't know that they're any good.  So even on MVS or z/OS or 
whatever it might happen to be called tomorrow, TEST THOSE BACKUPS.  
Even if they're "read-only".


One of my current employer's customers needed to restore a catalog 
from backup due to the catalog being broken.  Well, it was broken for 
much longer than they realized, and all of the backups (4 months 
worth) were incomplete due to that.  Nobody was looking at the backup 
job to ensure that it was successful.


At another place I worked in the dim past, the HSM SDSPs were backed 
up daily via REPRO to tape.  Do I really need to say it? The backups 
were all truncated due to a key sequence error in the SDSPs, but 
nobody was looking at the REPRO output.


/Leonard


Colin Paice wrote on 3/10/2023 12:27 AM:

Does it protect you from ransomware?  It gets you back to a good backup.
It depends on how often you backup - and having ransomware means  you might
lose all changes since the last backup  so unless the database is read only
- you are likely to lose  some data.

On Thu, 9 Mar 2023 at 23:44, Attila Fogarasi  wrote:


Also there are various solutions for immutable backups of z/OS data, which
would protect you against ransomware.


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

Re: How long for an experiened z/OS sysprog to come up to speed on a new environment?

[Leonard D Woren]

Eons ago, I tried out the RACF ISPF panels once.  Took me 10x as long 
to navigate to the panel as just typing the actual line command.  What 
those panels should do, but I don't know whether they do this or not, 
is display the line command as it's executed.


To this day I don't understand why experienced systems programmers and 
experienced security officers use the RACF ISPF panels.


That said, I will be writing ISPF panels to let coworkers use my 
personal productivity tools.



/Leonard

David Spiegel wrote on 2/21/2023 9:47 AM:

Hi Doug,
I consider relying on ISPF Panels *solely* negative, especially when 
SysProgs should learn the Command Line, in particular for RACF 
Commands. This is a sign of laziness.
I've also been in jobs where I maintained/added to ISPF Applications 
to e.g. create a z/OS Clone, where the user fills in the "from" and 
"to" DASD addresses and the ISPF application does the rest.
BTW, I am referring negatively to people who rely upon ISPF Panels 
*and* have never heard of CBT.

There is no need  to get offended.

Regards,
David

On 2023-02-21 12:13, Doug wrote:
So David, you consider using ISPF panels a net negative? I used to 
write dialogs for anything repetitive that I or anyone else had to do.
Never thought it was bad if  "people in charge are by-the-book 
mentality and I can imagine them using ISPF Panels for everything 
from RACF to SMP/e." Especially when I was the person in charge. 
And I knew what the CBT tape was and is


Doug Fuerst

-- Original Message --
From: "David Spiegel" <0468385049d1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@listserv.ua.edu
Sent: 21-Feb-23 6:09:15
Subject: Re: How long for an experiened z/OS sysprog to come up to 
speed on a new environment?



Hi Brian,
You said: "...so why would they question my use of anything I need 
in order to perform my job efficiently?  ..."
My answer is that the people in charge are by-the-book mentality 
and I can imagine them using ISPF Panels for everything from RACF 
to SMP/e.
(At one of my jobs, the MVS Team Lead said : "CBT??? ... never 
heard of it" (This guy has been an MVS Systems Programmer for more 
than 30 years.))
These same people eschew creativity in any form, because, they're 
scared due to ignorance.


Regards,
David

On 2023-02-21 00:31, Brian Westerman wrote:
I think that's a pretty invalid point. I don't see anyone 
questioning how to write an exit or install a new system, or use 
SMPe, so why would they question my use of anything I need in 
order to perform my job efficiently?


Maybe it's just that they all assume I must know what I'm doing.  
If they didn't believe that, I doubt they would have asked me to 
do the project.


Brian

-- 


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


-- 


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


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


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



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

Re: How long for an experiened z/OS sysprog to come up to speed on a new environment?

[Leonard D Woren]

When I started as the primary and basically only real sysprog at a 
small shop almost 40 years ago, it tooks weeks to get up to speed 
because the junior guys there resented me being brought in to be their 
supervisor, and wouldn't tell me anything.  The previous lead guy was 
being kept on as a part-time consultant until I could get up to speed, 
but he was nearly useless.  "Where's the IOGEN source?"  "I don't 
know." Sigh.


This article  is almost 3 years old and was written when COVID-19 
vaccine was just a hope, yet in my opinion it's still mostly valid:


   Never Go Back to the Office
https://www.theatlantic.com/ideas/archive/2020/05/never-go-back-office/611830/ 



What I remember of working in an office, other than commutes being 
horrid resulting in people starting their workday in a bad mood, is 
people getting to the office, getting their coffee, standing around 
socializing for 15-30 minutes, and then maybe starting useful work.


The last time I worked in an office was at a small start-up for a 
manager who thought if he couldn't see you, you weren't working. But 
for some reason he didn't notice the guy without enough to do who 
spent a major chunk of his time transcribing books.


In lieu of having coworkers at arm's reach for helping supply 
information (where's the IOGEN?), now there's Jabber, or the mess 
called Slack, or Microsoft Teams, etc, plus WebEx, Zoom, etc.  And 
old-school email.



Tom Brennan wrote on 2/20/2023 8:19 AM:
In the 80's I purposely bought a house only 12 minutes away from 
where I planned to work until retirement.  But this is Los Angeles 
so that 12 minutes eventually turned into a painful 30-45 with few 
work-from-home options.  When I got outsourced and got a new job, I 
remember calling the owner of the new company asking what office I 
should work at and he basically replied, "What in the world are you 
talking about - I don't want you wasting time driving."  Now that's 
a modern attitude!


On 2/20/2023 7:46 AM, Bob Bridges wrote:
Yeah, I commuted half an hour one-way on the interstate for a good 
many years and took it for granted.  I would have said it didn't 
cause any stress.  Then my wife talked me into buying a house in a 
different location, and suddenly I was commuting ten minutes by 
back roads...and I realized I'd been wrong, it really did make a 
difference.


--
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 want to cry

[Leonard D Woren]

You could ask if the customer still has the box that the product came in.

https://www.snopes.com/fact-check/word-imperfect/

/Leonard

Hank Oerlemans wrote on 2/2/2023 7:28 PM:

Customer : Could you please have a look and help us to fix the issue .
Customer log :  IEA992I SLIP TRAP ID=S047 MATCHED.

ME :
1. Hire a sysprog
2. RTFM
3. Google Play and hit update
4. Apple store and hit update
5. Check calendar and mortgage and see when I can retire
6. Tears welling up realising I can't actually say any of 1-4.

.

It's slow today down under.

haveagoodweegend.

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

[Leonard D Woren]

Bill Hitefield wrote on 11/30/2022 10:39 AM:

In college we had an IBM 1130 in the computer lab. Those of us working in the lab discovered an AM radio placed near 
the console switches made odd noises when you ran Fortran programs and set the radio to a specific "station". 
Further investigation revealed you could change the tone of the noise by using the "e to the x" function and 
varying the value of "x". Our goal in life then became to play "Smoke on the Water" using that 
radio. The temp wasn't too great, but you could recognize the main riff!

Bill Hitefield
Dino-Software Corporation
800.480.DINO
www.dino-software.com



I don't remember it very well, but I think the same could be done to 
some extent on some 360 models.


In the mid-1970s, a college friend had a job as an off-hours computer 
operator at RAND (amusingly, where that 1970 film was made).  He 
wrote, and a musical friend tuned, a program which played music on a 
2400 series tape drive by writing various length blocks -- the shorter 
the repeated block, the higher the note.  I think one of their 2 songs 
was Puff the Magic Dragon.  It was just hilarious to hear recognizable 
music from a tape drive.  The program wore out tapes pretty quickly 
though because all those short blocks were tough on the tape.  One 
long channel program IIRC to keep the music from pausing when a 
different job was dispatched.


Footnote:  That computer center had MVS 3.0 running in the mid 1970s.  
It was the first time that I saw MVS with lots of new stuff compared 
to MVT 21.  But no TSO -- they ran Wylbur.



/Leonard


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

Re: GTTERM assistance (really 3270 VTAM application?)

[Leonard D Woren]

Long ago, in a nearby galaxy, I used descriptive names for registers.  
I got over it after having to deal with a program that had 36 
different register equates.  That program was completely incomprehensible.


You should think not only of what works for you when writing it, but 
as they say, "Always code as if the guy who ends up maintaining your 
code will be a violent psychopath who /knows where you live/.."  (You 
can google that for yourself and get 100K hits.)


/Leonard

Brian Chapman wrote on 11/21/2022 7:04 AM:

For the register equates, I only use the equates when the equate is related
to an active USING statement. With registers 0,1,12 (if not
baseless),13,14,and 15 unavailable, it really limits the number of
registers for addressing control blocks. I find the register equate
methodology very useful and descriptive when managing many DSECTs.



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

Re: To share or not to share DASD

[Leonard D Woren]

Joel C. Ewing wrote on 11/24/2022 9:38 PM:

[...]

If volumes are SMS, all datasets must be cataloged and the 
associated catalogs must be accessed from any system that accesses 
those datasets.   If the systems are not in a relationship that 
enables proper catalog sharing, access and possible modification of 
the catalog from multiple systems causes the cached versions of 
catalog data to become out of sync with actual content on the drive 
when the catalog is altered from a different system, and there is a 
high probability the catalog will become corrupted on all systems.


Let me sharpen that last point.  If the catalog is being updated from 
more than one system not in a sysplex, it's not a "high probability", 
it's basically a certainty   The really fun part is that you may not 
discover the catalog corruption for days, weeks, or even months.



/Leonard


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

Re: Bytes in a 3390 track - reason for the question

[Leonard D Woren]

Paul Schuster wrote on 11/24/2022 11:13 PM:

TRKCALC knows everything.


Second best, I dug up this exec from the 1990s that should get it right:

/* Rexx */
Parse Arg kl dl .
"XPROC 2 KL DL DEBUG"
If dl = "" Then Do
   Say "Usage: BLK3390 keylen datalen [DEBUG]"
   Exit 2
   End
c = 10
If kl = 0 Then k = 0
  Else Do
   kn = DivRU( kl+6, 232 )
   k = 9 + DivRU( kl+6*kn+6, 34 )
   End
dn = DivRU( dl+6, 232 )
d = 9 + DivRU( dl+6*dn+6, 34 )
blks = 1729%(c+k+d)
If debug = "DEBUG" Then Say 'C' c', K' k', D' d
Say blks "blocks with keylen" kl "and datalen" dl "fit on a 3390."
Exit

/*/
DivRU:  /* divide and round UP */
Return (Arg(1)+Arg(2)-1)%Arg(2)


/Leonard


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

Re: Bytes in a 3390 track

[Leonard D Woren]

Seymour J Metz wrote on 11/25/2022 6:23 AM:

You have 80 terabytes?


At least.  You can get there pretty fast with 10 and 12 TB disks, in 
pairs for backup purposes.  But the pressure is on to switch to Linux 
because I'm just about out of drive letters on Windows, and I already 
have some disks with no drive letters using Windows mount points.



One reason is IBM's refusal to accept and implement the SHARE requirement to 
support FBA in MVS for both access methods and IPL.


I've long wondered why.  And in the 1980s (I think), IBM actually had 
a disk for s370 which was FBA, but only supported by DOS/VS.



I'd also ask why IBM didn't provide ACB/RPL support for all access methods, 
with compatibility and reverse compatibility interfaces as necessary, such as 
were present in OS/VS1 and VSE.


I'd also like to know why.  If they had done that, a lot of changes 
(such as the DCBE kludge) to non-VSAM access methods for 31 bit 
support would have been unnecessary because ACBs are 31 bit clean.



It's a shame that IBM dropped TSS; moving it to FBA would have been a piece of 
cake.


The grand irony of course is that VSAM and its cousins (Linear, PAGE, 
PDSE, ZFS) use FBA layered on top of CKD emulated on FBA. Surely I'm 
not the only one who thinks this is nuts?


/Leonard


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Leonard D Woren [ibm-main...@ldworen.net]
Sent: Wednesday, November 23, 2022 8:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track

True.

Yet... why is space still such a big deal on mainframes?  I have
almost as much disk space connected to my primary PC as 10,000 3390-9
would hold.



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

Re: Bytes in a 3390 track

[Leonard D Woren]

True.

Yet... why is space still such a big deal on mainframes?  I have 
almost as much disk space connected to my primary PC as 10,000 3390-9 
would hold.


Seeing a 3390 with 150,000 free cylinders does take some getting used to.

It's time to use this brainpower for better things than optimizing the 
arrangement of angels on a pinhead.  Just throw more hardware at it 
and move on.  A 4 TB disk is the equivalent of almost 5,000,000 3390 
cylinders, or 500 3390-9s.  How much DASD can you add in the disk 
array for the price (salary) of one additional storage management person?


/Leonard


Seymour J Metz wrote on 11/23/2022 3:20 PM:

With essentially all z DASD being cached these days, a lot of the efficiency 
issues no longer apply, leaving space as more dominant.


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

Re: Bytes in a 3390 track

[Leonard D Woren]

Long ago I had a theory regarding blksize=32K load module libraries 
that I could demonstrate on paper but never attempted to demonstrate 
for real due to the amount of work involved.  Consider that the 
linkage editor writes however much program text as fits on the rest of 
the track. IEBCOPY to a new data set copies members in membername 
order, not physical order from the original data set.  It is 
theoretically possible to construct a degenerate case where due to the 
above, the IEBCOPY'd data set will actually take _more_ space than the 
original!  You could have two members originally linked to different 
areas of the original PDS, decently utilizing 32K blocks.  Now you 
IEBCOPY the data set and those two members end up one following one 
another in the target, and the second member's 32K block doesn't fit 
after the first member's 32K block, and the short noise blocks in load 
modules come nowhere close to using up that space.  So in certain 
degenerate cases, you could waste maybe 1/3 of the space when 
IEBCOPYing a blksize=32K load module library.  I suspect that some 
number a bit below half track is optimum to allow for the small 
overhead blocks plus 2 long text blocks.


OTOH, why isn't everybody using PDSEs instead of wasting brain power 
on this?


/Leonard

Mike Schwab wrote on 11/23/2022 10:22 AM:
[...]

Load module PDSs have members with a symbol dictionary in text and
blocked together to start, then repeating a very short block then the
program machine code in multiples of 1K to the blocksize or fill the
rest of the track if less until the load module is complete.

When adding or updating the data is added to the end of the dataset.
When updating or deleting a member the references to the space
previously used is removed but can’t be reused.  Eventually you
compress the PDS in place.  The program reads the directory,
determines where unreferenced space is, then moves up the next block
to the unreferenced space.  The COPY command doesn’t reblock the data,
so if you have a 31K empty space but the next block is 32K, you don’t
use that space.  COPYMOD does reblock, but may not be used very often.

So, a research idea is to write a program that reads the C part of
each CKD record, and calculate a fake R255 for the Key/Blocksize that
could fill the track.  K8/D256 would be the directory blocks, K0/Dx
would be text, K0/Dnk would be program code.  Counts of each key /
block size in a dataset would give insight to that dataset or
collection of text datasets and collection of load module datasets.

Experiments to help determine optimal blocksizes would be to create a
test library with 32K blocksize, copy with reblock into the test
library, analyze blocksizes, delete first member, compress in place,
reanalyze blocksize especially the unused space at end of track.
Repeat until empty.  Reduce by 1K, repeat with copy with reblocking,
analyzing, deleting, compressing until empty.

My predictions of what could be optimal is a 4K blocksize.  And VSAM
and PDSE datasets usually use this physical block size.  And might
have advantages in the I/O occurring in a single frame.


On Wed, Nov 23, 2022 at 11:35 AM Seymour J Metz  wrote:

No, sometimes a smaller block size is more efficient. Also,  a 32K block size 
doesn't mean that all blocks are 32K; both the linkage editor and IEBCOPY can 
write short blocks to pad out a track.


From: IBM Mainframe Discussion List  on behalf of Paul 
Gorlinsky 
Sent: Wednesday, November 23, 2022 12:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bytes in a 3390 track

John, The simple view is that with DASD, the bigger the block as a multiple of 
the track size, the more data you can store on a track.

It almost like an IBG on the older tapes.

Best allocation or space calc is to use 1/2 track if possible, for QSAM, and 
PDSs. For PDSEs using 32760 is fine because I believe they like linear VSAM 
files with 4K blocks.

Remember for DASD, the maximum block size ( physical record ) is 32760. But 
this means on a 3390 you waste about 24K per track. Where as, using something 
near 27998 or less, you will get 2 blocks per track with about 1% overhead.

It looks like PDSEs have about 13% overhead per track assuming a 4K (PAGE) 
track record size ... BUT no compression needs..

For the most part, let the OS handle the allocation by using BLKSIZE=0 where 
you can. It will calc the optimized track record size ( blksize ) for the 
specific device, including tapes.

Do not expect 100% track utilization with MVS/VSE/VM ...







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

Re: AW: NOTSP The Latin of Software Code Is Thriving - The New York Times

[Leonard D Woren]

Mike Beer wrote on 7/7/2022 10:55 PM:

Other candidates could include PL/I - which is/was very common in Europe -


Even though I haven't written a PL/I program since college, I still 
think it's the second-best language and I'm disappointed that it's 
rarely used in the USA.  (Best language?  HLA with structured 
programming macros!)



REXX


Good, but slow.  I converted a CPU pig PC program from REXX to Perl 
and it took 1/3 of the CPU time.



  and maybe APL.


Ya gotta be kidding.  First of all, everyone knows that APL is a 
write-only language.  Second, what fraction of programmers these days 
know APL?  Maybe 0.1%?  And my recollection is that APL is a CPU pig.




Applications that were created many years ago work with virtually no
modifications.


In the early days of MVS/XA, i.e., 31 bit addressing, I had a very old 
TSO command load module but I didn't have easy access to the source.  
It abended S0C4 when run on MVS/XA.  So I marked it AMODE31 and it ran 
fine.  Cleanly written in Assembler, in the early days of MVS/370.


/Leonard



Best regards
Mike
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von
Timothy Sipples
Gesendet: Friday, July 08, 2022 7:37
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: NOTSP The Latin of Software Code Is Thriving - The New York
Times

It's *so* weird! Imagine writing this:

"Sarah, age 23, rejected her college advisor's career advice and started
work at Boeing in Seattle last year. Her friends who mainly pursued careers
in banking and law outright laugh at her for designing airplanes, the
antiquated vehicles invented well over a century ago. But Sarah takes their
ribbing in stride even as she works on designs that past generations of
engineers could mostly comprehend."

Or this:

"Last night Olivia Rodrigo won the 2022 GRAMMY for Best New Artist. It's
ironic that the Recording Academy uses the word 'new' to describe any award
they hand out. Audio recording was invented all the way back in the 1800s
with only modest incremental improvements since. And it's particularly
galling that Rodrigo has never publicly thanked Thomas Edison and other
music recording pioneers for contributing to her success in the ancient
industry she chose. Of course everyone knows music is dying. One analyst in
Ecuador predicts that within 10 years the number of people who listen to
music at least once per day will fall by 92.4%."

Here's how I think of programming languages. There's a very short list of
programming languages that are both so common, so useful, and (relatedly) so
adaptable (incrementally improved, integrated, extended, etc.) that they
have (for all intents and purposes) achieved "immortality." COBOL is
definitely on this distinguished short list. Other things being equal it's a
great characteristic when you're making investment choices including career
choices.




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

Re: The Story of Mainframe Passwords

[Leonard D Woren]

BRODCAST with its 1 byte keys is probably the only data set using 
non-unique hardware keys.


IIRC, the key values have the following meanings:
* (I think) header with pointers to the first system notice and the 
first user directory blocks

* free (available) record
* system notice - operator SEND with SAVE
* user directory
* user mail - TSO SEND with SAVE

Decades ago I heard that SYSCTLG/CVOL and PDS directories both had 256 
byte blocks with 8 byte keys because they used the same code for 
processing.  I have no idea whether that was true.


/Leonard

Seymour J Metz wrote on 5/13/2022 5:43 AM:

* BDAM
* ISAM
* PASSWORD
* PDS directory
* SYSCTLG/CVOL
* SYS1.BRODCAST
* VTOC

What about QTAM and TCAM message queues?


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

Re: Online citations for STARTIO

[Leonard D Woren]

Not all reliable sources are online, particularly if they pre-date the 
www (1989).  Yes, I read the supplied link to reliable sources, but 
it's just an obligatory hand-wave.  They've made it pretty clear that 
they really don't want to recognize anything that's not online.


I have a scan (with my handwritten notes) of a handout from SHARE 70 
(1988), session O346, titled "How to Write an IOS Driver - The MVS 
STARTIO Interface".  Alex Hilleary, Cray Research Inc.  I would 
consider that a reliable source, but we're talking about Wikipedia.


/Leonard


Seymour J Metz wrote on 5/10/2022 4:51 PM:

What I'm looking for is a "reliable source" 
() for the STARTIO macro and 
service in MVS, not the SIO instruction.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Attila Fogarasi [fogar...@gmail.com]
Sent: Tuesday, May 10, 2022 6:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Online citations for STARTIO

Are these 4 slides good enough?
https://secure-web.cisco.com/10SMEd6So8v3HaG3wroXc0E97GgYl4U2knyCjFiG5-90XVyGLfOxg_lZzRBkbRC3nzS9vQE3EhQDAJFfJ2gU6j12rfsb2LfWV61IWCZpTMmXl_dm6MMvszvw4i9bKRt13IIRt84GaxXqw53sHoKQT8tSw4Mi41UofNbZtoU9wDDBA1dDMlWXcHu3jRwaDbbEyHVZ0XVLwQW_GnPI6XHAD9LYB59vM3HrV8L0ejQKe4cuQCIq6LwFdpseKD4gARO_ngSL_3nWlSo9zqb0eXN8knwtMfvKJ_9yyLIM6oVEDOUlk6ER5ROlgI0yWMIUvY0kTATCARNN1VCtLWKIur2DKU_H6yf8Jciwje4lotPn4zTc09NcSPyesP1yPCnRaHGdb-JlY8bUa8GGKiE7CdLXoV7oIQzEb7CY_gl3hI3CrTP3QSLTNEnjMlMmDYK974cGBY5Zg-Ee3eZzSzLerin8tMA/https%3A%2F%2Fwww.slideserve.com%2Ffreira%2Fibm-s-360-370-io-instruction-format

On Tue, May 10, 2022 at 10:58 PM Seymour J Metz  wrote:


I'm looking for something that I can cite as a wiki reliable source for
STARTIO, preferably an online secondary source. Worst case I'll use a dead
tree on my bookcase, but I' hoping for something more accessible.



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

Re: Solutions Not Problems - Dilbert Comic Strip on 2022-02-25 | Dilbert by Scott Adams

[Leonard D Woren]

When a certain horrible 2-letter company acquired acf2, they did a 
global change in the manuals from 'product' to 'solution'.  
Occasionally made for some interesting sentences.


/Leonard

Art Gutowski wrote on 2/26/2022 8:04 PM:

On Fri, 25 Feb 2022 16:19:21 -0500, Mark Regan  wrote:


https://dilbert.com/strip/2022-02-25

Priceless.  I once knew a manager who insisted on calling bugs "opportunities".  To wit, 
a colleague responded, "Sure, a bug is an opportunity...if you're a frog."

Cheers,
Art Gutowski

--
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: 2.5 Heads Up

[Leonard D Woren]

Yep.  We ran into a 14-year old bug when trying to run one of our 
products on a system it normally isn't run on.  Eventually tracked it 
down to an incorrect (CLC which should have been CLI) reference to a 
PSA field which had always been zero.    But on that one system, 
someone had fired up IGVDGNPP and that field wasn't zero.  Tilt.  
Luckily we hit it before a customer (or IBM) did.


Good test tool.  Why isn't it documented?  The cat's out of the bag 
now.  Check with Google.


/Leonard

Jim Mulder wrote on 2/22/2022 11:37 AM:

   Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will
modify all of the reserved fields in every CPU's PSA in order to expose
latent defects in code that happens to seem to work when reserved fields
contain zeroes.  But since that may expose latent defects in other code
(IBM, ISV, or customer), it's not the kind of thing you would want to
use on a production system.

   We of course use that tool on our test systems, so that we tend to
not have zeros at PSA+4 on our z/OS 2.5 test systems, which may
have contributed to the bug escaping our notice
until it got into the field.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on
02/22/2022 10:26:40 AM:


From: "Charles Mills" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 02/22/2022 02:28 PM
Subject: Re: 2.5 Heads Up
Sent by: "IBM Mainframe Discussion List" 

Would using some "debug" type utility to store a non-zero value at

address 4

be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

   Location 4 means address 4 (i.e. offset 4 in the PSA).

  There was a latent bug from a prior release in the loop control
code so that it was erroneously fetching from address 4, and
behaving especially badly when the data at that location
is x'', which it is as of z/OS 2.5.  In prior releases,
it was x'000130E1' when in zArchitecture mode.



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