Re: Linear Datasets

[Seymour J Metz]

It depends on how you allocate it.


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



From: IBM Mainframe Discussion List  on behalf of 
SUBSCRIBE IBM-MAIN Anonymous 
Sent: Tuesday, February 4, 2020 7:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Linear Datasets

Hi All,

I have a TASK-A that attaches TASK-B, and then waits for TASK-B to complete. 
TASK-B does the following,

1. Dynamically allocate a linear dataset.
2. Issue "DIV IDENTIFY" for the allocated DDNAME.
3. Issue "DIV ACCESS", and then "DIV MAP".

I believe at the end of TASK-B, I need not "UNMAP", "UNACCESS", "UNIDENTIFY", 
and deallocate the linear dataset as it will automatically be done as part of 
the task clean-up. Please let me know if my understanding is correct.

--
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: Manuals for CA-VOLLIE?

[Wayne Bickerdike]

Depending on your clients willingness to change, you could use REXX/CICS.
It has a VM like editor. You can roll your own SUBMIT command. It is *free*
with CICS.

On Wed, Feb 5, 2020, 06:14 Bernd Oppolzer 
wrote:

> After working now two days with it, what strikes me most is the absence
> of a SAVE command.
> Every line you change (or delete !) is changed on the file even without
> SAVE, same goes for deletions,
> and there is no recovery (no other than saving the member before you
> begin or restoring an older
> version for the CA master lib).
>
> And some of the prefix commands are different from ISPF: Prefix command
> A means insert of a blank line
> and prefix I does insertions of lines which are in a buffer (like CUT
> ... PASTE). CC ... CC inserts lines into
> this buffer, but the buffer is not emptied prior to CC ... CC. If you
> want the buffer to be emptied,
> you have to use CCD (or CD, for a single line).
>
> I've worked with MVS for the last 25 years, so I will have a hard time
> in the next weeks :-)
> But I've done VSE before, and today I recalled how to do F F5 (or PFLUSH
> F5) to free a locked partition
> in VSE ... I've used this before in the late 1990s :-)
>
> F F5 can be done from with VOLLIE using the OPE command :-)
> VOLLIE even shows the status of the partitions and the operator console.
>
> Kind regards
>
> Bernd
>
>
> Am 04.02.2020 um 03:09 schrieb Wayne Bickerdike:
> > That's a blast from the past.
> > It does run as a CICS transaction (Normally OLLE).
> >
> > It is 1000% better than the IBM VSE offering (name escapes me).
> >
> > In architecture it's not unlike ROSCOE, runs very lean and mean. All
> > the members are contained within a single VSAM cluster which is
> > formatted and then has 3 char lib prefixes and 8 char names similar to
> > a PDS. eg JCL.MASTJOB1.
> >
> > It also has a crude form of security, defined in a macro assembler
> > module. This determines what you can see and do. A very naughty
> > programmer substituted his own version and when we found out, I
> > substituted yet another module that blasted ***violation*** on the
> > console. The guy in question (Kevin Parker where are you now?) crapped
> > his pants when he realised he'd been rumbled. Had an entertaining
> > dressing down meeting with him.
> >
> > >From memory, I belive you use the "l" command (list) to bring up a
> > member in an editor panel.
> >
> > It has a submit command (I think sub?) and has access to the Power
> > spool to fetch output.
> >
> > It's been 30 years since I last saw Vollie :)
> >
> > On 2/4/20, Bernd Oppolzer  wrote:
> >> great, thank you, I will have to ask my customer, if we can have access
> >> to this site.
> >> Thanks, kind regards
> >>
> >> Bernd
> >>
> >>
> >> Am 03.02.2020 um 20:51 schrieb Frank Swarbrick:
> >>> I don't have a Broadcom logon, but did you try this page?
> >>>
> https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-miscellaneous/legacy_bookshelves_and_pdfs/bookshelves_and_pdfs/bookshelves/ca-vollie-for-z-vse.html
> >>>
> >>> 
> >>> From: IBM Mainframe Discussion List  on
> behalf
> >>> of Bernd Oppolzer 
> >>> Sent: Monday, February 3, 2020 11:25 AM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU 
> >>> Subject: Manuals for CA-VOLLIE?
> >>>
> >>> In my new project assignment, I have to use a tool called VOLLIE (from
> >>> CA), which is used to modify (edit)
> >>> VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
> >>> programs etc.
> >>>
> >>> No VM in this installation. VOLLIE seems to be a CICS transaction.
> >>>
> >>> Is there a manual for CA-VOLLIE, which can be shared, for example PDF
> >>> format?
> >>> No match when using the well-known search engines.
> >>>
> >>> Thanks and regards
> >>>
> >>> Bernd
> >>>
> >>> --
> >>> 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: Manuals for CA-VOLLIE?

[Bernd Oppolzer]

After working now two days with it, what strikes me most is the absence 
of a SAVE command.
Every line you change (or delete !) is changed on the file even without 
SAVE, same goes for deletions,
and there is no recovery (no other than saving the member before you 
begin or restoring an older

version for the CA master lib).

And some of the prefix commands are different from ISPF: Prefix command 
A means insert of a blank line
and prefix I does insertions of lines which are in a buffer (like CUT 
... PASTE). CC ... CC inserts lines into
this buffer, but the buffer is not emptied prior to CC ... CC. If you 
want the buffer to be emptied,

you have to use CCD (or CD, for a single line).

I've worked with MVS for the last 25 years, so I will have a hard time 
in the next weeks :-)
But I've done VSE before, and today I recalled how to do F F5 (or PFLUSH 
F5) to free a locked partition

in VSE ... I've used this before in the late 1990s :-)

F F5 can be done from with VOLLIE using the OPE command :-)
VOLLIE even shows the status of the partitions and the operator console.

Kind regards

Bernd


Am 04.02.2020 um 03:09 schrieb Wayne Bickerdike:

That's a blast from the past.
It does run as a CICS transaction (Normally OLLE).

It is 1000% better than the IBM VSE offering (name escapes me).

In architecture it's not unlike ROSCOE, runs very lean and mean. All
the members are contained within a single VSAM cluster which is
formatted and then has 3 char lib prefixes and 8 char names similar to
a PDS. eg JCL.MASTJOB1.

It also has a crude form of security, defined in a macro assembler
module. This determines what you can see and do. A very naughty
programmer substituted his own version and when we found out, I
substituted yet another module that blasted ***violation*** on the
console. The guy in question (Kevin Parker where are you now?) crapped
his pants when he realised he'd been rumbled. Had an entertaining
dressing down meeting with him.

>From memory, I belive you use the "l" command (list) to bring up a
member in an editor panel.

It has a submit command (I think sub?) and has access to the Power
spool to fetch output.

It's been 30 years since I last saw Vollie :)

On 2/4/20, Bernd Oppolzer  wrote:

great, thank you, I will have to ask my customer, if we can have access
to this site.
Thanks, kind regards

Bernd


Am 03.02.2020 um 20:51 schrieb Frank Swarbrick:

I don't have a Broadcom logon, but did you try this page?
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-miscellaneous/legacy_bookshelves_and_pdfs/bookshelves_and_pdfs/bookshelves/ca-vollie-for-z-vse.html


From: IBM Mainframe Discussion List  on behalf
of Bernd Oppolzer 
Sent: Monday, February 3, 2020 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Manuals for CA-VOLLIE?

In my new project assignment, I have to use a tool called VOLLIE (from
CA), which is used to modify (edit)
VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
programs etc.

No VM in this installation. VOLLIE seems to be a CICS transaction.

Is there a manual for CA-VOLLIE, which can be shared, for example PDF
format?
No match when using the well-known search engines.

Thanks and regards

Bernd

--
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: CSSMTP and @ symbols

[Clark Morris]

[Default] On 4 Feb 2020 07:57:25 -0800, in bit.listserv.ibm-main
000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote:

