Re: thoughts on z/OS ftp server enhancement.

[Paul Gilmartin]

On Fri, 24 Mar 2017 21:53:45 -0500, Mike Schwab wrote:

>How about doing a portion of the dataset, FTP the result, delete the
>intermediate file.  Repeat for each segment.  I. E. last 1 or 2 digits
>of an account number, etc.  Using the high order digits could lead to
>some groups being pretty large, I.E. SS#s.  Or X number of records.
>2nd run skip X, process X.  3rd run Skip 2X, process X, etc.
> 
FTP from a DDNAME allocated from the output of a POSIX pipe the
input to which is the output of your transformation utility.
(Requires both UNIX and z/OS competency and whatever management
authorization.)

Beware!  I've noticed that FTP expects the DDNAME to be allocated to
a file or data set and finds and respects the attributes of that data set,
sometimes ignoring overriding allocation attributes.

>On Fri, Mar 24, 2017 at 8:08 AM, John McKown wrote:
>>
>> ... We can't get more
>> DASD basically because we are doing the ftp's to move data off of z/OS in
>> order to "get off the obsolete mainframe and on to current cloud based
>> systems" (managements' words, not mine). ...

-- gil

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

Re: thoughts on z/OS ftp server enhancement.

[Mike Schwab]

How about doing a portion of the dataset, FTP the result, delete the
intermediate file.  Repeat for each segment.  I. E. last 1 or 2 digits
of an account number, etc.  Using the high order digits could lead to
some groups being pretty large, I.E. SS#s.  Or X number of records.
2nd run skip X, process X.  3rd run Skip 2X, process X, etc.

On Fri, Mar 24, 2017 at 8:08 AM, John McKown
 wrote:
> On Fri, Mar 24, 2017 at 6:41 AM, Steve Smith  wrote:
>
>> I am over my self-imposed daily limit on IBM-MAIN replies and it's not even
>> 08:00 yet.  However, I see no reason to "enhance" ftp.  In fact, I think
>> the capability to convert to/from ASCII is misguided (as it's used by
>> mistake as often as on purpose - see above).
>>
>> Do whatever it takes to create the actual data set you want to transmit,
>> *then* invoke ftp to transmit it.
>>
>
> As the OP for this thread, I would generally concur with the above. The
> problem, at present, is that the files of which I am speaking are multi-GiB
> data sets and finding more DASD space can be problematic. We can't get more
> DASD basically because we are doing the ftp's to move data off of z/OS in
> order to "get off the obsolete mainframe and on to current cloud based
> systems" (managements' words, not mine). We could do BINARY ftps, but that
> would require more money to write a Windows program to read the data in
> "mainframe" format and write it out in "Windows" format. We do have
> Microfocus COBOL. Interestingly(?), it can read the "mainframe encoded"
> data (EBCDIC, z series integers & packed decimal) just fine. Unfortunately,
> unless I'm missing something, there is not any option to read in "mainframe
> encoded" mode but write out in "Windows encoded" mode. Of course, being a
> despised mainframe sysprog, I'm not allowed access to the PC environment
> where all this is going on.
>
>
>
>>
>> --
>> sas
>>
>>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: thoughts on z/OS ftp server enhancement.

[Frank Swarbrick]

