can you please tell me on which version of our package you get this
issue? [We had some similar in the early versions=
regards
didier
Thank you
Support of VSAM has some issues beyond the simple emulation of the
Cobol verbs needed to read and write files, simultaneous use of VSAM
and SQL creates on the mainframe a distributed unit of work (DUOW)
from a transactional standpoint.
this DUOW makes transaction-recovery for integrity of database more
tricky in case of failures: you have to properly synchronize the vsam
files as well as the sql db.
So, on purpose, we took a simpler path in our project: we migrated our
vsam files to simple sql tables (basically 2 cols: key + value) in
order to be able to keep 100% of integrity managed only by database
manager with no other coordination with file manager needed.
If you don't go this path, you need to implement Java Transaction Api
to supply recovery coordination between files and db
So, 2 paths are possible:
a) you do the same and then get back to a 100% sql environmenet
b) you develop (or mandate us to do so) a vsam emulator emulating the
Cobol (Cics + batch) verbs for VSAM. This emulator would in fact use
database to store the files. Also needed is a file loader from VSAM to
db to do the initial transfer.
So, our support of VSAM would go into direction (b) as soon as we find
a project able to finance this mandate or contributing back such a dev
done on its own resources.
regards
didier
We are coming back to you in order to see if you had a better success
with the online demo of NACA 1.2.0.2.
As per our support email yesterday, the online demo in NACA 1.2.0.1 is
having some problems (missing files), therefore the usage of NACA
1.2.0.2 is absolutely mandatory.
We are waiting for your feedback on a new test.
Best regards
Naca Support
> > > thank you for your work- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -
My owm Bms test program works fine, good work.
- only fields tagged as numeric are writable in the screen.
- what about concurrent access when programs are in pool(10 users
accessing same screen at the same time)?
thank you guys.
To answer your 2 questions:
a) all the fields properly defined in BMS becomes writable if
specified as such: they can be text, numeric, whatever. So, if some of
the fields that you want to write are not writable, please check you
original BMS defs.
We can analyze them with you if you supply them
b) Concurrency and re-entrance were key aspects of our design at all
levels (maps, programs, etc...). So, for the case of bms maps, each
session gets its own independent copy of map, cobol working storage,
etc....
Don't hesitate if you have further questions
regards
didier