DB2 Application Multitasking

[John P. Baker]

I am looking for any pointers to documentation describing how to structure a
multitasking assembler program where multiple subtasks are concurrently
accessing DB2.

 

No two (2) subtasks will be accessing the same DB2 table concurrently.

 

Any assistance will be most welcome.

 

John P. Baker


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

Re: Forbes: IT Professionals Don't Have What The Tech Industry Wants

[Ed Gould]

Timothy:
You make a broad brush stroke in blue.
There are *DOCUMENTED* instances where IT is coached into putting an  
ad into the paper asking for the world in qualifications and then put  
in a low salary in the same ad.
This is used to show the "need" for more IT workers at a reduced  
rate. Justifying the need to go overseas for people.

There is an industry of people just for doing this.
In reality as both you and I know this is just a way to get cheaper  
labor.


About 20 years ago a company I worked for hired one of these workers.  
What they got was a semi trained individual that could barely do JCL.
He had a contract for 6 months and was promptly lost when his  
contract was up.


I am not sure this example proves anything except he lied on his resume.

Ed
On Jul 3, 2015, at 2:52 AM, Timothy Sipples wrote:

One should not overinterpret the available wage evidence.  
Businesses do
have reasonable needs to bring in foreign workers and managers at  
least for
some period of time. Export-oriented businesses, for example,  
really do
need to have staff circulation to/from overseas in order to boost  
their
exports. It's also fairly easy to imagine skills requirements that  
only a

foreign worker could address in reasonable fashion within a reasonable
period of time. I imagine there's not a super abundance of experts in
German contract law (and German language contracts) living in Peoria,
Illinois, for example, but that sort of skill might be super  
important to a

particular employer.

Some countries -- Japan comes to mind -- have a ratio (or at least  
a ratio
sanity check) policy, meaning that employers are permitted to bring  
in X
number of foreign workers as long as they maintain or better yet  
increase

the number of local workers by some multiple of X. Perhaps that ratio
varies by profession or industry to some extent. That sort of approach
would appear to address at least the bulk of employers' needs.

To summarize, foreign workers can and should be welcomed...within a
reasonable immigration policy. "Reasonable" means based on the  
economics
and reality. Just to pick an example, I'd really like to see even  
more top
university graduates in the U.S. be able to pursue careers in the  
U.S. if

they wish and under reasonable terms. That sort of approach would be
pro-skills, pro-talent. As another example, as I understand it the  
current
H-1B visa program is tied to a specific sponsoring employer. In my  
view
foreign workers shouldn't be captive to a specific employer. They  
should be

able to "jump ship" for better working conditions and compensation, at
least after, say, 120 days. Otherwise (in my view) some of their  
employers
would be tempted to exploit them in various ways including  
compensating

them below market rate for their skills.

-- 
--

Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
-- 
--


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: Leap Second today!

[Jakubek, Jan]

Before posting silly guesses - I should have read 1st the answers in:



IBM publication: Leap Seconds and Server Time Protocol (STP) - 11 February 2015 
(pdf)



Table on page 4:

UTC=23:59:60 NTP/ETS=00:00:00 Leap second inserted. z/OS spins for 1 second.



Time UTC=23:59:60 is never passed to any program issuing TIME macro/s and never 
reported by any application.



If STCK instruction is used:

"This returns the raw Time of Date (TOD) value. The application needs to 
convert it to UTC by subtracting the total leap second offset, or to LOCAL time 
by adding the local time of day offset and subtracting the leap second offset."



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jakubek, Jan
Sent: Friday, July 03, 2015 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!



Replying to myself...likely I'm wrong.



I looked through my syslogs but could not find any entry with time stamp of 
2015181 19:59:60.xx (June 30th).



Did somebody see a syslog entry with date / time 2015181 19:59:60.xx ?



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jakubek, Jan

Sent: Friday, July 03, 2015 4:06 PM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Leap Second today!



I think leap second is "magical".

All time measuring devices that respect it - stop for one second to observe it.

Do I have it right?



--

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: Leap Second today!

[Paul Gilmartin]

On Fri, 3 Jul 2015 17:54:04 -0500, Mike Schwab wrote:

>We could switch to a day is the time between actual solar noons.
>Or adopt the ancient Hebrew definition of 12 hours of sunlight each
>day and 12 hours of nighttime every day.
> 
I've stated, and still hold, that UT1 would be a better, certainly more
practical, standard for IT than UTC:

o There are no discontinuities

o The conversion from UT1 seconds to -MM-DD hh:mm:ss
  can be performed predictably arbitrarily far into the future.

o Surely, if Amazon, Google, and z/OS STP can slew their clocks
  by a second variously in 24 hours, 20 hours, and 7 hours, steering
  to earth rotation time is feasible.

Unfortunately, POSIX chose to make two incompatible requirements:

o The time standard is UTC.

o Each day comprises 86,400 seconds.

And systems programmers struggle to reconcile them.  I say one must
go.  Discard UTC and keep consistent with earth rotation time.

Conversions between UT1, UTC, TAI, GPS, ... are and would remain
necessary.  But UT1 is fine for the stamp on my ATM stub.  I don't
need atomic stability for that.

"Smear" the leap second over several months rather than 7 hours.

-- gil

