Re: Does SOF exist anywhere

[Brian Westerman]

Marketing alert:

We (Syzygy Incorporated) have an automation suite which has the parts you need, 
it's about 1/10th (or less) the cost of Netview and other auto operator 
facilities from other vendors and about 10 times easier to use.  We have over 
300 customers and there is even a discount for IBM-MAIN participants of up to 
50% of the listed price.  Also the more "parts" of the entire facility you 
purchase, the more of a percentage is knocked off the pricing.  None of our 
pricing is based on the size of your processor, it's a one price thing no 
matter how big (or small) your system is.  Our thinking is that it's the same 
code, why should it cost more just because you are going to execute it faster?

It processes scripts just like you need, and has a command subset of hundreds 
of options which are likely a whole lot more than you will ever need, to allow 
you to do anything you can as an operator (except maybe change printer paper :) 
).

The web site is www.SyzygyInc.com.  The product you need is SyzCMD/z, but there 
are others there as well.  In fact, we have the only product (it's patented) 
that allows you to send an email or text message of your job execution 
condition codes and steps and programs, etc. (including the output if you 
want), without changing any JCL or adding SMF exits, etc.  That's SyzMPF/z and 
SyzMAIL/z.  

There is VERY little overhead to using any or all of the products in the suite. 
 I would say the overhead is not measurable, but that would not be exactly true.

You can contact me directly if you want, but you can also fill out the contact 
form on the web site.

Brian Westerman

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

Re: Sharing data sets VSAM VB

[Joel C. Ewing]

SHR was primarily designed to allow a max of one writer and any number
of readers.   When you allow multiple writers, then there is no longer
an obvious definition of what is the desired/intended "correct" result
when two different processes want to update the same part of that data
set, so typically some solution unique to each application would have to
be implemented rather than a generic solution.

Depending on your other constraints, it might be simplest for all the
jobs to use their own unique data set and then use a sort/merge step to
combine the records in the desired order, if they must all be in a
single dataset -- or if the order is not significant, just concatenate
all the separate data sets together under a single DD to read as if they
were a single sequential data set for what ever application needs to
read the combined data.

Or if you have a job scheduler and these are production jobs that aren't
required to run concurrently but just have problems if that happens by
accident, most job schedulers have ways to inhibit conflicting jobs from
running in parallel, like defining a single resource required by each of
the conflicting jobs and which must be free before each job is
submitted.  That way you avoid having jobs tie up initiators waiting on
availability of a data set.

I'm sure there are other possibilities, depending on your constraints.
    Joel C Ewing

On 2/24/21 12:57 PM, Joseph Reichman wrote:
> You are correct in your assumption of what I am trying to do so what is the 
> point of share options
>
>
>
>> On Feb 24, 2021, at 12:55 PM, Joel C. Ewing  wrote:
>>
>> But if you are talking about having multiple jobs having the file open
>> for writing concurrently, pretty sure you are talking about either using
>> VSAM RLS or observing some fairly stringent rules that requires the
>> programs involved to manage file record integrity on their own and to
>> use a SHR option that allows multiple concurrent opens for write and
>> constantly refreshes buffers for each record processed.   It's not just
>> a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
>> multiple concurrent OPENs for write on a VSAM with the usual default SHR
>> options, only the 1st concurrent open for write will succeed.
>>
>> If the object is to be able to write randomly interspersed records from
>> multiple jobs running concurrently, another possibility that might be
>> explored is to use a UNIX file and have all the jobs append output to
>> the same unix "log" file.
>>
>> z/OS assumes you want file integrity and deterministic behavior and
>> enforces that on MVS data sets.
>> The Unix world assumes you want what you "ask" for and if you ask for
>> multiple processes to write to the same file concurrently in ways that
>> are non-deterministic, it assumes random ordering from concurrent writes
>> is acceptable.
>>
>> Joel C Ewing
>>
>>> On 2/24/21 11:11 AM, Massimo Biancucci wrote:
>>> Joseph,
>>>
>>> for sure.
>>>
>>> VSAM variable length is OK.
>>>
>>> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>>>
>>> Best regards.
>>> Max
>>>
>>> 
>>> Mail
>>> priva di virus. www.avast.com
>>> 
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>>> reichman...@gmail.com> ha scritto:
>>>
 Hi

 I have multiple jobs sharing the same the same output dataset

 It’s RECFM=VB

 Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
 can write to the same dataset
 Thanks

 ...

 -- 
 Joel C. Ewing

...

-- 
Joel C. Ewing

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

Re: NO MAIL

[seungcheol lee]

 There we go!Thanks Mark. 
On Wednesday, February 24, 2021, 07:03:57 PM CST, Mark Charles 
 wrote:  
 
 What you need to do is send an email to lists...@listserv.ua.edu with the 
following in the body of the message:

SET IBM-MAIN NOMAIL


This  will prevent  LISTSERV from  sending  you email  directly from  the
IBM-MAIN  discussion list  while still  allowing  you to  post from  your
subscribed email address.

--
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: Colours on screen (mainframe history question)

[Seymour J Metz]

No, the 2260 did not use mercury delay lines; in fact, I don't know of anything 
that used them after the early 1950s. The delay lines on the 2848 used 
magnetostriction.

The 2265 was remote.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, February 24, 2021 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

First interactive system I ever wrote was for the 2260. Supported 80 terminals 
on a 360/50. People thought that was pretty astounding. (This was before CICS.) 
Control unit was the 2848. Used mercury delay lines for CRT memory. They were 
heated. On a Power On it took something like 20 minutes for them to come up to 
temperature. (Marvelous engineering decision -- a heated control unit in an 
air-conditioned datacenter.)

They were mux channel attached; there was no "remote" 2260 IIRC. The client 
needed remote terminals. We found some third-party 2260 clone that supported 
bisync attachment. They supported color (because they used more or less 
off-the-shelf TV's for monitors). IIRC the color was "automatic" (protected 
fields in blue, unprotected fields in white, or whatever). Or there was some 
sort of special sequence that customized the display colors. (That is the 
relevance to this thread; would have been around 1972 or 1973.)

The 2250 was a BEAST! Graphics. Light pen. A separate function key keypad. You 
could put typewritten labels in the function keys, and light up the allowed 
keys under program control. Had an 1130 computer under the hood as its 
controller. (No wonder it cost $$$.) The very first 360 application I ever saw 
was a 2250-driving system written in PL/I for one of the big pharmas -- trying 
to remember who. It was written by John Gilmore and Associates. (Yes, our very 
own IBMMAIN John Gilmore.) The idea was you could simulate the flow of a drug 
through the body, complete with a graphical representation. I don't believe it 
ever exactly worked. This would have been in 1969.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Attila Fogarasi
Sent: Wednesday, February 24, 2021 2:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

The 3279 used tri-plane symbols for extended colour (turquoise, pink,
yellow and white, plus blank for all 3 primary colours off).  This had the
neat trick of allowing easy reverse video highlighting (invert the primary
colour bits).  GDDM was the software exploitation of 3279, which also
introduced program symbols.  Most programs used 10% of the 3279s rather
complex capabilities (a situation not helped by only 2 of the 3279 models
having the full capability set).  Great case study on how to design great
hardware badly, or rather so that it is not used.

Note that the 2260 (3270 predecessor that used a keypunch mechanical
keyboard) and 2250 (million dollar vector graphics terminal) were released
circa 1965.  So the 3279 is 15 years later.

On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
wrote:

> The interesting question to me is "which colours"?
>
> I would say we started with a 3-bit colour space: R, G, B. And so the
> colour Red is 100 in this space and a more complex colour like Yellow is
> probably 110.
>
> Is this right, though?
>
> In particular I'd be surprised if a 4th bit weren't used. But for what?
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: 
> https://secure-web.cisco.com/1YGPosKZiFUgfxnOBL9vrrVAjRWHCHHO7z9uX-M738wu-ev3aFiqCANnBaIBhZHcmfUwhVDAY8QNWhCMT27G1gfioQM2n6fXggnXsuDkAukM1rmPaG8lj0pNlPi0oSApsRK8OEpEw0Jbh4zl_9Spu_z_L7j03Damb8lo_Mk2Mgpkz-1eLNoCoRVjD3vD5X5H-dDm5rWJ_sUPLtbiLaFwmS6NVvNCN4Vua-LfpzSLYJajU1VTJd7K7ua9Su010mLA_ZYa8kv6Oi1nJ20BuGpKS-NJVGDOza-tGEBPL8w8DLczm3PySk6d2jg74zSzv8NIXUdNMwdMWkW41N7lA0e735MzAKnP_Bt_fbs7bamHqOpW9ic3ifbo1Yy_PghmylbaMzJAuC2gtEa1hBjqcH-8D-XSGLW9kZm1cnmivFXVa0HvnSzkZOwcX7wNkeHTC1obl/https%3A%2F%2Fmainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://secure-web.cisco.com/1GJYrwVMB_qhc97VD8hZc5neN28hgVWolmLNJgEKyDU6Msi8U7y4XgLsDUK-1fIeTIVxGV2fmNDRTNlhuV97Grgz2E3HdEaNZBhR3VbT6n3RrToXqW1p8VWq4cJH_5ph8uj8HhZ1wSwDwh1AxamwAA78w7dMFOAuhV7r-avHrJaw2y_7wkz2cguHFnR_mizEMMASR6SuK1uGbHbJMoNTbxaWNvIaVLqu9IT0SdF98159z-IolurlMLAPXS3Cnp9RMNUabVMOI_scgA9bxv0Np_pubnbfYDp4zUJBtBsAGY_wsxxGVqLHIpcklXN7ggAWaSiKnYdOCRYue2ypq-Xbm_6Qo3-XhSgckZhGyr_XlbgwjdUkwfCVK9dIxfTWP5omZ4V9zfEOiLAWEpPiXoEO5PUM3AvznOwKvTgQMwl-hnMr8itR2ZExrQSezhywoCMPYgr5jmL-0lG0mAcVfp840YA/https%3A%2F%2Fanchor.fm%2Fmarna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>

Re: Does SOF exist anywhere

[Seymour J Metz]

Does TSSO work on z/OS 2.4? The price is right.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Colin Paice [colinpai...@gmail.com]
Sent: Wednesday, February 24, 2021 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Does SOF exist anywhere

I used to use an IBM product SOF (Software Operator Facility).  This
allowed you to have a set of operator commands in a file, and execute them
such as F SOF,/MQSTART.   You could pass parameters to it, and include
waits etc.

Does this still exist, or is there a good alternative without having to go
to a Netview type facility


Colin

--
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: Colours on screen (mainframe history question)

[Seymour J Metz]

The only valid planes for multi-plane characters are 001, 010 and 100; the only 
color attributes for SFE and SA are 3-bit.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Edward Finnell [000248cce9f3-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, February 24, 2021 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

Extended Attribute

In particular I'd be surprised if a 4th bit weren't used. But for what?




-Original Message-
From: Martin Packer 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, Feb 24, 2021 2:54 am
Subject: Re: Colours on screen (mainframe history question)

The interesting question to me is "which colours"?

I would say we started with a 3-bit colour space: R, G, B. And so the
colour Red is 100 in this space and a more complex colour like Yellow is
probably 110.

Is this right, though?

In particular I'd be surprised if a 4th bit weren't used. But for what?

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: 
https://secure-web.cisco.com/1I6OPsUVTCFCLgNe1XqmaN_H2QL5ut909RvAFKY5N-wOzyItWT2eRC0Wgi3r8l_AerOytwrxq1JKa8IJjWhmTNkaAuQ8fCeOAEJ0Sl9t34VTr9MAmHMUMRVDFr_lul3goVLfHttaoV_mNam7_7eDeYw4NTpiG_IHLIR_4-JzfoNrD6aJazQuNm27j1DnGxe8nuF7kDtZDQhKvTbez1v7qjCs3e70_aHkdmCmK4OdHpllh1Q8cySH61rqwwP3lBwa5TkLoMuvjiyf780IvJ1P1tp4uHJQpFqt0H0B9K7JXTA810nTee5HOkIsuU6U8J-NK3iLRecL9Jo8NZS26pM8vGy8USuNpRnnJK1-NLIPKyUT0hSXqX_rzxeD7SXZ34Q6xQaNiO9qduYIg6IaLz-ZHJWqKZ45QmauVxVdvOrz2JpB9x-xSz8XFpSj5CV4Scxki/https%3A%2F%2Fmainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle):
https://secure-web.cisco.com/19jnDAyTFo_m5zMXsY-r8tFZmCyHR3V4Qpzs_VpOjtb27SMpSQFdQiuZNSkjtEoa32I3v1KbDGoL7zaDe2G7x8hkYm-nM1MSaRLsM7jLOkXyzhSzZ9IdRHmtfWOEp-pgQseDYufnjcLfCfkbh1hJFYiLVmf1-q5zQAP1f9Rcf3qz2o0khsE_PqmFNi22LZz4FTKB16c35nRA5QoowRTcBdSprBJXSCP2sPUEIq5i9m3PcnmbUDXR95M0lIhX936IPwezJi5wbA6LS9qEyCSF1Xi_xKi2RZOhyF1sDdrUiSAGo8TENgTOM29reeDbN8wUrn4TgQNOPffjsznkyIguZYRpO3Qhpf-jmj8GnhFn6Sfl4-fzTIp0ewnDoomqZyRE3NdB_d_eJlC3cJcjqsgobLhBtsuOFIC8N1NqwWdGT3SqmyUdZ1bEfP2z5OpJ6a8kIGktj38biHaYlvzC3PN4-vg/https%3A%2F%2Fanchor.fm%2Fmarna-walle

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



From:  Tony Harminc 
To:IBM-MAIN@LISTSERV.UA.EDU
Date:  24/02/2021 01:00
Subject:[EXTERNAL] Re: Colours on screen (mainframe history
question)
Sent by:IBM Mainframe Discussion List 



On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:

> IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
recall when GDDM picked up color support.

Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
And almost certainly GDDM was under development in parallel with the
3279 hardware; IBM rarely comes out with hardware on a whim that has
no software to support it. One must also remember that the 3279 was
merely the first implementation of an architectural shift in the 3270
series.

Tony H.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: NO MAIL

[Mark Charles]

What you need to do is send an email to lists...@listserv.ua.edu with the 
following in the body of the message:

SET IBM-MAIN NOMAIL


This  will prevent  LISTSERV from  sending  you email  directly from  the
IBM-MAIN  discussion list  while still  allowing  you to  post from  your
subscribed email address.

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

Re: NO MAIL

[Gibney, Dave]

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

This link/information is at the bottom of each and every post from IBM-MAIN

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
seungcheol lee
Sent: Wednesday, February 24, 2021 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NO MAIL

 Sorry for the mis-communication.What I meant is that just directly request NO 
MAIL to the authorized from this Listserv not to send the all posts to this 
individual email. But with those replies from you guys I was abit confused as 
well. In my case, just like to go into the web/Listserv portal and search all 
post instead of email box being flooded.
Again, is there no way let them stop sending posts to individual email? 
Thanks ^^, SteveOn Wednesday, February 24, 2021, 06:31:05 PM CST, Gibney, 
Dave  wrote:  
 
 And, of course, I have no authority for accomplish his request. If the link 
provided is not working for him, I suggest a filter in his mail client

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Tom Brennan
> Sent: Wednesday, February 24, 2021 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: NO MAIL
> 
> Fun!  I think this would be a reason for the email address spoofing we 
> talked about recently :)
> 
> On 2/24/2021 4:07 PM, seungcheol lee wrote:
> >  Hey Dave,
> > If you don't mind please just set up NO MAIL for me over there?
> > Thanks,Steve
> >      On Wednesday, February 24, 2021, 04:27:08 PM CST, Gibney, Dave
>  wrote:
> >
> >  Should be three instances of the instructions at bottom of this 
> >reply. One
> for each iteration
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On 
> >> Behalf Of seungcheol lee
> >> Sent: Wednesday, February 24, 2021 1:19 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: NO MAIL
> >>
> >>    Sorry if I miss it. If you don't mind, please let me know the 
> >>Instruction.
> >> Thanks, Steve
> >>      On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul 
> >>Gilmartin  <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >>    On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
> >>> --
> >>> 
> >>>
> >> Just Read The Instructions.
> >>
> >> -- gil
> >>
> >> ---
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions, 
> >> send email to lists...@listserv.ua.edu with the message: INFO 
> >> IBM-MAIN
> >>
> >>
> >> ---
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions, 
> >> send email to lists...@listserv.ua.edu with the message: INFO 
> >> IBM-MAIN
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

Re: NO MAIL

[seungcheol lee]

 Sorry for the mis-communication.What I meant is that just directly request NO 
MAIL to the authorized from this Listserv not to send the all posts to this 
individual email. But with those replies from you guys I was abit confused as 
well. 
In my case, just like to go into the web/Listserv portal and search all post 
instead of email box being flooded.
Again, is there no way let them stop sending posts to individual email? 
Thanks ^^, SteveOn Wednesday, February 24, 2021, 06:31:05 PM CST, Gibney, 
Dave  wrote:  
 
 And, of course, I have no authority for accomplish his request. If the link 
provided is not working for him, I suggest a filter in his mail client

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Wednesday, February 24, 2021 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: NO MAIL
> 
> Fun!  I think this would be a reason for the email address spoofing we
> talked about recently :)
> 
> On 2/24/2021 4:07 PM, seungcheol lee wrote:
> >  Hey Dave,
> > If you don't mind please just set up NO MAIL for me over there?
> > Thanks,Steve
> >      On Wednesday, February 24, 2021, 04:27:08 PM CST, Gibney, Dave
>  wrote:
> >
> >  Should be three instances of the instructions at bottom of this reply. One
> for each iteration
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of seungcheol lee
> >> Sent: Wednesday, February 24, 2021 1:19 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: NO MAIL
> >>
> >>    Sorry if I miss it. If you don't mind, please let me know the 
> >>Instruction.
> >> Thanks, Steve
> >>      On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin
> >> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >>    On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
> >>> --
> >>>
> >> Just Read The Instructions.
> >>
> >> -- gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: NO MAIL

