Re: Mainframes testing

[Steve Smith]

First, Timothy Sipples is certainly one of the top authorities on this
board, and I take his opinion very seriously.  But both Lennie
Dymoke-Bradshaw's reply, and Brian Chapman's seem to me closer to the
facts.  The paper is not only has half-truths and is misleading, but is
utterly banal.  I can't see there's anyone with actual responsibility for
security or mainframes of any kind that could glean anything useful from
it, other than IBM wants to sell something.

A prospective customer shouldn't have to re-edit the copy, nor "read
between the lines" to divine what's really meant.  I expect better than
this from IBM.

sas

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Rick J. Valles]

Esmie,


I misunderstood your need for a listing of data sets in a catalog, but not on 
disk.


This DFDSS job lists data sets found in a VTOC, but not catalogued.


r

On August 15, 2019 at 6:01 AM, esmie moo 
<012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:


Ricks,
Thanks for the example.  I will try it out. 
On Wednesday, August 14, 2019, 12:10:39 a.m. GMT-4, Rick J. Valles 
<026801af9474-dmarc-requ...@listserv.ua.edu> wrote:

This is what we use (from my friend, John C. Miller @ jmit.com 
):


//S1      EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//SYSPRINT DD  SYSOUT=*
//TAPE    DD  DUMMY
//SYSIN    DD  *
DUMP DS(INC(**) BY(CATLG EQ NO)) OUTDD(TAPE) LOGINDYNAM(SYC500)


r


On Aug 13, 2019, at 9:00 AM, John McKown  wrote:


On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:


Gentle Readers,
Is there a way of weeding out dsns with cataloged entries only.  I tried
DFDSS logical backup with NORUN option but it did not give me the desired
results.  I coded the VOLSER of the disk to no avail.  I am doing this
exercise in preparation of removing old dasd but experiences of the past
jobs failed because the dsn is not accessible
Any suggestions would be helpful and welcomed.Here is an example of my jcl:
//NORUN  EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
  //*DFDSS1  EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
  //DASD1    DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),    //
          UNIT=3490,TRTCH=COMP,LABEL=(1,SL)                    //SYSPRINT
DD  SYSOUT=*                                              //SYSMAP  DD
SYSOUT=*                                              //SYSIN    DD  *
                                                  DUMP
DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -                          SPHERE
                                    -
SELECTMULTI(FIRST)                          -
LOGINDDNAME(DASD1)                          -
OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
TOL(ENQF)                                                      /*






Do you mean DSNs in a catalog that don't exist on some volume (I am
guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
command which will do it. We use that at disaster recovery. I am not aware
of any z/OS "built in" facility to do that.


--
A sine curve goes off to infinity, or at least the end of the blackboard.
-- Prof. Steiner


Maranatha! <><
John McKown


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


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

--
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: Local time in C on z/OS

[Jon Perryman]

 The op wants the machine local time as seen in the system log instead of all 
the exceptions that are allowed in the C standard. If the op doesn't get an 
acceptable solution, then call the assembler macro's directly from C.. It's a 
simple call to time or whatever macro you need.
As mentioned before, time is complicated.  z/OS adds machine local time as 
displayed in syslog and most other places.
Jon.
On Wednesday, August 14, 2019, 07:24:47 PM PDT, Kirk Wolf 
 wrote:  
 
 IMO, the underlying problem with z/OS Unix localtime() is that environment
variable initialization is brain dead in z/OS.  In other Unix/Posix
implementations, /etc/rc  initializes environment variables for the "init"
process (usually pid=1).  All other processes inherit from it.

In z/OS, along with /etc/rc there is /etc/init.options which initializes
the environment for the init process, but only *some* z/OS Unix processes
inherit from it.
z/OS Unix Processes that are "blind dubbed" do not.  These include normal
batch jobs and started tasks that use z/OS Unix services.

What does this mean?  Well, you should be able to set TZ in /etc/rc or
/etc/init.options and have *all* processes inherit it in their
environment.  Then all of the localtime() calls get the same system
default timezone.  from one place.

In z/OS however, you have to manually configure TZ for each job that
doesn't inherit its environment from the init process.    This can cause
all sorts of problems in z/OS Unix, but TZ is an easy one to understand.

(BTW: You only need to call tzset() if you want to change the current
process' timezone after the process starts).

I submitted this RFE back in 2014, and it was marked "uncommitted
candidate" in 2016, but it doesn't look to me like it made it into V2R4.
So I'm not holding my breath.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=59716


On Wed, Aug 14, 2019 at 8:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III 
> wrote:
>
> >Poked around some more, found
> >
> >
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
> >
> >which looked promising, but this:
> >  [ ... ]
> A few suggestions:
> Do you also need the date?  That should be derived from the same
> call to time(); lest midnight intrude.
>
> 615 $ cat when.c
>  #include 
>  #include 
>  #include 
>  #include 
>
>  time_t ltime;
>
>  static char hhmmss[9];
>
>  struct tm *tmptr;
>
> int main( int argc, char **argv ) {
>    time();
>
>    if ( ! getenv( "TZ" ) )  /* Support caller's setting of TZ.  */
>        setenv("TZ","CST6CDT",1);
>
>    tzset();
>
>    tmptr = localtime();
>
> /* timeptr = asctime(tmptr);
>    memcpy(, timeptr+11, 8);
>    hhmmss[8] = 0;
>    Deprecated; see
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html#tag_16_21_07
>    So:  */
>    strftime( hhmmss, 9, "%H:%M:%s\0", tmptr );
>
>    printf( "%s\n", hhmmss);  /* show result.  */
>    return( 0 );
> }
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Kirk Wolf]

I should point out that this doesn't deal with the issue of unmounted
volumes :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Thu, Aug 15, 2019 at 9:38 AM Kirk Wolf  wrote:

> As an opportunity to show that REXX isn't the only way to script something
> on z/OS, here is an example of using a z/OS Unix shell script in a batch
> job to do this.
>
> The COZBATCH utility is our alternative to BPXBATCH that simplifies batch
> shell scripts.
> "catsearch" is a little Unix shell command that produces output like ISPF
> 3.4 - it uses IGGCSI00 for searching the catalog and then it gathers the
> DSCBs to get label information.   Combining this with the z/OS Unix "awk"
> scripting program allows you to filter the output and print and format
> lines for the DSN and VOLUME of uncataloged datasets.
>
> //UNIX EXEC PGM=COZBATCH# a better BPXBATCH
> //STEPLIB DD DISP=SHR,DSN=DOVETAIL.COZ.LOADLIB
> //STDIN   DD *
> # This is just a z/OS Unix shell script:
> # Search the catalog and print those entries not found on the volume
> catsearch -l "*.**" |
>   awk '$2 == "??" { printf("%-44s %s\n",$3,$1); }'
> /*
> //STDOUT  DD DISP=(,PASS),DSN=&,DCB=(RECFM=FB,LRECL=80)
> //
>
> It would be trivial to have awk generate IDCAMS commands to delete
> uncataloged entries.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> PS> Co:Z can be downloaded and used free under our Community License:
> http://dovetail.com/support.html
> For more info on:
> catsearch command
> https://dovetail.com/docs/dspipes/dsp-ref_catsearch.html
> COZBATCH https://dovetail.com/products/cozbatch.html
>
>
>
>
> On Thu, Aug 15, 2019 at 8:10 AM Pew, Curtis G <
> curtis@austin.utexas.edu> wrote:
>
>> On Aug 15, 2019, at 7:00 AM, esmie moo <
>> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
>> >
>> > Yes.  I am trying to find any dsns that exist in the catalog but don't
>> exist on the disk.  I know that we have some ancient applications which
>> refer to procs that have dsns which are cataloged but do not exist on the
>> disk.
>>
>> I’m going to recommend Rocket Mainstar Catalog RecoveryPlus for this. It
>> won’t just identify the DSNs, it will generate the IDCAMS statements needed
>> to clean everything up. It can also find and fix more serious problems with
>> your catalogs.
>>
>> This is one of those products you don’t need often but saves a lot of
>> time and effort when you do need it.
>>
>>
>> --
>> Pew, Curtis G
>> curtis@austin.utexas.edu
>>
>>
>>
>>
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[esmie moo]

 John,
Yes.  I am trying to find any dsns that exist in the catalog but don't exist on 
the disk.  I know that we have some ancient applications which refer to procs 
that have dsns which are cataloged but do not exist on the disk.
On Wednesday, August 14, 2019, 12:35:39 a.m. GMT-4, John McKown 
 wrote:  
 
 On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

> Gentle Readers,
> Is there a way of weeding out dsns with cataloged entries only.  I tried
> DFDSS logical backup with NORUN option but it did not give me the desired
> results.  I coded the VOLSER of the disk to no avail.  I am doing this
> exercise in preparation of removing old dasd but experiences of the past
> jobs failed because the dsn is not accessible
> Any suggestions would be helpful and welcomed.Here is an example of my jcl:
> //NORUN  EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>  //*DFDSS1  EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
>  //DASD1    DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
>  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),    //
>            UNIT=3490,TRTCH=COMP,LABEL=(1,SL)                    //SYSPRINT
> DD  SYSOUT=*                                              //SYSMAP  DD
> SYSOUT=*                                              //SYSIN    DD  *
>                                                    DUMP
> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -                          SPHERE
>                                      -
> SELECTMULTI(FIRST)                          -
> LOGINDDNAME(DASD1)                          -
> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
> TOL(ENQF)                                                      /*
>
>
>
Do you mean DSNs in a catalog that don't exist on some volume (I am
guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
command which will do it. We use that at disaster recovery. I am not aware
of any z/OS "built in" facility to do that.

-- 
A sine curve goes off to infinity, or at least the end of the blackboard.
-- Prof. Steiner

Maranatha! <><
John McKown

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

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[esmie moo]

 Ricks,
Thanks for the example.  I will try it out. 
On Wednesday, August 14, 2019, 12:10:39 a.m. GMT-4, Rick J. Valles 
<026801af9474-dmarc-requ...@listserv.ua.edu> wrote:  
 
 This is what we use (from my friend, John C. Miller @ jmit.com 
):


//S1      EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//SYSPRINT DD  SYSOUT=*
//TAPE    DD  DUMMY
//SYSIN    DD  *
 DUMP DS(INC(**) BY(CATLG EQ NO)) OUTDD(TAPE) LOGINDYNAM(SYC500)


r

> On Aug 13, 2019, at 9:00 AM, John McKown  wrote:
> 
> On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> Gentle Readers,
>> Is there a way of weeding out dsns with cataloged entries only.  I tried
>> DFDSS logical backup with NORUN option but it did not give me the desired
>> results.  I coded the VOLSER of the disk to no avail.  I am doing this
>> exercise in preparation of removing old dasd but experiences of the past
>> jobs failed because the dsn is not accessible
>> Any suggestions would be helpful and welcomed.Here is an example of my jcl:
>> //NORUN  EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>>  //*DFDSS1  EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
>>  //DASD1    DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
>>  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),    //
>>          UNIT=3490,TRTCH=COMP,LABEL=(1,SL)                    //SYSPRINT
>> DD  SYSOUT=*                                              //SYSMAP  DD
>> SYSOUT=*                                              //SYSIN    DD  *
>>                                                  DUMP
>> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -                          SPHERE
>>                                    -
>> SELECTMULTI(FIRST)                          -
>> LOGINDDNAME(DASD1)                          -
>> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
>> TOL(ENQF)                                                      /*
>> 
>> 
>> 
> Do you mean DSNs in a catalog that don't exist on some volume (I am
> guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
> command which will do it. We use that at disaster recovery. I am not aware
> of any z/OS "built in" facility to do that.
> 
> -- 
> A sine curve goes off to infinity, or at least the end of the blackboard.
> -- Prof. Steiner
> 
> Maranatha! <><
> John McKown
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Kirk Wolf]

As an opportunity to show that REXX isn't the only way to script something
on z/OS, here is an example of using a z/OS Unix shell script in a batch
job to do this.

The COZBATCH utility is our alternative to BPXBATCH that simplifies batch
shell scripts.
"catsearch" is a little Unix shell command that produces output like ISPF
3.4 - it uses IGGCSI00 for searching the catalog and then it gathers the
DSCBs to get label information.   Combining this with the z/OS Unix "awk"
scripting program allows you to filter the output and print and format
lines for the DSN and VOLUME of uncataloged datasets.

//UNIX EXEC PGM=COZBATCH# a better BPXBATCH
//STEPLIB DD DISP=SHR,DSN=DOVETAIL.COZ.LOADLIB
//STDIN   DD *
# This is just a z/OS Unix shell script:
# Search the catalog and print those entries not found on the volume
catsearch -l "*.**" |
  awk '$2 == "??" { printf("%-44s %s\n",$3,$1); }'
/*
//STDOUT  DD DISP=(,PASS),DSN=&,DCB=(RECFM=FB,LRECL=80)
//

It would be trivial to have awk generate IDCAMS commands to delete
uncataloged entries.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Co:Z can be downloaded and used free under our Community License:
http://dovetail.com/support.html
For more info on:
catsearch command
https://dovetail.com/docs/dspipes/dsp-ref_catsearch.html
COZBATCH https://dovetail.com/products/cozbatch.html




On Thu, Aug 15, 2019 at 8:10 AM Pew, Curtis G 
wrote:

> On Aug 15, 2019, at 7:00 AM, esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Yes.  I am trying to find any dsns that exist in the catalog but don't
> exist on the disk.  I know that we have some ancient applications which
> refer to procs that have dsns which are cataloged but do not exist on the
> disk.
>
> I’m going to recommend Rocket Mainstar Catalog RecoveryPlus for this. It
> won’t just identify the DSNs, it will generate the IDCAMS statements needed
> to clean everything up. It can also find and fix more serious problems with
> your catalogs.
>
> This is one of those products you don’t need often but saves a lot of time
> and effort when you do need it.
>
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Local time in C on z/OS

[Allan Staller]

You can supply TZ via JCL parm, (LE) parm or OVMS shell variable or /etc/init 
or /etc/rc

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, August 14, 2019 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Local time in C on z/OS

I have a C POSIX application that writes timestamps on its output. It's always 
produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I 
thought maybe I could fix it.



Looking at the code, it's using ctime(). Ok, hey, localtime() should be 
gooderT! Nope, per IBM doc:

*  The ctime(), localtime(), and mktime() functions now return Coordinated 
Universal Time (UTC) unless customized locale information is made available, 
which includes setting the timezone_name variable.

*  In POSIX you can supply the necessary information by using environment 
variables.



Gee, thanks (and what does "now" mean in that first sentence? As opposed to 
tomorrow?? Last week???).



I'm not in a position to set environment variables for this. I know the 
hardware is set to UTC, but there's a system timezone offset at some level. Is 
there no simple way to just say "Gimme the same time as the operator's console 
would show"? Searching sure hasn't found one, hoping someone knows better!


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Mainframes testing

[Brian Chapman]

Timothy,

While I don't disagree with you, I think that most people here feel that
these topics are systemic issues with any platform. Storing unencrypted (or
even encrypted) userids and passwords in datasets or files that are not
highly restricted is a major liability. I feel that it is disingenuous and
unrealistic to say that a mainframe is antiquated or obsolete because of
these issues. These are just security 101 topics that are valid for every
platform.



Thank you,

Brian Chapman


On Thu, Aug 15, 2019 at 12:26 AM Timothy Sipples  wrote:

> Let's quote the author directly, OK? I'm going to quote the whole second
> section since context is important:
>
> "2. Data Left Behind
>
> "Because mainframes were once typically set-up-and-forget systems, they
> often contain sensitive data files that should have been deleted after the
> deployment phase ended. Certain data should not be written to a space that
> just any user can access.
>
>
> "We had one mainframe hacker who logged into the mainframe as an
> unprivileged user and immediately saw a highly sensitive file that
> contained information she could have used to compromise high-privileged
> users in the company’s environment. Files, such as lists of usernames and
> passwords and confidential client information, should not remain on the
> mainframe, where they are exposed to any type of user who gains physical or
> remote access."
>
>
> I don't think this is a particularly well written (or well edited? editors
> can sometimes do damage) piece of text -- let me just say that up front.
> However, in context, it's not awful. Let's work through this together
>
>
> "Because mainframes were once typically set-up-and-forget systems"
>
>
> That's not the first description that comes to mind of classic mainframes
> running MVS, for example. However, that is an excellent description of IBM
> AS/400s, and I have seen more than a few references to AS/400s (and IBM i
> machines) as "mainframes." That said, the first sentence is my least
> favorite.
>
>
> Sentence #2 in this section is quite important for context.
>
>
> "Files, such as lists of usernames and passwords and confidential client
> information, should not remain on the mainframe, where they are exposed to
> any type of user who gains physical or remote access."
>
>
> I don't think we should automatically blame the author for a stray comma.
> Let me oh-so-slightly adjust this sentence, and I'm going to add three
> words just to emphasize the problem with that comma:
>
>
> "Files, such as lists of usernames and passwords and confidential client
> information, should not remain on the mainframe or anywhere else where they
> are exposed to any type of user who gains physical or remote access."
>
>
> It's a very, very reasonable interpretation in context that that's what the
> author meant, but the comma, in particular, wasn't at all helpful. No, that
> comma certainly shouldn't be there, but it's a comma, and editors (and
> sometimes authors) unfortunately make punctuation mistakes.
>
>
> Has anyone who doesn't like this article bothered to contact the author, or
> at least try, to suggest improvements? If not, why not?
>
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
>
> 
>
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: logstream read/copy utility

[Don Poitras]

In article <00c201d5536f$e7e1d530$b7a57f90$@gmail.com> you wrote:
> Is there a generic utility anywhere to read a logstream and write it to a
> data set or report?
>  
>  
> Lionel B. Dyck <
> Website:   http://www.lbdsoftware.com

IDCAMS?

//DONLOGP JOB (,R214),POITRAS,NOTIFY=SASDTP,TIME=(1,59),CLASS=A  
//REPRO   EXEC  PGM=IDCAMS,REGION=20M 
//SYSUT1   DD  DISP=SHR,DSN=SASDTP.SAS.LOG,   
// SUBSYS=(LOGR), 
// DCB=(DSORG=PS,RECFM=VB,LRECL=32756,BLKSIZE=32760)  
//SYSUT2   DD  SYSOUT=*,  
// DCB=(DSORG=PS,RECFM=VB,LRECL=32756,BLKSIZE=32760)  
//SYSPRINT DD SYSOUT=*
//SYSINDD *   
 REPRO INFILE(SYSUT1) OFILE(SYSUT2)   
/*
//

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

System Logger - access to staging data?

[Lionel B Dyck]

Is there a utility that will copy/print the staging data for a logstream?

 

thanks

 

 

Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

logstream read/copy utility

[Lionel B Dyck]

Is there a generic utility anywhere to read a logstream and write it to a
data set or report?

 

 

Lionel B. Dyck <
Website:   http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

 


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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Pew, Curtis G]

On Aug 15, 2019, at 7:00 AM, esmie moo 
<012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Yes.  I am trying to find any dsns that exist in the catalog but don't exist 
> on the disk.  I know that we have some ancient applications which refer to 
> procs that have dsns which are cataloged but do not exist on the disk.

I’m going to recommend Rocket Mainstar Catalog RecoveryPlus for this. It won’t 
just identify the DSNs, it will generate the IDCAMS statements needed to clean 
everything up. It can also find and fix more serious problems with your 
catalogs.

This is one of those products you don’t need often but saves a lot of time and 
effort when you do need it.


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






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

Re: logstream read/copy utility

[Lionel B Dyck]

Thank you - this is perfect.


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what
you are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Don Poitras
Sent: Thursday, August 15, 2019 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: logstream read/copy utility

In article <00c201d5536f$e7e1d530$b7a57f90$@gmail.com> you wrote:
> Is there a generic utility anywhere to read a logstream and write it 
> to a data set or report?
>  
>  
> Lionel B. Dyck <
> Website:   http://www.lbdsoftware.com

IDCAMS?

//DONLOGP JOB (,R214),POITRAS,NOTIFY=SASDTP,TIME=(1,59),CLASS=A  
//REPRO   EXEC  PGM=IDCAMS,REGION=20M 
//SYSUT1   DD  DISP=SHR,DSN=SASDTP.SAS.LOG,   
// SUBSYS=(LOGR), 
// DCB=(DSORG=PS,RECFM=VB,LRECL=32756,BLKSIZE=32760)  
//SYSUT2   DD  SYSOUT=*,  
// DCB=(DSORG=PS,RECFM=VB,LRECL=32756,BLKSIZE=32760)  
//SYSPRINT DD SYSOUT=*
//SYSINDD *   
 REPRO INFILE(SYSUT1) OFILE(SYSUT2)   
/*
//

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Lizette Koehler]

I think this is still valid.  But you would need to check with CA Broadcom to 
be certain

If you have any CA products like, CA1, PDSMAN, DISK, ALLOCATE, and so forth

Then you should be able to download and install GMI which could also be called 
Vantage Lite or SRM Lite

It will do what you want.


Or if you have SRM/Vantage, it will do what you want.


So is the problem you are trying to solve preventing JCL errors due to datasets 
coded in JCL but not existing?  

Or is this due to using NON SMS Volumes where there is only a catalog entry and 
not a physical dataset?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> esmie moo
> Sent: Thursday, August 15, 2019 5:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY
> 
>  Ricks,
> Thanks for the example.  I will try it out.
> On Wednesday, August 14, 2019, 12:10:39 a.m. GMT-4, Rick J. Valles
> <026801af9474-dmarc-requ...@listserv.ua.edu> wrote:
> 
>  This is what we use (from my friend, John C. Miller @ jmit.com
> ):
> 
> 
> //S1  EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
> //SYSPRINT DD  SYSOUT=*
> //TAPEDD  DUMMY
> //SYSINDD  *
>  DUMP DS(INC(**) BY(CATLG EQ NO)) OUTDD(TAPE) LOGINDYNAM(SYC500)
> 
> 
> r
> 
> > On Aug 13, 2019, at 9:00 AM, John McKown 
> wrote:
> >
> > On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
> > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Gentle Readers,
> >> Is there a way of weeding out dsns with cataloged entries only.  I
> >>tried  DFDSS logical backup with NORUN option but it did not give me
> >>the desired  results.  I coded the VOLSER of the disk to no avail.  I
> >>am doing this  exercise in preparation of removing old dasd but
> >>experiences of the past  jobs failed because the dsn is not accessible
> >>Any suggestions would be helpful and welcomed.Here is an example of my jcl:
> >> //NORUN  EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
> >>  //*DFDSS1  EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
> >>  //DASD1DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
> >>  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),
> >>//
> >>  UNIT=3490,TRTCH=COMP,LABEL=(1,SL)
> >>//SYSPRINT  DD  SYSOUT=*
> >>//SYSMAP  DD
> >> SYSOUT=*  //SYSINDD
> >>*
> >>  DUMP
> >> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -
> >>SPHERE
> >>-
> >> SELECTMULTI(FIRST)  -
> >> LOGINDDNAME(DASD1)  -
> >> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
> >> TOL(ENQF)  /*
> >>
> >>
> >>
> > Do you mean DSNs in a catalog that don't exist on some volume (I am
> > guessing DASD in particular)? ADRDSSU won't address that. T-REX has a
> > SCRUB command which will do it. We use that at disaster recovery. I am
> > not aware of any z/OS "built in" facility to do that.
> >
> > --
> > A sine curve goes off to infinity, or at least the end of the blackboard.
> > -- Prof. Steiner
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> 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: Local time in C on z/OS

[Phil Smith III]

Gil provided a promising-looking code snippet, which I tried. Alas, no change! 
(I did have to fix the %s to %S, so I'm 100% sure I picked up the change-I'm 
cross-compiling using Dignus, which always adds that bit of vagary: did you get 
the right object? Etc.).

 

I don't think I missed anything (I'm still forcing CST6CDT; once I get it 
working, I'll worry about how to set that):
  time_t ltime;

  static char hhmmss[9];

  struct tm *tmptr;

 

   time(); /* Get the time */

   setenv("TZ","CST6CDT",1);

   tzset();

   tmptr = localtime();   /* Convert to local time */

   strftime( hhmmss, 9, "%H:%M:%S\0", tmptr );

 

   return(hhmmss);/* Return the hh:mm:ss */