Seems like those two would be great candidates for PowerExchange mapping, since 
it sounds like it fits in to their current job descriptions.  But what do I 
know!  :-(



From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 24, 2017 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: thoughts on z/OS ftp server enhancement.

On Fri, Mar 24, 2017 at 2:56 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Sad.
>
>
> It's my observation that the best person to create the PowerExchange maps
> is someone who knows the mainframe data.  But if they won't let you or
> another mainframer do it, and they won't / can't do it themselves, well it
> sounds like they are once again screwing themselves.  (Do you have any
> mainframe developers left?)
>

Two, who are in the midst of doing the data transformation (VSAM to
sequential, plus other sequential data) and the Mainframe to Micro Focus
COBOL conversion and testing. Micro Focus is supposedly helping us, but
there appears to be some sort of contract "glitch", about which I know
little and will say nothing more.



>
>
> Frank
>


--
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

--
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: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2

[Andy Wood]

On Fri, 24 Mar 2017 14:26:14 -0500, Joel M Ivey  wrote:

. . .
>+972 4140 0004 
>+976 1904 
>+978 4770 C986 <- 
>+97C 5802  
>+980 41F0 0004 
>+984 07FE 
>

I don't have the luxury of your assembly listing, but the ESTAE in the source 
code from cbttape.org looks like this:

RECOVERY DS0H   0844
 USING *,R15  SET UP ADDRESSABILITY 0845
 LAR4,4   PUT 4 IN REGISTER FOR COMPARE 0846
 CRR0,R4  IS SDWA PRESENT?  0847
 BNE   HAVESDWA   YES, BR TO PROCESS WITH SDWA  0848
 L R0,0(R2)   LOAD RETRY ADDRESS FROM PARAM LIST0849
 LAR15,4  SET RETCODE TO RETRY ADDR IN R0   0850
 BRR14RETURN TO PROCESSOR WITH RETRY ADDR   0851
HAVESDWA DS0H ENTER HERE IF SDWA PRESENT  

That code mirrors what support found, *except* it would appear that it is 
assembled from code which has the "  USING *,R15 " statement missing (in the 
object code, the BNE instruction is using R12, which is a mainline base 
register, not R15 as it should).

That makes me think that for some reason you are perhaps  *not* executing the 
version of IEFACTRT that you think you are, and that installing a new one, from 
SAMPLIB or elsewhere, is not going to help you until you figure out exactly why 
that is happening.  For a start, check your listing. You might have received a 
warning about an overlapping USING, but I think the correct code should still 
have been generated in this instance for the BNE instruction.

Over the years I saw problems like this many times when recovery (or retry) 
routines made unwarranted assumptions about the content of certain registers, 
particularly base registers, and the warning about the possibly dire 
consequences is justified. One such case is still firmly etched in my memory, 
well over ten years later - the wild branch there happened to take it part way 
into an instruction, which unfortunately was executed as a perfectly valid LCTL 
instruction. The results of loading rubbish into half of the control registers 
is not pretty.

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

l...@garlic.com (Anne & Lynn Wheeler) writes:
> For the 3090, they originally planned on using a 4331 with a highly
> modified version of vm370/cms release 6 as the service process ... with
> all service screens done in CMS IOS3270. This was upgraded to a pair of
> redundant 4361s. The 3092 ("service processor", i.e. pair of 4361s) has
> requirement for two FBA3370s (even for MVS customers that never
> supported FBA). ... 3090 announced 12Feb1985 (including requirement for
> two FBA3370s for 3092 service processor)
> https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

re:
http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of 
the mainframe

other 3092 lore. Early in the days of REX (before rename to REXX and
release to customers), I wanted to demonstrated REX was not just another
pretty scripting language so I chose as demonstration to rewrite IPCS
(dump reader, huge amount of assembler code) in less than 3months
elapsed time working less than half time would have ten times the
function and run ten times faster (some tricky coding to make
interpreted rex run ten times faster than assembler). I finished early,
so developed a set of automated library routines that would examine for
the most common types of failures.

I thot that it would then be released to customers as upgrade to
existing IPCS, but for some reason that never happened  even tho it
came to be in use by nearly every internal datacenter and customer
PSR. I eventually got permission to make presentations on DUMPRX and how
it was implemented ... and within several months, similar
implementations started appearing at customers.

Eventually the 3092 service process group contacted me about including
it in 3092 release. Since their vm370/cms release 6 was heavily modified
and out-of-date, they had to do almost all the service themselves and
they relied heavily on DUMPRX. some old email from the 3092 group
http://www.garlic.com/~lynn/2010e.html#email861031
http://www.garlic.com/~lynn/2010e.html#email861223

past posts mentioning dumprx
http://www.garlic.com/~lynn/submain.html#dumprx

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

r.skoru...@bremultibank.com.pl (R.S.) writes:
> BTW:
> What about LPARs?

re:
http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of 
the mainframe

FE had failure diagnoses requirement for bootstrap scope'able process.
3081 were inside TCM and no longer scope'able. Process was then a
scope'able service processor ... that could be diagnosed/repaired and
then the service processor had large number of probes into TCMs and the
service processor could be used to diagnose the TCMs. The 3081 service
processor was UC microprocessor and everything had to be developed and
implemented from scratch.

For the 3090, they originally planned on using a 4331 with a highly
modified version of vm370/cms release 6 as the service process ... with
all service screens done in CMS IOS3270. This was upgraded to a pair of
redundant 4361s. The 3092 ("service processor", i.e. pair of 4361s) has
requirement for two FBA3370s (even for MVS customers that never
supported FBA). ... 3090 announced 12Feb1985 (including requirement for
two FBA3370s for 3092 service processor)
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

I had done a lot of work on ECPS microcode assist and later would
give talks on the implementation at monthly user group meetings ...
and the Amdahl people would talk to me about their hypervisor
implementation ... old email from 1980
http://www.garlic.com/~lynn/2006p.html#email801121

mentioned in upthread discussion in this post archived here
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe

IBM eventually responds to Amdahl's hypervisor with PR/SM & LPAR
on the 3090 (announced 12Feb1985)

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: GREAT presentation on the history of the mainframe

[Tom Brennan]

John McKown wrote:

​No HMC. The console looked like a 3270 which was "built into" the machine.


Was that the specialized console where I used to type things like L1 and 
A2 (or whatever it was) to set the load address and IPL?  I don't 
remember the exact commands - from 3084 days.  And then there was the 
really loud beep when a box would go into a disabled wait state.  Ouch.


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

Re: GREAT presentation on the history of the mainframe

[Jesse 1 Robinson]

I totally agree with the dismay expressed at omission of 9672/9674. I've only 
been in this biz since the late 70s, but I was blown away at the architectural 
upheaval represented by the move from bipolar to CMOS. Yet the 9672 still ran 
decades-old programs without even recompile, let alone revision. 

The 9672 ran rather like a dog in the early days. We had to modify SMF exits to 
allow up to three times the coded CPU limit for batch jobs to avoid S322. But 
it worked, and as time went on, the CMOS processors became faster than the 
bipolar machines they replaced. I smell genius. ;-)

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Friday, March 24, 2017 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GREAT presentation on the history of the mainframe

On Fri, Mar 24, 2017 at 2:44 PM, R.S. 
wrote:

> W dniu 2017-03-24 o 18:04, Pommier, Rex pisze:
>
>> The only thing I wish he would have included in the presentation was 
>> the original 9672/9674 which was a huge shift from the GA-AS 
>> technology to silicon.
>>
>
> I wish I hadn't worked on pre-9672 machines.
> Was it really non-silicon? I was pretty sure it was silicon, but ECL, 
> not CMOS.
>
> BTW:
> What about LPARs?
>

​Yes. In "partitioned mode".


> How HMC looked like? Was it PC-DOS-based?
>

​No HMC. The console looked like a 3270 which was "built into" the machine.
Older ones had _dials_ and _buttons_ and _LIGHTS_! Oh, how I miss the lights.​



> What about I/O cards? were they similar to cards available in 9672?
> What OSA options were available?
>

​No OSAs. Had to have an outboard controller on a regular byte multiplexer 
channel (not block or selector).​



> What about cryptoHW?
>

​ No co-processor cards. Unless you think of integrated channels as a 
co-processor, that is.


>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>


--
"Irrigation of the land with seawater desalinated by fusion power is ancient. 
It's called 'rain'." -- Michael McClary, in alt.fusion

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: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

l...@garlic.com (Anne & Lynn Wheeler) writes:
> Endicott then complains tht the 5-way 370/125 SMP has better
> performance and better price/performance than 370/148 and I'm required
> in escalation meetings to argue both sides. Endicott wins ... and the
> 5-way SMP 370/125 is never announced.

re:
http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of 
the mainframe

note later, 3033 was really threatened by 4341 ... clusters of 4341 had
better performance, throughput, price/performance, lower floor
footprint, lower environmentals and power/instruction than 3033.  at one
point head of POK was so threatened that he got allocation of critical
4341 manufacturing component cut in half.

