Re: PC Interference from shredder Was: Kinda fun

[Lloyd Fuller]

When I was at Orange Coast College in the mid-70s, we had a 370-155 that had 
non-IBM memory.  The College had a microwave link between the Costa Mesa campus 
and the Huntington Beach campus.  The microwave link was at the campus library, 
and they fired it up about 9AM each week-day.  The computer center was in the 
path between the two campuses.  We would get machine checks each morning and 
about two minutes or so later, the system would IPL and everything would be 
fine until the next morning.
We finally got someone to look at the problem, and if I remember correctly, the 
microwave dish was slightly out of alignment and once they fixed that, no more 
machine checks.
Lloyd


Sent from AT Yahoo Mail for iPad


On Sunday, November 12, 2023, 8:55 AM, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

On Sun, 12 Nov 2023 10:48:19 +0100, Bernd Oppolzer wrote:
>
>At some point he looked out of the window and he saw the radar tower,
>which is about
>half a mile away and is needed for the traffic control of the airport
>nearby. So he speculated
>
A co-worker had worked for the FAA at a commercial airport near a
military airfield.  Military controlled its airspace; airport controlled
its.  He made a scatter plot of where planes vanished from civilian
control, thinking it might be useful..He showed it to a military
colleague who was aghast that the boundary of military control,
classified, was publicly available.

I heard a story of a physics lab that tried to operate a computer
room next to a spark chamber.

-- 
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: Two related member generation questions

[Lloyd Fuller]

I can answer one part of this.  GDGs can be members of PDS or PDSE.  This has 
been true for a long time.  The actual generated member name is different than 
for a GDG dataset.
Lloyd


Sent from AT Yahoo Mail for iPad


On Monday, May 29, 2023, 5:56 PM, Charles Mills  wrote:

1. Is there any support in JCL or in ISPF for reading member generations? If I 
want to reference or browse a PDSE 2 member generation other than the latest, 
is it possible to do so? Am I just missing the doc somewhere?

2. Is this not an error or at least an illogical statement in the JCL 
reference? Under DSNAME - Cataloged data set name it says

dsname(member)
Specifies the name of the permanent partitioned data set (PDS) or the 
partitioned data set extended (PDSE), and the name of a member within that data 
set. If the member does not exist and DISP=OLD or DISP=SHR is specified, the 
allocation will succeed, but the job will fail when the data set is opened for 
input. If the member does not exist and the data set is opened for output, the 
system will add the member to the data set.

member
1 to 8 alphanumeric or national characters, or a character X'C0'. The first 
character must be alphabetic, national, +, or -. If the first character is + or 
-, the member is a part of a generation data group.

dsname(generation)
Specifies the name of a generation data group (GDG) and the generation number 
(zero or a signed integer) of a generation data set within the GDG.

That member description is not right, is it? If the first character is numeric, 
+ or -, it's not a reference to a member of a PDS or PDSE at all -- it 
specifies a generation data set, right? Or is this support for member 
generations and I am not reading it correctly?

Also, member syntax has nothing to do with whether the dataset is cataloged, 
right? The syntax is exactly the same with a VOLSER reference or for a 
temporary dataset, right?

Charles

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




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

Re: ADRDSSU DUMP PATH

[Lloyd Fuller]

I usually use pax either via the command line or batch to an MVS file and then 
DFSMS the MVS file.
Lloyd 


Sent from AT Yahoo Mail for iPad


On Thursday, August 11, 2022, 8:39 AM, Mark Jacobs 
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

I'm trying to use ADRDSSU to backup a directory and all files and 
subdirectories under it. Unless I'm missing something it doesn't look like it's 
supported.

DUMP PATH(INC('sourcedir')) WORKINGDIRECTORY('/service') OUTDD(OUTDD)

ADRDSSU is only backing up the directory itself, nothing under it.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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




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

Re: AT-TLS & FTP troubles - cannot get very simple setup working

[Lloyd Fuller]

You are misusing things here.  SFTP does not equal FTPS.
SFTP is overlaid onshore which is using an encrypted interface itself.  FTPS is 
what the FTP server can support.
WinSCP can do both but not FTPS on port 22.
Lloyd

Sent from AT Yahoo Mail for iPad


On Wednesday, May 25, 2022, 11:20 AM, Michael Babcock  
wrote:

I don’t think you can use PAGENT for port 22 (not 100% sure on that).  If
using port 22 configure SSHD.

Did you set the trace parm in PAGENT to 255?  You will get much more info
in SYSLOG by doing that.

On Wed, May 25, 2022 at 10:05 AM Bob  wrote:

> That's one I have changed back and forth 21 ... 22 ... 21 .. 22 ... 21
> &22.  The config I started with had 21 in it, but the WinSCP references 22
> so I have been trying both ... without success.  I changed it back to 21
> now. Still fails.
>
> I just added an ftp configuration parameter of FTPLOGGING TRUE and received
> this message:
>
> EZYFS51I ID=FTPD10 CONN  fails  Reason=3 Text=getpeername failed
>
> Now I'm trying to figure out what that is telling me.
>
> On Wed, May 25, 2022 at 8:46 AM Michael Babcock 
> wrote:
>
> > I can SSH into z/OS USS but I don’t use pagent for port 22.  You should
> > configure SSHD for that.  Remove port 22 from PAGENT.
> >
> > On Wed, May 25, 2022 at 8:46 AM Bob  wrote:
> >
> > > I am struggling to get AT-TLS and FTP working on my new z/OS 2.5 system
> > and
> > > I don’t know why. I’m sure I am
> > >
> > > missing something very simple, but I have spent a lot of time over the
> > last
> > > few weeks trying to figure it out
> > >
> > > and I cannot.  Note that ftp without encryption does work and I have
> > > nothing else using PAGENT or AT-TLS.
> > >
> > >
> > >
> > > I originally started with a configuration created by z/OSMF Network
> > > Configuration Assistant, but after
> > >
> > > numerous attempts to get it working I have pared it down to the very
> > > minimum configuration below.
> > >
> > >
> > >
> > > I’m not even sure what info to share.
> > >
> > >
> > >
> > > When I try to connect using WinSCP I just get this:
> > >
> > >
> > >
> > > d:\>"c:\Program Files (x86)\WinSCP\WinSCP" /log=d:\WinSCP.log
> /loglevel=2
> > > testmvs
> > >
> > > Searching for host...
> > >
> > > Network error: Connection to "testmvs" refused.
> > >
> > > The server rejected SFTP connection, but it listens for FTP
> connections.
> > >
> > > Did you want to use FTP protocol instead of SFTP? Prefer using
> > encryption.
> > >
> > > winscp>
> > >
> > >
> > >
> > > And the WinSCP log doesn’t show much more:
> > >
> > >
> > >
> > > Looking up host "testmvs" for SSH connection
> > >
> > > Connecting to 10.80.63.94 port 22
> > >
> > > Failed to connect to 10.80.63.94: Network error: Connection refused
> > >
> > >
> > >
> > > And here are the related configuration files.
> > >
> > >
> > >
> > > Here’s the pagent.conf:
> > >
> > >
> > >
> > > LogLevel  511
> > >
> > > TcpImage  TCPIP FLUSH
> > >
> > > TTLSConfig /etc/TTLSConfig.conf FLUSH
> > >
> > >
> > >
> > > And here is the TTLSConfig.conf:
> > >
> > >
> > >
> > > TTLSGroupAction      ftp_server_group
> > >
> > > {
> > >
> > >    TTLSEnabled On
> > >
> > >    Trace 30
> > >
> > > }
> > >
> > > TTLSEnvironmentAction ftp_server_env
> > >
> > > {
> > >
> > >    HandshakeRole      Server
> > >
> > >    TTLSCipherParmsRef ftp_server_ciphers
> > >
> > >    TTLSKeyringParms
> > >
> > >    {
> > >
> > >      Keyring mtskeyring
> > >
> > >    }
> > >
> > >    TTLSEnvironmentAdvancedParms
> > >
> > >    {
> > >
> > >      ApplicationControlled On
> > >
> > >      SecondaryMap          On
> > >
> > >      TLSv1.2              On
> > >
> > >      TLSv1.3              On
> > >
> > >    }
> > >
> > > }
> > >
> > > TTLSCipherParms      ftp_server_ciphers
> > >
> > > {
> > >
> > >    V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
> > >
> > >    V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
> > >
> > >    V3CipherSuites TLS_RSA_WITH_NULL_SHA
> > >
> > > }
> > >
> > > TTLSRule              ftp_server_rule
> > >
> > > {
> > >
> > >    LocalPortRange          21-22
> > >
> > >    Direction                Inbound
> > >
> > >    TTLSGroupActionRef      ftp_server_group
> > >
> > >    TTLSEnvironmentActionRef ftp_server_env
> > >
> > > }
> > >
> > >
> > >
> > > Here is a ‘netstat ttls group’ command:
> > >
> > >
> > >
> > > MVS TCP/IP NETSTAT CS V2R5      TCPIP Name: TCPIP          13:14:46
> > >
> > > TTLSGrpAction                            Group ID          Conns
> > >
> > >   -  -
> > >
> > > ftp_server_group                          0003              0
> > >
> > >
> > >
> > > Does that Conns=0 mean anything?
> > >
> > >
> > >
> > > Let me know if there is some other info that might help.
> > >
> > >
> > >
> > > Thank you VERY MUCH for any  suggestions you can offer.
> > >
> > >
> > >
> > > Bob Lamerand
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / 

Re: ISPF edit, file tagging and ASCII conversion

[Lloyd Fuller]

The 037 code page square brackets are not ASCII compatible brackets.  That is 
part of the reason for 1047.
Regards.
Lloyd


Sent from AT Yahoo Mail for iPad


On Tuesday, February 8, 2022, 7:45 PM, David Crayford  
wrote:

On 8/2/22 11:06 am, Paul Gilmartin wrote:
>>    ...
>> The characters are supported in all code pages. They are just in the
>> wrong code-point when translating between IBM-273 and ISO8859-1. I have
>> formed the opinion that the ISPF editor does no honor code pages
>> and only supports translation between IBM-1047 <-> ISO8859-1.
>>
> The ISPF editor does much better than that. But, in general, it's complicated:
> 
I don't think it does. I just edited a ISO8859-1 tagged file using 037 
and inserted square brackets []. When I edited the file using Vim the 
square brackets had not been translated correctly.
I am almost 100% sure that ISPF only supports conversion from 1047. I'm 
going to ask IBM.

--
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: S/360-50 emulator

[Lloyd Fuller]

Did they ever hear of the original VM/360?  According to what I understood from 
people who worked at Lincoln Labs, that was exactly what it was supposed to do. 
 It was developed to train 360 CEs.
Regards.
Lloyd


Sent from AT Yahoo Mail for iPad


On Thursday, January 27, 2022, 12:13 PM, Pew, Curtis G 
 wrote:

On Jan 27, 2022, at 10:23 AM, rahimazizarab 
<03f036d88eeb-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Did they ever hear of Hercules.

Yes. Hercules emulates the System/360 and descendent architectures. This will 
be emulating the underlying S/360 model 50 implementation, so they can run the 
original microcode and manage it with the original hardware console.


-- 
Pew, Curtis G
curtis@austin.utexas.edu

--
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: PAX/TRS zFS

[Lloyd Fuller]

I do this, but I allocate the pax file before trying to write it.  I also 
specify -x OS390 to be sure to get links and other attributes.
Lloyd


Sent from AT Yahoo Mail for iPad


On Monday, October 11, 2021, 4:00 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

On Mon, 11 Oct 2021 15:20:24 -0400, David Spiegel wrote:
>
>Every time I've used Windows as a "waystation", I've never had a problem
>with TRS Files.
> 
What are the attributes of your "pax -z" output data set?  If RECFM=FB
it ought to be comparably robust with BINARY transfers.  Did you
pre-allocate it?  And it would save you the second job.

And.  I've extracted. pax -z output on a desktop by. piping through gunzip.

Alas, TRSMAIN is UNIX-hostile.  Wouldn't it be nice to pipe pax directly
into TRSMAIN?  (Cue Hobart Spitz.)

Add Carmen's delay step.  It won't solve your problem.  But while it sleeps
uou can display ENQs.

-- 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: ICSF Hash with a certain seed (Key)

[Lloyd Fuller]

You are dealing with ASCII and EBCDIC.  So you will not get the same answers 
unless both use one or the other.
Lloyd 


Sent from AT Yahoo Mail for iPad


On Wednesday, September 15, 2021, 1:59 PM, Isabel  
wrote:

Hello!!

We are still doing tests with our ICSF.

Our scenario:

We have the following Link:
https://www.freeformatter.com/hmac-generator.html#ad-output

For example we enter

in  "Copy-paste the string here"                                    :
Hola Mundo
in  "Secret key"                                                        :
  ABCabcAB12345678
in  "Select a message digest algorithm"                      :  We
select SHA-256

Then we click on  COMPUTE HMAC, and the following appears :
7483f0f47d20c89256805b69936ebdc31e62d99a40f6640b334c6b5a8d83df5e

In Mainframe we use  the CSNBSKI2 callable service first (to import the
key) and then the CSNBHMG Callable Service (that calculate the HMAC with
SHA-256 using the output of the first verb)

Our issue is that we have different results using the link above and the
mainframe and we are almost sure we need another conversion in the middle

I appreciate any help. Thanks in advance.

Regards, Andrea!



On Fri, Aug 13, 2021 at 5:28 PM Eric D Rossman  wrote:

> I've got questions. :)
>
> > Our scenario:
> > We are running z/OS 2.2, Crypto Express 5 and FMID=HCR77B0
>
> This is a little out of service but I think we can make this work.
>
> > We want to calculate a hash using sha-256 with a certain secret key (or
> > seed) that is provided by someone external (and given to us). We are not
> > sure how to store that key in the CKDS Dataset. The length of the key is
> 32
> > bits and has the form of n(1)n(2)n(32) where each n(i) is an
> > hexadecimal character (I don't know why...)
>
> I assume you mean 32 nibbles long (128 bits) because ICSF won't allow an
> HMAC key of less than 80 bits.
>
> Since you are on HCR77B0, you would convert it to binary and then use
> CSNBSKI2 to import clear key material as a secure key token. Doing this
> will require enabling SSM (special secure mode) in ICSF options dataset.
>
> Then, you can use CSNBKRC2 to put the token into the CKDS.
>
> > We already created and stored an AES master key in the cryptographic
> > hardware and we also changed the format of our CKDS in order to use
> HMAC.
>
> Perfect.
>
> > We tried different ways of putting this key in the CKDS using different
> > verbs, like using a REXX example from the web (HMAC Generation from a
> Clear
> > Key )
>
> Do you have a link to that example? CSNBHMG doesn't allow clear key tokens
> until "Cryptographic Support for z/OS V2R2 - z/OS V2R4 (HCR77D1)" (five
> releases after the release you have).
>
> > In our mainframe we want to use the callable service (verb) CSNBHMG in a
> > Cobol program to calculate the hash using the key stored in the CKDS.
> This
> > output should be the same as the output using
> > (with the same key).
>
> To be clear, that page is treating the data as ASCII, so you will need to
> account for that in your COBOL (ensure that the data is kept as binary
> until it is HMACed.
>
> > Our biggest issue is how to put this secret key (or seed) in the CKDS
> > dataset.
>
>
> --
> 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: IBM Encryption Facility for OpenPGP

[Lloyd Fuller]

The issue is probably EBCDIC vs ASCII for the pass-phrase.  
Lloyd


Sent from AT Yahoo Mail for iPad


On Monday, April 19, 2021, 6:52 AM, Beesley, Paul  wrote:

Hi

Does anyone use IBM Encryption Facility for OpenPGP (FMID HCF7740), 
specifically to encrypt files on z/OS and decrypt them on Windows or Linux?

I can successfully encrypt a file using a PassPhrase (not keys) and can decrypt 
it on another mainframe system.
However, if I send the encrypted file to another platform I cannot decrypt it. 
It detects that I've used a passphrase, and AES_256, but will not accept the 
PassPhrase.

This is what I get on Windows:
C:\Users\xxx\Downloads>gpg -o D2021109.TEST3.TXT --decrypt 
D2021109.TEST3.ENC
gpg: AES256.CFB encrypted session key
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key

On Linux it's similar but the message is
gpg: decryption failed: no secret key

Any help welcome. I do have a PMR open with IBM, but every little helps...

Paul

Atos is a trading name used by the Atos group. The trading entity is registered 
in England and Wales: Atos IT Services UK Limited (registered number 01245534). 
The registered office is located at: Second Floor, MidCity Place, 71 High 
Holborn, London, WC1V 6EA. The VAT No. is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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




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

Re: Is there a vertical split in ISPF?

[Lloyd Fuller]

1 connection 4 addresses on 3274 according to the data sheet.  So three LPARs 
plus VTAM screen would be possible.
Lloyd


Sent from AT Yahoo Mail for iPad


On Friday, April 16, 2021, 7:53 PM, Tom Brennan  
wrote:

Interesting!  So now I'm wondering how consoles from 3 different LPARs 
appeared on the same screen, plus a spare with a VTAM welcome message. 
At the time I thought all our consoles were direct connections (defined 
as unit addresses).

It was a long time ago so this could have been a dream or nightmare.

On 4/16/2021 4:35 PM, Ken Bloom wrote:
> Only 1 coax cable to a 3290.  It was a DFT device (distributed function 
> terminal).  They were more of an SNA device and not sure they functioned as 
> non-sna from what I remember
> 
> Kenneth A. Bloom
> Avenir Technologies Inc
> /d/b/a Visara International
> 203-984-2235
> bl...@visara.com
> www.visara.com
> 
> 
> On Apr 16, 2021, at 7:28 PM, Tom Brennan  wrote:
> 
> We had one 3290 where I worked, and my guess it was an IBM promotion or 
> perhaps ordered by someone who found they didn't like it.  So it ended up in 
> the tape room where it saved desk space by combining consoles for 3 LPARs 
> with a single TSO session.  I'm pretty sure it had 4 coax cables, so in that 
> mode the vertical split was not used.
> 
> Like Ed mentioned, I remember watching the text paint itself on the screen as 
> it arrived.  Since the plasma only had one brightness level, highlighted text 
> was underlined instead.  In addition, I seem to remember the underlines 
> appeared in a second painting scan after all the text had already finished 
> painting.
> 
> By coincidence, a week ago I received my monthly Model Aviation magazine and 
> there's a new transmitter featured that seems to have stolen the 3290 color: 
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.modelaviation.com%2fsites%2fdefault%2ffiles%2fImport%20Model.JPG=E,1,0e94sjqD6wpOaLrccRG_7BPo1mWmikGmSGQ3eTyyej2fPLdWxDbP2UZuYjREHrhTHYEbU9GRDXecXgpoGlYNIGCeeNu5QgSQuL2dKgl-01cMpCOBIB8Zhoc,=1
> 
> On 4/16/2021 2:47 PM, Steve Smith wrote:
> The 3290 added what I think was called "DFT", or "partitioned mode" to the
> 3270 protocol, and allowed a smart application (afaik, ISPF is the only
> application that smart) to divide up the screen into several logical
> screens.  The ISPF SPLITV command implemented that.  Maybe some TN3270 apps
> can support it, but I haven't explored it, as multiple sessions are better
> anyway.
> I used a 3290 for a while in the Naughty 90s, and liked it, except for the
> orange display.  The 3290 was a gas-plasma or something like that, so the
> color was chosen by physics, not aesthetics.
> sas
> On Fri, Apr 16, 2021 at 4:47 PM Ed Jaffe 
> wrote:
> On 4/16/2021 1:43 PM, Bob Bridges wrote:
> Somewhere in the dim reaches of my past I think I saw mention of the
> ability to split an ISPF screen vertically rather than horizontally.  I've
> never tried it, and I'm not sure I didn't just imagine the capability.
> 
> I used to have a 3290 "gas" panel display that had this feature.
> 
> The text was always orange, did not display high-intensity characters,
> and painted very slowly. But, it was kinda cool nonetheless.
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.phoenixsoftware.com%2f=E,1,QuU1IdzOgbHy5Mqfhn-DOnayC2O2g4639_PqaZ-ECjnu1GxEu9UfO5ZxySDZBYqurSKFfYoHBm8aEnZJPLZiNJ-uVKJIqC8Vs1Jh7EBgRtED9A,,=1
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

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




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

Re: How best to copy all UNIX files one z/OS to another

[Lloyd Fuller]

And nobody has mentioned that pax will write or read an MVS file so you are not 
restricted to Open MVS for the intermediate files.

Regards.

Lloyd

Sent from my iPad

> On Oct 29, 2020, at 10:01 AM, Charles Mills  wrote:
> 
> *Size* (disk space) might be a constraint so compression is good.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Thursday, October 29, 2020 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How best to copy all UNIX files one z/OS to another
> 
>> On Wed, 28 Oct 2020 18:49:46 +, Michael Brennan wrote:
>> 
>> After the pax, unmount your new ZFS/HFS file.  DFDSS dump it, terse the dump 
>> then FTP the tersed file.  At the receiving site, unterse and restore.
>> 
> That seems to be an exercise in seeing how many needless utilities you can
> exploit.  Just transfer the pax archive.
> 
> And the OP says bandwidth is not a constraint; no need to compress.
> Even so, pax has a "-z" option.
> 
> -- 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: Multi-channel OSA-ICC routing and TCP port behavior

[Lloyd Fuller]

z/VM and z/VSE allow 3215s as their consoles.  z/OS does not.  z/OS requires a 
3270 full screen console.

Regards.

Lloyd

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen
Sent: Tuesday, July 21, 2020 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multi-channel OSA-ICC routing and TCP port behavior

I don't have an answer to that. I know what works and what does not. I never 
dug into what was different due to the settings.

Most likely, it was something not in the specifications that z/OS happened to 
use, or had added for some reason, to the 3274 long ago.

Tony Thigpen

Seymour J Metz wrote on 7/21/20 9:32 AM:
> Doesn't z/OS work with a real 3270 as a console? If so, then it's the ICC 
> that's doing something nonstandard with the 3270 setting.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Tony Thigpen [t...@vse2pdf.com]
> Sent: Tuesday, July 21, 2020 9:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Multi-channel OSA-ICC routing and TCP port behavior
> 
> Brian,
> 
> In regards to the '3270' or 'console' setting, that is very specific 
> to z/OS. On z/VSE and z/VM the consoles are set to '3270' in the ICC 
> configuration. Setting the value to 'console' for them will lead to 
> problems. Yet, on z/OS, you must set the field to 'console' handle to 
> some quirk that z/OS has as it relates to consoles.
> 
> So, back to your question: "Why?", because z/OS again used something 
> non-standard in the operating system.
> 
> (As someone that works across all three of the operating systems, I 
> see this often. z/OS plays by it's own house rules, not the rules 
> printed inside the box top.)
> 
> Tony Thigpen
> 
> Brian Westerman wrote on 7/21/20 4:44 AM:
>> I completely disagree.  Why would IBM have two settings in the configuration 
>> screen for them, one as a 3270 and the other as a console, if they only 
>> wanted you to be able to use consoles?
>>
>> Brian
>>
>> On Mon, 20 Jul 2020 11:25:54 +, Parwez Hamid  
>> wrote:
>>
>>> Agreed. The full name is OSA-Express Integrated Console Controller and was 
>>> primarly meant to provide Console Support to IPL OSes. Overtime, its use 
>>> has evolved but the basic concept remains.
>>>
>>> Regards
>>>
>>> Parwez Hamid​
>>>
>>> 
>>> From: IBM Mainframe Discussion List  on 
>>> behalf of R.S. 
>>> Sent: 20 July 2020 12:17
>>> To: IBM-MAIN@LISTSERV.UA.EDU 
>>> Subject: Re: Multi-channel OSA-ICC routing and TCP port behavior
>>>
>>> Excuse me, but IMHO OSA-ICC is just way to get rid off old equipment 
>>> like 3174L. It is NOT replacement, it is only for local (called 
>>> non-SNA) terminals, printers and ...CONSOLES. Consoles are the most 
>>> important. Of course 3172, 3274, and other controllers were not the goal.
>>>
>>> IBM went looong way from 3174s to to ICC. There were 2074 (quite 
>>> expensive), VTAM consoles (not very usable for IPL), older SYSCON 
>>> (Operating System Messages on HMC) and the latest 3270-like SYSG aka 
>>> PCOMM-like icon in HMC. SYSG is AFAIK z/VM nomenclature.
>>>
>>>
>>> BTW, Note, nomenclaure for "HMC-like" consoles:
>>> 1. Operating System Messages
>>> z/VM: SYSC
>>> z/OS: SYSCON
>>>
>>> 2. HMC Integrated 3270 console (is it proper name?)
>>> z/VM: SYSG
>>> z/OS: HMCS
>>>
>>> I don't know about other OSes.
>>>
>>> --
>>> Radoslaw Skorupka
>>> Lodz, Poland
>>>
>>>
>>>
>>>
>>>
>>>
>>> W dniu 19.07.2020 o 15:17, Tony Thigpen pisze:
 Christian,
 I was dismayed too when I first discovered this limitation. The 
 OSA-C was originally intended to eliminate the local 3174 
 requirement. It was not really designed to replace the 3172-003, 
 which is what many are using it for today.

 And, you also need to look back at the OSA-C's roots which was the
 3274 emulation in the P370, P390 and the MP3000.

 Tony Thigpen

 Christian Svensson wrote on 7/19/20 8:40 AM:
> Thanks for the input folks.
>
> Brian: I have it working just fine, the setup was easy as you said 
> - the reason I started this thread was because I couldn't 
> understand why the limitations on the TCP port number and the 
> philosophy behind the routing.
>
> It seems pretty weird to me that IBM implemented ICC this way, but 
> hey - I'm just a stranger on the internet :-)
>
>
> Regards,
>
> On Sun, Jul 19, 2020, 06:52 Brian Westerman 
> 
> wrote:
>
>> You can set up some of the ports to be local VTAM terminals, then 
>> you can use VISTA (or any 3270 emulator) to connect into the ICC 
>> port 3270, and use the LUNAME of the 3270 you defined as a local 
>> 3270 terminal. Since you can have over 100 terminals per port, 
>> making them all os consoles is a waste, so having a bunch of them 
>> as local 3270's that 

Re: AZD messages?

[Lloyd Fuller]

Is localhost defined?

Sent from my iPad

> On Jun 8, 2020, at 8:16 AM, Sean Gleann  wrote:
> 
> Thanks for the hint about thoroughly checking output, Michael.
> I went back and studied all the saved outputs, hoping to find something
> that might be helpful.
> In the event, there were no indications of such problems - no error
> messages or non-zero return codes - but it's as well to be sure.
> 
> Can I ask you for more information regarding what you see with the '3.2
> Retrieve Workflow version' step, please?
> For me, I get to the point of clicking 'Perform' on this step, and I see
> that z/OSMF is about to use the REST API with the request
> 
> https://localhost:10443/zosmf/workflow/rest/1.0/workflows/3ca56936-9a81-48a0-94d9-84e28ee2d842
> :
> 
> Clicking 'Next' on this results in:
> 
> IZUWFE: The request cannot be completed because an error occurred. The
> following error data is returned: "EDC8128I Connection refused.
> (errno2=0x76630291) (Connection refused)"
> 
> and so I am forced to click on 'Finish' if I am to proceed.
> What do you see during this sequence?
> 
> I suspect that it's the 'localhost:10443' bit that is the root of the
> problem, but I'm unsure how to circumvent it, or even to correct the
> problem.
> As I said earlier in this thread, I'm working through a tunnelled SSH
> connection to access my z/OSMF. In the main, this is working quite happily.
> That connection definition associates my desktop system's local port 10443
> with the hosts systems' 10443, and the URL I use to access z/OSMF is
> https://localhost:10443/zosmf.
> So I'm at a bit of a loss in understanding why the connection should be
> refused.
> 
> Regards
> Sean
> 
> 
>> On Fri, 5 Jun 2020 at 04:08, Michael Babcock  wrote:
>> 
>> Oh and beware, just because the Verify Feature Bits job (and a couple of
>> others) gets a zero condition code doesn’t mean it executed successfully.
>> You have to check STDERR and STDOUT tabs.  Mine always gets a syntax
>> error.
>> 
>>> On Thu, Jun 4, 2020 at 10:05 AM Sean Gleann  wrote:
>>> 
>>> It's been really quite a troublesome effort for me, Michael, but I guess
>>> it's true to say that most of the problems are down to my rudimentary
>>> knowledge of TCPIP and networking in general.
>>> For various reasons, I have to use a tunnelled connection through to the
>>> z/OS guest, and that makes things a bit more interesting.
>>> The 'Getting Started' redbook (SG24-8457-00) has been my sole point of
>>> reference all the way through, and yeah, it's OK - up to point. it
>> doesn't
>>> cover the tunnelling complication, naturally, and there are some very
>> poor
>>> typos to take into account.
>>> As for the Workload Provisioning process in z/OSMF - after you've
>> specified
>>> a bunch of parameters, it's just a JCL generator/job submitter/checker
>> with
>>> a couple of z/OSMF-specific bits thrown in.
>>> During the initial parameter specification phase I had considerable
>>> difficulty at the point of specifying the RSA key, but eventually got it
>>> right.
>>> Step 3.2 in the process - where some sort of version information is
>> looked
>>> for - has always failed for me. I've never been able to make it work as
>>> expected and have had to force it to a 'complete' state by clicking the
>>> 'Finish' button.
>>> 
>>> I tried to adapt the process detailed in the redbook to suit our security
>>> set-up, but the result never worked. In the end, I followed the procedure
>>> to the letter, and created the ZCXxxx users and groups in RACF as
>>> specified.
>>> Result - I've finally got a working container that I can log in to. The
>>> next step according to the redbook is to download an image from
>>> hub.docker.com, but when I try the specified command - 'docker pull
>> nginx'
>>> - the container tries to go to registry-1.docker/.io/v2 - which isn't
>>> specified anywhere in the parameter files created by z/OSMF  - and it
>> times
>>> out.
>>> I've added suitable mods to \etc\hosts, \etc\ipnodes and to TCPIP.HOSTS,
>>> messed around with DNS specifications and I've commented out the IPSEC
>>> statements in the TCPIP PROFILE parameters (thank gawd for sandbox
>>> systems!). Nothing along those lines has altered the situation.
>>> Now, I'm waiting for our company networking guys to suggest other things
>> to
>>> try.
>>> 
>>> Good luck with your efforts, Michael.
>>> I hope you have a smoother ride than I have had so far.
>>> 
>>> Sean
>>> 
>>> On Thu, 4 Jun 2020 at 15:32, Michael Babcock 
>>> wrote:
>>> 
 Sean,
 
 I’m just going through the provisioning process now.  Any gotchas that
>>> you
 care to share?
 
 On Thu, Jun 4, 2020 at 5:30 AM Sean Gleann 
>>> wrote:
 
> Thanks, Gadi.
> Yes, there are GLZ messages associated with these AZDs, but all they
>> do
 is
> identify the stored failure data.
> 
> It's all somewhat moot now. I tried to /P the container, and got told
>>> the
> task was non-cancellable.
> Eventually I resorted 

Re: PARM= vs PARMDD= and symbol substitution

[Lloyd Fuller]

I do not know about VISAM, but 360 FFS used variable length QISAM and BISAM in 
the late 60s and early 70s.  The DOD used a lot of it.  Been there and learned 
assembler to support applications using it.

Lloyd

Sent from my iPad

> On Mar 31, 2020, at 8:42 PM, Seymour J Metz  wrote:
> 
> There was also a VISAM in TSS.
> 
> 
> --
> 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: Tuesday, March 31, 2020 4:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PARM= vs PARMDD= and symbol substitution
> 
> There were apparently several "VISAMs" around, because OCCURS DEPENDING is 
> such a basic feature of COBOL but RECFM=V was not supported by ISAM.
> 
> I had a client (not FSA but interestingly also in the financial package 
> software business) that had its own homegrown (AFAIK) VISAM. It used short 
> fixed-length ISAM records with keys and a pointer to variable length BDAM 
> records. I remember it because I wrote some software that utilized it (but I 
> was not at all involved in its development).
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tony Thigpen
> Sent: Monday, March 30, 2020 8:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PARM= vs PARMDD= and symbol substitution
> 
> Digging back into my mind for data from 1983:
> 
> Third National of Nashville (TNB) ran a bank data processing site in
> Florence, AL. The main bank there was First National (FNB). TNB decided
> to close up shop in Florence so FNB took their data processing in-house.
> FNB did not have a data processing department before this.
> 
> I was one of three programmers hired by FNB for this new department. The
> complete staff from the TNB site was hired by FNB with the permission of
> TNB as the operational staff.
> 
> We converted the data from TNB in-house written code to a set of
> programs from an Orlando base software provider Financial Software of
> America (FSA), later bought by UCC to become part of the new UCCEL
> company, later acquired by CA and so forth. The one system FSA did not
> have yet, but we needed, was a loan processing package. (They were
> writing it, but it was not yet available.)
> 
> TNB decided to give FNB the complete source for their Loan System. It
> was in assembler and I was tasked to convert it from MVS (or what ever
> at that time) to DOS/SIPO (predecessor to z/VSE).
> 
> What I found was interesting. The system used something called VISAM, or
> "variable length ISAM". It was not a big problem to convert it to VSAM,
> but here is the story I got about VISAM.
> 
> --
> 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: Merge Tool for git for z/OS?

[Lloyd Fuller]

Yes.    Use XEDIT and CMSUPDTE.  They work well, but are VM only,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Tuesday, December 03, 2019 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Merge Tool for git for z/OS?

Lionel,

Many years ago we developed a change management tool for an Israeli client that 
ued CA datacom based on SCLM. We used to perform merge by comparing the two 
versions (Ispf SUPERC). When configured it is a smart tool that tels you the 
location, if it is new line or update inline, etc.  Try this approach. I may 
look at my archives to see if I still have this module.

ITschak

On Tue, Dec 3, 2019 at 4:33 PM Lionel B Dyck  wrote:

> What is available to be used for the mergetool for git on z/OS?
>
>
>
> Thanks
>
>
>
> I've looked using google/bing without success.
>
>
>
>
>
> Lionel B. Dyck <
> Website:   http://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


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

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

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

Re: QWS3270 - Numbers are not recognized

[Lloyd Fuller]

In addition to all of the other suggestions.  Check which terminal type you are 
emulating.  Some of the emulators allow you to specify older terminal types 
that do NOT have numerics.  Also check what the terminal type is on screen 0 of 
ISPF.  Maybe you are defaulting to one of the 3277 types or have data set on 
screen format.

Lloyd



 From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, April 11, 2014 8:09 AM
Subject: Re: QWS3270 - Numbers are not recognized
  

Christian D wrote:

I am using QWS3270 emulator. QWS3270 emulator is not allowing me to type the 
Numbers but I am able to type the alphabets. For example if my ID is CHRIS01, 
Its not allowing me to Type '01'

Assuming the keyboard is really working (in other applications like NotePad) 
and you're sure about the 'Num Lock' toggle setting, on what screen (logmode / 
logon screen / etc) is the problem? If you enter a numeric key, does the 
cursor moves on or stays in one place just there?

You're not using a macro / script / keyboard logger?

I even resetted the keymap to default but still the problem persist.

Do you actually means 'remap keyboard layout' ? It reminds me some years ago 
that I had to remap the keyboards map based on keyboard layout (101-key or 
104-key or others keys) when we got new computers.

Could someone point me to the right direction on the above.

Also assuming the right (latest) version of QWS3270 is running on your 
machine, did you review the code page / characterset of your system/emulator? 

Did your emulator/keyboard worked properly previously? Are you alone or are 
others having the same problems?

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



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

Re: Metal C vs. HLASM - for C callable subroutine?

[Lloyd Fuller]

How much cross-platform C code do you do?  With Metal C, it is possible to use 
cross-platform code in z/OS environments that do not allow LE.
 
In my opinion Metal C is VERY useful.
 
Lloyd



 From: Gord Tomlin gt.ibm.li...@actionsoftware.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, March 25, 2014 11:38 PM
Subject: Re: Metal C vs. HLASM - for C callable subroutine?
  

On 2014-03-25 22:11, David Crayford wrote:
 I find that I rarely need Metal/C. What I do want to do is inline
 assembler into LE code.

I have found Metal to be useful in a few situations where it is 
desirable to have a self-contained program with inline Assembler and no 
dependencies on the LE runtime. Admittedly these occasions are not that 
common; in my experience it's not very often that a situation presents 
itself where C with inline Assembler is preferable to pure Assembler.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507


--
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: building text messages with substitutions

[Lloyd Fuller]

You can call a Metal C program with just a simple stack.
 
If you want to use the library (like sprintf), you need to do the __cinit and 
__cterm calls.  There is a C structure file that you need to fill out to call 
__cinit and I believe the only parameter is the address of that structure.  I 
did not find a DSECT describing the structure only the H file.
 
So what I did was write a small C program that builds the structure on its 
stack, and then calls __cinit to build the C stack/heap/etc.  That C program 
also loads R12 with the address of the heap as described in the Metal C program 
and any other C programs that are to be used are compiled with the reserve R12 
option.
 
My logic is for doing all of the C work at one time and NOT for making sprintf 
available to an assembler program.  But you should still be able to have 
similar logic and just write 2 C programs:  one to do the __cinit and one to do 
the __cterm.  You would have to maintain the original C stack that you use to 
call the first program until after the __cterm is finished.
 
For initializing the structure, I just copied the example in the Metal C 
programming guide and modified to suit my needs.
 
Lloyd



 From: Donald Russell russell@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 14, 2014 1:51 AM
Subject: Re: building text messages with substitutions
  

I've been looking for doc on how to do this It seems I need to call
__cinit to set up a C environment, then I can call sprintf and finally
__cterm to terminate the C environment

Sounds simple enough but I can't find what the parameter list looks like
for those calls... Do I actually LOAD/DELETE those module names? I thought
module names had to start with letter or national only.

I don't want to write the whole thing in C, and use the occasional
assembler macro, I have an assembler program and want to use sprintf to
create a string of text with various substitutions in it.

Once I have it all done I'm happy to share what I did...

Cheers



On Thursday, March 13, 2014, Tony Harminc t...@harminc.net wrote:

 On 13 March 2014 14:53, Donald Russell russell@gmail.comjavascript:;
 wrote:
  Holly Smokes! Metal C looks perfect THANKS! :-) I just need sprintf
 features

 Please keep us posted with your results. I haven't actually tried it,
 but I've thought about it a few times - enough to look at the calling
 and environment conventions. They look pretty easy to meet, but stack
 space requirements are large in comparison to typical assembler
 programs. If you're calling only sprintf you could presumably reuse or
 otherwise share the stack, i.e. what you pass to the function
 wouldn't have to be an actual stack that your program linkage
 conventions use.

 Tony H.

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



