Re: Some UNIX file usage questions

[David Crayford]

Python closes files at the end of a with statement scope. It will also 
close the file cleanly if an exception is thrown.  That's what I call KISS!


with open('file_path', 'w') as file:
    file.write('hello world !')


On 20/06/2022 1:47 pm, Peter Sylvester wrote:

Hi,

I remember I did that 25 years ago something like (was actually in 
perl on windows):


  open(path/prefix-current_day_or_so, |O_WRONLY|O_APPEND|)"
  write(..)
  cliose(..)
  fsync(...)

(error treating TDB).

KISS  ?

( If you are paranoiac, use three copies, or else  :-)

Peter
peter.sylvester (a) could


On 19/06/2022 22:35, Farley, Peter x23353 wrote:

Agreed; I did not spell out all the details, silly me.

close(old)
rename(old)
open(new)

Peter




--
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: Some UNIX file usage questions

[Peter Sylvester]

Hi,

I remember I did that 25 years ago something like (was actually in perl on 
windows):

  open(path/prefix-current_day_or_so, |O_WRONLY|O_APPEND|)"
  write(..)
  cliose(..)
  fsync(...)

(error treating TDB).

KISS  ?

( If you are paranoiac, use three copies, or else  :-)

Peter
peter.sylvester (a) could


On 19/06/2022 22:35, Farley, Peter x23353 wrote:

Agreed; I did not spell out all the details, silly me.

close(old)
rename(old)
open(new)

Peter




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

Re: Some UNIX file usage questions

[David Crayford]

On 20/06/2022 12:08 pm, kekronbekron wrote:

Hey Charles,


I know exactly how to execute a Started Task written in Rexx, and I know most 
of the gotchas.

Could you expand a bit on this please.
I have this compiled REXX called MON3B from IBM, from 2016.
https://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/s390/zos/wlm/MonitorIIIBatch-v1.10.pdf

Is cancelling it the only way to stop it, if the source for the REXX isn't 
available to modify?


If it's written in REXX I very much doubt it's handling operator 
commands. That would require a console handler thread which is waaayyy 
outside the limits of the language. I'm not familar with this product 
and RMF is one of our products.





  - KB

--- Original Message ---
On Sunday, June 19th, 2022 at 10:45 PM, Charles Mills  wrote:



Why not use Python? Good question.


1. I can undoubtedly do it perfectly satisfactorily, and almost certainly more 
quickly, in Rexx (because of the learning curve). I would have trouble 
justifying billing the client for my Python learning time when there is little 
benefit (that I know of -- correct me if I am wrong) for the client who is 
paying the bills.

Why not, then, learn Python on my own time? Don't I want to learn Python? Yes I 
do, but there are only so many hours in a day, and there are other things I 
want to learn more than I do Python. For example, I would rather spend the time 
learning to make the Roman-Jewish fried artichokes that are in the current 
Cooks Illustrated. Learning Python is just not very high on my bucket list. 
It's there, but probably not high enough to ever rise to the top.

2. I know exactly how to execute a Started Task written in Rexx, and I know most of the 
gotchas. In my experience, THAT is the problem with the "new tools" on z/OS. 
What would I have to do to execute a Started Task written in Python? What are the 
gotchas? Heck, what do I have to do to set up any Python environment at all? That is the 
time-consuming issue, and it holds about zero personal gratification for me. I could 
probably learn the Python language pretty readily, and it would be one more notch in my 
belt. Solving the probable gotchas of getting Python to actually do productive work on 
z/OS -- not so much.


it would trivial to serve those reports as a REST API


Neat, but that is not what the client (who is paying the bills) wants. He wants a 
trivial-to-read-on-his-iPhone email in his inbox every morning. Again, it would be nice to have 
"how to write a REST API" in my toolkit, but not nice enough for me to learn it on my own 
time. Frankly, I am in an "I wish I had less work on my plate" mode and I would probably 
rather learn that artichoke recipe than learn to write REST APIs even if I were getting paid for 
the learning time.


use SQLite instead of a file which will significantly simplify writing reports


Not for me, and probably not for the "report" (I am flattering the requirement calling it 
a report -- maybe call it an "alert") that the client wants. And again, a learning curve 
that is difficult to justify.

So I think I will write it in Rexx, with perhaps a little bit of Assembler.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Saturday, June 18, 2022 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On 19/06/2022 1:33 am, Paul Gilmartin wrote:


On Sat, 18 Jun 2022 09:51:45 -0700, Charles Mills wrote:


...
I picture writing the started task in Rexx, so I would have to write to a DD
name allocated to the UNIX file (either dynamically or with JCL), not with
"native" C fopen(), fwrite(), etc. Does that change any of the answers?

Why? In Rexx you can "address SYASCALL write ..." instead.


Why REXX? Is it a case of knowing the banjo so you play Stairway to
Heaven in the style of Earl Schruggs?

Why not use IBMs z/OS Python? You can then use SQLite instead of a file
which will significantly simplify writing reports. In fact, it would
trivial to serve those
reports as a REST API and put a nice WebUI on top using a simple
template that supports data tables.

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 12:10 pm, kekronbekron wrote:

  From the presentations I've seen they used CDC to capture writes and

then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.

Any chance it's available for the public?
I've seen a similar session by Confluent & Nationwide.
Knowing others' implementation stories is super useful.