[Gibney, Dave]

And, of course, I have no authority for accomplish his request. If the link 
provided is not working for him, I suggest a filter in his mail client

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Brennan
> Sent: Wednesday, February 24, 2021 4:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: NO MAIL
> 
> Fun!  I think this would be a reason for the email address spoofing we
> talked about recently :)
> 
> On 2/24/2021 4:07 PM, seungcheol lee wrote:
> >   Hey Dave,
> > If you don't mind please just set up NO MAIL for me over there?
> > Thanks,Steve
> >  On Wednesday, February 24, 2021, 04:27:08 PM CST, Gibney, Dave
>  wrote:
> >
> >   Should be three instances of the instructions at bottom of this reply. One
> for each iteration
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of seungcheol lee
> >> Sent: Wednesday, February 24, 2021 1:19 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: NO MAIL
> >>
> >>    Sorry if I miss it. If you don't mind, please let me know the 
> >> Instruction.
> >> Thanks, Steve
> >>      On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin
> >> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >>    On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
> >>> --
> >>>
> >> Just Read The Instructions.
> >>
> >> -- gil
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: NO MAIL

[Tom Brennan]

Fun!  I think this would be a reason for the email address spoofing we 
talked about recently :)


On 2/24/2021 4:07 PM, seungcheol lee wrote:

  Hey Dave,
