All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: Anonymous on 31 Jul 2008 10:48 In article <6b77cbd3-b3eb-40ce-957f-1a977d60944c(a)b38g2000prf.googlegroups.com>, <taoxianfeng(a)gmail.com> wrote: >On 7$B7n(B31$BF|(B, $B8a8e(B8:32, docdw...(a)panix.com () wrote: [snip] >> It seems that your knowledge of the tools required (COBOL and SQL) is >> rather basic and the choice of solution is being dictated elsewhere. >> >> Either you are receiving some very expensive on-the-job training or your >> management deserves the results they are getting. > >You got it. I'm a pure novice who just graduated from university last >year,especially compared to the ones who replied my post with decades >of experiences. I have a few years in this business, myself... and I believe that what you are doing is attempting to translate hexadecimal strings from an EBDCIC to an ASCII encoding scheme. This has been done easily for simple text and most punctuation marks... but anything else can get really, *really* complex. >You can also evaluate me and my company as you wish. Even myself is >thinking about 2 things: >1.the organization is really stupid; >2.try to find another job. In my experience: 1) All organisations say that their conditions are different than those of all other organisations; if all organisations are different then all organisations are the same. 2) There's always another job. > >BUT THAT'S ANOTHER QUESTION. > >I just want to find a technical solution here and try to do as much as >I can. And I'm not posting with some silly questions or doing nothing >but waiting for answer. I have no argument with that whatsoever. If you've followed this group for any time you may have noticed my tendency to ask people who post questions and do not show any of the work they've done towards the solution 'Please do your own job/homework'. I don't believe I've made that request of you and I'm not about to. > >You may guess I'm Chinese from my mail address. Eh? I thought you were Gmailian. >We have an old saying >"Do one's best and leave the rest to God's will". Other sayings from other places include 'Trust in Allah... but tie up your camels' and 'The gods help those who help themselves' and 'Always cut the cards, count the change and don't sit with your back to the door'. If your company believes that you are worthy of all this very expensive on-the-job training they are giving you... then who are you to object? As my Sainted Mother - may she sleep with the angels! - used to say, 'What you carry between your ears is the hardest thing to take from you'. DD
From: Anonymous on 31 Jul 2008 11:08 In article <nYjkk.344927$fz6.306514(a)fe08.news.easynews.com>, William M. Klein <wmklein(a)nospam.netcom.com> wrote: >Coming up with another approach entirely to the problem. If he's allowed to to that, Mr Klein, it would seem to make life Much Easier. [snip] >It seems to me that some (possibly most) of the problems come from the >"download" process of the unloaded file being created as "line sequential". I believe - and my memory might be as porous as usual - that the difficulty is twofold: the data being unloaded on the mainframe contain Japanese characters and the files are being transferred with an EBCDIC-to-ASCII translation. Off the top of my pointy little head I'd suggest the following test for a small sample, no more than 10,000 rows: 1) Mainframe side - use IKJEFT01 to execute SQL and SELECT the sample of rows to an FB output file. 2) Transfer the file to the ASCII platform *as binary*. 3) Set up a MicroFocus program to read the transferred file in EBCDIC and INSERT each record as a row into a table defined exactly as the mainframe one is defined... using a copy of the mainframe DCLGEN would make life much easier. 4) See what happens... get a 'smell' of the results and the time it takes to get them. If it works the way I believe it will then one might begin to consider ways to speed the process up so that decent amounts of data might be handled... 60,000,000 rows and the like. (A major, somewhat hidden, advantage to this test is that it uses methods that are unsophisticated; as such they run less of a chance of creating the 'I don't understand it so I won't let you do it' response.) DD
From: Pete Dashwood on 31 Jul 2008 12:10 "Robert" <no(a)e.mail> wrote in message news:o7e29413ea3ou9hjb0lq59msdkdkef2s9p(a)4ax.com... > On Wed, 30 Jul 2008 17:37:20 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >>Think some more about the Hex string. Each byte is represented by 2 hex >>symbols. If you had to, you could easily write a little COBOL routine that >>would give you the same byte in binary... Here's an example that is by no >>means definitive, but which I'm sure you can modify for your particular >>environment... >> >>*> interface >>01 two-bytes-in pic xx. >>01 one-byte-out pic x. >> >>*> reference data >>01 hc pic x(16) value '01234567890ABCDEF'. >>01 filler redefines hc. >> 12 hexchars pic x occurs 16 >> indexed by hc-x1. >>01 hv usage comp. >> 12 x0 pic s9(4) value zero. >> 12 x1 pic s9(4) value 1. >> 12 x2 pic s9(4) value 2. >> 12 x3 pic s9(4) value 3. >> 12 x4 pic s9(4) value 4. >> 12 x5 pic s9(4) value 5. >> 12 x6 pic s9(4) value 6. >> 12 x7 pic s9(4) value 7. >> 12 x8 pic s9(4) value 8. >> 12 x9 pic s9(4) value 9. >> 12 xA pic s9(4) value 10. >> 12 xB pic s9(4) value 11. >> 12 xC pic s9(4) value 12. >> 12 xD pic s9(4) value 13. >> 12 xE pic s9(4) value 14. >> 12 xF pic s9(4) value 15. >>01 filler redefines hv. >> 12 hexvalues pic s9(4) comp occurs 16 >> indexed by hv-x1. >> > >>get-binary section. >>gb000. >> set hc-x1 to 1 >> search hexchars >> at end >> *> the HEX, isn't... drastic action needed...not shown here >> when current-byte = hexchars (hc-x1) >> set hv-x1 to hc-x1 *> you might need to adjust this on >>MicroFocus >> move hexvalue (hv-x1) to bin-work >> end-search > > There is a much simpler way to convert hex digits: > > INSPECT current-byte CONVERTING > '0123456789ABCDEF' TO > X'000102030405060708090A0B0C0D0E0F' Cool! Will it work on ANY platform...? Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 31 Jul 2008 13:24 On Fri, 1 Aug 2008 04:10:30 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:o7e29413ea3ou9hjb0lq59msdkdkef2s9p(a)4ax.com... >> On Wed, 30 Jul 2008 17:37:20 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> >> wrote: >> >>>Think some more about the Hex string. Each byte is represented by 2 hex >>>symbols. If you had to, you could easily write a little COBOL routine that >>>would give you the same byte in binary... Here's an example that is by no >>>means definitive, but which I'm sure you can modify for your particular >>>environment... >>> >>>*> interface >>>01 two-bytes-in pic xx. >>>01 one-byte-out pic x. >>> >>>*> reference data >>>01 hc pic x(16) value '01234567890ABCDEF'. >>>01 filler redefines hc. >>> 12 hexchars pic x occurs 16 >>> indexed by hc-x1. >>>01 hv usage comp. >>> 12 x0 pic s9(4) value zero. >>> 12 x1 pic s9(4) value 1. >>> 12 x2 pic s9(4) value 2. >>> 12 x3 pic s9(4) value 3. >>> 12 x4 pic s9(4) value 4. >>> 12 x5 pic s9(4) value 5. >>> 12 x6 pic s9(4) value 6. >>> 12 x7 pic s9(4) value 7. >>> 12 x8 pic s9(4) value 8. >>> 12 x9 pic s9(4) value 9. >>> 12 xA pic s9(4) value 10. >>> 12 xB pic s9(4) value 11. >>> 12 xC pic s9(4) value 12. >>> 12 xD pic s9(4) value 13. >>> 12 xE pic s9(4) value 14. >>> 12 xF pic s9(4) value 15. >>>01 filler redefines hv. >>> 12 hexvalues pic s9(4) comp occurs 16 >>> indexed by hv-x1. >>> >> >>>get-binary section. >>>gb000. >>> set hc-x1 to 1 >>> search hexchars >>> at end >>> *> the HEX, isn't... drastic action needed...not shown here >>> when current-byte = hexchars (hc-x1) >>> set hv-x1 to hc-x1 *> you might need to adjust this on >>>MicroFocus >>> move hexvalue (hv-x1) to bin-work >>> end-search >> >> There is a much simpler way to convert hex digits: >> >> INSPECT current-byte CONVERTING >> '0123456789ABCDEF' TO >> X'000102030405060708090A0B0C0D0E0F' > >Cool! > >Will it work on ANY platform...? INSPECT .. CONVERTING and hex literals are in the 2002 Standard.
From: taoxianfeng on 1 Aug 2008 02:12
On 7¤ë31¤é, ¤È«á11:26, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > Coming up with another approach entirely to the problem. (I know Micro Focus > better on Windows than AIX, so this MAY take more work on AIX than it would on > Windows). > > It seems to me that some (possibly most) of the problems come from the > "download" process of the unloaded file being created as "line sequential". My > assumption is that on the mainframe it is a DCB=RECFM=VB (i.e. "variable length > QSAM) file. If so, then it may be worth looking into the Micro Focus "VRECGEN" > facility. Run some jobs (on the mainframe and the AIX environment), it might be > possible to get a > Record Sequential - Variable Length > file on AIX - with ALL the data "as it is on the mainframe". > > I am NOT saying that this is the "best" solution (or the only solution), but it > might be the easiest - if the "mandate" has come in that the file must be a DB2 > unloaded file from the mainframe that is downloaded to AIX and processed there > as a file that is THEN loaded into an AIX table. > > -- > Bill Klein > wmklein <at> ix.netcom.com VRECGEN is the supplied on Microfocus mainframe and Net Express...at least as I searched. And the original system is IBM Z/OS running IBM cobol. |