-- 
Sent from iPhone Gmail Mobile


--
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: Checking Years( was - Re: Storage Obtain .....)

[Lloyd Fuller]

Actually NOMAD.  The dates can be stored in NOMAD internal databases, IMS, 
IDMS, DB2, SQL/VM.

And the suggestion to use the input window for dates dated to 1979 or so.  It 
was actually implemented in the early 1990s.
 
Lloyd
 
 


 From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, February 14, 2014 8:29 AM
Subject: Checking Years( was - Re: Storage Obtain .)
  

Lloyd Fuller wrote:

Actually in some products quite a lot. 

Some other applications like your example: 

1. Astronomy: (Calculating position/movements of space things from x 
year/month/day/etc to y year/etc...)
2. Statistics and Mathematics: Census processing of population of people, 
animals, disease growth, etc. Only for really bored students. ;-D
3. Deeds registration: Registration of property.
4. Laws: Writing down laws and refering to year when past laws were made.

Internal dates went from 1/1/1600 to a time VERY long in the future (year 
1 something).

It depends on language used.

In fact, after discussion we even implemented the leap year calendar in the 
past by using negative dates.

In what format? (COBOL, Assembler, other?) Just curious if you dont mind, 
please?


Kees Vernooij wrote:

If I only had a Euro for each program that has this code and will not live 
until 2100...

From your industry, you probably know that Boeing was already implementing Y2K 
fixes since about 1990 [1] due to long ordering period of about 12 years and 
more of aeroplanes from various clients.

Groete / Greetings
Elardus Engelbrecht

[1] - I can't remember the exact year but it was certainly in those [ flying 
;-D ] times. I would be grateful if someone can post a source confirming it. 
:-)