WestPac (There's 4 in the series)

https://videos.confluent.io/watch/P5up2YQX9QdVMhmYfsXy7Q

Commonwealth Bank. CommBank own Bank West which has a similar 
architecture. I had an interesting chat with one of their architects at 
z meetup and he told me they use Oracle Golden Gate for CDC and Apache 
Cassandra. They also moved some DB2 SQL queries to distributed 
connecting via DDA which can be offloaded to a zIIP, removing a CICS 
transaction. 70% of all CICS transactions were reads which they now 
offload saving big . Mobile banking was killing them!


https://www.confluent.io/kafka-summit-sf18/kafka-in-the-enterprise/

NAB

https://business.nab.com.au/wp-content/uploads/2020/06/new-payments-platform-two-years-on.pdf

Another interesting read is project atom which is a partnership between 
CBA, NAB, WestPac, IBM and the RBA for interoperability of settlements 
using blockchain. Did you know that IBMs motivation to port golang to 
z/OS was so they could port HyperLedger which is written in Go?


https://www.rba.gov.au/payments-and-infrastructure/central-bank-digital-currency/pdf/project-atom-report_2021-12.pdf

I could go on and on. We had a meeting with Confluent and they pretty 
much have to financial services industry wrapped up. One of my team used 
to work for Barclays in the UK and they implemented an EBA almost 10 
years ago. Same with the big US banks.




- KB

--- Original Message ---
On Sunday, June 19th, 2022 at 11:32 PM, David Crayford  
wrote:



On 20/06/2022 12:38 am, Seymour J Metz wrote:


Keep in mind that the mainframe can only do batch processing, with input from 
cards. It doesn't support anything like CICS, IMS or Sabre..


What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight. In the
case of banking transactions that require inter-bank settlements this
can cause delays of several days. In Australia the government mandated
the NPP (New Payments Platform) which facilities instant payments using
payids, which can be an email address, cellphone numbers etc. The API is
a simple REST API using HTTP
https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
It's my understanding that no bank implemented NPP on the mainframe.
 From the presentations I've seen they used CDC to capture writes and
then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.
Back in the day straight-through processing was a pipe dream which is
why we have overnight batch. It's a relic of applications written
decades ago for very different hardware platforms.


It's much better to run Linux than to get an IFL, which can only run batch.


I have no idea what you mean?


Cynical? Moi?

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 19/06/2022 5:23 am, Enzo D'Amato wrote:


I also agree, but as a non-insider, I wanted to know what others were thinking. 
I also belive that in most cases, the effort spent trying to get off the 
mainframe would be better spent actually fixing the code running on it in the 
first place. Moving around broken code doesn't automatically fix it.
It's not just about fixing broken code. If you read the ING CIO's
remarks about why they wanted off the mainframe it's not about the
platform. Nobody denies that mainframes are insanely brilliant hardware
platforms. ING wanted to get rid of batch and move towards an event
driven architecture using pub/sub where they can easily deploy loosely
coupled micro-services to provide cutting edge products. The technology
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
Avro etc. The retail banking industry has been disrupted by fintechs so
waiting for an overnight batch schedule for settlements is a competitive
disadvantage. Cracking open and modernizing 50-60 year old COBOL batch
applications is a VERY heavy lift.

https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZ

Re: Some UNIX file usage questions

[David Crayford]

You could have learned Python in the time it took you to write this email.

On 20/06/2022 1:15 am, Charles Mills wrote:

Why not use Python? Good question.

1. I can undoubtedly do it perfectly satisfactorily, and almost certainly more 
quickly, in Rexx (because of the learning curve). I would have trouble 
justifying billing the client for my Python learning time when there is little 
benefit (that I know of -- correct me if I am wrong) for the client who is 
paying the bills.

Why not, then, learn Python on my own time? Don't I want to learn Python? Yes I 
do, but there are only so many hours in a day, and there are other things I 
want to learn more than I do Python. For example, I would rather spend the time 
learning to make the Roman-Jewish fried artichokes that are in the current 
Cooks Illustrated. Learning Python is just not very high on my bucket list. 
It's there, but probably not high enough to ever rise to the top.

2. I know exactly how to execute a Started Task written in Rexx, and I know most of the 
gotchas. In my experience, THAT is the problem with the "new tools" on z/OS. 
What would I have to do to execute a Started Task written in Python? What are the 
gotchas? Heck, what do I have to do to set up any Python environment at all? That is the 
time-consuming issue, and it holds about zero personal gratification for me. I could 
probably learn the Python language pretty readily, and it would be one more notch in my 
belt. Solving the probable gotchas of getting Python to actually do productive work on 
z/OS -- not so much.

Not for me, and probably not for the "report" (I am flattering the requirement calling it 
a report -- maybe call it an "alert") that the client wants. And again, a learning curve 
that is difficult to justify.

So I think I will write it in Rexx, with perhaps a little bit of Assembler.


Does your client REALLY want to maintain assembler code? Our company 
policy is not to use assembler for new code due to lack of available 
skills which will only get worse.





Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Saturday, June 18, 2022 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On 19/06/2022 1:33 am, Paul Gilmartin wrote:

On Sat, 18 Jun 2022 09:51:45 -0700, Charles Mills wrote:

 ...
I picture writing the started task in Rexx, so I would have to write to a DD
name allocated to the UNIX file (either dynamically or with JCL), not with
"native" C fopen(), fwrite(), etc. Does that change any of the answers?


Why?  In Rexx you can "address SYASCALL write ..." instead.

Why REXX? Is it a case of knowing the banjo so you play Stairway to
Heaven in the style of Earl Schruggs?

Why not use IBMs z/OS Python? You can then use SQLite instead of a file
which will significantly simplify writing reports. In fact, it would
trivial to serve those
reports as a REST API and put a nice WebUI on top using a simple
template that supports data tables.

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[kekronbekron]

>  From the presentations I've seen they used CDC to capture writes and
then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.

Any chance it's available for the public?
I've seen a similar session by Confluent & Nationwide.
Knowing others' implementation stories is super useful.

- KB

--- Original Message ---
On Sunday, June 19th, 2022 at 11:32 PM, David Crayford  
wrote:


> On 20/06/2022 12:38 am, Seymour J Metz wrote:
>
> > Keep in mind that the mainframe can only do batch processing, with input 
> > from cards. It doesn't support anything like CICS, IMS or Sabre..
>
>
> What have transactional systems like CICS or IMS got to do with
> real-time, straight-through processing? Most mainframe transactions
> store data that is later processed by batch, typically overnight. In the
> case of banking transactions that require inter-bank settlements this
> can cause delays of several days. In Australia the government mandated
> the NPP (New Payments Platform) which facilities instant payments using
> payids, which can be an email address, cellphone numbers etc. The API is
> a simple REST API using HTTP
> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
> It's my understanding that no bank implemented NPP on the mainframe.
> From the presentations I've seen they used CDC to capture writes and
> then published events to Kafka, which was fanned out to different
> micro-services to do fraud detection, payments, push notifications etc.
> Back in the day straight-through processing was a pipe dream which is
> why we have overnight batch. It's a relic of applications written
> decades ago for very different hardware platforms.
>
> > It's much better to run Linux than to get an IFL, which can only run batch.
>
>
> I have no idea what you mean?
>
> > Cynical? Moi?
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> > David Crayford [dcrayf...@gmail.com]
> > Sent: Sunday, June 19, 2022 2:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
> > AWS
> >
> > On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> >
> > > I also agree, but as a non-insider, I wanted to know what others were 
> > > thinking. I also belive that in most cases, the effort spent trying to 
> > > get off the mainframe would be better spent actually fixing the code 
> > > running on it in the first place. Moving around broken code doesn't 
> > > automatically fix it.
> > > It's not just about fixing broken code. If you read the ING CIO's
> > > remarks about why they wanted off the mainframe it's not about the
> > > platform. Nobody denies that mainframes are insanely brilliant hardware
> > > platforms. ING wanted to get rid of batch and move towards an event
> > > driven architecture using pub/sub where they can easily deploy loosely
> > > coupled micro-services to provide cutting edge products. The technology
> > > stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> > > Avro etc. The retail banking industry has been disrupted by fintechs so
> > > waiting for an overnight batch schedule for settlements is a competitive
> > > disadvantage. Cracking open and modernizing 50-60 year old COBOL batch
> > > applications is a VERY heavy lift.
> >
> > https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
> >  <- read
> > the comments section. It's hilarious :)
> >
> > The doubly whammy is there's a skills crisis slowly unraveling. In the
> > last year we've had 3 key resources move to 3 day weeks with a view to
> > retiring. Replacing highly skilled assembler programmers with deep
> > subsystem knowledge is proving to be difficult. Young people don't want
> > to learn HLASM as they consider it a dead-end. Their position is "why
> > invest 3-4 years learning a language that is useless if you move to
> > another industry?" I can't comment about COBOL application developers.
> >
> > In 10 years time I expect the mainframe to be alive and kicking and
> > significantly modernized. The small/medium shops will probably be all
> > gone. When I first moved to my current town in 1998 there were 25-30
> > mainframe sites. Now there are 3 and 1 is on life support. One of our
> > customers re-platformed their CICS/COBOL/Batch

Re: Some UNIX file usage questions

[kekronbekron]

Hey Charles,

> I know exactly how to execute a Started Task written in Rexx, and I know most 
> of the gotchas.

Could you expand a bit on this please.
I have this compiled REXX called MON3B from IBM, from 2016.
https://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/s390/zos/wlm/MonitorIIIBatch-v1.10.pdf

Is cancelling it the only way to stop it, if the source for the REXX isn't 
available to modify?

 - KB

--- Original Message ---
On Sunday, June 19th, 2022 at 10:45 PM, Charles Mills  wrote:


> > Why not use Python? Good question.
>
>
> 1. I can undoubtedly do it perfectly satisfactorily, and almost certainly 
> more quickly, in Rexx (because of the learning curve). I would have trouble 
> justifying billing the client for my Python learning time when there is 
> little benefit (that I know of -- correct me if I am wrong) for the client 
> who is paying the bills.
>
> Why not, then, learn Python on my own time? Don't I want to learn Python? Yes 
> I do, but there are only so many hours in a day, and there are other things I 
> want to learn more than I do Python. For example, I would rather spend the 
> time learning to make the Roman-Jewish fried artichokes that are in the 
> current Cooks Illustrated. Learning Python is just not very high on my bucket 
> list. It's there, but probably not high enough to ever rise to the top.
>
> 2. I know exactly how to execute a Started Task written in Rexx, and I know 
> most of the gotchas. In my experience, THAT is the problem with the "new 
> tools" on z/OS. What would I have to do to execute a Started Task written in 
> Python? What are the gotchas? Heck, what do I have to do to set up any Python 
> environment at all? That is the time-consuming issue, and it holds about zero 
> personal gratification for me. I could probably learn the Python language 
> pretty readily, and it would be one more notch in my belt. Solving the 
> probable gotchas of getting Python to actually do productive work on z/OS -- 
> not so much.
>
> > it would trivial to serve those reports as a REST API
>
>
> Neat, but that is not what the client (who is paying the bills) wants. He 
> wants a trivial-to-read-on-his-iPhone email in his inbox every morning. 
> Again, it would be nice to have "how to write a REST API" in my toolkit, but 
> not nice enough for me to learn it on my own time. Frankly, I am in an "I 
> wish I had less work on my plate" mode and I would probably rather learn that 
> artichoke recipe than learn to write REST APIs even if I were getting paid 
> for the learning time.
>
> > use SQLite instead of a file which will significantly simplify writing 
> > reports
>
>
> Not for me, and probably not for the "report" (I am flattering the 
> requirement calling it a report -- maybe call it an "alert") that the client 
> wants. And again, a learning curve that is difficult to justify.
>
> So I think I will write it in Rexx, with perhaps a little bit of Assembler.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David Crayford
> Sent: Saturday, June 18, 2022 11:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Some UNIX file usage questions
>
> On 19/06/2022 1:33 am, Paul Gilmartin wrote:
>
> > On Sat, 18 Jun 2022 09:51:45 -0700, Charles Mills wrote:
> >
> > > ...
> > > I picture writing the started task in Rexx, so I would have to write to a 
> > > DD
> > > name allocated to the UNIX file (either dynamically or with JCL), not with
> > > "native" C fopen(), fwrite(), etc. Does that change any of the answers?
> >
> > Why? In Rexx you can "address SYASCALL write ..." instead.
>
>
> Why REXX? Is it a case of knowing the banjo so you play Stairway to
> Heaven in the style of Earl Schruggs?
>
> Why not use IBMs z/OS Python? You can then use SQLite instead of a file
> which will significantly simplify writing reports. In fact, it would
> trivial to serve those
> reports as a REST API and put a nice WebUI on top using a simple
> template that supports data tables.
>
> --
> 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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

The mainframe has been a real time machine for decades. 


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 8:26 PM, David Crayford  wrote:

Did he say that are are you putting words into his mouth? Either way I don’t 
care. He’s been retired for years so his knowledge of the mainframe is frozen 
in time. If you’re not at the coalface you loose touch. 

> On 20 Jun 2022, at 8:19 am, Bill Johnson 
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Aren’t you the guy who thought Pharmacies weren’t open 24 by 7? Metz is 
> right, if you think the mainframe is a batch machine, you’ve got zero 
> credibility.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Sunday, June 19, 2022, 4:51 PM, David Crayford  wrote:
> 
>> On 20/06/2022 4:21 am, Bill Johnson wrote:
>> Most mainframes store transactions and process in batch? Are you the same 
>> guy who didn’t know pharmacies are open 24 by 7?
> 
> Go and have a nap Bill. And don't forget to take your meds when you wake up.
> 
> 
>> 
>> Sent from Yahoo Mail for iPhone
>> 
>> 
>> On Sunday, June 19, 2022, 2:03 PM, David Crayford  
>> wrote:
>> 
>> On 20/06/2022 12:38 am, Seymour J Metz wrote:
>>> Keep in mind that the mainframe can only do batch processing, with input 
>>> from cards. It doesn't support anything like CICS, IMS or Sabre..
>> What have transactional systems like CICS or IMS got to do with
>> real-time, straight-through processing? Most mainframe transactions
>> store data that is later processed by batch, typically overnight. In the
>> case of banking transactions that require inter-bank settlements this
>> can cause delays of several days. In Australia the government mandated
>> the NPP (New Payments Platform) which facilities instant payments using
>> payids, which can be an email address, cellphone numbers etc. The API is
>> a simple REST API using HTTP
>> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
>> It's my understanding that no bank implemented NPP on the mainframe.
>>  From the presentations I've seen they used CDC to capture writes and
>> then published events to Kafka, which was fanned out to different
>> micro-services to do fraud detection, payments, push notifications etc.
>> Back in the day straight-through processing was a pipe dream which is
>> why we have overnight batch. It's a relic of applications written
>> decades ago for very different hardware platforms.
>> 
>> 
>>> It's much better to run Linux than to get an IFL, which can only run batch.
>> I have no idea what you mean?
>> 
>>> Cynical? Moi?
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>> David Crayford [dcrayf...@gmail.com]
>>> Sent: Sunday, June 19, 2022 2:36 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
>>> AWS
>>> 
>>> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
 I also agree, but as a non-insider, I wanted to know what others were 
 thinking. I also belive that in most cases, the effort spent trying to get 
 off the mainframe would be better spent actually fixing the code running 
 on it in the first place. Moving around broken code doesn't automatically 
 fix it.
>>> It's not just about fixing broken code. If you read the ING CIO's
>>> remarks about why they wanted off the mainframe it's not about the
>>> platform. Nobody denies that mainframes are insanely brilliant hardware
>>> platforms. ING wanted to get rid of batch and move towards an event
>>> driven architecture using pub/sub where they can easily deploy loosely
>>> coupled micro-services to provide cutting edge products. The technology
>>> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
>>> Avro etc.  The retail banking industry has been disrupted by fintechs so
>>> waiting for an overnight batch schedule for settlements is a competitive
>>> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
>>> applications is a VERY heavy lift.
>>> 
>>> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>>>  <- read
>>> the comments section. It's hilarious :)
>>> 
>>> The doubly whammy is there's a skills crisis slowly unraveling. In the
>>> last year we've had 3 key resources move to 3 day weeks with a view to
>>> retiring. Replacing highly skilled assembler programmers w

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

How’s the Fintech stocks working for you? Most of them are going under.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 8:26 PM, David Crayford  wrote:

Did he say that are are you putting words into his mouth? Either way I don’t 
care. He’s been retired for years so his knowledge of the mainframe is frozen 
in time. If you’re not at the coalface you loose touch. 

> On 20 Jun 2022, at 8:19 am, Bill Johnson 
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Aren’t you the guy who thought Pharmacies weren’t open 24 by 7? Metz is 
> right, if you think the mainframe is a batch machine, you’ve got zero 
> credibility.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Sunday, June 19, 2022, 4:51 PM, David Crayford  wrote:
> 
>> On 20/06/2022 4:21 am, Bill Johnson wrote:
>> Most mainframes store transactions and process in batch? Are you the same 
>> guy who didn’t know pharmacies are open 24 by 7?
> 
> Go and have a nap Bill. And don't forget to take your meds when you wake up.
> 
> 
>> 
>> Sent from Yahoo Mail for iPhone
>> 
>> 
>> On Sunday, June 19, 2022, 2:03 PM, David Crayford  
>> wrote:
>> 
>> On 20/06/2022 12:38 am, Seymour J Metz wrote:
>>> Keep in mind that the mainframe can only do batch processing, with input 
>>> from cards. It doesn't support anything like CICS, IMS or Sabre..
>> What have transactional systems like CICS or IMS got to do with
>> real-time, straight-through processing? Most mainframe transactions
>> store data that is later processed by batch, typically overnight. In the
>> case of banking transactions that require inter-bank settlements this
>> can cause delays of several days. In Australia the government mandated
>> the NPP (New Payments Platform) which facilities instant payments using
>> payids, which can be an email address, cellphone numbers etc. The API is
>> a simple REST API using HTTP
>> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
>> It's my understanding that no bank implemented NPP on the mainframe.
>>  From the presentations I've seen they used CDC to capture writes and
>> then published events to Kafka, which was fanned out to different
>> micro-services to do fraud detection, payments, push notifications etc.
>> Back in the day straight-through processing was a pipe dream which is
>> why we have overnight batch. It's a relic of applications written
>> decades ago for very different hardware platforms.
>> 
>> 
>>> It's much better to run Linux than to get an IFL, which can only run batch.
>> I have no idea what you mean?
>> 
>>> Cynical? Moi?
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>> David Crayford [dcrayf...@gmail.com]
>>> Sent: Sunday, June 19, 2022 2:36 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
>>> AWS
>>> 
>>> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
 I also agree, but as a non-insider, I wanted to know what others were 
 thinking. I also belive that in most cases, the effort spent trying to get 
 off the mainframe would be better spent actually fixing the code running 
 on it in the first place. Moving around broken code doesn't automatically 
 fix it.
>>> It's not just about fixing broken code. If you read the ING CIO's
>>> remarks about why they wanted off the mainframe it's not about the
>>> platform. Nobody denies that mainframes are insanely brilliant hardware
>>> platforms. ING wanted to get rid of batch and move towards an event
>>> driven architecture using pub/sub where they can easily deploy loosely
>>> coupled micro-services to provide cutting edge products. The technology
>>> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
>>> Avro etc.  The retail banking industry has been disrupted by fintechs so
>>> waiting for an overnight batch schedule for settlements is a competitive
>>> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
>>> applications is a VERY heavy lift.
>>> 
>>> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>>>  <- read
>>> the comments section. It's hilarious :)
>>> 
>>> The doubly whammy is there's a skills crisis slowly unraveling. In the
>>> last year we've had 3 key resources move to 3 day weeks with a view to
>>> retiring. Replacing highly skilled assemble

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

Did he say that are are you putting words into his mouth? Either way I don’t 
care. He’s been retired for years so his knowledge of the mainframe is frozen 
in time. If you’re not at the coalface you loose touch. 

> On 20 Jun 2022, at 8:19 am, Bill Johnson 
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Aren’t you the guy who thought Pharmacies weren’t open 24 by 7? Metz is 
> right, if you think the mainframe is a batch machine, you’ve got zero 
> credibility.
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> 
> On Sunday, June 19, 2022, 4:51 PM, David Crayford  wrote:
> 
>> On 20/06/2022 4:21 am, Bill Johnson wrote:
>> Most mainframes store transactions and process in batch? Are you the same 
>> guy who didn’t know pharmacies are open 24 by 7?
> 
> Go and have a nap Bill. And don't forget to take your meds when you wake up.
> 
> 
>> 
>> Sent from Yahoo Mail for iPhone
>> 
>> 
>> On Sunday, June 19, 2022, 2:03 PM, David Crayford  
>> wrote:
>> 
>> On 20/06/2022 12:38 am, Seymour J Metz wrote:
>>> Keep in mind that the mainframe can only do batch processing, with input 
>>> from cards. It doesn't support anything like CICS, IMS or Sabre..
>> What have transactional systems like CICS or IMS got to do with
>> real-time, straight-through processing? Most mainframe transactions
>> store data that is later processed by batch, typically overnight. In the
>> case of banking transactions that require inter-bank settlements this
>> can cause delays of several days. In Australia the government mandated
>> the NPP (New Payments Platform) which facilities instant payments using
>> payids, which can be an email address, cellphone numbers etc. The API is
>> a simple REST API using HTTP
>> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
>> It's my understanding that no bank implemented NPP on the mainframe.
>>   From the presentations I've seen they used CDC to capture writes and
>> then published events to Kafka, which was fanned out to different
>> micro-services to do fraud detection, payments, push notifications etc.
>> Back in the day straight-through processing was a pipe dream which is
>> why we have overnight batch. It's a relic of applications written
>> decades ago for very different hardware platforms.
>> 
>> 
>>> It's much better to run Linux than to get an IFL, which can only run batch.
>> I have no idea what you mean?
>> 
>>> Cynical? Moi?
>>> 
>>> 
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>>> David Crayford [dcrayf...@gmail.com]
>>> Sent: Sunday, June 19, 2022 2:36 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
>>> AWS
>>> 
>>> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
 I also agree, but as a non-insider, I wanted to know what others were 
 thinking. I also belive that in most cases, the effort spent trying to get 
 off the mainframe would be better spent actually fixing the code running 
 on it in the first place. Moving around broken code doesn't automatically 
 fix it.
>>> It's not just about fixing broken code. If you read the ING CIO's
>>> remarks about why they wanted off the mainframe it's not about the
>>> platform. Nobody denies that mainframes are insanely brilliant hardware
>>> platforms. ING wanted to get rid of batch and move towards an event
>>> driven architecture using pub/sub where they can easily deploy loosely
>>> coupled micro-services to provide cutting edge products. The technology
>>> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
>>> Avro etc.  The retail banking industry has been disrupted by fintechs so
>>> waiting for an overnight batch schedule for settlements is a competitive
>>> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
>>> applications is a VERY heavy lift.
>>> 
>>> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>>>  <- read
>>> the comments section. It's hilarious :)
>>> 
>>> The doubly whammy is there's a skills crisis slowly unraveling. In the
>>> last year we've had 3 key resources move to 3 day weeks with a view to
>>> retiring. Replacing highly skilled assembler programmers with deep
>>> subsystem knowledge is proving to be difficult. Young people don't want
>>> to learn HLASM as they consider it a dead-end. Their position 

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Aren’t you the guy who thought Pharmacies weren’t open 24 by 7? Metz is right, 
if you think the mainframe is a batch machine, you’ve got zero credibility.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 4:51 PM, David Crayford  wrote:

On 20/06/2022 4:21 am, Bill Johnson wrote:
> Most mainframes store transactions and process in batch? Are you the same guy 
> who didn’t know pharmacies are open 24 by 7?

Go and have a nap Bill. And don't forget to take your meds when you wake up.


>
> Sent from Yahoo Mail for iPhone
>
>
> On Sunday, June 19, 2022, 2:03 PM, David Crayford  wrote:
>
> On 20/06/2022 12:38 am, Seymour J Metz wrote:
>> Keep in mind that the mainframe can only do batch processing, with input 
>> from cards. It doesn't support anything like CICS, IMS or Sabre..
> What have transactional systems like CICS or IMS got to do with
> real-time, straight-through processing? Most mainframe transactions
> store data that is later processed by batch, typically overnight. In the
> case of banking transactions that require inter-bank settlements this
> can cause delays of several days. In Australia the government mandated
> the NPP (New Payments Platform) which facilities instant payments using
> payids, which can be an email address, cellphone numbers etc. The API is
> a simple REST API using HTTP
> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
> It's my understanding that no bank implemented NPP on the mainframe.
>  From the presentations I've seen they used CDC to capture writes and
> then published events to Kafka, which was fanned out to different
> micro-services to do fraud detection, payments, push notifications etc.
> Back in the day straight-through processing was a pipe dream which is
> why we have overnight batch. It's a relic of applications written
> decades ago for very different hardware platforms.
>
>
>> It's much better to run Linux than to get an IFL, which can only run batch.
> I have no idea what you mean?
>
>> Cynical? Moi?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> David Crayford [dcrayf...@gmail.com]
>> Sent: Sunday, June 19, 2022 2:36 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
>> AWS
>>
>> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
>>> I also agree, but as a non-insider, I wanted to know what others were 
>>> thinking. I also belive that in most cases, the effort spent trying to get 
>>> off the mainframe would be better spent actually fixing the code running on 
>>> it in the first place. Moving around broken code doesn't automatically fix 
>>> it.
>> It's not just about fixing broken code. If you read the ING CIO's
>> remarks about why they wanted off the mainframe it's not about the
>> platform. Nobody denies that mainframes are insanely brilliant hardware
>> platforms. ING wanted to get rid of batch and move towards an event
>> driven architecture using pub/sub where they can easily deploy loosely
>> coupled micro-services to provide cutting edge products. The technology
>> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
>> Avro etc.  The retail banking industry has been disrupted by fintechs so
>> waiting for an overnight batch schedule for settlements is a competitive
>> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
>> applications is a VERY heavy lift.
>>
>> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>>  <- read
>> the comments section. It's hilarious :)
>>
>> The doubly whammy is there's a skills crisis slowly unraveling. In the
>> last year we've had 3 key resources move to 3 day weeks with a view to
>> retiring. Replacing highly skilled assembler programmers with deep
>> subsystem knowledge is proving to be difficult. Young people don't want
>> to learn HLASM as they consider it a dead-end. Their position is "why
>> invest 3-4 years learning a language that is useless if you move to
>> another industry?" I can't comment about COBOL application developers.
>>
>> In 10 years time I expect the mainframe to be alive and kicking and
>> significantly modernized. The small/medium shops will probably be all
>> gone. When I first moved to my current town in 1998 there were 25-30
>> mainframe sites. Now there are 3 and 1 is on life support. One of our

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 5:47 am, Joe Monk wrote:

"Please elaborate how IMS TM is anything more than a message queue that
processes transactions."

Youre quibbling about form over substance.


I'm asking you to back up your statement.



As an example, NASA uses message queue processing for spacecraft telemetry.


NASA doesn't use IMS.



Joe



On Sun, Jun 19, 2022 at 4:39 PM David Crayford  wrote:


On 20/06/2022 5:27 am, Joe Monk wrote:

"What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight."

If you think CICS and IMS are transactional only, youre stuck in the

'80s.

I've spent the last 20+ years working on ISV products for IMS and CICS.
Please elaborate how IMS TM is anything more than a message queue that
processes
transactions. If you want to throw IMS Connect into the mix then please
comment as I have in depth knowledge of the architecture as I was on dev
on the
IMS Connect Extensions product.


As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
writing code, storing it in a library, compiling, etc. are not

"real-time".
Awesome :/

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

"Please elaborate how IMS TM is anything more than a message queue that
processes transactions."

Youre quibbling about form over substance.

As an example, NASA uses message queue processing for spacecraft telemetry.

Joe



On Sun, Jun 19, 2022 at 4:39 PM David Crayford  wrote:

> On 20/06/2022 5:27 am, Joe Monk wrote:
> > "What have transactional systems like CICS or IMS got to do with
> > real-time, straight-through processing? Most mainframe transactions
> > store data that is later processed by batch, typically overnight."
> >
> > If you think CICS and IMS are transactional only, youre stuck in the
> '80s.
>
> I've spent the last 20+ years working on ISV products for IMS and CICS.
> Please elaborate how IMS TM is anything more than a message queue that
> processes
> transactions. If you want to throw IMS Connect into the mix then please
> comment as I have in depth knowledge of the architecture as I was on dev
> on the
> IMS Connect Extensions product.
>
> > As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
> > writing code, storing it in a library, compiling, etc. are not
> "real-time".
> Awesome :/
>
> --
> 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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 5:27 am, Joe Monk wrote:

"What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight."

If you think CICS and IMS are transactional only, youre stuck in the '80s.


I've spent the last 20+ years working on ISV products for IMS and CICS. 
Please elaborate how IMS TM is anything more than a message queue that 
processes
transactions. If you want to throw IMS Connect into the mix then please 
comment as I have in depth knowledge of the architecture as I was on dev 
on the

IMS Connect Extensions product.


As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
writing code, storing it in a library, compiling, etc. are not "real-time".

Awesome :/

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Joe Monk]

"What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight."

If you think CICS and IMS are transactional only, youre stuck in the '80s.
As an example, ICCF on VSE uses CICS as the TP Monitor. Tell me that
writing code, storing it in a library, compiling, etc. are not "real-time".

Joe

On Sun, Jun 19, 2022 at 1:03 PM David Crayford  wrote:

> On 20/06/2022 12:38 am, Seymour J Metz wrote:
> > Keep in mind that the mainframe can only do batch processing, with input
> from cards. It doesn't support anything like CICS, IMS or Sabre..
>
> What have transactional systems like CICS or IMS got to do with
> real-time, straight-through processing? Most mainframe transactions
> store data that is later processed by batch, typically overnight. In the
> case of banking transactions that require inter-bank settlements this
> can cause delays of several days. In Australia the government mandated
> the NPP (New Payments Platform) which facilities instant payments using
> payids, which can be an email address, cellphone numbers etc. The API is
> a simple REST API using HTTP
>
> https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
>
> It's my understanding that no bank implemented NPP on the mainframe.
>  From the presentations I've seen they used CDC to capture writes and
> then published events to Kafka, which was fanned out to different
> micro-services to do fraud detection, payments, push notifications etc.
> Back in the day straight-through processing was a pipe dream which is
> why we have overnight batch. It's a relic of applications written
> decades ago for very different hardware platforms.
>
>
> > It's much better to run Linux than to get an IFL, which can only run
> batch.
>
> I have no idea what you mean?
>
> >
> > Cynical? Moi?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of David Crayford [dcrayf...@gmail.com]
> > Sent: Sunday, June 19, 2022 2:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and AWS
> >
> > On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> >> I also agree, but as a non-insider, I wanted to know what others were
> thinking. I also belive that in most cases, the effort spent trying to get
> off the mainframe would be better spent actually fixing the code running on
> it in the first place. Moving around broken code doesn't automatically fix
> it.
> > It's not just about fixing broken code. If you read the ING CIO's
> > remarks about why they wanted off the mainframe it's not about the
> > platform. Nobody denies that mainframes are insanely brilliant hardware
> > platforms. ING wanted to get rid of batch and move towards an event
> > driven architecture using pub/sub where they can easily deploy loosely
> > coupled micro-services to provide cutting edge products. The technology
> > stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> > Avro etc.  The retail banking industry has been disrupted by fintechs so
> > waiting for an overnight batch schedule for settlements is a competitive
> > disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> > applications is a VERY heavy lift.
> >
> >
> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
> <- read
> > the comments section. It's hilarious :)
> >
> > The doubly whammy is there's a skills crisis slowly unraveling. In the
> > last year we've had 3 key resources move to 3 day weeks with a view to
> > retiring. Replacing highly skilled assembler programmers with deep
> > subsystem knowledge is proving to be difficult. Young people don't want
> > to learn HLASM as they consider it a dead-end. Their position is "why
> > invest 3-4 years learning a language that is useless if you move to
> > another industry?" I can't comment about COBOL application developers.
> >
> > In 10 years time I expect the mainframe to be alive and kicking and
> > significantly modernized. The small/medium shops will probably be all
> > gone. When I first moved to my current town in 1998 there were 25-30
> > mainframe sites. Now there are 3 and 1 is on life support. One of our
> > customers re-platformed their CICS/COBOL/Batch applications from a z9 to
> > 

Re: RIsks of sharing FICON adapters between LPARs on the same host

[Laurence Chiu]

I presume you do this encryption in flight as well as encryption at rest
using the native DS8K encryption facilities? So the data could be doubly
encrypted?

On Fri, Jun 17, 2022 at 9:22 PM Timothy Sipples  wrote:

> Laurence Chiu wrote:
> >If all data is encrypted before I/O are there any performance impacts on
> >say Z14's with lesser capable hardware encryption?
>
> The IBM z14 models were the first to incorporate the "step change" higher
> performance CPACF expressly designed for this mission (bulk data
> encryption/decryption).
>
> z/OS Data Set Encryption is technically compatible with models prior to
> z14 (all the way back to z196/z114), but on prior models the performance is
> less impressive. Thus on those models I suggest using z/OS Data Set
> Encryption only with your most sensitive data sets if you're concerned
> about performance impacts.
>
> — — — — —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM zSystems/LinuxONE, Asia-Pacific
> sipp...@sg.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 4:21 am, Bill Johnson wrote:

Most mainframes store transactions and process in batch? Are you the same guy 
who didn’t know pharmacies are open 24 by 7?


Go and have a nap Bill. And don't forget to take your meds when you wake up.




Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:03 PM, David Crayford  wrote:

On 20/06/2022 12:38 am, Seymour J Metz wrote:

Keep in mind that the mainframe can only do batch processing, with input from 
cards. It doesn't support anything like CICS, IMS or Sabre..

What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight. In the
case of banking transactions that require inter-bank settlements this
can cause delays of several days. In Australia the government mandated
the NPP (New Payments Platform) which facilities instant payments using
payids, which can be an email address, cellphone numbers etc. The API is
a simple REST API using HTTP
https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
It's my understanding that no bank implemented NPP on the mainframe.
  From the presentations I've seen they used CDC to capture writes and
then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.
Back in the day straight-through processing was a pipe dream which is
why we have overnight batch. It's a relic of applications written
decades ago for very different hardware platforms.



It's much better to run Linux than to get an IFL, which can only run batch.

I have no idea what you mean?


Cynical? Moi?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 19/06/2022 5:23 am, Enzo D'Amato wrote:

I also agree, but as a non-insider, I wanted to know what others were thinking. 
I also belive that in most cases, the effort spent trying to get off the 
mainframe would be better spent actually fixing the code running on it in the 
first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's
remarks about why they wanted off the mainframe it's not about the
platform. Nobody denies that mainframes are insanely brilliant hardware
platforms. ING wanted to get rid of batch and move towards an event
driven architecture using pub/sub where they can easily deploy loosely
coupled micro-services to provide cutting edge products. The technology
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
Avro etc.  The retail banking industry has been disrupted by fintechs so
waiting for an overnight batch schedule for settlements is a competitive
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
applications is a VERY heavy lift.

https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
 <- read
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the
last year we've had 3 key resources move to 3 day weeks with a view to
retiring. Replacing highly skilled assembler programmers with deep
subsystem knowledge is proving to be difficult. Young people don't want
to learn HLASM as they consider it a dead-end. Their position is "why
invest 3-4 years learning a language that is useless if you move to
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and
significantly modernized. The small/medium shops will probably be all
gone. When I first moved to my current town in 1998 there were 25-30
mainframe sites. Now there are 3 and 1 is on life support. One of our
customers re-platformed their CICS/COBOL/Batch applications from a z9 to
a single blade server. It doesn't make any sense financially for a small
site to run a mainframe.
https://secure-web.cisco.com/1-2iTgedz9DPApFopeywjfCeLAkb4kS8D5gFCEDU1FxvGiDWA4ou6pqJyb1d_hBAvGUBtcA89RrAylX3opaG2YEyDaGkIhptpRdukdHvdGOJNKn5bruFlKlnigitV6PrV4n-6zInQkhkJJdSriM40VeYiNOpB8Pg3nTa5E6k6TTIOXSfdaiQOGk1Y6EXL4Xtu-wkeXJmwaPEZljVo3KuwR0K75lrsX8fDe2f2CjcjvfrM3ruLG4na4

Re: Some UNIX file usage questions

[Farley, Peter x23353]

Agreed; I did not spell out all the details, silly me.

close(old)
rename(old)
open(new)

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, June 19, 2022 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On Sun, 19 Jun 2022 19:45:49 +, Farley, Peter x23353  wrote:
>...
>For discretely split data files (stop writing at EOD/end-of-period and start a 
>new file) using the same approach as the unix syslog demon would seem to be 
>useful.  Rename current to current-plus-timed-qualifier (date and/or time), 
>
close(); open();
Otherwise you continue writing to the renamed file.

>... write new with initial data, proceed as before.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Most mainframes store transactions and process in batch? Are you the same guy 
who didn’t know pharmacies are open 24 by 7? 


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:03 PM, David Crayford  wrote:

On 20/06/2022 12:38 am, Seymour J Metz wrote:
> Keep in mind that the mainframe can only do batch processing, with input from 
> cards. It doesn't support anything like CICS, IMS or Sabre..

What have transactional systems like CICS or IMS got to do with 
real-time, straight-through processing? Most mainframe transactions 
store data that is later processed by batch, typically overnight. In the 
case of banking transactions that require inter-bank settlements this 
can cause delays of several days. In Australia the government mandated 
the NPP (New Payments Platform) which facilities instant payments using 
payids, which can be an email address, cellphone numbers etc. The API is 
a simple REST API using HTTP 
https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf.
 
It's my understanding that no bank implemented NPP on the mainframe. 
 From the presentations I've seen they used CDC to capture writes and 
then published events to Kafka, which was fanned out to different 
micro-services to do fraud detection, payments, push notifications etc. 
Back in the day straight-through processing was a pipe dream which is 
why we have overnight batch. It's a relic of applications written 
decades ago for very different hardware platforms.


> It's much better to run Linux than to get an IFL, which can only run batch.

I have no idea what you mean?

>
> Cynical? Moi?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Crayford [dcrayf...@gmail.com]
> Sent: Sunday, June 19, 2022 2:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
> AWS
>
> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
>> I also agree, but as a non-insider, I wanted to know what others were 
>> thinking. I also belive that in most cases, the effort spent trying to get 
>> off the mainframe would be better spent actually fixing the code running on 
>> it in the first place. Moving around broken code doesn't automatically fix 
>> it.
> It's not just about fixing broken code. If you read the ING CIO's
> remarks about why they wanted off the mainframe it's not about the
> platform. Nobody denies that mainframes are insanely brilliant hardware
> platforms. ING wanted to get rid of batch and move towards an event
> driven architecture using pub/sub where they can easily deploy loosely
> coupled micro-services to provide cutting edge products. The technology
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> Avro etc.  The retail banking industry has been disrupted by fintechs so
> waiting for an overnight batch schedule for settlements is a competitive
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> applications is a VERY heavy lift.
>
> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>  <- read
> the comments section. It's hilarious :)
>
> The doubly whammy is there's a skills crisis slowly unraveling. In the
> last year we've had 3 key resources move to 3 day weeks with a view to
> retiring. Replacing highly skilled assembler programmers with deep
> subsystem knowledge is proving to be difficult. Young people don't want
> to learn HLASM as they consider it a dead-end. Their position is "why
> invest 3-4 years learning a language that is useless if you move to
> another industry?" I can't comment about COBOL application developers.
>
> In 10 years time I expect the mainframe to be alive and kicking and
> significantly modernized. The small/medium shops will probably be all
> gone. When I first moved to my current town in 1998 there were 25-30
> mainframe sites. Now there are 3 and 1 is on life support. One of our
> customers re-platformed their CICS/COBOL/Batch applications from a z9 to
> a single blade server. It doesn't make any sense financially for a small
> site to run a mainframe.
> https://secure-web.cisco.com/1-2iTgedz9DPApFopeywjfCeLAkb4kS8D5gFCEDU1FxvGiDWA4ou6pqJyb1d_hBAvGUBtcA89RrAylX3opaG2YEyDaGkIhptpRdukdHvdGOJNKn5bruFlKlnigitV6PrV4n-6zInQkhkJJdSriM40VeYiNOpB8Pg3nTa5E6k6TTIOXSfdaiQOGk1Y6EXL4Xtu-wkeXJmwaPEZljVo3KuwR0K75lrsX8fDe2f2CjcjvfrM3ruLG4na4z

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 19:45:49 +, Farley, Peter x23353  wrote:
>...
>For discretely split data files (stop writing at EOD/end-of-period and start a 
>new file) using the same approach as the unix syslog demon would seem to be 
>useful.  Rename current to current-plus-timed-qualifier (date and/or time), 
>
close(); open();
Otherwise you continue writing to the renamed file.

>... write new with initial data, proceed as before.

-- 
gil

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

Re: Some UNIX file usage questions

[Bernd Oppolzer]

Am 19.06.2022 um 21:47 schrieb Paul Gilmartin:

On Sun, 19 Jun 2022 21:21:28 +0200, Bernd Oppolzer wrote:


See: if I don't use the DD:xxx method the fopen the files,
that is, if I specify DS-names on the fopen, the C runtime even does the
allocation for me
(SVC 99, IIRC), so that I even don't need a JCL allocation for the file.


How does that runtime handle ENQ conflicts?


I didn't think much about it so far; here is what I guess:

The runtime has the data set name, because it is specified instead of 
the DDname on the fopen.
It builds an artificial DDName like SYS000xx and does the dynamic 
allocation for this,
using some default file attributes (if it does not know otherwise from 
the second fopen parameter,
where you can specify recfm and blksize and so on ... which is an IBM C 
extension).

IIRC, the defaults are RECFM=VB and LRECL=1024.

The ENQ, AFAIK, is based on the DS-name, so the runtime can do the 
normal ENQ processing

as in the other cases.

The C runtime today is called "Language Environment", after all; it 
supports a great list
of other things, but it supported this C specific file I/O on OS files 
from the beginning

(early 1990s, I guess).

Kind regards

Bernd

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

Re: Some UNIX file usage questions

[Tony Harminc]

On Sun, 19 Jun 2022 at 14:30, Paul Gilmartin
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
[...]
> On Sun, 19 Jun 2022 20:04:47 +0200, Bernd Oppolzer wrote:
>
> >There should be no difference in behaviour (in principle), no matter if you
> >are writing to a classic MVS dataset or to a USS file.
> >
> In UNIX, the kernel completes the partial block.  Classic access methods 
> don't.

I'm not sure where the kernel comes into this. What UNIX service reads
and writes MVS datasets? Isn't it LE doing the work.

Tony H.

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

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 21:21:28 +0200, Bernd Oppolzer wrote:

>I don't code DISP=MOD, if I want to append data to an existing dataset;
>instead I use fopen with an "a" in the mode parameter.
> 
I wonder how the runtime handles that.  I suppose it could POINT to DS1LSTAR.

>My files have RECFM=FB, not FBS.
>
So irregular length blocks would be permissible.

But fileno() doesn't work, and streams aren't inherited  on fork().

>See: if I don't use the DD:xxx method the fopen the files,
>that is, if I specify DS-names on the fopen, the C runtime even does the
>allocation for me
>(SVC 99, IIRC), so that I even don't need a JCL allocation for the file.
>
How does that runtime handle ENQ conflicts?

-- 
gil

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

Re: Some UNIX file usage questions

[Farley, Peter x23353]

Rexx VSAM file access from TSO/batch/STC is supported by the RXVSAM package 
(CBT file 268).  Not sure if using RLS for an ESDS file would assist in the 
"timed writer, occasional reader" scheme the OP wants, but it might help if he 
wants to try that path.

It would seem to me to be easier to use the unix file approach though.  If I 
understand the unix file system storage structure at all, it is a "byte" 
stream, so any issue of "short blocks" as questioned by one earlier post are an 
irrelevant question.  Write-append just adds bytes to the end of the existing 
file inside the architected storage system.  Any needed storage efficiency 
issues are controlled at the kernel level, far below any application interface.

For discretely split data files (stop writing at EOD/end-of-period and start a 
new file) using the same approach as the unix syslog demon would seem to be 
useful.  Rename current to current-plus-timed-qualifier (date and/or time), 
write new with initial data, proceed as before.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, June 19, 2022 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On Sun, 19 Jun 2022 09:02:53 -0400, Steve Smith wrote:

>Well, I said ESDS; a KSDS would add useless complication and overhead.
> 
I said I was entirely VSAM-naive.