>On Tue, 4 Feb 2020 15:39:58 +, Ronald Kristel wrote:
>
>>Was this not resolved with PI52704?
>>
>Looking at: https://www-01.ibm.com/support/docview.wss?uid=swg1PI52704
>>
>I don't see that this addresses the possibility that different users at
>a single site may use different code pages.  Is the "AtSign parameter
>option"  user-specific?
>
>More general would be an "originating CCSID" option.
>
>Regardless, the OP's problem occurred with a character in a quoted
>string.  That should be immune to such syntax hyper-enforcement.
>CSSMTP is superstitious about imputed rules at "domain.net".
>
>I hate EBCDIC!
>

This is a case to hate EBCDIC because the code points vary for the @
(and $ and #) sign in EBCDIC since they are national characters. While
I don't know the variants for the @ the dollar sign also uses the same
bit configuration as the pound sterling sign and the Japanese yen
sign.

Clark Morris
>
>>On Tue, 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>>>...
>>>Some userids contain @ symbols and are sending with FROM addresses like 
>>>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>>>says it is valid,
>
>-- 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: 3592-E07

[R.S.]

Tony, I'm pretty sure I understand RPO and RTO correctly. I'm used to 
teach it.
However please, take care - we talk about backup copy only, not about 
the system.
We don't know whole system setup and components. We know that tape 
waiting for PTAM (truck delivery to secondary DC) cause some additional 
period between backup is finished and backup is available in secondary 
data center. Of course any backup on tape is being done periodically, so 
one could loose some data between backups. That's true despite of backup 
replication/delivery method  - however delivery process or asynchronous 
replication process adds extra time to this window.
Last but not least: sometimes it is possible to recover from last 
existing backup only, previous copy is marked as unusable or it's hard 
to use it.
In such scenario your systeme (DASD replicated) could be aware of last 
backup, but your last backup is not delivered and will never be 
delivered because of fire on server room.


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 31.01.2020 o 17:44, Tony Thigpen pisze:

Radoslaw,

I think you don't understand RPO correctly.

read:
https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html 



Tony Thigpen

R.S. wrote on 1/31/20 11:24 AM:

W dniu 31.01.2020 o 07:07, Timothy Sipples pisze:

Radoslaw Skorupka wrote:

To complement and clarify: when using physical tapes (*
see below) your RPO and RTO may be 36 hours or zero.

No, your RPO certainly won't be zero. A backup is a (hopefully useful)
representation of data as it existed historically, at some 
particular past


moment(s) in time. It takes some amount of time to run a backup -- 
let's

call that "minutes or longer" for working purposes. Backups run at
periodic intervals -- let's call that "hourly or less often" for 
working
purposes. Your backups, without something else, facilitate a best 
case RPO


that's as long/big as the maximum (worst case) time elapsed since the
start of your last good backup. That practically always(*) means a 
RPO of

"a couple hours or more."

A long/big RPO usually holds RTO back too, but there are a few rare
exceptions. On the other hand, it's quite possible to have a 
long/big RTO

with a RPO of zero.

(*) Why not "always"? Exotic, contrived exceptions might be 
possible, such


as custom software that synchronizes writes directly to local and 
remote

tape.


No, my RPO *is* zero. We do not talk about backup itself, which is 
...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media 
the backup is representation of historical data.
What I'm talking about is time delta between primary and secondary 
(local, remote) backup copies.
And again: some (typical?) modes of VTS replication are not 
synchronous, so there is time delta between local copy is closed (and 
marked as done) and remote copy is also finished. For duplex write in 
HSM both tapes are being written simultaneously, so end of backup job 
means you have both copies ready.


Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it 
*adds* the time to "historical representation". VTS non-synchronous 
mode adds the time also (much less). but HSM duplex write add zero.




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



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2019 r. wynosi 169.347.928 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 

Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Jeremy Nicoll]

On Tue, 4 Feb 2020, at 16:31, Robert Prins wrote:
> On 2020-02-04 14:39, Jeremy Nicoll wrote:

> > That's confusing.  Earlier you implied it was the execs (ie the logic, I 
> > assumed)
> > that was changing.  Now you say it's the data.  Have you got both logic and 
> > data
> > in the same file(s)?
> 
> 1) An input file, subject to frequent changes (at least once per month), 
> processed by a handful of execs/edit macros
> 
> 2) A handful of execs/edit macros that process the input file, with 
> some of them using some (potentially new, last new keyword was
> added on 2018-07-31) keywords from 1)
> 
> 3) A "master" exec/edit macro that reads 1), and updates the keyword tables 
> inside the "handful of others"
> 
> > Why don't you leave the execs alone and make them read their data from
> > external files, and just change those?
> 
> If my uncle had been a woman, she'd my aunt...

OK, fair enough... and if you were designing it now you'd probably choose
a different structure.

Couldn't the table inside the execs, that gets changed every so often, be put 
in 
a rexx external function, called by every exec/macro that needs to access the
data?  Or be vput into application profile variables, or even an ispf table? 

Whether that's practical depends on the size of the table(s), I suppose.



> >   I suppose I'd have chosen to read the existing definitons first and only 
> > call an
> > edit macro to update them if they needed to change.
> 
> Same difference, but in that case you would have to open the "handful 
> of others"  potentially twice!

So what? 

-- 
Jeremy Nicoll - my opinions are my own.

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

Couple of old dstrom blog posts of note

[Phil Smith III]

If nothing else, these are fun as reminders of dead companies/technologies:

How to get rid of your mainframe (c. 1996)

https://blog.strom.com/wp/?p=7568

 

which in turn references


How to turn off your mainframe, c.1995


https://blog.strom.com/wp/?p=3468 


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

Re: CSSMTP and @ symbols

[Paul Gilmartin]

On Tue, 4 Feb 2020 15:39:58 +, Ronald Kristel wrote:

>Was this not resolved with PI52704?
>
Looking at: https://www-01.ibm.com/support/docview.wss?uid=swg1PI52704
>
I don't see that this addresses the possibility that different users at
a single site may use different code pages.  Is the "AtSign parameter
option"  user-specific?

More general would be an "originating CCSID" option.

Regardless, the OP's problem occurred with a character in a quoted
string.  That should be immune to such syntax hyper-enforcement.
CSSMTP is superstitious about imputed rules at "domain.net".

I hate EBCDIC!


>On Tue, 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>>...
>>Some userids contain @ symbols and are sending with FROM addresses like 
>>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>>says it is valid,

-- gil

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

Re: CSSMTP and @ symbols

[Paul Gilmartin]

On Tue, 4 Feb 2020 13:59:08 +, Beesley, Paul wrote:

>That's what I thought. PMR raised.
> 
Looking at: https://tools.ietf.org/html/rfc5322#section-3.6.2
3.6.2.  Originator Fields
...
I wonder what happens if you use your "From:" field and a
JES-friendly "Sender:" field?


>On Tu , 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>>
>>Some userids contain @ symbols and are sending with FROM addresses like 
>>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>>says it is valid, but CSSMTP rejects it with:
>>501 5.1.7 JES Syntax error in mailbox

-- gil

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

Re: CSSMTP and @ symbols

[Ronald Kristel]

Was this not resolved with PI52704?

Kind Regards,

Ronald Kristel

From: IBM Mainframe Discussion List  on behalf of 
Beesley, Paul 
Sent: Tuesday, February 4, 2020 2:59:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CSSMTP and @ symbols

That's what I thought. PMR raised.

Best Regards
Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 04 February 2020 12:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP and @ symbols

On Tue, 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>
>We are converting from SMTP to CSSMTP, and leaving aside the headaches 
>resulting from trying to pick the correct code pages, we have an issue with 
>some FROM email addresses.
>Some userids contain @ symbols and are sending with FROM addresses like 
>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>says it is valid, but CSSMTP rejects it with:
>501 5.1.7 JES Syntax error in mailbox
>
>Any suggestions? If not we will have to change the code that generates the 
>emails and remove the @.
>
APAR.

— gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Atos, Atos Consulting and Canopy The Open Cloud Company are trading names used 
by the Atos group. The following trading entities are registered in England and 
Wales: Atos IT Services UK Limited (registered number 01245534), Atos 
Consulting Limited (registered number 04312380) and Canopy The Open Cloud 
Company Limited (registration number 08011902). The registered office for each 
is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT 
No. for each 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: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Robert Prins]

