Automic Workload Automation

  • Private Community

  • 1.  Transport case file structure question — O record followed immediately by F record

    Posted May 15, 2017 12:41 PM
    Today I came across something that I had theretofore never seen in a transport case unload file: an O record followed immediately by F record. It seems that the TOH record marking the beginning of records for a new object is missing. Here is an excerpt:
    16367 TOH
    16368 F001+00100
    16369 F002CDOCU
    16370 F003CUC0.UAT.TEST#1_1.DOCU
    16371 F004+0003916132
    16372 F006+0001107131
    16373 F00720170418094936
    16374 F008+0001107131
    16375 F00920170418094936
    16376 F010+0000000001
    16377 F019001
    16378 F041M000000072^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00^K00
    16379 F049+0000000154
    16380 F063C00000000000000000000000000000000
    16381 F072C11.2
    16382 R
    16383 O\APPS{}\UC0{}\AUTOMATED_TESTS_ITE{}\TEST1{}\TEST1{}
    16384 F001+00100
    16385 F002CCALL
    16386 F003CUC0.ITE.TEST#1_1.CALL
    16387 F004+0003324899
    16388 F006+0001107131
    16389 F00720160622054022
    16390 F008+0003425117
    16391 F00920170502120727
    16392 F010+0000000017
    16393 F019001
    16394 F022+00001
    16395 F030C000000
    Line 16383 is the last record of a DOCU object, and line 16384 is the first record of a CALL object. As I understand the transport case file format, there is always a TOH record marking the beginning of a new object. This file was produced by ucybdbun version 11.2.3+build.416. The DB Load program does not complain when I tried to load this file into another system.

    Is this a bug, or is my understanding of the file format incomplete?

    The preceding object is a DOCU object with no content. As such, in the transport case file, it consists only of fields for the OH table. This sort of thing has apparently never come up in our environment before, or I would have seen it. Perhaps in this situation, one can assume that the succeeding group of F records (after the O record) also belongs to the OH table. (Since record 16384 starts over at F001, it’s pretty obvious that this is the start of a new object.)

    Thanks in advance for any light anyone can shed on this.


  • 2.  Transport case file structure question — O record followed immediately by F record

    Posted May 16, 2017 03:57 AM
    I will assume for now that my guess is correct. I updated my parsing scripts to handle this situation.


  • 3.  Transport case file structure question — O record followed immediately by F record

    Posted Jun 23, 2017 03:12 AM
    I ran into another similar situation today: a O record followed immediately by the S (end of file) record. This was another essentially empty object — this time, a JOBI. The object had records for only the OH table, so its O record was the last content record of the file. I have updated the parsing script to handle this situation, and will post the updated script shortly.

    Update 2017.08.28: I fixed this in v0.8 of the parsing script.