I warned my management in around 1996 about the upcoming Y2K monster and I 
used the Boeing example as part of my motivation. But as you probably guessed 
it, the management got active around 1998 and then only because IBM was 
getting paranoid ( shame! ;-D ) about that undying Y2K monster. ;-)
--
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: Storage Obtain .....

[Lloyd Fuller]

Actually in some products quite a lot.  A product that I worked on in the past 
is used by several banks including people who regularly post here and on the VM 
list.  Many of those banks used the product for various things including escrow 
accounts which are VERY long lived.  In several cases that I know about the 
escrow accounts were set up before 1900 so when they were computerized, the 
date algorithms had to handle a non-leap year 00 year.  Worked fine.  Some of 
the escrow accounts go past 2100 and those are working fine also.
 
For that same product the only Y2K issues were making sure that computer forms 
that only allowed two digits for years would be able to work.  Hence a century 
windor for input only was implemented.  Internal dates went from 1/1/1600 to a 
time VERY long in the future (year 1 something).  In fact, after discussion 
we even implemented the leap year calendar in the past by using negative dates. 
 In most of the cases that users wanted that, only year matter, not necessarily 
month and day so things worked fine.
 
Lloyd
 


 From: Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, February 12, 2014 9:40 AM
Subject: Re: Storage Obtain .
  

A similar one: 
How to determine a leap year:
Q1:Is year a multiple of 4?
If yes: Q2: is year a multiple of 100?
If yes: Q3: is year a multiple of 400?
If yes: it is a leapyear.
(skipping the 'If No' branches).

Q2 and Q3 will start making sense for the first time in the history of
computer programming in the year 2100. Until then Q1 would have been
sufficient.
How much power has been put into executing instructions to answer Q2 and
Q3? 
If I only had a Euro for each program that has this code and will not
live until 2100...

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gerhard Postpischil
Sent: Wednesday, February 12, 2014 15:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

On 2/12/2014 8:50 AM, Jim Thomas wrote:

           XR    R14,R14
           XR    R15,R15
           L     R1,=AL4(WORKAREA)
           MVCL  R0,R14