I still get GMT. This is making me feel VERY stupid. I will look at using MVS 
TIME next.


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

Re: Mainframes testing

[Lennie Dymoke-Bradshaw]

Timothy,

I don't particularly want to get into any argument about this. I was asked for 
an opinion on the paper and replied with my immediate reactions. I see no 
reason to change those statements.

As another ex-IBMer suggested to me, the paper appears to be a marketing paper 
and not aimed at technicians. The author also made some statements that I did 
not understand (and which I think others do not understand). Those statements 
indicated a lack of knowledge of the subject matter.

I am well aware that mainframes run Linux and that z/OS includes USS.

When I was employed by IBM I saw several marketing papers on various subjects 
that contained errors or inaccuracies. (A recent example is that I have seen 
statements that z/OS can encrypt ALL the data on z/OS systems.) IBM marketing 
makes claims from time to time that are either untrue or "stretch the truth". I 
have rarely succeeded in getting such documents changed.

Sadly, this paper taught me nothing. That is not to say it has no value. I 
accept it was probably not intended for me or other z/OS technicians. Maybe I 
should have stated that in my first post on the paper.

(Opinions expressed are my own and do not represent RSM).

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
'Dance like no one is watching. Encrypt like everyone is.'

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: 15 August 2019 04:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Mainframes testing

