Re: Why LE taking Transaction Dump rather than CEEDUMP?

[Mario Bezzi]

If you have access to IPCS, an  IP VERBX LEDATA 'ALL' command will give 
you a formatted dump similar to the CEEDUMP you are used to.


mario

On 1/13/21 5:58 PM, Seymour J Metz wrote:

First, without a functioning IPCS all choices are bad. I would probably take a 
SYSUDUMP or SYSABEND, look at the RB chains and look at the trace table, but 
browsing that from SPOOL is a lot less convenient from IPCS and I don't know 
whether your shop is including the trace table.

Have you done anything to increase CPU or virtual storage consumption? Is there 
anything unusual in the log?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Wednesday, January 13, 2021 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Why LE taking Transaction Dump rather than CEEDUMP?

I have a medium-sized C++ application under development (conventional
batch). I have gotten fairly used to and fairly fond of debugging S0C4's and
the like with the LE CEEDUMP (which pinpoints that sort of error down to the
source code file and line number).

Suddenly -- and I can't quite define "suddenly" ("I didn't change anything")
-- ABENDs have started instead producing a Transaction Dump, which I find
much less convenient, especially since at the moment Dallas has IPCS hosed
up and unusable on our machine. (If I code a SYSUDUMP DD I also get one of
those, which is even less convenient for higher level language problems.)

Why would LE start issuing Transaction Dumps rather than CEEDUMPs? There are
no TRAP(OFF) or anything similar in the source code or in the LE runtime
options. A CEEDUMP DD statement makes no difference. There is no ESTAE
issued by my code. How the heck do I get LE back to a CEEDUMP, or what the
heck should I be looking for?

z/OS V2R4

+CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
blah.blah.blah
IGD100I 03DE ALLOCATED TO DDNAME SYS3 DATACLAS ()

IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO blah.blah.blah

+CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.

+CEE0374C CONDITION=CEE3204S TOKEN=00030C84 59C3C5C5   455

   WHILE RUNNING PROGRAM myprogrm

   AT THE TIME OF INTERRUPT

   PSW 078D1400 9AE4AC66

   GPR 0-3 FD09 FD09 1B5D522C 1AE4ABF2

   GPR 4-7 1AE4ACF0 1AE541C0 1AE541C0 1AE541D3

   GPR 8-B 1B584878 0008 1B5BD2AC 1B5E68D0

   GPR C-F 1B5771D8 1B584A58 1B5F1FAD 1B584A28


Charles

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

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



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

Re: Hogan Financial Systems. It is a banking system

[Edgington, Jerry]

When I worked for banks, several companies were still using Hogan for the DDA 
and Savings. One of them is in the Top 10 of the largest bank in the United 
States.  That might be a good place to start.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
 
Sent: Thursday, January 14, 2021 2:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FW: Hogan Financial Systems. It is a banking system

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Hello,

I have been contacted by a company with the below request.  Please contact me 
if interested.

 

Please rack your brain for any one that can teach Hogan Financial Systems.
It is a banking system.

 

Thanks,

David Mingee  ming...@prodigy.net  

 

 

 

 


--
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: FW: Hogan Financial Systems. It is a banking system

[Joe Monk]

https://www.dxc.technology/banking/offerings/11090/48573-hogan_systems

those are the people to contact

Joe

On Thu, Jan 14, 2021 at 1:42 AM   
wrote:

> Hello,
>
> I have been contacted by a company with the below request.  Please contact
> me if interested.
>
>
>
> Please rack your brain for any one that can teach Hogan Financial Systems.
> It is a banking system.
>
>
>
> Thanks,
>
> David Mingee  ming...@prodigy.net 
>
>
>
>
>
>
>
>
>
>
> --
> 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: Why LE taking Transaction Dump rather than CEEDUMP?

[Seymour J Metz]

The OP wrote "at the moment Dallas has IPCS hosed  up and unusable on our 
machine." So the questions is what the choices are until it's fixed.

FWIW, I would certainly agree that problem analysis is much easier with IPCS, 
and I am normally very critical of the use of 19th Century formatted dumps.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mario Bezzi [mbe...@tiscali.it]
Sent: Thursday, January 14, 2021 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why LE taking Transaction Dump rather than CEEDUMP?

If you have access to IPCS, an  IP VERBX LEDATA 'ALL' command will give
you a formatted dump similar to the CEEDUMP you are used to.

mario