Minor quibble - when the from length is zero, the from register is never
referenced nor inspected, so the XR R14,R14 is extraneous. (If I had a
dollar for every time I've seen this, I could retire g).

Gerhard Postpischil
Bradford, Vermont

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

For information, services and offers, please visit our web site: 
http://www.klm.com/. This e-mail and any attachment may contain confidential 
and privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may 
be disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

            

--
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: Disposal of storage devices/media

[Lloyd Fuller]

In addition to the possibility of decryption, there is the issue that you need 
to get the disks from the array back into the same order they were in the 
original array with the same type and level of the disk controller.  This may 
be less of a problem with mainframe disk arrays, but it can really be an issue 
trying to recover anything from an x86 disk array:  there are several different 
arrays with different level of software and unless you get the disks into the 
same order with the same level of software on the same controller, it is next 
to impossible to recover anything useful even if the data is un-encrypted or 
just lightly encrypted (like DES).
 
Lloyd



 From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, January 20, 2014 5:53 PM
Subject: Re: Disposal of storage devices/media
  

John Gilmore wrote:
and I have two comments.

First. the professional cryptographers of my acquaintance avoid
assumptions about the encodings of the encrypted documents they are
examining.  They regard this as an empirical question to be answered
empirically, and they have powerful statistical methods for answering
such questions available to them

There are ways to suggest results, sure. My point, however, was that with NO 
idea what you're looking at, the Codex and a pr0n JPG are equally of value. 
And when you have no idea, applying those statistical methods becomes yet 
another drain on resources and time...

Second, the notion that DES (56 bit key strength) is adequate to any
serious encryption task will delight the NSA, the Chinese, and others
of that ilk.

Nor did I suggest that DES is adequate. Please reread.

...phsiii

--
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: pax, ddnames and _BPX_SHAREAS

[Lloyd Fuller]

Look at your DSName.  It is not a valid MVS dataset name:  too many characters 
without a period.

Lloyd



 From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, January 17, 2014 9:59 AM
Subject: Re: pax, ddnames and _BPX_SHAREAS
  

van der Grijn, Bart (B) wrote: 

Thanks Elardus,  

You're welcome! :-)

z/OS in question is z/OS 1.12 

Ok.

Should have clarified this in my original note, but I'm not trying to write 
to a 'unix' file, I'm trying to write to a MVS dataset allocated to a DDName. 
Using a dataset name in the pax command works fine, but I want to use a 
DDName so that I can code RELEASE or write to tape.  

Then I suspect the ALLOC command is not working 100% with that keyword 
combination. Could you try out TRACE in your REXX program to see what is 
happening when REXX is trying to execute ALLOC command? 

If ALLOC is working (you see the DD is allocated at all), then I'm at lost.

HTH! 

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




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

Re: pax, ddnames and _BPX_SHAREAS

[Lloyd Fuller]

Why do you need to use DD:... for pax?  If you are going to use a REXX variable 
in the DSN parameter, use the REXX variable in the pax command?  The use of a 
DSN in the pax command is documented and supported.  I have not tried to use it 
from REXX, but I have used it from the OMVS command line without problem 
(except syntax issues getting the quotes and double quotes correct).

Lloyd



 From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, January 17, 2014 2:41 PM
Subject: Re: pax, ddnames and _BPX_SHAREAS
  

On 2014-01-17 07:43, van der Grijn, Bart (B) wrote:
 
 z/OS in question is z/OS 1.12
 Should have clarified this in my original note, but I'm not trying to write 
 to a 'unix' file, I'm trying to write to a MVS dataset allocated to a 
 DDName. Using a dataset name in the pax command works fine, but I want to 
 use a DDName so that I can code RELEASE or write to tape. 
  
Even if what you're trying to do happens to succeed, it's
unsupported, and IBM will give you no assistance if it fails
in the future.

I've done similar things, using only supported (I believe)
facilities with a Rexx EXEC:
        ...
    say BPXWDYN( 'alloc dd(SYSUT2) dsn(...) ...attributes...' )
    say BPXWDYN( 'alloc dd(SYSUT1) filedata(BINARY) pathopts(ORDONLY)' ,
        'path(''/dev/fd/0'') [attributes compatible with SYSUT2]' )
    address ATTCHMVS 'IEBGENER'
        ...
and piping from pax to that EXEC.  It can also be done in a single
EXEC using SYSCALL 'pipe' and SYSCALL 'spawn' for pax and ATTCHMVS
for IEBGENER.

Of course, it's easier with Co:Z, but ISVs, for example, can't rely
on customers' having Co:Z.

-- 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: Exit interfaces and module attributes (was: Base-less ...)

[Lloyd Fuller]

The problem with using LE programs in exits is the environment in which the 
exits run.  Many run in cross-memory and/or SRB mode so SVCs are not allowed 
and LE functions use SVCs instead of instructions in many cases (i.e., the date 
and time routines).

Lloyd



 From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, December 6, 2013 1:33 PM
Subject: Re: Exit interfaces and module attributes (was: Base-less ...)
  

Gil,

I appreciate what you said. In the perfect world ( wasn't that a Blondie 
song), the API calls, linkage between languages would be well documented and 
extensive samples.  But life and code and development sometimes are messy, so 
experimentation is necessary. I ask questions, because like many of my 
colleagues I don't have all the answers, especially when I looking at a new 
design or concept. Times have changed no more PLMs or source to look at ...so 
here we are...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


 On Dec 6, 2013, at 1:22 PM, Paul Gilmartin paulgboul...@aim.com wrote:
 
 This thread seems to nave diverged into ASSEMBLER-LIST and
 IBM-MAIN.  I'm extending the topic.  A contributor said in
 ASSEMBLER LIST:
 
    ... I am trying to decide to convert it to baseless or write an
    assembler stub and redo the exit in C.
 
 In a perfect universe, a stub would be needless.
 
 About 40 years ago, before I had any OS/360 exposure, an Expert
 boasted to me that the calling conventions of OS were absolutely
 homogeneous -- a subroutine in any language could be called from
 any other language, or as a main program alike.  (I was skeptical --
 I asked, LISP?  SNOBOL4?  My mentor replied, Of course!)
 
 What have we lost?
 
 With XA, the facility was mostly preserved: CSECTs were marked
 AMODE 24 or AMODE 31; would be entered in the correct AMODE,
 and would return to a caller in the caller's mode via BSM.
 
 So, daydream/wishlist item:  It should be made possible to mark
 a load module as LE-mode so ATTACH or an EXIT interface would
 seamlessly enter an exit written in LE C (not just Metal C) and the
 exit return smoothly.
 
 Would Metal C remove the need for an Assembler stub?
 
 -- 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: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's?

[Lloyd Fuller]

Note that my COBOL sort days are long ago so what I am saying may no longer be 
true.  What used to happen with E35 is that SORT did NOT create the final 
sortout file:  the program was given the sorted records from the last merge 
set.  So you saved, at a minimum, that set of I/O.  Each COBOL return from the 
E35 exit was really the equivalent of a write to the sortout file from the sort 
standpoint.
 
If I remember correctly, there was also I/O savings using E15, but I do not 
remember what that savings was.
 
Lloyd



 From: John Gilmore jwgli...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, November 25, 2013 11:49 AM
Subject: Re: Has anyone measured CPU savings using external SORT's vs internal 
(COBOL) SORT's?
  

The scheme you are considering is---if I understand it---that of

read prepin==|preprocess|==write sortin
read sortin==|external sort|==write sortout
read sortout==|postprocess|==write postout

It involves six i/o operations per record, and it thus has little to
recommend it.

If instead you use Exits 15 and 35 of the external sort, either DFSORT
or SYNCSORT,
having the preprocessor hand unsorted records to the external sort
using Exit 15 and the postprocessor take sorted records back from the
external sort at Exit 35, all in one job step, you can save four of
these I/O operations.

This second scheme is in my experience a very muich better one than
the one you are considering.   It gives you all of the benefits of
using the external sort and avoids gratuitous I/O.

Note that the highly efficient i/o operations of SYNCSORT and DFSORT
are their internal ones.  They must and do use access methods to read
sortin and write sortout.  They do of course use these access methods
more efficiently than many/most COBOL programs, but the big i/o
savings are elsewhere.

John Gilmore, Ashland, MA 01721 - USA

--
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: using ./Configure to generate listing files

[Lloyd Fuller]

That is part of why I use a separate shell script to do this.  I parse the 
parameters and pull the filename into a variable using sed options.  Then I can 
build a listing file name and specify it in the actual c89/xlc command.
For example, this builds a C listing filename:
 
sname3=`echo $argshift1|sed 's/\.o/.lc/g'` 
 
Lloyd
 


 From: Janet Graff janet.gr...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, November 5, 2013 2:15 PM
Subject: Re: using ./Configure to generate listing files
  

The -Wc,LIST(filename) option would work fine to indicate that I want a 
listing file.  But without a file name it defaults to STDOUT.  The specific 
filename doesn't adjust for different source code files.  Is there a 
replacement variable for ./Configure that says use the source code file name 
so that I can add something like -Wc,LIST(${source}) to my options and get a 
seperate listing file for each source file?

Janet

--
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: using ./Configure to generate listing files

[Lloyd Fuller]

Janet,
 
When I have some options that are not part of the normal, I specify a different 
shell script for compiling (like xlc64.sh for example), and specify that as the 
compiler in ./configure or make or whatever.  Then that shell script calls 
the compiler once it has set up things like I want.
 
This allows me to test new options without breaking existing things:  just 
comment the real compiler name and specify the new one.  Then to reverse 
things, uncomment the real compiler and comment the new one.
 
Lloyd



 From: Janet Graff janet.gr...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, November 5, 2013 11:46 AM
Subject: Re: using ./Configure to generate listing files
  

Kirk,

Yes!  That excellent thread is what enabled me to get as far as I did and 
produce my needed libcrypto.a library.

I've been through that thread multiple times in the last three weeks but I 
don't recall a discussion of changing the ./Configure settings to produce 
listing files for every source code module compiled during the make phase.

Do you know that there is a reference to listing files in that thread (in 
which case I will go back through the thread again line by line) or was that a 
reference to general topic equivalence?

Thanks!
Janet

--
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: Google F1 was: Re: MongoDB

[Lloyd Fuller]

And this product is called NOMAD from Select Business Solutions.  It has only 
been available since 1976 or thereabouts.
 
And you can even MIX hierarchical and RDBMS if you want.
 
Geez.  Another wheel reinvented.
 
Lloyd



 From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, October 17, 2013 1:10 AM
Subject: Google F1 was: Re: MongoDB
  

The brainiacs over at google have invented a novel hybrid data base for their 
Ads business http://research.google.com/pubs/pub38125.html. It supports 
hierarchical schemas.

Quote With F1, we have built a novel hybrid system that combines the 
scalability, fault tolerance, transparent sharding, and cost benefits so far 
available only in “NoSQL” systems with the usability, familiarity, and 
transactional guarantees expected from an RDBMS.



On 16/10/2013 12:27 PM, Ze'ev Atlas wrote:
 Dave Caryford said: It is not, however, a drop in replacement for 
 traditional transactional
 data bases.
 
 You are correct, it IS not and SHOULD never be used as a transnational 
 database.  It is however, a great (read better, more natural, more scalable, 
 etc.) replacement to warehoses with star schemas and the like.
 
 Conceptually, navigating MongoDB is similar to navigating IMS and IDMS and 
 is totally different then using relational sets (using SQL)
 
 ZA
 
 --
 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: Quote on Slashdot.org

[Lloyd Fuller]

Actually in some circles ADA is the ONLY language.  Talk to the embedded 
systems people.  Unless things have changed quite a bit in the past 6 years or 
so, ADA is heavily used in airplanes, etc.

Lloyd



 From: John McKown john.archie.mck...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Sunday, September 29, 2013 9:45 PM
Subject: Re: Quote on Slashdot.org
  

I guess that good to know. And I can sort of see it, from what little I
remember of Turbo Pascal and Delphi, and a brief flirtation with Modula II.
I've only had the GCC Ada compiler, and I don't really know how standard it
is. But I don't think that Ada took off any better than PL/I did. So much
for either of them being the one language to rule them all. On z/OS,
COBOL still seems to be King (at least in terms of number of lines of
customer code). On UNIX, C/C++ seems to still the be the main winner, but
with a large retinue of others (Perl, Python, Ruby, ...). On Windows, well
I plead ignorance and apathy: I don't know and I don't care. I despise
MS-Windows. As is likely well known by now.


On Sat, Sep 28, 2013 at 8:46 PM, Shmuel Metz (Seymour J.) 
shmuel+ibm-m...@patriot.net wrote:

 In
 caajsdjhovrtxbmxk+bhdqwookpp7_h3z4mtthsyoyzyjfnj...@mail.gmail.com,
 on 09/26/2013
    at 09:10 AM, John McKown john.archie.mck...@gmail.com said:

 Ada is PL/I trying to be Smalltalk. -- Codoso diBlini

 Actually Ada comes from the Pascal tradition and is quite at variance
 with PL/I.

 --
      Shmuel (Seymour J.) Metz, SysProg and JOAT
      ISO position; see http://patriot.net/~shmuel/resume/brief.html
 We don't care. We don't have to care, we're Congress.
 (S877: The Shut up and Eat Your spam act of 2003)

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




-- 
I have _not_ lost my mind! It is backed up on a flash drive somewhere.

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: ICSF Without Crypto Card?

[Lloyd Fuller]

No.  The crypto cards preceded the z machines.  They were available as part of 
the 9672s.  There are several different ones with slightly different 
capabilities.  They are all on the I/O bus so they are slightly slower than the 
CPACF hardware for the same operation, but they may be more secure depending 
upon use.
 
CPACF is what was added with the z990.  This is a specialized processor that 
you access by issuing specific instructions (the K... ones).  This processor 
has been updated with almost every new z machine.  How many CPACF processors 
are available also varies by model.
 
Lloyd



 From: R.S. r.skoru...@bremultibank.com.pl
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, September 19, 2013 3:55 PM
Subject: Re: ICSF Without Crypto Card?
  

W dniu 2013-09-19 17:04, Tiegox QQ pisze:
 Are coprocessors supposed resided in CPU book?crypto card is different.

Since z990 (approx. 10 years) you can have crypto cards - the cards are
similar in format to ESCON, FICON or OSA cards.
The card is named CryptoExpress. The card inside contains whole computer
with strong CPU and specialized coprocessor. Such card is called
coprocessor.
Form the other hand, inside the BOOK, inside the MCM (multi-chip-module)
there is CPACF chip (actually it's share between 2 CPs depending on the
CPC model).
It's also coprocessor, but usually the name is not used.

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

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.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.2013 r. kapita　 zak　adowy BRE Banku SA (w ca　o　ci 
wp　acony) wynosi 168.555.904 z　otych.


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

[Lloyd Fuller]

It depends upon the manufacturer of the paper.  Most did not, but I saw a few 
boxes that did.
 
Lloyd



 From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, July 18, 2013 5:31 PM
Subject: Greenbar
  

Settle a debate: did greenbar paper have the bars on both sides of the paper? 
A colleague and I remember it differently (I won't tell you which way I'm 
arguing, lest I tempt anyone).

Once we have an answer, I'll explain how this came up!

...phsiii

--
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: Auditing vendor source code

[Lloyd Fuller]

Actually, US companies have also stolen software.  I will not go into details, 
but it has happened at a company that I worked for.  One of their customers 
stole the software for at least a couple of years until we changed how our 
license key was generated.
 
Lloyd


- Original Message -
 From: Phil Smith p...@voltage.com
 To: IBM-MAIN@LISTSERV.UA.EDU
 Cc: 
 Sent: Wednesday, June 19, 2013 4:10 PM
 Subject: Re: Auditing vendor source code
 
 Ed Jaffe wrote:
 We once had a situation in which a foreign distributor had numerous 
 off-book customers using our software illegally. It's not clear 
 whether the customers actually realized they were pirating the software. In 
 any 
 case, the implementation of so-called keys put a stop to all 
 subsequent attempts at deliberate or accidental misuse (as far as we know, of 
 course)...
 
 As you note, as far as we know. If the distributor was that 
 dishonest, I assume this meant that the US folks had to handle all keys? I 
 bet 
 that was fun...lots of off-hours calls!
 
 Yeah, the only argument I've ever heard that had any teeth was related to 
 them untrustworthy furriners. Though I suspect it's less that foreign 
 companies are less trustworthy than that American companies are more afraid 
 of 
 litigation...
 
 --
 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: XMIT Manager

[Lloyd Fuller]

The problem is not the executable.  The real 64-bit problem is in the 
installer.  The installer that is used with XMIT only installs to 32-bit based 
Windows.  


If someone updated the installer to a newer version, things would be fine.

So copying the XMIT directory works except you don't get all of the links done.

Lloyd



- Original Message 
From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, May 17, 2013 10:01:11 AM
Subject: Re: XMIT Manager

I run it on windows 7 .64 bit no problem...make sure it's in the non 64 bit 
program folder

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On May 17, 2013, at 1:42 AM, mf db dbajava...@gmail.com wrote:

 Hello,
 
 I am currently not able to install XMIT manager on my system. The error
 says that the software is not compatible with my PC(64 BIT).
 
 Does anyone find a XMIT manager which is compatible with 64 bit PC.
 
 Peter
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Business politics and software development

[Lloyd Fuller]

You have to look at where C was originally designed to run.  It was designed 
for 
the DEC PDP8.  Those were SMALL in resources machines.  Later versions of C 
were 
built on the PDP11s, but Richie and crew started out on the PDP8.  And, yes, C 
was designed to be a middle-level language.

During that time, new CPU designs were popping up all over the place.  The 
problem was moving things to them:  things like compilers and assemblers as 
well 
as applications that were written in those compiler languages.  So the thought 
was to design a language that would be quickly portable and easy to write for a 
new platform.

Lloyd



- Original Message 
From: John Gilmore jwgli...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, May 17, 2013 9:02:30 AM
Subject: Re: Business politics and software development

John McKown's notion that C is a middle-level language has merit.

In some respects it is.  Better, perhaps, it can be used like assembly
language; and when it is I have heard the results described as having
all of the expressive power and all of the portability of assembly
language.

In the hands of quondam COBOL programmers it can also, unsurprisingly,
be very COBOL-like.

John Gilmore, Ashland, MA 01721 - USA

--
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: Return codes

[Lloyd Fuller]

And then you have C / C++ that uses RC=1 as the good return code.  Any other is 
bad.

Lloyd



- Original Message 
From: Gerhard Postpischil gerh...@valley.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, May 8, 2013 2:41:51 PM
Subject: Re: Return codes

On 5/8/2013 2:14 PM, Elardus Engelbrecht wrote:
 Another possible reason is - same return codes standards are also
 used for macros (system services) and system exits. So one set of
 convention is used to pass info including RC from one module to
 another.

While I prefer the branch table conjecture, I have a number of programs that 
use 
a three-way branch (e.g., CH R15,=H'8') to save, what in the good old days was 
expensive storage. As for range checking, my all-time favorite is CL (e.g., CL 
R15,=F'16' / BH) that catches both negative and excessive values.

IBM has complicated matters, starting with BPAM macros, by adding more return 
codes. I would have preferred the old 0,4,8,12 paradigm, with R0 set to a 
reason 
code.

Gerhard Postpischil
Bradford, Vermont

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

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

Re: OT - What is the proper term for K notation?

[Lloyd Fuller]

Not sure.  I was just talking one time to one of the military people that were 
involved with Univac and the university (Oregon State, I think).  He mentioned 
that they had experimented with it.  And from the time frame you are probably 
correct that it was transistors rather than IC's.

Lloyd



- Original Message 
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, May 8, 2013 4:28:58 PM
Subject: Re: OT - What is the proper term for K notation?

In 1367845369.9745.yahoomai...@web181401.mail.ne1.yahoo.com, on
05/06/2013
   at 06:02 AM, Lloyd Fuller leful...@sbcglobal.net said:

Actually, Univac played with it back in the 1960s/1970s.

Any ternary logic or memory in the 1960's was probably implemented
with discrete transistors rather than with IC's.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: as OpenMVS assembler always gives ASMA935U

[Lloyd Fuller]

Or just specify the GOFF (-mGOFF) option which forces OBJECT and is MUCH more 
useful when combining things with C.

Lloyd



- Original Message 
From: J R jayare...@hotmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Mon, May 6, 2013 7:13:13 AM
Subject: Re: as OpenMVS assembler always gives ASMA935U

SYSPUNCH is required for the assembler DECK option.  
SYSLIN is required for the assembler OBJECT option.  

Since an earlier post of yours mentioned pseudo JCL contained a SYSLIN 
statement, passing assembler options NODECK,OBJECT (in addition to other 
options that you are already using) may fix your problem.  


=
=
 Date: Mon, 6 May 2013 02:11:17 -0500
 From: e.thij...@chello.nl
 Subject: Re: as OpenMVS assembler always gives ASMA935U
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Thanks, this gives me one extra line:
 IEC1301 SYSPUNCH DD STATEMENT MISSING
 
 This looks like some setup or configuration problem to me, since I am not 
running any JCL...
 I'll have to refer this to the system administrator.
 
 There are no other files or logs, as far as I can see, containing any as 
output.
 
 Thanks,
 Etienne
 
 On Fri, 3 May 2013 14:55:16 -0500, Kirk Wolf k...@dovetail.com wrote:
 
 FWIW, when I'm using the z/OS Unix shell, I usually set:
 
 export _BPXK_JOBLOG=STDERR
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: OT - What is the proper term for K notation?

[Lloyd Fuller]

Actually, Univac played with it back in the 1960s/1970s.  I believe they were 
working with someone from OSU.  As far as I know, they never marketed a product 
with it, but it was at least researched.

Lloyd



- Original Message 
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Mon, May 6, 2013 8:00:34 AM
Subject: Re: OT - What is the proper term for K notation?

In
cajtoo5_ed5s0uqief8aytixs1-ey5fcda-_xcz3k3spqyjn...@mail.gmail.com,
on 05/03/2013
   at 05:22 PM, Mike Schwab mike.a.sch...@gmail.com said:

When you build a memory chip, the input is X number of address bits,

Hasn't anybody built ternary memory?

Silly wabbit, trits are for kids.

When you build a computer disk, you can to return any number of 512
byte sectors,

Sectors? We don't need no stinking sectors. The IBM 1301, 1302 and
23xx disks did not have sectors.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Crypto Facility performance.

[Lloyd Fuller]

Yes, but not protected key.

Lloyd



- Original Message 
From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, April 27, 2013 2:27:59 PM
Subject: Re: Crypto Facility performance.

Guys,

I have a question , can a vendor use crypto services on Z without the crypto 
Card ?

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 27, 2013, at 2:07 PM, Anne  Lynn Wheeler l...@garlic.com wrote:

 paulgboul...@aim.com (Paul Gilmartin) writes:
 This is similar to credit card skimmers in ATMs.  It's *theoretically* 
possible
 but entirely implausible that some such person replace the entire z with a
 counterfeit look-alike ...
 
 early in the century there was a large pilot deployment of EMV chip
 credit cards in the US ... with an enormous fatal flaw ... even tho
 somebody had pointed out the fatal flaw before the deployment ... they
 apparently didn't understand and went ahead with the deployment
 anyway. When it finally did sink in, all evidence of the pilot
 evaporated ... and contributes to ongoing resistance to repeating
 another deployment in the states. this is somebody's old trip report to
 cartes2002 ... gone 404 but lives on at the wayback machine ... about
 presentation mentioning EMV design flaws (last paragraph)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
l
 
 after detailed description at an ATM Integrity Task Force meeting,
 somebody made a reference to billions of dollars having been spent to
 proove chips are less secure than magstripe.
 
 There was myopic attention to countermeasures for lost/stolen card and
 not exposing PIN (authentication information). ATM machines  POS
 terminals would ask the card if the person had entered the correct
 PIN. The problem was that it was trivial to create counterfeit
 chip-cards that were programmed to always answer YES (they became
 known as YES CARDS) ... it was no longer necessary to skim the PIN
 information ... since a counterfeit card would claim everything was
 correct PIN ... regardless of what was entered. misc. past posts
 mentioning YES CARDS
 http://www.garlic.com/~lynn/subintegrity.html#yescard
 
 part of the design flaw was the card was also asked whether the
 transaction should be done offline; Counterfeit YES CARDS always
 answered YES ... so even if the account was deactivated at the
 financial institution, it had no effect on stopping the transactions.
 
 during the Future System period in the early 70s ... the vm370
 development group was side-tracked into working on FS ... one of the
 things was a super-security enhanced vm370 so that all super secret
 Future System documents would only be available in softcopy and only
 viewed on specially permitted 3270 screens (the development group had
 outgrown the 3rd flr of 545 tech sq and moved out to the old SBC bldg at
 burlington mall). misc. past posts mentioning science center at 545 tech
 sq http://www.garlic.com/~lynn/subtopic.html#545tech
 
 part of this was slightly earlier, paper copy of document describing 370
 virtual memory (available for all 370s) showed up at an industry
 publication (before virtual memory for 370 was announced). investigation
 was sort of mini-Pentagon Papers ... afterwards ... all corporate
 copying machines were retrofitted with serial number that would appear
 on all copies made.
 
 one weekend I had some test time on another machine in the same room.  I
 went by on friday afternoon to get things prepared. they had to show off
 their new super secure machine ... and just had to say that even I
 couldn't break the security ... even if I was left along in the machine
 room over the weekend. so one of the few times I rose to the bait, I
 said it would take only five minutes ... most of the time was spent
 disabling/turning-off all external access to the machine ... and then i
 used the front panel to alter a byte of storage in main memory ... which
 effectively disabled all the system security processes.
 
 I pointed out that they would would need access authentication for use
 of machine front panel functions ... and could also use encryption for
 all data (this was even before DES, coppersmith was still down at
 harvard) 
 http://en.wikipedia.org/wiki/Don_Coppersmith
 
 for other topic drift ... some old public key email ... even discussion
 of PGP-like email operation a decade before PGP:
 http://www.garlic.com/~lynn/lhwemail.html#publickey
 
 MIT leaves behind a rich history in Tech Square
 http://web.mit.edu/newsoffice/2004/techsquare-0317.html
 
 Research topics also evolved, starting with the grand challenge of
 time-sharing and moving on to new problems as computer science began to
 mature. Tech Square served as the East Coast hub of the ARPANET (it was
 the original Network 18, known today as mit.edu); on the fifth floor,
 Dave Clark's group worked on the infrastructure for what would become
 the Internet, notably the 

Re: Crypto Facility performance.

[Lloyd Fuller]

Scott,

The newer version of z/PDT support crypto cards.  I am not sure which version 
added it, but I know that the last two or three versions support them.  They 
have to be configured in the zPDT device map.

Lloyd



- Original Message 
From: Scott Ford scott_j_f...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sun, April 28, 2013 8:38:21 AM
Subject: Re: Crypto Facility performance.

RS,

We use our own encryption routines ..I was wondering if I could make use of 
crypto cards, I am not familiar with them because we develop on Z/Pdt ...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


On Apr 28, 2013, at 5:44 AM, R.S. r.skoru...@bremultibank.com.pl wrote:

 W dniu 2013-04-27 20:27, Scott Ford pisze:
 Guys,
 
 I have a question , can a vendor use crypto services on Z without the crypto 
Card ?
 
 Please, define vendor and specify what kind of services you mean.
 
 In general every service means some algorithm, most of them also use a key. 
Algorithm can be implemented in your software, but you cannot use so called 
secure keys without crypto cards. There is also CPACF - crypto coprocessor 
which 
speeds up given crypto services, but does not offer secure key.
 
 
 -- 
 Radoslaw Skorupka
 Lodz, Poland
 
 
 
 
 
 
 --
 Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone 
wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z 
wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci 
lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej 
rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym 
charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo 
omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale 
usun 
t wiadomo wczajc 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 authorised 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. 

 BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
 Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug 
stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) 
wynosi 168.555.904 zotych.
 
 
 --
 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: Linking to MVS standard linkage function from Rexx