some large customers were also ordering hundreds of 4300s at a time for
placing out in departmental areas ... the leading edge of the coming
distributed computing tsunami. Internally, IBM was putting so many
distributed 4300s out in departmental conference rooms that conference
rooms became a scarce commodity.

The big explosion in distributed 4300s also attracted the MVS group,
they had the problem was that the only disks for non-datacenter were FBA
and MVS never bothered with FBA support. Eventually they did come out
with 3375, CKD simulated on FBA3370 ... however it didn't do much good,
the distributed environment requirement was also for scores of 4300
systems per support person ... while MVS required scores of support
people per system. some old 4300 email
http://www.garlic.com/~lynn/lhwemail.html#4341

I also got sucked into doing early benchmarks (on engineering 4341) for
LLNL that was looking at getting 70 for computer farm ... leading edge
of the coming cluster supercomputers. single 4341 benchmarked faster
than 370/158 and 3031 (in addition to clusters having better throughput
and price/performance than 3033). past posts mentioning "RAIN" benchmark
(objective was that it run approx. as fast as CDC6600)
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine 
was it?
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine 
was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine 
was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine 
was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After 
Multi-Core?
http://www.garlic.com/~lynn/2006y.html#21 moving on
http://www.garlic.com/~lynn/2007d.html#62 Cycles per ASM instruction
http://www.garlic.com/~lynn/2009d.html#54 mainframe performance
http://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source 
Apps
http://www.garlic.com/~lynn/2009r.html#37 While watching Biography about Bill 
Gates on CNBC last Night
http://www.garlic.com/~lynn/2011c.html#65 Comparing YOUR Computer with 
Supercomputers of the Past
http://www.garlic.com/~lynn/2011d.html#40 IBM Watson's Ancestors: A Look at 
Supercomputers of the Past
http://www.garlic.com/~lynn/2012n.html#45 Under what circumstances would it be 
a mistake to migrate applications/workload off the mainframe?
http://www.garlic.com/~lynn/2013.html#38 DEC/PDP minicomputers for business in 
1968?
http://www.garlic.com/~lynn/2013c.html#53 What Makes an Architecture Bizarre?
http://www.garlic.com/~lynn/2014c.html#61 I Must Have Been Dreaming (36-bit 
word needed for ballistics?)
http://www.garlic.com/~lynn/2014j.html#37 History--computer performance 
comparison chart
http://www.garlic.com/~lynn/2015h.html#71 Miniskirts and mainframes
http://www.garlic.com/~lynn/2015h.html#106 DOS descendant still lives was Re: 
slight reprieve on the z
http://www.garlic.com/~lynn/2016e.html#116 How the internet was invented
http://www.garlic.com/~lynn/2016h.html#44 Resurrected! Paul Allen's tech team 
brings 50-year-old supercomputer back from the dead
http://www.garlic.com/~lynn/2016h.html#49 Resurrected! Paul Allen's tech team 
brings 50-year -old supercomputer back from the dead
http://www.garlic.com/~lynn/2016h.html#51 Resurrected! Paul Allen's tech team 
brings 50-year -old supercomputer 

Re: thoughts on z/OS ftp server enhancement.

[John McKown]

On Fri, Mar 24, 2017 at 2:56 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Sad.
>
>
> It's my observation that the best person to create the PowerExchange maps
> is someone who knows the mainframe data.  But if they won't let you or
> another mainframer do it, and they won't / can't do it themselves, well it
> sounds like they are once again screwing themselves.  (Do you have any
> mainframe developers left?)
>

​Two, who are in the midst of doing the data transformation (VSAM to
sequential, plus other sequential data) and the Mainframe to Micro Focus
COBOL conversion and testing. Micro Focus is supposedly helping us, but
there appears to be some sort of contract "glitch", about which I know
little and will say nothing more.​



>
>
> Frank
>


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: GREAT presentation on the history of the mainframe

[John McKown]

On Fri, Mar 24, 2017 at 2:44 PM, R.S. 
wrote:

> W dniu 2017-03-24 o 18:04, Pommier, Rex pisze:
>
>> The only thing I wish he would have included in the presentation was the
>> original 9672/9674 which was a huge shift from the GA-AS technology to
>> silicon.
>>
>
> I wish I hadn't worked on pre-9672 machines.
> Was it really non-silicon? I was pretty sure it was silicon, but ECL, not
> CMOS.
>
> BTW:
> What about LPARs?
>

​Yes. In "partitioned mode".


> How HMC looked like? Was it PC-DOS-based?
>

​No HMC. The console looked like a 3270 which was "built into" the machine.
Older ones had _dials_ and _buttons_ and _LIGHTS_! Oh, how I miss the
lights.​



> What about I/O cards? were they similar to cards available in 9672?
> What OSA options were available?
>

​No OSAs. Had to have an outboard controller on a regular byte multiplexer
channel (not block or selector).​



> What about cryptoHW?
>

​ No co-processor cards. Unless you think of integrated channels as
a co-processor, that is.


>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: thoughts on z/OS ftp server enhancement.

[Frank Swarbrick]

Sad.


It's my observation that the best person to create the PowerExchange maps is 
someone who knows the mainframe data.  But if they won't let you or another 
mainframer do it, and they won't / can't do it themselves, well it sounds like 
they are once again screwing themselves.  (Do you have any mainframe developers 
left?)


Frank


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 24, 2017 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: thoughts on z/OS ftp server enhancement.

On Fri, Mar 24, 2017 at 11:13 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> There is a true ETL tool component, PowerExchange by Informatica that
> allows the actual ETL Tool (PowerCenter) to read IMS and VSAM files as if
> they were relational tables.  In general I would recommend this, but I
> don't have a sense of the "permanence" of the process you are concerned
> about.  So I don't know that you'd want to invest in such a product for a
> short term need.
>
>
> Anyway, you basically feed in a COBOL copybook that describes your file
> (or IMS database).  PowerExchange then generates one or more table
> structures that can be queried by PowerCenter.  PowerCenter would use these
> queries to actually load the data in to a true relational database.
>

We have that product. And, once again, I am at a lose because the people
who used it on the PC side are gone and nobody knows/wants to learn how to
use it. But I'll present it again as a possibility. We have a lot of
attitude of "that is mainframe. Don't expect me to help you. Oh, and give
me this data in a form that I can use directly, right now."