>Anyway, there doesn't seem to be any support for VSAM in REXX.  Not 
>sure about USS functions,
>
Are you thinking of: 
?
(That page is a mere fraction of what's available.)

>   ... but it seems much more straightforward to use USS files with USS 
>functions.
>
Amen.

>On Sat, Jun 18, 2022 at 5:05 PM Paul Gilmartin wrote:
>> ...
>> The KSDS method sounds promising.  I'm entirely VSAM-naive.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 2:53 am, Seymour J Metz wrote:

Systems like CICS *are* real-time, straight-through, although they can certainly create 
data for later batch processing. The point is that for half a century 
"mainframe" has included a wealth of applications that were not batch, and that 
the point of transactional subsytems was to get away from batch. There may be many valid 
reasons for getting away from a mainframe, but the belief that you need to do so in order 
to get away from batch is insane


You're still missing the point. CICS is a transaction monitor. I'm 
talking about real-time, continuous data feeds using middleware like 
Kafka as the central nervous system. This is a new concept and very 
different to traditional transaction processing + batch. Watch 
https://www.youtube.com/watch?v=x_rYEpRrdrA which is a microcosm of what 
many mainframe sites are doing. Almost every bank that I know of who run 
mainframes are doing something similar.





Similarly, the desire to use new APIs that are already available on the 
mainframe does not explain the desire to leave.


What APIs are you referring to?




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 20/06/2022 12:38 am, Seymour J Metz wrote:

Keep in mind that the mainframe can only do batch processing, with input from 
cards. It doesn't support anything like CICS, IMS or Sabre..

What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight. In the
case of banking transactions that require inter-bank settlements this
can cause delays of several days. In Australia the government mandated
the NPP (New Payments Platform) which facilities instant payments using
payids, which can be an email address, cellphone numbers etc. The API is
a simple REST API using HTTP
https://secure-web.cisco.com/1sBq5wh7NBIBtcLlnoe7mev6AZm4hzTAbw1IPjJa9kH6InoJ3U_Zwg7o9Mx_hc9VvcqSkO2GzjUCct8uA5cgnRrFTDuTMQtKKkcfMvJDb1lG83vYcBEiuvMNdKd-AF1d2oturWYl8cZaHKzA-Pdj-pyq3tHgfdJ5klsvrizH8LlkD_HYXieEshsP0famNedXtmoeOw5Urs-J_juVmfWlBLkL5DnxoSvjxKXs3irUVXLx3kIeGvCnSoZwaEeOhIw9o54Tm07SLXThtFfQSMhbhzK-GX34THADQG95_2Wf5Wm7VVHzxBSLvNCP4OVR5cUH1Blor-f81GcfMVs_XxpJ2-Z4_b4kClC7HDOWZLKqZGtSoXtnAaIXHkAeq2Pb3Q-S86UNOkXncePZm3DFQsAVpYKVN1zSAt5Hr9wo_ll03r2pE-zuCf5lLvXbyW6SSnZG_/https%3A%2F%2Fnppa.com.au%2Fwp-content%2Fuploads%2F2020%2F10%2FNPP-API-Framework-v4.0-Final.pdf.
It's my understanding that no bank implemented NPP on the mainframe.
  From the presentations I've seen they used CDC to capture writes and
then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.
Back in the day straight-through processing was a pipe dream which is
why we have overnight batch. It's a relic of applications written
decades ago for very different hardware platforms.



It's much better to run Linux than to get an IFL, which can only run batch.

I have no idea what you mean?


Cynical? Moi?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 19/06/2022 5:23 am, Enzo D'Amato wrote:

I also agree, but as a non-insider, I wanted to know what others were thinking. 
I also belive that in most cases, the effort spent trying to get off the 
mainframe would be better spent actually fixing the code running on it in the 
first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's
remarks about why they wanted off the mainframe it's not about the
platform. Nobody denies that mainframes are insanely brilliant hardware
platforms. ING wanted to get rid of batch and move towards an event
driven architecture using pub/sub where they can easily deploy loosely
coupled micro-services to provide cutting edge products. The technology
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
Avro etc.  The retail banking industry has been disrupted by fintechs so
waiting for an overnight batch schedule for settlements is a competitive
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
applications is a VERY heavy lift.

https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4

Re: Some UNIX file usage questions

[Bernd Oppolzer]

I don't code DISP=MOD, if I want to append data to an existing dataset;
instead I use fopen with an "a" in the mode parameter.

My files have RECFM=FB, not FBS.
I'm not aware of any restrictions; IMO, the C runtime handles all this.
IIRC, I always use DISP=SHR (this, maybe, is not true for the situation
where a file does not exist, and I open it first with fopen ("DD:xxx", 
"w") ...

but this is probably the only exception).

See: if I don't use the DD:xxx method the fopen the files,
that is, if I specify DS-names on the fopen, the C runtime even does the 
allocation for me

(SVC 99, IIRC), so that I even don't need a JCL allocation for the file.

...

IMO, the C runtime completes partial blocks, when a file is opened
with fopen (..., "wa"). This should be true for MVS classic files, as well.

fopen (..., "wa")
BTW
should be functional the same as a sequence of
fopen (..., "r");
then positioning to the end of the file using fseek and ftell
then fwrite ...

I understand why this cannot work with PDS members,
but with OS files, there is no problem, because ftell and fseek will 
work there, too.


Kind regards

Bernd



Am 19.06.2022 um 20:29 schrieb Paul Gilmartin:

On Sun, 19 Jun 2022 20:04:47 +0200, Bernd Oppolzer wrote:


... That is, if you do fopen ("dd:outfile","wa"),
a file allocated to OUTFILE which has some records already (in a block which
is not filled up completely) will be filled before the next empty block is 
allocated.

At least, this is my understanding, and everything else would be a shock for me.


I'm astonished.  Why then the restriction:


Do not code DISP=MOD if the data control block (DCB) specifies RECFM=FBS and 
the data set is processed by QSAM. If you do and a block is shorter than the 
specified block size, QSAM assumes that the short block is the last block and 
starts end-of-file processing. By this action, QSAM can embed short blocks in 
your data set and so affect the number of records per track.

(Sounds like non-anglophone usage.)


There should be no difference in behaviour (in principle), no matter if you
are writing to a classic MVS dataset or to a USS file.


In UNIX, the kernel completes the partial block.  Classic access methods don't.



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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

On Sun, 19 Jun 2022 at 18:42, Seymour J Metz  wrote:

> Well, I would normally advise using a zapmaker, but for something that
> trivial I would just code my own AMASPZAP input.
>

XMIT/RECEIVE also lets you edit load modules, and that's what I used to
change the BLKSIZE of IND$FILE from 6233 to 27998. ;)

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


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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Seymour J Metz]

Systems like CICS *are* real-time, straight-through, although they can 
certainly create data for later batch processing. The point is that for half a 
century "mainframe" has included a wealth of applications that were not batch, 
and that the point of transactional subsytems was to get away from batch. There 
may be many valid reasons for getting away from a mainframe, but the belief 
that you need to do so in order to get away from batch is insane.

Similarly, the desire to use new APIs that are already available on the 
mainframe does not explain the desire to leave.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 20/06/2022 12:38 am, Seymour J Metz wrote:
> Keep in mind that the mainframe can only do batch processing, with input from 
> cards. It doesn't support anything like CICS, IMS or Sabre..

What have transactional systems like CICS or IMS got to do with
real-time, straight-through processing? Most mainframe transactions
store data that is later processed by batch, typically overnight. In the
case of banking transactions that require inter-bank settlements this
can cause delays of several days. In Australia the government mandated
the NPP (New Payments Platform) which facilities instant payments using
payids, which can be an email address, cellphone numbers etc. The API is
a simple REST API using HTTP
https://secure-web.cisco.com/1sBq5wh7NBIBtcLlnoe7mev6AZm4hzTAbw1IPjJa9kH6InoJ3U_Zwg7o9Mx_hc9VvcqSkO2GzjUCct8uA5cgnRrFTDuTMQtKKkcfMvJDb1lG83vYcBEiuvMNdKd-AF1d2oturWYl8cZaHKzA-Pdj-pyq3tHgfdJ5klsvrizH8LlkD_HYXieEshsP0famNedXtmoeOw5Urs-J_juVmfWlBLkL5DnxoSvjxKXs3irUVXLx3kIeGvCnSoZwaEeOhIw9o54Tm07SLXThtFfQSMhbhzK-GX34THADQG95_2Wf5Wm7VVHzxBSLvNCP4OVR5cUH1Blor-f81GcfMVs_XxpJ2-Z4_b4kClC7HDOWZLKqZGtSoXtnAaIXHkAeq2Pb3Q-S86UNOkXncePZm3DFQsAVpYKVN1zSAt5Hr9wo_ll03r2pE-zuCf5lLvXbyW6SSnZG_/https%3A%2F%2Fnppa.com.au%2Fwp-content%2Fuploads%2F2020%2F10%2FNPP-API-Framework-v4.0-Final.pdf.
It's my understanding that no bank implemented NPP on the mainframe.
 From the presentations I've seen they used CDC to capture writes and
then published events to Kafka, which was fanned out to different
micro-services to do fraud detection, payments, push notifications etc.
Back in the day straight-through processing was a pipe dream which is
why we have overnight batch. It's a relic of applications written
decades ago for very different hardware platforms.


> It's much better to run Linux than to get an IFL, which can only run batch.

I have no idea what you mean?

>
> Cynical? Moi?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> David Crayford [dcrayf...@gmail.com]
> Sent: Sunday, June 19, 2022 2:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and 
> AWS
>
> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
>> I also agree, but as a non-insider, I wanted to know what others were 
>> thinking. I also belive that in most cases, the effort spent trying to get 
>> off the mainframe would be better spent actually fixing the code running on 
>> it in the first place. Moving around broken code doesn't automatically fix 
>> it.
> It's not just about fixing broken code. If you read the ING CIO's
> remarks about why they wanted off the mainframe it's not about the
> platform. Nobody denies that mainframes are insanely brilliant hardware
> platforms. ING wanted to get rid of batch and move towards an event
> driven architecture using pub/sub where they can easily deploy loosely
> coupled micro-services to provide cutting edge products. The technology
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> Avro etc.  The retail banking industry has been disrupted by fintechs so
> waiting for an overnight batch schedule for settlements is a competitive
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> applications is a VERY heavy lift.
>
> https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
>  <- read
> the comments section. It's hilarious :)
>
> The doubly whammy is there's a skills crisis s

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 18:33:42 +, Seymour J Metz wrote:
>
>Are you claiming that syscall is a convenient way to do I/O in REXX? I find 
>ANSI stream I/O to be much cleaner. 
> 
Make lemonade.

Does ANSI stream I/O provide full control of such as O_CREAT, O_EXCL,
O_TRUNC, O_APPEND, ... as syscall does?

-- 
gil

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Seymour J Metz]

Well, I would normally advise using a zapmaker, but for something that trivial 
I would just code my own AMASPZAP input.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Sunday, June 19, 2022 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options

I'm using, don't ask, the V2.3.0 Optimizing Compiler on, don't ask, z/OS
1.10 ADCD running under, OK enough.

I've managed to find out that the library routine to print the COUNT table
is IBMFEFCA, by doing a SRCHFOR for "GRAND", and by copying it into my
ISPPLIB, I've actually got a disassembly via the DISASM function of ISRDDN.
Now I just need to know how many and which of the, I guess, three BNP
instructions need to be changed into a BNZ, and yes, even a complete
assembler noob like me can do that without the usual tools. If anyone
(privately) likes to help me, feel free to contact me in private.

Robert

On Sun, 19 Jun 2022 at 17:42, Seymour J Metz  wrote:

> Is it the same in Version 2? Which is the OP using?
>
>
> --
> 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: Saturday, June 18, 2022 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options
>
> On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> wrote:
>
> > Does anyone know which library modules are responsible for the
> > implementation of these two compiler options, and more precisely, for the
> > reporting of statement counts, as I need to (try to) patch the latter,
> > given that it treats negative counts as zero, and I now have a program
> > where four of the counts have turned negative, because the statements are
> > executed more than 2^31-1 times.
>
> According to
> http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> you want module IBMBEFL.
>
> In that book, look at page 141 onwards for the description of how
> things work, and for the Flow data area, page 369. I'm not seeing
> right away where the Count info is stored, but I'm sure you can figure
> it out from there...
>
> 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
>


--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 

Some REXX code for use on z/OS


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

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

Re: Some UNIX file usage questions

[Seymour J Metz]

Nothing in Rexx is part of UNIX®.

Are you claiming that syscall is a convenient way to do I/O in REXX? I find 
ANSI stream I/O to be much cleaner. 


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, June 19, 2022 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On Sun, 19 Jun 2022 14:53:31 +, Seymour J Metz  wrote:
>
>Stream I/O is not part of UNIX�,
>
"not" ???

>... and is available with any ANSI compliant Rexx, e.g., Regina. Alas, 
> TSO/E REXX is not ANSI compliant
>
Alas.

>... and IBM only supports stream I/O in Unix shells. I'm not aware of any 
> convenient Unix facilities for accessing files within REXX.
>
If you had read further in the thread:
Are you thinking of: 
?
(That page is a mere fraction of what's available.)
More at: 

z/OS Using REXX and z/OS UNIX System Services
bpxb600_v2r5.pdf

--
gil

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

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

Re: Debit vs Credit card for cash at ATM? [was: RE: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS]

[Bob Bridges]

It was at length, wasn't it?  Sorry, I just felt I had to explain how I got
into the weird habit.

You must be right; it happens I just learned that my current credit score,
at least until last night, was pretty high.

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

/* The federal budget deficit continued to worsen, despite the concerted
effort of virtually every elected official in Washington -- Republican or
Democrat -- to spend more money.  -Dave Barry, 2004 in Review */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Sunday, June 19, 2022 13:28

Right, with low interest rates on bank accounts (and you're not prepaying
enough to be worth investing) the "borrowing" is insignificant. This is a
tried-and-true method of restoring credit. It also "cheats" the system
(yay!) by lowering your debt-to-credit ratio: each month when the various
folks look at your credit, they see (obviously I'm making up these numbers,
and ignoring things like mortgage, which I believe factor in but obviously
very differently from unsecured credit card debt):

Credit limit: $10K
Credit card balance: -$1K

That's obviously a VERY positive net debt-to-credit ratio, and works in your
favor. I look at my credit rating occasionally, and it varies by a few
points. This is often directly dependent on how much I've spent recently,
even though I NEVER carry a balance. That's because the various folks who
report it (I have a couple of cards that do it for free) look at me at
different times. So if they happen to pick a day just after my primary card
balance was paid, I look better to them. When we had roof/siding done 10
years ago and put it all on cards (yay points!), it went down noticeably the
next month, then back up.

Net: I see your approach as a plus for you all 'round. You're getting
whatever other benefits the card offers, not having to use debit (which is
riskier, since it has less protections both in terms of breach and against
the merchant not delivering), and raising your credit score-all at a cost of
a buck or two a month in "lost" interest, max!

--- Bob Bridges wrote at length, ending with:
> I simply put a few thousand on the card, as though it was a pre-paid.
The
> credit limit is back up to a usable level now, but I'm still in the habit:
I
> keep a negative balance on the card.

>Yeah, yeah, I know they're profiting from "borrowing" my money.  But I pay
the
> same either way, so I can't see that it makes a difference to me.  Are
there
> disadvantages I'm missing?

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

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 20:04:47 +0200, Bernd Oppolzer wrote:

>... That is, if you do fopen ("dd:outfile","wa"),
>a file allocated to OUTFILE which has some records already (in a block which
>is not filled up completely) will be filled before the next empty block is 
>allocated.
>
>At least, this is my understanding, and everything else would be a shock for 
>me.
> 
I'm astonished.  Why then the restriction:


Do not code DISP=MOD if the data control block (DCB) specifies RECFM=FBS and 
the data set is processed by QSAM. If you do and a block is shorter than the 
specified block size, QSAM assumes that the short block is the last block and 
starts end-of-file processing. By this action, QSAM can embed short blocks in 
your data set and so affect the number of records per track.

(Sounds like non-anglophone usage.)

>There should be no difference in behaviour (in principle), no matter if you
>are writing to a classic MVS dataset or to a USS file.
>
In UNIX, the kernel completes the partial block.  Classic access methods don't.

-- 
gil

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Charles Mills]

@Enzo, don't say I didn't warn you. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, June 19, 2022 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

Keep in mind that the mainframe can only do batch processing, with input
from cards. It doesn't support anything like CICS, IMS or Sabre.. It's much
better to run Linux than to get an IFL, which can only run batch.

Cynical? Moi?

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Charles Mills]

Yeah, after I wrote that I thought perhaps I was going off half-cocked.

The fact is still, however, that the *effective* exposure is $zero. You can
make your financial decisions as though it were otherwise, of course; that
is your privilege.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Sunday, June 19, 2022 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

No, the limit for a debit card is $500.00. Perhaps you're thinking of a
credit card, for which the limit is $50.00.

Again, that's why I don't and won't have a debit card.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Friday, June 17, 2022 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

As Phil says (1) the limit is $50, not $500; and (2) for all practical
purposes the limit is $0. Does anyone here know anyone who has ever gotten
dinged for more than $0?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, June 17, 2022 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

Plus even if the fraud was by an employee issuing the card, you're still on
the hook. Thanks but no thanks.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 17, 2022 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

The debit card loss is max $500 as long as you report it stolen within 60
days. After 60, unlimited. Agree with you about never having one.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconsumer.f
%2F&data=05%7C01%7Csmetz3%40gmu.edu%7Ca6ba78cd639440f5dde208da50b07e08%7
C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637911016213051643%7CUnknown%7CT
WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=gTyEYxT9DiX%2BJsUBN4XxMju2XyJe9SaVxgGPOI%2F0AhE%
3D&reserved=0
tc.gov%2Farticles%2Flost-or-stolen-credit-atm-debit-cards%23limit&data=0
5%7C01%7Csmetz3%40gmu.edu%7C125d22a6b7324b05640908da50a84fd6%7C9e857255df574
c47a0c00546460380cb%7C0%7C0%7C637910981072007504%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
%7C&sdata=ugEJ53tbY1rmlt3mS25zlEWkLfmwQjvT35Vryv5DCsc%3D&reserved=0





Sent from Yahoo Mail for iPhone


On Friday, June 17, 2022, 5:20 PM, Seymour J Metz  wrote:

In the US, under certain circumstances, there is a $50 cap on fraud losses
with credit cards but the cap for debit cards is $500. That's why I don't
have a debit card and don't plan to eveer have one, absent a change in the
law.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 17, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

I’ve had at least a dozen credit cards compromised in the last 20 years.
Including JPM. So much for the great non mainframe security & fraud
protection. With credit cards, I’m not on the hook for anything, and they
send me a new card overnight. Not true of debit cards. Your losses can be
infinite.

I get hundreds of spam emails on Yahoo daily. But, it’s not my main email
service. It’s disposable. No fear whatsoever.


Sent from Yahoo Mail for iPhone


On Friday, June 17, 2022, 2:28 PM, David Crayford 
wrote:

On 18/06/2022 2:20 am, Bill Johnson wrote:
> Here you go. Mainframe jobs you can apply for with JPM.

LOLZ! What's that got to do with anything?

>
>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linked
%2F&data=05%7C01%7Csmetz3%40gmu.edu%7Ca6ba78cd639440f5dde208da50b07e08%7
C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637911016213051643%7CUnknown%7CT
WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
D%7C3000%7C%7C%7C&sdata=XwB866Ef5SKaUTXOTcxUhmu3aEkF%2BGxW15WEtHQo1Rk%3D
&reserved=0
in.com%2Fjobs%2Fjpmorgan-chase-mainframe-jobs&data=05%7C01%7Csmetz3%40gm
u.edu%7C125d22a6b7324b05640908da50a84fd6%7C9e857255df574c47a0c00546460380cb%
7C0%7C0%7C637910981072007504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=784OFW
QQ%2BS%2BASGLIz1JXqr6TlsSN%2F

Re: Debit vs Credit card for cash at ATM? [was: RE: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS]

[Seymour J Metz]

That $50 cap is for credit cards; the liability cap for debit cards is ten 
times higher.

No, I've never be dinged, but why put myself at risk?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Friday, June 17, 2022 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Debit vs Credit card for cash at ATM? [was: RE: Modernize 
Mainframe Applications for Hybrid Cloud with IBM and AWS]

Peter Farley wrote:

>Curious - How do you get cash at an ATM directly from your checking or
savings account without a bank debit card?



Right, your ATM card is a debit card. The question is typically whether you
use it as PIN debit, as signature debit, or only as an ATM card.



Signature debit has more protections than PIN debit (if your card has a Visa
or Mastercard logo on it, you can use it as signature debit-that is, like
it's a credit card, swiped/inserted/tapped without entering a PIN) and
settlement happens after the fact, again like credit. If you use it as PIN
debit, settlement is instantaneous, and as others have noted, liability is
higher. The risk that makes some of us never use our ATM cards as debit
cards is that those transactions run on mostly the same rails as credit
transactions, including opportunities for compromise (cf. Target,
Nieman-Marcus, THD, et al.). If you ONLY ever use it with a bank, you're
reducing your risk significantly, since it's Someone Else's Money that will
get drained in a breach.



>Using a credit card to get cash from an ATM usually means drawing "Cash
Advance" money on that card, which is subject to interest costs on the
credit cards I own.



I've used my ATM card occasionally at foreign banks to get cash. Nowadays,
if I were traveling internationally, I might use my corporate credit card
instead, assuming it works for that.



Re card breach liability: yes, there's theoretically a $50 cap; de facto, it
seems to be $0. I've never found anyone who's gotten hit for the $50, and
I've asked hundreds of folks at dozens of presentations I've given on
Payments. I have an unconfirmed theory that if you're a deadbeat-behind on
payments, huge balance, etc.-they might try to ding you, but otherwise
they're not going to risk ticking you off over pennies like that.



Pennies, you say? "Don't those $50 add up?" Not in their eyes: the stats
I've seen show card fraud as pretty stable, around $5-7B/year, against
revenues of $300B (against transactions of $3T-note revenue = ten cents on
the dollar, including late fees, interest, etc.!). Losses to fraud and
bankruptcy are on the order of $50B. So they don't want fraud to increase,
but aren't panicked about it at its current level, really don't care. What
they worry about is that you lose confidence and stop using their cards.


--
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: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

I'm using, don't ask, the V2.3.0 Optimizing Compiler on, don't ask, z/OS
1.10 ADCD running under, OK enough.

I've managed to find out that the library routine to print the COUNT table
is IBMFEFCA, by doing a SRCHFOR for "GRAND", and by copying it into my
ISPPLIB, I've actually got a disassembly via the DISASM function of ISRDDN.
Now I just need to know how many and which of the, I guess, three BNP
instructions need to be changed into a BNZ, and yes, even a complete
assembler noob like me can do that without the usual tools. If anyone
(privately) likes to help me, feel free to contact me in private.

Robert

On Sun, 19 Jun 2022 at 17:42, Seymour J Metz  wrote:

> Is it the same in Version 2? Which is the OP using?
>
>
> --
> 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: Saturday, June 18, 2022 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options
>
> On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> wrote:
>
> > Does anyone know which library modules are responsible for the
> > implementation of these two compiler options, and more precisely, for the
> > reporting of statement counts, as I need to (try to) patch the latter,
> > given that it treats negative counts as zero, and I now have a program
> > where four of the counts have turned negative, because the statements are
> > executed more than 2^31-1 times.
>
> According to
> http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> you want module IBMBEFL.
>
> In that book, look at page 141 onwards for the description of how
> things work, and for the Flow data area, page 369. I'm not seeing
> right away where the Count info is stored, but I'm sure you can figure
> it out from there...
>
> 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
>


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


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

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 17:36:28 +, Seymour J Metz  wrote:

>Does Unix System Services support RECFM=FBS? If it does, then fopen needs to 
>properly handle short blocks for append.
>
Probably not.  Even QSAM can't do that, even though it should. Submit an RFE.

Or RYO with BSAM.

There's an argument here for using UNIX files rather than Classic
data sets.

___
On Sun, 19 Jun 2022 17:40:17 +, Seymour J Metz  wrote:

>I'm a REXX bigot, but updating a shared Unix file with appropriate 
>serialization might be easier in, e.g., Java, Perl, Python.
>
I believe the OP envisioned only one writer with zero or more concurrent 
readers.

I've done it in shell.

But in another case I went to SR with a performance problem with O_APPEND.
WAD.  O_APPEND imposes serialization overhead even though I was the
only writer.  I suppose a single writer might stat(); seek(); write() to avoid 
the
serialization overhead.

-- 
gil

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Seymour J Metz]

No, the limit for a debit card is $500.00. Perhaps you're thinking of a credit 
card, for which the limit is $50.00.

Again, that's why I don't and won't have a debit card.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, June 17, 2022 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

As Phil says (1) the limit is $50, not $500; and (2) for all practical
purposes the limit is $0. Does anyone here know anyone who has ever gotten
dinged for more than $0?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Friday, June 17, 2022 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

Plus even if the fraud was by an employee issuing the card, you're still on
the hook. Thanks but no thanks.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 17, 2022 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

The debit card loss is max $500 as long as you report it stolen within 60
days. After 60, unlimited. Agree with you about never having one.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconsumer.f%2F&data=05%7C01%7Csmetz3%40gmu.edu%7Ca6ba78cd639440f5dde208da50b07e08%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637911016213051643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gTyEYxT9DiX%2BJsUBN4XxMju2XyJe9SaVxgGPOI%2F0AhE%3D&reserved=0
tc.gov%2Farticles%2Flost-or-stolen-credit-atm-debit-cards%23limit&data=0
5%7C01%7Csmetz3%40gmu.edu%7C125d22a6b7324b05640908da50a84fd6%7C9e857255df574
c47a0c00546460380cb%7C0%7C0%7C637910981072007504%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
%7C&sdata=ugEJ53tbY1rmlt3mS25zlEWkLfmwQjvT35Vryv5DCsc%3D&reserved=0





Sent from Yahoo Mail for iPhone


On Friday, June 17, 2022, 5:20 PM, Seymour J Metz  wrote:

In the US, under certain circumstances, there is a $50 cap on fraud losses
with credit cards but the cap for debit cards is $500. That's why I don't
have a debit card and don't plan to eveer have one, absent a change in the
law.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 17, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
AWS

I’ve had at least a dozen credit cards compromised in the last 20 years.
Including JPM. So much for the great non mainframe security & fraud
protection. With credit cards, I’m not on the hook for anything, and they
send me a new card overnight. Not true of debit cards. Your losses can be
infinite.

I get hundreds of spam emails on Yahoo daily. But, it’s not my main email
service. It’s disposable. No fear whatsoever.


Sent from Yahoo Mail for iPhone


On Friday, June 17, 2022, 2:28 PM, David Crayford 
wrote:

On 18/06/2022 2:20 am, Bill Johnson wrote:
> Here you go. Mainframe jobs you can apply for with JPM.

LOLZ! What's that got to do with anything?

>
>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linked%2F&data=05%7C01%7Csmetz3%40gmu.edu%7Ca6ba78cd639440f5dde208da50b07e08%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637911016213051643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XwB866Ef5SKaUTXOTcxUhmu3aEkF%2BGxW15WEtHQo1Rk%3D&reserved=0
in.com%2Fjobs%2Fjpmorgan-chase-mainframe-jobs&data=05%7C01%7Csmetz3%40gm
u.edu%7C125d22a6b7324b05640908da50a84fd6%7C9e857255df574c47a0c00546460380cb%
7C0%7C0%7C637910981072007504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=784OFW
QQ%2BS%2BASGLIz1JXqr6TlsSN%2FizVE4qA6Clbkns%3D&reserved=0
>
> Be careful however because LinkedIn has some serious scam issues. Likely
because it’s on the cloud.

If you fear the cloud so much then stop using Yahoo mail, your bank
cards, entertainment services such as Netflix. Stock up on rations and
batton down the hatches and bunker down ;)

Do you worry that using a cloud based service like Yahoo mail may
compromise your cellphone?

>
>
https://secure-web.cisco.com/1a-kk_waopn-qFFy4YKhpV3UFGHUrt4JHRFYT1D0tsvgsqP
egeIx45CYbmjqCuigB4N32lo-7AbIf9o6d5qh9dTC9

Re: Some UNIX file usage questions

[Bernd Oppolzer]

I am talking about classic MVS datasets all the time;
not sure about USS files.

With classic MVS datasets (RECFM=FB), the C runtime supports large blocks
even with short record lengths. That is, if you do fopen ("dd:outfile", 
"wa"),
a file allocated to OUTFILE which has some records already (in a block 
which
is not filled up completely) will be filled before the next empty block 
is allocated.


At least, this is my understanding, and everything else would be a shock 
for me.


There should be no difference in behaviour (in principle), no matter if you
are writing to a classic MVS dataset or to a USS file.

Kind regards

Bernd


Am 19.06.2022 um 19:36 schrieb Seymour J Metz:

Does Unix System Services support RECFM=FBS? If it does, then fopen needs to 
properly handle short blocks for append.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Saturday, June 18, 2022 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

I am very sure that if you issue fopen (with "append")
on a file with, say, LRECL = 24 and BLKSIZE = 9600, which has
one record and one block with only one record in it,
and you write a second record, that then this file will still have
one block, but now two records.

At least this is what I expect from the C runtime.

Kind regards

Bernd


Am 18.06.2022 um 21:23 schrieb Steve Smith:

QSAM to a traditional PS file with the process you described is certainly
going to write only short blocks.  Given the amount of data involved, would
it matter?

However, besides USS files, you could consider an ESDS.  VSAM maintains its
CISIZE and blocksize quite rigorously.  And it should be very safe.

sas

--
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: Debit vs Credit card for cash at ATM? [was: RE: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS]

[Seymour J Metz]

I've never had a card cancelled because of breches or early payoff, but I do 
have a card on which I explicitly requested a low limit start cap creeping.

Way back in the 1960s there were still bamks doing accounting on EAM equipment 
or computers programmed to look like old EAM processes. I once overpaaid a CC 
bill and the next month's statement was hand processed. I assume that no bank 
has that particular issue any more.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Friday, June 17, 2022 9:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Debit vs Credit card for cash at ATM? [was: RE: Modernize 
Mainframe Applications for Hybrid Cloud with IBM and AWS]

I've been caught in only one breach (that I know of).  But that sort of
thing is the main reason I try to use PayPal as much as possible for on-line
shopping.  It's not that I assume PayPay will take better care of my data
than other vendors (though I hope they do) - but I like giving my card to
only one vendor rather than many, thus reducing my risk.

