Re: SYNCSORT Question: JFY a numeric field with leading zeroes?

[Alan Young]

One way I did it was using FINDREP= with STARTPOS and ENDPOS to change space to 
zero. You can make multiple passes on the output record with multiple 
IFTHEN=(WHEN=INIT statements - BUILD first then FINDREP or other manipulation 
after the build.

If you have a more recent version that supports the UFF format, use OVERLAY and 
that format to reprocess the field and apply an EDIT= mask to result. You might 
be able to do it directly in the BUILD instead of using JFY.

Alan

-Original Message-
>From: "Farley, Peter x23353" 
>Sent: Nov 11, 2019 5:08 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: SYNCSORT Question: JFY a numeric field with leading zeroes?
>
>We currently use SYNCSORT and need to parse an input CSV file with a trailing 
>number that we need to right-justify in a fixed-length field with leading 
>zeroes instead of leading blanks.
>
>So far I have not been able to find an example that shows how to write out 
>that trailing field as a right-justified number with leading zeroes instead of 
>leading blanks.
>
>Current SORT control cards look like the below.  Please don't take the size of 
>the input fields literally, they can be smaller.  I have just shown the 
>example input line with maximum expected input field lengths.
>
>OPTION COPY
>OUTREC PARSE=(%00=(ENDBEFR=C',',FIXLEN=9),
>   %01=(ENDBEFR=C',',FIXLEN=7),
>   %02=(ENDBEFR=C',',FIXLEN=8),
>   %03=(ENDBEFR=C' ',FIXLEN=10)),
>   BUILD=(%00,%01,%02,%03,JFY=(SHIFT=RIGHT),
>  15X),CONVERT
>
>Input file is RECFM=VB,LRECL=259, output file is RECFM=FB,LRECL=49
>
>Sample input line:
>
>ABCDEFGH0,ABCDEF1,20190731,1000
>
>Current output line using above control cards:
>
>ABCDEFGH0ABCDEF120190731  1000
>
>Desired output line (15 trailing blanks):
>
>ABCDEFGH0ABCDEF120190731001000
>
>TIA for any advice or RTFM pointer you can provide.
>
>Peter
>--
>
>
>
>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

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

Re: Unix files

[Rob Schramm]

Honestly, doesn't this sound like log4(x) territory? Or syslogd type of
stuff? Maybe i am missing something.

Rob

On Mon, Nov 11, 2019, 15:18 Pierre Fichaud  wrote:

> I had initially mentioned that more than 1 file could be generated by 1
> producer. There could also be more than 1 producer on the LPAR.
> I would assign 1 sub-task (written in assembler) to each zFS file.
>
> I need to read the log records produced by an application. Once the
> application has closed the file, I would need to know that. My sub-task
> would stop processing the file and close it.
>
> I also need to WAIT if there are no more records but the writer still
> has the file open.
>
> I am a reader so I have no say on preserving the contents of the file.
>
> I'll investigate pipes.
>
> My STC will have as input 1 or more zFS files. It would ATTACH 1
> sub-task per zFS file,
>
> Thanks to all for responding, Pierre.
>
> --
> 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

SYNCSORT Question: JFY a numeric field with leading zeroes?

[Farley, Peter x23353]

We currently use SYNCSORT and need to parse an input CSV file with a trailing 
number that we need to right-justify in a fixed-length field with leading 
zeroes instead of leading blanks.

So far I have not been able to find an example that shows how to write out that 
trailing field as a right-justified number with leading zeroes instead of 
leading blanks.

Current SORT control cards look like the below.  Please don't take the size of 
the input fields literally, they can be smaller.  I have just shown the example 
input line with maximum expected input field lengths.

OPTION COPY
OUTREC PARSE=(%00=(ENDBEFR=C',',FIXLEN=9),
   %01=(ENDBEFR=C',',FIXLEN=7),
   %02=(ENDBEFR=C',',FIXLEN=8),
   %03=(ENDBEFR=C' ',FIXLEN=10)),
   BUILD=(%00,%01,%02,%03,JFY=(SHIFT=RIGHT),
  15X),CONVERT

Input file is RECFM=VB,LRECL=259, output file is RECFM=FB,LRECL=49

Sample input line:

ABCDEFGH0,ABCDEF1,20190731,1000

Current output line using above control cards:

ABCDEFGH0ABCDEF120190731  1000

Desired output line (15 trailing blanks):

ABCDEFGH0ABCDEF120190731001000

TIA for any advice or RTFM pointer you can provide.

Peter
--



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: Is there an MVS service that will list IDENTIFYed entry points?

[Jesse 1 Robinson]

The PDS command (StarTool) is very good at mapping and manipulating load 
modules. I have not tried it with an entry point created only by IDENTIFY, but 
it's worth a shot. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Monday, November 11, 2019 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Is there an MVS service that will list IDENTIFYed entry 
points?

And the CDE list does indeed contain the answer. The entrypoint is not there, 
but that is my answer.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Monday, November 11, 2019 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there an MVS service that will list IDENTIFYed entry points?


You should see a CDE for the alias. You can use CSVINFO to retrieve a list.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 11, 2019 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there an MVS service that will list IDENTIFYed entry points?

In a SYSUDUMP I can see the names of loaded modules, but not (unless I am 
missing something) any names added by IDENTIFY. Is there a service that will 
return to me the names of all entry points added with IDENTIFY?

CSVQUERY will tell me about one particular entry point name but what if I 
wanted to list them all? I'd like a programming service but I would settle for 
a console command or the like.

The environment is program A loads program B. I am wondering if A is first 
IDENTIFYing entrypoint FOO. I am proposing writing my own B replacement -- it 
does not really have to do what B does, it just has to load and run -- and 
query whether entrypoint FOO is IDENTIFYed or not. The new B could run 
authorized if that is what is needed.

Charles

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

Re: Is there an MVS service that will list IDENTIFYed entry points?

[Charles Mills]

And the CDE list does indeed contain the answer. The entrypoint is not
there, but that is my answer.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, November 11, 2019 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there an MVS service that will list IDENTIFYed entry points?


You should see a CDE for the alias. You can use CSVINFO to retrieve a list.


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



From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Monday, November 11, 2019 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there an MVS service that will list IDENTIFYed entry points?

In a SYSUDUMP I can see the names of loaded modules, but not (unless I am
missing something) any names added by IDENTIFY. Is there a service that will
return to me the names of all entry points added with IDENTIFY?

CSVQUERY will tell me about one particular entry point name but what if I
wanted to list them all? I'd like a programming service but I would settle
for a console command or the like.

The environment is program A loads program B. I am wondering if A is first
IDENTIFYing entrypoint FOO. I am proposing writing my own B replacement --
it does not really have to do what B does, it just has to load and run --
and query whether entrypoint FOO is IDENTIFYed or not. The new B could run
authorized if that is what is needed.

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

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

Re: Gerhard Postpischil ז״ל

[Tom Marchant]

On Mon, 11 Nov 2019 19:06:04 +, Seymour J Metz  wrote:

>It is with deep regret that I announce the death of my friend and colleague 
>Gerhard Postpischil, whom some of you may know from here, CBTTAPE.ORG or 
>Hercules. Someone told his son Eric "You sound like your father." - I can 
>think of no greater compliment. Gerhard was a stickler for accuracy and always 
>strove to write 
tight code. He was also a good friend to me and my children, and we will miss 
him.



Condolences to you, Shmuel. I only knew Gerhard through his posts on this list, 
but I found him to be knowledgeable and helpful.

Tom Marchant

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

Re: Unix files

[Pierre Fichaud]

I had initially mentioned that more than 1 file could be generated by 1 
producer. There could also be more than 1 producer on the LPAR.

I would assign 1 sub-task (written in assembler) to each zFS file.

I need to read the log records produced by an application. Once the 
application has closed the file, I would need to know that. My sub-task 
would stop processing the file and close it.


I also need to WAIT if there are no more records but the writer still 
has the file open.


I am a reader so I have no say on preserving the contents of the file.

I'll investigate pipes.

My STC will have as input 1 or more zFS files. It would ATTACH 1 
sub-task per zFS file,


Thanks to all for responding, Pierre.

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

Re: WTO

[Seymour J Metz]

>I suppose that that depends what you think is the "obvious location". 
>I think that the obvious location is in the linkage conventions
>documentation (which is within the assembler services guide). 

Indeed.

>That is where the information is. 

FSVO is; that is where the information on the responsibilities of user-written 
subroutines is. Perhaps it was supposed to say that system services are written 
to do the same thing, but it doesn't.




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



From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Sunday, November 10, 2019 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO


Yes it's documented and legit, but it's a change in behaviour over the
last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15,
and STORAGE OBTAIN did not change the high half of R1.


You have no way of knowing if that is true or not. All that you could
possibly say is that you did not encounter such a case. The environment
that could cause such a case might even not have been under your control
and might be uncommon. Anyone relying on the system to preserve regs
0,1,15 (high half or low half, AR or not) in the absence of explicit
documentation otherwise is doing so at their customers' peril. This is not
new news.

The statement is not correct about STORAGE OBTAIN. The high half of R1 has
been changed on STORAGE OBTAIN ever since high halves existed. I think
that there was a situation, due to user code relying incorrectly on the
high half of reg 15 being unchanged across the invocation, where STORAGE
OBTAIN acceptably changed the high half of GR15 and the incorrect user
code stopped working.


Worse, I can't find the general description that existed way back when
about R15-R1 being transient. If it's still there, it's not in the obvious
location.


I suppose that that depends what you think is the "obvious location". I
think that the obvious location is in the linkage conventions
documentation (which is within the assembler services guide). That is
where the information is.

Copied from the assembler services guide:

Unless otherwise defined by the individual interface, the calling program
expects upon return:
The low halves (Bits 32-63) of GPRs 2 - 13 are unchanged
The high halves (Bits 0-31) of GPRs 2 - 14 are unchanged
ARs 2 - 13 are unchanged
FPRs 8 - 15 are unchanged; The Floating Point Control (FPC) Register is
unchanged except for two fields: the IEEE exception flags and the data
exception code (DXC).
Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 -
23 are unchanged.
When return information is provided in GPR 0, 1, or 15 (for example return
and reason codes), only bits 32-63 of the register contain the returned
value.
Individual interfaces can define that extra registers are unchanged, or
that extra registers are not unchanged, or that returned information in
registers uses more than bits 32-63.

Peter Relson
z/OS Core Technology Design


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

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

Re: WTO

[Seymour J Metz]

That depends. The short answer is that if the parameter list is in dynamic 
storage then it is reentrant.


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



From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: Sunday, November 10, 2019 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO

Guys,

Yeah I found it it happens to be another Well known ISV’s exit. But I have
a question in regard to when this exit is called it’s like IRREVX01 , so I
assume (I know ) that the WTO should be re-entrant. We are basically using
it for diagnostics if needed. Is my assumption correct on the WTO ?

Scott


On Sun, Nov 10, 2019 at 3:59 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 10 Nov 2019 09:30:30 -0500, Peter Relson wrote:
>
> >
> >Yes it's documented and legit, but it's a change in behaviour over the
> >last few z/OS releases. In IIRC z/OS 1.x, WTO did not clobber AR15,
> >and STORAGE OBTAIN did not change the high half of R1.
> >
> >
> >You have no way of knowing if that is true or not. All that you could
> >possibly say is that you did not encounter such a case. The environment
> >that could cause such a case might even not have been under your control
> >and might be uncommon. ...
> >
> I.e. the user, or even an ISV, was depending on undocumented behavior's
> remaining unchanged.
>
> >The statement is not correct about STORAGE OBTAIN. The high half of R1
> has
> >been changed on STORAGE OBTAIN ever since high halves existed. ...
> >
> Does code written at a time before "high halves existed", or perhaps even
> before ARs existed, and depending only on OS behavior documented at
> such a time, continue to operate correctly?  If so, a user has no ground
> for a complaint.  If it fails now, IBM should graciously apologize and move
> on.  The pertinent aphorism is, "You can't make an omelet without breaking
> eggs."
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Scott Ford
IDMWORKS
z/OS Development

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

Gerhard Postpischil ז״ל

[Seymour J Metz]

It is with deep regret that I announce the death of my friend and colleague 
Gerhard Postpischil, whom some of you may know from here, CBTTAPE.ORG or 
Hercules. Someone told his son Eric "You sound like your father." - I can think 
of no greater compliment. Gerhard was a stickler for accuracy and always strove 
to write 
tight code. He was also a good friend to me and my children, and we will miss 
him.



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

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

Re: Is there an MVS service that will list IDENTIFYed entry points?

[Charles Mills]

Perfect. Thanks,

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, November 11, 2019 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there an MVS service that will list IDENTIFYed entry points?


You should see a CDE for the alias. You can use CSVINFO to retrieve a list.


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



From: IBM Mainframe Discussion List  on behalf of
Charles Mills 
Sent: Monday, November 11, 2019 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there an MVS service that will list IDENTIFYed entry points?

In a SYSUDUMP I can see the names of loaded modules, but not (unless I am
missing something) any names added by IDENTIFY. Is there a service that will
return to me the names of all entry points added with IDENTIFY?

CSVQUERY will tell me about one particular entry point name but what if I
wanted to list them all? I'd like a programming service but I would settle
for a console command or the like.

The environment is program A loads program B. I am wondering if A is first
IDENTIFYing entrypoint FOO. I am proposing writing my own B replacement --
it does not really have to do what B does, it just has to load and run --
and query whether entrypoint FOO is IDENTIFYed or not. The new B could run
authorized if that is what is needed.

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

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

Re: Is there an MVS service that will list IDENTIFYed entry points?

[Seymour J Metz]

You should see a CDE for the alias. You can use CSVINFO to retrieve a list.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 11, 2019 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is there an MVS service that will list IDENTIFYed entry points?

In a SYSUDUMP I can see the names of loaded modules, but not (unless I am
missing something) any names added by IDENTIFY. Is there a service that will
return to me the names of all entry points added with IDENTIFY?

CSVQUERY will tell me about one particular entry point name but what if I
wanted to list them all? I'd like a programming service but I would settle
for a console command or the like.

The environment is program A loads program B. I am wondering if A is first
IDENTIFYing entrypoint FOO. I am proposing writing my own B replacement --
it does not really have to do what B does, it just has to load and run --
and query whether entrypoint FOO is IDENTIFYed or not. The new B could run
authorized if that is what is needed.

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

Is there an MVS service that will list IDENTIFYed entry points?

[Charles Mills]

In a SYSUDUMP I can see the names of loaded modules, but not (unless I am
missing something) any names added by IDENTIFY. Is there a service that will
return to me the names of all entry points added with IDENTIFY?

CSVQUERY will tell me about one particular entry point name but what if I
wanted to list them all? I'd like a programming service but I would settle
for a console command or the like.

The environment is program A loads program B. I am wondering if A is first
IDENTIFYing entrypoint FOO. I am proposing writing my own B replacement --
it does not really have to do what B does, it just has to load and run --
and query whether entrypoint FOO is IDENTIFYed or not. The new B could run
authorized if that is what is needed.

Charles

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

Re: Hyphens of mass destruction: When a clumsy finger meant the end for hundreds of (mainframe) jobs . The Register

[Seymour J Metz]

Dyslexia is not just a problem with hyphens. I once typed EXEC CMS ERASE when I 
meant ERASE CMS EXEC and was the fastest PA1 in the West.


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



From: IBM Mainframe Discussion List  on behalf of 
Mark Regan 
Sent: Monday, November 11, 2019 9:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Hyphens of mass destruction: When a clumsy finger meant the end for 
hundreds of (mainframe) jobs . The Register

https://secure-web.cisco.com/10SanL6FUn_ztrcHmnohaEyhDS3eDeJ3ewjeY7ge0il5xl4n3O_jEyEA0c7qIs_Z-3BH0FTf0_o7Pi7o72pdNMFlfcZMLmbWqs4FiIcTtK9w92ofRCXOWfsZNEiIPwWXZzSNKCGH9Qz3kaoSXbSVJ-JbIddfmssjjkv0cXb6ybLhrkgoE-8EQ9MonnjMYrkQodlTv21z1hOewq2Q8QUCxVFyIirlXG8HD2KSRRIGBQEV62sKsbQ7EF3IsdjPnEQcGRjuamcIqaAbJXYrE5Amz23X8ZyaY0wXF6PzejehIJPqgB_mFcmjQSzYjD4HGQfAf_k8b2JQTGDaCaXBogOAwiUoeAb89ZFxLavPHxJnrOVioBSUFHN_FDNIZKduzAjZxmcQSXlAJCDa0ht7rE24Vaw/https%3A%2F%2Fwww.theregister.co.uk%2F2019%2F11%2F11%2Fwho_me%2F



Regards,



Mark T. Regan, K8MTR

CTO1 USNR-Retired,

Nationwide Insurance, Retired






--
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: Hyphens of mass destruction: When a clumsy finger meant the end for hundreds of (mainframe) jobs . The Register

[Paul Gilmartin]

On Mon, 11 Nov 2019 10:59:40 -0500, Steve Smith wrote:

>I'm not sure about JES2 interpreting a job number as negative.  But the
>"convenient" wrap-around range feature did get an operator fired at my shop
>many years ago.  He intended to purge 2 jobs: $PJ1234-1235, but prematurely
>hit enter after $PJ1234-123.  Didn't make any noise until the supervisor &
>managers & users, etc. starting screaming.  Eventually they determined that
>a head must roll.
> 
I've always felt it safer to terminate a loop on inequality (">=") rather
than equality ("=="), particularly with a floating point control variable.
"convenient" be dammed!

-- gil

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

Re: Unix files

[Paul Gilmartin]

On Mon, 11 Nov 2019 11:01:22 -0500, Steve Smith wrote:

>Sounds like a job for a pipe to me.
> 
Or a named pipe for each producer?  But does a named pipe
provide any indication of the producer's terminating/closing it?
Perhaps a recognizable END record?

Does Pierre need to preserve the file contents?  That could be
achieved by the reader's echoing input to those log files.

(In his original post, Pierre mentioned multiple files and multiple
producers.)

>> On Sun, Nov 10, 2019 at 5:54 PM Pierre Fichaud wrote:
>>
>> > I must continuously monitor ("read") a Unix file that contains
>> > diagnostics. I open the file, parse the records and possibly produce
>> > output. Once I've read all the records, I need to wait (or be blocked)
>> > until more data arrives. Then I process the new records. But I want to
>> > know when the writer has closed the file. Then I stop. Regards, Pierre.

-- gil

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

Re: Unix files

[Steve Smith]

Sounds like a job for a pipe to me.

sas


> On Sun, Nov 10, 2019 at 5:54 PM Pierre Fichaud  wrote:
>
> > I must continuously monitor ("read") a Unix file that contains
> > diagnostics. I open the file, parse the records and possibly produce
> > output. Once I've read all the records, I need to wait (or be blocked)
> > until more data arrives. Then I process the new records. But I want to
> > know when the writer has closed the file. Then I stop. Regards, Pierre.
>

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

Re: Hyphens of mass destruction: When a clumsy finger meant the end for hundreds of (mainframe) jobs . The Register

[Steve Smith]

I'm not sure about JES2 interpreting a job number as negative.  But the
"convenient" wrap-around range feature did get an operator fired at my shop
many years ago.  He intended to purge 2 jobs: $PJ1234-1235, but prematurely
hit enter after $PJ1234-123.  Didn't make any noise until the supervisor &
managers & users, etc. starting screaming.  Eventually they determined that
a head must roll.

JES2 doesn't do "Are you sure (Y/N)"... not that I think that's often
helpful.  Systems Programming was subsequently tasked to suppress any JES2
command with a hyphen in it.

sas


On Mon, Nov 11, 2019 at 9:23 AM Mark Regan  wrote:

> https://www.theregister.co.uk/2019/11/11/who_me/
>
>
>
> Regards,
>
>
>
> Mark T. Regan, K8MTR
>
> CTO1 USNR-Retired,
>
> Nationwide Insurance, Retired
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
sas

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

Re: I saw 7 new college mainframe hires!

[ITschak Mugzach]

The Leipzig university (Germany) has a modern mainframe (I think z14) and
is teaching mainframe languages as well.

ITschak

On Mon, Nov 11, 2019 at 4:18 PM Bill Ogden  wrote:

> >Date:Sun, 10 Nov 2019 08:01:24 -0800
> >From:Tom Brennan 
> >Subject: I saw 7 new college mainframe hires!
> >
> >Last week I was invited to an IBM z15 meeting for a particular customer.
> >  There were 7 younger folks in the row behind me who stood out among
> >all the (let's say) "older" people there.  I was amazed when I found out
> >they were recently hired out of college by the customer and are on a 3
> >year mainframe training program.  Great work by the manager who pushed
> >for a long-term solution, and got it approved.  I hope other companies
> >hear about this and consider it.
>
> A few weeks ago I went through some zPDT material with 3 young people
> (very young, from my perspective!)
> who were recently hired by a European customer. The customer's intention
> was to "grow" new sysprogs.
> Wow!  They were each using zPDT systems as their educational sandboxes.
> Apparently a few companies
> are preparing for the future.
>
> Bill
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: High halves, ARs and old vs. new expectations (Was "WTO")

[John McKown]

On Mon, Nov 11, 2019 at 8:45 AM Charles Mills  wrote:

> Sure, there are lots of solutions (assuming the shop is not mortally
> afraid of touching 1993 assembler code, has a budget and staff to do so,
> and can find the source).
>
> My thought is why would the shop expect a problem? Why would a routine
> that has been working since 1993 be a suspect in an obscure
> high-halves-in-compiled-code problem?
>

I guess we'll just have to say "times change". Or, if we want to be
"nasty", we could say "What isn't specifically saved is subject to being
changed." Of course, this means a code review when something significant
changes, such as from 32 bit registers to 64 bit registers. Your code might
not have changed, but IBM's might have. Ergo, all use of an API used in
code _should_ be reviewed. Of course, who has time for that? Curiously, at
least around her, that would be another bullet in the "z/OS is junk"
argument, despite the fact that Windows has historically had even worse
problems.



>
> Charles
>
>

-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Re: Unix files

[Kirk Wolf]

I have used Unix domain datagram sockets for something very similar.   In
this case, a "monitor/server" program would create and open a Unix-domain
datagram socket and wait for messages from clients and process them.
 Clients would look for the existence of the socket as an indication to
write diagnostics to it.
See for example:
https://troydhanson.github.io/network/Unix_domain_sockets.html

Other IPC mechanisms include named pipes (FIFOs) and message queues.
http://docs.hfbk.net/beej.us/bgipc/output/print/bgipc_A4.pdf


On Sun, Nov 10, 2019 at 5:54 PM Pierre Fichaud  wrote:

> I must continuously monitor ("read") a Unix file that contains
> diagnostics. I open the file, parse the records and possibly produce
> output. Once I've read all the records, I need to wait (or be blocked)
> until more data arrives. Then I process the new records. But I want to
> know when the writer has closed the file. Then I stop. Regards, Pierre.
>
> --
> 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: High halves, ARs and old vs. new expectations (Was "WTO")

[Charles Mills]

Sure, there are lots of solutions (assuming the shop is not mortally afraid of 
touching 1993 assembler code, has a budget and staff to do so, and can find the 
source).

My thought is why would the shop expect a problem? Why would a routine that has 
been working since 1993 be a suspect in an obscure high-halves-in-compiled-code 
problem?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, November 11, 2019 6:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: High halves, ARs and old vs. new expectations (Was "WTO")

On Mon, Nov 11, 2019 at 7:52 AM Charles Mills  wrote:

> > The interesting scenario is the case of the "know something" caller
> > calling a "know nothing" target which in turn calls a "know something"
> > target.
>
> I've been thinking about that one for a couple of days. My scenario is
> this:
> a recently-compiled C or COBOL program calling a homegrown assembler
> function untouched since 1993 calling an MVS service, which now of course
> is
> a z/OS V2R4 service.
>
> The C or COBOL expects high halves and ARs to be preserved. The assembler
> routine is ignorant of them. It calls a z/OS function which alters some
> high
> halves. Is there a problem?
>
> I am tending to think not. The z/OS function (hopefully!) does not alter
> anything that the modern C or COBOL expects to be preserved. Am I right?
>
> Charles
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

IMO, don't do a static "call" to the assembler. I don't know off hand if it
is possible, but I'd try to make the HLASM's calling code use the
equivalent of a z/OS LINK macro. If that's not possible, then I'd make a
slight change to the z/OS HLASM to save the 64 bit GRs and the ARs.

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

Hyphens of mass destruction: When a clumsy finger meant the end for hundreds of (mainframe) jobs . The Register

[Mark Regan]

https://www.theregister.co.uk/2019/11/11/who_me/ 

 

Regards,

 

Mark T. Regan, K8MTR

CTO1 USNR-Retired,

Nationwide Insurance, Retired

 

 


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

Re: I saw 7 new college mainframe hires!

[Bill Ogden]

>Date:Sun, 10 Nov 2019 08:01:24 -0800
>From:Tom Brennan 
>Subject: I saw 7 new college mainframe hires!
>
>Last week I was invited to an IBM z15 meeting for a particular customer. 
>  There were 7 younger folks in the row behind me who stood out among 
>all the (let's say) "older" people there.  I was amazed when I found out 
>they were recently hired out of college by the customer and are on a 3 
>year mainframe training program.  Great work by the manager who pushed 
>for a long-term solution, and got it approved.  I hope other companies 
>hear about this and consider it.

A few weeks ago I went through some zPDT material with 3 young people 
(very young, from my perspective!)
who were recently hired by a European customer. The customer's intention 
was to "grow" new sysprogs.
Wow!  They were each using zPDT systems as their educational sandboxes. 
Apparently a few companies
are preparing for the future.

Bill


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

Re: High halves, ARs and old vs. new expectations (Was "WTO")

[John McKown]

On Mon, Nov 11, 2019 at 7:52 AM Charles Mills  wrote:

> > The interesting scenario is the case of the "know something" caller
> > calling a "know nothing" target which in turn calls a "know something"
> > target.
>
> I've been thinking about that one for a couple of days. My scenario is
> this:
> a recently-compiled C or COBOL program calling a homegrown assembler
> function untouched since 1993 calling an MVS service, which now of course
> is
> a z/OS V2R4 service.
>
> The C or COBOL expects high halves and ARs to be preserved. The assembler
> routine is ignorant of them. It calls a z/OS function which alters some
> high
> halves. Is there a problem?
>
> I am tending to think not. The z/OS function (hopefully!) does not alter
> anything that the modern C or COBOL expects to be preserved. Am I right?
>
> Charles
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

IMO, don't do a static "call" to the assembler. I don't know off hand if it
is possible, but I'd try to make the HLASM's calling code use the
equivalent of a z/OS LINK macro. If that's not possible, then I'd make a
slight change to the z/OS HLASM to save the 64 bit GRs and the ARs.


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Re: WTO

[John McKown]

On Fri, Nov 8, 2019 at 2:30 PM scott Ford  wrote:

> All:
>
> I have a bit of an issue I am trying to resolve in Assembler. We use a
> skeleton exit from another vendor and it has been working fine.
> It is re-entrant and keep seeing normal WTO's , i.e. ;  WTO
> 'X',ROUTCDE=11 , are not appearing on SYSLOG. We are using the
> WTOS to track through the flow of the exit. Could what i am seeing the exit
> being re-entrant and since WTO's use R1 that R1 is being destroyed by
> some task  ??
>
> Scott
>
> --
>

Not every WTO goes to SYSLOG. A message can be suppressed my an MPF exit,
or an "automated operations" package. Even without those, a message must
pass some criteria to be included. Those are listed here :
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag300/iea3g371.htm
(there
is "Have the “hardcopy only” message delivery attribute" which migt be OK).

To me the simplest way to ensure it is written to the SYSLOG is to use a
DESC of either 1, 2, 3, 11, or 12. 1 is "Systen Failure" (nope, wouldn't
use that). 2 is "Immediate Action Required" (nope). 3 is "Eventual Action
Require" (perhaps). 11 is "Critical Eventual Action Required" (nope). 12 is
"Important Information" (sound good to me).

Of course, check that R1 is correct and then check R15 upon return to see
if something "bad" happened.

Also, as an alternative to WTO is the WTL macro.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa900/iea3a9_Description23.htm
But
IBM says "IBM® recommends you use the WTO macro with the MCSFLAG=HRDCPY
parameter instead of WTL, because WTO supplies more data than WTL."



-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

High halves, ARs and old vs. new expectations (Was "WTO")

[Charles Mills]

> The interesting scenario is the case of the "know something" caller 
> calling a "know nothing" target which in turn calls a "know something" 
> target.

I've been thinking about that one for a couple of days. My scenario is this:
a recently-compiled C or COBOL program calling a homegrown assembler
function untouched since 1993 calling an MVS service, which now of course is
a z/OS V2R4 service. 

The C or COBOL expects high halves and ARs to be preserved. The assembler
routine is ignorant of them. It calls a z/OS function which alters some high
halves. Is there a problem?

I am tending to think not. The z/OS function (hopefully!) does not alter
anything that the modern C or COBOL expects to be preserved. Am I right?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Monday, November 11, 2019 5:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WTO


Does code written at a time before "high halves existed", or perhaps even
before ARs existed, and depending only on OS behavior documented at
such a time, continue to operate correctly? 


I can't think of a case where it wouldn't. Because such code would not 
have known anything about AMODE 64 or high halves. It would not have had 
any instructions or behavior that could have been affected by data in any 
high half (or any AR). That is why (at least "old") services (even with 
newer support that deals with 64-bit regs) are not supposed to look at 
data in high halves if the caller is not AMODE 64. That is why old 
services are not supposed to look at ARs if the caller is not AMODE 31. 
Going back to MVS/XA, that is why old services are not supposed to look at 
the high byte of an address if the caller is not AMODE 31 (and, now, is 
not AMODE 64). Services created after the advent of a new function (be 
that 64-bit GRs, ARs, or whatever) might always require the user to be 
cognizant of those new functions.

The interesting scenario is the case of the "know something" caller 
calling a "know nothing" target which in turn calls a "know something" 
target.
The "know nothing" target would not have any code to preserve high halves 
(or ARs if it went that far back). This is behind the asymmetry in the 
linkage convention for GRs (high half of GR14 is preserved, low half of 
GR14 is not for the AMODE 31 case). I'll leave it as an exercise to the 
reader of how this could be important. For AMODE 64 cases, that asymmetry 
does not exist. I'd bet that there are (likely many) branch-entry services 
that do not follow this convention; almost all get away with it just fine 
(if you're PC-entered or even if you use BAKR to save regs, you're pretty 
much safe because the PR restores the saved reg 14). Using the high half 
of GR14, when not AMODE 64, for saving "something" and expecting that to 
be preserved across a branch-entry interface is counter-intuitive (even if 
the linkage convention says you can do so). I'd guess that almost no one 
codes to such an expectation. But then I'd have guessed the same would be 
true for the high halves of GR0 and GR1 and GR15 (and AR1 and AR15) where 
they should have known better.

Peter Relson
z/OS Core Technology Design


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

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

Re: JES NOTIFY EMAIL=

[Carmen Vitullo]

thanks for your insight Brian, I'll have to check my security once, more, I 
would hope IBM support would have seen the security issues back in August when 
I opened the PMR and received the first trace 
as I said before they assured my my security was setup correctly 



Carmen Vitullo 

- Original Message -

From: "Brian Westerman"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, November 9, 2019 4:27:48 PM 
Subject: Re: JES NOTIFY EMAIL= 

On Fri, 8 Nov 2019 09:35:43 -0600, Carmen Vitullo  wrote: 

>David I feel your pain, we are also a TSS shop, CA (BROADCOM) has some good 
>doc on converting RACF to TSS, if you need I'll see if I can get the link to 
>you. 
> 
>my previous reply to Brian never was posted, 
> 
>agree, and what I do not understand, is the freebee software like JES2MAIL and 
>other paid products work well, access our SMTP passthru server with no issues, 
>this is not just a JES2EDS issue, but a normal notification issue from z/OSMF, 
>I can sent email's from OPS, from JCL batch, no issues, using the same 
>configuration, I'm trying to get ahead of the game and setup all the parts 
>pieces for z/OSMF, I suspect the notification, once we're are forced to us 
>this POC, will be very important. 
>another trace yesterday sent to level 2, SEV2 ticket still open since Aug 27th 
>:( 
> 
>-- 
>For IBM-MAIN subscribe / signoff / archive access instructions, 
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


Yes, the problem with the new JES mail option isn't getting CSSMTP to work with 
it, you will likely find that you missed one of the install steps or 
misinterpreted the results like I did (3 times). I ended up going through the 
entire install 4 times before I got it "right" thinking that everything was 
fine each time and it turned out that while the steps all seemed to have 
worked, checking the content of the issued messages themselves pointed to the 
problem I had with the izudflt.zosmf.notification.notify part. It turned out 
that no one (except zosmf itself) was authorized to send the email. :( 

But even when it was done and completely implemented, it wasn't even as nice as 
the stuff you can get off the freeware tapes. It is a particular pain to have 
to actually add the notify card to the jobs. I think there are several better 
ways that it could have been handled and it could have been much more 
comprehensively implemented. While it doesn't "suck" per se, it's not really 
worth the enormous effort for such a small "feature". If you already are 
running z/OSMF, then adding it is not going to really be a big deal, but I 
don't see any part of it which is worth the effort to implement (and actually 
run since z/OSMF is installed for you at serverpak now), all of z/OSMF just to 
get the notify part. 

I just keep falling back to the fact that if you don't make something simple 
and easy to use, that most people just won't bother to use it, at least not 
when it counts. We made SyzMPF/z and SyzMAIL/z so that normal installation is 
on the order of 10 minutes or less. I can't imagine what they were thinking 
when they decided to design the notify feature of z/OSMF but I'm thinking that 
it wasn't ease of implementation or use. :) 

Brian Westerman 
Syzygy Incorporated 
www.SyzygyInc.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: Unix files

[John McKown]

On Sun, Nov 10, 2019 at 8:00 AM Pierre Fichaud  wrote:

> I want to process Unix files in a sub-task.  The files are being written
> into by applications in other address spaces. I open the file (BPX1OPN).  I
> need to read all the records. errno EAGAIN seems to say that there are no
> new records in the file. So I would WAIT and retry. Does this make sense ?
> I also want to know if the file is still being written into. BPX1FST (file
> status) will return an area. Does the field ST_NLINK tell me how many
> "OPENs" have been done ? If I'm the only one connected to the file, would
> ST_NLINK have a value of 1?
>
> Thanks in advance, Pierre.
>
>
I don't know off hand the best way. However! You are describing what the
"tail -f" command does in Linux. The source for that is part of "coreutils"
and is at https://ftp.gnu.org/gnu/coreutils/ . It will be in C, but
hopefully it will make sense as to the technique used by some of the best
FOSS people on the planet.

-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

Re: WTO

[Peter Relson]

Does code written at a time before "high halves existed", or perhaps even
before ARs existed, and depending only on OS behavior documented at
such a time, continue to operate correctly? 


I can't think of a case where it wouldn't. Because such code would not 
have known anything about AMODE 64 or high halves. It would not have had 
any instructions or behavior that could have been affected by data in any 
high half (or any AR). That is why (at least "old") services (even with 
newer support that deals with 64-bit regs) are not supposed to look at 
data in high halves if the caller is not AMODE 64. That is why old 
services are not supposed to look at ARs if the caller is not AMODE 31. 
Going back to MVS/XA, that is why old services are not supposed to look at 
the high byte of an address if the caller is not AMODE 31 (and, now, is 
not AMODE 64). Services created after the advent of a new function (be 
that 64-bit GRs, ARs, or whatever) might always require the user to be 
cognizant of those new functions.

The interesting scenario is the case of the "know something" caller 
calling a "know nothing" target which in turn calls a "know something" 
target.
The "know nothing" target would not have any code to preserve high halves 
(or ARs if it went that far back). This is behind the asymmetry in the 
linkage convention for GRs (high half of GR14 is preserved, low half of 
GR14 is not for the AMODE 31 case). I'll leave it as an exercise to the 
reader of how this could be important. For AMODE 64 cases, that asymmetry 
does not exist. I'd bet that there are (likely many) branch-entry services 
that do not follow this convention; almost all get away with it just fine 
(if you're PC-entered or even if you use BAKR to save regs, you're pretty 
much safe because the PR restores the saved reg 14). Using the high half 
of GR14, when not AMODE 64, for saving "something" and expecting that to 
be preserved across a branch-entry interface is counter-intuitive (even if 
the linkage convention says you can do so). I'd guess that almost no one 
codes to such an expectation. But then I'd have guessed the same would be 
true for the high halves of GR0 and GR1 and GR15 (and AR1 and AR15) where 
they should have known better.

Peter Relson
z/OS Core Technology Design


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

Re: I saw 7 new college mainframe hires!

[Parwez Hamid]

I hope this is growing trend and continues elsewhere. Last week there were at 
least 25 of these young ones at the UK Guide Share Conference. They had there 
own '101' track. A number of sessions were actually presented by those who have 
been working with IBM Z for a couple of years!

If this continues at this rate, I will need to continue attending just to bring 
the average age up:-)

Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
scott Ford 
Sent: 11 November 2019 01:53
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: I saw 7 new college mainframe hires!

Great I love it

On Sun, Nov 10, 2019 at 8:29 PM Wayne Bickerdike  wrote:

> At Share in Phoenix there were some young folks from a Swedish bank. Still
> writing in Assembler.
>
> On Mon, Nov 11, 2019 at 12:17 PM Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > There are still a lot of mainframes. The last conference I went to, I
> > noticed quite a few people under 40 in attendance.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Sunday, November 10, 2019, 2:36 PM, Tom Brennan <
> > t...@tombrennansoftware.com> wrote:
> >
> > Last week I was invited to an IBM z15 meeting for a particular customer.
> >   There were 7 younger folks in the row behind me who stood out among
> > all the (let's say) "older" people there.  I was amazed when I found out
> > they were recently hired out of college by the customer and are on a 3
> > year mainframe training program.  Great work by the manager who pushed
> > for a long-term solution, and got it approved.  I hope other companies
> > hear about this and consider it.
> >
> > --
> > 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
> >
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Scott Ford
IDMWORKS
z/OS Development

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