On 1/13/21 5:58 PM, Seymour J Metz wrote:
> First, without a functioning IPCS all choices are bad. I would probably take 
> a SYSUDUMP or SYSABEND, look at the RB chains and look at the trace table, 
> but browsing that from SPOOL is a lot less convenient from IPCS and I don't 
> know whether your shop is including the trace table.
>
> Have you done anything to increase CPU or virtual storage consumption? Is 
> there anything unusual in the log?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Charles Mills [charl...@mcn.org]
> Sent: Wednesday, January 13, 2021 9:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Why LE taking Transaction Dump rather than CEEDUMP?
>
> I have a medium-sized C++ application under development (conventional
> batch). I have gotten fairly used to and fairly fond of debugging S0C4's and
> the like with the LE CEEDUMP (which pinpoints that sort of error down to the
> source code file and line number).
>
> Suddenly -- and I can't quite define "suddenly" ("I didn't change anything")
> -- ABENDs have started instead producing a Transaction Dump, which I find
> much less convenient, especially since at the moment Dallas has IPCS hosed
> up and unusable on our machine. (If I code a SYSUDUMP DD I also get one of
> those, which is even less convenient for higher level language problems.)
>
> Why would LE start issuing Transaction Dumps rather than CEEDUMPs? There are
> no TRAP(OFF) or anything similar in the source code or in the LE runtime
> options. A CEEDUMP DD statement makes no difference. There is no ESTAE
> issued by my code. How the heck do I get LE back to a CEEDUMP, or what the
> heck should I be looking for?
>
> z/OS V2R4
>
> +CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET:
> blah.blah.blah
> IGD100I 03DE ALLOCATED TO DDNAME SYS3 DATACLAS ()
>
> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO blah.blah.blah
>
> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP.
>
> +CEE0374C CONDITION=CEE3204S TOKEN=00030C84 59C3C5C5   455
>
>WHILE RUNNING PROGRAM myprogrm
>
>AT THE TIME OF INTERRUPT
>
>PSW 078D1400 9AE4AC66
>
>GPR 0-3 FD09 FD09 1B5D522C 1AE4ABF2
>
>GPR 4-7 1AE4ACF0 1AE541C0 1AE541C0 1AE541D3
>
>GPR 8-B 1B584878 0008 1B5BD2AC 1B5E68D0
>
>GPR C-F 1B5771D8 1B584A58 1B5F1FAD 1B584A28
>
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Progam directory AD/Cycle C/370

[Seymour J Metz]

> I have added the full

No, it's missing the first decade. In fact, the pictured manual cover lists 
compilers that are not in the table.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Dan 
Zhang [zhang...@cn.ibm.com]
Sent: Thursday, January 14, 2021 1:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Progam directory AD/Cycle C/370

I have added the full IBM COBOL compiler version table on the IBM COBOL wiki 
page at 
https://secure-web.cisco.com/1x78Cl38jSaZo9L70czHtjh_5iZB1e-fObPkEHhox4FxpSdPuPMYpP1llCpdhCO1YOxPytRXmQ0Z2FHl6ZqCLmkwaw4oZjEF1lGkzz9j8cw7VdCIW3CPGw_7zUho43hMJRgUDL6-7mPPjEg7LdPvOVAfs43k5Db2dj8TMvBPUC36K-udx0BvywKAPuJjrMgWYygxyRRs_lQTnLcenw020gFbyu61vCQUvWkXAYm1r56WfBAfwrTczCnqP3bwuUlTWPhhsg7vGGPN0kOmqWom_urwDMrZj2dYy125Dm05Zr2bA4R0A10ZmXI8C1m73upzrD0h_aWXEsVxVVHHJK6sZSeewLoJYOND0763layP0RuAVe0qWpsBm1i5JbD37f-5JgGXopK-9EUQJmjXsGy-PmnAOXcDsj8bu01jUE9bSiPVvbblGkR_XZz7Hq06II9Li/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIBM_COBOL.

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

OS/360 COBOL life cycle dates?

[Seymour J Metz]

The wiki article [[IBM COBOL]] has a table that is missing all of

360S-C0-503 COBOL (E)
360S-CB-524 COBOL (F)
360S-CB-545 COBOL (U)
5734-CB1 OS FULL AMERICAN NATIONAL STANDARD COBOL Versions 1-3
5734-CB2 OS FULL AMERICAN NATIONAL STANDARD COBOL Version 4, 5

Does anybody know the GA and EOS dates? Thanks.


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

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

Re: CCSID descriptions

[Paul Gilmartin]

On Wed, 13 Jan 2021 09:04:03 -0600, Norbert Friemel wrote:

>On Wed, 13 Jan 2021 08:58:49 +, Windt, W.K.F. van der (Fred) wrote:
>>
>>The IBM website used to have complete descriptions of every CCSID including a 
>>complete overview of every character (glyph) in that CCSID with it's 
>>encoding. Simply googling "IBM CCSID 1140" would quickly get you to the page 
>>of CCSID 1140. The CCSID was in the url so you could quickly switch to 
>>another CCSID by changing the url. But with the change to Knowledge Center I 
>>can't find those pages anymore... Does anybody know where the CCCSID 
>>descriptions have gone?
>
>Not a website but ... 
>ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/
> 
That would benefit greatly from an index mapping countries to CCSIDs.


On Wed, 13 Jan 2021 09:16:08 -0800, Tom Brennan wrote:

>After the last time things were changed, I've been going here:
>https://www.ibm.com/support/knowledgecenter/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference02.htm
>
Grrr... both of those are images rather than text, so I can't simply open,
e.g., File:CP01154.pdf, type "Ж" in a search box, and see it highlighted
at coordinate x'EC'. 

-- gil

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

Re: OS/360 COBOL life cycle dates?

[Joe Monk]

COBOL E and F are the  same compiler, but with different features enabled.
F has more features than  E. Both were available in 1964.

Joe

On Thu, Jan 14, 2021 at 8:05 AM Seymour J Metz  wrote:

> The wiki article [[IBM COBOL]] has a table that is missing all of
>
> 360S-C0-503 COBOL (E)
> 360S-CB-524 COBOL (F)
> 360S-CB-545 COBOL (U)
> 5734-CB1 OS FULL AMERICAN NATIONAL STANDARD COBOL Versions 1-3
> 5734-CB2 OS FULL AMERICAN NATIONAL STANDARD COBOL Version 4, 5
>
> Does anybody know the GA and EOS dates? Thanks.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Starting a started task from a started task