I'd be interested in some knowledgeable cove's comments on something else I
do with my credit card that I don't think I've heard anyone else admit to.
I had a single credit card for years - decades, I guess - and every so often
the issuer raised the credit limit.  ("You've been very responsible with
your card.  Here's a new credit limit:  Go be just a little less
responsible, please, take a vacation or something!")  It got up to I think
$24 000 or thereabouts, and then ten or twelve years back I caught swine flu
and spent some months in the hospital, then some months more in a sort of
rehab facility.  (It was really an old-folks' home, but the point was that
there were PTs there to help me recover, walk again etc).  I wasn't able to
work for almost a year, from Christmas Eve to about Thanksgiving, and for a
while I had to let my credit-card balance rise.

Once I was able to start making payments again, I paid it off pretty quickly
- but the card issuer reduced my available balance every time I paid off
more, then canceled the card in the end.  I was eventually issued a new
card, but with a very low credit limit - and my work used to involve travel,
ie airfare, car rental and hotels.  This card wasn't going to cut it.

It took me a while to realize that the solution was simple: I simply put a
few thousand on the card, as though it was a pre-paid.  The credit limit is
back up to a usable level now, but I'm still in the habit:  I keep a
negative balance on the card.

Yeah, yeah, I know they're profiting from "borrowing" my money.  But I pay
the same either way, so I can't see that it makes a difference to me.  Are
there disadvantages I'm missing?

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

/* Do not hit at all if it can be avoided, but never hit softly.  -Theodore
Roosevelt */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Friday, June 17, 2022 18:21

Re card breach liability: yes, there's theoretically a $50 cap; de facto, it
seems to be $0. I've never found anyone who's gotten hit for the $50, and
I've asked hundreds of folks at dozens of presentations I've given on
Payments. I have an unconfirmed theory that if you're a deadbeat-behind on
payments, huge balance, etc.-they might try to ding you, but otherwise
they're not going to risk ticking you off over pennies like that.

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[David Crayford]

On 20/06/2022 12:38 am, Seymour J Metz wrote:

Keep in mind that the mainframe can only do batch processing, with input from 
cards. It doesn't support anything like CICS, IMS or Sabre..


What have transactional systems like CICS or IMS got to do with 
real-time, straight-through processing? Most mainframe transactions 
store data that is later processed by batch, typically overnight. In the 
case of banking transactions that require inter-bank settlements this 
can cause delays of several days. In Australia the government mandated 
the NPP (New Payments Platform) which facilities instant payments using 
payids, which can be an email address, cellphone numbers etc. The API is 
a simple REST API using HTTP 
https://nppa.com.au/wp-content/uploads/2020/10/NPP-API-Framework-v4.0-Final.pdf. 
It's my understanding that no bank implemented NPP on the mainframe. 
From the presentations I've seen they used CDC to capture writes and 
then published events to Kafka, which was fanned out to different 
micro-services to do fraud detection, payments, push notifications etc. 
Back in the day straight-through processing was a pipe dream which is 
why we have overnight batch. It's a relic of applications written 
decades ago for very different hardware platforms.




It's much better to run Linux than to get an IFL, which can only run batch.


I have no idea what you mean?



Cynical? Moi?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 19/06/2022 5:23 am, Enzo D'Amato wrote:

I also agree, but as a non-insider, I wanted to know what others were thinking. 
I also belive that in most cases, the effort spent trying to get off the 
mainframe would be better spent actually fixing the code running on it in the 
first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's
remarks about why they wanted off the mainframe it's not about the
platform. Nobody denies that mainframes are insanely brilliant hardware
platforms. ING wanted to get rid of batch and move towards an event
driven architecture using pub/sub where they can easily deploy loosely
coupled micro-services to provide cutting edge products. The technology
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
Avro etc.  The retail banking industry has been disrupted by fintechs so
waiting for an overnight batch schedule for settlements is a competitive
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
applications is a VERY heavy lift.

https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
 <- read
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the
last year we've had 3 key resources move to 3 day weeks with a view to
retiring. Replacing highly skilled assembler programmers with deep
subsystem knowledge is proving to be difficult. Young people don't want
to learn HLASM as they consider it a dead-end. Their position is "why
invest 3-4 years learning a language that is useless if you move to
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and
significantly modernized. The small/medium shops will probably be all
gone. When I first moved to my current town in 1998 there were 25-30
mainframe sites. Now there are 3 and 1 is on life support. One of our
customers re-platformed their CICS/COBOL/Batch applications from a z9 to
a single blade server. It doesn't make any sense financially for a small
site to run a mainframe.
https://secure-web.cisco.com/1-2iTgedz9DPApFopeywjfCeLAkb4kS8D5gFCEDU1FxvGiDWA4ou6pqJyb1d_hBAvGUBtcA89RrAylX3opaG2YEyDaGkIhptpRdukdHvdGOJNKn5bruFlKlnigitV6PrV4n-6zInQkhkJJdSriM40VeYiNOpB8Pg3nTa5E6k6TTIOXSfdaiQOGk1Y6EXL4Xtu-wkeXJmwaPEZljVo3KuwR0K75lrsX8fDe2f2CjcjvfrM3ruLG4na4zrAU_pR4DViMh7bKBhJ35a94VHU7GR4Vh_mXKaYwtbhwnRJWR8gVkvYjmB2CjTOIxJE52bNN1-82_fpYopX-kZQntDkR4OKjvj-b1AV9yXlGQ3A-eGFbtuCb0_1t2R9tgZ5MqgMbzxGQKIf78I2U_xq8a9qYywx3_OgfQwbeMgd8fiatdC5CbUSlphDlQfSDw9sOErejC7z/https%3A%2F%2Fwww.itnews.com.au%2Fnews%2Fwa-insurance-commission-decommissions-mainframe-322780


Get BlueMail for 
Android

Re: Some UNIX file usage questions

[Seymour J Metz]

Would a named pipe suit your needs?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Saturday, June 18, 2022 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Some UNIX file usage questions

Hope some of you can help out a dinosaur. 

I am designing a z/OS application (for in-house use, not an ISV product). It
will consist of a started task that runs continuously plus one or more small
reporting programs, one of them to be run daily shortly after midnight. The
started task will record a very small amount of data (about 24 bytes or so)
every fifteen minutes, 96 times a day. That data will be input to the
reporting program(s).

Being a dinosaur, I thought in terms of recording that information in a
traditional MVS dataset. There are some problems with that: basically if I
do allocate, open, write, close, de-allocate then I think I am going to have
24-byte blocks on disk*, which is going to give me really poor track
utilization; and if I don't, then the report program is not going to be able
to read the dataset due to ENQ contention (absent some sort of special
"close it for a little while around midnight" logic) and also any abnormal
termination of the started task (such as an IPL) will cause a loss of data
-- not a critical issue, but less than desirable.

*Yeah, emulated blocks on emulated tracks. There are of course no real
tracks anymore. But the emulation is pretty realistic, right down to the
poor track utilization!

I thought about various approaches such as accumulating the records in
memory and then writing all 96 of them in a single blast right after
midnight. That would probably work out and solve the ENQ problem (but not
the IPL problem). It would unfortunately preclude any ad hoc reporting in
the middle of the day. And I would still end up with fairly small 2K blocks.

This morning I thought "why not a UNIX file?" I can of course look up any
specific questions in the relevant manuals, but I am just unfamiliar with
the big picture. Am I correct that (1) there is of course no "physical block
size/track utilization" issue with UNIX files; (2) that shortly after I
write a record it will be fixed in place and would survive an IPL or other
abnormal termination of the writing task; and (3) most importantly, the
report program can read the file while the writing task has it open? Are
those premises correct? (By "shortly after" I mean that I could live with a
delay of a few minutes or so; this is not a banking application where
two-phase commit is critical.)

I picture writing the started task in Rexx, so I would have to write to a DD
name allocated to the UNIX file (either dynamically or with JCL), not with
"native" C fopen(), fwrite(), etc. Does that change any of the answers?

Anyone see any gotcha's with the UNIX file approach that I seem not to have
thought of?

Thanks!

Charles

--
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: Old PL/I Optimizing compiler - COUNT & FLOW options

[Seymour J Metz]

Is it the same in Version 2? Which is the OP using?


--
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: Saturday, June 18, 2022 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options

On Sat, 18 Jun 2022 at 08:53, Robert Prins  wrote:

> Does anyone know which library modules are responsible for the
> implementation of these two compiler options, and more precisely, for the
> reporting of statement counts, as I need to (try to) patch the latter,
> given that it treats negative counts as zero, and I now have a program
> where four of the counts have turned negative, because the statements are
> executed more than 2^31-1 times.

According to 
http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
you want module IBMBEFL.

In that book, look at page 141 onwards for the description of how
things work, and for the Flow data area, page 369. I'm not seeing
right away where the Count info is stored, but I'm sure you can figure
it out from there...

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: Some UNIX file usage questions

[Seymour J Metz]

I'm a REXX bigot, but updating a shared Unix file with appropriate 
serialization might be easier in, e.g., Java, Perl, Python.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Saturday, June 18, 2022 2:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

Thanks!

Yes, I am familiar with the basics of UNIX I/O. I have written a couple of 
large applications in C++ so I have used fopen() and friends mostly for 
conventional MVS datasets but also for UNIX files. I just don't have much "big 
picture" usage experience with UNIX files beyond "yes, I write them, and the 
customers can do what they want with them." I have used fsync(). I know what an 
fd is but have more experience with FILE* (fopen() and fwrite() rather than 
open() and write()).

Thanks for the suggestions on using SYSCALLS rather than EXECIO. That would 
make a lot more sense, assuming I do end up using a UNIX file. I have used 
SYSCALLS but for sleep, not for I/O.

I don't "want" an ENQ. ENQ is the problem, not the solution . I picture one 
repetitive writer and one or more occasional readers, so there would be no 
write contention or confusion.

Thanks for your help! I am thinking that a UNIX file + Rexx with SYSCALLS will 
be the way to go.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Saturday, June 18, 2022 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On Sat, Jun 18, 2022 at 11:52 AM Charles Mills  wrote:

> Hope some of you can help out a dinosaur. 
>

One dino to another, I'll try.



>
> I am designing a z/OS application (for in-house use, not an ISV product).
> It
> will consist of a started task that runs continuously plus one or more
> small
> reporting programs, one of them to be run daily shortly after midnight. The
> started task will record a very small amount of data (about 24 bytes or so)
> every fifteen minutes, 96 times a day. That data will be input to the
> reporting program(s).
>
> Being a dinosaur, I thought in terms of recording that information in a
> traditional MVS dataset. There are some problems with that: basically if I
> do allocate, open, write, close, de-allocate then I think I am going to
> have
> 24-byte blocks on disk*, which is going to give me really poor track
> utilization; and if I don't, then the report program is not going to be
> able
> to read the dataset due to ENQ contention (absent some sort of special
> "close it for a little while around midnight" logic) and also any abnormal
> termination of the started task (such as an IPL) will cause a loss of data
> -- not a critical issue, but less than desirable.
>
> *Yeah, emulated blocks on emulated tracks. There are of course no real
> tracks anymore. But the emulation is pretty realistic, right down to the
> poor track utilization!
>
> I thought about various approaches such as accumulating the records in
> memory and then writing all 96 of them in a single blast right after
> midnight. That would probably work out and solve the ENQ problem (but not
> the IPL problem). It would unfortunately preclude any ad hoc reporting in
> the middle of the day. And I would still end up with fairly small 2K
> blocks.
>
> This morning I thought "why not a UNIX file?" I can of course look up any
> specific questions in the relevant manuals, but I am just unfamiliar with
> the big picture. Am I correct that (1) there is of course no "physical
> block
> size/track utilization" issue with UNIX files; (2) that shortly after I
> write a record it will be fixed in place and would survive an IPL or other
> abnormal termination of the writing task; and (3) most importantly, the
> report program can read the file while the writing task has it open? Are
> those premises correct? (By "shortly after" I mean that I could live with a
> delay of a few minutes or so; this is not a banking application where
> two-phase commit is critical.)
>

I sometimes do this. UNIX files are not written directly to disk by an
application. The application actually uses a subsystem type interface to
hand the buffer off to the UNIX file system colony address space, much like
DB2 or JES. To "harden" to data to disk, look at the UNIX fsync function.
in REXX 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.1.0%3Ftopic%3Ddescriptions-fsync&data=05%7C01%7Csmetz3%40gmu.edu%7Cccd1c8211c6c43a0ec9f08da515742e5%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637911732491828709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IGFCETQOAXK0Zyi6LH7Xde945teOi3AlNtst4YCUwT4%3D&reserved=0



>
> I picture writing the started task in Rexx, so I would have to write to a
> DD
> name alloc

Re: Some UNIX file usage questions

[Seymour J Metz]

Does Unix System Services support RECFM=FBS? If it does, then fopen needs to 
properly handle short blocks for append.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Saturday, June 18, 2022 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

I am very sure that if you issue fopen (with "append")
on a file with, say, LRECL = 24 and BLKSIZE = 9600, which has
one record and one block with only one record in it,
and you write a second record, that then this file will still have
one block, but now two records.

At least this is what I expect from the C runtime.

Kind regards

Bernd


Am 18.06.2022 um 21:23 schrieb Steve Smith:
> QSAM to a traditional PS file with the process you described is certainly
> going to write only short blocks.  Given the amount of data involved, would
> it matter?
>
> However, besides USS files, you could consider an ESDS.  VSAM maintains its
> CISIZE and blocksize quite rigorously.  And it should be very safe.
>
> sas
>
> --
> 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: Debit vs Credit card for cash at ATM? [was: RE: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS]

[Phil Smith III]

Bob Bridges wrote at length, ending with:

>.I simply put a

>few thousand on the card, as though it was a pre-paid.  The credit limit is

>back up to a usable level now, but I'm still in the habit:  I keep a

>negative balance on the card.

 

>Yeah, yeah, I know they're profiting from "borrowing" my money.  But I pay

>the same either way, so I can't see that it makes a difference to me.  Are

>there disadvantages I'm missing?

 

Right, with low interest rates on bank accounts (and you're not prepaying
enough to be worth investing) the "borrowing" is insignificant. This is a
tried-and-true method of restoring credit. It also "cheats" the system
(yay!) by lowering your debt-to-credit ratio: each month when the various
folks look at your credit, they see (obviously I'm making up these numbers,
and ignoring things like mortgage, which I believe factor in but obviously
very differently from unsecured credit card debt):

Credit limit: $10K 
Credit card balance: -$1K

 

That's obviously a VERY positive net debt-to-credit ratio, and works in your
favor. I look at my credit rating occasionally, and it varies by a few
points. This is often directly dependent on how much I've spent recently,
even though I NEVER carry a balance. That's because the various folks who
report it (I have a couple of cards that do it for free) look at me at
different times. So if they happen to pick a day just after my primary card
balance was paid, I look better to them. When we had roof/siding done 10
years ago and put it all on cards (yay points!), it went down noticeably the
next month, then back up.

 

Net: I see your approach as a plus for you all 'round. You're getting
whatever other benefits the card offers, not having to use debit (which is
riskier, since it has less protections both in terms of breach and against
the merchant not delivering), and raising your credit score-all at a cost of
a buck or two a month in "lost" interest, max!

 

...phsiii


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

Re: Some UNIX file usage questions

[Charles Mills]

> Why not use Python? Good question.

1. I can undoubtedly do it perfectly satisfactorily, and almost certainly more 
quickly, in Rexx (because of the learning curve). I would have trouble 
justifying billing the client for my Python learning time when there is little 
benefit (that I know of -- correct me if I am wrong) for the client who is 
paying the bills.

Why not, then, learn Python on my own time? Don't I want to learn Python? Yes I 
do, but there are only so many hours in a day, and there are other things I 
want to learn more than I do Python. For example, I would rather spend the time 
learning to make the Roman-Jewish fried artichokes that are in the current 
Cooks Illustrated. Learning Python is just not very high on my bucket list. 
It's there, but probably not high enough to ever rise to the top.

2. I know exactly how to execute a Started Task written in Rexx, and I know 
most of the gotchas. In my experience, THAT is the problem with the "new tools" 
on z/OS. What would I have to do to execute a Started Task written in Python? 
What are the gotchas? Heck, what do I have to do to set up any Python 
environment at all? That is the time-consuming issue, and it holds about zero 
personal gratification for me. I could probably learn the Python language 
pretty readily, and it would be one more notch in my belt. Solving the probable 
gotchas of getting Python to actually do productive work on z/OS -- not so much.

> it would trivial to serve those reports as a REST API

Neat, but that is not what the client (who is paying the bills) wants. He wants 
a trivial-to-read-on-his-iPhone email in his inbox every morning. Again, it 
would be nice to have "how to write a REST API" in my toolkit, but not nice 
enough for me to learn it on my own time. Frankly, I am in an "I wish I had 
less work on my plate" mode and I would probably rather learn that artichoke 
recipe than learn to write REST APIs even if I were getting paid for the 
learning time. 

> use SQLite instead of a file which will significantly simplify writing reports

Not for me, and probably not for the "report" (I am flattering the requirement 
calling it a report -- maybe call it an "alert") that the client wants. And 
again, a learning curve that is difficult to justify.

So I think I will write it in Rexx, with perhaps a little bit of Assembler.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Saturday, June 18, 2022 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

On 19/06/2022 1:33 am, Paul Gilmartin wrote:
> On Sat, 18 Jun 2022 09:51:45 -0700, Charles Mills wrote:
>> ...
>> I picture writing the started task in Rexx, so I would have to write to a DD
>> name allocated to the UNIX file (either dynamically or with JCL), not with
>> "native" C fopen(), fwrite(), etc. Does that change any of the answers?
>>
> Why?  In Rexx you can "address SYASCALL write ..." instead.

Why REXX? Is it a case of knowing the banjo so you play Stairway to 
Heaven in the style of Earl Schruggs?

Why not use IBMs z/OS Python? You can then use SQLite instead of a file 
which will significantly simplify writing reports. In fact, it would 
trivial to serve those
reports as a REST API and put a nice WebUI on top using a simple 
template that supports data tables.

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

Re: SMPe ACCEPT process

[Seymour J Metz]

There was a time when ACCEPT NOAPPLY followed by a Stage 1 Sysgen, a Stage 2 
Sysgen and a JCLIN was a common method for installing operating systems and 
program products. Most shops opted for IPO et al rather than going that route.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, June 18, 2022 11:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPe ACCEPT process

In the 1980's, IMS SYSMODs (CBIPO/CBPDO etc.) had to be accepted before
they could be applied. It might have had to do with the macros needing
to be accepted before the rest of it could be applied.

Not sure how it is done now. The last IMS *native SMP/E* CBIPO I did was
in 2000 - probably an accept then apply 'as usual' but I can't remember.



On 17/06/2022 16:05, Ed Jaffe wrote:
> On 6/16/2022 3:02 PM, Bill Giannelli wrote:
>> For my prior maintenance I have run an APPLY excluding several PTFs
>> due to PEs and specified several bypass options.
>> But when running an ACCEPT do I run WITHOUT the excludes and the bypass?
>
> Nothing will be accepted that hasn't already been applied.
>

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Seymour J Metz]

Keep in mind that the mainframe can only do batch processing, with input from 
cards. It doesn't support anything like CICS, IMS or Sabre.. It's much better 
to run Linux than to get an IFL, which can only run batch.

Cynical? Moi?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Sunday, June 19, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> I also agree, but as a non-insider, I wanted to know what others were 
> thinking. I also belive that in most cases, the effort spent trying to get 
> off the mainframe would be better spent actually fixing the code running on 
> it in the first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's
remarks about why they wanted off the mainframe it's not about the
platform. Nobody denies that mainframes are insanely brilliant hardware
platforms. ING wanted to get rid of batch and move towards an event
driven architecture using pub/sub where they can easily deploy loosely
coupled micro-services to provide cutting edge products. The technology
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
Avro etc.  The retail banking industry has been disrupted by fintechs so
waiting for an overnight batch schedule for settlements is a competitive
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
applications is a VERY heavy lift.

https://secure-web.cisco.com/1GoiNO6FBPSWW0D9FZYVYixer1jsPeSd_xH-wmi6jMOC-onAkZQ4Pkf3c1UMGWbQeEprnkSWa1xGxz4vvn-LF0jVrCFlVVFZKQJ4Jti8nbQ7QchsOxhwNiwluJrdKkQP2nXXHQH2Ut2NNa9VChfVBIDR7Akw4ud6_pIXLAFXO5l73Sv-iLZFNU1MWWnLapWhhCKvytdzs7EJTvNZ2qbU8xwCdBEl1UkUuL-jHHZLk6xJPxAadVRWP1nuLz8i5AZrfvDI8u8rZ0V0DT77_Uvu8klHLbL9xe2qaYi1P6a6mc8r9Aj2jothGC-CR9cbCgb-JVXupgin9UctH5C_iVMyn_T-9jzZjtNyZDETxb8hXMU-BOuUz89MGu1nniZJ2tvSSN8yh5A6K-_It8fA10UFCfSBhOB0NVkwKL5M8A2BxZ9_e111GnxGK_PAbj0wh5fvU/https%3A%2F%2Fwww.theregister.com%2F2016%2F07%2F01%2Fing_mainframe_strategy%2F
 <- read
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the
last year we've had 3 key resources move to 3 day weeks with a view to
retiring. Replacing highly skilled assembler programmers with deep
subsystem knowledge is proving to be difficult. Young people don't want
to learn HLASM as they consider it a dead-end. Their position is "why
invest 3-4 years learning a language that is useless if you move to
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and
significantly modernized. The small/medium shops will probably be all
gone. When I first moved to my current town in 1998 there were 25-30
mainframe sites. Now there are 3 and 1 is on life support. One of our
customers re-platformed their CICS/COBOL/Batch applications from a z9 to
a single blade server. It doesn't make any sense financially for a small
site to run a mainframe.
https://secure-web.cisco.com/1-2iTgedz9DPApFopeywjfCeLAkb4kS8D5gFCEDU1FxvGiDWA4ou6pqJyb1d_hBAvGUBtcA89RrAylX3opaG2YEyDaGkIhptpRdukdHvdGOJNKn5bruFlKlnigitV6PrV4n-6zInQkhkJJdSriM40VeYiNOpB8Pg3nTa5E6k6TTIOXSfdaiQOGk1Y6EXL4Xtu-wkeXJmwaPEZljVo3KuwR0K75lrsX8fDe2f2CjcjvfrM3ruLG4na4zrAU_pR4DViMh7bKBhJ35a94VHU7GR4Vh_mXKaYwtbhwnRJWR8gVkvYjmB2CjTOIxJE52bNN1-82_fpYopX-kZQntDkR4OKjvj-b1AV9yXlGQ3A-eGFbtuCb0_1t2R9tgZ5MqgMbzxGQKIf78I2U_xq8a9qYywx3_OgfQwbeMgd8fiatdC5CbUSlphDlQfSDw9sOErejC7z/https%3A%2F%2Fwww.itnews.com.au%2Fnews%2Fwa-insurance-commission-decommissions-mainframe-322780

>
> Get BlueMail for 
> Android
> On Jun 18, 2022, at 5:13 PM, Charles Mills 
> mailto:charl...@mcn.org>> wrote:
>
> I always like the stories about the companies that are in the eighth year of
> a three-year project to get off the mainframe.
>
> Enzo, my friend, you have just kicked the hornets' nest! You had better
> duck, because the onslaught is coming. "The mainframe is [not] dead" is near
> and dear to the hearts of IBM-MAINers.
>
> Yes, I think the consensus is that the mainframe has a future. IBM seems to
> be focused mainly on the very largest shops, so the trend seems to be bigger
> and bigger machines at fewer and fewer companies. But it is hard to envision
> 

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 14:53:31 +, Seymour J Metz  wrote:
>
>Stream I/O is not part of UNIX�, 
>
"not" ???

>... and is available with any ANSI compliant Rexx, e.g., Regina. Alas, 
> TSO/E REXX is not ANSI compliant
>
Alas.

>... and IBM only supports stream I/O in Unix shells. I'm not aware of any 
> convenient Unix facilities for accessing files within REXX.
>
If you had read further in the thread:
Are you thinking of: 
?
(That page is a mere fraction of what's available.)
More at: 

z/OS Using REXX and z/OS UNIX System Services
bpxb600_v2r5.pdf

-- 
gil

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

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Bingo. Exactly what I meant. We ran batch and still were available 24 by 7.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 12:04 PM, Don Leahy  wrote:

Running batch does not preclude 24x7 online availability.

On Sun, Jun 19, 2022 at 09:44 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> People still run batch on the mainframe? The ING CEO needs replaced. Last
> shop I worked at we ran very little batch. Because as a health insurance
> company, we needed to have 24 by 7 by 365 online availability or patients
> die.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Sunday, June 19, 2022, 2:36 AM, David Crayford 
> wrote:
>
> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> > I also agree, but as a non-insider, I wanted to know what others were
> thinking. I also belive that in most cases, the effort spent trying to get
> off the mainframe would be better spent actually fixing the code running on
> it in the first place. Moving around broken code doesn't automatically fix
> it.
>
> It's not just about fixing broken code. If you read the ING CIO's
> remarks about why they wanted off the mainframe it's not about the
> platform. Nobody denies that mainframes are insanely brilliant hardware
> platforms. ING wanted to get rid of batch and move towards an event
> driven architecture using pub/sub where they can easily deploy loosely
> coupled micro-services to provide cutting edge products. The technology
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> Avro etc.  The retail banking industry has been disrupted by fintechs so
> waiting for an overnight batch schedule for settlements is a competitive
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> applications is a VERY heavy lift.
>
> https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read
> the comments section. It's hilarious :)
>
> The doubly whammy is there's a skills crisis slowly unraveling. In the
> last year we've had 3 key resources move to 3 day weeks with a view to
> retiring. Replacing highly skilled assembler programmers with deep
> subsystem knowledge is proving to be difficult. Young people don't want
> to learn HLASM as they consider it a dead-end. Their position is "why
> invest 3-4 years learning a language that is useless if you move to
> another industry?" I can't comment about COBOL application developers.
>
> In 10 years time I expect the mainframe to be alive and kicking and
> significantly modernized. The small/medium shops will probably be all
> gone. When I first moved to my current town in 1998 there were 25-30
> mainframe sites. Now there are 3 and 1 is on life support. One of our
> customers re-platformed their CICS/COBOL/Batch applications from a z9 to
> a single blade server. It doesn't make any sense financially for a small
> site to run a mainframe.
>
> https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780
>
> >
> > Get BlueMail for Android
> > On Jun 18, 2022, at 5:13 PM, Charles Mills  charl...@mcn.org>> wrote:
> >
> > I always like the stories about the companies that are in the eighth
> year of
> > a three-year project to get off the mainframe.
> >
> > Enzo, my friend, you have just kicked the hornets' nest! You had better
> > duck, because the onslaught is coming. "The mainframe is [not] dead" is
> near
> > and dear to the hearts of IBM-MAINers.
> >
> > Yes, I think the consensus is that the mainframe has a future. IBM seems
> to
> > be focused mainly on the very largest shops, so the trend seems to be
> bigger
> > and bigger machines at fewer and fewer companies. But it is hard to
> envision
> > Bank of America balancing their checking accounts every day on an array
> of
> > Windows servers, in their datacenter or in the cloud. My reading of the
> tea
> > leaves -- I am not an insider -- is that for a long time IBM was *saying*
> > the mainframe was here to stay but internally they did not believe it and
> > were not making decisions on that basis -- but I think that has now
> changed.
> > IBM appears to have made a HUGE investment in the z16, an investment that
> > will take more than 5 or more years to recoup.
> >
> > Welcome aboard!
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Enzo D'Amato
> > Sent: Saturday, June 18, 2022 1:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and
> > AWS
> >
> > As someone who is new to this field, and hasn't been though a wave of
> "the
> > mainframe is going away" yet, will there still be companies running the
> > mainframe 5 or 10 years down the line? Also, when I read about companies
> > trying to get off of the mainframe, how often do these efforts end up
> > succeeding?
> > 
> >
> > From: IBM Mainframe Discussion List  on
> behalf of
> 

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Don Leahy]

Running batch does not preclude 24x7 online availability.

On Sun, Jun 19, 2022 at 09:44 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> People still run batch on the mainframe? The ING CEO needs replaced. Last
> shop I worked at we ran very little batch. Because as a health insurance
> company, we needed to have 24 by 7 by 365 online availability or patients
> die.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Sunday, June 19, 2022, 2:36 AM, David Crayford 
> wrote:
>
> On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> > I also agree, but as a non-insider, I wanted to know what others were
> thinking. I also belive that in most cases, the effort spent trying to get
> off the mainframe would be better spent actually fixing the code running on
> it in the first place. Moving around broken code doesn't automatically fix
> it.
>
> It's not just about fixing broken code. If you read the ING CIO's
> remarks about why they wanted off the mainframe it's not about the
> platform. Nobody denies that mainframes are insanely brilliant hardware
> platforms. ING wanted to get rid of batch and move towards an event
> driven architecture using pub/sub where they can easily deploy loosely
> coupled micro-services to provide cutting edge products. The technology
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi,
> Avro etc.  The retail banking industry has been disrupted by fintechs so
> waiting for an overnight batch schedule for settlements is a competitive
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch
> applications is a VERY heavy lift.
>
> https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read
> the comments section. It's hilarious :)
>
> The doubly whammy is there's a skills crisis slowly unraveling. In the
> last year we've had 3 key resources move to 3 day weeks with a view to
> retiring. Replacing highly skilled assembler programmers with deep
> subsystem knowledge is proving to be difficult. Young people don't want
> to learn HLASM as they consider it a dead-end. Their position is "why
> invest 3-4 years learning a language that is useless if you move to
> another industry?" I can't comment about COBOL application developers.
>
> In 10 years time I expect the mainframe to be alive and kicking and
> significantly modernized. The small/medium shops will probably be all
> gone. When I first moved to my current town in 1998 there were 25-30
> mainframe sites. Now there are 3 and 1 is on life support. One of our
> customers re-platformed their CICS/COBOL/Batch applications from a z9 to
> a single blade server. It doesn't make any sense financially for a small
> site to run a mainframe.
>
> https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780
>
> >
> > Get BlueMail for Android
> > On Jun 18, 2022, at 5:13 PM, Charles Mills  charl...@mcn.org>> wrote:
> >
> > I always like the stories about the companies that are in the eighth
> year of
> > a three-year project to get off the mainframe.
> >
> > Enzo, my friend, you have just kicked the hornets' nest! You had better
> > duck, because the onslaught is coming. "The mainframe is [not] dead" is
> near
> > and dear to the hearts of IBM-MAINers.
> >
> > Yes, I think the consensus is that the mainframe has a future. IBM seems
> to
> > be focused mainly on the very largest shops, so the trend seems to be
> bigger
> > and bigger machines at fewer and fewer companies. But it is hard to
> envision
> > Bank of America balancing their checking accounts every day on an array
> of
> > Windows servers, in their datacenter or in the cloud. My reading of the
> tea
> > leaves -- I am not an insider -- is that for a long time IBM was *saying*
> > the mainframe was here to stay but internally they did not believe it and
> > were not making decisions on that basis -- but I think that has now
> changed.
> > IBM appears to have made a HUGE investment in the z16, an investment that
> > will take more than 5 or more years to recoup.
> >
> > Welcome aboard!
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Enzo D'Amato
> > Sent: Saturday, June 18, 2022 1:56 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM
> and
> > AWS
> >
> > As someone who is new to this field, and hasn't been though a wave of
> "the
> > mainframe is going away" yet, will there still be companies running the
> > mainframe 5 or 10 years down the line? Also, when I read about companies
> > trying to get off of the mainframe, how often do these efforts end up
> > succeeding?
> > 
> >
> > From: IBM Mainframe Discussion List  on
> behalf of
> > Mike Schwab 
> > Sent: Saturday, June 18, 2022 12:04 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Fintech is causing massive losses. 
https://www.finextra.com/newsarticle/40236/fintech-cheerleader-tiger-global-faces-massive-losses



Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 11:11 AM, Tom Brennan  
wrote:

That's the most realistic assessment I've seen.

On 6/18/2022 11:36 PM, David Crayford wrote:

> It's not just about fixing broken code. If you read the ING CIO's 
> remarks about why they wanted off the mainframe it's not about the 
> platform. Nobody denies that mainframes are insanely brilliant hardware 
> platforms. ING wanted to get rid of batch and move towards an event 
> driven architecture using pub/sub where they can easily deploy loosely 
> coupled micro-services to provide cutting edge products. The technology 
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
> Avro etc.  The retail banking industry has been disrupted by fintechs so 
> waiting for an overnight batch schedule for settlements is a competitive 
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
> applications is a VERY heavy lift.
> 
> https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
> the comments section. It's hilarious :)
> 
> The doubly whammy is there's a skills crisis slowly unraveling. In the 
> last year we've had 3 key resources move to 3 day weeks with a view to 
> retiring. Replacing highly skilled assembler programmers with deep 
> subsystem knowledge is proving to be difficult. Young people don't want 
> to learn HLASM as they consider it a dead-end. Their position is "why 
> invest 3-4 years learning a language that is useless if you move to 
> another industry?" I can't comment about COBOL application developers.
> 
> In 10 years time I expect the mainframe to be alive and kicking and 
> significantly modernized. The small/medium shops will probably be all 
> gone. When I first moved to my current town in 1998 there were 25-30 
> mainframe sites. Now there are 3 and 1 is on life support. One of our 
> customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
> a single blade server. It doesn't make any sense financially for a small 
> site to run a mainframe. 
> https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780
>   

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Not in my voracious reading.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 11:11 AM, Tom Brennan  
wrote:

That's the most realistic assessment I've seen.

On 6/18/2022 11:36 PM, David Crayford wrote:

> It's not just about fixing broken code. If you read the ING CIO's 
> remarks about why they wanted off the mainframe it's not about the 
> platform. Nobody denies that mainframes are insanely brilliant hardware 
> platforms. ING wanted to get rid of batch and move towards an event 
> driven architecture using pub/sub where they can easily deploy loosely 
> coupled micro-services to provide cutting edge products. The technology 
> stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
> Avro etc.  The retail banking industry has been disrupted by fintechs so 
> waiting for an overnight batch schedule for settlements is a competitive 
> disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
> applications is a VERY heavy lift.
> 
> https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
> the comments section. It's hilarious :)
> 
> The doubly whammy is there's a skills crisis slowly unraveling. In the 
> last year we've had 3 key resources move to 3 day weeks with a view to 
> retiring. Replacing highly skilled assembler programmers with deep 
> subsystem knowledge is proving to be difficult. Young people don't want 
> to learn HLASM as they consider it a dead-end. Their position is "why 
> invest 3-4 years learning a language that is useless if you move to 
> another industry?" I can't comment about COBOL application developers.
> 
> In 10 years time I expect the mainframe to be alive and kicking and 
> significantly modernized. The small/medium shops will probably be all 
> gone. When I first moved to my current town in 1998 there were 25-30 
> mainframe sites. Now there are 3 and 1 is on life support. One of our 
> customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
> a single blade server. It doesn't make any sense financially for a small 
> site to run a mainframe. 
> https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780
>   

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

With interest rates rising, Fintech is in serious trouble. That’s why the 
stocks are down drastically. Add in that the accounts aren’t backed by the 
government and Fintech is basically unregulated & the coming insolvencies will 
be painful. Kind of like crypto. Everything that emanates from Silicon Valley 
is not golden. Saw a similar ending with the internet bubble. Zero interest 
rates creates bubbles. You can’t keep building economic growth via ever 
increasing levels of debt. The ending is always painful. I remember when Uber & 
Lyft were disrupting the transportation industry. Now, after 10’s of billions 
in losses, and the stocks below their IPO price, reality is setting in.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:36 AM, David Crayford  wrote:

On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> I also agree, but as a non-insider, I wanted to know what others were 
> thinking. I also belive that in most cases, the effort spent trying to get 
> off the mainframe would be better spent actually fixing the code running on 
> it in the first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's 
remarks about why they wanted off the mainframe it's not about the 
platform. Nobody denies that mainframes are insanely brilliant hardware 
platforms. ING wanted to get rid of batch and move towards an event 
driven architecture using pub/sub where they can easily deploy loosely 
coupled micro-services to provide cutting edge products. The technology 
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
Avro etc.  The retail banking industry has been disrupted by fintechs so 
waiting for an overnight batch schedule for settlements is a competitive 
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
applications is a VERY heavy lift.

https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the 
last year we've had 3 key resources move to 3 day weeks with a view to 
retiring. Replacing highly skilled assembler programmers with deep 
subsystem knowledge is proving to be difficult. Young people don't want 
to learn HLASM as they consider it a dead-end. Their position is "why 
invest 3-4 years learning a language that is useless if you move to 
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and 
significantly modernized. The small/medium shops will probably be all 
gone. When I first moved to my current town in 1998 there were 25-30 
mainframe sites. Now there are 3 and 1 is on life support. One of our 
customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
a single blade server. It doesn't make any sense financially for a small 
site to run a mainframe. 
https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780

>
> Get BlueMail for Android
> On Jun 18, 2022, at 5:13 PM, Charles Mills 
> mailto:charl...@mcn.org>> wrote:
>
> I always like the stories about the companies that are in the eighth year of
> a three-year project to get off the mainframe.
>
> Enzo, my friend, you have just kicked the hornets' nest! You had better
> duck, because the onslaught is coming. "The mainframe is [not] dead" is near
> and dear to the hearts of IBM-MAINers.
>
> Yes, I think the consensus is that the mainframe has a future. IBM seems to
> be focused mainly on the very largest shops, so the trend seems to be bigger
> and bigger machines at fewer and fewer companies. But it is hard to envision
> Bank of America balancing their checking accounts every day on an array of
> Windows servers, in their datacenter or in the cloud. My reading of the tea
> leaves -- I am not an insider -- is that for a long time IBM was *saying*
> the mainframe was here to stay but internally they did not believe it and
> were not making decisions on that basis -- but I think that has now changed.
> IBM appears to have made a HUGE investment in the z16, an investment that
> will take more than 5 or more years to recoup.
>
> Welcome aboard!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Enzo D'Amato
> Sent: Saturday, June 18, 2022 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> As someone who is new to this field, and hasn't been though a wave of "the
> mainframe is going away" yet, will there still be companies running the
> mainframe 5 or 10 years down the line? Also, when I read about companies
> trying to get off of the mainframe, how often do these efforts end up
> succeeding?
> 
>
> From: IBM Mainframe Discussion List  on behalf of
> Mike Schwab 
> Sent: 

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Tom Brennan]

That's the most realistic assessment I've seen.

On 6/18/2022 11:36 PM, David Crayford wrote:

It's not just about fixing broken code. If you read the ING CIO's 
remarks about why they wanted off the mainframe it's not about the 
platform. Nobody denies that mainframes are insanely brilliant hardware 
platforms. ING wanted to get rid of batch and move towards an event 
driven architecture using pub/sub where they can easily deploy loosely 
coupled micro-services to provide cutting edge products. The technology 
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
Avro etc.  The retail banking industry has been disrupted by fintechs so 
waiting for an overnight batch schedule for settlements is a competitive 
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
applications is a VERY heavy lift.


https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
the comments section. It's hilarious :)


The doubly whammy is there's a skills crisis slowly unraveling. In the 
last year we've had 3 key resources move to 3 day weeks with a view to 
retiring. Replacing highly skilled assembler programmers with deep 
subsystem knowledge is proving to be difficult. Young people don't want 
to learn HLASM as they consider it a dead-end. Their position is "why 
invest 3-4 years learning a language that is useless if you move to 
another industry?" I can't comment about COBOL application developers.


In 10 years time I expect the mainframe to be alive and kicking and 
significantly modernized. The small/medium shops will probably be all 
gone. When I first moved to my current town in 1998 there were 25-30 
mainframe sites. Now there are 3 and 1 is on life support. One of our 
customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
a single blade server. It doesn't make any sense financially for a small 
site to run a mainframe. 
https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780  


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

Re: Converting Spool files to PDF

[Seymour J Metz]

There are a variety of sysout managers on the market that support PDF. Some of 
them rely on JCL parameters and others can extract metadata from the SPOOL 
files. I'm not aware of any that process the actual AFP definitions rather than 
just the names.

No, you don't need PSF if you're just converting to PDF.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Gadi Ben-Avi [gad...@malam.com]
Sent: Sunday, June 19, 2022 3:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Converting Spool files to PDF

Hi,
We're exploring converting SPOOL files to PDF files.

The Spool file are currently printed on an Infoprint 4000 printer.
They use many of the function of PSF, including PAGEDEF's, FORMDEF's, Overlays, 
Page Segments and various fonts.

One option is to use Infoprint Server and AFP Print transform to PDF.

Would we still need PSF, even if we don't have a physical printer?

Thanks

Gadi



--
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: Some UNIX file usage questions

[Seymour J Metz]

There are REXX function packages for VSAM.


Stream I/O is not part of UNIX®, and is available with any ANSI compliant Rexx, 
e.g., Regina. Alas, TSO/E REXX is not ANSI compliant and IBM only supports 
stream I/O in Unix shells. I'm not aware of any convenient Unix facilities for 
accessing files within REXX.

Obligatory rant: why do they keep changing the case? DB2->Db2, REXX->Rexx, etc.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Sunday, June 19, 2022 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Some UNIX file usage questions

Well, I said ESDS; a KSDS would add useless complication and overhead.

Anyway, there doesn't seem to be any support for VSAM in REXX.  Not sure
about USS functions, but it seems much more straightforward to use USS
files with USS functions.

sas


On Sat, Jun 18, 2022 at 5:05 PM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> ...
>
> The KSDS method sounds promising.  I'm entirely VSAM-naive.
>
>

--
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: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Fintech is a bubble. 
https://www.cnbc.com/amp/2021/11/18/many-signs-that-fintech-is-in-a-bubble-jc-flowers-ceo-says.html

Silicon Valley’s Fintech disruption is only viable with free money and zero 
interest rates.
If offering your paycheck 2 days early is your offering, you’re a scam. A loan 
shark.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:36 AM, David Crayford  wrote:

On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> I also agree, but as a non-insider, I wanted to know what others were 
> thinking. I also belive that in most cases, the effort spent trying to get 
> off the mainframe would be better spent actually fixing the code running on 
> it in the first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's 
remarks about why they wanted off the mainframe it's not about the 
platform. Nobody denies that mainframes are insanely brilliant hardware 
platforms. ING wanted to get rid of batch and move towards an event 
driven architecture using pub/sub where they can easily deploy loosely 
coupled micro-services to provide cutting edge products. The technology 
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
Avro etc.  The retail banking industry has been disrupted by fintechs so 
waiting for an overnight batch schedule for settlements is a competitive 
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
applications is a VERY heavy lift.

https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the 
last year we've had 3 key resources move to 3 day weeks with a view to 
retiring. Replacing highly skilled assembler programmers with deep 
subsystem knowledge is proving to be difficult. Young people don't want 
to learn HLASM as they consider it a dead-end. Their position is "why 
invest 3-4 years learning a language that is useless if you move to 
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and 
significantly modernized. The small/medium shops will probably be all 
gone. When I first moved to my current town in 1998 there were 25-30 
mainframe sites. Now there are 3 and 1 is on life support. One of our 
customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
a single blade server. It doesn't make any sense financially for a small 
site to run a mainframe. 
https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780

>
> Get BlueMail for Android
> On Jun 18, 2022, at 5:13 PM, Charles Mills 
> mailto:charl...@mcn.org>> wrote:
>
> I always like the stories about the companies that are in the eighth year of
> a three-year project to get off the mainframe.
>
> Enzo, my friend, you have just kicked the hornets' nest! You had better
> duck, because the onslaught is coming. "The mainframe is [not] dead" is near
> and dear to the hearts of IBM-MAINers.
>
> Yes, I think the consensus is that the mainframe has a future. IBM seems to
> be focused mainly on the very largest shops, so the trend seems to be bigger
> and bigger machines at fewer and fewer companies. But it is hard to envision
> Bank of America balancing their checking accounts every day on an array of
> Windows servers, in their datacenter or in the cloud. My reading of the tea
> leaves -- I am not an insider -- is that for a long time IBM was *saying*
> the mainframe was here to stay but internally they did not believe it and
> were not making decisions on that basis -- but I think that has now changed.
> IBM appears to have made a HUGE investment in the z16, an investment that
> will take more than 5 or more years to recoup.
>
> Welcome aboard!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Enzo D'Amato
> Sent: Saturday, June 18, 2022 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> As someone who is new to this field, and hasn't been though a wave of "the
> mainframe is going away" yet, will there still be companies running the
> mainframe 5 or 10 years down the line? Also, when I read about companies
> trying to get off of the mainframe, how often do these efforts end up
> succeeding?
> 
>
> From: IBM Mainframe Discussion List  on behalf of
> Mike Schwab 
> Sent: Saturday, June 18, 2022 12:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> Moshix signed up for an AWS instance, loaded up Hercules and Turnkey
> 4-, got it going, and allowed some other people to log in.
>
> On Fri, Jun 17, 2022 at 8:31 AM Bill Johnson
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

Fintechs are struggling. Most Fintech stocks are down huge. Losing money hand 
over fist. They’re not even a challenge.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:36 AM, David Crayford  wrote:

On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> I also agree, but as a non-insider, I wanted to know what others were 
> thinking. I also belive that in most cases, the effort spent trying to get 
> off the mainframe would be better spent actually fixing the code running on 
> it in the first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's 
remarks about why they wanted off the mainframe it's not about the 
platform. Nobody denies that mainframes are insanely brilliant hardware 
platforms. ING wanted to get rid of batch and move towards an event 
driven architecture using pub/sub where they can easily deploy loosely 
coupled micro-services to provide cutting edge products. The technology 
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
Avro etc.  The retail banking industry has been disrupted by fintechs so 
waiting for an overnight batch schedule for settlements is a competitive 
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
applications is a VERY heavy lift.

https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the 
last year we've had 3 key resources move to 3 day weeks with a view to 
retiring. Replacing highly skilled assembler programmers with deep 
subsystem knowledge is proving to be difficult. Young people don't want 
to learn HLASM as they consider it a dead-end. Their position is "why 
invest 3-4 years learning a language that is useless if you move to 
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and 
significantly modernized. The small/medium shops will probably be all 
gone. When I first moved to my current town in 1998 there were 25-30 
mainframe sites. Now there are 3 and 1 is on life support. One of our 
customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
a single blade server. It doesn't make any sense financially for a small 
site to run a mainframe. 
https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780

>
> Get BlueMail for Android
> On Jun 18, 2022, at 5:13 PM, Charles Mills 
> mailto:charl...@mcn.org>> wrote:
>
> I always like the stories about the companies that are in the eighth year of
> a three-year project to get off the mainframe.
>
> Enzo, my friend, you have just kicked the hornets' nest! You had better
> duck, because the onslaught is coming. "The mainframe is [not] dead" is near
> and dear to the hearts of IBM-MAINers.
>
> Yes, I think the consensus is that the mainframe has a future. IBM seems to
> be focused mainly on the very largest shops, so the trend seems to be bigger
> and bigger machines at fewer and fewer companies. But it is hard to envision
> Bank of America balancing their checking accounts every day on an array of
> Windows servers, in their datacenter or in the cloud. My reading of the tea
> leaves -- I am not an insider -- is that for a long time IBM was *saying*
> the mainframe was here to stay but internally they did not believe it and
> were not making decisions on that basis -- but I think that has now changed.
> IBM appears to have made a HUGE investment in the z16, an investment that
> will take more than 5 or more years to recoup.
>
> Welcome aboard!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Enzo D'Amato
> Sent: Saturday, June 18, 2022 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> As someone who is new to this field, and hasn't been though a wave of "the
> mainframe is going away" yet, will there still be companies running the
> mainframe 5 or 10 years down the line? Also, when I read about companies
> trying to get off of the mainframe, how often do these efforts end up
> succeeding?
> 
>
> From: IBM Mainframe Discussion List  on behalf of
> Mike Schwab 
> Sent: Saturday, June 18, 2022 12:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> Moshix signed up for an AWS instance, loaded up Hercules and Turnkey
> 4-, got it going, and allowed some other people to log in.
>
> On Fri, Jun 17, 2022 at 8:31 AM Bill Johnson
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
>  Cloud - Something the mainframe has been doing for decades. We called it
> outsourcing. GM ran their entire organization out of mainframes in
> Charlotte, Dallas, & perhaps anoth

Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

[Bill Johnson]

People still run batch on the mainframe? The ING CEO needs replaced. Last shop 
I worked at we ran very little batch. Because as a health insurance company, we 
needed to have 24 by 7 by 365 online availability or patients die.


Sent from Yahoo Mail for iPhone


On Sunday, June 19, 2022, 2:36 AM, David Crayford  wrote:

On 19/06/2022 5:23 am, Enzo D'Amato wrote:
> I also agree, but as a non-insider, I wanted to know what others were 
> thinking. I also belive that in most cases, the effort spent trying to get 
> off the mainframe would be better spent actually fixing the code running on 
> it in the first place. Moving around broken code doesn't automatically fix it.

It's not just about fixing broken code. If you read the ING CIO's 
remarks about why they wanted off the mainframe it's not about the 
platform. Nobody denies that mainframes are insanely brilliant hardware 
platforms. ING wanted to get rid of batch and move towards an event 
driven architecture using pub/sub where they can easily deploy loosely 
coupled micro-services to provide cutting edge products. The technology 
stacks are built on open source such as Kafka, MongoDB, Cassandra, NiFi, 
Avro etc.  The retail banking industry has been disrupted by fintechs so 
waiting for an overnight batch schedule for settlements is a competitive 
disadvantage.  Cracking open and modernizing 50-60 year old COBOL batch 
applications is a VERY heavy lift.

https://www.theregister.com/2016/07/01/ing_mainframe_strategy/ <- read 
the comments section. It's hilarious :)

The doubly whammy is there's a skills crisis slowly unraveling. In the 
last year we've had 3 key resources move to 3 day weeks with a view to 
retiring. Replacing highly skilled assembler programmers with deep 
subsystem knowledge is proving to be difficult. Young people don't want 
to learn HLASM as they consider it a dead-end. Their position is "why 
invest 3-4 years learning a language that is useless if you move to 
another industry?" I can't comment about COBOL application developers.

In 10 years time I expect the mainframe to be alive and kicking and 
significantly modernized. The small/medium shops will probably be all 
gone. When I first moved to my current town in 1998 there were 25-30 
mainframe sites. Now there are 3 and 1 is on life support. One of our 
customers re-platformed their CICS/COBOL/Batch applications from a z9 to 
a single blade server. It doesn't make any sense financially for a small 
site to run a mainframe. 
https://www.itnews.com.au/news/wa-insurance-commission-decommissions-mainframe-322780

>
> Get BlueMail for Android
> On Jun 18, 2022, at 5:13 PM, Charles Mills 
> mailto:charl...@mcn.org>> wrote:
>
> I always like the stories about the companies that are in the eighth year of
> a three-year project to get off the mainframe.
>
> Enzo, my friend, you have just kicked the hornets' nest! You had better
> duck, because the onslaught is coming. "The mainframe is [not] dead" is near
> and dear to the hearts of IBM-MAINers.
>
> Yes, I think the consensus is that the mainframe has a future. IBM seems to
> be focused mainly on the very largest shops, so the trend seems to be bigger
> and bigger machines at fewer and fewer companies. But it is hard to envision
> Bank of America balancing their checking accounts every day on an array of
> Windows servers, in their datacenter or in the cloud. My reading of the tea
> leaves -- I am not an insider -- is that for a long time IBM was *saying*
> the mainframe was here to stay but internally they did not believe it and
> were not making decisions on that basis -- but I think that has now changed.
> IBM appears to have made a HUGE investment in the z16, an investment that
> will take more than 5 or more years to recoup.
>
> Welcome aboard!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Enzo D'Amato
> Sent: Saturday, June 18, 2022 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> As someone who is new to this field, and hasn't been though a wave of "the
> mainframe is going away" yet, will there still be companies running the
> mainframe 5 or 10 years down the line? Also, when I read about companies
> trying to get off of the mainframe, how often do these efforts end up
> succeeding?
> 
>
> From: IBM Mainframe Discussion List  on behalf of
> Mike Schwab 
> Sent: Saturday, June 18, 2022 12:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and
> AWS
>
> Moshix signed up for an AWS instance, loaded up Hercules and Turnkey
> 4-, got it going, and allowed some other people to log in.
>
> On Fri, Jun 17, 2022 at 8:31 AM Bill Johnson
> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
>  Cloud - Something the mainframe has been doing for decades. We called 

Re: Some UNIX file usage questions

[Paul Gilmartin]

On Sun, 19 Jun 2022 09:02:53 -0400, Steve Smith wrote:

>Well, I said ESDS; a KSDS would add useless complication and overhead.
> 
I said I was entirely VSAM-naive.

>Anyway, there doesn't seem to be any support for VSAM in REXX.  Not sure
>about USS functions, 
>
Are you thinking of: 
?
(That page is a mere fraction of what's available.)

>   ... but it seems much more straightforward to use USS
>files with USS functions.
>
Amen.

>On Sat, Jun 18, 2022 at 5:05 PM Paul Gilmartin wrote:
>> ...
>> The KSDS method sounds promising.  I'm entirely VSAM-naive.

-- 
gil

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

Re: Some UNIX file usage questions

[Steve Smith]

Well, I said ESDS; a KSDS would add useless complication and overhead.

Anyway, there doesn't seem to be any support for VSAM in REXX.  Not sure
about USS functions, but it seems much more straightforward to use USS
files with USS functions.

sas


On Sat, Jun 18, 2022 at 5:05 PM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> ...
>
> The KSDS method sounds promising.  I'm entirely VSAM-naive.
>
>

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

Re: z/OSMF Rollout

[Colin Paice]

Brian,

I am not an expert in z/OSMF, but I wrote z/OSMF autostart: how to stop it,
and how to use it (or not)

because you might need to handle a z/OSMF instance starting on LPARA today.
and LPARB tomorrow. Do you need a VIPA?
Do you need more than one instance of a stateless z/OSMF running, for
example one on each LPAR, and an instance where you do "workload" type
stuff, which contains state about work in progress.  If you have to restart
z/OSMF, how do you handle the down time - which could be minutes?  I could
not find answers to these sorts of questions.

Colin

On Mon, 13 Jun 2022 at 19:20, Igor Froderick <
04219c614a54-dmarc-requ...@listserv.ua.edu> wrote:

> We're looking to rollout a z/OSMF 2.4 configuration from our test
> environment to our user-acceptance environment.
> Hoping to not have to start from scratch.
>
> Just wondering if anyone had any rules-of-thumb, procedures, or advice in
> general for rolling it into an n'th environment
> while changing only what is required for the new environment.
>
> Does it make sense to try to employ the Software Deployment component?
>
> Any advice greatly appreciated!
>
> Thanks in Advance,
> 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

Re: Converting Spool files to PDF

[Itschak Mugzach]

Right... Didn't notice the full requirements.

*| **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 Sun, Jun 19, 2022 at 11:32 AM Gadi Ben-Avi  wrote:

> Not if they need specific PAGEDEFs, FORMDEFs and other AFP constructs.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Itschak Mugzach
> Sent: Sunday, June 19, 2022 11:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Converting Spool files to PDF
>
> Gadi,
>
> xmitip (a freeware) can convert spool files to PDF.
>
> ITschak
>
> *| **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 Sun, Jun 19, 2022 at 10:50 AM Gadi Ben-Avi  wrote:
>
> > Hi,
> > We're exploring converting SPOOL files to PDF files.
> >
> > The Spool file are currently printed on an Infoprint 4000 printer.
> > They use many of the function of PSF, including PAGEDEF's, FORMDEF's,
> > Overlays, Page Segments and various fonts.
> >
> > One option is to use Infoprint Server and AFP Print transform to PDF.
> >
> > Would we still need PSF, even if we don't have a physical printer?
> >
> > Thanks
> >
> > Gadi
> >
> >
> >
> > --
> > 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
>
> Email secured by Check Point
>
> --
> 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: Converting Spool files to PDF

[Gadi Ben-Avi]

Not if they need specific PAGEDEFs, FORMDEFs and other AFP constructs. 


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Sunday, June 19, 2022 11:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Converting Spool files to PDF

Gadi,

xmitip (a freeware) can convert spool files to PDF.

ITschak

*| **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 Sun, Jun 19, 2022 at 10:50 AM Gadi Ben-Avi  wrote:

> Hi,
> We're exploring converting SPOOL files to PDF files.
>
> The Spool file are currently printed on an Infoprint 4000 printer.
> They use many of the function of PSF, including PAGEDEF's, FORMDEF's, 
> Overlays, Page Segments and various fonts.
>
> One option is to use Infoprint Server and AFP Print transform to PDF.
>
> Would we still need PSF, even if we don't have a physical printer?
>
> Thanks
>
> Gadi
>
>
>
> --
> 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

Email secured by Check Point

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

Re: Converting Spool files to PDF

[Itschak Mugzach]

Gadi,

xmitip (a freeware) can convert spool files to PDF.

ITschak

*| **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 Sun, Jun 19, 2022 at 10:50 AM Gadi Ben-Avi  wrote:

> Hi,
> We're exploring converting SPOOL files to PDF files.
>
> The Spool file are currently printed on an Infoprint 4000 printer.
> They use many of the function of PSF, including PAGEDEF's, FORMDEF's,
> Overlays, Page Segments and various fonts.
>
> One option is to use Infoprint Server and AFP Print transform to PDF.
>
> Would we still need PSF, even if we don't have a physical printer?
>
> Thanks
>
> Gadi
>
>
>
> --
> 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

Converting Spool files to PDF

[Gadi Ben-Avi]

Hi,
We're exploring converting SPOOL files to PDF files.

The Spool file are currently printed on an Infoprint 4000 printer.
They use many of the function of PSF, including PAGEDEF's, FORMDEF's, Overlays, 
Page Segments and various fonts.

One option is to use Infoprint Server and AFP Print transform to PDF.

Would we still need PSF, even if we don't have a physical printer?

Thanks

Gadi



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