Lennie Dymoke-Bradshaw wrote:
>The IBM paper reads as if it has been written by someone with 
>relatively little System z knowledge.

You seem to be assuming that mainframes don't run Linux and aren't UNIX(TM) 
servers. If so, that's not a reasonable assumption.

I agree with Charles Mills. As an analogy, it's still possible to find useful, 
basic (at least) information about cancer without reading a dozen peer reviewed 
articles published in the New England Journal of Medicine, The Lancet, and The 
Journal of the American Medical Association.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

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

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

Re: Local time in C on z/OS

[Charles Mills]

IBM seems to have a unique ability to make complicated the inherently
simple. 

"Alexa, what time is it?" "The time is ten twenty-eight AM."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Thursday, August 15, 2019 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS

Jon Perryman wrote:

>The op wants the machine local time as seen in the system log instead of

>all the exceptions that are allowed in the C standard. If the op doesn't

>get an acceptable solution, then call the assembler macro's directly

>from C.. It's a simple call to time or whatever macro you need.

 

Yep, that's where I wound up. Sort of amazing that 50 years after OS/360,
there's no standard way to get the current time as hh:mm:ss. How many
thousands of us have had to write that same code.

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

Re: Reason for 2 digit years was Re: Instruction speeds

[Mike Schwab]

I interned in a catalog sales company in the marketing department in
1984.  Used 1 digit year and purged sales data over 6 years old.

On Thu, Aug 15, 2019 at 12:46 AM Support, DUNNIT SYSTEMS LTD.
 wrote:
>
> 2 digit years I recall a shop who throughout the 70's implemented 1 digit 
> year dates across their files because of the precious cost and availability 
> of DASD space. In 1979, someone there took are hard look at what the future 
> held in store. So they did a full conversion project and changed all of their 
> date fields to. 2 digit year dates!
>
> --
> 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: Reason for 2 digit years was Re: Instruction speeds

[Seymour J Metz]

> IBM 701 with 2048, later 4095 36 bit word

ITYM 4096

The Williams Tube was one of those technologies that I was too young to know 
about, for which I am grateful.

> two digit dates and Packed Decimal 

It's not that hard to used unsigned packed decimal for a three digit year in 
two bytes.


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


From: IBM Mainframe Discussion List  on behalf of 
Nightwatch RenBand 
Sent: Thursday, August 15, 2019 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was Re: Instruction speeds

My first programming experience was in the mid to late 1960's and even then
there were "old timers" who explained things like this in lurid detail;
perhaps, as King Henry V said " with advantages what feats he did that
day". As I remember they said that the problem was memory.  They programmed
on IBM 701 with 2048, later 4095 36 bit wordd of CRT memory.  Yes, you
could output to tape or punched cards, but you had to do your calculations
in main memory.  Virtual memory had been proven in the labs, but for years
programmers struggled with "overlays" where your code actually moved the
next routine into memory before continuing processing.  Naturally, the
smaller you could make your code and data areas the less you would have to
do overlays, so two digit dates and Packed Decimal saved main memory at the
cost of cpu cycles.  Also the reason that the ZAP and AP commands were
devised.  CPU cycles are a cost, but remember that overlays take many more
instructions than packing dates, and programmer time was just as expensive,
perhaps more so, than today (since wages have been close to stagnant since
about 1980).  Oh, did I mention that they were programming with early
Assembler which did not include symbolics?  You had to remember the offsets
for every piece of data as well as the location of the instructions in
memory.  Perhaps that's why so many of them smoked and drank.
SO that's the story as they saw it.  It may not stand up to rigorous
computer science analysis, but it "seemed like a good idea at the time".
Which reminds me of my favorite joke.  From the Maginficent Seven"
https://www.youtube.com/watch?v=0ieicflBG_Y

Calvera: What I don't understand is why a man like you took the job in the
first place, hum? Why, heh?

Chris: I wonder myself.

Calvera: No, come on, tell me why.

Vin: It's like this fellow I knew in El Paso. One day, he just took all his
clothes off and jumped in a mess of cactus. I asked him that same question,
"Why?"

Calvera: And?

Vin: He said, "It seemed like a good idea at the time."

--
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: Local time in C on z/OS

[Phil Smith III]

Jon Perryman wrote:

>The op wants the machine local time as seen in the system log instead of

>all the exceptions that are allowed in the C standard. If the op doesn't

>get an acceptable solution, then call the assembler macro's directly

>from C.. It's a simple call to time or whatever macro you need.

 

Yep, that's where I wound up. Sort of amazing that 50 years after OS/360, 
there's no standard way to get the current time as hh:mm:ss. How many thousands 
of us have had to write that same code.

 

Thanks to all who helped!


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

Reason for 2 digit years was Re: Instruction speeds

[Nightwatch RenBand]

My first programming experience was in the mid to late 1960's and even then
there were "old timers" who explained things like this in lurid detail;
perhaps, as King Henry V said " with advantages what feats he did that
day". As I remember they said that the problem was memory.  They programmed
on IBM 701 with 2048, later 4095 36 bit wordd of CRT memory.  Yes, you
could output to tape or punched cards, but you had to do your calculations
in main memory.  Virtual memory had been proven in the labs, but for years
programmers struggled with "overlays" where your code actually moved the
next routine into memory before continuing processing.  Naturally, the
smaller you could make your code and data areas the less you would have to
do overlays, so two digit dates and Packed Decimal saved main memory at the
cost of cpu cycles.  Also the reason that the ZAP and AP commands were
devised.  CPU cycles are a cost, but remember that overlays take many more
instructions than packing dates, and programmer time was just as expensive,
perhaps more so, than today (since wages have been close to stagnant since
about 1980).  Oh, did I mention that they were programming with early
Assembler which did not include symbolics?  You had to remember the offsets
for every piece of data as well as the location of the instructions in
memory.  Perhaps that's why so many of them smoked and drank.
SO that's the story as they saw it.  It may not stand up to rigorous
computer science analysis, but it "seemed like a good idea at the time".
Which reminds me of my favorite joke.  From the Maginficent Seven"
https://www.youtube.com/watch?v=0ieicflBG_Y

Calvera: What I don't understand is why a man like you took the job in the
first place, hum? Why, heh?

Chris: I wonder myself.

Calvera: No, come on, tell me why.

Vin: It's like this fellow I knew in El Paso. One day, he just took all his
clothes off and jumped in a mess of cactus. I asked him that same question,
"Why?"

Calvera: And?

Vin: He said, "It seemed like a good idea at the time."

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

Re: Local time in C on z/OS

[Charles Mills]

Are you POSIX ON or OFF? For POSIX OFF the variable is named _TZ . Try that.

Check the return code from setenv(). Unlikely it is failing, but who knows?

My notes indicate that the environment variable timezone_name *may* be
needed. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Thursday, August 15, 2019 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS

Gil provided a promising-looking code snippet, which I tried. Alas, no
change! (I did have to fix the %s to %S, so I'm 100% sure I picked up the
change-I'm cross-compiling using Dignus, which always adds that bit of
vagary: did you get the right object? Etc.).

 

I don't think I missed anything (I'm still forcing CST6CDT; once I get it
working, I'll worry about how to set that):
  time_t ltime;

  static char hhmmss[9];

  struct tm *tmptr;

 

   time(); /* Get the time */

   setenv("TZ","CST6CDT",1);

   tzset();

   tmptr = localtime();   /* Convert to local time */

   strftime( hhmmss, 9, "%H:%M:%S\0", tmptr );

 

   return(hhmmss);/* Return the hh:mm:ss */