[Horne, Jim]

Hi all,

This may sound like a stupid question but is there a way to start a second 
started task from a running one when the currently running one completes.  I 
know how to submit a batch job from a final step of a started task but I don't 
know how to do the same sort of thing to initiate another started task.

I appreciate any help I can get,
Jim Horne

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: Why LE taking Transaction Dump rather than CEEDUMP?

[Charles Mills]

USER COMPLETION CODE=4087 REASON CODE=

Which points to the incredibly helpful

X'00' (0)
Language Environment condition manager was in control at the time of the 
condition.

The blasted "user" ABENDs from IBM products drive me nuts. System completion 
codes -- you know where to look them up. Every "user" ABEND code is in a 
different place. 

BTW, I think the "real" problem is the CONDITION=CEE3204S which I looked up and 
indicated a S0C4 or something like that. I think the U4087 is due to ABEND 
recursion, and it and its reason code have little to do with the original 
problem.

The original problem is that I whacked a BUNCH of memory. The error was a 
memset(buffer+len, ' ', lrecl-len); That looks pretty good, but when lrecl is 
80 and len is 85 it whacks a whole bunch of memory. Pretty much a guaranteed 
S0C4.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Wednesday, January 13, 2021 5:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why LE taking Transaction Dump rather than CEEDUMP?

There should be a reason code 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceea900/cs00015.htm.

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

Re: Starting a started task from a started task

[Mike Schwab]

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa900/iea3a9_Description26.htm
XCTL or XCTLX.  Branches to another program.  Returns to the caller of
the program issuing XCTL(X).

On Thu, Jan 14, 2021 at 8:58 AM Horne, Jim  wrote:
>
> Hi all,
>
> This may sound like a stupid question but is there a way to start a second 
> started task from a running one when the currently running one completes.  I 
> know how to submit a batch job from a final step of a started task but I 
> don't know how to do the same sort of thing to initiate another started task.
>
> I appreciate any help I can get,
> Jim Horne
> 
> NOTICE: All information in and attached to the e-mails below may be 
> proprietary, confidential, privileged and otherwise protected from improper 
> or erroneous disclosure. If you are not the sender's intended recipient, you 
> are not authorized to intercept, read, print, retain, copy, forward, or 
> disseminate this message. If you have erroneously received this 
> communication, please notify the sender immediately by phone (704-758-1000) 
> or by e-mail and destroy all copies of this message electronic, paper, or 
> otherwise. By transmitting documents via this email: Users, Customers, 
> Suppliers and Vendors collectively acknowledge and agree the transmittal of 
> information via email is voluntary, is offered as a convenience, and is not a 
> secured method of communication; Not to transmit any payment information E.G. 
> credit card, debit card, checking account, wire transfer information, 
> passwords, or sensitive and personal information E.G. Driver's license, DOB, 
> social security, or any other information the user wishes to remain 
> confidential; To transmit only non-confidential information such as plans, 
> pictures and drawings and to assume all risk and liability for and indemnify 
> Lowe's from any claims, losses or damages that may arise from the transmittal 
> of documents or including non-confidential information in the body of an 
> email transmittal. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Starting a started task from a started task

[ITschak Mugzach]

Started tasks are started by a console command START  (S ). There
are more variations to the command, but this is the basic one. If you want
the same task run in parallel with the same tak, add a name (S .yyy).

ITschak


ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Thu, Jan 14, 2021 at 5:06 PM Mike Schwab  wrote:

>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa900/iea3a9_Description26.htm
> XCTL or XCTLX.  Branches to another program.  Returns to the caller of
> the program issuing XCTL(X).
>
> On Thu, Jan 14, 2021 at 8:58 AM Horne, Jim  wrote:
> >
> > Hi all,
> >
> > This may sound like a stupid question but is there a way to start a
> second started task from a running one when the currently running one
> completes.  I know how to submit a batch job from a final step of a started
> task but I don't know how to do the same sort of thing to initiate another
> started task.
> >
> > I appreciate any help I can get,
> > Jim Horne
> > 
> > NOTICE: All information in and attached to the e-mails below may be
> proprietary, confidential, privileged and otherwise protected from improper
> or erroneous disclosure. If you are not the sender's intended recipient,
> you are not authorized to intercept, read, print, retain, copy, forward, or
> disseminate this message. If you have erroneously received this
> communication, please notify the sender immediately by phone (704-758-1000)
> or by e-mail and destroy all copies of this message electronic, paper, or
> otherwise. By transmitting documents via this email: Users, Customers,
> Suppliers and Vendors collectively acknowledge and agree the transmittal of
> information via email is voluntary, is offered as a convenience, and is not
> a secured method of communication; Not to transmit any payment information
> E.G. credit card, debit card, checking account, wire transfer information,
> passwords, or sensitive and personal information E.G. Driver's license,
> DOB, social security, or any other information the user wishes to remain
> confidential; To transmit only non-confidential information such as plans,
> pictures and drawings and to assume all risk and liability for and
> indemnify Lowe's from any claims, losses or damages that may arise from the
> transmittal of documents or including non-confidential information in the
> body of an email transmittal. Thank you.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

JCL to tar USS directory

[Bill Giannelli]

can anyone provide JCL to tar a USS directory?
thanks
Bill

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

Re: CCSID descriptions

[Norbert Friemel]

On Thu, 14 Jan 2021 08:17:23 -0600, Paul Gilmartin wrote:

>On Wed, 13 Jan 2021 09:04:03 -0600, Norbert Friemel wrote:
>
>>On Wed, 13 Jan 2021 08:58:49 +, Windt, W.K.F. van der (Fred) wrote:
>>>
>>>The IBM website used to have complete descriptions of every CCSID including 
>>>a complete overview of every character (glyph) in that CCSID with it's 
>>>encoding. Simply googling "IBM CCSID 1140" would quickly get you to the page 
>>>of CCSID 1140. The CCSID was in the url so you could quickly switch to 
>>>another CCSID by changing the url. But with the change to Knowledge Center I 
>>>can't find those pages anymore... Does anybody know where the CCCSID 
>>>descriptions have gone?
>>
>>Not a website but ... 
>>ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/
>> 
>That would benefit greatly from an index mapping countries to CCSIDs.
>
>

The old website is (partly) archived @ 

I don't know how usable it is

Norbert Friemel

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

Re: Starting a started task from a started task

[R.S.]

W dniu 14.01.2021 o 15:57, Horne, Jim pisze:

Hi all,

This may sound like a stupid question but is there a way to start a second 
started task from a running one when the currently running one completes.  I 
know how to submit a batch job from a final step of a started task but I don't 
know how to do the same sort of thing to initiate another started task.


It depends.
The simplest way is to use JCL facilities.
Your started task can have last step, which can submit batch job, which 
in turn can issue a COMMAND, the command can be START STC.

A little bit Ruby Goldberg, but it works.

Other way is to use one of the tools from CBT to issue a command. In 
that scenario you last step in started task run the program. Program 
parameters contain you command - START STC.


I would also think about SystemREXX, but I have to solution here.

HTH

--
Radoslaw Skorupka
Lodz, Poland





==

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. Prosta 18, 00-850 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.2020 r. wynosi 
169.401.468 złotych.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


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. Prosta 18, 00-850 
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: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: Starting a started task from a started task

[Seymour J Metz]

XCTL is not what  the OP asked for. 

Jim needs to issue a start. I don't know his authorization status, environment 
or language.


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



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Thursday, January 14, 2021 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Starting a started task from a started task

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieaa900/iea3a9_Description26.htm
XCTL or XCTLX.  Branches to another program.  Returns to the caller of
the program issuing XCTL(X).

On Thu, Jan 14, 2021 at 8:58 AM Horne, Jim  wrote:
>
> Hi all,
>
> This may sound like a stupid question but is there a way to start a second 
> started task from a running one when the currently running one completes.  I 
> know how to submit a batch job from a final step of a started task but I 
> don't know how to do the same sort of thing to initiate another started task.
>
> I appreciate any help I can get,
> Jim Horne
> 
> NOTICE: All information in and attached to the e-mails below may be 
> proprietary, confidential, privileged and otherwise protected from improper 
> or erroneous disclosure. If you are not the sender's intended recipient, you 
> are not authorized to intercept, read, print, retain, copy, forward, or 
> disseminate this message. If you have erroneously received this 
> communication, please notify the sender immediately by phone (704-758-1000) 
> or by e-mail and destroy all copies of this message electronic, paper, or 
> otherwise. By transmitting documents via this email: Users, Customers, 
> Suppliers and Vendors collectively acknowledge and agree the transmittal of 
> information via email is voluntary, is offered as a convenience, and is not a 
> secured method of communication; Not to transmit any payment information E.G. 
> credit card, debit card, checking account, wire transfer information, 
> passwords, or sensitive and personal information E.G. Driver's license, DOB, 
> social security, or any other information the user wishes to remain 
> confidential; To transmit only non-confidential information such as plans, 
> pictures and drawings and to assume all risk and liability for and indemnify 
> Lowe's from any claims, losses or damages that may arise from the transmittal 
> of documents or including non-confidential information in the body of an 
> email transmittal. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

Re: JCL to tar USS directory

[R.S.]

W dniu 14.01.2021 o 16:00, Bill Giannelli pisze:

can anyone provide JCL to tar a USS directory?
thanks



//K10  EXEC PGM=BPXBATCH,PARM='SH tar parameterscd;ls'
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*

ls is redundant, it is just as example of second command within the step.

--
Radoslaw Skorupka
Lodz, Poland





==

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. Prosta 18, 00-850 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.2020 r. wynosi 
169.401.468 złotych.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


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. Prosta 18, 00-850 
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: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: JCL to tar USS directory

[R.S.]

W dniu 14.01.2021 o 16:00, Bill Giannelli pisze:

can anyone provide JCL to tar a USS directory?
thanks
Bill


Correction:
//K10  EXEC PGM=BPXBATCH,PARM='PGM /bin/tar -?'
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*

--
Radoslaw Skorupka
Lodz, Poland





==

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. Prosta 18, 00-850 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.2020 r. wynosi 
169.401.468 złotych.

Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z 
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które 
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną 
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w 
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo


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. Prosta 18, 00-850 
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: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

We are the controller of your personal data, which you provided in connection 
with correspondence with us. We process your data for purposes resulting from 
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in 
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.

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

Re: [EXTERNAL] Re: Starting a started task from a started task

[Horne, Jim]

And that's the problem, in a nutshell.  The reason I am looking to start 
another STC is that initiators may be down.  If I knew initiators would be up, 
I would just submit a batch job and call it done.  In fact, I do that today but 
want to avoid problems when initiators are not available.

Jim Horne


