Change in GETMAIN behavior

[Leonard.John.J]

Virtual Storage Manager in z/OS 1.10 HBB7750 which results in different behavior when storage is Getmained
We are trying to understand the ramifications of this change to the GETMAIN and I was wondering if anyone else has dealt with this. I have this document that says

“References to GETMAIN also apply to STORAGE OBTAIN.

The description and behavior of the GETMAIN macro as documented
in the z/OS MVS Assembler Services Reference remain unchanged
by this APAR. With respect to whether or not the system zeroes
the newly getmained storage, the guidelines remain as follows:

When you obtain storage, the system clears the requested storage
to zeros if you obtain either:
o 8192 bytes or more from a pageable, private storage subpool.
o 4096 bytes or more from a pageable, private storage subpool,
with BNDRY=PAGE specified

In all other cases you must NOT assume that the storage is
cleared to zeros, unless indicated by the return code when
CHECKZERO=YES is specified.”

The way I read this is getmained storage may not be initialized in all cases.

What if I do a CICS GETMAIN and specify INITIMG(BLANK)

Even if I figure out what to do with every GETMAIN what do I do about vendor code I don’t have the source so I can’t tell if the code assumes the storage is initialized or not

John J. Leonard
Application Developer III SOA Team
Westfield Group
One Park Circle P.O. Box 5001
Westfield Center Ohio 44251-5001
Office (330) 887-8249
Toll Free 1-(800) 243-0210 ext 4308249
Email johnl...@westfieldgrp.com
Extension 430-8249

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of ASSEMBLER-LIST automatic digest system
Sent: Thursday, November 19, 2015 12:00 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: ASSEMBLER-LIST Digest - 17 Nov 2015 to 18 Nov 2015 (#2015-128)

There are 6 messages totaling 200 lines in this issue.

Topics of the day:

1. TOD conversion to display (5)
2. Christian OBERLEITNER ist außer Haus.

----------------------------------------------------------------------

Date: Wed, 18 Nov 2015 10:19:18 -0500
From: Victor Gil <victo...@BROADRIDGE.COM>
Subject: Re: TOD conversion to display

We have rather high transaction volume, especially around the market open/close times, so, yes, we did have duplicates before and sometimes had to retry multiple times [based on the bumped sequence number] to provide for uniqueness.

I can't go into specifics, but the whole idea was to spread the input queues, containing a dynamic mix of transactions, into logical sub-queues related to their "types", all of which are to be still processed in parallel. However, within a given "type" each distinct transaction "originator" has to be processed sequentially, so that a request to "cancel" an order is delayed until the original order has actually been seen and processed.

-Victor-

On 2015-11-17, at 10:04, Tony Harminc wrote:
>
> It seems to me that duplicates are extremely unlikely, given the
> relative speed of CPUs and I/O devices these days. Sure, I realize
> that each record doesn't imply an I/O operation; there will be
> blocking going on. But how long does it take to write out a VSAM
> block? Less than a microsecond? The clock values from STCKF on any
> modern machine surely have much greater precision than that.
>
Birthday Paradox, given that the OP has multiple threads.

> And in any case, doesn't it make sense to let VSAM catch the duplicate
> key and obtain a new one only then?
>
But perhaps the OP envisions a performance advantage in not specifying the key as unique (does VSAM support that? SQL does, sorta) and guaranteeing uniqueness externally.

Are the keys in the DB displayable or in STCK format? Is the performance bottleneck in inserting records or extracting them?

-- gil

------------------------------

Date: Wed, 18 Nov 2015 16:23:48 +0100
From: Christian OBERLEITNER <christian....@GRZ.AT>
Subject: Christian OBERLEITNER ist außer Haus.

Ich werde ab 17.11.2015 nicht im Büro sein. Ich kehre zurück am 23.11.2015.
Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

Die Rückmeldung bezieht sich auf ein Mail mit folgendem Thema:
Re: TOD conversion to display

____________________________________________________________________________________________
Gesendet (c) GRZ/RACON Linz 2015 Agent 'Abwesenheit'


Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium nicht ausgetauscht werden.

Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications.

------------------------------

Date: Wed, 18 Nov 2015 10:00:21 -0700
From: Paul Gilmartin <PaulGB...@AIM.COM>
Subject: Re: TOD conversion to display

On 2015-11-18, at 08:19, Victor Gil wrote:

> We have rather high transaction volume, especially around the market open/close times, so, yes, we did have duplicates before and sometimes had to retry multiple times [based on the bumped sequence number] to provide for uniqueness.
>
> I can't go into specifics, but the whole idea was to spread the input queues, containing a dynamic mix of transactions, into logical sub-queues related to their "types", all of which are to be still processed in parallel. However, within a given "type" each distinct transaction "originator" has to be processed sequentially, so that a request to "cancel" an order is delayed until the original order has actually been seen and processed.
>
Ah, yes. The high-frequency trading wars. 60 Minutes had a story a few years ago mentioning how one institution overcame a disadvantage by introducing a wire(!) delay line to delay its competitor's transactions by a few milliseconds.

-- gil

------------------------------

Date: Wed, 18 Nov 2015 12:08:22 -0500
From: Tom Marchant <m42tom-...@YAHOO.COM>
Subject: Re: TOD conversion to display

On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <PaulGB...@AIM.COM> wrote:

>one institution overcame a disadvantage by introducing a wire(!) delay
>line to delay its competitor's transactions by a few milliseconds.

That would be a really long piece of wire.

--
Tom Marchant

------------------------------

Date: Wed, 18 Nov 2015 17:18:26 +0000
From: "Hardee, Chuck" <chuck....@THERMOFISHER.COM>
Subject: Re: TOD conversion to display

Or a huge resistor in series with it



Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 Chuck....@ThermoFisher.com | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies.


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant
Sent: Wednesday, November 18, 2015 12:08 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: TOD conversion to display

On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <PaulGB...@AIM.COM> wrote:

>one institution overcame a disadvantage by introducing a wire(!) delay
>line to delay its competitor's transactions by a few milliseconds.

That would be a really long piece of wire.

--
Tom Marchant

------------------------------

Date: Wed, 18 Nov 2015 10:44:27 -0700
From: Paul Gilmartin <PaulGB...@AIM.COM>
Subject: Re: TOD conversion to display

On 2015-11-18, at 10:08, Tom Marchant wrote:

> On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <PaulGB...@AIM.COM> wrote:
>
>> one institution overcame a disadvantage by introducing a wire(!)
>> delay line to delay its competitor's transactions by a few
>> milliseconds.
>
> That would be a really long piece of wire.
>
I stand corrected; I checked; it was 350 µsec. That one's prfoit may depend on that edge is ample reason for the OP to desire to shave a few instructions off time display conversion.

http://www.bloomberg.com/news/articles/2014-03-30/high-frequency-traders-ripping-off-investors-michael-lewis-says

-- gil

------------------------------

End of ASSEMBLER-LIST Digest - 17 Nov 2015 to 18 Nov 2015 (#2015-128)
*********************************************************************

[Walt Farrell]

On Thu, 19 Nov 2015 14:52:33 +0000, Leonard.John.J <JohnL...@WESTFIELDGRP.COM> wrote:

>Virtual Storage Manager in z/OS 1.10 HBB7750 which results in different behavior when storage is Getmained
>We are trying to understand the ramifications of this change to the GETMAIN and I was wondering if anyone else has dealt with this. I >have this document that says

... snipped...

As I recall that documentation was not describing a change to GETMAIN behavior, but merely documenting more clearly how it has worked for a very long time. In any case, it is not up to you to determine whether vendor-supplied GETMAINs are working nor to fix them; that's entirely up to the vendor.

By the way, I believe that z/OS V1.10 is long out of support. If you're still using it I would say that is of far more importance than any considerations of how GETMAIN might work. Also, I think your question is more appropriate for the IBM-MAIN list (as it deals with z/OS) than the ASSEMBLER list (which deals specifically with the assembler and the hardware architecture).

--
Walt

[Steve Smith]

Walt, I think there was a change to GETMAIN behavior, but it's rather
subtle (low-end vs. high-end page-filling), and this part was merely to
reassure everyone that from a program's point-of-view, nothing was really
any different.

The key words are "remain unchanged". The behavior (which is the same as
it's always been) is re-iterated for your convenience.

Proper programming insures all variables are initialized, so this behavior
should be irrelevant. However, programs often clear newly acquired storage
for convenience or aesthetics. The main point of the clearing rule is that
you should *not* clear storage when the system has done it already because
that wastes resources.

The APAR has nothing to do with CICS GETMAIN. Read CICS doc for how that
works.


sas

On Thu, Nov 19, 2015 at 10:07 AM, Walt Farrell <walt.f...@gmail.com>
wrote:

--
sas

[Gary Weinhold]

I would think it's up to CICS to initialize CICS acquired memory on your
behalf.

And if your applications (vendor or otherwise) run under LE, then LE
controls whether it will initialize the storage based on options you set.

But you have a valid concern about vendors' assembler code. We should
be asked whether we know about this. Note that it says that the
behaviour is not changed, which means this exposure has existed before
z/OS 1.10. The availability of the CHECKZERO option means that users of
GETMAIN/STORAGE may not always have to zero the storage they obtained to
ensure that it is initialized to zeroes.

Regards, Gary

PS: try to avoid copying the entire digest when replying to the list.








Gary Weinhold
Senior Application Architect

DATAKINETICS | Data Performance & Optimization

Phone +1.613.523.5500 x216
Email: wein...@dkl.com

Visit us online at www.DKL.com

E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.


__________

[John McKown]

​EXEC CICS GETMAIN functionality is not affected by the z/OS GETMAIN​
function. They are totally separate and distinct. EXEC CICS GETMAIN simply
looks in the appropriate CICS DSA (Dynamic Storage Area) for "free space".
There are a number of different DSAs in CICS. They are "suballocated" from
a single z/OS area which is initialized at CICS start up. CICS itself,
internally, manages the suballocation. Therefore, the CICS DSA storage is
always allocated from a z/OS perspective, regardless of whether it is
"allocated" or "free" from a CICS perspective. When you use the INITIMG()
parameter on an EXEC CICS GETMAIN, then the CICS memory manager (not z/OS
memory manager) will perform the requested initialization.

From:
http://www-01.ibm.com/support/knowledgecenter/SSGMCP_5.1.0/com.ibm.cics.ts.applicationprogramming.doc/commands/dfhp4_getmain.html
<quote>
INITIMG(data-value)Specifies an optional 1-byte initialization value. If
you specify INITIMG, CICS sets every byte of the acquired storage to the
bit string you provide. Otherwise, CICS does not initialize the storage. In
COBOL programs only, you must use a data area rather than a data value to
define the initialization bit string.
</quote>

So, if your application does not use the INITIMG() parameter, the data in
storage is "undetermined". That is, whatever happened to be in the area
from whatever used it last. The same with vendor code. If they don't use
INITIMG(), then "who knows?".

However, also keep in mind the CEECOPT settings for LE.
http://www-01.ibm.com/support/knowledgecenter/SSGMCP_5.1.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3_langenv_runopts.html?lang=en
which affects things like COBOL LOCAL and WORKING storages.

>
> John J. Leonard
> Application Developer III SOA Team
> Westfield Group
> One Park Circle P.O. Box 5001
> Westfield Center Ohio 44251-5001
> Office (330) 887-8249
> Toll Free 1-(800) 243-0210 ext 4308249
> Email johnl...@westfieldgrp.com
> Extension 430-8249
>

--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

[Lizette Koehler]

So, if you were not aware, there is a CICS list that might help with your question on CICS Getmains.

To join, if you have not done so, use this URL
CICS http://www.listserv.uga.edu/archives/cics-l.html

Lizette

[Tom Marchant]

On Thu, 19 Nov 2015 14:52:33 +0000, Leonard.John.J wrote:

>We are trying to understand the ramifications of this change to
>the GETMAIN and I was wondering if anyone else has dealt with this.
>I have this document that says
>
>“References to GETMAIN also apply to STORAGE OBTAIN.
>
>The description and behavior of the GETMAIN macro as documented
>in the z/OS MVS Assembler Services Reference remain unchanged
>by this APAR. With respect to whether or not the system zeroes
>the newly getmained storage, the guidelines remain as follows:
>
>When you obtain storage, the system clears the requested storage
>to zeros if you obtain either:
> o 8192 bytes or more from a pageable, private storage subpool.
> o 4096 bytes or more from a pageable, private storage subpool,
> with BNDRY=PAGE specified
>
>In all other cases you must NOT assume that the storage is
>cleared to zeros, unless indicated by the return code when
>CHECKZERO=YES is specified.”
>
>The way I read this is getmained storage may not be initialized in all cases.

That is correct, but it is very old behavior. Long ago, the storage that you
obtain was never initialized by GETMAIN. By MVS/ESA V4, the documentation
was changed to include the above text. The change was introduced sometime
between 1987 and 1993.

APAR OA27291 describes the change in GETMAIN that was introduced in
z/OS 2.1. It results in better performance of GETMAIN. A side effect is that is
that there is somewhat more chance that a request will be satisfied from a
location that had been previously obtained and then freed. If that request is
less than 8K (or 4K with BNDRY=PAGE), it will not be zeroed and there might
be residual data in that storage.

There is a DIAG option, USEZOSV1R9RULES, to tell VSM whether or not to use
the new algorithms. The default is still YES, "to provide a seamless migration",
even in z/OS 2.2.

>Even if I figure out what to do with every GETMAIN what do I do
>about vendor code I don’t have the source so I can’t tell if the
>code assumes the storage is initialized or not

Contact the vendors.

--
Tom Marchant

[Tony Harminc]

On 19 November 2015 at 10:14, Gary Weinhold <wein...@dkl.com> wrote:
> But you have a valid concern about vendors' assembler code. We should be
> asked whether we know about this.

When these changes were first brought up by IBM quite a few years ago
now, every even marginally competent ISV reviewed its use of GETMAINed
storage, and made corrections if necessary. In my view this was a good
exercise whether or not changes were needed.

> Note that it says that the behaviour is
> not changed, which means this exposure has existed before z/OS 1.10. The
> availability of the CHECKZERO option means that users of GETMAIN/STORAGE may
> not always have to zero the storage they obtained to ensure that it is
> initialized to zeroes.

While there was no change to the documented/guaranteed behaviour of
GETMAIN, what changed as a result of the under-the-covers algorithm
changes was the customary behaviour under certain circumstances. Some
programs doubtless relied -- implicitly or explicitly -- on certain
storage being zeroed even though the GETMAIN rules never suggested
that there was any such guaranty.

What also changed because of the under-the-covers algorithm changes,
and was discussed at some length on this list and elsewhere, is the
way fragmentation may occur. Overall it seems that fragmentation is
less likely with the new algorithms, but there are doubtless cases
where it increases, and therefore certain jobs will require more
storage than they did under the old regime.

One slighly related point: It has been the case from day 1 of MVS
(OS/VS2 R2) that even though GETMAIN can give out non-zeroed storage,
that storage will never contain data left over from another address
space, or from a fetch protected subpool in the current or common
space. This would be a violation of the MVS statement of system
integrity, and if found would be fixed very quickly.

Tony H.

[Elardus Engelbrecht]

Tony Harminc wrote:

>One slighly related point: It has been the case from day 1 of MVS (OS/VS2 R2) that even though GETMAIN can give out non-zeroed storage, that storage will never contain data left over from another address space, or from a fetch protected subpool in the current or common space. This would be a violation of the MVS statement of system integrity, and if found would be fixed very quickly.

As an Assembler programmer I know it is very true, but where is that documented these days? Just give me a link, book name or search argument so I can research my Principle of Operations, Bookmanager shelves, IBM Knowledge Centre, etc.

Seemed I really need 'search 101'! ;-[

Side note: After GETMAIN, I always populate all needed parts with my own known values using MVC instruction for example. I simply don't a$$ume there is something there even if that means there is some overhead.

Groete / Greetings
Elardus Engelbrecht

[Paul Gilmartin]

On 2015-11-19, at 11:03, Elardus Engelbrecht wrote:

> Tony Harminc wrote:
>
>> One slighly related point: It has been the case from day 1 of MVS (OS/VS2 R2) that even though GETMAIN can give out non-zeroed storage, that storage will never contain data left over from another address space, or from a fetch protected subpool in the current or common space. This would be a violation of the MVS statement of system integrity, and if found would be fixed very quickly.
>
> As an Assembler programmer I know it is very true, but where is that documented these days? Just give me a link, book name or search argument so I can research my Principle of Operations, Bookmanager shelves, IBM Knowledge Centre, etc.
>

I suspect it's implicit. Does the SoI not guarantee that no user's data
will ever be disclosed to another user? Doesn't that cover this?


On 2015-11-19, at 09:35, Tom Marchant wrote:
> ...

> APAR OA27291 describes the change in GETMAIN that was introduced in
> z/OS 2.1. It results in better performance of GETMAIN. A side effect is that is
> that there is somewhat more chance that a request will be satisfied from a
> location that had been previously obtained and then freed.
>

Is it "more chance", or simply that the hazard is shifted to a different
sequence of GETMAINs?

Why does the option for "dirty" GETMAIN (I forget the correct name) remain
undocumented, despite its value for testing?

Why is that option system-wide rather than being available with JOB scope
(option on the JOB statement) or job step scope (option on the EXEC statment)?
I'd use it for testing if it were available to me.

-- gil

[Blaicher, Christopher Y.]

Here are all the documented and undocumented 'Dirty' parameters I know of. These go in the DIAGxx member of SYS1.PARMLIB. These are NOT recommended for production or even development environments. Try them on a TEST LPAR to shake out any problem areas.

Traps Name(IeaCmSetV, /* Ensure disabled CMSET caller */
IeaInitArSrb, /* Initialize registers for SRBs */
IeaInitRegsTask, /* Initialize registers for TCBs */
IeaSpinLockV, /* Verify spin lock environment */
IeaScheduleV, /* Verify schedule environment */
IeaScheduleTrace, /* Trace SCHEDULE & IEAMSCHD */
IeaRpsgnlTrace, /* Trace RPSGNL calls */
/* Sloooow IgvCpoolGetV, /* Validate CPOOL GET environment */
IgvInitCpool, /* Initialize CPOOL GET elements */
IgvInitGetmain, /* Initialize GETMAINed storage */
IgvInitFreemain, /* Initialize FREEMAINed storage */
IarSt64InitGet, /* Initialize gotten 64-bit stg. */
IarSt64InitFree, /* Initialize freed 64-bit stg. */
IarCp64InitGet, /* Initialize gotten 64-bit cells */
IarCp64InitFree /* Initialize freed 64-bit cells */
)

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803    
E: cbla...@syncsort.com

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, November 19, 2015 1:15 PM
To: MVS List Server 2 <ASSEMBL...@LISTSERV.UGA.EDU>
Subject: Re: Change in GETMAIN behavior

On 2015-11-19, at 11:03, Elardus Engelbrecht wrote:


Why does the option for "dirty" GETMAIN (I forget the correct name) remain undocumented, despite its value for testing?

-- gil

[Blaicher, Christopher Y.]

Wow, that didn't format correctly the first time. Hopefully this time is better.

[Elardus Engelbrecht]

Blaicher, Christopher Y. wrote:

>Wow, that didn't format correctly the first time.

Both your mails were formatted properly (Wow!) on the ASSEMBLER-L website.

>Here are all the documented and undocumented 'Dirty' parameters I know of.
>These go in the DIAGxx member of SYS1.PARMLIB.
>These are NOT recommended for production or even development environments.

They're so 'dirty', you risk getting page faults...

I'm only familiar with USEZOSV1R9RULES.

[Jim Mulder]

> > APAR OA27291 describes the change in GETMAIN that was introduced in
> > z/OS 2.1. It results in better performance of GETMAIN. A side
> effect is that is
> > that there is somewhat more chance that a request will be satisfied
from a
> > location that had been previously obtained and then freed.
> >
> Is it "more chance", or simply that the hazard is shifted to a different
> sequence of GETMAINs?

As the designer and implementer of the z/OS 1.10 change, I would say
that it creates some additional circumstances where a request (or part
of a request) can be satisfied from a location which contains residual
data from a previous use. "More chance" is may be a reasonable
way to say that colloquially. But yes, the actual behavior depends
entirely
on the sequence of requests. There is no randomness involved.

> Why does the option for "dirty" GETMAIN (I forget the correct name)
remain
> undocumented, despite its value for testing?

IGVINITGETMAIN is the TRAP name. It was designed and implemented as a
one person, unfunded, spare time project, by me, to meet some my needs for
testing
purposes. There were none of the design and externals reviews that are
done
for the normal development process of documented functions. Low
implementation cost, affecting only system components in which I was
sufficiently experienced to dabble (which does not in JCL
converter/interpreter),
was essential. Not being an officially documented function shields it
somewhat
from complaints about the usability of the externals, complaints about
what it does
and doesn't do, and requests for enhancements.

Also, use of this kind of test tool can cause unexpected damaging system
effects.
In one case years ago, it exposed a bug which caused corruption of an
HSM control data set. Even on a test system, that was pretty disruptive,
and it quite a bit of effort for the ISV who encountered this misfortune,
working
with HSM level 2 support, to salvage his HSM environment.

> Why is that option system-wide rather than being available with JOB
scope
> (option on the JOB statement) or job step scope (option on the EXEC
statment)?
> I'd use it for testing if it were available to me.

See above.

Or, to quote from "Man of La Mancha":
Don Quixote:
"We waited, sire, for a dwarf to mount the battlements...
and announce us, but none appeared."
Innkeeper:
"The, uh, the dwarfs, they're all busy."

Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY

[Elardus Engelbrecht]

Jim Mulder wrote:

> As the designer and implementer of the z/OS 1.10 change,

I, a novice Assembler programmer, will never argue with you. ;-)

> IGVINITGETMAIN is the TRAP name. It was designed and implemented as a one person, unfunded, spare time project, by me, to meet some my needs for testing purposes.

Wow! That is a worthwhile achievement! You deserved a medal or two.

>In one case years ago, it exposed a bug which caused corruption of an HSM control data set. Even on a test system, that was pretty disruptive,

Ouch... Only the HSM CDS? What about catalogs and the HSM datasets (ML0/1/2) themselves? Were they also corrupted?

> Or, to quote from "Man of La Mancha":
>Don Quixote:
> "We waited, sire, for a dwarf to mount the battlements...
> and announce us, but none appeared."
>Innkeeper:
> "The, uh, the dwarfs, they're all busy."

Ok. I will not disturb you... ;-D Thanks for this quote!

[Paul Gilmartin]

On 2015-11-23, at 03:40, Elardus Engelbrecht wrote:

> Jim Mulder wrote:
>
>> IGVINITGETMAIN is the TRAP name. It was designed and implemented as a one person, unfunded, spare time project, by me, to meet some my needs for testing purposes.
>
> Wow! That is a worthwhile achievement! You deserved a medal or two.
>>
>> In one case years ago, it exposed a bug which caused corruption of an HSM control data set. Even on a test system, that was pretty disruptive,
>
> Ouch... Only the HSM CDS? What about catalogs and the HSM datasets (ML0/1/2) themselves? Were they also corrupted?
>

I only hope the bug was repaired.

As a more applications-oriented programmer than systems-oriented, I
find this strengthens my wish for an IGVINITGETMAIN-like facility
with ASID scope which could meet some of my needs for testing purposes
without dirupting or endangering other operations. But, yes, this
must be balanced against the cost of implementation.

Thanks,
gil

[Tom Marchant]

On Mon, 23 Nov 2015 07:48:20 -0700, Paul Gilmartin wrote:

>As a more applications-oriented programmer than systems-oriented, I
>find this strengthens my wish for an IGVINITGETMAIN-like facility

>with ASID scope ...

Did you submit a requirement?

--
Tom Marchant

[Elardus Engelbrecht]

Tom Marchant wrote:

>Paul Gilmartin wrote:

>>As a more applications-oriented programmer than systems-oriented, I find this strengthens my wish for an IGVINITGETMAIN-like facility with ASID scope ...

>Did you submit a requirement?

For a 'one person, unfunded, spare time project'? Paul, you may need to motivate (perhaps for ASID scope) it properly to catch big blue's attention.

Good luck! (Some of my formal requests to IBM were shot down (WAD, etc.) ... I don't blame them... oh well...)

Groete / Greetings
Elardus Engelbrecht

[1] - I got an ex-colleague to submit a requirement to have SDSF command line to be expanded to more than one line (for those long VTAM console commands). It was shot down - WAD or that request never reached IBM in the first place.

Anyways, that feature was introduced at a later SDSF version plus a command history as a bonus.

[Robert Ngan]

I asked that SDSF be changed so the scroll field dynamically move to the
right side of the screen based on the current screen width, which would
have given more room for stacked commands but that was also shot down.
I have a 142 column screen, with the scroll field in the middle of it!

Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
2015/11/24 07:02:07:

> From: Elardus Engelbrecht <elardus.e...@SITA.CO.ZA>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 2015/11/24 07:24
> Subject: Re: Change in GETMAIN behavior

[David de Jongh]

Robert,
In SDSF edit (line command SE) the scroll field is right justified, at least
with a 137 character width. I have a number of PComm macros that paste
stacked commands into the command area. It's also useful for downloads,
where the dataset name makes the command too long.
David de Jongh

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]

[Robert Ngan]

I assume SE is correct because SDSF is just invoking the ISPF EDIF service,
and ISPF EDIT handles it correctly. None of the "pure" SDSF panels handle
the scroll field placement properly.
And from within SE, only EDIT commands are accepted. It won't accept SDSF
specific commands. Just another of life's minor annoyances!

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

2015/11/24 21:31:16:

[Pieter Wiid]

Is there a site where we can vote for this? It's been a major pain in my
life, especially after using EJES and SYSVIEW.

Pieter

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Robert Ngan

> command history as a bonus.=

[Peter Relson]

Regarding requirements:

As with any requirement, it needs to be evaluated both for technical
validity (the ones mentioned in this thread seem valid) and also for their
likelihood of bubbling to the top of a prioritized list given limited
resources. Surely this is the case for every company. A request that is
rejected / declined may be for either reason.

I cannot speak for SDSF in this regard. But you always have to ask whether
the product would be better off having implemented this as opposed to
spending those resources implementing something else. For an individual,
the answer might be "yes" but not necessarily for the broader community.
And I make no judgment on the specific thing mentioned for SDSF.

If you want my guess about "dirty getmain" being implemented on a per-job
basis the answer will be "no". It really is not valid to be used in a
production environment (because even an application does not in general
control 100% of what runs, so even an implementation that does this on a
job or task basis only for problem state user key requests might be
dangerous and might break things not under your control ). By the way, is
there anything that is documented to be used only in a test environment
along with "don't call us if something breaks as a result unless you know
that it is due to something that that something is not allowed to expect?
An example of a case that dirty getmain would break that is not truly a
program error is for a program that runs only as EXEC PGM= and does its
very first getmain for less than 4K and does not clear the area before
using it. It will be zeroes without dirty getmain. It will not be zeroes
with dirty getmain (which has no information available about "first or
not"). Is it stupid of the program to have such a dependency? Sure? Wrong?
Not necessarily.

In general, FWIW, IBM has changed a lot of code over the years to
accommodate the undocumented option. And we'll likely continue to do. If
for no other reason than that the option is useless if something normal
"breaks" because of this, thus inhibiting it from being used at all due to
its whole-system scope.

If you have a test system, why not try it? It's hardly a secret.

Peter Relson
rel...@us.ibm.com

[Pate, Gene]

Make the following change to the ISFPCU41 panel and your 'SCROLL' field we be on the right hand edge of your panel.

$COMMAND INPUT ===>_ISFCMD / /$SCROLL ===>_ISFS+
5CDDDCDC4CDDEE477766CECCDC4444444444444444444444444444444446465ECDDDD477766CECE4
B36441540957430EEEED926344000000000000000000000000000000000101B2396330EEEED9262E


I use a 133 column screen and it works just fine on both the 80 column screens used by our other sysprogs and also my 133.

Gene Pate
CSX Technology
Enterprise Architecture
550 Water Street - 741GG
Jacksonville, FL 32202
(904) 633-5158 (o)
(904) 662-5103 (c)
(904) 245-4058 (f)
gene...@csx.com<mailto:gene...@csx.com>
www.csx.com<http://www.csx.com/>

>-----Original Message-----
>From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
>On Behalf Of Robert Ngan
>Sent: 25 November 2015 01:19
>To: ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>
>Subject: Re: Change in GETMAIN behavior
>
>I asked that SDSF be changed so the scroll field dynamically move to the right side of the screen based on the current screen width, which would have given more room for stacked >commands but that was also shot down.
>I have a 142 column screen, with the scroll field in the middle of it!
>
>Robert Ngan
>CSC Financial Services Group

>IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>> wrote on
>2015/11/24 07:02:07:




This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email.