If you don't mind please just set up NO MAIL for me over there?
Thanks,Steve
 On Wednesday, February 24, 2021, 04:27:08 PM CST, Gibney, Dave 
 wrote:
  
  Should be three instances of the instructions at bottom of this reply. One for each iteration



-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of seungcheol lee
Sent: Wednesday, February 24, 2021 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NO MAIL

   Sorry if I miss it. If you don't mind, please let me know the Instruction.
Thanks, Steve
     On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

   On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:

--


Just Read The Instructions.

-- gil

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


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


--
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: NO MAIL

[seungcheol lee]

 Hey Dave,
If you don't mind please just set up NO MAIL for me over there?   
Thanks,Steve
On Wednesday, February 24, 2021, 04:27:08 PM CST, Gibney, Dave 
 wrote:  
 
 Should be three instances of the instructions at bottom of this reply. One for 
each iteration

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of seungcheol lee
> Sent: Wednesday, February 24, 2021 1:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: NO MAIL
> 
>  Sorry if I miss it. If you don't mind, please let me know the Instruction.
> Thanks, Steve
>    On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>  On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
> >--
> >
> Just Read The Instructions.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: FTP with TLSv1.2 and SHA256

[Frank Swarbrick]

Interesting, as I believe I just resolved my issue, and I think it worked.  My 
issue was my method of specifying environment variables.  I had them specified 
in a single quoted string instead of two separate quoted strings, separated by 
a comma.  The following works (specified in a CEEOPTS DD):

ENVAR('GSK_PROTOCOL_TLSV1_2=1', 'GSK_V3_CIPHER_SPECS=3D35')

This does cause a warning that "specID 3D not recognized", but I think that is 
simply a result of the FTP application trying to find a text representation for 
a cipher that it doesn't know about.  But at the System SSL level it all seems 
to work.

With "DEBUG SEC" specified in my ftp.data I see the following:

FC0334 ftpAuth:  cipherspecs =
FC0379 ftpAuth: environment_open()
FC0543 ftpAuth: environment_init()
FC0552 ftpAuth: environment initialization complete
EZA1701I >>> AUTH TLS
234 AUTH command OK. Initializing SSL connection.
FC1011 authServer: secure_socket_open()
FC1083 HSNOTIFY rc: 0
FC1088 authServer: secure_socket_init()
FU1316 tlsLevel: specID 3D not recognized
FU1325 tlsLevel: using TLSV1.2  (3D)
FC1171 authServer: gsk_attribute_get_cert_info()
FC1216 authServer: decode certificate length = 1575
EZA2895I Authentication negotiation succeeded

Everything seems to work.  I won't be able to validate for 100% that it's using 
a SHA256 MAC until the server is reconfigured to exclude SHA1 again, but I 
think we're good.

Not that we shouldn't convert to AT-TLS at some point.  But right now we just 
want to get this working.

Frank


From: IBM Mainframe Discussion List  on behalf of 
John S. Giltner, Jr. 
Sent: Wednesday, February 24, 2021 3:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP with TLSv1.2 and SHA256

I just went through this and had a PRM with IBM.  FTP will use TLSv1.2 as you 
have found buy using env variables, but you are limited to the cipher specs it 
supports natively.   It will not honor anything you try and code with env 
variables. You will need to use AT-TLS.

--
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: [External] Re: NO MAIL

[Edward Finnell]

The web Interface at listserv.ua.edu/archives/ibm-main.html has options 
interface.

Look at the bottom of this e-mail and you will see the instructions on how to 
get the instructions you're looking for.




-Original Message-
From: Pommier, Rex 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, Feb 24, 2021 3:34 pm
Subject: Re: [External] Re: NO MAIL

Steve,

Look at the bottom of this e-mail and you will see the instructions on how to 
get the instructions you're looking for.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
seungcheol lee
Sent: Wednesday, February 24, 2021 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: NO MAIL

 Sorry if I miss it. If you don't mind, please let me know the Instruction.
Thanks, Steve
    On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
>--
>
Just Read The Instructions.

-- gil

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

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


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

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

Re: FTP with TLSv1.2 and SHA256

[John S. Giltner, Jr.]

I just went through this and had a PRM with IBM.  FTP will use TLSv1.2 as you 
have found buy using env variables, but you are limited to the cipher specs it 
supports natively.   It will not honor anything you try and code with env 
variables. You will need to use AT-TLS.

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

Re: Colours on screen (mainframe history question)

[Edward Finnell]

Extended Attribute

In particular I'd be surprised if a 4th bit weren't used. But for what?




-Original Message-
From: Martin Packer 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, Feb 24, 2021 2:54 am
Subject: Re: Colours on screen (mainframe history question)

The interesting question to me is "which colours"?

I would say we started with a 3-bit colour space: R, G, B. And so the 
colour Red is 100 in this space and a more complex colour like Yellow is 
probably 110.

Is this right, though?

In particular I'd be surprised if a 4th bit weren't used. But for what?

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

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

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