R.S. wrote:
It depends.
The simplest way is to use JCL facilities.
Your started task can have last step, which can submit batch job, which in turn 
can issue a COMMAND, the command can be START STC.
A little bit Ruby Goldberg, but it works.

Other way is to use one of the tools from CBT to issue a command. In that 
scenario you last step in started task run the program. Program parameters 
contain you command - START STC.

I would also think about SystemREXX, but I have to solution here.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: [EXTERNAL] Re: Starting a started task from a started task

[Seymour J Metz]

If you're authorized you can issue the command with MGCRE. For REXX scripts 
CONSOLE is convenient. You need the appropriate permissions.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Horne, Jim [jim.s.ho...@lowes.com]
Sent: Thursday, January 14, 2021 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Starting a started task from a started task

And that's the problem, in a nutshell.  The reason I am looking to start 
another STC is that initiators may be down.  If I knew initiators would be up, 
I would just submit a batch job and call it done.  In fact, I do that today but 
want to avoid problems when initiators are not available.

Jim Horne


R.S. wrote:
It depends.
The simplest way is to use JCL facilities.
Your started task can have last step, which can submit batch job, which in turn 
can issue a COMMAND, the command can be START STC.
A little bit Ruby Goldberg, but it works.

Other way is to use one of the tools from CBT to issue a command. In that 
scenario you last step in started task run the program. Program parameters 
contain you command - START STC.

I would also think about SystemREXX, but I have to solution here.


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

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

Re: [EXTERNAL] Re: Starting a started task from a started task

[Horne, Jim]

Thanks!  I had not thought about CONSOLE.  That will do the trick just fine!

Jim Horne
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz

If you're authorized you can issue the command with MGCRE. For REXX scripts 
CONSOLE is convenient. You need the appropriate permissions.

NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.

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

Re: Hogan Financial Systems. It is a banking system

[Phil Smith III]

Just to pile onto what Joe Monk said: Hogan was developed by Hogan Systems,
bought by Continuum in 1995. A year or so later, CSC bought Continuum. At
some point CSC rebranded Hogan to ConnectWise, but that never really "took".

 

And a couple of years ago, CSC and DXC (formerly HPE, formerly HP Global
Services, formerly EDS) basically merged (I think they used some other term)
and it seems to be back to being called "Hogan" again.

 

So all of the capitalized words above (except Joe and Monk, and I guess HP
Global Services/HPE/EDS) might be associated with Hogan in various contexts.
Figured this might reduce confusion. Or, I suppose, increase it.

 

...phsiii


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

CICS and COBOL DISPLAY UPON CONSOLE

[Frank Swarbrick]

I just accidentally did a DISPLAY UPON CONSOLE statement in a CICS program and 
was surprised that it actually worked.  The documentation seems to indicate 
that this is not supported.  Has something changed?  Is this supported or just 
"happens to work"?  Enterprise COBOL V6.2 and CICS V5.4.

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

Re: Starting a started task from a started task

[Binyamin Dissen]

On Thu, 14 Jan 2021 14:57:47 + "Horne, Jim"  wrote:

:>This may sound like a stupid question but is there a way to start a second 
started task from a running one when the currently running one completes.  I 
know how to submit a batch job from a final step of a started task but I don't 
know how to do the same sort of thing to initiate another started task.

I will ask the question that seems to have been missed.

What are you trying to do? Why specifically start a new STC? What is the
business case? Why not conditionally execute the next step?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: CICS and COBOL DISPLAY UPON CONSOLE

[Steve Horein]

As an automation administrator, please try to stick with DISPLAY UPON
SYSOUT.

On Thu, Jan 14, 2021 at 11:56 AM Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> I just accidentally did a DISPLAY UPON CONSOLE statement in a CICS program
> and was surprised that it actually worked.  The documentation seems to
> indicate that this is not supported.  Has something changed?  Is this
> supported or just "happens to work"?  Enterprise COBOL V6.2 and CICS V5.4.
>
> --
> 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

Bug in DFSORT? [WAS: Merging multiple records using DFSORT]

[Robert Prins]

On 2021-01-12 16:12, Robert Prins wrote:

I'm currently using this...


I've posted the question to , 
and someone came up with a really very elegant way of performing this task, but 
his solution, unlike the one I posted in the start of this thread, cannot handle 
data in a legacy format, which is a must, as the code to look at older results 
automagically invokes sort to convert members that contain split (into chunks of 
121 bytes) members into merged ones.


So I added some additional code that correctly processes the old data, but then 
I realised that instead of using my hack, it would be more useful to select a 
unique column in the second table that does not appear in the same format in the 
same place in the legacy data.


Fow what it's worth, and for those not willing to access the above post, the JCL 
I use is below:


//PRINOSOR JOB (PRINO),
// 'Test LW merge',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(2,0),
// NOTIFY=&SYSUID
//*
//MERGELW EXEC PGM=SORT
//*
//SYSOUTDD SYSOUT=*
//*
//SORTINDD DSN=&SYSUID..@@121.TEXT,  /* FB(121)
// DISP=SHR
//*
//SORTOUT   DD SYSOUT=*
//*
//SYSIN DD *
* Merge the LW file
*
* See: https://ibmmainframes.com/viewtopic.php?t=68044

  OPTION COPY
* 
* Put '0120' in columns 364-367

  INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)),

* Whatever   0120
* 
* Test column 9 for '+' or '|' OR column 41 for '+' or '|'
* - copy 365 ('1') to 364
* - add seqno to 367, for two records