On 2020-02-04 14:39, Jeremy Nicoll wrote:

On Tue, 4 Feb 2020, at 13:19, Robert Prins wrote:

On 2020-02-04 10:56, Jeremy Nicoll wrote:

On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote:


It also updates the change-logs in each of the affected execs, and as
we keep a few generations of older versions around, it's irritating
that compares show that the change-log has been updated, but
that there are no other changes.


So "it also updates the change-logs in each of the affected execs"
statement is incorrect.   They weren't 'affected execs'.

Why on earth are you updating change-logs with (in effect) "no change"
statements?

Why don't you stop inserting pointless change-log entries ... then you
won't have the 'compare' problem?


The input file for the affected execs does change, but the changes may not
affect all of the REXX execs/edit macros that are used to process its contents.
The "master" exec/edit macro (it's both) just extracts all the relevant data,
and passes it on to the various per-exec/edit macro subroutines. It has no clue
whether the data to be processed by any of these other exec/edit macros has
changed.


That's confusing.  Earlier you implied it was the execs (ie the logic, I 
assumed)
that was changing.  Now you say it's the data.  Have you got both logic and data
in the same file(s)?


1) An input file, subject to frequent changes (at least once per month), 
processed by a handful of execs/edit macros


2) A handful of execs/edit macros that process the input file, with some of them 
using some (potentially new, last new keyword was added on 2018-07-31) keywords 
from 1)


3) A "master" exec/edit macro that reads 1), and updates the keyword tables 
inside the "handful of others"



Why don't you leave the execs alone and make them read their data from
external files, and just change those?


If my uncle had been a woman, she'd my aunt...

The code in some of the "handful of others" goes back to 1992, the "master" exec 
was added as a quick hack in 2005, as manually updating the "handful of others" 
was error-prone.



The, until yesterday, code would willy-nilly copy the new data, whether changed
or not, into the member, and update the change-log. What I wanted to do was to
just insert the data, do a "COMPARE *", and then either do a "cancel", if there
were no changes...


  I suppose I'd have chosen to read the existing definitons first and only call 
an
edit macro to update them if they needed to change.


Same difference, but in that case you would have to open the "handful of others" 
potentially twice!


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Jeremy Nicoll]

On Tue, 4 Feb 2020, at 13:19, Robert Prins wrote:
> On 2020-02-04 10:56, Jeremy Nicoll wrote:
> > On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote:
> > 
> >> It also updates the change-logs in each of the affected execs, and as
> >> we keep a few generations of older versions around, it's irritating
> >> that compares show that the change-log has been updated, but
> >> that there are no other changes.
> > 
> > So "it also updates the change-logs in each of the affected execs"
> > statement is incorrect.   They weren't 'affected execs'.
> > 
> > Why on earth are you updating change-logs with (in effect) "no change"
> > statements?
> > 
> > Why don't you stop inserting pointless change-log entries ... then you
> > won't have the 'compare' problem?
> 
> The input file for the affected execs does change, but the changes may not 
> affect all of the REXX execs/edit macros that are used to process its 
> contents. 
> The "master" exec/edit macro (it's both) just extracts all the relevant data, 
> and passes it on to the various per-exec/edit macro subroutines. It has no 
> clue 
> whether the data to be processed by any of these other exec/edit macros has 
> changed.

That's confusing.  Earlier you implied it was the execs (ie the logic, I 
assumed) 
that was changing.  Now you say it's the data.  Have you got both logic and data
in the same file(s)?

Why don't you leave the execs alone and make them read their data from 
external files, and just change those? 


> The, until yesterday, code would willy-nilly copy the new data, whether 
> changed 
> or not, into the member, and update the change-log. What I wanted to do was 
> to 
> just insert the data, do a "COMPARE *", and then either do a "cancel", if 
> there 
> were no changes...

 I suppose I'd have chosen to read the existing definitons first and only call 
an 
edit macro to update them if they needed to change.

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: CSSMTP and @ symbols

[Beesley, Paul]

That's what I thought. PMR raised.

Best Regards
Paul

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 04 February 2020 12:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSSMTP and @ symbols

On Tue, 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>
>We are converting from SMTP to CSSMTP, and leaving aside the headaches 
>resulting from trying to pick the correct code pages, we have an issue with 
>some FROM email addresses.
>Some userids contain @ symbols and are sending with FROM addresses like 
>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>says it is valid, but CSSMTP rejects it with:
>501 5.1.7 JES Syntax error in mailbox
>
>Any suggestions? If not we will have to change the code that generates the 
>emails and remove the @.
>
APAR.

— gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Atos, Atos Consulting and Canopy The Open Cloud Company are trading names used 
by the Atos group. The following trading entities are registered in England and 
Wales: Atos IT Services UK Limited (registered number 01245534), Atos 
Consulting Limited (registered number 04312380) and Canopy The Open Cloud 
Company Limited (registration number 08011902). The registered office for each 
is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT 
No. for each 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

Re: CSSMTP and @ symbols

[Paul Gilmartin]

On Tue, 4 Feb 2020 12:03:52 +, Beesley, Paul wrote:
>
>We are converting from SMTP to CSSMTP, and leaving aside the headaches 
>resulting from trying to pick the correct code pages, we have an issue with 
>some FROM email addresses.
>Some userids contain @ symbols and are sending with FROM addresses like 
>"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 
>says it is valid, but CSSMTP rejects it with:
>501 5.1.7 JES Syntax error in mailbox
>
>Any suggestions? If not we will have to change the code that generates the 
>emails and remove the @.
>
APAR.

— gil

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

Linear Datasets

[SUBSCRIBE IBM-MAIN Anonymous]

Hi All,

I have a TASK-A that attaches TASK-B, and then waits for TASK-B to complete. 
TASK-B does the following,

1. Dynamically allocate a linear dataset.
2. Issue "DIV IDENTIFY" for the allocated DDNAME.
3. Issue "DIV ACCESS", and then "DIV MAP".

I believe at the end of TASK-B, I need not "UNMAP", "UNACCESS", "UNIDENTIFY", 
and deallocate the linear dataset as it will automatically be done as part of 
the task clean-up. Please let me know if my understanding is correct.

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

zPDT and containers

[Willy Jensen]

Hi,
anyone have any info on how to deploy zPDT in a Docker container? I have tried 
to seach the net and IBM's Internet Library, but no luck so far.

Willy

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

Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Robert Prins]

On 2020-02-04 10:56, Jeremy Nicoll wrote:

On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote:


It also updates the change-logs in each of the affected execs, and as
we keep a few generations of older versions around, it's irritating
that compares show that the change-log has been updated, but
that there are no other changes.


So "it also updates the change-logs in each of the affected execs"
statement is incorrect.   They weren't 'affected execs'.

Why on earth are you updating change-logs with (in effect) "no change"
statements?

Why don't you stop inserting pointless change-log entries ... then you
won't have the 'compare' problem?


The input file for the affected execs does change, but the changes may not 
affect all of the REXX execs/edit macros that are used to process its contents. 
The "master" exec/edit macro (it's both) just extracts all the relevant data, 
and passes it on to the various per-exec/edit macro subroutines. It has no clue 
whether the data to be processed by any of these other exec/edit macros has 
changed.


The, until yesterday, code would willy-nilly copy the new data, whether changed 
or not, into the member, and update the change-log. What I wanted to do was to 
just insert the data, do a "COMPARE *", and then either do a "cancel", if there 
were no changes, or call a common subroutine to update the change-log.


Given that the "COMPARE" command doesn't seem to return its messages in the 
designated variables, I have for now resorted to comparing every line of the 
block-of-lines-to-be-replaced with its new version, and only when that tells me 
that there are any changes I will replace the old lines with the new ones, and 
update the change-log.


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

CSSMTP and @ symbols

[Beesley, Paul]

Hello

We are converting from SMTP to CSSMTP, and leaving aside the headaches 
resulting from trying to pick the correct code pages, we have an issue with 
some FROM email addresses.
Some userids contain @ symbols and are sending with FROM addresses like 
"CCC.@DSS99"@domain.net. SMTP allowed this and RFC 5322 says 
it is valid, but CSSMTP rejects it with:
501 5.1.7 JES Syntax error in mailbox

Any suggestions? If not we will have to change the code that generates the 
emails and remove the @.

Paul

Atos, Atos Consulting and Canopy The Open Cloud Company are trading names used 
by the Atos group. The following trading entities are registered in England and 
Wales: Atos IT Services UK Limited (registered number 01245534), Atos 
Consulting Limited (registered number 04312380) and Canopy The Open Cloud 
Company Limited (registration number 08011902). The registered office for each 
is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA.  The VAT 
No. for each 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

Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Jeremy Nicoll]