From:  Tony Harminc 
To:    IBM-MAIN@LISTSERV.UA.EDU
Date:  24/02/2021 01:00
Subject:        [EXTERNAL] Re: Colours on screen (mainframe history 
question)
Sent by:        IBM Mainframe Discussion List 



On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:

> IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't 
recall when GDDM picked up color support.

Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
And almost certainly GDDM was under development in parallel with the
3279 hardware; IBM rarely comes out with hardware on a whim that has
no software to support it. One must also remember that the 3279 was
merely the first implementation of an architectural shift in the 3270
series.

Tony H.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: NO MAIL

[Gibney, Dave]

Should be three instances of the instructions at bottom of this reply. One for 
each iteration

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of seungcheol lee
> Sent: Wednesday, February 24, 2021 1:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: NO MAIL
> 
>  Sorry if I miss it. If you don't mind, please let me know the Instruction.
> Thanks, Steve
> On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>  On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
> >--
> >
> Just Read The Instructions.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [External] Re: NO MAIL

[Pommier, Rex]

Steve,

Look at the bottom of this e-mail and you will see the instructions on how to 
get the instructions you're looking for.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
seungcheol lee
Sent: Wednesday, February 24, 2021 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: NO MAIL

 Sorry if I miss it. If you don't mind, please let me know the Instruction.
Thanks, Steve
On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
>--
>
Just Read The Instructions.

-- gil

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

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


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: NO MAIL

[seungcheol lee]

 Sorry if I miss it. If you don't mind, please let me know the Instruction.
Thanks, Steve
On Wednesday, February 24, 2021, 12:47:27 PM CST, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
>--
>
Just Read The Instructions.

-- gil

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

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

If you are thinking: How can IBM’s latest programming languages offer additional value to help you modernize core business applications on z/OS? Join us in our upcoming event to learn more.

[Chandni Dinani]

As you are embracing modern technology in your digital transformation journey, 
you can continue to leverage the trusted and performant environment to run your 
business-critical applications. This session covers a high-level overview of 
how IBM’s latest programming language offerings (example: COBOL, Automatic 
Binary Optimizer, PL/I, C/C++, Java, Node.js, Python and, Go) can help you 
modernize these applications on z/OS to create more value, develop new 
applications to augment digital experiences, and reduce operating costs.

Register here: 
https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp==3023334=1=A3771131FD33318D50F1FA8294FC7ED0®Tag==false=register

Speaker Information: 
Roland Koo
Program Director, Offering Management and Strategy, Enterprise Products and 
Compilers on Z

Roland is responsible for C/C++, PL/I, COBOL and Automatic Binary Optimizer on 
IBM Z. He is based in Toronto, Canada and has been with IBM for 26 years. Prior 
to his current position, Roland was the manager of the Compiler optimization 
team. He has also held a number of leadership positions in the compiler area, 
including product planning, compiler front end development, testing, and 
managing compiler research activities with University partners and IBM research 
at IBM Center for Advanced Studies.

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

Re: Sharing data sets VSAM VB

[Paul Gilmartin]

On Wed, 24 Feb 2021 11:55:18 -0600, Joel C. Ewing wrote:
>...
>use a SHR option that allows multiple concurrent opens for write and
>constantly refreshes buffers for each record processed. ...
>
>If the object is to be able to write randomly interspersed records from
>multiple jobs running concurrently, another possibility that might be
>explored is to use a UNIX file and have all the jobs append output to
>the same unix "log" file.
>
Open the file with O_APPEND (C, REXX SYSCALL, JCL) or ">>" (Shell).
I have experienced poor performance appending to a UNIX file.
IBM support tells me that is a consequence of need to preserve
integrity.

>z/OS assumes you want file integrity and deterministic behavior and
>enforces that on MVS data sets.
>The Unix world assumes you want what you "ask" for and if you ask for
>multiple processes to write to the same file concurrently in ways that
>are non-deterministic, it assumes random ordering from concurrent writes
>is acceptable.
>
The randomness will be less for a single write() operation with a
a datum < kernel buffer size (131072?)

-- gil

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

Re: Sharing data sets VSAM VB

[Joseph Reichman]

You are correct in your assumption of what I am trying to do so what is the 
point of share options



> On Feb 24, 2021, at 12:55 PM, Joel C. Ewing  wrote:
> 
> But if you are talking about having multiple jobs having the file open
> for writing concurrently, pretty sure you are talking about either using
> VSAM RLS or observing some fairly stringent rules that requires the
> programs involved to manage file record integrity on their own and to
> use a SHR option that allows multiple concurrent opens for write and
> constantly refreshes buffers for each record processed.   It's not just
> a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
> multiple concurrent OPENs for write on a VSAM with the usual default SHR
> options, only the 1st concurrent open for write will succeed.
> 
> If the object is to be able to write randomly interspersed records from
> multiple jobs running concurrently, another possibility that might be
> explored is to use a UNIX file and have all the jobs append output to
> the same unix "log" file.
> 
> z/OS assumes you want file integrity and deterministic behavior and
> enforces that on MVS data sets.
> The Unix world assumes you want what you "ask" for and if you ask for
> multiple processes to write to the same file concurrently in ways that
> are non-deterministic, it assumes random ordering from concurrent writes
> is acceptable.
> 
> Joel C Ewing
> 
>> On 2/24/21 11:11 AM, Massimo Biancucci wrote:
>> Joseph,
>> 
>> for sure.
>> 
>> VSAM variable length is OK.
>> 
>> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>> 
>> Best regards.
>> Max
>> 
>> 
>> Mail
>> priva di virus. www.avast.com
>> 
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> 
>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>> reichman...@gmail.com> ha scritto:
>> 
>>> Hi
>>> 
>>> I have multiple jobs sharing the same the same output dataset
>>> 
>>> It’s RECFM=VB
>>> 
>>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>>> can write to the same dataset
>>> Thanks
>>> 
>>> --
>>> 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
> 
> 
> -- 
> Joel C. Ewing
> 
> --
> 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: NO MAIL

[Paul Gilmartin]

On Wed, 24 Feb 2021 18:17:01 +, seungcheol lee wrote:
>--
>
Just Read The Instructions.

-- gil

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

Re: Does SOF exist anywhere

[Wayne Bickerdike]

AUTO from the CBT tape file 332 has a lot of functions you could utilise.
ISFSLASH function can be rolled into some REXX code to issue Console
commands and perform waits. Combine the two and you have the function you
describe.


On Thu, Feb 25, 2021, 04:20 Colin Paice  wrote:

> I used to use an IBM product SOF (Software Operator Facility).  This
> allowed you to have a set of operator commands in a file, and execute them
> such as F SOF,/MQSTART.   You could pass parameters to it, and include
> waits etc.
>
> Does this still exist, or is there a good alternative without having to go
> to a Netview type facility
>
>
> Colin
>
> --
> 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

NO MAIL

[seungcheol lee]

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

Re: Sharing data sets VSAM VB

[Joel C. Ewing]

But if you are talking about having multiple jobs having the file open
for writing concurrently, pretty sure you are talking about either using
VSAM RLS or observing some fairly stringent rules that requires the
programs involved to manage file record integrity on their own and to
use a SHR option that allows multiple concurrent opens for write and
constantly refreshes buffers for each record processed.   It's not just
a matter of substituting a VSAM file for a  RECFM=VB file.   If you try
multiple concurrent OPENs for write on a VSAM with the usual default SHR
options, only the 1st concurrent open for write will succeed.

If the object is to be able to write randomly interspersed records from
multiple jobs running concurrently, another possibility that might be
explored is to use a UNIX file and have all the jobs append output to
the same unix "log" file.

z/OS assumes you want file integrity and deterministic behavior and
enforces that on MVS data sets.
The Unix world assumes you want what you "ask" for and if you ask for
multiple processes to write to the same file concurrently in ways that
are non-deterministic, it assumes random ordering from concurrent writes
is acceptable.

    Joel C Ewing