>On Fri, Jul 3, 2015 at 4:46 PM, Charles Mills  wrote:
>>> I don't believe (but I've already been wrong once) that a programmer can 
>>> request a GMT or LT more than 4 months in the future.
>>
>> I think you're right. An LT or GMT STIMER pops the next time that time of 
>> day occurs, so it can be at most 23:59:59.99 away (23:59:60.99 counting leap 
>> seconds).
>>
>> Hey, there's one for you, Gil. One June 30, could one have set an STIMER GMT 
>> of 23:59:60.hh? (I think I know the answer.)
>>
>> The interval processing has no good answer IMHO. Sure, it seems like 4 
>> seconds after 23:59:58 on June 30 should be 00:00:01, not :02 -- but how far 
>> do you carry that? What is 30 days after 23:59:58? Would you expect it to be 
>> 23:59:57 on July 30? To be consistent, it should be.
>>
>> Can a prisoner serving a 30-year sentence demand to be released 'n' seconds 
>> early to account for the leap seconds of incarceration?
>>
>> How long is a day? Is it exactly 24 hours, or is it variable, depending on 
>> what day you are talking about?
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Paul Gilmartin
>> Sent: Friday, July 03, 2015 2:24 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Leap Second today!
>>
>> On Fri, 3 Jul 2015 15:33:37 -0500, George Kozakos wrote:

 So it actually waits for 4 seconds rather than the 3 requested.
>>>
>>>The problem is that at 17:59:59 when the STIMER is processed we don't
>>>know that a leap second will occur at 18:00.
>>>
>> Actually, you could have known that for 4 months, ever since the IERS 
>> announced the leap second.  (Less the time it takes for a PTF to be created, 
>> distributed, and installed.)  I don't believe (but I've already been wrong 
>> once) that a programmer can request a GMT or LT more than 4 months in the 
>> future.
>>
>> So, when a leap second occurs, scan the timer queue.  You have nothing 
>> better to do; user programs are nondispatchable.
>>
>> o If an entry is for an interval, leave it alone.
>>
>> o If an entry is for GMT or LT, add a second and replace in
>>   the queue in proper order.
>>
>> At a Daylight Saving Time boundary, scan the queue.
>>
>> o If an entry is for an interval or GMT, leave it alone.
>>
>> o If an entry is for LT, subtract an hour in the Spring
>>   (It may pop immediately).  In the Fall, add an hour
>>   If it's in the ambiguous hour, it will not pop for another
>>   hour.
>>
>> --
>> 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: Leap Second today!

[Paul Gilmartin]

On Fri, 3 Jul 2015 16:41:03 -0500, George Kozakos wrote:
>
>Leap seconds are scheduled via STP or the sysplex timer.
>
>z/OS can only know about a leap second when it gets the Time Control
>Parameter Change event external interrupt for STP or the ETR Alert
>event external interrupt for ETR.
> 
Tunnel vision.  The same information that is provided to STP could also
be made available to the code behind the STIMER macro and used
to make the wait expire as accurately as possible.  A leap second
is only a second.  Daylight Saving can advance clocks by an hour.
People don't wan't to be an hour late for appointments.

On 2011-12-29 24:00:00, Independent Samoa advanced its clocks
by 24 hours, to 2011-12031 00:00:00.  There was no December 30.
This was announced well in advance, and published in advance in
the IANA database.  It could have been handled.  Linux systems
had it right well in advance of the critical date.


On Fri, 3 Jul 2015 14:46:30 -0700, Charles Mills wrote:

>> I don't believe (but I've already been wrong once) that a programmer can 
>> request a GMT or LT more than 4 months in the future.
>
>I think you're right. An LT or GMT STIMER pops the next time that time of day 
>occurs, so it can be at most 23:59:59.99 away (23:59:60.99 counting leap 
>seconds).
>
>Hey, there's one for you, Gil. One June 30, could one have set an STIMER GMT 
>of 23:59:60.hh? (I think I know the answer.)
>
>The interval processing has no good answer IMHO. Sure, it seems like 4 seconds 
>after 23:59:58 on June 30 should be 00:00:01, not :02 -- but how far do you 
>carry that? What is 30 days after 23:59:58? Would you expect it to be 23:59:57 
>on July 30? To be consistent, it should be. 
>
Seconds are easy.  The programmer should be able to request an interval in 
seconds,
up to about 2,000,000.00.  STIMER should convert that to TOD format; add the 
current
content of the TOD clock (report error if overflow); and load the Comparator 
register.

-MM-DD hh:mm:ss.hh (not an interval), the macro should do best it can from
available information.  Programmers should be cautioned that there are 
unpredictable
effects due to IERS actions and legislative whims.

>Can a prisoner serving a 30-year sentence demand to be released 'n' seconds 
>early to account for the leap seconds of incarceration?
>
"The law is a ass."  English Common Law says a person is of legal age on the
day before his 21st birthday.  The Colorado liquor code elected, for no good
reason, to deviate from this and explicitly prohibit sale of alcohol until the
purchaser's 21st birthday.  Did they really believe that in 24 hours an
individual shouldgain sufficient maturity and discretion to merit the deviation?

>How long is a day? Is it exactly 24 hours, or is it variable, depending on 
>what day you are talking about?
>
Use seconds.  That's why there are atomic clocks, and STP refers to them
and TOD runs at their rate.
 
-- gil

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

Re: Leap Second today!

[Mike Schwab]

We could switch to a day is the time between actual solar noons.
Or adopt the ancient Hebrew definition of 12 hours of sunlight each
day and 12 hours of nighttime every day.

On Fri, Jul 3, 2015 at 4:46 PM, Charles Mills  wrote:
>> I don't believe (but I've already been wrong once) that a programmer can 
>> request a GMT or LT more than 4 months in the future.
>
> I think you're right. An LT or GMT STIMER pops the next time that time of day 
> occurs, so it can be at most 23:59:59.99 away (23:59:60.99 counting leap 
> seconds).
>
> Hey, there's one for you, Gil. One June 30, could one have set an STIMER GMT 
> of 23:59:60.hh? (I think I know the answer.)
>
> The interval processing has no good answer IMHO. Sure, it seems like 4 
> seconds after 23:59:58 on June 30 should be 00:00:01, not :02 -- but how far 
> do you carry that? What is 30 days after 23:59:58? Would you expect it to be 
> 23:59:57 on July 30? To be consistent, it should be.
>
> Can a prisoner serving a 30-year sentence demand to be released 'n' seconds 
> early to account for the leap seconds of incarceration?
>
> How long is a day? Is it exactly 24 hours, or is it variable, depending on 
> what day you are talking about?
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, July 03, 2015 2:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Leap Second today!
>
> On Fri, 3 Jul 2015 15:33:37 -0500, George Kozakos wrote:
>>>
>>> So it actually waits for 4 seconds rather than the 3 requested.
>>
>>The problem is that at 17:59:59 when the STIMER is processed we don't
>>know that a leap second will occur at 18:00.
>>
> Actually, you could have known that for 4 months, ever since the IERS 
> announced the leap second.  (Less the time it takes for a PTF to be created, 
> distributed, and installed.)  I don't believe (but I've already been wrong 
> once) that a programmer can request a GMT or LT more than 4 months in the 
> future.
>
> So, when a leap second occurs, scan the timer queue.  You have nothing better 
> to do; user programs are nondispatchable.
>
> o If an entry is for an interval, leave it alone.
>
> o If an entry is for GMT or LT, add a second and replace in
>   the queue in proper order.
>
> At a Daylight Saving Time boundary, scan the queue.
>
> o If an entry is for an interval or GMT, leave it alone.
>
> o If an entry is for LT, subtract an hour in the Spring
>   (It may pop immediately).  In the Fall, add an hour
>   If it's in the ambiguous hour, it will not pop for another
>   hour.
>
> --
> 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: Leap Second today!

[Jakubek, Jan]

Replying to myself...likely I'm wrong.

I looked through my syslogs but could not find any entry with time stamp of 
2015181 19:59:60.xx (June 30th).

Did somebody see a syslog entry with date / time 2015181 19:59:60.xx ? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jakubek, Jan
Sent: Friday, July 03, 2015 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

I think leap second is "magical".
All time measuring devices that respect it - stop for one second to observe it.
Do I have it right?

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

Re: Leap Second today!

[Charles Mills]

> I don't believe (but I've already been wrong once) that a programmer can 
> request a GMT or LT more than 4 months in the future.

I think you're right. An LT or GMT STIMER pops the next time that time of day 
occurs, so it can be at most 23:59:59.99 away (23:59:60.99 counting leap 
seconds).

Hey, there's one for you, Gil. One June 30, could one have set an STIMER GMT of 
23:59:60.hh? (I think I know the answer.)

The interval processing has no good answer IMHO. Sure, it seems like 4 seconds 
after 23:59:58 on June 30 should be 00:00:01, not :02 -- but how far do you 
carry that? What is 30 days after 23:59:58? Would you expect it to be 23:59:57 
on July 30? To be consistent, it should be. 

Can a prisoner serving a 30-year sentence demand to be released 'n' seconds 
early to account for the leap seconds of incarceration?

How long is a day? Is it exactly 24 hours, or is it variable, depending on what 
day you are talking about?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, July 03, 2015 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

On Fri, 3 Jul 2015 15:33:37 -0500, George Kozakos wrote:
>>
>> So it actually waits for 4 seconds rather than the 3 requested.
>
>The problem is that at 17:59:59 when the STIMER is processed we don't 
>know that a leap second will occur at 18:00.
> 
Actually, you could have known that for 4 months, ever since the IERS announced 
the leap second.  (Less the time it takes for a PTF to be created, distributed, 
and installed.)  I don't believe (but I've already been wrong once) that a 
programmer can request a GMT or LT more than 4 months in the future.

So, when a leap second occurs, scan the timer queue.  You have nothing better 
to do; user programs are nondispatchable.

o If an entry is for an interval, leave it alone.

o If an entry is for GMT or LT, add a second and replace in
  the queue in proper order.

At a Daylight Saving Time boundary, scan the queue.

o If an entry is for an interval or GMT, leave it alone.

o If an entry is for LT, subtract an hour in the Spring
  (It may pop immediately).  In the Fall, add an hour
  If it's in the ambiguous hour, it will not pop for another
  hour.

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

Re: Leap Second today!

[George Kozakos]

> >> So it actually waits for 4 seconds rather than the 3 requested.
> >
> >The problem is that at 17:59:59 when the STIMER is processed we
> >don't know that a leap second will occur at 18:00.
> >
> Actually, you could have known that for 4 months, ever since the
> IERS announced the leap second.  (Less the time it takes for a
> PTF to be created, distributed, and installed.)  I don't believe
> (but I've already been wrong once) that a programmer can request
> a GMT or LT more than 4 months in the future.

Leap seconds are scheduled via STP or the sysplex timer.

z/OS can only know about a leap second when it gets the Time Control
Parameter Change event external interrupt for STP or the ETR Alert
event external interrupt for ETR.

George Kozakos
z/OS Software Service, Level 2 Supervisor

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

Re: Leap Second today!

[Charles Mills]

How I knew this: 
https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/ylLbkY32dM4 

Can't seem to find OA14062 anymore.

I am not so negative on z/OS time support as you are but all of these little 
buglets kind of amaze me. I appreciate that this is tricky stuff to get right, 
with all of the boundary conditions and so forth, but if I were writing 
STIMER-type support for a million-dollar operating system I would try my 
damnedest to get it perfect.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, July 03, 2015 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

On Fri, 3 Jul 2015 13:13:32 -0700, Charles Mills wrote:

>> the syntax of STIMER macro provides no way to specify a time past 
>> midnight
>
>Au contraire (assuming "STIMER" includes STIMERM). I issue
>
> STIMERM SET,LT=MIDNITE,EXIT=POP_MIDNITE,ID=ID_MIDNITE,+
>   ERRET=ERR_MIDNITE,PARM=AWORKAR,MF=(E,STIMERML_SET)
>
>all the time, where
>
>MIDNITE  DCCL8'0100'   Midnight + 1 second 00:00:01.00
> 
I hadn't known that, nor was I able to suss it out from the Manual.  May I 
assume that if you issue your command at 00:00:00.5, the timer pops in another 
0.5 seconds, which may or may not be what you intend.

Ugly.  If STIMER LT is issued close enough to the requested time it's 
unpredictable, depending on code path and dispatchability, whether it waits for 
0.01 second or 863399.99 seconds.

Ugly; ugly!  If the request is for an interval, just add it to the TOD value 
and load the Clock Comparator.

If the request is for LT or GMT, compare to current time,  If the requested 
time is less than the current time, add a day.

If GMT, adjust for leap seconds when they occur.

If LT, adjust for leap seconds and Daylight Saving Time boundaries when they 
occur.

My head hurts.

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

Re: HMIGRATE vs. ENQ

[Paul Gilmartin]

On Wed, 1 Jul 2015 08:42:45 -0400, Shmuel Metz (Seymour J.) wrote:

>on 06/26/2015 at 12:12 PM, Paul Gilmartin said:
>
>>Isn't there a timing window right here?
>
>Not unless you add FREE=CLOSE to the DD.
> 
No.

>>Anyone else waiting in the queue will grab an ENQ at this point?
>
>At what point? SYSZDSN/data.set.name is held for the life of the job.
>Or does CONSOLIDATE only queue a request rather than doing the work
>itself?
>
Not for the life of the job; only through the last job step containing a
DD statement.

I believe this thread was discussing two steps:

//STEP1  EXEC  PGM=IEFBR71
//X DD  DISP=OLD,DSN=DATA.SET.NAME
//*
//* STEP 1 concludes; ENQ is freed; timing window occurs.
//*
//STEP2  EXEC  PGM=IKJEFT01
//SYSTSIN  DD  *
 HMIGRATE 'DATA.SET.NAME' WAIT
...

-- gil

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

Re: Leap Second today!

[Paul Gilmartin]

On Fri, 3 Jul 2015 15:33:37 -0500, George Kozakos wrote:
>>
>> So it actually waits for 4 seconds rather than the 3 requested.
>
>The problem is that at 17:59:59 when the STIMER is processed we
>don't know that a leap second will occur at 18:00.
> 
Actually, you could have known that for 4 months, ever since the
IERS announced the leap second.  (Less the time it takes for a
PTF to be created, distributed, and installed.)  I don't believe
(but I've already been wrong once) that a programmer can request
a GMT or LT more than 4 months in the future.

So, when a leap second occurs, scan the timer queue.  You
have nothing better to do; user programs are nondispatchable.

o If an entry is for an interval, leave it alone.

o If an entry is for GMT or LT, add a second and replace in
  the queue in proper order.

At a Daylight Saving Time boundary, scan the queue.

o If an entry is for an interval or GMT, leave it alone.

o If an entry is for LT, subtract an hour in the Spring
  (It may pop immediately).  In the Fall, add an hour
  If it's in the ambiguous hour, it will not pop for another
  hour.

My head hurts.

-- gil

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

Re: Leap Second today!

[Paul Gilmartin]

On Fri, 3 Jul 2015 13:13:32 -0700, Charles Mills wrote:

>> the syntax of STIMER macro provides no way to specify a time past midnight
>
>Au contraire (assuming "STIMER" includes STIMERM). I issue 
>
> STIMERM SET,LT=MIDNITE,EXIT=POP_MIDNITE,ID=ID_MIDNITE,+
>   ERRET=ERR_MIDNITE,PARM=AWORKAR,MF=(E,STIMERML_SET)
>
>all the time, where
>
>MIDNITE  DCCL8'0100'   Midnight + 1 second 00:00:01.00
> 
I hadn't known that, nor was I able to suss it out from the Manual.  May
I assume that if you issue your command at 00:00:00.5, the timer pops
in another 0.5 seconds, which may or may not be what you intend.

Ugly.  If STIMER LT is issued close enough to the requested time it's
unpredictable, depending on code path and dispatchability, whether
it waits for 0.01 second or 863399.99 seconds.

Ugly; ugly!  If the request is for an interval, just add it to the TOD
value and load the Clock Comparator.

If the request is for LT or GMT, compare to current time,  If the
requested time is less than the current time, add a day.

If GMT, adjust for leap seconds when they occur.

If LT, adjust for leap seconds and Daylight Saving Time boundaries
when they occur.

My head hurts.

-- gil

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

Re: Python FTP binary object file upload

[Shmuel Metz (Seymour J.)]

In <2287664539861543.wa.paulgboulderaim@listserv.ua.edu>, on
06/29/2015
   at 04:54 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>This appears to be saying not that "QUOTE" (quotation marks in the
>RFC) is an FTP protocol command,

That's specific to QUOTE, and doesn't restate what is sted elsewhere.
Near the begining the RFC's describe the elements of FTP, and
differentiate between the user interface and the command syntax; the
latter being part of the protocol.

>While it doesn't say so,

For good reasons.

>I take "must implement" to refer to the user interface and 
>"must ... support[]" to refer to the network protocol.

No, each refers to the network protocol, which includes the syntax of
commands from the UI.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: HMIGRATE vs. ENQ

[Shmuel Metz (Seymour J.)]

In <1596193685427433.wa.paulgboulderaim@listserv.ua.edu>, on
06/26/2015
   at 12:12 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Isn't there a timing window right here?

Not unless you add FREE=CLOSE to the DD.

>Anyone else waiting in the queue will grab an ENQ at this point?

At what point? SYSZDSN/data.set.name is held for the life of the job.
Or does CONSOLIDATE only queue a request rather than doing the work
itself?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Split screen ISPF edit copy?

[Shmuel Metz (Seymour J.)]

In <558c83a8.2030...@aim.com>, on 06/25/2015
   at 04:41 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Has THE actually been ported to z/OS?

If you have a THE port available then it's been ported. If not, who
knows.

>But the refutation of that, as of 64-bit assembler, will be, "We've
>been doing fine without that for nigh on 50 years.

Not if you present a sound business case.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Leap Second today!

[George Kozakos]

> >> If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
> >> would the wait have expired at 18:00:01?
> >
> >No, it would expire at 18:00:02 regardless of whether you are using
> >leap seconds
> >
> And since the Leap Second code is ignorant of whether an entry
> corresponds to a clock time or a duration, it assumes the former
> and adds the second regardless.  Particularly silly if the wait
> spans midnight since the syntax of STIMER macro provides no
> way to specify a time past midnight, so it must have been a
> duration.
>
> So it actually waits for 4 seconds rather than the 3 requested.

The problem is that at 17:59:59 when the STIMER is processed we
don't know that a leap second will occur at 18:00.

George Kozakos
z/OS Software Service, Level 2 Supervisor

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

Re: Leap Second today!

[Charles Mills]

> the syntax of STIMER macro provides no way to specify a time past midnight

Au contraire (assuming "STIMER" includes STIMERM). I issue 

 STIMERM SET,LT=MIDNITE,EXIT=POP_MIDNITE,ID=ID_MIDNITE,+
   ERRET=ERR_MIDNITE,PARM=AWORKAR,MF=(E,STIMERML_SET)

all the time, where

MIDNITE  DCCL8'0100'   Midnight + 1 second 00:00:01.00

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, July 03, 2015 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

On Fri, 3 Jul 2015 14:42:31 -0500, George Kozakos wrote:

>> In my time zone, the leap second occurred at 17:59:60.  So, I wonder 
>> about the z/OS STIMER macro:
>>
>> If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01]
>> would the wait have expired in 3 seconds?
>
>Yes, if you scheduled the leap second via STP or ETR.
>It would expire in 2 seconds if you aren't using leap seconds
> 
OK.  I imagine that there's a queue of Clock Comparator Register values, and 
that Leap Second processing scans that queue and adds one second to each value.

>> If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
>> would the wait have expired at 18:00:01?
>
>No, it would expire at 18:00:02 regardless of whether you are using 
>leap seconds
> 
And since the Leap Second code is ignorant of whether an entry corresponds to a 
clock time or a duration, it assumes the former and adds the second regardless. 
 Particularly silly if the wait spans midnight since the syntax of STIMER macro 
provides no way to specify a time past midnight, so it must have been a 
duration.

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

Re: Leap Second today!

[Jakubek, Jan]

I think leap second is "magical".
All time measuring devices that respect it - stop for one second to observe it.
Do I have it right?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of George Kozakos
Sent: Friday, July 03, 2015 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Leap Second today!

> In my time zone, the leap second occurred at 17:59:60.  So, I wonder 
> about the z/OS STIMER macro:
>
> If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01]
> would the wait have expired in 3 seconds?