On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote:

> It also updates the change-logs in each of the affected execs, and as 
> we keep a few generations of older versions around, it's irritating 
> that compares show that the change-log has been updated, but 
> that there are no other changes.

So "it also updates the change-logs in each of the affected execs"
statement is incorrect.   They weren't 'affected execs'.

Why on earth are you updating change-logs with (in effect) "no change"
statements?

Why don't you stop inserting pointless change-log entries ... then you 
won't have the 'compare' problem?

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?

[Robert Prins]

On 2020-02-03 21:52, Bob Bridges wrote:

I've never used the COMPARE command.  (Never used MACRO_MSG, either.)  What
message were you expecting from COMPARE?


"Files are the same"

or of course the message that tells me they're not. It would allow me to cancel 
the update that in fact isn't an update, there's a "master" REXX exec that fires 
off updates of a lot of other execs and edit macros if some key file is changed.


It also updates the change-logs in each of the affected execs, and as we keep a 
few generations of older versions around, it's irritating that compares show 
that the change-log has been updated, but that there are no other changes. For 
now I've worked around it by comparing the (relatively) small number of 
lines-to-be changed with what's already there, and cancelling the update if they 
are the same.


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html
 > -Original Message-

From: ispf-l-l...@nd.edu [mailto:ispf-l-l...@nd.edu] On Behalf Of Robert Prins
Sent: Monday, February 3, 2020 09:11

I've been using this for ages, and in case you've never heard of it:

MACRO_MSG Set or Query the Macro Message switch

The MACRO_MSG assignment statement sets or retrieves the value of the
macro_msg switch, which controls whether macro processing delivers ISPF
messages to the macro.

Syntax

  >>--ISREDIT--(varname)-- = --MACRO_MSG--><

   +-ON--+
  >>--ISREDIT--MACRO_MSG-- = --+-+><
   +-OFF-+

varname The name of a variable containing the setting of MACRO_MSG.

ON  ISPF messages generated by macro commands are formatted.
OFF ISPF messages are not formatted.

Description

The MACRO_MSG assignment statement sets a switch for subsequent macro
processing. When set ON, any message that is generated by a macro command
is formatted and made available in variables in ZEDILMSG, ZEDISMSG, and
ZEDMSGNO.

This is a diagnostic switch and should only be used to extract messages as
required. Macros that perform operations on many edit lines may experience
a performance degradation if this switch is ON.

Return codes

0   Normal completion
20  Severe error

I now wanted to use it to get at the message set by the "COMPARE" command, as
that just returns RC=0, no matter (differences or no differences) what, but in
this case all three above mentioned variables come back as 8-character blank
strings. Am I doing something wrong, or is this a bug?

Replies please to IBM-MAIN only (I cross-posted this also to ISPF-L)



--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: Phases of Project in Mainframe

[Parwez Hamid]

Agreed, the SAPR would have been ideal for creating a 'customised' project 
plan. Spent  many hours, both as a reviewer of the draft versions and using it 
as a project planning doc . I believe its no longer created - well not in its 
original form 

Regards

Parwez Hamid​


From: IBM Mainframe Discussion List  on behalf of 
Edward Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu>
Sent: 04 February 2020 00:06
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Phases of Project in Mainframe

What happened to SAPR? It was in essence the project plan from soup to nuts. 
Environmental, hardware changes, software requirements, ISV levels, backout and 
assignment to persons responsible.

