ca.portal.admin

[IDMS-L] Dictionary Migrator message

Discussion created by ca.portal.admin on Jan 2, 2007
I get this message from the migrator:

ENTITY-NAME VERSION ERROR MESSAGE
C474M762 1 VALD231W- OPTIONS DIFFERENT
CATCH ALL

Here is the definition of the message:

VALD231W - OPTIONS DIFFERENT options list:

Reason: The table named has different characteristics in the source and
object dictionaries. The characteristics cannot be changed in a MODIFY
command, therefore the update of the table is complete unless remedial
action is taken first.

Action: Determine which characteristics should be used and correct the
appropriate entity.


This is the ""OBJECT"" table:

ADD
TABLE NAME IS C474M762 VERSION IS 1
PUBLIC ACCESS IS ALLOWED FOR ALL
TYPE IS CODE
SEARCH IS LINEAR
ENCODE DATA IS ALPHANUMERIC
DECODE DATA IS ALPHANUMERIC
TABLE IS UNSORTED
VALUES ARE ( ' ' ' ' '' '' TD06 1 MANU 2 )
*+       INCLUDE MAP M474M762 VERSION IS 1
*+           TYPE IS LINKED EDIT/CODE
GENERATE
.

This is the ""SOURCE"" table:

ADD
TABLE NAME IS C474M762 VERSION IS 1
PUBLIC ACCESS IS ALLOWED FOR ALL
TYPE IS CODE
SEARCH IS LINEAR
ENCODE DATA IS ALPHANUMERIC
DECODE DATA IS ALPHANUMERIC
TABLE IS UNSORTED
VALUES ARE ( ' ' ' ' '' '' TD06 1 MANU 2 PREV 3 )
*+       INCLUDE MAP M474M762 VERSION IS 1
*+           TYPE IS LINKED EDIT/CODE
GENERATE
.

Please note there is a change the table values and granted, it's a
warning message, but I cannot understand what the message means. Any
ideas?

Tim Gortner
State of Iowa
Department of Human Services
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Using the TPSORT pre-compiler in a COBOL Compile
"HI,



WE have just found what looks like a bug in the 16.0 SP1 level toolkit.
We have a DC-COBOL program that uses TPSORT with a SESSION number. The
GETSORT SESSION 2 FIRST INTO record does not expand correctly. It
expanded to TRANSFER 'TPSET' RETURN USING TPSCOMM,

|



|



Record



Which comes out as a syntax error with CC = 49 in the DMLC step.



Anyone else seen this?



Thanks



Chris Wood

Alberta Department of Energy

CANADA




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








Normal

Normal
Daylight Saving Time
"Greetings everyone,

The period for daylight saving time has been changed starting in 2007. It
will start on March 11 this year.

Upon request of our management here, we are currently evaluating the impact
this may have on IDMS and applications using IDMS. Also, if DST timing is
used as a trigger in some applications, there could be some unforeseen
impacts.

Details about daylight saving time are available here:

http://webexhibits.org/daylightsaving/b.html

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








Normal

Normal
16.0 Hyper QO85084(TD67778)
"Hi,



Did anyone on the list find this situation? The test was created last
October.



Thanks



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








Normal

Normal
Re: [IDMSVENDOR-L] Daylight Saving Time
"I am not sure how in IDMS DST comes into play - if you have an assembler
routine that compares GMT to local time, and if the difference is X you
are ST, and X-1 you are on DST (or vice versa) - then it would not matter
WHEN DST is set or unset

if on the other hand, there are hard-coded (or even calulated) dates/times
in your apps, then good luck - i would try to avoid hard-coding anything
that is bureaucratically modifiable .....
(i *think I can live with hardcoding for days of the week and months of
the year, but even than I might prefer to be table driven)

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




The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Daylight Saving Time
"Never chance anything

When Augustus (August) took over for Julius (July), he took a day from
Februalia (February) so he would be equa.....as legend has it. .


Rob Klan/Cincinnati/IBM
Phone: 1-877-205-4871 (T/L: 349-2446)
ITN: 23492446
Email: rklan@us.ibm.com



Chris Hoelscher <choelscher@HUMANA.COM>
Sent by: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>
01/05/2007 03:59 PM
Please respond to
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>


To
IDMS-L@LISTSERV.IUASSN.COM
cc

Subject
Re: [IDMSVENDOR-L] Daylight Saving Time






I am not sure how in IDMS DST comes into play - if you have an assembler
routine that compares GMT to local time, and if the difference is X you
are ST, and X-1 you are on DST (or vice versa) - then it would not matter
WHEN DST is set or unset

if on the other hand, there are hard-coded (or even calulated) dates/times
in your apps, then good luck - i would try to avoid hard-coding anything
that is bureaucratically modifiable .....
(i *think I can live with hardcoding for days of the week and months of
the year, but even than I might prefer to be table driven)

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




The information transmitted is intended only for the person or entity to
which it is addressed and may contain CONFIDENTIAL material. If you
receive this material/information in error, please contact the sender and
delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: 16.0 Hyper QO85084(TD67778)
"Chris,

We did not encounter the situation detailed in QO85084(TD67778).
However, we did apply TD67778 before it was published as it fixes some
new bug arising from QO79308 (SUP TD67776) and its pre-requisite
QO78461.

TD67778 - UNABLE TO FIND BGIN/COMT CKPTS. TEMPORARY DELAY ROLLBACK
IF A TRANSACTION GETS A DC209002, TEMPORARY DELAY IN ROLLBACK,
THE TRANSACTION MAY NEVER COMPLETE THE RECOVERY. THE DC209002
IS USUALLY FOLLOWED BYA DC203006, UNABLE TO FIND BGIN/COMT
CKPTS FOR ALL ACTIVE TRANSACTIONS. THE 2 MESSAGES WILL
CONTINUE TO APPEAR IN THE LOG AND ON THE CONSOLE, BUT THE
RECOVERY WILL NOT COMPLETE.

QO79308 - IDMS FAILS TO ROLL OUT UPDATES TO THE DATABASE.

IF A TRANSACTION SPANS JOURNALS, IDMS WILL NOT ROLL OUT

THE UPDATES WHICH WERE JOURNALED TO THE NEW JOURNAL.

THE FOLLOWING MESSAGES MAY APPEAR;

DC209002 TEMPORARY DELAY IN ROLLBACK

DC203006 UNABLE TO FIND BGIN/COMT CKPTS FOR ALL ACTIVE

TRANSACTIONS.



NOTE: Apar QO78461 is a prerequisite to this apar. Both of
these
apars must be applied to resolve this problem.

QO78461 - AUTOMATIC RECOVERY GETS A DC209002, THEN COMPLETES.

AUTOMATIC RECOVERY GETS A DC203006, UNABLE TO FIND BGIN/COMT

THEN GETS A DC209002, TEMPORARY DELAY IN ROLLBACK.

THEN A DC203005, TRANSACTION HAS BEEN ROLLED OUT.

ALSO, IF AFTER A JOURNAL SWAP, WHERE ALL THE TRANSACTION'S

JOURNAL RECORDS ARE IN THE PRIOR JOURNAL, BUT THE RECOVERY IS

STARTED IN THE NEW JOURNAL, THEN RECOVERY MAY MISS JOURNAL

RECORDS AND FAIL.

Regards,
Paul Mak

Outcomes