>
>
> Or something like that.  I've only worked on the PowerExchange side, not
> the PowerCenter side.
>
>
> There is a PowerExchange STC that runs on z/OS and deals with both the
> data mapping and data transmission.  No FTP involved.
>
>
> Probably there are other similar tools, but this is the only one I am
> personally aware of.
>
>
> Frank
>

--
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

--
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: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2

[Lizette Koehler]

I was wondering if you have looked at the sample SYS1.SAMPLIB for member 
IEEACTRT

We typically used the sample IBM Supplied

Lizette


-Original Message-
>From: Joel M Ivey 
>Sent: Mar 24, 2017 12:26 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: 0C4, 071, 822 abends in IEFACTRT after zOS 2.2
>
>After migrating to zOS 2.2, a vendor-customized IEFACTRT routine 
>started getting 0c4, 071, and 822 abends in certain highly-used 
>initiators.  We discovered that the vendor portion was supposed 
>to have been removed prior to 2.2 so we removed their custom 
>module.  Abends still occurred.  We downloaded the latest source of
>IEFACTRT from CBT109, compared it to what we already had and there 
>were very few differences.  We assembled the latest
>source and moved it into production.   Same thing.  
>
>An excerpt from IBM support, in reference to the latest CBT109 IEFACTRT:
>"This 0C4 abend led to IEFACTRT's recovery routine being invoked. 
>According the the SCB control block, the recovery routine is located at 
>+x'972':
> 
>+972 4140 0004 
>+976 1904 
>+978 4770 C986 <- 
>+97C 5802  
>+980 41F0 0004 
>+984 07FE 
>
>"On entry to this routine, regs R3-R12 are zeroes - so the instruction at 
>+x'978' triggers a branch to address 0986. This address is in the PSA, 
>and is used as a savearea by disabled routines. As a result, the contents at 
>this address may vary - leading to unpredictable abends - including 0c1 
>abends and spin loops."
>
>Any other shops have issues on zOS 2.2 with CBT109 IEFACTRT?
>
>Thanks,
>Joel M Ivey
>

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

Re: GREAT presentation on the history of the mainframe

[R.S.]

W dniu 2017-03-24 o 18:04, Pommier, Rex pisze:

The only thing I wish he would have included in the presentation was the 
original 9672/9674 which was a huge shift from the GA-AS technology to silicon.


I wish I hadn't worked on pre-9672 machines.
Was it really non-silicon? I was pretty sure it was silicon, but ECL, 
not CMOS.


BTW:
What about LPARs?
How HMC looked like? Was it PC-DOS-based?
What about I/O cards? were they similar to cards available in 9672?
What OSA options were available?
What about cryptoHW?

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

0C4, 071, 822 abends in IEFACTRT after zOS 2.2

[Joel M Ivey]

After migrating to zOS 2.2, a vendor-customized IEFACTRT routine 
started getting 0c4, 071, and 822 abends in certain highly-used 
initiators.  We discovered that the vendor portion was supposed 
to have been removed prior to 2.2 so we removed their custom 
module.  Abends still occurred.  We downloaded the latest source of
IEFACTRT from CBT109, compared it to what we already had and there 
were very few differences.  We assembled the latest
source and moved it into production.   Same thing.  

An excerpt from IBM support, in reference to the latest CBT109 IEFACTRT:
"This 0C4 abend led to IEFACTRT's recovery routine being invoked. 
According the the SCB control block, the recovery routine is located at +x'972':
 
+972 4140 0004 
+976 1904 
+978 4770 C986 <- 
+97C 5802  
+980 41F0 0004 
+984 07FE 

"On entry to this routine, regs R3-R12 are zeroes - so the instruction at 
+x'978' triggers a branch to address 0986. This address is in the PSA, 
and is used as a savearea by disabled routines. As a result, the contents at 
this address may vary - leading to unpredictable abends - including 0c1 
abends and spin loops."

Any other shops have issues on zOS 2.2 with CBT109 IEFACTRT?

Thanks,
Joel M Ivey

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

TSS - TSSINSTX

[Steely.Mark]

Cross posted in CA-Communities

Does anyone have a sample RESOURCE ACCESS VALIDATION EXIT (TSSINSTX)? We are 
trying to determine the best way to protect keys in ICSF. We have a resource 
class defined as CSFKEYS. The CICS regions are bypassing  the CSFKEYS check due 
to the option of NORESCHK. Can  the exit could force a check if CSFKEYS 
resource is requested. I have the sample provided by CA but it doesn't have any 
code for the resource access validation section.

Thanks

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

arno...@us.ibm.com (Todd Arnold) writes:
> 360 processors with special microcode were used in a number of things.
> Early in my career, I worked on development of the IBM 3890 high-speed
> check sorter.  (https://en.wikipedia.org/wiki/IBM_3890) The controller
> in that sorter was a 360 mod 25, with all the code written in native
> microcode - no 360 instruction set.  It turned out to be very fast,
> and it was many years before IBM was able to find anything to replace
> that old mod 25 with its core memory.

re:
http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?)

nearly all 360s & 370s had integrated channels (engine was shared
between simulating 360/370 instructions and running channel microcode)
... it was only the high-end machines that had dedicated external
channles 360/65 & above, 165/168, etc.

boeblingon got their hands slapped by corporate for the 370/115 &
370/125. The 370/115 had nine-position memory bus for microprocessors
... all identical ... one microprocessor was programmed for simulating
370 instructions and one or several other microprocessors programmed
with controller microcode (i.e. not only integrated channels, but also
integrated controllers). The 370/125 was identical to the 370/115 except
the microprocessor running the 370 instruction simulation microcode was
50% faster (than the othere microprocessors).

Very few customer 115/125 configurations had more than 2-3 controller
microprocessors, so they suck me into doing a 5-way SMP multiprocessor
design for 370/125 (I also do a bunch of enhancements including queued
IO/interrupt akin to what is later seen with 370/xa, I also drop
microcode queued interface for multiprocessing dispatching). Endicott
also sucks me into do a lot of work on the microcode enhancements for
138/148. Endicott then complains tht the 5-way 370/125 SMP has better
performance and better price/performance than 370/148 and I'm required
in escalation meetings to argue both sides. Endicott wins ... and the
5-way SMP 370/125 is never announced.

In the late 70s, there was an effort to replace the myriad of different
internal microprocessors with 801/risc (Illiad) ... to simplify the
enormous development & programming environments for each unique
microprocessor ... aka the 4361&4381 followon to 4331&4341, the S/38,
nearly every controller. etc. The followon to the displaywriter was also
going to be 801/risc romp. In any case, all of these efforts floundered
for various reasons.

The channel latency processing of the 370/158 intergrated channels was
much slower than the high end external channels ... characteristic which
is then carried over to the whole 303x family (3031, 3032, 3033). An
example was that even the 4341 integrated channel with minor tweak was
able to handle the 3880/3380 3mbyte/sec speed (and could be used in
bldg14&15 for 3880/3380 testing).

trivia: 138/148 microcode enhancement. Typical 370 (vertical) microcode
simulation ran avg. of ten native instructions for every 370
instruction. I was told that there was 6kbytes worth of available
microcode space ...  and the objective was identify the highest used
6kbytes of supervisor code for dropping into microcode for 10:1
speedup. old post that 6kbytes of kernel highest used pathlength
accounted for 79.55% of kernel processing time (reduced to 8% when
dropped into native microcode, 10:1 speedup)
http://www.garlic.com/~lynn/94.html#21

other trivia: low&mid-range was vertical microcode ... so those 360&370
machines were little like the Hercules simulation (and native MIP rate
was ten times faster than 370 MIP rate). The high-end machines were
horizontal micrcode ... and rather than measured in avg native
instructions to 360/370 instructions ... high-end machines were measured
in avg. machine cycles per 360/370 instructions (in part because of high
level of hardware integration and overlap). Part of the move from
370/165 to 370/168 was replacing the 2mic memory with 400ns memory
(cache miss latency reduced).  The other part was optimizing the
horizontal microcode reducing the avg. machine cycles from 2.1 to 1.6.
3033 started out with moving 168 logic to 20% faster chips ... but they
also further optimized horizontal microcode getting down close to avg of
one machine cycle per 370 instruction.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: ComputerWorld Says: Cobol plays major role in U.S. government breaches

[Michael Seeman]

Some articles posted regarding the 2015 OPM Breach at the Department of the 
Interior Data Center implied that DOI Mainframes were hacked.  This is not the 
case.

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

Re: GREAT presentation on the history of the mainframe

[Pommier, Rex]

The only thing I wish he would have included in the presentation was the 
original 9672/9674 which was a huge shift from the GA-AS technology to silicon.

Rex


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: GREAT presentation on the history of the mainframe

[Steve Thompson]

I had thought that the 3890 check sorter used a S/3 CPU because 
of right-left movement (which those machines did). As I recall, 
with SCI code, one had to think the reverse of what a S/360 did 
in a move. Granted, I didn't do very much 3890 programming, but I 
did a lot of CPCS programming to handle various tasks and so had 
to be familiar with that and know that a 1419 check sorter 
(Read/Write direct thing) was a backup (never used it).


Regards,
Steve Thompson

On 03/24/2017 09:51 AM, Todd Arnold wrote:

303x external channels (channel director) was 158 engine with integrated
channel microcode (and no 370 microcode).