Yes, if you scheduled the leap second via STP or ETR.
It would expire in 2 seconds if you aren't using leap seconds

> If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
> would the wait have expired at 18:00:01?

No, it would expire at 18:00:02 regardless of whether you are using leap seconds

>
> Unless the answer to both questions is "Yes," there's a bug.
>
> -- gil

George Kozakos
z/OS Software Service, Level 2 Supervisor

--
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: Leap Second today!

[Paul Gilmartin]

On Fri, 3 Jul 2015 14:42:31 -0500, George Kozakos wrote:

>> In my time zone, the leap second occurred at 17:59:60.  So, I wonder
>> about the z/OS STIMER macro:
>>
>> If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01]
>> would the wait have expired in 3 seconds?
>
>Yes, if you scheduled the leap second via STP or ETR.
>It would expire in 2 seconds if you aren't using leap seconds
> 
OK.  I imagine that there's a queue of Clock Comparator Register
values, and that Leap Second processing scans that queue and
adds one second to each value.

>> If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
>> would the wait have expired at 18:00:01?
>
>No, it would expire at 18:00:02 regardless of whether you are using
>leap seconds
> 
And since the Leap Second code is ignorant of whether an entry
corresponds to a clock time or a duration, it assumes the former
and adds the second regardless.  Particularly silly if the wait
spans midnight since the syntax of STIMER macro provides no
way to specify a time past midnight, so it must have been a
duration.

So it actually waits for 4 seconds rather than the 3 requested.

>> Unless the answer to both questions is "Yes," there's a bug.
>> 
There's a bug.

-- gil

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

Re: Leap Second today!

[George Kozakos]

> In my time zone, the leap second occurred at 17:59:60.  So, I wonder
> about the z/OS STIMER macro:
>
> If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01]
> would the wait have expired in 3 seconds?

Yes, if you scheduled the leap second via STP or ETR.
It would expire in 2 seconds if you aren't using leap seconds

> If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds]
> would the wait have expired at 18:00:01?

No, it would expire at 18:00:02 regardless of whether you are using
leap seconds

>
> Unless the answer to both questions is "Yes," there's a bug.
>
> -- gil

George Kozakos
z/OS Software Service, Level 2 Supervisor

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

Re: Downgrading ENQ

[Paul Gilmartin]

On Fri, 3 Jul 2015 11:07:31 -0500, Scott Fagen wrote:

>On Thu, 2 Jul 2015 09:31:37 -0500, Paul Gilmartin wrote:
>
>>Suppose:
>>ALLOCATE DD(DDSHR) DSN(FOO.BAR) SHR
>>There is now an ENQ SHR SYSDSN FOO.BAR
>>
>>Then:
>>ALLOCATE DD(DDEXC) DSN(FOO.BAR) OLD
>>The ENQ is upgraded to EXC
>>
>>... some stuff ...  Then:
>>FREE DD(DDEXC)
>>is the ENQ downgraded back to SHR?  Why or why not?
>>
>>-- gil
>
>See 
>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0za100/mvssysdsn.htm
>
Which says much about JCL, but nothing about dynamic allocation which
was the subject of my quetion and example.

-- gil

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

Re: Downgrading ENQ

[Scott Fagen]

On Thu, 2 Jul 2015 09:31:37 -0500, Paul Gilmartin  wrote:

>Suppose:
>ALLOCATE DD(DDSHR) DSN(FOO.BAR) SHR
>There is now an ENQ SHR SYSDSN FOO.BAR
>
>Then:
>ALLOCATE DD(DDEXC) DSN(FOO.BAR) OLD
>The ENQ is upgraded to EXC
>
>... some stuff ...  Then:
>FREE DD(DDEXC)
>is the ENQ downgraded back to SHR?  Why or why not?
>
>-- gil

See 
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0za100/mvssysdsn.htm

Scott Fagen
Chief Architect - Mainframe
CA Technologies

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

Re: How does one definitively recognize a temp dataset by name?

[Charles Mills]

> If you would detail your requirements, a better answer can be provided

SMF 42 reports a member update or delete. Is this a file integrity event? Is 
this worth correlating, or is it noise?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, July 03, 2015 6:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does one definitively recognize a temp dataset by name?

What are you looking for in SMF Type 42 Records that is not there?  SMF Type 42 
has been expanded to cover a lot of information other than SMS Statistics.

Many times you need to combine more than one SMF Record Type to get the picture.

If you would detail your requirements, a better answer can be provided

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

Re: SMS ACS ROUTINE VARIABLES

[Lizette Koehler]

Or, if you want to prevent ALL users from creating PDS/E datasets, then you
can make a more general ACS statement.

There are some functions that need to create PDS/E datasets.  So figure out
which is the easier to maintain

A FILTLIST with an INCLUDE for 
1)  Users that can create PDS/E
Or 
2) Users that cannot create PDS/E

Remember, if you are planning to go to Enterprise COBOL V5 and above,
datasets for the Cobol Compiler and the Load Module will need to be PDS/E
datasets.

Based on what I have seen for PDS/E V2 - I can see at some point that IBM
might make a direction statement that PDS datasets should only be PDS/E
datasets.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tabor, Rich
> Sent: Friday, July 03, 2015 7:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS ACS ROUTINE VARIABLES
> 
> Comparing &USER to &JOB might be useful.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
> Sent: Friday, July 03, 2015 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] SMS ACS ROUTINE VARIABLES
> 
> I saw the &USER variable in the doc but I was thrown off track when I read
> the explanation of &USER which says the following : The user ID of the
> person allocating the dataset.  I would like to try your suggestion
however
> since we have multiple batch users begining @ would a @* work because the
> job(s) are submitted by the scheduler?
> 
> 
> On Thu, 7/2/15, Greg Shirey  wrote:
> 
>  Subject: Re: SMS ACS ROUTINE VARIABLES
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Thursday, July 2, 2015, 1:46 PM
> 
>  &USER is the User ID
>  associated with the batch job.   If you have a  FILTLIST of the User IDs
called,
> say, "NOPDSES",  then you can code:
> 
>  WHEN
>  (&USER EQ &NOPDSES  AND
> 
>&DSNTYPE EQ 'LIB')  THEN DO
>  WRITE 'NOT ALLOWED FOR PDSE'
>  EXIT CODE(12)
> 
>  END
> 
> 
>  HTH,
>  Greg Shirey
>  Ben E. Keith Company
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
>  Sent: Thursday,
>  July 02, 2015 12:35 PM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: SMS ACS ROUTINE VARIABLES
> 
>  Hallo All,
> 
>  I am stuck with trying to figure out how I can  code the variable for a
Batch
> userid.  For examle users  aren't allowed to create a PDSe.  I thought by
> coding  the condition for the user's batch id it would solve the  problem.
> However, I looked at all the SMS ACS read  variable list but there is none
for a
> batch id.
>  Could anyone suggest how I can go about  this?
> 

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

FW: Help finding on-line SAS training

[Marty Wertheim]

I teach a SAS class at a local community college and we use SAS on Demand for  
Academics for our SAS platform.  It is browser-accessible and you don’t have to 
be a college student to register for it.  They also offer a free Programming I 
class.  
http://www.sas.com/en_us/industry/higher-education/on-demand-for-academics.html#independent-learners
 

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

Re: SMS ACS ROUTINE VARIABLES

[Ted MacNEIL]

A point of curiosity. Why are your users not allowed to create PDSE datasets?

-
-teD
-
  Original Message  
From: willie bunter
Sent: Friday, July 3, 2015 09:34
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SMS ACS ROUTINE VARIABLES

I saw the &USER variable in the doc but I was thrown off track when I read the 
explanation of &USER which says the following : The user ID of the person 
allocating the dataset. I would like to try your suggestion however since we 
have multiple batch users begining @ would a @* work because the job(s) are 
submitted by the scheduler?


On Thu, 7/2/15, Greg Shirey  wrote:

Subject: Re: SMS ACS ROUTINE VARIABLES
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 2, 2015, 1:46 PM

&USER is the User ID
associated with the batch job.   If you have a
FILTLIST of the User IDs called, say, "NOPDSES",
then you can code:

WHEN
(&USER EQ &NOPDSES  AND    
   
  &DSNTYPE EQ 'LIB')  THEN DO
    WRITE 'NOT ALLOWED FOR PDSE'
    EXIT CODE(12)
   
END


HTH,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of willie bunter
Sent: Thursday,
July 02, 2015 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS ACS ROUTINE VARIABLES

Hallo All,

I am stuck with trying to figure out how I can
code the variable for a Batch userid.  For examle users
aren't allowed to create a PDSe.  I thought by coding
the condition for the user's batch id it would solve the
problem.  However, I looked at all the SMS ACS read
variable list but there is none for a batch id.
Could anyone suggest how I can go about
this?

--
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: SMS ACS ROUTINE VARIABLES

[Lizette Koehler]

My recommendation is to try it.  It is the best teaching tool.  And remember
to ISMF TEST function for testing ACS code


Remember to follow the conventions needed to code masked variables vs.
specific data for variables.

So long as the name follows normal z/OS policy - you should be fine.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
> Sent: Friday, July 03, 2015 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS ACS ROUTINE VARIABLES
> 
> I saw the &USER variable in the doc but I was thrown off track when I read
> the explanation of &USER which says the following : The user ID of the
> person allocating the dataset.  I would like to try your suggestion
however
> since we have multiple batch users begining @ would a @* work because the
> job(s) are submitted by the scheduler?
> 
> 
> On Thu, 7/2/15, Greg Shirey  wrote:
> 
>  Subject: Re: SMS ACS ROUTINE VARIABLES
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Received: Thursday, July 2, 2015, 1:46 PM
> 
>  &USER is the User ID
>  associated with the batch job.   If you have a  FILTLIST of the User IDs
called,
> say, "NOPDSES",  then you can code:
> 
>  WHEN
>  (&USER EQ &NOPDSES  AND
> 
>    &DSNTYPE EQ 'LIB')  THEN DO
>      WRITE 'NOT ALLOWED FOR PDSE'
>      EXIT CODE(12)
> 
>  END
> 
> 
>  HTH,
>  Greg Shirey
>  Ben E. Keith Company
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
>  Sent: Thursday,
>  July 02, 2015 12:35 PM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: SMS ACS ROUTINE VARIABLES
> 
>  Hallo All,
> 
>  I am stuck with trying to figure out how I can  code the variable for a
Batch
> userid.  For examle users  aren't allowed to create a PDSe.  I thought by
> coding  the condition for the user's batch id it would solve the
> problem.  However, I looked at all the SMS ACS read  variable list but
there is
> none for a batch id.
>  Could anyone suggest how I can go about  this?
> 

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

Re: How does one definitively recognize a temp dataset by name?

[David Crayford]

On 3/07/2015 4:30 PM, Barry Merrill wrote:

SMF14/15 SMF14RIN Bit 3 SMF14TDS. Temporary data set.


Thanks Baz! You really are the doyen of SMF and that information is very 
useful to me.


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

Re: How does one definitively recognize a temp dataset by name?

[Lizette Koehler]

What are you looking for in SMF Type 42 Records that is not there?  SMF Type 42 
has been expanded to cover a lot of information other than SMS Statistics.

Many times you need to combine more than one SMF Record Type to get the picture.

If you would detail your requirements, a better answer can be provided

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Charles Mills
> Sent: Friday, July 03, 2015 6:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How does one definitively recognize a temp dataset by name?
> 
> Duh. Why didn't I notice that? Thank you.
> 
> Now if IBM had only done the same thing for SMF 42.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Barry Merrill
> Sent: Friday, July 03, 2015 1:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How does one definitively recognize a temp dataset by name?
> 
> SMF14/15 SMF14RIN Bit 3 SMF14TDS. Temporary data set.

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

Re: SMS ACS ROUTINE VARIABLES

[willie bunter]

I saw the &USER variable in the doc but I was thrown off track when I read the 
explanation of &USER which says the following : The user ID of the person 
allocating the dataset.  I would like to try your suggestion however since we 
have multiple batch users begining @ would a @* work because the job(s) are 
submitted by the scheduler?


On Thu, 7/2/15, Greg Shirey  wrote:

 Subject: Re: SMS ACS ROUTINE VARIABLES
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 2, 2015, 1:46 PM
 
 &USER is the User ID
 associated with the batch job.   If you have a
 FILTLIST of the User IDs called, say, "NOPDSES",
 then you can code:
 
 WHEN
 (&USER EQ &NOPDSES  AND    
    
   &DSNTYPE EQ 'LIB')  THEN DO
     WRITE 'NOT ALLOWED FOR PDSE'
     EXIT CODE(12)
    
 END
 
 
 HTH,
 Greg Shirey
 Ben E. Keith Company 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Thursday,
 July 02, 2015 12:35 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: SMS ACS ROUTINE VARIABLES
 
 Hallo All,
 
 I am stuck with trying to figure out how I can
 code the variable for a Batch userid.  For examle users
 aren't allowed to create a PDSe.  I thought by coding
 the condition for the user's batch id it would solve the
 problem.  However, I looked at all the SMS ACS read
 variable list but there is none for a batch id.
 Could anyone suggest how I can go about
 this?
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: How does one definitively recognize a temp dataset by name?

[Charles Mills]

Duh. Why didn't I notice that? Thank you.

Now if IBM had only done the same thing for SMF 42.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barry Merrill
Sent: Friday, July 03, 2015 1:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does one definitively recognize a temp dataset by name?

SMF14/15 SMF14RIN Bit 3 SMF14TDS. Temporary data set.

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

Re: CICS Upgrade

[Jantje.]

On Thu, 2 Jul 2015 14:00:47 +0530, zos reader  wrote:

>Hi All,
>
>We are planning to Upgrade CICS 3.1 to current level in our Shop running on
>z/OS 1.13.
>Can someone help me by sharing any manuals or documents or any ideas for
>upgrading CICS.


You will probably get more respons on the CICS-L.
https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L

Cheers,

Jantje.

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

Re: EMCS Console identities

[Terry Sambrooks]

Hi Rob,

Thanks for your pointer about the SDSF options panel, I blanked out the
invalid userid stored there and everything is now as it should be.

My only remaining issue is whether I spend time investigation why the value
was incorrect or not, I probably will not as it is likely that I changed it
somehow in the past and simply forgot.

Thanks again.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


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

Re: How does one definitively recognize a temp dataset by name?

[Barry Merrill]

SMF14/15 SMF14RIN Bit 3 SMF14TDS. Temporary data set.


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 – Still works, received as email
Tel:  214 351 1966 – Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, July 02, 2015 10:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does one definitively recognize a temp dataset by name?

SMF 15 reports a dataset output CLOSE. SMF 42 reports a member update or 
delete. Is this a file integrity event? Is this worth correlating, or is it 
noise?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Thursday, July 02, 2015 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does one definitively recognize a temp dataset by name?

On Thu, 2 Jul 2015 13:55:46 -0700, Charles Mills  wrote:

>Is there a definitive rule for recognizing *by name* a system temporary 
>dataset? The actual name, not &&WHATEVER. I am checking for (using 
>RACF EGN notation here to express my rule) 'SYS*.T*.R*.**'. Is that 
>sufficient to preclude false positives? Will it produce false 
>negatives? Is it over-specified?

Just to be clear: you are only interested in temporary data sets where the 
system generated the name? You do not care about temporary data sets where the 
user specified the name fully, by using something like: 
DSNAME=X.Y,DISP=(NEW,DELETE),SPACE=...

If you really want ALL temporary data sets then you cannot definitively find 
them by name.

It would help if we knew what you were really trying to accomplish :)

--
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: Forbes: IT Professionals Don't Have What The Tech Industry Wants

[Martin Packer]

And then I think we should encourage workers to emigrate.

And then there are people like me with worldwide jobs: Exactly WHOSE job 
am I stealing? And I assert such jobs SHOULD exist; Many's the time I've 
used the experience from a customer in Country A to inform what I'm doing 
with a customer in Country B.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Timothy Sipples 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   03/07/2015 08:53
Subject:Re: Forbes: IT Professionals Don't Have What The Tech 
Industry Wants
Sent by:IBM Mainframe Discussion List 



One should not overinterpret the available wage evidence. Businesses do
have reasonable needs to bring in foreign workers and managers at least 
for
some period of time. Export-oriented businesses, for example, really do
need to have staff circulation to/from overseas in order to boost their
exports. It's also fairly easy to imagine skills requirements that only a
foreign worker could address in reasonable fashion within a reasonable
period of time. I imagine there's not a super abundance of experts in
German contract law (and German language contracts) living in Peoria,
Illinois, for example, but that sort of skill might be super important to 
a
particular employer.

Some countries -- Japan comes to mind -- have a ratio (or at least a ratio
sanity check) policy, meaning that employers are permitted to bring in X
number of foreign workers as long as they maintain or better yet increase
the number of local workers by some multiple of X. Perhaps that ratio
varies by profession or industry to some extent. That sort of approach
would appear to address at least the bulk of employers' needs.

To summarize, foreign workers can and should be welcomed...within a
reasonable immigration policy. "Reasonable" means based on the economics
and reality. Just to pick an example, I'd really like to see even more top
university graduates in the U.S. be able to pursue careers in the U.S. if
they wish and under reasonable terms. That sort of approach would be
pro-skills, pro-talent. As another example, as I understand it the current
H-1B visa program is tied to a specific sponsoring employer. In my view
foreign workers shouldn't be captive to a specific employer. They should 
be
able to "jump ship" for better working conditions and compensation, at
least after, say, 120 days. Otherwise (in my view) some of their employers
would be tempted to exploit them in various ways including compensating
them below market rate for their skills.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA


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



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

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

Re: Forbes: IT Professionals Don't Have What The Tech Industry Wants

[Timothy Sipples]

One should not overinterpret the available wage evidence. Businesses do
have reasonable needs to bring in foreign workers and managers at least for
some period of time. Export-oriented businesses, for example, really do
need to have staff circulation to/from overseas in order to boost their
exports. It's also fairly easy to imagine skills requirements that only a
foreign worker could address in reasonable fashion within a reasonable
period of time. I imagine there's not a super abundance of experts in
German contract law (and German language contracts) living in Peoria,
Illinois, for example, but that sort of skill might be super important to a
particular employer.

Some countries -- Japan comes to mind -- have a ratio (or at least a ratio
sanity check) policy, meaning that employers are permitted to bring in X
number of foreign workers as long as they maintain or better yet increase
the number of local workers by some multiple of X. Perhaps that ratio
varies by profession or industry to some extent. That sort of approach
would appear to address at least the bulk of employers' needs.

To summarize, foreign workers can and should be welcomed...within a
reasonable immigration policy. "Reasonable" means based on the economics
and reality. Just to pick an example, I'd really like to see even more top
university graduates in the U.S. be able to pursue careers in the U.S. if
they wish and under reasonable terms. That sort of approach would be
pro-skills, pro-talent. As another example, as I understand it the current
H-1B visa program is tied to a specific sponsoring employer. In my view
foreign workers shouldn't be captive to a specific employer. They should be
able to "jump ship" for better working conditions and compensation, at
least after, say, 120 days. Otherwise (in my view) some of their employers
would be tempted to exploit them in various ways including compensating
them below market rate for their skills.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA


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