In a message dated 2/3/2020 6:01:30 AM Central Standard Time, 
parwez_ha...@hotmail.com writes:
I am sure there are other tasks and these will again depend on the experience 
and skill level of those who are doing the 'installation of or migration to the 
z15'

A combination of the the following:

z15 Redbook (SG24-8860) and the z15 Installation Manual for Physical Planning 
(GC28-7002) may help you in creating a Project Plan.

--
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: Manuals for CA-VOLLIE?

[Sean Gleann]

"...It is 1000% better than the IBM VSE offering (name escapes me)"
It's 'ICCF' - but I really had to hunt for *that* particular brain cell.
I remember getting myself into trouble with my manager when recovering from
forgetting my password.
I dumped the first track of the ICCF VSAM(?), and there were all the
passwords, in plain text!
Hopefully that was changed in later days.

Regards
Sean

On Tue, 4 Feb 2020 at 02:09, Wayne Bickerdike  wrote:

> That's a blast from the past.
> It does run as a CICS transaction (Normally OLLE).
>
> It is 1000% better than the IBM VSE offering (name escapes me).
>
> In architecture it's not unlike ROSCOE, runs very lean and mean. All
> the members are contained within a single VSAM cluster which is
> formatted and then has 3 char lib prefixes and 8 char names similar to
> a PDS. eg JCL.MASTJOB1.
>
> It also has a crude form of security, defined in a macro assembler
> module. This determines what you can see and do. A very naughty
> programmer substituted his own version and when we found out, I
> substituted yet another module that blasted ***violation*** on the
> console. The guy in question (Kevin Parker where are you now?) crapped
> his pants when he realised he'd been rumbled. Had an entertaining
> dressing down meeting with him.
>
> From memory, I belive you use the "l" command (list) to bring up a
> member in an editor panel.
>
> It has a submit command (I think sub?) and has access to the Power
> spool to fetch output.
>
> It's been 30 years since I last saw Vollie :)
>
> On 2/4/20, Bernd Oppolzer  wrote:
> > great, thank you, I will have to ask my customer, if we can have access
> > to this site.
> > Thanks, kind regards
> >
> > Bernd
> >
> >
> > Am 03.02.2020 um 20:51 schrieb Frank Swarbrick:
> >> I don't have a Broadcom logon, but did you try this page?
> >>
> https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-miscellaneous/legacy_bookshelves_and_pdfs/bookshelves_and_pdfs/bookshelves/ca-vollie-for-z-vse.html
> >>
> >> 
> >> From: IBM Mainframe Discussion List  on
> behalf
> >> of Bernd Oppolzer 
> >> Sent: Monday, February 3, 2020 11:25 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU 
> >> Subject: Manuals for CA-VOLLIE?
> >>
> >> In my new project assignment, I have to use a tool called VOLLIE (from
> >> CA), which is used to modify (edit)
> >> VSE libraries and prepare compile and test jobs for VSE and COBOL-CICS
> >> programs etc.
> >>
> >> No VM in this installation. VOLLIE seems to be a CICS transaction.
> >>
> >> Is there a manual for CA-VOLLIE, which can be shared, for example PDF
> >> format?
> >> No match when using the well-known search engines.
> >>
> >> Thanks and regards
> >>
> >> Bernd
> >>
> >> --
> >> 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
> > --
> >
> > Oppolzer-Informatik
> > Dipl. Inf. Bernd Oppolzer
> > Bärenhofstraße 23
> > 70771 Leinfelden-Echterdingen
> > —
> > Tel.: +49 711 7949591
> > priv.: +49 711 7949590
> > mobil: +49 151 75005359
> > eMail: bernd.oppol...@t-online.de 
> > Web: http://bernd-oppolzer.de/job.htm
> > —
> > Für Umsatzsteuerzwecke:
> > SteuerNr.: 97 076 / 29921
> > USt-ID-Nr.: DE 147 700 393
> > —
> > Oppolzer-Informatik 1983 - 2019
> > 36years of experience in computer science**
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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