ca.portal.admin

Re: [IDMSVENDOR-L] subarea

Discussion created by ca.portal.admin on Sep 27, 2007
NO NO NO - subarea affects the IDMSCALC computation, and if you change
or remove subareas, CALC access will fail (area sweeps or set access
would continue to work though) YOU WOULD NEED TO UNLOAD/RELOAD


Chris Hoelscher
Senior IDMS & DB2 Database Administrator Humana Inc
502-476-2538
choelscher@humana.com


We have a record type confined to a subarea. This is not really
necessary (online access is CALC only), and we now want to increase the
number of pages in the subarea to include the entire area. Am I correct
in thinking that this is a definition change only, and that there is no
need for an unload/reload?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
ROLLBACK TO THE FUTURE at the IUA Fall Workshop
"Fellow IDMS Professional,

ROLLBACK TO THE FUTURE with the IUA at our Fall Workshop. This year our keynote speaker will be John Cullinane, founder of Cullinane Corporation (Cullinet Software). Join us as John brings us his perspective on the past and his vision for the future of IDMS.

We will have 3 tracks this year: Application Programming, Database Administration and IDMS Modernization.

In the Applications track we're planning sessions on Intro to IDD, Database Navigation, Application debugging and many more.

In the DBA track we're planning sessions on IDMS DB/DC Control Structures, Scratch Management, Express Reorg, 2-Phase Commit and many others.

The Modernization track will have sessions such as Techniques to Modernize IDMS, Real World Relational Experiences, Planning Legacy Modernization, Table Procedures and many more.

To see a list of all the sessions we're planning to have, go to www.iuassn.org <http://www.iuassn.org/>
select the EVENTS button at the top of the page
select VIEW DETAILS
select EVENT SCHEDULE at the bottom of the page

The workshop will be held at the CA Education Center in Herndon, VA. from October 22nd through October 24th 2007. The cost of this event will be $249 (usd). To register, go to the IUA website ( www.iuassn.org <http://www.iuassn.org/> ) and select the Events button at the top of the page.

Hotel information can be found on the IUA website
go to www.iuassn.org <http://www.iuassn.org/>
select the EVENTS button at the top of the page
select VIEW DETAILS
select EVENT BROCHURE at the bottom of the page

To get the CA hotel rate, let the hotel registration staff know you're attending a CA education event. Please note; you may need to identify the rate as a Computer Associates rate.

If you have any questions regarding the workshop, please contact me at wiklund@tiburontech.com or give me a call.

Bob Wiklund
2007 Workshop Chair
Tiburon Technologies
623 594-6022

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: COBOL calls
"At 05:53 PM 9/30/2007, Don Casey wrote:

External run units for instance HAVE to use SVCs on EVERY call to IDMS (e.g.
online CICS programs issuing IDMS calls), and it requires one in both
directions, so I'm not convinced that the hit taken in a DC ""call"" using
COBOL calls vs IDMS txfrs is going to be all that noticeable, but that's
just an opinion.
which is (in my opinion) about the only value to LRF - it allowed
multiple IDMS DMLs to be called in one SVC from a CICS (or other
external) program




This is Chris Hoelscher and I approved this email
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
0307 from AREPORT01
"Hi Everyone,
When running AREPORT01 I get a few of the following messages:

F ARPT001 -- AN IDMS STATUS ERROR OF 0307 OCCURRED WHILE EXECUTING LINE
NUMBER 555.

Can anyone tell me what set line number 555 is reading please?

Many thanks,
Geoff
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: COBOL calls
"I agree with Lutz with a couple of caveats (some of what follows is just
further elaboration on his points):

1) SVC screening is selective, IDMS gets control only on those SVCs being
screened (ABENDs, LOADs, GETMAINs, etc), and only when screening is enabled.
Screening is (or was, not sure it still works this way) enabled only when a
COBOL program is active. I forget how it gets turned on, whether THAT
requires an SVC, or only a bit gets flipped. Assuming it still works this
way, this overhead (turning it on and off) still exists whether or not a
COBOL pgm ever issues an SVC. Think of it as background noise.

2) The FLIH is by nature, fairly lean. It does as little as possible to
hand the interrupt off to whatever code is going to do the actual work. It
has to be since MVS handles a ton of interrupts.

3) As noted, there are a lot of interrupts (I/Os, etc) going on that can
also cause MVS to pull the processor away from IDMS. Assuming IDMS is
running at the top priority in most cases IDMS should get redispatched
immediately. In most cases. On a heavily loaded machine, with other high
priority workloads (JES, CICS, DB2) there IS a possibility IDMS may get
placed in a wait due to the interrupt.

All that said, I don't know that anybody has ever measured the exact impact.

External run units for instance HAVE to use SVCs on EVERY call to IDMS (e.g.
online CICS programs issuing IDMS calls), and it requires one in both
directions, so I'm not convinced that the hit taken in a DC ""call"" using
COBOL calls vs IDMS txfrs is going to be all that noticeable, but that's
just an opinion.

Note however, a long time ago when APL converted lots of DC and ADSO
programs to CICS, there was one application where the additional
wait/dispatch overhead incurred by the SVC sequence between CICS and IDMS
WAS noticeable. In this case, however, the online application was literally
doing THOUSANDS of IDMS calls, and the extra wait time due to dispatching on
both the CICS and the IDMS side (ERUS tasks) was adding 30 seconds to the
elapsed time. This was due primarily to the contention for other work on
the CICS and IDMS side, not due to contention with other MVS work or CPU
availability. We ""solved"" the problem by moving the application into a
dedicated CV, so when IDMS redispatched it it was at the top of the wait
queue. We also increased the priority on the CICS side to achieve the same
degree of ""love"" within CICS.

Again, barring a case where there where hundreds/thousands of subroutine
calls I'm not sure it's worth worrying about.

Perhaps a tool like Strobe could provide actual metrics, if somebody has it
and wants to run a Science Experiment.

FWIW.

Outcomes