ca.portal.admin

Vary offline immediate

Discussion created by ca.portal.admin on Aug 23, 2007
One of our production users has had problems with the ""vary area offline
immediate"" command. On two occasions, it did not work immediately. The
""immediate"" parameter causes DCMT to wait until the area actually goes
offline, rather than returning a ""pending"" message as it does otherwise.
These commands were submitted via UCFBTCH, and the batch job eventually
timed out while waiting for the DCMT command to complete.

Unfortunately, no one got a look at the CV at the time to see what the
holdup was. Since this problem results in late-night calls, the users
are natually reluctant to try it again for debugging purposes. Has
anyone else had experiences where the ""vary area offline immediate""
command went into a wait state?

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
Re: Programming Question/ Bug?
"Thank you to all who replied to my question. I had some email
problems for a while and was not able to see any IDMS-L mail for 2
days after I posted the question so please excuse the my lack of
responses to all the questions that were asked.

I do not know what in the map the programmer changed. However, we
conducted an experiment where we just changed the response process
and nothing else. We still saw the same problem. I think that Peter's
explanation is the best for our situation and it looks like we should
be changing the code where it exists.

I personally also do not like checking for zero/zeroes on an
alphanumeric field. I was taught NEVER to do that. But it is allowed
per the Ads Reference Guide.

Regards,
Petra


This looks the problem we had last millennium with a now-defunct
application when we went from 10.2 to 12.0 and then 14.0. We had to apply
optional fixes LS10368 to 12.0 and LS17332 and TF24083 to 14.0.

The 'problem' is that ADS treats a PIC X field as unsigned zoned decimal
when comparing the field to ZERO, which is a numeric figurative constant.
This is documented in the ADS reference. So if the contents of the field
can be converted to a valid numeric value then ADS does so. I think this
can happen if the field begins with a valid zoned decimal character or
spaces followed by zoned decimal characters. Perhaps it shouldn't be
possible for ADS to convert a value such as '0A' to a valid numeric but
rather give an error such as 'DC175015 NO NUMBER ON EBCDIC/NUMERIC
CONVERSION'.

Also, just an opinion, ZEROS and ZEROES shouldn't be valid syntax for the
figurative constant. They imply functionality that doesn't exist.


Peter Hannigan
IBM Global Technology Services Australia and New Zealand
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Pro's & Con's of Multiple Target and DLIB Zones in SMP/E
"Hello All:

for those of you that have installed IDMS over the years I would like to
hear your opinions regarding multiple TGT & DLIB Zones in the IDMS CSI.

Background Information, I have recently picked up a new client that has 17
Central Versions, currently they are running IDMS 16.0 SP1 and I am going to
upgrade them to SP5 to take advantage of some of the additional features
provided with SP2 and above such as High Speed Storage Protection.

What they have in place is one CSI with one GLOBAL Zone and 17 unique TGT &
DLIB zones, one TGT & DLIB for each Central Version, but, all 17 of the
Central versions are exactly the same, there is nothing specila about one or the
other, they all use the same SVC, the same RHDOPTF (optional APAR) the same
RHDCSRTT (except for the environment name) the same RHDCUXIT, as far as I can
tell there is no difference in any of the systems.

So, I am asking your opinion of the 17 unique TGT & DLIB zones in SMP/E.

Bill Allen
(704) 641-0296



************************************** Get a sneak peek of the all-new AOL at
http://discover.aol.com/memed/aolcom30tour
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Pro's & Con's of Multiple Target and DLIB Zones in SMP/E
">if they are all the same, then WHY have multiple ANYTHING? the only
reason i can think of is portability - but in that case - i would
have separate global zones as well .....
if you ever wanted to have different opt apars applied, or different
values applied to different targets for the same opt apars, then you
could do it with a shared global zone but would require a lot of
rejecting (and you know how i hate rejection) and re-receiving, but i
would recommend nothing shared - either one big CSI for all to use
(which would require all getting the same maint applied at the same
time) or 17 individual global/target/dist zones - this would allow
maximum flexibility - but most work for the installer - tou can write
reports to compare the smp/e status of the zones and compare - to see
what is out of sync ...




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
Re: Pro's & Con's of Multiple Target and DLIB Zones in SMP/E
"I never understood the advantages of creating multiple zones over
creation of a brand new csi, and a manual record of which specific
apars/usermods the site has installed and needs. then when an upgrade
comes along, creating a new csi and making sure the site specific apars
have not been lost and if need be, reapplying them. For one thing, I
dont believe in accepting maintenance. It makes backing out a bad apar
impossible and forces a wait for a new usermod/apar from the vendor
which might make matters worse and takes time, or creating my own
usermod which essentially backs out the vendors bad apar (this is
politically fraught in today's loosy goosy change control world with
outsiders making technical decisions). When I did IDMS SMPE maintenance
from day 1 for 13 years, until my present job confines me to windows
point and click, I never accepted a maintenance and always built a new
CSI for the new release, and never ever applied the latest service pack.
If it doesn't hurt, leave it alone, until a year or two before the
software level goes out of support and then upgrade, building a new csi.
Creating a new zone and exporting the previous into the new is, well,
hmm, I dont remember the details, but I do remember the conclusion that
it's error prone.

Lutz Petzold

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Pro's & Con's of Multiple Target and DLIB Zones in SMP/E
"Hi Bill, how are you?
Does this mean if you wanted to apply 1 high priority apar you'd have to
do it 17 times? Yuck!

Outcomes