360 processors with special microcode were used in a number of things.  Early 
in my career, I worked on development of the IBM 3890 high-speed check sorter.  
(https://en.wikipedia.org/wiki/IBM_3890)  The controller in that sorter was a 
360 mod 25, with all the code written in native microcode - no 360 instruction 
set.  It turned out to be very fast, and it was many years before IBM was able 
to find anything to replace that old mod 25 with its core memory.

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

Trenton Area Contract/Employment

[Gary Green]

I hope I am not violating forum decorum by posting this.  If so, then I would 
ask that the forum administrators kill it.

I am putting this out there in case anyone within commuting distance of 
Trenton, NJ is interested in a full-time contract that would most likely lead 
to full-time employment.  I am down one person and all z/OS and z/OS related 
software, IBM & third party, falls on my shoulders.  I cannot even go away for 
a long weekend without fear of being called; not that I get called that much, 
but you know what I mean.

Anyways...

The position is for a z/OS generalist.  The candidate must have enough 
experience (minimum 5 years) to know SMP/e, can install a ServerPac, knows some 
storage admin, the usual TSO, ISPF, JCL, VSAM, IDCAMS, HFS/ZFS, etc...  Also 
must be willing, and able, to go on on-call rotation (lasts one week; although 
I am usually the first person called).  Although the public posting of this 
contract mentions RACF, you do not need to be a RACF ADMIN; just know enough 
about the product to assist when/if necessary.

The position is for the NJ Judiciary, i.e. the court system, however, the 
contract was let out to a firm in Ann Arbor, Michigan, called, ACRO Corp: 
https://www.acrocorp.com.  The contract contact is Tracy Koval ; 
tko...@acrocorp.com. If you go directly through ACRO, your billing rate could 
be more than going through the plethora of agencies out their beating the 
ground for any warm body that can spell zos (deliberate misspelling on my 
part).  The contract was initially put out for a duration of six months.  It 
could be extended or ...

At the end of the contract, if we like the candidate and the candidate likes 
us, we will probably make an offer for fulltime employment.  This position 
reports directly to me; although there is a "hiring committee".  All candidates 
will be asked the exact same interview questions (we are a government agency 
and our selection process must be completely above reproach :( ... ).  During 
the “tell us about yourself” phase is when you get the chance to shine and show 
us your experience and knowledge.

Important … please note…  Anyone that works for any NJ state agency must, Must, 
MUST … be a resident of NJ within one year of starting said employment; how I 
wish this were not so.  And I must also note that we will not offer any form of 
moving assistance.   Oh, another thing…  Salaries for fulltime employees are 
fixed within a range.  When someone is hired, the start of the “range” is what 
can be offered; but I can push for a few percentage points over that.  Although 
starting salaries are a bit low by corporate world standards, raises are 
automatic each year until one’s salary reaches the maximum.

Although my contact particulars are below, please DO NOT CALL me.  Although I 
prefer questions, and their subsequent answers, to be posted publically for all 
to see, you may email me for clarification, that's it.  And do not expect an 
immediate response. I am so busy that email is the last thing I pay attention 
to.

Thanks for listening and enjoy your weekend.

Gary Green
Supervisor – Large Systems and Mainframe Networks
New Jersey Judiciary
Richard J. Hughes Justice Complex
25 Market Street
Trenton, New Jersey
08625
609-815-2900, x-32770  –  Office
Please note my new email address:
  gary.gr...@njcourts.gov

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

Re: thoughts on z/OS ftp server enhancement.

[John McKown]

On Fri, Mar 24, 2017 at 11:13 AM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> There is a true ETL tool component, PowerExchange by Informatica that
> allows the actual ETL Tool (PowerCenter) to read IMS and VSAM files as if
> they were relational tables.  In general I would recommend this, but I
> don't have a sense of the "permanence" of the process you are concerned
> about.  So I don't know that you'd want to invest in such a product for a
> short term need.
>
>
> Anyway, you basically feed in a COBOL copybook that describes your file
> (or IMS database).  PowerExchange then generates one or more table
> structures that can be queried by PowerCenter.  PowerCenter would use these
> queries to actually load the data in to a true relational database.
>

​We have that product. And, once again, I am at a lose because the people
who used it on the PC side are gone and nobody knows/wants to learn how to
use it. But I'll present it again as a possibility. We have a lot of
attitude of "that is mainframe. Don't expect me to help you. Oh, and give
me this data in a form that I can use directly, right now."​



>
>
> Or something like that.  I've only worked on the PowerExchange side, not
> the PowerCenter side.
>
>
> There is a PowerExchange STC that runs on z/OS and deals with both the
> data mapping and data transmission.  No FTP involved.
>
>
> Probably there are other similar tools, but this is the only one I am
> personally aware of.
>
>
> Frank
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: thoughts on z/OS ftp server enhancement.

[Frank Swarbrick]

There is a true ETL tool component, PowerExchange by Informatica that allows 
the actual ETL Tool (PowerCenter) to read IMS and VSAM files as if they were 
relational tables.  In general I would recommend this, but I don't have a sense 
of the "permanence" of the process you are concerned about.  So I don't know 
that you'd want to invest in such a product for a short term need.


Anyway, you basically feed in a COBOL copybook that describes your file (or IMS 
database).  PowerExchange then generates one or more table structures that can 
be queried by PowerCenter.  PowerCenter would use these queries to actually 
load the data in to a true relational database.


Or something like that.  I've only worked on the PowerExchange side, not the 
PowerCenter side.


There is a PowerExchange STC that runs on z/OS and deals with both the data 
mapping and data transmission.  No FTP involved.


Probably there are other similar tools, but this is the only one I am 
personally aware of.


Frank


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, March 24, 2017 7:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: thoughts on z/OS ftp server enhancement.

On Fri, Mar 24, 2017 at 6:41 AM, Steve Smith  wrote:

> I am over my self-imposed daily limit on IBM-MAIN replies and it's not even
> 08:00 yet.  However, I see no reason to "enhance" ftp.  In fact, I think
> the capability to convert to/from ASCII is misguided (as it's used by
> mistake as often as on purpose - see above).
>
> Do whatever it takes to create the actual data set you want to transmit,
> *then* invoke ftp to transmit it.
>

As the OP for this thread, I would generally concur with the above. The
problem, at present, is that the files of which I am speaking are multi-GiB
data sets and finding more DASD space can be problematic. We can't get more
DASD basically because we are doing the ftp's to move data off of z/OS in
order to "get off the obsolete mainframe and on to current cloud based
systems" (managements' words, not mine). We could do BINARY ftps, but that
would require more money to write a Windows program to read the data in
"mainframe" format and write it out in "Windows" format. We do have
Microfocus COBOL. Interestingly(?), it can read the "mainframe encoded"
data (EBCDIC, z series integers & packed decimal) just fine. Unfortunately,
unless I'm missing something, there is not any option to read in "mainframe
encoded" mode but write out in "Windows encoded" mode. Of course, being a
despised mainframe sysprog, I'm not allowed access to the PC environment
where all this is going on.



>
> --
> sas
>
>

--
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

--
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: Easiest way to share incore data between batch jobs

[Victor Gil]

I'd like to thank everyone responded to this quest. Very educational!

It looks like the team has decided to cache this file locally, i.e. in each and 
every address space accessing data, so nothing exciting is going to transpire 
this time around.

Ah, well, back to the daily routine...

Thanks again!
-Victor-

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

Re: Easiest way to share incore data between batch jobs

[IronSphere by SecuriTeam Software]

Hi Victor.

Why should it be a problem state program? the idea is a single load, many
reads, isn't it?  after IPL, run a  STC to load the data and create the
name-token pair. later on, all users can access the data. As I wrote in my
original response, there are several product that does that (table base for
example. There are some product that are just the tool to do this (like
matrix that stores your data in a dataspace(s) and even enable writes to
storage from a problem state programs).


ITschak

On Thu, Mar 23, 2017 at 8:22 PM, Victor Gil 
wrote:

> ITschak,
>
> Really like this idea, could you please elaborate a bit - how would a
> problem-state program load data in common area? It needs to be
> store-protected to prevent overlays, so that would require the loader to be
> APF authorization, no?
>
> -Victor-
>
> --
> If your interest is sharing, CICS can store a complete vsam file in
> dataspace using a standard IO routines (GET, PUT, POINT etc.). It is few
> CICS parameters away and involves no code change. I am not sure that EXCI
> will save you CPU or elapse. BTW, there are few products that store data in
> storage and/or dataspaces (Matrix from Expanse comes to mind).
> Another alternative is to store the dataset in a common area (nay be above
> the bar), and store the start and end addresses in single name-token pair.
> you just need a loaded program and a search one. this fits for a none
> updated file.
>
> HTH
> ITschak
>
> --
> 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* *|** An IT GRC for Legacy systems* *| Automated
Security Readiness Reviews (SRR) **|*

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

Re: thoughts on z/OS ftp server enhancement.

[John McKown]

On Fri, Mar 24, 2017 at 8:42 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 24 Mar 2017 08:08:33 -0500, John McKown wrote:
> >>
> >> Do whatever it takes to create the actual data set you want to transmit,
> >> *then* invoke ftp to transmit it.
> >>
> THis may depend on the denizens' of the target system having the
> privilege and skill to do this.
>
> >​... We do have
> >Microfocus COBOL. Interestingly(?), it can read the "mainframe encoded"
> >data (EBCDIC, z series integers & packed decimal) just fine.
> Unfortunately,
> >unless I'm missing something, there is not any option to read in
> "mainframe
> >encoded" mode but write out in "Windows encoded" mode. ...
> >
> So leave the data in "mainframe encoded" mode perpetually and rely on the
> abilities of Microfocus COBOL to process it?
> ???
>

​Except that they want to use other languages as well. I am now wondering
if, while in "mainframe encoded" mode, ​the COBOL program could properly
talk to an MS SQL Server (company standard) to store the data, instead of
in a regular PC file.


>
> ​
>


> ​
>
> -- gil
>
>
-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: GREAT presentation on the history of the mainframe

[Todd Arnold]

> 303x external channels (channel director) was 158 engine with integrated
> channel microcode (and no 370 microcode).

360 processors with special microcode were used in a number of things.  Early 
in my career, I worked on development of the IBM 3890 high-speed check sorter.  
(https://en.wikipedia.org/wiki/IBM_3890)  The controller in that sorter was a 
360 mod 25, with all the code written in native microcode - no 360 instruction 
set.  It turned out to be very fast, and it was many years before IBM was able 
to find anything to replace that old mod 25 with its core memory.

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

Re: thoughts on z/OS ftp server enhancement.

[Paul Gilmartin]

On Fri, 24 Mar 2017 08:08:33 -0500, John McKown wrote:
>>
>> Do whatever it takes to create the actual data set you want to transmit,
>> *then* invoke ftp to transmit it.
>>
THis may depend on the denizens' of the target system having the
privilege and skill to do this.

>​... We do have
>Microfocus COBOL. Interestingly(?), it can read the "mainframe encoded"
>data (EBCDIC, z series integers & packed decimal) just fine. Unfortunately,
>unless I'm missing something, there is not any option to read in "mainframe
>encoded" mode but write out in "Windows encoded" mode. ...
>
So leave the data in "mainframe encoded" mode perpetually and rely on the
abilities of Microfocus COBOL to process it?
???

I'll stray off-charter and draw a parallel with events today in Washington D.C.
A group driven by ideology is working under pressure of a deadline to reach a
goal with no practical plan to get there.

-- gil

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

Re: thoughts on z/OS ftp server enhancement.

[Elardus Engelbrecht]

John McKown wrote:

>Steve Smith wrote:

>> Do whatever it takes to create the actual data set you want to transmit, 
>> *then* invoke ftp to transmit it.
>​As the OP for this thread, I would generally concur with the above. 

I stayed out of this thread to see what others said. I agree 100% with Steve! 

I think, write something to massage that dataset to produce a shortened CSV 
file with the changed/expanded numbers. Just select your fields and move them 
via FTP to save on DASD space. It should be easy with DFSORT / ICETOOL, of 
course YMMV. 

Just be sure in what format are those numbers. That alone is a nasty trap with 
'funny' results...


>... but that would require more money to write a Windows program to read the 
>data in "mainframe" format and write it out in "Windows" format. 

I will not [rather] do that approach, simply for type of 'endian' (spelling?), 
encoding scheme and format of your fields which may be varied between records 
as well as format and size in bytes of those numbers.

Groete / Greetings
Elardus Engelbrecht

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

Re: thoughts on z/OS ftp server enhancement.

[John McKown]

On Fri, Mar 24, 2017 at 6:41 AM, Steve Smith  wrote:

> I am over my self-imposed daily limit on IBM-MAIN replies and it's not even
> 08:00 yet.  However, I see no reason to "enhance" ftp.  In fact, I think
> the capability to convert to/from ASCII is misguided (as it's used by
> mistake as often as on purpose - see above).
>
> Do whatever it takes to create the actual data set you want to transmit,
> *then* invoke ftp to transmit it.
>

​As the OP for this thread, I would generally concur with the above. The
problem, at present, is that the files of which I am speaking are multi-GiB
data sets and finding more DASD space can be problematic. We can't get more
DASD basically because we are doing the ftp's to move data off of z/OS in
order to "get off the obsolete mainframe and on to current cloud based
systems" (managements' words, not mine).​ We could do BINARY ftps, but that
would require more money to write a Windows program to read the data in
"mainframe" format and write it out in "Windows" format. We do have
Microfocus COBOL. Interestingly(?), it can read the "mainframe encoded"
data (EBCDIC, z series integers & packed decimal) just fine. Unfortunately,
unless I'm missing something, there is not any option to read in "mainframe
encoded" mode but write out in "Windows encoded" mode. Of course, being a
despised mainframe sysprog, I'm not allowed access to the PC environment
where all this is going on.



>
> --
> sas
>
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: SAS user abend code documentation?

[Elardus Engelbrecht]

Steve Smith  wrote:

>Don Poitras  wrote:

>>  'after sunset' is a new one on me. With the days getting shorter, your 
>> batch window is closing fast.
>> :) (Sorry, couldn't resist.)

Haha. That is a 'sunset' joke. Sorry and sorry... ;-)


>> Only in the southern hemisphere.  It's springtime on the top side.

Indeed. Luckily we don't have any 'daylight saving' thing you have.


>I guess I should point out that I share my initials with the well-known 
>software company, but we have no relationship to speak of.

I see 'SAS' in at least three places, your initials, both you and Don's e-mail 
addresses containin 'sas' and then there is that statistical company and its 
products language.

I rather see SAS as 'Special Air Services' or 'South African Ship'. ;-)

I think it was once said to Scotty in a Star Trek episode: 'Seach Again, 
Scotty'...

Look in this webpage for different meaning of 'SAS': 
https://en.wikipedia.org/wiki/SAS

Groete / Greetings
Elardus Engelbrecht

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

Re: thoughts on z/OS ftp server enhancement.

[Steve Smith]

I am over my self-imposed daily limit on IBM-MAIN replies and it's not even
08:00 yet.  However, I see no reason to "enhance" ftp.  In fact, I think
the capability to convert to/from ASCII is misguided (as it's used by
mistake as often as on purpose - see above).

Do whatever it takes to create the actual data set you want to transmit,
*then* invoke ftp to transmit it.

-- 
sas

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

Re: Easiest way to share incore data between batch jobs

[Steve Smith]

I'll second Lizette's suggestion for RLS.  It should do exactly what you
want with far less change and trouble.


On Thu, Mar 23, 2017 at 2:25 PM, Victor Gil 
wrote:

> Thanks Denis, an interesting approach!
>
> Will have to do some reading as this is my "terra incognita"...
>
> -Victor-
>
>
-- 
sas

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

Re: SAS user abend code documentation?

[Steve Smith]

On Thu, Mar 23, 2017 at 10:06 AM, Don Poitras  wrote:

> In article <7157494272622550.wa.nitzibmgmx@listserv.ua.edu> you wrote:
>  'after sunset' is a new one on
> me. With the days getting shorter, your batch window is closing fast.
> :) (Sorry, couldn't resist.)
>
> Only in the southern hemisphere.  It's springtime on the top side.
I guess I should point out that I share my initials with the well-known
software company, but we have no relationship to speak of.

-- 
sas

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

Destination Z Winners

[Edward Gould]

The IBM Destination z community is pleased to announce the winners of the 
annual IBM Destination z Enterprise Computing Scholarship for 2016. To be 
considered for this scholarship, students must have demonstrated excellence in 
their enterprise computing coursework, with plans for continued growth on the 
mainframe platform in their academic and professional careers and attend a 
post-secondary school in the U.S. that’s both a member of the IBM Academic 
Initiative and Destination z.
 
The winners of the 2016 scholarship, chosen by a panel of representatives in 
the mainframe community, are:

Jeremy Delossantos, West Texas A&M University
Derek Garrity, Northern Illinois University
Ari Kenney, University of California, Berkeley
James O’Brien, Marist College
Shikandar Hoque, Touro College
Keep an eye out in our academic section 

 for a feature soon on 2016 winner Jeremy Delossantos.
 
Congratulations to all of these scholarship winners, and best wishes for their 
continued academic success. The scholarship is made possible by the Destination 
z sponsors: IBM, INNOVATION Data Processing, Rocket Software and Vicom Infinity.
 
The Destination z community looks forward to continuing to encourage the next 
generation of enterprise systems professionals. If you’d like to become 
involved in the Destination z Enterprise Computing Scholarship as a sponsor, 
please email Troy Crutcher  or learn more here 
.
 A list of member schools is available here 
.
 Schools can register by filling out a form on ibm.com 
.
 


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

Question on RMF Storage report

[Duc Tuan Nguyen]

Dear listers, 

I am a DB2 sysprog and our DB2 statistics report shows a high number of "Pagein 
for read I/O" (+5000/ minute) , just a single peak and nearly nothing around 
the interval , so maybe not accurate.

I am trying to correlate this with RMF data (The DB2 i am looking on is DB2I) . 
On this report PAGEIN RATE is 4 for DB2IDBM1. Not a big number , right ?

But on the next RMF report , at the same period (05:25) . There 32% of frames 
available but the UIC is "only" 37686 ??

Can you please explain me a bit on these figures ? 

Thank you for your answers. 





, RMF V2R1   Storage Frames, Line 1
Command ===>,,Scroll ==

Samples: 50  System:,SUDB, Date:,03/21/17, Time:,05.25.00, Range:,1

   Service-- Frame Occup.-- - Active Frames - AUX   PGIN
Jobname  C Class   Cr TOTAL  ACTV  IDLE  WSET FIXED   DIV SLOTS RATE

DB2VDBM1 S SSTCHI  822K  822K 0  822K  4748  5416  641K0
DB2IDBM1 S SSTCHI  490K  490K 0  490K  3676  5580  631K4
*MASTER* S SYSTEM 54393 54393 0 54393  4624 0  23080
CICSIARD S SSERVHI48175 48175 0 48175   422 0 00
CICSPRED S SSERVHI35661 35661 0 35661   388 0 00
ZFS  S SYSSTC 34737 34737 0 34737   898 0 903690
MKP7MSTR S SSTCHI 34431 34431 0 34431  1790 0 479520
WLM  S SYSTEM 33269 33269 0 33269   293 0   8310
GRS  S SYSTEM 30087 30087 0 30087   498 0 101550
IXGLOGR  S SYSTEM 24691 24691 0 24691   829 0  60250
RMF  S SYSSTC 23122 23122 0 23122   211 0 300380
CICSIARF S SSERVHI16483 16483 0 16483   233 0 00
XCFASS SYSTEM 12525 12525 0 12525  4659 0  14490



  , RMF V2R1   Storage Resource Delays ,   Line 1 of 5,
Command ===>,,Scroll ===>,CSR ,

Samples: 100 System:,SUDB, Date:,03/21/17, Time:,05.25.00, Range:,200  ,Sec
  ,
--- Central Storage Summary ---
--- % Frames Frames  System
NUC  SQA  CSA  LPA  ACTV  IDLE  AVAIL SHROnline   UIC
  000059 1 32   5   3145728   37686

 Page/Swap Activity ---
Volume DEV  CU   ACT CON DSC PND PendSPACE  - AVG Active Users-
Serial Type Type PAV  %   %   %   %  Reasons TYPE   TOTL LOCL SWAP COMM
  ,
SPBP01 3390A2107 1.0H  0   0   0   0 NoneCOMM0.0  0.0  0.0  0.0
 PLPA0.0  0.0  0.0  0.0
SPBP50 3390A2107 1.0H  0   0   0   0 NoneLOCL0.0  0.0  0.0  0.0
SPBP51 3390A2107 1.0H  0   0   0   0 NoneLOCL0.0  0.0  0.0  0.0
SPBP52 3390A2107 1.0H  0   0   0   0 NoneLOCL0.0  0.0  0.0  0.0

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