[Lloyd Fuller]

You can use malloc() in Metal C.  We do.  My point was that the malloc() in 
Metal C is a different routine than the malloc() in the LE library.  Also, to 
use malloc() and some of the other Metal C functions, you need to call __cinit. 
 
I am not sure how you do that when you are also linking with the LE library.

Can you do an external load with C++ like you can with COBOL:  i.e., CALL 
'name' 
or CALL variable_name?  If you can do that, I think that you might be safe.  I 
just suspect that you are going to have some problems linking Metal C and a 
standard C/C++ routine.

Lloyd



- Original Message 
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, March 29, 2013 2:37:46 PM
Subject: Re: Linking to MVS standard linkage function from Rexx

Why?

I have a product coded in Rexx, and a product coded in C++. I want to add
the same function to both of them. FWIW, the function is writing a user SMF
record. The format of the SMF record is going to be fairly complex, with
four different recurring sections pointed to by triplets.

Rather than write, debug and maintain the construct the SMF record logic
twice, once as a method embedded in the C++ code and once in some
combination of Rexx and assembler for the Rexx code, I thought I would write
the logic once in Metal C and call it from the Rexx code and from the C++
code.

I would link it statically with the C++ code. The Rexx code is compiled, and
I would like to  link it statically there also. I don't think I can do that
if I want to use LINKMVS/PGM, unless I alias or IDENTIFY it -- that was the
question I was asking -- so I will instead (I think) write a little Rexx
helper stub in assembler that is called as a function (part of a function
package) that bridges Rexx linkage to standard MVS linkage.

No I/O required. I think what I need to do is a good match for the
capabilities of Metal C. It would not be terribly difficult to do in
assembler but I prefer C. Mostly just pointer logic and memcpy()'s, plus an
invocation of SMFEWTM. Not exactly sure how I will do that, whether with
__asm() or by calling a little assembler routine. I think probably the
latter -- more straightforward, and performance is not critical because it
is a single call.

BTW, you can use malloc() in Metal C, at least according to the
documentation, although I don't think I intend to.

I like static linkage in general. My perception is that it leads to fewer
surprises, although I am also aware of the drawbacks.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lloyd Fuller
Sent: Friday, March 29, 2013 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linking to MVS standard linkage function from Rexx

I am not sure WHY you would want to do this:  imbed assembler maybe?  You
would not be able to use malloc or most of the C functions.  The Metal C
functions resolve into different functions than normal C compiles.  Also,
unless you play games you cannot do I/O in Metal C (i.e. sprintf() works,
but printf() does not).  Many of the C functions have no Metal C equivalent,
for example, the time and date ones, ICONV, etc.

It may be doable, but I would be very careful.  Also, if you are going to
ship this as part of the product, you need to use static linkage for the
Metal C part particularly if you need to do __cinit.  The underlying
function changed between z/OS 1.11 and 1.12 and they are not necessarily
compatible in execution.  Been bitten there.

--
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: Linking to MVS standard linkage function from Rexx

[Lloyd Fuller]

If he is careful, he can even compile C1 for normal C calls and compile it a 
second time with Metal C for calling from Rexx.  I agree with Charles, calling 
from Rexx to Metal C is probably simpler than calling a standard C routine.

We have several routines that we compile both ways:  for some things we have a 
C 
or C++ main and use a set of functions compiled with c89.  For other uses of 
those same functions, we have a little C routine DESIGNED to be called from 
assembler that initializes the Metal C library and builds the parameter lists 
for the same set of C functions.  For a few of the normal C functions, we 
have 
some two-way #ifs in the code that says that if this is Metal C you use this 
set 
of #includes and it not Metal C you use a different set.

This all works well.

Lloyd



- Original Message 
From: Bernd Oppolzer bernd.oppol...@t-online.de
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, March 29, 2013 3:27:52 PM
Subject: Re: Linking to MVS standard linkage function from Rexx

I read your post more carefully once again ...

If performance indeed is not critical, why not write two things:

- a C function, let's call it C1, which does the construction of the SMF records
and can be called from the C++ code directly

- and a little C main program C2, which does the conversation with REXX
(gets the needed information from the REXX variables) and builds the
interface to C1, much the same way as the C++ code does it, and then
calls C1.

The C2 main program is called directly from REXX as a command,
and because it is a C main, the LE environment is built on every call.

If this is not executed high frequency, it should work without problems.

Kind regards

Bernd



Am 29.03.2013 20:16, schrieb Bernd Oppolzer:
 I don't quite understand why you are restricting yourself by using
 Metal C instead of normal ANSI C. What is the drawback of using
 normal C below the REXX application, too? Of course, you may have some
 trouble keeping the LE environment alive across different calls, if 
performance
 is an issue (if not, you may well build the LE environment on every call), but
 AFAIK there are ways to do this - isn't it called CEEPIPI? We do it below APL,
 for example - well, that's easy, you don't even need CEEPIPI, because APL
 supports the construction of persistent environments and a callback to APL,
 when the environment has been constructed once - so APL calls an environment
 constructing module that you provide on the first call of any application 
module
 and then never again - this is controlled by APL.
 
 In my opinion it's much easier to get normal C running below REXX than
 Metal C below C++; maybe it's possible, but IMHO Metal C is meant to be
 used in environments like systems programming where you cannot tolerate
 the LE overhead, but in your case I believe you can.
 
 Kind regards
 
 Bernd
 
 
 
 Am 29.03.2013 19:37, schrieb Charles Mills:
 Why?
 
 I have a product coded in Rexx, and a product coded in C++. I want to add
 the same function to both of them. FWIW, the function is writing a user SMF
 record. The format of the SMF record is going to be fairly complex, with
 four different recurring sections pointed to by triplets.
 
 Rather than write, debug and maintain the construct the SMF record logic
 twice, once as a method embedded in the C++ code and once in some
 combination of Rexx and assembler for the Rexx code, I thought I would write
 the logic once in Metal C and call it from the Rexx code and from the C++
 code.
 
 I would link it statically with the C++ code. The Rexx code is compiled, and
 I would like to  link it statically there also. I don't think I can do that
 if I want to use LINKMVS/PGM, unless I alias or IDENTIFY it -- that was the
 question I was asking -- so I will instead (I think) write a little Rexx
 helper stub in assembler that is called as a function (part of a function
 package) that bridges Rexx linkage to standard MVS linkage.
 
 No I/O required. I think what I need to do is a good match for the
 capabilities of Metal C. It would not be terribly difficult to do in
 assembler but I prefer C. Mostly just pointer logic and memcpy()'s, plus an
 invocation of SMFEWTM. Not exactly sure how I will do that, whether with
 __asm() or by calling a little assembler routine. I think probably the
 latter -- more straightforward, and performance is not critical because it
 is a single call.
 
 BTW, you can use malloc() in Metal C, at least according to the
 documentation, although I don't think I intend to.
 
 I like static linkage in general. My perception is that it leads to fewer
 surprises, although I am also aware of the drawbacks.
 
 Charles
 
 


-- Bernd Oppolzer
---
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
---
Tel.: +49 711 2272522
priv.: +49 711 7949590
eMail: 

Re: Linking to MVS standard linkage function from Rexx

[Lloyd Fuller]

I think you are safer that way.

We have code that does the __cinit() call for our Metal C routines that is in a 
separate routine that never gets compiled with normal C.  I see no reason why 
you could not put it into your function and use #ifdefs to not compile it when 
you are using standard C.  And our define for the Metal C compiles and 
#ifdefs 
is METAL_C so it is obvious which code is specific to that compile.

Two warnings:  since you are going to different platforms with your product, 
make sure you do a static compile and bind with the Metal C.  We ran into 
issues 
compiling on z/OS 1.12 and trying to run on 1.11.  Once we did things static we 
were fine on both platforms.  Also, if you are going to use 64-bit, there is a 
documentation issue in the __cinit() sample code.  You do NOT need to cast the 
return from the __cinit() call for 64-bit or 32-bit.  You will get compile 
errors if you try it use the sample code as it.

Lloyd



- Original Message 
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Mon, April 1, 2013 10:03:56 AM
Subject: Re: Linking to MVS standard linkage function from Rexx

Great minds think alike!

I am now thinking that perhaps I write the SMF build logic in the Metal C
subset dialect, but then compile it two ways:

1. With Metal C for linking with Rexx.
2. With standard C (is there a name for non-metallic C? Plastic C?) for
linking with the C++ code.

Along with the advantage of avoiding the sorts of problems you allude to,
another advantage would be that I could sneak some printf's for debugging
purposes into the standard C compile, and then after debugging comment them
back out of the source before doing the Metal C compile. (Or use #ifdefs.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lloyd Fuller
Sent: Monday, April 01, 2013 4:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linking to MVS standard linkage function from Rexx

If he is careful, he can even compile C1 for normal C calls and compile it a
second time with Metal C for calling from Rexx.  I agree with Charles,
calling from Rexx to Metal C is probably simpler than calling a standard C
routine.

We have several routines that we compile both ways:  for some things we have
a C or C++ main and use a set of functions compiled with c89.  For other
uses of those same functions, we have a little C routine DESIGNED to be
called from assembler that initializes the Metal C library and builds the
parameter lists for the same set of C functions.  For a few of the normal
C functions, we have some two-way #ifs in the code that says that if this is
Metal C you use this set of #includes and it not Metal C you use a different
set.

--
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: Linking to MVS standard linkage function from Rexx

[Lloyd Fuller]

Charles,

Before you get to far, unless things have changed, Metal C does not handle C++. 
 
C only.  I have not looked specifically at z/OS 1.13, but I do know that in 
1.12 
and earlier, C only.

Lloyd



- Original Message 
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, March 28, 2013 8:59:05 PM
Subject: Linking to MVS standard linkage function from Rexx

Level set: I know what I am doing in Rexx. I am real familiar with and have
written function packages already.

I want to write a function that will be callable both from Rexx and from
C++. (This may be my first adventure with Metal C, but that's a different
topic.) The C++ part is easy; let's talk about the linkage from Rexx.

I know I can call from Rexx using standard MVS linkage using ADDRESS
LINKMVS or LINKPGM. (We just went over the differences here; let's not
digress into that!) But if I am RTFM correctly, LINKMVS/PGM requires a
separate load module or alias (or IDENTIFY and I don't think I want to go
there for this). For the sake of neater packaging I would like to linkedit
the callable function into an existing function package. Relying on
separate load modules or PDS aliases complicates life in other ways.

I don't *think* I can make a standard MVS linkage function part of a Rexx
function package, is that right? LINKMVS/PGM and Rexx functions live in
different worlds, right? LINKMVS/PGM always searches for MVS entry points,
and only Rexx functions use function packages, is that right?

If I want to do this then instead of using LINKMVS/PGM I will have to write
a Rexx linkage Rexx function that provides a glue layer between Rexx and
the standard MVS linkage function? 

Or does anyone know something I am missing?

Thanks!

Charles 

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

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

Re: Lost datagrams on z/OS 1.12?

[Lloyd Fuller]

Charles,

Where was the routine compiled?  Under which version of z/OS?  If z/OS 1.12 or 
newer, make sure that you check the updates to the compiler and the library.  
They were significant.

Lloyd



- Original Message 
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, March 20, 2013 11:09:07 AM
Subject: Re: Lost datagrams on z/OS 1.12?

Thanks all.

Filling in some gaps and answering some questions.

I've added additional trace code within the product to make certain that the
socket, sockaddr, and record length are as expected. (I already know that
the sendto() is getting issued with the correct record.) I changed the error
check from if ( returnvalue  length ) to if (returnvalue != length ) to
help avoid any possibility of signed/unsigned or similar issues. Running a
test at the customer today with a packet trace also.

Environment is z/OS started task. Source language is IBM XL C++. Record
length varies but is typically a few hundred bytes and never exceeds 1024
bytes. Ditto for the old version that works, so maximum datagram and MTU
size issues seem unlikely. Don't know any of the customer's TCP/IP
configuration but the message traffic should be 99.9% the same for both
versions -- they are in theory both sending the same stuff.

More to follow ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Miklos Szigetvari
Sent: Wednesday, March 20, 2013 12:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lost datagrams on z/OS 1.12?

Not really rings the bell, but we have here some UDP applications, and the
TCP/IP UDP settings  maybe different, We had to change some maxudp...
values in the TCP/IP or OMVS definition .
On 19.03.2013 20:16, Charles Mills wrote:
 I've got a problem that is defying my ability to find it. I have a 
 product that uses sendto() to send UDP messages (datagrams). At one 
 and perhaps two z/OS 1.12 customers I have seen a problem in which 
 what appear to be perfectly good sendto()'s send a datagram that never 
 arrives at its destination. (Of course, the lack of error feedback is 
 a known characteristic of UDP.)

 Version x.1 of my product does not exhibit this behavior. Version x.2
does.
 There is relatively little difference between how the two issue 
 sendto(). I have never seen the problem on my development machine, 
 including under z/OS 1.12.

 It is definitely not a firewall or other external issue because 
 Version x.1 works fine. You bring it down and bring Version x.2 up 
 with the same parameters and it works for a little while and then 100% 
 of the messages start disappearing. You bring it down and bring x.1 back
up and all is well.
 Similar TCP/IP code does not seem to have the same problem.

--
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: Where current HLASM doc?

[Lloyd Fuller]

There were several of us working on the SHARE requirements.  We tried to make a 
business case for the requirements that we needed.  And, yes, some of Greg's 
changes did not get put into HLASM.  


A few we could not come up with a business case, and a few none of us were 
using 
and we did not know anyone that was using the feature so we did not burden IBM 
with those.  As I remember, there were only one or two that John was not able 
to 
get implemented once we gave him the business case.  And, yes, there were one 
or 
two that IBM implemented differently because it was the IBM way and not Greg's 
way.

Lloyd



- Original Message 
From: Shmuel Metz (Seymour J.) shmuel+...@patriot.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, March 7, 2013 9:24:34 AM
Subject: Re: Where current HLASM doc?

In 1362595274.25094.yahoomai...@web181403.mail.ne1.yahoo.com, on
03/06/2013
   at 10:41 AM, Lloyd Fuller leful...@sbcglobal.net said:

In fact many of the feature upgrades from H Assembler to HLASM came
from the  SLAC mods descriptions as we wrote SHARE requirements for
those features.

In at least one case Greg's version was better than IBM's.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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: Where current HLASM doc?

[Lloyd Fuller]

And you could get the SLAC mods for H Assembler which made it MUCH more usable. 
Thanks, Greg.  :-)

In fact many of the feature upgrades from H Assembler to HLASM came from the 
SLAC mods descriptions as we wrote SHARE requirements for those features.

Lloyd



- Original Message 
From: John Gilmore jwgli...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, March 6, 2013 9:02:36 AM
Subject: Re: Where current HLASM doc?

The H Assembler at least was once charged for.

The cost was always nominal, US$150 per month is what I remember, but
I should not wish to be hanged if that number is wrong.  It was widely
used because it did SYSGENs, NCPGENs, and the like very much faster
than the F Assembler.

John Gilmore, Ashland, MA 01721 - USA

--
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: Article for the boss: COBOL will outlive us all

[Lloyd Fuller]

This is also a great way to hide files from casual users:  make the name 
unprintable characters and they do not see the file.

Or make it read only on a writable disk:  use lower case or unprintable 
characters in the name.  Without a program it is difficult to overwrite, read, 
or delete the file.  Been bit more than once.  :-)

Lloyd



- Original Message 
From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, February 13, 2013 5:17:35 PM
Subject: Re: Article for the boss: COBOL will outlive us all


(Oddly, the one quasi-counter-argument is CMS, where you have to work at it to 
create/use a file with lowercase in the fileid-but that's a different kettle of 
hamsters, since it's more a byproduct of an historical mistake than a 
deliberate 
feature, and not the same at all as *IX.)
--
...phsiii

Phil Smith III


--
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: RACF on an ADCD system

[Lloyd Fuller]

As several other people have pointed out, the ADCD systems are mainly used by 
software vendors, mostly for zPDT systems, but sometimes others.  And many of 
us 
HAVE to support old software:  we still have customers that have not migrated 
for one reason or another.

I agree that ADCD as delivered is not the best, but most of us do NOT worry 
about audits because we are not using these systems for production just for 
development and customer support.  In fact, that is how the IBM contract for 
ADCD reads for us:  the systems can only be used in development and support.

Lloyd



- Original Message 
From: ibmmain nitz-...@gmx.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, January 3, 2013 12:38:36 PM
Subject: Re: RACF on an ADCD system

 And the DB2s are separately down-loadable from IBM-Dallas.  So you can have 
 DB2 

 V8 on 1.13.  I agree that ADCD does not come with it directly, but it is 
 available.

So basically what y'all are saying is that this rubbish is nice to have. I 
disagree, especially for remnants of userids that don't exist anymore.

In my opinion, if someone wants to add outdated software (even if it is still 
supported) to their system, they better know how to set it up properly. We will 
certainly not run several DB2s or CICSs or WASs or IMSs, only the latest, if 
any. What I didn't mention was that I basically eliminated every activated IMS 
class, all classes dealing with Websphere and z/OSMF plus a few others. If we 
will run this sometime in the future, I'll be reading the books on how to set 
this up rather than deal with obsolete definitions that may or may not have an 
impact on something else.

These ADCD systems are not set up for migration from one z/OS release to 
another 
at all, so data transfer from one system to the next appears to be a must. I 
understand that the ADCD comes with two releases of each (and I don't think we 
were missing volumes). I am also aware of the different load parms (one of the 
first things I checked). It is even mentioned on that website I cited (which is 
the only documentation I have for an ADCD system).

the ADCD has evolved over the years it hasn't been cleaned up properly and the 
team that build it is quite small
That's what I figured. An overworked, too small group that cannot keep up with 
the demands, so they do the best they can. Which falls far flat of IBMs 
propagated 'best practises'. As far as RACF is concerned, an ADCD system would 
never survive an audit, even with mild auditors.

Barbara

--
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: dsf to write over entire volume

[Lloyd Fuller]

At my previous job, when we had to retire the P390 systems, the IT 
administrator 
had some problems to work off.  So he took the 3.5 inch drives home and used 
his 
splitting ax on them over a couple of week-ends.  Cheap and therapeutic.  He 
brought one back in and they were very nicely destroyed.  :-)

Lloyd  



- Original Message 
From: Don Williams donb...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, December 14, 2012 7:57:03 AM
Subject: Re: dsf to write over entire volume

I agree that it is quite unlikely that our DASD will be hacked. My manager
thinks the same. Regardless, our management has chosen certified crushing
and shreding of retired DASD, Tape, etc. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: Friday, December 14, 2012 1:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dsf to write over entire volume

W dniu 2012-12-13 18:22, Ron Hawkins pisze:
 Radosalw, (Radoslaw, pronounced like Radoslav ;-) )

 Encryption is a matter of time and cost. The question is WHEN I will
 decrypt
 the data, not IF. And WHEN depends on my budget (the more money the 
 more zombies works for me) and piece of good luck (I can guess the 
 key 5 min. after start or as last possible value).

 [Ron Hawkins] I'm not sure I follow the point. Encryption occurs when 
 the data is destaged to the array group, and decrypted when you read 
 it from the disk. There's no overhead to this . If you mean switching 
 encryption on for existing array groups then yes there will be some
planning involved.

I think you missed the point. Encryption does not prevent data from being
read, it does DELAY the moment when hacker will read the data. 
If the dealy is measuer in centuries that's OK, but nowadays the are methods
to accelerate decryption (brute force) attacks i.e. using grid, cloud or
just bunch of PC's, possibly using GPU (VGA card processors), possibly
using hacked machines without onwers awareness.






BTW: This is significant: few years ago nobody suggested (and offered) full
disk encryption inside dasd arrays, nobody was selling security erasure
features for those arrays, nobody was selling data erasure programs
operating at OS (MVS) level. However degaussers for tape carts were around
us even then.

What was changed? Physics? No. Maybe with exception of SSD as new media.
The issues addressed by the above means had existed for years. 15 years ago
it was also possible to play with bad sectors of disk coming from dasd
array, or preferrably with whole healthy tracks on such disk.

What was changed?
IMHO two things: minor change in available tools for potential hackers and
major change in our minds. Changes driven by horror stories 
presented in IT newspapers. Majority of them does not describe real attacks
but possibilities of such attacks. Considerations how many times should the
track be overwritten with random data to erase residual vestiges of data at
sides of the track...

That remains me thesis from some movie - probably Bowling for Columbine
- the number of violence acts decreased sligthly over the years, but the
percentage of report about those acts in the news increased 10 times. 
There are specialized TV teams hunting for accidents, fussilades, bank
robberies, madmen with guns, etc.

Maybe it's the same in IT - the vulnerabilities remain unchanged for years,
but we talk about them much more. ;-)


-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by
jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste
adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej
przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie,
rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie
zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo,
prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
usun t wiadomo wczajc 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 authorised
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. 

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy 

Re: Usefullness (or not) of STOC/LOC instructions?

[Lloyd Fuller]

- Original Message 
From: McKown, John john.mck...@healthmarkets.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, November 28, 2012 4:06:00 PM
Subject: Re: Usefullness (or not) of STOC/LOC instructions?

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Kirk Talman
 Sent: Wednesday, November 28, 2012 2:26 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Usefullness (or not) of STOC/LOC instructions?
 


 I guess, in my case, it is a combination of esthetics and being concerned 
 about 
possible AR mode considerations. In AR mode:

LR2,0(,R1)
 and
   LR2,0(R1)

 will likely result in greatly different values being loaded into R2 if the 
contents of AR1  primary address space. 


The latter can also run into issues in AMODE 64.  The index register is always 
32 bits, not 24, 31, or 64 depending upon AMODE.  Waste the extra nano-second, 
use the comma.  It is meaningful.

Lloyd

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

Re: Usefullness (or not) of STOC/LOC instructions?

[Lloyd Fuller]

I was muddling.  It is always 64 bit in zArch. 

My point still remains:  save yourself and follow-on programmers time and 
effort 
- put in the comma.  


Lloyd



- Original Message 
From: Tony Harminc t...@harminc.net
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, November 29, 2012 12:53:00 PM
Subject: Re: Usefullness (or not) of STOC/LOC instructions?

On 29 November 2012 07:29, Lloyd Fuller leful...@sbcglobal.net wrote:

 The latter can also run into issues in AMODE 64.  The index register is always
 32 bits, not 24, 31, or 64 depending upon AMODE.  Waste the extra nano-second,
 use the comma.  It is meaningful.

I think you're muddling the index register (always 64 bits in zArch)
with the access register (always 32 bits on 370/ESA through zArch). Or
perhaps it was just a typo - 32 was meant to be 64?

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: Check out ATT, Verizon, Sprint, T-Mobile Offer Statements On Hurricane Netwo

[Lloyd Fuller]

I live in a coastal town, but not near the water.  Unfortunately most of the 
cell towers that are near my home were also much nearer the water so even 
backup 
generators/battery backup did not help.  I have been told that several of them 
are not even standing anymore.  With previous storms, even ones that made 
land-fall closer to us, the cell towers mostly survived.  Unfortunately, backup 
generators or battery backup does not help when the base of the tower is under 
a 
few feet of water.

Lloyd



- Original Message 
From: Blaicher, Christopher Y. cblaic...@syncsort.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, October 31, 2012 2:18:57 PM
Subject: Re: Check out ATT, Verizon, Sprint, T-Mobile Offer Statements On 
Hurricane Netwo

Most cell towers have UPS's with backup generators.  I have fellow employees 
that are saying they are now losing service.  My guess is that the generators 
are running out of fuel and various sites are dropping off because of that.  In 
defense of all the companies, you plan for the bad case, or worse, but how do 
you plan for a total disaster?

I am located in Texas, but my daughter has friends in northern New Jersey that 
planned ahead and have generators for their homes, but now they can't get any 
more fuel for them so they are dropping off.

If things get back to any form of normal in less than a week, it will be a 
miracle.  For some places it will be measured in months, lots of months.

Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Finnell
Sent: Wednesday, October 31, 2012 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Check out ATT, Verizon, Sprint, T-Mobile Offer Statements On 
Hurricane 
Netwo

_ATT,  Verizon, Sprint, T-Mobile Offer Statements On Hurricane Network
Issues: No ETA  Given For Fix | TechCrunch_ 
(http://techcrunch.com/2012/10/30/att-verizon-sprint-t-mobile-offer-statements-on-hurricane-network-issues-no-et

a-given-for-fix/?icid=maing-grid10|htmlws-main-bb|dl6|sec3_lnk1pLid=227781)


Anybody tracking the edu's as online/offline?

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



ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other  confidential 
and/or legally privileged information. Any pricing information contained in 
this 
message or in any files transmitted with this message is always confidential 
and 
cannot be shared with any third parties without prior written approval from 
Syncsort. This message is intended to be read only by the individual or entity 
to whom it is addressed or by their designee. If the reader of this message is 
not the intended recipient, you are on notice that any use, disclosure, copying 
or distribution of this message, in any form, is strictly prohibited. If you 
have received this message in error, please immediately notify the sender 
and/or 
Syncsort and destroy all copies of this message in your possession, custody or 
control.

--
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: zEC12, and previous generations, why? type question - GPU computing.

[Lloyd Fuller]

- Original Message 
From: zMan zedgarhoo...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, September 5, 2012 5:17:37 PM
Subject: Re: zEC12, and previous generations, why? type question - GPU 
computing.

On Wed, Sep 5, 2012 at 2:28 PM, Shmuel Metz (Seymour J.) 
shmuel+...@patriot.net wrote:

 In a6b9336cdb62bb46b9f8708e686a7ea0115baa1...@nrhmms8p02.uicnrh.dom,
 on 09/05/2012
at 11:45 AM, McKown, John john.mck...@healthmarkets.com said:

 If it is because the z architecture is not good at numeric
 computation,

 The z architecture is fine for numeric computations. The problem is
 that the implementation is competing with processors manufactured in
 bulk. If IBM could sell millions of z boxen then they'd be able to cut
 the price dramatically.

 I've always wondered what would have happened had IBM used a 370
 instruction set on the PC instead of Intel.


16MB ought to be enough for anybody? :-)

Since IBM wasn't manufacturing the chips, of course that wasn't even on the
table, but it's still a VERY interesting Gedankenexperiment...
-- 
zMan -- I've got a mainframe and I'm not afraid to use it

They could have gone with the Motorola 6800x chips instead.  However, I am not 
sure that Motorola would have committed to producing as many chips as IBM 
thought they needed.  The 6800x is what was used for the 370 part of the PC-370 
systems.

Lloyd

--
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: zEC12, and previous generations, why? type question - GPU computing.

[Lloyd Fuller]

There were two:  the PC/370 and the AT/370.  I am not sure that many PC/370s 
got 
distributed as they were real SLOW.  My old company had both for awhile.

Lloyd



- Original Message 
From: zMan zedgarhoo...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thu, September 6, 2012 8:54:25 AM
Subject: Re: zEC12, and previous generations, why? type question - GPU 
computing.

AT/370.

On Thu, Sep 6, 2012 at 2:07 AM, Leopold Strauss 
leopold.stra...@isis-papyrus.com wrote:

 Yes.

 It was a microprogrammed motorola-68000-chip, which was used. Name was
 similar to PC/370, but I am not sure about that.
 Many years ago the company, where I was employeed at that tim, had one for
 short for testing-purposes. Ibelieve to remember, it was the time,
 where 3033-systems came up ( before 3081/3083).




 On 06.09.2012 07:58, George Henke wrote:

 I believe IBM produced a pc with a 370 to run VM on a PC.  Merrill Lynch
 had one.  Somewhere in the late 80's I believe.

 On Thu, Sep 6, 2012 at 1:52 AM, Timothy Sipples1 sipp...@sg.ibm.com
 wrote:

  Yes, there are organizations that use zEnterprise servers for heavy
 numeric computation. Like decimal floating point. Cryptography is
 another
 excellent example. And you can buy optional CryptoExpress adapters if you
 want to augment the excellent capabilities found in every machine. You
 can
 also buy the optional zBladeCenter Extension (zBX) if you want to add
 DataPower accelerators, Power blades, and/or X86 blades. You can also add
 an optional IBM DB2 Analytics Accelerator, to boost many types of DB2
 queries. So we're way ahead of you, John. ;-)

 I think the simple answer is that it depends what you optimize for in
 designing a server processor (or complex). But IBM has broken a lot of
 rules already about which server should do what, and I predict more
 rules
 will be broken.

 With respect to the 370-on-a-chip, IBM sort of did that with the 1975
 introduction of the IBM 5100 Portable Computer starting at $8,975 (1975
 dollars), although it was for a relatively narrow initial purpose (to get
 APL running). The 5100 sold reasonably well from what I've read, but I
 think there were three basic problems which prevented it from becoming a
 blockbuster:

 1. The price was not low enough for mass market appeal. (Apple had a
 similar problem with the Lisa in the early 1980s.)

 2. The software selection didn't exactly hit the mark, although it was a
 good try for the time. (IBM learned the value of software somewhat later
 in
 its evolution but not in time for the 1981 IBM PC.)

 3. It probably didn't have the right third party marketing and
 distribution
 channels. With some very notable exceptions, like typewriters, at that
 time
 IBM would have had some challenges with this type of product.

 Keep in mind that for 1975 this was absolutely amazing technology, but
 amazing technology required some expense. Being early is pricey. If the
 5100 debuted in, say, 1977 or 1978, it would have still been well timed
 but
 could have dramatically reduced the chip and board count. I also think
 the
 small built-in monitor could have been sacrified (at least as an option)
 in
 favor of a display port of some kind -- ideally RF for TV hookup. And IBM
 might have gone with a diskette drive for storage -- the 5100 was too
 early
 for the 5.25 inch drive, which debuted in 1976. Finally, if IBM had
 provided a little more guidance on the 370 subset instruction set they
 implemented, software developers could have taken over from there.

 So I think the 5100 could have been a nice 5110 by tweaking the recipe a
 bit. But history didn't happen that way.

 IBM had some success with the System/4 Pi avionics processors which are
 descended from System/360.


 --**--**
 --**--
 Timothy Sipples
 Consulting Enterprise IT Architect (Based in Singapore)
 E-Mail: sipp...@sg.ibm.com
 --**--**
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





 --
 Mit freundlichen Grüßen / Kind Regards,

 Leopold Strauss
 Research and Development

 ISIS Papyrus Europe AG
 Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
 T: +43 - 2236 – 27551, F: +43 - 2236 - 21081
 @ leopold.strauss@isis-papyrus.**com leopold.stra...@isis-papyrus.com

 Visit our brand new extended Website at www.isis-papyrus.com

 This e-mail is only intended for the recipient and not legally binding.
 Unauthorised use, publication, reproduction or disclosure of the content
 of this e-mail is not permitted. This e-mail has been checked for known
 viruses, but ISIS accepts no responsibility for malicious or inappropriate
 content.


 --**--**--
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to 

Re: GUIfication of tn3270 screens

[Lloyd Fuller]

You can do at least part of this with 3270.  The Nomad2 product does part of 
it, 
but it drives the 3270 itself basically using alternate screen stuff.  Only one 
piece of the screen is allowed to input and the rest can have scrolling data in 
multiple pieces that are driven by the Nomad2 application.

However, that will not solve Frank's problem.  I do not think that he wants to 
write the debugger product in Nomad.  :-)

Lloyd



- Original Message 
From: McKown, John john.mck...@healthmarkets.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, August 10, 2012 1:46:40 PM
Subject: Re: GUIfication of tn3270 screens

Well, I have a fair idea what you want. But I cannot conceive of a way to do it 
using the 3270 data stream. Personally, I'd go with having some way to invoke 
the debugger via HTTP, using a web browser. Then use AJAX to implement the 
windowing within the browser itself with a Java app or Javascript.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA 
Life and Health Insurance Company.SM

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Chu
 Sent: Friday, August 10, 2012 12:37 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: GUIfication of tn3270 screens
 
 John,
 
 It's for an application that has already been written by us.  
 The app is 
 an assembler debugger and we want to add the ability/option of 
 displaying it's contents on the PC with something other than 
 in a 3270 
 emulator. There's not a lot of real estate in a 3270 screen and 
 there are limitations on how we display things.  This is 
 becoming more 
 of an issue as we move beyond just debugging HLASM programs.
 
 With regards to the multiple tabs/windows.  The general idea 
 behind the 
 GUI on the PC would be that in a single debugging session, 
 you can have 
 a window open for displaying the code as you are stepping 
 through it.  
 Another window to display register contents, another one for 
 variables, 
 another one for displaying storage that your program will modify, 
 another window for HELP, etc.   If you have used Eclipse or Visual 
 Studio, it's similar to something like that.
 
 
 Frank

--
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: [z390] Anyone want Source code listing of last VSE program product Supervisor?

[Lloyd Fuller]

It used to (late 1980s and early 1990s.  At some used book dealers you used to 
find the cover-less books available.  I do not know if it happens anymore.

Lloyd



- Original Message 
From: Ken Brick kbr...@netspace.net.au
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Mon, August 6, 2012 6:08:07 PM
Subject: Re: [z390] Anyone want Source code listing of last VSE program product 
Supervisor?

This was a common condition inserted by publishers of lots of books on a 
monthly 
basis and sale or return with the previous months books being removed from the 
shelves. Rather than requiring the store to return the whole book back to the 
publisher they required the store totear the front cover of the book and return 
the book to the publisher to receive their credit. This left the store to get 
rid of the books but not by sale as it was prohibited by the terms and 
conditions of trade.

I'm sure even if indirectly similar events happen in the states,

Ken
On 7/08/2012 04:45 AM, David Andrews wrote:
 On Mon, 2012-08-06 at 14:30 -0400, Lindy Mayfield wrote:
 Books I've bought from the UK say this in the front.  Seems a bit strict, 
 but 
is this the same thing?
 This book is sold subject to the condition that it shall not, by way of 
 trade 
or
 otherwise, be lent, re-sold, hired out or otherwise circulated without the 
publisher's
 prior consent in any form of binding or cover other than that in which it is 
published
 and without a similar condition including this condition being imposed on the
 subsequent purchaser.
 Perhaps this is to discourage resale of a stripped volume?
 
 https://en.wikipedia.org/wiki/Stripped_book
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 

-- Ken

Mob: 0409 009 764

--
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: Off topic

[Lloyd Fuller]

Yes.  I do not remember the name of the malware, but it redirected DNS to a 
hijacked one.  The US FBI set up a clone of the hijacked DNS server and have 
been running it to take away the malware power for better than a year.  The 
reason for the Monday deadline is that is when the FBI is shutting down the 
cloned DNS server.

Check Wired and Ars Technica.  They have been had articles about it within the 
past month or so.

Lloyd



- Original Message 
From: Steve Comstock st...@trainersfriend.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, July 7, 2012 6:26:08 PM
Subject: Re: Off topic

On 7/7/2012 4:21 PM, Ed Finnell wrote:
 There's some pretty nasty malware going around, supposed to strike 'Monday'
   whenever that is. Usually run with ACK as listserv option and the server
 will
 confirm receipt. Course iffin it's in Estonia where it's routed may not
 mean much

I've heard snippits about this. Is there any believable
source for the story?




 In a message dated 7/7/2012 5:05:19 P.M. Central Daylight Time,
 scott_j_f...@yahoo.com writes:

 Has  anyone has messages disappear when the sent them to the listserv  ?


-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
   + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
 for training dollars at
   http://www.trainersfriend.com/ROI/roi.html

--
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: Secure Encryption Keys vs Protected Keys

[Lloyd Fuller]

Consider the cost of a CEX operation as ((ICSF call CPU)+I/O) and the  cost of 
a 
CPACF operation as ((ICSF call)+(some CPU cycles for the  operation)). So the 
difference is I/O vs. CPACF cycles. The I/O cost  doesn't change (much) with 
larger blocks; the CPACF cycles do.

This statement implies that CPACF REQUIRES ICSF.  That is NOT true.  You can 
happily do CPACF operations yourself without ICSF even configured on the 
system.  IBM's white papers about CPACF performance indicate that ICSF imposes 
a 
big performance hit on CPACF.

Lloyd


- Original Message 
From: Phil Smith p...@voltage.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, July 6, 2012 3:32:01 PM
Subject: Re: Secure Encryption Keys vs Protected Keys

R.S. wrote:
Protected key means CPACF in use, secure key means CryptoExpress card.
The difference can be 1000 times or 10 times. Of course CPACF is always
faster.

The more cpu-intensive algorithm and the smaller block of data to be
encrypted, the bigger difference is.

I think the second sentence is confusing here-not saying it's wrong, just that 
I 
can read it a couple of ways, due to English's inherent lack of clarity (not 
your fault, Radoslaw!).

For very large blocks of data, on very CPU-constrained systems that have 
relatively low CEX use, CEX should be faster relative to CPACF than on less 
CPU-constrained systems. That is, you look at the CEX interaction as an I/O and 
CPACF as something that uses some of the real CPU as well as being somewhat 
offloaded, then if real CPU is at a premium, and the blocks are large, the 
cost of the I/O becomes smaller (relatively) than in a less-constrained case, 
or 
one with smaller blocks.

Consider the cost of a CEX operation as ((ICSF call CPU)+I/O) and the cost of a 
CPACF operation as ((ICSF call)+(some CPU cycles for the operation)). So the 
difference is I/O vs. CPACF cycles. The I/O cost doesn't change (much) with 
larger blocks; the CPACF cycles do.

Thus with large blocks, CEX will still be slower than CPACF, just (somewhat) 
less noticeably so. I had a customer claim CEX could actually be faster in some 
cases, but they didn't have data to back it up, so I don't believe him (I don't 
disbelieve him either-more of a Schrödinger's cat deal).
--
...phsiii

Phil Smith III
p...@voltage.commailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.comhttp://www.voltage.com/
(703) 476-4511 (home office)
(703) 568-6662 (cell)

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