IFTHEN=(WHEN=GROUP,BEGIN=(9,1,SS,EQ,C'+|',OR,41,1,SS,EQ,C'+|'),
  PUSH=(364:365,1,367:SEQ=1),RECORDS=2),

* T-1 / P-1  1121
* T-1 / P-2  1122
* 
* Test column 44 for '+' or '|'
* - copy 366 ('2') to 364
* - add seqno to 367, for three records

*!! CHANGE 44 below to 80 and things go wrong!!

IFTHEN=(WHEN=GROUP,BEGIN=(44,1,SS,EQ,C'+|'),
  PUSH=(364:366,1,367:SEQ=1),RECORDS=3),

* T-2 / P-1  2121
* T-2 / P-2  2122
* T-2 / P-3  2123
* 
* Test column column 367 for '1'
* - add columns 1-121 at column 122

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+1),
  PUSH=(122:1,121)),

* Whatever   0120
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-11122
* Whatever  T-1 / P-10120
* T-2 / P-1 T-2 / P-12121
* T-2 / P-2 T-2 / P-12122
* T-2 / P-3 T-2 / P-12123
* Whatever  T-2 / P-10120
* 
* Test column column 367 for '2'
* - add columns 1-121 at column 243

IFTHEN=(WHEN=GROUP,BEGIN=(367,1,ZD,EQ,+2),
  PUSH=(243:1,121))

* Whatever   0120  x 0...: 1,121
* T-1 / P-1 T-1 / P-11121
* T-1 / P-2 T-1 / P-1 T-1 / P-2  1122
* t-1 / P-1 t-1 / P-1 T-1 / P-2  1121  x 1..1: 122,1+1,121
* t-1 / P-2 t-1 / P-1 t-1 / P-1  1122
* Whatever  t-1 / P-1 t-1 / P-1  0120  x 0...: 1,121
* T-2 / P-1 T-2 / P-1 t-1 / P-1  2121
* T-2 / P-2 T-2 / P-1 T-2 / P-2  2122
* T-2 / P-3 T-2 / P-1 T-2 / P-2  2123  x 2..3: 122,121+243,121+1,121
* 

  OUTFIL FNAMES=(SORTOUT),
INCLUDE=((364,1,ZD,EQ,+0),OR,
 (364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),OR,
 (364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3)),

FTOV,VLTRIM=C' ',

IFTHEN=(WHEN=(364,1,ZD,EQ,+0),BUILD=(1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+1,AND,367,1,ZD,EQ,+2),
  BUILD=(122,121,1,121)),

IFTHEN=(WHEN=(364,1,ZD,EQ,+2,AND,367,1,ZD,EQ,+3),
  BUILD=(122,121,243,121,1,121))

The input file (@@121.text) is included (I hope) as a plain-text (58 lines, no 
trailing spaces) attachment, or can be scraped from 
 (with the JCL and 
expected output)


Paste it into an FB(121) dataset, paste the JCL, and submit it, and SYSOUT from 
SORT will show two merged tables, so far so good.


If you look at the input or, to make things a bit easier, the output, and then 
look at the second and third IFTHEN statements, the second tests for a '+'or '|' 
in columns 9 & 41, the third just checks for the same two characters in column 44.


I've not (yet) checked why the second IFTHEN uses two columns and the third 
IFTHEN only one column as the three columns checked are mutually exclusive, but...


column 44 is also present in the legacy data, so I thought, "Why not change that 
one into 80?" which is the next column in the second table that only contains 
'+

Re: CICS and COBOL DISPLAY UPON CONSOLE

[Gibney, Dave]

Happens to work. Not supported, in that it isn't a good idea. And, it quite 
likely stalled the entire CICS region for a very brief moment.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Horein
> Sent: Thursday, January 14, 2021 2:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CICS and COBOL DISPLAY UPON CONSOLE
> 
> As an automation administrator, please try to stick with DISPLAY UPON
> SYSOUT.
> 
> On Thu, Jan 14, 2021 at 11:56 AM Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
> 
> > I just accidentally did a DISPLAY UPON CONSOLE statement in a CICS
> program
> > and was surprised that it actually worked.  The documentation seems to
> > indicate that this is not supported.  Has something changed?  Is this
> > supported or just "happens to work"?  Enterprise COBOL V6.2 and CICS
> V5.4.
> >
> > --
> > 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: CICS and COBOL DISPLAY UPON CONSOLE

[Frank Swarbrick]

Thanks.


From: IBM Mainframe Discussion List  on behalf of 
Gibney, Dave 
Sent: Thursday, January 14, 2021 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: CICS and COBOL DISPLAY UPON CONSOLE

Happens to work. Not supported, in that it isn't a good idea. And, it quite 
likely stalled the entire CICS region for a very brief moment.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Steve Horein
> Sent: Thursday, January 14, 2021 2:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CICS and COBOL DISPLAY UPON CONSOLE
>
> As an automation administrator, please try to stick with DISPLAY UPON
> SYSOUT.
>
> On Thu, Jan 14, 2021 at 11:56 AM Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
>
> > I just accidentally did a DISPLAY UPON CONSOLE statement in a CICS
> program
> > and was surprised that it actually worked.  The documentation seems to
> > indicate that this is not supported.  Has something changed?  Is this
> > supported or just "happens to work"?  Enterprise COBOL V6.2 and CICS
> V5.4.
> >
> > --
> > 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: Code to verify LOGON password

[Bob Bridges]