I still get GMT. This is making me feel VERY stupid. I will look at using
MVS TIME next.


--
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: Reason for 2 digit years was Re: Instruction speeds

[Matthew Stitt]

I worked at such company that had 1 digit years.  The routine(s) to keep them 
straight across the decades I never did fully understand.

OTOH, I also worked at a small Insurance company.  The best (non) joke was when 
a client called regarding a new build discount she was getting on her house.  
The house was built in 1892.

Matthew

On Thu, 15 Aug 2019 00:46:00 -0500, Support, DUNNIT SYSTEMS LTD. 
 wrote:

>2 digit years I recall a shop who throughout the 70's implemented 1 digit 
>year dates across their files because of the precious cost and availability of 
>DASD space. In 1979, someone there took are hard look at what the future held 
>in store. So they did a full conversion project and changed all of their date 
>fields to. 2 digit year dates!
>

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Matthew Stitt]

Program LISTICAT on the CBT tape, file 527 will give you the list of datasets 
in a catalog, but not in a VTOC.  That's in the error listing.

Matthew

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

Re: Reason for 2 digit years was Re: Instruction speeds

[Seymour J Metz]

If you don't like binarythen there's unsigned packed decimal. The code to 
convert between packed decimal and unsigned packed decimal is not exactly 
rocket science.


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


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Wednesday, August 14, 2019 6:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Reason for 2 digit years was  Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time
and for dates stored as packed decimal 0yymmdds the use of the high
order nibble would have worked at the cost of complexity.  I suspect
that the real saving was in data entry and the desire to fit as much
information on one 80 byte punch card as well as on to a 132 character
print line.  I note that my credit cards still use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)

--
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: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Rick J. Valles]

Thanks, Matthew. I just downloaded and received FILE527.XMI and will checkout 
LISTICAT and the other programs.


Great Author!    :)


r

On August 15, 2019 at 10:50 AM, Matthew Stitt  wrote:


Program LISTICAT on the CBT tape, file 527 will give you the list of datasets 
in a catalog, but not in a VTOC. That's in the error listing.

Matthew

--
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: Reason for 2 digit years was Re: Instruction speeds

[Seymour J Metz]

>  foremoms and foredads

Some of us were there at the time. I've lost track of the number of times that 
I've criticized something only to be accused, decades later, of only having 
"20-20 hindsight". W4 aren't allo newbies.


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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, August 14, 2019 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was  Re: Instruction speeds

It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
and foredads for the reckless choice they made decades ago to store dates in 
two-digit format. Making our lives miserable in the process. OTOH I remember 
reading some diary excerpts from US Civil War soldiers who routinely recorded 
dates as 61, 63, and so on.

Suppose you were an influencer in, say, 1975. Would you walk into an 
application design meeting and propose *any* change to date representation? 
There were already countless date fields stored in other intersecting 
applications. Those would have to change also or be interfaced only with 
conversion routines.

I think the only point in IT history where a radical change actually made sense 
was just when it happened: right ahead of the wrecking ball. And rather than 
saturate the landscape with a gajillion *useless* year digits, many companies 
were content to implement sliding windows that permanently solved the problem 
with minimal extra storage space.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time and for 
dates stored as packed decimal 0yymmdds the use of the high order nibble would 
have worked at the cost of complexity.  I suspect that the real saving was in 
data entry and the desire to fit as much information on one 80 byte punch card 
as well as on to a 132 character print line.  I note that my credit cards still 
use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on
>behalf of Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On
>Behalf Of Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I program the 
>> flow is:
>>- dividable by 4?
>>- dividable by 100?
>>- dividable by 400?
>
>The last 2 are completely unnecessary until the year 2100.
>
>And in the year 2100 people will curse you for deciding that it's unnecessary.
>
>Après Moi Le Déluge (Après nous le deluge for purists.)


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

Re: Local time in C on z/OS

[Joe Monk]

Code is right here 

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm

/* CELEBL07

   This example queries the system clock and displays the local time.

 */
#include 
#include 

int main(void)
{
   struct tm *newtime;
   time_t ltime;

   time();
   newtime = localtime();
   printf("The date and time is %s", asctime(newtime));
}


On Thu, Aug 15, 2019 at 12:49 PM Phil Smith III  wrote:

> Jon Perryman wrote:
>
> >The op wants the machine local time as seen in the system log instead of
>
> >all the exceptions that are allowed in the C standard. If the op doesn't
>
> >get an acceptable solution, then call the assembler macro's directly
>
> >from C.. It's a simple call to time or whatever macro you need.
>
>
>
> Yep, that's where I wound up. Sort of amazing that 50 years after OS/360,
> there's no standard way to get the current time as hh:mm:ss. How many
> thousands of us have had to write that same code.
>
>
>
> Thanks to all who helped!
>
>
> --
> 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: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[John McKown]

On Thu, Aug 15, 2019 at 9:58 AM Kirk Wolf  wrote:

> I should point out that this doesn't deal with the issue of unmounted
> volumes :-)
>

Is that a 3330-11 I see in your pocket



>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
>
-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

Maranatha! <><
John McKown

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Seymour J Metz]

Well, there's LIST .

Seriously, there are actually cases where CLIST still makes sense. I just wish 
that they'd enhance REXX to have the same capability.


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


From: IBM Mainframe Discussion List  on behalf of 
Kirk Wolf 
Sent: Thursday, August 15, 2019 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

As an opportunity to show that REXX isn't the only way to script something
on z/OS, here is an example of using a z/OS Unix shell script in a batch
job to do this.

The COZBATCH utility is our alternative to BPXBATCH that simplifies batch
shell scripts.
"catsearch" is a little Unix shell command that produces output like ISPF
3.4 - it uses IGGCSI00 for searching the catalog and then it gathers the
DSCBs to get label information.   Combining this with the z/OS Unix "awk"
scripting program allows you to filter the output and print and format
lines for the DSN and VOLUME of uncataloged datasets.

//UNIX EXEC PGM=COZBATCH# a better BPXBATCH
//STEPLIB DD DISP=SHR,DSN=DOVETAIL.COZ.LOADLIB
//STDIN   DD *
# This is just a z/OS Unix shell script:
# Search the catalog and print those entries not found on the volume
catsearch -l "*.**" |
  awk '$2 == "??" { printf("%-44s %s\n",$3,$1); }'