On 2/24/21 11:11 AM, Massimo Biancucci wrote:
> Joseph,
>
> for sure.
>
> VSAM variable length is OK.
>
> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
>
> Best regards.
> Max
>
> 
> Mail
> priva di virus. www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
> reichman...@gmail.com> ha scritto:
>
>> Hi
>>
>> I have multiple jobs sharing the same the same output dataset
>>
>> It’s RECFM=VB
>>
>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>> can write to the same dataset
>> Thanks
>>
>> --
>> 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


-- 
Joel C. Ewing

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

Re: Sharing data sets VSAM VB

[Joseph Reichman]

Thanks 

> On Feb 24, 2021, at 12:12 PM, Massimo Biancucci  wrote:
> 
> Joseph,
> 
> for sure.
> 
> VSAM variable length is OK.
> 
> When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.
> 
> Best regards.
> Max
> 
> 
> Mail
> priva di virus. www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
>> Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
>> reichman...@gmail.com> ha scritto:
>> 
>> Hi
>> 
>> I have multiple jobs sharing the same the same output dataset
>> 
>> It’s RECFM=VB
>> 
>> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
>> can write to the same dataset
>> Thanks
>> 
>> --
>> 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

Does SOF exist anywhere

[Colin Paice]

I used to use an IBM product SOF (Software Operator Facility).  This
allowed you to have a set of operator commands in a file, and execute them
such as F SOF,/MQSTART.   You could pass parameters to it, and include
waits etc.

Does this still exist, or is there a good alternative without having to go
to a Netview type facility


Colin

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

Re: Sharing data sets VSAM VB

[Massimo Biancucci]

Joseph,

for sure.

VSAM variable length is OK.

When define VSAM keyword RECORDSIZE( 1000 131072 ) states lrecl from to.

Best regards.
Max


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 24 feb 2021 alle ore 17:38 Joseph Reichman <
reichman...@gmail.com> ha scritto:

> Hi
>
> I have multiple jobs sharing the same the same output dataset
>
> It’s RECFM=VB
>
> Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs
> can write to the same dataset
> Thanks
>
> --
> 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: Z/VM

[Nai, Dean]

Thanks for those who replied.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 22, 2021 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Z/VM

EXTERNAL: Do not open attachments or click on links unless you recognize and 
trust the sender.


On Mon, 22 Feb 2021 10:26:15 -0600, Paul Gilmartin wrote:

>On Mon, 22 Feb 2021 15:26:53 +, Nai, Dean wrote:
>
>>Is anyone aware of a Z/VM mainframe discussion group or a Z/VM RACF 
>>discussion group? I am members of both the Z/OS mainframe and security groups.
>>
>https://urldefense.com/v3/__https://listserv.uark.edu/scripts/wa-uarkedu.exe?A0=IBMVM__;!!Oai6dtTQULp8Sw!H7Aaz6Dz5EXSmEBB0EqbGuaA6a1uxvIc-0NDpmHzw7Yko63XryX0CtHchaPST_9qLHm6$
>
I'll also suggest: 
https://urldefense.com/v3/__https://www.vm.ibm.com/techinfo/__;!!Oai6dtTQULp8Sw!H7Aaz6Dz5EXSmEBB0EqbGuaA6a1uxvIc-0NDpmHzw7Yko63XryX0CtHchaPST0V7fHVW$

... where you might infer that IBM's z/VM culture is more receptive
to user-provided content than z/OS.  History, I guess.

-- gil

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

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

Re: FTP with TLSv1.2 and SHA256

[Frank Swarbrick]

That's not the issue.   GSK_PROTOCOL_TLSV1_2=1 is correct and works.  It's the 
cipherspecs that are at issue.


From: IBM Mainframe Discussion List  on behalf of 
Roberto Halais 
Sent: Wednesday, February 24, 2021 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP with TLSv1.2 and SHA256

I read in a presentation that you specify
GSK_PROTOCOL_TLSV1_2=ON
Test this.

On Tue, Feb 23, 2021 at 8:38 PM Frank Swarbrick 
wrote:

> We are not currently using AT-TLS for FTP.
> We are currently activating TLSv1.2 support with the following environment
> variable:
> GSK_PROTOCOL_TLSV1_2=1
>
> This works fine and allows us to use (default) cipherspec 35:
> TLS_RSA_WITH_AES_256_CBC_SHA (FU1330 tlsLevel: using TLSV1.2  with
> SSL_AES_256_SHA (35)).
>
> This cipherspec uses a SHA-1 hash, and we want to eliminate use of SHA-1.
> So I'm trying to figure out how to use cipherspec 3D:
> TLS_RSA_WITH_AES_256_CBC_SHA256.
>
> It doesn't look like the FTP client supports explicit use of SHA256
> hashes, as far as I can tell.  There does not appear to be a CIPHERSUITE
> statement value to utilize SHA256.  So I've been trying to use a GSK
> environment variable to specify it.  I've tried all of the following, and
> none seem to work:
>
> GSK_V3_CIPHER_SPECS=3D
> GSK_V3_CIPHER_SPECS="3D"
> GSK_V3_CIPHER_SPECS_EXPANDED=003D
> GSK_V3_CIPHER_SPECS_EXPANDED="003D"
>
> All of them get the following (when DEBUG SEC is specified in my ftp.data<
> ftp://ftp.data> file):
> FC0334 ftpAuth:  cipherspecs =
> FC0379 ftpAuth: environment_open()
> FC0383 ftpAuth: open of the TLS environment failed with rc = 703
> (Enumeration is not valid)
> EZA2897I Authentication negotiation failed
>
> I am thinking that we might have to bite the bullet and use ATTLS instead,
> but if anyone has been successful using a SHA256 cipherspec without it I'd
> love to hear your thoughts.
>
> Thanks,
> Frank
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Politics: Poli (many) - tics (blood sucking parasites)

--
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: FTP with TLSv1.2 and SHA256

[Frank Swarbrick]

z/OS 2.3


From: IBM Mainframe Discussion List  on behalf of 
Roberto Halais 
Sent: Wednesday, February 24, 2021 5:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP with TLSv1.2 and SHA256

What z/OS version?

On Tue, Feb 23, 2021 at 8:38 PM Frank Swarbrick 
wrote:

> We are not currently using AT-TLS for FTP.
> We are currently activating TLSv1.2 support with the following environment
> variable:
> GSK_PROTOCOL_TLSV1_2=1
>
> This works fine and allows us to use (default) cipherspec 35:
> TLS_RSA_WITH_AES_256_CBC_SHA (FU1330 tlsLevel: using TLSV1.2  with
> SSL_AES_256_SHA (35)).
>
> This cipherspec uses a SHA-1 hash, and we want to eliminate use of SHA-1.
> So I'm trying to figure out how to use cipherspec 3D:
> TLS_RSA_WITH_AES_256_CBC_SHA256.
>
> It doesn't look like the FTP client supports explicit use of SHA256
> hashes, as far as I can tell.  There does not appear to be a CIPHERSUITE
> statement value to utilize SHA256.  So I've been trying to use a GSK
> environment variable to specify it.  I've tried all of the following, and
> none seem to work:
>
> GSK_V3_CIPHER_SPECS=3D
> GSK_V3_CIPHER_SPECS="3D"
> GSK_V3_CIPHER_SPECS_EXPANDED=003D
> GSK_V3_CIPHER_SPECS_EXPANDED="003D"
>
> All of them get the following (when DEBUG SEC is specified in my ftp.data<
> ftp://ftp.data> file):
> FC0334 ftpAuth:  cipherspecs =
> FC0379 ftpAuth: environment_open()
> FC0383 ftpAuth: open of the TLS environment failed with rc = 703
> (Enumeration is not valid)
> EZA2897I Authentication negotiation failed
>
> I am thinking that we might have to bite the bullet and use ATTLS instead,
> but if anyone has been successful using a SHA256 cipherspec without it I'd
> love to hear your thoughts.
>
> Thanks,
> Frank
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Politics: Poli (many) - tics (blood sucking parasites)

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

Sharing data sets VSAM VB

[Joseph Reichman]

Hi

I have multiple jobs sharing the same the same output dataset 

It’s RECFM=VB

Is it possible to define this RECFM under VSAM, as with VSAM multiple jobs can 
write to the same dataset 
Thanks 

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

Re: Colours on screen (mainframe history question)

[Charles Mills]

First interactive system I ever wrote was for the 2260. Supported 80 terminals 
on a 360/50. People thought that was pretty astounding. (This was before CICS.) 
Control unit was the 2848. Used mercury delay lines for CRT memory. They were 
heated. On a Power On it took something like 20 minutes for them to come up to 
temperature. (Marvelous engineering decision -- a heated control unit in an 
air-conditioned datacenter.)

They were mux channel attached; there was no "remote" 2260 IIRC. The client 
needed remote terminals. We found some third-party 2260 clone that supported 
bisync attachment. They supported color (because they used more or less 
off-the-shelf TV's for monitors). IIRC the color was "automatic" (protected 
fields in blue, unprotected fields in white, or whatever). Or there was some 
sort of special sequence that customized the display colors. (That is the 
relevance to this thread; would have been around 1972 or 1973.)

The 2250 was a BEAST! Graphics. Light pen. A separate function key keypad. You 
could put typewritten labels in the function keys, and light up the allowed 
keys under program control. Had an 1130 computer under the hood as its 
controller. (No wonder it cost $$$.) The very first 360 application I ever saw 
was a 2250-driving system written in PL/I for one of the big pharmas -- trying 
to remember who. It was written by John Gilmore and Associates. (Yes, our very 
own IBMMAIN John Gilmore.) The idea was you could simulate the flow of a drug 
through the body, complete with a graphical representation. I don't believe it 
ever exactly worked. This would have been in 1969.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Attila Fogarasi
Sent: Wednesday, February 24, 2021 2:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

The 3279 used tri-plane symbols for extended colour (turquoise, pink,
yellow and white, plus blank for all 3 primary colours off).  This had the
neat trick of allowing easy reverse video highlighting (invert the primary
colour bits).  GDDM was the software exploitation of 3279, which also
introduced program symbols.  Most programs used 10% of the 3279s rather
complex capabilities (a situation not helped by only 2 of the 3279 models
having the full capability set).  Great case study on how to design great
hardware badly, or rather so that it is not used.

Note that the 2260 (3270 predecessor that used a keypunch mechanical
keyboard) and 2250 (million dollar vector graphics terminal) were released
circa 1965.  So the 3279 is 15 years later.

On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
wrote:

> The interesting question to me is "which colours"?
>
> I would say we started with a 3-bit colour space: R, G, B. And so the
> colour Red is 100 in this space and a more complex colour like Yellow is
> probably 110.
>
> Is this right, though?
>
> In particular I'd be surprised if a 4th bit weren't used. But for what?
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Tony Harminc 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   24/02/2021 01:00
> Subject:[EXTERNAL] Re: Colours on screen (mainframe history
> question)
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:
>
> > IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
> recall when GDDM picked up color support.
>
> Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
> And almost certainly GDDM was under development in parallel with the
> 3279 hardware; IBM rarely comes out with hardware on a whim that has
> no software to support it. One must also remember that the 3279 was
> merely the first implementation of an architectural shift in the 3270
> series.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> 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 

Re: Colours on screen (mainframe history question)

[Seymour J Metz]

First? Wasn't the 3278 the first to use EDS?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Tuesday, February 23, 2021 8:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:

> IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't recall 
> when GDDM picked up color support.

Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
And almost certainly GDDM was under development in parallel with the
3279 hardware; IBM rarely comes out with hardware on a whim that has
no software to support it. One must also remember that the 3279 was
merely the first implementation of an architectural shift in the 3270
series.

Tony H.

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

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

Re: Colours on screen (mainframe history question)

[Seymour J Metz]

That depends on the model and the mode. In the basic mode, the color was 
determined by one of four combination of attributes, e.g., intense and input. 
In EDS mode (2B and 3B only) there was also a color type for field and 
character attributes, with a choice of attributes. Multiplane symbols added 
another layer of complexity.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Martin Packer [martin_pac...@uk.ibm.com]
Sent: Wednesday, February 24, 2021 3:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

The interesting question to me is "which colours"?

I would say we started with a 3-bit colour space: R, G, B. And so the
colour Red is 100 in this space and a more complex colour like Yellow is
probably 110.

Is this right, though?

In particular I'd be surprised if a 4th bit weren't used. But for what?

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: 
https://secure-web.cisco.com/1K-uYK1eipWFSg-6F8XNC9m_2CAm1sZo_cFkRZQ8b9SP3yxiRIXY1kGG-X1UjpIoPU18B1vjwzGpiIXMzT7fHB62cQsbDWT-XUuy6Ctn6JTRFDlMYd47fyazRCHFtqSvV24HBIPst9cpirjDKUQQ9yy4dXbT0kWr7PD50k1lN-kZdxSCOkzW9mNM6MuofKZ8leHTtmqqBkwdTP9XLy97mRBJo8GveAJBlEm9uCU6eqdobf2vesil8x23USjmYoQMGM9UxB_b0ks-1FibtiBFz7TFRS3xmr0r6TfLD_zSyral9nZbd6cO60bgRX99BSfCITrEXk6UpWpNt8z5NO2rq9OaQA0ZKBb7rLf-bny0lV8I6V3GHVYWAycaf2g4g7BcKMy_qVndFmTMy4UFV1aQjkcyuSjaPK_msPFnQnopu77dISOgqBU2_qR7FfV56vMY5/https%3A%2F%2Fmainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle):
https://secure-web.cisco.com/1pCNnU8kfL9doKBHIlVIZMuyHaCv0OdoTo35dxF9qR4b51FQPhhzpM1zczVJHBhp2IEbjrgShmpk32YIkXVS8yhgZTSjiEytCDoRLE7OrZkjiK7m1drXYdPIFyk5k-TWPCLoygXxp7mtytW1k5RZM4uZGYbUdZ_VjdL7J1VdLTnwiSR45imJX-MSuheP9OKWb264dPFx18AAhts-sbZdmVTPBl3B9VP7L5KNxtdthCvg7CVlnEac8IVABRzD3L4NbP8SQGL-APN8ApBNuhbICrPCXf518hbV2p8fU_Bub_odwpVSdSYZUWetgUxo58T3eoZvzmsR46cLs95Oey25WLgtKFLAU3jiGmujiziFQCWgGiFDfy6pNucIKG5iD4lPXoDyRvH6RoaPL_NNSLqnbPHgdA_3SF9XZSLAXN1XinmjP86ApXgoYiyGeYsUoXbSZA9GGaT7cPGckl7Ueqq6Wzw/https%3A%2F%2Fanchor.fm%2Fmarna-walle

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



From:   Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/02/2021 01:00
Subject:[EXTERNAL] Re: Colours on screen (mainframe history
question)
Sent by:IBM Mainframe Discussion List 



On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:

> IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
recall when GDDM picked up color support.

Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
And almost certainly GDDM was under development in parallel with the
3279 hardware; IBM rarely comes out with hardware on a whim that has
no software to support it. One must also remember that the 3279 was
merely the first implementation of an architectural shift in the 3270
series.

Tony H.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: Colours on screen (mainframe history question)

[Seymour J Metz]

GDDM was far from the only product to support color on the 3279. There was 
support in DIDOCS )a component of, e.g., MVS), ISPF and XEDIT (a component of 
VM/SP). GDDM used a hack with PSS to do graphics, befor APA came out.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Attila Fogarasi [fogar...@gmail.com]
Sent: Wednesday, February 24, 2021 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Colours on screen (mainframe history question)

The 3279 used tri-plane symbols for extended colour (turquoise, pink,
yellow and white, plus blank for all 3 primary colours off).  This had the
neat trick of allowing easy reverse video highlighting (invert the primary
colour bits).  GDDM was the software exploitation of 3279, which also
introduced program symbols.  Most programs used 10% of the 3279s rather
complex capabilities (a situation not helped by only 2 of the 3279 models
having the full capability set).  Great case study on how to design great
hardware badly, or rather so that it is not used.

Note that the 2260 (3270 predecessor that used a keypunch mechanical
keyboard) and 2250 (million dollar vector graphics terminal) were released
circa 1965.  So the 3279 is 15 years later.

On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
wrote:

> The interesting question to me is "which colours"?
>
> I would say we started with a 3-bit colour space: R, G, B. And so the
> colour Red is 100 in this space and a more complex colour like Yellow is
> probably 110.
>
> Is this right, though?
>
> In particular I'd be surprised if a 4th bit weren't used. But for what?
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: 
> https://secure-web.cisco.com/1tuksu0ukPCLppwAA105vO5AgobzrYuI6QbKFQsP37SpfCaspPwNHasuyXO3dTM-UIXrznH_heWw3zPVhEciQr2giuEjGwVHmL2tjlbVBhKJItAOaZW4QTTla3Q7xGpEYVSfplI7sYinKmwzq1_C4W1luMHIVEXjDbWmQzdGEwzR8vidSVPC4-oJ1kMuGCh0XZ4QfAyEqrjlsCWAH0IugtUYDxxGssUOzIvGD_9nxNnelNxSP9BfmNHsq9NwyhuqSgTaM16c2WMZHO3ld5qAsWSUGe9_l-Xwv8pNq8HzUthh6z-VKIpfaOsczs5kHTe2H07ZvdK84qTNcjV8WG8b6Anhkz_MYtuxVvMDqrsQlqTgRsGWeMBLavTvmZIBxfi5p0YEXrtkVKzBikSaXhN0scJTvQ1jBmmNAjDDipZ-cslZPSQlqBRY_-1uRqVgFNQKm/https%3A%2F%2Fmainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://secure-web.cisco.com/1sdryWJ53tfoumGwdfCueUNAYvYNAzsJA0QieHMNyRFgqF6ltl54X9BHrC31AjccvWVOJQi9MweF4n5eZcC8qFNTmmv35YGvThgHmjrnEOJXCunSVfiZ4CixJbRAHPP-kY3Q9VW_c0RTg46tayZmKP0NMBjMnBfkA94dYUaIhpcdm4-zUaDIExfs2uqEiv48N_juVUMokbrmpXoZXa3v7qTSJuhO1KCk_1kVrGRtdqsAAB33EMx9LjfZORpURD1OB6d-FjDsQxRj_2NcvOVfjdRZFG-o6tCGQugQYqwvKxWSlaT4iZ5RxYzTfC_VMQSwbCA_RRdW217XzWsaJUhWYfxhQLdbeJidWdJztjHpgIYvSqtR2ykKgFlD3FIBfJ1te6g9SuuCQSA_q5WVLzOPL5W9j_o90xu58z6ywgNuXRSZjRT3Zq5kFmjN7y9oB9BRgMi9hFsEXId7LbscprUd9nQ/https%3A%2F%2Fanchor.fm%2Fmarna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Tony Harminc 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   24/02/2021 01:00
> Subject:[EXTERNAL] Re: Colours on screen (mainframe history
> question)
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:
>
> > IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
> recall when GDDM picked up color support.
>
> Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
> And almost certainly GDDM was under development in parallel with the
> 3279 hardware; IBM rarely comes out with hardware on a whim that has
> no software to support it. One must also remember that the 3279 was
> merely the first implementation of an architectural shift in the 3270
> series.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> 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

IBM PEM (Partner Engagement Manager) Product

[Sasso, Len]

What are your experiences (good or bad) with the IBM PEM (Partner Engagement 
Manager)
Product? 



Thank You and Please Be Safe!


Len Sasso

Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

TEAM: Together Everyone Achieves More

Office Hours: M-F  7 AM - 3:45 PM      
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP with TLSv1.2 and SHA256

[Roberto Halais]

I read in a presentation that you specify
GSK_PROTOCOL_TLSV1_2=ON
Test this.

On Tue, Feb 23, 2021 at 8:38 PM Frank Swarbrick 
wrote:

> We are not currently using AT-TLS for FTP.
> We are currently activating TLSv1.2 support with the following environment
> variable:
> GSK_PROTOCOL_TLSV1_2=1
>
> This works fine and allows us to use (default) cipherspec 35:
> TLS_RSA_WITH_AES_256_CBC_SHA (FU1330 tlsLevel: using TLSV1.2  with
> SSL_AES_256_SHA (35)).
>
> This cipherspec uses a SHA-1 hash, and we want to eliminate use of SHA-1.
> So I'm trying to figure out how to use cipherspec 3D:
> TLS_RSA_WITH_AES_256_CBC_SHA256.
>
> It doesn't look like the FTP client supports explicit use of SHA256
> hashes, as far as I can tell.  There does not appear to be a CIPHERSUITE
> statement value to utilize SHA256.  So I've been trying to use a GSK
> environment variable to specify it.  I've tried all of the following, and
> none seem to work:
>
> GSK_V3_CIPHER_SPECS=3D
> GSK_V3_CIPHER_SPECS="3D"
> GSK_V3_CIPHER_SPECS_EXPANDED=003D
> GSK_V3_CIPHER_SPECS_EXPANDED="003D"
>
> All of them get the following (when DEBUG SEC is specified in my ftp.data<
> ftp://ftp.data> file):
> FC0334 ftpAuth:  cipherspecs =
> FC0379 ftpAuth: environment_open()
> FC0383 ftpAuth: open of the TLS environment failed with rc = 703
> (Enumeration is not valid)
> EZA2897I Authentication negotiation failed
>
> I am thinking that we might have to bite the bullet and use ATTLS instead,
> but if anyone has been successful using a SHA256 cipherspec without it I'd
> love to hear your thoughts.
>
> Thanks,
> Frank
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Politics: Poli (many) - tics (blood sucking parasites)

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

Re: FTP with TLSv1.2 and SHA256

[Roberto Halais]

What z/OS version?

On Tue, Feb 23, 2021 at 8:38 PM Frank Swarbrick 
wrote:

> We are not currently using AT-TLS for FTP.
> We are currently activating TLSv1.2 support with the following environment
> variable:
> GSK_PROTOCOL_TLSV1_2=1
>
> This works fine and allows us to use (default) cipherspec 35:
> TLS_RSA_WITH_AES_256_CBC_SHA (FU1330 tlsLevel: using TLSV1.2  with
> SSL_AES_256_SHA (35)).
>
> This cipherspec uses a SHA-1 hash, and we want to eliminate use of SHA-1.
> So I'm trying to figure out how to use cipherspec 3D:
> TLS_RSA_WITH_AES_256_CBC_SHA256.
>
> It doesn't look like the FTP client supports explicit use of SHA256
> hashes, as far as I can tell.  There does not appear to be a CIPHERSUITE
> statement value to utilize SHA256.  So I've been trying to use a GSK
> environment variable to specify it.  I've tried all of the following, and
> none seem to work:
>
> GSK_V3_CIPHER_SPECS=3D
> GSK_V3_CIPHER_SPECS="3D"
> GSK_V3_CIPHER_SPECS_EXPANDED=003D
> GSK_V3_CIPHER_SPECS_EXPANDED="003D"
>
> All of them get the following (when DEBUG SEC is specified in my ftp.data<
> ftp://ftp.data> file):
> FC0334 ftpAuth:  cipherspecs =
> FC0379 ftpAuth: environment_open()
> FC0383 ftpAuth: open of the TLS environment failed with rc = 703
> (Enumeration is not valid)
> EZA2897I Authentication negotiation failed
>
> I am thinking that we might have to bite the bullet and use ATTLS instead,
> but if anyone has been successful using a SHA256 cipherspec without it I'd
> love to hear your thoughts.
>
> Thanks,
> Frank
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Politics: Poli (many) - tics (blood sucking parasites)

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

Re: Colours on screen (mainframe history question)

[Joe Monk]

My first experience with a real 3279  was in college, University  of Texas
  at Arlington, 1983.

Our engineering  school  had three  along with a Tektronix graphics  device
 (4010/14?) side by side. We could write  code in fortran on the 3279 and
use the  graphics  libraries to draw on the tektronix terminal...

Joe

On Wed, Feb 24, 2021 at 5:16 AM Colin Paice  wrote:

> I was around during 3279 development.  I think it was code named hotspur
> (or was it beano).
> During a demo a customer (a big bank) asked "why do people need a colour
> screen".  A quick witted person replied "you could display overdrawn
> accounts in red!!" "great - I'll put in an order".
> And of course the managers got the colour screens first.
> Colin
>
> On Wed, 24 Feb 2021 at 10:56, Attila Fogarasi  wrote:
>
> > The 3279 used tri-plane symbols for extended colour (turquoise, pink,
> > yellow and white, plus blank for all 3 primary colours off).  This had
> the
> > neat trick of allowing easy reverse video highlighting (invert the
> primary
> > colour bits).  GDDM was the software exploitation of 3279, which also
> > introduced program symbols.  Most programs used 10% of the 3279s rather
> > complex capabilities (a situation not helped by only 2 of the 3279 models
> > having the full capability set).  Great case study on how to design great
> > hardware badly, or rather so that it is not used.
> >
> > Note that the 2260 (3270 predecessor that used a keypunch mechanical
> > keyboard) and 2250 (million dollar vector graphics terminal) were
> released
> > circa 1965.  So the 3279 is 15 years later.
> >
> > On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
> > wrote:
> >
> > > The interesting question to me is "which colours"?
> > >
> > > I would say we started with a 3-bit colour space: R, G, B. And so the
> > > colour Red is 100 in this space and a more complex colour like Yellow
> is
> > > probably 110.
> > >
> > > Is this right, though?
> > >
> > > In particular I'd be surprised if a 4th bit weren't used. But for what?
> > >
> > > Cheers, Martin
> > >
> > > Martin Packer
> > >
> > > WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
> > >
> > > +44-7802-245-584
> > >
> > > email: martin_pac...@uk.ibm.com
> > >
> > > Twitter / Facebook IDs: MartinPacker
> > >
> > > Blog: https://mainframeperformancetopics.com
> > >
> > > Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> > > https://anchor.fm/marna-walle
> > >
> > > Youtube channel:
> > https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> > >
> > >
> > >
> > > From:   Tony Harminc 
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date:   24/02/2021 01:00
> > > Subject:[EXTERNAL] Re: Colours on screen (mainframe history
> > > question)
> > > Sent by:IBM Mainframe Discussion List <
> IBM-MAIN@LISTSERV.UA.EDU>
> > >
> > >
> > >
> > > On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:
> > >
> > > > IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I
> don't
> > > recall when GDDM picked up color support.
> > >
> > > Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
> > > And almost certainly GDDM was under development in parallel with the
> > > 3279 hardware; IBM rarely comes out with hardware on a whim that has
> > > no software to support it. One must also remember that the 3279 was
> > > merely the first implementation of an architectural shift in the 3270
> > > series.
> > >
> > > Tony H.
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > >
> > >
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Format of CMS packed files

[Paul Gilmartin]

On Wed, 24 Feb 2021 12:48:24 +0200, Binyamin Dissen wrote:
>
>Is there a way to use CMS to make an XMIT type file? Don't see it.
>
SENDFILE

— gil

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

Re: Colours on screen (mainframe history question)

[Colin Paice]

I was around during 3279 development.  I think it was code named hotspur
(or was it beano).
During a demo a customer (a big bank) asked "why do people need a colour
screen".  A quick witted person replied "you could display overdrawn
accounts in red!!" "great - I'll put in an order".
And of course the managers got the colour screens first.
Colin

On Wed, 24 Feb 2021 at 10:56, Attila Fogarasi  wrote:

> The 3279 used tri-plane symbols for extended colour (turquoise, pink,
> yellow and white, plus blank for all 3 primary colours off).  This had the
> neat trick of allowing easy reverse video highlighting (invert the primary
> colour bits).  GDDM was the software exploitation of 3279, which also
> introduced program symbols.  Most programs used 10% of the 3279s rather
> complex capabilities (a situation not helped by only 2 of the 3279 models
> having the full capability set).  Great case study on how to design great
> hardware badly, or rather so that it is not used.
>
> Note that the 2260 (3270 predecessor that used a keypunch mechanical
> keyboard) and 2250 (million dollar vector graphics terminal) were released
> circa 1965.  So the 3279 is 15 years later.
>
> On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
> wrote:
>
> > The interesting question to me is "which colours"?
> >
> > I would say we started with a 3-bit colour space: R, G, B. And so the
> > colour Red is 100 in this space and a more complex colour like Yellow is
> > probably 110.
> >
> > Is this right, though?
> >
> > In particular I'd be surprised if a 4th bit weren't used. But for what?
> >
> > Cheers, Martin
> >
> > Martin Packer
> >
> > WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
> >
> > +44-7802-245-584
> >
> > email: martin_pac...@uk.ibm.com
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog: https://mainframeperformancetopics.com
> >
> > Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> > https://anchor.fm/marna-walle
> >
> > Youtube channel:
> https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> >
> >
> >
> > From:   Tony Harminc 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   24/02/2021 01:00
> > Subject:[EXTERNAL] Re: Colours on screen (mainframe history
> > question)
> > Sent by:IBM Mainframe Discussion List 
> >
> >
> >
> > On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:
> >
> > > IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
> > recall when GDDM picked up color support.
> >
> > Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
> > And almost certainly GDDM was under development in parallel with the
> > 3279 hardware; IBM rarely comes out with hardware on a whim that has
> > no software to support it. One must also remember that the 3279 was
> > merely the first implementation of an architectural shift in the 3270
> > series.
> >
> > Tony H.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > --
> > 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: Colours on screen (mainframe history question)

[Attila Fogarasi]

The 3279 used tri-plane symbols for extended colour (turquoise, pink,
yellow and white, plus blank for all 3 primary colours off).  This had the
neat trick of allowing easy reverse video highlighting (invert the primary
colour bits).  GDDM was the software exploitation of 3279, which also
introduced program symbols.  Most programs used 10% of the 3279s rather
complex capabilities (a situation not helped by only 2 of the 3279 models
having the full capability set).  Great case study on how to design great
hardware badly, or rather so that it is not used.

Note that the 2260 (3270 predecessor that used a keypunch mechanical
keyboard) and 2250 (million dollar vector graphics terminal) were released
circa 1965.  So the 3279 is 15 years later.

On Wed, Feb 24, 2021 at 7:55 PM Martin Packer 
wrote:

> The interesting question to me is "which colours"?
>
> I would say we started with a 3-bit colour space: R, G, B. And so the
> colour Red is 100 in this space and a more complex colour like Yellow is
> probably 110.
>
> Is this right, though?
>
> In particular I'd be surprised if a 4th bit weren't used. But for what?
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Tony Harminc 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   24/02/2021 01:00
> Subject:[EXTERNAL] Re: Colours on screen (mainframe history
> question)
> Sent by:IBM Mainframe Discussion List 
>
>
>
> On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:
>
> > IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't
> recall when GDDM picked up color support.
>
> Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
> And almost certainly GDDM was under development in parallel with the
> 3279 hardware; IBM rarely comes out with hardware on a whim that has
> no software to support it. One must also remember that the 3279 was
> merely the first implementation of an architectural shift in the 3270
> series.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> 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

Format of CMS packed files

[Binyamin Dissen]

I am trying to move some CMS V packed files to TSO. The were done packed as
that was the only way to transfer V format without losing the length. 

Is there a way to use CMS to make an XMIT type file? Don't see it.

Looking at CMS PACKED format I see

http://www.vm.ibm.com/devpages/altmarka/packed.html 

which unfortunately has the format "under construction".

Before I reinvent the wheel, is there some doc on what the format is?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Colours on screen (mainframe history question)

[Martin Packer]

The interesting question to me is "which colours"?

I would say we started with a 3-bit colour space: R, G, B. And so the 
colour Red is 100 in this space and a more complex colour like Yellow is 
probably 110.

Is this right, though?

In particular I'd be surprised if a 4th bit weren't used. But for what?

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

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

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



From:   Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   24/02/2021 01:00
Subject:[EXTERNAL] Re: Colours on screen (mainframe history 
question)
Sent by:IBM Mainframe Discussion List 



On Tue, 23 Feb 2021 at 19:10, Seymour J Metz  wrote:

> IBM had color support for DIDOCS, ISPF and XEDIT pretty early. I don't 
recall when GDDM picked up color support.

Very early 1980s - earlier than I remember support for DIDOCS or ISPF.
And almost certainly GDDM was under development in parallel with the
3279 hardware; IBM rarely comes out with hardware on a whim that has
no software to support it. One must also remember that the 3279 was
merely the first implementation of an architectural shift in the 3270
series.

Tony H.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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