It isn't just UACC(READ) or UID(*).  Why does ~anyone~ have read access to the 
database?  (To say nothing of update.)

At a client I served a while back, I pointed out that a lot of people had read 
access, and quite a few had update.  They argued that it was necessary so that 
their admins could do their jobs.  Apparently they believed that the admin 
needed update access to change permissions, create profiles etc.

Now, it happened that was a TSS shop.  But surely the answer is the same in 
RACF?  I don't need update (or even read) access to the RACF database; when I 
issue a RACF command, RACF determines whether I have the authority and then 
executes the command under the authority of its own ID, whichever one runs the 
STC.

My own rule (when I'm allowed my way) is that NO ONE has access to the 
database, except a system programmer doing migrations to a new version; for 
that purpose I'll grant the necessary access for a defined period, say two 
months, extendible upon request, but expiring automatically.

The Logica breakin, as I understand it, started with the theft of the password 
of an ID that had read access to the RACF database.  The bad guys then 
downloaded it and applied CRACF to it.  Forensic investigators afterward tested 
the same utility and were able to get 10 or 20 thousand passwords from it in 
the first day of running on an ordinary PC.  (Going by memory, but I think it's 
about right.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* We must picture Hell as a state where everyone is perpetually concerned 
about his own dignity and advancement, where everyone has a grievance, and 
where eveyone lives the deadly serious passions of envy, self-importance, and 
resentment.  -C S Lewis, preface to _The Screwtape Letters_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Monday, January 11, 2021 11:44

https://en.wikipedia.org/wiki/John_the_Ripper 

There is a downloadable plugin for RACF -- old RACF hashing only, I *think*.

No one "gives" their RACF DB to anyone (I would hope). The problem -- and 
everyone reading this who is not sure about their RACF DB should go check right 
now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I 
can download your RACF DB and attack it off-platform I can defeat any "revoke 
the userid after 'n' tries" that you have in place.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Monday, January 11, 2021 10:07

That's what we call brute force attack.
There is no way to protect against it ...or maybe there are some things to help.
1. Do not give your RACF db to hackers. Never

--- W dniu 11.01.2021 o 15:39, Tom Brennan pisze:
> Isn't there a program someone wrote (talked about here many years ago) 
> that can try various passwords until something matches the hashed 
> value?  If that's the case, hashing doesn't really do as much good as 
> people think it does, once someone gets hold of the RACF dataset of 
> course.

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

Re: Hogan Financial Systems. It is a banking system

Verhoef-Training company and Brian Miller - Brian Miller
  are looking for someone to teach a class on Hogan
Banking system.
Please contact Brian Miller if interested.  I work for this company on a
part time basis.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Thursday, January 14, 2021 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hogan Financial Systems. It is a banking system

Just to pile onto what Joe Monk said: Hogan was developed by Hogan Systems,
bought by Continuum in 1995. A year or so later, CSC bought Continuum. At
some point CSC rebranded Hogan to ConnectWise, but that never really "took".

 

And a couple of years ago, CSC and DXC (formerly HPE, formerly HP Global
Services, formerly EDS) basically merged (I think they used some other term)
and it seems to be back to being called "Hogan" again.

 

So all of the capitalized words above (except Joe and Monk, and I guess HP
Global Services/HPE/EDS) might be associated with Hogan in various contexts.
Figured this might reduce confusion. Or, I suppose, increase it.

 

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

Using JobClass condition in JES2 Policy

[Roger Lowe]

Hi,
   Am trying to get a JES2 Policy using the "JobClass" condition and I try and 
do the $POLICY IMPORT command it is failing with - 

$HASP1640 Error in condition expression in definition entry 1.
$HASP1605 Syntax error 3 in expression near position 13.  
  Name was not found. 
  " JobClass = A" 
  .*.   

Have checked the JSON syntax and it all looks fine.

Not sure why the dots '...' are appearing as part of the error message.

Anyone else get a JES2 Policy using the JobClass condition working under a zOS 
2.4 environment?

Thanks, Roger

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

Re: Code to verify LOGON password

[Seymour J Metz]

Even there are tasks that require access to the RACF DB, they can probably be 
done under a userid to which you have proxy access. Security constraints don't 
just protect against malice, they can also protect against some mistakes.

Update access to what resource? I'm not aware of any command in ACF2, RACF or 
TSS that requires authority to the security data base.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Thursday, January 14, 2021 7:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Code to verify LOGON password

It isn't just UACC(READ) or UID(*).  Why does ~anyone~ have read access to the 
database?  (To say nothing of update.)

At a client I served a while back, I pointed out that a lot of people had read 
access, and quite a few had update.  They argued that it was necessary so that 
their admins could do their jobs.  Apparently they believed that the admin 
needed update access to change permissions, create profiles etc.

Now, it happened that was a TSS shop.  But surely the answer is the same in 
RACF?  I don't need update (or even read) access to the RACF database; when I 
issue a RACF command, RACF determines whether I have the authority and then 
executes the command under the authority of its own ID, whichever one runs the 
STC.

My own rule (when I'm allowed my way) is that NO ONE has access to the 
database, except a system programmer doing migrations to a new version; for 
that purpose I'll grant the necessary access for a defined period, say two 
months, extendible upon request, but expiring automatically.

The Logica breakin, as I understand it, started with the theft of the password 
of an ID that had read access to the RACF database.  The bad guys then 
downloaded it and applied CRACF to it.  Forensic investigators afterward tested 
the same utility and were able to get 10 or 20 thousand passwords from it in 
the first day of running on an ordinary PC.  (Going by memory, but I think it's 
about right.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* We must picture Hell as a state where everyone is perpetually concerned 
about his own dignity and advancement, where everyone has a grievance, and 
where eveyone lives the deadly serious passions of envy, self-importance, and 
resentment.  -C S Lewis, preface to _The Screwtape Letters_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Monday, January 11, 2021 11:44

https://secure-web.cisco.com/1iesSYf-0P7Z111PONKdFPj51TIo8fUKnSxQgEv6-FOvP_cg1RdEOEJAsogbGQKckKIinPKkXvRGW4R6-8YWVzKpOgxlQ-t0RU5zq129AKX6JI6RZRSI_GG4AT2ZoGcDoqCEFD0e6_XSmRBLoWIBP9e49maT1IrMAtyFtp3VtHN7RSNgCbi8bYYcKAANHTzrqOhrql_lVCftNpWRfrPn_bATNcadHXHyBI0u0SAQuFOd31cunlivurVjnb_ixTIsrUwO4PviyoJGbZrl4kcMojaMqtk2RH9DtaNZ11cQAKUjqkWdTiemtTrBENm27KHjdjC-Fc0ZnI1dTXx_VGDeHQzCamRdMasHFow5N8G573IDkHGxLl3D6kFSXYu4wcbd6fMAcZGL7dh5tUsfHh1fEtN_H-ogLpK0kPYA95dJCtFF0eHvOzcoxJqZZTAzXuLdK/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJohn_the_Ripper

There is a downloadable plugin for RACF -- old RACF hashing only, I *think*.

No one "gives" their RACF DB to anyone (I would hope). The problem -- and 
everyone reading this who is not sure about their RACF DB should go check right 
now -- is UACC or USERID(*) READ access to the RACF DB *or its backup*. If I 
can download your RACF DB and attack it off-platform I can defeat any "revoke 
the userid after 'n' tries" that you have in place.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Monday, January 11, 2021 10:07

That's what we call brute force attack.
There is no way to protect against it ...or maybe there are some things to help.
1. Do not give your RACF db to hackers. Never

--- W dniu 11.01.2021 o 15:39, Tom Brennan pisze:
> Isn't there a program someone wrote (talked about here many years ago)
> that can try various passwords until something matches the hashed
> value?  If that's the case, hashing doesn't really do as much good as
> people think it does, once someone gets hold of the RACF dataset of
> course.

--
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: CCSID descriptions

[David Price]

Wikipedia used to have some great articles on each of the EBCDIC Code Pages.

In July 2020 someone marked all 120+ pages for deletion for "lack of 
notability".
In accordance with procedure, the relevant committee voted on this, and the 
majority decision was to keep the pages.
However the individual ignored the vote, and deleted all 120+ pages.

Pushback forced the individual to say they could be transwiki-ed to wikibooks 
if somebody else did it, but he showed no regret for his deletion actually 
preventing that from happening.

The revisionist history was invented that it was a consensus decision to 
delete/transwiki those pages.
Wikipedia's own logs reveal something different.

The URLs had the form  https://en.wikipedia.org/wiki/EBCDIC_500  which can be 
viewed at
https://web.archive.org/web/20200724140250/https://en.wikipedia.org/wiki/EBCDIC_500

In the case of  https://en.wikipedia.org/wiki/EBCDIC_1140  it pointed to 
EBCDIC_037 as in
https://web.archive.org/web/20200712175228if_/https://en.wikipedia.org/wiki/EBCDIC_037#CP1140
because EBCDIC 1140 is just EBCDIC 037 with the square lozenge ICU 
(International Currency Unit) symbol replaced with the Euro symbol.

Attempts to reconstruct some of these deleted web pages, such as
https://en.wikipedia.org/wiki/Draft:EBCDIC_037   or the links in
https://en.wikibooks.org/wiki/Wikibooks:Requests_for_import/Archives/2020/September
are incomplete or misleading templates in their current state.

Strangely the same kinds of Wikipedia articles for non-EBCDIC code pages remain 
untouched.
https://en.wikipedia.org/wiki/Windows-1252
https://en.wikipedia.org/wiki/Western_Latin_character_sets_(computing)
https://en.wikipedia.org/wiki/Code_page_437

Was EBCDIC targeted through ignorance or malice?

My next donation to Wikipedia is scheduled for when all 120+ EBCDIC pages are 
reinstated on Wikipedia itself. 


On Thu, 14 Jan 2021 08:17:23 -0600, Paul Gilmartin wrote:

>On Wed, 13 Jan 2021 09:04:03 -0600, Norbert Friemel wrote:
>
>>On Wed, 13 Jan 2021 08:58:49 +, Windt, W.K.F. van der (Fred) wrote:
>>>
>>>The IBM website used to have complete descriptions of every CCSID including 
>>>a complete overview of every character (glyph) in that CCSID with it's 
>>>encoding. Simply googling "IBM CCSID 1140" would quickly get you to the page 
>>>of CCSID 1140. The CCSID was in the url so you could quickly switch to 
>>>another CCSID by changing the url. But with the change to Knowledge Center I 
>>>can't find those pages anymore... Does anybody know where the CCCSID 
>>>descriptions have gone?
>>
>>Not a website but ... 
>>ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/
>> 
>That would benefit greatly from an index mapping countries to CCSIDs.
>
>

The old website is (partly) archived @ 

I don't know how usable it is

Norbert Friemel

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