/*
//STDOUT  DD DISP=(,PASS),DSN=&,DCB=(RECFM=FB,LRECL=80)
//

It would be trivial to have awk generate IDCAMS commands to delete
uncataloged entries.

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1bx9oM1LpoLUkcEMUGPQqAgvrd4MwoNQF-ZdQUbvjeu7kTOBtXsBAo5h4v5OC35u0w7HaY3KPg8fJlZZWAJYGgmRjJG1PQhw7VLXqlkRgYEEGVEj1f27P5v2JrZuK6D88YoJndf_swqQti3YYqbpSq48pczlPZ0yqGg0RZhuvosFBHd39NLUKOdqIxwU61qcIk96K4-9Z3aRUccK2urGFnXEikF0-LrA1lwEJM8pe81AP7yvN4yEJ9ChqMulN-DVpU_q9mHq0Fh3v_oIdINnYvHikS1mznHyrL63j85bqMlCp3N6zOXI8ahgCLvshyCdXQd7cOUjuWtabrB_fHiYHCy6iRzRed0pS9BZs4sas7Dhgl2FIrCuFB1RThR1-AS2YFrPYMuV3HJToXHP8QdbVzuvkg6qyqsYGJ4LuDE-bxgE3Zx9XIMt_X8VBdDtuy855/http%3A%2F%2Fdovetail.com

PS> Co:Z can be downloaded and used free under our Community License:
http://secure-web.cisco.com/1w1NYPRqZ3vq1L1aoisGhYxOhP8CqcJE74kCp-jRwhdIIvYl-qqsxF8vBjd3Qtwpqh5h-ehbwO2lJecsY4SWKobOxVqeZv6-ytuCC2TIoLZft3XPmXDqHE03_iCUwKAR6ddZTc6XtFA6GoWayFRR-4eQyuLbSAY7kmdhKvcD8KwLe7JD6pSTOEL1e-YHOrdyA5iV8yI-q4KS4oBOYc-r0aWRzBq-GGWZ9Fjbkexq9q8WyNBXrjsSOTw3UKPx2omwq2xlUIUN6BrShGx6VYAwCrSiqQVpwy8L_PGpTuJ-08j6arRRMHzh7vfc2Cs_jxH_X6-mpZ8jQlm8X_WtWI6fr-9eVHLLaox3-mexmOsF_jVPM-DLfXzzgelMLPwD9f3OwmyXjiPCn7bEHHkJij4hhCw6OHkv_OMjE8prchmvvxuqpghmTFjeHyfKhtAafiShT/http%3A%2F%2Fdovetail.com%2Fsupport.html
For more info on:
catsearch command
https://secure-web.cisco.com/1G0_5oLlmmGTPB_0FIFHhVI3CcK7fN-9SR-AXkZOdYycOb4qdi9MwydtcaVyR99uetSoClur_W8my-JsQYafpkcuzW2b28HXP1roWHC4vmPhPBxa58eRC5fCVKzPGkGsBbTRZ58shFpQpejJbhg7HSiDiRIvgGQjPChUkUiW9MTXH6quiO5qxsKEJiQygYOsCfr2SJPxNOeX9lazSX_8A6zqByO6of7HQz2Iru7XlqfGJ6vo-yieTVN2HKld3l21pEMG_EtEy6S_BY1KWcZd-j09u7eFndj-eoP1gN4VV4O08sFj0CbqhvoJcEifbGQoVRP-ldGwXmtXhpBD5rLeluOSDO5XdCp_bweeTLV1bB7MVVtU79lASKkXz3VPsH2iF--RfwcGuEtL7ICOj0geRbNEJXhJToNnLHV0bJ8X2HyC06nv1Ktji40dfFrcBNvRM/https%3A%2F%2Fdovetail.com%2Fdocs%2Fdspipes%2Fdsp-ref_catsearch.html
COZBATCH 
https://secure-web.cisco.com/1N8QOuOLNQYsfKtGpUt8zvD-zkE5uZyyijyGQ1WuWuEuLEJ-9GWPixIkdhmcVAYUwrXtxJuRuRg2egaV9HIPiFxYycRY8W3ZpGojHmJGPm_yhwJ-6l7wW2r9HILr5oGjqsB7Nyw4hLYaPhaJCUJBtiiRIVQs2p1kZJ485oUnEZ8TMX__lR9_XF1s2AzgoFQNYWhB01UIMFNM09ShdfpmgTb3kxB10gleJn9srHvrtEj5ctT_WHA-RzCcRaXr0weFTRVNtQ6BhKh7ppuieTfRJtSoM2kYwP8VtK5BPN_fV6AHd5w-SrtOtJPvifURLyaO-jKW7h7j49YpxpTh56ZJZUTlKeJDZxT8UjXrbieKwZ1WA_4n6z2bDxdWSH2BkiiZ1YRXNS3VHS1QSUV90vWHUwPZV4WZuPkGG8psUywojNUNS46SZd-8vH9h2Eu1w89UH/https%3A%2F%2Fdovetail.com%2Fproducts%2Fcozbatch.html




On Thu, Aug 15, 2019 at 8:10 AM Pew, Curtis G 
wrote:

> On Aug 15, 2019, at 7:00 AM, esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Yes.  I am trying to find any dsns that exist in the catalog but don't
> exist on the disk.  I know that we have some ancient applications which
> refer to procs that have dsns which are cataloged but do not exist on the
> disk.
>
> I’m going to recommend Rocket Mainstar Catalog RecoveryPlus for this. It
> won’t just identify the DSNs, it will generate the IDCAMS statements needed
> to clean everything up. It can also find and fix more serious problems with
> your catalogs.
>
> This is one of those products you don’t need often but saves a lot of time
> and effort when you do need it.
>
>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

PROCs IEASDBS and IEABE

[Alexander Riedel]

Hi,
in our SYS1.IBM.PROCLIB i found 2 new procedures IEASDBS that calls PGM 
IEAVESBS and procedure IEABE that

calls PGM IEAVEBE.

What are these IBM procedures doing?

Thanks,
Alexander

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

Re: Local time in C on z/OS

[Paul Gilmartin]

On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote:

>Code is right here 
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm
> 
Which says:
...
1. This function is sensitive to time zone information ...

-- gil

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

Re: Local time in C on z/OS

[Charles Mills]

And did not work for the OPoster, hence the OPost.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, August 15, 2019 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS

On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote:

>Code is right here 
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm
> 
Which says:
...
1. This function is sensitive to time zone information ...

-- 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: Integrated 3270 Console in HMC 2.12 in web browser

[Cieri, Anthony]

Weather this is possible may depend upon the level of Java that you are 
using.

I use FireFox to connect to the HMC for an older z10 machine. I also 
keep a Java Version 7 installed specifically for the Integrated 3270 Console 
function.  I have colleagues here with similar PC configurations, that have 
Java Version 8 or later installed.  They can access some HMC functions via a 
remote Web Browser, but unfortunately the Integrated 3270 console is NOT one of 
them.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christian Svensson
Sent: Wednesday, August 14, 2019 2:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Integrated 3270 Console in HMC 2.12 in web browser

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


Hi,

Is it possible to launch Integrated 3270 Console in HMC 2.12 when accessing
the HMC using a web browser?

When I click on the LPAR and choose Integrated 3270 Console nothing happens
when using a remote web browser. It works locally on the HMC. The Chrome
network request is:

Request URL: https:///hmc/ui/dnd2/launch
Request Method: POST
Status Code: 204 No Content
Remote Address: 10.114.2.10:443
Referrer Policy: no-referrer-when-downgrade
Date: Wed, 14 Aug 2019 06:00:22 GMT
Server: zSeries management console embedded web server / 2.0

Nothing more. Am I missing something? Some other actions at least say "this
task cannot be used remotely" which makes me wonder if I'm doing something
wrong.

Bonus question: Can I connect to the LPAR 3270 console remotely in some
other fashion?

Thanks,

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

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

Re: Local time in C on z/OS

[Charles Mills]

> The Dignus runtime main() start-up from a BATCH or TSO start examines the
CVTTZ value and constructs a TZ that offers the proper offset

Good approach IMHO. I know I tried doing that and ran into some sort of
issue.

The fact is that the LE approach is poor. I don't say that because I am a
configuration genius and could have done better. I say that because in 8
years of supporting an STC written in C++ we encountered customer after
customer with whom we had the following dialog:

"Your product is broken. The times are wrong."
"You just need to set the local time offset in /etc/whatever."
"No, we have the local offset. Every other product gets it right. Your
product is broken."
"That's in CLOCKxx. You need to set the local time zone variable with ENVAR
in /etc/whatever."
"Why should we have to do that. Every other product gets it right. Your
product is broken."

The default for USS startup should be the offset in SYS1.PARMLIB(CLOCKxx),
and let UNIX-sophisticated customers override that as they wish.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, August 15, 2019 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS

Phil Smith III wrote:

>I have a C POSIX application that writes timestamps on its output. It's
always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly,
so I thought maybe I could fix it.
>
> 
>  
>

The fundamental problem with "local time" is the definition of "local".

If we make the assumption that the machine clock is kept in UTC (GMT), then
the local time is simply the different from UTC to where one might be at 
that
moment on the globe.

Now - consider the problem of a terminal connected to a fairly remote 
system.
The user may consider himself in a different timezone from the system; hence
his idea of "local" is different than the, say, the operator console 
which happens
to be physically adjacent to the actual hardware device that keeps track 
of the
time.

This is why UNIX/POSIX has the TZ environment variable - one user can set a
different timezone than another.   And this is also why a "global" 
setting of
TZ in, say, /etc/rc isn't always the right idea.  You may have multiple 
users in
multiple timezones. 

Some systems might go as far as keeping a database of sorts for 
terminals, and
having the /etc/rc script make a good guess as to what the proper TZ setting
might be.

This is also why the ssh (and other remote-connect-over-the-internet 
protocols)
have mechanisms for passing the value of the TZ environment variable to the
remote shell.   The user connecting can say "hey - when you connect, set 
this
to be my TZ value."

All that is well and good - but then we run into the problem of programs 
being
dub'd without going thru the typical UNIX start-up... what TZ should 
they get then?

The Dignus runtime main() start-up from a BATCH or TSO start examines 
the CVTTZ
value and constructs a TZ that offers the proper offset from UTC (again, 
this assumes
the machine's clock is set to UTC and that CVTTZ is properly set.)   
This basically
gives you a "local time" for the machine, the user would need to set TZ 
to something
else if they are not in the same locality as the machine.   Under a USS 
start-up, we
inherit the TZ environment variable from the BPX environment.

Thus - the entire question about "what time is it" is totally answered 
when you
can reliably answer the question of "where are you?"

- Dave Rivers -



-- 
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

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

Re: Local time in C on z/OS

[Paul Gilmartin]

On Thu, 15 Aug 2019 16:56:32 -0400, Thomas David Rivers wrote:
>...
>The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ
>value and constructs a TZ that offers the proper offset from UTC (again,this 
>assumes
>the machine's clock is set to UTC and that CVTTZ is properly set.) This 
>basically
>
According to the PoOp, the proper setting for the machine clock is not UTC but
TAI minus 10 seconds.  Sometimes a half-minute (and growing) matters.

What happens if that startup and the program's STCK straddle a Daylight
Saving boundary?

>gives you a "local time" for the machine, the user would need to set TZ to 
>something
>else if they are not in the same locality as the machine.   Under a USS 
>start-up, we
>inherit the TZ environment variable from the BPX environment.
>
>Thus - the entire question about "what time is it" is totally answered when you
>can reliably answer the question of "where are you?"
> 
Which can be complicated.  Arizona, sort of within Mountain time, does not 
observe
DST.  The Navajo Nation, mostly within AZ observes DST.  The Hopi Reservation,
an enclave entirely surrounded by the Navajo Nation follows the AZ convention.

Things are worse for the Autonomous Republic of Crimea.

IBM really ought to:
o Provide initialization of TZ in all cases.
o Provide a single point of control for /etc/rc, /etc/init.options,
  CVTTZ, and CVTLDTO so they don't get out of sync because of
  careless sysadmins.

IBM doesn't care.

-- gil

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

Re: Reason for 2 digit years was Re: Instruction speeds

[Jesse 1 Robinson]

Ah yes. I have a calendar application that reminds me I'm really old. But my 
very first job in IT as an application programmer trainee was in 1978. So I'm 
kinda like the guy in that old up-down intermarriage puzzle who can be 
considered my own grandfather. 

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 15, 2019 10:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Reason for 2 digit years was Re: Instruction speeds

>  foremoms and foredads

Some of us were there at the time. I've lost track of the number of times that 
I've criticized something only to be accused, decades later, of only having 
"20-20 hindsight". W4 aren't allo newbies.


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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Wednesday, August 14, 2019 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reason for 2 digit years was  Re: Instruction speeds

It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms 
and foredads for the reckless choice they made decades ago to store dates in 
two-digit format. Making our lives miserable in the process. OTOH I remember 
reading some diary excerpts from US Civil War soldiers who routinely recorded 
dates as 61, 63, and so on.

Suppose you were an influencer in, say, 1975. Would you walk into an 
application design meeting and propose *any* change to date representation? 
There were already countless date fields stored in other intersecting 
applications. Those would have to change also or be interfaced only with 
conversion routines.

I think the only point in IT history where a radical change actually made sense 
was just when it happened: right ahead of the wrecking ball. And rather than 
saturate the landscape with a gajillion *useless* year digits, many companies 
were content to implement sliding windows that permanently solved the problem 
with minimal extra storage space.

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clark Morris
Sent: Wednesday, August 14, 2019 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Reason for 2 digit years was Re: Instruction speeds

[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main 
sme...@gmu.edu (Seymour J Metz) wrote:

>There were other options to reduce the storage requirement of a date, e.g., 
>store them in binary.
>
The conversion to and from binary would have been costly in CPU time and for 
dates stored as packed decimal 0yymmdds the use of the high order nibble would 
have worked at the cost of complexity.  I suspect that the real saving was in 
data entry and the desire to fit as much information on one 80 byte punch card 
as well as on to a 132 character print line.  I note that my credit cards still 
use 2 digit years.

Clark Morris
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on 
>behalf of Jesse 1 Robinson 
>Sent: Wednesday, August 14, 2019 12:10 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Instruction speeds
>
>A couple of observations on Y2K accommodation.
>
>-- As my shop was slogging through remediation required for year 2000, 
>insurance companies apparently coasted along because they had ALWAYS needed to 
>handle four-digit years from the inception of IT. For them it was business as 
>usual.
>
>-- Can't cite attribution, but I remember the calculation that despite our 
>late 1990s poignant misery, the ancient choice to represent dates with two 
>digits was actually economically correct. The burdensome cost of both media 
>and memory storage in, say, 1970, outweighed on balance the eventual cost of 
>remediation. It's easy to ask what difference two bytes would have made, but 
>the hard-money cost of billions and billions of 'extra' bytes would have been 
>substantial.
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ?=== NEW
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Seymour J Metz
>Sent: Wednesday, August 14, 2019 7:49 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Instruction speeds
>
>> That assumes that you know what is unnecessary. The smart money says that 
>> the unnecessary code will turn out to be necessary, at the least convenient 
>> time.
>
>> A nice example is how to determine leap years: from as long as I 

Re: Reason for 2 digit years was Re: Instruction speeds

[Paul Gilmartin]

On Thu, 15 Aug 2019 00:46:00 -0500, Support, DUNNIT SYSTEMS LTD. wrote:

>2 digit years I recall a shop who throughout the 70's implemented 1 digit 
>year dates across their files because of the precious cost and availability of 
>DASD space. In 1979, someone there took are hard look at what the future held 
>in store. So they did a full conversion project and changed all of their date 
>fields to. 2 digit year dates!
>
I'll go 20% better:

DEC PDP-8 had 12-bit words.  OS 8 stored each date in a single 12-bit
word: 5 bits for day; 4 bits for month; 3 bits for year-1970.  I was not
in a position to confront it after about 1976.

-- gil

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

Re: Local time in C on z/OS

[Joe Monk]

You left off the rest ...

This function is sensitive to time zone information which is provided by:

   - The TZ environmental variable when POSIX(ON) and TZ is correctly
   defined, or by the _TZ environmental variable when POSIX(OFF) and _TZ is
   correctly defined.
   - The LC_TOD category of the current locale if POSIX(OFF) or TZ is not
   defined.

Joe

On Thu, Aug 15, 2019 at 2:22 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote:
>
> >Code is right here 
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm
> >
> Which says:
> ...
> 1. This function is sensitive to time zone information ...
>
> -- 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: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Dana Mitchell]

What would be one of those cases?  I can't really think of anyting, maybe its 
been so long since I've written a clist that I'm don't remember what I'm 
missing.  If you want a trip into the early 80's, try writing an IBMi  CL 
program ;)

Dana

On Thu, 15 Aug 2019 16:41:15 +, Seymour J Metz  wrote:
>
>Seriously, there are actually cases where CLIST still makes sense. I just wish 
>that they'd enhance REXX to have the same capability.
>

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Seymour J Metz]

DATA and DATA PROMPT come to mind, as does the parsing of keyword parameters. 
I've tried to avoid CLIST since TSO/E V2, but there really re things that it 
does better than REXX.


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


From: IBM Mainframe Discussion List  on behalf of 
Dana Mitchell 
Sent: Thursday, August 15, 2019 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

What would be one of those cases?  I can't really think of anyting, maybe its 
been so long since I've written a clist that I'm don't remember what I'm 
missing.  If you want a trip into the early 80's, try writing an IBMi  CL 
program ;)

Dana

On Thu, 15 Aug 2019 16:41:15 +, Seymour J Metz  wrote:
>
>Seriously, there are actually cases where CLIST still makes sense. I just wish 
>that they'd enhance REXX to have the same capability.
>

--
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: Instruction speeds

[Tony Harminc]

On Wed, 14 Aug 2019 at 18:56, Charles Mills  wrote:

> This is really interesting. For those put off by the "C++" note that the
> issue has nothing whatsoever to do with C++. It is a pure branch prediction
> issue. Picture a program that computes an array of pseudo-random 8-bit
> integers from 0 to 255. Then it solves the problem "what is the sum of all
> of the numbers in the table greater than or equal to 128?" It does that
> with the obvious loop, which then contains
>
> IC   R0,next_table_byte
> CHI  R0,128
> JL   *+6
> AR   R2,R0
>
> The assertion of the thread -- and I don't doubt it -- is that the above
> code uses 1/6 the CPU time if you first sort the table. (Obviously, a
> stupid way of doing things: you could sort the table high to low and then
> exit once you got a value below 128; but that's not the point.)
>
> It illustrates the value of, or problem with, depending on your point of
> view, branch prediction. If the table is random then the outcome of the
> CHI/JL is unpredictable, and the branch prediction is at best useless and
> at worst counter-productive. But if the table is sorted, then the branch
> prediction has a chance to be right most of the time.
>

Of course the sort doesn't generally come free. As well as the basic CPU
cost (typically n log n for any modern sort), it will have some amount of
startup CPU and additional memory references. Yes, of course I understand
that this is an example to demonstrate branch prediction. But in the Real
World, branch prediction is just one of many aspects of modern CPUs that
are hard to predict. For that matter branch prediction itself is more than
just remembering which way previous branches went. As a rule, if you know
which path is more likely (and you have reason to think that the predictor
doesn't know better than you do), you should make the likely path the
non-branch one. Similarly you should make the test as unlikely to branch as
possible, e.g. arrange the algorithm to use JL rather than JNH, even if JNH
might give the same result. The predictor, if it knows nothing else, is
going to guess branching based on the number of bits on in the mask.


> There's a lot more than that in the thread, and it fundamentally has to do
> with modern CPU technology, not C++.
>

Yup. It is a good thread, with a nice explanation/analogy.

Tony H.

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Jesse 1 Robinson]

One CLIST feature I miss in REXX is the ability to run in subcommand mode. With 
CLIST, you can execute for example TSO TEST and supply in-line subcommands that 
execute in sequence from within the CLIST. With REXX, you have to QUEUE the 
subcommands before issuing TEST, after which REXX is no longer in control.  

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 15, 2019 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

DATA and DATA PROMPT come to mind, as does the parsing of keyword parameters. 
I've tried to avoid CLIST since TSO/E V2, but there really re things that it 
does better than REXX.


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


From: IBM Mainframe Discussion List  on behalf of 
Dana Mitchell 
Sent: Thursday, August 15, 2019 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

What would be one of those cases?  I can't really think of anyting, maybe its 
been so long since I've written a clist that I'm don't remember what I'm 
missing.  If you want a trip into the early 80's, try writing an IBMi  CL 
program ;)

Dana

On Thu, 15 Aug 2019 16:41:15 +, Seymour J Metz  wrote:
>
>Seriously, there are actually cases where CLIST still makes sense. I just wish 
>that they'd enhance REXX to have the same capability.
>

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

Re: LOCASCB STOKEN=

[Jim Mulder]

   The LOCASCB service originated in MVS/ESA SP3.1.0, around 1987.   An 
STOKEN is 64 bits, and we did not have 64-bit registers until 13 years 
later.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> I'm a bit puzzled. This service takes a pointer to an STOKEN, and 
returns
> an ASCB address. Or a return code indicating that the STOKEN is invalid 
or
> obsolete. So if I am passed an STOKEN pointer by my caller, this seems 
like
> the right service to tell me if this is pointing to a valid and current
> STOKEN, which it does. But if I pass in a bogus *pointer*, e.g. to some
> random address that is fetch protected from me (I'm running user key,
> problem state) then the PC routine code abends, because it's done the 
right
> thing and assumed my key before trying to reference the supposed STOKEN.
> 
> So... Although the description says "Abend codes: none", in fact it can
> S0C4. (Yeah, I know this means that LOCASCB itself generates no abend
> codes.)  So it seems I have to check the validity of the pointer before 
I
> pass it in. I agree such a requirement makes sense in most cases, but 
here
> I am in a constrained environment with no work area, so I have no 
obvious
> way of passing in the STOKEN itself for checking without having a 
pointer
> to it. Is there a design reason the service takes a pointer rather than 
the
> STOKEN itself?



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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Russell Witt]

Lizette is absolutely correct with regard to CA 1. We have a utility (TMSOSCAT) 
that will give you a list of all MVS/Catalog tape entries for which there is no 
actual record in the TMC for. A great way to eliminate obsolete catalog entries.

Russell Witt
CA 1 Architect
Broadcom

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, August 15, 2019 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

I think this is still valid.  But you would need to check with CA Broadcom to 
be certain

If you have any CA products like, CA1, PDSMAN, DISK, ALLOCATE, and so forth

Then you should be able to download and install GMI which could also be called 
Vantage Lite or SRM Lite

It will do what you want.


Or if you have SRM/Vantage, it will do what you want.


So is the problem you are trying to solve preventing JCL errors due to datasets 
coded in JCL but not existing?  

Or is this due to using NON SMS Volumes where there is only a catalog entry and 
not a physical dataset?


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of esmie moo
> Sent: Thursday, August 15, 2019 5:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY
> 
>  Ricks,
> Thanks for the example.  I will try it out.
> On Wednesday, August 14, 2019, 12:10:39 a.m. GMT-4, Rick J. Valles 
> <026801af9474-dmarc-requ...@listserv.ua.edu> wrote:
> 
>  This is what we use (from my friend, John C. Miller @ jmit.com
> ):
> 
> 
> //S1  EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
> //SYSPRINT DD  SYSOUT=*
> //TAPEDD  DUMMY
> //SYSINDD  *
>  DUMP DS(INC(**) BY(CATLG EQ NO)) OUTDD(TAPE) LOGINDYNAM(SYC500)
> 
> 
> r
> 
> > On Aug 13, 2019, at 9:00 AM, John McKown 
> > 
> wrote:
> >
> > On Tue, Aug 13, 2019 at 9:37 AM esmie moo < 
> > 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Gentle Readers,
> >> Is there a way of weeding out dsns with cataloged entries only.  I 
> >>tried  DFDSS logical backup with NORUN option but it did not give me 
> >>the desired  results.  I coded the VOLSER of the disk to no avail.  
> >>I am doing this  exercise in preparation of removing old dasd but 
> >>experiences of the past  jobs failed because the dsn is not 
> >>accessible Any suggestions would be helpful and welcomed.Here is an example 
> >>of my jcl:
> >> //NORUN  EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
> >>  //*DFDSS1  EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
> >>  //DASD1DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
> >>  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),
> >>//
> >>  UNIT=3490,TRTCH=COMP,LABEL=(1,SL) //SYSPRINT  DD  SYSOUT=* 
> >>//SYSMAP  DD
> >> SYSOUT=*  //SYSINDD
> >>*
> >>  DUMP
> >> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  - SPHERE
> >>-
> >> SELECTMULTI(FIRST)  -
> >> LOGINDDNAME(DASD1)  -
> >> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
> >> TOL(ENQF)  /*
> >>
> >>
> >>
> > Do you mean DSNs in a catalog that don't exist on some volume (I am 
> > guessing DASD in particular)? ADRDSSU won't address that. T-REX has 
> > a SCRUB command which will do it. We use that at disaster recovery. 
> > I am not aware of any z/OS "built in" facility to do that.
> >
> > --
> > A sine curve goes off to infinity, or at least the end of the blackboard.
> > -- Prof. Steiner
> >
> > Maranatha! <><
> > John McKown
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> 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

LOCASCB STOKEN=

[Tony Harminc]

I'm a bit puzzled. This service takes a pointer to an STOKEN, and returns
an ASCB address. Or a return code indicating that the STOKEN is invalid or
obsolete. So if I am passed an STOKEN pointer by my caller, this seems like
the right service to tell me if this is pointing to a valid and current
STOKEN, which it does. But if I pass in a bogus *pointer*, e.g. to some
random address that is fetch protected from me (I'm running user key,
problem state) then the PC routine code abends, because it's done the right
thing and assumed my key before trying to reference the supposed STOKEN.

So... Although the description says "Abend codes: none", in fact it can
S0C4. (Yeah, I know this means that LOCASCB itself generates no abend
codes.)  So it seems I have to check the validity of the pointer before I
pass it in. I agree such a requirement makes sense in most cases, but here
I am in a constrained environment with no work area, so I have no obvious
way of passing in the STOKEN itself for checking without having a pointer
to it. Is there a design reason the service takes a pointer rather than the
STOKEN itself?

Thanks...

Tony H.

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