Physical File Characteristics Sample Clauses

Physical File Characteristics. 6.2.1 The Optional Daily Usage File will be distributed to <<customer_name>> via an agreed medium with CONNECT:Direct being the preferred transport method. The Daily Usage Feed will be a variable block format (2476) with an LRECL of 2472. The data on the Daily Usage Feed will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis (Monday through Friday except holidays). Details such as dataset name and delivery schedule will be addressed during negotiations of the distribution medium. There will be a maximum of one dataset per workday per OCN.
Sample 1Sample 2Sample 3See All (255)
Physical File Characteristics. 7.2.1 The Enhanced Optional Daily Usage Feed will be distributed to <<customer_name>> over their existing Optional Daily Usage File (ODUF) feed. The EODUF messages will be intermingled among <<customer_name>>’s Optional Daily Usage File (ODUF) messages. The EODUF will be a variable block format (2476) with an LRECL of 2472. The data on the EODUF will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis (Monday through Friday except holidays).
Sample 1Sample 2Sample 3See All (241)
Physical File Characteristics. 7.2.1 The EODUF feed will be distributed to SPARDI via Connect: Direct, Connect: Enterprise Client or another mutually agreed medium. The EODUF messages will be intermingled among SPARDI’s Optional Daily Usage File (ODUF) messages. The EODUF will be a variable block format. The data on the EODUF will be in a non- compacted EMI format (175 byte format plus modules). It will be created on a daily basis Monday through Friday except holiday.
Sample 1Sample 2See All (77)
Physical File Characteristics. 7.2.1 The EODUF feed will be distributed to NuVox over their existing ODUF feed. The EODUF messages will be intermingled among NuVox’s ODUF messages. The EODUF will be a variable block format (2476) with a LRECL of 2472. The data on the EODUF will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis (Monday through Friday except holidays).
Sample 1Sample 2Sample 3See All (13)
Physical File Characteristics. 7.2.1 The Enhanced Optional Daily Usage Feed will be distributed to New East Telephony, Inc. d/b/a Down Home Telephone over their existing Optional Daily Usage File (ODUF) feed. The EODUF messages will be intermingled among New East Telephony, Inc. d/b/a Down Home Telephone’s Optional Daily Usage File (ODUF) messages. The EODUF will be a variable block format (2476) with an LRECL of 2472. The data on the EODUF will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis (Monday through Friday except holidays).
Sample 1
Physical File Characteristics. 7.2.1 EODUF feed will be distributed to Tallahassee Telephone via Secure File Transfer Protocol (FTP). The EODUF messages will be intermingled among Tallahassee Telephone’s Optional Daily Usage File (ODUF) messages. The EODUF will be a variable block format. The data on the EODUF will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis Monday through Friday except holiday. If BellSouth determines the Secure FTP mailbox is nearing capacity levels, BellSouth may move the customer to CONNECT:Direct file delivery.
Sample 1Sample 2

Related to Physical File Characteristics

  • ODUF Physical File Characteristics 6.2.1 ODUF will be distributed to TWTC via Secure File Transfer Protocol (FTP). The ODUF feed will be a variable block format. The data on the ODUF feed will be in a non-compacted EMI format (175 byte format plus modules). It will be created on a daily basis Monday through Friday except holidays. Details such as dataset name and delivery schedule will be addressed during negotiations of the distribution medium. There will be a maximum of one dataset per workday per OCN. If AT&T determines the Secure FTP Mailbox is nearing capacity levels, AT&T may move the customer to CONNECT: Direct file delivery.

  • Authoritative Root Database To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (a) ensure that the authoritative root will point to the top-­‐level domain nameservers designated by Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction.